Permalink
Commits on Sep 20, 2015
  1. Revert "mmc: Remove artificial bus speed limitation"

    u-ra committed Sep 20, 2015
    This reverts commit 7440814.
    
    Change-Id: If468ddeb3aec754fcfed7748e0fdebd825b036a9
Commits on Sep 18, 2015
  1. arm: Remove HW machine_name assignment

    mdmower committed Sep 18, 2015
    Superseded by arch_read_hardware_id()
    
    Change-Id: Ie2f25cfe1069242900d8d0cbcd718b88c67ed6cf
  2. sched: Queue RT tasks to head when prio drops

    Thomas Gleixner authored and u-ra committed Feb 7, 2014
    commit 81a44c5441d7f7d2c3dc9105f4d65ad0d5818617 upstream.
    
    The following scenario does not work correctly:
    
    Runqueue of CPUx contains two runnable and pinned tasks:
    
     T1: SCHED_FIFO, prio 80
     T2: SCHED_FIFO, prio 80
    
    T1 is on the cpu and executes the following syscalls (classic priority
    ceiling scenario):
    
     sys_sched_setscheduler(pid(T1), SCHED_FIFO, .prio = 90);
     ...
     sys_sched_setscheduler(pid(T1), SCHED_FIFO, .prio = 80);
     ...
    
    Now T1 gets preempted by T3 (SCHED_FIFO, prio 95). After T3 goes back
    to sleep the scheduler picks T2. Surprise!
    
    The same happens w/o actual preemption when T1 is forced into the
    scheduler due to a sporadic NEED_RESCHED event. The scheduler invokes
    pick_next_task() which returns T2. So T1 gets preempted and scheduled
    out.
    
    This happens because sched_setscheduler() dequeues T1 from the prio 90
    list and then enqueues it on the tail of the prio 80 list behind T2.
    This violates the POSIX spec and surprises user space which relies on
    the guarantee that SCHED_FIFO tasks are not scheduled out unless they
    give the CPU up voluntarily or are preempted by a higher priority
    task. In the latter case the preempted task must get back on the CPU
    after the preempting task schedules out again.
    
    We fixed a similar issue already in commit 60db48c (sched: Queue a
    deboosted task to the head of the RT prio queue). The same treatment
    is necessary for sched_setscheduler(). So enqueue to head of the prio
    bucket list if the priority of the task is lowered.
    
    It might be possible that existing user space relies on the current
    behaviour, but it can be considered highly unlikely due to the corner
    case nature of the application scenario.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/1391803122-4425-6-git-send-email-bigeasy@linutronix.de
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  3. pipe: iovec: Fix memory corruption when retrying atomic copy as non-a…

    bwhacks authored and u-ra committed Jun 15, 2015
    …tomic
    
    pipe_iov_copy_{from,to}_user() may be tried twice with the same iovec,
    the first time atomically and the second time not.  The second attempt
    needs to continue from the iovec position, pipe buffer offset and
    remaining length where the first attempt failed, but currently the
    pipe buffer offset and remaining length are reset.  This will corrupt
    the piped data (possibly also leading to an information leak between
    processes) and may also corrupt kernel memory.
    
    This was fixed upstream by commits f0d1bec9d58d ("new helper:
    copy_page_from_iter()") and 637b58c2887e ("switch pipe_read() to
    copy_page_to_iter()"), but those aren't suitable for stable.  This fix
    for older kernel versions was made by Seth Jennings for RHEL and I
    have extracted it from their update.
    
    CVE-2015-1805
    
    References: https://bugzilla.redhat.com/show_bug.cgi?id=1202855
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [lizf: Backported to 3.4: adjust context]
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  4. block: fix ext_dev_lock lockdep report

    djbw authored and u-ra committed Jun 11, 2015
    commit 4d66e5e9b6d720d8463e11d027bd4ad91c8b1318 upstream.
    
     =================================
     [ INFO: inconsistent lock state ]
     4.1.0-rc7+ #217 Tainted: G           O
     ---------------------------------
     inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
     swapper/6/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
      (ext_devt_lock){+.?...}, at: [<ffffffff8143a60c>] blk_free_devt+0x3c/0x70
     {SOFTIRQ-ON-W} state was registered at:
       [<ffffffff810bf6b1>] __lock_acquire+0x461/0x1e70
       [<ffffffff810c1947>] lock_acquire+0xb7/0x290
       [<ffffffff818ac3a8>] _raw_spin_lock+0x38/0x50
       [<ffffffff8143a07d>] blk_alloc_devt+0x6d/0xd0  <-- take the lock in process context
    [..]
      [<ffffffff810bf64e>] __lock_acquire+0x3fe/0x1e70
      [<ffffffff810c00ad>] ? __lock_acquire+0xe5d/0x1e70
      [<ffffffff810c1947>] lock_acquire+0xb7/0x290
      [<ffffffff8143a60c>] ? blk_free_devt+0x3c/0x70
      [<ffffffff818ac3a8>] _raw_spin_lock+0x38/0x50
      [<ffffffff8143a60c>] ? blk_free_devt+0x3c/0x70
      [<ffffffff8143a60c>] blk_free_devt+0x3c/0x70    <-- take the lock in softirq
      [<ffffffff8143bfec>] part_release+0x1c/0x50
      [<ffffffff8158edf6>] device_release+0x36/0xb0
      [<ffffffff8145ac2b>] kobject_cleanup+0x7b/0x1a0
      [<ffffffff8145aad0>] kobject_put+0x30/0x70
      [<ffffffff8158f147>] put_device+0x17/0x20
      [<ffffffff8143c29c>] delete_partition_rcu_cb+0x16c/0x180
      [<ffffffff8143c130>] ? read_dev_sector+0xa0/0xa0
      [<ffffffff810e0e0f>] rcu_process_callbacks+0x2ff/0xa90
      [<ffffffff810e0dcf>] ? rcu_process_callbacks+0x2bf/0xa90
      [<ffffffff81067e2e>] __do_softirq+0xde/0x600
    
    Neil sees this in his tests and it also triggers on pmem driver unbind
    for the libnvdimm tests.  This fix is on top of an initial fix by Keith
    for incorrect usage of mutex_lock() in this path: 2da78092dda1 "block:
    Fix dev_t minor allocation lifetime".  Both this and 2da78092dda1 are
    candidates for -stable.
    
    Fixes: 2da78092dda1 ("block: Fix dev_t minor allocation lifetime")
    Cc: Keith Busch <keith.busch@intel.com>
    Reported-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    [lizf: Backported to 3.4: adjust context]
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  5. bridge: superfluous skb->nfct check in br_nf_dev_queue_xmit

    VasilyAverin authored and u-ra committed May 4, 2014
    commit aff09ce303f83bd370772349238482ae422a2341 upstream.
    
    Currently bridge can silently drop ipv4 fragments.
    If node have loaded nf_defrag_ipv4 module but have no nf_conntrack_ipv4,
    br_nf_pre_routing defragments incoming ipv4 fragments
    but nfct check in br_nf_dev_queue_xmit does not allow re-fragment combined
    packet back, and therefore it is dropped in br_dev_queue_push_xmit without
    incrementing of any failcounters
    
    It seems the only way to hit the ip_fragment code in the bridge xmit
    path is to have a fragment list whose reassembled fragments go over
    the mtu. This only happens if nf_defrag is enabled. Thanks to
    Florian Westphal for providing feedback to clarify this.
    
    Defragmentation ipv4 is required not only in conntracks but at least in
    TPROXY target and socket match, therefore #ifdef is changed from
    NF_CONNTRACK_IPV4 to NF_DEFRAG_IPV4
    
    Signed-off-by: Vasily Averin <vvs@openvz.org>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Cc: Kirill Tkhai <ktkhai@odin.com>
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  6. net: socket: Fix the wrong returns for recvmsg and sendmsg

    zhengjunling authored and u-ra committed Jun 1, 2015
    Based on 08adb7dabd4874cc5666b4490653b26534702ce0 upstream.
    
    We found that after v3.10.73, recvmsg might return -EFAULT while -EINVAL
    was expected.
    
    We tested it through the recvmsg01 testcase come from LTP testsuit. It set
    msg->msg_namelen to -1 and the recvmsg syscall returned errno 14, which is
    unexpected (errno 22 is expected):
    
    recvmsg01    4  TFAIL  :  invalid socket length ; returned -1 (expected -1),
    errno 14 (expected 22)
    
    Linux mainline has no this bug for commit 08adb7dab fixes it accidentally.
    However, it is too large and complex to be backported to LTS 3.10.
    
    Commit 281c9c36 (net: compat: Update get_compat_msghdr() to match
    copy_msghdr_from_user() behaviour) made get_compat_msghdr() return
    error if msg_sys->msg_namelen was negative, which changed the behaviors
    of recvmsg and sendmsg syscall in a lib32 system:
    
    Before commit 281c9c36, get_compat_msghdr() wouldn't fail and it would
    return -EINVAL in move_addr_to_user() or somewhere if msg_sys->msg_namelen
    was invalid and then syscall returned -EINVAL, which is correct.
    
    And now, when msg_sys->msg_namelen is negative, get_compat_msghdr() will
    fail and wants to return -EINVAL, however, the outer syscall will return
    -EFAULT directly, which is unexpected.
    
    This patch gets the return value of get_compat_msghdr() as well as
    copy_msghdr_from_user(), then returns this expected value if
    get_compat_msghdr() fails.
    
    Fixes: 281c9c36 (net: compat: Update get_compat_msghdr() to match copy_msghdr_from_user() behaviour)
    Signed-off-by: Junling Zheng <zhengjunling@huawei.com>
    Signed-off-by: Hanbing Xu <xuhanbing@huawei.com>
    Cc: Li Zefan <lizefan@huawei.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: David Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  7. md: use kzalloc() when bitmap is disabled

    benjamin-42 authored and u-ra committed Jul 25, 2015
    commit b6878d9e03043695dbf3fa1caa6dfc09db225b16 upstream.
    
    In drivers/md/md.c get_bitmap_file() uses kmalloc() for creating a
    mdu_bitmap_file_t called "file".
    
    5769         file = kmalloc(sizeof(*file), GFP_NOIO);
    5770         if (!file)
    5771                 return -ENOMEM;
    
    This structure is copied to user space at the end of the function.
    
    5786         if (err == 0 &&
    5787             copy_to_user(arg, file, sizeof(*file)))
    5788                 err = -EFAULT
    
    But if bitmap is disabled only the first byte of "file" is initialized
    with zero, so it's possible to read some bytes (up to 4095) of kernel
    space memory from user space. This is an information leak.
    
    5775         /* bitmap disabled, zero the first byte and copy out */
    5776         if (!mddev->bitmap_info.file)
    5777                 file->pathname[0] = '\0';
    
    Signed-off-by: Benjamin Randazzo <benjamin@randazzo.fr>
    Signed-off-by: NeilBrown <neilb@suse.com>
    [lizf: Backported to 3.4: fix both branches]
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  8. tracing: Have filter check for balanced ops

    rostedt authored and u-ra committed Jun 15, 2015
    commit 2cf30dc180cea808077f003c5116388183e54f9e upstream.
    
    When the following filter is used it causes a warning to trigger:
    
     # cd /sys/kernel/debug/tracing
     # echo "((dev==1)blocks==2)" > events/ext4/ext4_truncate_exit/filter
    -bash: echo: write error: Invalid argument
     # cat events/ext4/ext4_truncate_exit/filter
    ((dev==1)blocks==2)
    ^
    parse_error: No error
    
     ------------[ cut here ]------------
     WARNING: CPU: 2 PID: 1223 at kernel/trace/trace_events_filter.c:1640 replace_preds+0x3c5/0x990()
     Modules linked in: bnep lockd grace bluetooth  ...
     CPU: 3 PID: 1223 Comm: bash Tainted: G        W       4.1.0-rc3-test+ #450
     Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v02.05 05/07/2012
      0000000000000668 ffff8800c106bc98 ffffffff816ed4f9 ffff88011ead0cf0
      0000000000000000 ffff8800c106bcd8 ffffffff8107fb07 ffffffff8136b46c
      ffff8800c7d81d48 ffff8800d4c2bc00 ffff8800d4d4f920 00000000ffffffea
     Call Trace:
      [<ffffffff816ed4f9>] dump_stack+0x4c/0x6e
      [<ffffffff8107fb07>] warn_slowpath_common+0x97/0xe0
      [<ffffffff8136b46c>] ? _kstrtoull+0x2c/0x80
      [<ffffffff8107fb6a>] warn_slowpath_null+0x1a/0x20
      [<ffffffff81159065>] replace_preds+0x3c5/0x990
      [<ffffffff811596b2>] create_filter+0x82/0xb0
      [<ffffffff81159944>] apply_event_filter+0xd4/0x180
      [<ffffffff81152bbf>] event_filter_write+0x8f/0x120
      [<ffffffff811db2a8>] __vfs_write+0x28/0xe0
      [<ffffffff811dda43>] ? __sb_start_write+0x53/0xf0
      [<ffffffff812e51e0>] ? security_file_permission+0x30/0xc0
      [<ffffffff811dc408>] vfs_write+0xb8/0x1b0
      [<ffffffff811dc72f>] SyS_write+0x4f/0xb0
      [<ffffffff816f5217>] system_call_fastpath+0x12/0x6a
     ---[ end trace e11028bd95818dcd ]---
    
    Worse yet, reading the error message (the filter again) it says that
    there was no error, when there clearly was. The issue is that the
    code that checks the input does not check for balanced ops. That is,
    having an op between a closed parenthesis and the next token.
    
    This would only cause a warning, and fail out before doing any real
    harm, but it should still not caues a warning, and the error reported
    should work:
    
     # cd /sys/kernel/debug/tracing
     # echo "((dev==1)blocks==2)" > events/ext4/ext4_truncate_exit/filter
    -bash: echo: write error: Invalid argument
     # cat events/ext4/ext4_truncate_exit/filter
    ((dev==1)blocks==2)
    ^
    parse_error: Meaningless filter expression
    
    And give no kernel warning.
    
    Link: http://lkml.kernel.org/r/20150615175025.7e809215@gandalf.local.home
    
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
    Reported-by: Vince Weaver <vincent.weaver@maine.edu>
    Tested-by: Vince Weaver <vincent.weaver@maine.edu>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    [lizf: Backported to 3.4: remove the check for OP_NOT, as it's not supported.]
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  9. ring-buffer-benchmark: Fix the wrong sched_priority of producer

    datawolf authored and u-ra committed Jun 10, 2015
    commit 108029323910c5dd1ef8fa2d10da1ce5fbce6e12 upstream.
    
    The producer should be used producer_fifo as its sched_priority,
    so correct it.
    
    Link: http://lkml.kernel.org/r/1433923957-67842-1-git-send-email-long.wanglong@huawei.com
    
    Signed-off-by: Wang Long <long.wanglong@huawei.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  10. bridge: fix multicast router rlist endless loop

    NikAleksandrov authored and u-ra committed Jun 9, 2015
    commit 1a040eaca1a22f8da8285ceda6b5e4a2cb704867 upstream.
    
    Since the addition of sysfs multicast router support if one set
    multicast_router to "2" more than once, then the port would be added to
    the hlist every time and could end up linking to itself and thus causing an
    endless loop for rlist walkers.
    So to reproduce just do:
    echo 2 > multicast_router; echo 2 > multicast_router;
    in a bridge port and let some igmp traffic flow, for me it hangs up
    in br_multicast_flood().
    Fix this by adding a check in br_multicast_add_router() if the port is
    already linked.
    The reason this didn't happen before the addition of multicast_router
    sysfs entries is because there's a !hlist_unhashed check that prevents
    it.
    
    Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
    Fixes: 0909e11 ("bridge: Add multicast_router sysfs entries")
    Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [lizf: Backported to 3.4: adjust context]
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  11. bridge: disable softirqs around br_fdb_update to avoid lockup

    Nikolay Aleksandrov authored and u-ra committed Jun 6, 2015
    commit c4c832f89dc468cf11dc0dd17206bace44526651 upstream.
    
    br_fdb_update() can be called in process context in the following way:
    br_fdb_add() -> __br_fdb_add() -> br_fdb_update() (if NTF_USE flag is set)
    so we need to disable softirqs because there are softirq users of the
    hash_lock. One easy way to reproduce this is to modify the bridge utility
    to set NTF_USE, enable stp and then set maxageing to a low value so
    br_fdb_cleanup() is called frequently and then just add new entries in
    a loop. This happens because br_fdb_cleanup() is called from timer/softirq
    context. The spin locks in br_fdb_update were _bh before commit f8ae737
    ("[BRIDGE]: forwarding remove unneeded preempt and bh diasables")
    and at the time that commit was correct because br_fdb_update() couldn't be
    called from process context, but that changed after commit:
    292d139 ("bridge: add NTF_USE support")
    Using local_bh_disable/enable around br_fdb_update() allows us to keep
    using the spin_lock/unlock in br_fdb_update for the fast-path.
    
    Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
    Fixes: 292d139 ("bridge: add NTF_USE support")
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [lizf: Backported to 3.4: adjust context]
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  12. bridge: use _bh spinlock variant for br_fdb_update to avoid lockup

    wilson-kok authored and u-ra committed Jun 5, 2015
    commit 1d7c49037b12016e7056b9f2c990380e2187e766 upstream.
    
    br_fdb_update() can be called in process context in the following way:
    br_fdb_add() -> __br_fdb_add() -> br_fdb_update() (if NTF_USE flag is set)
    so we need to use spin_lock_bh because there are softirq users of the
    hash_lock. One easy way to reproduce this is to modify the bridge utility
    to set NTF_USE, enable stp and then set maxageing to a low value so
    br_fdb_cleanup() is called frequently and then just add new entries in
    a loop. This happens because br_fdb_cleanup() is called from timer/softirq
    context. These locks were _bh before commit f8ae737
    ("[BRIDGE]: forwarding remove unneeded preempt and bh diasables")
    and at the time that commit was correct because br_fdb_update() couldn't be
    called from process context, but that changed after commit:
    292d139 ("bridge: add NTF_USE support")
    
    Signed-off-by: Wilson Kok <wkok@cumulusnetworks.com>
    Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
    Fixes: 292d139 ("bridge: add NTF_USE support")
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [lizf: Backported to 3.4: adjust context]
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  13. ALSA: usb-audio: add MAYA44 USB+ mixer control names

    cladisch authored and u-ra committed Jun 3, 2015
    commit 044bddb9ca8d49edb91bc22b9940a463b0dbb97f upstream.
    
    Add mixer control names for the ESI Maya44 USB+ (which appears to be
    identical width the AudioTrak Maya44 USB).
    
    Reported-by: nightmixes <nightmixes@gmail.com>
    Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  14. d_walk() might skip too much

    Al Viro authored and u-ra committed May 29, 2015
    commit 2159184ea01e4ae7d15f2017e296d4bc82d5aeb0 upstream.
    
    when we find that a child has died while we'd been trying to ascend,
    we should go into the first live sibling itself, rather than its sibling.
    
    Off-by-one in question had been introduced in "deal with deadlock in
    d_walk()" and the fix needs to be backported to all branches this one
    has been backported to.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  15. bridge: fix parsing of MLDv2 reports

    Thadeu Lima de Souza Cascardo authored and u-ra committed May 22, 2015
    commit 47cc84ce0c2fe75c99ea5963c4b5704dd78ead54 upstream.
    
    When more than a multicast address is present in a MLDv2 report, all but
    the first address is ignored, because the code breaks out of the loop if
    there has not been an error adding that address.
    
    This has caused failures when two guests connected through the bridge
    tried to communicate using IPv6. Neighbor discoveries would not be
    transmitted to the other guest when both used a link-local address and a
    static address.
    
    This only happens when there is a MLDv2 querier in the network.
    
    The fix will only break out of the loop when there is a failure adding a
    multicast address.
    
    The mdb before the patch:
    
    dev ovirtmgmt port vnet0 grp ff02::1:ff7d:6603 temp
    dev ovirtmgmt port vnet1 grp ff02::1:ff7d:6604 temp
    dev ovirtmgmt port bond0.86 grp ff02::2 temp
    
    After the patch:
    
    dev ovirtmgmt port vnet0 grp ff02::1:ff7d:6603 temp
    dev ovirtmgmt port vnet1 grp ff02::1:ff7d:6604 temp
    dev ovirtmgmt port bond0.86 grp ff02::fb temp
    dev ovirtmgmt port bond0.86 grp ff02::2 temp
    dev ovirtmgmt port bond0.86 grp ff02::d temp
    dev ovirtmgmt port vnet0 grp ff02::1:ff00:76 temp
    dev ovirtmgmt port bond0.86 grp ff02::16 temp
    dev ovirtmgmt port vnet1 grp ff02::1:ff00:77 temp
    dev ovirtmgmt port bond0.86 grp ff02::1:ff00:def temp
    dev ovirtmgmt port bond0.86 grp ff02::1:ffa1:40bf temp
    
    Fixes: 08b202b ("bridge br_multicast: IPv6 MLD support.")
    Reported-by: Rik Theys <Rik.Theys@esat.kuleuven.be>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
    Tested-by: Rik Theys <Rik.Theys@esat.kuleuven.be>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  16. sd: Disable support for 256 byte/sector disks

    Mark Hounschell authored and u-ra committed May 13, 2015
    commit 74856fbf441929918c49ff262ace9835048e4e6a upstream.
    
    256 bytes per sector support has been broken since 2.6.X,
    and no-one stepped up to fix this.
    So disable support for it.
    
    Signed-off-by: Mark Hounschell <dmarkh@cfl.rr.com>
    Signed-off-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: James Bottomley <JBottomley@Odin.com>
    [lizf: Backported to 3.4: adjust context]
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  17. mac80211: move WEP tailroom size check

    dziedjan authored and u-ra committed May 11, 2015
    commit 47b4e1fc4972cc43a19121bc2608a60aef3bf216 upstream.
    
    Remove checking tailroom when adding IV as it uses only
    headroom, and move the check to the ICV generation that
    actually needs the tailroom.
    
    In other case I hit such warning and datapath don't work,
    when testing:
    - IBSS + WEP
    - ath9k with hw crypt enabled
    - IPv6 data (ping6)
    
    WARNING: CPU: 3 PID: 13301 at net/mac80211/wep.c:102 ieee80211_wep_add_iv+0x129/0x190 [mac80211]()
    [...]
    Call Trace:
    [<ffffffff817bf491>] dump_stack+0x45/0x57
    [<ffffffff8107746a>] warn_slowpath_common+0x8a/0xc0
    [<ffffffff8107755a>] warn_slowpath_null+0x1a/0x20
    [<ffffffffc09ae109>] ieee80211_wep_add_iv+0x129/0x190 [mac80211]
    [<ffffffffc09ae7ab>] ieee80211_crypto_wep_encrypt+0x6b/0xd0 [mac80211]
    [<ffffffffc09d3fb1>] invoke_tx_handlers+0xc51/0xf30 [mac80211]
    [...]
    
    Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    [lizf: Backported to 3.4: s/IEEE80211_WEP/_WEP/g]
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  18. ipvs: fix memory leak in ip_vs_ctl.c

    rantala authored and u-ra committed May 7, 2015
    commit f30bf2a5cac6c60ab366c4bc6db913597bf4d6ab upstream.
    
    Fix memory leak introduced in commit a0840e2 ("IPVS: netns,
    ip_vs_ctl local vars moved to ipvs struct."):
    
    unreferenced object 0xffff88005785b800 (size 2048):
      comm "(-localed)", pid 1434, jiffies 4294755650 (age 1421.089s)
      hex dump (first 32 bytes):
        bb 89 0b 83 ff ff ff ff b0 78 f0 4e 00 88 ff ff  .........x.N....
        04 00 00 00 a4 01 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<ffffffff8262ea8e>] kmemleak_alloc+0x4e/0xb0
        [<ffffffff811fba74>] __kmalloc_track_caller+0x244/0x430
        [<ffffffff811b88a0>] kmemdup+0x20/0x50
        [<ffffffff823276b7>] ip_vs_control_net_init+0x1f7/0x510
        [<ffffffff8231d630>] __ip_vs_init+0x100/0x250
        [<ffffffff822363a1>] ops_init+0x41/0x190
        [<ffffffff82236583>] setup_net+0x93/0x150
        [<ffffffff82236cc2>] copy_net_ns+0x82/0x140
        [<ffffffff810ab13d>] create_new_namespaces+0xfd/0x190
        [<ffffffff810ab49a>] unshare_nsproxy_namespaces+0x5a/0xc0
        [<ffffffff810833e3>] SyS_unshare+0x173/0x310
        [<ffffffff8265cbd7>] system_call_fastpath+0x12/0x6f
        [<ffffffffffffffff>] 0xffffffffffffffff
    
    Fixes: a0840e2 ("IPVS: netns, ip_vs_ctl local vars moved to ipvs struct.")
    Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
    Acked-by: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: Simon Horman <horms@verge.net.au>
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  19. ext4: check for zero length extent explicitly

    guaneryu authored and u-ra committed May 14, 2015
    commit 2f974865ffdfe7b9f46a9940836c8b167342563d upstream.
    
    The following commit introduced a bug when checking for zero length extent
    
    5946d08 ext4: check for overlapping extents in ext4_valid_extent_entries()
    
    Zero length extent could pass the check if lblock is zero.
    
    Adding the explicit check for zero length back.
    
    Signed-off-by: Eryu Guan <guaneryu@gmail.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  20. ARM: net: delegate filter to kernel interpreter when imm_offset() ret…

    nschichan authored and u-ra committed May 7, 2015
    …urn value can't fit into 12bits.
    
    commit 0b59d8806a31bb0267b3a461e8fef20c727bdbf6 upstream.
    
    The ARM JIT code emits "ldr rX, [pc, #offset]" to access the literal
    pool. #offset maximum value is 4095 and if the generated code is too
    large, the #offset value can overflow and not point to the expected
    slot in the literal pool. Additionally, when overflow occurs, bits of
    the overflow can end up changing the destination register of the ldr
    instruction.
    
    Fix that by detecting the overflow in imm_offset() and setting a flag
    that is checked for each BPF instructions converted in
    build_body(). As of now it can only be detected in the second pass. As
    a result the second build_body() call can now fail, so add the
    corresponding cleanup code in that case.
    
    Using multiple literal pools in the JITed code is going to require
    lots of intrusive changes to the JIT code (which would better be done
    as a feature instead of fix), just delegating to the kernel BPF
    interpreter in that case is a more straight forward, minimal fix and
    easy to backport.
    
    Fixes: ddecdfc ("ARM: 7259/3: net: JIT compiler for packet filters")
    Signed-off-by: Nicolas Schichan <nschichan@freebox.fr>
    Acked-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  21. mm/memory-failure: call shake_page() when error hits thp tail page

    Naoya-Horiguchi authored and u-ra committed May 5, 2015
    commit 09789e5de18e4e442870b2d700831f5cb802eb05 upstream.
    
    Currently memory_failure() calls shake_page() to sweep pages out from
    pcplists only when the victim page is 4kB LRU page or thp head page.
    But we should do this for a thp tail page too.
    
    Consider that a memory error hits a thp tail page whose head page is on
    a pcplist when memory_failure() runs.  Then, the current kernel skips
    shake_pages() part, so hwpoison_user_mappings() returns without calling
    split_huge_page() nor try_to_unmap() because PageLRU of the thp head is
    still cleared due to the skip of shake_page().
    
    As a result, me_huge_page() runs for the thp, which is broken behavior.
    
    One effect is a leak of the thp.  And another is to fail to isolate the
    memory error, so later access to the error address causes another MCE,
    which kills the processes which used the thp.
    
    This patch fixes this problem by calling shake_page() for thp tail case.
    
    Fixes: 385de35 ("thp: allow a hwpoisoned head page to be put back to LRU")
    Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Reviewed-by: Andi Kleen <ak@linux.intel.com>
    Acked-by: Dean Nelson <dnelson@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
    Cc: Jin Dongming <jin.dongming@np.css.fujitsu.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  22. mmc: core: add missing pm event in mmc_pm_notify to fix hib restore

    grygoriyS authored and u-ra committed Apr 23, 2015
    commit 184af16b09360d6273fd6160e6ff7f8e2482ef23 upstream.
    
    The PM_RESTORE_PREPARE is not handled now in mmc_pm_notify(),
    as result mmc_rescan() could be scheduled and executed at
    late hibernation restore stages when MMC device is suspended
    already - which, in turn, will lead to system crash on TI dra7-evm board:
    
    WARNING: CPU: 0 PID: 3188 at drivers/bus/omap_l3_noc.c:148 l3_interrupt_handler+0x258/0x374()
    44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER1_P3 (Idle): Data Access in User mode during Functional access
    
    Hence, add missed PM_RESTORE_PREPARE PM event in mmc_pm_notify().
    
    Change-Id: I7fe4334171fcf2971a9c31e205bfb1e965592249
    Fixes: 4c2ef25 (mmc: fix all hangs related to mmc/sd card...)
    Signed-off-by: Grygorii Strashko <Grygorii.Strashko@linaro.org>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    [lizf: Backported to 3.4: adjust context]
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  23. ext4: move check under lock scope to close a race.

    dcci authored and u-ra committed May 3, 2015
    commit 280227a75b56ab5d35854f3a77ef74a7ad56a203 upstream.
    
    fallocate() checks that the file is extent-based and returns
    EOPNOTSUPP in case is not. Other tasks can convert from and to
    indirect and extent so it's safe to check only after grabbing
    the inode mutex.
    
    Signed-off-by: Davide Italiano <dccitaliano@gmail.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    [lizf: Backported to 3.4:
     - adjust context
     - return -EOPNOTSUPP instead of jumping to the "out" label]
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  24. serial: of-serial: Remove device_type = "serial" registration

    michalsimek authored and u-ra committed Apr 14, 2015
    commit 6befa9d883385c580369a2cc9e53fbf329771f6d upstream.
    
    Do not probe all serial drivers by of_serial.c which are using
    device_type = "serial"; property. Only drivers which have valid
    compatible strings listed in the driver should be probed.
    
    When PORT_UNKNOWN is setup probe will fail anyway.
    
    Arnd quotation about driver historical background:
    "when I wrote that driver initially, the idea was that it would
    get used as a stub to hook up all other serial drivers but after
    that, the common code learned to create platform devices from DT"
    
    This patch fix the problem with on the system with xilinx_uartps and
    16550a where of_serial failed to register for xilinx_uartps and because
    of irq_dispose_mapping() removed irq_desc. Then when xilinx_uartps was asking
    for irq with request_irq() EINVAL is returned.
    
    Signed-off-by: Michal Simek <michal.simek@xilinx.com>
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  25. serial: xilinx: Use platform_get_irq to get irq description structure

    michalsimek authored and u-ra committed Apr 13, 2015
    commit 5c90c07b98c02198d9777a7c4f3047b0a94bf7ed upstream.
    
    For systems with CONFIG_SERIAL_OF_PLATFORM=y and device_type =
    "serial"; property in DT of_serial.c driver maps and unmaps IRQ (because
    driver probe fails). Then a driver is called but irq mapping is not
    created that's why driver is failing again in again on request_irq().
    Based on this use platform_get_irq() instead of platform_get_resource()
    which is doing irq_desc allocation and driver itself can request IRQ.
    
    Fix both xilinx serial drivers in the tree.
    
    Signed-off-by: Michal Simek <michal.simek@xilinx.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [lizf: Backported to 3.4: adjust context]
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  26. RCU pathwalk breakage when running into a symlink overmounting something

    Al Viro authored and u-ra committed Apr 24, 2015
    commit 3cab989afd8d8d1bc3d99fef0e7ed87c31e7b647 upstream.
    
    Calling unlazy_walk() in walk_component() and do_last() when we find
    a symlink that needs to be followed doesn't acquire a reference to vfsmount.
    That's fine when the symlink is on the same vfsmount as the parent directory
    (which is almost always the case), but it's not always true - one _can_
    manage to bind a symlink on top of something.  And in such cases we end up
    with excessive mntput().
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    [lizf: Backported to 3.4: drop the changes to do_last()]
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  27. ptrace: fix race between ptrace_resume() and wait_task_stopped()

    utrace authored and u-ra committed Apr 16, 2015
    commit b72c186999e689cb0b055ab1c7b3cd8fffbeb5ed upstream.
    
    ptrace_resume() is called when the tracee is still __TASK_TRACED.  We set
    tracee->exit_code and then wake_up_state() changes tracee->state.  If the
    tracer's sub-thread does wait() in between, task_stopped_code(ptrace => T)
    wrongly looks like another report from tracee.
    
    This confuses debugger, and since wait_task_stopped() clears ->exit_code
    the tracee can miss a signal.
    
    Test-case:
    
    	#include <stdio.h>
    	#include <unistd.h>
    	#include <sys/wait.h>
    	#include <sys/ptrace.h>
    	#include <pthread.h>
    	#include <assert.h>
    
    	int pid;
    
    	void *waiter(void *arg)
    	{
    		int stat;
    
    		for (;;) {
    			assert(pid == wait(&stat));
    			assert(WIFSTOPPED(stat));
    			if (WSTOPSIG(stat) == SIGHUP)
    				continue;
    
    			assert(WSTOPSIG(stat) == SIGCONT);
    			printf("ERR! extra/wrong report:%x\n", stat);
    		}
    	}
    
    	int main(void)
    	{
    		pthread_t thread;
    
    		pid = fork();
    		if (!pid) {
    			assert(ptrace(PTRACE_TRACEME, 0,0,0) == 0);
    			for (;;)
    				kill(getpid(), SIGHUP);
    		}
    
    		assert(pthread_create(&thread, NULL, waiter, NULL) == 0);
    
    		for (;;)
    			ptrace(PTRACE_CONT, pid, 0, SIGCONT);
    
    		return 0;
    	}
    
    Note for stable: the bug is very old, but without 9899d11f6544 "ptrace:
    ensure arch_ptrace/ptrace_request can never race with SIGKILL" the fix
    should use lock_task_sighand(child).
    
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Reported-by: Pavel Labath <labath@google.com>
    Tested-by: Pavel Labath <labath@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  28. dm crypt: fix deadlock when async crypto algorithm returns -EBUSY

    benmcollins authored and u-ra committed Apr 3, 2015
    commit 0618764cb25f6fa9fb31152995de42a8a0496475 upstream.
    
    I suspect this doesn't show up for most anyone because software
    algorithms typically don't have a sense of being too busy.  However,
    when working with the Freescale CAAM driver it will return -EBUSY on
    occasion under heavy -- which resulted in dm-crypt deadlock.
    
    After checking the logic in some other drivers, the scheme for
    crypt_convert() and it's callback, kcryptd_async_done(), were not
    correctly laid out to properly handle -EBUSY or -EINPROGRESS.
    
    Fix this by using the completion for both -EBUSY and -EINPROGRESS.  Now
    crypt_convert()'s use of completion is comparable to
    af_alg_wait_for_completion().  Similarly, kcryptd_async_done() follows
    the pattern used in af_alg_complete().
    
    Before this fix dm-crypt would lockup within 1-2 minutes running with
    the CAAM driver.  Fix was regression tested against software algorithms
    on PPC32 and x86_64, and things seem perfectly happy there as well.
    
    Change-Id: I4750c93721392d358088b4ba04639af7e989192d
    Signed-off-by: Ben Collins <ben.c@servergy.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    [lizf: Backported to 3.4: adjust context]
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  29. fs/binfmt_elf.c: fix bug in loading of PIE binaries

    calcodion authored and u-ra committed Apr 14, 2015
    commit a87938b2e246b81b4fb713edb371a9fa3c5c3c86 upstream.
    
    With CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE enabled, and a normal top-down
    address allocation strategy, load_elf_binary() will attempt to map a PIE
    binary into an address range immediately below mm->mmap_base.
    
    Unfortunately, load_elf_ binary() does not take account of the need to
    allocate sufficient space for the entire binary which means that, while
    the first PT_LOAD segment is mapped below mm->mmap_base, the subsequent
    PT_LOAD segment(s) end up being mapped above mm->mmap_base into the are
    that is supposed to be the "gap" between the stack and the binary.
    
    Since the size of the "gap" on x86_64 is only guaranteed to be 128MB this
    means that binaries with large data segments > 128MB can end up mapping
    part of their data segment over their stack resulting in corruption of the
    stack (and the data segment once the binary starts to run).
    
    Any PIE binary with a data segment > 128MB is vulnerable to this although
    address randomization means that the actual gap between the stack and the
    end of the binary is normally greater than 128MB.  The larger the data
    segment of the binary the higher the probability of failure.
    
    Fix this by calculating the total size of the binary in the same way as
    load_elf_interp().
    
    Signed-off-by: Michael Davidson <md@google.com>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Kees Cook <keescook@chromium.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  30. selinux/nlmsg: add XFRM_MSG_MAPPING

    NicolasDichtel authored and u-ra committed Apr 10, 2015
    commit bd2cba07381a6dba60bc1c87ed8b37931d244da1 upstream.
    
    This command is missing.
    
    Fixes: 3a2dfbe ("xfrm: Notify changes in UDP encapsulation via netlink")
    CC: Martin Willi <martin@strongswan.org>
    Reported-by: Stephen Smalley <sds@tycho.nsa.gov>
    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  31. selinux/nlmsg: add XFRM_MSG_MIGRATE

    NicolasDichtel authored and u-ra committed Apr 10, 2015
    commit 8d465bb777179c4bea731b828ec484088cc9fbc1 upstream.
    
    This command is missing.
    
    Fixes: 5c79de6 ("[XFRM]: User interface for handling XFRM_MSG_MIGRATE")
    Reported-by: Stephen Smalley <sds@tycho.nsa.gov>
    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  32. selinux/nlmsg: add XFRM_MSG_REPORT

    NicolasDichtel authored and u-ra committed Apr 10, 2015
    commit b0b59b0056acd6f157a04cc895f7e24692fb08aa upstream.
    
    This command is missing.
    
    Fixes: 97a64b4 ("[XFRM]: Introduce XFRM_MSG_REPORT.")
    Reported-by: Stephen Smalley <sds@tycho.nsa.gov>
    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  33. selinux/nlmsg: add XFRM_MSG_[NEW|GET]SADINFO

    NicolasDichtel authored and u-ra committed Apr 8, 2015
    commit 5b5800fad072133e4a9c2efbf735baaac83dec86 upstream.
    
    These commands are missing.
    
    Fixes: 28d8909 ("[XFRM]: Export SAD info.")
    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [lizf: Backported to 3.4: adjust context]
    Signed-off-by: Zefan Li <lizefan@huawei.com>
  34. selinux/nlmsg: add XFRM_MSG_GETSPDINFO

    NicolasDichtel authored and u-ra committed Apr 8, 2015
    commit 5e6deebafb45fb271ae6939d48832e920b8fb74e upstream.
    
    This command is missing.
    
    Fixes: ecfd6b1 ("[XFRM]: Export SPD info")
    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [lizf: Backported to 3.4: adjust context]
    Signed-off-by: Zefan Li <lizefan@huawei.com>