commit 55db23d3a51e8a5b2f05f121f71525c13efb5e35
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Mar 30 09:44:36 2017 +0200

    Linux 4.10.7

commit 0dad3de8682599bfa56c4e9fc61123337f10354f
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Thu Dec 15 14:31:01 2016 +0100

    crypto: algif_hash - avoid zero-sized array
    
    commit 6207119444595d287b1e9e83a2066c17209698f3 upstream.
    
    With this reproducer:
      struct sockaddr_alg alg = {
              .salg_family = 0x26,
              .salg_type = "hash",
              .salg_feat = 0xf,
              .salg_mask = 0x5,
              .salg_name = "digest_null",
      };
      int sock, sock2;
    
      sock = socket(AF_ALG, SOCK_SEQPACKET, 0);
      bind(sock, (struct sockaddr *)&alg, sizeof(alg));
      sock2 = accept(sock, NULL, NULL);
      setsockopt(sock, SOL_ALG, ALG_SET_KEY, "\x9b\xca", 2);
      accept(sock2, NULL, NULL);
    
    ==== 8< ======== 8< ======== 8< ======== 8< ====
    
    one can immediatelly see an UBSAN warning:
    UBSAN: Undefined behaviour in crypto/algif_hash.c:187:7
    variable length array bound value 0 <= 0
    CPU: 0 PID: 15949 Comm: syz-executor Tainted: G            E      4.4.30-0-default #1
    ...
    Call Trace:
    ...
     [<ffffffff81d598fd>] ? __ubsan_handle_vla_bound_not_positive+0x13d/0x188
     [<ffffffff81d597c0>] ? __ubsan_handle_out_of_bounds+0x1bc/0x1bc
     [<ffffffffa0e2204d>] ? hash_accept+0x5bd/0x7d0 [algif_hash]
     [<ffffffffa0e2293f>] ? hash_accept_nokey+0x3f/0x51 [algif_hash]
     [<ffffffffa0e206b0>] ? hash_accept_parent_nokey+0x4a0/0x4a0 [algif_hash]
     [<ffffffff8235c42b>] ? SyS_accept+0x2b/0x40
    
    It is a correct warning, as hash state is propagated to accept as zero,
    but creating a zero-length variable array is not allowed in C.
    
    Fix this as proposed by Herbert -- do "?: 1" on that site. No sizeof or
    similar happens in the code there, so we just allocate one byte even
    though we do not use the array.
    
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: "David S. Miller" <davem@davemloft.net> (maintainer:CRYPTO API)
    Reported-by: Sasha Levin <sasha.levin@oracle.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f9955dcaceae3a6d5c747b065e1d9da1be50b5ba
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Jan 11 17:09:50 2017 +0100

    fbcon: Fix vc attr at deinit
    
    commit 8aac7f34369726d1a158788ae8aff3002d5eb528 upstream.
    
    fbcon can deal with vc_hi_font_mask (the upper 256 chars) and adjust
    the vc attrs dynamically when vc_hi_font_mask is changed at
    fbcon_init().  When the vc_hi_font_mask is set, it remaps the attrs in
    the existing console buffer with one bit shift up (for 9 bits), while
    it remaps with one bit shift down (for 8 bits) when the value is
    cleared.  It works fine as long as the font gets updated after fbcon
    was initialized.
    
    However, we hit a bizarre problem when the console is switched to
    another fb driver (typically from vesafb or efifb to drmfb).  At
    switching to the new fb driver, we temporarily rebind the console to
    the dummy console, then rebind to the new driver.  During the
    switching, we leave the modified attrs as is.  Thus, the new fbcon
    takes over the old buffer as if it were to contain 8 bits chars
    (although the attrs are still shifted for 9 bits), and effectively
    this results in the yellow color texts instead of the original white
    color, as found in the bugzilla entry below.
    
    An easy fix for this is to re-adjust the attrs before leaving the
    fbcon at con_deinit callback.  Since the code to adjust the attrs is
    already present in the current fbcon code, in this patch, we simply
    factor out the relevant code, and call it from fbcon_deinit().
    
    Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1000619
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a3241044b1c4ecc13f73b7158881881fb7534a1
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Dec 21 11:23:30 2016 +0100

    drm: reference count event->completion
    
    commit 24835e442f289813aa568d142a755672a740503c upstream.
    
    When writing the generic nonblocking commit code I assumed that
    through clever lifetime management I can assure that the completion
    (stored in drm_crtc_commit) only gets freed after it is completed. And
    that worked.
    
    I also wanted to make nonblocking helpers resilient against driver
    bugs, by having timeouts everywhere. And that worked too.
    
    Unfortunately taking boths things together results in oopses :( Well,
    at least sometimes: What seems to happen is that the drm event hangs
    around forever stuck in limbo land. The nonblocking helpers eventually
    time out, move on and release it. Now the bug I tested all this
    against is drivers that just entirely fail to deliver the vblank
    events like they should, and in those cases the event is simply
    leaked. But what seems to happen, at least sometimes, on i915 is that
    the event is set up correctly, but somohow the vblank fails to fire in
    time. Which means the event isn't leaked, it's still there waiting for
    eventually a vblank to fire. That tends to happen when re-enabling the
    pipe, and then the trap springs and the kernel oopses.
    
    The correct fix here is simply to refcount the crtc commit to make
    sure that the event sticks around even for drivers which only
    sometimes fail to deliver vblanks for some arbitrary reasons. Since
    crtc commits are already refcounted that's easy to do.
    
    References: https://bugs.freedesktop.org/show_bug.cgi?id=96781
    Cc: Jim Rees <rees@umich.edu>
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Cc: Jani Nikula <jani.nikula@linux.intel.com>
    Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
    Link: http://patchwork.freedesktop.org/patch/msgid/20161221102331.31033-1-daniel.vetter@ffwll.ch
    Cc: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 597584832d0cb7d8fbb3655d67bd45781653f10b
Author: Dan Streetman <ddstreet@ieee.org>
Date:   Fri Jan 13 15:07:51 2017 -0500

    xen: do not re-use pirq number cached in pci device msi msg data
    
    commit c74fd80f2f41d05f350bb478151021f88551afe8 upstream.
    
    Revert the main part of commit:
    af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")
    
    That commit introduced reading the pci device's msi message data to see
    if a pirq was previously configured for the device's msi/msix, and re-use
    that pirq.  At the time, that was the correct behavior.  However, a
    later change to Qemu caused it to call into the Xen hypervisor to unmap
    all pirqs for a pci device, when the pci device disables its MSI/MSIX
    vectors; specifically the Qemu commit:
    c976437c7dba9c7444fb41df45468968aaa326ad
    ("qemu-xen: free all the pirqs for msi/msix when driver unload")
    
    Once Qemu added this pirq unmapping, it was no longer correct for the
    kernel to re-use the pirq number cached in the pci device msi message
    data.  All Qemu releases since 2.1.0 contain the patch that unmaps the
    pirqs when the pci device disables its MSI/MSIX vectors.
    
    This bug is causing failures to initialize multiple NVMe controllers
    under Xen, because the NVMe driver sets up a single MSIX vector for
    each controller (concurrently), and then after using that to talk to
    the controller for some configuration data, it disables the single MSIX
    vector and re-configures all the MSIX vectors it needs.  So the MSIX
    setup code tries to re-use the cached pirq from the first vector
    for each controller, but the hypervisor has already given away that
    pirq to another controller, and its initialization fails.
    
    This is discussed in more detail at:
    https://lists.xen.org/archives/html/xen-devel/2017-01/msg00447.html
    
    Fixes: af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")
    Signed-off-by: Dan Streetman <dan.streetman@canonical.com>
    Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
    Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 535693055d2a8f4571550266bbeff0188ee3fdf2
Author: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Date:   Sun Mar 19 00:51:59 2017 +0530

    cpuidle: Validate cpu_dev in cpuidle_add_sysfs()
    
    commit ad0a45fd9c14feebd000b6e84189d0edff265170 upstream.
    
    If a given cpu is not in cpu_present and cpu hotplug
    is disabled, arch can skip setting up the cpu_dev.
    
    Arch cpuidle driver should pass correct cpu mask
    for registration, but failing to do so by the driver
    causes error to propagate and crash like this:
    
    [   30.076045] Unable to handle kernel paging request for data at address 0x00000048
    [   30.076100] Faulting instruction address: 0xc0000000007b2f30
    cpu 0x4d: Vector: 300 (Data Access) at [c000003feb18b670]
        pc: c0000000007b2f30: kobject_get+0x20/0x70
        lr: c0000000007b3c94: kobject_add_internal+0x54/0x3f0
        sp: c000003feb18b8f0
       msr: 9000000000009033
       dar: 48
     dsisr: 40000000
      current = 0xc000003fd2ed8300
      paca    = 0xc00000000fbab500   softe: 0        irq_happened: 0x01
        pid   = 1, comm = swapper/0
    Linux version 4.11.0-rc2-svaidy+ (sv@sagarika) (gcc version 6.2.0
    20161005 (Ubuntu 6.2.0-5ubuntu12) ) #10 SMP Sun Mar 19 00:08:09 IST 2017
    enter ? for help
    [c000003feb18b960] c0000000007b3c94 kobject_add_internal+0x54/0x3f0
    [c000003feb18b9f0] c0000000007b43a4 kobject_init_and_add+0x64/0xa0
    [c000003feb18ba70] c000000000e284f4 cpuidle_add_sysfs+0xb4/0x130
    [c000003feb18baf0] c000000000e26038 cpuidle_register_device+0x118/0x1c0
    [c000003feb18bb30] c000000000e26c48 cpuidle_register+0x78/0x120
    [c000003feb18bbc0] c00000000168fd9c powernv_processor_idle_init+0x110/0x1c4
    [c000003feb18bc40] c00000000000cff8 do_one_initcall+0x68/0x1d0
    [c000003feb18bd00] c0000000016242f4 kernel_init_freeable+0x280/0x360
    [c000003feb18bdc0] c00000000000d864 kernel_init+0x24/0x160
    [c000003feb18be30] c00000000000b4e8 ret_from_kernel_thread+0x5c/0x74
    
    Validating cpu_dev fixes the crash and reports correct error message like:
    
    [   30.163506] Failed to register cpuidle device for cpu136
    [   30.173329] Registration of powernv driver failed.
    
    Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
    [ rjw: Comment massage ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a27142e6d0ebeddc47048244d88285fa8bce29f1
Author: Damien Le Moal <damien.lemoal@wdc.com>
Date:   Wed Mar 1 17:27:00 2017 +0900

    scsi: sd: Check for unaligned partial completion
    
    commit c46f09175dabd5dd6a1507f36250bfa734a0156e upstream.
    
    Commit <f2e767bb5d6e> ("mpt3sas: Force request partial completion
    alignment") was not considering the case of commands not operating on
    logical block size units (e.g. REQ_OP_ZONE_REPORT and its 64B aligned
    partial replies). In this case, forcing alignment of resid to the device
    logical block size can break the command result, e.g. in the case of
    REQ_OP_ZONE_REPORT, the exact number of zone reported by the device.
    
    Move the partial completion alignement check of mpt3sas to a generic
    implementation in sd_done(). The check is added within the default
    section of the initial req_op() switch case so that the report and reset
    zone commands are ignored. In addition, as sd_done() is not called for
    passthrough requests, resid corrections are not done as intended by the
    initial mpt3sas patch.
    
    Fixes: f2e767bb5d6e ("mpt3sas: Force request partial completion alignment")
    Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
    Acked-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Bart Van Assche <bart.vanassche@sandisk.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 66c0812889def117ac3b20478f23acfe9100ba2b
Author: Dave Jiang <dave.jiang@intel.com>
Date:   Fri Mar 10 13:24:22 2017 -0700

    device-dax: fix pmd/pte fault fallback handling
    
    commit 0134ed4fb9e78672ee9f7b18007114404c81e63f upstream.
    
    Jeff Moyer reports:
    
        With a device dax alignment of 4KB or 2MB, I get sigbus when running
        the attached fio job file for the current kernel (4.11.0-rc1+).  If
        I specify an alignment of 1GB, it works.
    
        I turned on debug output, and saw that it was failing in the huge
        fault code.
    
         dax dax1.0: dax_open
         dax dax1.0: dax_mmap
         dax dax1.0: dax_dev_huge_fault: fio: write (0x7f08f0a00000 -
         dax dax1.0: __dax_dev_pud_fault: phys_to_pgoff(0xffffffffcf60
         dax dax1.0: dax_release
    
        fio config for reproduce:
        [global]
        ioengine=dev-dax
        direct=0
        filename=/dev/dax0.0
        bs=2m
    
        [write]
        rw=write
    
        [read]
        stonewall
        rw=read
    
    The driver fails to fallback when taking a fault that is larger than
    the device alignment, or handling a larger fault when a smaller
    mapping is already established. While we could support larger
    mappings for a device with a smaller alignment, that change is
    too large for the immediate fix. The simplest change is to force
    fallback until the fault size matches the alignment.
    
    Fixes: dee410792419 ("/dev/dax, core: file operations and dax-mmap")
    Cc: <stable@vger.kernel.org>
    Reported-by: Jeff Moyer <jmoyer@redhat.com>
    Signed-off-by: Dave Jiang <dave.jiang@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 96aa12df241019f297097495e28e032f7cbc69a4
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Wed Mar 1 17:33:27 2017 +0100

    libceph: don't set weight to IN when OSD is destroyed
    
    commit b581a5854eee4b7851dedb0f8c2ceb54fb902c06 upstream.
    
    Since ceph.git commit 4e28f9e63644 ("osd/OSDMap: clear osd_info,
    osd_xinfo on osd deletion"), weight is set to IN when OSD is deleted.
    This changes the result of applying an incremental for clients, not
    just OSDs.  Because CRUSH computations are obviously affected,
    pre-4e28f9e63644 servers disagree with post-4e28f9e63644 clients on
    object placement, resulting in misdirected requests.
    
    Mirrors ceph.git commit a6009d1039a55e2c77f431662b3d6cc5a8e8e63f.
    
    Fixes: 930c53286977 ("libceph: apply new_state before new_up_client on incrementals")
    Link: http://tracker.ceph.com/issues/19122
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Reviewed-by: Sage Weil <sage@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b38e3191816f99038e7c6ee058baee2681284d2
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Mon Mar 13 14:36:32 2017 +0200

    mmc: block: Fix is_waiting_last_req set incorrectly
    
    commit 2602b740e45cc64feb55d5a9ee8db744ab3becbb upstream.
    
    Commit 15520111500c ("mmc: core: Further fix thread wake-up") allowed a
    queue to release the host with is_waiting_last_req set to true. A queue
    waiting to claim the host will not reset it, which can result in the
    queue getting stuck in a loop.
    
    Fixes: 15520111500c ("mmc: core: Further fix thread wake-up")
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f2a9bf4d93dfd0a61388e7169ec512b02e70f37f
Author: K. Y. Srinivasan <kys@microsoft.com>
Date:   Sun Mar 12 20:00:30 2017 -0700

    Drivers: hv: vmbus: Don't leak memory when a channel is rescinded
    
    commit 5e030d5ce9d99a899b648413139ff65bab12b038 upstream.
    
    When we close a channel that has been rescinded, we will leak memory since
    vmbus_teardown_gpadl() returns an error. Fix this so that we can properly
    cleanup the memory allocated to the ring buffers.
    
    Fixes: ccb61f8a99e6 ("Drivers: hv: vmbus: Fix a rescind handling bug")
    
    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
    Cc: Dexuan Cui <decui@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 840065777b4d64afa9fafffe1eb1e4f7d1098df5
Author: K. Y. Srinivasan <kys@microsoft.com>
Date:   Mon Mar 13 15:57:09 2017 -0700

    Drivers: hv: vmbus: Don't leak channel ids
    
    commit 9a5476020a5f06a0fc6f17097efc80275d2f03cd upstream.
    
    If we cannot allocate memory for the channel, free the relid
    associated with the channel.
    
    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f8dd767b84e2e6d477a760d87999d74c2580ea9a
Author: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Date:   Fri Feb 24 16:04:15 2017 +0200

    intel_th: Don't leak module refcount on failure to activate
    
    commit e609ccef5222c73b46b322be7d3796d60bff353d upstream.
    
    Output 'activation' may fail for the reasons of the output driver,
    for example, if msc's buffer is not allocated. We forget, however,
    to drop the module reference in this case. So each attempt at
    activation in this case leaks a reference, preventing the module
    from ever unloading.
    
    This patch adds the missing module_put() in the activation error
    path.
    
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7bf105ac9277edc445b5158d1aa92e766206d23a
Author: Eric Biggers <ebiggers@google.com>
Date:   Wed Mar 15 15:08:48 2017 -0400

    jbd2: don't leak memory if setting up journal fails
    
    commit cd9cb405e0b948363811dc74dbb2890f56f2cb87 upstream.
    
    In journal_init_common(), if we failed to allocate the j_wbuf array, or
    if we failed to create the buffer_head for the journal superblock, we
    leaked the memory allocated for the revocation tables.  Fix this.
    
    Fixes: f0c9fd5458bacf7b12a9a579a727dc740cbe047e
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8668c61ba509d9ff6d7aed106ac407b69c7f1ff3
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Sun Feb 19 16:33:35 2017 -0800

    auxdisplay: img-ascii-lcd: add missing sentinel entry in img_ascii_lcd_matches
    
    commit abda288bb207e5c681306299126af8c022709c18 upstream.
    
    The OF device table must be terminated, otherwise we'll be walking past it
    and into areas unknown.
    
    Fixes: 0cad855fbd08 ("auxdisplay: img-ascii-lcd: driver for simple ASCII...")
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Tested-by: Fengguang Wu <fengguang.wu@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 67dfc0850f71a47c7be81cae4c8c705fde8f82cf
Author: Evan Quan <evan.quan@amd.com>
Date:   Fri Mar 17 10:22:51 2017 +0800

    drm/amd/amdgpu: add POLARIS12 PCI ID
    
    commit cf8c73afb3abf0f8905efbaddd4ce11a0deec9da upstream.
    
    Signed-off-by: Evan Quan <evan.quan@amd.com>
    Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a7a14362e27842b56a12e05fed172c7df28b9988
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Mar 15 21:13:25 2017 -0400

    drm/amdgpu: reinstate oland workaround for sclk
    
    commit e11ddff68a7c455e63c4b46154a3e75c699a7b55 upstream.
    
    Higher sclks seem to be unstable on some boards.
    
    bug: https://bugs.freedesktop.org/show_bug.cgi?id=100222
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 51d3848c10b3af777adc48cdef48b1a636a350c0
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Mar 20 09:58:33 2017 +0100

    cpsw/netcp: cpts depends on posix_timers
    
    commit 07fef3623407444e51c12ea57cd91df38c1069e0 upstream.
    
    With posix timers having become optional, we get a build error with
    the cpts time sync option of the CPSW driver:
    
    drivers/net/ethernet/ti/cpts.c: In function 'cpts_find_ts':
    drivers/net/ethernet/ti/cpts.c:291:23: error: implicit declaration of function 'ptp_classify_raw';did you mean 'ptp_classifier_init'? [-Werror=implicit-function-declaration]
    
    This adds a hard dependency on PTP_CLOCK to avoid the problem, as
    building it without PTP support makes no sense anyway.
    
    Fixes: baa73d9e478f ("posix-timers: Make them configurable")
    Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Nicolas Pitre <nico@linaro.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 16379a79ee4504640f0d5b133decdaf14c96fdc7
Author: Ming Lei <tom.leiming@gmail.com>
Date:   Wed Mar 22 10:14:43 2017 +0800

    blk-mq: don't complete un-started request in timeout handler
    
    commit 95a49603707d982b25d17c5b70e220a05556a2f9 upstream.
    
    When iterating busy requests in timeout handler,
    if the STARTED flag of one request isn't set, that means
    the request is being processed in block layer or driver, and
    isn't submitted to hardware yet.
    
    In current implementation of blk_mq_check_expired(),
    if the request queue becomes dying, un-started requests are
    handled as being completed/freed immediately. This way is
    wrong, and can cause rq corruption or double allocation[1][2],
    when doing I/O and removing&resetting NVMe device at the sametime.
    
    This patch fixes several issues reported by Yi Zhang.
    
    [1]. oops log 1
    [  581.789754] ------------[ cut here ]------------
    [  581.789758] kernel BUG at block/blk-mq.c:374!
    [  581.789760] invalid opcode: 0000 [#1] SMP
    [  581.789761] Modules linked in: vfat fat ipmi_ssif intel_rapl sb_edac
    edac_core x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm nvme
    irqbypass crct10dif_pclmul nvme_core crc32_pclmul ghash_clmulni_intel
    intel_cstate ipmi_si mei_me ipmi_devintf intel_uncore sg ipmi_msghandler
    intel_rapl_perf iTCO_wdt mei iTCO_vendor_support mxm_wmi lpc_ich dcdbas shpchp
    pcspkr acpi_power_meter wmi nfsd auth_rpcgss nfs_acl lockd dm_multipath grace
    sunrpc ip_tables xfs libcrc32c sd_mod mgag200 i2c_algo_bit drm_kms_helper
    syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm ahci libahci
    crc32c_intel tg3 libata megaraid_sas i2c_core ptp fjes pps_core dm_mirror
    dm_region_hash dm_log dm_mod
    [  581.789796] CPU: 1 PID: 1617 Comm: kworker/1:1H Not tainted 4.10.0.bz1420297+ #4
    [  581.789797] Hardware name: Dell Inc. PowerEdge R730xd/072T6D, BIOS 2.2.5 09/06/2016
    [  581.789804] Workqueue: kblockd blk_mq_timeout_work
    [  581.789806] task: ffff8804721c8000 task.stack: ffffc90006ee4000
    [  581.789809] RIP: 0010:blk_mq_end_request+0x58/0x70
    [  581.789810] RSP: 0018:ffffc90006ee7d50 EFLAGS: 00010202
    [  581.789811] RAX: 0000000000000001 RBX: ffff8802e4195340 RCX: ffff88028e2f4b88
    [  581.789812] RDX: 0000000000001000 RSI: 0000000000001000 RDI: 0000000000000000
    [  581.789813] RBP: ffffc90006ee7d60 R08: 0000000000000003 R09: ffff88028e2f4b00
    [  581.789814] R10: 0000000000001000 R11: 0000000000000001 R12: 00000000fffffffb
    [  581.789815] R13: ffff88042abe5780 R14: 000000000000002d R15: ffff88046fbdff80
    [  581.789817] FS:  0000000000000000(0000) GS:ffff88047fc00000(0000) knlGS:0000000000000000
    [  581.789818] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  581.789819] CR2: 00007f64f403a008 CR3: 000000014d078000 CR4: 00000000001406e0
    [  581.789820] Call Trace:
    [  581.789825]  blk_mq_check_expired+0x76/0x80
    [  581.789828]  bt_iter+0x45/0x50
    [  581.789830]  blk_mq_queue_tag_busy_iter+0xdd/0x1f0
    [  581.789832]  ? blk_mq_rq_timed_out+0x70/0x70
    [  581.789833]  ? blk_mq_rq_timed_out+0x70/0x70
    [  581.789840]  ? __switch_to+0x140/0x450
    [  581.789841]  blk_mq_timeout_work+0x88/0x170
    [  581.789845]  process_one_work+0x165/0x410
    [  581.789847]  worker_thread+0x137/0x4c0
    [  581.789851]  kthread+0x101/0x140
    [  581.789853]  ? rescuer_thread+0x3b0/0x3b0
    [  581.789855]  ? kthread_park+0x90/0x90
    [  581.789860]  ret_from_fork+0x2c/0x40
    [  581.789861] Code: 48 85 c0 74 0d 44 89 e6 48 89 df ff d0 5b 41 5c 5d c3 48
    8b bb 70 01 00 00 48 85 ff 75 0f 48 89 df e8 7d f0 ff ff 5b 41 5c 5d c3 <0f>
    0b e8 71 f0 ff ff 90 eb e9 0f 1f 40 00 66 2e 0f 1f 84 00 00
    [  581.789882] RIP: blk_mq_end_request+0x58/0x70 RSP: ffffc90006ee7d50
    [  581.789889] ---[ end trace bcaf03d9a14a0a70 ]---
    
    [2]. oops log2
    [ 6984.857362] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
    [ 6984.857372] IP: nvme_queue_rq+0x6e6/0x8cd [nvme]
    [ 6984.857373] PGD 0
    [ 6984.857374]
    [ 6984.857376] Oops: 0000 [#1] SMP
    [ 6984.857379] Modules linked in: ipmi_ssif vfat fat intel_rapl sb_edac
    edac_core x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm
    irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel ipmi_si iTCO_wdt
    iTCO_vendor_support mxm_wmi ipmi_devintf intel_cstate sg dcdbas intel_uncore
    mei_me intel_rapl_perf mei pcspkr lpc_ich ipmi_msghandler shpchp
    acpi_power_meter wmi nfsd auth_rpcgss dm_multipath nfs_acl lockd grace sunrpc
    ip_tables xfs libcrc32c sd_mod mgag200 i2c_algo_bit drm_kms_helper syscopyarea
    sysfillrect crc32c_intel sysimgblt fb_sys_fops ttm nvme drm nvme_core ahci
    libahci i2c_core tg3 libata ptp megaraid_sas pps_core fjes dm_mirror
    dm_region_hash dm_log dm_mod
    [ 6984.857416] CPU: 7 PID: 1635 Comm: kworker/7:1H Not tainted
    4.10.0-2.el7.bz1420297.x86_64 #1
    [ 6984.857417] Hardware name: Dell Inc. PowerEdge R730xd/072T6D, BIOS 2.2.5 09/06/2016
    [ 6984.857427] Workqueue: kblockd blk_mq_run_work_fn
    [ 6984.857429] task: ffff880476e3da00 task.stack: ffffc90002e90000
    [ 6984.857432] RIP: 0010:nvme_queue_rq+0x6e6/0x8cd [nvme]
    [ 6984.857433] RSP: 0018:ffffc90002e93c50 EFLAGS: 00010246
    [ 6984.857434] RAX: 0000000000000000 RBX: ffff880275646600 RCX: 0000000000001000
    [ 6984.857435] RDX: 0000000000000fff RSI: 00000002fba2a000 RDI: ffff8804734e6950
    [ 6984.857436] RBP: ffffc90002e93d30 R08: 0000000000002000 R09: 0000000000001000
    [ 6984.857437] R10: 0000000000001000 R11: 0000000000000000 R12: ffff8804741d8000
    [ 6984.857438] R13: 0000000000000040 R14: ffff880475649f80 R15: ffff8804734e6780
    [ 6984.857439] FS:  0000000000000000(0000) GS:ffff88047fcc0000(0000) knlGS:0000000000000000
    [ 6984.857440] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 6984.857442] CR2: 0000000000000010 CR3: 0000000001c09000 CR4: 00000000001406e0
    [ 6984.857443] Call Trace:
    [ 6984.857451]  ? mempool_free+0x2b/0x80
    [ 6984.857455]  ? bio_free+0x4e/0x60
    [ 6984.857459]  blk_mq_dispatch_rq_list+0xf5/0x230
    [ 6984.857462]  blk_mq_process_rq_list+0x133/0x170
    [ 6984.857465]  __blk_mq_run_hw_queue+0x8c/0xa0
    [ 6984.857467]  blk_mq_run_work_fn+0x12/0x20
    [ 6984.857473]  process_one_work+0x165/0x410
    [ 6984.857475]  worker_thread+0x137/0x4c0
    [ 6984.857478]  kthread+0x101/0x140
    [ 6984.857480]  ? rescuer_thread+0x3b0/0x3b0
    [ 6984.857481]  ? kthread_park+0x90/0x90
    [ 6984.857489]  ret_from_fork+0x2c/0x40
    [ 6984.857490] Code: 8b bd 70 ff ff ff 89 95 50 ff ff ff 89 8d 58 ff ff ff 44
    89 95 60 ff ff ff e8 b7 dd 12 e1 8b 95 50 ff ff ff 48 89 85 68 ff ff ff <4c>
    8b 48 10 44 8b 58 18 8b 8d 58 ff ff ff 44 8b 95 60 ff ff ff
    [ 6984.857511] RIP: nvme_queue_rq+0x6e6/0x8cd [nvme] RSP: ffffc90002e93c50
    [ 6984.857512] CR2: 0000000000000010
    [ 6984.895359] ---[ end trace 2d7ceb528432bf83 ]---
    
    Reported-by: Yi Zhang <yizhan@redhat.com>
    Tested-by: Yi Zhang <yizhan@redhat.com>
    Reviewed-by: Bart Van Assche <bart.vanassche@sandisk.com>
    Reviewed-by: Hannes Reinecke <hare@suse.com>
    Signed-off-by: Ming Lei <tom.leiming@gmail.com>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fee328fee94659b74e42c8deb262741e85a268d1
Author: Tejun Heo <tj@kernel.org>
Date:   Tue Mar 14 19:25:56 2017 -0400

    cgroup, net_cls: iterate the fds of only the tasks which are being migrated
    
    commit a05d4fd9176003e0c1f9c3d083f4dac19fd346ab upstream.
    
    The net_cls controller controls the classid field of each socket which
    is associated with the cgroup.  Because the classid is per-socket
    attribute, when a task migrates to another cgroup or the configured
    classid of the cgroup changes, the controller needs to walk all
    sockets and update the classid value, which was implemented by
    3b13758f51de ("cgroups: Allow dynamically changing net_classid").
    
    While the approach is not scalable, migrating tasks which have a lot
    of fds attached to them is rare and the cost is born by the ones
    initiating the operations.  However, for simplicity, both the
    migration and classid config change paths call update_classid() which
    scans all fds of all tasks in the target css.  This is an overkill for
    the migration path which only needs to cover a much smaller subset of
    tasks which are actually getting migrated in.
    
    On cgroup v1, this can lead to unexpected scalability issues when one
    tries to migrate a task or process into a net_cls cgroup which already
    contains a lot of fds.  Even if the migration traget doesn't have many
    to get scanned, update_classid() ends up scanning all fds in the
    target cgroup which can be extremely numerous.
    
    Unfortunately, on cgroup v2 which doesn't use net_cls, the problem is
    even worse.  Before bfc2cf6f61fc ("cgroup: call subsys->*attach() only
    for subsystems which are actually affected by migration"), cgroup core
    would call the ->css_attach callback even for controllers which don't
    see actual migration to a different css.
    
    As net_cls is always disabled but still mounted on cgroup v2, whenever
    a process is migrated on the cgroup v2 hierarchy, net_cls sees
    identity migration from root to root and cgroup core used to call
    ->css_attach callback for those.  The net_cls ->css_attach ends up
    calling update_classid() on the root net_cls css to which all
    processes on the system belong to as the controller isn't used.  This
    makes any cgroup v2 migration O(total_number_of_fds_on_the_system)
    which is horrible and easily leads to noticeable stalls triggering RCU
    stall warnings and so on.
    
    The worst symptom is already fixed in upstream by bfc2cf6f61fc
    ("cgroup: call subsys->*attach() only for subsystems which are
    actually affected by migration"); however, backporting that commit is
    too invasive and we want to avoid other cases too.
    
    This patch updates net_cls's cgrp_attach() to iterate fds of only the
    processes which are actually getting migrated.  This removes the
    surprising migration cost which is dependent on the total number of
    fds in the target cgroup.  As this leaves write_classid() the only
    user of update_classid(), open-code the helper into write_classid().
    
    Reported-by: David Goode <dgoode@fb.com>
    Fixes: 3b13758f51de ("cgroups: Allow dynamically changing net_classid")
    Cc: Nina Schiff <ninasc@fb.com>
    Cc: David S. Miller <davem@davemloft.net>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3742b9a0868229e334c2911be3992c598401c262
Author: Viresh Kumar <viresh.kumar@linaro.org>
Date:   Tue Mar 21 11:36:06 2017 +0530

    cpufreq: Restore policy min/max limits on CPU online
    
    commit ff010472fb75670cb5c08671e820eeea3af59c87 upstream.
    
    On CPU online the cpufreq core restores the previous governor (or
    the previous "policy" setting for ->setpolicy drivers), but it does
    not restore the min/max limits at the same time, which is confusing,
    inconsistent and real pain for users who set the limits and then
    suspend/resume the system (using full suspend), in which case the
    limits are reset on all CPUs except for the boot one.
    
    Fix this by making cpufreq_online() restore the limits when an inactive
    policy is brought online.
    
    The commit log and patch are inspired from Rafael's earlier work.
    
    Reported-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fc0af2511915cc1527dd78eef12bf623b51e60a2
Author: Neeraj Upadhyay <neeraju@codeaurora.org>
Date:   Wed Mar 22 17:08:25 2017 +0530

    arm64: kaslr: Fix up the kernel image alignment
    
    commit afd0e5a876703accb95894f23317a13e2c49b523 upstream.
    
    If kernel image extends across alignment boundary, existing
    code increases the KASLR offset by size of kernel image. The
    offset is masked after resizing. There are cases, where after
    masking, we may still have kernel image extending across
    boundary. This eventually results in only 2MB block getting
    mapped while creating the page tables. This results in data aborts
    while accessing unmapped regions during second relocation (with
    kaslr offset) in __primary_switch. To fix this problem, round up the
    kernel image size, by swapper block size, before adding it for
    correction.
    
    For example consider below case, where kernel image still crosses
    1GB alignment boundary, after masking the offset, which is fixed
    by rounding up kernel image size.
    
    SWAPPER_TABLE_SHIFT = 30
    Swapper using section maps with section size 2MB.
    CONFIG_PGTABLE_LEVELS = 3
    VA_BITS = 39
    
    _text  : 0xffffff8008080000
    _end   : 0xffffff800aa1b000
    offset : 0x1f35600000
    mask = ((1UL << (VA_BITS - 2)) - 1) & ~(SZ_2M - 1)
    
    (_text + offset) >> SWAPPER_TABLE_SHIFT = 0x3fffffe7c
    (_end + offset) >> SWAPPER_TABLE_SHIFT  = 0x3fffffe7d
    
    offset after existing correction (before mask) = 0x1f37f9b000
    (_text + offset) >> SWAPPER_TABLE_SHIFT = 0x3fffffe7d
    (_end + offset) >> SWAPPER_TABLE_SHIFT  = 0x3fffffe7d
    
    offset (after mask) = 0x1f37e00000
    (_text + offset) >> SWAPPER_TABLE_SHIFT = 0x3fffffe7c
    (_end + offset) >> SWAPPER_TABLE_SHIFT  = 0x3fffffe7d
    
    new offset w/ rounding up = 0x1f38000000
    (_text + offset) >> SWAPPER_TABLE_SHIFT = 0x3fffffe7d
    (_end + offset) >> SWAPPER_TABLE_SHIFT  = 0x3fffffe7d
    
    Fixes: f80fb3a3d508 ("arm64: add support for kernel ASLR")
    Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Neeraj Upadhyay <neeraju@codeaurora.org>
    Signed-off-by: Srinivas Ramana <sramana@codeaurora.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f464f86d8b8da9cf0956a8ca894d59d412865591
Author: Nicolas Ferre <nicolas.ferre@microchip.com>
Date:   Tue Mar 14 09:38:04 2017 +0100

    ARM: at91: pm: cpu_idle: switch DDR to power-down mode
    
    commit 60b89f1928af80b546b5c3fd8714a62f6f4b8844 upstream.
    
    On some DDR controllers, compatible with the sama5d3 one,
    the sequence to enter/exit/re-enter the self-refresh mode adds
    more constrains than what is currently written in the at91_idle
    driver. An actual access to the DDR chip is needed between exit
    and re-enter of this mode which is somehow difficult to implement.
    This sequence can completely hang the SoC. It is particularly
    experienced on parts which embed a L2 cache if the code run
    between IDLE calls fits in it...
    
    Moreover, as the intention is to enter and exit pretty rapidly
    from IDLE, the power-down mode is a good candidate.
    
    So now we use power-down instead of self-refresh. As we can
    simplify the code for sama5d3 compatible DDR controllers,
    we instantiate a new sama5d3_ddr_standby() function.
    
    Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
    Fixes: 017b5522d5e3 ("ARM: at91: Add new binding for sama5d3-ddramc")
    Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 166fdccc86a50f461aa5825df8f1ea0a2661d22a
Author: Romain Izard <romain.izard.pro@gmail.com>
Date:   Fri Feb 17 16:12:50 2017 +0100

    Revert "ARM: at91/dt: sama5d2: Use new compatible for ohci node"
    
    commit 9e10889a3177340dcda7d29c6d8fbd97247b007b upstream.
    
    This reverts commit cab43282682e ("ARM: at91/dt: sama5d2: Use new
    compatible for ohci node")
    
    It depends from commit 7150bc9b4d43 ("usb: ohci-at91: Forcibly suspend
    ports while USB suspend") which was reverted and implemented
    differently. With the new implementation, the compatible string must
    remain the same.
    
    The compatible string introduced by this commit has been used in the
    default SAMA5D2 dtsi starting from Linux 4.8. As it has never been
    working correctly in an official release, removing it should not be
    breaking the stability rules.
    
    Fixes: cab43282682e ("ARM: at91/dt: sama5d2: Use new compatible for ohci node")
    Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 514e122cf8d0dd7350009d44553a16dc2a18ac7b
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date:   Mon Mar 20 10:17:57 2017 +0100

    iommu/exynos: Workaround FLPD cache flush issues for SYSMMU v5
    
    commit cd37a296a9f890586665bb8974a8b17ee2f17d6d upstream.
    
    For some unknown reasons, in some cases, FLPD cache invalidation doesn't
    work properly with SYSMMU v5 controllers found in Exynos5433 SoCs. This
    can be observed by a firmware crash during initialization phase of MFC
    video decoder available in the mentioned SoCs when IOMMU support is
    enabled. To workaround this issue perform a full TLB/FLPD invalidation
    in case of replacing any first level page descriptors in case of SYSMMU v5.
    
    Fixes: 740a01eee9ada ("iommu/exynos: Add support for v5 SYSMMU")
    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Tested-by: Andrzej Hajda <a.hajda@samsung.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 03d92bd5b426ea4ee6def637c101195b57f74bf0
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date:   Mon Mar 20 10:17:56 2017 +0100

    iommu/exynos: Block SYSMMU while invalidating FLPD cache
    
    commit 7d2aa6b814476a2e2794960f844344519246df72 upstream.
    
    Documentation specifies that SYSMMU should be in blocked state while
    performing TLB/FLPD cache invalidation, so add needed calls to
    sysmmu_block/unblock.
    
    Fixes: 66a7ed84b345d ("iommu/exynos: Apply workaround of caching fault page table entries")
    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b7d02d90d03a985bd041068c13844e02d76baad7
Author: Koos Vriezen <koos.vriezen@gmail.com>
Date:   Wed Mar 1 21:02:50 2017 +0100

    iommu/vt-d: Fix NULL pointer dereference in device_to_iommu
    
    commit 5003ae1e735e6bfe4679d9bed6846274f322e77e upstream.
    
    The function device_to_iommu() in the Intel VT-d driver
    lacks a NULL-ptr check, resulting in this oops at boot on
    some platforms:
    
     BUG: unable to handle kernel NULL pointer dereference at 00000000000007ab
     IP: [<ffffffff8132234a>] device_to_iommu+0x11a/0x1a0
     PGD 0
    
     [...]
    
     Call Trace:
       ? find_or_alloc_domain.constprop.29+0x1a/0x300
       ? dw_dma_probe+0x561/0x580 [dw_dmac_core]
       ? __get_valid_domain_for_dev+0x39/0x120
       ? __intel_map_single+0x138/0x180
       ? intel_alloc_coherent+0xb6/0x120
       ? sst_hsw_dsp_init+0x173/0x420 [snd_soc_sst_haswell_pcm]
       ? mutex_lock+0x9/0x30
       ? kernfs_add_one+0xdb/0x130
       ? devres_add+0x19/0x60
       ? hsw_pcm_dev_probe+0x46/0xd0 [snd_soc_sst_haswell_pcm]
       ? platform_drv_probe+0x30/0x90
       ? driver_probe_device+0x1ed/0x2b0
       ? __driver_attach+0x8f/0xa0
       ? driver_probe_device+0x2b0/0x2b0
       ? bus_for_each_dev+0x55/0x90
       ? bus_add_driver+0x110/0x210
       ? 0xffffffffa11ea000
       ? driver_register+0x52/0xc0
       ? 0xffffffffa11ea000
       ? do_one_initcall+0x32/0x130
       ? free_vmap_area_noflush+0x37/0x70
       ? kmem_cache_alloc+0x88/0xd0
       ? do_init_module+0x51/0x1c4
       ? load_module+0x1ee9/0x2430
       ? show_taint+0x20/0x20
       ? kernel_read_file+0xfd/0x190
       ? SyS_finit_module+0xa3/0xb0
       ? do_syscall_64+0x4a/0xb0
       ? entry_SYSCALL64_slow_path+0x25/0x25
     Code: 78 ff ff ff 4d 85 c0 74 ee 49 8b 5a 10 0f b6 9b e0 00 00 00 41 38 98 e0 00 00 00 77 da 0f b6 eb 49 39 a8 88 00 00 00 72 ce eb 8f <41> f6 82 ab 07 00 00 04 0f 85 76 ff ff ff 0f b6 4d 08 88 0e 49
     RIP  [<ffffffff8132234a>] device_to_iommu+0x11a/0x1a0
      RSP <ffffc90001457a78>
     CR2: 00000000000007ab
     ---[ end trace 16f974b6d58d0aad ]---
    
    Add the missing pointer check.
    
    Fixes: 1c387188c60f53b338c20eee32db055dfe022a9b ("iommu/vt-d: Fix IOMMU lookup for SR-IOV Virtual Functions")
    Signed-off-by: Koos Vriezen <koos.vriezen@gmail.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fa477d804fd3e05f0599f866193f2deea0147f34
Author: Ankur Arora <ankur.a.arora@oracle.com>
Date:   Tue Mar 21 15:43:38 2017 -0700

    xen/acpi: upload PM state from init-domain to Xen
    
    commit 1914f0cd203c941bba72f9452c8290324f1ef3dc upstream.
    
    This was broken in commit cd979883b9ed ("xen/acpi-processor:
    fix enabling interrupts on syscore_resume"). do_suspend (from
    xen/manage.c) and thus xen_resume_notifier never get called on
    the initial-domain at resume (it is if running as guest.)
    
    The rationale for the breaking change was that upload_pm_data()
    potentially does blocking work in syscore_resume(). This patch
    addresses the original issue by scheduling upload_pm_data() to
    execute in workqueue context.
    
    Cc: Stanislaw Gruszka <sgruszka@redhat.com>
    Based-on-patch-by: Konrad Wilk <konrad.wilk@oracle.com>
    Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b0219e35b43cb6ceb592a1fb35af5a9d5d91b5d
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Tue Mar 21 13:19:09 2017 -0600

    vfio: Rework group release notifier warning
    
    commit 65b1adebfe43c642dfe3b109edb5d992db5fbe72 upstream.
    
    The intent of the original warning is make sure that the mdev vendor
    driver has removed any group notifiers at the point where the group
    is closed by the user.  Theoretically this would be through an
    orderly shutdown where any devices are release prior to the group
    release.  We can't always count on an orderly shutdown, the user can
    close the group before the notifier can be removed or the user task
    might be killed.  We'd like to add this sanity test when the group is
    idle and the only references are from the devices within the group
    themselves, but we don't have a good way to do that.  Instead check
    both when the group itself is removed and when the group is opened.
    A bit later than we'd prefer, but better than the current over
    aggressive approach.
    
    Fixes: ccd46dbae77d ("vfio: support notifier chain in vfio_group")
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Cc: Jike Song <jike.song@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d05871e5e4319e846a9596dd24b7546b1c81eb7
Author: Eric Biggers <ebiggers@google.com>
Date:   Tue Feb 21 15:07:11 2017 -0800

    fscrypt: remove broken support for detecting keyring key revocation
    
    commit 1b53cf9815bb4744958d41f3795d5d5a1d365e2d upstream.
    
    Filesystem encryption ostensibly supported revoking a keyring key that
    had been used to "unlock" encrypted files, causing those files to become
    "locked" again.  This was, however, buggy for several reasons, the most
    severe of which was that when key revocation happened to be detected for
    an inode, its fscrypt_info was immediately freed, even while other
    threads could be using it for encryption or decryption concurrently.
    This could be exploited to crash the kernel or worse.
    
    This patch fixes the use-after-free by removing the code which detects
    the keyring key having been revoked, invalidated, or expired.  Instead,
    an encrypted inode that is "unlocked" now simply remains unlocked until
    it is evicted from memory.  Note that this is no worse than the case for
    block device-level encryption, e.g. dm-crypt, and it still remains
    possible for a privileged user to evict unused pages, inodes, and
    dentries by running 'sync; echo 3 > /proc/sys/vm/drop_caches', or by
    simply unmounting the filesystem.  In fact, one of those actions was
    already needed anyway for key revocation to work even somewhat sanely.
    This change is not expected to break any applications.
    
    In the future I'd like to implement a real API for fscrypt key
    revocation that interacts sanely with ongoing filesystem operations ---
    waiting for existing operations to complete and blocking new operations,
    and invalidating and sanitizing key material and plaintext from the VFS
    caches.  But this is a hard problem, and for now this bug must be fixed.
    
    This bug affected almost all versions of ext4, f2fs, and ubifs
    encryption, and it was potentially reachable in any kernel configured
    with encryption support (CONFIG_EXT4_ENCRYPTION=y,
    CONFIG_EXT4_FS_ENCRYPTION=y, CONFIG_F2FS_FS_ENCRYPTION=y, or
    CONFIG_UBIFS_FS_ENCRYPTION=y).  Note that older kernels did not use the
    shared fs/crypto/ code, but due to the potential security implications
    of this bug, it may still be worthwhile to backport this fix to them.
    
    Fixes: b7236e21d55f ("ext4 crypto: reorganize how we store keys in the inode")
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Acked-by: Michael Halcrow <mhalcrow@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f115bf08b7d2a67aded1b11dcf89892fd4e90298
Author: Gary R Hook <ghook@amd.com>
Date:   Fri Mar 10 12:28:18 2017 -0600

    crypto: ccp - Assign DMA commands to the channel's CCP
    
    commit 7c468447f40645fbf2a033dfdaa92b1957130d50 upstream.
    
    The CCP driver generally uses a round-robin approach when
    assigning operations to available CCPs. For the DMA engine,
    however, the DMA mappings of the SGs are associated with a
    specific CCP. When an IOMMU is enabled, the IOMMU is
    programmed based on this specific device.
    
    If the DMA operations are not performed by that specific
    CCP then addressing errors and I/O page faults will occur.
    
    Update the CCP driver to allow a specific CCP device to be
    requested for an operation and use this in the DMA engine
    support.
    
    Signed-off-by: Gary R Hook <gary.hook@amd.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c62625b6b383748963a116cdd66f7e030717b171
Author: Ryan Hsu <ryanhsu@qca.qualcomm.com>
Date:   Mon Mar 13 15:49:03 2017 -0700

    ath10k: fix incorrect wlan_mac_base in qca6174_regs
    
    commit 6be3b6cce1e225f189b68b4e84fc711d19b4277b upstream.
    
    In the 'commit ebee76f7fa46 ("ath10k: allow setting coverage class")',
    it inherits the design and the address offset from ath9k, but the address
    is not applicable to QCA6174, which leads to a random crash while doing the
    resume() operation, since the set_coverage_class.ops will be called from
    ieee80211_reconfig() when resume() (if the wow is not configured).
    
    Fix the incorrect address offset here to avoid the random crash.
    
    Verified on QCA6174/hw3.0 with firmware WLAN.RM.4.4-00022-QCARMSWPZ-2.
    
    kvalo: this also seems to fix a regression with firmware restart.
    
    Fixes: ebee76f7fa46 ("ath10k: allow setting coverage class")
    Signed-off-by: Ryan Hsu <ryanhsu@qca.qualcomm.com>
    Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f69745c309c5b823765db08d0c96a949a6a33de
Author: Brian Norris <briannorris@chromium.org>
Date:   Fri Mar 10 17:39:21 2017 -0800

    mwifiex: pcie: don't leak DMA buffers when removing
    
    commit 4e841d3eb9294ce4137fdb5d0a88f1bceab9c212 upstream.
    
    When PCIe FLR support was added, much of the remove/release code for
    PCIe was migrated to ->down_dev(), but ->down_dev() is never called for
    device removal. Let's refactor the cleanup to be done in both cases.
    
    Also, drop the comments above mwifiex_cleanup_pcie(), because they were
    clearly wrong, and it's better to have clear and obvious code than to
    detail the code steps in comments anyway.
    
    Fixes: 4c5dae59d2e9 ("mwifiex: add PCIe function level reset support")
    Signed-off-by: Brian Norris <briannorris@chromium.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad3b48d36e0df32fa76e0be491ce8591d13f265e
Author: Chen-Yu Tsai <wens@csie.org>
Date:   Tue Feb 14 11:35:22 2017 +0800

    clk: sunxi-ng: mp: Adjust parent rate for pre-dividers
    
    commit ac8616e4c81dded650dfade49a7da283565d37ce upstream.
    
    The MP style clocks support an mux with pre-dividers. While the driver
    correctly accounted for them in the .determine_rate callback, it did
    not in the .recalc_rate and .set_rate callbacks.
    
    This means when calculating the factors in the .set_rate callback, they
    would be off by a factor of the active pre-divider. Same goes for
    reading back the clock rate after it is set.
    
    Fixes: 2ab836db5097 ("clk: sunxi-ng: Add M-P factor clock support")
    Signed-off-by: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9300e322b68db47bee5e0d543762065fde522061
Author: Chen-Yu Tsai <wens@csie.org>
Date:   Tue Feb 14 10:23:32 2017 +0800

    clk: sunxi-ng: sun6i: Fix enable bit offset for hdmi-ddc module clock
    
    commit 9ad0bb39fce319d7b92c17d306ed0a9f70a02e7d upstream.
    
    The enable bit offset for the hdmi-ddc module clock is wrong. It is
    pointing to the main hdmi module clock enable bit.
    
    Reported-by: Bob Ham <rah@settrans.net>
    Fixes: c6e6c96d8fa6 ("clk: sunxi-ng: Add A31/A31s clocks")
    Signed-off-by: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 76b5eb51114aab772fd85da3a5e936864fc2deaf
Author: Prarit Bhargava <prarit@redhat.com>
Date:   Tue Mar 14 07:36:02 2017 -0400

    hwrng: geode - Revert managed API changes
    
    commit 8c75704ebcac2ffa31ee7bcc359baf701b52bf00 upstream.
    
    After commit e9afc746299d ("hwrng: geode - Use linux/io.h instead of
    asm/io.h") the geode-rng driver uses devres with pci_dev->dev to keep
    track of resources, but does not actually register a PCI driver.  This
    results in the following issues:
    
    1.  The driver leaks memory because the driver does not attach to a
    device.  The driver only uses the PCI device as a reference.   devm_*()
    functions will release resources on driver detach, which the geode-rng
    driver will never do.  As a result,
    
    2.  The driver cannot be reloaded because there is always a use of the
    ioport and region after the first load of the driver.
    
    Revert the changes made by  e9afc746299d ("hwrng: geode - Use linux/io.h
    instead of asm/io.h").
    
    Signed-off-by: Prarit Bhargava <prarit@redhat.com>
    Fixes: 6e9b5e76882c ("hwrng: geode - Migrate to managed API")
    Cc: Matt Mackall <mpm@selenic.com>
    Cc: Corentin LABBE <clabbe.montjoie@gmail.com>
    Cc: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
    Cc: Wei Yongjun <weiyongjun1@huawei.com>
    Cc: linux-crypto@vger.kernel.org
    Cc: linux-geode@lists.infradead.org
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b35f163f7fe408c9993a67d9a1c354b55cdfe4a
Author: Prarit Bhargava <prarit@redhat.com>
Date:   Tue Mar 14 07:36:01 2017 -0400

    hwrng: amd - Revert managed API changes
    
    commit 69db7009318758769d625b023402161c750f7876 upstream.
    
    After commit 31b2a73c9c5f ("hwrng: amd - Migrate to managed API"), the
    amd-rng driver uses devres with pci_dev->dev to keep track of resources,
    but does not actually register a PCI driver.  This results in the
    following issues:
    
    1. The message
    
    WARNING: CPU: 2 PID: 621 at drivers/base/dd.c:349 driver_probe_device+0x38c
    
    is output when the i2c_amd756 driver loads and attempts to register a PCI
    driver.  The PCI & device subsystems assume that no resources have been
    registered for the device, and the WARN_ON() triggers since amd-rng has
    already do so.
    
    2.  The driver leaks memory because the driver does not attach to a
    device.  The driver only uses the PCI device as a reference.   devm_*()
    functions will release resources on driver detach, which the amd-rng
    driver will never do.  As a result,
    
    3.  The driver cannot be reloaded because there is always a use of the
    ioport and region after the first load of the driver.
    
    Revert the changes made by 31b2a73c9c5f ("hwrng: amd - Migrate to managed
    API").
    
    Signed-off-by: Prarit Bhargava <prarit@redhat.com>
    Fixes: 31b2a73c9c5f ("hwrng: amd - Migrate to managed API").
    Cc: Matt Mackall <mpm@selenic.com>
    Cc: Corentin LABBE <clabbe.montjoie@gmail.com>
    Cc: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
    Cc: Wei Yongjun <weiyongjun1@huawei.com>
    Cc: linux-crypto@vger.kernel.org
    Cc: linux-geode@lists.infradead.org
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ce6c155ada08872d3b80aaa9b4c13391397436fb
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Mon Mar 20 19:50:30 2017 +0200

    mmc: sdhci-pci: Do not disable interrupts in sdhci_intel_set_power
    
    commit 027fb89e61054b4aedd962adb3e2003dec78a716 upstream.
    
    Disabling interrupts for even a millisecond can cause problems for some
    devices. That can happen when Intel host controllers wait for the present
    state to propagate.
    
    The spin lock is not necessary here. Anything that is racing with changes
    to the I/O state is already broken. The mmc core already provides
    synchronization via "claiming" the host.
    
    Although the spin lock probably should be removed from the code paths that
    lead to this point, such a patch would touch too much code to be suitable
    for stable trees. Consequently, for this patch, just drop the spin lock
    while waiting.
    
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Tested-by: Ludovic Desroches <ludovic.desroches@microchip.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f89c8a5007b27107344417798f52ff694fb1b081
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Mon Mar 20 19:50:29 2017 +0200

    mmc: sdhci: Do not disable interrupts while waiting for clock
    
    commit e2ebfb2142acefecc2496e71360f50d25726040b upstream.
    
    Disabling interrupts for even a millisecond can cause problems for some
    devices. That can happen when sdhci changes clock frequency because it
    waits for the clock to become stable under a spin lock.
    
    The spin lock is not necessary here. Anything that is racing with changes
    to the I/O state is already broken. The mmc core already provides
    synchronization via "claiming" the host.
    
    Although the spin lock probably should be removed from the code paths that
    lead to this point, such a patch would touch too much code to be suitable
    for stable trees. Consequently, for this patch, just drop the spin lock
    while waiting.
    
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Tested-by: Ludovic Desroches <ludovic.desroches@microchip.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b821a0a5fde92add670f877f29e65e8ad7b05b1a
Author: Anssi Hannula <anssi.hannula@bitwise.fi>
Date:   Mon Feb 13 14:06:10 2017 +0200

    mmc: sdhci-of-arasan: fix incorrect timeout clock
    
    commit 16681037e75ce08f2980ac5dbb03414429c7a55d upstream.
    
    sdhci_arasan_get_timeout_clock() divides the frequency it has with (1 <<
    (13 + divisor)).
    
    However, the divisor is not some Arasan-specific value, but instead is
    just the Data Timeout Counter Value from the SDHCI Timeout Control
    Register.
    
    Applying it here like this is wrong as the sdhci driver already takes
    that value into account when calculating timeouts, and in fact it *sets*
    that register value based on how long a timeout is wanted.
    
    Additionally, sdhci core interprets the .get_timeout_clock callback
    return value as if it were read from hardware registers, i.e. the unit
    should be kHz or MHz depending on SDHCI_TIMEOUT_CLK_UNIT capability bit.
    This bit is set at least on the tested Zynq-7000 SoC.
    
    With the tested hardware (SDHCI_TIMEOUT_CLK_UNIT set) this results in
    too high a timeout clock rate being reported, causing the core to use
    longer-than-needed timeouts. Additionally, on a partitioned MMC
    (therefore having erase_group_def bit set) mmc_calc_max_discard()
    disables discard support as it looks like controller does not support
    the long timeouts needed for that.
    
    Do not apply the extra divisor and return the timeout clock in the
    expected unit.
    
    Tested with a Zynq-7000 SoC and a partitioned Toshiba THGBMAG5A1JBAWR
    eMMC card.
    
    Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
    Fixes: e3ec3a3d11ad ("mmc: arasan: Add driver for Arasan SDHCI")
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 116418547216d35b83475ed1bfabd7419827a414
Author: Romain Izard <romain.izard.pro@gmail.com>
Date:   Thu Mar 9 16:18:20 2017 +0100

    mmc: sdhci-of-at91: Support external regulators
    
    commit 2ce0c7b65505e0d915e99389cced45b478dc935d upstream.
    
    The SDHCI controller in the SAMA5D2 chip requires a valid voltage set
    in the power control register, otherwise commands will fail with a
    timeout error.
    
    When using the regulator framework to specify the regulator used by the
    mmc device, the voltage is not configured, and it is not possible to use
    the connected device.
    
    Implement a custom 'set_power' function for this specific hardware, that
    configures the voltage in the register in all cases.
    
    Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>
    Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a0c48115cd2343231585f2f5e609b2ac9aa4e0af
Author: Paul Moore <paul@paul-moore.com>
Date:   Tue Mar 21 11:26:35 2017 -0400

    audit: fix auditd/kernel connection state tracking
    
    commit 5b52330bbfe63b3305765354d6046c9f7f89c011 upstream.
    
    What started as a rather straightforward race condition reported by
    Dmitry using the syzkaller fuzzer ended up revealing some major
    problems with how the audit subsystem managed its netlink sockets and
    its connection with the userspace audit daemon.  Fixing this properly
    had quite the cascading effect and what we are left with is this rather
    large and complicated patch.  My initial goal was to try and decompose
    this patch into multiple smaller patches, but the way these changes
    are intertwined makes it difficult to split these changes into
    meaningful pieces that don't break or somehow make things worse for
    the intermediate states.
    
    The patch makes a number of changes, but the most significant are
    highlighted below:
    
    * The auditd tracking variables, e.g. audit_sock, are now gone and
    replaced by a RCU/spin_lock protected variable auditd_conn which is
    a structure containing all of the auditd tracking information.
    
    * We no longer track the auditd sock directly, instead we track it
    via the network namespace in which it resides and we use the audit
    socket associated with that namespace.  In spirit, this is what the
    code was trying to do prior to this patch (at least I think that is
    what the original authors intended), but it was done rather poorly
    and added a layer of obfuscation that only masked the underlying
    problems.
    
    * Big backlog queue cleanup, again.  In v4.10 we made some pretty big
    changes to how the audit backlog queues work, here we haven't changed
    the queue design so much as cleaned up the implementation.  Brought
    about by the locking changes, we've simplified kauditd_thread() quite
    a bit by consolidating the queue handling into a new helper function,
    kauditd_send_queue(), which allows us to eliminate a lot of very
    similar code and makes the looping logic in kauditd_thread() clearer.
    
    * All netlink messages sent to auditd are now sent via
    auditd_send_unicast_skb().  Other than just making sense, this makes
    the lock handling easier.
    
    * Change the audit_log_start() sleep behavior so that we never sleep
    on auditd events (unchanged) or if the caller is holding the
    audit_cmd_mutex (changed).  Previously we didn't sleep if the caller
    was auditd or if the message type fell between a certain range; the
    type check was a poor effort of doing what the cmd_mutex check now
    does.  Richard Guy Briggs originally proposed not sleeping the
    cmd_mutex owner several years ago but his patch wasn't acceptable
    at the time.  At least the idea lives on here.
    
    * A problem with the lost record counter has been resolved.  Steve
    Grubb and I both happened to notice this problem and according to
    some quick testing by Steve, this problem goes back quite some time.
    It's largely a harmless problem, although it may have left some
    careful sysadmins quite puzzled.
    
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72c89fa6106a94b9bb793d58907c61d8d09741f6
Author: Nicholas Piggin <npiggin@gmail.com>
Date:   Fri Mar 17 15:13:20 2017 +1000

    powerpc/64s: Fix idle wakeup potential to clobber registers
    
    commit 6d98ce0be541d4a3cfbb52cd75072c0339ebb500 upstream.
    
    We concluded there may be a window where the idle wakeup code could get
    to pnv_wakeup_tb_loss() (which clobbers non-volatile GPRs), but the
    hardware may set SRR1[46:47] to 01b (no state loss) which would result
    in the wakeup code failing to restore non-volatile GPRs.
    
    I was not able to trigger this condition with trivial tests on real
    hardware or simulator, but the ISA (at least 2.07) seems to allow for
    it, and Gautham says that it can happen if there is an exception pending
    when the sleep/winkle instruction is executed.
    
    Fixes: 1706567117ba ("powerpc/kvm: make hypervisor state restore a function")
    Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
    Acked-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 35637b59f6759d3c79d881490aaca2dc73173bf5
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Sat Mar 25 17:22:47 2017 -0400

    ext4: lock the xattr block before checksuming it
    
    commit dac7a4b4b1f664934e8b713f529b629f67db313c upstream.
    
    We must lock the xattr block before calculating or verifying the
    checksum in order to avoid spurious checksum failures.
    
    https://bugzilla.kernel.org/show_bug.cgi?id=193661
    
    Reported-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 26512e52106d8050bcf710e62badbcb120c34841
Author: Eric Biggers <ebiggers@google.com>
Date:   Wed Mar 15 14:52:02 2017 -0400

    ext4: mark inode dirty after converting inline directory
    
    commit b9cf625d6ecde0d372e23ae022feead72b4228a6 upstream.
    
    If ext4_convert_inline_data() was called on a directory with inline
    data, the filesystem was left in an inconsistent state (as considered by
    e2fsck) because the file size was not increased to cover the new block.
    This happened because the inode was not marked dirty after i_disksize
    was updated.  Fix this by marking the inode dirty at the end of
    ext4_finish_convert_inline_dir().
    
    This bug was probably not noticed before because most users mark the
    inode dirty afterwards for other reasons.  But if userspace executed
    FS_IOC_SET_ENCRYPTION_POLICY with invalid parameters, as exercised by
    'kvm-xfstests -c adv generic/396', then the inode was never marked dirty
    after updating i_disksize.
    
    Fixes: 3c47d54170b6a678875566b1b8d6dcf57904e49b
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 762602796be626cbb6b3a6573e00b9ee7db00c97
Author: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Date:   Mon Mar 6 23:23:43 2017 +0000

    ppdev: fix registering same device name
    
    commit 9a69645dde1188723d80745c1bc6ee9af2cbe2a7 upstream.
    
    Usually every parallel port will have a single pardev registered with
    it. But ppdev driver is an exception. This userspace parallel port
    driver allows to create multiple parrallel port devices for a single
    parallel port. And as a result we were having a big warning like:
    "sysfs: cannot create duplicate filename '/devices/parport0/ppdev0.0'".
    And with that many parallel port printers stopped working.
    
    We have been using the minor number as the id field while registering
    a parralel port device with a parralel port. But when there are
    multiple parrallel port device for one single parallel port, they all
    tried to register with the same name like 'pardev0.0' and everything
    started failing.
    Use an incremented index as the id instead of the minor number.
    
    Fixes: 8b7d3a9d903e ("ppdev: use new parport device model")
    Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1414656
    Bugzilla: https://bugs.archlinux.org/task/52322
    Tested-by: James Feeney <james@nurealm.net>
    Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f8155f4e63687c55fb24dbded73ffc190e5eefa0
Author: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Date:   Mon Mar 6 23:23:42 2017 +0000

    parport: fix attempt to write duplicate procfiles
    
    commit 03270c6ac6207fc55bbf9d20d195029dca210c79 upstream.
    
    Usually every parallel port will have a single pardev registered with
    it. But ppdev driver is an exception. This userspace parallel port
    driver allows to create multiple parrallel port devices for a single
    parallel port. And as a result we were having a nice warning like:
    "sysctl table check failed:
    /dev/parport/parport0/devices/ppdev0/timeslice Sysctl already exists"
    
    Use the same logic as used in parport_register_device() and register
    the proc files only once for each parallel port.
    
    Fixes: 6fa45a226897 ("parport: add device-model to parport subsystem")
    Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1414656
    Bugzilla: https://bugs.archlinux.org/task/52322
    Tested-by: James Feeney <james@nurealm.net>
    Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c3a22b5f4339623af3196491deec4d6b82ca2720
Author: Alexander Usyskin <alexander.usyskin@intel.com>
Date:   Sun Mar 5 21:40:42 2017 +0200

    mei: don't wait for os version message reply
    
    commit c6240cacdb2c3cb56a21fb3ea0c105154ab87a2a upstream.
    
    The driver still struggles with firmwares that do not replay to the OS
    version request. It is safe not waiting for the replay. First, the driver
    doesn't do anything with the replay second the connection is closed
    immediately, hence the packet will be just safely discarded in case it
    is received and last the driver won't get stuck if the firmware won't
    reply.
    
    Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
    Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0dc119af06a5b04287269244cc0496632017bb8e
Author: Tomas Winkler <tomas.winkler@intel.com>
Date:   Sun Mar 5 21:40:41 2017 +0200

    mei: fix deadlock on mei reset
    
    commit a733ded50b6ea846200073e7381a302df71e13b3 upstream.
    
    This patch fixes 'mei: synchronize irq before initiating a reset'
    The patch had introduced a deadlock between irq thread and mei_reset()
    as they are both holding the same device lock.
    
    ---> device_lock:
            mei_reset()
                            <---- interrupt thread
                                    device_lock
    ---> synchornize_irq()
           wait on interrupt thread == (dead lock)
    
    The fix is to call synchronize_irq
    prior to call locked mei_reset function.
    
    Fixes: f302bb0de6ac (mei: synchronize irq before initiating a reset)
    Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bf1aedff42b22df092f97a43a8f6b74fd75799ce
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Wed Mar 1 15:37:57 2017 -0800

    iio: magnetometer: ak8974: remove incorrect __exit markups
    
    commit 3ff861f59f6c1f5bf2bc03d2cd36ac3f992cbc06 upstream.
    
    Even if bus is not hot-pluggable, devices can be unbound from the
    driver via sysfs, so we should not be using __exit annotations on
    remove() methods. The only exception is drivers registered with
    platform_driver_probe() which specifically disables sysfs bind/unbind
    attributes.
    
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c2aab07d12436af1cd8d9ac1d117a442cc91eec
Author: Song Hongyan <hongyan.song@intel.com>
Date:   Wed Feb 22 17:17:38 2017 +0800

    iio: hid-sensor-trigger: Change get poll value function order to avoid sensor properties losing after resume from S3
    
    commit 3bec247474469f769af41e8c80d3a100dd97dd76 upstream.
    
    In function _hid_sensor_power_state(), when hid_sensor_read_poll_value()
    is called, sensor's all properties will be updated by the value from
    sensor hardware/firmware.
    In some implementation, sensor hardware/firmware will do a power cycle
    during S3. In this case, after resume, once hid_sensor_read_poll_value()
    is called, sensor's all properties which are kept by driver during S3
    will be changed to default value.
    But instead, if a set feature function is called first, sensor
    hardware/firmware will be recovered to the last status. So change the
    sensor_hub_set_feature() calling order to behind of set feature function
    to avoid sensor properties lose.
    
    Signed-off-by: Song Hongyan <hongyan.song@intel.com>
    Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9323d92a280b2a2b14aa76c3d790b68344d83297
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Thu Mar 9 17:20:04 2017 +0100

    iio: sw-device: Fix config group initialization
    
    commit c42f8218610aa09d7d3795e5810387673c1f84b6 upstream.
    
    Use the IS_ENABLED() helper macro to ensure that the configfs group is
    initialized either when configfs is built-in or when configfs is built as a
    module. Otherwise software device creation will result in undefined
    behaviour when configfs is built as a module since the configfs group for
    the device not properly initialized.
    
    Similar to commit b2f0c09664b7 ("iio: sw-trigger: Fix config group
    initialization").
    
    Fixes: 0f3a8c3f34f7 ("iio: Add support for creating IIO devices via configfs")
    Reported-by: Miguel Robles <miguel.robles@farole.net>
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Acked-by: Daniel Baluta <daniel.baluta@gmail.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a12d1eadd0d1bf4b8c929d2cea942d2b4f2d167a
Author: Michael Engl <michael.engl@wjw-solutions.com>
Date:   Tue Oct 3 13:57:00 2017 +0100

    iio: adc: ti_am335x_adc: fix fifo overrun recovery
    
    commit e83bb3e6f3efa21f4a9d883a25d0ecd9dfb431e1 upstream.
    
    The tiadc_irq_h(int irq, void *private) function is handling FIFO
    overruns by clearing flags, disabling and enabling the ADC to
    recover.
    
    If the ADC is running in continuous mode a FIFO overrun happens
    regularly. If the disabling of the ADC happens concurrently with
    a new conversion. It might happen that the enabling of the ADC
    is ignored by the hardware. This stops the ADC permanently. No
    more interrupts are triggered.
    
    According to the AM335x Reference Manual (SPRUH73H October 2011 -
    Revised April 2013 - Chapter 12.4 and 12.5) it is necessary to
    check the ADC FSM bits in REG_ADCFSM before enabling the ADC
    again. Because the disabling of the ADC is done right after the
    current conversion has been finished.
    
    To trigger this bug it is necessary to run the ADC in continuous
    mode. The ADC values of all channels need to be read in an endless
    loop. The bug appears within the first 6 hours (~5.4 million
    handled FIFO overruns). The user space application will hang on
    reading new values from the character device.
    
    Fixes: ca9a563805f7a ("iio: ti_am335x_adc: Add continuous sampling support")
    Signed-off-by: Michael Engl <michael.engl@wjw-solutions.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f4004c87c8c66bb611c0c2cd295dccfb27af557e
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Wed Mar 1 14:11:47 2017 -0800

    mmc: core: Fix access to HS400-ES devices
    
    commit 773dc118756b1f38766063e90e582016be868f09 upstream.
    
    HS400-ES devices fail to initialize with the following error messages.
    
    mmc1: power class selection to bus width 8 ddr 0 failed
    mmc1: error -110 whilst initialising MMC card
    
    This was seen on Samsung Chromebook Plus. Code analysis points to
    commit 3d4ef329757c ("mmc: core: fix multi-bit bus width without
    high-speed mode"), which attempts to set the bus width for all but
    HS200 devices unconditionally. However, for HS400-ES, the bus width
    is already selected.
    
    Cc: Anssi Hannula <anssi.hannula@bitwise.fi>
    Cc: Douglas Anderson <dianders@chromium.org>
    Cc: Brian Norris <briannorris@chromium.org>
    Fixes: 3d4ef329757c ("mmc: core: fix multi-bit bus width ...")
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Reviewed-by: Shawn Lin <shawn.lin@rock-chip.com>
    Tested-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a56eba20b4473572c94504a56d720afaac97848f
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Mar 15 14:26:04 2017 +0100

    nl80211: fix dumpit error path RTNL deadlocks
    
    commit ea90e0dc8cecba6359b481e24d9c37160f6f524f upstream.
    
    Sowmini pointed out Dmitry's RTNL deadlock report to me, and it turns out
    to be perfectly accurate - there are various error paths that miss unlock
    of the RTNL.
    
    To fix those, change the locking a bit to not be conditional in all those
    nl80211_prepare_*_dump() functions, but make those require the RTNL to
    start with, and fix the buggy error paths. This also let me use sparse
    (by appropriately overriding the rtnl_lock/rtnl_unlock functions) to
    validate the changes.
    
    Reported-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f876c1039440a492f354bf7347d8d633d45596bd
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Mar 13 13:40:22 2017 +0100

    mmc: ushc: fix NULL-deref at probe
    
    commit 181302dc7239add8ab1449c23ecab193f52ee6ab upstream.
    
    Make sure to check the number of endpoints to avoid dereferencing a
    NULL-pointer should a malicious device lack endpoints.
    
    Fixes: 53f3a9e26ed5 ("mmc: USB SD Host Controller (USHC) driver")
    Cc: David Vrabel <david.vrabel@csr.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 90c2bb66e98e3edf23b490bb34bdf03d98c7d157
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Mar 13 13:47:52 2017 +0100

    uwb: hwa-rc: fix NULL-deref at probe
    
    commit daf229b15907fbfdb6ee183aac8ca428cb57e361 upstream.
    
    Make sure to check the number of endpoints to avoid dereferencing a
    NULL-pointer should a malicious device lack endpoints.
    
    Note that the dereference happens in the start callback which is called
    during probe.
    
    Fixes: de520b8bd552 ("uwb: add HWA radio controller driver")
    Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
    Cc: David Vrabel <david.vrabel@csr.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 05393ccea6e388d10ccfa00bf61862d5f057db4d
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Mar 13 13:47:53 2017 +0100

    uwb: i1480-dfu: fix NULL-deref at probe
    
    commit 4ce362711d78a4999011add3115b8f4b0bc25e8c upstream.
    
    Make sure to check the number of endpoints to avoid dereferencing a
    NULL-pointer should a malicious device lack endpoints.
    
    Note that the dereference happens in the cmd and wait_init_done
    callbacks which are called during probe.
    
    Fixes: 1ba47da52712 ("uwb: add the i1480 DFU driver")
    Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
    Cc: David Vrabel <david.vrabel@csr.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb486e80a13f0f4d61b9256b58aa33b9cf57d3f3
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Mar 14 17:55:46 2017 +0100

    USB: usbtmc: fix probe error path
    
    commit 2e47c53503eb9faff42b3cfa144a833344dd1f89 upstream.
    
    Make sure to initialise the return value to avoid having allocation
    failures going unnoticed when allocating interrupt-endpoint resources.
    
    This prevents use-after-free or worse when the device is later unbound.
    
    Fixes: dbf3e7f654c0 ("Implement an ioctl to support the USMTMC-USB488 READ_STATUS_BYTE operation.")
    Cc: Dave Penkler <dpenkler@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad1bbccdf018396c3b469d0fea29aaae81b9ae09
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Mar 14 17:55:45 2017 +0100

    USB: usbtmc: add missing endpoint sanity check
    
    commit 687e0687f71ec00e0132a21fef802dee88c2f1ad upstream.
    
    USBTMC devices are required to have a bulk-in and a bulk-out endpoint,
    but the driver failed to verify this, something which could lead to the
    endpoint addresses being taken from uninitialised memory.
    
    Make sure to zero all private data as part of allocation, and add the
    missing endpoint sanity check.
    
    Note that this also addresses a more recently introduced issue, where
    the interrupt-in-presence flag would also be uninitialised whenever the
    optional interrupt-in endpoint is not present. This in turn could lead
    to an interrupt urb being allocated, initialised and submitted based on
    uninitialised values.
    
    Fixes: dbf3e7f654c0 ("Implement an ioctl to support the USMTMC-USB488 READ_STATUS_BYTE operation.")
    Fixes: 5b775f672cc9 ("USB: add USB test and measurement class driver")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9ec0027442cb1be3f23b0104ed27fee512375d51
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Wed Mar 8 10:19:36 2017 -0800

    usb: hub: Fix crash after failure to read BOS descriptor
    
    commit 7b2db29fbb4e766fcd02207eb2e2087170bd6ebc upstream.
    
    If usb_get_bos_descriptor() returns an error, usb->bos will be NULL.
    Nevertheless, it is dereferenced unconditionally in
    hub_set_initial_usb2_lpm_policy() if usb2_hw_lpm_capable is set.
    This results in a crash.
    
    usb 5-1: unable to get BOS descriptor
    ...
    Unable to handle kernel NULL pointer dereference at virtual address 00000008
    pgd = ffffffc00165f000
    [00000008] *pgd=000000000174f003, *pud=000000000174f003,
                    *pmd=0000000001750003, *pte=00e8000001751713
    Internal error: Oops: 96000005 [#1] PREEMPT SMP
    Modules linked in: uinput uvcvideo videobuf2_vmalloc cmac [ ... ]
    CPU: 5 PID: 3353 Comm: kworker/5:3 Tainted: G    B 4.4.52 #480
    Hardware name: Google Kevin (DT)
    Workqueue: events driver_set_config_work
    task: ffffffc0c3690000 ti: ffffffc0ae9a8000 task.ti: ffffffc0ae9a8000
    PC is at hub_port_init+0xc3c/0xd10
    LR is at hub_port_init+0xc3c/0xd10
    ...
    Call trace:
    [<ffffffc0007fbbfc>] hub_port_init+0xc3c/0xd10
    [<ffffffc0007fbe2c>] usb_reset_and_verify_device+0x15c/0x82c
    [<ffffffc0007fc5e0>] usb_reset_device+0xe4/0x298
    [<ffffffbffc0e3fcc>] rtl8152_probe+0x84/0x9b0 [r8152]
    [<ffffffc00080ca8c>] usb_probe_interface+0x244/0x2f8
    [<ffffffc000774a24>] driver_probe_device+0x180/0x3b4
    [<ffffffc000774e48>] __device_attach_driver+0xb4/0xe0
    [<ffffffc000772168>] bus_for_each_drv+0xb4/0xe4
    [<ffffffc0007747ec>] __device_attach+0xd0/0x158
    [<ffffffc000775080>] device_initial_probe+0x24/0x30
    [<ffffffc0007739d4>] bus_probe_device+0x50/0xe4
    [<ffffffc000770bd0>] device_add+0x414/0x738
    [<ffffffc000809fe8>] usb_set_configuration+0x89c/0x914
    [<ffffffc00080a120>] driver_set_config_work+0xc0/0xf0
    [<ffffffc000249bb8>] process_one_work+0x390/0x6b8
    [<ffffffc00024abcc>] worker_thread+0x480/0x610
    [<ffffffc000251a80>] kthread+0x164/0x178
    [<ffffffc0002045d0>] ret_from_fork+0x10/0x40
    
    Since we don't know anything about LPM capabilities without BOS descriptor,
    don't attempt to enable LPM if it is not available.
    
    Fixes: 890dae886721 ("xhci: Enable LPM support only for hardwired ...")
    Cc: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9eae384ab967943206fcca6624463ee9d6c0fadd
Author: Bin Liu <b-liu@ti.com>
Date:   Fri Mar 10 14:43:35 2017 -0600

    usb: musb: cppi41: don't check early-TX-interrupt for Isoch transfer
    
    commit 0090114d336a9604aa2d90bc83f20f7cd121b76c upstream.
    
    The CPPI 4.1 driver polls register to workaround the premature TX
    interrupt issue, but it causes audio playback underrun when triggered in
    Isoch transfers.
    
    Isoch doesn't do back-to-back transfers, the TX should be done by the
    time the next transfer is scheduled. So skip this polling workaround for
    Isoch transfer.
    
    Fixes: a655f481d83d6 ("usb: musb: musb_cppi41: handle pre-mature TX complete interrupt")
    Reported-by: Alexandre Bailon <abailon@baylibre.com>
    Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Tested-by: Alexandre Bailon <abailon@baylibre.com>
    Signed-off-by: Bin Liu <b-liu@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a769fe27a7cf4aacb18efc73bb6024f81b0c7a73
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Mar 13 13:47:51 2017 +0100

    USB: wusbcore: fix NULL-deref at probe
    
    commit 03ace948a4eb89d1cf51c06afdfc41ebca5fdb27 upstream.
    
    Make sure to check the number of endpoints to avoid dereferencing a
    NULL-pointer or accessing memory beyond the endpoint array should a
    malicious device lack the expected endpoints.
    
    This specifically fixes the NULL-pointer dereference when probing HWA HC
    devices.
    
    Fixes: df3654236e31 ("wusb: add the Wire Adapter (WA) core")
    Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
    Cc: David Vrabel <david.vrabel@csr.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bcf394acf7360aae3d420bfa4b2172f48450fa44
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Mar 13 13:47:48 2017 +0100

    USB: idmouse: fix NULL-deref at probe
    
    commit b0addd3fa6bcd119be9428996d5d4522479ab240 upstream.
    
    Make sure to check the number of endpoints to avoid dereferencing a
    NULL-pointer should a malicious device lack endpoints.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f615aa74026ff786061b91ce37ffbf1767ce7342
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Mar 13 13:47:49 2017 +0100

    USB: lvtest: fix NULL-deref at probe
    
    commit 1dc56c52d2484be09c7398a5207d6b11a4256be9 upstream.
    
    Make sure to check the number of endpoints to avoid dereferencing a
    NULL-pointer should the probed device lack endpoints.
    
    Note that this driver does not bind to any devices by default.
    
    Fixes: ce21bfe603b3 ("USB: Add LVS Test device driver")
    Cc: Pratyush Anand <pratyush.anand@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0918c32f09ddaa28b2a502c5135ff2ff6ec9e2c1
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Mar 13 13:47:50 2017 +0100

    USB: uss720: fix NULL-deref at probe
    
    commit f259ca3eed6e4b79ac3d5c5c9fb259fb46e86217 upstream.
    
    Make sure to check the number of endpoints to avoid dereferencing a
    NULL-pointer or accessing memory beyond the endpoint array should a
    malicious device lack the expected endpoints.
    
    Note that the endpoint access that causes the NULL-deref is currently
    only used for debugging purposes during probe so the oops only happens
    when dynamic debugging is enabled. This means the driver could be
    rewritten to continue to accept device with only two endpoints, should
    such devices exist.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dfdd59a3ec07d48165c4ab13be40469b004d7227
Author: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date:   Mon Mar 13 20:50:08 2017 +0100

    usb-core: Add LINEAR_FRAME_INTR_BINTERVAL USB quirk
    
    commit 3243367b209faed5c320a4e5f9a565ee2a2ba958 upstream.
    
    Some USB 2.0 devices erroneously report millisecond values in
    bInterval. The generic config code manages to catch most of them,
    but in some cases it's not completely enough.
    
    The case at stake here is a USB 2.0 braille device, which wants to
    announce 10ms and thus sets bInterval to 10, but with the USB 2.0
    computation that yields to 64ms.  It happens that one can type fast
    enough to reach this interval and get the device buffers overflown,
    leading to problematic latencies.  The generic config code does not
    catch this case because the 64ms is considered a sane enough value.
    
    This change thus adds a USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL quirk
    to mark devices which actually report milliseconds in bInterval,
    and marks Vario Ultra devices as needing it.
    
    Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aacb73b7ae2f3aa5588de8d745fc59736a144cfa
Author: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Date:   Sun Feb 12 13:02:13 2017 -0200

    dvb-usb-firmware: don't do DMA on stack
    
    commit 67b0503db9c29b04eadfeede6bebbfe5ddad94ef upstream.
    
    The buffer allocation for the firmware data was changed in
    commit 43fab9793c1f ("[media] dvb-usb: don't use stack for firmware load")
    but the same applies for the reset value.
    
    Fixes: 43fab9793c1f ("[media] dvb-usb: don't use stack for firmware load")
    Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f1b221121b1651fa5939e6c99197e121d976fea7
Author: Roger Quadros <rogerq@ti.com>
Date:   Wed Mar 8 16:05:43 2017 +0200

    usb: gadget: f_uvc: Fix SuperSpeed companion descriptor's wBytesPerInterval
    
    commit 09424c50b7dff40cb30011c09114404a4656e023 upstream.
    
    The streaming_maxburst module parameter is 0 offset (0..15)
    so we must add 1 while using it for wBytesPerInterval
    calculation for the SuperSpeed companion descriptor.
    
    Without this host uvcvideo driver will always see the wrong
    wBytesPerInterval for SuperSpeed uvc gadget and may not find
    a suitable video interface endpoint.
    e.g. for streaming_maxburst = 0 case it will always
    fail as wBytePerInterval was evaluating to 0.
    
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Roger Quadros <rogerq@ti.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c37fcc17bf36a97b9cb065b4a6179e9cdf7f99ea
Author: Oliver Neukum <oneukum@suse.com>
Date:   Tue Mar 14 12:09:56 2017 +0100

    ACM gadget: fix endianness in notifications
    
    commit cdd7928df0d2efaa3270d711963773a08a4cc8ab upstream.
    
    The gadget code exports the bitfield for serial status changes
    over the wire in its internal endianness. The fix is to convert
    to little endian before sending it over the wire.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Tested-by: 家瑋 <momo1208@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7cdfdddb2e612a8b606f5682f3ba11d66e18ad6b
Author: Bjørn Mork <bjorn@mork.no>
Date:   Fri Mar 17 17:21:28 2017 +0100

    USB: serial: qcserial: add Dell DW5811e
    
    commit 436ecf5519d892397af133a79ccd38a17c25fa51 upstream.
    
    This is a Dell branded Sierra Wireless EM7455.
    
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b1849b029cc17096f1c10ef5f470e1b86187e102
Author: Dan Williams <dcbw@redhat.com>
Date:   Thu Mar 9 11:32:28 2017 -0600

    USB: serial: option: add Quectel UC15, UC20, EC21, and EC25 modems
    
    commit 6e9f44eaaef0df7b846e9316fa9ca72a02025d44 upstream.
    
    Add Quectel UC15, UC20, EC21, and EC25.  The EC20 is handled by
    qcserial due to a USB VID/PID conflict with an existing Acer
    device.
    
    Signed-off-by: Dan Williams <dcbw@redhat.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 37e91f5d0105ffc19efe9246201f51a972fc8369
Author: Hui Wang <hui.wang@canonical.com>
Date:   Thu Mar 23 10:00:25 2017 +0800

    ALSA: hda - Adding a group of pin definition to fix headset problem
    
    commit 3f307834e695f59dac4337a40316bdecfb9d0508 upstream.
    
    A new Dell laptop needs to apply ALC269_FIXUP_DELL1_MIC_NO_PRESENCE to
    fix the headset problem, and the pin definiton of this machine is not
    in the pin quirk table yet, now adding it to the table.
    
    Signed-off-by: Hui Wang <hui.wang@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0b7e15f1a165213321aa2afd7cccc489587bc27d
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Mar 20 10:08:19 2017 +0100

    ALSA: ctxfi: Fix the incorrect check of dma_set_mask() call
    
    commit f363a06642f28caaa78cb6446bbad90c73fe183c upstream.
    
    In the commit [15c75b09f8d1: ALSA: ctxfi: Fallback DMA mask to 32bit],
    I forgot to put "!" at dam_set_mask() call check in cthw20k1.c (while
    cthw20k2.c is OK).  This patch fixes that obvious bug.
    
    (As a side note: although the original commit was completely wrong,
     it's still working for most of machines, as it sets to 32bit DMA mask
     in the end.  So the bug severity is low.)
    
    Fixes: 15c75b09f8d1 ("ALSA: ctxfi: Fallback DMA mask to 32bit")
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4c381c7affcbd8622e68e5e3fc6be1cbc8e1c8bb
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Mar 21 13:56:04 2017 +0100

    ALSA: seq: Fix racy cell insertions during snd_seq_pool_done()
    
    commit c520ff3d03f0b5db7146d9beed6373ad5d2a5e0e upstream.
    
    When snd_seq_pool_done() is called, it marks the closing flag to
    refuse the further cell insertions.  But snd_seq_pool_done() itself
    doesn't clear the cells but just waits until all cells are cleared by
    the caller side.  That is, it's racy, and this leads to the endless
    stall as syzkaller spotted.
    
    This patch addresses the racy by splitting the setup of pool->closing
    flag out of snd_seq_pool_done(), and calling it properly before
    snd_seq_pool_done().
    
    BugLink: http://lkml.kernel.org/r/CACT4Y+aqqy8bZA1fFieifNxR2fAfFQQABcBHj801+u5ePV0URw@mail.gmail.com
    Reported-and-tested-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9ccad2dfe28c29f802fd5b0c3d63be6dca8afb87
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Mar 16 11:43:09 2017 -0700

    Input: sur40 - validate number of endpoints before using them
    
    commit 92461f5d723037530c1f36cce93640770037812c upstream.
    
    Make sure to check the number of endpoints to avoid dereferencing a
    NULL-pointer or accessing memory that lie beyond the end of the endpoint
    array should a malicious device lack the expected endpoints.
    
    Fixes: bdb5c57f209c ("Input: add sur40 driver for Samsung SUR40... ")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb50058c79702dc052eba5ea537145da30f57cf2
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Mar 16 11:41:55 2017 -0700

    Input: kbtab - validate number of endpoints before using them
    
    commit cb1b494663e037253337623bf1ef2df727883cb7 upstream.
    
    Make sure to check the number of endpoints to avoid dereferencing a
    NULL-pointer should a malicious device lack endpoints.
    
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 865b020ff2a1644ce5ef43022456a9dc14765477
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Mar 16 11:35:12 2017 -0700

    Input: cm109 - validate number of endpoints before using them
    
    commit ac2ee9ba953afe88f7a673e1c0c839227b1d7891 upstream.
    
    Make sure to check the number of endpoints to avoid dereferencing a
    NULL-pointer should a malicious device lack endpoints.
    
    Fixes: c04148f915e5 ("Input: add driver for USB VoIP phones with CM109...")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 69cbb678881a73920ccaae5d3c0b3bded31e5d23
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Mar 16 11:37:01 2017 -0700

    Input: yealink - validate number of endpoints before using them
    
    commit 5cc4a1a9f5c179795c8a1f2b0f4361829d6a070e upstream.
    
    Make sure to check the number of endpoints to avoid dereferencing a
    NULL-pointer should a malicious device lack endpoints.
    
    Fixes: aca951a22a1d ("[PATCH] input-driver-yealink-P1K-usb-phone")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e8861cb37fafd9a148d5fc020e04b06a515f45f9
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Mar 16 11:39:29 2017 -0700

    Input: hanwang - validate number of endpoints before using them
    
    commit ba340d7b83703768ce566f53f857543359aa1b98 upstream.
    
    Make sure to check the number of endpoints to avoid dereferencing a
    NULL-pointer should a malicious device lack endpoints.
    
    Fixes: bba5394ad3bd ("Input: add support for Hanwang tablets")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9318ae922a52aabdfba188fb4494a35633c3aa80
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Mar 16 11:36:13 2017 -0700

    Input: ims-pcu - validate number of endpoints before using them
    
    commit 1916d319271664241b7aa0cd2b05e32bdb310ce9 upstream.
    
    Make sure to check the number of endpoints to avoid dereferencing a
    NULL-pointer should a malicious device lack control-interface endpoints.
    
    Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed6a66dc2f7ac166e7bf99cfdda299994c427dba
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Mar 16 11:34:02 2017 -0700

    Input: iforce - validate number of endpoints before using them
    
    commit 59cf8bed44a79ec42303151dd014fdb6434254bb upstream.
    
    Make sure to check the number of endpoints to avoid dereferencing a
    NULL-pointer or accessing memory that lie beyond the end of the endpoint
    array should a malicious device lack the expected endpoints.
    
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b5157d07935b683c6d577542d1aab8fd213a7740
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Tue Mar 7 09:31:29 2017 -0800

    Input: i8042 - add noloop quirk for Dell Embedded Box PC 3000
    
    commit 45838660e34d90db8d4f7cbc8fd66e8aff79f4fe upstream.
    
    The aux port does not get detected without noloop quirk, so external PS/2
    mouse cannot work as result.
    
    The PS/2 mouse can work with this quirk.
    
    BugLink: https://bugs.launchpad.net/bugs/1591053
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Reviewed-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f1d4be3d754c6d07d97a53707bc4df7449b349fe
Author: Matjaz Hegedic <matjaz.hegedic@gmail.com>
Date:   Fri Mar 10 14:33:09 2017 -0800

    Input: elan_i2c - add ASUS EeeBook X205TA special touchpad fw
    
    commit 92ef6f97a66e580189a41a132d0f8a9f78d6ddce upstream.
    
    EeeBook X205TA is yet another ASUS device with a special touchpad
    firmware that needs to be accounted for during initialization, or
    else the touchpad will go into an invalid state upon suspend/resume.
    Adding the appropriate ic_type and product_id check fixes the problem.
    
    Signed-off-by: Matjaz Hegedic <matjaz.hegedic@gmail.com>
    Acked-by: KT Liao <kt.liao@emc.com.tw>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b87dd1d7dacc2f0d300fa6d5e3065948db3095fc
Author: Masaki Ota <masaki.ota@jp.alps.com>
Date:   Fri Mar 17 14:19:40 2017 -0700

    Input: ALPS - fix trackstick button handling on V8 devices
    
    commit 47e6fb4212d09f325c0847d05985dd3d71553095 upstream.
    
    Alps stick devices always have physical buttons, so we should not check
    ALPS_BUTTONPAD flag to decide whether we should report them.
    
    Fixes: 4777ac220c43 ("Input: ALPS - add touchstick support for SS5 hardware")
    Signed-off-by: Masaki Ota <masaki.ota@jp.alps.com>
    Acked-by: Pali Rohar <pali.rohar@gmail.com>
    Tested-by: Paul Donohue <linux-kernel@PaulSD.com>
    Tested-by: Nick Fletcher <nick.m.fletcher@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0186e6a4e501d39f5f90dd7e5887bc668aef06c4
Author: Masaki Ota <masaki.ota@jp.alps.com>
Date:   Fri Mar 17 14:10:57 2017 -0700

    Input: ALPS - fix V8+ protocol handling (73 03 28)
    
    commit e7348396c6d51b57c95c6646c390cd078e038e19 upstream.
    
    Devices identified as E7="73 03 28" use slightly modified version of V8
    protocol, with lower count per electrode, different offsets, and different
    feature bits in OTP data.
    
    Fixes: aeaa881f9b17 ("Input: ALPS - set DualPoint flag for 74 03 28 devices")
    Signed-off-by: Masaki Ota <masaki.ota@jp.alps.com>
    Acked-by: Pali Rohar <pali.rohar@gmail.com>
    Tested-by: Paul Donohue <linux-kernel@PaulSD.com>
    Tested-by: Nick Fletcher <nick.m.fletcher@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 00ca1a71292cbe666aa500567ae831c709a6c357
Author: Roderick Colenbrander <roderick.colenbrander@sony.com>
Date:   Fri Feb 24 16:14:15 2017 -0800

    HID: sony: Fix input device leak when connecting a DS4 twice using USB/BT
    
    commit a687c5765b5ae19fe559e14615ddc87ebb46d409 upstream.
    
    When a user connects a DS4 twice using USB and BT, we reject the
    second device connection after the setup work. We then perform
    a cleanup, but during cleanup we are not removing the touchpad
    device. This leads to leakage of an input device, which we would
    never remove. It can likely result into a kernel oops as well
    when the touchpad evdev node is accessed and the underlaying HID
    device has been removed from the system.
    
    [jkosina@suse.cz: added stable annotation]
    Fixes: ac797b95f532 ("HID: sony: Make the DS4 touchpad a separate device")
    Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
    Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit de93e41f77340c1b9cc6a0733add8b5aa526216a
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Mar 16 19:02:33 2017 -0700

    net: solve a NAPI race
    
    commit 39e6c8208d7b6fb9d2047850fb3327db567b564b upstream.
    
    While playing with mlx4 hardware timestamping of RX packets, I found
    that some packets were received by TCP stack with a ~200 ms delay...
    
    Since the timestamp was provided by the NIC, and my probe was added
    in tcp_v4_rcv() while in BH handler, I was confident it was not
    a sender issue, or a drop in the network.
    
    This would happen with a very low probability, but hurting RPC
    workloads.
    
    A NAPI driver normally arms the IRQ after the napi_complete_done(),
    after NAPI_STATE_SCHED is cleared, so that the hard irq handler can grab
    it.
    
    Problem is that if another point in the stack grabs NAPI_STATE_SCHED bit
    while IRQ are not disabled, we might have later an IRQ firing and
    finding this bit set, right before napi_complete_done() clears it.
    
    This can happen with busy polling users, or if gro_flush_timeout is
    used. But some other uses of napi_schedule() in drivers can cause this
    as well.
    
    thread 1                                 thread 2 (could be on same cpu, or not)
    
    // busy polling or napi_watchdog()
    napi_schedule();
    ...
    napi->poll()
    
    device polling:
    read 2 packets from ring buffer
                                              Additional 3rd packet is
    available.
                                              device hard irq
    
                                              // does nothing because
    NAPI_STATE_SCHED bit is owned by thread 1
                                              napi_schedule();
    
    napi_complete_done(napi, 2);
    rearm_irq();
    
    Note that rearm_irq() will not force the device to send an additional
    IRQ for the packet it already signaled (3rd packet in my example)
    
    This patch adds a new NAPI_STATE_MISSED bit, that napi_schedule_prep()
    can set if it could not grab NAPI_STATE_SCHED
    
    Then napi_complete_done() properly reschedules the napi to make sure
    we do not miss something.
    
    Since we manipulate multiple bits at once, use cmpxchg() like in
    sk_busy_loop() to provide proper transactions.
    
    In v2, I changed napi_watchdog() to use a relaxed variant of
    napi_schedule_prep() : No need to set NAPI_STATE_MISSED from this point.
    
    In v3, I added more details in the changelog and clears
    NAPI_STATE_MISSED in busy_poll_stop()
    
    In v4, I added the ideas given by Alexander Duyck in v3 review
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Alexander Duyck <alexander.duyck@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a1fd7338b43e92cc73ad03f4d4571e7815c8e95f
Author: Lendacky, Thomas <Thomas.Lendacky@amd.com>
Date:   Wed Mar 22 17:25:27 2017 -0500

    amd-xgbe: Fix the ECC-related bit position definitions
    
    [ Upstream commit f43feef4e6acde10857fcbfdede790d6b3f2c71d ]
    
    The ECC bit positions that describe whether the ECC interrupt is for
    Tx, Rx or descriptor memory and whether the it is a single correctable
    or double detected error were defined in incorrectly (reversed order).
    Fix the bit position definitions for these settings so that the proper
    ECC handling is performed.
    
    Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d3add547afd39289eeefc674755cd3014806916b
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Mar 22 08:10:21 2017 -0700

    tcp: initialize icsk_ack.lrcvtime at session start time
    
    [ Upstream commit 15bb7745e94a665caf42bfaabf0ce062845b533b ]
    
    icsk_ack.lrcvtime has a 0 value at socket creation time.
    
    tcpi_last_data_recv can have bogus value if no payload is ever received.
    
    This patch initializes icsk_ack.lrcvtime for active sessions
    in tcp_finish_connect(), and for passive sessions in
    tcp_create_openreq_child()
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a3639645a94b3b05e17ffd79115d2d709396543a
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Wed Mar 22 16:08:33 2017 +0100

    genetlink: fix counting regression on ctrl_dumpfamily()
    
    [ Upstream commit 1d2a6a5e4bf2921531071fcff8538623dce74efa ]
    
    Commit 2ae0f17df1cd ("genetlink: use idr to track families") replaced
    
            if (++n < fams_to_skip)
                    continue;
    into:
    
            if (n++ < fams_to_skip)
                    continue;
    
    This subtle change cause that on retry ctrl_dumpfamily() call we omit
    one family that failed to do ctrl_fill_info() on previous call, because
    cb->args[0] = n number counts also family that failed to do
    ctrl_fill_info().
    
    Patch fixes the problem and avoid confusion in the future just decrease
    n counter when ctrl_fill_info() fail.
    
    User visible problem caused by this bug is failure to get access to
    some genetlink family i.e. nl80211. However problem is reproducible
    only if number of registered genetlink families is big enough to
    cause second call of ctrl_dumpfamily().
    
    Cc: Xose Vazquez Perez <xose.vazquez@gmail.com>
    Cc: Larry Finger <Larry.Finger@lwfinger.net>
    Cc: Johannes Berg <johannes@sipsolutions.net>
    Fixes: 2ae0f17df1cd ("genetlink: use idr to track families")
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Acked-by: Johannes Berg <johannes@sipsolutions.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aaa31c62f737f7b09a27c5aa7f4627141744b1e8
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Wed Mar 22 13:08:08 2017 +0100

    socket, bpf: fix sk_filter use after free in sk_clone_lock
    
    [ Upstream commit a97e50cc4cb67e1e7bff56f6b41cda62ca832336 ]
    
    In sk_clone_lock(), we create a new socket and inherit most of the
    parent's members via sock_copy() which memcpy()'s various sections.
    Now, in case the parent socket had a BPF socket filter attached,
    then newsk->sk_filter points to the same instance as the original
    sk->sk_filter.
    
    sk_filter_charge() is then called on the newsk->sk_filter to take a
    reference and should that fail due to hitting max optmem, we bail
    out and release the newsk instance.
    
    The issue is that commit 278571baca2a ("net: filter: simplify socket
    charging") wrongly combined the dismantle path with the failure path
    of xfrm_sk_clone_policy(). This means, even when charging failed, we
    call sk_free_unlock_clone() on the newsk, which then still points to
    the same sk_filter as the original sk.
    
    Thus, sk_free_unlock_clone() calls into __sk_destruct() eventually
    where it tests for present sk_filter and calls sk_filter_uncharge()
    on it, which potentially lets sk_omem_alloc wrap around and releases
    the eBPF prog and sk_filter structure from the (still intact) parent.
    
    Fix it by making sure that when sk_filter_charge() failed, we reset
    newsk->sk_filter back to NULL before passing to sk_free_unlock_clone(),
    so that we don't mess with the parents sk_filter.
    
    Only if xfrm_sk_clone_policy() fails, we did reach the point where
    either the parent's filter was NULL and as a result newsk's as well
    or where we previously had a successful sk_filter_charge(), thus for
    that case, we do need sk_filter_uncharge() to release the prior taken
    reference on sk_filter.
    
    Fixes: 278571baca2a ("net: filter: simplify socket charging")
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1880e1308e9da2337b74b4241361ac54433ffd95
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Mar 21 19:22:28 2017 -0700

    ipv4: provide stronger user input validation in nl_fib_input()
    
    [ Upstream commit c64c0b3cac4c5b8cb093727d2c19743ea3965c0b ]
    
    Alexander reported a KMSAN splat caused by reads of uninitialized
    field (tb_id_in) from user provided struct fib_result_nl
    
    It turns out nl_fib_input() sanity tests on user input is a bit
    wrong :
    
    User can pretend nlh->nlmsg_len is big enough, but provide
    at sendmsg() time a too small buffer.
    
    Reported-by: Alexander Potapenko <glider@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 212508f709ab66f972481a681a29ca971d78692b
Author: Doug Berger <opendmb@gmail.com>
Date:   Tue Mar 21 14:01:06 2017 -0700

    net: bcmgenet: remove bcmgenet_internal_phy_setup()
    
    [ Upstream commit 31739eae738ccbe8b9d627c3f2251017ca03f4d2 ]
    
    Commit 6ac3ce8295e6 ("net: bcmgenet: Remove excessive PHY reset")
    removed the bcmgenet_mii_reset() function from bcmgenet_power_up() and
    bcmgenet_internal_phy_setup() functions.  In so doing it broke the reset
    of the internal PHY devices used by the GENETv1-GENETv3 which required
    this reset before the UniMAC was enabled.  It also broke the internal
    GPHY devices used by the GENETv4 because the config_init that installed
    the AFE workaround was no longer occurring after the reset of the GPHY
    performed by bcmgenet_phy_power_set() in bcmgenet_internal_phy_setup().
    In addition the code in bcmgenet_internal_phy_setup() related to the
    "enable APD" comment goes with the bcmgenet_mii_reset() so it should
    have also been removed.
    
    Commit bd4060a6108b ("net: bcmgenet: Power on integrated GPHY in
    bcmgenet_power_up()") moved the bcmgenet_phy_power_set() call to the
    bcmgenet_power_up() function, but failed to remove it from the
    bcmgenet_internal_phy_setup() function.  Had it done so, the
    bcmgenet_internal_phy_setup() function would have been empty and could
    have been removed at that time.
    
    Commit 5dbebbb44a6a ("net: bcmgenet: Software reset EPHY after power on")
    was submitted to correct the functional problems introduced by
    commit 6ac3ce8295e6 ("net: bcmgenet: Remove excessive PHY reset"). It
    was included in v4.4 and made available on 4.3-stable. Unfortunately,
    it didn't fully revert the commit because this bcmgenet_mii_reset()
    doesn't apply the soft reset to the internal GPHY used by GENETv4 like
    the previous one did. This prevents the restoration of the AFE work-
    arounds for internal GPHY devices after the bcmgenet_phy_power_set() in
    bcmgenet_internal_phy_setup().
    
    This commit takes the alternate approach of removing the unnecessary
    bcmgenet_internal_phy_setup() function which shouldn't have been in v4.3
    so that when bcmgenet_mii_reset() was restored it should have only gone
    into bcmgenet_power_up().  This will avoid the problems while also
    removing the redundancy (and hopefully some of the confusion).
    
    Fixes: 6ac3ce8295e6 ("net: bcmgenet: Remove excessive PHY reset")
    Signed-off-by: Doug Berger <opendmb@gmail.com>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 30b72691dbca4828f9abffd79aae3b39f31aa186
Author: Alexander Potapenko <glider@google.com>
Date:   Tue Mar 21 17:14:27 2017 +0100

    ipv6: make sure to initialize sockc.tsflags before first use
    
    [ Upstream commit d515684d78148884d5fc425ba904c50f03844020 ]
    
    In the case udp_sk(sk)->pending is AF_INET6, udpv6_sendmsg() would
    jump to do_append_data, skipping the initialization of sockc.tsflags.
    Fix the problem by moving sockc.tsflags initialization earlier.
    
    The bug was detected with KMSAN.
    
    Fixes: c14ac9451c34 ("sock: enable timestamping using control messages")
    Signed-off-by: Alexander Potapenko <glider@google.com>
    Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4162e85c7134627179e25ece5f401e1f7e1b604c
Author: Gal Pressman <galp@mellanox.com>
Date:   Tue Mar 21 15:59:19 2017 +0200

    net/mlx5e: Count LRO packets correctly
    
    [ Upstream commit 8ab7e2ae15d84ba758b2c8c6f4075722e9bd2a08 ]
    
    RX packets statistics ('rx_packets' counter) used to count LRO packets
    as one, even though it contains multiple segments.
    This patch will increment the counter by the number of segments, and
    align the driver with the behavior of other drivers in the stack.
    
    Note that no information is lost in this patch due to 'rx_lro_packets'
    counter existence.
    
    Before, ethtool showed:
    $ ethtool -S ens6 | egrep "rx_packets|rx_lro_packets"
         rx_packets: 435277
         rx_lro_packets: 35847
         rx_packets_phy: 1935066
    
    Now, we will see the more logical statistics:
    $ ethtool -S ens6 | egrep "rx_packets|rx_lro_packets"
         rx_packets: 1935066
         rx_lro_packets: 35847
         rx_packets_phy: 1935066
    
    Fixes: e586b3b0baee ("net/mlx5: Ethernet Datapath files")
    Signed-off-by: Gal Pressman <galp@mellanox.com>
    Cc: kernel-team@fb.com
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Acked-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ec387a74cdc440c9f7f78d1286451bf313e77f2
Author: Gal Pressman <galp@mellanox.com>
Date:   Tue Mar 21 15:59:18 2017 +0200

    net/mlx5e: Count GSO packets correctly
    
    [ Upstream commit d3a4e4da54c7adb420d5f48e89be913b14bdeff1 ]
    
    TX packets statistics ('tx_packets' counter) used to count GSO packets
    as one, even though it contains multiple segments.
    This patch will increment the counter by the number of segments, and
    align the driver with the behavior of other drivers in the stack.
    
    Note that no information is lost in this patch due to 'tx_tso_packets'
    counter existence.
    
    Before, ethtool showed:
    $ ethtool -S ens6 | egrep "tx_packets|tx_tso_packets"
         tx_packets: 61340
         tx_tso_packets: 60954
         tx_packets_phy: 2451115
    
    Now, we will see the more logical statistics:
    $ ethtool -S ens6 | egrep "tx_packets|tx_tso_packets"
         tx_packets: 2451115
         tx_tso_packets: 60954
         tx_packets_phy: 2451115
    
    Fixes: e586b3b0baee ("net/mlx5: Ethernet Datapath files")
    Signed-off-by: Gal Pressman <galp@mellanox.com>
    Cc: kernel-team@fb.com
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Acked-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 345aad1f460293baf48c845d02f28429fa317d54
Author: Maor Gottlieb <maorg@mellanox.com>
Date:   Tue Mar 21 15:59:17 2017 +0200

    net/mlx5: Increase number of max QPs in default profile
    
    [ Upstream commit 5f40b4ed975c26016cf41953b7510fe90718e21c ]
    
    With ConnectX-4 sharing SRQs from the same space as QPs, we hit a
    limit preventing some applications to allocate needed QPs amount.
    Double the size to 256K.
    
    Fixes: e126ba97dba9e ('mlx5: Add driver for Mellanox Connect-IB adapters')
    Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 458034b72f35ffc27d87ae1c9cf628028abcb079
Author: Paul Blakey <paulb@mellanox.com>
Date:   Tue Mar 21 15:59:16 2017 +0200

    net/mlx5e: Avoid supporting udp tunnel port ndo for VF reps
    
    [ Upstream commit 1ad9a00ae0efc2e9337148d6c382fad3d27bf99a ]
    
    This was added to allow the TC offloading code to identify offloading
    encap/decap vxlan rules.
    
    The VF reps are effectively related to the same mlx5 PCI device as the
    PF. Since the kernel invokes the (say) delete ndo for each netdev, the
    FW erred on multiple vxlan dst port deletes when the port was deleted
    from the system.
    
    We fix that by keeping the registration to be carried out only by the
    PF. Since the PF serves as the uplink device, the VF reps will look
    up a port there and realize if they are ok to offload that.
    
    Tested:
     <SETUP VFS>
     <SETUP switchdev mode to have representors>
     ip link add vxlan1 type vxlan id 44 dev ens5f0 dstport 9999
     ip link set vxlan1 up
     ip link del dev vxlan1
    
    Fixes: 4a25730eb202 ('net/mlx5e: Add ndo_udp_tunnel_add to VF representors')
    Signed-off-by: Paul Blakey <paulb@mellanox.com>
    Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit daa6e01308ad32ba2ffee6685389c4750aff56ed
Author: Or Gerlitz <ogerlitz@mellanox.com>
Date:   Tue Mar 21 15:59:15 2017 +0200

    net/mlx5e: Use the proper UAPI values when offloading TC vlan actions
    
    [ Upstream commit 09c91ddf2cd33489c2c14edfef43ae38d412888e ]
    
    Currently we use the non UAPI values and we miss erring on
    the modify action which is not supported, fix that.
    
    Fixes: 8b32580df1cb ('net/mlx5e: Add TC vlan action for SRIOV offloads')
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Reported-by: Petr Machata <petrm@mellanox.com>
    Reviewed-by: Jiri Pirko <jiri@mellanox.com>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b709b83ea5ece6ec5c6d2e4a2be6a5035d5af4eb
Author: Roi Dayan <roid@mellanox.com>
Date:   Tue Mar 21 15:59:14 2017 +0200

    net/mlx5: E-Switch, Don't allow changing inline mode when flows are configured
    
    [ Upstream commit 375f51e2b5b7b9a42b3139aea519cbb1bfc5d6ef ]
    
    Changing the eswitch inline mode can potentially cause already configured
    flows not to match the policy. E.g. set policy L4, add some L4 rules,
    set policy to L2 --> bad! Hence we disallow it.
    
    Keep track of how many offloaded rules are now set and refuse
    inline mode changes if this isn't zero.
    
    Fixes: bffaa916588e ("net/mlx5: E-Switch, Add control for inline mode")
    Signed-off-by: Roi Dayan <roid@mellanox.com>
    Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 402073e7e39adceef109d337353a3bdb6cc9b22f
Author: Or Gerlitz <ogerlitz@mellanox.com>
Date:   Tue Mar 21 15:59:13 2017 +0200

    net/mlx5e: Change the TC offload rule add/del code path to be per NIC or E-Switch
    
    [ Upstream commit d85cdccbb3fe9a632ec9d0f4e4526c8c84fc3523 ]
    
    Refactor the code to deal with add/del TC rules to have handler per NIC/E-switch
    offloading use case, and push the latter into the e-switch code. This provides
    better separation and is to be used in down-stream patch for applying a fix.
    
    Fixes: bffaa916588e ("net/mlx5: E-Switch, Add control for inline mode")
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Reviewed-by: Roi Dayan <roid@mellanox.com>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5e96d44bbdd406bbaf49492a6ec537ebb0e7eba5
Author: Or Gerlitz <ogerlitz@mellanox.com>
Date:   Tue Mar 21 15:59:12 2017 +0200

    net/mlx5: Add missing entries for set/query rate limit commands
    
    [ Upstream commit 1f30a86c58093046dc3e49c23d2618894e098f7a ]
    
    The switch cases for the rate limit set and query commands were
    missing, which could get us wrong under fw error or driver reset
    flow, fix that.
    
    Fixes: 1466cc5b23d1 ('net/mlx5: Rate limit tables support')
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Reviewed-by: Hadar Hen Zion <hadarh@mellanox.com>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eccc68710effc0c062bd57c5399c404bb2c9ac5e
Author: David Ahern <dsa@cumulusnetworks.com>
Date:   Fri Mar 17 16:07:11 2017 -0700

    net: vrf: Reset rt6i_idev in local dst after put
    
    [ Upstream commit 3dc857f0e8fc22610a59cbb346ba62c6e921863f ]
    
    The VRF driver takes a reference to the inet6_dev on the VRF device for
    its rt6_local dst when handling local traffic through the VRF device as
    a loopback. When the device is deleted the driver does a put on the idev
    but does not reset rt6i_idev in the rt6_info struct. When the dst is
    destroyed, dst_destroy calls ip6_dst_destroy which does a second put for
    what is essentially the same reference causing it to be prematurely freed.
    Reset rt6i_idev after the put in the vrf driver.
    
    Fixes: b4869aa2f881e ("net: vrf: ipv6 support for local traffic to
                           local addresses")
    Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 29323e2def4860b20e32e6a8229836d875eb3597
Author: Bjørn Mork <bjorn@mork.no>
Date:   Fri Mar 17 17:20:48 2017 +0100

    qmi_wwan: add Dell DW5811e
    
    [ Upstream commit 6bd845d1cf98b45c634baacb8381436dad3c2dd0 ]
    
    This is a Dell branded Sierra Wireless EM7455. It is operating in
    MBIM mode by default, but can be configured to provide two QMI/RMNET
    functions.
    
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4f320b855b8ab045b196cdbee0bde391ef66bae6
Author: Andrey Ulanov <andreyu@google.com>
Date:   Tue Mar 14 20:16:42 2017 -0700

    net: unix: properly re-increment inflight counter of GC discarded candidates
    
    [ Upstream commit 7df9c24625b9981779afb8fcdbe2bb4765e61147 ]
    
    Dmitry has reported that a BUG_ON() condition in unix_notinflight()
    may be triggered by a simple code that forwards unix socket in an
    SCM_RIGHTS message.
    That is caused by incorrect unix socket GC implementation in unix_gc().
    
    The GC first collects list of candidates, then (a) decrements their
    "children's" inflight counter, (b) checks which inflight counters are
    now 0, and then (c) increments all inflight counters back.
    (a) and (c) are done by calling scan_children() with inc_inflight or
    dec_inflight as the second argument.
    
    Commit 6209344f5a37 ("net: unix: fix inflight counting bug in garbage
    collector") changed scan_children() such that it no longer considers
    sockets that do not have UNIX_GC_CANDIDATE flag. It also added a block
    of code that that unsets this flag _before_ invoking
    scan_children(, dec_iflight, ). This may lead to incorrect inflight
    counters for some sockets.
    
    This change fixes this bug by changing order of operations:
    UNIX_GC_CANDIDATE is now unset only after all inflight counters are
    restored to the original state.
    
      kernel BUG at net/unix/garbage.c:149!
      RIP: 0010:[<ffffffff8717ebf4>]  [<ffffffff8717ebf4>]
      unix_notinflight+0x3b4/0x490 net/unix/garbage.c:149
      Call Trace:
       [<ffffffff8716cfbf>] unix_detach_fds.isra.19+0xff/0x170 net/unix/af_unix.c:1487
       [<ffffffff8716f6a9>] unix_destruct_scm+0xf9/0x210 net/unix/af_unix.c:1496
       [<ffffffff86a90a01>] skb_release_head_state+0x101/0x200 net/core/skbuff.c:655
       [<ffffffff86a9808a>] skb_release_all+0x1a/0x60 net/core/skbuff.c:668
       [<ffffffff86a980ea>] __kfree_skb+0x1a/0x30 net/core/skbuff.c:684
       [<ffffffff86a98284>] kfree_skb+0x184/0x570 net/core/skbuff.c:705
       [<ffffffff871789d5>] unix_release_sock+0x5b5/0xbd0 net/unix/af_unix.c:559
       [<ffffffff87179039>] unix_release+0x49/0x90 net/unix/af_unix.c:836
       [<ffffffff86a694b2>] sock_release+0x92/0x1f0 net/socket.c:570
       [<ffffffff86a6962b>] sock_close+0x1b/0x20 net/socket.c:1017
       [<ffffffff81a76b8e>] __fput+0x34e/0x910 fs/file_table.c:208
       [<ffffffff81a771da>] ____fput+0x1a/0x20 fs/file_table.c:244
       [<ffffffff81483ab0>] task_work_run+0x1a0/0x280 kernel/task_work.c:116
       [<     inline     >] exit_task_work include/linux/task_work.h:21
       [<ffffffff8141287a>] do_exit+0x183a/0x2640 kernel/exit.c:828
       [<ffffffff8141383e>] do_group_exit+0x14e/0x420 kernel/exit.c:931
       [<ffffffff814429d3>] get_signal+0x663/0x1880 kernel/signal.c:2307
       [<ffffffff81239b45>] do_signal+0xc5/0x2190 arch/x86/kernel/signal.c:807
       [<ffffffff8100666a>] exit_to_usermode_loop+0x1ea/0x2d0
      arch/x86/entry/common.c:156
       [<     inline     >] prepare_exit_to_usermode arch/x86/entry/common.c:190
       [<ffffffff81009693>] syscall_return_slowpath+0x4d3/0x570
      arch/x86/entry/common.c:259
       [<ffffffff881478e6>] entry_SYSCALL_64_fastpath+0xc4/0xc6
    
    Link: https://lkml.org/lkml/2017/3/6/252
    Signed-off-by: Andrey Ulanov <andreyu@google.com>
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Fixes: 6209344 ("net: unix: fix inflight counting bug in garbage collector")
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d965848569f9c6cbba2df610adb8de80ae65b7cc
Author: Kris Murphy <kriskend@linux.vnet.ibm.com>
Date:   Thu Mar 16 10:51:28 2017 -0500

    openvswitch: Add missing case OVS_TUNNEL_KEY_ATTR_PAD
    
    [ Upstream commit 8f3dbfd79ed9ef9770305a7cc4e13dfd31ad2cd0 ]
    
    Added a case for OVS_TUNNEL_KEY_ATTR_PAD to the switch statement
    in ip_tun_from_nlattr in order to prevent the default case
    returning an error.
    
    Fixes: b46f6ded906e ("libnl: nla_put_be64(): align on a 64-bit area")
    Signed-off-by: Kris Murphy <kriskend@linux.vnet.ibm.com>
    Acked-by: Joe Stringer <joe@ovn.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ae9d577f3dbb686862b7d0dc9cc73054f0964d4d
Author: Lendacky, Thomas <Thomas.Lendacky@amd.com>
Date:   Wed Mar 15 15:11:23 2017 -0500

    amd-xgbe: Fix jumbo MTU processing on newer hardware
    
    [ Upstream commit 622c36f143fc9566ba49d7cec994c2da1182d9e2 ]
    
    Newer hardware does not provide a cumulative payload length when multiple
    descriptors are needed to handle the data. Once the MTU increases beyond
    the size that can be handled by a single descriptor, the SKB does not get
    built properly by the driver.
    
    The driver will now calculate the size of the data buffers used by the
    hardware.  The first buffer of the first descriptor is for packet headers
    or packet headers and data when the headers can't be split. Subsequent
    descriptors in a multi-descriptor chain will not use the first buffer. The
    second buffer is used by all the descriptors in the chain for payload data.
    Based on whether the driver is processing the first, intermediate, or last
    descriptor it can calculate the buffer usage and build the SKB properly.
    
    Tested and verified on both old and new hardware.
    
    Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5dd697af3014b800525607342d1b17b2f0398605
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Mar 15 13:21:28 2017 -0700

    net: properly release sk_frag.page
    
    [ Upstream commit 22a0e18eac7a9e986fec76c60fa4a2926d1291e2 ]
    
    I mistakenly added the code to release sk->sk_frag in
    sk_common_release() instead of sk_destruct()
    
    TCP sockets using sk->sk_allocation == GFP_ATOMIC do no call
    sk_common_release() at close time, thus leaking one (order-3) page.
    
    iSCSI is using such sockets.
    
    Fixes: 5640f7685831 ("net: use a per task frag allocator")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 200caa0be5d238a0024031c543db6a7379126c26
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Wed Mar 15 12:57:21 2017 -0700

    net: bcmgenet: Do not suspend PHY if Wake-on-LAN is enabled
    
    [ Upstream commit 5371bbf4b295eea334ed453efa286afa2c3ccff3 ]
    
    Suspending the PHY would be putting it in a low power state where it
    may no longer allow us to do Wake-on-LAN.
    
    Fixes: cc013fb48898 ("net: bcmgenet: correctly suspend and resume PHY device")
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c9f2c656aca1478d1bd57bc384347882a5cf263
Author: Or Gerlitz <ogerlitz@mellanox.com>
Date:   Wed Mar 15 18:10:47 2017 +0200

    net/openvswitch: Set the ipv6 source tunnel key address attribute correctly
    
    [ Upstream commit 3d20f1f7bd575d147ffa75621fa560eea0aec690 ]
    
    When dealing with ipv6 source tunnel key address attribute
    (OVS_TUNNEL_KEY_ATTR_IPV6_SRC) we are wrongly setting the tunnel
    dst ip, fix that.
    
    Fixes: 6b26ba3a7d95 ('openvswitch: netlink attributes for IPv6 tunneling')
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Reported-by: Paul Blakey <paulb@mellanox.com>
    Acked-by: Jiri Benc <jbenc@redhat.com>
    Acked-by: Joe Stringer <joe@ovn.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>