commit 07a40fa22291c6d10583ab00fc8589e3c2088372
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sun Nov 26 13:51:12 2017 +0000

    Linux 3.2.96

commit 2c0a646da94d4e334e4070286e0361f91cd4f016
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Wed Nov 22 02:04:29 2017 +0000

    mac80211: Fix null dereference in ieee80211_key_link()
    
    Commit ef810e7c3d2a ("mac80211: accept key reinstall without changing
    anything") moved the initialisation of key->sdata later in
    ieee80211_key_link().  In the upstream commit fdf7cb4185b6 this was
    fine, but in this version of the function there is additional code
    which relies on key->sdata.  Change this to use the value that will be
    (conditionally) assigned to it later.
    
    Cc: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3599fa6eb4415945063710c7be20c74ce6f2e3b4
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Oct 24 21:12:13 2017 +0200

    mac80211: don't compare TKIP TX MIC key in reinstall prevention
    
    commit cfbb0d90a7abb289edc91833d0905931f8805f12 upstream.
    
    For the reinstall prevention, the code I had added compares the
    whole key. It turns out though that iwlwifi firmware doesn't
    provide the TKIP TX MIC key as it's not needed in client mode,
    and thus the comparison will always return false.
    
    For client mode, thus always zero out the TX MIC key part before
    doing the comparison in order to avoid accepting the reinstall
    of the key with identical encryption and RX MIC key, but not the
    same TX MIC key (since the supplicant provides the real one.)
    
    Fixes: fdf7cb4185b6 ("mac80211: accept key reinstall without changing anything")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    [bwh: Backported to 3.2:
     - Keep using memcmp() as we don't have crypto_memneq()
     - Adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d7d24810ac55e2f3fb213d6acf80016a0d337c50
Author: Bjørn Mork <bjorn@mork.no>
Date:   Mon Nov 6 15:37:22 2017 +0100

    net: cdc_ether: fix divide by 0 on bad descriptors
    
    commit 2cb80187ba065d7decad7c6614e35e07aec8a974 upstream.
    
    Setting dev->hard_mtu to 0 will cause a divide error in
    usbnet_probe. Protect against devices with bogus CDC Ethernet
    functional descriptors by ignoring a zero wMaxSegmentSize.
    
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Acked-by: Oliver Neukum <oneukum@suse.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.2: parsing code is organised differently]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2de544fd1b16f76f8dd1213d585ce611155ccd34
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Mon Oct 23 16:46:00 2017 -0700

    Input: gtco - fix potential out-of-bound access
    
    commit a50829479f58416a013a4ccca791336af3c584c7 upstream.
    
    parse_hid_report_descriptor() has a while (i < length) loop, which
    only guarantees that there's at least 1 byte in the buffer, but the
    loop body can read multiple bytes which causes out-of-bounds access.
    
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Reviewed-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    [bwh: Backported to 3.2: use &device->usbdev->dev as the device for dev_err()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0df873c63e8e99a8fb6e068d182b860e6e6e07a9
Author: Arvind Yadav <arvind.yadav.cs@gmail.com>
Date:   Mon Oct 9 20:14:48 2017 +0200

    media: imon: Fix null-ptr-deref in imon_probe
    
    commit 58fd55e838276a0c13d1dc7c387f90f25063cbf3 upstream.
    
    It seems that the return value of usb_ifnum_to_if() can be NULL and
    needs to be checked.
    
    Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
    Tested-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 59a7195cd497d430d9f76bc9f71cf53ed4102743
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Sep 21 05:40:18 2017 -0300

    cx231xx-cards: fix NULL-deref on missing association descriptor
    
    commit 6c3b047fa2d2286d5e438bcb470c7b1a49f415f6 upstream.
    
    Make sure to check that we actually have an Interface Association
    Descriptor before dereferencing it during probe to avoid dereferencing a
    NULL-pointer.
    
    Fixes: e0d3bafd0258 ("V4L/DVB (10954): Add cx231xx USB driver")
    
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Tested-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    [bwh: Backported to 3.2: adjust filename, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b92072aadd839c9379190979edac63285ae2b790
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Oct 4 11:01:13 2017 +0200

    USB: serial: console: fix use-after-free after failed setup
    
    commit 299d7572e46f98534033a9e65973f13ad1ce9047 upstream.
    
    Make sure to reset the USB-console port pointer when console setup fails
    in order to avoid having the struct usb_serial be prematurely freed by
    the console code when the device is later disconnected.
    
    Fixes: 73e487fdb75f ("[PATCH] USB console: fix disconnection issues")
    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 16585babafe54375f23f73a8fc323bd51e7955d7
Author: Xin Long <lucien.xin@gmail.com>
Date:   Tue Oct 17 23:26:10 2017 +0800

    sctp: do not peel off an assoc from one netns to another one
    
    commit df80cd9b28b9ebaa284a41df611dbf3a2d05ca74 upstream.
    
    Now when peeling off an association to the sock in another netns, all
    transports in this assoc are not to be rehashed and keep use the old
    key in hashtable.
    
    As a transport uses sk->net as the hash key to insert into hashtable,
    it would miss removing these transports from hashtable due to the new
    netns when closing the sock and all transports are being freeed, then
    later an use-after-free issue could be caused when looking up an asoc
    and dereferencing those transports.
    
    This is a very old issue since very beginning, ChunYu found it with
    syzkaller fuzz testing with this series:
    
      socket$inet6_sctp()
      bind$inet6()
      sendto$inet6()
      unshare(0x40000000)
      getsockopt$inet_sctp6_SCTP_GET_ASSOC_ID_LIST()
      getsockopt$inet_sctp6_SCTP_SOCKOPT_PEELOFF()
    
    This patch is to block this call when peeling one assoc off from one
    netns to another one, so that the netns of all transport would not
    go out-sync with the key in hashtable.
    
    Note that this patch didn't fix it by rehashing transports, as it's
    difficult to handle the situation when the tuple is already in use
    in the new netns. Besides, no one would like to peel off one assoc
    to another netns, considering ipaddrs, ifaces, etc. are usually
    different.
    
    Reported-by: ChunYu Wang <chunwang@redhat.com>
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.2:
     - Add #include <linux/nsproxy.h>
     - Adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c570bbb1d40059d70f32b43619f52cc121329337
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Wed Feb 15 01:26:39 2017 -0500

    ext4: fix fencepost in s_first_meta_bg validation
    
    commit 2ba3e6e8afc9b6188b471f27cf2b5e3cf34e7af2 upstream.
    
    It is OK for s_first_meta_bg to be equal to the number of block group
    descriptor blocks.  (It rarely happens, but it shouldn't cause any
    problems.)
    
    https://bugzilla.kernel.org/show_bug.cgi?id=194567
    
    Fixes: 3a4b77cd47bb837b8557595ec7425f281f2ca1fe
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit dd9bcb2452b4646dd7548ed503bce0c4eb76a4e4
Author: Eryu Guan <guaneryu@gmail.com>
Date:   Thu Dec 1 15:08:37 2016 -0500

    ext4: validate s_first_meta_bg at mount time
    
    commit 3a4b77cd47bb837b8557595ec7425f281f2ca1fe upstream.
    
    Ralf Spenneberg reported that he hit a kernel crash when mounting a
    modified ext4 image. And it turns out that kernel crashed when
    calculating fs overhead (ext4_calculate_overhead()), this is because
    the image has very large s_first_meta_bg (debug code shows it's
    842150400), and ext4 overruns the memory in count_overhead() when
    setting bitmap buffer, which is PAGE_SIZE.
    
    ext4_calculate_overhead():
      buf = get_zeroed_page(GFP_NOFS);  <=== PAGE_SIZE buffer
      blks = count_overhead(sb, i, buf);
    
    count_overhead():
      for (j = ext4_bg_num_gdb(sb, grp); j > 0; j--) { <=== j = 842150400
              ext4_set_bit(EXT4_B2C(sbi, s++), buf);   <=== buffer overrun
              count++;
      }
    
    This can be reproduced easily for me by this script:
    
      #!/bin/bash
      rm -f fs.img
      mkdir -p /mnt/ext4
      fallocate -l 16M fs.img
      mke2fs -t ext4 -O bigalloc,meta_bg,^resize_inode -F fs.img
      debugfs -w -R "ssv first_meta_bg 842150400" fs.img
      mount -o loop fs.img /mnt/ext4
    
    Fix it by validating s_first_meta_bg first at mount time, and
    refusing to mount if its value exceeds the largest possible meta_bg
    number.
    
    Reported-by: Ralf Spenneberg <ralf@os-t.de>
    Signed-off-by: Eryu Guan <guaneryu@gmail.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Andreas Dilger <adilger@dilger.ca>
    [bwh: Backported to 3.2: open-code ext4_has_feature_meta_bg()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4d9031264bf8c9766b1effbbd81c82e6e29cb48e
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Fri Sep 15 09:36:16 2017 -0700

    Input: i8042 - add Gigabyte P57 to the keyboard reset table
    
    commit 697c5d8a36768b36729533fb44622b35d56d6ad0 upstream.
    
    Similar to other Gigabyte laptops, the touchpad on P57 requires a
    keyboard reset to detect Elantech touchpad correctly.
    
    BugLink: https://bugs.launchpad.net/bugs/1594214
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 090836f3082e1861a4acd1d9b1f39f157cb5ee9c
Author: Wanpeng Li <wanpeng.li@hotmail.com>
Date:   Thu Sep 14 03:54:16 2017 -0700

    KVM: async_pf: Fix #DF due to inject "Page not Present" and "Page Ready" exceptions simultaneously
    
    commit 9a6e7c39810e4a8bc7fc95056cefb40583fe07ef upstream.
    
    qemu-system-x86-8600  [004] d..1  7205.687530: kvm_entry: vcpu 2
    qemu-system-x86-8600  [004] ....  7205.687532: kvm_exit: reason EXCEPTION_NMI rip 0xffffffffa921297d info ffffeb2c0e44e018 80000b0e
    qemu-system-x86-8600  [004] ....  7205.687532: kvm_page_fault: address ffffeb2c0e44e018 error_code 0
    qemu-system-x86-8600  [004] ....  7205.687620: kvm_try_async_get_page: gva = 0xffffeb2c0e44e018, gfn = 0x427e4e
    qemu-system-x86-8600  [004] .N..  7205.687628: kvm_async_pf_not_present: token 0x8b002 gva 0xffffeb2c0e44e018
        kworker/4:2-7814  [004] ....  7205.687655: kvm_async_pf_completed: gva 0xffffeb2c0e44e018 address 0x7fcc30c4e000
    qemu-system-x86-8600  [004] ....  7205.687703: kvm_async_pf_ready: token 0x8b002 gva 0xffffeb2c0e44e018
    qemu-system-x86-8600  [004] d..1  7205.687711: kvm_entry: vcpu 2
    
    After running some memory intensive workload in guest, I catch the kworker
    which completes the GUP too quickly, and queues an "Page Ready" #PF exception
    after the "Page not Present" exception before the next vmentry as the above
    trace which will result in #DF injected to guest.
    
    This patch fixes it by clearing the queue for "Page not Present" if "Page Ready"
    occurs before the next vmentry since the GUP has already got the required page
    and shadow page table has already been fixed by "Page Ready" handler.
    
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
    Fixes: 7c90705bf2a3 ("KVM: Inject asynchronous page fault into a PV guest if page is swapped out.")
    [Changed indentation and added clearing of injected. - Radim]
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    [bwh: Backported to 3.2: Don't assign to kvm_queued_exception::injected or
     x86_exception::async_page_fault]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 630fcebf47671aff56b09697d6652262183a5892
Author: Jan H. Schönherr <jschoenh@amazon.de>
Date:   Tue Sep 5 23:58:44 2017 +0200

    KVM: SVM: Add a missing 'break' statement
    
    commit 49a8afca386ee1775519a4aa80f8e121bd227dd4 upstream.
    
    Signed-off-by: Jan H. Schönherr <jschoenh@amazon.de>
    Fixes: f6511935f424 ("KVM: SVM: Add checks for IO instructions")
    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 938e899ca0b5fa31a16172efb2f0124414a3858b
Author: Nisar Sayed <Nisar.Sayed@microchip.com>
Date:   Mon Sep 11 17:43:11 2017 +0000

    smsc95xx: Configure pause time to 0xffff when tx flow control enabled
    
    commit 9c0827317f235865ae421293f8aecf6cb327a63e upstream.
    
    Configure pause time to 0xffff when tx flow control enabled
    
    Set pause time to 0xffff in the pause frame to indicate the
    partner to stop sending the packets. When RX buffer frees up,
    the device sends pause frame with pause time zero for partner to
    resume transmission.
    
    Fixes: 2f7ca802bdae ("Add SMSC LAN9500 USB2.0 10/100 ethernet adapter driver")
    Signed-off-by: Nisar Sayed <Nisar.Sayed@microchip.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d5025b4788cafc54fb0160d9d8a6ff0fd42416f5
Author: Cameron Gutman <aicommander@gmail.com>
Date:   Tue Sep 12 11:27:44 2017 -0700

    Input: xpad - validate USB endpoint type during probe
    
    commit 122d6a347329818419b032c5a1776e6b3866d9b9 upstream.
    
    We should only see devices with interrupt endpoints. Ignore any other
    endpoints that we find, so we don't send try to send them interrupt URBs
    and trigger a WARN down in the USB stack.
    
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Tested-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c59778f2b745d3dd5ce497d200ebdc303eaaabf6
Author: Cameron Gutman <aicommander@gmail.com>
Date:   Tue Jan 3 22:40:38 2017 -0800

    Input: xpad - don't depend on endpoint order
    
    commit c01b5e7464f0cf20936d7467c7528163c4e2782d upstream.
    
    The order of endpoints is well defined on official Xbox pads, but
    we have found at least one 3rd-party pad that doesn't follow the
    standard ("Titanfall 2 Xbox One controller" 0e6f:0165).
    
    Fortunately, we get lucky with this specific pad because it uses
    endpoint addresses that differ only by direction. We know that
    there are other pads out where this is not true, so let's go
    ahead and fix this.
    
    Signed-off-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    [bwh: Backported to 3.2:
     - Use 'fail3' label in case of failure
     - Adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8e6535216c719085f1eea7a61c7512339f79a8fc
Author: Ted Mielczarek <ted@mielczarek.org>
Date:   Fri Aug 8 11:21:59 2014 -0700

    Input: xpad - add support for Xbox One controllers
    
    commit 1a48ff81b3912be5fadae3fafde6c2f632246a4c upstream.
    
    Xbox One controllers require an initialization message to start sending
    data, so xpad_init_output becomes a required function. The Xbox One
    controller does not have LEDs like the Xbox 360 controller, so that
    functionality is not implemented. The format of messages controlling rumble
    is currently undocumented, so rumble support is not yet implemented.
    
    Note that Xbox One controller advertises three interfaces with the same
    interface class, subclass and protocol, so we have to also match against
    interface number.
    
    Signed-off-by: Ted Mielczarek <ted@mielczarek.org>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit da2a3dada9ea15469bdfd06350d055aa8692a27c
Author: Guillermo A. Amaral <g@maral.me>
Date:   Sun Dec 2 23:26:18 2012 -0800

    Input: xpad - add a few new VID/PID combinations
    
    commit 540602a43ae5fa94064f8fae100f5ca75d4c002b upstream.
    
    This adds VID/PID combinations for MadCatz, PDP and PowerA (new).
    
    Removed Pelican 'TSZ' Wired Xbox 360 Controller since it's clashing with Edge
    wireless Controller and I failed to confirm the PID.
    
    Signed-off-by: "Guillermo A. Amaral B." <g@maral.me>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ae0ebfe24b8ca8b5a10022d9dc448f2ddf32782d
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Sep 8 15:48:47 2017 -0700

    ipv6: fix typo in fib6_net_exit()
    
    commit 32a805baf0fb70b6dbedefcd7249ac7f580f9e3b upstream.
    
    IPv6 FIB should use FIB6_TABLE_HASHSZ, not FIB_TABLE_HASHSZ.
    
    Fixes: ba1cc08d9488 ("ipv6: fix memory leak with multiple tables during netns destruction")
    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 4faaefb9e038c5aa09ff5b33a91c2bf9b8b37e93
Author: Sabrina Dubroca <sd@queasysnail.net>
Date:   Fri Sep 8 10:26:19 2017 +0200

    ipv6: fix memory leak with multiple tables during netns destruction
    
    commit ba1cc08d9488c94cb8d94f545305688b72a2a300 upstream.
    
    fib6_net_exit only frees the main and local tables. If another table was
    created with fib6_alloc_table, we leak it when the netns is destroyed.
    
    Fix this in the same way ip_fib_net_exit cleans up tables, by walking
    through the whole hashtable of fib6_table's. We can get rid of the
    special cases for local and main, since they're also part of the
    hashtable.
    
    Reproducer:
        ip netns add x
        ip -net x -6 rule add from 6003:1::/64 table 100
        ip netns del x
    
    Reported-by: Jianlin Shi <jishi@redhat.com>
    Fixes: 58f09b78b730 ("[NETNS][IPV6] ip6_fib - make it per network namespace")
    Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.2:
     - No need to call inetpeer_invalidate_tree()
     - Add the extra iterator variable needed by hlist_for_each_entry_safe()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5cb8ec47887b051ff0d967126651644a0ea6eb9e
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Sep 5 10:12:20 2017 +0200

    genirq: Make sparse_irq_lock protect what it should protect
    
    commit 12ac1d0f6c3e95732d144ffa65c8b20fbd9aa462 upstream.
    
    for_each_active_irq() iterates the sparse irq allocation bitmap. The caller
    must hold sparse_irq_lock. Several code pathes expect that an active bit in
    the sparse bitmap also has a valid interrupt descriptor.
    
    Unfortunately that's not true. The (de)allocation is a two step process,
    which holds the sparse_irq_lock only across the queue/remove from the radix
    tree and the set/clear in the allocation bitmap.
    
    If a iteration locks sparse_irq_lock between the two steps, then it might
    see an active bit but the corresponding irq descriptor is NULL. If that is
    dereferenced unconditionally, then the kernel oopses. Of course, all
    iterator sites could be audited and fixed, but....
    
    There is no reason why the sparse_irq_lock needs to be dropped between the
    two steps, in fact the code becomes simpler when the mutex is held across
    both and the semantics become more straight forward, so future problems of
    missing NULL pointer checks in the iteration are avoided and all existing
    sites are fixed in one go.
    
    Expand the lock held sections so both operations are covered and the bitmap
    and the radixtree are in sync.
    
    Fixes: a05a900a51c7 ("genirq: Make sparse_lock a mutex")
    Reported-and-tested-by: Huang Ying <ying.huang@intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 77d1e45b368a69252a0e3520f30f466072db2a67
Author: SeongJae Park <sj38.park@gmail.com>
Date:   Wed Sep 6 16:24:23 2017 -0700

    mm/vmstat.c: fix wrong comment
    
    commit f113e64121ba9f4791332248b315d9f57ee33a6b upstream.
    
    Comment for pagetypeinfo_showblockcount() is mistakenly duplicated from
    pagetypeinfo_show_free()'s comment.  This commit fixes it.
    
    Link: http://lkml.kernel.org/r/20170809185816.11244-1-sj38.park@gmail.com
    Fixes: 467c996c1e19 ("Print out statistics in relation to fragmentation avoidance to /proc/pagetypeinfo")
    Signed-off-by: SeongJae Park <sj38.park@gmail.com>
    Cc: Michal Hocko <mhocko@kernel.org>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    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 fa380301cdd54070bae40b00c8d06cf6fa35eeef
Author: Jonas Gorski <jonas.gorski@gmail.com>
Date:   Tue Jul 18 12:17:27 2017 +0200

    MIPS: BCM63XX: allow NULL clock for clk_get_rate
    
    commit 1b495faec231980b6c719994b24044ccc04ae06c upstream.
    
    Make the behaviour of clk_get_rate consistent with common clk's
    clk_get_rate by accepting NULL clocks as parameter. Some device
    drivers rely on this, and will cause an OOPS otherwise.
    
    Fixes: e7300d04bd08 ("MIPS: BCM63xx: Add support for the Broadcom BCM63xx family of SOCs.")
    Reported-by: Mathias Kresin <dev@kresin.me>
    Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Cc: bcm-kernel-feedback-list@broadcom.com
    Cc: James Hogan <james.hogan@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Cc: linux-kernel@vger.kernel.org
    Patchwork: https://patchwork.linux-mips.org/patch/16776/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 72e9d0bd45d27b2d3cd0b458514be7360c3d748c
Author: Jonas Gorski <jonas.gorski@gmail.com>
Date:   Tue Jul 18 12:17:26 2017 +0200

    MIPS: AR7: allow NULL clock for clk_get_rate
    
    commit 585e0e9d02a690c29932b2fc0789835c7b91d448 upstream.
    
    Make the behaviour of clk_get_rate consistent with common clk's
    clk_get_rate by accepting NULL clocks as parameter. Some device
    drivers rely on this, and will cause an OOPS otherwise.
    
    Fixes: 780019ddf02f ("MIPS: AR7: Implement clock API")
    Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
    Reported-by: Mathias Kresin <dev@kresin.me>
    Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
    Cc: James Hogan <james.hogan@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Cc: linux-kernel@vger.kernel.org
    Patchwork: https://patchwork.linux-mips.org/patch/16775/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ca8172873304dbc6c6047b698452d9c89d86f037
Author: Guillaume Nault <g.nault@alphalink.fr>
Date:   Fri Sep 1 17:58:51 2017 +0200

    l2tp: pass tunnel pointer to ->session_create()
    
    commit f026bc29a8e093edfbb2a77700454b285c97e8ad upstream.
    
    Using l2tp_tunnel_find() in pppol2tp_session_create() and
    l2tp_eth_create() is racy, because no reference is held on the
    returned session. These functions are only used to implement the
    ->session_create callback which is run by l2tp_nl_cmd_session_create().
    Therefore searching for the parent tunnel isn't necessary because
    l2tp_nl_cmd_session_create() already has a pointer to it and holds a
    reference.
    
    This patch modifies ->session_create()'s prototype to directly pass the
    the parent tunnel as parameter, thus avoiding searching for it in
    pppol2tp_session_create() and l2tp_eth_create().
    
    Since we have to touch the ->session_create() call in
    l2tp_nl_cmd_session_create(), let's also remove the useless conditional:
    we know that ->session_create isn't NULL at this point because it's
    already been checked earlier in this same function.
    
    Finally, one might be tempted to think that the removed
    l2tp_tunnel_find() calls were harmless because they would return the
    same tunnel as the one held by l2tp_nl_cmd_session_create() anyway.
    But that tunnel might be removed and a new one created with same tunnel
    Id before the l2tp_tunnel_find() call. In this case l2tp_tunnel_find()
    would return the new tunnel which wouldn't be protected by the
    reference held by l2tp_nl_cmd_session_create().
    
    Fixes: 309795f4bec2 ("l2tp: Add netlink control API for L2TP")
    Fixes: d9e31d17ceba ("l2tp: Add L2TP ethernet pseudowire support")
    Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c211c4acad97c764eebc71d11d91bc9af0c4b5da
Author: Guillaume Nault <g.nault@alphalink.fr>
Date:   Fri Sep 1 17:58:48 2017 +0200

    l2tp: prevent creation of sessions on terminated tunnels
    
    commit f3c66d4e144a0904ea9b95d23ed9f8eb38c11bfb upstream.
    
    l2tp_tunnel_destruct() sets tunnel->sock to NULL, then removes the
    tunnel from the pernet list and finally closes all its sessions.
    Therefore, it's possible to add a session to a tunnel that is still
    reachable, but for which tunnel->sock has already been reset. This can
    make l2tp_session_create() dereference a NULL pointer when calling
    sock_hold(tunnel->sock).
    
    This patch adds the .acpt_newsess field to struct l2tp_tunnel, which is
    used by l2tp_tunnel_closeall() to prevent addition of new sessions to
    tunnels. Resetting tunnel->sock is done after l2tp_tunnel_closeall()
    returned, so that l2tp_session_add_to_tunnel() can safely take a
    reference on it when .acpt_newsess is true.
    
    The .acpt_newsess field is modified in l2tp_tunnel_closeall(), rather
    than in l2tp_tunnel_destruct(), so that it benefits all tunnel removal
    mechanisms. E.g. on UDP tunnels, a session could be added to a tunnel
    after l2tp_udp_encap_destroy() proceeded. This would prevent the tunnel
    from being removed because of the references held by this new session
    on the tunnel and its socket. Even though the session could be removed
    manually later on, this defeats the purpose of
    commit 9980d001cec8 ("l2tp: add udp encap socket destroy handler").
    
    Fixes: fd558d186df2 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
    Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.2:
     - Drop changes in l2tp_tunnel_destruct(), as the assignment to tunnel->sock
       is already after the call to l2tp_tunnel_closeall()
     - Adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit da8772cac83ae16f469532b3bb27aacbb9ead399
Author: Amir Goldstein <amir73il@gmail.com>
Date:   Wed Aug 30 09:23:12 2017 -0700

    xfs: fix incorrect log_flushed on fsync
    
    commit 47c7d0b19502583120c3f396c7559e7a77288a68 upstream.
    
    When calling into _xfs_log_force{,_lsn}() with a pointer
    to log_flushed variable, log_flushed will be set to 1 if:
    1. xlog_sync() is called to flush the active log buffer
    AND/OR
    2. xlog_wait() is called to wait on a syncing log buffers
    
    xfs_file_fsync() checks the value of log_flushed after
    _xfs_log_force_lsn() call to optimize away an explicit
    PREFLUSH request to the data block device after writing
    out all the file's pages to disk.
    
    This optimization is incorrect in the following sequence of events:
    
     Task A                    Task B
     -------------------------------------------------------
     xfs_file_fsync()
       _xfs_log_force_lsn()
         xlog_sync()
            [submit PREFLUSH]
                               xfs_file_fsync()
                                 file_write_and_wait_range()
                                   [submit WRITE X]
                                   [endio  WRITE X]
                                 _xfs_log_force_lsn()
                                   xlog_wait()
            [endio  PREFLUSH]
    
    The write X is not guarantied to be on persistent storage
    when PREFLUSH request in completed, because write A was submitted
    after the PREFLUSH request, but xfs_file_fsync() of task A will
    be notified of log_flushed=1 and will skip explicit flush.
    
    If the system crashes after fsync of task A, write X may not be
    present on disk after reboot.
    
    This bug was discovered and demonstrated using Josef Bacik's
    dm-log-writes target, which can be used to record block io operations
    and then replay a subset of these operations onto the target device.
    The test goes something like this:
    - Use fsx to execute ops of a file and record ops on log device
    - Every now and then fsync the file, store md5 of file and mark
      the location in the log
    - Then replay log onto device for each mark, mount fs and compare
      md5 of file to stored value
    
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Josef Bacik <jbacik@fb.com>
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bf70348b602b6b39cd26cc84fb4518db507bfda6
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Fri Sep 1 12:04:09 2017 -0400

    ftrace: Fix selftest goto location on error
    
    commit 46320a6acc4fb58f04bcf78c4c942cc43b20f986 upstream.
    
    In the second iteration of trace_selftest_ops(), the error goto label is
    wrong in the case where trace_selftest_test_global_cnt is off. In the
    case of error, it leaks the dynamic ops that was allocated.
    
    Fixes: 95950c2e ("ftrace: Add self-tests for multiple function trace users")
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    [bwh: Backported to 3.2: adjust context, indentation]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 79ac778a4f68c4609e069eb965586af42dd71119
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Tue Aug 29 21:23:49 2017 +0200

    driver core: bus: Fix a potential double free
    
    commit 0f9b011d3321ca1079c7a46c18cb1956fbdb7bcb upstream.
    
    The .release function of driver_ktype is 'driver_release()'.
    This function frees the container_of this kobject.
    
    So, this memory must not be freed explicitly in the error handling path of
    'bus_add_driver()'. Otherwise a double free will occur.
    
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5abbd54557e1d841669b35c10558e1556d6a32c2
Author: Paul Mackerras <paulus@ozlabs.org>
Date:   Wed Aug 30 14:12:24 2017 +1000

    powerpc: Correct instruction code for xxlor instruction
    
    commit 93b2d3cf3733b4060d3623161551f51ea1ab5499 upstream.
    
    The instruction code for xxlor that commit 0016a4cf5582 ("powerpc:
    Emulate most Book I instructions in emulate_step()", 2010-06-15)
    added is actually the code for xxlnor.  It is used in get_vsr()
    and put_vsr() and the effect of the error is that if emulate_step
    is used to emulate a VSX load or store from any register other
    than vsr0, the bitwise complement of the correct value will be
    loaded or stored.  This corrects the error.
    
    Fixes: 0016a4cf5582 ("powerpc: Emulate most Book I instructions in emulate_step()")
    Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c82575e660913d358714ab1a3123f497318b73a3
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Aug 25 13:33:40 2017 +0300

    powerpc/44x: Fix mask and shift to zero bug
    
    commit 8d046759f6ad75824fdf7b9c9a3da0272ea9ea92 upstream.
    
    My static checker complains that 0x00001800 >> 13 is zero. Looking at
    the context, it seems like a copy and paste bug from the line below
    and probably 0x3 << 13 or 0x00006000 was intended.
    
    Fixes: 2af59f7d5c3e ("[POWERPC] 4xx: Add 405GPr and 405EP support in boot wrapper")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1714a066d71dc00bc336aa1565ec86551e388704
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Aug 30 16:30:35 2017 +0300

    scsi: qla2xxx: Fix an integer overflow in sysfs code
    
    commit e6f77540c067b48dee10f1e33678415bfcc89017 upstream.
    
    The value of "size" comes from the user.  When we add "start + size" it
    could lead to an integer overflow bug.
    
    It means we vmalloc() a lot more memory than we had intended.  I believe
    that on 64 bit systems vmalloc() can succeed even if we ask it to
    allocate huge 4GB buffers.  So we would get memory corruption and likely
    a crash when we call ha->isp_ops->write_optrom() and ->read_optrom().
    
    Only root can trigger this bug.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=194061
    
    Fixes: b7cc176c9eb3 ("[SCSI] qla2xxx: Allow region-based flash-part accesses.")
    Reported-by: shqking <shqking@gmail.com>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 959626c47d701bd308d02b240ac36dd9086cc189
Author: Chad Dupuis <chad.dupuis@qlogic.com>
Date:   Wed Feb 26 04:14:56 2014 -0500

    qla2xxx: Add mutex around optrom calls to serialize accesses.
    
    commit 7a8ab9c840b5dff9bb70328338a86444ed1c2415 upstream.
    
    Signed-off-by: Chad Dupuis <chad.dupuis@qlogic.com>
    Signed-off-by: Saurav Kashyap <saurav.kashyap@qlogic.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4eec08bd11df161bd9d404ab5356a4e6510a5279
Author: Joe Carnuccio <joe.carnuccio@qlogic.com>
Date:   Fri Nov 18 09:03:13 2011 -0800

    qla2xxx: Corrections to returned sysfs error codes.
    
    commit 71dfe9e776878d9583d004edade55edc2bdac5eb upstream.
    
    Correct the erroneous return codes introduced by the following patch:
    "Return sysfs error codes appropriate to conditions".
    
    Signed-off-by: Joe Carnuccio <joe.carnuccio@qlogic.com>
    Signed-off-by: Chad Dupuis <chad.dupuis@qlogic.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a37d7be7a0aafd3aaa224b0ba79f63f55881afb9
Author: Brian King <brking@linux.vnet.ibm.com>
Date:   Tue Aug 29 10:00:29 2017 -0500

    scsi: aacraid: Fix command send race condition
    
    commit 1ae948fa4f00f3a2823e7cb19a3049ef27dd6947 upstream.
    
    This fixes a potential race condition observed on Power systems.
    
    Several places throughout the aacraid driver call aac_fib_send or
    similar to send a command to the aacraid adapter, then check the return
    code to determine if the command was actually sent to the adapter, then
    update the phase field in the scsi command scratch pad area to track
    that the firmware now owns this command.  However, there is nothing that
    ensures that by the time the aac_fib_send function returns and we go to
    write to the scsi command, that the command hasn't already completed and
    the scsi command has been freed.  This was causing random crashes in the
    TCP stack which was tracked down to be caused by memory that had been a
    struct request + scsi_cmnd being now used for an skbuff. Memory
    poisoning was enabled in the kernel to debug this which showed that the
    last owner of the memory that had been freed was aacraid and that it was
    a struct request.  The memory that was corrupted was the exact data
    pattern of AAC_OWNER_FIRMWARE and it was at the same offset that aacraid
    writes, which is scsicmd->SCp.phase. The patch below resolves this
    issue.
    
    Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
    Tested-by: Wen Xiong <wenxiong@linux.vnet.ibm.com>
    Reviewed-by: Dave Carroll <david.carroll@microsemi.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    [bwh: Backported to 3.2:
     - Drop changes to aac_send_hba_fib()
     - Adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 48dc5149694b5d77d730d6a07e28488883f61500
Author: Leon Romanovsky <leonro@mellanox.com>
Date:   Mon Aug 28 16:38:21 2017 +0300

    net/mlx4_core: Make explicit conversion to 64bit value
    
    commit 187782eb58a89ea030731114c6ae37842a4472fe upstream.
    
    The "lg" variable is declared as int so in all places where this variable
    is used as a shift operand, the output will be int too.
    
    This produces the following smatch warning:
    drivers/net/ethernet/mellanox/mlx4/fw.c:1532 mlx4_map_cmd() warn:
            should '1 << lg' be a 64 bit type?
    
    Simple declaration of "1" to be "1ULL" will fix the issue.
    
    Fixes: 225c7b1feef1 ("IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters")
    Signed-off-by: Leon Romanovsky <leonro@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 ff408ba4cd682a3844fd833c0281a68fec6239b3
Author: Mike Marciniszyn <mike.marciniszyn@intel.com>
Date:   Mon Aug 21 18:26:20 2017 -0700

    IB/{qib, hfi1}: Avoid flow control testing for RDMA write operation
    
    commit 5b0ef650bd0f820e922fcc42f1985d4621ae19cf upstream.
    
    Section 9.7.7.2.5 of the 1.3 IBTA spec clearly says that receive
    credits should never apply to RDMA write.
    
    qib and hfi1 were doing that.  The following situation will result
    in a QP hang:
    - A prior SEND or RDMA_WRITE with immmediate consumed the last
      credit for a QP using RC receive buffer credits
    - The prior op is acked so there are no more acks
    - The peer ULP fails to post receive for some reason
    - An RDMA write sees that the credits are exhausted and waits
    - The peer ULP posts receive buffers
    - The ULP posts a send or RDMA write that will be hung
    
    The fix is to avoid the credit test for the RDMA write operation.
    
    Reviewed-by: Kaike Wan <kaike.wan@intel.com>
    Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    [bwh: Backported to 3.2:
     - Drop changes to hfi1
     - Adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5d04de9a24824635e4da8da62b23a797f4774aef
Author: Dmitry Fleytman <dmitry@daynix.com>
Date:   Fri Aug 25 10:38:35 2017 +0300

    usb: Add device quirk for Logitech HD Pro Webcam C920-C
    
    commit a1279ef74eeeb5f627f091c71d80dd7ac766c99d upstream.
    
    Commit e0429362ab15
    ("usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e")
    introduced quirk to workaround an issue with some Logitech webcams.
    
    Apparently model C920-C has the same issue so applying
    the same quirk as well.
    
    See aforementioned commit message for detailed explanation of the problem.
    
    Signed-off-by: Dmitry Fleytman <dmitry@daynix.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bd6280e2b948f68979811bf7c6186fcd51b3cf93
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Wed Aug 16 10:53:20 2017 +0800

    usb: quirks: add delay init quirk for Corsair Strafe RGB keyboard
    
    commit de3af5bf259d7a0bfaac70441c8568ab5998d80c upstream.
    
    Corsair Strafe RGB keyboard has trouble to initialize:
    
    [ 1.679455] usb 3-6: new full-speed USB device number 4 using xhci_hcd
    [ 6.871136] usb 3-6: unable to read config index 0 descriptor/all
    [ 6.871138] usb 3-6: can't read configurations, error -110
    [ 6.991019] usb 3-6: new full-speed USB device number 5 using xhci_hcd
    [ 12.246642] usb 3-6: unable to read config index 0 descriptor/all
    [ 12.246644] usb 3-6: can't read configurations, error -110
    [ 12.366555] usb 3-6: new full-speed USB device number 6 using xhci_hcd
    [ 17.622145] usb 3-6: unable to read config index 0 descriptor/all
    [ 17.622147] usb 3-6: can't read configurations, error -110
    [ 17.742093] usb 3-6: new full-speed USB device number 7 using xhci_hcd
    [ 22.997715] usb 3-6: unable to read config index 0 descriptor/all
    [ 22.997716] usb 3-6: can't read configurations, error -110
    
    Although it may work after several times unpluging/pluging:
    
    [ 68.195240] usb 3-6: new full-speed USB device number 11 using xhci_hcd
    [ 68.337459] usb 3-6: New USB device found, idVendor=1b1c, idProduct=1b20
    [ 68.337463] usb 3-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    [ 68.337466] usb 3-6: Product: Corsair STRAFE RGB Gaming Keyboard
    [ 68.337468] usb 3-6: Manufacturer: Corsair
    [ 68.337470] usb 3-6: SerialNumber: 0F013021AEB8046755A93ED3F5001941
    
    Tried three quirks: USB_QUIRK_DELAY_INIT, USB_QUIRK_NO_LPM and
    USB_QUIRK_DEVICE_QUALIFIER, user confirmed that USB_QUIRK_DELAY_INIT alone
    can workaround this issue. Hence add the quirk for Corsair Strafe RGB.
    
    BugLink: https://bugs.launchpad.net/bugs/1678477
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 35c89368d5e8ce48fb38b93acad2492505c0942a
Author: Douglas Anderson <dianders@chromium.org>
Date:   Thu Aug 10 15:42:22 2017 -0700

    USB: core: Avoid race of async_completed() w/ usbdev_release()
    
    commit ed62ca2f4f51c17841ea39d98c0c409cb53a3e10 upstream.
    
    While running reboot tests w/ a specific set of USB devices (and
    slub_debug enabled), I found that once every few hours my device would
    be crashed with a stack that looked like this:
    
    [   14.012445] BUG: spinlock bad magic on CPU#0, modprobe/2091
    [   14.012460]  lock: 0xffffffc0cb055978, .magic: ffffffc0, .owner: cryption contexts: %lu/%lu
    [   14.012460] /1025536097, .owner_cpu: 0
    [   14.012466] CPU: 0 PID: 2091 Comm: modprobe Not tainted 4.4.79 #352
    [   14.012468] Hardware name: Google Kevin (DT)
    [   14.012471] Call trace:
    [   14.012483] [<....>] dump_backtrace+0x0/0x160
    [   14.012487] [<....>] show_stack+0x20/0x28
    [   14.012494] [<....>] dump_stack+0xb4/0xf0
    [   14.012500] [<....>] spin_dump+0x8c/0x98
    [   14.012504] [<....>] spin_bug+0x30/0x3c
    [   14.012508] [<....>] do_raw_spin_lock+0x40/0x164
    [   14.012515] [<....>] _raw_spin_lock_irqsave+0x64/0x74
    [   14.012521] [<....>] __wake_up+0x2c/0x60
    [   14.012528] [<....>] async_completed+0x2d0/0x300
    [   14.012534] [<....>] __usb_hcd_giveback_urb+0xc4/0x138
    [   14.012538] [<....>] usb_hcd_giveback_urb+0x54/0xf0
    [   14.012544] [<....>] xhci_irq+0x1314/0x1348
    [   14.012548] [<....>] usb_hcd_irq+0x40/0x50
    [   14.012553] [<....>] handle_irq_event_percpu+0x1b4/0x3f0
    [   14.012556] [<....>] handle_irq_event+0x4c/0x7c
    [   14.012561] [<....>] handle_fasteoi_irq+0x158/0x1c8
    [   14.012564] [<....>] generic_handle_irq+0x30/0x44
    [   14.012568] [<....>] __handle_domain_irq+0x90/0xbc
    [   14.012572] [<....>] gic_handle_irq+0xcc/0x18c
    
    Investigation using kgdb() found that the wait queue that was passed
    into wake_up() had been freed (it was filled with slub_debug poison).
    
    I analyzed and instrumented the code and reproduced.  My current
    belief is that this is happening:
    
    1. async_completed() is called (from IRQ).  Moves "as" onto the
       completed list.
    2. On another CPU, proc_reapurbnonblock_compat() calls
       async_getcompleted().  Blocks on spinlock.
    3. async_completed() releases the lock; keeps running; gets blocked
       midway through wake_up().
    4. proc_reapurbnonblock_compat() => async_getcompleted() gets the
       lock; removes "as" from completed list and frees it.
    5. usbdev_release() is called.  Frees "ps".
    6. async_completed() finally continues running wake_up().  ...but
       wake_up() has a pointer to the freed "ps".
    
    The instrumentation that led me to believe this was based on adding
    some trace_printk() calls in a select few functions and then using
    kdb's "ftdump" at crash time.  The trace follows (NOTE: in the trace
    below I cheated a little bit and added a udelay(1000) in
    async_completed() after releasing the spinlock because I wanted it to
    trigger quicker):
    
    <...>-2104   0d.h2 13759034us!: async_completed at start: as=ffffffc0cc638200
    mtpd-2055    3.... 13759356us : async_getcompleted before spin_lock_irqsave
    mtpd-2055    3d..1 13759362us : async_getcompleted after list_del_init: as=ffffffc0cc638200
    mtpd-2055    3.... 13759371us+: proc_reapurbnonblock_compat: free_async(ffffffc0cc638200)
    mtpd-2055    3.... 13759422us+: async_getcompleted before spin_lock_irqsave
    mtpd-2055    3.... 13759479us : usbdev_release at start: ps=ffffffc0cc042080
    mtpd-2055    3.... 13759487us : async_getcompleted before spin_lock_irqsave
    mtpd-2055    3.... 13759497us!: usbdev_release after kfree(ps): ps=ffffffc0cc042080
    <...>-2104   0d.h2 13760294us : async_completed before wake_up(): as=ffffffc0cc638200
    
    To fix this problem we can just move the wake_up() under the ps->lock.
    There should be no issues there that I'm aware of.
    
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    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 7a8f94b0198aa17034da702f020411ad996f63e2
Author: Colin Ian King <colin.king@canonical.com>
Date:   Tue Aug 22 10:21:20 2017 -0400

    media: em28xx: calculate left volume level correctly
    
    commit 801e3659bf2c87c31b7024087d61e89e172b5651 upstream.
    
    The calculation of the left volume looks suspect, the value of
    0x1f - ((val << 8) & 0x1f) is always 0x1f. The debug prior to the
    assignment of value[1] prints the left volume setting using the
    calculation 0x1f - (val >> 8) & 0x1f which looks correct to me.
    Fix the left volume by using the correct expression as used in
    the debug.
    
    Detected by CoverityScan, CID#146140 ("Wrong operator used")
    
    Fixes: 850d24a5a861 ("[media] em28xx-alsa: add mixer support for AC97 volume controls")
    
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Hans Verkuil <hansverk@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f9f71f3a1e4f36cd4c3493003eb9a0c5c234ca52
Author: Sean Young <sean@mess.org>
Date:   Thu Aug 3 17:42:28 2017 -0400

    media: lirc_zilog: driver only sends LIRCCODE
    
    commit 89d8a2cc51d1f29ea24a0b44dde13253141190a0 upstream.
    
    This driver cannot send pulse, it only accepts driver-dependent codes.
    
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c889e4cbe9b3975b3f8d109c397b0b8ef2d7bd2f
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Tue Aug 8 08:56:21 2017 -0400

    media: uvcvideo: Prevent heap overflow when accessing mapped controls
    
    commit 7e09f7d5c790278ab98e5f2c22307ebe8ad6e8ba upstream.
    
    The size of uvc_control_mapping is user controlled leading to a
    potential heap overflow in the uvc driver. This adds a check to verify
    the user provided size fits within the bounds of the defined buffer
    size.
    
    Originally-from: Richard Simmons <rssimmo@amazon.com>
    
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e813577167c4a1c3f25cd9d84c29301b82d95597
Author: Bart Van Assche <bart.vanassche@wdc.com>
Date:   Thu Aug 17 13:12:44 2017 -0700

    block: Relax a check in blk_start_queue()
    
    commit 4ddd56b003f251091a67c15ae3fe4a5c5c5e390a upstream.
    
    Calling blk_start_queue() from interrupt context with the queue
    lock held and without disabling IRQs, as the skd driver does, is
    safe. This patch avoids that loading the skd driver triggers the
    following warning:
    
    WARNING: CPU: 11 PID: 1348 at block/blk-core.c:283 blk_start_queue+0x84/0xa0
    RIP: 0010:blk_start_queue+0x84/0xa0
    Call Trace:
     skd_unquiesce_dev+0x12a/0x1d0 [skd]
     skd_complete_internal+0x1e7/0x5a0 [skd]
     skd_complete_other+0xc2/0xd0 [skd]
     skd_isr_completion_posted.isra.30+0x2a5/0x470 [skd]
     skd_isr+0x14f/0x180 [skd]
     irq_forced_thread_fn+0x2a/0x70
     irq_thread+0x144/0x1a0
     kthread+0x125/0x140
     ret_from_fork+0x2a/0x40
    
    Fixes: commit a038e2536472 ("[PATCH] blk_start_queue() must be called with irq disabled - add warning")
    Signed-off-by: Bart Van Assche <bart.vanassche@wdc.com>
    Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
    Cc: Andrew Morton <akpm@osdl.org>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Hannes Reinecke <hare@suse.de>
    Cc: Johannes Thumshirn <jthumshirn@suse.de>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a08789b3fa9475ecfc767aeba88b0f0303459c90
Author: Xiangliang.Yu <Xiangliang.Yu@amd.com>
Date:   Wed Aug 16 14:25:51 2017 +0800

    drm/ttm: Fix accounting error when fail to get pages for pool
    
    commit 9afae2719273fa1d406829bf3498f82dbdba71c7 upstream.
    
    When fail to get needed page for pool, need to put allocated pages
    into pool. But current code has a miscalculation of allocated pages,
    correct it.
    
    Signed-off-by: Xiangliang.Yu <Xiangliang.Yu@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Monk Liu <monk.liu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 27c98187446ad56a2911e5c83baf4ebf68492b91
Author: Andrey Korolyov <andrey@xdel.ru>
Date:   Thu Aug 10 13:21:14 2017 +0300

    cs5536: add support for IDE controller variant
    
    commit 591b6bb605785c12a21e8b07a08a277065b655a5 upstream.
    
    Several legacy devices such as Geode-based Cisco ASA appliances
    and DB800 development board do possess CS5536 IDE controller
    with different PCI id than existing one. Using pata_generic is
    not always feasible as at least DB800 requires MSR quirk from
    pata_cs5536 to be used with vendor firmware.
    
    Signed-off-by: Andrey Korolyov <andrey@xdel.ru>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit af8bbadc62b289fd658e56b02ecdefd808c4ddff
Author: Finn Thain <fthain@telegraphics.com.au>
Date:   Fri Aug 4 01:43:19 2017 -0400

    scsi: mac_esp: Fix PIO transfers for MESSAGE IN phase
    
    commit 7640d91d285893a5cf1e62b2cd00f0884c401d93 upstream.
    
    When in MESSAGE IN phase, the ESP device does not automatically
    acknowledge each byte that is transferred by PIO. The mac_esp driver
    neglects to explicitly ack them, which causes a timeout during messages
    larger than one byte (e.g. tag bytes during reconnect). Fix this with an
    ESP_CMD_MOK command after each byte.
    
    The MESSAGE IN phase is also different in that each byte transferred
    raises ESP_INTR_FDONE. So don't exit the transfer loop for this interrupt,
    for this phase.
    
    That resolves the "Reconnect IRQ2 timeout" error on those Macs which use
    PIO transfers instead of PDMA. This patch also improves on the weak tests
    for unexpected interrupts and phase changes during PIO transfers.
    
    Tested-by: Stan Johnson <userm57@yahoo.com>
    Fixes: 02507a80b35e ("[PATCH] [SCSI] mac_esp: fix PIO mode, take 2")
    Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b467649e33ec97a1956c2038bb43e317f32a9911
Author: Steffen Maier <maier@linux.vnet.ibm.com>
Date:   Fri Jul 28 12:30:57 2017 +0200

    scsi: zfcp: trace HBA FSF response by default on dismiss or timedout late response
    
    commit fdb7cee3b9e3c561502e58137a837341f10cbf8b upstream.
    
    At the default trace level, we only trace unsuccessful events including
    FSF responses.
    
    zfcp_dbf_hba_fsf_response() only used protocol status and FSF status to
    decide on an unsuccessful response. However, this is only one of multiple
    possible sources determining a failed struct zfcp_fsf_req.
    
    An FSF request can also "fail" if its response runs into an ERP timeout
    or if it gets dismissed because a higher level recovery was triggered
    [trace tags "erscf_1" or "erscf_2" in zfcp_erp_strategy_check_fsfreq()].
    FSF requests with ERP timeout are:
    FSF_QTCB_EXCHANGE_CONFIG_DATA, FSF_QTCB_EXCHANGE_PORT_DATA,
    FSF_QTCB_OPEN_PORT_WITH_DID or FSF_QTCB_CLOSE_PORT or
    FSF_QTCB_CLOSE_PHYSICAL_PORT for target ports,
    FSF_QTCB_OPEN_LUN, FSF_QTCB_CLOSE_LUN.
    One example is slow queue processing which can cause follow-on errors,
    e.g. FSF_PORT_ALREADY_OPEN after FSF_QTCB_OPEN_PORT_WITH_DID timed out.
    In order to see the root cause, we need to see late responses even if the
    channel presented them successfully with FSF_PROT_GOOD and FSF_GOOD.
    Example trace records formatted with zfcpdbf from the s390-tools package:
    
    Timestamp      : ...
    Area           : REC
    Subarea        : 00
    Level          : 1
    Exception      : -
    CPU ID         : ..
    Caller         : ...
    Record ID      : 1
    Tag            : fcegpf1
    LUN            : 0xffffffffffffffff
    WWPN           : 0x<WWPN>
    D_ID           : 0x00<D_ID>
    Adapter status : 0x5400050b
    Port status    : 0x41200000
    LUN status     : 0x00000000
    Ready count    : 0x00000001
    Running count  : 0x...
    ERP want       : 0x02                           ZFCP_ERP_ACTION_REOPEN_PORT
    ERP need       : 0x02                           ZFCP_ERP_ACTION_REOPEN_PORT
    |
    Timestamp      : ...                            30 seconds later
    Area           : REC
    Subarea        : 00
    Level          : 1
    Exception      : -
    CPU ID         : ..
    Caller         : ...
    Record ID      : 2
    Tag            : erscf_2
    LUN            : 0xffffffffffffffff
    WWPN           : 0x<WWPN>
    D_ID           : 0x00<D_ID>
    Adapter status : 0x5400050b
    Port status    : 0x41200000
    LUN status     : 0x00000000
    Request ID     : 0x<request_ID>
    ERP status     : 0x10000000                     ZFCP_STATUS_ERP_TIMEDOUT
    ERP step       : 0x0800                         ZFCP_ERP_STEP_PORT_OPENING
    ERP action     : 0x02                           ZFCP_ERP_ACTION_REOPEN_PORT
    ERP count      : 0x00
    |
    Timestamp      : ...                            later than previous record
    Area           : HBA
    Subarea        : 00
    Level          : 5      > default level         => 3    <= default level
    Exception      : -
    CPU ID         : 00
    Caller         : ...
    Record ID      : 1
    Tag            : fs_qtcb                        => fs_rerr
    Request ID     : 0x<request_ID>
    Request status : 0x00001010                     ZFCP_STATUS_FSFREQ_DISMISSED
                                                    | ZFCP_STATUS_FSFREQ_CLEANUP
    FSF cmnd       : 0x00000005
    FSF sequence no: 0x...
    FSF issued     : ...                            > 30 seconds ago
    FSF stat       : 0x00000000                     FSF_GOOD
    FSF stat qual  : 00000000 00000000 00000000 00000000
    Prot stat      : 0x00000001                     FSF_PROT_GOOD
    Prot stat qual : 00000000 00000000 00000000 00000000
    Port handle    : 0x...
    LUN handle     : 0x00000000
    QTCB log length: ...
    QTCB log info  : ...
    
    In case of problems detecting that new responses are waiting on the input
    queue, we sooner or later trigger adapter recovery due to an FSF request
    timeout (trace tag "fsrth_1").
    FSF requests with FSF request timeout are:
    typically FSF_QTCB_ABORT_FCP_CMND; but theoretically also
    FSF_QTCB_EXCHANGE_CONFIG_DATA or FSF_QTCB_EXCHANGE_PORT_DATA via sysfs,
    FSF_QTCB_OPEN_PORT_WITH_DID or FSF_QTCB_CLOSE_PORT for WKA ports,
    FSF_QTCB_FCP_CMND for task management function (LUN / target reset).
    One or more pending requests can meanwhile have FSF_PROT_GOOD and FSF_GOOD
    because the channel filled in the response via DMA into the request's QTCB.
    
    In a theroretical case, inject code can create an erroneous FSF request
    on purpose. If data router is enabled, it uses deferred error reporting.
    A READ SCSI command can succeed with FSF_PROT_GOOD, FSF_GOOD, and
    SAM_STAT_GOOD. But on writing the read data to host memory via DMA,
    it can still fail, e.g. if an intentionally wrong scatter list does not
    provide enough space. Rather than getting an unsuccessful response,
    we get a QDIO activate check which in turn triggers adapter recovery.
    One or more pending requests can meanwhile have FSF_PROT_GOOD and FSF_GOOD
    because the channel filled in the response via DMA into the request's QTCB.
    Example trace records formatted with zfcpdbf from the s390-tools package:
    
    Timestamp      : ...
    Area           : HBA
    Subarea        : 00
    Level          : 6      > default level         => 3    <= default level
    Exception      : -
    CPU ID         : ..
    Caller         : ...
    Record ID      : 1
    Tag            : fs_norm                        => fs_rerr
    Request ID     : 0x<request_ID2>
    Request status : 0x00001010                     ZFCP_STATUS_FSFREQ_DISMISSED
                                                    | ZFCP_STATUS_FSFREQ_CLEANUP
    FSF cmnd       : 0x00000001
    FSF sequence no: 0x...
    FSF issued     : ...
    FSF stat       : 0x00000000                     FSF_GOOD
    FSF stat qual  : 00000000 00000000 00000000 00000000
    Prot stat      : 0x00000001                     FSF_PROT_GOOD
    Prot stat qual : ........ ........ 00000000 00000000
    Port handle    : 0x...
    LUN handle     : 0x...
    |
    Timestamp      : ...
    Area           : SCSI
    Subarea        : 00
    Level          : 3
    Exception      : -
    CPU ID         : ..
    Caller         : ...
    Record ID      : 1
    Tag            : rsl_err
    Request ID     : 0x<request_ID2>
    SCSI ID        : 0x...
    SCSI LUN       : 0x...
    SCSI result    : 0x000e0000                     DID_TRANSPORT_DISRUPTED
    SCSI retries   : 0x00
    SCSI allowed   : 0x05
    SCSI scribble  : 0x<request_ID2>
    SCSI opcode    : 28...                          Read(10)
    FCP rsp inf cod: 0x00
    FCP rsp IU     : 00000000 00000000 00000000 00000000
                                             ^^     SAM_STAT_GOOD
                     00000000 00000000
    
    Only with luck in both above cases, we could see a follow-on trace record
    of an unsuccesful event following a successful but late FSF response with
    FSF_PROT_GOOD and FSF_GOOD. Typically this was the case for I/O requests
    resulting in a SCSI trace record "rsl_err" with DID_TRANSPORT_DISRUPTED
    [On ZFCP_STATUS_FSFREQ_DISMISSED, zfcp_fsf_protstatus_eval() sets
    ZFCP_STATUS_FSFREQ_ERROR seen by the request handler functions as failure].
    However, the reason for this follow-on trace was invisible because the
    corresponding HBA trace record was missing at the default trace level
    (by default hidden records with tags "fs_norm", "fs_qtcb", or "fs_open").
    
    On adapter recovery, after we had shut down the QDIO queues, we perform
    unsuccessful pseudo completions with flag ZFCP_STATUS_FSFREQ_DISMISSED
    for each pending FSF request in zfcp_fsf_req_dismiss_all().
    In order to find the root cause, we need to see all pseudo responses even
    if the channel presented them successfully with FSF_PROT_GOOD and FSF_GOOD.
    
    Therefore, check zfcp_fsf_req.status for ZFCP_STATUS_FSFREQ_DISMISSED
    or ZFCP_STATUS_FSFREQ_ERROR and trace with a new tag "fs_rerr".
    
    It does not matter that there are numerous places which set
    ZFCP_STATUS_FSFREQ_ERROR after the location where we trace an FSF response
    early. These cases are based on protocol status != FSF_PROT_GOOD or
    == FSF_PROT_FSF_STATUS_PRESENTED and are thus already traced by default
    as trace tag "fs_perr" or "fs_ferr" respectively.
    
    NB: The trace record with tag "fssrh_1" for status read buffers on dismiss
    all remains. zfcp_fsf_req_complete() handles this and returns early.
    All other FSF request types are handled separately and as described above.
    
    Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
    Fixes: 8a36e4532ea1 ("[SCSI] zfcp: enhancement of zfcp debug features")
    Fixes: 2e261af84cdb ("[SCSI] zfcp: Only collect FSF/HBA debug data for matching trace levels")
    Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
    Signed-off-by: Benjamin Block <bblock@linux.vnet.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6c39dd63a30093a57f03f5fcf3ccf9b41fdeb5e1
Author: Steffen Maier <maier@linux.vnet.ibm.com>
Date:   Fri Jul 28 12:30:56 2017 +0200

    scsi: zfcp: fix payload with full FCP_RSP IU in SCSI trace records
    
    commit 12c3e5754c8022a4f2fd1e9f00d19e99ee0d3cc1 upstream.
    
    If the FCP_RSP UI has optional parts (FCP_SNS_INFO or FCP_RSP_INFO) and
    thus does not fit into the fsp_rsp field built into a SCSI trace record,
    trace the full FCP_RSP UI with all optional parts as payload record
    instead of just FCP_SNS_INFO as payload and
    a 1 byte RSP_INFO_CODE part of FCP_RSP_INFO built into the SCSI record.
    
    That way we would also get the full FCP_SNS_INFO in case a
    target would ever send more than
    min(SCSI_SENSE_BUFFERSIZE==96, ZFCP_DBF_PAY_MAX_REC==256)==96.
    
    The mandatory part of FCP_RSP IU is only 24 bytes.
    PAYload costs at least one full PAY record of 256 bytes anyway.
    We cap to the hardware response size which is only FSF_FCP_RSP_SIZE==128.
    So we can just put the whole FCP_RSP IU with any optional parts into
    PAYload similarly as we do for SAN PAY since v4.9 commit aceeffbb59bb
    ("zfcp: trace full payload of all SAN records (req,resp,iels)").
    This does not cause any additional trace records wasting memory.
    
    Decoded trace records were confusing because they showed a hard-coded
    sense data length of 96 even if the FCP_RSP_IU field FCP_SNS_LEN showed
    actually less.
    
    Since the same commit, we set pl_len for SAN traces to the full length of a
    request/response even if we cap the corresponding trace.
    In contrast, here for SCSI traces we set pl_len to the pre-computed
    length of FCP_RSP IU considering SNS_LEN or RSP_LEN if valid.
    Nonetheless we trace a hardcoded payload of length FSF_FCP_RSP_SIZE==128
    if there were optional parts.
    This makes it easier for the zfcpdbf tool to format only the relevant
    part of the long FCP_RSP UI buffer. And any trailing information is still
    available in the payload trace record just in case.
    
    Rename the payload record tag from "fcp_sns" to "fcp_riu" to make the new
    content explicit to zfcpdbf which can then pick a suitable field name such
    as "FCP rsp IU all:" instead of "Sense info :"
    Also, the same zfcpdbf can still be backwards compatible with "fcp_sns".
    
    Old example trace record before this fix, formatted with the tool zfcpdbf
    from s390-tools:
    
    Timestamp      : ...
    Area           : SCSI
    Subarea        : 00
    Level          : 3
    Exception      : -
    CPU id         : ..
    Caller         : 0x...
    Record id      : 1
    Tag            : rsl_err
    Request id     : 0x<request_id>
    SCSI ID        : 0x...
    SCSI LUN       : 0x...
    SCSI result    : 0x00000002
    SCSI retries   : 0x00
    SCSI allowed   : 0x05
    SCSI scribble  : 0x<request_id>
    SCSI opcode    : 00000000 00000000 00000000 00000000
    FCP rsp inf cod: 0x00
    FCP rsp IU     : 00000000 00000000 00000202 00000000
                                           ^^==FCP_SNS_LEN_VALID
                     00000020 00000000
                     ^^^^^^^^==FCP_SNS_LEN==32
    Sense len      : 96 <==min(SCSI_SENSE_BUFFERSIZE,ZFCP_DBF_PAY_MAX_REC)
    Sense info     : 70000600 00000018 00000000 29000000
                     00000400 00000000 00000000 00000000
                     00000000 00000000 00000000 00000000<==superfluous
                     00000000 00000000 00000000 00000000<==superfluous
                     00000000 00000000 00000000 00000000<==superfluous
                     00000000 00000000 00000000 00000000<==superfluous
    
    New example trace records with this fix:
    
    Timestamp      : ...
    Area           : SCSI
    Subarea        : 00
    Level          : 3
    Exception      : -
    CPU ID         : ..
    Caller         : 0x...
    Record ID      : 1
    Tag            : rsl_err
    Request ID     : 0x<request_id>
    SCSI ID        : 0x...
    SCSI LUN       : 0x...
    SCSI result    : 0x00000002
    SCSI retries   : 0x00
    SCSI allowed   : 0x03
    SCSI scribble  : 0x<request_id>
    SCSI opcode    : a30c0112 00000000 02000000 00000000
    FCP rsp inf cod: 0x00
    FCP rsp IU     : 00000000 00000000 00000a02 00000200
                     00000020 00000000
    FCP rsp IU len : 56
    FCP rsp IU all : 00000000 00000000 00000a02 00000200
                                           ^^=FCP_RESID_UNDER|FCP_SNS_LEN_VALID
                     00000020 00000000 70000500 00000018
                     ^^^^^^^^==FCP_SNS_LEN
                                       ^^^^^^^^^^^^^^^^^
                     00000000 240000cb 00011100 00000000
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                     00000000 00000000
                     ^^^^^^^^^^^^^^^^^==FCP_SNS_INFO
    
    Timestamp      : ...
    Area           : SCSI
    Subarea        : 00
    Level          : 1
    Exception      : -
    CPU ID         : ..
    Caller         : 0x...
    Record ID      : 1
    Tag            : lr_okay
    Request ID     : 0x<request_id>
    SCSI ID        : 0x...
    SCSI LUN       : 0x...
    SCSI result    : 0x00000000
    SCSI retries   : 0x00
    SCSI allowed   : 0x05
    SCSI scribble  : 0x<request_id>
    SCSI opcode    : <CDB of unrelated SCSI command passed to eh handler>
    FCP rsp inf cod: 0x00
    FCP rsp IU     : 00000000 00000000 00000100 00000000
                     00000000 00000008
    FCP rsp IU len : 32
    FCP rsp IU all : 00000000 00000000 00000100 00000000
                                           ^^==FCP_RSP_LEN_VALID
                     00000000 00000008 00000000 00000000
                              ^^^^^^^^==FCP_RSP_LEN
                                       ^^^^^^^^^^^^^^^^^==FCP_RSP_INFO
    
    Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
    Fixes: 250a1352b95e ("[SCSI] zfcp: Redesign of the debug tracing for SCSI records.")
    Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
    Signed-off-by: Benjamin Block <bblock@linux.vnet.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 78b8fbf4fc51ce2d8aac4d1b12e77d8fd19dfebf
Author: Steffen Maier <maier@linux.vnet.ibm.com>
Date:   Fri Jul 28 12:30:55 2017 +0200

    scsi: zfcp: fix missing trace records for early returns in TMF eh handlers
    
    commit 1a5d999ebfc7bfe28deb48931bb57faa8e4102b6 upstream.
    
    For problem determination we need to see that we were in scsi_eh
    as well as whether and why we were successful or not.
    
    The following commits introduced new early returns without adding
    a trace record:
    
    v2.6.35 commit a1dbfddd02d2
    ("[SCSI] zfcp: Pass return code from fc_block_scsi_eh to scsi eh")
    on fc_block_scsi_eh() returning != 0 which is FAST_IO_FAIL,
    
    v2.6.30 commit 63caf367e1c9
    ("[SCSI] zfcp: Improve reliability of SCSI eh handlers in zfcp")
    on not having gotten an FSF request after the maximum number of retry
    attempts and thus could not issue a TMF and has to return FAILED.
    
    Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
    Fixes: a1dbfddd02d2 ("[SCSI] zfcp: Pass return code from fc_block_scsi_eh to scsi eh")
    Fixes: 63caf367e1c9 ("[SCSI] zfcp: Improve reliability of SCSI eh handlers in zfcp")
    Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
    Signed-off-by: Benjamin Block <bblock@linux.vnet.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 575864f93bda010b168bab0114f9bb617566e0ce
Author: Steffen Maier <maier@linux.vnet.ibm.com>
Date:   Fri Jul 28 12:30:54 2017 +0200

    scsi: zfcp: fix passing fsf_req to SCSI trace on TMF to correlate with HBA
    
    commit 9fe5d2b2fd30aa8c7827ec62cbbe6d30df4fe3e3 upstream.
    
    Without this fix we get SCSI trace records on task management functions
    which cannot be correlated to HBA trace records because all fields
    related to the FSF request are empty (zero).
    Also, the FCP_RSP_IU is missing as well as any sense data if available.
    
    This was caused by v2.6.14 commit 8a36e4532ea1 ("[SCSI] zfcp: enhancement
    of zfcp debug features") introducing trace records for TMFs but
    hard coding NULL for a possibly existing TMF FSF request.
    The scsi_cmnd scribble is also zero or unrelated for the TMF request
    so it also could not lookup a suitable FSF request from there.
    
    A broken example trace record formatted with zfcpdbf from the s390-tools
    package:
    
    Timestamp      : ...
    Area           : SCSI
    Subarea        : 00
    Level          : 1
    Exception      : -
    CPU ID         : ..
    Caller         : 0x...
    Record ID      : 1
    Tag            : lr_fail
    Request ID     : 0x0000000000000000
                       ^^^^^^^^^^^^^^^^ no correlation to HBA record
    SCSI ID        : 0x<scsitarget>
    SCSI LUN       : 0x<scsilun>
    SCSI result    : 0x000e0000
    SCSI retries   : 0x00
    SCSI allowed   : 0x05
    SCSI scribble  : 0x0000000000000000
    SCSI opcode    : 2a000017 3bb80000 08000000 00000000
    FCP rsp inf cod: 0x00
                       ^^ no TMF response
    FCP rsp IU     : 00000000 00000000 00000000 00000000
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                     00000000 00000000
                     ^^^^^^^^^^^^^^^^^ no interesting FCP_RSP_IU
    Sense len      : ...
    ^^^^^^^^^^^^^^^^^^^^ no sense data length
    Sense info     : ...
    ^^^^^^^^^^^^^^^^^^^^ no sense data content, even if present
    
    There are some true cases where we really do not have an FSF request:
    "rsl_fai" from zfcp_dbf_scsi_fail_send() called for early
    returns / completions in zfcp_scsi_queuecommand(),
    "abrt_or", "abrt_bl", "abrt_ru", "abrt_ar" from
    zfcp_scsi_eh_abort_handler() where we did not get as far,
    "lr_nres", "tr_nres" from zfcp_task_mgmt_function() where we're
    successful and do not need to do anything because adapter stopped.
    For these cases it's correct to pass NULL for fsf_req to _zfcp_dbf_scsi().
    
    Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
    Fixes: 8a36e4532ea1 ("[SCSI] zfcp: enhancement of zfcp debug features")
    Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
    Signed-off-by: Benjamin Block <bblock@linux.vnet.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0ad9409e45b50b9eb971f495db57a95b8c4cf0f2
Author: Steffen Maier <maier@linux.vnet.ibm.com>
Date:   Fri Jul 28 12:30:53 2017 +0200

    scsi: zfcp: fix capping of unsuccessful GPN_FT SAN response trace records
    
    commit 975171b4461be296a35e83ebd748946b81cf0635 upstream.
    
    v4.9 commit aceeffbb59bb ("zfcp: trace full payload of all SAN records
    (req,resp,iels)") fixed trace data loss of 2.6.38 commit 2c55b750a884
    ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
    necessary for problem determination, e.g. to see the
    currently active zone set during automatic port scan.
    
    While it already saves space by not dumping any empty residual entries
    of the large successful GPN_FT response (4 pages), there are seldom cases
    where the GPN_FT response is unsuccessful and likely does not have
    FC_NS_FID_LAST set in fp_flags so we did not cap the trace record.
    We typically see such case for an initiator WWPN, which is not in any zone.
    
    Cap unsuccessful responses to at least the actual basic CT_IU response
    plus whatever fits the SAN trace record built-in "payload" buffer
    just in case there's trailing information
    of which we would at least see the existence and its beginning.
    
    In order not to erroneously cap successful responses, we need to swap
    calling the trace function and setting the CT / ELS status to success (0).
    
    Example trace record pair formatted with zfcpdbf:
    
    Timestamp      : ...
    Area           : SAN
    Subarea        : 00
    Level          : 1
    Exception      : -
    CPU ID         : ..
    Caller         : 0x...
    Record ID      : 1
    Tag            : fssct_1
    Request ID     : 0x<request_id>
    Destination ID : 0x00fffffc
    SAN req short  : 01000000 fc020000 01720ffc 00000000
                     00000008
    SAN req length : 20
    |
    Timestamp      : ...
    Area           : SAN
    Subarea        : 00
    Level          : 1
    Exception      : -
    CPU ID         : ..
    Caller         : 0x...
    Record ID      : 2
    Tag            : fsscth2
    Request ID     : 0x<request_id>
    Destination ID : 0x00fffffc
    SAN resp short : 01000000 fc020000 80010000 00090700
                     00000000 00000000 00000000 00000000 [trailing info]
                     00000000 00000000 00000000 00000000 [trailing info]
    SAN resp length: 16384
    San resp info  : 01000000 fc020000 80010000 00090700
                     00000000 00000000 00000000 00000000 [trailing info]
                     00000000 00000000 00000000 00000000 [trailing info]
                     00000000 00000000 00000000 00000000 [trailing info]
                     00000000 00000000 00000000 00000000 [trailing info]
                     00000000 00000000 00000000 00000000 [trailing info]
                     00000000 00000000 00000000 00000000 [trailing info]
                     00000000 00000000 00000000 00000000 [trailing info]
                     00000000 00000000 00000000 00000000 [trailing info]
                     00000000 00000000 00000000 00000000 [trailing info]
                     00000000 00000000 00000000 00000000 [trailing info]
                     00000000 00000000 00000000 00000000 [trailing info]
                     00000000 00000000 00000000 00000000 [trailing info]
                     00000000 00000000 00000000 00000000 [trailing info]
                     00000000 00000000 00000000 00000000 [trailing info]
                     00000000 00000000 00000000 00000000 [trailing info]
    
    The fix saves all but one of the previously associated 64 PAYload trace
    record chunks of size 256 bytes each.
    
    Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
    Fixes: aceeffbb59bb ("zfcp: trace full payload of all SAN records (req,resp,iels)")
    Fixes: 2c55b750a884 ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
    Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
    Signed-off-by: Benjamin Block <bblock@linux.vnet.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a5f62a9212cd9f447193da57feba524b4c843f07
Author: Benjamin Block <bblock@linux.vnet.ibm.com>
Date:   Fri Jul 28 12:30:52 2017 +0200

    scsi: zfcp: add handling for FCP_RESID_OVER to the fcp ingress path
    
    commit a099b7b1fc1f0418ab8d79ecf98153e1e134656e upstream.
    
    Up until now zfcp would just ignore the FCP_RESID_OVER flag in the FCP
    response IU. When this flag is set, it is possible, in regards to the
    FCP standard, that the storage-server processes the command normally, up
    to the point where data is missing and simply ignores those.
    
    In this case no CHECK CONDITION would be set, and because we ignored the
    FCP_RESID_OVER flag we resulted in at least a data loss or even
    -corruption as a follow-up error, depending on how the
    applications/layers on top behave. To prevent this, we now set the
    host-byte of the corresponding scsi_cmnd to DID_ERROR.
    
    Other storage-behaviors, where the same condition results in a CHECK
    CONDITION set in the answer, don't need to be changed as they are
    handled in the mid-layer already.
    
    Following is an example trace record decoded with zfcpdbf from the
    s390-tools package. We forcefully injected a fc_dl which is one byte too
    small:
    
    Timestamp      : ...
    Area           : SCSI
    Subarea        : 00
    Level          : 3
    Exception      : -
    CPU ID         : ..
    Caller         : 0x...
    Record ID      : 1
    Tag            : rsl_err
    Request ID     : 0x...
    SCSI ID        : 0x...
    SCSI LUN       : 0x...
    SCSI result    : 0x00070000
                         ^^DID_ERROR
    SCSI retries   : 0x..
    SCSI allowed   : 0x..
    SCSI scribble  : 0x...
    SCSI opcode    : 2a000000 00000000 08000000 00000000
    FCP rsp inf cod: 0x00
    FCP rsp IU     : 00000000 00000000 00000400 00000001
                                           ^^fr_flags==FCP_RESID_OVER
                                             ^^fr_status==SAM_STAT_GOOD
                                                ^^^^^^^^fr_resid
                     00000000 00000000
    
    As of now, we don't actively handle to possibility that a response IU
    has both flags - FCP_RESID_OVER and FCP_RESID_UNDER - set at once.
    
    Reported-by: Luke M. Hopkins <lmhopkin@us.ibm.com>
    Reviewed-by: Steffen Maier <maier@linux.vnet.ibm.com>
    Fixes: 553448f6c483 ("[SCSI] zfcp: Message cleanup")
    Fixes: ea127f975424 ("[PATCH] s390 (7/7): zfcp host adapter.") (tglx/history.git)
    Signed-off-by: Benjamin Block <bblock@linux.vnet.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f70239b3495212472828b6fb8b6f1d293ac158ec
Author: Steffen Maier <maier@linux.vnet.ibm.com>
Date:   Fri Jul 28 12:30:51 2017 +0200

    scsi: zfcp: fix queuecommand for scsi_eh commands when DIX enabled
    
    commit 71b8e45da51a7b64a23378221c0a5868bd79da4f upstream.
    
    Since commit db007fc5e20c ("[SCSI] Command protection operation"),
    scsi_eh_prep_cmnd() saves scmd->prot_op and temporarily resets it to
    SCSI_PROT_NORMAL.
    Other FCP LLDDs such as qla2xxx and lpfc shield their queuecommand()
    to only access any of scsi_prot_sg...() if
    (scsi_get_prot_op(cmd) != SCSI_PROT_NORMAL).
    
    Do the same thing for zfcp, which introduced DIX support with
    commit ef3eb71d8ba4 ("[SCSI] zfcp: Introduce experimental support for
    DIF/DIX").
    
    Otherwise, TUR SCSI commands as part of scsi_eh likely fail in zfcp,
    because the regular SCSI command with DIX protection data, that scsi_eh
    re-uses in scsi_send_eh_cmnd(), of course still has
    (scsi_prot_sg_count() != 0) and so zfcp sends down bogus requests to the
    FCP channel hardware.
    
    This causes scsi_eh_test_devices() to have (finish_cmds == 0)
    [not SCSI device is online or not scsi_eh_tur() failed]
    so regular SCSI commands, that caused / were affected by scsi_eh,
    are moved to work_q and scsi_eh_test_devices() itself returns false.
    In turn, it unnecessarily escalates in our case in scsi_eh_ready_devs()
    beyond host reset to finally scsi_eh_offline_sdevs()
    which sets affected SCSI devices offline with the following kernel message:
    
    "kernel: sd H:0:T:L: Device offlined - not ready after error recovery"
    
    Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
    Fixes: ef3eb71d8ba4 ("[SCSI] zfcp: Introduce experimental support for DIF/DIX")
    Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
    Signed-off-by: Benjamin Block <bblock@linux.vnet.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4fe99d0aad2886f1d3d6b2135821d31ba3ea41b7
Author: Andy Lutomirski <luto@kernel.org>
Date:   Tue Aug 1 07:11:35 2017 -0700

    x86/fsgsbase/64: Report FSBASE and GSBASE correctly in core dumps
    
    commit 9584d98bed7a7a904d0702ad06bbcc94703cb5b4 upstream.
    
    In ELF_COPY_CORE_REGS, we're copying from the current task, so
    accessing thread.fsbase and thread.gsbase makes no sense.  Just read
    the values from the CPU registers.
    
    In practice, the old code would have been correct most of the time
    simply because thread.fsbase and thread.gsbase usually matched the
    CPU registers.
    
    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Borislav Petkov <bpetkov@suse.de>
    Cc: Brian Gerst <brgerst@gmail.com>
    Cc: Chang Seok <chang.seok.bae@intel.com>
    Cc: Denys Vlasenko <dvlasenk@redhat.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d06189473cae286a6588e28f8baa101ebe799b37
Author: Edwin Török <edvin.torok@citrix.com>
Date:   Thu Aug 3 10:30:06 2017 +0100

    dlm: avoid double-free on error path in dlm_device_{register,unregister}
    
    commit 55acdd926f6b21a5cdba23da98a48aedf19ac9c3 upstream.
    
    Can be reproduced when running dlm_controld (tested on 4.4.x, 4.12.4):
     # seq 1 100 | xargs -P0 -n1 dlm_tool join
     # seq 1 100 | xargs -P0 -n1 dlm_tool leave
    
    misc_register fails due to duplicate sysfs entry, which causes
    dlm_device_register to free ls->ls_device.name.
    In dlm_device_deregister the name was freed again, causing memory
    corruption.
    
    According to the comment in dlm_device_deregister the name should've been
    set to NULL when registration fails,
    so this patch does that.
    
    sysfs: cannot create duplicate filename '/dev/char/10:1'
    ------------[ cut here ]------------
    warning: cpu: 1 pid: 4450 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x56/0x70
    modules linked in: msr rfcomm dlm ccm bnep dm_crypt uvcvideo
    videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core videodev
    btusb media btrtl btbcm btintel bluetooth ecdh_generic intel_rapl
    x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm
    snd_hda_codec_hdmi irqbypass crct10dif_pclmul crc32_pclmul
    ghash_clmulni_intel thinkpad_acpi pcbc nvram snd_seq_midi
    snd_seq_midi_event aesni_intel snd_hda_codec_realtek snd_hda_codec_generic
    snd_rawmidi aes_x86_64 crypto_simd glue_helper snd_hda_intel snd_hda_codec
    cryptd intel_cstate arc4 snd_hda_core snd_seq snd_seq_device snd_hwdep
    iwldvm intel_rapl_perf mac80211 joydev input_leds iwlwifi serio_raw
    cfg80211 snd_pcm shpchp snd_timer snd mac_hid mei_me lpc_ich mei soundcore
    sunrpc parport_pc ppdev lp parport autofs4 i915 psmouse
     e1000e ahci libahci i2c_algo_bit sdhci_pci ptp drm_kms_helper sdhci
    pps_core syscopyarea sysfillrect sysimgblt fb_sys_fops drm wmi video
    cpu: 1 pid: 4450 comm: dlm_test.exe not tainted 4.12.4-041204-generic
    hardware name: lenovo 232425u/232425u, bios g2et82ww (2.02 ) 09/11/2012
    task: ffff96b0cbabe140 task.stack: ffffb199027d0000
    rip: 0010:sysfs_warn_dup+0x56/0x70
    rsp: 0018:ffffb199027d3c58 eflags: 00010282
    rax: 0000000000000038 rbx: ffff96b0e2c49158 rcx: 0000000000000006
    rdx: 0000000000000000 rsi: 0000000000000086 rdi: ffff96b15e24dcc0
    rbp: ffffb199027d3c70 r08: 0000000000000001 r09: 0000000000000721
    r10: ffffb199027d3c00 r11: 0000000000000721 r12: ffffb199027d3cd1
    r13: ffff96b1592088f0 r14: 0000000000000001 r15: ffffffffffffffef
    fs:  00007f78069c0700(0000) gs:ffff96b15e240000(0000)
    knlgs:0000000000000000
    cs:  0010 ds: 0000 es: 0000 cr0: 0000000080050033
    cr2: 000000178625ed28 cr3: 0000000091d3e000 cr4: 00000000001406e0
    call trace:
     sysfs_do_create_link_sd.isra.2+0x9e/0xb0
     sysfs_create_link+0x25/0x40
     device_add+0x5a9/0x640
     device_create_groups_vargs+0xe0/0xf0
     device_create_with_groups+0x3f/0x60
     ? snprintf+0x45/0x70
     misc_register+0x140/0x180
     device_write+0x6a8/0x790 [dlm]
     __vfs_write+0x37/0x160
     ? apparmor_file_permission+0x1a/0x20
     ? security_file_permission+0x3b/0xc0
     vfs_write+0xb5/0x1a0
     sys_write+0x55/0xc0
     ? sys_fcntl+0x5d/0xb0
     entry_syscall_64_fastpath+0x1e/0xa9
    rip: 0033:0x7f78083454bd
    rsp: 002b:00007f78069bbd30 eflags: 00000293 orig_rax: 0000000000000001
    rax: ffffffffffffffda rbx: 0000000000000006 rcx: 00007f78083454bd
    rdx: 000000000000009c rsi: 00007f78069bee00 rdi: 0000000000000005
    rbp: 00007f77f8000a20 r08: 000000000000fcf0 r09: 0000000000000032
    r10: 0000000000000024 r11: 0000000000000293 r12: 00007f78069bde00
    r13: 00007f78069bee00 r14: 000000000000000a r15: 00007f78069bbd70
    code: 85 c0 48 89 c3 74 12 b9 00 10 00 00 48 89 c2 31 f6 4c 89 ef e8 2c c8
    ff ff 4c 89 e2 48 89 de 48 c7 c7 b0 8e 0c a8 e8 41 e8 ed ff <0f> ff 48 89
    df e8 00 d5 f4 ff 5b 41 5c 41 5d 5d c3 66 0f 1f 84
    ---[ end trace 40412246357cc9e0 ]---
    
    dlm: 59f24629-ae39-44e2-9030-397ebc2eda26: leaving the lockspace group...
    bug: unable to handle kernel null pointer dereference at 0000000000000001
    ip: [<ffffffff811a3b4a>] kmem_cache_alloc+0x7a/0x140
    pgd 0
    oops: 0000 [#1] smp
    modules linked in: dlm 8021q garp mrp stp llc openvswitch nf_defrag_ipv6
    nf_conntrack libcrc32c iptable_filter dm_multipath crc32_pclmul dm_mod
    aesni_intel psmouse aes_x86_64 sg ablk_helper cryptd lrw gf128mul
    glue_helper i2c_piix4 nls_utf8 tpm_tis tpm isofs nfsd auth_rpcgss
    oid_registry nfs_acl lockd grace sunrpc xen_wdt ip_tables x_tables autofs4
    hid_generic usbhid hid sr_mod cdrom sd_mod ata_generic pata_acpi 8139too
    serio_raw ata_piix 8139cp mii uhci_hcd ehci_pci ehci_hcd libata
    scsi_dh_rdac scsi_dh_hp_sw scsi_dh_emc scsi_dh_alua scsi_mod ipv6
    cpu: 0 pid: 394 comm: systemd-udevd tainted: g w 4.4.0+0 #1
    hardware name: xen hvm domu, bios 4.7.2-2.2 05/11/2017
    task: ffff880002410000 ti: ffff88000243c000 task.ti: ffff88000243c000
    rip: e030:[<ffffffff811a3b4a>] [<ffffffff811a3b4a>]
    kmem_cache_alloc+0x7a/0x140
    rsp: e02b:ffff88000243fd90 eflags: 00010202
    rax: 0000000000000000 rbx: ffff8800029864d0 rcx: 000000000007b36c
    rdx: 000000000007b36b rsi: 00000000024000c0 rdi: ffff880036801c00
    rbp: ffff88000243fdc0 r08: 0000000000018880 r09: 0000000000000054
    r10: 000000000000004a r11: ffff880034ace6c0 r12: 00000000024000c0
    r13: ffff880036801c00 r14: 0000000000000001 r15: ffffffff8118dcc2
    fs: 00007f0ab77548c0(0000) gs:ffff880036e00000(0000) knlgs:0000000000000000
    cs: e033 ds: 0000 es: 0000 cr0: 0000000080050033
    cr2: 0000000000000001 cr3: 000000000332d000 cr4: 0000000000040660
    stack:
    ffffffff8118dc90 ffff8800029864d0 0000000000000000 ffff88003430b0b0
    ffff880034b78320 ffff88003430b0b0 ffff88000243fdf8 ffffffff8118dcc2
    ffff8800349c6700 ffff8800029864d0 000000000000000b 00007f0ab7754b90
    call trace:
    [<ffffffff8118dc90>] ? anon_vma_fork+0x60/0x140
    [<ffffffff8118dcc2>] anon_vma_fork+0x92/0x140
    [<ffffffff8107033e>] copy_process+0xcae/0x1a80
    [<ffffffff8107128b>] _do_fork+0x8b/0x2d0
    [<ffffffff81071579>] sys_clone+0x19/0x20
    [<ffffffff815a30ae>] entry_syscall_64_fastpath+0x12/0x71
    ] code: f6 75 1c 4c 89 fa 44 89 e6 4c 89 ef e8 a7 e4 00 00 41 f7 c4 00 80
    00 00 49 89 c6 74 47 eb 32 49 63 45 20 48 8d 4a 01 4d 8b 45 00 <49> 8b 1c
    06 4c 89 f0 65 49 0f c7 08 0f 94 c0 84 c0 74 ac 49 63
    rip [<ffffffff811a3b4a>] kmem_cache_alloc+0x7a/0x140
    rsp <ffff88000243fd90>
    cr2: 0000000000000001
    --[ end trace 70cb9fd1b164a0e8 ]--
    
    Signed-off-by: Edwin Török <edvin.torok@citrix.com>
    Signed-off-by: David Teigland <teigland@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f06f9d10d1be9028cc8eab6684904a99dfdc1120
Author: Aleksandr Bezzubikov <zuban32s@gmail.com>
Date:   Tue Jul 18 17:12:25 2017 +0300

    PCI: shpchp: Enable bridge bus mastering if MSI is enabled
    
    commit 48b79a14505349a29b3e20f03619ada9b33c4b17 upstream.
    
    An SHPC may generate MSIs to notify software about slot or controller
    events (SHPC spec r1.0, sec 4.7).  A PCI device can only generate an MSI if
    it has bus mastering enabled.
    
    Enable bus mastering if the bridge contains an SHPC that uses MSI for event
    notifications.
    
    Signed-off-by: Aleksandr Bezzubikov <zuban32s@gmail.com>
    [bhelgaas: changelog]
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Marcel Apfelbaum <marcel@redhat.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d89a5d32aa10c6d3ef5cbfd389de549841787613
Author: Rui Teng <rui.teng@linux.vnet.ibm.com>
Date:   Thu Jan 12 17:09:06 2017 +0800

    powerpc/mm: Fix check of multiple 16G pages from device tree
    
    commit 23493c121912a39f0262e0dbeb236e1d39efa4d5 upstream.
    
    The offset of hugepage block will not be 16G, if the expected
    page is more than one. Calculate the totol size instead of the
    hardcode value.
    
    Fixes: 4792adbac9eb ("powerpc: Don't use a 16G page if beyond mem= limits")
    Signed-off-by: Rui Teng <rui.teng@linux.vnet.ibm.com>
    Tested-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 00e1fb59eddc1de07358dde20ae3aa50e49f043d
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Thu Jun 29 09:28:50 2017 -0500

    fcntl: Don't use ambiguous SIG_POLL si_codes
    
    commit d08477aa975e97f1dc64c0ae59cebf98520456ce upstream.
    
    We have a weird and problematic intersection of features that when
    they all come together result in ambiguous siginfo values, that
    we can not support properly.
    
    - Supporting fcntl(F_SETSIG,...) with arbitrary valid signals.
    
    - Using positive values for POLL_IN, POLL_OUT, POLL_MSG, ..., etc
      that imply they are signal specific si_codes and using the
      aforementioned arbitrary signal to deliver them.
    
    - Supporting injection of arbitrary siginfo values for debugging and
      checkpoint/restore.
    
    The result is that just looking at siginfo si_codes of 1 to 6 are
    ambigious.  It could either be a signal specific si_code or it could
    be a generic si_code.
    
    For most of the kernel this is a non-issue but for sending signals
    with siginfo it is impossible to play back the kernel signals and
    get the same result.
    
    Strictly speaking when the si_code was changed from SI_SIGIO to
    POLL_IN and friends between 2.2 and 2.4 this functionality was not
    ambiguous, as only real time signals were supported.  Before 2.4 was
    released the kernel began supporting siginfo with non realtime signals
    so they could give details of why the signal was sent.
    
    The result is that if F_SETSIG is set to one of the signals with signal
    specific si_codes then user space can not know why the signal was sent.
    
    I grepped through a bunch of userspace programs using debian code
    search to get a feel for how often people choose a signal that results
    in an ambiguous si_code.  I only found one program doing so and it was
    using SIGCHLD to test the F_SETSIG functionality, and did not appear
    to be a real world usage.
    
    Therefore the ambiguity does not appears to be a real world problem in
    practice.  Remove the ambiguity while introducing the smallest chance
    of breakage by changing the si_code to SI_SIGIO when signals with
    signal specific si_codes are targeted.
    
    Fixes: v2.3.40 -- Added support for queueing non-rt signals
    Fixes: v2.3.21 -- Changed the si_code from SI_SIGIO
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b88cd8f4f1dd0b64e12eb0a944270380f88a4755
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Mon May 23 16:24:02 2016 -0700

    signal: move the "sig < SIGRTMIN" check into siginmask(sig)
    
    commit 5c8ccefdf46c5f87d87b694c7fbc04941c2c99a5 upstream.
    
    All the users of siginmask() must ensure that sig < SIGRTMIN.  sig_fatal()
    doesn't and this is wrong:
    
            UBSAN: Undefined behaviour in kernel/signal.c:911:6
            shift exponent 32 is too large for 32-bit type 'long unsigned int'
    
    the patch doesn't add the neccesary check to sig_fatal(), it moves the
    check into siginmask() and updates other callers.
    
    Link: http://lkml.kernel.org/r/20160517195052.GA15187@redhat.com
    Reported-by: Meelis Roos <mroos@linux.ee>
    Signed-off-by: Oleg Nesterov <oleg@redhat.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 a7f3619d51e620c157dad6361ce74143adb1903f
Author: Noa Osherovich <noaos@mellanox.com>
Date:   Mon Jun 12 11:14:02 2017 +0300

    IB/core: Fix the validations of a multicast LID in attach or detach operations
    
    commit 5236333592244557a19694a51337df6ac018f0a7 upstream.
    
    RoCE Annex (A16.9.10/11) declares that during attach (detach) QP to a
    multicast group, if the QP is associated with a RoCE port, the
    multicast group MLID is unused and is ignored.
    
    During attach or detach multicast, when the QP is associated with a
    port, it is enough to check the port's link layer and validate the
    LID only if it is Infiniband. Otherwise, avoid validating the
    multicast LID.
    
    Fixes: 8561eae60ff9 ("IB/core: For multicast functions, verify that LIDs are multicast LIDs")
    Signed-off-by: Noa Osherovich <noaos@mellanox.com>
    Reviewed-by: Moni Shoua <monis@mellanox.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    [bwh: Backported to 3.2: use literal number instead of IB_MULTICAST_LID_BASE]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>