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

net: filter: make JITs zero A for SKF_AD_ALU_XOR_X

2016-02-15T20:42:43+00:00

[ Upstream commit 55795ef5469290f89f04e12e662ded604909e462 ]

The SKF_AD_ALU_XOR_X ancillary is not like the other ancillary data
instructions since it XORs A with X while all the others replace A with
some loaded value.  All the BPF JITs fail to clear A if this is used as
the first instruction in a filter.  This was found using american fuzzy
lop.

Add a helper to determine if A needs to be cleared given the first
instruction in a filter, and use this in the JITs.  Except for ARM, the
rest have only been compile-tested.

Fixes: 3480593131e0 ("net: filter: get rid of BPF_S_* enum")
Signed-off-by: Rabin Vincent 
Acked-by: Daniel Borkmann 
Acked-by: Alexei Starovoitov 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

unix: properly account for FDs passed over unix sockets

2016-02-15T20:42:43+00:00

[ Upstream commit 712f4aad406bb1ed67f3f98d04c044191f0ff593 ]

It is possible for a process to allocate and accumulate far more FDs than
the process' limit by sending them over a unix socket then closing them
to keep the process' fd count low.

This change addresses this problem by keeping track of the number of FDs
in flight per user and preventing non-privileged processes from having
more FDs in flight than their configured FD limit.

Reported-by: socketpair@gmail.com
Reported-by: Tetsuo Handa 
Mitigates: CVE-2013-4312 (Linux 2.0+)
Suggested-by: Linus Torvalds 
Acked-by: Hannes Frederic Sowa 
Signed-off-by: Willy Tarreau 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

radix-tree: fix oops after radix_tree_iter_retry

2016-02-15T20:42:41+00:00

[ Upstream commit 732042821cfa106b3c20b9780e4c60fee9d68900 ]

Helper radix_tree_iter_retry() resets next_index to the current index.
In following radix_tree_next_slot current chunk size becomes zero.  This
isn't checked and it tries to dereference null pointer in slot.

Tagged iterator is fine because retry happens only at slot 0 where tag
bitmask in iter->tags is filled with single bit.

Fixes: 46437f9a554f ("radix-tree: fix race in gang lookup")
Signed-off-by: Konstantin Khlebnikov 
Cc: Matthew Wilcox 
Cc: Hugh Dickins 
Cc: Ohad Ben-Cohen 
Cc: Jeremiah Mahler 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

mm: replace vma_lock_anon_vma with anon_vma_lock_read/write

2016-02-15T20:42:41+00:00

[ Upstream commit 12352d3cae2cebe18805a91fab34b534d7444231 ]

Sequence vma_lock_anon_vma() - vma_unlock_anon_vma() isn't safe if
anon_vma appeared between lock and unlock.  We have to check anon_vma
first or call anon_vma_prepare() to be sure that it's here.  There are
only few users of these legacy helpers.  Let's get rid of them.

This patch fixes anon_vma lock imbalance in validate_mm().  Write lock
isn't required here, read lock is enough.

And reorders expand_downwards/expand_upwards: security_mmap_addr() and
wrapping-around check don't have to be under anon vma lock.

Link: https://lkml.kernel.org/r/CACT4Y+Y908EjM2z=706dv4rV6dWtxTLK9nFg9_7DhRMLppBo2g@mail.gmail.com
Signed-off-by: Konstantin Khlebnikov 
Reported-by: Dmitry Vyukov 
Acked-by: Kirill A. Shutemov 
Cc: Andrea Arcangeli 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

radix-tree: fix race in gang lookup

2016-02-15T20:42:38+00:00

[ Upstream commit 46437f9a554fbe3e110580ca08ab703b59f2f95a ]

If the indirect_ptr bit is set on a slot, that indicates we need to redo
the lookup.  Introduce a new function radix_tree_iter_retry() which
forces the loop to retry the lookup by setting 'slot' to NULL and
turning the iterator back to point at the problematic entry.

This is a pretty rare problem to hit at the moment; the lookup has to
race with a grow of the radix tree from a height of 0.  The consequences
of hitting this race are that gang lookup could return a pointer to a
radix_tree_node instead of a pointer to whatever the user had inserted
in the tree.

Fixes: cebbd29e1c2f ("radix-tree: rewrite gang lookup using iterator")
Signed-off-by: Matthew Wilcox 
Cc: Hugh Dickins 
Cc: Ohad Ben-Cohen 
Cc: Konstantin Khlebnikov 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

printk: do cond_resched() between lines while outputting to consoles

2016-02-10T03:57:30+00:00

[ Upstream commit 8d91f8b15361dfb438ab6eb3b319e2ded43458ff ]

@console_may_schedule tracks whether console_sem was acquired through
lock or trylock.  If the former, we're inside a sleepable context and
console_conditional_schedule() performs cond_resched().  This allows
console drivers which use console_lock for synchronization to yield
while performing time-consuming operations such as scrolling.

However, the actual console outputting is performed while holding
irq-safe logbuf_lock, so console_unlock() clears @console_may_schedule
before starting outputting lines.  Also, only a few drivers call
console_conditional_schedule() to begin with.  This means that when a
lot of lines need to be output by console_unlock(), for example on a
console registration, the task doing console_unlock() may not yield for
a long time on a non-preemptible kernel.

If this happens with a slow console devices, for example a serial
console, the outputting task may occupy the cpu for a very long time.
Long enough to trigger softlockup and/or RCU stall warnings, which in
turn pile more messages, sometimes enough to trigger the next cycle of
warnings incapacitating the system.

Fix it by making console_unlock() insert cond_resched() between lines if
@console_may_schedule.

Signed-off-by: Tejun Heo 
Reported-by: Calvin Owens 
Acked-by: Jan Kara 
Cc: Dave Jones 
Cc: Kyle McMartin 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

locks: update comments that refer to inode->i_flock

2016-02-10T03:56:32+00:00

[ Upstream commit 8116bf4cb62d337c953cfa5369ef4cf83e73140c ]

Signed-off-by: Jeff Layton 
Signed-off-by: Sasha Levin

NFS: Remove the "NFS_CAP_CHANGE_ATTR" capability

2016-02-10T03:55:51+00:00

[ Upstream commit cd812599796f500b042f5464b6665755eca21137 ]

Setting the change attribute has been mandatory for all NFS versions, since
commit 3a1556e8662c ("NFSv2/v3: Simulate the change attribute"). We should
therefore not have anything be conditional on it being set/unset.

Signed-off-by: Trond Myklebust 
Signed-off-by: Sasha Levin

Thermal: do thermal zone update after a cooling device registered

2016-02-10T03:55:43+00:00

[ Upstream commit 4511f7166a2deb5f7a578cf87fd2fe1ae83527e3 ]

When a new cooling device is registered, we need to update the
thermal zone to set the new registered cooling device to a proper
state.

This fixes a problem that the system is cool, while the fan devices
are left running on full speed after boot, if fan device is registered
after thermal zone device.

Here is the history of why current patch looks like this:
https://patchwork.kernel.org/patch/7273041/

CC:  #3.18+
Reference:https://bugzilla.kernel.org/show_bug.cgi?id=92431
Tested-by: Manuel Krause 
Tested-by: szegad 
Tested-by: prash 
Tested-by: amish 
Reviewed-by: Javi Merino 
Signed-off-by: Zhang Rui 
Signed-off-by: Chen Yu 
Signed-off-by: Sasha Levin

Thermal: initialize thermal zone device correctly

2016-02-10T03:55:42+00:00

[ Upstream commit bb431ba26c5cd0a17c941ca6c3a195a3a6d5d461 ]

After thermal zone device registered, as we have not read any
temperature before, thus tz->temperature should not be 0,
which actually means 0C, and thermal trend is not available.
In this case, we need specially handling for the first
thermal_zone_device_update().

Both thermal core framework and step_wise governor is
enhanced to handle this. And since the step_wise governor
is the only one that uses trends, so it's the only thermal
governor that needs to be updated.

CC:  #3.18+
Tested-by: Manuel Krause 
Tested-by: szegad 
Tested-by: prash 
Tested-by: amish 
Tested-by: Matthias 
Reviewed-by: Javi Merino 
Signed-off-by: Zhang Rui 
Signed-off-by: Chen Yu 
Signed-off-by: Sasha Levin