commit 54f1c43c391590cb82ae204e0db67103b15cdcd0
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Thu Feb 23 03:54:49 2017 +0000

    Linux 3.16.40

commit 9c868a2790b5a6c3a9c78da87d06158e4bd48e47
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed Dec 14 12:45:25 2016 -0800

    vfs,mm: fix return value of read() at s_maxbytes
    
    commit d05c5f7ba164aed3db02fb188c26d0dd94f5455b upstream.
    
    We truncated the possible read iterator to s_maxbytes in commit
    c2a9737f45e2 ("vfs,mm: fix a dead loop in truncate_inode_pages_range()"),
    but our end condition handling was wrong: it's not an error to try to
    read at the end of the file.
    
    Reading past the end should return EOF (0), not EINVAL.
    
    See for example
    
      https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1649342
      http://lists.gnu.org/archive/html/bug-coreutils/2016-12/msg00008.html
    
    where a md5sum of a maximally sized file fails because the final read is
    exactly at s_maxbytes.
    
    Fixes: c2a9737f45e2 ("vfs,mm: fix a dead loop in truncate_inode_pages_range()")
    Reported-by: Joseph Salisbury <joseph.salisbury@canonical.com>
    Cc: Wei Fang <fangwei1@huawei.com>
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: Dave Chinner <david@fromorbit.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit afd9c2402bdfdbc813587faf7f0e8e1f94c2ee91
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Apr 14 18:02:37 2016 +0200

    ALSA: pcm : Call kill_fasync() in stream lock
    
    commit 3aa02cb664c5fb1042958c8d1aa8c35055a2ebc4 upstream.
    
    Currently kill_fasync() is called outside the stream lock in
    snd_pcm_period_elapsed().  This is potentially racy, since the stream
    may get released even during the irq handler is running.  Although
    snd_pcm_release_substream() calls snd_pcm_drop(), this doesn't
    guarantee that the irq handler finishes, thus the kill_fasync() call
    outside the stream spin lock may be invoked after the substream is
    detached, as recently reported by KASAN.
    
    As a quick workaround, move kill_fasync() call inside the stream
    lock.  The fasync is rarely used interface, so this shouldn't have a
    big impact from the performance POV.
    
    Ideally, we should implement some sync mechanism for the proper finish
    of stream and irq handler.  But this oneliner should suffice for most
    cases, so far.
    
    Reported-by: Baozeng Ding <sploving1@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 756826fd4e4a25589a2e77a7ceb791314c73cf48
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Dec 2 09:44:53 2016 -0800

    net: avoid signed overflows for SO_{SND|RCV}BUFFORCE
    
    commit b98b0bc8c431e3ceb4b26b0dfc8db509518fb290 upstream.
    
    CAP_NET_ADMIN users should not be allowed to set negative
    sk_sndbuf or sk_rcvbuf values, as it can lead to various memory
    corruptions, crashes, OOM...
    
    Note that before commit 82981930125a ("net: cleanups in
    sock_setsockopt()"), the bug was even more serious, since SO_SNDBUF
    and SO_RCVBUF were vulnerable.
    
    This needs to be backported to all known linux kernels.
    
    Again, many thanks to syzkaller team for discovering this gem.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 249741c2c0d7a905da66efc6d1292d3915aef1fc
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Fri Dec 16 13:42:06 2016 -0500

    sg_write()/bsg_write() is not fit to be called under KERNEL_DS
    
    commit 128394eff343fc6d2f32172f03e24829539c5835 upstream.
    
    Both damn things interpret userland pointers embedded into the payload;
    worse, they are actually traversing those.  Leaving aside the bad
    API design, this is very much _not_ safe to call with KERNEL_DS.
    Bail out early if that happens.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1685cd22d7ebda79ea519457499f9cc4ced1e966
Author: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date:   Tue Oct 25 14:27:39 2016 -0200

    sctp: validate chunk len before actually using it
    
    commit bf911e985d6bbaa328c20c3e05f4eb03de11fdd6 upstream.
    
    Andrey Konovalov reported that KASAN detected that SCTP was using a slab
    beyond the boundaries. It was caused because when handling out of the
    blue packets in function sctp_sf_ootb() it was checking the chunk len
    only after already processing the first chunk, validating only for the
    2nd and subsequent ones.
    
    The fix is to just move the check upwards so it's also validated for the
    1st chunk.
    
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Tested-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Reviewed-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: moved code is slightly different]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0b66ea3bca021aea839c526d7643df085c5dadbc
Author: Zhou Chengming <zhouchengming1@huawei.com>
Date:   Fri Jan 6 09:32:32 2017 +0800

    sysctl: Drop reference added by grab_header in proc_sys_readdir
    
    commit 93362fa47fe98b62e4a34ab408c4a418432e7939 upstream.
    
    Fixes CVE-2016-9191, proc_sys_readdir doesn't drop reference
    added by grab_header when return from !dir_emit_dots path.
    It can cause any path called unregister_sysctl_table will
    wait forever.
    
    The calltrace of CVE-2016-9191:
    
    [ 5535.960522] Call Trace:
    [ 5535.963265]  [<ffffffff817cdaaf>] schedule+0x3f/0xa0
    [ 5535.968817]  [<ffffffff817d33fb>] schedule_timeout+0x3db/0x6f0
    [ 5535.975346]  [<ffffffff817cf055>] ? wait_for_completion+0x45/0x130
    [ 5535.982256]  [<ffffffff817cf0d3>] wait_for_completion+0xc3/0x130
    [ 5535.988972]  [<ffffffff810d1fd0>] ? wake_up_q+0x80/0x80
    [ 5535.994804]  [<ffffffff8130de64>] drop_sysctl_table+0xc4/0xe0
    [ 5536.001227]  [<ffffffff8130de17>] drop_sysctl_table+0x77/0xe0
    [ 5536.007648]  [<ffffffff8130decd>] unregister_sysctl_table+0x4d/0xa0
    [ 5536.014654]  [<ffffffff8130deff>] unregister_sysctl_table+0x7f/0xa0
    [ 5536.021657]  [<ffffffff810f57f5>] unregister_sched_domain_sysctl+0x15/0x40
    [ 5536.029344]  [<ffffffff810d7704>] partition_sched_domains+0x44/0x450
    [ 5536.036447]  [<ffffffff817d0761>] ? __mutex_unlock_slowpath+0x111/0x1f0
    [ 5536.043844]  [<ffffffff81167684>] rebuild_sched_domains_locked+0x64/0xb0
    [ 5536.051336]  [<ffffffff8116789d>] update_flag+0x11d/0x210
    [ 5536.057373]  [<ffffffff817cf61f>] ? mutex_lock_nested+0x2df/0x450
    [ 5536.064186]  [<ffffffff81167acb>] ? cpuset_css_offline+0x1b/0x60
    [ 5536.070899]  [<ffffffff810fce3d>] ? trace_hardirqs_on+0xd/0x10
    [ 5536.077420]  [<ffffffff817cf61f>] ? mutex_lock_nested+0x2df/0x450
    [ 5536.084234]  [<ffffffff8115a9f5>] ? css_killed_work_fn+0x25/0x220
    [ 5536.091049]  [<ffffffff81167ae5>] cpuset_css_offline+0x35/0x60
    [ 5536.097571]  [<ffffffff8115aa2c>] css_killed_work_fn+0x5c/0x220
    [ 5536.104207]  [<ffffffff810bc83f>] process_one_work+0x1df/0x710
    [ 5536.110736]  [<ffffffff810bc7c0>] ? process_one_work+0x160/0x710
    [ 5536.117461]  [<ffffffff810bce9b>] worker_thread+0x12b/0x4a0
    [ 5536.123697]  [<ffffffff810bcd70>] ? process_one_work+0x710/0x710
    [ 5536.130426]  [<ffffffff810c3f7e>] kthread+0xfe/0x120
    [ 5536.135991]  [<ffffffff817d4baf>] ret_from_fork+0x1f/0x40
    [ 5536.142041]  [<ffffffff810c3e80>] ? kthread_create_on_node+0x230/0x230
    
    One cgroup maintainer mentioned that "cgroup is trying to offline
    a cpuset css, which takes place under cgroup_mutex.  The offlining
    ends up trying to drain active usages of a sysctl table which apprently
    is not happening."
    The real reason is that proc_sys_readdir doesn't drop reference added
    by grab_header when return from !dir_emit_dots path. So this cpuset
    offline path will wait here forever.
    
    See here for details: http://www.openwall.com/lists/oss-security/2016/11/04/13
    
    Fixes: f0c3b5093add ("[readdir] convert procfs")
    Reported-by: CAI Qian <caiqian@redhat.com>
    Tested-by: Yang Shukui <yangshukui@huawei.com>
    Signed-off-by: Zhou Chengming <zhouchengming1@huawei.com>
    Acked-by: Al Viro <viro@ZenIV.linux.org.uk>
    Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 17a3ea20a2c046b194e69fcb6d696ad5a6265e8e
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue Nov 8 11:17:00 2016 +0100

    Fix potential infoleak in older kernels
    
    Not upstream as it is not needed there.
    
    So a patch something like this might be a safe way to fix the
    potential infoleak in older kernels.
    
    THIS IS UNTESTED. It's a very obvious patch, though, so if it compiles
    it probably works. It just initializes the output variable with 0 in
    the inline asm description, instead of doing it in the exception
    handler.
    
    It will generate slightly worse code (a few unnecessary ALU
    operations), but it doesn't have any interactions with the exception
    handler implementation.
    
    
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ce626e14b2fd8f1f0ff6d17a8503f12d3e991cd3
Author: EunTaik Lee <eun.taik.lee@samsung.com>
Date:   Wed Feb 24 04:38:06 2016 +0000

    staging/android/ion : fix a race condition in the ion driver
    
    commit 9590232bb4f4cc824f3425a6e1349afbe6d6d2b7 upstream.
    
    There is a use-after-free problem in the ion driver.
    This is caused by a race condition in the ion_ioctl()
    function.
    
    A handle has ref count of 1 and two tasks on different
    cpus calls ION_IOC_FREE simultaneously.
    
    cpu 0                                   cpu 1
    -------------------------------------------------------
    ion_handle_get_by_id()
    (ref == 2)
                                ion_handle_get_by_id()
                                (ref == 3)
    
    ion_free()
    (ref == 2)
    
    ion_handle_put()
    (ref == 1)
    
                                ion_free()
                                (ref == 0 so ion_handle_destroy() is
                                called
                                and the handle is freed.)
    
                                ion_handle_put() is called and it
                                decreases the slub's next free pointer
    
    The problem is detected as an unaligned access in the
    spin lock functions since it uses load exclusive
     instruction. In some cases it corrupts the slub's
    free pointer which causes a mis-aligned access to the
    next free pointer.(kmalloc returns a pointer like
    ffffc0745b4580aa). And it causes lots of other
    hard-to-debug problems.
    
    This symptom is caused since the first member in the
    ion_handle structure is the reference count and the
    ion driver decrements the reference after it has been
    freed.
    
    To fix this problem client->lock mutex is extended
    to protect all the codes that uses the handle.
    
    Signed-off-by: Eun Taik Lee <eun.taik.lee@samsung.com>
    Reviewed-by: Laura Abbott <labbott@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3d59e6e25fd0cbe700d3f2910291729227dcfd23
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Nov 10 13:12:35 2016 -0800

    tcp: take care of truncations done by sk_filter()
    
    commit ac6e780070e30e4c35bd395acfe9191e6268bdd3 upstream.
    
    With syzkaller help, Marco Grassi found a bug in TCP stack,
    crashing in tcp_collapse()
    
    Root cause is that sk_filter() can truncate the incoming skb,
    but TCP stack was not really expecting this to happen.
    It probably was expecting a simple DROP or ACCEPT behavior.
    
    We first need to make sure no part of TCP header could be removed.
    Then we need to adjust TCP_SKB_CB(skb)->end_seq
    
    Many thanks to syzkaller team and Marco for giving us a reproducer.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Marco Grassi <marco.gra@gmail.com>
    Reported-by: Vladis Dronov <vdronov@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 49bbb1dc818f09bfb323ce5b36c47306ad9e94ac
Author: Willem de Bruijn <willemb@google.com>
Date:   Tue Jul 12 18:18:57 2016 -0400

    dccp: limit sk_filter trim to payload
    
    commit 4f0c40d94461cfd23893a17335b2ab78ecb333c8 upstream.
    
    Dccp verifies packet integrity, including length, at initial rcv in
    dccp_invalid_packet, later pulls headers in dccp_enqueue_skb.
    
    A call to sk_filter in-between can cause __skb_pull to wrap skb->len.
    skb_copy_datagram_msg interprets this as a negative value, so
    (correctly) fails with EFAULT. The negative length is reported in
    ioctl SIOCINQ or possibly in a DCCP_WARN in dccp_close.
    
    Introduce an sk_receive_skb variant that caps how small a filter
    program can trim packets, and call this in dccp with the header
    length. Excessively trimmed packets are now processed normally and
    queued for reception as 0B payloads.
    
    Fixes: 7c657876b63c ("[DCCP]: Initial implementation")
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Acked-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d0fb92f2ca9b8c3ba10047b5e134cd7d1459cc1c
Author: Willem de Bruijn <willemb@google.com>
Date:   Tue Jul 12 18:18:56 2016 -0400

    rose: limit sk_filter trim to payload
    
    commit f4979fcea7fd36d8e2f556abef86f80e0d5af1ba upstream.
    
    Sockets can have a filter program attached that drops or trims
    incoming packets based on the filter program return value.
    
    Rose requires data packets to have at least ROSE_MIN_LEN bytes. It
    verifies this on arrival in rose_route_frame and unconditionally pulls
    the bytes in rose_recvmsg. The filter can trim packets to below this
    value in-between, causing pull to fail, leaving the partial header at
    the time of skb_copy_datagram_msg.
    
    Place a lower bound on the size to which sk_filter may trim packets
    by introducing sk_filter_trim_cap and call this for rose packets.
    
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Acked-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bed7167a188ec74018825232eeee67e2032275f8
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Thu Dec 29 03:06:54 2016 +0000

    net: Add __sock_queue_rcv_skb()
    
    Extraxcted from commit e6afc8ace6dd5cef5e812f26c72579da8806f5ac
    "udp: remove headers from UDP packets before queueing".
    
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4952d0fe7849840bf3767051eb296e84c0e6ed52
Author: Kees Cook <keescook@chromium.org>
Date:   Tue Jan 24 15:18:24 2017 -0800

    fbdev: color map copying bounds checking
    
    commit 2dc705a9930b4806250fbf5a76e55266e59389f2 upstream.
    
    Copying color maps to userspace doesn't check the value of to->start,
    which will cause kernel heap buffer OOB read due to signedness wraps.
    
    CVE-2016-8405
    
    Link: http://lkml.kernel.org/r/20170105224249.GA50925@beast
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Reported-by: Peter Pi (@heisecode) of Trend Micro
    Cc: Min Chong <mchong@google.com>
    Cc: Dan Carpenter <dan.carpenter@oracle.com>
    Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8a984a4795fd4432da09e170efe7d9766d0e91cf
Author: Phil Turnbull <phil.turnbull@oracle.com>
Date:   Tue Feb 2 13:36:45 2016 -0500

    netfilter: nfnetlink: correctly validate length of batch messages
    
    commit c58d6c93680f28ac58984af61d0a7ebf4319c241 upstream.
    
    If nlh->nlmsg_len is zero then an infinite loop is triggered because
    'skb_pull(skb, msglen);' pulls zero bytes.
    
    The calculation in nlmsg_len() underflows if 'nlh->nlmsg_len <
    NLMSG_HDRLEN' which bypasses the length validation and will later
    trigger an out-of-bound read.
    
    If the length validation does fail then the malformed batch message is
    copied back to userspace. However, we cannot do this because the
    nlh->nlmsg_len can be invalid. This leads to an out-of-bounds read in
    netlink_ack:
    
        [   41.455421] ==================================================================
        [   41.456431] BUG: KASAN: slab-out-of-bounds in memcpy+0x1d/0x40 at addr ffff880119e79340
        [   41.456431] Read of size 4294967280 by task a.out/987
        [   41.456431] =============================================================================
        [   41.456431] BUG kmalloc-512 (Not tainted): kasan: bad access detected
        [   41.456431] -----------------------------------------------------------------------------
        ...
        [   41.456431] Bytes b4 ffff880119e79310: 00 00 00 00 d5 03 00 00 b0 fb fe ff 00 00 00 00  ................
        [   41.456431] Object ffff880119e79320: 20 00 00 00 10 00 05 00 00 00 00 00 00 00 00 00   ...............
        [   41.456431] Object ffff880119e79330: 14 00 0a 00 01 03 fc 40 45 56 11 22 33 10 00 05  .......@EV."3...
        [   41.456431] Object ffff880119e79340: f0 ff ff ff 88 99 aa bb 00 14 00 0a 00 06 fe fb  ................
                                                ^^ start of batch nlmsg with
                                                   nlmsg_len=4294967280
        ...
        [   41.456431] Memory state around the buggy address:
        [   41.456431]  ffff880119e79400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        [   41.456431]  ffff880119e79480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        [   41.456431] >ffff880119e79500: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc
        [   41.456431]                                ^
        [   41.456431]  ffff880119e79580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
        [   41.456431]  ffff880119e79600: fc fc fc fc fc fc fc fc fc fc fb fb fb fb fb fb
        [   41.456431] ==================================================================
    
    Fix this with better validation of nlh->nlmsg_len and by setting
    NFNL_BATCH_FAILURE if any batch message fails length validation.
    
    CAP_NET_ADMIN is required to trigger the bugs.
    
    Fixes: 9ea2aa8b7dba ("netfilter: nfnetlink: validate nfnetlink header from batch")
    Signed-off-by: Phil Turnbull <phil.turnbull@oracle.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    [bwh: Backported to 3.16:
     - We don't have an error list so don't call nfnl_err_reset()
     - Set 'success' variable instead of 'status']
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e137da9c2207aa45c353b224a12b1cecfdcb54cb
Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date:   Tue Jan 19 12:34:58 2016 +0100

    HID: core: prevent out-of-bound readings
    
    commit 50220dead1650609206efe91f0cc116132d59b3f upstream.
    
    Plugging a Logitech DJ receiver with KASAN activated raises a bunch of
    out-of-bound readings.
    
    The fields are allocated up to MAX_USAGE, meaning that potentially, we do
    not have enough fields to fit the incoming values.
    Add checks and silence KASAN.
    
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0fbed614ccd7ab27d77bc129a9d8539181d7d275
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Thu Apr 14 17:01:17 2016 +0200

    usb: gadget: f_fs: Fix use-after-free
    
    commit 38740a5b87d53ceb89eb2c970150f6e94e00373a upstream.
    
    When using asynchronous read or write operations on the USB endpoints the
    issuer of the IO request is notified by calling the ki_complete() callback
    of the submitted kiocb when the URB has been completed.
    
    Calling this ki_complete() callback will free kiocb. Make sure that the
    structure is no longer accessed beyond that point, otherwise undefined
    behaviour might occur.
    
    Fixes: 2e4c7553cd6f ("usb: gadget: f_fs: add aio support")
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    [bwh: Backported to 3.16:
     - Adjust filename
     - We only use kiocb::private, not kiocb::ki_flags]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fe525a280e8b5f04c7666fe22d1a4ef592f7b953
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Wed Jan 11 21:09:50 2017 +0100

    perf/core: Fix concurrent sys_perf_event_open() vs. 'move_group' race
    
    commit 321027c1fe77f892f4ea07846aeae08cefbbb290 upstream.
    
    Di Shen reported a race between two concurrent sys_perf_event_open()
    calls where both try and move the same pre-existing software group
    into a hardware context.
    
    The problem is exactly that described in commit:
    
      f63a8daa5812 ("perf: Fix event->ctx locking")
    
    ... where, while we wait for a ctx->mutex acquisition, the event->ctx
    relation can have changed under us.
    
    That very same commit failed to recognise sys_perf_event_context() as an
    external access vector to the events and thereby didn't apply the
    established locking rules correctly.
    
    So while one sys_perf_event_open() call is stuck waiting on
    mutex_lock_double(), the other (which owns said locks) moves the group
    about. So by the time the former sys_perf_event_open() acquires the
    locks, the context we've acquired is stale (and possibly dead).
    
    Apply the established locking rules as per perf_event_ctx_lock_nested()
    to the mutex_lock_double() for the 'move_group' case. This obviously means
    we need to validate state after we acquire the locks.
    
    Reported-by: Di Shen (Keen Lab)
    Tested-by: John Dias <joaodias@google.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Min Chong <mchong@google.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Vince Weaver <vincent.weaver@maine.edu>
    Fixes: f63a8daa5812 ("perf: Fix event->ctx locking")
    Link: http://lkml.kernel.org/r/20170106131444.GZ3174@twins.programming.kicks-ass.net
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    [bwh: Backported to 3.16:
     - Use ACCESS_ONCE() instead of READ_ONCE()
     - Test perf_event::group_flags instead of group_caps
     - Add the err_locked cleanup block, which we didn't need before
     - Adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5838f3ef80e9e06a704f6317d7ab45257b29101e
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Wed Feb 24 18:45:41 2016 +0100

    perf: Do not double free
    
    commit 130056275ade730e7a79c110212c8815202773ee upstream.
    
    In case of: err_file: fput(event_file), we'll end up calling
    perf_release() which in turn will free the event.
    
    Do not then free the event _again_.
    
    Tested-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: dvyukov@google.com
    Cc: eranian@google.com
    Cc: oleg@redhat.com
    Cc: panand@redhat.com
    Cc: sasha.levin@oracle.com
    Cc: vince@deater.net
    Link: http://lkml.kernel.org/r/20160224174947.697350349@infradead.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 18163dd15627bfa34af63299998523d8dd1a109e
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Fri Jan 23 12:24:14 2015 +0100

    perf: Fix event->ctx locking
    
    commit f63a8daa5812afef4f06c962351687e1ff9ccb2b upstream.
    
    There have been a few reported issues wrt. the lack of locking around
    changing event->ctx. This patch tries to address those.
    
    It avoids the whole rwsem thing; and while it appears to work, please
    give it some thought in review.
    
    What I did fail at is sensible runtime checks on the use of
    event->ctx, the RCU use makes it very hard.
    
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Link: http://lkml.kernel.org/r/20150123125834.209535886@infradead.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 16c30eea9553b0ccbb379eed34f85fbed5e2cdcd
Author: Peter Hurley <peter@hurleysoftware.com>
Date:   Fri Nov 27 14:30:21 2015 -0500

    tty: Prevent ldisc drivers from re-using stale tty fields
    
    commit dd42bf1197144ede075a9d4793123f7689e164bc upstream.
    
    Line discipline drivers may mistakenly misuse ldisc-related fields
    when initializing. For example, a failure to initialize tty->receive_room
    in the N_GIGASET_M101 line discipline was recently found and fixed [1].
    Now, the N_X25 line discipline has been discovered accessing the previous
    line discipline's already-freed private data [2].
    
    Harden the ldisc interface against misuse by initializing revelant
    tty fields before instancing the new line discipline.
    
    [1]
        commit fd98e9419d8d622a4de91f76b306af6aa627aa9c
        Author: Tilman Schmidt <tilman@imap.cc>
        Date:   Tue Jul 14 00:37:13 2015 +0200
    
        isdn/gigaset: reset tty->receive_room when attaching ser_gigaset
    
    [2] Report from Sasha Levin <sasha.levin@oracle.com>
        [  634.336761] ==================================================================
        [  634.338226] BUG: KASAN: use-after-free in x25_asy_open_tty+0x13d/0x490 at addr ffff8800a743efd0
        [  634.339558] Read of size 4 by task syzkaller_execu/8981
        [  634.340359] =============================================================================
        [  634.341598] BUG kmalloc-512 (Not tainted): kasan: bad access detected
        ...
        [  634.405018] Call Trace:
        [  634.405277] dump_stack (lib/dump_stack.c:52)
        [  634.405775] print_trailer (mm/slub.c:655)
        [  634.406361] object_err (mm/slub.c:662)
        [  634.406824] kasan_report_error (mm/kasan/report.c:138 mm/kasan/report.c:236)
        [  634.409581] __asan_report_load4_noabort (mm/kasan/report.c:279)
        [  634.411355] x25_asy_open_tty (drivers/net/wan/x25_asy.c:559 (discriminator 1))
        [  634.413997] tty_ldisc_open.isra.2 (drivers/tty/tty_ldisc.c:447)
        [  634.414549] tty_set_ldisc (drivers/tty/tty_ldisc.c:567)
        [  634.415057] tty_ioctl (drivers/tty/tty_io.c:2646 drivers/tty/tty_io.c:2879)
        [  634.423524] do_vfs_ioctl (fs/ioctl.c:43 fs/ioctl.c:607)
        [  634.427491] SyS_ioctl (fs/ioctl.c:622 fs/ioctl.c:613)
        [  634.427945] entry_SYSCALL_64_fastpath (arch/x86/entry/entry_64.S:188)
    
    Cc: Tilman Schmidt <tilman@imap.cc>
    Cc: Sasha Levin <sasha.levin@oracle.com>
    Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 311c3b32f1e591b88e1b290efdcbc79c081f8e0f
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue Dec 15 13:49:05 2015 +0100

    perf: Fix race in swevent hash
    
    commit 12ca6ad2e3a896256f086497a7c7406a547ee373 upstream.
    
    There's a race on CPU unplug where we free the swevent hash array
    while it can still have events on. This will result in a
    use-after-free which is BAD.
    
    Simply do not free the hash array on unplug. This leaves the thing
    around and no use-after-free takes place.
    
    When the last swevent dies, we do a for_each_possible_cpu() iteration
    anyway to clean these up, at which time we'll free it, so no leakage
    will occur.
    
    Reported-by: Sasha Levin <sasha.levin@oracle.com>
    Tested-by: Sasha Levin <sasha.levin@oracle.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Vince Weaver <vincent.weaver@maine.edu>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 79cfd63480a7c4b48c6c329fab1bde569e0a4ac2
Author: Calvin Owens <calvinowens@fb.com>
Date:   Fri Oct 30 16:57:00 2015 -0700

    sg: Fix double-free when drives detach during SG_IO
    
    commit f3951a3709ff50990bf3e188c27d346792103432 upstream.
    
    In sg_common_write(), we free the block request and return -ENODEV if
    the device is detached in the middle of the SG_IO ioctl().
    
    Unfortunately, sg_finish_rem_req() also tries to free srp->rq, so we
    end up freeing rq->cmd in the already free rq object, and then free
    the object itself out from under the current user.
    
    This ends up corrupting random memory via the list_head on the rq
    object. The most common crash trace I saw is this:
    
      ------------[ cut here ]------------
      kernel BUG at block/blk-core.c:1420!
      Call Trace:
      [<ffffffff81281eab>] blk_put_request+0x5b/0x80
      [<ffffffffa0069e5b>] sg_finish_rem_req+0x6b/0x120 [sg]
      [<ffffffffa006bcb9>] sg_common_write.isra.14+0x459/0x5a0 [sg]
      [<ffffffff8125b328>] ? selinux_file_alloc_security+0x48/0x70
      [<ffffffffa006bf95>] sg_new_write.isra.17+0x195/0x2d0 [sg]
      [<ffffffffa006cef4>] sg_ioctl+0x644/0xdb0 [sg]
      [<ffffffff81170f80>] do_vfs_ioctl+0x90/0x520
      [<ffffffff81258967>] ? file_has_perm+0x97/0xb0
      [<ffffffff811714a1>] SyS_ioctl+0x91/0xb0
      [<ffffffff81602afb>] tracesys+0xdd/0xe2
        RIP [<ffffffff81281e04>] __blk_put_request+0x154/0x1a0
    
    The solution is straightforward: just set srp->rq to NULL in the
    failure branch so that sg_finish_rem_req() doesn't attempt to re-free
    it.
    
    Additionally, since sg_rq_end_io() will never be called on the object
    when this happens, we need to free memory backing ->cmd if it isn't
    embedded in the object itself.
    
    KASAN was extremely helpful in finding the root cause of this bug.
    
    Signed-off-by: Calvin Owens <calvinowens@fb.com>
    Acked-by: Douglas Gilbert <dgilbert@interlog.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    [bwh: Backported to 3.16:
     - sg_finish_rem_req() would not free srp->rq->cmd so don't do it here either
     - Adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fd61e9c0a35a5c62b3a268c366cb57fee5646180
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Dec 7 14:22:03 2016 +0300

    ser_gigaset: return -ENOMEM on error instead of success
    
    commit 93a97c50cbf1c007caf12db5cc23e0d5b9c8473c upstream.
    
    If we can't allocate the resources in gigaset_initdriver() then we
    should return -ENOMEM instead of zero.
    
    Fixes: 2869b23e4b95 ("[PATCH] drivers/isdn/gigaset: new M101 driver (v2)")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6623e57d684b324de25dc1b936529f7b0fbd3a9a
Author: 추지호 <jiho.chu@samsung.com>
Date:   Thu Dec 8 12:01:13 2016 +0000

    can: peak: fix bad memory access and free sequence
    
    commit b67d0dd7d0dc9e456825447bbeb935d8ef43ea7c upstream.
    
    Fix for bad memory access while disconnecting. netdev is freed before
    private data free, and dev is accessed after freeing netdev.
    
    This makes a slub problem, and it raise kernel oops with slub debugger
    config.
    
    Signed-off-by: Jiho Chu <jiho.chu@samsung.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2dd5177598ac0a78ee5860f3f7cec45b41385469
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Mon Dec 5 11:44:23 2016 +0100

    can: raw: raw_setsockopt: limit number of can_filter that can be set
    
    commit 332b05ca7a438f857c61a3c21a88489a21532364 upstream.
    
    This patch adds a check to limit the number of can_filters that can be
    set via setsockopt on CAN_RAW sockets. Otherwise allocations > MAX_ORDER
    are not prevented resulting in a warning.
    
    Reference: https://lkml.org/lkml/2016/12/2/230
    
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Tested-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2cc1ff50c4772742158ea4b0f162e33db5328256
Author: John David Anglin <dave.anglin@bell.net>
Date:   Tue Dec 6 22:02:01 2016 -0500

    parisc: Remove unnecessary TLB purges from flush_dcache_page_asm and flush_icache_page_asm
    
    commit febe42964fe182281859b3d43d844bb25ca49367 upstream.
    
    We have four routines in pacache.S that use temporary alias pages:
    copy_user_page_asm(), clear_user_page_asm(), flush_dcache_page_asm() and
    flush_icache_page_asm().  copy_user_page_asm() and clear_user_page_asm()
    don't purge the TLB entry used for the operation.
    flush_dcache_page_asm() and flush_icache_page_asm do purge the entry.
    
    Presumably, this was thought to optimize TLB use.  However, the
    operation is quite heavy weight on PA 1.X processors as we need to take
    the TLB lock and a TLB broadcast is sent to all processors.
    
    This patch removes the purges from flush_dcache_page_asm() and
    flush_icache_page_asm.
    
    Signed-off-by: John David Anglin  <dave.anglin@bell.net>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 76d794a5acd7668dc7a2497fcc43a6bacd0f1872
Author: John David Anglin <dave.anglin@bell.net>
Date:   Tue Dec 6 21:47:04 2016 -0500

    parisc: Purge TLB before setting PTE
    
    commit c78e710c1c9fbeff43dddc0aa3d0ff458e70b0cc upstream.
    
    The attached change interchanges the order of purging the TLB and
    setting the corresponding page table entry.  TLB purges are strongly
    ordered.  It occurred to me one night that setting the PTE first might
    have subtle ordering issues on SMP machines and cause random memory
    corruption.
    
    A TLB lock guards the insertion of user TLB entries.  So after the TLB
    is purged, a new entry can't be inserted until the lock is released.
    This ensures that the new PTE value is used when the lock is released.
    
    Since making this change, no random segmentation faults have been
    observed on the Debian hppa buildd servers.
    
    Signed-off-by: John David Anglin  <dave.anglin@bell.net>
    Signed-off-by: Helge Deller <deller@gmx.de>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a4ab1eeb4f60563209664142185a4969c703f02d
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Tue Dec 6 16:18:45 2016 +0100

    fuse: fix clearing suid, sgid for chown()
    
    commit c01638f5d919728f565bf8b5e0a6a159642df0d9 upstream.
    
    Basically, the pjdfstests set the ownership of a file to 06555, and then
    chowns it (as root) to a new uid/gid. Prior to commit a09f99eddef4 ("fuse:
    fix killing s[ug]id in setattr"), fuse would send down a setattr with both
    the uid/gid change and a new mode.  Now, it just sends down the uid/gid
    change.
    
    Technically this is NOTABUG, since POSIX doesn't _require_ that we clear
    these bits for a privileged process, but Linux (wisely) has done that and I
    think we don't want to change that behavior here.
    
    This is caused by the use of should_remove_suid(), which will always return
    0 when the process has CAP_FSETID.
    
    In fact we really don't need to be calling should_remove_suid() at all,
    since we've already been indicated that we should remove the suid, we just
    don't want to use a (very) stale mode for that.
    
    This patch should fix the above as well as simplify the logic.
    
    Reported-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Fixes: a09f99eddef4 ("fuse: fix killing s[ug]id in setattr")
    Reviewed-by: Jeff Layton <jlayton@redhat.com>
    [bwh: Backported to 3.16: adjust context, indentation]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit dd613d3308c5d7223746b955317fd5f825074419
Author: Peter Zijlstra (Intel) <peterz@infradead.org>
Date:   Tue Nov 29 20:33:28 2016 +0000

    perf/x86: Fix full width counter, counter overflow
    
    commit 7f612a7f0bc13a2361a152862435b7941156b6af upstream.
    
    Lukasz reported that perf stat counters overflow handling is broken on KNL/SLM.
    
    Both these parts have full_width_write set, and that does indeed have
    a problem. In order to deal with counter wrap, we must sample the
    counter at at least half the counter period (see also the sampling
    theorem) such that we can unambiguously reconstruct the count.
    
    However commit:
    
      069e0c3c4058 ("perf/x86/intel: Support full width counting")
    
    sets the sampling interval to the full period, not half.
    
    Fixing that exposes another issue, in that we must not sign extend the
    delta value when we shift it right; the counter cannot have
    decremented after all.
    
    With both these issues fixed, counter overflow functions correctly
    again.
    
    Reported-by: Lukasz Odzioba <lukasz.odzioba@intel.com>
    Tested-by: Liang, Kan <kan.liang@intel.com>
    Tested-by: Odzioba, Lukasz <lukasz.odzioba@intel.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Vince Weaver <vincent.weaver@maine.edu>
    Fixes: 069e0c3c4058 ("perf/x86/intel: Support full width counting")
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    [bwh: Backported to 3.16: adjust filenames]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4ba569b0011d742d27530b81622058e8c81c1257
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Sun Dec 4 19:22:05 2016 -0800

    net: ep93xx_eth: Do not crash unloading module
    
    commit c823abac17926767fb50175e098f087a6ac684c3 upstream.
    
    When we unload the ep93xx_eth, whether we have opened the network
    interface or not, we will either hit a kernel paging request error, or a
    simple NULL pointer de-reference because:
    
    - if ep93xx_open has been called, we have created a valid DMA mapping
      for ep->descs, when we call ep93xx_stop, we also call
      ep93xx_free_buffers, ep->descs now has a stale value
    
    - if ep93xx_open has not been called, we have a NULL pointer for
      ep->descs, so performing any operation against that address just won't
      work
    
    Fix this by adding a NULL pointer check for ep->descs which means that
    ep93xx_free_buffers() was able to successfully tear down the descriptors
    and free the DMA cookie as well.
    
    Fixes: 1d22e05df818 ("[PATCH] Cirrus Logic ep93xx ethernet driver")
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 718d94ed19281af41d6042c2d8e2089d348c424e
Author: Kees Cook <keescook@chromium.org>
Date:   Mon Dec 5 10:34:38 2016 -0800

    net: ping: check minimum size on ICMP header length
    
    commit 0eab121ef8750a5c8637d51534d5e9143fb0633f upstream.
    
    Prior to commit c0371da6047a ("put iov_iter into msghdr") in v3.19, there
    was no check that the iovec contained enough bytes for an ICMP header,
    and the read loop would walk across neighboring stack contents. Since the
    iov_iter conversion, bad arguments are noticed, but the returned error is
    EFAULT. Returning EINVAL is a clearer error and also solves the problem
    prior to v3.19.
    
    This was found using trinity with KASAN on v3.18:
    
    BUG: KASAN: stack-out-of-bounds in memcpy_fromiovec+0x60/0x114 at addr ffffffc071077da0
    Read of size 8 by task trinity-c2/9623
    page:ffffffbe034b9a08 count:0 mapcount:0 mapping:          (null) index:0x0
    flags: 0x0()
    page dumped because: kasan: bad access detected
    CPU: 0 PID: 9623 Comm: trinity-c2 Tainted: G    BU         3.18.0-dirty #15
    Hardware name: Google Tegra210 Smaug Rev 1,3+ (DT)
    Call trace:
    [<ffffffc000209c98>] dump_backtrace+0x0/0x1ac arch/arm64/kernel/traps.c:90
    [<ffffffc000209e54>] show_stack+0x10/0x1c arch/arm64/kernel/traps.c:171
    [<     inline     >] __dump_stack lib/dump_stack.c:15
    [<ffffffc000f18dc4>] dump_stack+0x7c/0xd0 lib/dump_stack.c:50
    [<     inline     >] print_address_description mm/kasan/report.c:147
    [<     inline     >] kasan_report_error mm/kasan/report.c:236
    [<ffffffc000373dcc>] kasan_report+0x380/0x4b8 mm/kasan/report.c:259
    [<     inline     >] check_memory_region mm/kasan/kasan.c:264
    [<ffffffc00037352c>] __asan_load8+0x20/0x70 mm/kasan/kasan.c:507
    [<ffffffc0005b9624>] memcpy_fromiovec+0x5c/0x114 lib/iovec.c:15
    [<     inline     >] memcpy_from_msg include/linux/skbuff.h:2667
    [<ffffffc000ddeba0>] ping_common_sendmsg+0x50/0x108 net/ipv4/ping.c:674
    [<ffffffc000dded30>] ping_v4_sendmsg+0xd8/0x698 net/ipv4/ping.c:714
    [<ffffffc000dc91dc>] inet_sendmsg+0xe0/0x12c net/ipv4/af_inet.c:749
    [<     inline     >] __sock_sendmsg_nosec net/socket.c:624
    [<     inline     >] __sock_sendmsg net/socket.c:632
    [<ffffffc000cab61c>] sock_sendmsg+0x124/0x164 net/socket.c:643
    [<     inline     >] SYSC_sendto net/socket.c:1797
    [<ffffffc000cad270>] SyS_sendto+0x178/0x1d8 net/socket.c:1761
    
    CVE-2016-8399
    
    Reported-by: Qidan He <i@flanker017.me>
    Fixes: c319b4d76b9e ("net: ipv4: add IPPROTO_ICMP socket kind")
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit cd53924265a9d328af37722c6b682e4ea793d04e
Author: Michal Kubeček <mkubecek@suse.cz>
Date:   Fri Dec 2 09:33:41 2016 +0100

    tipc: check minimum bearer MTU
    
    commit 3de81b758853f0b29c61e246679d20b513c4cfec upstream.
    
    Qian Zhang (张谦) reported a potential socket buffer overflow in
    tipc_msg_build() which is also known as CVE-2016-8632: due to
    insufficient checks, a buffer overflow can occur if MTU is too short for
    even tipc headers. As anyone can set device MTU in a user/net namespace,
    this issue can be abused by a regular user.
    
    As agreed in the discussion on Ben Hutchings' original patch, we should
    check the MTU at the moment a bearer is attached rather than for each
    processed packet. We also need to repeat the check when bearer MTU is
    adjusted to new device MTU. UDP case also needs a check to avoid
    overflow when calculating bearer MTU.
    
    Fixes: b97bf3fd8f6a ("[TIPC] Initial merge")
    Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
    Reported-by: Qian Zhang (张谦) <zhangqian-c@360.cn>
    Acked-by: Ying Xue <ying.xue@windriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16:
     - Adjust context
     - Duplicate macro definitions in bearer.h to avoid mutual inclusion
     - NETDEV_DOWN and NETDEV_CHANGEMTU cases in net notifier were combined
     - Drop changes in udp_media.c]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e07d83a4c3854f0d13d761b51895fa8d1dc9c6a4
Author: Chris Brandt <chris.brandt@renesas.com>
Date:   Thu Dec 1 13:32:14 2016 -0500

    sh_eth: remove unchecked interrupts for RZ/A1
    
    commit 33d446dbba4d4d6a77e1e900d434fa99e0f02c86 upstream.
    
    When streaming a lot of data and the RZ/A1 can't keep up, some status bits
    will get set that are not being checked or cleared which cause the
    following messages and the Ethernet driver to stop working. This
    patch fixes that issue.
    
    irq 21: nobody cared (try booting with the "irqpoll" option)
    handlers:
    [<c036b71c>] sh_eth_interrupt
    Disabling IRQ #21
    
    Fixes: db893473d313a4ad ("sh_eth: Add support for r7s72100")
    Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
    Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a0579d7ed8475d1c20a1da4aaf1416f35cc91859
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Thu Dec 1 09:45:45 2016 -0800

    net: bcmgenet: Utilize correct struct device for all DMA operations
    
    commit 8c4799ac799665065f9bf1364fd71bf4f7dc6a4a upstream.
    
    __bcmgenet_tx_reclaim() and bcmgenet_free_rx_buffers() are not using the
    same struct device during unmap that was used for the map operation,
    which makes DMA-API debugging warn about it. Fix this by always using
    &priv->pdev->dev throughout the driver, using an identical device
    reference for all map/unmap calls.
    
    Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file")
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16:
     - Adjust context
     - Also fix call from bcmgenet_desc_rx(), fixed upstream in commit
       d6707bec5986 "net: bcmgenet: rewrite bcmgenet_rx_refill()"]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 770e91712ca6bc5bc00470772e34466e09e652e7
Author: Eli Cooper <elicooper@gmx.com>
Date:   Thu Dec 1 10:05:11 2016 +0800

    ipv6: Set skb->protocol properly for local output
    
    commit b4e479a96fc398ccf83bb1cffb4ffef8631beaf1 upstream.
    
    When xfrm is applied to TSO/GSO packets, it follows this path:
    
        xfrm_output() -> xfrm_output_gso() -> skb_gso_segment()
    
    where skb_gso_segment() relies on skb->protocol to function properly.
    
    This patch sets skb->protocol to ETH_P_IPV6 before dst_output() is called,
    fixing a bug where GSO packets sent through an ipip6 tunnel are dropped
    when xfrm is involved.
    
    Signed-off-by: Eli Cooper <elicooper@gmx.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bb8815da1627509da24850d2d2b39e981a8b223f
Author: Eli Cooper <elicooper@gmx.com>
Date:   Thu Dec 1 10:05:10 2016 +0800

    ipv4: Set skb->protocol properly for local output
    
    commit f4180439109aa720774baafdd798b3234ab1a0d2 upstream.
    
    When xfrm is applied to TSO/GSO packets, it follows this path:
    
        xfrm_output() -> xfrm_output_gso() -> skb_gso_segment()
    
    where skb_gso_segment() relies on skb->protocol to function properly.
    
    This patch sets skb->protocol to ETH_P_IP before dst_output() is called,
    fixing a bug where GSO packets sent through a sit tunnel are dropped
    when xfrm is involved.
    
    Signed-off-by: Eli Cooper <elicooper@gmx.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 943e7299c0fec28de9df8985953f45633b071690
Author: Philip Pettersson <philip.pettersson@gmail.com>
Date:   Wed Nov 30 14:55:36 2016 -0800

    packet: fix race condition in packet_set_ring
    
    commit 84ac7260236a49c79eede91617700174c2c19b0c upstream.
    
    When packet_set_ring creates a ring buffer it will initialize a
    struct timer_list if the packet version is TPACKET_V3. This value
    can then be raced by a different thread calling setsockopt to
    set the version to TPACKET_V1 before packet_set_ring has finished.
    
    This leads to a use-after-free on a function pointer in the
    struct timer_list when the socket is closed as the previously
    initialized timer will not be deleted.
    
    The bug is fixed by taking lock_sock(sk) in packet_setsockopt when
    changing the packet version while also taking the lock at the start
    of packet_set_ring.
    
    Fixes: f6fb8f100b80 ("af-packet: TPACKET_V3 flexible buffer implementation.")
    Signed-off-by: Philip Pettersson <philip.pettersson@gmail.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b94195752fb8ac766a5907cd025539f4aa1cef05
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Wed Nov 30 21:04:41 2016 +0000

    locking/rtmutex: Prevent dequeue vs. unlock race
    
    commit dbb26055defd03d59f678cb5f2c992abe05b064a upstream.
    
    David reported a futex/rtmutex state corruption. It's caused by the
    following problem:
    
    CPU0            CPU1            CPU2
    
    l->owner=T1
                    rt_mutex_lock(l)
                    lock(l->wait_lock)
                    l->owner = T1 | HAS_WAITERS;
                    enqueue(T2)
                    boost()
                      unlock(l->wait_lock)
                    schedule()
    
                                    rt_mutex_lock(l)
                                    lock(l->wait_lock)
                                    l->owner = T1 | HAS_WAITERS;
                                    enqueue(T3)
                                    boost()
                                      unlock(l->wait_lock)
                                    schedule()
                    signal(->T2)    signal(->T3)
                    lock(l->wait_lock)
                    dequeue(T2)
                    deboost()
                      unlock(l->wait_lock)
                                    lock(l->wait_lock)
                                    dequeue(T3)
                                      ===> wait list is now empty
                                    deboost()
                                     unlock(l->wait_lock)
                    lock(l->wait_lock)
                    fixup_rt_mutex_waiters()
                      if (wait_list_empty(l)) {
                        owner = l->owner & ~HAS_WAITERS;
                        l->owner = owner
                         ==> l->owner = T1
                      }
    
                                    lock(l->wait_lock)
    rt_mutex_unlock(l)              fixup_rt_mutex_waiters()
                                      if (wait_list_empty(l)) {
                                        owner = l->owner & ~HAS_WAITERS;
    cmpxchg(l->owner, T1, NULL)
     ===> Success (l->owner = NULL)
                                        l->owner = owner
                                         ==> l->owner = T1
                                      }
    
    That means the problem is caused by fixup_rt_mutex_waiters() which does the
    RMW to clear the waiters bit unconditionally when there are no waiters in
    the rtmutexes rbtree.
    
    This can be fatal: A concurrent unlock can release the rtmutex in the
    fastpath because the waiters bit is not set. If the cmpxchg() gets in the
    middle of the RMW operation then the previous owner, which just unlocked
    the rtmutex is set as the owner again when the write takes place after the
    successfull cmpxchg().
    
    The solution is rather trivial: verify that the owner member of the rtmutex
    has the waiters bit set before clearing it. This does not require a
    cmpxchg() or other atomic operations because the waiters bit can only be
    set and cleared with the rtmutex wait_lock held. It's also safe against the
    fast path unlock attempt. The unlock attempt via cmpxchg() will either see
    the bit set and take the slowpath or see the bit cleared and release it
    atomically in the fastpath.
    
    It's remarkable that the test program provided by David triggers on ARM64
    and MIPS64 really quick, but it refuses to reproduce on x86-64, while the
    problem exists there as well. That refusal might explain that this got not
    discovered earlier despite the bug existing from day one of the rtmutex
    implementation more than 10 years ago.
    
    Thanks to David for meticulously instrumenting the code and providing the
    information which allowed to decode this subtle problem.
    
    Reported-by: David Daney <ddaney@caviumnetworks.com>
    Tested-by: David Daney <david.daney@cavium.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Sebastian Siewior <bigeasy@linutronix.de>
    Cc: Will Deacon <will.deacon@arm.com>
    Fixes: 23f78d4a03c5 ("[PATCH] pi-futex: rt mutex core")
    Link: http://lkml.kernel.org/r/20161130210030.351136722@linutronix.de
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    [bwh: Backported to 3.16: use ACCESS_ONCE() instead of {READ,WRITE}_ONCE()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 907742aa70bdae374014fea488489382f7a4773d
Author: Sven Eckelmann <sven@narfation.org>
Date:   Wed Nov 30 21:47:09 2016 +0100

    batman-adv: Check for alloc errors when preparing TT local data
    
    commit c2d0f48a13e53b4747704c9e692f5e765e52041a upstream.
    
    batadv_tt_prepare_tvlv_local_data can fail to allocate the memory for the
    new TVLV block. The caller is informed about this problem with the returned
    length of 0. Not checking this value results in an invalid memory access
    when either tt_data or tt_change is accessed.
    
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Fixes: 7ea7b4a14275 ("batman-adv: make the TT CRC logic VLAN specific")
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1344f5b6cbcfcdba4c9f1add550cb8ee3b3b08c3
Author: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Date:   Thu Dec 1 11:23:05 2016 +1100

    powerpc/eeh: Fix deadlock when PE frozen state can't be cleared
    
    commit 409bf7f8a02ef88db5a0f2cdcf9489914f4b8508 upstream.
    
    In eeh_reset_device(), we take the pci_rescan_remove_lock immediately after
    after we call eeh_reset_pe() to reset the PCI controller. We then call
    eeh_clear_pe_frozen_state(), which can return an error. In this case, we
    bail out of eeh_reset_device() without calling pci_unlock_rescan_remove().
    
    Add a call to pci_unlock_rescan_remove() in the eeh_clear_pe_frozen_state()
    error path so that we don't cause a deadlock later on.
    
    Reported-by: Pradipta Ghosh <pradghos@in.ibm.com>
    Fixes: 78954700631f ("powerpc/eeh: Avoid I/O access during PE reset")
    Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
    Acked-by: Russell Currey <ruscur@russell.cc>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 85dc53fe3bace2fae0740e40a4ce897645f0bbf5
Author: Hongxu Jia <hongxu.jia@windriver.com>
Date:   Tue Nov 29 21:56:26 2016 -0500

    netfilter: arp_tables: fix invoking 32bit "iptable -P INPUT ACCEPT" failed in 64bit kernel
    
    commit 17a49cd549d9dc8707dc9262210166455c612dde upstream.
    
    Since 09d9686047db ("netfilter: x_tables: do compat validation via
    translate_table"), it used compatr structure to assign newinfo
    structure.  In translate_compat_table of ip_tables.c and ip6_tables.c,
    it used compatr->hook_entry to replace info->hook_entry and
    compatr->underflow to replace info->underflow, but not do the same
    replacement in arp_tables.c.
    
    It caused invoking 32-bit "arptbale -P INPUT ACCEPT" failed in 64bit
    kernel.
    --------------------------------------
    root@qemux86-64:~# arptables -P INPUT ACCEPT
    root@qemux86-64:~# arptables -P INPUT ACCEPT
    ERROR: Policy for `INPUT' offset 448 != underflow 0
    arptables: Incompatible with this kernel
    --------------------------------------
    
    Fixes: 09d9686047db ("netfilter: x_tables: do compat validation via translate_table")
    Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
    Acked-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 61c64c67981229a7394ab754b3ed1b96713faade
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Nov 1 11:46:39 2016 +0100

    pwm: Fix device reference leak
    
    commit 0e1614ac84f1719d87bed577963bb8140d0c9ce8 upstream.
    
    Make sure to drop the reference to the parent device taken by
    class_find_device() after "unexporting" any children when deregistering
    a PWM chip.
    
    Fixes: 0733424c9ba9 ("pwm: Unexport children before chip removal")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 96239edec08bb293755bdebefe3690763905a843
Author: Jack Morgenstein <jackm@dev.mellanox.co.il>
Date:   Sun Nov 27 19:20:52 2016 +0200

    net/mlx4: Fix uninitialized fields in rule when adding promiscuous mode to device managed flow steering
    
    commit 44b911e77793d686b481608770d0c55c18055ba0 upstream.
    
    In procedure mlx4_flow_steer_promisc_add(), several fields
    were left uninitialized in the rule structure.
    Correctly initialize these fields.
    
    Fixes: 592e49dda812 ("net/mlx4: Implement promiscuous mode with device managed flow-steering")
    Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
    Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 26f2b33f75e4ddc0008c55e46b50af971d0f531c
Author: Andrew Lunn <andrew@lunn.ch>
Date:   Thu Nov 24 00:08:13 2016 +0100

    net: ethernet: mvneta: Remove IFF_UNICAST_FLT which is not implemented
    
    commit 97db8afa2ab919fc400fe982f5054060868bdf07 upstream.
    
    The mvneta driver advertises it supports IFF_UNICAST_FLT. However, it
    actually does not. The hardware probably does support it, but there is
    no code to configure the filter. As a quick and simple fix, remove the
    flag. This will cause the core to fall back to promiscuous mode.
    
    Signed-off-by: Andrew Lunn <andrew@lunn.ch>
    Fixes: b50b72de2f2f ("net: mvneta: enable features before registering the driver")
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3136a9a1cc104f4bb123e910b6e8dae90b2065f9
Author: John David Anglin <dave.anglin@bell.net>
Date:   Thu Nov 24 20:18:14 2016 -0500

    parisc: Also flush data TLB in flush_icache_page_asm
    
    commit 5035b230e7b67ac12691ed3b5495bbb617027b68 upstream.
    
    This is the second issue I noticed in reviewing the parisc TLB code.
    
    The fic instruction may use either the instruction or data TLB in
    flushing the instruction cache.  Thus, on machines with a split TLB, we
    should also flush the data TLB after setting up the temporary alias
    registers.
    
    Although this has no functional impact, I changed the pdtlb and pitlb
    instructions to consistently use the index register %r0.  These
    instructions do not support integer displacements.
    
    Tested on rp3440 and c8000.
    
    Signed-off-by: John David Anglin  <dave.anglin@bell.net>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c2bf3d858ef2da9d89b8b561859a2d0715c4423d
Author: John David Anglin <dave.anglin@bell.net>
Date:   Thu Nov 24 20:06:32 2016 -0500

    parisc: Fix race in pci-dma.c
    
    commit c0452fb9fb8f49c7d68ab9fa0ad092016be7b45f upstream.
    
    We are still troubled by occasional random segmentation faults and
    memory memory corruption on SMP machines.  The causes quite a few
    package builds to fail on the Debian buildd machines for parisc.  When
    gcc-6 failed to build three times in a row, I looked again at the TLB
    related code.  I found a couple of issues.  This is the first.
    
    In general, we need to ensure page table updates and corresponding TLB
    purges are atomic.  The attached patch fixes an instance in pci-dma.c
    where the page table update was not guarded by the TLB lock.
    
    Tested on rp3440 and c8000.  So far, no further random segmentation
    faults have been observed.
    
    Signed-off-by: John David Anglin  <dave.anglin@bell.net>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0a74b364c4c2ce4bfffdbefd62cced99ad76bec9
Author: Andrey Ryabinin <aryabinin@virtuozzo.com>
Date:   Thu Nov 24 13:23:10 2016 +0000

    mpi: Fix NULL ptr dereference in mpi_powm() [ver #3]
    
    commit f5527fffff3f002b0a6b376163613b82f69de073 upstream.
    
    This fixes CVE-2016-8650.
    
    If mpi_powm() is given a zero exponent, it wants to immediately return
    either 1 or 0, depending on the modulus.  However, if the result was
    initalised with zero limb space, no limbs space is allocated and a
    NULL-pointer exception ensues.
    
    Fix this by allocating a minimal amount of limb space for the result when
    the 0-exponent case when the result is 1 and not touching the limb space
    when the result is 0.
    
    This affects the use of RSA keys and X.509 certificates that carry them.
    
    BUG: unable to handle kernel NULL pointer dereference at           (null)
    IP: [<ffffffff8138ce5d>] mpi_powm+0x32/0x7e6
    PGD 0
    Oops: 0002 [#1] SMP
    Modules linked in:
    CPU: 3 PID: 3014 Comm: keyctl Not tainted 4.9.0-rc6-fscache+ #278
    Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
    task: ffff8804011944c0 task.stack: ffff880401294000
    RIP: 0010:[<ffffffff8138ce5d>]  [<ffffffff8138ce5d>] mpi_powm+0x32/0x7e6
    RSP: 0018:ffff880401297ad8  EFLAGS: 00010212
    RAX: 0000000000000000 RBX: ffff88040868bec0 RCX: ffff88040868bba0
    RDX: ffff88040868b260 RSI: ffff88040868bec0 RDI: ffff88040868bee0
    RBP: ffff880401297ba8 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000047 R11: ffffffff8183b210 R12: 0000000000000000
    R13: ffff8804087c7600 R14: 000000000000001f R15: ffff880401297c50
    FS:  00007f7a7918c700(0000) GS:ffff88041fb80000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000000 CR3: 0000000401250000 CR4: 00000000001406e0
    Stack:
     ffff88040868bec0 0000000000000020 ffff880401297b00 ffffffff81376cd4
     0000000000000100 ffff880401297b10 ffffffff81376d12 ffff880401297b30
     ffffffff81376f37 0000000000000100 0000000000000000 ffff880401297ba8
    Call Trace:
     [<ffffffff81376cd4>] ? __sg_page_iter_next+0x43/0x66
     [<ffffffff81376d12>] ? sg_miter_get_next_page+0x1b/0x5d
     [<ffffffff81376f37>] ? sg_miter_next+0x17/0xbd
     [<ffffffff8138ba3a>] ? mpi_read_raw_from_sgl+0xf2/0x146
     [<ffffffff8132a95c>] rsa_verify+0x9d/0xee
     [<ffffffff8132acca>] ? pkcs1pad_sg_set_buf+0x2e/0xbb
     [<ffffffff8132af40>] pkcs1pad_verify+0xc0/0xe1
     [<ffffffff8133cb5e>] public_key_verify_signature+0x1b0/0x228
     [<ffffffff8133d974>] x509_check_for_self_signed+0xa1/0xc4
     [<ffffffff8133cdde>] x509_cert_parse+0x167/0x1a1
     [<ffffffff8133d609>] x509_key_preparse+0x21/0x1a1
     [<ffffffff8133c3d7>] asymmetric_key_preparse+0x34/0x61
     [<ffffffff812fc9f3>] key_create_or_update+0x145/0x399
     [<ffffffff812fe227>] SyS_add_key+0x154/0x19e
     [<ffffffff81001c2b>] do_syscall_64+0x80/0x191
     [<ffffffff816825e4>] entry_SYSCALL64_slow_path+0x25/0x25
    Code: 56 41 55 41 54 53 48 81 ec a8 00 00 00 44 8b 71 04 8b 42 04 4c 8b 67 18 45 85 f6 89 45 80 0f 84 b4 06 00 00 85 c0 75 2f 41 ff ce <49> c7 04 24 01 00 00 00 b0 01 75 0b 48 8b 41 18 48 83 38 01 0f
    RIP  [<ffffffff8138ce5d>] mpi_powm+0x32/0x7e6
     RSP <ffff880401297ad8>
    CR2: 0000000000000000
    ---[ end trace d82015255d4a5d8d ]---
    
    Basically, this is a backport of a libgcrypt patch:
    
            http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=patch;h=6e1adb05d290aeeb1c230c763970695f4a538526
    
    Fixes: cdec9cb5167a ("crypto: GnuPG based MPI lib - source files (part 1)")
    Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    cc: Dmitry Kasatkin <dmitry.kasatkin@gmail.com>
    cc: linux-ima-devel@lists.sourceforge.net
    Signed-off-by: James Morris <james.l.morris@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4fa681dcf745c848f6c37d3a7fffd7368e076b93
Author: Radim Krčmář <rkrcmar@redhat.com>
Date:   Wed Nov 23 21:15:00 2016 +0100

    KVM: x86: drop error recovery in em_jmp_far and em_ret_far
    
    commit 2117d5398c81554fbf803f5fd1dc55eb78216c0c upstream.
    
    em_jmp_far and em_ret_far assumed that setting IP can only fail in 64
    bit mode, but syzkaller proved otherwise (and SDM agrees).
    Code segment was restored upon failure, but it was left uninitialized
    outside of long mode, which could lead to a leak of host kernel stack.
    We could have fixed that by always saving and restoring the CS, but we
    take a simpler approach and just break any guest that manages to fail
    as the error recovery is error-prone and modern CPUs don't need emulator
    for this.
    
    Found by syzkaller:
    
      WARNING: CPU: 2 PID: 3668 at arch/x86/kvm/emulate.c:2217 em_ret_far+0x428/0x480
      Kernel panic - not syncing: panic_on_warn set ...
    
      CPU: 2 PID: 3668 Comm: syz-executor Not tainted 4.9.0-rc4+ #49
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
       [...]
      Call Trace:
       [...] __dump_stack lib/dump_stack.c:15
       [...] dump_stack+0xb3/0x118 lib/dump_stack.c:51
       [...] panic+0x1b7/0x3a3 kernel/panic.c:179
       [...] __warn+0x1c4/0x1e0 kernel/panic.c:542
       [...] warn_slowpath_null+0x2c/0x40 kernel/panic.c:585
       [...] em_ret_far+0x428/0x480 arch/x86/kvm/emulate.c:2217
       [...] em_ret_far_imm+0x17/0x70 arch/x86/kvm/emulate.c:2227
       [...] x86_emulate_insn+0x87a/0x3730 arch/x86/kvm/emulate.c:5294
       [...] x86_emulate_instruction+0x520/0x1ba0 arch/x86/kvm/x86.c:5545
       [...] emulate_instruction arch/x86/include/asm/kvm_host.h:1116
       [...] complete_emulated_io arch/x86/kvm/x86.c:6870
       [...] complete_emulated_mmio+0x4e9/0x710 arch/x86/kvm/x86.c:6934
       [...] kvm_arch_vcpu_ioctl_run+0x3b7a/0x5a90 arch/x86/kvm/x86.c:6978
       [...] kvm_vcpu_ioctl+0x61e/0xdd0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2557
       [...] vfs_ioctl fs/ioctl.c:43
       [...] do_vfs_ioctl+0x18c/0x1040 fs/ioctl.c:679
       [...] SYSC_ioctl fs/ioctl.c:694
       [...] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:685
       [...] entry_SYSCALL_64_fastpath+0x1f/0xc2
    
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Fixes: d1442d85cc30 ("KVM: x86: Handle errors when RIP is set during far jumps")
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8b6e9077ce04b02be3fa0da6845606a35ee04289
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Nov 24 01:19:08 2016 +0300

    x86/apic/uv: Silence a shift wrapping warning
    
    commit c4597fd756836a5fb7900f2091797ab564390ad0 upstream.
    
    'm_io' is stored in 6 bits so it's a number in the 0-63 range.  Static
    analysis tools complain that 1 << 63 will wrap so I have changed it to
    1ULL << m_io.
    
    This code is over three years old so presumably the bug doesn't happen
    very frequently in real life or someone would have complained by now.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Cc: Alex Thorlton <athorlton@sgi.com>
    Cc: Dimitri Sivanich <sivanich@sgi.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Mike Travis <travis@sgi.com>
    Cc: Nathan Zimmer <nzimmer@sgi.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: kernel-janitors@vger.kernel.org
    Fixes: b15cc4a12bed ("x86, uv, uv3: Update x2apic Support for SGI UV3")
    Link: http://lkml.kernel.org/r/20161123221908.GA23997@mwanda
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b8052d28325c05df142147a06c736321a9abc4e7
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Nov 17 10:49:31 2016 +0100

    xc2028: Fix use-after-free bug properly
    
    commit 22a1e7783e173ab3d86018eb590107d68df46c11 upstream.
    
    The commit 8dfbcc4351a0 ("[media] xc2028: avoid use after free") tried
    to address the reported use-after-free by clearing the reference.
    
    However, it's clearing the wrong pointer; it sets NULL to
    priv->ctrl.fname, but it's anyway overwritten by the next line
    memcpy(&priv->ctrl, p, sizeof(priv->ctrl)).
    
    OTOH, the actual code accessing the freed string is the strcmp() call
    with priv->fname:
            if (!firmware_name[0] && p->fname &&
                priv->fname && strcmp(p->fname, priv->fname))
                    free_firmware(priv);
    
    where priv->fname points to the previous file name, and this was
    already freed by kfree().
    
    For fixing the bug properly, this patch does the following:
    
    - Keep the copy of firmware file name in only priv->fname,
      priv->ctrl.fname isn't changed;
    - The allocation is done only when the firmware gets loaded;
    - The kfree() is called in free_firmware() commonly
    
    Fixes: commit 8dfbcc4351a0 ('[media] xc2028: avoid use after free')
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b3a20f6bf9237e5223a47fd9eb1f54b4aa00ab9f
Author: Chris Metcalf <cmetcalf@mellanox.com>
Date:   Wed Nov 16 11:18:05 2016 -0500

    tile: avoid using clocksource_cyc2ns with absolute cycle count
    
    commit e658a6f14d7c0243205f035979d0ecf6c12a036f upstream.
    
    For large values of "mult" and long uptimes, the intermediate
    result of "cycles * mult" can overflow 64 bits.  For example,
    the tile platform calls clocksource_cyc2ns with a 1.2 GHz clock;
    we have mult = 853, and after 208.5 days, we overflow 64 bits.
    
    Since clocksource_cyc2ns() is intended to be used for relative
    cycle counts, not absolute cycle counts, performance is more
    importance than accepting a wider range of cycle values.  So,
    just use mult_frac() directly in tile's sched_clock().
    
    Commit 4cecf6d401a0 ("sched, x86: Avoid unnecessary overflow
    in sched_clock") by Salman Qazi results in essentially the same
    generated code for x86 as this change does for tile.  In fact,
    a follow-on change by Salman introduced mult_frac() and switched
    to using it, so the C code was largely identical at that point too.
    
    Peter Zijlstra then added mul_u64_u32_shr() and switched x86
    to use it.  This is, in principle, better; by optimizing the
    64x64->64 multiplies to be 32x32->64 multiplies we can potentially
    save some time.  However, the compiler piplines the 64x64->64
    multiplies pretty well, and the conditional branch in the generic
    mul_u64_u32_shr() causes some bubbles in execution, with the
    result that it's pretty much a wash.  If tilegx provided its own
    implementation of mul_u64_u32_shr() without the conditional branch,
    we could potentially save 3 cycles, but that seems like small gain
    for a fair amount of additional build scaffolding; no other platform
    currently provides a mul_u64_u32_shr() override, and tile doesn't
    currently have an <asm/div64.h> header to put the override in.
    
    Additionally, gcc currently has an optimization bug that prevents
    it from recognizing the opportunity to use a 32x32->64 multiply,
    and so the result would be no better than the existing mult_frac()
    until such time as the compiler is fixed.
    
    For now, just using mult_frac() seems like the right answer.
    
    Signed-off-by: Chris Metcalf <cmetcalf@mellanox.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7781dcac4508bbf83f15b5387820b3ddc7d57ef0
Author: Andy Lutomirski <luto@kernel.org>
Date:   Sat Nov 19 18:42:40 2016 -0800

    x86/traps: Ignore high word of regs->cs in early_fixup_exception()
    
    commit fc0e81b2bea0ebceb71889b61d2240856141c9ee upstream.
    
    On the 80486 DX, it seems that some exceptions may leave garbage in
    the high bits of CS.  This causes sporadic failures in which
    early_fixup_exception() refuses to fix up an exception.
    
    As far as I can tell, this has been buggy for a long time, but the
    problem seems to have been exacerbated by commits:
    
      1e02ce4cccdc ("x86: Store a per-cpu shadow copy of CR4")
      e1bfc11c5a6f ("x86/init: Fix cr4_init_shadow() on CR4-less machines")
    
    This appears to have broken for as long as we've had early
    exception handling.
    
    [ This backport should apply to kernels from 3.4 - 4.5. ]
    
    Fixes: 4c5023a3fa2e ("x86-32: Handle exception table entries during early boot")
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: stable@vger.kernel.org
    Reported-by: Matthew Whitehead <tedheadster@gmail.com>
    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 31e7f933453b2d8415381b57741a2cdd1d4d5f36
Author: John Johansen <john.johansen@canonical.com>
Date:   Wed Aug 31 21:10:06 2016 -0700

    apparmor: fix change_hat not finding hat after policy replacement
    
    commit 3d40658c977769ce2138f286cf131537bf68bdfe upstream.
    
    After a policy replacement, the task cred may be out of date and need
    to be updated. However change_hat is using the stale profiles from
    the out of date cred resulting in either: a stale profile being applied
    or, incorrect failure when searching for a hat profile as it has been
    migrated to the new parent profile.
    
    Fixes: 01e2b670aa898a39259bc85c78e3d74820f4d3b6 (failure to find hat)
    Fixes: 898127c34ec03291c86f4ff3856d79e9e18952bc (stale policy being applied)
    Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1000287
    Signed-off-by: John Johansen <john.johansen@canonical.com>
    Signed-off-by: James Morris <james.l.morris@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7c3ad0d86f80618c00a5d6a267080238185038f6
Author: Guillaume Nault <g.nault@alphalink.fr>
Date:   Fri Nov 18 22:13:00 2016 +0100

    l2tp: fix racy SOCK_ZAPPED flag check in l2tp_ip{,6}_bind()
    
    commit 32c231164b762dddefa13af5a0101032c70b50ef upstream.
    
    Lock socket before checking the SOCK_ZAPPED flag in l2tp_ip6_bind().
    Without lock, a concurrent call could modify the socket flags between
    the sock_flag(sk, SOCK_ZAPPED) test and the lock_sock() call. This way,
    a socket could be inserted twice in l2tp_ip6_bind_table. Releasing it
    would then leave a stale pointer there, generating use-after-free
    errors when walking through the list or modifying adjacent entries.
    
    BUG: KASAN: use-after-free in l2tp_ip6_close+0x22e/0x290 at addr ffff8800081b0ed8
    Write of size 8 by task syz-executor/10987
    CPU: 0 PID: 10987 Comm: syz-executor Not tainted 4.8.0+ #39
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
     ffff880031d97838 ffffffff829f835b ffff88001b5a1640 ffff8800081b0ec0
     ffff8800081b15a0 ffff8800081b6d20 ffff880031d97860 ffffffff8174d3cc
     ffff880031d978f0 ffff8800081b0e80 ffff88001b5a1640 ffff880031d978e0
    Call Trace:
     [<ffffffff829f835b>] dump_stack+0xb3/0x118 lib/dump_stack.c:15
     [<ffffffff8174d3cc>] kasan_object_err+0x1c/0x70 mm/kasan/report.c:156
     [<     inline     >] print_address_description mm/kasan/report.c:194
     [<ffffffff8174d666>] kasan_report_error+0x1f6/0x4d0 mm/kasan/report.c:283
     [<     inline     >] kasan_report mm/kasan/report.c:303
     [<ffffffff8174db7e>] __asan_report_store8_noabort+0x3e/0x40 mm/kasan/report.c:329
     [<     inline     >] __write_once_size ./include/linux/compiler.h:249
     [<     inline     >] __hlist_del ./include/linux/list.h:622
     [<     inline     >] hlist_del_init ./include/linux/list.h:637
     [<ffffffff8579047e>] l2tp_ip6_close+0x22e/0x290 net/l2tp/l2tp_ip6.c:239
     [<ffffffff850b2dfd>] inet_release+0xed/0x1c0 net/ipv4/af_inet.c:415
     [<ffffffff851dc5a0>] inet6_release+0x50/0x70 net/ipv6/af_inet6.c:422
     [<ffffffff84c4581d>] sock_release+0x8d/0x1d0 net/socket.c:570
     [<ffffffff84c45976>] sock_close+0x16/0x20 net/socket.c:1017
     [<ffffffff817a108c>] __fput+0x28c/0x780 fs/file_table.c:208
     [<ffffffff817a1605>] ____fput+0x15/0x20 fs/file_table.c:244
     [<ffffffff813774f9>] task_work_run+0xf9/0x170
     [<ffffffff81324aae>] do_exit+0x85e/0x2a00
     [<ffffffff81326dc8>] do_group_exit+0x108/0x330
     [<ffffffff81348cf7>] get_signal+0x617/0x17a0 kernel/signal.c:2307
     [<ffffffff811b49af>] do_signal+0x7f/0x18f0
     [<ffffffff810039bf>] exit_to_usermode_loop+0xbf/0x150 arch/x86/entry/common.c:156
     [<     inline     >] prepare_exit_to_usermode arch/x86/entry/common.c:190
     [<ffffffff81006060>] syscall_return_slowpath+0x1a0/0x1e0 arch/x86/entry/common.c:259
     [<ffffffff85e4d726>] entry_SYSCALL_64_fastpath+0xc4/0xc6
    Object at ffff8800081b0ec0, in cache L2TP/IPv6 size: 1448
    Allocated:
    PID = 10987
     [ 1116.897025] [<ffffffff811ddcb6>] save_stack_trace+0x16/0x20
     [ 1116.897025] [<ffffffff8174c736>] save_stack+0x46/0xd0
     [ 1116.897025] [<ffffffff8174c9ad>] kasan_kmalloc+0xad/0xe0
     [ 1116.897025] [<ffffffff8174cee2>] kasan_slab_alloc+0x12/0x20
     [ 1116.897025] [<     inline     >] slab_post_alloc_hook mm/slab.h:417
     [ 1116.897025] [<     inline     >] slab_alloc_node mm/slub.c:2708
     [ 1116.897025] [<     inline     >] slab_alloc mm/slub.c:2716
     [ 1116.897025] [<ffffffff817476a8>] kmem_cache_alloc+0xc8/0x2b0 mm/slub.c:2721
     [ 1116.897025] [<ffffffff84c4f6a9>] sk_prot_alloc+0x69/0x2b0 net/core/sock.c:1326
     [ 1116.897025] [<ffffffff84c58ac8>] sk_alloc+0x38/0xae0 net/core/sock.c:1388
     [ 1116.897025] [<ffffffff851ddf67>] inet6_create+0x2d7/0x1000 net/ipv6/af_inet6.c:182
     [ 1116.897025] [<ffffffff84c4af7b>] __sock_create+0x37b/0x640 net/socket.c:1153
     [ 1116.897025] [<     inline     >] sock_create net/socket.c:1193
     [ 1116.897025] [<     inline     >] SYSC_socket net/socket.c:1223
     [ 1116.897025] [<ffffffff84c4b46f>] SyS_socket+0xef/0x1b0 net/socket.c:1203
     [ 1116.897025] [<ffffffff85e4d685>] entry_SYSCALL_64_fastpath+0x23/0xc6
    Freed:
    PID = 10987
     [ 1116.897025] [<ffffffff811ddcb6>] save_stack_trace+0x16/0x20
     [ 1116.897025] [<ffffffff8174c736>] save_stack+0x46/0xd0
     [ 1116.897025] [<ffffffff8174cf61>] kasan_slab_free+0x71/0xb0
     [ 1116.897025] [<     inline     >] slab_free_hook mm/slub.c:1352
     [ 1116.897025] [<     inline     >] slab_free_freelist_hook mm/slub.c:1374
     [ 1116.897025] [<     inline     >] slab_free mm/slub.c:2951
     [ 1116.897025] [<ffffffff81748b28>] kmem_cache_free+0xc8/0x330 mm/slub.c:2973
     [ 1116.897025] [<     inline     >] sk_prot_free net/core/sock.c:1369
     [ 1116.897025] [<ffffffff84c541eb>] __sk_destruct+0x32b/0x4f0 net/core/sock.c:1444
     [ 1116.897025] [<ffffffff84c5aca4>] sk_destruct+0x44/0x80 net/core/sock.c:1452
     [ 1116.897025] [<ffffffff84c5ad33>] __sk_free+0x53/0x220 net/core/sock.c:1460
     [ 1116.897025] [<ffffffff84c5af23>] sk_free+0x23/0x30 net/core/sock.c:1471
     [ 1116.897025] [<ffffffff84c5cb6c>] sk_common_release+0x28c/0x3e0 ./include/net/sock.h:1589
     [ 1116.897025] [<ffffffff8579044e>] l2tp_ip6_close+0x1fe/0x290 net/l2tp/l2tp_ip6.c:243
     [ 1116.897025] [<ffffffff850b2dfd>] inet_release+0xed/0x1c0 net/ipv4/af_inet.c:415
     [ 1116.897025] [<ffffffff851dc5a0>] inet6_release+0x50/0x70 net/ipv6/af_inet6.c:422
     [ 1116.897025] [<ffffffff84c4581d>] sock_release+0x8d/0x1d0 net/socket.c:570
     [ 1116.897025] [<ffffffff84c45976>] sock_close+0x16/0x20 net/socket.c:1017
     [ 1116.897025] [<ffffffff817a108c>] __fput+0x28c/0x780 fs/file_table.c:208
     [ 1116.897025] [<ffffffff817a1605>] ____fput+0x15/0x20 fs/file_table.c:244
     [ 1116.897025] [<ffffffff813774f9>] task_work_run+0xf9/0x170
     [ 1116.897025] [<ffffffff81324aae>] do_exit+0x85e/0x2a00
     [ 1116.897025] [<ffffffff81326dc8>] do_group_exit+0x108/0x330
     [ 1116.897025] [<ffffffff81348cf7>] get_signal+0x617/0x17a0 kernel/signal.c:2307
     [ 1116.897025] [<ffffffff811b49af>] do_signal+0x7f/0x18f0
     [ 1116.897025] [<ffffffff810039bf>] exit_to_usermode_loop+0xbf/0x150 arch/x86/entry/common.c:156
     [ 1116.897025] [<     inline     >] prepare_exit_to_usermode arch/x86/entry/common.c:190
     [ 1116.897025] [<ffffffff81006060>] syscall_return_slowpath+0x1a0/0x1e0 arch/x86/entry/common.c:259
     [ 1116.897025] [<ffffffff85e4d726>] entry_SYSCALL_64_fastpath+0xc4/0xc6
    Memory state around the buggy address:
     ffff8800081b0d80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
     ffff8800081b0e00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    >ffff8800081b0e80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
                                                        ^
     ffff8800081b0f00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff8800081b0f80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    
    ==================================================================
    
    The same issue exists with l2tp_ip_bind() and l2tp_ip_bind_table.
    
    Fixes: c51ce49735c1 ("l2tp: fix oops in L2TP IP sockets for connect() AF_UNSPEC case")
    Reported-by: Baozeng Ding <sploving1@gmail.com>
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Tested-by: Baozeng Ding <sploving1@gmail.com>
    Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 304ad3c9caa7687ecf43125a423b325c0e32fb6f
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Fri Nov 18 13:00:24 2016 -0500

    ext4: sanity check the block and cluster size at mount time
    
    commit 8cdf3372fe8368f56315e66bea9f35053c418093 upstream.
    
    If the block size or cluster size is insane, reject the mount.  This
    is important for security reasons (although we shouldn't be just
    depending on this check).
    
    Ref: http://www.securityfocus.com/archive/1/539661
    Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1332506
    Reported-by: Borislav Petkov <bp@alien8.de>
    Reported-by: Nikolay Borisov <kernel@kyup.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2156e86cd61f6012dabc97714501853fa784e50b
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Thu Nov 17 15:55:46 2016 +0100

    KVM: x86: fix missed SRCU usage in kvm_lapic_set_vapic_addr
    
    commit 7301d6abaea926d685832f7e1f0c37dd206b01f4 upstream.
    
    Reported by syzkaller:
    
        [ INFO: suspicious RCU usage. ]
        4.9.0-rc4+ #47 Not tainted
        -------------------------------
        ./include/linux/kvm_host.h:536 suspicious rcu_dereference_check() usage!
    
        stack backtrace:
        CPU: 1 PID: 6679 Comm: syz-executor Not tainted 4.9.0-rc4+ #47
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
         ffff880039e2f6d0 ffffffff81c2e46b ffff88003e3a5b40 0000000000000000
         0000000000000001 ffffffff83215600 ffff880039e2f700 ffffffff81334ea9
         ffffc9000730b000 0000000000000004 ffff88003c4f8420 ffff88003d3f8000
        Call Trace:
         [<     inline     >] __dump_stack lib/dump_stack.c:15
         [<ffffffff81c2e46b>] dump_stack+0xb3/0x118 lib/dump_stack.c:51
         [<ffffffff81334ea9>] lockdep_rcu_suspicious+0x139/0x180 kernel/locking/lockdep.c:4445
         [<     inline     >] __kvm_memslots include/linux/kvm_host.h:534
         [<     inline     >] kvm_memslots include/linux/kvm_host.h:541
         [<ffffffff8105d6ae>] kvm_gfn_to_hva_cache_init+0xa1e/0xce0 virt/kvm/kvm_main.c:1941
         [<ffffffff8112685d>] kvm_lapic_set_vapic_addr+0xed/0x140 arch/x86/kvm/lapic.c:2217
    
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Fixes: fda4e2e85589191b123d31cdc21fd33ee70f50fd
    Cc: Andrew Honig <ahonig@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b3674a17c4c18724797fdc530b228a7100bd57f0
Author: Ignacio Alvarado <ikalvarado@google.com>
Date:   Fri Nov 4 12:15:55 2016 -0700

    KVM: Disable irq while unregistering user notifier
    
    commit 1650b4ebc99da4c137bfbfc531be4a2405f951dd upstream.
    
    Function user_notifier_unregister should be called only once for each
    registered user notifier.
    
    Function kvm_arch_hardware_disable can be executed from an IPI context
    which could cause a race condition with a VCPU returning to user mode
    and attempting to unregister the notifier.
    
    Signed-off-by: Ignacio Alvarado <ikalvarado@google.com>
    Fixes: 18863bdd60f8 ("KVM: x86 shared msr infrastructure")
    Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8b4edf66c48a55fc51b25f20fcafcb9e6b145ab1
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Nov 17 17:40:02 2016 +0100

    net: ethernet: ti: cpsw: fix secondary-emac probe error path
    
    commit a7fe9d466f6a33558a38c7ca9d58bcc83512d577 upstream.
    
    Make sure to deregister the primary device in case the secondary emac
    fails to probe.
    
    kernel BUG at /home/johan/work/omicron/src/linux/net/core/dev.c:7743!
    ...
    [<c05b3dec>] (free_netdev) from [<c04fe6c0>] (cpsw_probe+0x9cc/0xe50)
    [<c04fe6c0>] (cpsw_probe) from [<c047b28c>] (platform_drv_probe+0x5c/0xc0)
    
    Fixes: d9ba8f9e6298 ("driver: net: ethernet: cpsw: dual emac interface
    implementation")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0b19869e3c3eaaa829e18ffed5ce329f0b1fa2e7
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Nov 17 17:39:59 2016 +0100

    net: ethernet: ti: cpsw: fix mdio device reference leak
    
    commit 86e1d5adcef961eb383ce4eacbe0ef22f06e2045 upstream.
    
    Make sure to drop the reference taken by of_find_device_by_node() when
    looking up an mdio device from a phy_id property during probe.
    
    Fixes: 549985ee9c72 ("cpsw: simplify the setup of the register
    pointers")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: adjust context, indentation]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b50bf102927b902d44333616544ca13b046dcd68
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Nov 17 17:39:58 2016 +0100

    net: ethernet: ti: cpsw: fix bad register access in probe error path
    
    commit c46ab7e08c79be7400f6d59edbc6f26a91941c5a upstream.
    
    Make sure to keep the platform device runtime-resumed throughout probe
    to avoid accessing the CPSW registers in the error path (e.g. for
    deferred probe) with clocks disabled:
    
    Unhandled fault: external abort on non-linefetch (0x1008) at 0xd0872d08
    ...
    [<c04fabcc>] (cpsw_ale_control_set) from [<c04fb8b4>] (cpsw_ale_destroy+0x2c/0x44)
    [<c04fb8b4>] (cpsw_ale_destroy) from [<c04fea58>] (cpsw_probe+0xbd0/0x10c4)
    [<c04fea58>] (cpsw_probe) from [<c047b2a0>] (platform_drv_probe+0x5c/0xc0)
    
    Fixes: df828598a755 ("netdev: driver: ethernet: Add TI CPSW driver")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16:
     - s/cpsw->/priv->/g
     - Adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a78748b4a770a1dfab81802496fdec8f1195585f
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Nov 15 12:05:11 2016 +0100

    cfg80211: limit scan results cache size
    
    commit 9853a55ef1bb66d7411136046060bbfb69c714fa upstream.
    
    It's possible to make scanning consume almost arbitrary amounts
    of memory, e.g. by sending beacon frames with random BSSIDs at
    high rates while somebody is scanning.
    
    Limit the number of BSS table entries we're willing to cache to
    1000, limiting maximum memory usage to maybe 4-5MB, but lower
    in practice - that would be the case for having both full-sized
    beacon and probe response frames for each entry; this seems not
    possible in practice, so a limit of 1000 entries will likely be
    closer to 0.5 MB.
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b2486d4f0e95783651f3d390cf03eb5331949ae7
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Nov 16 15:20:36 2016 +0100

    of_mdio: fix node leak in of_phy_register_fixed_link error path
    
    commit 48c1699d5335bc045b50989a06b1c526b17a25ff upstream.
    
    Make sure to drop the of_node reference also on failure to parse the
    speed property in of_phy_register_fixed_link().
    
    Fixes: 3be2a49e5c08 ("of: provide a binding for fixed link PHYs")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit dddd478f8d027aa801cd14e32a40c5673419249f
Author: Brian Norris <briannorris@chromium.org>
Date:   Tue Nov 8 18:28:24 2016 -0800

    mwifiex: printk() overflow with 32-byte SSIDs
    
    commit fcd2042e8d36cf644bd2d69c26378d17158b17df upstream.
    
    SSIDs aren't guaranteed to be 0-terminated. Let's cap the max length
    when we print them out.
    
    This can be easily noticed by connecting to a network with a 32-octet
    SSID:
    
    [ 3903.502925] mwifiex_pcie 0000:01:00.0: info: trying to associate to
    '0123456789abcdef0123456789abcdef <uninitialized mem>' bssid
    xx:xx:xx:xx:xx:xx
    
    Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
    Signed-off-by: Brian Norris <briannorris@chromium.org>
    Acked-by: Amitkumar Karwar <akarwar@marvell.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    [bwh: Backported to 3.16: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 52e8b41f2df336dd2f78e80dea53ead5b9d2824b
Author: Matan Barak <matanb@mellanox.com>
Date:   Thu Nov 10 11:30:55 2016 +0200

    IB/mlx4: Fix create CQ error flow
    
    commit 593ff73bcfdc79f79a8a0df55504f75ad3e5d1a9 upstream.
    
    Currently, if ib_copy_to_udata fails, the CQ
    won't be deleted from the radix tree and the HW (HW2SW).
    
    Fixes: 225c7b1feef1 ('IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters')
    Signed-off-by: Matan Barak <matanb@mellanox.com>
    Signed-off-by: Daniel Jurgens <danielj@mellanox.com>
    Reviewed-by: Mark Bloch <markb@mellanox.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b959798f84b4252b6967d444e204dac67d732396
Author: Eli Cohen <eli@mellanox.com>
Date:   Thu Oct 27 16:36:46 2016 +0300

    IB/mlx5: Fix NULL pointer dereference on debug print
    
    commit a1ab8402d15d2305d2315d96ec3294bfdf16587e upstream.
    
    For XRC QP CQs may not exist. Check before attempting dereference.
    
    Fixes: e126ba97dba9 ('mlx5: Add driver for Mellanox Connect-IB adapters')
    Signed-off-by: Eli Cohen <eli@mellanox.com>
    Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
    Reviewed-by: Yishai Hadas <yishaih@mellanox.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0d4ad2aae6062290538b0ff29cc09546103738df
Author: Moshe Lazer <moshel@mellanox.com>
Date:   Thu Oct 27 16:36:42 2016 +0300

    IB/mlx5: Resolve soft lock on massive reg MRs
    
    commit 6bc1a656ab9f57f0112823b4a36930c9a29d1f89 upstream.
    
    When calling reg_mr of large MRs (e.g. 4GB) from multiple processes
    and MR caches can't supply the required amount of MRs the slow-path
    of MR allocation may be used. In this case we need to serialize the
    slow-path between the processes to avoid soft lock.
    
    Fixes: e126ba97dba9 ('mlx5: Add driver for Mellanox Connect-IB adapters')
    Signed-off-by: Moshe Lazer <moshel@mellanox.com>
    Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
    Reviewed-by: Eli Cohen <eli@mellanox.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 765316afd1db2a9f2f9ed96eb9ca458625407209
Author: Daniel Jurgens <danielj@mellanox.com>
Date:   Thu Oct 27 16:36:41 2016 +0300

    IB/mlx5: Use cache line size to select CQE stride
    
    commit 16b0e0695a73b68d8ca40288c8f9614ef208917b upstream.
    
    When creating kernel CQs use 128B CQE stride if the
    cache line size is 128B, 64B otherwise.  This prevents
    multiple CQEs from residing in a 128B cache line,
    which can cause retries when there are concurrent
    read and writes in one cache line.
    
    Tested with IPoIB on PPC64, saw ~5% throughput
    improvement.
    
    Fixes: e126ba97dba9 ('mlx5: Add driver for Mellanox Connect-IB adapters')
    Signed-off-by: Daniel Jurgens <danielj@mellanox.com>
    Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d05da7e292580d7cbe66a9b00895be74c7a64e46
Author: Mark Bloch <markb@mellanox.com>
Date:   Thu Oct 27 16:36:31 2016 +0300

    IB/core: Avoid unsigned int overflow in sg_alloc_table
    
    commit 3c7ba5760ab8eedec01159b267bb9bfcffe522ac upstream.
    
    sg_alloc_table gets unsigned int as parameter while the driver
    returns it as size_t. Check npages isn't greater than maximum
    unsigned int.
    
    Fixes: eeb8461e36c9 ("IB: Refactor umem to use linear SG table")
    Signed-off-by: Mark Bloch <markb@mellanox.com>
    Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8ad2c099493e4d38318b80e430e5b9772fe6efea
Author: Mark Bloch <markb@mellanox.com>
Date:   Thu Oct 27 16:36:27 2016 +0300

    IB/cm: Mark stale CM id's whenever the mad agent was unregistered
    
    commit 9db0ff53cb9b43ed75bacd42a89c1a0ab048b2b0 upstream.
    
    When there is a CM id object that has port assigned to it, it means that
    the cm-id asked for the specific port that it should go by it, but if
    that port was removed (hot-unplug event) the cm-id was not updated.
    In order to fix that the port keeps a list of all the cm-id's that are
    planning to go by it, whenever the port is removed it marks all of them
    as invalid.
    
    This commit fixes a kernel panic which happens when running traffic between
    guests and we force reboot a guest mid traffic, it triggers a kernel panic:
    
     Call Trace:
      [<ffffffff815271fa>] ? panic+0xa7/0x16f
      [<ffffffff8152b534>] ? oops_end+0xe4/0x100
      [<ffffffff8104a00b>] ? no_context+0xfb/0x260
      [<ffffffff81084db2>] ? del_timer_sync+0x22/0x30
      [<ffffffff8104a295>] ? __bad_area_nosemaphore+0x125/0x1e0
      [<ffffffff81084240>] ? process_timeout+0x0/0x10
      [<ffffffff8104a363>] ? bad_area_nosemaphore+0x13/0x20
      [<ffffffff8104aabf>] ? __do_page_fault+0x31f/0x480
      [<ffffffff81065df0>] ? default_wake_function+0x0/0x20
      [<ffffffffa0752675>] ? free_msg+0x55/0x70 [mlx5_core]
      [<ffffffffa0753434>] ? cmd_exec+0x124/0x840 [mlx5_core]
      [<ffffffff8105a924>] ? find_busiest_group+0x244/0x9f0
      [<ffffffff8152d45e>] ? do_page_fault+0x3e/0xa0
      [<ffffffff8152a815>] ? page_fault+0x25/0x30
      [<ffffffffa024da25>] ? cm_alloc_msg+0x35/0xc0 [ib_cm]
      [<ffffffffa024e821>] ? ib_send_cm_dreq+0xb1/0x1e0 [ib_cm]
      [<ffffffffa024f836>] ? cm_destroy_id+0x176/0x320 [ib_cm]
      [<ffffffffa024fb00>] ? ib_destroy_cm_id+0x10/0x20 [ib_cm]
      [<ffffffffa034f527>] ? ipoib_cm_free_rx_reap_list+0xa7/0x110 [ib_ipoib]
      [<ffffffffa034f590>] ? ipoib_cm_rx_reap+0x0/0x20 [ib_ipoib]
      [<ffffffffa034f5a5>] ? ipoib_cm_rx_reap+0x15/0x20 [ib_ipoib]
      [<ffffffff81094d20>] ? worker_thread+0x170/0x2a0
      [<ffffffff8109b2a0>] ? autoremove_wake_function+0x0/0x40
      [<ffffffff81094bb0>] ? worker_thread+0x0/0x2a0
      [<ffffffff8109aef6>] ? kthread+0x96/0xa0
      [<ffffffff8100c20a>] ? child_rip+0xa/0x20
      [<ffffffff8109ae60>] ? kthread+0x0/0xa0
      [<ffffffff8100c200>] ? child_rip+0x0/0x20
    
    Fixes: a977049dacde ("[PATCH] IB: Add the kernel CM implementation")
    Signed-off-by: Mark Bloch <markb@mellanox.com>
    Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
    Reviewed-by: Maor Gottlieb <maorg@mellanox.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7bb7d0aab0b33bc87d1de051ac2dbdd1cb3cd72c
Author: Tariq Toukan <tariqt@mellanox.com>
Date:   Thu Oct 27 16:36:26 2016 +0300

    IB/uverbs: Fix leak of XRC target QPs
    
    commit 5b810a242c28e1d8d64d718cebe75b79d86a0b2d upstream.
    
    The real QP is destroyed in case of the ref count reaches zero, but
    for XRC target QPs this call was missed and caused to QP leaks.
    
    Let's call to destroy for all flows.
    
    Fixes: 0e0ec7e0638e ('RDMA/core: Export ib_open_qp() to share XRC...')
    Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: Noa Osherovich <noaos@mellanox.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4f5af796101b0b79b3535a9b94bce7d3979dfd82
Author: Keith Busch <keith.busch@intel.com>
Date:   Tue Nov 15 15:56:26 2016 -0500

    nvme/pci: Don't free queues on error
    
    commit d48756228ee9161ac8836b346589a43fabdc9f3c upstream.
    
    The nvme_remove function tears down all allocated resources in the correct
    order, so no need to free queues on error during initialization. This
    fixes possible use-after-free errors when queues are still associated
    with a blk-mq hctx.
    
    Reported-by: Scott Bauer <scott.bauer@intel.com>
    Tested-by: Scott Bauer <scott.bauer@intel.com>
    Signed-off-by: Keith Busch <keith.busch@intel.com>
    Reviewed-by: Sagi Grimberg <sagi@grimbeg.me>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    [bwh: Backported to 3.16:
     - Adjust filename, context
     - Only nvme_setup_io_queues() needs to be fixed]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 220d91f75b48f16d28541b87fef790b45cbc516d
Author: Paul Jakma <paul@jakma.org>
Date:   Wed Nov 16 10:13:49 2016 +0000

    USB: serial: cp210x: add ID for the Zone DPMX
    
    commit 2ab13292d7a314fa45de0acc808e41aaad31989c upstream.
    
    The BRIM Brothers Zone DPMX is a bicycle powermeter. This ID is for the USB
    serial interface in its charging dock for the control pods, via which some
    settings for the pods can be modified.
    
    Signed-off-by: Paul Jakma <paul@jakma.org>
    Cc: Barry Redmond <barry@brimbrothers.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2bdc931eb3a3c771d6de63040f296e296a3f45b9
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Nov 1 11:38:18 2016 +0100

    mfd: core: Fix device reference leak in mfd_clone_cell
    
    commit 722f191080de641f023feaa7d5648caf377844f5 upstream.
    
    Make sure to drop the reference taken by bus_find_device_by_name()
    before returning from mfd_clone_cell().
    
    Fixes: a9bbba996302 ("mfd: add platform_device sharing support for mfd")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6a9c63564c4f3ce1a01b72b5e2316208c01c48c4
Author: Sabrina Dubroca <sd@queasysnail.net>
Date:   Tue Nov 15 10:39:03 2016 +0100

    rtnetlink: fix rtnl_vfinfo_size
    
    commit 7e75f74a171a8146cc3ee92d5562878b40c25fb5 upstream.
    
    The size reported by rtnl_vfinfo_size doesn't match the space used by
    rtnl_fill_vfinfo.
    
    rtnl_vfinfo_size currently doesn't account for the nest attributes
    used by statistics (added in commit 3b766cd83232), nor for struct
    ifla_vf_tx_rate (since commit ed616689a3d9, which added ifla_vf_rate
    to the dump without removing ifla_vf_tx_rate, but replaced
    ifla_vf_tx_rate with ifla_vf_rate in the size computation).
    
    Fixes: 3b766cd83232 ("net/core: Add reading VF statistics through the PF netdevice")
    Fixes: ed616689a3d9 ("net-next:v4: Add support to configure SR-IOV VF minimum and maximum Tx rate through ip tool")
    Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: only need to add space for IFLA_VF_TX_RATE]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 79f45203f41517c71772c002daa53ac3f52c5f7d
Author: Peter Chen <peter.chen@nxp.com>
Date:   Tue Nov 15 18:05:33 2016 +0800

    usb: chipidea: move the lock initialization to core file
    
    commit a5d906bb261cde5f881a949d3b0fbaa285dcc574 upstream.
    
    This can fix below dump when the lock is accessed at host
    mode due to it is not initialized.
    
    [   46.119638] INFO: trying to register non-static key.
    [   46.124643] the code is fine but needs lockdep annotation.
    [   46.130144] turning off the locking correctness validator.
    [   46.135659] CPU: 0 PID: 690 Comm: cat Not tainted 4.9.0-rc3-00079-g4b75f1d #1210
    [   46.143075] Hardware name: Freescale i.MX6 SoloX (Device Tree)
    [   46.148923] Backtrace:
    [   46.151448] [<c010c460>] (dump_backtrace) from [<c010c658>] (show_stack+0x18/0x1c)
    [   46.159038]  r7:edf52000
    [   46.161412]  r6:60000193
    [   46.163967]  r5:00000000
    [   46.165035]  r4:c0e25c2c
    
    [   46.169109] [<c010c640>] (show_stack) from [<c03f58a4>] (dump_stack+0xb4/0xe8)
    [   46.176362] [<c03f57f0>] (dump_stack) from [<c016d690>] (register_lock_class+0x4fc/0x56c)
    [   46.184554]  r10:c0e25d24
    [   46.187014]  r9:edf53e70
    [   46.189569]  r8:c1642444
    [   46.190637]  r7:ee9da024
    [   46.193191]  r6:00000000
    [   46.194258]  r5:00000000
    [   46.196812]  r4:00000000
    [   46.199185]  r3:00000001
    
    [   46.203259] [<c016d194>] (register_lock_class) from [<c0171294>] (__lock_acquire+0x80/0x10f0)
    [   46.211797]  r10:c0e25d24
    [   46.214257]  r9:edf53e70
    [   46.216813]  r8:ee9da024
    [   46.217880]  r7:c1642444
    [   46.220435]  r6:edcd1800
    [   46.221502]  r5:60000193
    [   46.224057]  r4:00000000
    
    [   46.227953] [<c0171214>] (__lock_acquire) from [<c01726c0>] (lock_acquire+0x74/0x94)
    [   46.235710]  r10:00000001
    [   46.238169]  r9:edf53e70
    [   46.240723]  r8:edf53f80
    [   46.241790]  r7:00000001
    [   46.244344]  r6:00000001
    [   46.245412]  r5:60000193
    [   46.247966]  r4:00000000
    
    [   46.251866] [<c017264c>] (lock_acquire) from [<c096c8fc>] (_raw_spin_lock_irqsave+0x40/0x54)
    [   46.260319]  r7:ee1c6a00
    [   46.262691]  r6:c062a570
    [   46.265247]  r5:20000113
    [   46.266314]  r4:ee9da014
    
    [   46.270393] [<c096c8bc>] (_raw_spin_lock_irqsave) from [<c062a570>] (ci_port_test_show+0x2c/0x70)
    [   46.279280]  r6:eebd2000
    [   46.281652]  r5:ee9da010
    [   46.284207]  r4:ee9da014
    
    [   46.286810] [<c062a544>] (ci_port_test_show) from [<c0248d04>] (seq_read+0x1ac/0x4f8)
    [   46.294655]  r9:edf53e70
    [   46.297028]  r8:edf53f80
    [   46.299583]  r7:ee1c6a00
    [   46.300650]  r6:00000001
    [   46.303205]  r5:00000000
    [   46.304273]  r4:eebd2000
    [   46.306850] [<c0248b58>] (seq_read) from [<c039e864>] (full_proxy_read+0x54/0x6c)
    [   46.314348]  r10:00000000
    [   46.316808]  r9:c0a6ad30
    [   46.319363]  r8:edf53f80
    [   46.320430]  r7:00020000
    [   46.322986]  r6:b6de3000
    [   46.324053]  r5:ee1c6a00
    [   46.326607]  r4:c0248b58
    
    [   46.330505] [<c039e810>] (full_proxy_read) from [<c021ec98>] (__vfs_read+0x34/0x118)
    [   46.338262]  r9:edf52000
    [   46.340635]  r8:c0107fc4
    [   46.343190]  r7:00020000
    [   46.344257]  r6:edf53f80
    [   46.346812]  r5:c039e810
    [   46.347879]  r4:ee1c6a00
    [   46.350447] [<c021ec64>] (__vfs_read) from [<c021fbd0>] (vfs_read+0x8c/0x11c)
    [   46.357597]  r9:edf52000
    [   46.359969]  r8:c0107fc4
    [   46.362524]  r7:edf53f80
    [   46.363592]  r6:b6de3000
    [   46.366147]  r5:ee1c6a00
    [   46.367214]  r4:00020000
    [   46.369782] [<c021fb44>] (vfs_read) from [<c0220a4c>] (SyS_read+0x4c/0xa8)
    [   46.376672]  r8:c0107fc4
    [   46.379045]  r7:00020000
    [   46.381600]  r6:b6de3000
    [   46.382667]  r5:ee1c6a00
    [   46.385222]  r4:ee1c6a00
    
    [   46.387817] [<c0220a00>] (SyS_read) from [<c0107e20>] (ret_fast_syscall+0x0/0x1c)
    [   46.395314]  r7:00000003
    [   46.397687]  r6:b6de3000
    [   46.400243]  r5:00020000
    [   46.401310]  r4:00020000
    
    Fixes: 26c696c678c4 ("USB: Chipidea: rename struct
                    ci13xxx variables from udc to ci")
    Signed-off-by: Peter Chen <peter.chen@nxp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fcee7d4bd149fc5ab4206aa35cc5fd113bb14d32
Author: Borislav Petkov <bp@suse.de>
Date:   Mon Nov 14 19:41:31 2016 +0100

    kbuild: Steal gcc's pie from the very beginning
    
    commit c6a385539175ebc603da53aafb7753d39089f32e upstream.
    
    So Sebastian turned off the PIE for kernel builds but that was too late
    - Kbuild.include already uses KBUILD_CFLAGS and trying to disable gcc
    options with, say cc-disable-warning, fails:
    
      gcc -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
      ...
      -Wno-sign-compare -fno-asynchronous-unwind-tables -Wframe-address -c -x c /dev/null -o .31392.tmp
      /dev/null:1:0: error: code model kernel does not support PIC mode
    
    because that returns an error and we can't disable the warning. For
    example in this case:
    
    KBUILD_CFLAGS   += $(call cc-disable-warning,frame-address,)
    
    which leads to gcc issuing all those warnings again.
    
    So let's turn off PIE/PIC at the earliest possible moment, when we
    declare KBUILD_CFLAGS so that cc-disable-warning picks it up too.
    
    Also, we need the $(call cc-option ...) because -fno-PIE is supported
    since gcc v3.4 and our lowest supported gcc version is 3.2 right now.
    
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Michal Marek <mmarek@suse.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f578da7993474f470fca4dac8bf562026ff2543c
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Thu Aug 18 09:10:44 2016 +0200

    fuse: fix fuse_write_end() if zero bytes were copied
    
    commit 59c3b76cc61d1d676f965c192cc7969aa5cb2744 upstream.
    
    If pos is at the beginning of a page and copied is zero then page is not
    zeroed but is marked uptodate.
    
    Fix by skipping everything except unlock/put of page if zero bytes were
    copied.
    
    Reported-by: Al Viro <viro@zeniv.linux.org.uk>
    Fixes: 6b12c1b37e55 ("fuse: Implement write_begin/write_end callbacks")
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8eb21f2c4ac39e538b2128f5df1e1ebc6f5536ee
Author: Petr Vandrovec <petr@vandrovec.name>
Date:   Thu Nov 10 13:57:14 2016 -0800

    Fix USB CB/CBI storage devices with CONFIG_VMAP_STACK=y
    
    commit 2ce9d2272b98743b911196c49e7af5841381c206 upstream.
    
    Some code (all error handling) submits CDBs that are allocated
    on the stack.  This breaks with CB/CBI code that tries to create
    URB directly from SCSI command buffer - which happens to be in
    vmalloced memory with vmalloced kernel stacks.
    
    Let's make copy of the command in usb_stor_CB_transport.
    
    Signed-off-by: Petr Vandrovec <petr@vandrovec.name>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 185e1a93af4b90ec4d84c8fa7a0677c74d615aa0
Author: Stephen Suryaputra Lin <stephen.suryaputra.lin@gmail.com>
Date:   Thu Nov 10 11:16:15 2016 -0500

    ipv4: use new_gw for redirect neigh lookup
    
    commit 969447f226b451c453ddc83cac6144eaeac6f2e3 upstream.
    
    In v2.6, ip_rt_redirect() calls arp_bind_neighbour() which returns 0
    and then the state of the neigh for the new_gw is checked. If the state
    isn't valid then the redirected route is deleted. This behavior is
    maintained up to v3.5.7 by check_peer_redirect() because rt->rt_gateway
    is assigned to peer->redirect_learned.a4 before calling
    ipv4_neigh_lookup().
    
    After commit 5943634fc559 ("ipv4: Maintain redirect and PMTU info in
    struct rtable again."), ipv4_neigh_lookup() is performed without the
    rt_gateway assigned to the new_gw. In the case when rt_gateway (old_gw)
    isn't zero, the function uses it as the key. The neigh is most likely
    valid since the old_gw is the one that sends the ICMP redirect message.
    Then the new_gw is assigned to fib_nh_exception. The problem is: the
    new_gw ARP may never gets resolved and the traffic is blackholed.
    
    So, use the new_gw for neigh lookup.
    
    Changes from v1:
     - use __ipv4_neigh_lookup instead (per Eric Dumazet).
    
    Fixes: 5943634fc559 ("ipv4: Maintain redirect and PMTU info in struct rtable again.")
    Signed-off-by: Stephen Suryaputra Lin <ssurya@ieee.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c9341eadaddd557e4df245bd73e25900c0abc2df
Author: WANG Cong <xiyou.wangcong@gmail.com>
Date:   Wed Sep 24 17:07:53 2014 -0700

    neigh: check error pointer instead of NULL for ipv4_neigh_lookup()
    
    commit 2c1a4311b61072afe2309d4152a7993e92caa41c upstream.
    
    Fixes: commit f187bc6efb7250afee0e2009b6106 ("ipv4: No need to set generic neighbour pointer")
    Cc: David S. Miller <davem@davemloft.net>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d5e40173c1495ebd5a4d92c681dccb715f8e5bc1
Author: Andrey Grodzovsky <andrey2805@gmail.com>
Date:   Thu Nov 10 09:35:27 2016 -0500

    scsi: mpt3sas: Fix secure erase premature termination
    
    commit 18f6084a989ba1b38702f9af37a2e4049a924be6 upstream.
    
    This is a work around for a bug with LSI Fusion MPT SAS2 when perfoming
    secure erase. Due to the very long time the operation takes, commands
    issued during the erase will time out and will trigger execution of the
    abort hook. Even though the abort hook is called for the specific
    command which timed out, this leads to entire device halt
    (scsi_state terminated) and premature termination of the secure erase.
    
    Set device state to busy while ATA passthrough commands are in progress.
    
    [mkp: hand applied to 4.9/scsi-fixes, tweaked patch description]
    
    Signed-off-by: Andrey Grodzovsky <andrey2805@gmail.com>
    Acked-by: Sreekanth Reddy <Sreekanth.Reddy@broadcom.com>
    Cc: <linux-scsi@vger.kernel.org>
    Cc: Sathya Prakash <sathya.prakash@broadcom.com>
    Cc: Chaitra P B <chaitra.basappa@broadcom.com>
    Cc: Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com>
    Cc: Sreekanth Reddy <Sreekanth.Reddy@broadcom.com>
    Cc: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit da5448733cdeefba335d2e68fe66ff3754b3512f
Author: Sean Young <sean@mess.org>
Date:   Thu Nov 10 17:44:49 2016 +0100

    dib0700: fix nec repeat handling
    
    commit ba13e98f2cebd55a3744c5ffaa08f9dca73bf521 upstream.
    
    When receiving a nec repeat, ensure the correct scancode is repeated
    rather than a random value from the stack.  This removes the need for
    the bogus uninitialized_var() and also fixes the warnings:
    
        drivers/media/usb/dvb-usb/dib0700_core.c: In function ‘dib0700_rc_urb_completion’:
        drivers/media/usb/dvb-usb/dib0700_core.c:679: warning: ‘protocol’ may be used uninitialized in this function
    
    [sean addon: So after writing the patch and submitting it, I've bought the
                 hardware on ebay. Without this patch you get random scancodes
                 on nec repeats, which the patch indeed fixes.]
    
    Signed-off-by: Sean Young <sean@mess.org>
    Tested-by: Sean Young <sean@mess.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 032889978169077fd75f4745fef3d378ed808c07
Author: Andrey Ryabinin <aryabinin@virtuozzo.com>
Date:   Thu Nov 10 10:46:38 2016 -0800

    coredump: fix unfreezable coredumping task
    
    commit 70d78fe7c8b640b5acfad56ad341985b3810998a upstream.
    
    It could be not possible to freeze coredumping task when it waits for
    'core_state->startup' completion, because threads are frozen in
    get_signal() before they got a chance to complete 'core_state->startup'.
    
    Inability to freeze a task during suspend will cause suspend to fail.
    Also CRIU uses cgroup freezer during dump operation.  So with an
    unfreezable task the CRIU dump will fail because it waits for a
    transition from 'FREEZING' to 'FROZEN' state which will never happen.
    
    Use freezer_do_not_count() to tell freezer to ignore coredumping task
    while it waits for core_state->startup completion.
    
    Link: http://lkml.kernel.org/r/1475225434-3753-1-git-send-email-aryabinin@virtuozzo.com
    Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
    Acked-by: Pavel Machek <pavel@ucw.cz>
    Acked-by: Oleg Nesterov <oleg@redhat.com>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
    Cc: Michal Hocko <mhocko@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 817a7e885801c8efe8ed4ecc1903255c9750857d
Author: Jann Horn <jann@thejh.net>
Date:   Thu Nov 10 10:46:19 2016 -0800

    swapfile: fix memory corruption via malformed swapfile
    
    commit dd111be69114cc867f8e826284559bfbc1c40e37 upstream.
    
    When root activates a swap partition whose header has the wrong
    endianness, nr_badpages elements of badpages are swabbed before
    nr_badpages has been checked, leading to a buffer overrun of up to 8GB.
    
    This normally is not a security issue because it can only be exploited
    by root (more specifically, a process with CAP_SYS_ADMIN or the ability
    to modify a swap file/partition), and such a process can already e.g.
    modify swapped-out memory of any other userspace process on the system.
    
    Link: http://lkml.kernel.org/r/1477949533-2509-1-git-send-email-jann@thejh.net
    Signed-off-by: Jann Horn <jann@thejh.net>
    Acked-by: Kees Cook <keescook@chromium.org>
    Acked-by: Jerome Marchand <jmarchan@redhat.com>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Hugh Dickins <hughd@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c45aadd9813c2e274b18dfbb40b07b45097acbab
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Nov 11 12:33:20 2016 +0100

    ALSA: hda - Fix mic regression by ASRock mobo fixup
    
    commit 9a2541910dc7eaaa6859eea8a0ffda673059a623 upstream.
    
    The commit [1a3f099101b8: ALSA: hda - Fix surround output pins for
    ASRock B150M mobo] introduced a fixup of pin configs for ASRock
    mobos to fix the surround outputs.  However, this overrides the pin
    configs of the mic pins as if they are outputs-only, effectively
    disabling the mic inputs.  Of course, it's a regression wrt mic
    functionality.
    
    Actually the pins 0x18 and 0x1a don't need to be changed; we just need
    to disable the bogus pins 0x14 and 0x15.  Then the auto-parser will
    pick up mic pins as switchable and assign the surround outputs there.
    
    This patch removes the incorrect pin overrides of NID 0x18 and 0x1a
    from the ASRock fixup.
    
    Fixes: 1a3f099101b8 ('ALSA: hda - Fix surround output pins for ASRock...')
    Reported-and-tested-by: Vitor Antunes <vitor.hda@gmail.com>
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=187431
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f7c9b17c00eb86ec8f1f55883943fcc420bf4cb4
Author: Brian Norris <briannorris@chromium.org>
Date:   Wed Nov 9 17:21:08 2016 -0800

    PM / sleep: don't suspend parent when async child suspend_{noirq, late} fails
    
    commit 6f75c3fd56daf547d684127a7f83c283c3c160d1 upstream.
    
    Consider two devices, A and B, where B is a child of A, and B utilizes
    asynchronous suspend (it does not matter whether A is sync or async). If
    B fails to suspend_noirq() or suspend_late(), or is interrupted by a
    wakeup (pm_wakeup_pending()), then it aborts and sets the async_error
    variable. However, device A does not (immediately) check the async_error
    variable; it may continue to run its own suspend_noirq()/suspend_late()
    callback. This is bad.
    
    We can resolve this problem by doing our error and wakeup checking
    (particularly, for the async_error flag) after waiting for children to
    suspend, instead of before. This also helps align the logic for the noirq and
    late suspend cases with the logic in __device_suspend().
    
    It's easy to observe this erroneous behavior by, for example, forcing a
    device to sleep a bit in its suspend_noirq() (to ensure the parent is
    waiting for the child to complete), then return an error, and watch the
    parent suspend_noirq() still get called. (Or similarly, fake a wakeup
    event at the right (or is it wrong?) time.)
    
    Fixes: de377b397272 (PM / sleep: Asynchronous threads for suspend_late)
    Fixes: 28b6fd6e3779 (PM / sleep: Asynchronous threads for suspend_noirq)
    Reported-by: Jeffy Chen <jeffy.chen@rock-chips.com>
    Signed-off-by: Brian Norris <briannorris@chromium.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e847450961c019730f0347ade53e0fa2fe9387c5
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Nov 8 13:10:57 2016 +0100

    USB: cdc-acm: fix TIOCMIWAIT
    
    commit 18266403f3fe507f0246faa1d5432333a2f139ca upstream.
    
    The TIOCMIWAIT implementation would return -EINVAL if any of the three
    supported signals were included in the mask.
    
    Instead of returning an error in case TIOCM_CTS is included, simply
    drop the mask check completely, which is in accordance with how other
    drivers implement this ioctl.
    
    Fixes: 5a6a62bdb925 ("cdc-acm: add TIOCMIWAIT")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Acked-by: Oliver Neukum <oneukum@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit cdcd7162f822a7629a79e11c8490fbeb322bd30e
Author: Hui Wang <hui.wang@canonical.com>
Date:   Thu Nov 10 13:20:05 2016 +0800

    ALSA: hda - add a new condition to check if it is thinkpad
    
    commit 2ecb704a1290edb5e3d53a75529192e7ed2a1a28 upstream.
    
    Latest Thinkpad laptops use the HKEY_HID LEN0268 instead of the
    LEN0068, as a result neither audio mute led nor mic mute led can work
    any more.
    
    After adding the new HKEY_HID into the is_thinkpad(), both of them
    works well as before.
    
    Signed-off-by: Hui Wang <hui.wang@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    [bwh: Backported to 3.16: use acpi_get_devices() instead of acpi_dev_found()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f60c9f651a505df9d132e2ac61af229506eac2d5
Author: Mathias Krause <minipli@googlemail.com>
Date:   Mon Nov 7 23:22:19 2016 +0100

    rtnl: reset calcit fptr in rtnl_unregister()
    
    commit f567e950bf51290755a2539ff2aaef4c26f735d3 upstream.
    
    To avoid having dangling function pointers left behind, reset calcit in
    rtnl_unregister(), too.
    
    This is no issue so far, as only the rtnl core registers a netlink
    handler with a calcit hook which won't be unregistered, but may become
    one if new code makes use of the calcit hook.
    
    Fixes: c7ac8679bec9 ("rtnetlink: Compute and store minimum ifinfo...")
    Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Cc: Greg Rose <gregory.v.rose@intel.com>
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 982003cd25059b11504e16c8c02e3b036c3105f1
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Fri Nov 4 19:39:39 2016 +0100

    scripts/has-stack-protector: add -fno-PIE
    
    commit 82031ea29e454b574bc6f49a33683a693ca5d907 upstream.
    
    Adding -no-PIE to the fstack protector check. -no-PIE was introduced
    before -fstack-protector so there is no need for a runtime check.
    
    Without it the build stops:
    |Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong available but compiler is broken
    
    due to -mcmodel=kernel + -fPIE if -fPIE is enabled by default.
    
    Tagging it stable so it is possible to compile recent stable kernels as
    well.
    
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Michal Marek <mmarek@suse.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a91c92626249a0274c625b3fbb5d20041d1b5a13
Author: Sumit Saxena <sumit.saxena@broadcom.com>
Date:   Wed Nov 9 02:59:42 2016 -0800

    scsi: megaraid_sas: fix macro MEGASAS_IS_LOGICAL to avoid regression
    
    commit 5e5ec1759dd663a1d5a2f10930224dd009e500e8 upstream.
    
    This patch will fix regression caused by commit 1e793f6fc0db ("scsi:
    megaraid_sas: Fix data integrity failure for JBOD (passthrough)
    devices").
    
    The problem was that the MEGASAS_IS_LOGICAL macro did not have braces
    and as a result the driver ended up exposing a lot of non-existing SCSI
    devices (all SCSI commands to channels 1,2,3 were returned as
    SUCCESS-DID_OK by driver).
    
    [mkp: clarified patch description]
    
    Fixes: 1e793f6fc0db920400574211c48f9157a37e3945
    Reported-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com>
    Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
    Tested-by: Sumit Saxena <sumit.saxena@broadcom.com>
    Reviewed-by: Tomas Henzl <thenzl@redhat.com>
    Tested-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fc23d5570ca80b7b6dbaa6d6d6e7fda272acc923
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Fri Nov 4 19:39:38 2016 +0100

    kbuild: add -fno-PIE
    
    commit 8ae94224c9d72fc4d9aaac93b2d7833cf46d7141 upstream.
    
    Debian started to build the gcc with -fPIE by default so the kernel
    build ends before it starts properly with:
    |kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
    
    Also add to KBUILD_AFLAGS due to:
    
    |gcc -Wp,-MD,arch/x86/entry/vdso/vdso32/.note.o.d … -mfentry -DCC_USING_FENTRY … vdso/vdso32/note.S
    |arch/x86/entry/vdso/vdso32/note.S:1:0: sorry, unimplemented: -mfentry isn’t supported for 32-bit in combination with -fpic
    
    Tagging it stable so it is possible to compile recent stable kernels as
    well.
    
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Michal Marek <mmarek@suse.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fc4167f5277301dfc95bf43eed43b1b020f529f0
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Nov 3 18:40:20 2016 +0100

    net: ethernet: ti: cpsw: fix device and of_node leaks
    
    commit c7262aaace1b17a650598063e3b9ee1785fde377 upstream.
    
    Make sure to drop the references taken by of_get_child_by_name() and
    bus_find_device() before returning from cpsw_phy_sel().
    
    Note that holding a reference to the cpsw-phy-sel device does not
    prevent the devres-managed private data from going away.
    
    Fixes: 5892cd135e16 ("drivers: net: cpsw-phy-sel: Add new driver...")
    Cc: Mugunthan V N <mugunthanvnm@ti.com>
    Cc: Grygorii Strashko <grygorii.strashko@ti.com>
    Cc: linux-omap@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit cd9e47dc4a69d2dc7f1f7e7be3f40991b2a89ae2
Author: Fabio Estevam <fabio.estevam@nxp.com>
Date:   Sat Nov 5 17:45:07 2016 -0200

    mmc: mxs: Initialize the spinlock prior to using it
    
    commit f91346e8b5f46aaf12f1df26e87140584ffd1b3f upstream.
    
    An interrupt may occur right after devm_request_irq() is called and
    prior to the spinlock initialization, leading to a kernel oops,
    as the interrupt handler uses the spinlock.
    
    In order to prevent this problem, move the spinlock initialization
    prior to requesting the interrupts.
    
    Fixes: e4243f13d10e (mmc: mxs-mmc: add mmc host driver for i.MX23/28)
    Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
    Reviewed-by: Marek Vasut <marex@denx.de>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    [bwh: Backported to 3.16 adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bc776413673d4cf2ab7a035da4c07a737e5fbbd9
Author: Marc Dietrich <marvin24@gmx.de>
Date:   Tue Nov 1 13:59:40 2016 +0100

    staging: nvec: remove managed resource from PS2 driver
    
    commit 68fae2f3df455f53d0dfe33483a49020b3b758f3 upstream.
    
    This basicly reverts commit e534f3e9 (staging:nvec: Introduce the use of
    the managed version of kzalloc). Serio struct should never by managed
    because it is refcounted. Doing so will lead to a double free oops on module
    remove.
    
    Signed-off-by: Marc Dietrich <marvin24@gmx.de>
    Fixes: e534f3e9429f ("staging:nvec: Introduce the use of the managed version of kzalloc")
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2386b74f680ef74c12f1d327cb1f5ba98b734f45
Author: Paul Fertser <fercerpav@gmail.com>
Date:   Thu Oct 27 17:22:09 2016 +0300

    Revert "staging: nvec: ps2: change serio type to passthrough"
    
    commit 17c1c9ba15b238ef79b51cf40d855c05b58d5934 upstream.
    
    This reverts commit 36b30d6138f4677514aca35ab76c20c1604baaad.
    
    This is necessary to detect paz00 (ac100) touchpad properly as one
    speaking ETPS/2 protocol. Without it X.org's synaptics driver doesn't
    work as the touchpad is detected as an ImPS/2 mouse instead.
    
    Commit ec6184b1c717b8768122e25fe6d312f609cc1bb4 changed the way
    auto-detection is performed on ports marked as pass through and made the
    issue apparent.
    
    A pass through port is an additional PS/2 port used to connect a slave
    device to a master device that is using PS/2 to communicate with the
    host (so slave's PS/2 communication is tunneled over master's PS/2
    link). "Synaptics PS/2 TouchPad Interfacing Guide" describes such a
    setup (PS/2 PASS-THROUGH OPTION section).
    
    Since paz00's embedded controller is not connected to a PS/2 port
    itself, the PS/2 interface it exposes is not a pass-through one.
    
    Signed-off-by: Paul Fertser <fercerpav@gmail.com>
    Acked-by: Marc Dietrich <marvin24@gmx.de>
    Fixes: 36b30d6138f4 ("staging: nvec: ps2: change serio type to passthrough")
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6984cd1a141114c2789e12ab950fd7b0939b0324
Author: Paul Fertser <fercerpav@gmail.com>
Date:   Thu Oct 27 17:22:08 2016 +0300

    drivers: staging: nvec: remove bogus reset command for PS/2 interface
    
    commit d8f8a74d5fece355d2234e1731231d1aebc66b38 upstream.
    
    This command was sent behind serio's back and the answer to it was
    confusing atkbd probe function which lead to the elantech touchpad
    getting detected as a keyboard.
    
    To prevent this from happening just let every party do its part of the
    job.
    
    Signed-off-by: Paul Fertser <fercerpav@gmail.com>
    Acked-by: Marc Dietrich <marvin24@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8f44c909e118b08136ae3b0cd1c87b2cd2a7190c
Author: Doug Brown <doug@schmorgal.com>
Date:   Fri Nov 4 21:18:20 2016 -0700

    USB: serial: ftdi_sio: add support for TI CC3200 LaunchPad
    
    commit 9bfef729a3d11f04d12788d749a3ce6b47645734 upstream.
    
    This patch adds support for the TI CC3200 LaunchPad board, which uses a
    custom USB vendor ID and product ID. Channel A is used for JTAG, and
    channel B is used for a UART.
    
    Signed-off-by: Doug Brown <doug@schmorgal.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 274b874d00600cf100864a5bbfa4995e76a22c24
Author: Song Hongyan <hongyan.song@intel.com>
Date:   Tue Oct 25 01:30:07 2016 +0000

    iio: hid-sensors: Increase the precision of scale to fix wrong reading interpretation.
    
    commit 6f77199e9e4b84340c751c585691d7642a47d226 upstream.
    
    While testing, it was observed that on some platforms the scale value
    from iio sysfs for gyroscope is always 0 (E.g. Yoga 260). This results
    in the final angular velocity component values to be zeros.
    
    This is caused by insufficient precision of scale value displayed in sysfs.
    If the precision is changed to nano from current micro, then this is
    sufficient to display the scale value on this platform.
    Since this can be a problem for all other HID sensors, increase scale
    precision of all HID sensors to nano from current micro.
    
    Results on Yoga 260:
    
    name            scale before    scale now
    --------------------------------------------
    gyro_3d         0.000000        0.000000174
    als                     0.001000        0.001000000
    magn_3d         0.000001        0.000001000
    accel_3d                0.000009        0.000009806
    
    Signed-off-by: Song Hongyan <hongyan.song@intel.com>
    Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0f1ce2b97e907a4b2ee4865222757b0119c5cdac
Author: Sachin Kamat <sachin.kamat@samsung.com>
Date:   Fri Mar 7 07:44:00 2014 +0000

    iio: hid-sensors: Fix compilation warning
    
    commit a034234277d2f51104deadd559dd9584ba00a8cc upstream.
    
    Move the 'static' keyword to beginning of definition to silence the
    following compilation warning:
    drivers/iio/common/hid-sensors/hid-sensor-attributes.c:34:1: warning: ‘static’ is not at beginning of declaration [-Wold-style-declaration]
    
    Signed-off-by: Sachin Kamat <sachin.kamat@samsung.com>
    Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d776b0380d58978b41806e497dc7338968731db9
Author: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Date:   Mon Oct 31 21:46:24 2016 +0200

    i2c: core: fix NULL pointer dereference under race condition
    
    commit 147b36d5b70c083cc76770c47d60b347e8eaf231 upstream.
    
    Race condition between registering an I2C device driver and
    deregistering an I2C adapter device which is assumed to manage that
    I2C device may lead to a NULL pointer dereference due to the
    uninitialized list head of driver clients.
    
    The root cause of the issue is that the I2C bus may know about the
    registered device driver and thus it is matched by bus_for_each_drv(),
    but the list of clients is not initialized and commonly it is NULL,
    because I2C device drivers define struct i2c_driver as static and
    clients field is expected to be initialized by I2C core:
    
      i2c_register_driver()             i2c_del_adapter()
        driver_register()                 ...
          bus_add_driver()                ...
            ...                           bus_for_each_drv(..., __process_removed_adapter)
          ...                               i2c_do_del_adapter()
        ...                                   list_for_each_entry_safe(..., &driver->clients, ...)
        INIT_LIST_HEAD(&driver->clients);
    
    To solve the problem it is sufficient to do clients list head
    initialization before calling driver_register().
    
    The problem was found while using an I2C device driver with a sluggish
    registration routine on a bus provided by a physically detachable I2C
    master controller, but practically the oops may be reproduced under
    the race between arbitraty I2C device driver registration and managing
    I2C bus device removal e.g. by unbinding the latter over sysfs:
    
    % echo 21a4000.i2c > /sys/bus/platform/drivers/imx-i2c/unbind
      Unable to handle kernel NULL pointer dereference at virtual address 00000000
      Internal error: Oops: 17 [#1] SMP ARM
      CPU: 2 PID: 533 Comm: sh Not tainted 4.9.0-rc3+ #61
      Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
      task: e5ada400 task.stack: e4936000
      PC is at i2c_do_del_adapter+0x20/0xcc
      LR is at __process_removed_adapter+0x14/0x1c
      Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
      Control: 10c5387d  Table: 35bd004a  DAC: 00000051
      Process sh (pid: 533, stack limit = 0xe4936210)
      Stack: (0xe4937d28 to 0xe4938000)
      Backtrace:
      [<c0667be0>] (i2c_do_del_adapter) from [<c0667cc0>] (__process_removed_adapter+0x14/0x1c)
      [<c0667cac>] (__process_removed_adapter) from [<c0516998>] (bus_for_each_drv+0x6c/0xa0)
      [<c051692c>] (bus_for_each_drv) from [<c06685ec>] (i2c_del_adapter+0xbc/0x284)
      [<c0668530>] (i2c_del_adapter) from [<bf0110ec>] (i2c_imx_remove+0x44/0x164 [i2c_imx])
      [<bf0110a8>] (i2c_imx_remove [i2c_imx]) from [<c051a838>] (platform_drv_remove+0x2c/0x44)
      [<c051a80c>] (platform_drv_remove) from [<c05183d8>] (__device_release_driver+0x90/0x12c)
      [<c0518348>] (__device_release_driver) from [<c051849c>] (device_release_driver+0x28/0x34)
      [<c0518474>] (device_release_driver) from [<c0517150>] (unbind_store+0x80/0x104)
      [<c05170d0>] (unbind_store) from [<c0516520>] (drv_attr_store+0x28/0x34)
      [<c05164f8>] (drv_attr_store) from [<c0298acc>] (sysfs_kf_write+0x50/0x54)
      [<c0298a7c>] (sysfs_kf_write) from [<c029801c>] (kernfs_fop_write+0x100/0x214)
      [<c0297f1c>] (kernfs_fop_write) from [<c0220130>] (__vfs_write+0x34/0x120)
      [<c02200fc>] (__vfs_write) from [<c0221088>] (vfs_write+0xa8/0x170)
      [<c0220fe0>] (vfs_write) from [<c0221e74>] (SyS_write+0x4c/0xa8)
      [<c0221e28>] (SyS_write) from [<c0108a20>] (ret_fast_syscall+0x0/0x1c)
    
    Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 62ac9322ace32add8a5eee36d8086faabdd0dd15
Author: Lance Richardson <lrichard@redhat.com>
Date:   Wed Nov 2 16:36:17 2016 -0400

    ipv4: allow local fragmentation in ip_finish_output_gso()
    
    commit 9ee6c5dc816aa8256257f2cd4008a9291ec7e985 upstream.
    
    Some configurations (e.g. geneve interface with default
    MTU of 1500 over an ethernet interface with 1500 MTU) result
    in the transmission of packets that exceed the configured MTU.
    While this should be considered to be a "bad" configuration,
    it is still allowed and should not result in the sending
    of packets that exceed the configured MTU.
    
    Fix by dropping the assumption in ip_finish_output_gso() that
    locally originated gso packets will never need fragmentation.
    Basic testing using iperf (observing CPU usage and bandwidth)
    have shown no measurable performance impact for traffic not
    requiring fragmentation.
    
    Fixes: c7ba65d7b649 ("net: ip: push gso skb forwarding handling down the stack")
    Reported-by: Jan Tluka <jtluka@redhat.com>
    Signed-off-by: Lance Richardson <lrichard@redhat.com>
    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: never had the IPSKB_FRAG_SEGS flag]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 32aa5c99f49e04d1fa5ef9421282ac73f73d77cc
Author: Oliver Neukum <oneukum@suse.com>
Date:   Thu Nov 3 12:31:41 2016 +0100

    HID: usbhid: add ATEN CS962 to list of quirky devices
    
    commit cf0ea4da4c7df11f7a508b2f37518e0f117f3791 upstream.
    
    Like many similar devices it needs a quirk to work.
    Issuing the request gets the device into an irrecoverable state.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2e863ceddbd8f7d167461b16ed3731fdb43c49b3
Author: Laura Abbott <labbott@fedoraproject.org>
Date:   Tue May 12 10:00:00 2015 -0700

    HID: usbhid: Add HID_QUIRK_NOGET for Aten DVI KVM switch
    
    commit 849eca7b9dae0364e2fbe8afdf0fb610d12c9c8f upstream.
    
    Like other KVM switches, the Aten DVI KVM switch needs a quirk to avoid spewing
    errors:
    
    [791759.606542] usb 1-5.4: input irq status -75 received
    [791759.614537] usb 1-5.4: input irq status -75 received
    [791759.622542] usb 1-5.4: input irq status -75 received
    
    Add it.
    
    Signed-off-by: Laura Abbott <labbott@fedoraproject.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f31d4542bf1aa7c7c902cb9066fb37d4e8d9e3b6
Author: Stefan Richter <stefanr@s5r6.in-berlin.de>
Date:   Sun Oct 30 17:32:01 2016 +0100

    firewire: net: fix fragmented datagram_size off-by-one
    
    commit e9300a4b7bbae83af1f7703938c94cf6dc6d308f upstream.
    
    RFC 2734 defines the datagram_size field in fragment encapsulation
    headers thus:
    
        datagram_size:  The encoded size of the entire IP datagram.  The
        value of datagram_size [...] SHALL be one less than the value of
        Total Length in the datagram's IP header (see STD 5, RFC 791).
    
    Accordingly, the eth1394 driver of Linux 2.6.36 and older set and got
    this field with a -/+1 offset:
    
        ether1394_tx() /* transmit */
            ether1394_encapsulate_prep()
                hdr->ff.dg_size = dg_size - 1;
    
        ether1394_data_handler() /* receive */
            if (hdr->common.lf == ETH1394_HDR_LF_FF)
                dg_size = hdr->ff.dg_size + 1;
            else
                dg_size = hdr->sf.dg_size + 1;
    
    Likewise, I observe OS X 10.4 and Windows XP Pro SP3 to transmit 1500
    byte sized datagrams in fragments with datagram_size=1499 if link
    fragmentation is required.
    
    Only firewire-net sets and gets datagram_size without this offset.  The
    result is lacking interoperability of firewire-net with OS X, Windows
    XP, and presumably Linux' eth1394.  (I did not test with the latter.)
    For example, FTP data transfers to a Linux firewire-net box with max_rec
    smaller than the 1500 bytes MTU
      - from OS X fail entirely,
      - from Win XP start out with a bunch of fragmented datagrams which
        time out, then continue with unfragmented datagrams because Win XP
        temporarily reduces the MTU to 576 bytes.
    
    So let's fix firewire-net's datagram_size accessors.
    
    Note that firewire-net thereby loses interoperability with unpatched
    firewire-net, but only if link fragmentation is employed.  (This happens
    with large broadcast datagrams, and with large datagrams on several
    FireWire CardBus cards with smaller max_rec than equivalent PCI cards,
    and it can be worked around by setting a small enough MTU.)
    
    Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 176ae6407856cfeb30a03a904e7543987c473f74
Author: John David Anglin <dave.anglin@bell.net>
Date:   Fri Oct 28 23:00:34 2016 -0400

    parisc: Ensure consistent state when switching to kernel stack at syscall entry
    
    commit 6ed518328d0189e0fdf1bb7c73290d546143ea66 upstream.
    
    We have one critical section in the syscall entry path in which we switch from
    the userspace stack to kernel stack. In the event of an external interrupt, the
    interrupt code distinguishes between those two states by analyzing the value of
    sr7. If sr7 is zero, it uses the kernel stack. Therefore it's important, that
    the value of sr7 is in sync with the currently enabled stack.
    
    This patch now disables interrupts while executing the critical section.  This
    prevents the interrupt handler to possibly see an inconsistent state which in
    the worst case can lead to crashes.
    
    Interestingly, in the syscall exit path interrupts were already disabled in the
    critical section which switches back to the userspace stack.
    
    Signed-off-by: John David Anglin <dave.anglin@bell.net>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9cc906639d6cb4e2b4e4c6634fc56426f5894639
Author: Eli Cooper <elicooper@gmx.com>
Date:   Tue Nov 1 23:45:12 2016 +0800

    ip6_tunnel: Clear IP6CB in ip6tunnel_xmit()
    
    commit 23f4ffedb7d751c7e298732ba91ca75d224bc1a6 upstream.
    
    skb->cb may contain data from previous layers. In the observed scenario,
    the garbage data were misinterpreted as IP6CB(skb)->frag_max_size, so
    that small packets sent through the tunnel are mistakenly fragmented.
    
    This patch unconditionally clears the control buffer in ip6tunnel_xmit(),
    which affects ip6_tunnel, ip6_udp_tunnel and ip6_gre. Currently none of
    these tunnels set IP6CB(skb)->flags, otherwise it needs to be done earlier.
    
    Signed-off-by: Eli Cooper <elicooper@gmx.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e5eb6913c62999d31c88de843e282a8d97946012
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Nov 1 11:49:56 2016 +0100

    PM / sleep: fix device reference leak in test_suspend
    
    commit ceb75787bc75d0a7b88519ab8a68067ac690f55a upstream.
    
    Make sure to drop the reference taken by class_find_device() after
    opening the RTC device.
    
    Fixes: 77437fd4e61f (pm: boot time suspend selftest)
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f0cde54863da281cec1ed85497b4ec58d29c1460
Author: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Date:   Wed Oct 19 15:03:41 2016 -0600

    gpio/mvebu: Use irq_domain_add_linear
    
    commit 812d47889a8e418d7bea9bec383581a34c19183e upstream.
    
    This fixes the irq allocation in this driver to not print:
     irq: Cannot allocate irq_descs @ IRQ34, assuming pre-allocated
     irq: Cannot allocate irq_descs @ IRQ66, assuming pre-allocated
    
    Which happens because the driver already called irq_alloc_descs()
    and so the change to use irq_domain_add_simple resulted in calling
    irq_alloc_descs() twice.
    
    Modernize the irq allocation in this driver to use the
    irq_domain_add_linear flow directly and eliminate the use of
    irq_domain_add_simple/legacy
    
    Fixes: ce931f571b6d ("gpio/mvebu: convert to use irq_domain_add_simple()")
    Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    [bwh: Backported to 3.16:
     - Keep using irq_set_handler_data(), irq_set_chained_handler()
     - Adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 754c3cd742182dc2c7df777e0612a62c1eea62a8
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Nov 1 12:13:31 2016 +0100

    uwb: fix device reference leaks
    
    commit d6124b409ca33c100170ffde51cd8dff761454a1 upstream.
    
    This subsystem consistently fails to drop the device reference taken by
    class_find_device().
    
    Note that some of these lookup functions already take a reference to the
    returned data, while others claim no reference is needed (or does not
    seem need one).
    
    Fixes: 183b9b592a62 ("uwb: add the UWB stack (core files)")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 60811cdb035aa2755928ef499b21c0781888d3be
Author: Felipe Balbi <felipe.balbi@linux.intel.com>
Date:   Tue Nov 1 13:20:22 2016 +0200

    usb: gadget: u_ether: remove interrupt throttling
    
    commit fd9afd3cbe404998d732be6cc798f749597c5114 upstream.
    
    According to Dave Miller "the networking stack has a
    hard requirement that all SKBs which are transmitted
    must have their completion signalled in a fininte
    amount of time. This is because, until the SKB is
    freed by the driver, it holds onto socket,
    netfilter, and other subsystem resources."
    
    In summary, this means that using TX IRQ throttling
    for the networking gadgets is, at least, complex and
    we should avoid it for the time being.
    
    Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Suggested-by: David Miller <davem@davemloft.net>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    [bwh: Backported to 3.16: adjust filename, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 50ef5ffed9e40be91ea5a6ad4bc94bb1dad09199
Author: Andy Gospodarek <gospo@broadcom.com>
Date:   Mon Oct 31 13:32:03 2016 -0400

    bgmac: stop clearing DMA receive control register right after it is set
    
    commit fcdefccac976ee51dd6071832b842d8fb41c479c upstream.
    
    Current bgmac code initializes some DMA settings in the receive control
    register for some hardware and then immediately clears those settings.
    Not clearing those settings results in ~420Mbps *improvement* in
    throughput; this system can now receive frames at line-rate on Broadcom
    5871x hardware compared to ~520Mbps today.  I also tested a few other
    values but found there to be no discernible difference in CPU
    utilization even if burst size and prefetching values are different.
    
    On the hardware tested there was no need to keep the code that cleared
    all but bits 16-17, but since there is a wide variety of hardware that
    used this driver (I did not look at all hardware docs for hardware using
    this IP block), I find it wise to move this call up and clear bits just
    after reading the default value from the hardware rather than completely
    removing it.
    
    This is a good candidate for -stable >=3.14 since that is when the code
    that was supposed to improve performance (but did not) was introduced.
    
    Signed-off-by: Andy Gospodarek <gospo@broadcom.com>
    Fixes: 56ceecde1f29 ("bgmac: initialize the DMA controller of core...")
    Cc: Hauke Mehrtens <hauke@hauke-m.de>
    Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c3f5d4495036a94aebe4ba4ffed9fc3705ef9571
Author: Oliver Hartkopp <socketcan@hartkopp.net>
Date:   Mon Oct 24 21:11:26 2016 +0200

    can: bcm: fix warning in bcm_connect/proc_register
    
    commit deb507f91f1adbf64317ad24ac46c56eeccfb754 upstream.
    
    Andrey Konovalov reported an issue with proc_register in bcm.c.
    As suggested by Cong Wang this patch adds a lock_sock() protection and
    a check for unsuccessful proc_create_data() in bcm_connect().
    
    Reference: http://marc.info/?l=linux-netdev&m=147732648731237
    
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Suggested-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
    Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
    Tested-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3b80503137bd6a523f23d7d04bcfeb24ff587164
Author: Jakub Sitnicki <jkbs@redhat.com>
Date:   Wed Oct 26 11:21:14 2016 +0200

    ipv6: Don't use ufo handling on later transformed packets
    
    commit f89c56ce710afa65e1b2ead555b52c4807f34ff7 upstream.
    
    Similar to commit c146066ab802 ("ipv4: Don't use ufo handling on later
    transformed packets"), don't perform UFO on packets that will be IPsec
    transformed. To detect it we rely on the fact that headerlen in
    dst_entry is non-zero only for transformation bundles (xfrm_dst
    objects).
    
    Unwanted segmentation can be observed with a NETIF_F_UFO capable device,
    such as a dummy device:
    
      DEV=dum0 LEN=1493
    
      ip li add $DEV type dummy
      ip addr add fc00::1/64 dev $DEV nodad
      ip link set $DEV up
      ip xfrm policy add dir out src fc00::1 dst fc00::2 \
         tmpl src fc00::1 dst fc00::2 proto esp spi 1
      ip xfrm state add src fc00::1 dst fc00::2 \
         proto esp spi 1 enc 'aes' 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
    
      tcpdump -n -nn -i $DEV -t &
      socat /dev/zero,readbytes=$LEN udp6:[fc00::2]:$LEN
    
    tcpdump output before:
    
      IP6 fc00::1 > fc00::2: frag (0|1448) ESP(spi=0x00000001,seq=0x1), length 1448
      IP6 fc00::1 > fc00::2: frag (1448|48)
      IP6 fc00::1 > fc00::2: ESP(spi=0x00000001,seq=0x2), length 88
    
    ... and after:
    
      IP6 fc00::1 > fc00::2: frag (0|1448) ESP(spi=0x00000001,seq=0x1), length 1448
      IP6 fc00::1 > fc00::2: frag (1448|80)
    
    Fixes: e89e9cf539a2 ("[IPv4/IPv6]: UFO Scatter-gather approach")
    
    Signed-off-by: Jakub Sitnicki <jkbs@redhat.com>
    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ad6dcc78333f0e2e2add0f1b350ce8d049e98ffc
Author: Alexander Usyskin <alexander.usyskin@intel.com>
Date:   Mon Oct 31 19:02:39 2016 +0200

    mei: bus: fix received data size check in NFC fixup
    
    commit 582ab27a063a506ccb55fc48afcc325342a2deba upstream.
    
    NFC version reply size checked against only header size, not against
    full message size. That may lead potentially to uninitialized memory access
    in version data.
    
    That leads to warnings when version data is accessed:
    drivers/misc/mei/bus-fixup.c: warning: '*((void *)&ver+11)' may be used uninitialized in this function [-Wuninitialized]:  => 212:2
    
    Reported in
    Build regressions/improvements in v4.9-rc3
    https://lkml.org/lkml/2016/10/30/57
    
    Fixes: 59fcd7c63abf (mei: nfc: Initial nfc implementation)
    Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
    Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.16:
     - Drop change in mei_phy.c
     - Adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6ca68d9535acf388b07d141a743316632d8b3cbe
Author: Liping Zhang <zlpnobody@gmail.com>
Date:   Sat Oct 29 22:03:05 2016 +0800

    netfilter: nf_tables: destroy the set if fail to add transaction
    
    commit c17c3cdff10b9f59ef1244a14604f10949f17117 upstream.
    
    When the memory is exhausted, then we will fail to add the NFT_MSG_NEWSET
    transaction. In such case, we should destroy the set before we free it.
    
    Fixes: 958bee14d071 ("netfilter: nf_tables: use new transaction infrastructure to handle sets")
    Signed-off-by: Liping Zhang <zlpnobody@gmail.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 36da5ca72753251ea0e188792e801a0ad4bdbb37
Author: Matt Redfearn <matt.redfearn@imgtec.com>
Date:   Tue Oct 11 12:05:15 2016 +0100

    virtio: console: Unlock vqs while freeing buffers
    
    commit 34563769e438d2881f62cf4d9badc4e589ac0ec0 upstream.
    
    Commit c6017e793b93 ("virtio: console: add locks around buffer removal
    in port unplug path") added locking around the freeing of buffers in the
    vq. However, when free_buf() is called with can_sleep = true and rproc
    is enabled, it calls dma_free_coherent() directly, requiring interrupts
    to be enabled. Currently a WARNING is triggered due to the spin locking
    around free_buf, with a call stack like this:
    
    WARNING: CPU: 3 PID: 121 at ./include/linux/dma-mapping.h:433
    free_buf+0x1a8/0x288
    Call Trace:
    [<8040c538>] show_stack+0x74/0xc0
    [<80757240>] dump_stack+0xd0/0x110
    [<80430d98>] __warn+0xfc/0x130
    [<80430ee0>] warn_slowpath_null+0x2c/0x3c
    [<807e7c6c>] free_buf+0x1a8/0x288
    [<807ea590>] remove_port_data+0x50/0xac
    [<807ea6a0>] unplug_port+0xb4/0x1bc
    [<807ea858>] virtcons_remove+0xb0/0xfc
    [<807b6734>] virtio_dev_remove+0x58/0xc0
    [<807f918c>] __device_release_driver+0xac/0x134
    [<807f924c>] device_release_driver+0x38/0x50
    [<807f7edc>] bus_remove_device+0xfc/0x130
    [<807f4b74>] device_del+0x17c/0x21c
    [<807f4c38>] device_unregister+0x24/0x38
    [<807b6b50>] unregister_virtio_device+0x28/0x44
    
    Fix this by restructuring the loops to allow the locks to only be taken
    where it is necessary to protect the vqs, and release it while the
    buffer is being freed.
    
    Fixes: c6017e793b93 ("virtio: console: add locks around buffer removal in port unplug path")
    Signed-off-by: Matt Redfearn <matt.redfearn@imgtec.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a6cc35756bb9ba093eae6077221e6ff6281d1bc3
Author: Ashok Raj <ashok.raj@intel.com>
Date:   Fri Oct 21 15:32:05 2016 -0700

    iommu/vt-d: Fix IOMMU lookup for SR-IOV Virtual Functions
    
    commit 1c387188c60f53b338c20eee32db055dfe022a9b upstream.
    
    The VT-d specification (§8.3.3) says:
        ‘Virtual Functions’ of a ‘Physical Function’ are under the scope
        of the same remapping unit as the ‘Physical Function’.
    
    The BIOS is not required to list all the possible VFs in the scope
    tables, and arguably *shouldn't* make any attempt to do so, since there
    could be a huge number of them.
    
    This has been broken basically for ever — the VF is never going to match
    against a specific unit's scope, so it ends up being assigned to the
    INCLUDE_ALL IOMMU. Which was always actually correct by coincidence, but
    now we're looking at Root-Complex integrated devices with SR-IOV support
    it's going to start being wrong.
    
    Fix it to simply use pci_physfn() before doing the lookup for PCI devices.
    
    Signed-off-by: Sainath Grandhi <sainath.grandhi@intel.com>
    Signed-off-by: Ashok Raj <ashok.raj@intel.com>
    Signed-off-by: David Woodhouse <dwmw2@infradead.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 37332b5bc488240c7563e689b359001315c5d365
Author: Boris Brezillon <boris.brezillon@free-electrons.com>
Date:   Fri Oct 28 17:12:28 2016 +0200

    m68k: Fix ndelay() macro
    
    commit 7e251bb21ae08ca2e4fb28cc0981fac2685a8efa upstream.
    
    The current ndelay() macro definition has an extra semi-colon at the
    end of the line thus leading to a compilation error when ndelay is used
    in a conditional block without curly braces like this one:
    
            if (cond)
                    ndelay(t);
            else
                    ...
    
    which, after the preprocessor pass gives:
    
            if (cond)
                    m68k_ndelay(t);;
            else
                    ...
    
    thus leading to the following gcc error:
    
            error: 'else' without a previous 'if'
    
    Remove this extra semi-colon.
    
    Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
    Fixes: c8ee038bd1488 ("m68k: Implement ndelay() based on the existing udelay() logic")
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e5f9f9b44eb35d9a014bb816813d54bebd9c86e5
Author: Jack Morgenstein <jackm@dev.mellanox.co.il>
Date:   Thu Oct 27 16:27:21 2016 +0300

    net/mlx4_en: Fix potential deadlock in port statistics flow
    
    commit d2582a03939ed0a80ffcd3ea5345505bc8067c54 upstream.
    
    mlx4_en_DUMP_ETH_STATS took the *counter mutex* and then
    called the FW command, with WRAPPED attribute. As a result, the fw command
    is wrapped on the Hypervisor when it calls mlx4_en_DUMP_ETH_STATS.
    The FW command wrapper flow on the hypervisor takes the *slave_cmd_mutex*
    during processing.
    
    At the same time, a VF could be in the process of coming up, and could
    call mlx4_QUERY_FUNC_CAP.  On the hypervisor, the command flow takes the
    *slave_cmd_mutex*, then executes mlx4_QUERY_FUNC_CAP_wrapper.
    mlx4_QUERY_FUNC_CAP wrapper calls mlx4_get_default_counter_index(),
    which takes the *counter mutex*. DEADLOCK.
    
    The fix is that the DUMP_ETH_STATS fw command should be called with
    the NATIVE attribute, so that on the hypervisor, this command does not
    enter the wrapper flow.
    
    Since the Hypervisor no longer goes through the wrapper code, we also
    simply return 0 in mlx4_DUMP_ETH_STATS_wrapper (i.e.the function succeeds,
    but the returned data will be all zeroes).
    No need to test if it is the Hypervisor going through the wrapper.
    
    Fixes: f9baff509f8a ("mlx4_core: Add "native" argument to mlx4_cmd ...")
    Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
    Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: mlx4_en_DUMP_ETH_STATS() only uses this command once]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 301dc03b1b012012974c3ecd7c941df85ece5b33
Author: Erez Shitrit <erezsh@mellanox.com>
Date:   Thu Oct 27 16:27:17 2016 +0300

    net/mlx4_en: Process all completions in RX rings after port goes up
    
    commit 8d59de8f7bb3db296331c665779c653b0c8d13ba upstream.
    
    Currently there is a race between incoming traffic and
    initialization flow. HW is able to receive the packets
    after INIT_PORT is done and unicast steering is configured.
    Before we set priv->port_up NAPI is not scheduled and
    receive queues become full. Therefore we never get
    new interrupts about the completions.
    This issue could happen if running heavy traffic during
    bringing port up.
    The resolution is to schedule NAPI once port_up is set.
    If receive queues were full this will process all cqes
    and release them.
    
    Fixes: c27a02cd94d6 ("mlx4_en: Add driver for Mellanox ConnectX 10GbE NIC")
    Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
    Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com>
    Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1cdb21d7343760132084a14e062414bba3d2e572
Author: Eugenia Emantayev <eugenia@mellanox.com>
Date:   Thu Oct 27 16:27:16 2016 +0300

    net/mlx4_en: Resolve dividing by zero in 32-bit system
    
    commit 4850cf4581578216468b7b3c3d06cc5abb0a697d upstream.
    
    When doing roundup_pow_of_two for large enough number with
    bit 31, an overflow will occur and a value equal to 1 will
    be returned. In this case 1 will be subtracted from the return
    value and division by zero will be reached.
    
    Fixes: 31c128b66e5b ("net/mlx4_en: Choose time-stamping shift value according to HW frequency")
    Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com>
    Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d0e5f1308da8f303c2021d7b78f8acb4a5f57e30
Author: Jack Morgenstein <jackm@dev.mellanox.co.il>
Date:   Thu Oct 27 16:27:13 2016 +0300

    net/mlx4_core: Fix the resource-type enum in res tracker to conform to FW spec
    
    commit aa0c08feae8161b945520ada753d0dfe62b14fe7 upstream.
    
    The resource type enum in the resource tracker was incorrect.
    RES_EQ was put in the position of RES_NPORT_ID (a FC resource).
    
    Since the remaining resources maintain their current values,
    and RES_EQ is not passed from slaves to the hypervisor in any
    FW command, this change affects only the hypervisor.
    Therefore, there is no backwards-compatibility issue.
    
    Fixes: 623ed84b1f95 ("mlx4_core: initial header-file changes for SRIOV support")
    Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
    Signed-off-by: Moshe Shemesh <moshe@mellanox.com>
    Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a920cb0d89fd74b2cb5a8924e59373e144fb6a07
Author: Willem de Bruijn <willemb@google.com>
Date:   Wed Oct 26 11:23:07 2016 -0400

    packet: on direct_xmit, limit tso and csum to supported devices
    
    commit 104ba78c98808ae837d1f63aae58c183db5505df upstream.
    
    When transmitting on a packet socket with PACKET_VNET_HDR and
    PACKET_QDISC_BYPASS, validate device support for features requested
    in vnet_hdr.
    
    Drop TSO packets sent to devices that do not support TSO or have the
    feature disabled. Note that the latter currently do process those
    packets correctly, regardless of not advertising the feature.
    
    Because of SKB_GSO_DODGY, it is not sufficient to test device features
    with netif_needs_gso. Full validate_xmit_skb is needed.
    
    Switch to software checksum for non-TSO packets that request checksum
    offload if that device feature is unsupported or disabled. Note that
    similar to the TSO case, device drivers may perform checksum offload
    correctly even when not advertising it.
    
    When switching to software checksum, packets hit skb_checksum_help,
    which has two BUG_ON checksum not in linear segment. Packet sockets
    always allocate at least up to csum_start + csum_off + 2 as linear.
    
    Tested by running github.com/wdebruij/kerneltools/psock_txring_vnet.c
    
      ethtool -K eth0 tso off tx on
      psock_txring_vnet -d $dst -s $src -i eth0 -l 2000 -n 1 -q -v
      psock_txring_vnet -d $dst -s $src -i eth0 -l 2000 -n 1 -q -v -N
    
      ethtool -K eth0 tx off
      psock_txring_vnet -d $dst -s $src -i eth0 -l 1000 -n 1 -q -v -G
      psock_txring_vnet -d $dst -s $src -i eth0 -l 1000 -n 1 -q -v -G -N
    
    v2:
      - add EXPORT_SYMBOL_GPL(validate_xmit_skb_list)
    
    Fixes: d346a3fae3ff ("packet: introduce PACKET_QDISC_BYPASS socket option")
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: open-code the necessary checks as we don't have
     validate_xmit_skb_list()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e03e406c240a4f9d5f8dadb68f6c8884e8d0b902
Author: Noa Osherovich <noaos@mellanox.com>
Date:   Tue Oct 25 18:36:35 2016 +0300

    net/mlx5: Avoid passing dma address 0 to firmware
    
    commit 6b276190c50a12511d889d9079ffb901ff94a822 upstream.
    
    Currently the firmware can't work with a page with dma address 0.
    Passing such an address to the firmware will cause the give_pages
    command to fail.
    
    To avoid this, in case we get a 0 dma address of a page from the
    dma engine, we avoid passing it to FW by remapping to get an address
    other than 0.
    
    Fixes: bf0bf77f6519 ('mlx5: Support communicating arbitrary host...')
    Signed-off-by: Noa Osherovich <noaos@mellanox.com>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d1f472daaa80d8afdd7cdcdfb8f48e7a99223194
Author: NeilBrown <neilb@suse.com>
Date:   Fri Oct 28 15:59:41 2016 +1100

    md: be careful not lot leak internal curr_resync value into metadata. -- (all)
    
    commit 1217e1d1999ed6c9c1e1b1acae0a74ab70464ae2 upstream.
    
    mddev->curr_resync usually records where the current resync is up to,
    but during the starting phase it has some "magic" values.
    
     1 - means that the array is trying to start a resync, but has yielded
         to another array which shares physical devices, and also needs to
         start a resync
     2 - means the array is trying to start resync, but has found another
         array which shares physical devices and has already started resync.
    
     3 - means that resync has commensed, but it is possible that nothing
         has actually been resynced yet.
    
    It is important that this value not be visible to user-space and
    particularly that it doesn't get written to the metadata, as the
    resync or recovery checkpoint.  In part, this is because it may be
    slightly higher than the correct value, though this is very rare.
    In part, because it is not a multiple of 4K, and some devices only
    support 4K aligned accesses.
    
    There are two places where this value is propagates into either
    ->curr_resync_completed or ->recovery_cp or ->recovery_offset.
    These currently avoid the propagation of values 1 and 3, but will
    allow 3 to leak through.
    
    Change them to only propagate the value if it is > 3.
    
    As this can cause an array to fail, the patch is suitable for -stable.
    
    Reported-by: Viswesh <viswesh.vichu@gmail.com>
    Signed-off-by: NeilBrown <neilb@suse.com>
    Signed-off-by: Shaohua Li <shli@fb.com>
    [bwh: Backported to 3.16: there is only one comparison to fix]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit dba8e88e9827d87f1210c8ae392542508aecbd13
Author: Richard Weinberger <richard@nod.at>
Date:   Fri Oct 28 11:49:03 2016 +0200

    ubifs: Fix regression in ubifs_readdir()
    
    commit a00052a296e54205cf238c75bd98d17d5d02a6db upstream.
    
    Commit c83ed4c9dbb35 ("ubifs: Abort readdir upon error") broke
    overlayfs support because the fix exposed an internal error
    code to VFS.
    
    Reported-by: Peter Rosin <peda@axentia.se>
    Tested-by: Peter Rosin <peda@axentia.se>
    Reported-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
    Tested-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
    Fixes: c83ed4c9dbb35 ("ubifs: Abort readdir upon error")
    Signed-off-by: Richard Weinberger <richard@nod.at>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 192d5e7c1ccfe5c6391bfc7090d28204a95984bd
Author: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Date:   Wed Oct 19 12:29:41 2016 +0200

    GenWQE: Fix bad page access during abort of resource allocation
    
    commit a7a7aeefbca2982586ba2c9fd7739b96416a6d1d upstream.
    
    When interrupting an application which was allocating DMAable
    memory, it was possible, that the DMA memory was deallocated
    twice, leading to the error symptoms below.
    
    Thanks to Gerald, who analyzed the problem and provided this
    patch.
    
    I agree with his analysis of the problem: ddcb_cmd_fixups() ->
    genwqe_alloc_sync_sgl() (fails in f/lpage, but sgl->sgl != NULL
    and f/lpage maybe also != NULL) -> ddcb_cmd_cleanup() ->
    genwqe_free_sync_sgl() (double free, because sgl->sgl != NULL and
    f/lpage maybe also != NULL)
    
    In this scenario we would have exactly the kind of double free that
    would explain the WARNING / Bad page state, and as expected it is
    caused by broken error handling (cleanup).
    
    Using the Ubuntu git source, tag Ubuntu-4.4.0-33.52, he was able to reproduce
    the "Bad page state" issue, and with the patch on top he could not reproduce
    it any more.
    
    ------------[ cut here ]------------
    WARNING: at /build/linux-o03cxz/linux-4.4.0/arch/s390/include/asm/pci_dma.h:141
    Modules linked in: qeth_l2 ghash_s390 prng aes_s390 des_s390 des_generic sha512_s390 sha256_s390 sha1_s390 sha_common genwqe_card qeth crc_itu_t qdio ccwgroup vmur dm_multipath dasd_eckd_mod dasd_mod
    CPU: 2 PID: 3293 Comm: genwqe_gunzip Not tainted 4.4.0-33-generic #52-Ubuntu
    task: 0000000032c7e270 ti: 00000000324e4000 task.ti: 00000000324e4000
    Krnl PSW : 0404c00180000000 0000000000156346 (dma_update_cpu_trans+0x9e/0xa8)
               R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3
    Krnl GPRS: 00000000324e7bcd 0000000000c3c34a 0000000027628298 000000003215b400
               0000000000000400 0000000000001fff 0000000000000400 0000000116853000
               07000000324e7b1e 0000000000000001 0000000000000001 0000000000000001
               0000000000001000 0000000116854000 0000000000156402 00000000324e7a38
    Krnl Code: 000000000015633a: 95001000           cli     0(%r1),0
               000000000015633e: a774ffc3           brc     7,1562c4
              #0000000000156342: a7f40001           brc     15,156344
              >0000000000156346: 92011000           mvi     0(%r1),1
               000000000015634a: a7f4ffbd           brc     15,1562c4
               000000000015634e: 0707               bcr     0,%r7
               0000000000156350: c00400000000       brcl    0,156350
               0000000000156356: eb7ff0500024       stmg    %r7,%r15,80(%r15)
    Call Trace:
    ([<00000000001563e0>] dma_update_trans+0x90/0x228)
     [<00000000001565dc>] s390_dma_unmap_pages+0x64/0x160
     [<00000000001567c2>] s390_dma_free+0x62/0x98
     [<000003ff801310ce>] __genwqe_free_consistent+0x56/0x70 [genwqe_card]
     [<000003ff801316d0>] genwqe_free_sync_sgl+0xf8/0x160 [genwqe_card]
     [<000003ff8012bd6e>] ddcb_cmd_cleanup+0x86/0xa8 [genwqe_card]
     [<000003ff8012c1c0>] do_execute_ddcb+0x110/0x348 [genwqe_card]
     [<000003ff8012c914>] genwqe_ioctl+0x51c/0xc20 [genwqe_card]
     [<000000000032513a>] do_vfs_ioctl+0x3b2/0x518
     [<0000000000325344>] SyS_ioctl+0xa4/0xb8
     [<00000000007b86c6>] system_call+0xd6/0x264
     [<000003ff9e8e520a>] 0x3ff9e8e520a
    Last Breaking-Event-Address:
     [<0000000000156342>] dma_update_cpu_trans+0x9a/0xa8
    ---[ end trace 35996336235145c8 ]---
    BUG: Bad page state in process jbd2/dasdb1-8  pfn:3215b
    page:000003d100c856c0 count:-1 mapcount:0 mapping:          (null) index:0x0
    flags: 0x3fffc0000000000()
    page dumped because: nonzero _count
    
    Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
    Signed-off-by: Frank Haverkamp <haver@linux.vnet.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9ba74d1ab65075babe1dabaf527ed92d2eb74233
Author: Ido Yariv <ido@wizery.com>
Date:   Fri Oct 21 12:39:57 2016 -0400

    KVM: x86: fix wbinvd_dirty_mask use-after-free
    
    commit bd768e146624cbec7122ed15dead8daa137d909d upstream.
    
    vcpu->arch.wbinvd_dirty_mask may still be used after freeing it,
    corrupting memory. For example, the following call trace may set a bit
    in an already freed cpu mask:
        kvm_arch_vcpu_load
        vcpu_load
        vmx_free_vcpu_nested
        vmx_free_vcpu
        kvm_arch_vcpu_free
    
    Fix this by deferring freeing of wbinvd_dirty_mask.
    
    Signed-off-by: Ido Yariv <ido@wizery.com>
    Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b31d60e114f1188537b15f72622de2c118885fe4
Author: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Date:   Tue Oct 25 16:24:28 2016 +0200

    s390/hypfs: Use get_free_page() instead of kmalloc to ensure page alignment
    
    commit 237d6e6884136923b6bd26d5141ebe1d065960c9 upstream.
    
    Since commit d86bd1bece6f ("mm/slub: support left redzone") it is no longer
    guaranteed that kmalloc(PAGE_SIZE) returns page aligned memory.
    
    After the above commit we get an error for diag224 because aligned
    memory is required. This leads to the following user visible error:
    
     # mount none -t s390_hypfs /sys/hypervisor/
     mount: unknown filesystem type 's390_hypfs'
    
     # dmesg | grep hypfs
     hypfs.cccfb8: The hardware system does not provide all functions
                   required by hypfs
     hypfs.7a79f0: Initialization of hypfs failed with rc=-61
    
    Fix this problem and use get_free_page() instead of kmalloc() to get
    correctly aligned memory.
    
    Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2c1a5759282f8c8650a600587091e00e52942eed
Author: Daniel Mentz <danielmentz@google.com>
Date:   Thu Oct 27 17:46:59 2016 -0700

    lib/genalloc.c: start search from start of chunk
    
    commit 62e931fac45b17c2a42549389879411572f75804 upstream.
    
    gen_pool_alloc_algo() iterates over the chunks of a pool trying to find
    a contiguous block of memory that satisfies the allocation request.
    
    The shortcut
    
            if (size > atomic_read(&chunk->avail))
                    continue;
    
    makes the loop skip over chunks that do not have enough bytes left to
    fulfill the request.  There are two situations, though, where an
    allocation might still fail:
    
    (1) The available memory is not contiguous, i.e.  the request cannot
        be fulfilled due to external fragmentation.
    
    (2) A race condition.  Another thread runs the same code concurrently
        and is quicker to grab the available memory.
    
    In those situations, the loop calls pool->algo() to search the entire
    chunk, and pool->algo() returns some value that is >= end_bit to
    indicate that the search failed.  This return value is then assigned to
    start_bit.  The variables start_bit and end_bit describe the range that
    should be searched, and this range should be reset for every chunk that
    is searched.  Today, the code fails to reset start_bit to 0.  As a
    result, prefixes of subsequent chunks are ignored.  Memory allocations
    might fail even though there is plenty of room left in these prefixes of
    those other chunks.
    
    Fixes: 7f184275aa30 ("lib, Make gen_pool memory allocator lockless")
    Link: http://lkml.kernel.org/r/1477420604-28918-1-git-send-email-danielmentz@google.com
    Signed-off-by: Daniel Mentz <danielmentz@google.com>
    Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Acked-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f86f1bbd61797f5f26d66382776e0e727c7f9ae3
Author: Chris Mason <clm@fb.com>
Date:   Thu Oct 27 10:42:20 2016 -0700

    btrfs: fix races on root_log_ctx lists
    
    commit 570dd45042a7c8a7aba1ee029c5dd0f5ccf41b9b upstream.
    
    btrfs_remove_all_log_ctxs takes a shortcut where it avoids walking the
    list because it knows all of the waiters are patiently waiting for the
    commit to finish.
    
    But, there's a small race where btrfs_sync_log can remove itself from
    the list if it finds a log commit is already done.  Also, it uses
    list_del_init() to remove itself from the list, but there's no way to
    know if btrfs_remove_all_log_ctxs has already run, so we don't know for
    sure if it is safe to call list_del_init().
    
    This gets rid of all the shortcuts for btrfs_remove_all_log_ctxs(), and
    just calls it with the proper locking.
    
    This is part two of the corruption fixed by cbd60aa7cd1.  I should have
    done this in the first place, but convinced myself the optimizations were
    safe.  A 12 hour run of dbench 2048 will eventually trigger a list debug
    WARN_ON for the list_del_init() in btrfs_sync_log().
    
    Fixes: d1433debe7f4346cf9fc0dafc71c3137d2a97bc4
    Reported-by: Dave Jones <davej@codemonkey.org.uk>
    Signed-off-by: Chris Mason <clm@fb.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 768071f432eee4448a1c064a2032e9c58830c748
Author: John W. Linville <linville@tuxdriver.com>
Date:   Tue Oct 25 15:56:39 2016 -0400

    netfilter: nf_tables: fix type mismatch with error return from nft_parse_u32_check
    
    commit f1d505bb762e30bf316ff5d3b604914649d6aed3 upstream.
    
    Commit 36b701fae12ac ("netfilter: nf_tables: validate maximum value of
    u32 netlink attributes") introduced nft_parse_u32_check with a return
    value of "unsigned int", yet on error it returns "-ERANGE".
    
    This patch corrects the mismatch by changing the return value to "int",
    which happens to match the actual users of nft_parse_u32_check already.
    
    Found by Coverity, CID 1373930.
    
    Note that commit 21a9e0f1568ea ("netfilter: nft_exthdr: fix error
    handling in nft_exthdr_init()) attempted to address the issue, but
    did not address the return type of nft_parse_u32_check.
    
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Cc: Laura Garcia Liebana <nevola@gmail.com>
    Cc: Pablo Neira Ayuso <pablo@netfilter.org>
    Cc: Dan Carpenter <dan.carpenter@oracle.com>
    Fixes: 36b701fae12ac ("netfilter: nf_tables: validate maximum value...")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e01234be2260e1fc9d14328989fc483051dfc56f
Author: Ulrich Weber <ulrich.weber@riverbed.com>
Date:   Mon Oct 24 18:07:23 2016 +0200

    netfilter: nf_conntrack_sip: extend request line validation
    
    commit 444f901742d054a4cd5ff045871eac5131646cfb upstream.
    
    on SIP requests, so a fragmented TCP SIP packet from an allow header starting with
     INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE
     Content-Length: 0
    
    will not bet interpreted as an INVITE request. Also Request-URI must start with an alphabetic character.
    
    Confirm with RFC 3261
     Request-Line   =  Method SP Request-URI SP SIP-Version CRLF
    
    Fixes: 30f33e6dee80 ("[NETFILTER]: nf_conntrack_sip: support method specific request/response handling")
    Signed-off-by: Ulrich Weber <ulrich.weber@riverbed.com>
    Acked-by: Marco Angaroni <marcoangaroni@gmail.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit dbc3fd44f957a39407e889287bf61fa0ef3ecc14
Author: Scot Doyle <lkml14@scotdoyle.com>
Date:   Thu Oct 13 12:12:43 2016 -0500

    vt: clear selection before resizing
    
    commit 009e39ae44f4191188aeb6dfbf661b771dbbe515 upstream.
    
    When resizing a vt its selection may exceed the new size, resulting in
    an invalid memory access [1]. Clear the selection before resizing.
    
    [1] http://lkml.kernel.org/r/CACT4Y+acDTwy4umEvf5ROBGiRJNrxHN4Cn5szCXE5Jw-d1B=Xw@mail.gmail.com
    
    Reported-and-tested-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Scot Doyle <lkml14@scotdoyle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 35bb12d75a5c8e9c6b4892f43f8d28c6c27f3bc0
Author: Dmitry Vyukov <dvyukov@google.com>
Date:   Fri Oct 14 15:18:28 2016 +0200

    tty: limit terminal size to 4M chars
    
    commit 32b2921e6a7461fe63b71217067a6cf4bddb132f upstream.
    
    Size of kmalloc() in vc_do_resize() is controlled by user.
    Too large kmalloc() size triggers WARNING message on console.
    Put a reasonable upper bound on terminal size to prevent WARNINGs.
    
    Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
    CC: David Rientjes <rientjes@google.com>
    Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Jiri Slaby <jslaby@suse.com>
    Cc: Peter Hurley <peter@hurleysoftware.com>
    Cc: linux-kernel@vger.kernel.org
    Cc: syzkaller@googlegroups.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c7bd359b369c1d0c6ccd35bfb723d650c0c44f0e
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Mon Oct 3 11:00:17 2016 +0200

    tty: vt, fix bogus division in csi_J
    
    commit 42acfc6615f47e465731c263bee0c799edb098f2 upstream.
    
    In csi_J(3), the third parameter of scr_memsetw (vc_screenbuf_size) is
    divided by 2 inappropriatelly. But scr_memsetw expects size, not
    count, because it divides the size by 2 on its own before doing actual
    memset-by-words.
    
    So remove the bogus division.
    
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Cc: Petr Písař <ppisar@redhat.com>
    Fixes: f8df13e0a9 (tty: Clean console safely)
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit cb3c092e52f10778ef6e8ccd700a1271b6d0d965
Author: Marcel Hasler <mahasler@gmail.com>
Date:   Thu Oct 27 00:42:27 2016 +0200

    ALSA: usb-audio: Add quirk for Syntek STK1160
    
    commit bdc3478f90cd4d2928197f36629d5cf93b64dbe9 upstream.
    
    The stk1160 chip needs QUIRK_AUDIO_ALIGN_TRANSFER. This patch resolves
    the issue reported on the mailing list
    (http://marc.info/?l=linux-sound&m=139223599126215&w=2) and also fixes
    bug 180071 (https://bugzilla.kernel.org/show_bug.cgi?id=180071).
    
    Signed-off-by: Marcel Hasler <mahasler@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 493f26f5d24b665c3c5fb727fdee2fbab970cf30
Author: Ching Huang <ching2048@areca.com.tw>
Date:   Wed Oct 19 17:50:26 2016 +0800

    scsi: arcmsr: Send SYNCHRONIZE_CACHE command to firmware
    
    commit 2bf7dc8443e113844d078fd6541b7f4aa544f92f upstream.
    
    The arcmsr driver failed to pass SYNCHRONIZE CACHE to controller
    firmware. Depending on how drive caches are handled internally by
    controller firmware this could potentially lead to data integrity
    problems.
    
    Ensure that cache flushes are passed to the controller.
    
    [mkp: applied by hand and removed unused vars]
    
    Signed-off-by: Ching Huang <ching2048@areca.com.tw>
    Reported-by: Tomas Henzl <thenzl@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 58bcbdf5b617129e476d883d4ddb69516b6ad19d
Author: Ewan D. Milne <emilne@redhat.com>
Date:   Wed Oct 26 11:22:53 2016 -0400

    scsi: scsi_debug: Fix memory leak if LBP enabled and module is unloaded
    
    commit 4d2b496f19f3c2cfaca1e8fa0710688b5ff3811d upstream.
    
    map_storep was not being vfree()'d in the module_exit call.
    
    Signed-off-by: Ewan D. Milne <emilne@redhat.com>
    Reviewed-by: Laurence Oberman <loberman@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ed3c533a3b67cfd13a82ed26b2344d3aa3a15a3a
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Oct 14 16:38:02 2016 -0400

    drm/radeon/si_dpm: workaround for SI kickers
    
    commit 7dc86ef5ac91642dfc3eb93ee0f0458e702a343e upstream.
    
    Consolidate existing quirks. Fixes stability issues
    on some kickers.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e840e9340be4ec163fefe53981e57d703d6f40cd
Author: James Hogan <james.hogan@imgtec.com>
Date:   Tue Oct 25 16:11:12 2016 +0100

    KVM: MIPS: Precalculate MMIO load resume PC
    
    commit e1e575f6b026734be3b1f075e780e91ab08ca541 upstream.
    
    The advancing of the PC when completing an MMIO load is done before
    re-entering the guest, i.e. before restoring the guest ASID. However if
    the load is in a branch delay slot it may need to access guest code to
    read the prior branch instruction. This isn't safe in TLB mapped code at
    the moment, nor in the future when we'll access unmapped guest segments
    using direct user accessors too, as it could read the branch from host
    user memory instead.
    
    Therefore calculate the resume PC in advance while we're still in the
    right context and save it in the new vcpu->arch.io_pc (replacing the no
    longer needed vcpu->arch.pending_load_cause), and restore it on MMIO
    completion.
    
    Fixes: e685c689f3a8 ("KVM/MIPS32: Privileged instruction/target branch emulation.")
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: "Radim Krčmář <rkrcmar@redhat.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: linux-mips@linux-mips.org
    Cc: kvm@vger.kernel.org
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    [bwh: Backported to 3.16: adjust filename, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 61b547833ce0c9574549cc0e7143227c74706a5b
Author: Nicholas Mc Guire <hofrat@osadl.org>
Date:   Fri May 8 17:38:52 2015 +0200

    MIPS: KVM: Fix unused variable build warning
    
    commit 5f508c43a7648baa892528922402f1e13f258bd4 upstream.
    
    As kvm_mips_complete_mmio_load() did not yet modify PC at this point
    as James Hogans <james.hogan@imgtec.com> explained the curr_pc variable
    and the comments along with it can be dropped.
    
    Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
    Link: http://lkml.org/lkml/2015/5/8/422
    Cc: Gleb Natapov <gleb@kernel.org>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: James Hogan <james.hogan@imgtec.com>
    Cc: kvm@vger.kernel.org
    Cc: linux-mips@linux-mips.org
    Cc: linux-kernel@vger.kernel.org
    Patchwork: https://patchwork.linux-mips.org/patch/9993/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    [bwh: Backported to 3.16: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 77b0cff55b05c1bf44205111912958ab0f88f65b
Author: James Hogan <james.hogan@imgtec.com>
Date:   Tue Oct 25 16:11:11 2016 +0100

    KVM: MIPS: Make ERET handle ERL before EXL
    
    commit ede5f3e7b54a4347be4d8525269eae50902bd7cd upstream.
    
    The ERET instruction to return from exception is used for returning from
    exception level (Status.EXL) and error level (Status.ERL). If both bits
    are set however we should be returning from ERL first, as ERL can
    interrupt EXL, for example when an NMI is taken. KVM however checks EXL
    first.
    
    Fix the order of the checks to match the pseudocode in the instruction
    set manual.
    
    Fixes: e685c689f3a8 ("KVM/MIPS32: Privileged instruction/target branch emulation.")
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: "Radim Krčmář <rkrcmar@redhat.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: linux-mips@linux-mips.org
    Cc: kvm@vger.kernel.org
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    [bwh: Backported to 3.16: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 65573ae3d0341f8317a0db9cc933f1e90c83fb30
Author: Lucas Stach <dev@lynxeye.de>
Date:   Mon Oct 24 23:32:04 2016 +0200

    drm/radeon: drop register readback in cayman_cp_int_cntl_setup
    
    commit 537b4b462caa8bfb9726d9695b8e56e2d5e6b41e upstream.
    
    The read is taking a considerable amount of time (about 50us on this
    machine). The register does not ever hold anything other than the ring
    ID that is updated in this exact function, so there is no need for
    the read modify write cycle.
    
    This chops off a big chunk of the time spent in hardirq disabled
    context, as this function is called multiple times in the interrupt
    handler. With this change applied radeon won't show up in the list
    of the worst IRQ latency offenders anymore, where it was a regular
    before.
    
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Lucas Stach <dev@lynxeye.de>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fbcdcf9cb658d2cad18d629f2c5059adcee12a44
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Oct 24 17:22:01 2016 +0200

    staging: iio: ad5933: avoid uninitialized variable in error case
    
    commit 34eee70a7b82b09dbda4cb453e0e21d460dae226 upstream.
    
    The ad5933_i2c_read function returns an error code to indicate
    whether it could read data or not. However ad5933_work() ignores
    this return code and just accesses the data unconditionally,
    which gets detected by gcc as a possible bug:
    
    drivers/staging/iio/impedance-analyzer/ad5933.c: In function 'ad5933_work':
    drivers/staging/iio/impedance-analyzer/ad5933.c:649:16: warning: 'status' may be used uninitialized in this function [-Wmaybe-uninitialized]
    
    This adds minimal error handling so we only evaluate the
    data if it was correctly read.
    
    Link: https://patchwork.kernel.org/patch/8110281/
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 84e01e65c88090a49f5fc20ed7a148e7f10c1ded
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Oct 20 12:14:51 2016 +0200

    ALSA: hda - Fix surround output pins for ASRock B150M mobo
    
    commit 1a3f099101b85cc93d864eb030d97e7725c72ea7 upstream.
    
    ASRock B150M Pro4/D3 mobo with ALC892 codec doesn't seem to provide
    proper pins for the surround outputs, hence we need to specify the
    pincfgs manually with a couple of other corrections.
    
    Reported-and-tested-by: Benjamin Valentin <benpicco@googlemail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f4a001cea6abab0ef37742927e2fca3d6953df72
Author: Long Li <longli@microsoft.com>
Date:   Wed Oct 5 16:57:46 2016 -0700

    hv: do not lose pending heartbeat vmbus packets
    
    commit 407a3aee6ee2d2cb46d9ba3fc380bc29f35d020c upstream.
    
    The host keeps sending heartbeat packets independent of the
    guest responding to them.  Even though we respond to the heartbeat messages at
    interrupt level, we can have situations where there maybe multiple heartbeat
    messages pending that have not been responded to. For instance this occurs when the
    VM is paused and the host continues to send the heartbeat messages.
    Address this issue by draining and responding to all
    the heartbeat messages that maybe pending.
    
    Signed-off-by: Long Li <longli@microsoft.com>
    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1ee24cf8904d9553e785c71889468a1c80d1a75d
Author: Kashyap Desai <kashyap.desai@broadcom.com>
Date:   Fri Oct 21 06:33:32 2016 -0700

    scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough) devices
    
    commit 1e793f6fc0db920400574211c48f9157a37e3945 upstream.
    
    Commit 02b01e010afe ("megaraid_sas: return sync cache call with
    success") modified the driver to successfully complete SYNCHRONIZE_CACHE
    commands without passing them to the controller. Disk drive caches are
    only explicitly managed by controller firmware when operating in RAID
    mode. So this commit effectively disabled writeback cache flushing for
    any drives used in JBOD mode, leading to data integrity failures.
    
    [mkp: clarified patch description]
    
    Fixes: 02b01e010afeeb49328d35650d70721d2ca3fd59
    Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com>
    Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
    Reviewed-by: Tomas Henzl <thenzl@redhat.com>
    Reviewed-by: Hannes Reinecke <hare@suse.com>
    Reviewed-by: Ewan D. Milne <emilne@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 47e1befd550ccacf735afb640d17cf55e4d4b8ec
Author: Alexander Usyskin <alexander.usyskin@intel.com>
Date:   Wed Oct 19 01:34:48 2016 +0300

    mei: txe: don't clean an unprocessed interrupt cause.
    
    commit 43605e293eb13c07acb546c14f407a271837af17 upstream.
    
    SEC registers are not accessible when the TXE device is in low power
    state, hence the SEC interrupt cannot be processed if device is not
    awake.
    
    In some rare cases entrance to low power state (aliveness off) and input
    ready bits can be signaled at the same time, resulting in communication
    stall as input ready won't be signaled again after waking up. To resolve
    this IPC_HHIER_SEC bit in HHISR_REG should not be cleaned if the
    interrupt is not processed.
    
    Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
    Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2992aceed9a9d3ad2755e7b8e26fd25ddc984712
Author: tang.junhui <tang.junhui@zte.com.cn>
Date:   Fri Oct 21 09:35:32 2016 +0800

    dm table: fix missing dm_put_target_type() in dm_table_add_target()
    
    commit dafa724bf582181d9a7d54f5cb4ca0bf8ef29269 upstream.
    
    dm_get_target_type() was previously called so any error returned from
    dm_table_add_target() must first call dm_put_target_type().  Otherwise
    the DM target module's reference count will leak and the associated
    kernel module will be unable to be removed.
    
    Also, leverage the fact that r is already -EINVAL and remove an extra
    newline.
    
    Fixes: 36a0456 ("dm table: add immutable feature")
    Fixes: cc6cbe1 ("dm table: add always writeable feature")
    Fixes: 3791e2f ("dm table: add singleton feature")
    Signed-off-by: tang.junhui <tang.junhui@zte.com.cn>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    [bwh: Backported to 3.16: adjuat context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0472b28bcde40b44cb802c02a1a8aa5996927d05
Author: Punit Agrawal <punit.agrawal@arm.com>
Date:   Tue Oct 18 17:07:19 2016 +0100

    ACPI / APEI: Fix incorrect return value of ghes_proc()
    
    commit 806487a8fc8f385af75ed261e9ab658fc845e633 upstream.
    
    Although ghes_proc() tests for errors while reading the error status,
    it always return success (0). Fix this by propagating the return
    value.
    
    Fixes: d334a49113a4a33 (ACPI, APEI, Generic Hardware Error Source memory error support)
    Signed-of-by: Punit Agrawal <punit.agrawa.@arm.com>
    Tested-by: Tyler Baicar <tbaicar@codeaurora.org>
    Reviewed-by: Borislav Petkov <bp@suse.de>
    [ rjw: Subject ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 95e6876830ab18697bb4d59f2dbf5274490d4201
Author: WANG Cong <xiyou.wangcong@gmail.com>
Date:   Thu Oct 20 14:19:46 2016 -0700

    ipv4: use the right lock for ping_group_range
    
    commit 396a30cce15d084b2b1a395aa6d515c3d559c674 upstream.
    
    This reverts commit a681574c99be23e4d20b769bf0e543239c364af5
    ("ipv4: disable BH in set_ping_group_range()") because we never
    read ping_group_range in BH context (unlike local_port_range).
    
    Then, since we already have a lock for ping_group_range, those
    using ip_local_ports.lock for ping_group_range are clearly typos.
    
    We might consider to share a same lock for both ping_group_range
    and local_port_range w.r.t. space saving, but that should be for
    net-next.
    
    Fixes: a681574c99be ("ipv4: disable BH in set_ping_group_range()")
    Fixes: ba6b918ab234 ("ping: move ping_group_range out of CONFIG_SYSCTL")
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Eric Salo <salo@google.com>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: we never applied "ipv4: disable BH in
      set_ping_group_range()"]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bfdc3cea6b01ef937e6aed447bc7130a393d9428
Author: Segher Boessenkool <segher@kernel.crashing.org>
Date:   Thu Oct 6 13:42:19 2016 +0000

    powerpc: Convert cmp to cmpd in idle enter sequence
    
    commit 80f23935cadb1c654e81951f5a8b7ceae0acc1b4 upstream.
    
    PowerPC's "cmp" instruction has four operands. Normally people write
    "cmpw" or "cmpd" for the second cmp operand 0 or 1. But, frequently
    people forget, and write "cmp" with just three operands.
    
    With older binutils this is silently accepted as if this was "cmpw",
    while often "cmpd" is wanted. With newer binutils GAS will complain
    about this for 64-bit code. For 32-bit code it still silently assumes
    "cmpw" is what is meant.
    
    In this instance the code comes directly from ISA v2.07, including the
    cmp, but cmpd is correct. Backport to stable so that new toolchains can
    build old kernels.
    
    Fixes: 948cf67c4726 ("powerpc: Add NAP mode support on Power7 in HV mode")
    Reviewed-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
    Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    [bwh: Backported to 3.16: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fc39a7bceec4a65f8e8f613d86d0737db46ff0dd
Author: Will Deacon <will.deacon@arm.com>
Date:   Thu Sep 29 12:37:01 2016 +0100

    arm64: KVM: Take S1 walks into account when determining S2 write faults
    
    commit 60e21a0ef54cd836b9eb22c7cb396989b5b11648 upstream.
    
    The WnR bit in the HSR/ESR_EL2 indicates whether a data abort was
    generated by a read or a write instruction. For stage 2 data aborts
    generated by a stage 1 translation table walk (i.e. the actual page
    table access faults at EL2), the WnR bit therefore reports whether the
    instruction generating the walk was a load or a store, *not* whether the
    page table walker was reading or writing the entry.
    
    For page tables marked as read-only at stage 2 (e.g. due to KSM merging
    them with the tables from another guest), this could result in livelock,
    where a page table walk generated by a load instruction attempts to
    set the access flag in the stage 1 descriptor, but fails to trigger
    CoW in the host since only a read fault is reported.
    
    This patch modifies the arm64 kvm_vcpu_dabt_iswrite function to
    take into account stage 2 faults in stage 1 walks. Since DBM cannot be
    disabled at EL2 for CPUs that implement it, we assume that these faults
    are always causes by writes, avoiding the livelock situation at the
    expense of occasional, spurious CoWs.
    
    We could, in theory, do a bit better by checking the guest TCR
    configuration and inspecting the page table to see why the PTE faulted.
    However, I doubt this is measurable in practice, and the threat of
    livelock is real.
    
    Cc: Julien Grall <julien.grall@arm.com>
    Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
    Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    [bwh: Backported to 3.16:
     - Keep using ESR_EL2_WNR in the first part of the condition
     - Adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 11db0f5767306c1cffba1041e6a818b2570ac04d
Author: Tom St Denis <tom.stdenis@amd.com>
Date:   Thu Oct 13 12:38:07 2016 -0400

    drm/radeon/si_dpm: Limit clocks on HD86xx part
    
    commit fb9a5b0c1c9893db2e0d18544fd49e19d784a87d upstream.
    
    Limit clocks on a specific HD86xx part to avoid
    crashes (while awaiting an appropriate PP fix).
    
    Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4d43ed19a85d346c77811f074ecb93a78da0a1f5
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Oct 21 12:56:27 2016 +0200

    USB: serial: fix potential NULL-dereference at probe
    
    commit 126d26f66d9890a69158812a6caa248c05359daa upstream.
    
    Make sure we have at least one port before attempting to register a
    console.
    
    Currently, at least one driver binds to a "dummy" interface and requests
    zero ports for it. Should such an interface also lack endpoints, we get
    a NULL-deref during probe.
    
    Fixes: e5b1e2062e05 ("USB: serial: make minor allocation dynamic")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 83ad37772a017287cf5fb8e9573dab5e2cb6b6d2
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Thu Oct 20 18:09:19 2016 +0300

    xhci: workaround for hosts missing CAS bit
    
    commit 346e99736c3ce328fd42d678343b70243aca5f36 upstream.
    
    If a device is unplugged and replugged during Sx system suspend
    some  Intel xHC hosts will overwrite the CAS (Cold attach status) flag
    and no device connection is noticed in resume.
    
    A device in this state can be identified in resume if its link state
    is in polling or compliance mode, and the current connect status is 0.
    A device in this state needs to be warm reset.
    
    Intel 100/c230 series PCH specification update Doc #332692-006 Errata #8
    
    Observed on Cherryview and Apollolake as they go into compliance mode
    if LFPS times out during polling, and re-plugged devices are not
    discovered at resume.
    
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 34f9fb3ce5901020481e3ca3e16b6c482c18a147
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Thu Oct 20 18:09:18 2016 +0300

    xhci: add restart quirk for Intel Wildcatpoint PCH
    
    commit 4c39135aa412d2f1381e43802523da110ca7855c upstream.
    
    xHC in Wildcatpoint-LP PCH is similar to LynxPoint-LP and need the
    same quirks to prevent machines from spurious restart while
    shutting them down.
    
    Reported-by: Hasan Mahmood <hasan.mahm@gmail.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c0186ef8523f8d19afcec0d5be1754c71e3ca5fd
Author: Dinesh Israni <ddi@datera.io>
Date:   Mon Oct 10 20:22:03 2016 -0700

    target: Don't override EXTENDED_COPY xcopy_pt_cmd SCSI status code
    
    commit 926317de33998c112c5510301868ea9aa34097e2 upstream.
    
    This patch addresses a bug where a local EXTENDED_COPY WRITE or READ
    backend I/O request would always return SAM_STAT_CHECK_CONDITION,
    even if underlying xcopy_pt_cmd->se_cmd generated a different
    SCSI status code.
    
    ESX host environments expect to hit SAM_STAT_RESERVATION_CONFLICT
    for certain scenarios, and SAM_STAT_CHECK_CONDITION results in
    non-retriable status for these cases.
    
    Tested on v4.1.y with ESX v5.5u2+ with local IBLOCK backend copy.
    
    Reported-by: Nixon Vincent <nixon.vincent@calsoftinc.com>
    Tested-by: Nixon Vincent <nixon.vincent@calsoftinc.com>
    Cc: Nixon Vincent <nixon.vincent@calsoftinc.com>
    Tested-by: Dinesh Israni <ddi@datera.io>
    Signed-off-by: Dinesh Israni <ddi@datera.io>
    Cc: Dinesh Israni <ddi@datera.io>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 279a47ee31bc58e0f7965eb884e70feaafee7078
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Sat Oct 8 17:26:44 2016 -0700

    target: Make EXTENDED_COPY 0xe4 failure return COPY TARGET DEVICE NOT REACHABLE
    
    commit 449a137846c84829a328757cd21fd9ca65c08519 upstream.
    
    This patch addresses a bug where EXTENDED_COPY across multiple LUNs
    results in a CHECK_CONDITION when the source + destination are not
    located on the same physical node.
    
    ESX Host environments expect sense COPY_ABORTED w/ COPY TARGET DEVICE
    NOT REACHABLE to be returned when this occurs, in order to signal
    fallback to local copy method.
    
    As described in section 6.3.3 of spc4r22:
    
      "If it is not possible to complete processing of a segment because the
       copy manager is unable to establish communications with a copy target
       device, because the copy target device does not respond to INQUIRY,
       or because the data returned in response to INQUIRY indicates
       an unsupported logical unit, then the EXTENDED COPY command shall be
       terminated with CHECK CONDITION status, with the sense key set to
       COPY ABORTED, and the additional sense code set to COPY TARGET DEVICE
       NOT REACHABLE."
    
    Tested on v4.1.y with ESX v5.5u2+ with BlockCopy across multiple nodes.
    
    Reported-by: Nixon Vincent <nixon.vincent@calsoftinc.com>
    Tested-by: Nixon Vincent <nixon.vincent@calsoftinc.com>
    Cc: Nixon Vincent <nixon.vincent@calsoftinc.com>
    Tested-by: Dinesh Israni <ddi@datera.io>
    Signed-off-by: Dinesh Israni <ddi@datera.io>
    Cc: Dinesh Israni <ddi@datera.io>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    [bwh: Backported to 3.16: generate the sense data in
     transport_send_check_condition_and_sense() rather than adding to
     sense_info_table]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8a8d8a7c8b819b72d73f4ba3ffa854d194b928b0
Author: Richard Weinberger <richard@nod.at>
Date:   Wed Oct 19 12:43:07 2016 +0200

    ubifs: Abort readdir upon error
    
    commit c83ed4c9dbb358b9e7707486e167e940d48bfeed upstream.
    
    If UBIFS is facing an error while walking a directory, it reports this
    error and ubifs_readdir() returns the error code. But the VFS readdir
    logic does not make the getdents system call fail in all cases. When the
    readdir cursor indicates that more entries are present, the system call
    will just return and the libc wrapper will try again since it also
    knows that more entries are present.
    This causes the libc wrapper to busy loop for ever when a directory is
    corrupted on UBIFS.
    A common approach do deal with corrupted directory entries is
    skipping them by setting the cursor to the next entry. On UBIFS this
    approach is not possible since we cannot compute the next directory
    entry cursor position without reading the current entry. So all we can
    do is setting the cursor to the "no more entries" position and make
    getdents exit.
    
    Signed-off-by: Richard Weinberger <richard@nod.at>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7652f9e9895c7074f96a1ca546b9575f3cb86069
Author: Richard Weinberger <richard@nod.at>
Date:   Tue Sep 20 10:08:30 2016 +0200

    ubifs: Fix xattr_names length in exit paths
    
    commit 843741c5778398ea67055067f4cc65ae6c80ca0e upstream.
    
    When the operation fails we also have to undo the changes
    we made to ->xattr_names. Otherwise listxattr() will report
    wrong lengths.
    
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 58f60455fe26f6f60ea089d74f4fdca4755e05a2
Author: Patrick Scheuring <patrick.scheuring.dev@gmail.com>
Date:   Wed Oct 19 12:04:02 2016 -0700

    Input: i8042 - add XMG C504 to keyboard reset table
    
    commit da25311c7ca8b0254a686fc0d597075b9aa3b683 upstream.
    
    The Schenker XMG C504 is a rebranded Gigabyte P35 v2 laptop.
    Therefore it also needs a keyboard reset to detect the Elantech touchpad.
    Otherwise the touchpad appears to be dead.
    
    With this patch the touchpad is detected:
    
    $ dmesg | grep -E "(i8042|Elantech|elantech)"
    
    [    2.675399] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
    [    2.680372] i8042: Attempting to reset device connected to KBD port
    [    2.789037] serio: i8042 KBD port at 0x60,0x64 irq 1
    [    2.791586] serio: i8042 AUX port at 0x60,0x64 irq 12
    [    2.813840] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input4
    [    3.811431] psmouse serio1: elantech: assuming hardware version 4 (with firmware version 0x361f0e)
    [    3.825424] psmouse serio1: elantech: Synaptics capabilities query result 0x00, 0x15, 0x0f.
    [    3.839424] psmouse serio1: elantech: Elan sample query result 03, 58, 74
    [    3.911349] input: ETPS/2 Elantech Touchpad as /devices/platform/i8042/serio1/input/input6
    
    Signed-off-by: Patrick Scheuring <patrick.scheuring.dev@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2cd8816eccf2fb56d19d0e8751e451eb980815f3
Author: Andrew Lutomirski <luto@kernel.org>
Date:   Mon Oct 17 10:06:27 2016 -0700

    hwrng: core - Don't use a stack buffer in add_early_randomness()
    
    commit 6d4952d9d9d4dc2bb9c0255d95a09405a1e958f7 upstream.
    
    hw_random carefully avoids using a stack buffer except in
    add_early_randomness().  This causes a crash in virtio_rng if
    CONFIG_VMAP_STACK=y.
    
    Reported-by: Matt Mullins <mmullins@mmlx.us>
    Tested-by: Matt Mullins <mmullins@mmlx.us>
    Fixes: d3cc7996473a ("hwrng: fetch randomness only after device init")
    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 91dd2474f37e9e1dcd4c0c9c51891fc50edbad8c
Author: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date:   Tue Oct 18 18:09:48 2016 +0200

    bridge: multicast: restore perm router ports on multicast enable
    
    commit 7cb3f9214dfa443c1ccc2be637dcc6344cc203f0 upstream.
    
    Satish reported a problem with the perm multicast router ports not getting
    reenabled after some series of events, in particular if it happens that the
    multicast snooping has been disabled and the port goes to disabled state
    then it will be deleted from the router port list, but if it moves into
    non-disabled state it will not be re-added because the mcast snooping is
    still disabled, and enabling snooping later does nothing.
    
    Here are the steps to reproduce, setup br0 with snooping enabled and eth1
    added as a perm router (multicast_router = 2):
    1. $ echo 0 > /sys/class/net/br0/bridge/multicast_snooping
    2. $ ip l set eth1 down
    ^ This step deletes the interface from the router list
    3. $ ip l set eth1 up
    ^ This step does not add it again because mcast snooping is disabled
    4. $ echo 1 > /sys/class/net/br0/bridge/multicast_snooping
    5. $ bridge -d -s mdb show
    <empty>
    
    At this point we have mcast enabled and eth1 as a perm router (value = 2)
    but it is not in the router list which is incorrect.
    
    After this change:
    1. $ echo 0 > /sys/class/net/br0/bridge/multicast_snooping
    2. $ ip l set eth1 down
    ^ This step deletes the interface from the router list
    3. $ ip l set eth1 up
    ^ This step does not add it again because mcast snooping is disabled
    4. $ echo 1 > /sys/class/net/br0/bridge/multicast_snooping
    5. $ bridge -d -s mdb show
    router ports on br0: eth1
    
    Note: we can directly do br_multicast_enable_port for all because the
    querier timer already has checks for the port state and will simply
    expire if it's in blocking/disabled. See the comment added by
    commit 9aa66382163e7 ("bridge: multicast: add a comment to
    br_port_state_selection about blocking state")
    
    Fixes: 561f1103a2b7 ("bridge: Add multicast_snooping sysfs toggle")
    Reported-by: Satish Ashok <sashok@cumulusnetworks.com>
    Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0122596ed3481ac385c40ece1b61df219e9aa259
Author: Jan Kara <jack@suse.cz>
Date:   Tue Oct 4 13:44:06 2016 +0200

    isofs: Do not return EACCES for unknown filesystems
    
    commit a2ed0b391dd9c3ef1d64c7c3e370f4a5ffcd324a upstream.
    
    When isofs_mount() is called to mount a device read-write, it returns
    EACCES even before it checks that the device actually contains an isofs
    filesystem. This may confuse mount(8) which then tries to mount all
    subsequent filesystem types in read-only mode.
    
    Fix the problem by returning EACCES only once we verify that the device
    indeed contains an iso9660 filesystem.
    
    Fixes: 17b7f7cf58926844e1dd40f5eb5348d481deca6a
    Reported-by: Kent Overstreet <kent.overstreet@gmail.com>
    Reported-by: Karel Zak <kzak@redhat.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2a071533f8f74f11206b7efbd22fbbbf305fd816
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Mon Oct 17 17:23:59 2016 +0100

    ALSA: hda - allow 40 bit DMA mask for NVidia devices
    
    commit 3ab7511eafdd5c4f40d2832f09554478dfbea170 upstream.
    
    Commit 49d9e77e72cf ("ALSA: hda - Fix system panic when DMA > 40 bits
    for Nvidia audio controllers") simply disabled any DMA exceeding 32
    bits for NVidia devices, even though they are capable of performing
    DMA up to 40 bits. On some architectures (such as arm64), system memory
    is not guaranteed to be 32-bit addressable by PCI devices, and so this
    change prevents NVidia devices from working on platforms such as AMD
    Seattle.
    
    Since the original commit already mentioned that up to 40 bits of DMA
    is supported, and given that the code has been updated in the meantime
    to support a 40 bit DMA mask on other devices, revert commit 49d9e77e72cf
    and explicitly set the DMA mask to 40 bits for NVidia devices.
    
    Fixes: 49d9e77e72cf ('ALSA: hda - Fix system panic when DMA > 40 bits...')
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1ba27ad9a4f434ae470b73955e1e111c4b075ac6
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Oct 12 12:14:29 2016 +0300

    netfilter: nf_tables: underflow in nft_parse_u32_check()
    
    commit 09525a09ad3099efd9ba49b0b90bddc350d6b53a upstream.
    
    We don't want to allow negatives here.
    
    Fixes: 36b701fae12a ('netfilter: nf_tables: validate maximum value of u32 netlink attributes')
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f81f51bd324b334716018685933a6420d1c52033
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Mon Oct 17 13:47:34 2016 +0100

    arm64: kernel: Init MDCR_EL2 even in the absence of a PMU
    
    commit 850540351bb1a4fa5f192e5ce55b89928cc57f42 upstream.
    
    Commit f436b2ac90a0 ("arm64: kernel: fix architected PMU registers
    unconditional access") made sure we wouldn't access unimplemented
    PMU registers, but also left MDCR_EL2 uninitialized in that case,
    leading to trap bits being potentially left set.
    
    Make sure we always write something in that register.
    
    Fixes: f436b2ac90a0 ("arm64: kernel: fix architected PMU registers unconditional access")
    Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Cc: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0e5ecaa49dcf1092d8ebc0dce5795931d815b900
Author: Stefan Tauner <stefan.tauner@technikum-wien.at>
Date:   Thu Oct 6 18:40:11 2016 +0200

    USB: serial: ftdi_sio: add support for Infineon TriBoard TC2X7
    
    commit ca006f785fbfd7a5c901900bd3fe2b26e946a1ee upstream.
    
    This adds support to ftdi_sio for the Infineon TriBoard TC2X7
    engineering board for first-generation Aurix SoCs with Tricore CPUs.
    Mere addition of the device IDs does the job.
    
    Signed-off-by: Stefan Tauner <stefan.tauner@technikum-wien.at>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b9836e6a0bf784e26e1648f94cd8f361a9551a78
Author: Ulf Hansson <ulf.hansson@linaro.org>
Date:   Wed Sep 28 11:33:28 2016 -0700

    memstick: rtsx_usb_ms: Manage runtime PM when accessing the device
    
    commit 9158cb29e7c2f10dd325eb1589f0fe745a271257 upstream.
    
    Accesses to the rtsx usb device, which is the parent of the rtsx memstick
    device, must not be done unless it's runtime resumed. This is currently not
    the case and it could trigger various errors.
    
    Fix this by properly deal with runtime PM in this regards. This means
    making sure the device is runtime resumed, when serving requests via the
    ->request() callback or changing settings via the ->set_param() callbacks.
    
    Cc: Ritesh Raj Sarraf <rrs@researchut.com>
    Cc: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f276b44159ebfc6d50c8c0088a6275543c5346d7
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Mon Sep 26 15:45:41 2016 -0700

    memstick: rtsx_usb_ms: Runtime resume the device when polling for cards
    
    commit 796aa46adf1d90eab36ae06a42e6d3f10b28a75c upstream.
    
    Accesses to the rtsx usb device, which is the parent of the rtsx memstick
    device, must not be done unless it's runtime resumed.
    
    Therefore when the rtsx_usb_ms driver polls for inserted memstick cards,
    let's add pm_runtime_get|put*() to make sure accesses is done when the
    rtsx usb device is runtime resumed.
    
    Reported-by: Ritesh Raj Sarraf <rrs@researchut.com>
    Tested-by: Ritesh Raj Sarraf <rrs@researchut.com>
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f099ba5897715dc06b7ba2e20aeba893df4354e7
Author: Ulf Hansson <ulf.hansson@linaro.org>
Date:   Thu Sep 15 14:46:21 2016 +0200

    mmc: rtsx_usb_sdmmc: Handle runtime PM while changing the led
    
    commit 4f48aa7a11bfed9502a7c85a5b68cd40ea827f73 upstream.
    
    Accesses of the rtsx sdmmc's parent device, which is the rtsx usb device,
    must be done when it's runtime resumed. Currently this isn't case when
    changing the led, so let's fix this by adding a pm_runtime_get_sync() and
    a pm_runtime_put() around those operations.
    
    Reported-by: Ritesh Raj Sarraf <rrs@researchut.com>
    Tested-by: Ritesh Raj Sarraf <rrs@researchut.com>
    Cc: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 640060a967c5e81f62805f2076c55c0aef92e2a4
Author: Ulf Hansson <ulf.hansson@linaro.org>
Date:   Tue Sep 27 08:44:33 2016 -0700

    mmc: rtsx_usb_sdmmc: Avoid keeping the device runtime resumed when unused
    
    commit 31cf742f515c275d22843c4c756e048d2b6d716c upstream.
    
    The rtsx_usb_sdmmc driver may bail out in its ->set_ios() callback when no
    SD card is inserted. This is wrong, as it could cause the device to remain
    runtime resumed when it's unused. Fix this behaviour.
    
    Tested-by: Ritesh Raj Sarraf <rrs@researchut.com>
    Cc: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4288c31aad07b2e3c9a5e7d858d6dbf364662a1a
Author: Haibo Chen <haibo.chen@nxp.com>
Date:   Mon Oct 17 10:18:37 2016 +0200

    mmc: sdhci: cast unsigned int to unsigned long long to avoid unexpeted error
    
    commit 02265cd60335a2c1417abae4192611e1fc05a6e5 upstream.
    
    Potentially overflowing expression 1000000 * data->timeout_clks with
    type unsigned int is evaluated using 32-bit arithmetic, and then used
    in a context that expects an expression of type unsigned long long.
    
    To avoid overflow, cast 1000000U to type unsigned long long.
    Special thanks to Coverity.
    
    Fixes: 7f05538af71c ("mmc: sdhci: fix data timeout (part 2)")
    Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 512f4d834dbb40c74aa48cd6978e526e14c430dc
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Oct 14 16:18:39 2016 -0400

    scsi: zfcp: spin_lock_irqsave() is not nestable
    
    commit e7cb08e894a0b876443ef8fdb0706575dc00a5d2 upstream.
    
    We accidentally overwrite the original saved value of "flags" so that we
    can't re-enable IRQs at the end of the function.  Presumably this
    function is mostly called with IRQs disabled or it would be obvious in
    testing.
    
    Fixes: aceeffbb59bb ("zfcp: trace full payload of all SAN records (req,resp,iels)")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5dd09f87f4dc9080dda50cf6dc3a95153670122a
Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date:   Wed Oct 12 10:10:40 2016 +0200

    ipv6: correctly add local routes when lo goes up
    
    commit a220445f9f4382c36a53d8ef3e08165fa27f7e2c upstream.
    
    The goal of the patch is to fix this scenario:
     ip link add dummy1 type dummy
     ip link set dummy1 up
     ip link set lo down ; ip link set lo up
    
    After that sequence, the local route to the link layer address of dummy1 is
    not there anymore.
    
    When the loopback is set down, all local routes are deleted by
    addrconf_ifdown()/rt6_ifdown(). At this time, the rt6_info entry still
    exists, because the corresponding idev has a reference on it. After the rcu
    grace period, dst_rcu_free() is called, and thus ___dst_free(), which will
    set obsolete to DST_OBSOLETE_DEAD.
    
    In this case, init_loopback() is called before dst_rcu_free(), thus
    obsolete is still sets to something <= 0. So, the function doesn't add the
    route again. To avoid that race, let's check the rt6 refcnt instead.
    
    Fixes: 25fb6ca4ed9c ("net IPv6 : Fix broken IPv6 routing table after loopback down-up")
    Fixes: a881ae1f625c ("ipv6: don't call addrconf_dst_alloc again when enable lo")
    Fixes: 33d99113b110 ("ipv6: reallocate addrconf router for ipv6 address when lo device up")
    Reported-by: Francesco Santoro <francesco.santoro@6wind.com>
    Reported-by: Samuel Gauthier <samuel.gauthier@6wind.com>
    CC: Balakumaran Kannan <Balakumaran.Kannan@ap.sony.com>
    CC: Maruthi Thotad <Maruthi.Thotad@ap.sony.com>
    CC: Sabrina Dubroca <sd@queasysnail.net>
    CC: Hannes Frederic Sowa <hannes@stressinduktion.org>
    CC: Weilong Chen <chenweilong@huawei.com>
    CC: Gao feng <gaofeng@cn.fujitsu.com>
    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c4529dec666e52d8452a8c8195915d4dcb32befe
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Oct 12 15:28:55 2016 -0400

    drm/radeon: change vblank_time's calculation method to reduce computational error.
    
    commit 02cfb5fccb0f9f968f0e208d89d9769aa16267bc upstream.
    
    Ported from Rex's amdgpu change.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 22508742b93ec8b3216594510e788f5eaf3a963e
Author: Taesoo Kim <tsgatesv@gmail.com>
Date:   Wed Oct 12 23:19:18 2016 -0400

    jbd2: fix incorrect unlock on j_list_lock
    
    commit 559cce698eaf4ccecb2213b2519ea3a0413e5155 upstream.
    
    When 'jh->b_transaction == transaction' (asserted by below)
    
      J_ASSERT_JH(jh, (jh->b_transaction == transaction || ...
    
    'journal->j_list_lock' will be incorrectly unlocked, since
    the the lock is aquired only at the end of if / else-if
    statements (missing the else case).
    
    Signed-off-by: Taesoo Kim <tsgatesv@gmail.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Andreas Dilger <adilger@dilger.ca>
    Fixes: 6e4862a5bb9d12be87e4ea5d9a60836ebed71d28
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7bbb3c6c8e6808ac136ed1b2143edc51aa493ea1
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Oct 5 10:14:42 2016 +0200

    mac80211: discard multicast and 4-addr A-MSDUs
    
    commit ea720935cf6686f72def9d322298bf7e9bd53377 upstream.
    
    In mac80211, multicast A-MSDUs are accepted in many cases that
    they shouldn't be accepted in:
     * drop A-MSDUs with a multicast A1 (RA), as required by the
       spec in 9.11 (802.11-2012 version)
     * drop A-MSDUs with a 4-addr header, since the fourth address
       can't actually be useful for them; unless 4-address frame
       format is actually requested, even though the fourth address
       is still not useful in this case, but ignored
    
    Accepting the first case, in particular, is very problematic
    since it allows anyone else with possession of a GTK to send
    unicast frames encapsulated in a multicast A-MSDU, even when
    the AP has client isolation enabled.
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7c40fa13ddc022774f1687eea361bdabc39dc925
Author: Ming Lei <tom.leiming@gmail.com>
Date:   Sun Oct 9 13:23:27 2016 +0800

    scsi: Fix use-after-free
    
    commit bcd8f2e94808fcddf6ef3af5f060a36820dcc432 upstream.
    
    This patch fixes one use-after-free report[1] by KASAN.
    
    In __scsi_scan_target(), when a type 31 device is probed,
    SCSI_SCAN_TARGET_PRESENT is returned and the target will be scanned
    again.
    
    Inside the following scsi_report_lun_scan(), one new scsi_device
    instance is allocated, and scsi_probe_and_add_lun() is called again to
    probe the target and still see type 31 device, finally
    __scsi_remove_device() is called to remove & free the device at the end
    of scsi_probe_and_add_lun(), so cause use-after-free in
    scsi_report_lun_scan().
    
    And the following SCSI log can be observed:
    
            scsi 0:0:2:0: scsi scan: INQUIRY pass 1 length 36
            scsi 0:0:2:0: scsi scan: INQUIRY successful with code 0x0
            scsi 0:0:2:0: scsi scan: peripheral device type of 31, no device added
            scsi 0:0:2:0: scsi scan: Sending REPORT LUNS to (try 0)
            scsi 0:0:2:0: scsi scan: REPORT LUNS successful (try 0) result 0x0
            scsi 0:0:2:0: scsi scan: REPORT LUN scan
            scsi 0:0:2:0: scsi scan: INQUIRY pass 1 length 36
            scsi 0:0:2:0: scsi scan: INQUIRY successful with code 0x0
            scsi 0:0:2:0: scsi scan: peripheral device type of 31, no device added
            BUG: KASAN: use-after-free in __scsi_scan_target+0xbf8/0xe40 at addr ffff88007b44a104
    
    This patch fixes the issue by moving the putting reference at
    the end of scsi_report_lun_scan().
    
    [1] KASAN report
    ==================================================================
    [    3.274597] PM: Adding info for serio:serio1
    [    3.275127] BUG: KASAN: use-after-free in __scsi_scan_target+0xd87/0xdf0 at addr ffff880254d8c304
    [    3.275653] Read of size 4 by task kworker/u10:0/27
    [    3.275903] CPU: 3 PID: 27 Comm: kworker/u10:0 Not tainted 4.8.0 #2121
    [    3.276258] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
    [    3.276797] Workqueue: events_unbound async_run_entry_fn
    [    3.277083]  ffff880254d8c380 ffff880259a37870 ffffffff94bbc6c1 ffff880078402d80
    [    3.277532]  ffff880254d8bb80 ffff880259a37898 ffffffff9459fec1 ffff880259a37930
    [    3.277989]  ffff880254d8bb80 ffff880078402d80 ffff880259a37920 ffffffff945a0165
    [    3.278436] Call Trace:
    [    3.278528]  [<ffffffff94bbc6c1>] dump_stack+0x65/0x84
    [    3.278797]  [<ffffffff9459fec1>] kasan_object_err+0x21/0x70
    [    3.279063] device: 'psaux': device_add
    [    3.279616]  [<ffffffff945a0165>] kasan_report_error+0x205/0x500
    [    3.279651] PM: Adding info for No Bus:psaux
    [    3.280202]  [<ffffffff944ecd22>] ? kfree_const+0x22/0x30
    [    3.280486]  [<ffffffff94bc2dc9>] ? kobject_release+0x119/0x370
    [    3.280805]  [<ffffffff945a0543>] __asan_report_load4_noabort+0x43/0x50
    [    3.281170]  [<ffffffff9507e1f7>] ? __scsi_scan_target+0xd87/0xdf0
    [    3.281506]  [<ffffffff9507e1f7>] __scsi_scan_target+0xd87/0xdf0
    [    3.281848]  [<ffffffff9507d470>] ? scsi_add_device+0x30/0x30
    [    3.282156]  [<ffffffff94f7f660>] ? pm_runtime_autosuspend_expiration+0x60/0x60
    [    3.282570]  [<ffffffff956ddb07>] ? _raw_spin_lock+0x17/0x40
    [    3.282880]  [<ffffffff9507e505>] scsi_scan_channel+0x105/0x160
    [    3.283200]  [<ffffffff9507e8a2>] scsi_scan_host_selected+0x212/0x2f0
    [    3.283563]  [<ffffffff9507eb3c>] do_scsi_scan_host+0x1bc/0x250
    [    3.283882]  [<ffffffff9507efc1>] do_scan_async+0x41/0x450
    [    3.284173]  [<ffffffff941c1fee>] async_run_entry_fn+0xfe/0x610
    [    3.284492]  [<ffffffff941a8954>] ? pwq_dec_nr_in_flight+0x124/0x2a0
    [    3.284876]  [<ffffffff941d1770>] ? preempt_count_add+0x130/0x160
    [    3.285207]  [<ffffffff941a9a84>] process_one_work+0x544/0x12d0
    [    3.285526]  [<ffffffff941aa8e9>] worker_thread+0xd9/0x12f0
    [    3.285844]  [<ffffffff941aa810>] ? process_one_work+0x12d0/0x12d0
    [    3.286182]  [<ffffffff941bb365>] kthread+0x1c5/0x260
    [    3.286443]  [<ffffffff940855cd>] ? __switch_to+0x88d/0x1430
    [    3.286745]  [<ffffffff941bb1a0>] ? kthread_worker_fn+0x5a0/0x5a0
    [    3.287085]  [<ffffffff956dde9f>] ret_from_fork+0x1f/0x40
    [    3.287368]  [<ffffffff941bb1a0>] ? kthread_worker_fn+0x5a0/0x5a0
    [    3.287697] Object at ffff880254d8bb80, in cache kmalloc-2048 size: 2048
    [    3.288064] Allocated:
    [    3.288147] PID = 27
    [    3.288218]  [<ffffffff940b27ab>] save_stack_trace+0x2b/0x50
    [    3.288531]  [<ffffffff9459f246>] save_stack+0x46/0xd0
    [    3.288806]  [<ffffffff9459f4bd>] kasan_kmalloc+0xad/0xe0
    [    3.289098]  [<ffffffff9459c07e>] __kmalloc+0x13e/0x250
    [    3.289378]  [<ffffffff95078e5a>] scsi_alloc_sdev+0xea/0xcf0
    [    3.289701]  [<ffffffff9507de76>] __scsi_scan_target+0xa06/0xdf0
    [    3.290034]  [<ffffffff9507e505>] scsi_scan_channel+0x105/0x160
    [    3.290362]  [<ffffffff9507e8a2>] scsi_scan_host_selected+0x212/0x2f0
    [    3.290724]  [<ffffffff9507eb3c>] do_scsi_scan_host+0x1bc/0x250
    [    3.291055]  [<ffffffff9507efc1>] do_scan_async+0x41/0x450
    [    3.291354]  [<ffffffff941c1fee>] async_run_entry_fn+0xfe/0x610
    [    3.291695]  [<ffffffff941a9a84>] process_one_work+0x544/0x12d0
    [    3.292022]  [<ffffffff941aa8e9>] worker_thread+0xd9/0x12f0
    [    3.292325]  [<ffffffff941bb365>] kthread+0x1c5/0x260
    [    3.292594]  [<ffffffff956dde9f>] ret_from_fork+0x1f/0x40
    [    3.292886] Freed:
    [    3.292945] PID = 27
    [    3.293016]  [<ffffffff940b27ab>] save_stack_trace+0x2b/0x50
    [    3.293327]  [<ffffffff9459f246>] save_stack+0x46/0xd0
    [    3.293600]  [<ffffffff9459fa61>] kasan_slab_free+0x71/0xb0
    [    3.293916]  [<ffffffff9459bac2>] kfree+0xa2/0x1f0
    [    3.294168]  [<ffffffff9508158a>] scsi_device_dev_release_usercontext+0x50a/0x730
    [    3.294598]  [<ffffffff941ace9a>] execute_in_process_context+0xda/0x130
    [    3.294974]  [<ffffffff9508107c>] scsi_device_dev_release+0x1c/0x20
    [    3.295322]  [<ffffffff94f566f6>] device_release+0x76/0x1e0
    [    3.295626]  [<ffffffff94bc2db7>] kobject_release+0x107/0x370
    [    3.295942]  [<ffffffff94bc29ce>] kobject_put+0x4e/0xa0
    [    3.296222]  [<ffffffff94f56e17>] put_device+0x17/0x20
    [    3.296497]  [<ffffffff9505201c>] scsi_device_put+0x7c/0xa0
    [    3.296801]  [<ffffffff9507e1bc>] __scsi_scan_target+0xd4c/0xdf0
    [    3.297132]  [<ffffffff9507e505>] scsi_scan_channel+0x105/0x160
    [    3.297458]  [<ffffffff9507e8a2>] scsi_scan_host_selected+0x212/0x2f0
    [    3.297829]  [<ffffffff9507eb3c>] do_scsi_scan_host+0x1bc/0x250
    [    3.298156]  [<ffffffff9507efc1>] do_scan_async+0x41/0x450
    [    3.298453]  [<ffffffff941c1fee>] async_run_entry_fn+0xfe/0x610
    [    3.298777]  [<ffffffff941a9a84>] process_one_work+0x544/0x12d0
    [    3.299105]  [<ffffffff941aa8e9>] worker_thread+0xd9/0x12f0
    [    3.299408]  [<ffffffff941bb365>] kthread+0x1c5/0x260
    [    3.299676]  [<ffffffff956dde9f>] ret_from_fork+0x1f/0x40
    [    3.299967] Memory state around the buggy address:
    [    3.300209]  ffff880254d8c200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [    3.300608]  ffff880254d8c280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [    3.300986] >ffff880254d8c300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [    3.301408]                    ^
    [    3.301550]  ffff880254d8c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [    3.301987]  ffff880254d8c400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [    3.302396]
    ==================================================================
    
    Cc: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Ming Lei <tom.leiming@gmail.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 383eeaf90a873ebdb814da81bca6927c93fb53e3
Author: murray foster <mrafoster@gmail.com>
Date:   Sun Oct 9 13:28:45 2016 -0700

    ASoC: cs4270: fix DAPM stream name mismatch
    
    commit aa5f920993bda2095952177eea79bc8e58ae6065 upstream.
    
    Mismatching stream names in DAPM route and widget definitions are
    causing compilation errors. Fixing these names allows the cs4270
    driver to compile and function.
    
    [Errors must be at probe time not compile time -- broonie]
    
    Signed-off-by: Murray Foster <mrafoster@gmail.com>
    Acked-by: Paul Handrigan <Paul.Handrigan@cirrus.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8258908d546058ab483fb0a3aa85b0626ce19b4d
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Mon Oct 3 10:58:28 2016 +0200

    mmc: core: Annotate cmd_hdr as __le32
    
    commit 3f2d26643595973e835e8356ea90c7c15cb1b0f1 upstream.
    
    Commit f68381a70bb2 (mmc: block: fix packed command header endianness)
    correctly fixed endianness handling of packed_cmd_hdr in
    mmc_blk_packed_hdr_wrq_prep.
    
    But now, sparse complains about incorrect types:
    drivers/mmc/card/block.c:1613:27: sparse: incorrect type in assignment (different base types)
    drivers/mmc/card/block.c:1613:27:    expected unsigned int [unsigned] [usertype] <noident>
    drivers/mmc/card/block.c:1613:27:    got restricted __le32 [usertype] <noident>
    ...
    
    So annotate cmd_hdr properly using __le32 to make everyone happy.
    
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Fixes: f68381a70bb2 (mmc: block: fix packed command header endianness)
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 777c9de7ef47ea28cb4f458bed2c83acc7bc95d0
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Mon Sep 26 18:07:48 2016 +0200

    fs/super.c: fix race between freeze_super() and thaw_super()
    
    commit 89f39af129382a40d7cd1f6914617282cfeee28e upstream.
    
    Change thaw_super() to check frozen != SB_FREEZE_COMPLETE rather than
    frozen == SB_UNFROZEN, otherwise it can race with freeze_super() which
    drops sb->s_umount after SB_FREEZE_WRITE to preserve the lock ordering.
    
    In this case thaw_super() will wrongly call s_op->unfreeze_fs() before
    it was actually frozen, and call sb_freeze_unlock() which leads to the
    unbalanced percpu_up_write(). Unfortunately lockdep can't detect this,
    so this triggers misc BUG_ON()'s in kernel/rcu/sync.c.
    
    Reported-and-tested-by: Nikolay Borisov <kernel@kyup.com>
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1b40078c2b53f5c0264830eab1f1bbd237421eb8
Author: Steve French <smfrench@gmail.com>
Date:   Thu Sep 29 04:20:23 2016 -0500

    Cleanup missing frees on some ioctls
    
    commit 24df1483c272c99ed88b0cba135d0e1dfdee3930 upstream.
    
    Cleanup some missing mem frees on some cifs ioctls, and
    clarify others to make more obvious that no data is returned.
    
    Signed-off-by: Steve French <smfrench@gmail.com>
    Acked-by: Sachin Prabhu <sprabhu@redhat.com>
    [bwh: Backported to 3.16:
     - Drop changes to smb2_duplicate_extents(), smb3_set_integrity()
     - Adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5731ddb7187dc24ca5c65cc7fc5e91e447d06af6
Author: Steve French <smfrench@gmail.com>
Date:   Mon Sep 26 14:23:08 2016 -0500

    Do not send SMB3 SET_INFO request if nothing is changing
    
    commit 18dd8e1a65ddae2351d0f0d6dd4a334f441fc5fa upstream.
    
    [CIFS] We had cases where we sent a SMB2/SMB3 setinfo request with all
    timestamp (and DOS attribute) fields marked as 0 (ie do not change)
    e.g. on chmod or chown.
    
    Signed-off-by: Steve French <steve.french@primarydata.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d02e327b875605d50f6dcab62c08cf9ccd667225
Author: Steve French <smfrench@gmail.com>
Date:   Thu Sep 22 18:58:16 2016 -0500

    Clarify locking of cifs file and tcon structures and make more granular
    
    commit 3afca265b5f53a0b15b79531c13858049505582d upstream.
    
    Remove the global file_list_lock to simplify cifs/smb3 locking and
    have spinlocks that more closely match the information they are
    protecting.
    
    Add new tcon->open_file_lock and file->file_info_lock spinlocks.
    Locks continue to follow a heirachy,
            cifs_socket --> cifs_ses --> cifs_tcon --> cifs_file
    where global tcp_ses_lock still protects socket and cifs_ses, while the
    the newer locks protect the lower level structure's information
    (tcon and cifs_file respectively).
    
    Signed-off-by: Steve French <steve.french@primarydata.com>
    Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
    Reviewed-by: Aurelien Aptel <aaptel@suse.com>
    Reviewed-by: Germano Percossi <germano.percossi@citrix.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 37ed7e2d37f1d35f2457a8881ef10dbdc54a26f4
Author: Steve French <smfrench@gmail.com>
Date:   Thu Sep 22 00:39:34 2016 -0500

    SMB3: GUIDs should be constructed as random but valid uuids
    
    commit fa70b87cc6641978b20e12cc5d517e9ffc0086d4 upstream.
    
    GUIDs although random, and 16 bytes, need to be generated as
    proper uuids.
    
    Signed-off-by: Steve French <steve.french@primarydata.com>
    Reviewed-by: Aurelien Aptel <aaptel@suse.com>
    Reported-by: David Goebels <davidgoe@microsoft.com>
    [bwh: Backported to 3.16: drop changes to create_durable_v2_buf()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d7c931703ec3e2fe022013c835182715ee06cb5c
Author: Steve French <smfrench@gmail.com>
Date:   Tue Sep 20 22:56:13 2016 -0500

    Set previous session id correctly on SMB3 reconnect
    
    commit c2afb8147e69819885493edf3a7c1ce03aaf2d4e upstream.
    
    Signed-off-by: Steve French <steve.french@primarydata.com>
    Reported-by: David Goebel <davidgoe@microsoft.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 47aa7c01b2fb464d27e1f4091a96b5dade97c0b2
Author: Ross Lagerwall <ross.lagerwall@citrix.com>
Date:   Tue Sep 20 13:37:13 2016 +0100

    cifs: Limit the overall credit acquired
    
    commit 7d414f396c91a3382e51cf628c1cf0709ad0188b upstream.
    
    The kernel client requests 2 credits for many operations even though
    they only use 1 credit (presumably to build up a buffer of credit).
    Some servers seem to give the client as much credit as is requested.  In
    this case, the amount of credit the client has continues increasing to
    the point where (server->credits * MAX_BUFFER_SIZE) overflows in
    smb2_wait_mtu_credits().
    
    Fix this by throttling the credit requests if an set limit is reached.
    For async requests where the credit charge may be > 1, request as much
    credit as what is charged.
    The limit is chosen somewhat arbitrarily. The Windows client
    defaults to 128 credits, the Windows server allows clients up to
    512 credits (or 8192 for Windows 2016), and the NetApp server
    (and at least one other) does not limit clients at all.
    Choose a high enough value such that the client shouldn't limit
    performance.
    
    This behavior was seen with a NetApp filer (NetApp Release 9.0RC2).
    
    Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
    Signed-off-by: Steve French <smfrench@gmail.com>
    [bwh: Backported to 3.16: drop changes to smb2_async_{read,write}v()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a8c714961c25fcf77a044fb89a00f38e2e8a23f8
Author: Steve French <smfrench@gmail.com>
Date:   Mon Sep 19 22:06:35 2016 -0500

    Display number of credits available
    
    commit 9742805d6b1bfb45d7f267648c34fb5bcd347397 upstream.
    
    In debugging smb3, it is useful to display the number
    of credits available, so we can see when the server has not granted
    sufficient operations for the client to make progress, or alternatively
    the client has requested too many credits (as we saw in a recent bug)
    so we can compare with the number of credits the server thinks
    we have.
    
    Add a /proc/fs/cifs/DebugData line to display the client view
    on how many credits are available.
    
    Signed-off-by: Steve French <steve.french@primarydata.com>
    Reported-by: Germano Percossi <germano.percossi@citrix.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9de05bceeb433753ad4b615954d7b7e9db29c18b
Author: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
Date:   Wed Oct 12 09:32:56 2016 +0200

    MIPS: ptrace: Fix regs_return_value for kernel context
    
    commit 74f1077b5b783e7bf4fa3007cefdc8dbd6c07518 upstream.
    
    Currently regs_return_value always negates reg[2] if it determines
    the syscall has failed, but when called in kernel context this check is
    invalid and may result in returning a wrong value.
    
    This fixes errors reported by CONFIG_KPROBES_SANITY_TEST
    
    Fixes: d7e7528bcd45 ("Audit: push audit success and retcode into arch ptrace.h")
    Signed-off-by: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/14381/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit accb9f16adbaeb5878974abc7b0e334790e59c11
Author: Manfred Spraul <manfred@colorfullife.com>
Date:   Tue Oct 11 13:54:50 2016 -0700

    ipc/sem.c: fix complex_count vs. simple op race
    
    commit 5864a2fd3088db73d47942370d0f7210a807b9bc upstream.
    
    Commit 6d07b68ce16a ("ipc/sem.c: optimize sem_lock()") introduced a
    race:
    
    sem_lock has a fast path that allows parallel simple operations.
    There are two reasons why a simple operation cannot run in parallel:
     - a non-simple operations is ongoing (sma->sem_perm.lock held)
     - a complex operation is sleeping (sma->complex_count != 0)
    
    As both facts are stored independently, a thread can bypass the current
    checks by sleeping in the right positions.  See below for more details
    (or kernel bugzilla 105651).
    
    The patch fixes that by creating one variable (complex_mode)
    that tracks both reasons why parallel operations are not possible.
    
    The patch also updates stale documentation regarding the locking.
    
    With regards to stable kernels:
    The patch is required for all kernels that include the
    commit 6d07b68ce16a ("ipc/sem.c: optimize sem_lock()") (3.10?)
    
    The alternative is to revert the patch that introduced the race.
    
    The patch is safe for backporting, i.e. it makes no assumptions
    about memory barriers in spin_unlock_wait().
    
    Background:
    Here is the race of the current implementation:
    
    Thread A: (simple op)
    - does the first "sma->complex_count == 0" test
    
    Thread B: (complex op)
    - does sem_lock(): This includes an array scan. But the scan can't
      find Thread A, because Thread A does not own sem->lock yet.
    - the thread does the operation, increases complex_count,
      drops sem_lock, sleeps
    
    Thread A:
    - spin_lock(&sem->lock), spin_is_locked(sma->sem_perm.lock)
    - sleeps before the complex_count test
    
    Thread C: (complex op)
    - does sem_lock (no array scan, complex_count==1)
    - wakes up Thread B.
    - decrements complex_count
    
    Thread A:
    - does the complex_count test
    
    Bug:
    Now both thread A and thread C operate on the same array, without
    any synchronization.
    
    Fixes: 6d07b68ce16a ("ipc/sem.c: optimize sem_lock()")
    Link: http://lkml.kernel.org/r/1469123695-5661-1-git-send-email-manfred@colorfullife.com
    Reported-by: <felixh@informatik.uni-bremen.de>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Davidlohr Bueso <dave@stgolabs.net>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@elte.hu>
    Cc: <1vier1@web.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.16:
     - We missed out on some earlier memory barrier changes
     - Use set_mb instead of smp_store_mb]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5b11c133308bb386e8b6eb6dfc07f232bf0306a1
Author: Joe Perches <joe@perches.com>
Date:   Wed Apr 15 16:17:54 2015 -0700

    ipc: remove use of seq_printf return value
    
    commit 7f032d6ef6154868a2a5d5f6b2c3f8587292196c upstream.
    
    The seq_printf return value, because it's frequently misused,
    will eventually be converted to void.
    
    See: commit 1f33c41c03da ("seq_file: Rename seq_overflow() to
         seq_has_overflowed() and make public")
    
    Signed-off-by: Joe Perches <joe@perches.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6b454ee19ded0051ac67b90c809d64d8cd72a96b
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Fri Sep 5 11:14:48 2014 -0700

    compiler: Allow 1- and 2-byte smp_load_acquire() and smp_store_release()
    
    commit 536fa402221f09633e7c5801b327055ab716a363 upstream.
    
    CPUs without single-byte and double-byte loads and stores place some
    "interesting" requirements on concurrent code.  For example (adapted
    from Peter Hurley's test code), suppose we have the following structure:
    
            struct foo {
                    spinlock_t lock1;
                    spinlock_t lock2;
                    char a; /* Protected by lock1. */
                    char b; /* Protected by lock2. */
            };
            struct foo *foop;
    
    Of course, it is common (and good) practice to place data protected
    by different locks in separate cache lines.  However, if the locks are
    rarely acquired (for example, only in rare error cases), and there are
    a great many instances of the data structure, then memory footprint can
    trump false-sharing concerns, so that it can be better to place them in
    the same cache cache line as above.
    
    But if the CPU does not support single-byte loads and stores, a store
    to foop->a will do a non-atomic read-modify-write operation on foop->b,
    which will come as a nasty surprise to someone holding foop->lock2.  So we
    now require CPUs to support single-byte and double-byte loads and stores.
    Therefore, this commit adjusts the definition of __native_word() to allow
    these sizes to be used by smp_load_acquire() and smp_store_release().
    
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fd5c3e142300876ddae0db14c3ff32318306c884
Author: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Date:   Tue Oct 11 13:54:26 2016 -0700

    mips/panic: replace smp_send_stop() with kdump friendly version in panic path
    
    commit 54c721b857fd45f3ad3bda695ee4f472518db02a upstream.
    
    Daniel Walker reported problems which happens when
    crash_kexec_post_notifiers kernel option is enabled
    (https://lkml.org/lkml/2015/6/24/44).
    
    In that case, smp_send_stop() is called before entering kdump routines
    which assume other CPUs are still online.  As the result, kdump
    routines fail to save other CPUs' registers.  Additionally for MIPS
    OCTEON, it misses to stop the watchdog timer.
    
    To fix this problem, call a new kdump friendly function,
    crash_smp_send_stop(), instead of the smp_send_stop() when
    crash_kexec_post_notifiers is enabled.  crash_smp_send_stop() is a
    weak function, and it just call smp_send_stop().  Architecture
    codes should override it so that kdump can work appropriately.
    This patch provides MIPS version.
    
    Fixes: f06e5153f4ae (kernel/panic.c: add "crash_kexec_post_notifiers" option)
    Link: http://lkml.kernel.org/r/20160810080950.11028.28000.stgit@sysi4-13.yrl.intra.hitachi.co.jp
    Signed-off-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
    Reported-by: Daniel Walker <dwalker@fifo99.com>
    Cc: Dave Young <dyoung@redhat.com>
    Cc: Baoquan He <bhe@redhat.com>
    Cc: Vivek Goyal <vgoyal@redhat.com>
    Cc: Eric Biederman <ebiederm@xmission.com>
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Daniel Walker <dwalker@fifo99.com>
    Cc: Xunlei Pang <xpang@redhat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Borislav Petkov <bp@suse.de>
    Cc: David Vrabel <david.vrabel@citrix.com>
    Cc: Toshi Kani <toshi.kani@hpe.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: David Daney <david.daney@cavium.com>
    Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
    Cc: "Steven J. Hill" <steven.hill@cavium.com>
    Cc: Corey Minyard <cminyard@mvista.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ed1d3436a46541e9343e697332260d5290c0fb6d
Author: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Date:   Tue Oct 11 13:54:23 2016 -0700

    x86/panic: replace smp_send_stop() with kdump friendly version in panic path
    
    commit 0ee59413c967c35a6dd2dbdab605b4cd42025ee5 upstream.
    
    Daniel Walker reported problems which happens when
    crash_kexec_post_notifiers kernel option is enabled
    (https://lkml.org/lkml/2015/6/24/44).
    
    In that case, smp_send_stop() is called before entering kdump routines
    which assume other CPUs are still online.  As the result, for x86, kdump
    routines fail to save other CPUs' registers and disable virtualization
    extensions.
    
    To fix this problem, call a new kdump friendly function,
    crash_smp_send_stop(), instead of the smp_send_stop() when
    crash_kexec_post_notifiers is enabled.  crash_smp_send_stop() is a weak
    function, and it just call smp_send_stop().  Architecture codes should
    override it so that kdump can work appropriately.  This patch only
    provides x86-specific version.
    
    For Xen's PV kernel, just keep the current behavior.
    
    NOTES:
    
    - Right solution would be to place crash_smp_send_stop() before
      __crash_kexec() invocation in all cases and remove smp_send_stop(), but
      we can't do that until all architectures implement own
      crash_smp_send_stop()
    
    - crash_smp_send_stop()-like work is still needed by
      machine_crash_shutdown() because crash_kexec() can be called without
      entering panic()
    
    Fixes: f06e5153f4ae (kernel/panic.c: add "crash_kexec_post_notifiers" option)
    Link: http://lkml.kernel.org/r/20160810080948.11028.15344.stgit@sysi4-13.yrl.intra.hitachi.co.jp
    Signed-off-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
    Reported-by: Daniel Walker <dwalker@fifo99.com>
    Cc: Dave Young <dyoung@redhat.com>
    Cc: Baoquan He <bhe@redhat.com>
    Cc: Vivek Goyal <vgoyal@redhat.com>
    Cc: Eric Biederman <ebiederm@xmission.com>
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Daniel Walker <dwalker@fifo99.com>
    Cc: Xunlei Pang <xpang@redhat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Borislav Petkov <bp@suse.de>
    Cc: David Vrabel <david.vrabel@citrix.com>
    Cc: Toshi Kani <toshi.kani@hpe.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: David Daney <david.daney@cavium.com>
    Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
    Cc: "Steven J. Hill" <steven.hill@cavium.com>
    Cc: Corey Minyard <cminyard@mvista.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4aa22b892e1ee0f0c93b8776de27246ffa66d02b
Author: Paul Mackerras <paulus@ozlabs.org>
Date:   Tue Oct 11 22:25:47 2016 +1100

    powerpc/64: Fix incorrect return value from __copy_tofrom_user
    
    commit 1a34439e5a0b2235e43f96816dbb15ee1154f656 upstream.
    
    Debugging a data corruption issue with virtio-net/vhost-net led to
    the observation that __copy_tofrom_user was occasionally returning
    a value 16 larger than it should.  Since the return value from
    __copy_tofrom_user is the number of bytes not copied, this means
    that __copy_tofrom_user can occasionally return a value larger
    than the number of bytes it was asked to copy.  In turn this can
    cause higher-level copy functions such as copy_page_to_iter_iovec
    to corrupt memory by copying data into the wrong memory locations.
    
    It turns out that the failing case involves a fault on the store
    at label 79, and at that point the first unmodified byte of the
    destination is at R3 + 16.  Consequently the exception handler
    for that store needs to add 16 to R3 before using it to work out
    how many bytes were not copied, but in this one case it was not
    adding the offset to R3.  To fix it, this moves the label 179 to
    the point where we add 16 to R3.  I have checked manually all the
    exception handlers for the loads and stores in this code and the
    rest of them are correct (it would be excellent to have an
    automated test of all the exception cases).
    
    This bug has been present since this code was initially
    committed in May 2002 to Linux version 2.5.20.
    
    Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0d86a59aa535517acbb16a4bc1558af154f2e188
Author: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Date:   Thu Oct 6 15:33:21 2016 +0200

    powerpc/pseries: Fix stack corruption in htpe code
    
    commit 05af40e885955065aee8bb7425058eb3e1adca08 upstream.
    
    This commit fixes a stack corruption in the pseries specific code dealing
    with the huge pages.
    
    In __pSeries_lpar_hugepage_invalidate() the buffer used to pass arguments
    to the hypervisor is not large enough. This leads to a stack corruption
    where a previously saved register could be corrupted leading to unexpected
    result in the caller, like the following panic:
    
      Oops: Kernel access of bad area, sig: 11 [#1]
      SMP NR_CPUS=2048 NUMA pSeries
      Modules linked in: virtio_balloon ip_tables x_tables autofs4
      virtio_blk 8139too virtio_pci virtio_ring 8139cp virtio
      CPU: 11 PID: 1916 Comm: mmstress Not tainted 4.8.0 #76
      task: c000000005394880 task.stack: c000000005570000
      NIP: c00000000027bf6c LR: c00000000027bf64 CTR: 0000000000000000
      REGS: c000000005573820 TRAP: 0300   Not tainted  (4.8.0)
      MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE>  CR: 84822884  XER: 20000000
      CFAR: c00000000010a924 DAR: 420000000014e5e0 DSISR: 40000000 SOFTE: 1
      GPR00: c00000000027bf64 c000000005573aa0 c000000000e02800 c000000004447964
      GPR04: c00000000404de18 c000000004d38810 00000000042100f5 00000000f5002104
      GPR08: e0000000f5002104 0000000000000001 042100f5000000e0 00000000042100f5
      GPR12: 0000000000002200 c00000000fe02c00 c00000000404de18 0000000000000000
      GPR16: c1ffffffffffe7ff 00003fff62000000 420000000014e5e0 00003fff63000000
      GPR20: 0008000000000000 c0000000f7014800 0405e600000000e0 0000000000010000
      GPR24: c000000004d38810 c000000004447c10 c00000000404de18 c000000004447964
      GPR28: c000000005573b10 c000000004d38810 00003fff62000000 420000000014e5e0
      NIP [c00000000027bf6c] zap_huge_pmd+0x4c/0x470
      LR [c00000000027bf64] zap_huge_pmd+0x44/0x470
      Call Trace:
      [c000000005573aa0] [c00000000027bf64] zap_huge_pmd+0x44/0x470 (unreliable)
      [c000000005573af0] [c00000000022bbd8] unmap_page_range+0xcf8/0xed0
      [c000000005573c30] [c00000000022c2d4] unmap_vmas+0x84/0x120
      [c000000005573c80] [c000000000235448] unmap_region+0xd8/0x1b0
      [c000000005573d80] [c0000000002378f0] do_munmap+0x2d0/0x4c0
      [c000000005573df0] [c000000000237be4] SyS_munmap+0x64/0xb0
      [c000000005573e30] [c000000000009560] system_call+0x38/0x108
      Instruction dump:
      fbe1fff8 fb81ffe0 7c7f1b78 7ca32b78 7cbd2b78 f8010010 7c9a2378 f821ffb1
      7cde3378 4bfffea9 7c7b1b79 41820298 <e87f0000> 48000130 7fa5eb78 7fc4f378
    
    Most of the time, the bug is surfacing in a caller up in the stack from
    __pSeries_lpar_hugepage_invalidate() which is quite confusing.
    
    This bug is pending since v3.11 but was hidden if a caller of the
    caller of __pSeries_lpar_hugepage_invalidate() has pushed the corruped
    register (r18 in this case) in the stack and is not using it until
    restoring it. GCC 6.2.0 seems to raise it more frequently.
    
    This commit also change the definition of the parameter buffer in
    pSeries_lpar_flush_hash_range() to rely on the global define
    PLPAR_HCALL9_BUFSIZE (no functional change here).
    
    Fixes: 1a5272866f87 ("powerpc: Optimize hugepage invalidate")
    Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
    Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
    Acked-by: Balbir Singh <bsingharora@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 272830350bb1bb5bb39395966ea63b9864b135d1
Author: Wei Fang <fangwei1@huawei.com>
Date:   Fri Oct 7 17:01:52 2016 -0700

    vfs,mm: fix a dead loop in truncate_inode_pages_range()
    
    commit c2a9737f45e27d8263ff9643f994bda9bac0b944 upstream.
    
    We triggered a deadloop in truncate_inode_pages_range() on 32 bits
    architecture with the test case bellow:
    
            ...
            fd = open();
            write(fd, buf, 4096);
            preadv64(fd, &iovec, 1, 0xffffffff000);
            ftruncate(fd, 0);
            ...
    
    Then ftruncate() will not return forever.
    
    The filesystem used in this case is ubifs, but it can be triggered on
    many other filesystems.
    
    When preadv64() is called with offset=0xffffffff000, a page with
    index=0xffffffff will be added to the radix tree of ->mapping.  Then
    this page can be found in ->mapping with pagevec_lookup().  After that,
    truncate_inode_pages_range(), which is called in ftruncate(), will fall
    into an infinite loop:
    
     - find a page with index=0xffffffff, since index>=end, this page won't
       be truncated
    
     - index++, and index become 0
    
     - the page with index=0xffffffff will be found again
    
    The data type of index is unsigned long, so index won't overflow to 0 on
    64 bits architecture in this case, and the dead loop won't happen.
    
    Since truncate_inode_pages_range() is executed with holding lock of
    inode->i_rwsem, any operation related with this lock will be blocked,
    and a hung task will happen, e.g.:
    
      INFO: task truncate_test:3364 blocked for more than 120 seconds.
      ...
         call_rwsem_down_write_failed+0x17/0x30
         generic_file_write_iter+0x32/0x1c0
         ubifs_write_iter+0xcc/0x170
         __vfs_write+0xc4/0x120
         vfs_write+0xb2/0x1b0
         SyS_write+0x46/0xa0
    
    The page with index=0xffffffff added to ->mapping is useless.  Fix this
    by checking the read position before allocating pages.
    
    Link: http://lkml.kernel.org/r/1475151010-40166-1-git-send-email-fangwei1@huawei.com
    Signed-off-by: Wei Fang <fangwei1@huawei.com>
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: Dave Chinner <david@fromorbit.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4428f3bdd8fe8597be1c3580da8d051a0e43b906
Author: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Date:   Fri Oct 7 17:01:10 2016 -0700

    mm/hugetlb: check for reserved hugepages during memory offline
    
    commit 082d5b6b60e9f25e1511557fcfcb21eedd267446 upstream.
    
    In dissolve_free_huge_pages(), free hugepages will be dissolved without
    making sure that there are enough of them left to satisfy hugepage
    reservations.
    
    Fix this by adding a return value to dissolve_free_huge_pages() and
    checking h->free_huge_pages vs.  h->resv_huge_pages.  Note that this may
    lead to the situation where dissolve_free_huge_page() returns an error
    and all free hugepages that were dissolved before that error are lost,
    while the memory block still cannot be set offline.
    
    Fixes: c8721bbb ("mm: memory-hotplug: enable memory hotplug to handle hugepage")
    Link: http://lkml.kernel.org/r/20160926172811.94033-3-gerald.schaefer@de.ibm.com
    Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Acked-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Mike Kravetz <mike.kravetz@oracle.com>
    Cc: "Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>
    Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
    Cc: Rui Teng <rui.teng@linux.vnet.ibm.com>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 23ac701d18c482dcc353299d1b3aeaa1f44bdce6
Author: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Date:   Fri Oct 7 17:01:07 2016 -0700

    mm/hugetlb: fix memory offline with hugepage size > memory block size
    
    commit 2247bb335ab9c40058484cac36ea74ee652f3b7b upstream.
    
    Patch series "mm/hugetlb: memory offline issues with hugepages", v4.
    
    This addresses several issues with hugepages and memory offline.  While
    the first patch fixes a panic, and is therefore rather important, the
    last patch is just a performance optimization.
    
    The second patch fixes a theoretical issue with reserved hugepages,
    while still leaving some ugly usability issue, see description.
    
    This patch (of 3):
    
    dissolve_free_huge_pages() will either run into the VM_BUG_ON() or a
    list corruption and addressing exception when trying to set a memory
    block offline that is part (but not the first part) of a "gigantic"
    hugetlb page with a size > memory block size.
    
    When no other smaller hugetlb page sizes are present, the VM_BUG_ON()
    will trigger directly.  In the other case we will run into an addressing
    exception later, because dissolve_free_huge_page() will not work on the
    head page of the compound hugetlb page which will result in a NULL
    hstate from page_hstate().
    
    To fix this, first remove the VM_BUG_ON() because it is wrong, and then
    use the compound head page in dissolve_free_huge_page().  This means
    that an unused pre-allocated gigantic page that has any part of itself
    inside the memory block that is going offline will be dissolved
    completely.  Losing an unused gigantic hugepage is preferable to failing
    the memory offline, for example in the situation where a (possibly
    faulty) memory DIMM needs to go offline.
    
    Fixes: c8721bbb ("mm: memory-hotplug: enable memory hotplug to handle hugepage")
    Link: http://lkml.kernel.org/r/20160926172811.94033-2-gerald.schaefer@de.ibm.com
    Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Acked-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Mike Kravetz <mike.kravetz@oracle.com>
    Cc: "Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>
    Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
    Cc: Rui Teng <rui.teng@linux.vnet.ibm.com>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 95b17cb3a42a57ac43af6e54b8f0609778d6f615
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Wed Oct 5 22:49:30 2016 -0700

    Input: elantech - add Fujitsu Lifebook E556 to force crc_enabled
    
    commit 62837b3c1a95535d1a287c9c8c6563bbd8d37033 upstream.
    
    Another Lifebook machine that needs the same quirk as other similar
    models to make the driver working.
    
    Also let's reorder elantech_dmi_force_crc_enabled list so LIfebook enries
    are in alphabetical order.
    
    Reported-by: William Linna <william.linna@gmail.com>
    Tested-by: William Linna <william.linna@gmail.com>
    Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 00a05de9ae402f3408fe7fb43fb5654c435831ed
Author: Bart Van Assche <bart.vanassche@sandisk.com>
Date:   Mon Sep 26 12:58:49 2016 -0700

    IB/srp: Fix infinite loop when FMR sg[0].offset != 0
    
    commit 681cc3608355737c1effebc8145f95c8c3344bc3 upstream.
    
    Avoid that mapping an sg-list in which the first element has a
    non-zero offset triggers an infinite loop when using FMR. This
    patch makes the FMR mapping code similar to that of ib_sg_to_pages().
    
    Note: older Mellanox HCAs do not support non-zero offsets for FMR.
    See also commit 8c4037b501ac ("IB/srp: always avoid non-zero offsets
    into an FMR").
    
    Reported-by: Alex Estrin <alex.estrin@intel.com>
    Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3c54629c642f3b11dd33e412b9519091b5bb3ede
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Fri Oct 7 10:40:59 2016 -0700

    metag: Only define atomic_dec_if_positive conditionally
    
    commit 35d04077ad96ed33ceea2501f5a4f1eacda77218 upstream.
    
    The definition of atomic_dec_if_positive() assumes that
    atomic_sub_if_positive() exists, which is only the case if
    metag specific atomics are used. This results in the following
    build error when trying to build metag1_defconfig.
    
    kernel/ucount.c: In function 'dec_ucount':
    kernel/ucount.c:211: error:
            implicit declaration of function 'atomic_sub_if_positive'
    
    Moving the definition of atomic_dec_if_positive() into the metag
    conditional code fixes the problem.
    
    Fixes: 6006c0d8ce94 ("metag: Atomics, locks and bitops")
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8647e797b4063c12e58370594acd376a71726f60
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Oct 6 04:13:18 2016 +0900

    netlink: do not enter direct reclaim from netlink_dump()
    
    commit d35c99ff77ecb2eb239731b799386f3b3637a31e upstream.
    
    Since linux-3.15, netlink_dump() can use up to 16384 bytes skb
    allocations.
    
    Due to struct skb_shared_info ~320 bytes overhead, we end up using
    order-3 (on x86) page allocations, that might trigger direct reclaim and
    add stress.
    
    The intent was really to attempt a large allocation but immediately
    fallback to a smaller one (order-1 on x86) in case of memory stress.
    
    On recent kernels (linux-4.4), we can remove __GFP_DIRECT_RECLAIM to
    meet the goal. Old kernels would need to remove __GFP_WAIT
    
    While we are at it, since we do an order-3 allocation, allow to use
    all the allocated bytes instead of 16384 to reduce syscalls during
    large dumps.
    
    iproute2 already uses 32KB recvmsg() buffer sizes.
    
    Alexei provided an initial patch downsizing to SKB_WITH_OVERHEAD(16384)
    
    Fixes: 9063e21fb026 ("netlink: autosize skb lengthes")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Alexei Starovoitov <ast@kernel.org>
    Cc: Greg Thelen <gthelen@google.com>
    Reviewed-by: Greg Rose <grose@lightfleet.com>
    Acked-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16:
     - Adjust context
     - Mask out __GFP_WAIT, as suggested]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 19cf51e772dbd13e5021cd0b8c6c114a81153777
Author: Johannes Weiner <hannes@cmpxchg.org>
Date:   Tue Oct 4 16:58:06 2016 +0200

    mm: filemap: fix mapping->nrpages double accounting in fuse
    
    commit 3ddf40e8c31964b744ff10abb48c8e36a83ec6e7 upstream.
    
    Commit 22f2ac51b6d6 ("mm: workingset: fix crash in shadow node shrinker
    caused by replace_page_cache_page()") switched replace_page_cache() from
    raw radix tree operations to page_cache_tree_insert() but didn't take
    into account that the latter function, unlike the raw radix tree op,
    handles mapping->nrpages.  As a result, that counter is bumped for each
    page replacement rather than balanced out even.
    
    The mapping->nrpages counter is used to skip needless radix tree walks
    when invalidating, truncating, syncing inodes without pages, as well as
    statistics for userspace.  Since the error is positive, we'll do more
    page cache tree walks than necessary; we won't miss a necessary one.
    And we'll report more buffer pages to userspace than there are.  The
    error is limited to fuse inodes.
    
    Fixes: 22f2ac51b6d6 ("mm: workingset: fix crash in shadow node shrinker caused by replace_page_cache_page()")
    Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Miklos Szeredi <miklos@szeredi.hu>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c3fa800fe93510717471914ecc499269c89746f8
Author: Justin Maggard <jmaggard10@gmail.com>
Date:   Tue Oct 4 13:17:58 2016 -0700

    async_pq_val: fix DMA memory leak
    
    commit c84750906b4818d4929fbf73a4ae6c113b94f52b upstream.
    
    Add missing dmaengine_unmap_put(), so we don't OOM during RAID6 sync.
    
    Fixes: 1786b943dad0 ("async_pq_val: convert to dmaengine_unmap_data")
    Signed-off-by: Justin Maggard <jmaggard@netgear.com>
    Reviewed-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 315d5cc06a0d6b4eb1900e94e3bee45c42124d3c
Author: Lu Baolu <baolu.lu@linux.intel.com>
Date:   Thu Aug 11 10:39:03 2016 +0800

    mfd: rtsx_usb: Avoid setting ucr->current_sg.status
    
    commit 8dcc5ff8fcaf778bb57ab4448fedca9e381d088f upstream.
    
    Member "status" of struct usb_sg_request is managed by usb core. A
    spin lock is used to serialize the change of it. The driver could
    check the value of req->status, but should avoid changing it without
    the hold of the spinlock. Otherwise, it could cause race or error
    in usb core.
    
    This patch could be backported to stable kernels with version later
    than v3.14.
    
    Cc: Alan Stern <stern@rowland.harvard.edu>
    Cc: Roger Tseng <rogerable@realtek.com>
    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0de782facf8117f70a07c77fa7815ebef5a04703
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Aug 4 08:26:56 2016 +0300

    mfd: 88pm80x: Double shifting bug in suspend/resume
    
    commit 9a6dc644512fd083400a96ac4a035ac154fe6b8d upstream.
    
    set_bit() and clear_bit() take the bit number so this code is really
    doing "1 << (1 << irq)" which is a double shift bug.  It's done
    consistently so it won't cause a problem unless "irq" is more than 4.
    
    Fixes: 70c6cce04066 ('mfd: Support 88pm80x in 80x driver')
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit cd8ce3b27fcad92527cbcc40cfdb3e28ed703c63
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Fri Jul 29 21:29:15 2016 +0200

    mfd: wm8350-i2c: Make sure the i2c regmap functions are compiled
    
    commit 88003fb10f1fc606e1704611c62ceae95fd1d7da upstream.
    
    This fixes a compile failure:
    
            drivers/built-in.o: In function `wm8350_i2c_probe':
            core.c:(.text+0x828b0): undefined reference to `__devm_regmap_init_i2c'
            Makefile:953: recipe for target 'vmlinux' failed
    
    Fixes: 52b461b86a9f ("mfd: Add regmap cache support for wm8350")
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4e47ea8e9a012c3fa3602af88ef1ac01a2dab9a1
Author: Gavin Shan <gwshan@linux.vnet.ibm.com>
Date:   Tue Aug 2 14:10:32 2016 +1000

    powerpc/powernv: Use CPU-endian PEST in pnv_pci_dump_p7ioc_diag_data()
    
    commit 5adaf8629b193f185ca5a1665b9e777a0579f518 upstream.
    
    This fixes the warnings reported from sparse:
    
      pci.c:312:33: warning: restricted __be64 degrades to integer
      pci.c:313:33: warning: restricted __be64 degrades to integer
    
    Fixes: cee72d5bb489 ("powerpc/powernv: Display diag data on p7ioc EEH errors")
    Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5af075a544d0706c8494d4f0c92069334a4e7898
Author: Guilherme G Piccoli <gpiccoli@linux.vnet.ibm.com>
Date:   Mon Oct 3 00:31:12 2016 -0700

    i40e: avoid NULL pointer dereference and recursive errors on early PCI error
    
    commit edfc23ee3e0ebbb6713d7574ab1b00abff178f6c upstream.
    
    Although rare, it's possible to hit PCI error early on device
    probe, meaning possibly some structs are not entirely initialized,
    and some might even be completely uninitialized, leading to NULL
    pointer dereference.
    
    The i40e driver currently presents a "bad" behavior if device hits
    such early PCI error: firstly, the struct i40e_pf might not be
    attached to pci_dev yet, leading to a NULL pointer dereference on
    access to pf->state.
    
    Even checking if the struct is NULL and avoiding the access in that
    case isn't enough, since the driver cannot recover from PCI error
    that early; in our experiments we saw multiple failures on kernel
    log, like:
    
      [549.664] i40e 0007:01:00.1: Initial pf_reset failed: -15
      [549.664] i40e: probe of 0007:01:00.1 failed with error -15
      [...]
      [871.644] i40e 0007:01:00.1: The driver for the device stopped because the
      device firmware failed to init. Try updating your NVM image.
      [871.644] i40e: probe of 0007:01:00.1 failed with error -32
      [...]
      [872.516] i40e 0007:01:00.0: ARQ: Unknown event 0x0000 ignored
    
    Between the first probe failure (error -15) and the second (error -32)
    another PCI error happened due to the first bad probe. Also, driver
    started to flood console with those ARQ event messages.
    
    This patch will prevent these issues by allowing error recovery
    mechanism to remove the failed device from the system instead of
    trying to recover from early PCI errors during device probe.
    
    Signed-off-by: Guilherme G Piccoli <gpiccoli@linux.vnet.ibm.com>
    Acked-by: Jacob Keller <jacob.e.keller@intel.com>
    Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fbcf2477f6059f7928d1fdca541654ff7966bac5
Author: Richard Weinberger <richard@nod.at>
Date:   Wed Aug 24 14:36:15 2016 +0200

    ubi: Fix Fastmap's update_vol()
    
    commit f7d11b33d4e8cedf19367c09b891bbc705163976 upstream.
    
    Usually Fastmap is free to consider every PEB in one of the pools
    as newer than the existing PEB. Since PEBs in a pool are by definition
    newer than everything else.
    But update_vol() missed the case that a pool can contain more than
    one candidate.
    
    Fixes: dbb7d2a88d ("UBI: Add fastmap core")
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2092c83cb126bde378d809ba0633b1a0275a398c
Author: Richard Weinberger <richard@nod.at>
Date:   Wed Aug 24 14:36:14 2016 +0200

    ubi: Fix races around ubi_refill_pools()
    
    commit 2e8f08deabbc7eefe4c5838aaa6aa9a23a8acf2e upstream.
    
    When writing a new Fastmap the first thing that happens
    is refilling the pools in memory.
    At this stage it is possible that new PEBs from the new pools
    get already claimed and written with data.
    If this happens before the new Fastmap data structure hits the
    flash and we face power cut the freshly written PEB will not
    scanned and unnoticed.
    
    Solve the issue by locking the pools until Fastmap is written.
    
    Fixes: dbb7d2a88d ("UBI: Add fastmap core")
    Signed-off-by: Richard Weinberger <richard@nod.at>
    [bwh: Backported to 3.16:
     - Adjust filename, context, indentation
     - s/ubi->fm_eba_sem/ubi->fm_sem/]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a99718155783ae8a715f11ea2ca8ea040654beff
Author: Richard Weinberger <richard@nod.at>
Date:   Wed Aug 24 14:36:13 2016 +0200

    ubi: Deal with interrupted erasures in WL
    
    commit 2365418879e9abf12ea9def7f9f3caf0dfa7ffb0 upstream.
    
    When Fastmap is used we can face here an -EBADMSG
    since Fastmap cannot know about unmaps.
    If the erasure was interrupted the PEB may show ECC
    errors and UBI would go to ro-mode as it assumes
    that the PEB was check during attach time, which is
    not the case with Fastmap.
    
    Fixes: dbb7d2a88d ("UBI: Add fastmap core")
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d6983e15fa7a6ab88b2ac9ca723fbb407e35185c
Author: Boris Brezillon <boris.brezillon@free-electrons.com>
Date:   Fri Sep 16 16:59:12 2016 +0200

    UBI: fastmap: scrub PEB when bitflips are detected in a free PEB EC header
    
    commit ecbfa8eabae9cd73522d1d3d15869703c263d859 upstream.
    
    scan_pool() does not mark the PEB for scrubing when bitflips are
    detected in the EC header of a free PEB (VID header region left to
    0xff).
    Make sure we scrub the PEB in this case.
    
    Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
    Fixes: dbb7d2a88d2a ("UBI: Add fastmap core")
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 273f111f0e29eef958dd50d9fa71e87d8a8a4ffe
Author: Wei Yongjun <weiyj.lk@gmail.com>
Date:   Sat Oct 1 00:38:08 2016 +0800

    staging: rtl8188eu: fix double unlock error in rtw_resume_process()
    
    commit 23bf40424a0f641ca7ff4225add4aa592086bdd5 upstream.
    
    Fix following static checker warning:
        drivers/staging/rtl8188eu/os_dep/usb_intf.c:311 rtw_resume_process()
        error: double unlock 'mutex:&pwrpriv->mutex_lock'
    
    Fixes: eaf47b713b60 ("staging: rtl8188eu: fix missing unlock on error in rtw_resume_process()")
    Reported-By: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Wei Yongjun <weiyj.lk@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.16:
     - Adjust context
     - Unlock pwrctrl_priv::lock]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0a43549f8249868c3dad4e646caa98df6f41127c
Author: Wei Yongjun <weiyongjun1@huawei.com>
Date:   Fri Aug 26 14:45:05 2016 +0000

    staging: rtl8188eu: fix missing unlock on error in rtw_resume_process()
    
    commit eaf47b713b602e7d0129ed8d18d2818246a17e49 upstream.
    
    Add the missing unlock before return from function
    rtw_resume_process() in the error handling case.
    
    Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.16:
     - Adjust context
     - Unlock pwrctrl_priv::lock]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 615e796a8828fc251b2902fbe5ba48b952e25386
Author: Ondrej Mosnáček <omosnacek@gmail.com>
Date:   Fri Sep 23 10:47:32 2016 +0200

    crypto: gcm - Fix IV buffer size in crypto_gcm_setkey
    
    commit 50d2e6dc1f83db0563c7d6603967bf9585ce934b upstream.
    
    The cipher block size for GCM is 16 bytes, and thus the CTR transform
    used in crypto_gcm_setkey() will also expect a 16-byte IV. However,
    the code currently reserves only 8 bytes for the IV, causing
    an out-of-bounds access in the CTR transform. This patch fixes
    the issue by setting the size of the IV buffer to 16 bytes.
    
    Fixes: 84c911523020 ("[CRYPTO] gcm: Add support for async ciphers")
    Signed-off-by: Ondrej Mosnacek <omosnacek@gmail.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit cbe308a4471f9dc65d1059bd2f9e242ddcf4b548
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Sat Oct 1 07:32:32 2016 +0200

    fuse: listxattr: verify xattr list
    
    commit cb3ae6d25a5471be62bfe6ac1fccc0e91edeaba0 upstream.
    
    Make sure userspace filesystem is returning a well formed list of xattr
    names (zero or more nonzero length, null terminated strings).
    
    [Michael Theall: only verify in the nonzero size case]
    
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    [bwh: Backported to 3.16: adjust context, indentation]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2787db9e6b9600dab0e0aae39d197a3d21c890b5
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Sat Oct 1 07:32:32 2016 +0200

    fuse: fix killing s[ug]id in setattr
    
    commit a09f99eddef44035ec764075a37bace8181bec38 upstream.
    
    Fuse allowed VFS to set mode in setattr in order to clear suid/sgid on
    chown and truncate, and (since writeback_cache) write.  The problem with
    this is that it'll potentially restore a stale mode.
    
    The poper fix would be to let the filesystems do the suid/sgid clearing on
    the relevant operations.  Possibly some are already doing it but there's no
    way we can detect this.
    
    So fix this by refreshing and recalculating the mode.  Do this only if
    ATTR_KILL_S[UG]ID is set to not destroy performance for writes.  This is
    still racy but the size of the window is reduced.
    
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 03f23d54b16fb39d42dafe806228f9adb8cb30ea
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Sat Oct 1 07:32:32 2016 +0200

    fuse: invalidate dir dentry after chmod
    
    commit 5e2b8828ff3d79aca8c3a1730652758753205b61 upstream.
    
    Without "default_permissions" the userspace filesystem's lookup operation
    needs to perform the check for search permission on the directory.
    
    If directory does not allow search for everyone (this is quite rare) then
    userspace filesystem has to set entry timeout to zero to make sure
    permissions are always performed.
    
    Changing the mode bits of the directory should also invalidate the
    (previously cached) dentry to make sure the next lookup will have a chance
    of updating the timeout, if needed.
    
    Reported-by: Jean-Pierre André <jean-pierre.andre@wanadoo.fr>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e8e71d678bae3c909d04c7939a293eb8d914a6a0
Author: Sascha Silbe <silbe@linux.vnet.ibm.com>
Date:   Tue Sep 20 19:09:07 2016 +0200

    s390/con3270: fix insufficient space padding
    
    commit 6cd997db911f28f2510b771691270c52b63ed2e6 upstream.
    
    con3270 contains an optimisation that reduces the amount of data to be
    transmitted to the 3270 terminal by putting a Repeat to Address (RA)
    order into the data stream. The RA order itself takes up space, so
    con3270 only uses it if there's enough space left in the line
    buffer. Otherwise it just pads out the line manually.
    
    For lines that were _just_ short enough that the RA order still fit in
    the line buffer, the line was instead padded with an insufficient
    amount of spaces. This was caused by examining the size of the
    allocated line buffer rather than the length of the string to be
    displayed.
    
    For con3270_cline_end(), we just compare against the line length. For
    con3270_update_string() however that isn't available anymore, so we
    check whether the Repeat to Address order is present.
    
    Fixes: f51320a5 ("[PATCH] s390: new 3270 driver.") (tglx/history.git)
    Tested-by: Jing Liu <liujbjl@linux.vnet.ibm.com>
    Tested-by: Yang Chen <bjcyang@linux.vnet.ibm.com>
    Signed-off-by: Sascha Silbe <silbe@linux.vnet.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 87221677bd7c4ce27b6dc0300dfce56afa360ac5
Author: Sascha Silbe <silbe@linux.vnet.ibm.com>
Date:   Thu Aug 11 21:34:54 2016 +0200

    s390/con3270: fix use of uninitialised data
    
    commit c14f2aac7aa147861793eed9f41f91dd530f0be1 upstream.
    
    con3270 contains an optimisation that reduces the amount of data to be
    transmitted to the 3270 terminal by putting a Repeat to Address (RA)
    order into the data stream. The RA order itself takes up space, so
    con3270 only uses it if there's enough space left in the line
    buffer. Otherwise it just pads out the line manually.
    
    For lines too long to include the RA order, one byte was left
    uninitialised. This was caused by an off-by-one bug in the loop that
    pads out the line. Since the buffer is allocated from a common pool,
    the single byte left uninitialised contained some previous buffer
    content. Usually this was just a space or some character (which can
    result in clutter but is otherwise harmless). Sometimes, however, it
    was a Repeat to Address order, messing up the entire screen layout and
    causing the display to send the entire buffer content on every
    keystroke.
    
    Fixes: f51320a5 ("[PATCH] s390: new 3270 driver.") (tglx/history.git)
    Reported-by: Liu Jing <liujbjl@linux.vnet.ibm.com>
    Tested-by: Jing Liu <liujbjl@linux.vnet.ibm.com>
    Tested-by: Yang Chen <bjcyang@linux.vnet.ibm.com>
    Signed-off-by: Sascha Silbe <silbe@linux.vnet.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c9b2f81ee805fe254a49b5d542851b816000b02c
Author: gmail <yngsion@gmail.com>
Date:   Fri Sep 30 01:33:37 2016 -0400

    ext4: release bh in make_indexed_dir
    
    commit e81d44778d1d57bbaef9e24c4eac7c8a7a401d40 upstream.
    
    The commit 6050d47adcad: "ext4: bail out from make_indexed_dir() on
    first error" could end up leaking bh2 in the error path.
    
    [ Also avoid renaming bh2 to bh, which just confuses things --tytso ]
    
    Signed-off-by: yangsheng <yngsion@gmail.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a35222e8ca8ee8603281008692a4cc2d6eab1624
Author: Anton Blanchard <anton@samba.org>
Date:   Sun Sep 25 17:16:53 2016 +1000

    powerpc/vdso64: Use double word compare on pointers
    
    commit 5045ea37377ce8cca6890d32b127ad6770e6dce5 upstream.
    
    __kernel_get_syscall_map() and __kernel_clock_getres() use cmpli to
    check if the passed in pointer is non zero. cmpli maps to a 32 bit
    compare on binutils, so we ignore the top 32 bits.
    
    A simple test case can be created by passing in a bogus pointer with
    the bottom 32 bits clear. Using a clk_id that is handled by the VDSO,
    then one that is handled by the kernel shows the problem:
    
      printf("%d\n", clock_getres(CLOCK_REALTIME, (void *)0x100000000));
      printf("%d\n", clock_getres(CLOCK_BOOTTIME, (void *)0x100000000));
    
    And we get:
    
      0
      -1
    
    The bigger issue is if we pass a valid pointer with the bottom 32 bits
    clear, in this case we will return success but won't write any data
    to the pointer.
    
    I stumbled across this issue because the LLVM integrated assembler
    doesn't accept cmpli with 3 arguments. Fix this by converting them to
    cmpldi.
    
    Fixes: a7f290dad32e ("[PATCH] powerpc: Merge vdso's and add vdso support to 32 bits kernel")
    Signed-off-by: Anton Blanchard <anton@samba.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4e8ad3f9850d7c9b69c49e6e257c40c8bb2b57f2
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Sep 27 14:51:53 2016 -0400

    drm/radeon/si/dpm: fix phase shedding setup
    
    commit 427920292b00474d978d632bc03a8e4e50029af3 upstream.
    
    Used the wrong index to setup the phase shedding mask.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    [bwh: Backported to 3.16: adjust context, indentation]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1da7cdab3e775fbff95defe3eb16e3acf58baae1
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Sep 28 11:48:44 2016 +0200

    Revert "usbtmc: convert to devm_kzalloc"
    
    commit ab21b63e8aedfc73565dd9cdd51eb338341177cb upstream.
    
    This reverts commit e6c7efdcb76f11b04e3d3f71c8d764ab75c9423b.
    
    Turns out it was totally wrong.  The memory is supposed to be bound to
    the kref, as the original code was doing correctly, not the
    device/driver binding as the devm_kzalloc() would cause.
    
    This fixes an oops when read would be called after the device was
    unbound from the driver.
    
    Reported-by: Ladislav Michl <ladis@linux-mips.org>
    Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 38442f71bd115c482b88483d96c9318a29432212
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Thu Sep 22 13:39:18 2016 -0400

    NFSv4: Open state recovery must account for file permission changes
    
    commit 304020fe48c6c7fff8b5a38f382b54404f0f79d3 upstream.
    
    If the file permissions change on the server, then we may not be able to
    recover open state. If so, we need to ensure that we mark the file
    descriptor appropriately.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Tested-by: Oleg Drokin <green@linuxhacker.ru>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 32ce2fe9a4d622568e952910160a44d8bfc74afe
Author: Kyle Jones <kyle@kf5jwc.us>
Date:   Fri Sep 23 13:28:37 2016 -0500

    USB: serial: cp210x: Add ID for a Juniper console
    
    commit decc5360f23e9efe0252094f47f57f254dcbb3a9 upstream.
    
    Signed-off-by: Kyle Jones <kyle@kf5jwc.us>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6335a74179221e4260aa335585ef8bf5877e64ad
Author: Thomas Huth <thuth@redhat.com>
Date:   Wed Sep 21 15:06:45 2016 +0200

    KVM: PPC: Book3s PR: Allow access to unprivileged MMCR2 register
    
    commit fa73c3b25bd8d0d393dc6109a1dba3c2aef0451e upstream.
    
    The MMCR2 register is available twice, one time with number 785
    (privileged access), and one time with number 769 (unprivileged,
    but it can be disabled completely). In former times, the Linux
    kernel was using the unprivileged register 769 only, but since
    commit 8dd75ccb571f3c92c ("powerpc: Use privileged SPR number
    for MMCR2"), it uses the privileged register 785 instead.
    The KVM-PR code then of course also switched to use the SPR 785,
    but this is causing older guest kernels to crash, since these
    kernels still access 769 instead. So to support older kernels
    with KVM-PR again, we have to support register 769 in KVM-PR, too.
    
    Fixes: 8dd75ccb571f3c92c48014b3dabd3d51a115ab41
    Signed-off-by: Thomas Huth <thuth@redhat.com>
    Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2f0dd849775c8193fcdf10804ed661d5b23024b7
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Jul 14 13:15:46 2016 +0300

    KVM: PPC: BookE: Fix a sanity check
    
    commit ac0e89bb4744d3882ccd275f2416d9ce22f4e1e7 upstream.
    
    We use logical negate where bitwise negate was intended.  It means that
    we never return -EINVAL here.
    
    Fixes: ce11e48b7fdd ('KVM: PPC: E500: Add userspace debug stub support')
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Alexander Graf <agraf@suse.de>
    Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 469a46b41efd3fa7656f31f2bae2674e8e579f06
Author: Paul Mackerras <paulus@ozlabs.org>
Date:   Thu Sep 15 13:42:52 2016 +1000

    KVM: PPC: Book3S: Treat VTB as a per-subcore register, not per-thread
    
    commit 88b02cf97bb7e742db3e31671d54177e3e19fd89 upstream.
    
    POWER8 has one virtual timebase (VTB) register per subcore, not one
    per CPU thread.  The HV KVM code currently treats VTB as a per-thread
    register, which can lead to spurious soft lockup messages from guests
    which use the VTB as the time source for the soft lockup detector.
    (CPUs before POWER8 did not have the VTB register.)
    
    For HV KVM, this fixes the problem by making only the primary thread
    in each virtual core save and restore the VTB value.  With this,
    the VTB state becomes part of the kvmppc_vcore structure.  This
    also means that "piggybacking" of multiple virtual cores onto one
    subcore is not possible on POWER8, because then the virtual cores
    would share a single VTB register.
    
    PR KVM emulates a VTB register, which is per-vcpu because PR KVM
    has no notion of CPU threads or SMT.  For PR KVM we move the VTB
    state into the kvmppc_vcpu_book3s struct.
    
    Reported-by: Thomas Huth <thuth@redhat.com>
    Tested-by: Thomas Huth <thuth@redhat.com>
    Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
    [bwh: Backported to 3.16:
     - Adjust filenames, context
     - Drop changes to kvmppc_core_emulate_mfspr_pr(), can_piggyback_subcore(),
       kvmppc_copy_from_svcpu()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 041ec31435e788f8aa9c32537de657d73cd89b27
Author: Daniel Glöckner <dg@emlix.com>
Date:   Tue Aug 30 14:17:30 2016 +0200

    mmc: block: don't use CMD23 with very old MMC cards
    
    commit 0ed50abb2d8fc81570b53af25621dad560cd49b3 upstream.
    
    CMD23 aka SET_BLOCK_COUNT was introduced with MMC v3.1.
    Older versions of the specification allowed to terminate
    multi-block transfers only with CMD12.
    
    The patch fixes the following problem:
    
      mmc0: new MMC card at address 0001
      mmcblk0: mmc0:0001 SDMB-16 15.3 MiB
      mmcblk0: timed out sending SET_BLOCK_COUNT command, card status 0x400900
      ...
      blk_update_request: I/O error, dev mmcblk0, sector 0
      Buffer I/O error on dev mmcblk0, logical block 0, async page read
       mmcblk0: unable to read partition table
    
    Signed-off-by: Daniel Glöckner <dg@emlix.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bfd041f0c81082fe5d14102b59130eebb5358587
Author: Nicholas Mc Guire <hofrat@osadl.org>
Date:   Mon Jul 25 19:59:23 2016 +0200

    mmc: moxart: fix wait_for_completion_interruptible_timeout return variable type
    
    commit 41f469cac2663a41a7b0c84cb94e8f7024385ae4 upstream.
    
    wait_for_completion_timeout_interruptible returns long not unsigned long
    so dma_time, which is used exclusively here, is changed to long.
    
    Fixes: 1b66e94e6b99 ("mmc: moxart: Add MOXA ART SD/MMC driver")
    Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e38f2bfcbf18dc44ce40cff46472bee841deb135
Author: Hui Wang <hui.wang@canonical.com>
Date:   Mon Sep 26 10:59:38 2016 +0800

    ALSA: hda - Adding one more ALC255 pin definition for headset problem
    
    commit 392c9da24a994f238c5d7ea611c6245be4617014 upstream.
    
    We have two new Dell laptop models, they have the same ALC255 pin
    definition, but not in the pin quirk table yet, as a result, the
    headset microphone can't work. After adding the definition in the
    table, the headset microphone works well.
    
    Signed-off-by: Hui Wang <hui.wang@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bd18898a21fbbcc7e578fcd75024fb39d881d21b
Author: Jan Remmet <j.remmet@phytec.de>
Date:   Fri Sep 23 10:52:00 2016 +0200

    regulator: tps65910: Work around silicon erratum SWCZ010
    
    commit 8f9165c981fed187bb483de84caf9adf835aefda upstream.
    
    http://www.ti.com/lit/pdf/SWCZ010:
      DCDC o/p voltage can go higher than programmed value
    
    Impact:
    VDDI, VDD2, and VIO output programmed voltage level can go higher than
    expected or crash, when coming out of PFM to PWM mode or using DVFS.
    
    Description:
    When DCDC CLK SYNC bits are 11/01:
    * VIO 3-MHz oscillator is the source clock of the digital core and input
      clock of VDD1 and VDD2
    * Turn-on of VDD1 and VDD2 HSD PFETis synchronized or at a constant
      phase shift
    * Current pulled though VCC1+VCC2 is Iload(VDD1) + Iload(VDD2)
    * The 3 HSD PFET will be turned-on at the same time, causing the highest
      possible switching noise on the application. This noise level depends
      on the layout, the VBAT level, and the load current. The noise level
      increases with improper layout.
    
    When DCDC CLK SYNC bits are 00:
    * VIO 3-MHz oscillator is the source clock of digital core
    * VDD1 and VDD2 are running on their own 3-MHz oscillator
    * Current pulled though VCC1+VCC2 average of Iload(VDD1) + Iload(VDD2)
    * The switching noise of the 3 SMPS will be randomly spread over time,
      causing lower overall switching noise.
    
    Workaround:
    Set DCDCCTRL_REG[1:0]= 00.
    
    Signed-off-by: Jan Remmet <j.remmet@phytec.de>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ea1c052896d88cbc8fd777998cc6ae7c8865f0d2
Author: Bart Van Assche <bart.vanassche@sandisk.com>
Date:   Fri Sep 23 09:07:56 2016 -0700

    blkcg: Annotate blkg_hint correctly
    
    commit 55679c8d23d191c24ad133abc5647e3054ca8de1 upstream.
    
    Avoid that sparse complains about blkg_hint manipulations.
    
    Fixes: a637120e4902 ("blkcg: use radix tree to index blkgs from blkcg")
    Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
    Acked-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    [bwh: Backported to 3.16: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit cd2abef604580d2864af4428da2f9c79c888fa17
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue Sep 13 10:52:50 2016 -0400

    svcrdma: Tail iovec leaves an orphaned DMA mapping
    
    commit cace564f8b6260e806f5e28d7f192fd0e0c603ed upstream.
    
    The ctxt's count field is overloaded to mean the number of pages in
    the ctxt->page array and the number of SGEs in the ctxt->sge array.
    Typically these two numbers are the same.
    
    However, when an inline RPC reply is constructed from an xdr_buf
    with a tail iovec, the head and tail often occupy the same page,
    but each are DMA mapped independently. In that case, ->count equals
    the number of pages, but it does not equal the number of SGEs.
    There's one more SGE, for the tail iovec. Hence there is one more
    DMA mapping than there are pages in the ctxt->page array.
    
    This isn't a real problem until the server's iommu is enabled. Then
    each RPC reply that has content in that iovec orphans a DMA mapping
    that consists of real resources.
    
    krb5i and krb5p always populate that tail iovec. After a couple
    million sent krb5i/p RPC replies, the NFS server starts behaving
    erratically. Reboot is needed to clear the problem.
    
    Fixes: 9d11b51ce7c1 ("svcrdma: Fix send_reply() scatter/gather set-up")
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    [bwh: Backported to 3.16:
     - Adjust context
     - Drop changes to svc_rdma_bc_sendto()
     - s/xprt->sc_pd->local_dma_lkey/xprt->sc_dma_lkey/
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4f00b3d78eaaf05193567df939b19aae3c708976
Author: Laura Garcia Liebana <nevola@gmail.com>
Date:   Wed Sep 14 15:00:02 2016 +0200

    netfilter: nf_tables: validate maximum value of u32 netlink attributes
    
    commit 36b701fae12ac763a568037e4e7c96b5727a8b3e upstream.
    
    Fetch value and validate u32 netlink attribute. This validation is
    usually required when the u32 netlink attributes are being stored in a
    field whose size is smaller.
    
    This patch revisits 4da449ae1df9 ("netfilter: nft_exthdr: Add size check
    on u8 nft_exthdr attributes").
    
    Fixes: 96518518cc41 ("netfilter: add nftables")
    Suggested-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Laura Garcia Liebana <nevola@gmail.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit aaf2bb422c25859fad0a66fb722bc47866004ab8
Author: Laura Garcia Liebana <nevola@gmail.com>
Date:   Tue Aug 9 20:46:16 2016 +0200

    netfilter: nft_exthdr: Add size check on u8 nft_exthdr attributes
    
    commit 4da449ae1df9cfeb167e78f250b250eff64bc65e upstream.
    
    Fix the direct assignment of offset and length attributes included in
    nft_exthdr structure from u32 data to u8.
    
    Signed-off-by: Laura Garcia Liebana <nevola@gmail.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2c40ffcb74ef7c56e9ba007002f9200201167406
Author: Anssi Hannula <anssi.hannula@iki.fi>
Date:   Fri Sep 23 06:43:47 2016 +0300

    ALSA: usb-audio: Extend DragonFly dB scale quirk to cover other variants
    
    commit eb1a74b7bea17eea31915c4f76385cefe69d9795 upstream.
    
    The DragonFly quirk added in 42e3121d90f4 ("ALSA: usb-audio: Add a more
    accurate volume quirk for AudioQuest DragonFly") applies a custom dB map
    on the volume control when its range is reported as 0..50 (0 .. 0.2dB).
    
    However, there exists at least one other variant (hw v1.0c, as opposed
    to the tested v1.2) which reports a different non-sensical volume range
    (0..53) and the custom map is therefore not applied for that device.
    
    This results in all of the volume change appearing close to 100% on
    mixer UIs that utilize the dB TLV information.
    
    Add a fallback case where no dB TLV is reported at all if the control
    range is not 0..50 but still 0..N where N <= 1000 (3.9 dB). Also
    restrict the quirk to only apply to the volume control as there is also
    a mute control which would match the check otherwise.
    
    Fixes: 42e3121d90f4 ("ALSA: usb-audio: Add a more accurate volume quirk for AudioQuest DragonFly")
    Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
    Reported-by: David W <regulars@d-dub.org.uk>
    Tested-by: David W <regulars@d-dub.org.uk>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 89b1e6c4a5fe244a4a96c1a560b29720516fa328
Author: Russell Currey <ruscur@russell.cc>
Date:   Mon Sep 12 14:17:22 2016 +1000

    powerpc/eeh: Null check uses of eeh_pe_bus_get
    
    commit 04fec21c06e35b169a83e75a84a015ab4606bf5e upstream.
    
    eeh_pe_bus_get() can return NULL if a PCI bus isn't found for a given PE.
    Some callers don't check this, and can cause a null pointer dereference
    under certain circumstances.
    
    Fix this by checking NULL everywhere eeh_pe_bus_get() is called.
    
    Fixes: 8a6b1bc70dbb ("powerpc/eeh: EEH core to handle special event")
    Signed-off-by: Russell Currey <ruscur@russell.cc>
    Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1caebfb554c8c667d4d32700990373c954d6da41
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Sep 19 12:35:22 2016 -0400

    drm/radeon: narrow asic_init for virtualization
    
    commit 884031f0aacf57dad1575f96714efc80de9b19cc upstream.
    
    Only needed on CIK+ due to the way pci reset is handled
    by the GPU.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 95f76fb6b1bf7390891466347448bfe3c00d855c
Author: Jack Morgenstein <jackm@dev.mellanox.co.il>
Date:   Tue Sep 20 14:39:42 2016 +0300

    net/mlx4_core: Fix deadlock when switching between polling and event fw commands
    
    commit a7e1f04905e5b2b90251974dddde781301b6be37 upstream.
    
    When switching from polling-based fw commands to event-based fw
    commands, there is a race condition which could cause a fw command
    in another task to hang: that task will keep waiting for the polling
    sempahore, but may never be able to acquire it. This is due to
    mlx4_cmd_use_events, which "down"s the sempahore back to 0.
    
    During driver initialization, this is not a problem, since no other
    tasks which invoke FW commands are active.
    
    However, there is a problem if the driver switches to polling mode
    and then back to event mode during normal operation.
    
    The "test_interrupts" feature does exactly that.
    Running "ethtool -t <eth device> offline" causes the PF driver to
    temporarily switch to polling mode, and then back to event mode.
    (Note that for VF drivers, such switching is not performed).
    
    Fix this by adding a read-write semaphore for protection when
    switching between modes.
    
    Fixes: 225c7b1feef1 ("IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters")
    Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
    Signed-off-by: Matan Barak <matanb@mellanox.com>
    Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: adjust context, indentation]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b8f011769576d586280da85d36b6c2415ae4b8f4
Author: Kamal Heib <kamalh@mellanox.com>
Date:   Tue Sep 20 14:39:40 2016 +0300

    net/mlx4_en: Fix wrong indentation
    
    commit 57c970c2e8d8772237294bb8a6a25a205448fd96 upstream.
    
    Use tabs instead of spaces before if statement, no functional change.
    
    Fixes: e7c1c2c46201 ("mlx4_en: Added self diagnostics test implementation")
    Signed-off-by: Kamal Heib <kamalh@mellanox.com>
    Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5d1d4fb4ab35b8eebf3b9112c460cb25edb89143
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Sep 19 19:09:51 2016 +0100

    usb: misc: legousbtower: Fix NULL pointer deference
    
    commit 2fae9e5a7babada041e2e161699ade2447a01989 upstream.
    
    This patch fixes a NULL pointer dereference caused by a race codition in
    the probe function of the legousbtower driver. It re-structures the
    probe function to only register the interface after successfully reading
    the board's firmware ID.
    
    The probe function does not deregister the usb interface after an error
    receiving the devices firmware ID. The device file registered
    (/dev/usb/legousbtower%d) may be read/written globally before the probe
    function returns. When tower_delete is called in the probe function
    (after an r/w has been initiated), core dev structures are deleted while
    the file operation functions are still running. If the 0 address is
    mappable on the machine, this vulnerability can be used to create a
    Local Priviege Escalation exploit via a write-what-where condition by
    remapping dev->interrupt_out_buffer in tower_write. A forged USB device
    and local program execution would be required for LPE. The USB device
    would have to delay the control message in tower_probe and accept
    the control urb in tower_open whilst guest code initiated a write to the
    device file as tower_delete is called from the error in tower_probe.
    
    This bug has existed since 2003. Patch tested by emulated device.
    
    Reported-by: James Patrick-Evans <james@jmp-e.com>
    Tested-by: James Patrick-Evans <james@jmp-e.com>
    Signed-off-by: James Patrick-Evans <james@jmp-e.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 497063a28f54ecaa159b61babe937a42ae462903
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Sep 21 14:38:02 2016 +0200

    ALSA: ali5451: Fix out-of-bound position reporting
    
    commit db68577966abc1aeae4ec597b3dcfa0d56e92041 upstream.
    
    The pointer callbacks of ali5451 driver may return the value at the
    boundary occasionally, and it results in the kernel warning like
      snd_ali5451 0000:00:06.0: BUG: , pos = 16384, buffer size = 16384, period size = 1024
    
    It seems that folding the position offset is enough for fixing the
    warning and no ill-effect has been seen by that.
    
    Reported-by: Enrico Mioso <mrkiko.rs@gmail.com>
    Tested-by: Enrico Mioso <mrkiko.rs@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 70e794f9456c4e87e0182bcd65905f5113c2b72a
Author: Pan Xinhui <xinhui.pan@linux.vnet.ibm.com>
Date:   Thu Dec 10 15:30:02 2015 +0800

    powerpc/nvram: Fix an incorrect partition merge
    
    commit 11b7e154b132232535befe51c55db048069c8461 upstream.
    
    When we merge two contiguous partitions whose signatures are marked
    NVRAM_SIG_FREE, We need update prev's length and checksum, then write it
    to nvram, not cur's. So lets fix this mistake now.
    
    Also use memset instead of strncpy to set the partition's name. It's
    more readable if we want to fill up with duplicate chars .
    
    Fixes: fa2b4e54d41f ("powerpc/nvram: Improve partition removal")
    Signed-off-by: Pan Xinhui <xinhui.pan@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 89376f3f174b005550e4a329d4a50c9e662c9ed9
Author: Brian King <brking@linux.vnet.ibm.com>
Date:   Mon Sep 19 08:59:19 2016 -0500

    scsi: ibmvfc: Fix I/O hang when port is not mapped
    
    commit 07d0e9a847401ffd2f09bd450d41644cd090e81d upstream.
    
    If a VFC port gets unmapped in the VIOS, it may not respond with a CRQ
    init complete following H_REG_CRQ. If this occurs, we can end up having
    called scsi_block_requests and not a resulting unblock until the init
    complete happens, which may never occur, and we end up hanging I/O
    requests.  This patch ensures the host action stay set to
    IBMVFC_HOST_ACTION_TGT_DEL so we move all rports into devloss state and
    unblock unless we receive an init complete.
    
    Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
    Acked-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 73a5c7e718ea64a6838ff72321d386f93924dfcb
Author: Baoquan He <bhe@redhat.com>
Date:   Thu Sep 15 16:50:52 2016 +0800

    iommu/amd: Free domain id when free a domain of struct dma_ops_domain
    
    commit c3db901c54466a9c135d1e6e95fec452e8a42666 upstream.
    
    The current code missed freeing domain id when free a domain of
    struct dma_ops_domain.
    
    Signed-off-by: Baoquan He <bhe@redhat.com>
    Fixes: ec487d1a110a ('x86, AMD IOMMU: add domain allocation and deallocation functions')
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 353c74c7f50084863df40cf3aaeed1fd1320b2d0
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Sep 15 16:20:01 2016 -0700

    pkt_sched: fq: use proper locking in fq_dump_stats()
    
    commit 695b4ec0f0a9cf29deabd3ac075911d58b31f42b upstream.
    
    When fq is used on 32bit kernels, we need to lock the qdisc before
    copying 64bit fields.
    
    Otherwise "tc -s qdisc ..." might report bogus values.
    
    Fixes: afe4fd062416 ("pkt_sched: fq: Fair Queue packet scheduler")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: keep using ktime_to_ns(ktime_get())]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1fed0e6113dd67f341da7202f98811c42a116b10
Author: Xin Long <lucien.xin@gmail.com>
Date:   Wed Sep 14 02:04:19 2016 +0800

    sctp: do not return the transmit err back to sctp_sendmsg
    
    commit 66388f2c08dfa38071f9eceae7bb29060d9be9aa upstream.
    
    Once a chunk is enqueued successfully, sctp queues can take care of it.
    Even if it is failed to transmit (like because of nomem), it should be
    put into retransmit queue.
    
    If sctp report this error to users, it confuses them, they may resend
    that msg, but actually in kernel sctp stack is in charge of retransmit
    it already.
    
    Besides, this error probably is not from the failure of transmitting
    current msg, but transmitting or retransmitting another msg's chunks,
    as sctp_outq_flush just tries to send out all transports' chunks.
    
    This patch is to make sctp_cmd_send_msg return avoid, and not return the
    transmit err back to sctp_sendmsg
    
    Fixes: 8b570dc9f7b6 ("sctp: only drop the reference on the datamsg after sending a msg")
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: no gfp flags parameter]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit acf50db444f7a9f751365ad0a65cb5cc3ed21f52
Author: Mike Galbraith <efault@gmx.de>
Date:   Mon Aug 13 15:21:23 2012 +0200

    reiserfs: Unlock superblock before calling reiserfs_quota_on_mount()
    
    commit 420902c9d086848a7548c83e0a49021514bd71b7 upstream.
    
    If we hold the superblock lock while calling reiserfs_quota_on_mount(), we can
    deadlock our own worker - mount blocks kworker/3:2, sleeps forever more.
    
    crash> ps|grep UN
        715      2   3  ffff880220734d30  UN   0.0       0      0  [kworker/3:2]
       9369   9341   2  ffff88021ffb7560  UN   1.3  493404 123184  Xorg
       9665   9664   3  ffff880225b92ab0  UN   0.0   47368    812  udisks-daemon
      10635  10403   3  ffff880222f22c70  UN   0.0   14904    936  mount
    crash> bt ffff880220734d30
    PID: 715    TASK: ffff880220734d30  CPU: 3   COMMAND: "kworker/3:2"
     #0 [ffff8802244c3c20] schedule at ffffffff8144584b
     #1 [ffff8802244c3cc8] __rt_mutex_slowlock at ffffffff814472b3
     #2 [ffff8802244c3d28] rt_mutex_slowlock at ffffffff814473f5
     #3 [ffff8802244c3dc8] reiserfs_write_lock at ffffffffa05f28fd [reiserfs]
     #4 [ffff8802244c3de8] flush_async_commits at ffffffffa05ec91d [reiserfs]
     #5 [ffff8802244c3e08] process_one_work at ffffffff81073726
     #6 [ffff8802244c3e68] worker_thread at ffffffff81073eba
     #7 [ffff8802244c3ec8] kthread at ffffffff810782e0
     #8 [ffff8802244c3f48] kernel_thread_helper at ffffffff81450064
    crash> rd ffff8802244c3cc8 10
    ffff8802244c3cc8:  ffffffff814472b3 ffff880222f23250   .rD.....P2."....
    ffff8802244c3cd8:  0000000000000000 0000000000000286   ................
    ffff8802244c3ce8:  ffff8802244c3d30 ffff880220734d80   0=L$.....Ms ....
    ffff8802244c3cf8:  ffff880222e8f628 0000000000000000   (.."............
    ffff8802244c3d08:  0000000000000000 0000000000000002   ................
    crash> struct rt_mutex ffff880222e8f628
    struct rt_mutex {
      wait_lock = {
        raw_lock = {
          slock = 65537
        }
      },
      wait_list = {
        node_list = {
          next = 0xffff8802244c3d48,
          prev = 0xffff8802244c3d48
        }
      },
      owner = 0xffff880222f22c71,
      save_state = 0
    }
    crash> bt 0xffff880222f22c70
    PID: 10635  TASK: ffff880222f22c70  CPU: 3   COMMAND: "mount"
     #0 [ffff8802216a9868] schedule at ffffffff8144584b
     #1 [ffff8802216a9910] schedule_timeout at ffffffff81446865
     #2 [ffff8802216a99a0] wait_for_common at ffffffff81445f74
     #3 [ffff8802216a9a30] flush_work at ffffffff810712d3
     #4 [ffff8802216a9ab0] schedule_on_each_cpu at ffffffff81074463
     #5 [ffff8802216a9ae0] invalidate_bdev at ffffffff81178aba
     #6 [ffff8802216a9af0] vfs_load_quota_inode at ffffffff811a3632
     #7 [ffff8802216a9b50] dquot_quota_on_mount at ffffffff811a375c
     #8 [ffff8802216a9b80] finish_unfinished at ffffffffa05dd8b0 [reiserfs]
     #9 [ffff8802216a9cc0] reiserfs_fill_super at ffffffffa05de825 [reiserfs]
        RIP: 00007f7b9303997a  RSP: 00007ffff443c7a8  RFLAGS: 00010202
        RAX: 00000000000000a5  RBX: ffffffff8144ef12  RCX: 00007f7b932e9ee0
        RDX: 00007f7b93d9a400  RSI: 00007f7b93d9a3e0  RDI: 00007f7b93d9a3c0
        RBP: 00007f7b93d9a2c0   R8: 00007f7b93d9a550   R9: 0000000000000001
        R10: ffffffffc0ed040e  R11: 0000000000000202  R12: 000000000000040e
        R13: 0000000000000000  R14: 00000000c0ed040e  R15: 00007ffff443ca20
        ORIG_RAX: 00000000000000a5  CS: 0033  SS: 002b
    
    Signed-off-by: Mike Galbraith <efault@gmx.de>
    Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
    Acked-by: Mike Galbraith <mgalbraith@suse.de>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d93ddc2df26d6526ddb9253e97476e1a3617339d
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date:   Sun Sep 4 13:04:15 2016 +0200

    ARM: dts: exynos: Fix mismatched value for SD4 pull up/down configuration on exynos4210
    
    commit f7061ffb44116490f282f130a220ca2d10849248 upstream.
    
    The pinctrl pull up/down register on exynos4210 is 2-bit wide for each
    pin and it accepts only values of 0, 1 and 3.  The pins sd4-bus-width8
    were configured with value of 4.  The driver does not validate the value
    so this overflow effectively set a bit 1 in adjacent pins thus
    configuring them to pull down.
    
    The author's intention was probably to set drive strength of 4x.  All
    other bus-widths pins are configured with pull up and drive strength of
    4x.  Fix this one with same pattern.
    
    Fixes: 87711d8c7c70 ("ARM: dts: Add pinctrl node entries for SAMSUNG EXYNOS4210 SoC")
    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
    Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Acked-by: Linus Walleij <linus.walleij@linaro.org>
    [bwh: Backported to 3.16: use literal constant]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5974db8fe4a54a6d490f5b9121250fb5105c4157
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sat Sep 10 16:31:04 2016 -0400

    arc: don't leak bits of kernel stack into coredump
    
    commit 7798bf2140ebcc36eafec6a4194fffd8d585d471 upstream.
    
    On faulting sigreturn we do get SIGSEGV, all right, but anything
    we'd put into pt_regs could end up in the coredump.  And since
    __copy_from_user() never zeroed on arc, we'd better bugger off
    on its failure without copying random uninitialized bits of
    kernel stack into pt_regs...
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    [bwh: Backported to 3.16:
     - Adjust context
     - Don't change the single return statement]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 473d29f25546d1a41f2a652f4ccf2e6fc3fa3f4e
Author: wangguang <wang.guang55@zte.com.cn>
Date:   Thu Sep 15 11:32:46 2016 -0400

    ext4: bugfix for mmaped pages in mpage_release_unused_pages()
    
    commit 4e800c0359d9a53e6bf0ab216954971b2515247f upstream.
    
    Pages clear buffers after ext4 delayed block allocation failed,
    However, it does not clean its pte_dirty flag.
    if the pages unmap ,in cording to the pte_dirty ,
    unmap_page_range may try to call __set_page_dirty,
    
    which may lead to the bugon at
    mpage_prepare_extent_to_map:head = page_buffers(page);.
    
    This patch just call clear_page_dirty_for_io to clean pte_dirty
    at mpage_release_unused_pages for pages mmaped.
    
    Steps to reproduce the bug:
    
    (1) mmap a file in ext4
            addr = (char *)mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED,
                                fd, 0);
            memset(addr, 'i', 4096);
    
    (2) return EIO at
    
            ext4_writepages->mpage_map_and_submit_extent->mpage_map_one_extent
    
    which causes this log message to be print:
    
                    ext4_msg(sb, KERN_CRIT,
                            "Delayed block allocation failed for "
                            "inode %lu at logical offset %llu with"
                            " max blocks %u with error %d",
                            inode->i_ino,
                            (unsigned long long)map->m_lblk,
                            (unsigned)map->m_len, -err);
    
    (3)Unmap the addr cause warning at
    
            __set_page_dirty:WARN_ON_ONCE(warn && !PageUptodate(page));
    
    (4) wait for a minute,then bugon happen.
    
    Signed-off-by: wangguang <wangguang03@zte.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 88946b284075b80a63b41399587466d6804bbf23
Author: Mike Snitzer <snitzer@redhat.com>
Date:   Thu Sep 1 12:06:37 2016 -0400

    dm mpath: check if path's request_queue is dying in activate_path()
    
    commit f10e06b744074824fb8ec7066bc03ecc90918f5b upstream.
    
    If pg_init_retries is set and a request is queued against a multipath
    device with all underlying block device request_queues in the "dying"
    state then an infinite loop is triggered because activate_path() never
    succeeds and hence never calls pg_init_done().
    
    This change avoids that device removal triggers an infinite loop by
    failing the activate_path() which causes the "dying" path to be failed.
    
    Reported-by: Bart Van Assche <bart.vanassche@sandisk.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a51e427a433d5cd2389bee6ac72b5dc3cc0f2da4
Author: Bart Van Assche <bart.vanassche@sandisk.com>
Date:   Wed Aug 31 15:17:49 2016 -0700

    dm: mark request_queue dead before destroying the DM device
    
    commit 3b785fbcf81c3533772c52b717f77293099498d3 upstream.
    
    This avoids that new requests are queued while __dm_destroy() is in
    progress.
    
    Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    [js: use md->queue instead of non-present helper]
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8461bcfb9798e6adc598ce3b8adadbb86da724aa
Author: Dave Chinner <david@fromorbit.com>
Date:   Wed Sep 14 07:40:21 2016 +1000

    xfs: change mailing list address
    
    commit 541d48f05fa1c19a4a968d38df685529e728a20a upstream.
    
    oss.sgi.com is going away, move contact details over to vger.
    
    Signed-off-by: Dave Chinner <david@fromorbit.com>
    [bwh: Backported to 3.16: Also update the git URL, done upstream in commit
     9f273c24ec5f "MAINTAINERS: add/fix git URLs for various subsystems"]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 17fe3f2631a4d15723d11e0f7e5ee204a6282ee0
Author: Chen-Yu Tsai <wens@csie.org>
Date:   Fri Sep 9 11:58:18 2016 +0800

    phy: sun4i-usb: Use spinlock to guard phyctl register access
    
    commit 919ab2524c52e5f801d8873f09145ce822cdd43a upstream.
    
    The musb driver calls into this phy driver to disable/enable squelch
    detection. This function was introduced in 24fe86a617c5 ("phy: sun4i-usb:
    Add a sunxi specific function for setting squelch-detect"). This
    function in turn calls sun4i_usb_phy_write, which uses a mutex to
    guard the common access register. Unfortunately musb does this
    in atomic context, which results in the following warning with lock
    debugging enabled:
    
    BUG: sleeping function called from invalid context at kernel/locking/mutex.c:97
    in_atomic(): 1, irqs_disabled(): 128, pid: 96, name: kworker/0:2
    CPU: 0 PID: 96 Comm: kworker/0:2 Not tainted 4.8.0-rc4-00181-gd502f8ad1c3e #13
    Hardware name: Allwinner sun8i Family
    Workqueue: events musb_deassert_reset
    [<c010bc01>] (unwind_backtrace) from [<c0109237>] (show_stack+0xb/0xc)
    [<c0109237>] (show_stack) from [<c02a669b>] (dump_stack+0x67/0x74)
    [<c02a669b>] (dump_stack) from [<c05d68c9>] (mutex_lock+0x15/0x2c)
    [<c05d68c9>] (mutex_lock) from [<c02c3589>] (sun4i_usb_phy_write+0x39/0xec)
    [<c02c3589>] (sun4i_usb_phy_write) from [<c03e6327>] (musb_port_reset+0xfb/0x184)
    [<c03e6327>] (musb_port_reset) from [<c03e4917>] (musb_deassert_reset+0x1f/0x2c)
    [<c03e4917>] (musb_deassert_reset) from [<c012ecb5>] (process_one_work+0x129/0x2b8)
    [<c012ecb5>] (process_one_work) from [<c012f5e3>] (worker_thread+0xf3/0x424)
    [<c012f5e3>] (worker_thread) from [<c0132dbd>] (kthread+0xa1/0xb8)
    [<c0132dbd>] (kthread) from [<c0105f31>] (ret_from_fork+0x11/0x20)
    
    Since the register access is mmio, we can use a spinlock to guard this
    specific access, rather than the mutex that guards the entire phy.
    
    Fixes: ba4bdc9e1dc0 ("PHY: sunxi: Add driver for sunxi usb phy")
    Cc: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Chen-Yu Tsai <wens@csie.org>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 67d7d69d4b23bc9bde53b274d6899ea0532ba0f7
Author: Robert Jarzmik <robert.jarzmik@free.fr>
Date:   Tue Aug 2 00:01:32 2016 +0200

    ARM: pxa: fix GPIO double shifts
    
    commit ca26475bf02ed8562b9b46f91d3e8b52ec312541 upstream.
    
    The commit 9bf448c66d4b ("ARM: pxa: use generic gpio operation instead of
    gpio register") from Oct 17, 2011, leads to the following static checker
    warning:
      arch/arm/mach-pxa/spitz_pm.c:172 spitz_charger_wakeup()
      warn: double left shift '!gpio_get_value(SPITZ_GPIO_KEY_INT)
            << (1 << ((SPITZ_GPIO_KEY_INT) & 31))'
    
    As Dan reported, the value is shifted three times :
     - once by gpio_get_value(), which returns either 0 or BIT(gpio)
     - once by the shift operation '<<'
     - a last time by GPIO_bit(gpio) which is BIT(gpio)
    
    Therefore the calculation lead to a chained or operator of :
     - (1 << gpio) << (1 << gpio) = (2^gpio)^gpio = 2 ^ (gpio * gpio)
    
    It is be sheer luck the former statement works, only because each gpio
    used is strictly smaller than 6, and therefore 2^(gpio^2) never
    overflows a 32 bits value, and because it is used as a boolean value to
    check a gpio activation.
    
    As the xxx_charger_wakeup() functions are used as a true/false detection
    mechanism, take that opportunity to change their prototypes from integer
    return value to boolean one.
    
    Fixes: 9bf448c66d4b ("ARM: pxa: use generic gpio operation instead of
    gpio register")
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Cc: Joe Perches <joe@perches.com>
    Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
    [bwh: Backported to 3.16: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7763e1f41acaa24298308f52d1535145090f4bdb
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Sep 7 21:52:56 2016 -0700

    ipv4: accept u8 in IP_TOS ancillary data
    
    commit e895cdce683161081e3626c4f5a5c55cb72089f8 upstream.
    
    In commit f02db315b8d8 ("ipv4: IP_TOS and IP_TTL can be specified as
    ancillary data") Francesco added IP_TOS values specified as integer.
    
    However, kernel sends to userspace (at recvmsg() time) an IP_TOS value
    in a single byte, when IP_RECVTOS is set on the socket.
    
    It can be very useful to reflect all ancillary options as given by the
    kernel in a subsequent sendmsg(), instead of aborting the sendmsg() with
    EINVAL after Francesco patch.
    
    So this patch extends IP_TOS ancillary to accept an u8, so that an UDP
    server can simply reuse same ancillary block without having to mangle
    it.
    
    Jesper can then augment
    https://github.com/netoptimizer/network-testing/blob/master/src/udp_example02.c
    to add TOS reflection ;)
    
    Fixes: f02db315b8d8 ("ipv4: IP_TOS and IP_TTL can be specified as ancillary data")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Francesco Fusco <ffusco@redhat.com>
    Cc: Jesper Dangaard Brouer <brouer@redhat.com>
    Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6cab552356fd3cd66aa3c972d3fc9ce3169b2930
Author: Andrew Bresticker <abrestic@chromium.org>
Date:   Mon Feb 15 09:19:49 2016 +0100

    pstore/ram: Use memcpy_fromio() to save old buffer
    
    commit d771fdf94180de2bd811ac90cba75f0f346abf8d upstream.
    
    The ramoops buffer may be mapped as either I/O memory or uncached
    memory.  On ARM64, this results in a device-type (strongly-ordered)
    mapping.  Since unnaligned accesses to device-type memory will
    generate an alignment fault (regardless of whether or not strict
    alignment checking is enabled), it is not safe to use memcpy().
    memcpy_fromio() is guaranteed to only use aligned accesses, so use
    that instead.
    
    Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
    Signed-off-by: Enric Balletbo Serra <enric.balletbo@collabora.com>
    Reviewed-by: Puneet Kumar <puneetster@chromium.org>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6e951f8938bd4fcf9b709e0f6d85c86b1f8dde30
Author: Furquan Shaikh <furquan@google.com>
Date:   Mon Feb 15 09:19:48 2016 +0100

    pstore/ram: Use memcpy_toio instead of memcpy
    
    commit 7e75678d23167c2527e655658a8ef36a36c8b4d9 upstream.
    
    persistent_ram_update uses vmap / iomap based on whether the buffer is in
    memory region or reserved region. However, both map it as non-cacheable
    memory. For armv8 specifically, non-cacheable mapping requests use a
    memory type that has to be accessed aligned to the request size. memcpy()
    doesn't guarantee that.
    
    Signed-off-by: Furquan Shaikh <furquan@google.com>
    Signed-off-by: Enric Balletbo Serra <enric.balletbo@collabora.com>
    Reviewed-by: Aaron Durbin <adurbin@chromium.org>
    Reviewed-by: Olof Johansson <olofj@chromium.org>
    Tested-by: Furquan Shaikh <furquan@chromium.org>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ed5a49ca199f7b154e84167e0c02852b9f968d2f
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Thu Sep 8 13:48:06 2016 +0200

    pstore/core: drop cmpxchg based updates
    
    commit d5a9bf0b38d2ac85c9a693c7fb851f74fd2a2494 upstream.
    
    I have here a FPGA behind PCIe which exports SRAM which I use for
    pstore. Now it seems that the FPGA no longer supports cmpxchg based
    updates and writes back 0xff…ff and returns the same.  This leads to
    crash during crash rendering pstore useless.
    Since I doubt that there is much benefit from using cmpxchg() here, I am
    dropping this atomic access and use the spinlock based version.
    
    Cc: Anton Vorontsov <anton@enomsg.org>
    Cc: Colin Cross <ccross@android.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: Rabin Vincent <rabinv@axis.com>
    Tested-by: Rabin Vincent <rabinv@axis.com>
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    [kees: remove "_locked" suffix since it's the only option now]
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8e397928583e94fd6f19b7c35c6f1f6c517fbbae
Author: Daeho Jeong <daeho.jeong@samsung.com>
Date:   Mon Sep 5 22:56:10 2016 -0400

    ext4: reinforce check of i_dtime when clearing high fields of uid and gid
    
    commit 93e3b4e6631d2a74a8cf7429138096862ff9f452 upstream.
    
    Now, ext4_do_update_inode() clears high 16-bit fields of uid/gid
    of deleted and evicted inode to fix up interoperability with old
    kernels. However, it checks only i_dtime of an inode to determine
    whether the inode was deleted and evicted, and this is very risky,
    because i_dtime can be used for the pointer maintaining orphan inode
    list, too. We need to further check whether the i_dtime is being
    used for the orphan inode list even if the i_dtime is not NULL.
    
    We found that high 16-bit fields of uid/gid of inode are unintentionally
    and permanently cleared when the inode truncation is just triggered,
    but not finished, and the inode metadata, whose high uid/gid bits are
    cleared, is written on disk, and the sudden power-off follows that
    in order.
    
    Signed-off-by: Daeho Jeong <daeho.jeong@samsung.com>
    Signed-off-by: Hobin Woo <hobin.woo@samsung.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ef33b3335d61d66f94bf08a827159039cd8ca75e
Author: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Date:   Sun Sep 4 10:06:39 2016 -0300

    cx231xx: fix GPIOs for Pixelview SBTVD hybrid
    
    commit 24b923f073ac37eb744f56a2c7f77107b8219ab2 upstream.
    
    This device uses GPIOs: 28 to switch between analog and
    digital modes: on digital mode, it should be set to 1.
    
    The code that sets it on analog mode is OK, but it misses
    the logic that sets it on digital mode.
    
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0cb3575c5cca40624a64190ffac3a11691446c1a
Author: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Date:   Sun Sep 4 09:56:33 2016 -0300

    cx231xx: don't return error on success
    
    commit 1871d718a9db649b70f0929d2778dc01bc49b286 upstream.
    
    The cx231xx_set_agc_analog_digital_mux_select() callers
    expect it to return 0 or an error. Returning a positive value
    makes the first attempt to switch between analog/digital to fail.
    
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 89ae9950d0ec3bdfa424463f8a1fb9e31b0e4dcc
Author: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Date:   Sun Sep 4 10:43:53 2016 -0300

    mb86a20s: fix demod settings
    
    commit 505a0ea706fc1db4381baa6c6bd2e596e730a55e upstream.
    
    With the current settings, only one channel locks properly.
    That's likely because, when this driver was written, Brazil
    were still using experimental transmissions.
    
    Change it to reproduce the settings used by the newer drivers.
    That makes it lock on other channels.
    
    Tested with both PixelView SBTVD Hybrid (cx231xx-based) and
    C3Tech Digital Duo HDTV/SDTV (em28xx-based) devices.
    
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a9a1550c470ed16cce8e9b32285f632e989dd3e5
Author: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Date:   Sun Sep 4 10:16:18 2016 -0300

    mb86a20s: fix the locking logic
    
    commit dafb65fb98d85d8e78405e82c83e81975e5d5480 upstream.
    
    On this frontend, it takes a while to start output normal
    TS data. That only happens on state S9. On S8, the TS output
    is enabled, but it is not reliable enough.
    
    However, the zigzag loop is too fast to let it sync.
    
    As, on practical tests, the zigzag software loop doesn't
    seem to be helping, but just slowing down the tuning, let's
    switch to hardware algorithm, as the tuners used on such
    devices are capable of work with frequency drifts without
    any help from software.
    
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1eb985ab574b02b637bcc0aa94f00b795855ac6a
Author: David Hsu <davidhsu@google.com>
Date:   Tue Aug 9 14:57:46 2016 -0700

    pwm: Unexport children before chip removal
    
    commit 0733424c9ba9f42242409d1ece780777272f7ea1 upstream.
    
    Exported pwm channels aren't removed before the pwmchip and are
    leaked. This results in invalid sysfs files. This fix removes
    all exported pwm channels before chip removal.
    
    Signed-off-by: David Hsu <davidhsu@google.com>
    Fixes: 76abbdde2d95 ("pwm: Add sysfs interface")
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f25fec22d4cbc3b921356f4600f48e4eea8a0f7d
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Mon Aug 22 14:27:59 2016 -0500

    rtlwifi: Fix missing country code for Great Britain
    
    commit 0c9d3491530773858ff9d705ec2a9c382f449230 upstream.
    
    Some RTL8821AE devices sold in Great Britain have the country code of
    0x25 encoded in their EEPROM. This value is not tested in the routine
    that establishes the regulatory info for the chip. The fix is to set
    this code to have the same capabilities as the EU countries. In addition,
    the channels allowed for COUNTRY_CODE_ETSI were more properly suited
    for China and Israel, not the EU. This problem has also been fixed.
    
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    [bwh: Backported to 3.16: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6c086028dde2b29fe7003b9256ce857cbedc0950
Author: Shao Fu <shaofu@realtek.com>
Date:   Fri May 15 16:32:59 2015 -0500

    rtlwifi: Update regulatory database
    
    commit 02b5fffbe9e02f5d63fa4a801fb807cf0aab4fc9 upstream.
    
    Driver rtlwifi maintains its own regulatory information, The Chrome Autotest
    (https://www.chromium.org/chromium-os/testing/autotest-user-doc)
    showed some errors. This patch adds the necessary information for rtlwifi.
    
    Signed-off-by: Shao Fu <shaofu@realtek.com>
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f88b9b4d7d379e37640ec75b9c84fc50cc4975d5
Author: Sebastian Frias <sf84@laposte.net>
Date:   Mon Aug 1 16:27:38 2016 +0200

    genirq/generic_chip: Add irq_unmap callback
    
    commit ee26c013cdee0b947e29d6cadfb9ff3341c69ff9 upstream.
    
    Without this patch irq_domain_disassociate() cannot properly release the
    interrupt. In fact, irq_map_generic_chip() checks a bit on 'gc->installed'
    but said bit is never cleared, only set.
    
    Commit 088f40b7b027 ("genirq: Generic chip: Add linear irq domain support")
    added irq_map_generic_chip() function and also stated "This lacks a removal
    function for now".
    
    This commit provides an implementation of an unmap function that can be
    called by irq_domain_disassociate().
    
    [ tglx: Made the function static and removed the export as we have neither
            a prototype nor a modular user. ]
    
    Fixes: 088f40b7b027 ("genirq: Generic chip: Add linear irq domain support")
    Signed-off-by: Sebastian Frias <sf84@laposte.net>
    Cc: Marc Zyngier <marc.zyngier@arm.com>
    Cc: Mason <slash.tmp@free.fr>
    Cc: Jason Cooper <jason@lakedaemon.net>
    Link: http://lkml.kernel.org/r/579F5C5A.2070507@laposte.net
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    [bwh: Backported to 3.16: open-code irq_domain_get_irq_data(),
     irq_domain_set_info()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 59dd50d101b7049255199bef62568750eb25a739
Author: Chen-Yu Tsai <wens@csie.org>
Date:   Sat Aug 27 19:27:59 2016 +0800

    ASoC: dapm: Fix value setting for _ENUM_DOUBLE MUX's second channel
    
    commit 071133a209354f39d4e5785d5a6a390e03241841 upstream.
    
    The value for the second channel in _ENUM_DOUBLE (double channel) MUXs
    is not correctly updated, due to using the wrong bit shift.
    
    Use the correct bit shift, so both channels toggle together.
    
    Fixes: 3727b4968453 (ASoC: dapm: Consolidate MUXs and value MUXs)
    Signed-off-by: Chen-Yu Tsai <wens@csie.org>
    Reviewed-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 29bcabf8d96d1d61a3cb2acc5575d8090ac87eaa
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Thu Sep 1 11:00:23 2016 -0300

    perf symbols: Fixup symbol sizes before picking best ones
    
    commit 432746f8e0b6a82ba832b771afe31abd51af6752 upstream.
    
    When we call symbol__fixup_duplicate() we use algorithms to pick the
    "best" symbols for cases where there are various functions/aliases to an
    address, and those check zero size symbols, which, before calling
    symbol__fixup_end() are _all_ symbols in a just parsed kallsyms file.
    
    So first fixup the end, then fixup the duplicates.
    
    Found while trying to figure out why 'perf test vmlinux' failed, see the
    output of 'perf test -v vmlinux' to see cases where the symbols picked
    as best for vmlinux don't match the ones picked for kallsyms.
    
    Cc: Anton Blanchard <anton@samba.org>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: David Ahern <dsahern@gmail.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Wang Nan <wangnan0@huawei.com>
    Fixes: 694bf407b061 ("perf symbols: Add some heuristics for choosing the best duplicate symbol")
    Link: http://lkml.kernel.org/n/tip-rxqvdgr0mqjdxee0kf8i2ufn@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 43d95069729e96ca0cd1266ada99bd319c22d9a7
Author: Will Deacon <will.deacon@arm.com>
Date:   Fri Aug 26 11:36:39 2016 +0100

    arm64: debug: avoid resetting stepping state machine when TIF_SINGLESTEP
    
    commit 3a402a709500c5a3faca2111668c33d96555e35a upstream.
    
    When TIF_SINGLESTEP is set for a task, the single-step state machine is
    enabled and we must take care not to reset it to the active-not-pending
    state if it is already in the active-pending state.
    
    Unfortunately, that's exactly what user_enable_single_step does, by
    unconditionally setting the SS bit in the SPSR for the current task.
    This causes failures in the GDB testsuite, where GDB ends up missing
    expected step traps if the instruction being stepped generates another
    trap, e.g. PTRACE_EVENT_FORK from an SVC instruction.
    
    This patch fixes the problem by preserving the current state of the
    stepping state machine when TIF_SINGLESTEP is set on the current thread.
    
    Reported-by: Yao Qi <yao.qi@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 16d02c7e83b6b60651af77e73dcd23b099f4a886
Author: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date:   Mon Jul 4 01:04:24 2016 +0300

    platform: don't return 0 from platform_get_irq[_byname]() on error
    
    commit e330b9a6bb35dc7097a4f02cb1ae7b6f96df92af upstream.
    
    of_irq_get[_byname]() return 0 iff  irq_create_of_mapping() call fails.
    Returning both  error code and 0 on failure is a sign of a misdesigned API,
    it makes the failure check unnecessarily complex and error prone. We should
    rely  on the platform IRQ resource in this case, not return 0,  especially
    as 0 can be  a valid  IRQ resource too...
    
    Fixes: aff008ad813c ("platform_get_irq: Revert to platform_get_resource if of_irq_get fails")
    Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3ab4b2989ec51a7b1f8ac2568380a05592fafd2b
Author: Jan Viktorin <viktorin@rehivetech.com>
Date:   Tue May 17 11:22:17 2016 +0200

    uio: fix dmem_region_start computation
    
    commit 4d31a2588ae37a5d0f61f4d956454e9504846aeb upstream.
    
    The variable i contains a total number of resources (including
    IORESOURCE_IRQ). However, we want the dmem_region_start to point
    after the last resource of type IORESOURCE_MEM. The original behaviour
    leads (very likely) to skipping several UIO mapping regions and makes
    them useless. Fix this by computing dmem_region_start from the uiomem
    which points to the last used UIO mapping.
    
    Fixes: 0a0c3b5a24bd ("Add new uio device for dynamic memory allocation")
    
    Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 737766466e1f3d5c192c9ec9da72c086f2c9bef5
Author: Florian Westphal <fw@strlen.de>
Date:   Thu Aug 25 15:33:29 2016 +0200

    netfilter: restart search if moved to other chain
    
    commit 95a8d19f28e6b29377a880c6264391a62e07fccc upstream.
    
    In case nf_conntrack_tuple_taken did not find a conflicting entry
    check that all entries in this hash slot were tested and restart
    in case an entry was moved to another chain.
    
    Reported-by: Eric Dumazet <edumazet@google.com>
    Fixes: ea781f197d6a ("netfilter: nf_conntrack: use SLAB_DESTROY_BY_RCU and get rid of call_rcu()")
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    [bwh: Backported to 3.16:
     - Adjust context
     - Use NF_CT_STAT_INC(), not the _ATOMIC variant, since we disable BHs]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3b7ecf53c92feae9b8e2423cad5ce4fbc4f9e4b4
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Wed Aug 24 14:21:41 2016 -0700

    net: systemport: Fix ordering in intrl2_*_mask_clear macro
    
    commit 9a0a5c4cb1af98b625dcefd72e987ca4929db71d upstream.
    
    Since we keep shadow copies of which interrupt sources are enabled
    through the intrl2_*_mask_{set,clear} macros, make sure that the
    ordering in which we do these two operations: update the copy, then
    unmask the register is correct.
    
    This is not currently a problem because we actually do not use them, but
    we will in a subsequent patch optimizing register accesses, so better be
    safe here.
    
    Fixes: 80105befdb4b ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver")
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2f262767a3aeac80a0e6440760716d290eabc44e
Author: Maik Broemme <mbroemme@libmpq.org>
Date:   Tue Aug 9 16:41:31 2016 +0200

    PCI: Mark Atheros AR9580 to avoid bus reset
    
    commit 8e2e03179923479ca0c0b6fdc7c93ecf89bce7a8 upstream.
    
    Similar to the AR93xx and the AR94xx series, the AR95xx also have the same
    quirk for the Bus Reset.  It will lead to instant system reset if the
    device is assigned via VFIO to a KVM VM.  I've been able reproduce this
    behavior with a MikroTik R11e-2HnD.
    
    Fixes: c3e59ee4e766 ("PCI: Mark Atheros AR93xx to avoid bus reset")
    Signed-off-by: Maik Broemme <mbroemme@libmpq.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit dd8302b10f2c6377cb865bedc1095253455dc8ae
Author: Josh Poimboeuf <jpoimboe@redhat.com>
Date:   Thu Aug 18 10:59:06 2016 -0500

    x86/dumpstack: Fix x86_32 kernel_stack_pointer() previous stack access
    
    commit 72b4f6a5e903b071f2a7c4eb1418cbe4eefdc344 upstream.
    
    On x86_32, when an interrupt happens from kernel space, SS and SP aren't
    pushed and the existing stack is used.  So pt_regs is effectively two
    words shorter, and the previous stack pointer is normally the memory
    after the shortened pt_regs, aka '&regs->sp'.
    
    But in the rare case where the interrupt hits right after the stack
    pointer has been changed to point to an empty stack, like for example
    when call_on_stack() is used, the address immediately after the
    shortened pt_regs is no longer on the stack.  In that case, instead of
    '&regs->sp', the previous stack pointer should be retrieved from the
    beginning of the current stack page.
    
    kernel_stack_pointer() wants to do that, but it forgets to dereference
    the pointer.  So instead of returning a pointer to the previous stack,
    it returns a pointer to the beginning of the current stack.
    
    Note that it's probably outside of kernel_stack_pointer()'s scope to be
    switching stacks at all.  The x86_64 version of this function doesn't do
    it, and it would be better for the caller to do it if necessary.  But
    that's a patch for another day.  This just fixes the original intent.
    
    Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andy Lutomirski <luto@amacapital.net>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Brian Gerst <brgerst@gmail.com>
    Cc: Byungchul Park <byungchul.park@lge.com>
    Cc: Denys Vlasenko <dvlasenk@redhat.com>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Nilay Vaish <nilayvaish@gmail.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Fixes: 0788aa6a23cb ("x86: Prepare removal of previous_esp from i386 thread_info structure")
    Link: http://lkml.kernel.org/r/472453d6e9f6a2d4ab16aaed4935f43117111566.1471535549.git.jpoimboe@redhat.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f68c511d0b0c00957132934a2f155d489329f0b6
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Fri Aug 12 14:37:54 2016 +0200

    clk: divider: Fix clk_divider_round_rate() to use clk_readl()
    
    commit 2cf9a57811bddb6fa6b0f8d7376da164d5534813 upstream.
    
    clk-divider uses clk_readl()/clk_writel() everywhere, except in
    clk_divider_round_rate(), where plain readl() is used. Change this to
    clk_readl(), as it makes a difference on powerpc.
    
    Fixes: e6d5e7d90be92cee ("clk-divider: Fix READ_ONLY when divider > 1")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: James Hogan <james.hogan@imgtec.com>
    Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c23ef4c163ad2271ee6bd30526b8fa1d0cecdcd9
Author: Steffen Maier <maier@linux.vnet.ibm.com>
Date:   Wed Aug 10 18:30:53 2016 +0200

    zfcp: trace full payload of all SAN records (req,resp,iels)
    
    commit aceeffbb59bb91404a0bda32a542d7ebf878433a upstream.
    
    This was lost with commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c
    ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
    but is necessary for problem determination, e.g. to see the
    currently active zone set during automatic port scan.
    
    For the large GPN_FT response (4 pages), save space by not dumping
    any empty residual entries.
    
    Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
    Fixes: 2c55b750a884 ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
    Reviewed-by: Alexey Ishchuk <aishchuk@linux.vnet.ibm.com>
    Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
    Reviewed-by: Hannes Reinecke <hare@suse.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 728e51b88f48fe861e6fe731a4ee67f7d7064147
Author: Steffen Maier <maier@linux.vnet.ibm.com>
Date:   Wed Aug 10 18:30:52 2016 +0200

    zfcp: fix payload trace length for SAN request&response
    
    commit 94db3725f049ead24c96226df4a4fb375b880a77 upstream.
    
    commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c
    ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
    started to add FC_CT_HDR_LEN which made zfcp dump random data
    out of bounds for RSPN GS responses because u.rspn.rsp
    is the largest and last field in the union of struct zfcp_fc_req.
    Other request/response types only happened to stay within bounds
    due to the padding of the union or
    due to the trace capping of u.gspn.rsp to ZFCP_DBF_SAN_MAX_PAYLOAD.
    
    Timestamp      : ...
    Area           : SAN
    Subarea        : 00
    Level          : 1
    Exception      : -
    CPU id         : ..
    Caller         : ...
    Record id      : 2
    Tag            : fsscth2
    Request id     : 0x...
    Destination ID : 0x00fffffc
    Payload short  : 01000000 fc020000 80020000 00000000
                     xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx <===
                     00000000 00000000 00000000 00000000
    Payload length : 32                                  <===
    
    struct zfcp_fc_req {
        [0] struct zfcp_fsf_ct_els ct_els;
       [56] struct scatterlist sg_req;
       [96] struct scatterlist sg_rsp;
            union {
                struct {req; rsp;} adisc;    SIZE: 28+28=   56
                struct {req; rsp;} gid_pn;   SIZE: 24+20=   44
                struct {rspsg; req;} gpn_ft; SIZE: 40*4+20=180
                struct {req; rsp;} gspn;     SIZE: 20+273= 293
                struct {req; rsp;} rspn;     SIZE: 277+16= 293
      [136] } u;
    }
    SIZE: 432
    
    Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
    Fixes: 2c55b750a884 ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
    Reviewed-by: Alexey Ishchuk <aishchuk@linux.vnet.ibm.com>
    Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
    Reviewed-by: Hannes Reinecke <hare@suse.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d5d73600c8086ce4dbede66621e045cbb4671345
Author: Steffen Maier <maier@linux.vnet.ibm.com>
Date:   Wed Aug 10 18:30:51 2016 +0200

    zfcp: fix D_ID field with actual value on tracing SAN responses
    
    commit 771bf03537ddfa4a4dde62ef9dfbc82e4f77ab20 upstream.
    
    With commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c
    ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
    we lost the N_Port-ID where an ELS response comes from.
    With commit 7c7dc196814b9e1d5cc254dc579a5fa78ae524f7
    ("[SCSI] zfcp: Simplify handling of ct and els requests")
    we lost the N_Port-ID where a CT response comes from.
    It's especially useful if the request SAN trace record
    with D_ID was already lost due to trace buffer wrap.
    
    GS uses an open WKA port handle and ELS just a D_ID, and
    only for ELS we could get D_ID from QTCB bottom via zfcp_fsf_req.
    To cover both cases, add a new field to zfcp_fsf_ct_els
    and fill it in on request to use in SAN response trace.
    Strictly speaking the D_ID on SAN response is the FC frame's S_ID.
    We don't need a field for the other end which is always us.
    
    Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
    Fixes: 2c55b750a884 ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
    Fixes: 7c7dc196814b ("[SCSI] zfcp: Simplify handling of ct and els requests")
    Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
    Reviewed-by: Hannes Reinecke <hare@suse.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1e44520165546310e5851d80051101a653071fb4
Author: Steffen Maier <maier@linux.vnet.ibm.com>
Date:   Wed Aug 10 18:30:50 2016 +0200

    zfcp: restore tracing of handle for port and LUN with HBA records
    
    commit 7c964ffe586bc0c3d9febe9bf97a2e4b2866e5b7 upstream.
    
    This information was lost with
    commit a54ca0f62f953898b05549391ac2a8a4dad6482b
    ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
    but is required to debug e.g. invalid handle situations.
    
    Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
    Fixes: a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
    Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
    Reviewed-by: Hannes Reinecke <hare@suse.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5e4c51658e6d7253b41760d359b09af894c34fdb
Author: Steffen Maier <maier@linux.vnet.ibm.com>
Date:   Wed Aug 10 18:30:49 2016 +0200

    zfcp: trace on request for open and close of WKA port
    
    commit d27a7cb91960cf1fdd11b10071e601828cbf4b1f upstream.
    
    Since commit a54ca0f62f953898b05549391ac2a8a4dad6482b
    ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
    HBA records no longer contain WWPN, D_ID, or LUN
    to reduce duplicate information which is already in REC records.
    In contrast to "regular" target ports, we don't use recovery to open
    WKA ports such as directory/nameserver, so we don't get REC records.
    Therefore, introduce pseudo REC running records without any
    actual recovery action but including D_ID of WKA port on open/close.
    
    Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
    Fixes: a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
    Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
    Reviewed-by: Hannes Reinecke <hare@suse.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit dbd59605c367528a0be8f79bc1d142aec7ec754f
Author: Steffen Maier <maier@linux.vnet.ibm.com>
Date:   Wed Aug 10 18:30:48 2016 +0200

    zfcp: restore: Dont use 0 to indicate invalid LUN in rec trace
    
    commit 0102a30a6ff60f4bb4c07358ca3b1f92254a6c25 upstream.
    
    bring back
    commit d21e9daa63e009ce5b87bbcaa6d11ce48e07bbbe
    ("[SCSI] zfcp: Dont use 0 to indicate invalid LUN in rec trace")
    which was lost with
    commit ae0904f60fab7cb20c48d32eefdd735e478b91fb
    ("[SCSI] zfcp: Redesign of the debug tracing for recovery actions.")
    
    Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
    Fixes: ae0904f60fab ("[SCSI] zfcp: Redesign of the debug tracing for recovery actions.")
    Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
    Reviewed-by: Hannes Reinecke <hare@suse.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5de93d9f99238c20a914d3a1c9e84856931a719d
Author: Steffen Maier <maier@linux.vnet.ibm.com>
Date:   Wed Aug 10 18:30:47 2016 +0200

    zfcp: retain trace level for SCSI and HBA FSF response records
    
    commit 35f040df97fa0e94c7851c054ec71533c88b4b81 upstream.
    
    While retaining the actual filtering according to trace level,
    the following commits started to write such filtered records
    with a hardcoded record level of 1 instead of the actual record level:
    commit 250a1352b95e1db3216e5c5d4f4365bea5122f4a
    ("[SCSI] zfcp: Redesign of the debug tracing for SCSI records.")
    commit a54ca0f62f953898b05549391ac2a8a4dad6482b
    ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
    
    Now we can distinguish written records again for offline level filtering.
    
    Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
    Fixes: 250a1352b95e ("[SCSI] zfcp: Redesign of the debug tracing for SCSI records.")
    Fixes: a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
    Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
    Reviewed-by: Hannes Reinecke <hare@suse.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit afb08b0bc5c2c864b9b1ca958ecd9062e0bf73cf
Author: Steffen Maier <maier@linux.vnet.ibm.com>
Date:   Wed Aug 10 18:30:46 2016 +0200

    zfcp: close window with unblocked rport during rport gone
    
    commit 4eeaa4f3f1d6c47b69f70e222297a4df4743363e upstream.
    
    On a successful end of reopen port forced,
    zfcp_erp_strategy_followup_success() re-uses the port erp_action
    and the subsequent zfcp_erp_action_cleanup() now
    sees ZFCP_ERP_SUCCEEDED with
    erp_action->action==ZFCP_ERP_ACTION_REOPEN_PORT
    instead of ZFCP_ERP_ACTION_REOPEN_PORT_FORCED
    but must not perform zfcp_scsi_schedule_rport_register().
    
    We can detect this because the fresh port reopen erp_action
    is in its very first step ZFCP_ERP_STEP_UNINITIALIZED.
    
    Otherwise this opens a time window with unblocked rport
    (until the followup port reopen recovery would block it again).
    If a scsi_cmnd timeout occurs during this time window
    fc_timed_out() cannot work as desired and such command
    would indeed time out and trigger scsi_eh. This prevents
    a clean and timely path failover.
    This should not happen if the path issue can be recovered
    on FC transport layer such as path issues involving RSCNs.
    
    Also, unnecessary and repeated DID_IMM_RETRY for pending and
    undesired new requests occur because internally zfcp still
    has its zfcp_port blocked.
    
    As follow-on errors with scsi_eh, it can cause,
    in the worst case, permanently lost paths due to one of:
    sd <scsidev>: [<scsidisk>] Medium access timeout failure. Offlining disk!
    sd <scsidev>: Device offlined - not ready after error recovery
    
    For fix validation and to aid future debugging with other recoveries
    we now also trace (un)blocking of rports.
    
    Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
    Fixes: 5767620c383a ("[SCSI] zfcp: Do not unblock rport from REOPEN_PORT_FORCED")
    Fixes: a2fa0aede07c ("[SCSI] zfcp: Block FC transport rports early on errors")
    Fixes: 5f852be9e11d ("[SCSI] zfcp: Fix deadlock between zfcp ERP and SCSI")
    Fixes: 338151e06608 ("[SCSI] zfcp: make use of fc_remote_port_delete when target port is unavailable")
    Fixes: 3859f6a248cb ("[PATCH] zfcp: add rports to enable scsi_add_device to work again")
    Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
    Reviewed-by: Hannes Reinecke <hare@suse.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5ae95bcd9e50d7e85f8dd7791617343e32d35a85
Author: Steffen Maier <maier@linux.vnet.ibm.com>
Date:   Wed Aug 10 18:30:45 2016 +0200

    zfcp: fix ELS/GS request&response length for hardware data router
    
    commit 70369f8e15b220f50a16348c79a61d3f7054813c upstream.
    
    In the hardware data router case, introduced with kernel 3.2
    commit 86a9668a8d29 ("[SCSI] zfcp: support for hardware data router")
    the ELS/GS request&response length needs to be initialized
    as in the chained SBAL case.
    
    Otherwise, the FCP channel rejects ELS requests with
    FSF_REQUEST_SIZE_TOO_LARGE.
    
    Such ELS requests can be issued by user space through BSG / HBA API,
    or zfcp itself uses ADISC ELS for remote port link test on RSCN.
    The latter can cause a short path outage due to
    unnecessary remote target port recovery because the always
    failing ADISC cannot detect extremely short path interruptions
    beyond the local FCP channel.
    
    Below example is decoded with zfcpdbf from s390-tools:
    
    Timestamp      : ...
    Area           : SAN
    Subarea        : 00
    Level          : 1
    Exception      : -
    CPU id         : ..
    Caller         : zfcp_dbf_san_req+0408
    Record id      : 1
    Tag            : fssels1
    Request id     : 0x<reqid>
    Destination ID : 0x00<target d_id>
    Payload info   : 52000000 00000000 <our wwpn       >           [ADISC]
                     <our wwnn       > 00<s_id> 00000000
                     00000000 00000000 00000000 00000000
    
    Timestamp      : ...
    Area           : HBA
    Subarea        : 00
    Level          : 1
    Exception      : -
    CPU id         : ..
    Caller         : zfcp_dbf_hba_fsf_res+0740
    Record id      : 1
    Tag            : fs_ferr
    Request id     : 0x<reqid>
    Request status : 0x00000010
    FSF cmnd       : 0x0000000b               [FSF_QTCB_SEND_ELS]
    FSF sequence no: 0x...
    FSF issued     : ...
    FSF stat       : 0x00000061               [FSF_REQUEST_SIZE_TOO_LARGE]
    FSF stat qual  : 00000000 00000000 00000000 00000000
    Prot stat      : 0x00000100
    Prot stat qual : 00000000 00000000 00000000 00000000
    
    Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
    Fixes: 86a9668a8d29 ("[SCSI] zfcp: support for hardware data router")
    Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
    Reviewed-by: Hannes Reinecke <hare@suse.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2f7a91d23ae36f03fdcd73124955131a59ccbb9d
Author: Steffen Maier <maier@linux.vnet.ibm.com>
Date:   Wed Aug 10 18:30:44 2016 +0200

    zfcp: fix fc_host port_type with NPIV
    
    commit bd77befa5bcff8c51613de271913639edf85fbc2 upstream.
    
    For an NPIV-enabled FCP device, zfcp can erroneously show
    "NPort (fabric via point-to-point)" instead of "NPIV VPORT"
    for the port_type sysfs attribute of the corresponding
    fc_host.
    s390-tools that can be affected are dbginfo.sh and ziomon.
    
    zfcp_fsf_exchange_config_evaluate() ignores
    fsf_qtcb_bottom_config.connection_features indicating NPIV
    and only sets fc_host_port_type to FC_PORTTYPE_NPORT if
    fsf_qtcb_bottom_config.fc_topology is FSF_TOPO_FABRIC.
    
    Only the independent zfcp_fsf_exchange_port_evaluate()
    evaluates connection_features to overwrite fc_host_port_type
    to FC_PORTTYPE_NPIV in case of NPIV.
    Code was introduced with upstream kernel 2.6.30
    commit 0282985da5923fa6365adcc1a1586ae0c13c1617
    ("[SCSI] zfcp: Report fc_host_port_type as NPIV").
    
    This works during FCP device recovery (such as set online)
    because it performs FSF_QTCB_EXCHANGE_CONFIG_DATA followed by
    FSF_QTCB_EXCHANGE_PORT_DATA in sequence.
    
    However, the zfcp-specific scsi host sysfs attributes
    "requests", "megabytes", or "seconds_active" trigger only
    zfcp_fsf_exchange_config_evaluate() resetting fc_host
    port_type to FC_PORTTYPE_NPORT despite NPIV.
    
    The zfcp-specific scsi host sysfs attribute "utilization"
    triggers only zfcp_fsf_exchange_port_evaluate() correcting
    the fc_host port_type again in case of NPIV.
    
    Evaluate fsf_qtcb_bottom_config.connection_features
    in zfcp_fsf_exchange_config_evaluate() where it belongs to.
    
    Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
    Fixes: 0282985da592 ("[SCSI] zfcp: Report fc_host_port_type as NPIV")
    Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
    Reviewed-by: Hannes Reinecke <hare@suse.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ef70fd11f507619530238f3cd990616f4612a63d
Author: Max Staudt <mstaudt@suse.de>
Date:   Mon Jun 13 19:15:59 2016 +0200

    fbdev/efifb: Fix 16 color palette entry calculation
    
    commit d50b3f43db739f03fcf8c0a00664b3d2fed0496e upstream.
    
    When using efifb with a 16-bit (5:6:5) visual, fbcon's text is rendered
    in the wrong colors - e.g. text gray (#aaaaaa) is rendered as green
    (#50bc50) and neighboring pixels have slightly different values
    (such as #50bc78).
    
    The reason is that fbcon loads its 16 color palette through
    efifb_setcolreg(), which in turn calculates a 32-bit value to write
    into memory for each palette index.
    Until now, this code could only handle 8-bit visuals and didn't mask
    overlapping values when ORing them.
    
    With this patch, fbcon displays the correct colors when a qemu VM is
    booted in 16-bit mode (in GRUB: "set gfxpayload=800x600x16").
    
    Fixes: 7c83172b98e5 ("x86_64 EFI boot support: EFI frame buffer driver")  # v2.6.24+
    Signed-off-by: Max Staudt <mstaudt@suse.de>
    Acked-By: Peter Jones <pjones@redhat.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 272b2715194fbc55413b61ca79c776fb513dd34b
Author: Lyude <cpaul@redhat.com>
Date:   Tue Jun 21 17:03:42 2016 -0400

    drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init()
    
    commit 9504a89247595b6c066c68aea0c34af1fc78d021 upstream.
    
    While VGA hotplugging worked(ish) before, it looks like that was mainly
    because we'd unintentionally enable it in
    valleyview_crt_detect_hotplug() when we did a force trigger. This
    doesn't work reliably enough because whenever the display powerwell on
    vlv gets disabled, the values set in VLV_ADPA get cleared and
    consequently VGA hotplugging gets disabled. This causes bugs such as one
    we found on an Intel NUC, where doing the following sequence of
    hotplugs:
    
          - Disconnect all monitors
          - Connect VGA
          - Disconnect VGA
          - Connect HDMI
    
    Would result in VGA hotplugging becoming disabled, due to the powerwells
    getting toggled in the process of connecting HDMI.
    
    Changes since v3:
     - Expose intel_crt_reset() through intel_drv.h and call that in
       vlv_display_power_well_init() instead of
       encoder->base.funcs->reset(&encoder->base);
    
    Changes since v2:
     - Use intel_encoder structs instead of drm_encoder structs
    
    Changes since v1:
     - Instead of handling the register writes ourself, we just reuse
       intel_crt_detect()
     - Instead of resetting the ADPA during display IRQ installation, we now
       reset them in vlv_display_power_well_init()
    
    Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Lyude <cpaul@redhat.com>
    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    [danvet: Rebase over dev_priv/drm_device embedding.]
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    [bwh: Backported to 3.16:
     - Adjust filename, context
     - Open-code for_each_intel_encoder()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8561c2f90e958e8a400bac1dffa29ea0589095ed
Author: Lyude <cpaul@redhat.com>
Date:   Tue Jun 21 17:03:41 2016 -0400

    drm/i915/vlv: Make intel_crt_reset() per-encoder
    
    commit 28cf71ce3e206db1c3f30b3da31e7b48b2269e4c upstream.
    
    This lets call intel_crt_reset() in contexts where IRQs are disabled and
    as such, can't hold the locks required to work with the connectors.
    
    Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Lyude <cpaul@redhat.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 50b070e8224f7bf86622ede1abee9fa3d3dc2f10
Author: Jan Kara <jack@suse.cz>
Date:   Thu May 26 16:55:18 2016 +0200

    fs: Give dentry to inode_change_ok() instead of inode
    
    commit 31051c85b5e2aaaf6315f74c72a732673632a905 upstream.
    
    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.
    
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Jan Kara <jack@suse.cz>
    [bwh: Backported to 3.16:
     - Drop changes to orangefs, overlayfs
     - Adjust filenames, context
     - In nfsd, pass dentry to nfsd_sanitize_attrs()
     - Update ext3 as well]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2dd45cd109b0a950f1022f8fbddae2383b6015a0
Author: Jan Kara <jack@suse.cz>
Date:   Thu May 26 17:12:41 2016 +0200

    fuse: Propagate dentry down to inode_change_ok()
    
    commit 62490330769c1ce5dcba3f1f3e8f4005e9b797e6 upstream.
    
    To avoid clearing of capabilities or security related extended
    attributes too early, inode_change_ok() will need to take dentry instead
    of inode. Propagate it down to fuse_do_setattr().
    
    Acked-by: Miklos Szeredi <mszeredi@redhat.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Jan Kara <jack@suse.cz>
    [bwh: Backported to 3.16: open-code file_dentry()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e043e711a028a94906d2e28efd19a364842ea61b
Author: Jan Kara <jack@suse.cz>
Date:   Thu May 26 14:46:43 2016 +0200

    xfs: Propagate dentry down to inode_change_ok()
    
    commit 69bca80744eef58fa155e8042996b968fec17b26 upstream.
    
    To avoid clearing of capabilities or security related extended
    attributes too early, inode_change_ok() will need to take dentry instead
    of inode. Propagate dentry down to functions calling inode_change_ok().
    This is rather straightforward except for xfs_set_mode() function which
    does not have dentry easily available. Luckily that function does not
    call inode_change_ok() anyway so we just have to do a little dance with
    function prototypes.
    
    Acked-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Jan Kara <jack@suse.cz>
    [bwh: Backported to 3.16:
     - Keep XFS_ERROR() calls
     - Adjust context, indentation]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1c608c2d1aefca2bf63497663e17cfb49e6b022c
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Wed Nov 30 23:13:05 2016 +0000

    Revert "fs: Give dentry to inode_change_ok() instead of inode"
    
    This reverts commit be9df699432235753c3824b0f5a27d46de7fdc9e, which was
    commit 31051c85b5e2aaaf6315f74c72a732673632a905 upstream.  The backport
    breaks fuse and makes a mess of xfs, which can be improved by picking
    further upstream commits as I should have done in the first place.
    
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>