Skip to content

Commit

Permalink
Merge branch 'cm-12.1' into ef52/cm-12.1
Browse files Browse the repository at this point in the history
  • Loading branch information
Lê Hoàng committed Nov 15, 2015
2 parents 56271e0 + 00a47f7 commit a001fc0
Show file tree
Hide file tree
Showing 3,087 changed files with 48,885 additions and 23,312 deletions.
The diff you're trying to view is too large. We only load the first 3000 changed files.
6 changes: 0 additions & 6 deletions Documentation/ABI/testing/sysfs-bus-rbd
View file
Original file line number Diff line number Diff line change
Expand Up @@ -51,12 +51,6 @@ current_snap

The current snapshot for which the device is mapped.

create_snap

Create a snapshot:

$ echo <snap-name> > /sys/bus/rbd/devices/<dev-id>/snap_create

snap_*

A directory per each snapshot
Expand Down
32 changes: 16 additions & 16 deletions Documentation/HOWTO
View file
Original file line number Diff line number Diff line change
Expand Up @@ -218,16 +218,16 @@ The development process
Linux kernel development process currently consists of a few different
main kernel "branches" and lots of different subsystem-specific kernel
branches. These different branches are:
- main 2.6.x kernel tree
- 2.6.x.y -stable kernel tree
- 2.6.x -git kernel patches
- main 3.x kernel tree
- 3.x.y -stable kernel tree
- 3.x -git kernel patches
- subsystem specific kernel trees and patches
- the 2.6.x -next kernel tree for integration tests
- the 3.x -next kernel tree for integration tests

2.6.x kernel tree
3.x kernel tree
-----------------
2.6.x kernels are maintained by Linus Torvalds, and can be found on
kernel.org in the pub/linux/kernel/v2.6/ directory. Its development
3.x kernels are maintained by Linus Torvalds, and can be found on
kernel.org in the pub/linux/kernel/v3.x/ directory. Its development
process is as follows:
- As soon as a new kernel is released a two weeks window is open,
during this period of time maintainers can submit big diffs to
Expand Down Expand Up @@ -262,20 +262,20 @@ mailing list about kernel releases:
released according to perceived bug status, not according to a
preconceived timeline."

2.6.x.y -stable kernel tree
3.x.y -stable kernel tree
---------------------------
Kernels with 4-part versions are -stable kernels. They contain
Kernels with 3-part versions are -stable kernels. They contain
relatively small and critical fixes for security problems or significant
regressions discovered in a given 2.6.x kernel.
regressions discovered in a given 3.x kernel.

This is the recommended branch for users who want the most recent stable
kernel and are not interested in helping test development/experimental
versions.

If no 2.6.x.y kernel is available, then the highest numbered 2.6.x
If no 3.x.y kernel is available, then the highest numbered 3.x
kernel is the current stable kernel.

2.6.x.y are maintained by the "stable" team <stable@vger.kernel.org>, and
3.x.y are maintained by the "stable" team <stable@vger.kernel.org>, and
are released as needs dictate. The normal release period is approximately
two weeks, but it can be longer if there are no pressing problems. A
security-related problem, instead, can cause a release to happen almost
Expand All @@ -285,7 +285,7 @@ The file Documentation/stable_kernel_rules.txt in the kernel tree
documents what kinds of changes are acceptable for the -stable tree, and
how the release process works.

2.6.x -git patches
3.x -git patches
------------------
These are daily snapshots of Linus' kernel tree which are managed in a
git repository (hence the name.) These patches are usually released
Expand Down Expand Up @@ -317,13 +317,13 @@ revisions to it, and maintainers can mark patches as under review,
accepted, or rejected. Most of these patchwork sites are listed at
http://patchwork.kernel.org/.

2.6.x -next kernel tree for integration tests
3.x -next kernel tree for integration tests
---------------------------------------------
Before updates from subsystem trees are merged into the mainline 2.6.x
Before updates from subsystem trees are merged into the mainline 3.x
tree, they need to be integration-tested. For this purpose, a special
testing repository exists into which virtually all subsystem trees are
pulled on an almost daily basis:
http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git
http://linux.f-seidel.de/linux-next/pmwiki/

This way, the -next kernel gives a summary outlook onto what will be
Expand Down
6 changes: 3 additions & 3 deletions Documentation/cgroups/cpusets.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -345,14 +345,14 @@ the named feature on.
The implementation is simple.

Setting the flag 'cpuset.memory_spread_page' turns on a per-process flag
PF_SPREAD_PAGE for each task that is in that cpuset or subsequently
PFA_SPREAD_PAGE for each task that is in that cpuset or subsequently
joins that cpuset. The page allocation calls for the page cache
is modified to perform an inline check for this PF_SPREAD_PAGE task
is modified to perform an inline check for this PFA_SPREAD_PAGE task
flag, and if set, a call to a new routine cpuset_mem_spread_node()
returns the node to prefer for the allocation.

Similarly, setting 'cpuset.memory_spread_slab' turns on the flag
PF_SPREAD_SLAB, and appropriately marked slab caches will allocate
PFA_SPREAD_SLAB, and appropriately marked slab caches will allocate
pages from the node returned by cpuset_mem_spread_node().

The cpuset_mem_spread_node() routine is also simple. It uses the
Expand Down
4 changes: 4 additions & 0 deletions Documentation/cgroups/memory.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -466,6 +466,10 @@ Note:
5.3 swappiness

Similar to /proc/sys/vm/swappiness, but affecting a hierarchy of groups only.
Please note that unlike the global swappiness, memcg knob set to 0
really prevents from any swapping even if there is a swap storage
available. This might lead to memcg OOM killer if there are no file
pages to reclaim.

Following cgroups' swappiness can't be changed.
- root cgroup (uses /proc/sys/vm/swappiness).
Expand Down
131 changes: 46 additions & 85 deletions Documentation/device-mapper/verity.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -7,39 +7,39 @@ This target is read-only.

Construction Parameters
=======================
<version> <dev> <hash_dev> <hash_start>
<version> <dev> <hash_dev>
<data_block_size> <hash_block_size>
<num_data_blocks> <hash_start_block>
<algorithm> <digest> <salt>

<version>
This is the version number of the on-disk format.
This is the type of the on-disk hash format.

0 is the original format used in the Chromium OS.
The salt is appended when hashing, digests are stored continuously and
the rest of the block is padded with zeros.
The salt is appended when hashing, digests are stored continuously and
the rest of the block is padded with zeros.

1 is the current format that should be used for new devices.
The salt is prepended when hashing and each digest is
padded with zeros to the power of two.
The salt is prepended when hashing and each digest is
padded with zeros to the power of two.

<dev>
This is the device containing the data the integrity of which needs to be
This is the device containing data, the integrity of which needs to be
checked. It may be specified as a path, like /dev/sdaX, or a device number,
<major>:<minor>.

<hash_dev>
This is the device that that supplies the hash tree data. It may be
This is the device that supplies the hash tree data. It may be
specified similarly to the device path and may be the same device. If the
same device is used, the hash_start should be outside of the dm-verity
configured device size.
same device is used, the hash_start should be outside the configured
dm-verity device.

<data_block_size>
The block size on a data device. Each block corresponds to one digest on
the hash device.
The block size on a data device in bytes.
Each block corresponds to one digest on the hash device.

<hash_block_size>
The size of a hash block.
The size of a hash block in bytes.

<num_data_blocks>
The number of data blocks on the data device. Additional blocks are
Expand All @@ -65,28 +65,28 @@ Construction Parameters
Theory of operation
===================

dm-verity is meant to be setup as part of a verified boot path. This
dm-verity is meant to be set up as part of a verified boot path. This
may be anything ranging from a boot using tboot or trustedgrub to just
booting from a known-good device (like a USB drive or CD).

When a dm-verity device is configured, it is expected that the caller
has been authenticated in some way (cryptographic signatures, etc).
After instantiation, all hashes will be verified on-demand during
disk access. If they cannot be verified up to the root node of the
tree, the root hash, then the I/O will fail. This should identify
tree, the root hash, then the I/O will fail. This should detect
tampering with any data on the device and the hash data.

Cryptographic hashes are used to assert the integrity of the device on a
per-block basis. This allows for a lightweight hash computation on first read
into the page cache. Block hashes are stored linearly-aligned to the nearest
block the size of a page.
per-block basis. This allows for a lightweight hash computation on first read
into the page cache. Block hashes are stored linearly, aligned to the nearest
block size.

Hash Tree
---------

Each node in the tree is a cryptographic hash. If it is a leaf node, the hash
is of some block data on disk. If it is an intermediary node, then the hash is
of a number of child nodes.
of some data block on disk is calculated. If it is an intermediary node,
the hash of a number of child nodes is calculated.

Each entry in the tree is a collection of neighboring nodes that fit in one
block. The number is determined based on block_size and the size of the
Expand All @@ -110,85 +110,46 @@ alg = sha256, num_blocks = 32768, block_size = 4096
On-disk format
==============

Below is the recommended on-disk format. The verity kernel code does not
read the on-disk header. It only reads the hash blocks which directly
follow the header. It is expected that a user-space tool will verify the
integrity of the verity_header and then call dmsetup with the correct
parameters. Alternatively, the header can be omitted and the dmsetup
parameters can be passed via the kernel command-line in a rooted chain
of trust where the command-line is verified.
The verity kernel code does not read the verity metadata on-disk header.
It only reads the hash blocks which directly follow the header.
It is expected that a user-space tool will verify the integrity of the
verity header.

The on-disk format is especially useful in cases where the hash blocks
are on a separate partition. The magic number allows easy identification
of the partition contents. Alternatively, the hash blocks can be stored
in the same partition as the data to be verified. In such a configuration
the filesystem on the partition would be sized a little smaller than
the full-partition, leaving room for the hash blocks.

struct superblock {
uint8_t signature[8]
"verity\0\0";

uint8_t version;
1 - current format

uint8_t data_block_bits;
log2(data block size)

uint8_t hash_block_bits;
log2(hash block size)

uint8_t pad1[1];
zero padding

uint16_t salt_size;
big-endian salt size

uint8_t pad2[2];
zero padding

uint32_t data_blocks_hi;
big-endian high 32 bits of the 64-bit number of data blocks

uint32_t data_blocks_lo;
big-endian low 32 bits of the 64-bit number of data blocks

uint8_t algorithm[16];
cryptographic algorithm

uint8_t salt[384];
salt (the salt size is specified above)

uint8_t pad3[88];
zero padding to 512-byte boundary
}
Alternatively, the header can be omitted and the dmsetup parameters can
be passed via the kernel command-line in a rooted chain of trust where
the command-line is verified.

Directly following the header (and with sector number padded to the next hash
block boundary) are the hash blocks which are stored a depth at a time
(starting from the root), sorted in order of increasing index.

The full specification of kernel parameters and on-disk metadata format
is available at the cryptsetup project's wiki page
http://code.google.com/p/cryptsetup/wiki/DMVerity

Status
======
V (for Valid) is returned if every check performed so far was valid.
If any check failed, C (for Corruption) is returned.

Example
=======

Setup a device:
dmsetup create vroot --table \
"0 2097152 "\
"verity 1 /dev/sda1 /dev/sda2 4096 4096 2097152 1 "\
Set up a device:
# dmsetup create vroot --readonly --table \
"0 2097152 verity 1 /dev/sda1 /dev/sda2 4096 4096 262144 1 sha256 "\
"4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076 "\
"1234000000000000000000000000000000000000000000000000000000000000"

A command line tool veritysetup is available to compute or verify
the hash tree or activate the kernel driver. This is available from
the LVM2 upstream repository and may be supplied as a package called
device-mapper-verity-tools:
git://sources.redhat.com/git/lvm2
http://sourceware.org/git/?p=lvm2.git
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/verity?cvsroot=lvm2

veritysetup -a vroot /dev/sda1 /dev/sda2 \
4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076
the hash tree or activate the kernel device. This is available from
the cryptsetup upstream repository http://code.google.com/p/cryptsetup/
(as a libcryptsetup extension).

Create hash on the device:
# veritysetup format /dev/sda1 /dev/sda2
...
Root hash: 4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076

Activate the device:
# veritysetup create vroot /dev/sda1 /dev/sda2 \
4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076
2 changes: 1 addition & 1 deletion Documentation/devicetree/bindings/arm/atmel-at91.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ PIT Timer required properties:
shared across all System Controller members.

TC/TCLIB Timer required properties:
- compatible: Should be "atmel,<chip>-pit".
- compatible: Should be "atmel,<chip>-tcb".
<chip> can be "at91rm9200" or "at91sam9x5"
- reg: Should contain registers location and length
- interrupts: Should contain all interrupts for the TC block
Expand Down
8 changes: 4 additions & 4 deletions Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -10,8 +10,8 @@ Required properties:

Optional properties:
- fsl,card-wired : Indicate the card is wired to host permanently
- fsl,cd-internal : Indicate to use controller internal card detection
- fsl,wp-internal : Indicate to use controller internal write protection
- fsl,cd-controller : Indicate to use controller internal card detection
- fsl,wp-controller : Indicate to use controller internal write protection
- cd-gpios : Specify GPIOs for card detection
- wp-gpios : Specify GPIOs for write protection

Expand All @@ -21,8 +21,8 @@ esdhc@70004000 {
compatible = "fsl,imx51-esdhc";
reg = <0x70004000 0x4000>;
interrupts = <1>;
fsl,cd-internal;
fsl,wp-internal;
fsl,cd-controller;
fsl,wp-controller;
};

esdhc@70008000 {
Expand Down
3 changes: 3 additions & 0 deletions Documentation/devicetree/bindings/tty/serial/of-serial.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -10,6 +10,9 @@ Required properties:
- "ns16850"
- "nvidia,tegra20-uart"
- "ibm,qpace-nwp-serial"
- "altr,16550-FIFO32"
- "altr,16550-FIFO64"
- "altr,16550-FIFO128"
- "serial" if the port type is unknown.
- reg : offset and length of the register set for the device.
- interrupts : should contain uart interrupt.
Expand Down
2 changes: 1 addition & 1 deletion Documentation/dvb/get_dvb_firmware
View file
Original file line number Diff line number Diff line change
Expand Up @@ -115,7 +115,7 @@ sub tda10045 {

sub tda10046 {
my $sourcefile = "TT_PCI_2.19h_28_11_2006.zip";
my $url = "http://www.tt-download.com/download/updates/219/$sourcefile";
my $url = "http://technotrend.com.ua/download/software/219/$sourcefile";
my $hash = "6a7e1e2f2644b162ff0502367553c72d";
my $outfile = "dvb-fe-tda10046.fw";
my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1);
Expand Down
Loading

0 comments on commit a001fc0

Please sign in to comment.