linux-toradex.git/include, branch v4.4.7

bitops: Do not default to __clear_bit() for __clear_bit_unlock()

2016-04-12T16:09:00+00:00

commit f75d48644c56a31731d17fa693c8175328957e1d upstream.

__clear_bit_unlock() is a special little snowflake. While it carries the
non-atomic '__' prefix, it is specifically documented to pair with
test_and_set_bit() and therefore should be 'somewhat' atomic.

Therefore the generic implementation of __clear_bit_unlock() cannot use
the fully non-atomic __clear_bit() as a default.

If an arch is able to do better; is must provide an implementation of
__clear_bit_unlock() itself.

Specifically, this came up as a result of hackbench livelock'ing in
slab_lock() on ARC with SMP + SLUB + !LLSC.

The issue was incorrect pairing of atomic ops.

 slab_lock() -> bit_spin_lock() -> test_and_set_bit()
 slab_unlock() -> __bit_spin_unlock() -> __clear_bit()

The non serializing __clear_bit() was getting "lost"

 80543b8e:	ld_s       r2,[r13,0] <--- (A) Finds PG_locked is set
 80543b90:	or         r3,r2,1    <--- (B) other core unlocks right here
 80543b94:	st_s       r3,[r13,0] <--- (C) sets PG_locked (overwrites unlock)

Fixes ARC STAR 9000817404 (and probably more).

Reported-by: Vineet Gupta 
Tested-by: Vineet Gupta 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Andrew Morton 
Cc: Christoph Lameter 
Cc: David Rientjes 
Cc: Helge Deller 
Cc: James E.J. Bottomley 
Cc: Joonsoo Kim 
Cc: Linus Torvalds 
Cc: Noam Camus 
Cc: Paul E. McKenney 
Cc: Pekka Enberg 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20160309114054.GJ6356@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

tracing: Fix trace_printk() to print when not using bprintk()

2016-04-12T16:09:00+00:00

commit 3debb0a9ddb16526de8b456491b7db60114f7b5e upstream.

The trace_printk() code will allocate extra buffers if the compile detects
that a trace_printk() is used. To do this, the format of the trace_printk()
is saved to the __trace_printk_fmt section, and if that section is bigger
than zero, the buffers are allocated (along with a message that this has
happened).

If trace_printk() uses a format that is not a constant, and thus something
not guaranteed to be around when the print happens, the compiler optimizes
the fmt out, as it is not used, and the __trace_printk_fmt section is not
filled. This means the kernel will not allocate the special buffers needed
for the trace_printk() and the trace_printk() will not write anything to the
tracing buffer.

Adding a "__used" to the variable in the __trace_printk_fmt section will
keep it around, even though it is set to NULL. This will keep the string
from being printed in the debugfs/tracing/printk_formats section as it is
not needed.

Reported-by: Vlastimil Babka 
Fixes: 07d777fe8c398 "tracing: Add percpu buffers for trace_printk()"
Signed-off-by: Steven Rostedt 
Signed-off-by: Greg Kroah-Hartman

fs/coredump: prevent fsuid=0 dumps into user-controlled directories

2016-04-12T16:08:58+00:00

commit 378c6520e7d29280f400ef2ceaf155c86f05a71a upstream.

This commit fixes the following security hole affecting systems where
all of the following conditions are fulfilled:

 - The fs.suid_dumpable sysctl is set to 2.
 - The kernel.core_pattern sysctl's value starts with "/". (Systems
   where kernel.core_pattern starts with "|/" are not affected.)
 - Unprivileged user namespace creation is permitted. (This is
   true on Linux >=3.8, but some distributions disallow it by
   default using a distro patch.)

Under these conditions, if a program executes under secure exec rules,
causing it to run with the SUID_DUMP_ROOT flag, then unshares its user
namespace, changes its root directory and crashes, the coredump will be
written using fsuid=0 and a path derived from kernel.core_pattern - but
this path is interpreted relative to the root directory of the process,
allowing the attacker to control where a coredump will be written with
root privileges.

To fix the security issue, always interpret core_pattern for dumps that
are written under SUID_DUMP_ROOT relative to the root directory of init.

Signed-off-by: Jann Horn 
Acked-by: Kees Cook 
Cc: Al Viro 
Cc: "Eric W. Biederman" 
Cc: Andy Lutomirski 
Cc: Oleg Nesterov 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

cgroup: ignore css_sets associated with dead cgroups during migration

2016-04-12T16:08:54+00:00

commit 2b021cbf3cb6208f0d40fd2f1869f237934340ed upstream.

Before 2e91fa7f6d45 ("cgroup: keep zombies associated with their
original cgroups"), all dead tasks were associated with init_css_set.
If a zombie task is requested for migration, while migration prep
operations would still be performed on init_css_set, the actual
migration would ignore zombie tasks.  As init_css_set is always valid,
this worked fine.

However, after 2e91fa7f6d45, zombie tasks stay with the css_set it was
associated with at the time of death.  Let's say a task T associated
with cgroup A on hierarchy H-1 and cgroup B on hiearchy H-2.  After T
becomes a zombie, it would still remain associated with A and B.  If A
only contains zombie tasks, it can be removed.  On removal, A gets
marked offline but stays pinned until all zombies are drained.  At
this point, if migration is initiated on T to a cgroup C on hierarchy
H-2, migration path would try to prepare T's css_set for migration and
trigger the following.

 WARNING: CPU: 0 PID: 1576 at kernel/cgroup.c:474 cgroup_get+0x121/0x160()
 CPU: 0 PID: 1576 Comm: bash Not tainted 4.4.0-work+ #289
 ...
 Call Trace:
  [] dump_stack+0x4e/0x82
  [] warn_slowpath_common+0x78/0xb0
  [] warn_slowpath_null+0x15/0x20
  [] cgroup_get+0x121/0x160
  [] link_css_set+0x7b/0x90
  [] find_css_set+0x3bc/0x5e0
  [] cgroup_migrate_prepare_dst+0x89/0x1f0
  [] cgroup_attach_task+0x157/0x230
  [] __cgroup_procs_write+0x2b7/0x470
  [] cgroup_tasks_write+0xc/0x10
  [] cgroup_file_write+0x30/0x1b0
  [] kernfs_fop_write+0x13c/0x180
  [] __vfs_write+0x23/0xe0
  [] vfs_write+0xa4/0x1a0
  [] SyS_write+0x44/0xa0
  [] entry_SYSCALL_64_fastpath+0x12/0x6f

It doesn't make sense to prepare migration for css_sets pointing to
dead cgroups as they are guaranteed to contain only zombies which are
ignored later during migration.  This patch makes cgroup destruction
path mark all affected css_sets as dead and updates the migration path
to ignore them during preparation.

Signed-off-by: Tejun Heo 
Fixes: 2e91fa7f6d45 ("cgroup: keep zombies associated with their original cgroups")
Signed-off-by: Greg Kroah-Hartman

tty: Fix GPF in flush_to_ldisc(), part 2

2016-04-12T16:08:49+00:00

commit f33798deecbd59a2955f40ac0ae2bc7dff54c069 upstream.

commit 9ce119f318ba ("tty: Fix GPF in flush_to_ldisc()") fixed a
GPF caused by a line discipline which does not define a receive_buf()
method.

However, the vt driver (and speakup driver also) pushes selection
data directly to the line discipline receive_buf() method via
tty_ldisc_receive_buf(). Fix the same problem in tty_ldisc_receive_buf().

Signed-off-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman

dm snapshot: disallow the COW and origin devices from being identical

2016-04-12T16:08:39+00:00

commit 4df2bf466a9c9c92f40d27c4aa9120f4e8227bfc upstream.

Otherwise loading a "snapshot" table using the same device for the
origin and COW devices, e.g.:

echo "0 20971520 snapshot 253:3 253:3 P 8" | dmsetup create snap

will trigger:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000098
[ 1958.979934] IP: [] dm_exception_store_set_chunk_size+0x7a/0x110 [dm_snapshot]
[ 1958.989655] PGD 0
[ 1958.991903] Oops: 0000 [#1] SMP
...
[ 1959.059647] CPU: 9 PID: 3556 Comm: dmsetup Tainted: G          IO    4.5.0-rc5.snitm+ #150
...
[ 1959.083517] task: ffff8800b9660c80 ti: ffff88032a954000 task.ti: ffff88032a954000
[ 1959.091865] RIP: 0010:[]  [] dm_exception_store_set_chunk_size+0x7a/0x110 [dm_snapshot]
[ 1959.104295] RSP: 0018:ffff88032a957b30  EFLAGS: 00010246
[ 1959.110219] RAX: 0000000000000000 RBX: 0000000000000008 RCX: 0000000000000001
[ 1959.118180] RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff880329334a00
[ 1959.126141] RBP: ffff88032a957b50 R08: 0000000000000000 R09: 0000000000000001
[ 1959.134102] R10: 000000000000000a R11: f000000000000000 R12: ffff880330884d80
[ 1959.142061] R13: 0000000000000008 R14: ffffc90001c13088 R15: ffff880330884d80
[ 1959.150021] FS:  00007f8926ba3840(0000) GS:ffff880333440000(0000) knlGS:0000000000000000
[ 1959.159047] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1959.165456] CR2: 0000000000000098 CR3: 000000032f48b000 CR4: 00000000000006e0
[ 1959.173415] Stack:
[ 1959.175656]  ffffc90001c13040 ffff880329334a00 ffff880330884ed0 ffff88032a957bdc
[ 1959.183946]  ffff88032a957bb8 ffffffffa040f225 ffff880329334a30 ffff880300000000
[ 1959.192233]  ffffffffa04133e0 ffff880329334b30 0000000830884d58 00000000569c58cf
[ 1959.200521] Call Trace:
[ 1959.203248]  [] dm_exception_store_create+0x1d5/0x240 [dm_snapshot]
[ 1959.211986]  [] snapshot_ctr+0x140/0x630 [dm_snapshot]
[ 1959.219469]  [] ? dm_split_args+0x64/0x150 [dm_mod]
[ 1959.226656]  [] dm_table_add_target+0x177/0x440 [dm_mod]
[ 1959.234328]  [] table_load+0x143/0x370 [dm_mod]
[ 1959.241129]  [] ? retrieve_status+0x1b0/0x1b0 [dm_mod]
[ 1959.248607]  [] ctl_ioctl+0x255/0x4d0 [dm_mod]
[ 1959.255307]  [] ? memzero_explicit+0x12/0x20
[ 1959.261816]  [] dm_ctl_ioctl+0x13/0x20 [dm_mod]
[ 1959.268615]  [] do_vfs_ioctl+0xa6/0x5c0
[ 1959.274637]  [] ? __audit_syscall_entry+0xaf/0x100
[ 1959.281726]  [] ? do_audit_syscall_entry+0x66/0x70
[ 1959.288814]  [] SyS_ioctl+0x79/0x90
[ 1959.294450]  [] entry_SYSCALL_64_fastpath+0x12/0x71
...
[ 1959.323277] RIP  [] dm_exception_store_set_chunk_size+0x7a/0x110 [dm_snapshot]
[ 1959.333090]  RSP 
[ 1959.336978] CR2: 0000000000000098
[ 1959.344121] ---[ end trace b049991ccad1169e ]---

Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1195899
Signed-off-by: Ding Xiang 
Signed-off-by: Mike Snitzer 
Signed-off-by: Greg Kroah-Hartman

PCI: Disable IO/MEM decoding for devices with non-compliant BARs

2016-04-12T16:08:37+00:00

commit b84106b4e2290c081cdab521fa832596cdfea246 upstream.

The PCI config header (first 64 bytes of each device's config space) is
defined by the PCI spec so generic software can identify the device and
manage its usage of I/O, memory, and IRQ resources.

Some non-spec-compliant devices put registers other than BARs where the
BARs should be.  When the PCI core sizes these "BARs", the reads and writes
it does may have unwanted side effects, and the "BAR" may appear to
describe non-sensical address space.

Add a flag bit to mark non-compliant devices so we don't touch their BARs.
Turn off IO/MEM decoding to prevent the devices from consuming address
space, since we can't read the BARs to find out what that address space
would be.

Signed-off-by: Bjorn Helgaas 
Tested-by: Andi Kleen 
Signed-off-by: Greg Kroah-Hartman

Thermal: Ignore invalid trip points

2016-04-12T16:08:35+00:00

commit 81ad4276b505e987dd8ebbdf63605f92cd172b52 upstream.

In some cases, platform thermal driver may report invalid trip points,
thermal core should not take any action for these trip points.

This fixed a regression that bogus trip point starts to screw up thermal
control on some Lenovo laptops, after
commit bb431ba26c5cd0a17c941ca6c3a195a3a6d5d461
Author: Zhang Rui 
Date:   Fri Oct 30 16:31:47 2015 +0800

    Thermal: initialize thermal zone device correctly

    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.

    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 

Link: https://bugzilla.redhat.com/show_bug.cgi?id=1317190
Link: https://bugzilla.kernel.org/show_bug.cgi?id=114551
Signed-off-by: Zhang Rui 
Signed-off-by: Greg Kroah-Hartman

ASoC: samsung: pass DMA channels as pointers

2016-04-12T16:08:32+00:00

commit b9a1a743818ea3265abf98f9431623afa8c50c86 upstream.

ARM64 allmodconfig produces a bunch of warnings when building the
samsung ASoC code:

sound/soc/samsung/dmaengine.c: In function 'samsung_asoc_init_dma_data':
sound/soc/samsung/dmaengine.c:53:32: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
   playback_data->filter_data = (void *)playback->channel;
sound/soc/samsung/dmaengine.c:60:31: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
   capture_data->filter_data = (void *)capture->channel;

We could easily shut up the warning by adding an intermediate cast,
but there is a bigger underlying problem: The use of IORESOURCE_DMA
to pass data from platform code to device drivers is dubious to start
with, as what we really want is a pointer that can be passed into
a filter function.

Note that on s3c64xx, the pl08x DMA data is already a pointer, but
gets cast to resource_size_t so we can pass it as a resource, and it
then gets converted back to a pointer. In contrast, the data we pass
for s3c24xx is an index into a device specific table, and we artificially
convert that into a pointer for the filter function.

Signed-off-by: Arnd Bergmann 
Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

block: don't optimize for non-cloned bio in bio_get_last_bvec()

2016-03-16T15:43:01+00:00

commit 90d0f0f11588ec692c12f9009089b398be395184 upstream.

For !BIO_CLONED bio, we can use .bi_vcnt safely, but it
doesn't mean we can just simply return .bi_io_vec[.bi_vcnt - 1]
because the start postion may have been moved in the middle of
the bvec, such as splitting in the middle of bvec.

Fixes: 7bcd79ac50d9(block: bio: introduce helpers to get the 1st and last bvec)
Reported-by: Kent Overstreet 
Signed-off-by: Ming Lei 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman