linux-toradex.git/Documentation, branch toradex_vf_4.1

Merge tag 'v4.1.39' into toradex_vf_4.1-next

2017-03-15T17:35:51+00:00

Linux 4.1.39

Merge tag 'v4.1.32' into toradex_vf_4.1-next

2017-03-15T17:35:47+00:00

Linux 4.1.32

Merge tag 'v4.1.24' into toradex_vf_4.1-next

2017-03-15T17:35:46+00:00

Linux 4.1.24

KVM: PPC: Book3S HV: Save/restore XER in checkpointed register state

2017-01-13T01:56:54+00:00

[ Upstream commit 0d808df06a44200f52262b6eb72bcb6042f5a7c5 ]

When switching from/to a guest that has a transaction in progress,
we need to save/restore the checkpointed register state.  Although
XER is part of the CPU state that gets checkpointed, the code that
does this saving and restoring doesn't save/restore XER.

This fixes it by saving and restoring the XER.  To allow userspace
to read/write the checkpointed XER value, we also add a new ONE_REG
specifier.

The visible effect of this bug is that the guest may see its XER
value being corrupted when it uses transactions.

Fixes: e4e38121507a ("KVM: PPC: Book3S HV: Add transactional memory support")
Fixes: 0a8eccefcb34 ("KVM: PPC: Book3S HV: Add missing code for transaction reclaim on guest exit")
Cc: stable@vger.kernel.org # v3.15+
Signed-off-by: Paul Mackerras 
Reviewed-by: Thomas Huth 
Signed-off-by: Paul Mackerras 
Signed-off-by: Sasha Levin

mnt: Add a per mount namespace limit on the number of mounts

2016-12-23T13:56:35+00:00

[ Upstream commit d29216842a85c7970c536108e093963f02714498 ]

CAI Qian  pointed out that the semantics
of shared subtrees make it possible to create an exponentially
increasing number of mounts in a mount namespace.

    mkdir /tmp/1 /tmp/2
    mount --make-rshared /
    for i in $(seq 1 20) ; do mount --bind /tmp/1 /tmp/2 ; done

Will create create 2^20 or 1048576 mounts, which is a practical problem
as some people have managed to hit this by accident.

As such CVE-2016-6213 was assigned.

Ian Kent  described the situation for autofs users
as follows:

> The number of mounts for direct mount maps is usually not very large because of
> the way they are implemented, large direct mount maps can have performance
> problems. There can be anywhere from a few (likely case a few hundred) to less
> than 10000, plus mounts that have been triggered and not yet expired.
>
> Indirect mounts have one autofs mount at the root plus the number of mounts that
> have been triggered and not yet expired.
>
> The number of autofs indirect map entries can range from a few to the common
> case of several thousand and in rare cases up to between 30000 and 50000. I've
> not heard of people with maps larger than 50000 entries.
>
> The larger the number of map entries the greater the possibility for a large
> number of active mounts so it's not hard to expect cases of a 1000 or somewhat
> more active mounts.

So I am setting the default number of mounts allowed per mount
namespace at 100,000.  This is more than enough for any use case I
know of, but small enough to quickly stop an exponential increase
in mounts.  Which should be perfect to catch misconfigurations and
malfunctioning programs.

For anyone who needs a higher limit this can be changed by writing
to the new /proc/sys/fs/mount-max sysctl.

Tested-by: CAI Qian 
Signed-off-by: "Eric W. Biederman" 

Conflicts:
	fs/namespace.c
	kernel/sysctl.c

Signed-off-by: Philipp Hahn 
Signed-off-by: Sasha Levin

fs: Give dentry to inode_change_ok() instead of inode

2016-12-23T13:56:35+00:00

[ Upstream commit 31051c85b5e2aaaf6315f74c72a732673632a905 ]

inode_change_ok() will be resposible for clearing capabilities and IMA
extended attributes and as such will need dentry. Give it as an argument
to inode_change_ok() instead of an inode. Also rename inode_change_ok()
to setattr_prepare() to better relect that it does also some
modifications in addition to checks.

References: CVE-2015-1350
Reviewed-by: Christoph Hellwig 
Signed-off-by: Jan Kara 
Signed-off-by: Philipp Hahn 
Signed-off-by: Sasha Levin

bus: arm-ccn: Provide required event arguments

2016-12-22T03:45:34+00:00

[ Upstream commit 8f06c51fac1ca4104b8b64872f310e28186aea42 ]

Since 688d4dfcdd624192cbf03c08402e444d1d11f294 "perf tools: Support
parsing parameterized events" the perf userspace tools understands
"argument=?" syntax in the events file, making sure that required
arguments are provided by the user and not defaulting to 0, causing
confusion.

This patch adds the required arguments lists for CCN events.

Signed-off-by: Pawel Moll 
Signed-off-by: Sasha Levin

x86/mm: Expand the exception table logic to allow new handling options

2016-10-30T18:15:18+00:00

[ Upstream commit 548acf19234dbda5a52d5a8e7e205af46e9da840 ]

Huge amounts of help from  Andy Lutomirski and Borislav Petkov to
produce this. Andy provided the inspiration to add classes to the
exception table with a clever bit-squeezing trick, Boris pointed
out how much cleaner it would all be if we just had a new field.

Linus Torvalds blessed the expansion with:

  ' I'd rather not be clever in order to save just a tiny amount of space
    in the exception table, which isn't really criticial for anybody. '

The third field is another relative function pointer, this one to a
handler that executes the actions.

We start out with three handlers:

 1: Legacy - just jumps the to fixup IP
 2: Fault - provide the trap number in %ax to the fixup code
 3: Cleaned up legacy for the uaccess error hack

Signed-off-by: Tony Luck 
Reviewed-by: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/f6af78fcbd348cf4939875cfda9c19689b5e50b8.1455732970.git.tony.luck@intel.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin

iio: proximity: as3935: correct IIO_CHAN_INFO_RAW output

2016-08-20T03:08:41+00:00

[ Upstream commit 5138806f16c74c7cb8ac3e408a859c79eb7c9567 ]

IIO_CHAN_INFO_RAW was returning processed data which was incorrect.
This also adds the IIO_CHAN_INFO_SCALE value to convert to a processed value.

Signed-off-by: Matt Ranostay 
Cc: 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Sasha Levin

Documentation/module-signing.txt: Note need for version info if reusing a key

2016-08-20T03:07:58+00:00

[ Upstream commit b8612e517c3c9809e1200b72c474dbfd969e5a83 ]

Signing a module should only make it trusted by the specific kernel it
was built for, not anything else.  If a module signing key is used for
multiple ABI-incompatible kernels, the modules need to include enough
version information to distinguish them.

Signed-off-by: Ben Hutchings 
Cc: stable@vger.kernel.org
Signed-off-by: Rusty Russell 
Signed-off-by: Sasha Levin