linux-stable.git/include/linux, branch v3.18.24

iio: Add inverse unit conversion macros

2015-10-28T02:14:36+00:00

[ Upstream commit c689a923c867eac40ed3826c1d9328edea8b6bc7 ]

Add inverse unit conversion macro to convert from standard IIO units to
units that might be used by some devices.

Those are useful in combination with scale factors that are specified as
IIO_VAL_FRACTIONAL. Typically the denominator for those specifications will
contain the maximum raw value the sensor will generate and the numerator
the value it maps to in a specific unit. Sometimes datasheets specify those
in different units than the standard IIO units (e.g. degree/s instead of
rad/s) and so we need to do a unit conversion.

From a mathematical point of view it does not make a difference whether we
apply the unit conversion to the numerator or the inverse unit conversion
to the denominator since (x / y) / z = x / (y * z). But as the denominator
is typically a larger value and we are rounding both the numerator and
denominator to integer values using the later method gives us a better
precision (E.g. the relative error is smaller if we round 8000.3 to 8000
rather than rounding 8.3 to 8).

This is where in inverse unit conversion macros will be used.

Marked for stable as used by some upcoming fixes.

Signed-off-by: Lars-Peter Clausen 
Cc: 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Sasha Levin

overlayfs: Make f_path always point to the overlay and f_inode to the underlay

2015-10-28T02:14:24+00:00

[ Upstream commit 4bacc9c9234c7c8eec44f5ed4e960d9f96fa0f01 ]

Make file->f_path always point to the overlay dentry so that the path in
/proc/pid/fd is correct and to ensure that label-based LSMs have access to the
overlay as well as the underlay (path-based LSMs probably don't need it).

Using my union testsuite to set things up, before the patch I see:

	[root@andromeda union-testsuite]# bash 5 /a/foo107
	[root@andromeda union-testsuite]# stat /mnt/a/foo107
	...
	Device: 23h/35d Inode: 13381       Links: 1
	...
	[root@andromeda union-testsuite]# stat -L /proc/$$/fd/5
	...
	Device: 23h/35d Inode: 13381       Links: 1
	...

After the patch:

	[root@andromeda union-testsuite]# bash 5 /mnt/a/foo107
	[root@andromeda union-testsuite]# stat /mnt/a/foo107
	...
	Device: 23h/35d Inode: 40346       Links: 1
	...
	[root@andromeda union-testsuite]# stat -L /proc/$$/fd/5
	...
	Device: 23h/35d Inode: 40346       Links: 1
	...

Note the change in where /proc/$$/fd/5 points to in the ls command.  It was
pointing to /a/foo107 (which doesn't exist) and now points to /mnt/a/foo107
(which is correct).

The inode accessed, however, is the lower layer.  The union layer is on device
25h/37d and the upper layer on 24h/36d.

Signed-off-by: David Howells 
Signed-off-by: Al Viro 
Signed-off-by: Sasha Levin

VFS: Introduce inode-getting helpers for layered/unioned fs environments

2015-10-28T02:14:23+00:00

[ Upstream commit 155e35d4daa804582f75acaa2c74ec797a89c615 ]

Introduce some function for getting the inode (and also the dentry) in an
environment where layered/unioned filesystems are in operation.

The problem is that we have places where we need *both* the union dentry and
the lower source or workspace inode or dentry available, but we can only have
a handle on one of them.  Therefore we need to derive the handle to the other
from that.

The idea is to introduce an extra field in struct dentry that allows the union
dentry to refer to and pin the lower dentry.

Signed-off-by: David Howells 
Signed-off-by: Al Viro 
Signed-off-by: Sasha Levin

security: fix typo in security_task_prctl

2015-10-28T02:14:04+00:00

[ Upstream commit b7f76ea2ef6739ee484a165ffbac98deb855d3d3 ]

Signed-off-by: Jann Horn 
Reviewed-by: Andy Lutomirski 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

if_link: Add an additional parameter to ifla_vf_info for RSS querying

2015-10-27T13:31:42+00:00

[ Upstream commit 01a3d796813d6302af9f828f34b73d21a4b96c9a ]

Add configuration setting for drivers to allow/block an RSS Redirection
Table and a Hash Key querying for discrete VFs.

On some devices VF share the mentioned above information with PF and
querying it may adduce a theoretical security risk. We want to let a
system administrator to decide if he/she wants to take this risk or not.

Signed-off-by: Vlad Zolotarov 
Tested-by: Phil Schmitt 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Sasha Levin

rcu: Move lockless_dereference() out of rcupdate.h

2015-09-27T16:18:53+00:00

[ Upstream commit 0a04b0166929405cd833c1cc40f99e862b965ddc ]

I want to use lockless_dereference() from seqlock.h, which would mean
including rcupdate.h from it, however rcupdate.h already includes
seqlock.h.

Avoid this by moving lockless_dereference() into compiler.h. This is
somewhat tricky since it uses smp_read_barrier_depends() which isn't
available there, but its a CPP macro so we can get away with it.

The alternative would be moving it into asm/barrier.h, but that would
be updating each arch (I can do if people feel that is more
appropriate).

Cc: Paul McKenney 
Signed-off-by: Peter Zijlstra (Intel) 
Signed-off-by: Rusty Russell 
Signed-off-by: Sasha Levin

libata: add ATA_HORKAGE_NOTRIM

2015-08-27T17:26:11+00:00

[ Upstream commit 71d126fd28de2d4d9b7b2088dbccd7ca62fad6e0 ]

Some devices lose data on TRIM whether queued or not.  This patch adds
a horkage to disable TRIM.

tj: Collapsed unnecessary if() nesting.

Signed-off-by: Arne Fitzenreiter 
Signed-off-by: Tejun Heo 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

libata: Whitelist SSDs that are known to properly return zeroes after TRIM

2015-08-27T17:26:08+00:00

[ Upstream commit e61f7d1c3c07a7e51036b0796749edb00deff845 ]

As defined, the DRAT (Deterministic Read After Trim) and RZAT (Return
Zero After Trim) flags in the ATA Command Set are unreliable in the
sense that they only define what happens if the device successfully
executed the DSM TRIM command. TRIM is only advisory, however, and the
device is free to silently ignore all or parts of the request.

In practice this renders the DRAT and RZAT flags completely useless and
because the results are unpredictable we decided to disable discard in
MD for 3.18 to avoid the risk of data corruption.

Hardware vendors in the real world obviously need better guarantees than
what the standards bodies provide. Unfortuntely those guarantees are
encoded in product requirements documents rather than somewhere we can
key off of them programatically. So we are compelled to disabling
discard_zeroes_data for all devices unless we explicitly have data to
support whitelisting them.

This patch whitelists SSDs from a few of the main vendors. None of the
whitelists are based on written guarantees. They are purely based on
empirical evidence collected from internal and external users that have
tested or qualified these drives in RAID deployments.

The whitelist is only meant as a starting point and is by no means
comprehensive:

   - All intel SSD models except for 510
   - Micron M5?0/M600
   - Samsung SSDs
   - Seagate SSDs

Signed-off-by: Martin K. Petersen 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Tejun Heo 
Signed-off-by: Sasha Levin

Revert "libata: add ATA_HORKAGE_NOTRIM"

2015-08-27T17:26:07+00:00

This reverts commit e7a84605061b205350654641d823e1ca9589ec24.

kexec: allocate the kexec control page with KEXEC_CONTROL_MEMORY_GFP

2015-08-27T17:26:05+00:00

[ Upstream commit 7e01b5acd88b3f3108d8c4ce44e3205d67437202 ]

Introduce KEXEC_CONTROL_MEMORY_GFP to allow the architecture code
to override the gfp flags of the allocation for the kexec control
page. The loop in kimage_alloc_normal_control_pages allocates pages
with GFP_KERNEL until a page is found that happens to have an
address smaller than the KEXEC_CONTROL_MEMORY_LIMIT. On systems
with a large memory size but a small KEXEC_CONTROL_MEMORY_LIMIT
the loop will keep allocating memory until the oom killer steps in.

Signed-off-by: Martin Schwidefsky 
Signed-off-by: Sasha Levin