commit e419281295bfb1e51133b702c0d5166268e62e89
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Mar 3 15:09:05 2016 -0800

    Linux 3.14.63

commit 52a2780a444e156215c0db69472934c6c2dede53
Author: Oren Givon <oren.givon@intel.com>
Date:   Thu Dec 17 14:17:00 2015 +0200

    iwlwifi: update and fix 7265 series PCI IDs
    
    commit 006bda75d81fd27a583a3b310e9444fea2aa6ef2 upstream.
    
    Update and fix some 7265 PCI IDs entries.
    
    Signed-off-by: Oren Givon <oren.givon@intel.com>
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 08b706179843ff538c51bf11a04b893f149b6247
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Thu Feb 11 16:10:26 2016 -0500

    xen/pcifront: Fix mysterious crashes when NUMA locality information was extracted.
    
    commit 4d8c8bd6f2062c9988817183a91fe2e623c8aa5e upstream.
    
    Occasionaly PV guests would crash with:
    
    pciback 0000:00:00.1: Xen PCI mapped GSI0 to IRQ16
    BUG: unable to handle kernel paging request at 0000000d1a8c0be0
    .. snip..
      <ffffffff8139ce1b>] find_next_bit+0xb/0x10
      [<ffffffff81387f22>] cpumask_next_and+0x22/0x40
      [<ffffffff813c1ef8>] pci_device_probe+0xb8/0x120
      [<ffffffff81529097>] ? driver_sysfs_add+0x77/0xa0
      [<ffffffff815293e4>] driver_probe_device+0x1a4/0x2d0
      [<ffffffff813c1ddd>] ? pci_match_device+0xdd/0x110
      [<ffffffff81529657>] __device_attach_driver+0xa7/0xb0
      [<ffffffff815295b0>] ? __driver_attach+0xa0/0xa0
      [<ffffffff81527622>] bus_for_each_drv+0x62/0x90
      [<ffffffff8152978d>] __device_attach+0xbd/0x110
      [<ffffffff815297fb>] device_attach+0xb/0x10
      [<ffffffff813b75ac>] pci_bus_add_device+0x3c/0x70
      [<ffffffff813b7618>] pci_bus_add_devices+0x38/0x80
      [<ffffffff813dc34e>] pcifront_scan_root+0x13e/0x1a0
      [<ffffffff817a0692>] pcifront_backend_changed+0x262/0x60b
      [<ffffffff814644c6>] ? xenbus_gather+0xd6/0x160
      [<ffffffff8120900f>] ? put_object+0x2f/0x50
      [<ffffffff81465c1d>] xenbus_otherend_changed+0x9d/0xa0
      [<ffffffff814678ee>] backend_changed+0xe/0x10
      [<ffffffff81463a28>] xenwatch_thread+0xc8/0x190
      [<ffffffff810f22f0>] ? woken_wake_function+0x10/0x10
    
    which was the result of two things:
    
    When we call pci_scan_root_bus we would pass in 'sd' (sysdata)
    pointer which was an 'pcifront_sd' structure. However in the
    pci_device_add it expects that the 'sd' is 'struct sysdata' and
    sets the dev->node to what is in sd->node (offset 4):
    
    set_dev_node(&dev->dev, pcibus_to_node(bus));
    
     __pcibus_to_node(const struct pci_bus *bus)
    {
            const struct pci_sysdata *sd = bus->sysdata;
    
            return sd->node;
    }
    
    However our structure was pcifront_sd which had nothing at that
    offset:
    
    struct pcifront_sd {
            int                        domain;    /*     0     4 */
            /* XXX 4 bytes hole, try to pack */
            struct pcifront_device *   pdev;      /*     8     8 */
    }
    
    That is an hole - filled with garbage as we used kmalloc instead of
    kzalloc (the second problem).
    
    This patch fixes the issue by:
     1) Use kzalloc to initialize to a well known state.
     2) Put 'struct pci_sysdata' at the start of 'pcifront_sd'. That
        way access to the 'node' will access the right offset.
    
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 478ee5e09bbd59e219cc6d281c84e9495f006ab8
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sat Feb 27 19:17:33 2016 -0500

    do_last(): don't let a bogus return value from ->open() et.al. to confuse us
    
    commit c80567c82ae4814a41287618e315a60ecf513be6 upstream.
    
    ... into returning a positive to path_openat(), which would interpret that
    as "symlink had been encountered" and proceed to corrupt memory, etc.
    It can only happen due to a bug in some ->open() instance or in some LSM
    hook, etc., so we report any such event *and* make sure it doesn't trick
    us into further unpleasantness.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cda49c04f6cdccca0f2db13f740e707d592ef114
Author: Simon Guinot <simon.guinot@sequanux.org>
Date:   Thu Sep 10 00:15:18 2015 +0200

    kernel/resource.c: fix muxed resource handling in __request_region()
    
    commit 59ceeaaf355fa0fb16558ef7c24413c804932ada upstream.
    
    In __request_region, if a conflict with a BUSY and MUXED resource is
    detected, then the caller goes to sleep and waits for the resource to be
    released.  A pointer on the conflicting resource is kept.  At wake-up
    this pointer is used as a parent to retry to request the region.
    
    A first problem is that this pointer might well be invalid (if for
    example the conflicting resource have already been freed).  Another
    problem is that the next call to __request_region() fails to detect a
    remaining conflict.  The previously conflicting resource is passed as a
    parameter and __request_region() will look for a conflict among the
    children of this resource and not at the resource itself.  It is likely
    to succeed anyway, even if there is still a conflict.
    
    Instead, the parent of the conflicting resource should be passed to
    __request_region().
    
    As a fix, this patch doesn't update the parent resource pointer in the
    case we have to wait for a muxed region right after.
    
    Reported-and-tested-by: Vincent Pelletier <plr.vincent@gmail.com>
    Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
    Tested-by: Vincent Donnefort <vdonnefort@gmail.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0fbc074e6ff1393c43245bae78bd367173be4903
Author: Stefan Hajnoczi <stefanha@redhat.com>
Date:   Thu Feb 18 18:55:54 2016 +0000

    sunrpc/cache: fix off-by-one in qword_get()
    
    commit b7052cd7bcf3c1478796e93e3dff2b44c9e82943 upstream.
    
    The qword_get() function NUL-terminates its output buffer.  If the input
    string is in hex format \xXXXX... and the same length as the output
    buffer, there is an off-by-one:
    
      int qword_get(char **bpp, char *dest, int bufsize)
      {
          ...
          while (len < bufsize) {
              ...
              *dest++ = (h << 4) | l;
              len++;
          }
          ...
          *dest = '\0';
          return len;
      }
    
    This patch ensures the NUL terminator doesn't fall outside the output
    buffer.
    
    Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 68d3584b90b4388de64607bb1d35fce2293ce334
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Wed Feb 24 09:04:24 2016 -0500

    tracing: Fix showing function event in available_events
    
    commit d045437a169f899dfb0f6f7ede24cc042543ced9 upstream.
    
    The ftrace:function event is only displayed for parsing the function tracer
    data. It is not used to enable function tracing, and does not include an
    "enable" file in its event directory.
    
    Originally, this event was kept separate from other events because it did
    not have a ->reg parameter. But perf added a "reg" parameter for its use
    which caused issues, because it made the event available to functions where
    it was not compatible for.
    
    Commit 9b63776fa3ca9 "tracing: Do not enable function event with enable"
    added a TRACE_EVENT_FL_IGNORE_ENABLE flag that prevented the function event
    from being enabled by normal trace events. But this commit missed keeping
    the function event from being displayed by the "available_events" directory,
    which is used to show what events can be enabled by set_event.
    
    One documented way to enable all events is to:
    
     cat available_events > set_event
    
    But because the function event is displayed in the available_events, this
    now causes an INVALID error:
    
     cat: write error: Invalid argument
    
    Reported-by: Chunyu Hu <chuhu@redhat.com>
    Fixes: 9b63776fa3ca9 "tracing: Do not enable function event with enable"
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b8cf39c1b9d05b3ce67f494ea18f6c9f7f56443a
Author: Christian Borntraeger <borntraeger@de.ibm.com>
Date:   Fri Feb 19 13:11:46 2016 +0100

    KVM: async_pf: do not warn on page allocation failures
    
    commit d7444794a02ff655eda87e3cc54e86b940e7736f upstream.
    
    In async_pf we try to allocate with NOWAIT to get an element quickly
    or fail. This code also handle failures gracefully. Lets silence
    potential page allocation failures under load.
    
    qemu-system-s39: page allocation failure: order:0,mode:0x2200000
    [...]
    Call Trace:
    ([<00000000001146b8>] show_trace+0xf8/0x148)
    [<000000000011476a>] show_stack+0x62/0xe8
    [<00000000004a36b8>] dump_stack+0x70/0x98
    [<0000000000272c3a>] warn_alloc_failed+0xd2/0x148
    [<000000000027709e>] __alloc_pages_nodemask+0x94e/0xb38
    [<00000000002cd36a>] new_slab+0x382/0x400
    [<00000000002cf7ac>] ___slab_alloc.constprop.30+0x2dc/0x378
    [<00000000002d03d0>] kmem_cache_alloc+0x160/0x1d0
    [<0000000000133db4>] kvm_setup_async_pf+0x6c/0x198
    [<000000000013dee8>] kvm_arch_vcpu_ioctl_run+0xd48/0xd58
    [<000000000012fcaa>] kvm_vcpu_ioctl+0x372/0x690
    [<00000000002f66f6>] do_vfs_ioctl+0x3be/0x510
    [<00000000002f68ec>] SyS_ioctl+0xa4/0xb8
    [<0000000000781c5e>] system_call+0xd6/0x264
    [<000003ffa24fa06a>] 0x3ffa24fa06a
    
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Reviewed-by: Dominik Dingel <dingel@linux.vnet.ibm.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d4db460720392ee6cb687db260417c85fd8c7fc4
Author: Benjamin Coddington <bcodding@redhat.com>
Date:   Wed Feb 17 10:41:41 2016 -0500

    NFSv4: Fix a dentry leak on alias use
    
    commit d9dfd8d741683347ee159d25f5b50c346a0df557 upstream.
    
    In the case where d_add_unique() finds an appropriate alias to use it will
    have already incremented the reference count.  An additional dget() to swap
    the open context's dentry is unnecessary and will leak a reference.
    
    Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
    Fixes: 275bb307865a3 ("NFSv4: Move dentry instantiation into the NFSv4-...")
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ebbc1058f6efbd635e6c7c19cba5db1ad3acfcda
Author: Christoph Hellwig <hch@lst.de>
Date:   Mon Feb 8 21:11:50 2016 +0100

    nfs: fix nfs_size_to_loff_t
    
    commit 50ab8ec74a153eb30db26529088bc57dd700b24c upstream.
    
    See http: //www.infradead.org/rpr.html
    X-Evolution-Source: 1451162204.2173.11@leira.trondhjem.org
    Content-Transfer-Encoding: 8bit
    Mime-Version: 1.0
    
    We support OFFSET_MAX just fine, so don't round down below it.  Also
    switch to using min_t to make the helper more readable.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Fixes: 433c92379d9c ("NFS: Clean up nfs_size_to_loff_t()")
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4606a229c2f2b44223faa13b192165ba545ee2a9
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Mon Jan 25 10:08:00 2016 -0600

    PCI/AER: Flush workqueue on device remove to avoid use-after-free
    
    commit 4ae2182b1e3407de369f8c5d799543b7db74221b upstream.
    
    A Root Port's AER structure (rpc) contains a queue of events.  aer_irq()
    enqueues AER status information and schedules aer_isr() to dequeue and
    process it.  When we remove a device, aer_remove() waits for the queue to
    be empty, then frees the rpc struct.
    
    But aer_isr() references the rpc struct after dequeueing and possibly
    emptying the queue, which can cause a use-after-free error as in the
    following scenario with two threads, aer_isr() on the left and a
    concurrent aer_remove() on the right:
    
      Thread A                      Thread B
      --------                      --------
      aer_irq():
        rpc->prod_idx++
                                    aer_remove():
                                      wait_event(rpc->prod_idx == rpc->cons_idx)
                                      # now blocked until queue becomes empty
      aer_isr():                      # ...
        rpc->cons_idx++               # unblocked because queue is now empty
        ...                           kfree(rpc)
        mutex_unlock(&rpc->rpc_mutex)
    
    To prevent this problem, use flush_work() to wait until the last scheduled
    instance of aer_isr() has completed before freeing the rpc struct in
    aer_remove().
    
    I reproduced this use-after-free by flashing a device FPGA and
    re-enumerating the bus to find the new device.  With SLUB debug, this
    crashes with 0x6b bytes (POISON_FREE, the use-after-free magic number) in
    GPR25:
    
      pcieport 0000:00:00.0: AER: Multiple Corrected error received: id=0000
      Unable to handle kernel paging request for data at address 0x27ef9e3e
      Workqueue: events aer_isr
      GPR24: dd6aa000 6b6b6b6b 605f8378 605f8360 d99b12c0 604fc674 606b1704 d99b12c0
      NIP [602f5328] pci_walk_bus+0xd4/0x104
    
    [bhelgaas: changelog, stable tag]
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 44b75c2a479c39b42aaeb95d97ca605924aeec8a
Author: Tejun Heo <tj@kernel.org>
Date:   Mon Feb 1 11:33:21 2016 -0500

    libata: fix sff host state machine locking while polling
    
    commit 8eee1d3ed5b6fc8e14389567c9a6f53f82bb7224 upstream.
    
    The bulk of ATA host state machine is implemented by
    ata_sff_hsm_move().  The function is called from either the interrupt
    handler or, if polling, a work item.  Unlike from the interrupt path,
    the polling path calls the function without holding the host lock and
    ata_sff_hsm_move() selectively grabs the lock.
    
    This is completely broken.  If an IRQ triggers while polling is in
    progress, the two can easily race and end up accessing the hardware
    and updating state machine state at the same time.  This can put the
    state machine in an illegal state and lead to a crash like the
    following.
    
      kernel BUG at drivers/ata/libata-sff.c:1302!
      invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
      Modules linked in:
      CPU: 1 PID: 10679 Comm: syz-executor Not tainted 4.5.0-rc1+ #300
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
      task: ffff88002bd00000 ti: ffff88002e048000 task.ti: ffff88002e048000
      RIP: 0010:[<ffffffff83a83409>]  [<ffffffff83a83409>] ata_sff_hsm_move+0x619/0x1c60
      ...
      Call Trace:
       <IRQ>
       [<ffffffff83a84c31>] __ata_sff_port_intr+0x1e1/0x3a0 drivers/ata/libata-sff.c:1584
       [<ffffffff83a85611>] ata_bmdma_port_intr+0x71/0x400 drivers/ata/libata-sff.c:2877
       [<     inline     >] __ata_sff_interrupt drivers/ata/libata-sff.c:1629
       [<ffffffff83a85bf3>] ata_bmdma_interrupt+0x253/0x580 drivers/ata/libata-sff.c:2902
       [<ffffffff81479f98>] handle_irq_event_percpu+0x108/0x7e0 kernel/irq/handle.c:157
       [<ffffffff8147a717>] handle_irq_event+0xa7/0x140 kernel/irq/handle.c:205
       [<ffffffff81484573>] handle_edge_irq+0x1e3/0x8d0 kernel/irq/chip.c:623
       [<     inline     >] generic_handle_irq_desc include/linux/irqdesc.h:146
       [<ffffffff811a92bc>] handle_irq+0x10c/0x2a0 arch/x86/kernel/irq_64.c:78
       [<ffffffff811a7e4d>] do_IRQ+0x7d/0x1a0 arch/x86/kernel/irq.c:240
       [<ffffffff86653d4c>] common_interrupt+0x8c/0x8c arch/x86/entry/entry_64.S:520
       <EOI>
       [<     inline     >] rcu_lock_acquire include/linux/rcupdate.h:490
       [<     inline     >] rcu_read_lock include/linux/rcupdate.h:874
       [<ffffffff8164b4a1>] filemap_map_pages+0x131/0xba0 mm/filemap.c:2145
       [<     inline     >] do_fault_around mm/memory.c:2943
       [<     inline     >] do_read_fault mm/memory.c:2962
       [<     inline     >] do_fault mm/memory.c:3133
       [<     inline     >] handle_pte_fault mm/memory.c:3308
       [<     inline     >] __handle_mm_fault mm/memory.c:3418
       [<ffffffff816efb16>] handle_mm_fault+0x2516/0x49a0 mm/memory.c:3447
       [<ffffffff8127dc16>] __do_page_fault+0x376/0x960 arch/x86/mm/fault.c:1238
       [<ffffffff8127e358>] trace_do_page_fault+0xe8/0x420 arch/x86/mm/fault.c:1331
       [<ffffffff8126f514>] do_async_page_fault+0x14/0xd0 arch/x86/kernel/kvm.c:264
       [<ffffffff86655578>] async_page_fault+0x28/0x30 arch/x86/entry/entry_64.S:986
    
    Fix it by ensuring that the polling path is holding the host lock
    before entering ata_sff_hsm_move() so that all hardware accesses and
    state updates are performed under the host lock.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-and-tested-by: Dmitry Vyukov <dvyukov@google.com>
    Link: http://lkml.kernel.org/g/CACT4Y+b_JsOxJu2EZyEf+mOXORc_zid5V1-pLZSroJVxyWdSpw@mail.gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c48469ef81f5b939289c2f8d49291a724e7658ef
Author: Tejun Heo <tj@kernel.org>
Date:   Tue Feb 9 16:11:26 2016 -0500

    Revert "workqueue: make sure delayed work run in local cpu"
    
    commit 041bd12e272c53a35c54c13875839bcb98c999ce upstream.
    
    This reverts commit 874bbfe600a660cba9c776b3957b1ce393151b76.
    
    Workqueue used to implicity guarantee that work items queued without
    explicit CPU specified are put on the local CPU.  Recent changes in
    timer broke the guarantee and led to vmstat breakage which was fixed
    by 176bed1de5bf ("vmstat: explicitly schedule per-cpu work on the CPU
    we need it to run on").
    
    vmstat is the most likely to expose the issue and it's quite possible
    that there are other similar problems which are a lot more difficult
    to trigger.  As a preventive measure, 874bbfe600a6 ("workqueue: make
    sure delayed work run in local cpu") was applied to restore the local
    CPU guarnatee.  Unfortunately, the change exposed a bug in timer code
    which got fixed by 22b886dd1018 ("timers: Use proper base migration in
    add_timer_on()").  Due to code restructuring, the commit couldn't be
    backported beyond certain point and stable kernels which only had
    874bbfe600a6 started crashing.
    
    The local CPU guarantee was accidental more than anything else and we
    want to get rid of it anyway.  As, with the vmstat case fixed,
    874bbfe600a6 is causing more problems than it's fixing, it has been
    decided to take the chance and officially break the guarantee by
    reverting the commit.  A debug feature will be added to force foreign
    CPU assignment to expose cases relying on the guarantee and fixes for
    the individual cases will be backported to stable as necessary.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Fixes: 874bbfe600a6 ("workqueue: make sure delayed work run in local cpu")
    Link: http://lkml.kernel.org/g/20160120211926.GJ10810@quack.suse.cz
    Cc: Mike Galbraith <umgwanakikbuti@gmail.com>
    Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
    Cc: Daniel Bilik <daniel.bilik@neosystem.cz>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Shaohua Li <shli@fb.com>
    Cc: Sasha Levin <sasha.levin@oracle.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Daniel Bilik <daniel.bilik@neosystem.cz>
    Cc: Jiri Slaby <jslaby@suse.cz>
    Cc: Michal Hocko <mhocko@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 24ff5178f249a562174cfc339ac4439a436dab04
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Jan 26 11:29:03 2016 +0100

    rfkill: fix rfkill_fop_read wait_event usage
    
    commit 6736fde9672ff6717ac576e9bba2fd5f3dfec822 upstream.
    
    The code within wait_event_interruptible() is called with
    !TASK_RUNNING, so mustn't call any functions that can sleep,
    like mutex_lock().
    
    Since we re-check the list_empty() in a loop after the wait,
    it's safe to simply use list_empty() without locking.
    
    This bug has existed forever, but was only discovered now
    because all userspace implementations, including the default
    'rfkill' tool, use poll() or select() to get a readable fd
    before attempting to read.
    
    Fixes: c64fb01627e24 ("rfkill: create useful userspace interface")
    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 2d9db494ab05a1cec2d3ab1daab610e023cff75a
Author: Oliver Neukum <oneukum@suse.com>
Date:   Mon Jan 18 15:45:18 2016 +0100

    cdc-acm:exclude Samsung phone 04e8:685d
    
    commit e912e685f372ab62a2405a1acd923597f524e94a upstream.
    
    This phone needs to be handled by a specialised firmware tool
    and is reported to crash irrevocably if cdc-acm takes it.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 739ed1f0c0d26230e686fa12a1b1601b27471723
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Wed Feb 17 20:04:08 2016 +0100

    libceph: don't bail early from try_read() when skipping a message
    
    commit e7a88e82fe380459b864e05b372638aeacb0f52d upstream.
    
    The contract between try_read() and try_write() is that when called
    each processes as much data as possible.  When instructed by osd_client
    to skip a message, try_read() is violating this contract by returning
    after receiving and discarding a single message instead of checking for
    more.  try_write() then gets a chance to write out more requests,
    generating more replies/skips for try_read() to handle, forcing the
    messenger into a starvation loop.
    
    Reported-by: Varada Kari <Varada.Kari@sandisk.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Tested-by: Varada Kari <Varada.Kari@sandisk.com>
    Reviewed-by: Alex Elder <elder@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2b522d5f634ec22e24ca4470b54bb145324422f2
Author: Peter Rosin <peda@axentia.se>
Date:   Thu Feb 18 14:07:52 2016 +0100

    hwmon: (ads1015) Handle negative conversion values correctly
    
    commit acc146943957d7418a6846f06e029b2c5e87e0d5 upstream.
    
    Make the divisor signed as DIV_ROUND_CLOSEST is undefined for negative
    dividends when the divisor is unsigned.
    
    Signed-off-by: Peter Rosin <peda@axentia.se>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dc49ba72c01a1f7b39b3d48f5f28fa8487461a60
Author: Mike Marciniszyn <mike.marciniszyn@intel.com>
Date:   Thu Jan 7 16:44:10 2016 -0500

    IB/qib: fix mcast detach when qp not attached
    
    commit 09dc9cd6528f5b52bcbd3292a6312e762c85260f upstream.
    
    The code produces the following trace:
    
    [1750924.419007] general protection fault: 0000 [#3] SMP
    [1750924.420364] Modules linked in: nfnetlink autofs4 rpcsec_gss_krb5 nfsv4
    dcdbas rfcomm bnep bluetooth nfsd auth_rpcgss nfs_acl dm_multipath nfs lockd
    scsi_dh sunrpc fscache radeon ttm drm_kms_helper drm serio_raw parport_pc
    ppdev i2c_algo_bit lpc_ich ipmi_si ib_mthca ib_qib dca lp parport ib_ipoib
    mac_hid ib_cm i3000_edac ib_sa ib_uverbs edac_core ib_umad ib_mad ib_core
    ib_addr tg3 ptp dm_mirror dm_region_hash dm_log psmouse pps_core
    [1750924.420364] CPU: 1 PID: 8401 Comm: python Tainted: G D
    3.13.0-39-generic #66-Ubuntu
    [1750924.420364] Hardware name: Dell Computer Corporation PowerEdge
    860/0XM089, BIOS A04 07/24/2007
    [1750924.420364] task: ffff8800366a9800 ti: ffff88007af1c000 task.ti:
    ffff88007af1c000
    [1750924.420364] RIP: 0010:[<ffffffffa0131d51>] [<ffffffffa0131d51>]
    qib_mcast_qp_free+0x11/0x50 [ib_qib]
    [1750924.420364] RSP: 0018:ffff88007af1dd70  EFLAGS: 00010246
    [1750924.420364] RAX: 0000000000000001 RBX: ffff88007b822688 RCX:
    000000000000000f
    [1750924.420364] RDX: ffff88007b822688 RSI: ffff8800366c15a0 RDI:
    6764697200000000
    [1750924.420364] RBP: ffff88007af1dd78 R08: 0000000000000001 R09:
    0000000000000000
    [1750924.420364] R10: 0000000000000011 R11: 0000000000000246 R12:
    ffff88007baa1d98
    [1750924.420364] R13: ffff88003ecab000 R14: ffff88007b822660 R15:
    0000000000000000
    [1750924.420364] FS:  00007ffff7fd8740(0000) GS:ffff88007fc80000(0000)
    knlGS:0000000000000000
    [1750924.420364] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [1750924.420364] CR2: 00007ffff597c750 CR3: 000000006860b000 CR4:
    00000000000007e0
    [1750924.420364] Stack:
    [1750924.420364]  ffff88007b822688 ffff88007af1ddf0 ffffffffa0132429
    000000007af1de20
    [1750924.420364]  ffff88007baa1dc8 ffff88007baa0000 ffff88007af1de70
    ffffffffa00cb313
    [1750924.420364]  00007fffffffde88 0000000000000000 0000000000000008
    ffff88003ecab000
    [1750924.420364] Call Trace:
    [1750924.420364]  [<ffffffffa0132429>] qib_multicast_detach+0x1e9/0x350
    [ib_qib]
    [1750924.568035]  [<ffffffffa00cb313>] ? ib_uverbs_modify_qp+0x323/0x3d0
    [ib_uverbs]
    [1750924.568035]  [<ffffffffa0092d61>] ib_detach_mcast+0x31/0x50 [ib_core]
    [1750924.568035]  [<ffffffffa00cc213>] ib_uverbs_detach_mcast+0x93/0x170
    [ib_uverbs]
    [1750924.568035]  [<ffffffffa00c61f6>] ib_uverbs_write+0xc6/0x2c0 [ib_uverbs]
    [1750924.568035]  [<ffffffff81312e68>] ? apparmor_file_permission+0x18/0x20
    [1750924.568035]  [<ffffffff812d4cd3>] ? security_file_permission+0x23/0xa0
    [1750924.568035]  [<ffffffff811bd214>] vfs_write+0xb4/0x1f0
    [1750924.568035]  [<ffffffff811bdc49>] SyS_write+0x49/0xa0
    [1750924.568035]  [<ffffffff8172f7ed>] system_call_fastpath+0x1a/0x1f
    [1750924.568035] Code: 66 2e 0f 1f 84 00 00 00 00 00 31 c0 5d c3 66 2e 0f 1f
    84 00 00 00 00 00 66 90 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb 48 8b 7f 10
    <f0> ff 8f 40 01 00 00 74 0e 48 89 df e8 8e f8 06 e1 5b 5d c3 0f
    [1750924.568035] RIP  [<ffffffffa0131d51>] qib_mcast_qp_free+0x11/0x50
    [ib_qib]
    [1750924.568035]  RSP <ffff88007af1dd70>
    [1750924.650439] ---[ end trace 73d5d4b3f8ad4851 ]
    
    The fix is to note the qib_mcast_qp that was found.   If none is found, then
    return EINVAL indicating the error.
    
    Reviewed-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Reported-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
    Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eeecc3f39587463b95ea8ddd7b7ec2c2155e0782
Author: Insu Yun <wuninsu@gmail.com>
Date:   Sat Jan 23 15:44:19 2016 -0500

    ACPI / PCI / hotplug: unlock in error path in acpiphp_enable_slot()
    
    commit 2c3033a0664dfae91e1dee7fabac10f24354b958 upstream.
    
    In acpiphp_enable_slot(), there is a missing unlock path
    when error occurred.  It needs to be unlocked before returning
    an error.
    
    Signed-off-by: Insu Yun <wuninsu@gmail.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ee61647c34f18c204db1bc384e53c9f11c1b3819
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Feb 19 18:05:10 2016 -0500

    drm/radeon/pm: adjust display configuration after powerstate
    
    commit 39d4275058baf53e89203407bf3841ff2c74fa32 upstream.
    
    set_power_state defaults to no displays, so we need to update
    the display configuration after setting up the powerstate on the
    first call. In most cases this is not an issue since ends up
    getting called multiple times at any given modeset and the proper
    order is achieved in the display changed handling at the top of
    the function.
    
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Acked-by: Jordan Lazare <Jordan.Lazare@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e4707e743e6ab24a45c2fe758f8b918122172abc
Author: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Date:   Mon Feb 15 19:41:47 2016 +0100

    drm/radeon: use post-decrement in error handling
    
    commit bc3f5d8c4ca01555820617eb3b6c0857e4df710d upstream.
    
    We need to use post-decrement to get the pci_map_page undone also for
    i==0, and to avoid some very unpleasant behaviour if pci_map_page
    failed already at i==0.
    
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ccaa0f16445bbe9abe2ce6c3be8038c635229a8a
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Tue Feb 16 14:25:00 2016 +0100

    drm/qxl: use kmalloc_array to alloc reloc_info in qxl_process_single_command
    
    commit 34855706c30d52b0a744da44348b5d1cc39fbe51 upstream.
    
    This avoids integer overflows on 32bit machines when calculating
    reloc_info size, as reported by Alan Cox.
    
    Cc: gnomes@lxorguk.ukuu.org.uk
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8bdbb55d0555794ac7bc917d5aec4b1516eba14f
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Wed Jan 13 16:35:20 2016 +0200

    drm/i915/dp: fall back to 18 bpp when sink capability is unknown
    
    commit 5efd407674068dede403551bea3b0b134c32513a upstream.
    
    Per DP spec, the source device should fall back to 18 bpp, VESA range
    RGB when the sink capability is unknown. Fix the color depth
    clamping. 18 bpp color depth should ensure full color range in automatic
    mode.
    
    The clamping has been HDMI specific since its introduction in
    
    commit 996a2239f93b03c5972923f04b097f65565c5bed
    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
    Date:   Fri Apr 19 11:24:34 2013 +0200
    
        drm/i915: Disable high-bpc on pre-1.4 EDID screens
    
    Reported-and-tested-by: Dihan Wickremasuriya <nayomal@gmail.com>
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105331
    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Link: http://patchwork.freedesktop.org/patch/msgid/1452695720-7076-1-git-send-email-jani.nikula@intel.com
    (cherry picked from commit 013dd9e038723bbd2aa67be51847384b75be8253)
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 50353e6f86eb2ac46ffe3cc0b9f9a11ddc8a9410
Author: Nicolai Hähnle <nicolai.haehnle@amd.com>
Date:   Fri Feb 5 14:35:53 2016 -0500

    drm/radeon: hold reference to fences in radeon_sa_bo_new
    
    commit f6ff4f67cdf8455d0a4226eeeaf5af17c37d05eb upstream.
    
    An arbitrary amount of time can pass between spin_unlock and
    radeon_fence_wait_any, so we need to ensure that nobody frees the
    fences from under us.
    
    Based on the analogous fix for amdgpu.
    
    Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dcbad9717b0626faa00c13fb51e81410e60fe543
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Dec 17 12:52:17 2015 -0500

    drm/radeon: clean up fujitsu quirks
    
    commit 0eb1c3d4084eeb6fb3a703f88d6ce1521f8fcdd1 upstream.
    
    Combine the two quirks.
    
    bug:
    https://bugzilla.kernel.org/show_bug.cgi?id=109481
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6558531dd981b9ee133ee135ce1e89e7c970681d
Author: Rob Clark <robdclark@gmail.com>
Date:   Wed Oct 15 15:00:47 2014 -0400

    drm/vmwgfx: respect 'nomodeset'
    
    commit 96c5d076f0a5e2023ecdb44d8261f87641ee71e0 upstream.
    
    Signed-off-by: Rob Clark <robdclark@gmail.com>
    Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>.
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 670aaf542dc20fbba515a00aff228e3a03b670e7
Author: Dmitry V. Levin <ldv@altlinux.org>
Date:   Sun Dec 27 02:13:27 2015 +0300

    sparc64: fix incorrect sign extension in sys_sparc64_personality
    
    commit 525fd5a94e1be0776fa652df5c687697db508c91 upstream.
    
    The value returned by sys_personality has type "long int".
    It is saved to a variable of type "int", which is not a problem
    yet because the type of task_struct->pesonality is "unsigned int".
    The problem is the sign extension from "int" to "long int"
    that happens on return from sys_sparc64_personality.
    
    For example, a userspace call personality((unsigned) -EINVAL) will
    result to any subsequent personality call, including absolutely
    harmless read-only personality(0xffffffff) call, failing with
    errno set to EINVAL.
    
    Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1dc152850f7b2c6c2ca6912c699099b1ca8f0699
Author: Borislav Petkov <bp@suse.de>
Date:   Fri Nov 27 10:38:38 2015 +0100

    EDAC: Robustify workqueues destruction
    
    commit fcd5c4dd8201595d4c598c9cca5e54760277d687 upstream.
    
    EDAC workqueue destruction is really fragile. We cancel delayed work
    but if it is still running and requeues itself, we still go ahead and
    destroy the workqueue and the queued work explodes when workqueue core
    attempts to run it.
    
    Make the destruction more robust by switching op_state to offline so
    that requeuing stops. Cancel any pending work *synchronously* too.
    
      EDAC i7core: Driver loaded.
      general protection fault: 0000 [#1] SMP
      CPU 12
      Modules linked in:
      Supported: Yes
      Pid: 0, comm: kworker/0:1 Tainted: G          IE   3.0.101-0-default #1 HP ProLiant DL380 G7
      RIP: 0010:[<ffffffff8107dcd7>]  [<ffffffff8107dcd7>] __queue_work+0x17/0x3f0
      < ... regs ...>
      Process kworker/0:1 (pid: 0, threadinfo ffff88019def6000, task ffff88019def4600)
      Stack:
       ...
      Call Trace:
       call_timer_fn
       run_timer_softirq
       __do_softirq
       call_softirq
       do_softirq
       irq_exit
       smp_apic_timer_interrupt
       apic_timer_interrupt
       intel_idle
       cpuidle_idle_call
       cpu_idle
      Code: ...
      RIP  __queue_work
       RSP <...>
    
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0832c136e4e337866381e57b508d44cea34077b8
Author: zengtao <prime.zeng@huawei.com>
Date:   Tue Feb 2 11:38:34 2016 +0800

    cputime: Prevent 32bit overflow in time[val|spec]_to_cputime()
    
    commit 0f26922fe5dc5724b1adbbd54b21bad03590b4f3 upstream.
    
    The datatype __kernel_time_t is u32 on 32bit platform, so its subject to
    overflows in the timeval/timespec to cputime conversion.
    
    Currently the following functions are affected:
    1. setitimer()
    2. timer_create/timer_settime()
    3. sys_clock_nanosleep
    
    This can happen on MIPS32 and ARM32 with "Full dynticks CPU time accounting"
    enabled, which is required for CONFIG_NO_HZ_FULL.
    
    Enforce u64 conversion to prevent the overflow.
    
    Fixes: 31c1fc818715 ("ARM: Kconfig: allow full nohz CPU accounting")
    Signed-off-by: zengtao <prime.zeng@huawei.com>
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    Cc: <fweisbec@gmail.com>
    Link: http://lkml.kernel.org/r/1454384314-154784-1-git-send-email-prime.zeng@huawei.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e62b1b5a1312d86fba7d6bbdc33847ae141ec323
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Mon Jan 4 02:21:55 2016 +0100

    mmc: mmci: fix an ages old detection error
    
    commit 0bcb7efdff63564e80fe84dd36a9fbdfbf6697a4 upstream.
    
    commit 4956e10903fd ("ARM: 6244/1: mmci: add variant data and default
    MCICLOCK support") added variant data for ARM, U300 and Ux500 variants.
    The Nomadik NHK8815/8820 variant was erroneously labeled as a U300
    variant, and when the proper Nomadik variant was later introduced in
    commit 34fd421349ff ("ARM: 7378/1: mmci: add support for the Nomadik MMCI
    variant") this was not fixes. Let's say this fixes the latter commit as
    there was no proper Nomadik support until then.
    
    Fixes: 34fd421349ff ("ARM: 7378/1: mmci: add support for the Nomadik...")
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 73195d5f9f5097b8d5c130be96912e0fc11f661d
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Thu Nov 26 14:00:50 2015 +0200

    mmc: sdhci: Fix sdhci_runtime_pm_bus_on/off()
    
    commit 5c671c410c8704800f4f1673b6f572137e7e6ddd upstream.
    
    sdhci has a legacy facility to prevent runtime suspend if the
    bus power is on.  This is needed in cases where the power to
    the card is dependent on the bus power.  It is controlled by
    a pair of functions: sdhci_runtime_pm_bus_on() and
    sdhci_runtime_pm_bus_off().  These functions use a boolean
    variable 'bus_on' to ensure changes are always paired.
    There is an additional check for 'runtime_suspended' which is
    the problem.  In fact, its use is ill-conceived as the only
    requirement for the logic is that 'on' and 'off' are paired,
    which is actually broken by the check, for example if the bus
    power is turned on during runtime resume.  So remove  the check.
    
    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 8dedf98a03b31c7087e22753024e282b47a8690f
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Thu Nov 26 14:00:47 2015 +0200

    mmc: sdio: Fix invalid vdd in voltage switch power cycle
    
    commit d9bfbb95ed598a09cf336adb0f190ee0ff802f0d upstream.
    
    The 'ocr' parameter passed to mmc_set_signal_voltage()
    defines the power-on voltage used when power cycling
    after a failure to set the voltage.  However, in the
    case of mmc_sdio_init_card(), the value passed has the
    R4_18V_PRESENT flag set which is not valid for power-on
    and results in an invalid vdd.  Fix by passing the card's
    ocr value which does not have the flag.
    
    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 bd57fce6f51abecc06b025831a85c607af5b3f0d
Author: Richard Cochran <richardcochran@gmail.com>
Date:   Tue Dec 22 22:19:58 2015 +0100

    posix-clock: Fix return code on the poll method's error path
    
    commit 1b9f23727abb92c5e58f139e7d180befcaa06fe0 upstream.
    
    The posix_clock_poll function is supposed to return a bit mask of
    POLLxxx values.  However, in case the hardware has disappeared (due to
    hot plugging for example) this code returns -ENODEV in a futile
    attempt to throw an error at the file descriptor level.  The kernel's
    file_operations interface does not accept such error codes from the
    poll method.  Instead, this function aught to return POLLERR.
    
    The value -ENODEV does, in fact, contain the POLLERR bit (and almost
    all the other POLLxxx bits as well), but only by chance.  This patch
    fixes code to return a proper bit mask.
    
    Credit goes to Markus Elfring for pointing out the suspicious
    signed/unsigned mismatch.
    
    Reported-by: Markus Elfring <elfring@users.sourceforge.net>
    igned-off-by: Richard Cochran <richardcochran@gmail.com>
    Cc: John Stultz <john.stultz@linaro.org>
    Cc: Julia Lawall <julia.lawall@lip6.fr>
    Link: http://lkml.kernel.org/r/1450819198-17420-1-git-send-email-richardcochran@gmail.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 44bfff548b8bd13c3e7299b88abbee9297151b8a
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Fri Jan 8 19:07:55 2016 -0500

    dm snapshot: fix hung bios when copy error occurs
    
    commit 385277bfb57faac44e92497104ba542cdd82d5fe upstream.
    
    When there is an error copying a chunk dm-snapshot can incorrectly hold
    associated bios indefinitely, resulting in hung IO.
    
    The function copy_callback sets pe->error if there was error copying the
    chunk, and then calls complete_exception.  complete_exception calls
    pending_complete on error, otherwise it calls commit_exception with
    commit_callback (and commit_callback calls complete_exception).
    
    The persistent exception store (dm-snap-persistent.c) assumes that calls
    to prepare_exception and commit_exception are paired.
    persistent_prepare_exception increases ps->pending_count and
    persistent_commit_exception decreases it.
    
    If there is a copy error, persistent_prepare_exception is called but
    persistent_commit_exception is not.  This results in the variable
    ps->pending_count never returning to zero and that causes some pending
    exceptions (and their associated bios) to be held forever.
    
    Fix this by unconditionally calling commit_exception regardless of
    whether the copy was successful.  A new "valid" parameter is added to
    commit_exception -- when the copy fails this parameter is set to zero so
    that the chunk that failed to copy (and all following chunks) is not
    recorded in the snapshot store.  Also, remove commit_callback now that
    it is merely a wrapper around pending_complete.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 771b4a00bcc64cd370d5b102e2cee316e71d4f93
Author: Mike Snitzer <snitzer@redhat.com>
Date:   Mon Dec 14 09:26:01 2015 -0500

    dm space map metadata: remove unused variable in brb_pop()
    
    commit 512167788a6fe9481a33a3cce5f80b684631a1bb upstream.
    
    Remove the unused struct block_op pointer that was inadvertantly
    introduced, via cut-and-paste of previous brb_op() code, as part of
    commit 50dd842ad.
    
    (Cc'ing stable@ because commit 50dd842ad did)
    
    Fixes: 50dd842ad ("dm space map metadata: fix ref counting bug when bootstrapping a new space map")
    Reported-by: David Binderman <dcb314@hotmail.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4d0ac631239b11443de839c255d80ac9fc09fc32
Author: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Date:   Wed Feb 3 17:33:48 2016 -0200

    tda1004x: only update the frontend properties if locked
    
    commit e8beb02343e7582980c6705816cd957cf4f74c7a upstream.
    
    The tda1004x was updating the properties cache before locking.
    If the device is not locked, the data at the registers are just
    random values with no real meaning.
    
    This caused the driver to fail with libdvbv5, as such library
    calls GET_PROPERTY from time to time, in order to return the
    DVB stats.
    
    Tested with a saa7134 card 78:
    	ASUSTeK P7131 Dual, vendor PCI ID: 1043:4862
    
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 518cc7158e72d32c9954c7819c3e086e53064ea0
Author: Antonio Ospite <ao2@ao2.it>
Date:   Fri Oct 2 17:33:13 2015 -0300

    gspca: ov534/topro: prevent a division by 0
    
    commit dcc7fdbec53a960588f2c40232db2c6466c09917 upstream.
    
    v4l2-compliance sends a zeroed struct v4l2_streamparm in
    v4l2-test-formats.cpp::testParmType(), and this results in a division by
    0 in some gspca subdrivers:
    
      divide error: 0000 [#1] SMP
      Modules linked in: gspca_ov534 gspca_main ...
      CPU: 0 PID: 17201 Comm: v4l2-compliance Not tainted 4.3.0-rc2-ao2 #1
      Hardware name: System manufacturer System Product Name/M2N-E SLI, BIOS
        ASUS M2N-E SLI ACPI BIOS Revision 1301 09/16/2010
      task: ffff8800818306c0 ti: ffff880095c4c000 task.ti: ffff880095c4c000
      RIP: 0010:[<ffffffffa079bd62>]  [<ffffffffa079bd62>] sd_set_streamparm+0x12/0x60 [gspca_ov534]
      RSP: 0018:ffff880095c4fce8  EFLAGS: 00010296
      RAX: 0000000000000000 RBX: ffff8800c9522000 RCX: ffffffffa077a140
      RDX: 0000000000000000 RSI: ffff880095e0c100 RDI: ffff8800c9522000
      RBP: ffff880095e0c100 R08: ffffffffa077a100 R09: 00000000000000cc
      R10: ffff880067ec7740 R11: 0000000000000016 R12: ffffffffa07bb400
      R13: 0000000000000000 R14: ffff880081b6a800 R15: 0000000000000000
      FS:  00007fda0de78740(0000) GS:ffff88012fc00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000014630f8 CR3: 00000000cf349000 CR4: 00000000000006f0
      Stack:
       ffffffffa07a6431 ffff8800c9522000 ffffffffa077656e 00000000c0cc5616
       ffff8800c9522000 ffffffffa07a5e20 ffff880095e0c100 0000000000000000
       ffff880067ec7740 ffffffffa077a140 ffff880067ec7740 0000000000000016
      Call Trace:
       [<ffffffffa07a6431>] ? v4l_s_parm+0x21/0x50 [videodev]
       [<ffffffffa077656e>] ? vidioc_s_parm+0x4e/0x60 [gspca_main]
       [<ffffffffa07a5e20>] ? __video_do_ioctl+0x280/0x2f0 [videodev]
       [<ffffffffa07a5ba0>] ? video_ioctl2+0x20/0x20 [videodev]
       [<ffffffffa07a59b9>] ? video_usercopy+0x319/0x4e0 [videodev]
       [<ffffffff81182dc1>] ? page_add_new_anon_rmap+0x71/0xa0
       [<ffffffff811afb92>] ? mem_cgroup_commit_charge+0x52/0x90
       [<ffffffff81179b18>] ? handle_mm_fault+0xc18/0x1680
       [<ffffffffa07a15cc>] ? v4l2_ioctl+0xac/0xd0 [videodev]
       [<ffffffff811c846f>] ? do_vfs_ioctl+0x28f/0x480
       [<ffffffff811c86d4>] ? SyS_ioctl+0x74/0x80
       [<ffffffff8154a8b6>] ? entry_SYSCALL_64_fastpath+0x16/0x75
      Code: c7 93 d9 79 a0 5b 5d e9 f1 f3 9a e0 0f 1f 00 66 2e 0f 1f 84 00
        00 00 00 00 66 66 66 66 90 53 31 d2 48 89 fb 48 83 ec 08 8b 46 10 <f7>
        76 0c 80 bf ac 0c 00 00 00 88 87 4e 0e 00 00 74 09 80 bf 4f
      RIP  [<ffffffffa079bd62>] sd_set_streamparm+0x12/0x60 [gspca_ov534]
       RSP <ffff880095c4fce8>
      ---[ end trace 279710c2c6c72080 ]---
    
    Following what the doc says about a zeroed timeperframe (see
    http://www.linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-parm.html):
    
      ...
      To reset manually applications can just set this field to zero.
    
    fix the issue by resetting the frame rate to a default value in case of
    an unusable timeperframe.
    
    The fix is done in the subdrivers instead of gspca.c because only the
    subdrivers have notion of a default frame rate to reset the camera to.
    
    Signed-off-by: Antonio Ospite <ao2@ao2.it>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 334dffff77b1aa0a3556a8fe2c11ddd759a78ca7
Author: Malcolm Priestley <tvboxspy@gmail.com>
Date:   Mon Aug 31 06:13:45 2015 -0300

    media: dvb-core: Don't force CAN_INVERSION_AUTO in oneshot mode
    
    commit c9d57de6103e343f2d4e04ea8d9e417e10a24da7 upstream.
    
    When in FE_TUNE_MODE_ONESHOT the frontend must report
    the actual capabilities so user can take appropriate
    action.
    
    With frontends that can't do auto inversion this is done
    by dvb-core automatically so CAN_INVERSION_AUTO is valid.
    
    However, when in FE_TUNE_MODE_ONESHOT this is not true.
    
    So only set FE_CAN_INVERSION_AUTO in modes other than
    FE_TUNE_MODE_ONESHOT
    
    Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 50e55af824d22215630f6a5f0e3f5fd2d708c195
Author: Vegard Nossum <vegard.nossum@oracle.com>
Date:   Wed Dec 16 21:59:56 2015 +0100

    uml: fix hostfs mknod()
    
    commit 9f2dfda2f2f1c6181c3732c16b85c59ab2d195e0 upstream.
    
    An inverted return value check in hostfs_mknod() caused the function
    to return success after handling it as an error (and cleaning up).
    
    It resulted in the following segfault when trying to bind() a named
    unix socket:
    
      Pid: 198, comm: a.out Not tainted 4.4.0-rc4
      RIP: 0033:[<0000000061077df6>]
      RSP: 00000000daae5d60  EFLAGS: 00010202
      RAX: 0000000000000000 RBX: 000000006092a460 RCX: 00000000dfc54208
      RDX: 0000000061073ef1 RSI: 0000000000000070 RDI: 00000000e027d600
      RBP: 00000000daae5de0 R08: 00000000da980ac0 R09: 0000000000000000
      R10: 0000000000000003 R11: 00007fb1ae08f72a R12: 0000000000000000
      R13: 000000006092a460 R14: 00000000daaa97c0 R15: 00000000daaa9a88
      Kernel panic - not syncing: Kernel mode fault at addr 0x40, ip 0x61077df6
      CPU: 0 PID: 198 Comm: a.out Not tainted 4.4.0-rc4 #1
      Stack:
       e027d620 dfc54208 0000006f da981398
       61bee000 0000c1ed daae5de0 0000006e
       e027d620 dfcd4208 00000005 6092a460
      Call Trace:
       [<60dedc67>] SyS_bind+0xf7/0x110
       [<600587be>] handle_syscall+0x7e/0x80
       [<60066ad7>] userspace+0x3e7/0x4e0
       [<6006321f>] ? save_registers+0x1f/0x40
       [<6006c88e>] ? arch_prctl+0x1be/0x1f0
       [<60054985>] fork_handler+0x85/0x90
    
    Let's also get rid of the "cosmic ray protection" while we're at it.
    
    Fixes: e9193059b1b3 "hostfs: fix races in dentry_name() and inode_name()"
    Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
    Cc: Jeff Dike <jdike@addtoit.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fdba8a6da249a47fa59039f64a7379927519f0af
Author: Vegard Nossum <vegard.nossum@oracle.com>
Date:   Fri Dec 18 21:28:53 2015 +0100

    uml: flush stdout before forking
    
    commit 0754fb298f2f2719f0393491d010d46cfb25d043 upstream.
    
    I was seeing some really weird behaviour where piping UML's output
    somewhere would cause output to get duplicated:
    
      $ ./vmlinux | head -n 40
      Checking that ptrace can change system call numbers...Core dump limits :
              soft - 0
              hard - NONE
      OK
      Checking syscall emulation patch for ptrace...Core dump limits :
              soft - 0
              hard - NONE
      OK
      Checking advanced syscall emulation patch for ptrace...Core dump limits :
              soft - 0
              hard - NONE
      OK
      Core dump limits :
              soft - 0
              hard - NONE
    
    This is because these tests do a fork() which duplicates the non-empty
    stdout buffer, then glibc flushes the duplicated buffer as each child
    exits.
    
    A simple workaround is to flush before forking.
    
    Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad4c943fdaba8548a177cd91ccc84ab1ca295584
Author: Stefan Haberland <stefan.haberland@de.ibm.com>
Date:   Tue Dec 15 10:45:05 2015 +0100

    s390/dasd: fix refcount for PAV reassignment
    
    commit 9d862ababb609439c5d6987f6d3ddd09e703aa0b upstream.
    
    Add refcount to the DASD device when a summary unit check worker is
    scheduled. This prevents that the device is set offline with worker
    in place.
    
    Signed-off-by: Stefan Haberland <stefan.haberland@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 75e016b7d251cc18214b9685cd8283ad86b121ba
Author: Stefan Haberland <stefan.haberland@de.ibm.com>
Date:   Tue Dec 15 10:16:43 2015 +0100

    s390/dasd: prevent incorrect length error under z/VM after PAV changes
    
    commit 020bf042e5b397479c1174081b935d0ff15d1a64 upstream.
    
    The channel checks the specified length and the provided amount of
    data for CCWs and provides an incorrect length error if the size does
    not match. Under z/VM with simulation activated the length may get
    changed. Having the suppress length indication bit set is stated as
    good CCW coding practice and avoids errors under z/VM.
    
    Signed-off-by: Stefan Haberland <stefan.haberland@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 19bb7e5c2ebff45cb369c44fb83db772994be1fe
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Fri Jan 1 13:39:22 2016 +0100

    s390: fix normalization bug in exception table sorting
    
    commit bcb7825a77f41c7dd91da6f7ac10b928156a322e upstream.
    
    The normalization pass in the sorting routine of the relative exception
    table serves two purposes:
    - it ensures that the address fields of the exception table entries are
      fully ordered, so that no ambiguities arise between entries with
      identical instruction offsets (i.e., when two instructions that are
      exactly 8 bytes apart each have an exception table entry associated with
      them)
    - it ensures that the offsets of both the instruction and the fixup fields
      of each entry are relative to their final location after sorting.
    
    Commit eb608fb366de ("s390/exceptions: switch to relative exception table
    entries") ported the relative exception table format from x86, but modified
    the sorting routine to only normalize the instruction offset field and not
    the fixup offset field. The result is that the fixup offset of each entry
    will be relative to the original location of the entry before sorting,
    likely leading to crashes when those entries are dereferenced.
    
    Fixes: eb608fb366de ("s390/exceptions: switch to relative exception table entries")
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 55330b801ed55f24a64ca4be6f777ee2f3e38cd9
Author: Filipe Manana <fdmanana@suse.com>
Date:   Thu Dec 31 18:16:29 2015 +0000

    Btrfs: fix number of transaction units required to create symlink
    
    commit 9269d12b2d57d9e3d13036bb750762d1110d425c upstream.
    
    We weren't accounting for the insertion of an inline extent item for the
    symlink inode nor that we need to update the parent inode item (through
    the call to btrfs_add_nondir()). So fix this by including two more
    transaction units.
    
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e5e48c0ad397cd92f2a8ec81c3ded958ceb357a1
Author: Filipe Manana <fdmanana@suse.com>
Date:   Thu Dec 31 18:07:59 2015 +0000

    Btrfs: send, don't BUG_ON() when an empty symlink is found
    
    commit a879719b8c90e15c9e7fa7266d5e3c0ca962f9df upstream.
    
    When a symlink is successfully created it always has an inline extent
    containing the source path. However if an error happens when creating
    the symlink, we can leave in the subvolume's tree a symlink inode without
    any such inline extent item - this happens if after btrfs_symlink() calls
    btrfs_end_transaction() and before it calls the inode eviction handler
    (through the final iput() call), the transaction gets committed and a
    crash happens before the eviction handler gets called, or if a snapshot
    of the subvolume is made before the eviction handler gets called. Sadly
    we can't just avoid this by making btrfs_symlink() call
    btrfs_end_transaction() after it calls the eviction handler, because the
    later can commit the current transaction before it removes any items from
    the subvolume tree (if it encounters ENOSPC errors while reserving space
    for removing all the items).
    
    So make send fail more gracefully, with an -EIO error, and print a
    message to dmesg/syslog informing that there's an empty symlink inode,
    so that the user can delete the empty symlink or do something else
    about it.
    
    Reported-by: Stephen R. van den Berg <srb@cuci.nl>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d985de97bf3d0aef79d5ac619733cb4627af0368
Author: Josef Bacik <jbacik@fb.com>
Date:   Thu Oct 22 15:05:09 2015 -0400

    Btrfs: igrab inode in writepage
    
    commit be7bd730841e69fe8f70120098596f648cd1f3ff upstream.
    
    We hit this panic on a few of our boxes this week where we have an
    ordered_extent with an NULL inode.  We do an igrab() of the inode in writepages,
    but weren't doing it in writepage which can be called directly from the VM on
    dirty pages.  If the inode has been unlinked then we could have I_FREEING set
    which means igrab() would return NULL and we get this panic.  Fix this by trying
    to igrab in btrfs_writepage, and if it returns NULL then just redirty the page
    and return AOP_WRITEPAGE_ACTIVATE; so the VM knows it wasn't successful.  Thanks,
    
    Signed-off-by: Josef Bacik <jbacik@fb.com>
    Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7354b179aff3dccac22c6e9110a26b5885606a12
Author: Anand Jain <anand.jain@oracle.com>
Date:   Wed Oct 7 17:23:23 2015 +0800

    Btrfs: add missing brelse when superblock checksum fails
    
    commit b2acdddfad13c38a1e8b927d83c3cf321f63601a upstream.
    
    Looks like oversight, call brelse() when checksum fails. Further down the
    code, in the non error path, we do call brelse() and so we don't see
    brelse() in the goto error paths.
    
    Signed-off-by: Anand Jain <anand.jain@oracle.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b11202ea8547258205ef1ea15c61c7dd50d65989
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Fri Dec 11 12:09:03 2015 +0000

    scripts: recordmcount: break hardlinks
    
    commit dd39a26538e37f6c6131e829a4a510787e43c783 upstream.
    
    recordmcount edits the file in-place, which can cause problems when
    using ccache in hardlink mode.  Arrange for recordmcount to break a
    hardlinked object.
    
    Link: http://lkml.kernel.org/r/E1a7MVT-0000et-62@rmk-PC.arm.linux.org.uk
    
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c1a968eced547b68eb6a584b4808fb5990c7eaa7
Author: Prarit Bhargava <prarit@redhat.com>
Date:   Wed Dec 9 08:31:12 2015 -0500

    powercap / RAPL: fix BIOS lock check
    
    commit 79a21dbfae3cd40d5a801778071a9967b79c2c20 upstream.
    
    Intel RAPL initialized on several systems where the BIOS lock bit (msr
    0x610, bit 63) was set.  This occured because the return value of
    rapl_read_data_raw() was being checked, rather than the value of the variable
    passed in, locked.
    
    This patch properly implments the rapl_read_data_raw() call to check the
    variable locked, and now the Intel RAPL driver outputs the warning:
    
    	intel_rapl: RAPL package 0 domain package locked by BIOS
    
    and does not initialize for the package.
    
    Signed-off-by: Prarit Bhargava <prarit@redhat.com>
    Acked-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 59caef576e710b7fd43adca93113477511a6e944
Author: James Bottomley <James.Bottomley@HansenPartnership.com>
Date:   Fri Dec 11 09:16:38 2015 -0800

    ses: fix additional element traversal bug
    
    commit 5e1033561da1152c57b97ee84371dba2b3d64c25 upstream.
    
    KASAN found that our additional element processing scripts drop off
    the end of the VPD page into unallocated space.  The reason is that
    not every element has additional information but our traversal
    routines think they do, leading to them expecting far more additional
    information than is present.  Fix this by adding a gate to the
    traversal routine so that it only processes elements that are expected
    to have additional information (list is in SES-2 section 6.1.13.1:
    Additional Element Status diagnostic page overview)
    
    Reported-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
    Tested-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
    Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 55ee25f6bfdc18393d4ea5d3bcc56bc57e56a8a7
Author: James Bottomley <James.Bottomley@HansenPartnership.com>
Date:   Tue Dec 8 09:00:31 2015 -0800

    ses: Fix problems with simple enclosures
    
    commit 3417c1b5cb1fdc10261dbed42b05cc93166a78fd upstream.
    
    Simple enclosure implementations (mostly USB) are allowed to return only
    page 8 to every diagnostic query.  That really confuses our
    implementation because we assume the return is the page we asked for and
    end up doing incorrect offsets based on bogus information leading to
    accesses outside of allocated ranges.  Fix that by checking the page
    code of the return and giving an error if it isn't the one we asked for.
    This should fix reported bugs with USB storage by simply refusing to
    attach to enclosures that behave like this.  It's also good defensive
    practise now that we're starting to see more USB enclosures.
    
    Reported-by: Andrea Gelmini <andrea.gelmini@gelma.net>
    Reviewed-by: Ewan D. Milne <emilne@redhat.com>
    Reviewed-by: Tomas Henzl <thenzl@redhat.com>
    Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b25bfd9272838d020da06df12bd0d21c0302a9f9
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Dec 10 10:37:51 2015 +0100

    rfkill: copy the name into the rfkill struct
    
    commit b7bb110008607a915298bf0f47d25886ecb94477 upstream.
    
    Some users of rfkill, like NFC and cfg80211, use a dynamic name when
    allocating rfkill, in those cases dev_name(). Therefore, the pointer
    passed to rfkill_alloc() might not be valid forever, I specifically
    found the case that the rfkill name was quite obviously an invalid
    pointer (or at least garbage) when the wiphy had been renamed.
    
    Fix this by making a copy of the rfkill name in rfkill_alloc().
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0c35217d74c8b32099a80aaeda1f60e992484143
Author: Kirill A. Shutemov <kirill@shutemov.name>
Date:   Mon Nov 30 04:17:31 2015 +0200

    vgaarb: fix signal handling in vga_get()
    
    commit 9f5bd30818c42c6c36a51f93b4df75a2ea2bd85e upstream.
    
    There are few defects in vga_get() related to signal hadning:
    
      - we shouldn't check for pending signals for TASK_UNINTERRUPTIBLE
        case;
    
      - if we found pending signal we must remove ourself from wait queue
        and change task state back to running;
    
      - -ERESTARTSYS is more appropriate, I guess.
    
    Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name>
    Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 681edbd0b1b1d02833b8310a45b22dae9c7d32fd
Author: Guillaume Delbergue <guillaume.delbergue@greensocs.com>
Date:   Tue Dec 1 18:55:51 2015 +0100

    irqchip/versatile-fpga: Fix PCI IRQ mapping on Versatile PB
    
    commit d5d4fdd86f5759924fe54efa793e22eccf508db6 upstream.
    
    This patch is specifically for PCI support on the Versatile PB board using
    a DT. Currently, the dynamic IRQ mapping is broken when using DTs. For
    example, on QEMU, the SCSI driver is unable to request the IRQ. To fix
    this issue, this patch replaces the current dynamic mechanism with a
    static value as is done in the non-DT case.
    
    Signed-off-by: Guillaume Delbergue <guillaume.delbergue@greensocs.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 255822b235149c26054d7fb4ba63d0b2dd776ea0
Author: Joe Thornber <ejt@redhat.com>
Date:   Thu Dec 10 14:37:53 2015 +0000

    dm btree: fix bufio buffer leaks in dm_btree_del() error path
    
    commit ed8b45a3679eb49069b094c0711b30833f27c734 upstream.
    
    If dm_btree_del()'s call to push_frame() fails, e.g. due to
    btree_node_validator finding invalid metadata, the dm_btree_del() error
    path must unlock all frames (which have active dm-bufio buffers) that
    were pushed onto the del_stack.
    
    Otherwise, dm_bufio_client_destroy() will BUG_ON() because dm-bufio
    buffers have leaked, e.g.:
      device-mapper: bufio: leaked buffer 3, hold count 1, list 0
    
    Signed-off-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a58ccbd069ee6a53b78bad5894fa493f124ab944
Author: Joe Thornber <ejt@redhat.com>
Date:   Wed Dec 9 16:38:12 2015 +0000

    dm space map metadata: fix ref counting bug when bootstrapping a new space map
    
    commit 50dd842ad83b43bed71790efb31cfb2f6c05c9c1 upstream.
    
    When applying block operations (BOPs) do not remove them from the
    uncommitted BOP ring-buffer until after they've been applied -- in case
    we recurse.
    
    Also, perform BOP_INC operation, in dm_sm_metadata_create() and
    sm_metadata_extend(), in terms of the uncommitted BOP ring-buffer rather
    than using direct calls to sm_ll_inc().
    
    Signed-off-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a9a7b4e292fd37f896748affa1ab69015e64dad
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Thu Nov 26 12:00:59 2015 -0500

    sata_sil: disable trim
    
    commit d98f1cd0a3b70ea91f1dfda3ac36c3b2e1a4d5e2 upstream.
    
    When I connect an Intel SSD to SATA SIL controller (PCI ID 1095:3114), any
    TRIM command results in I/O errors being reported in the log. There is
    other similar error reported with TRIM and the SIL controller:
    https://bugs.centos.org/view.php?id=5880
    
    Apparently the controller doesn't support TRIM commands. This patch
    disables TRIM support on the SATA SIL controller.
    
    ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
    ata7.00: BMDMA2 stat 0x50001
    ata7.00: failed command: DATA SET MANAGEMENT
    ata7.00: cmd 06/01:01:00:00:00/00:00:00:00:00/a0 tag 0 dma 512 out
             res 51/04:01:00:00:00/00:00:00:00:00/a0 Emask 0x1 (device error)
    ata7.00: status: { DRDY ERR }
    ata7.00: error: { ABRT }
    ata7.00: device reported invalid CHS sector 0
    sd 8:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
    sd 8:0:0:0: [sdb] tag#0 Sense Key : Illegal Request [current] [descriptor]
    sd 8:0:0:0: [sdb] tag#0 Add. Sense: Unaligned write command
    sd 8:0:0:0: [sdb] tag#0 CDB: Write same(16) 93 08 00 00 00 00 00 21 95 88 00 20 00 00 00 00
    blk_update_request: I/O error, dev sdb, sector 2200968
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df7a5f94f075e5ee962d7009ce2c9c15f207e63f
Author: Sasha Levin <sasha.levin@oracle.com>
Date:   Mon Nov 30 20:34:20 2015 -0500

    sched/core: Remove false-positive warning from wake_up_process()
    
    commit 119d6f6a3be8b424b200dcee56e74484d5445f7e upstream.
    
    Because wakeups can (fundamentally) be late, a task might not be in
    the expected state. Therefore testing against a task's state is racy,
    and can yield false positives.
    
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Mike Galbraith <efault@gmx.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: oleg@redhat.com
    Fixes: 9067ac85d533 ("wake_up_process() should be never used to wakeup a TASK_STOPPED/TRACED task")
    Link: http://lkml.kernel.org/r/1448933660-23082-1-git-send-email-sasha.levin@oracle.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 88bec78f852374545641a5a23049dc6ead58d570
Author: Xunlei Pang <xlpang@redhat.com>
Date:   Wed Dec 2 19:52:59 2015 +0800

    sched/core: Clear the root_domain cpumasks in init_rootdomain()
    
    commit 8295c69925ad53ec32ca54ac9fc194ff21bc40e2 upstream.
    
    root_domain::rto_mask allocated through alloc_cpumask_var()
    contains garbage data, this may cause problems. For instance,
    When doing pull_rt_task(), it may do useless iterations if
    rto_mask retains some extra garbage bits. Worse still, this
    violates the isolated domain rule for clustered scheduling
    using cpuset, because the tasks(with all the cpus allowed)
    belongs to one root domain can be pulled away into another
    root domain.
    
    The patch cleans the garbage by using zalloc_cpumask_var()
    instead of alloc_cpumask_var() for root_domain::rto_mask
    allocation, thereby addressing the issues.
    
    Do the same thing for root_domain's other cpumask memembers:
    dlo_mask, span, and online.
    
    Signed-off-by: Xunlei Pang <xlpang@redhat.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Mike Galbraith <efault@gmx.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/1449057179-29321-1-git-send-email-xlpang@redhat.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c4e04f090eac8430e3b42212b5d6f16806ee9787
Author: Mirza Krak <mirza.krak@hostmobility.com>
Date:   Tue Nov 10 14:59:34 2015 +0100

    can: sja1000: clear interrupts on start
    
    commit 7cecd9ab80f43972c056dc068338f7bcc407b71c upstream.
    
    According to SJA1000 data sheet error-warning (EI) interrupt is not
    cleared by setting the controller in to reset-mode.
    
    Then if we have the following case:
    - system is suspended (echo mem > /sys/power/state) and SJA1000 is left
      in operating state
    - A bus error condition occurs which activates EI interrupt, system is
      still suspended which means EI interrupt will be not be handled nor
      cleared.
    
    If the above two events occur, on resume there is no way to return the
    SJA1000 to operating state, except to cycle power to it.
    
    By simply reading the IR register on start we will clear any previous
    conditions that could be present.
    
    Signed-off-by: Mirza Krak <mirza.krak@hostmobility.com>
    Reported-by: Christian Magnusson <Christian.Magnusson@semcon.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ef8d4d93d242c0153d00ab782a18befdbef35dcc
Author: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Date:   Tue Nov 24 17:13:21 2015 -0500

    RDS: fix race condition when sending a message on unbound socket
    
    commit 8c7188b23474cca017b3ef354c4a58456f68303a upstream.
    
    Sasha's found a NULL pointer dereference in the RDS connection code when
    sending a message to an apparently unbound socket.  The problem is caused
    by the code checking if the socket is bound in rds_sendmsg(), which checks
    the rs_bound_addr field without taking a lock on the socket.  This opens a
    race where rs_bound_addr is temporarily set but where the transport is not
    in rds_bind(), leading to a NULL pointer dereference when trying to
    dereference 'trans' in __rds_conn_create().
    
    Vegard wrote a reproducer for this issue, so kindly ask him to share if
    you're interested.
    
    I cannot reproduce the NULL pointer dereference using Vegard's reproducer
    with this patch, whereas I could without.
    
    Complete earlier incomplete fix to CVE-2015-6937:
    
      74e98eb08588 ("RDS: verify the underlying transport exists before creating a connection")
    
    Reviewed-by: Vegard Nossum <vegard.nossum@oracle.com>
    Reviewed-by: Sasha Levin <sasha.levin@oracle.com>
    Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
    Signed-off-by: Quentin Casasnovas <quentin.casasnovas@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1e65a06366da51b0b5c5b2c77804be1529406842
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Nov 17 14:25:21 2015 +0100

    mac80211: mesh: fix call_rcu() usage
    
    commit c2e703a55245bfff3db53b1f7cbe59f1ee8a4339 upstream.
    
    When using call_rcu(), the called function may be delayed quite
    significantly, and without a matching rcu_barrier() there's no
    way to be sure it has finished.
    Therefore, global state that could be gone/freed/reused should
    never be touched in the callback.
    
    Fix this in mesh by moving the atomic_dec() into the caller;
    that's not really a problem since we already unlinked the path
    and it will be destroyed anyway.
    
    This fixes a crash Jouni observed when running certain tests in
    a certain order, in which the mesh interface was torn down, the
    memory reused for a function pointer (work struct) and running
    that then crashed since the pointer had been decremented by 1,
    resulting in an invalid instruction byte stream.
    
    Fixes: eb2b9311fd00 ("mac80211: mesh path table implementation")
    Reported-by: Jouni Malinen <j@w1.fi>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c08efea2e18f6ea6931d619e27fbe900e3af9ad
Author: Suman Anna <s-anna@ti.com>
Date:   Wed Sep 16 19:29:17 2015 -0500

    virtio: fix memory leak of virtio ida cache layers
    
    commit c13f99b7e945dad5273a8b7ee230f4d1f22d3354 upstream.
    
    The virtio core uses a static ida named virtio_index_ida for
    assigning index numbers to virtio devices during registration.
    The ida core may allocate some internal idr cache layers and
    an ida bitmap upon any ida allocation, and all these layers are
    truely freed only upon the ida destruction. The virtio_index_ida
    is not destroyed at present, leading to a memory leak when using
    the virtio core as a module and atleast one virtio device is
    registered and unregistered.
    
    Fix this by invoking ida_destroy() in the virtio core module
    exit.
    
    Signed-off-by: Suman Anna <s-anna@ti.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6fa733e9dba350f1c4de4ff3cde8ee0afc9243e5
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Mon Nov 23 10:35:36 2015 -0500

    ring-buffer: Update read stamp with first real commit on page
    
    commit b81f472a208d3e2b4392faa6d17037a89442f4ce upstream.
    
    Do not update the read stamp after swapping out the reader page from the
    write buffer. If the reader page is swapped out of the buffer before an
    event is written to it, then the read_stamp may get an out of date
    timestamp, as the page timestamp is updated on the first commit to that
    page.
    
    rb_get_reader_page() only returns a page if it has an event on it, otherwise
    it will return NULL. At that point, check if the page being returned has
    events and has not been read yet. Then at that point update the read_stamp
    to match the time stamp of the reader page.
    
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c190c2adcc896df5be428c77506d95ca28228e7a
Author: Jan Engelhardt <jengelh@inai.de>
Date:   Mon Nov 23 17:46:32 2015 +0100

    target: fix COMPARE_AND_WRITE non zero SGL offset data corruption
    
    commit d94e5a61357a04938ce14d6033b4d33a3c5fd780 upstream.
    
    target_core_sbc's compare_and_write functionality suffers from taking
    data at the wrong memory location when writing a CAW request to disk
    when a SGL offset is non-zero.
    
    This can happen with loopback and vhost-scsi fabric drivers when
    SCF_PASSTHROUGH_SG_TO_MEM_NOALLOC is used to map existing user-space
    SGL memory into COMPARE_AND_WRITE READ/WRITE payload buffers.
    
    Given the following sample LIO subtopology,
    
    % targetcli ls /loopback/
    o- loopback ................................. [1 Target]
      o- naa.6001405ebb8df14a ....... [naa.60014059143ed2b3]
        o- luns ................................... [2 LUNs]
          o- lun0 ................ [iblock/ram0 (/dev/ram0)]
          o- lun1 ................ [iblock/ram1 (/dev/ram1)]
    % lsscsi -g
    [3:0:1:0]    disk    LIO-ORG  IBLOCK           4.0   /dev/sdc   /dev/sg3
    [3:0:1:1]    disk    LIO-ORG  IBLOCK           4.0   /dev/sdd   /dev/sg4
    
    the following bug can be observed in Linux 4.3 and 4.4~rc1:
    
    % perl -e 'print chr$_ for 0..255,reverse 0..255' >rand
    % perl -e 'print "\0" x 512' >zero
    % cat rand >/dev/sdd
    % sg_compare_and_write -i rand -D zero --lba 0 /dev/sdd
    % sg_compare_and_write -i zero -D rand --lba 0 /dev/sdd
    Miscompare reported
    % hexdump -Cn 512 /dev/sdd
    00000000  0f 0e 0d 0c 0b 0a 09 08  07 06 05 04 03 02 01 00
    00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
    *
    00000200
    
    Rather than writing all-zeroes as instructed with the -D file, it
    corrupts the data in the sector by splicing some of the original
    bytes in. The page of the first entry of cmd->t_data_sg includes the
    CDB, and sg->offset is set to a position past the CDB. I presume that
    sg->offset is also the right choice to use for subsequent sglist
    members.
    
    Signed-off-by: Jan Engelhardt <jengelh@netitwork.de>
    Tested-by: Douglas Gilbert <dgilbert@interlog.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 99853deb97618d86d663b9e22ed9968f7461957b
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Thu Nov 5 23:37:59 2015 -0800

    target: Fix race for SCF_COMPARE_AND_WRITE_POST checking
    
    commit 057085e522f8bf94c2e691a5b76880f68060f8ba upstream.
    
    This patch addresses a race + use after free where the first
    stage of COMPARE_AND_WRITE in compare_and_write_callback()
    is rescheduled after the backend sends the secondary WRITE,
    resulting in second stage compare_and_write_post() callback
    completing in target_complete_ok_work() before the first
    can return.
    
    Because current code depends on checking se_cmd->se_cmd_flags
    after return from se_cmd->transport_complete_callback(),
    this results in first stage having SCF_COMPARE_AND_WRITE_POST
    set, which incorrectly falls through into second stage CAW
    processing code, eventually triggering a NULL pointer
    dereference due to use after free.
    
    To address this bug, pass in a new *post_ret parameter into
    se_cmd->transport_complete_callback(), and depend upon this
    value instead of ->se_cmd_flags to determine when to return
    or fall through into ->queue_status() code for CAW.
    
    Cc: Sagi Grimberg <sagig@mellanox.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d2ac4bf5d05b52a428ee7f8cdadd09fc96d66537
Author: Jan Kara <jack@suse.cz>
Date:   Mon Nov 23 13:09:51 2015 +0100

    vfs: Avoid softlockups with sendfile(2)
    
    commit c2489e07c0a71a56fb2c84bc0ee66cddfca7d068 upstream.
    
    The following test program from Dmitry can cause softlockups or RCU
    stalls as it copies 1GB from tmpfs into eventfd and we don't have any
    scheduling point at that path in sendfile(2) implementation:
    
            int r1 = eventfd(0, 0);
            int r2 = memfd_create("", 0);
            unsigned long n = 1<<30;
            fallocate(r2, 0, 0, n);
            sendfile(r1, r2, 0, n);
    
    Add cond_resched() into __splice_from_pipe() to fix the problem.
    
    CC: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 31ab5afaaf6ddb7590f0ccc5974e7303dc62f11e
Author: Vineet Gupta <vgupta@synopsys.com>
Date:   Mon Nov 23 19:32:51 2015 +0530

    ARC: dw2 unwind: Remove falllback linear search thru FDE entries
    
    commit 2e22502c080f27afeab5e6f11e618fb7bc7aea53 upstream.
    
    Fixes STAR 9000953410: "perf callgraph profiling causing RCU stalls"
    
    | perf record -g -c 15000 -e cycles /sbin/hackbench
    |
    | INFO: rcu_preempt self-detected stall on CPU
    | 1: (1 GPs behind) idle=609/140000000000002/0 softirq=2914/2915 fqs=603
    | Task dump for CPU 1:
    
    in-kernel dwarf unwinder has a fast binary lookup and a fallback linear
    search (which iterates thru each of ~11K entries) thus takes 2 orders of
    magnitude longer (~3 million cycles vs. 2000). Routines written in hand
    assembler lack dwarf info (as we don't support assembler CFI pseudo-ops
    yet) fail the unwinder binary lookup, hit linear search, failing
    nevertheless in the end.
    
    However the linear search is pointless as binary lookup tables are created
    from it in first place. It is impossible to have binary lookup fail while
    succeed the linear search. It is pure waste of cycles thus removed by
    this patch.
    
    This manifested as RCU stalls / NMI watchdog splat when running
    hackbench under perf with callgraph profiling. The triggering condition
    was perf counter overflowing in routine lacking dwarf info (like memset)
    leading to patheic 3 million cycle unwinder slow path and by the time it
    returned new interrupts were already pending (Timer, IPI) and taken
    rightaway. The original memset didn't make forward progress, system kept
    accruing more interrupts and more unwinder delayes in a vicious feedback
    loop, ultimately triggering the NMI diagnostic.
    
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f4f03c4a1e9a4b9679feafe7625a780864a4e76
Author: Kees Cook <keescook@chromium.org>
Date:   Thu Nov 19 17:18:54 2015 -0800

    mac: validate mac_partition is within sector
    
    commit 02e2a5bfebe99edcf9d694575a75032d53fe1b73 upstream.
    
    If md->signature == MAC_DRIVER_MAGIC and md->block_size == 1023, a single
    512 byte sector would be read (secsize / 512). However the partition
    structure would be located past the end of the buffer (secsize % 512).
    
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6eca392d950c5737d02005252b519981d91412fb
Author: Luca Porzio <lporzio@micron.com>
Date:   Fri Nov 6 15:12:26 2015 +0000

    mmc: remove bondage between REQ_META and reliable write
    
    commit d3df0465db00cf4ed9f90d0bfc3b827d32b9c796 upstream.
    
    Anytime a write operation is performed with Reliable Write flag enabled,
    the eMMC device is enforced to bypass the cache and do a write to the
    underling NVM device by Jedec specification; this causes a performance
    penalty since write operations can't be optimized by the device cache.
    
    In our tests, we replayed a typical mobile daily trace pattern and found
    ~9% overall time reduction in trace replay by using this patch. Also the
    write ops within 4KB~64KB chunk size range get a 40~60% performance
    improvement by using the patch (as this range of write chunks are the ones
    affected by REQ_META).
    
    This patch has been discussed in the Mobile & Embedded Linux Storage Forum
    and it's the results of feedbacks from many people. We also checked with
    fsdevl and f2fs mailing list developers that this change in the usage of
    REQ_META is not affecting FS behavior and we got positive feedbacks.
    Reporting here the feedbacks:
    http://comments.gmane.org/gmane.linux.file-systems/97219
    http://thread.gmane.org/gmane.linux.file-systems.f2fs/3178/focus=3183
    
    Signed-off-by: Bruce Ford <bford@micron.com>
    Signed-off-by: Luca Porzio <lporzio@micron.com>
    Fixes: ce39f9d17c14 ("mmc: support packed write command for eMMC4.5 devices")
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ca9d9fb376b4cf94bdb9d71bca0d3ac89f32427f
Author: K. Y. Srinivasan <kys@microsoft.com>
Date:   Mon Aug 31 08:21:54 2015 -0700

    storvsc: Don't set the SRB_FLAGS_QUEUE_ACTION_ENABLE flag
    
    commit 8cf308e1225f5f93575f03cc4dbef24516fa81c9 upstream.
    
    Don't set the SRB_FLAGS_QUEUE_ACTION_ENABLE flag since we are not specifying
    tags.  Without this, the qlogic driver doesn't work properly with storvsc.
    
    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
    Signed-off-by: James Bottomley <JBottomley@Odin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f1c308e86f3a30c54af519591a3fb3e66d6050e2
Author: sumit.saxena@avagotech.com <sumit.saxena@avagotech.com>
Date:   Thu Oct 15 13:40:54 2015 +0530

    megaraid_sas : SMAP restriction--do not access user memory from IOCTL code
    
    commit 323c4a02c631d00851d8edc4213c4d184ef83647 upstream.
    
    This is an issue on SMAP enabled CPUs and 32 bit apps running on 64 bit
    OS. Do not access user memory from kernel code. The SMAP bit restricts
    accessing user memory from kernel code.
    
    Signed-off-by: Sumit Saxena <sumit.saxena@avagotech.com>
    Signed-off-by: Kashyap Desai <kashyap.desai@avagotech.com>
    Reviewed-by: Tomas Henzl <thenzl@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b081b34d613f2b87b34a7ce349816b4cb3e9cb7d
Author: sumit.saxena@avagotech.com <sumit.saxena@avagotech.com>
Date:   Thu Oct 15 13:40:04 2015 +0530

    megaraid_sas: Do not use PAGE_SIZE for max_sectors
    
    commit 357ae967ad66e357f78b5cfb5ab6ca07fb4a7758 upstream.
    
    Do not use PAGE_SIZE marco to calculate max_sectors per I/O
    request. Driver code assumes PAGE_SIZE will be always 4096 which can
    lead to wrongly calculated value if PAGE_SIZE is not 4096. This issue
    was reported in Ubuntu Bugzilla Bug #1475166.
    
    Signed-off-by: Sumit Saxena <sumit.saxena@avagotech.com>
    Signed-off-by: Kashyap Desai <kashyap.desai@avagotech.com>
    Reviewed-by: Tomas Henzl <thenzl@redhat.com>
    Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b9f2d7c9b199d6f65a23bb7ec469a116e07bfe8c
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Mon Sep 28 18:57:04 2015 +0300

    dmaengine: dw: convert to __ffs()
    
    commit 39416677b95bf1ab8bbfa229ec7e511c96ad5d0c upstream.
    
    We replace __fls() by __ffs() since we have to find a *minimum* data width that
    satisfies both source and destination.
    
    While here, rename dwc_fast_fls() to dwc_fast_ffs() which it really is.
    
    Fixes: 4c2d56c574db (dw_dmac: introduce dwc_fast_fls())
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 45b0335f5ae64a817b8fec25d6ca6840841f4b7b
Author: Valentin Rothberg <valentinrothberg@gmail.com>
Date:   Tue Sep 22 19:00:40 2015 +0200

    wm831x_power: Use IRQF_ONESHOT to request threaded IRQs
    
    commit 90adf98d9530054b8e665ba5a928de4307231d84 upstream.
    
    Since commit 1c6c69525b40 ("genirq: Reject bogus threaded irq requests")
    threaded IRQs without a primary handler need to be requested with
    IRQF_ONESHOT, otherwise the request will fail.
    
    scripts/coccinelle/misc/irqf_oneshot.cocci detected this issue.
    
    Fixes: b5874f33bbaf ("wm831x_power: Use genirq")
    Signed-off-by: Valentin Rothberg <valentinrothberg@gmail.com>
    Signed-off-by: Sebastian Reichel <sre@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a255d55190d702c217eef87de067b14c25a5c2d2
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Sep 21 19:21:51 2015 +0300

    devres: fix a for loop bounds check
    
    commit 1f35d04a02a652f14566f875aef3a6f2af4cb77b upstream.
    
    The iomap[] array has PCIM_IOMAP_MAX (6) elements and not
    DEVICE_COUNT_RESOURCE (16).  This bug was found using a static checker.
    It may be that the "if (!(mask & (1 << i)))" check means we never
    actually go past the end of the array in real life.
    
    Fixes: ec04b075843d ('iomap: implement pcim_iounmap_regions()')
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e7f460fef9a6d391abfca3b9819de348e449461e
Author: Andrey Ryabinin <aryabinin@virtuozzo.com>
Date:   Wed Sep 23 15:49:29 2015 +0300

    lockd: create NSM handles per net namespace
    
    commit 0ad95472bf169a3501991f8f33f5147f792a8116 upstream.
    
    Commit cb7323fffa85 ("lockd: create and use per-net NSM
     RPC clients on MON/UNMON requests") introduced per-net
    NSM RPC clients. Unfortunately this doesn't make any sense
    without per-net nsm_handle.
    
    E.g. the following scenario could happen
    Two hosts (X and Y) in different namespaces (A and B) share
    the same nsm struct.
    
    1. nsm_monitor(host_X) called => NSM rpc client created,
    	nsm->sm_monitored bit set.
    2. nsm_mointor(host-Y) called => nsm->sm_monitored already set,
    	we just exit. Thus in namespace B ln->nsm_clnt == NULL.
    3. host X destroyed => nsm->sm_count decremented to 1
    4. host Y destroyed => nsm_unmonitor() => nsm_mon_unmon() => NULL-ptr
    	dereference of *ln->nsm_clnt
    
    So this could be fixed by making per-net nsm_handles list,
    instead of global. Thus different net namespaces will not be able
    share the same nsm_handle.
    
    Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4eed7b9c2f5c7beceeca333436768cd9fdc2dbe7
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Nov 23 16:43:29 2015 -0500

    drm/radeon: make rv770_set_sw_state failures non-fatal
    
    commit 4e7697ed79d0c0d5f869c87a6b3ce3d5cd1a07d6 upstream.
    
    On some cards it takes a relatively long time for the change
    to take place.  Make a timeout non-fatal.
    
    bug:
    https://bugs.freedesktop.org/show_bug.cgi?id=76130
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 10cdad157d42a3bea75c2d4d6e2caf7f6f2e4e78
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Nov 10 13:01:35 2015 -0500

    drm/radeon: unconditionally set sysfs_initialized
    
    commit 24dd2f64c5a877392925202321c7c2c46c2b0ddf upstream.
    
    Avoids spew on resume for systems where sysfs may
    fail even on init.
    
    bug:
    https://bugzilla.kernel.org/show_bug.cgi?id=106851
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e71a1817e2882753b83fbb4cff8e60b88fb0e0d
Author: NeilBrown <neilb@suse.com>
Date:   Thu Jan 7 11:02:34 2016 +1100

    async_tx: use GFP_NOWAIT rather than GFP_IO
    
    commit b02bab6b0f928d49dbfb03e1e4e9dd43647623d7 upstream.
    
    These async_XX functions are called from md/raid5 in an atomic
    section, between get_cpu() and put_cpu(), so they must not sleep.
    So use GFP_NOWAIT rather than GFP_IO.
    
    Dan Williams writes: Longer term async_tx needs to be merged into md
    directly as we can allocate this unmap data statically per-stripe
    rather than per request.
    
    Fixed: 7476bd79fc01 ("async_pq: convert to dmaengine_unmap_data")
    Reported-and-tested-by: Stanislav Samsonov <slava@annapurnalabs.com>
    Acked-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: NeilBrown <neilb@suse.com>
    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 194770bb72f1c59c7f0872635a30dde361c9dfc7
Author: Roman Volkov <rvolkov@v1ros.org>
Date:   Fri Jan 1 16:24:41 2016 +0300

    clocksource/drivers/vt8500: Increase the minimum delta
    
    commit f9eccf24615672896dc13251410c3f2f33a14f95 upstream.
    
    The vt8500 clocksource driver declares itself as capable to handle the
    minimum delay of 4 cycles by passing the value into
    clockevents_config_and_register(). The vt8500_timer_set_next_event()
    requires the passed cycles value to be at least 16. The impact is that
    userspace hangs in nanosleep() calls with small delay intervals.
    
    This problem is reproducible in Linux 4.2 starting from:
    c6eb3f70d448 ('hrtimer: Get rid of hrtimer softirq')
    
    From Russell King, more detailed explanation:
    
    "It's a speciality of the StrongARM/PXA hardware. It takes a certain
    number of OSCR cycles for the value written to hit the compare registers.
    So, if a very small delta is written (eg, the compare register is written
    with a value of OSCR + 1), the OSCR will have incremented past this value
    before it hits the underlying hardware. The result is, that you end up
    waiting a very long time for the OSCR to wrap before the event fires.
    
    So, we introduce a check in set_next_event() to detect this and return
    -ETIME if the calculated delta is too small, which causes the generic
    clockevents code to retry after adding the min_delta specified in
    clockevents_config_and_register() to the current time value.
    
    min_delta must be sufficient that we don't re-trip the -ETIME check - if
    we do, we will return -ETIME, forward the next event time, try to set it,
    return -ETIME again, and basically lock the system up. So, min_delta
    must be larger than the check inside set_next_event(). A factor of two
    was chosen to ensure that this situation would never occur.
    
    The PXA code worked on PXA systems for years, and I'd suggest no one
    changes this mechanism without access to a wide range of PXA systems,
    otherwise they're risking breakage."
    
    Cc: Russell King <linux@arm.linux.org.uk>
    Acked-by: Alexey Charkov <alchark@gmail.com>
    Signed-off-by: Roman Volkov <rvolkov@v1ros.org>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9ba2f080fb5fc14f966f864f694101721dc04fef
Author: Roman Volkov <rvolkov@v1ros.org>
Date:   Fri Jan 1 16:38:11 2016 +0300

    dts: vt8500: Add SDHC node to DTS file for WM8650
    
    commit 0f090bf14e51e7eefb71d9d1c545807f8b627986 upstream.
    
    Since WM8650 has the same 'WMT' SDHC controller as WM8505, and the driver
    is already in the kernel, this node enables the controller support for
    WM8650
    
    Signed-off-by: Roman Volkov <rvolkov@v1ros.org>
    Reviewed-by: Alexey Charkov <alchark@gmail.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c6dc876f00e5e01a0b91778f409b5ab3d607089
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sun Dec 13 18:12:30 2015 +0100

    genirq: Prevent chip buslock deadlock
    
    commit abc7e40c81d113ef4bacb556f0a77ca63ac81d85 upstream.
    
    If a interrupt chip utilizes chip->buslock then free_irq() can
    deadlock in the following way:
    
    CPU0				CPU1
    				interrupt(X) (Shared or spurious)
    free_irq(X)			interrupt_thread(X)
    chip_bus_lock(X)
    				   irq_finalize_oneshot(X)
    				     chip_bus_lock(X)
    synchronize_irq(X)
    
    synchronize_irq() waits for the interrupt thread to complete,
    i.e. forever.
    
    Solution is simple: Drop chip_bus_lock() before calling
    synchronize_irq() as we do with the irq_desc lock. There is nothing to
    be protected after the point where irq_desc lock has been released.
    
    This adds chip_bus_lock/unlock() to the remove_irq() code path, but
    that's actually correct in the case where remove_irq() is called on
    such an interrupt. The current users of remove_irq() are not affected
    as none of those interrupts is on a chip which requires buslock.
    
    Reported-by: Fredrik Markström <fredrik.markstrom@gmail.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4901294a76c258e2a6fdaf216ce8ccecfce12f7a
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Thu Jun 11 14:46:43 2015 +0200

    sched, dl: Convert switched_{from, to}_dl() / prio_changed_dl() to balance callbacks
    
    commit 9916e214998a4a363b152b637245e5c958067350 upstream.
    
    Remove the direct {push,pull} balancing operations from
    switched_{from,to}_dl() / prio_changed_dl() and use the balance
    callback queue.
    
    Again, err on the side of too many reschedules; since too few is a
    hard bug while too many is just annoying.
    
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: ktkhai@parallels.com
    Cc: rostedt@goodmis.org
    Cc: juri.lelli@gmail.com
    Cc: pang.xunlei@linaro.org
    Cc: oleg@redhat.com
    Cc: wanpeng.li@linux.intel.com
    Cc: umgwanakikbuti@gmail.com
    Link: http://lkml.kernel.org/r/20150611124742.968262663@infradead.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Byungchul Park <byungchul.park@lge.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c8356b2924b63026132b48de14fa9a896e4fc85b
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Thu Jun 11 14:46:42 2015 +0200

    sched,dl: Remove return value from pull_dl_task()
    
    commit 0ea60c2054fc3b0c3eb68ac4f6884f3ee78d9925 upstream.
    
    In order to be able to use pull_dl_task() from a callback, we need to
    do away with the return value.
    
    Since the return value indicates if we should reschedule, do this
    inside the function. Since not all callers currently do this, this can
    increase the number of reschedules due rt balancing.
    
    Too many reschedules is not a correctness issues, too few are.
    
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: ktkhai@parallels.com
    Cc: rostedt@goodmis.org
    Cc: juri.lelli@gmail.com
    Cc: pang.xunlei@linaro.org
    Cc: oleg@redhat.com
    Cc: wanpeng.li@linux.intel.com
    Cc: umgwanakikbuti@gmail.com
    Link: http://lkml.kernel.org/r/20150611124742.859398977@infradead.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Byungchul Park <byungchul.park@lge.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb62b0e9078675f3ecfdbb623748d863af93d179
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Thu Jun 11 14:46:41 2015 +0200

    sched, rt: Convert switched_{from, to}_rt() / prio_changed_rt() to balance callbacks
    
    commit fd7a4bed183523275279c9addbf42fce550c2e90 upstream.
    
    Remove the direct {push,pull} balancing operations from
    switched_{from,to}_rt() / prio_changed_rt() and use the balance
    callback queue.
    
    Again, err on the side of too many reschedules; since too few is a
    hard bug while too many is just annoying.
    
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: ktkhai@parallels.com
    Cc: rostedt@goodmis.org
    Cc: juri.lelli@gmail.com
    Cc: pang.xunlei@linaro.org
    Cc: oleg@redhat.com
    Cc: wanpeng.li@linux.intel.com
    Cc: umgwanakikbuti@gmail.com
    Link: http://lkml.kernel.org/r/20150611124742.766832367@infradead.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Byungchul Park <byungchul.park@lge.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f664a58c2222b97b2f96478b6df54da8d52cb91e
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Thu Jun 11 14:46:40 2015 +0200

    sched,rt: Remove return value from pull_rt_task()
    
    commit 8046d6806247088de5725eaf8a2580b29e50ac5a upstream.
    
    In order to be able to use pull_rt_task() from a callback, we need to
    do away with the return value.
    
    Since the return value indicates if we should reschedule, do this
    inside the function. Since not all callers currently do this, this can
    increase the number of reschedules due rt balancing.
    
    Too many reschedules is not a correctness issues, too few are.
    
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: ktkhai@parallels.com
    Cc: rostedt@goodmis.org
    Cc: juri.lelli@gmail.com
    Cc: pang.xunlei@linaro.org
    Cc: oleg@redhat.com
    Cc: wanpeng.li@linux.intel.com
    Cc: umgwanakikbuti@gmail.com
    Link: http://lkml.kernel.org/r/20150611124742.679002000@infradead.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Byungchul Park <byungchul.park@lge.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad11cd879b413a2c98eeb0b9fa26b08ede092365
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Thu Jun 11 14:46:39 2015 +0200

    sched: Allow balance callbacks for check_class_changed()
    
    commit 4c9a4bc89a9cca8128bce67d6bc8870d6b7ee0b2 upstream.
    
    In order to remove dropping rq->lock from the
    switched_{to,from}()/prio_changed() sched_class methods, run the
    balance callbacks after it.
    
    We need to remove dropping rq->lock because its buggy,
    suppose using sched_setattr()/sched_setscheduler() to change a running
    task from FIFO to OTHER.
    
    By the time we get to switched_from_rt() the task is already enqueued
    on the cfs runqueues. If switched_from_rt() does pull_rt_task() and
    drops rq->lock, load-balancing can come in and move our task @p to
    another rq.
    
    The subsequent switched_to_fair() still assumes @p is on @rq and bad
    things will happen.
    
    By using balance callbacks we delay the load-balancing operations
    {rt,dl}x{push,pull} until we've done all the important work and the
    task is fully set up.
    
    Furthermore, the balance callbacks do not know about @p, therefore
    they cannot get confused like this.
    
    Reported-by: Mike Galbraith <umgwanakikbuti@gmail.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: ktkhai@parallels.com
    Cc: rostedt@goodmis.org
    Cc: juri.lelli@gmail.com
    Cc: pang.xunlei@linaro.org
    Cc: oleg@redhat.com
    Cc: wanpeng.li@linux.intel.com
    Link: http://lkml.kernel.org/r/20150611124742.615343911@infradead.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Byungchul Park <byungchul.park@lge.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5bd91f42b43f877f3705f77684153b37b9ddd0e8
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Thu Jun 11 14:46:37 2015 +0200

    sched: Replace post_schedule with a balance callback list
    
    commit e3fca9e7cbfb72694a21c886fcdf9f059cfded9c upstream.
    
    Generalize the post_schedule() stuff into a balance callback list.
    This allows us to more easily use it outside of schedule() and cross
    sched_class.
    
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: ktkhai@parallels.com
    Cc: rostedt@goodmis.org
    Cc: juri.lelli@gmail.com
    Cc: pang.xunlei@linaro.org
    Cc: oleg@redhat.com
    Cc: wanpeng.li@linux.intel.com
    Cc: umgwanakikbuti@gmail.com
    Link: http://lkml.kernel.org/r/20150611124742.424032725@infradead.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Byungchul Park <byungchul.park@lge.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 15e9c1c43ab477e1256556adc3cf40132b7d2415
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Fri Jan 17 15:09:39 2014 +0100

    sched: Clean up idle task SMP logic
    
    commit 6c3b4d44ba2838f00614a5a2d777d4401e0bfd71 upstream.
    
    The idle post_schedule flag is just a vile waste of time, furthermore
    it appears unneeded, move the idle_enter_fair() call into
    pick_next_task_idle().
    
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
    Cc: Vincent Guittot <vincent.guittot@linaro.org>
    Cc: alex.shi@linaro.org
    Cc: mingo@kernel.org
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Link: http://lkml.kernel.org/n/tip-aljykihtxJt3mkokxi0qZurb@git.kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: Byungchul Park <byungchul.park@lge.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 780f6783bddda8603d919bba5707034714dbee71
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date:   Wed Feb 3 02:11:03 2016 +0100

    unix: correctly track in-flight fds in sending process user_struct
    
    commit 415e3d3e90ce9e18727e8843ae343eda5a58fad6 upstream.
    
    The commit referenced in the Fixes tag incorrectly accounted the number
    of in-flight fds over a unix domain socket to the original opener
    of the file-descriptor. This allows another process to arbitrary
    deplete the original file-openers resource limit for the maximum of
    open files. Instead the sending processes and its struct cred should
    be credited.
    
    To do so, we add a reference counted struct user_struct pointer to the
    scm_fp_list and use it to account for the number of inflight unix fds.
    
    Fixes: 712f4aad406bb1 ("unix: properly account for FDs passed over unix sockets")
    Reported-by: David Herrmann <dh.herrmann@gmail.com>
    Cc: David Herrmann <dh.herrmann@gmail.com>
    Cc: Willy Tarreau <w@1wt.eu>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fa03c8f459c4c66f50625e2df1151fdfcf056f85
Author: Manish Chopra <Manish.Chopra@qlogic.com>
Date:   Thu Jun 25 15:19:24 2015 +0300

    bnx2x: Don't notify about scratchpad parities
    
    commit ad6afbe9578d1fa26680faf78c846bd8c00d1d6e upstream.
    
    The scratchpad is a shared block between all functions of a given device.
    Due to HW limitations, we can't properly close its parity notifications
    to all functions on legal flows.
    E.g., it's possible that while taking a register dump from one function
    a parity error would be triggered on other functions.
    
    Today driver doesn't consider this parity as a 'real' parity unless its
    being accompanied by additional indications [which would happen in a real
    parity scenario]; But it does print notifications for such events in the
    system logs.
    
    This eliminates such prints - in case of real parities driver would have
    additional indications; But if this is the only signal user will not even
    see a parity being logged in the system.
    
    Signed-off-by: Manish Chopra <Manish.Chopra@qlogic.com>
    Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com>
    Signed-off-by: Ariel Elior <Ariel.Elior@qlogic.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Patrick Schaaf <netdev@bof.de>
    Tested-by: Patrick Schaaf <netdev@bof.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 85143efeae29cf306cf48c1a73563ae94fb57311
Author: Olga Kornievskaia <aglo@umich.edu>
Date:   Mon Sep 14 19:54:36 2015 -0400

    Failing to send a CLOSE if file is opened WRONLY and server reboots on a 4.x mount
    
    commit a41cbe86df3afbc82311a1640e20858c0cd7e065 upstream.
    
    A test case is as the description says:
    open(foobar, O_WRONLY);
    sleep()  --> reboot the server
    close(foobar)
    
    The bug is because in nfs4state.c in nfs4_reclaim_open_state() a few
    line before going to restart, there is
    clear_bit(NFS4CLNT_RECLAIM_NOGRACE, &state->flags).
    
    NFS4CLNT_RECLAIM_NOGRACE is a flag for the client states not open
    owner states. Value of NFS4CLNT_RECLAIM_NOGRACE is 4 which is the
    value of NFS_O_WRONLY_STATE in nfs4_state->flags. So clearing it wipes
    out state and when we go to close it, “call_close” doesn’t get set as
    state flag is not set and CLOSE doesn’t go on the wire.
    
    Signed-off-by: Olga Kornievskaia <aglo@umich.edu>
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d2733aa845a7160480317b418b1bbc6404d4d3e8
Author: Christophe Leroy <christophe.leroy@c-s.fr>
Date:   Wed May 6 17:26:47 2015 +0200

    splice: sendfile() at once fails for big files
    
    commit 0ff28d9f4674d781e492bcff6f32f0fe48cf0fed upstream.
    
    Using sendfile with below small program to get MD5 sums of some files,
    it appear that big files (over 64kbytes with 4k pages system) get a
    wrong MD5 sum while small files get the correct sum.
    This program uses sendfile() to send a file to an AF_ALG socket
    for hashing.
    
    /* md5sum2.c */
    #include <stdio.h>
    #include <stdlib.h>
    #include <unistd.h>
    #include <string.h>
    #include <fcntl.h>
    #include <sys/socket.h>
    #include <sys/stat.h>
    #include <sys/types.h>
    #include <linux/if_alg.h>
    
    int main(int argc, char **argv)
    {
    	int sk = socket(AF_ALG, SOCK_SEQPACKET, 0);
    	struct stat st;
    	struct sockaddr_alg sa = {
    		.salg_family = AF_ALG,
    		.salg_type = "hash",
    		.salg_name = "md5",
    	};
    	int n;
    
    	bind(sk, (struct sockaddr*)&sa, sizeof(sa));
    
    	for (n = 1; n < argc; n++) {
    		int size;
    		int offset = 0;
    		char buf[4096];
    		int fd;
    		int sko;
    		int i;
    
    		fd = open(argv[n], O_RDONLY);
    		sko = accept(sk, NULL, 0);
    		fstat(fd, &st);
    		size = st.st_size;
    		sendfile(sko, fd, &offset, size);
    		size = read(sko, buf, sizeof(buf));
    		for (i = 0; i < size; i++)
    			printf("%2.2x", buf[i]);
    		printf("  %s\n", argv[n]);
    		close(fd);
    		close(sko);
    	}
    	exit(0);
    }
    
    Test below is done using official linux patch files. First result is
    with a software based md5sum. Second result is with the program above.
    
    root@vgoip:~# ls -l patch-3.6.*
    -rw-r--r--    1 root     root         64011 Aug 24 12:01 patch-3.6.2.gz
    -rw-r--r--    1 root     root         94131 Aug 24 12:01 patch-3.6.3.gz
    
    root@vgoip:~# md5sum patch-3.6.*
    b3ffb9848196846f31b2ff133d2d6443  patch-3.6.2.gz
    c5e8f687878457db77cb7158c38a7e43  patch-3.6.3.gz
    
    root@vgoip:~# ./md5sum2 patch-3.6.*
    b3ffb9848196846f31b2ff133d2d6443  patch-3.6.2.gz
    5fd77b24e68bb24dcc72d6e57c64790e  patch-3.6.3.gz
    
    After investivation, it appears that sendfile() sends the files by blocks
    of 64kbytes (16 times PAGE_SIZE). The problem is that at the end of each
    block, the SPLICE_F_MORE flag is missing, therefore the hashing operation
    is reset as if it was the end of the file.
    
    This patch adds SPLICE_F_MORE to the flags when more data is pending.
    
    With the patch applied, we get the correct sums:
    
    root@vgoip:~# md5sum patch-3.6.*
    b3ffb9848196846f31b2ff133d2d6443  patch-3.6.2.gz
    c5e8f687878457db77cb7158c38a7e43  patch-3.6.3.gz
    
    root@vgoip:~# ./md5sum2 patch-3.6.*
    b3ffb9848196846f31b2ff133d2d6443  patch-3.6.2.gz
    c5e8f687878457db77cb7158c38a7e43  patch-3.6.3.gz
    
    Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d596f66da6e1763fed39c8e76923a3a419d6f001
Author: Sasha Levin <sasha.levin@oracle.com>
Date:   Tue Sep 8 10:53:40 2015 -0400

    RDS: verify the underlying transport exists before creating a connection
    
    commit 74e98eb085889b0d2d4908f59f6e00026063014f upstream.
    
    There was no verification that an underlying transport exists when creating
    a connection, this would cause dereferencing a NULL ptr.
    
    It might happen on sockets that weren't properly bound before attempting to
    send a message, which will cause a NULL ptr deref:
    
    [135546.047719] kasan: GPF could be caused by NULL-ptr deref or user memory accessgeneral protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN
    [135546.051270] Modules linked in:
    [135546.051781] CPU: 4 PID: 15650 Comm: trinity-c4 Not tainted 4.2.0-next-20150902-sasha-00041-gbaa1222-dirty #2527
    [135546.053217] task: ffff8800835bc000 ti: ffff8800bc708000 task.ti: ffff8800bc708000
    [135546.054291] RIP: __rds_conn_create (net/rds/connection.c:194)
    [135546.055666] RSP: 0018:ffff8800bc70fab0  EFLAGS: 00010202
    [135546.056457] RAX: dffffc0000000000 RBX: 0000000000000f2c RCX: ffff8800835bc000
    [135546.057494] RDX: 0000000000000007 RSI: ffff8800835bccd8 RDI: 0000000000000038
    [135546.058530] RBP: ffff8800bc70fb18 R08: 0000000000000001 R09: 0000000000000000
    [135546.059556] R10: ffffed014d7a3a23 R11: ffffed014d7a3a21 R12: 0000000000000000
    [135546.060614] R13: 0000000000000001 R14: ffff8801ec3d0000 R15: 0000000000000000
    [135546.061668] FS:  00007faad4ffb700(0000) GS:ffff880252000000(0000) knlGS:0000000000000000
    [135546.062836] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    [135546.063682] CR2: 000000000000846a CR3: 000000009d137000 CR4: 00000000000006a0
    [135546.064723] Stack:
    [135546.065048]  ffffffffafe2055c ffffffffafe23fc1 ffffed00493097bf ffff8801ec3d0008
    [135546.066247]  0000000000000000 00000000000000d0 0000000000000000 ac194a24c0586342
    [135546.067438]  1ffff100178e1f78 ffff880320581b00 ffff8800bc70fdd0 ffff880320581b00
    [135546.068629] Call Trace:
    [135546.069028] ? __rds_conn_create (include/linux/rcupdate.h:856 net/rds/connection.c:134)
    [135546.069989] ? rds_message_copy_from_user (net/rds/message.c:298)
    [135546.071021] rds_conn_create_outgoing (net/rds/connection.c:278)
    [135546.071981] rds_sendmsg (net/rds/send.c:1058)
    [135546.072858] ? perf_trace_lock (include/trace/events/lock.h:38)
    [135546.073744] ? lockdep_init (kernel/locking/lockdep.c:3298)
    [135546.074577] ? rds_send_drop_to (net/rds/send.c:976)
    [135546.075508] ? __might_fault (./arch/x86/include/asm/current.h:14 mm/memory.c:3795)
    [135546.076349] ? __might_fault (mm/memory.c:3795)
    [135546.077179] ? rds_send_drop_to (net/rds/send.c:976)
    [135546.078114] sock_sendmsg (net/socket.c:611 net/socket.c:620)
    [135546.078856] SYSC_sendto (net/socket.c:1657)
    [135546.079596] ? SYSC_connect (net/socket.c:1628)
    [135546.080510] ? trace_dump_stack (kernel/trace/trace.c:1926)
    [135546.081397] ? ring_buffer_unlock_commit (kernel/trace/ring_buffer.c:2479 kernel/trace/ring_buffer.c:2558 kernel/trace/ring_buffer.c:2674)
    [135546.082390] ? trace_buffer_unlock_commit (kernel/trace/trace.c:1749)
    [135546.083410] ? trace_event_raw_event_sys_enter (include/trace/events/syscalls.h:16)
    [135546.084481] ? do_audit_syscall_entry (include/trace/events/syscalls.h:16)
    [135546.085438] ? trace_buffer_unlock_commit (kernel/trace/trace.c:1749)
    [135546.085515] rds_ib_laddr_check(): addr 36.74.25.172 ret -99 node type -1
    
    Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: "Charles (Chas) Williams" <3chas3@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit db449d873870aee9161edb9259d72254987ad7c0
Author: Marcelo Leitner <mleitner@redhat.com>
Date:   Mon Feb 23 11:17:13 2015 -0300

    ipv6: addrconf: validate new MTU before applying it
    
    commit 77751427a1ff25b27d47a4c36b12c3c8667855ac upstream.
    
    Currently we don't check if the new MTU is valid or not and this allows
    one to configure a smaller than minimum allowed by RFCs or even bigger
    than interface own MTU, which is a problem as it may lead to packet
    drops.
    
    If you have a daemon like NetworkManager running, this may be exploited
    by remote attackers by forging RA packets with an invalid MTU, possibly
    leading to a DoS. (NetworkManager currently only validates for values
    too small, but not for too big ones.)
    
    The fix is just to make sure the new value is valid. That is, between
    IPV6_MIN_MTU and interface's MTU.
    
    Note that similar check is already performed at
    ndisc_router_discovery(), for when kernel itself parses the RA.
    
    Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
    Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: "Charles (Chas) Williams" <3chas3@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bf229d804ba683af8ef708de84bc0d24aabcbf81
Author: James Hogan <james.hogan@imgtec.com>
Date:   Wed Nov 11 14:21:20 2015 +0000

    MIPS: KVM: Uninit VCPU in vcpu_create error path
    
    commit 585bb8f9a5e592f2ce7abbe5ed3112d5438d2754 upstream.
    
    If either of the memory allocations in kvm_arch_vcpu_create() fail, the
    vcpu which has been allocated and kvm_vcpu_init'd doesn't get uninit'd
    in the error handling path. Add a call to kvm_vcpu_uninit() to fix this.
    
    Fixes: 669e846e6c4e ("KVM/MIPS32: MIPS arch specific APIs for KVM")
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Gleb Natapov <gleb@kernel.org>
    Cc: linux-mips@linux-mips.org
    Cc: kvm@vger.kernel.org
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f1a718fd26af8108766882eebe8e69644d22cd43
Author: James Hogan <james.hogan@imgtec.com>
Date:   Wed Nov 11 14:21:19 2015 +0000

    MIPS: KVM: Fix CACHE immediate offset sign extension
    
    commit c5c2a3b998f1ff5a586f9d37e154070b8d550d17 upstream.
    
    The immediate field of the CACHE instruction is signed, so ensure that
    it gets sign extended by casting it to an int16_t rather than just
    masking the low 16 bits.
    
    Fixes: e685c689f3a8 ("KVM/MIPS32: Privileged instruction/target branch emulation.")
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Gleb Natapov <gleb@kernel.org>
    Cc: linux-mips@linux-mips.org
    Cc: kvm@vger.kernel.org
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2fde5f91217eaed9721a2973ca38541c75840699
Author: James Hogan <james.hogan@imgtec.com>
Date:   Wed Nov 11 14:21:18 2015 +0000

    MIPS: KVM: Fix ASID restoration logic
    
    commit 002374f371bd02df864cce1fe85d90dc5b292837 upstream.
    
    ASID restoration on guest resume should determine the guest execution
    mode based on the guest Status register rather than bit 30 of the guest
    PC.
    
    Fix the two places in locore.S that do this, loading the guest status
    from the cop0 area. Note, this assembly is specific to the trap &
    emulate implementation of KVM, so it doesn't need to check the
    supervisor bit as that mode is not implemented in the guest.
    
    Fixes: b680f70fc111 ("KVM/MIPS32: Entry point for trampolining to...")
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Gleb Natapov <gleb@kernel.org>
    Cc: linux-mips@linux-mips.org
    Cc: kvm@vger.kernel.org
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4d57edcd044c0a5e0ae5241ec51962f5219caee2
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Thu Jun 12 00:29:13 2014 -0400

    lock_parent: don't step on stale ->d_parent of all-but-freed one
    
    commit c2338f2dc7c1e9f6202f370c64ffd7f44f3d4b51 upstream.
    
    Dentry that had been through (or into) __dentry_kill() might be seen
    by shrink_dentry_list(); that's normal, it'll be taken off the shrink
    list and freed if __dentry_kill() has already finished.  The problem
    is, its ->d_parent might be pointing to already freed dentry, so
    lock_parent() needs to be careful.
    
    We need to check that dentry hasn't already gone into __dentry_kill()
    *and* grab rcu_read_lock() before dropping ->d_lock - the latter makes
    sure that whatever we see in ->d_parent after dropping ->d_lock it
    won't be freed until we drop rcu_read_lock().
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 001869c34bdefa35f021f2633ed37122cfd3aa2d
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat May 31 09:13:21 2014 -0700

    dcache: add missing lockdep annotation
    
    commit 9f12600fe425bc28f0ccba034a77783c09c15af4 upstream.
    
    lock_parent() very much on purpose does nested locking of dentries, and
    is careful to maintain the right order (lock parent first).  But because
    it didn't annotate the nested locking order, lockdep thought it might be
    a deadlock on d_lock, and complained.
    
    Add the proper annotation for the inner locking of the child dentry to
    make lockdep happy.
    
    Introduced by commit 046b961b45f9 ("shrink_dentry_list(): take parent's
    ->d_lock earlier").
    
    Reported-and-tested-by: Josh Boyer <jwboyer@fedoraproject.org>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b004c3a7f5ee27001a39892874c733d23b7ecbc6
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Thu May 29 09:18:26 2014 -0400

    dentry_kill() doesn't need the second argument now
    
    commit 8cbf74da435d1bd13dbb790f94c7ff67b2fb6af4 upstream.
    
    it's 1 in the only remaining caller.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6179fe3753519bb624d767c02f9b685642cc63df
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Thu May 29 09:11:45 2014 -0400

    dealing with the rest of shrink_dentry_list() livelock
    
    commit b2b80195d8829921506880f6dccd21cabd163d0d upstream.
    
    We have the same problem with ->d_lock order in the inner loop, where
    we are dropping references to ancestors.  Same solution, basically -
    instead of using dentry_kill() we use lock_parent() (introduced in the
    previous commit) to get that lock in a safe way, recheck ->d_count
    (in case if lock_parent() has ended up dropping and retaking ->d_lock
    and somebody managed to grab a reference during that window), trylock
    the inode->i_lock and use __dentry_kill() to do the rest.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 286adf77d94e8b57a620e6cdbdcc72d99d8609b3
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Thu May 29 08:54:52 2014 -0400

    shrink_dentry_list(): take parent's ->d_lock earlier
    
    commit 046b961b45f93a92e4c70525a12f3d378bced130 upstream.
    
    The cause of livelocks there is that we are taking ->d_lock on
    dentry and its parent in the wrong order, forcing us to use
    trylock on the parent's one.  d_walk() takes them in the right
    order, and unfortunately it's not hard to create a situation
    when shrink_dentry_list() can't make progress since trylock
    keeps failing, and shrink_dcache_parent() or check_submounts_and_drop()
    keeps calling d_walk() disrupting the very shrink_dentry_list() it's
    waiting for.
    
    Solution is straightforward - if that trylock fails, let's unlock
    the dentry itself and take locks in the right order.  We need to
    stabilize ->d_parent without holding ->d_lock, but that's doable
    using RCU.  And we'd better do that in the very beginning of the
    loop in shrink_dentry_list(), since the checks on refcount, etc.
    would need to be redone anyway.
    
    That deals with a half of the problem - killing dentries on the
    shrink list itself.  Another one (dropping their parents) is
    in the next commit.
    
    locking parent is interesting - it would be easy to do rcu_read_lock(),
    lock whatever we think is a parent, lock dentry itself and check
    if the parent is still the right one.  Except that we need to check
    that *before* locking the dentry, or we are risking taking ->d_lock
    out of order.  Fortunately, once the D1 is locked, we can check if
    D2->d_parent is equal to D1 without the need to lock D2; D2->d_parent
    can start or stop pointing to D1 only under D1->d_lock, so taking
    D1->d_lock is enough.  In other words, the right solution is
    rcu_read_lock/lock what looks like parent right now/check if it's
    still our parent/rcu_read_unlock/lock the child.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d2cac5b667889e625290f6fc758133baded7aa7b
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Wed May 28 13:59:13 2014 -0400

    expand dentry_kill(dentry, 0) in shrink_dentry_list()
    
    commit ff2fde9929feb2aef45377ce56b8b12df85dda69 upstream.
    
    Result will be massaged to saner shape in the next commits.  It is
    ugly, no questions - the point of that one is to be a provably
    equivalent transformation (and it might be worth splitting a bit
    more).
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c233eac2740e5234480ac2a33f753f46fa81512a
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Wed May 28 13:51:12 2014 -0400

    split dentry_kill()
    
    commit e55fd011549eae01a230e3cace6f4d031b6a3453 upstream.
    
    ... into trylocks and everything else.  The latter (actual killing)
    is __dentry_kill().
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f718ea386c2f2a077e29a0f338507cfcd75e55cd
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Wed May 28 09:48:44 2014 -0400

    lift the "already marked killed" case into shrink_dentry_list()
    
    commit 64fd72e0a44bdd62c5ca277cb24d0d02b2d8e9dc upstream.
    
    It can happen only when dentry_kill() is called with unlock_on_failure
    equal to 0 - other callers had dentry pinned until the moment they've
    got ->d_lock and DCACHE_DENTRY_KILLED is set only after lockref_mark_dead().
    
    IOW, only one of three call sites of dentry_kill() might end up reaching
    that code.  Just move it there.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8e0cb6c1f8c403c189b45b969540284862b30f85
Author: Hariprasad S <hariprasad@chelsio.com>
Date:   Fri Dec 11 13:59:17 2015 +0530

    iw_cxgb3: Fix incorrectly returning error on success
    
    commit 67f1aee6f45059fd6b0f5b0ecb2c97ad0451f6b3 upstream.
    
    The cxgb3_*_send() functions return NET_XMIT_ values, which are
    positive integers values. So don't treat positive return values
    as an error.
    
    Signed-off-by: Steve Wise <swise@opengridcomputing.com>
    Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    [a pox on developers and maintainers who do not cc: stable for bug fixes like this - gregkh]
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 223c676634fcfe5a54b80bc3d58aec8e49a3c016
Author: Corey Wright <undefined@pobox.com>
Date:   Sun Feb 28 02:42:39 2016 -0600

    proc: Fix ptrace-based permission checks for accessing task maps
    
    Modify mm_access() calls in fs/proc/task_mmu.c and fs/proc/task_nommu.c to
    have the mode include PTRACE_MODE_FSCREDS so accessing /proc/pid/maps and
    /proc/pid/pagemap is not denied to all users.
    
    In backporting upstream commit caaee623 to pre-3.18 kernel versions it was
    overlooked that mm_access() is used in fs/proc/task_*mmu.c as those calls
    were removed in 3.18 (by upstream commit 29a40ace) and did not exist at the
    time of the original commit.
    
    Signed-off-by: Corey Wright <undefined@pobox.com>
    Acked-by: Jann Horn <jann@thejh.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 235679d9169bbb3dbee8f140aec92ddf397013ad
Author: Bjørn Mork <bjorn@mork.no>
Date:   Fri Feb 12 16:40:00 2016 +0100

    USB: option: add "4G LTE usb-modem U901"
    
    commit d061c1caa31d4d9792cfe48a2c6b309a0e01ef46 upstream.
    
    Thomas reports:
    
    T:  Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=  4 Spd=480 MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=05c6 ProdID=6001 Rev=00.00
    S:  Manufacturer=USB Modem
    S:  Product=USB Modem
    S:  SerialNumber=1234567890ABCDEF
    C:  #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
    I:  If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
    
    Reported-by: Thomas Schäfer <tschaefer@t-online.de>
    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 287522d78493f875dba74b0baa381f8a54268732
Author: Andrey Skvortsov <andrej.skvortzov@gmail.com>
Date:   Fri Jan 29 00:07:30 2016 +0300

    USB: option: add support for SIM7100E
    
    commit 3158a8d416f4e1b79dcc867d67cb50013140772c upstream.
    
    $ lsusb:
    Bus 001 Device 101: ID 1e0e:9001 Qualcomm / Option
    
    $ usb-devices:
    T:  Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=101 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  2
    P:  Vendor=1e0e ProdID=9001 Rev= 2.32
    S:  Manufacturer=SimTech, Incorporated
    S:  Product=SimTech, Incorporated
    S:  SerialNumber=0123456789ABCDEF
    C:* #Ifs= 7 Cfg#= 1 Atr=80 MxPwr=500mA
    I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
    I:* If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    
    The last interface (6) is used for Android Composite ADB interface.
    
    Serial port layout:
    0: QCDM/DIAG
    1: NMEA
    2: AT
    3: AT/PPP
    4: audio
    
    Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 315c1d00270eaeacebb0c7c8829bf5190fd1adba
Author: Ken Lin <ken.lin@advantech.com.tw>
Date:   Mon Feb 1 14:57:25 2016 -0500

    USB: cp210x: add IDs for GE B650V3 and B850V3 boards
    
    commit 6627ae19385283b89356a199d7f03c75ba35fb29 upstream.
    
    Add USB ID for cp2104/5 devices on GE B650v3 and B850v3 boards.
    
    Signed-off-by: Ken Lin <ken.lin@advantech.com.tw>
    Signed-off-by: Akshay Bhat <akshay.bhat@timesys.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 02673048632e87c8edd114893738f62d5a6d1ec6
Author: Gerhard Uttenthaler <uttenthaler@ems-wuensche.com>
Date:   Tue Dec 22 17:29:16 2015 +0100

    can: ems_usb: Fix possible tx overflow
    
    commit 90cfde46586d2286488d8ed636929e936c0c9ab2 upstream.
    
    This patch fixes the problem that more CAN messages could be sent to the
    interface as could be send on the CAN bus. This was more likely for slow baud
    rates. The sleeping _start_xmit was woken up in the _write_bulk_callback. Under
    heavy TX load this produced another bulk transfer without checking the
    free_slots variable and hence caused the overflow in the interface.
    
    Signed-off-by: Gerhard Uttenthaler <uttenthaler@ems-wuensche.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5e297a6a053ea694cf32b18be496c6b87d9e35e8
Author: Nikolay Borisov <kernel@kyup.com>
Date:   Thu Dec 17 18:03:35 2015 +0200

    dm thin: fix race condition when destroying thin pool workqueue
    
    commit 18d03e8c25f173f4107a40d0b8c24defb6ed69f3 upstream.
    
    When a thin pool is being destroyed delayed work items are
    cancelled using cancel_delayed_work(), which doesn't guarantee that on
    return the delayed item isn't running.  This can cause the work item to
    requeue itself on an already destroyed workqueue.  Fix this by using
    cancel_delayed_work_sync() which guarantees that on return the work item
    is not running anymore.
    
    Fixes: 905e51b39a555 ("dm thin: commit outstanding data every second")
    Fixes: 85ad643b7e7e5 ("dm thin: add timeout to stop out-of-data-space mode holding IO forever")
    Signed-off-by: Nikolay Borisov <kernel@kyup.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb44c5a6ff5b0e8f2c0d1e68bc95f58334754fef
Author: Joe Thornber <ejt@redhat.com>
Date:   Wed Dec 9 16:23:24 2015 +0000

    dm thin metadata: fix bug when taking a metadata snapshot
    
    commit 49e99fc717f624aa75ca755d6e7bc029efd3f0e9 upstream.
    
    When you take a metadata snapshot the btree roots for the mapping and
    details tree need to have their reference counts incremented so they
    persist for the lifetime of the metadata snap.
    
    The roots being incremented were those currently written in the
    superblock, which could possibly be out of date if concurrent IO is
    triggering new mappings, breaking of sharing, etc.
    
    Fix this by performing a commit with the metadata lock held while taking
    a metadata snapshot.
    
    Signed-off-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 613c515dc0462beba95912ac8a077c9878dcf768
Author: Mike Snitzer <snitzer@redhat.com>
Date:   Fri Nov 6 10:53:01 2015 -0500

    dm thin: restore requested 'error_if_no_space' setting on OODS to WRITE transition
    
    commit 172c238612ebf81cabccc86b788c9209af591f61 upstream.
    
    A thin-pool that is in out-of-data-space (OODS) mode may transition back
    to write mode -- without the admin adding more space to the thin-pool --
    if/when blocks are released (either by deleting thin devices or
    discarding provisioned blocks).
    
    But as part of the thin-pool's earlier transition to out-of-data-space
    mode the thin-pool may have set the 'error_if_no_space' flag to true if
    the no_space_timeout expires without more space having been made
    available.  That implementation detail, of changing the pool's
    error_if_no_space setting, needs to be reset back to the default that
    the user specified when the thin-pool's table was loaded.
    
    Otherwise we'll drop the user requested behaviour on the floor when this
    out-of-data-space to write mode transition occurs.
    
    Reported-by: Vivek Goyal <vgoyal@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Acked-by: Joe Thornber <ejt@redhat.com>
    Fixes: 2c43fd26e4 ("dm thin: fix missing out-of-data-space to write mode transition if blocks are released")
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9dd9ef83bef5cbbcfc33d834c07ba5d8dd7753ed
Author: Ingo Molnar <mingo@kernel.org>
Date:   Tue Mar 3 07:34:33 2015 +0100

    efi: Disable interrupts around EFI calls, not in the epilog/prolog calls
    
    commit 23a0d4e8fa6d3a1d7fb819f79bcc0a3739c30ba9 upstream.
    
    Tapasweni Pathak reported that we do a kmalloc() in efi_call_phys_prolog()
    on x86-64 while having interrupts disabled, which is a big no-no, as
    kmalloc() can sleep.
    
    Solve this by removing the irq disabling from the prolog/epilog calls
    around EFI calls: it's unnecessary, as in this stage we are single
    threaded in the boot thread, and we don't ever execute this from
    interrupt contexts.
    
    Reported-by: Tapasweni Pathak <tapaswenipathak@gmail.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e133febe49210ceb99f5b793533ce1575aeaeebe
Author: Dave Airlie <airlied@redhat.com>
Date:   Thu Aug 20 10:13:55 2015 +1000

    drm/radeon: fix hotplug race at startup
    
    commit 7f98ca454ad373fc1b76be804fa7138ff68c1d27 upstream.
    
    We apparantly get a hotplug irq before we've initialised
    modesetting,
    
    [drm] Loading R100 Microcode
    BUG: unable to handle kernel NULL pointer dereference at   (null)
    IP: [<c125f56f>] __mutex_lock_slowpath+0x23/0x91
    *pde = 00000000
    Oops: 0002 [#1]
    Modules linked in: radeon(+) drm_kms_helper ttm drm i2c_algo_bit backlight pcspkr psmouse evdev sr_mod input_leds led_class cdrom sg parport_pc parport floppy intel_agp intel_gtt lpc_ich acpi_cpufreq processor button mfd_core agpgart uhci_hcd ehci_hcd rng_core snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm usbcore usb_common i2c_i801 i2c_core snd_timer snd soundcore thermal_sys
    CPU: 0 PID: 15 Comm: kworker/0:1 Not tainted 4.2.0-rc7-00015-gbf67402 #111
    Hardware name: MicroLink                               /D850MV                         , BIOS MV85010A.86A.0067.P24.0304081124 04/08/2003
    Workqueue: events radeon_hotplug_work_func [radeon]
    task: f6ca5900 ti: f6d3e000 task.ti: f6d3e000
    EIP: 0060:[<c125f56f>] EFLAGS: 00010282 CPU: 0
    EIP is at __mutex_lock_slowpath+0x23/0x91
    EAX: 00000000 EBX: f5e900fc ECX: 00000000 EDX: fffffffe
    ESI: f6ca5900 EDI: f5e90100 EBP: f5e90000 ESP: f6d3ff0c
     DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
    CR0: 8005003b CR2: 00000000 CR3: 36f61000 CR4: 000006d0
    Stack:
     f5e90100 00000000 c103c4c1 f6d2a5a0 f5e900fc f6df394c c125f162 f8b0faca
     f6d2a5a0 c138ca00 f6df394c f7395600 c1034741 00d40000 00000000 f6d2a5a0
     c138ca00 f6d2a5b8 c138ca10 c1034b58 00000001 f6d40000 f6ca5900 f6d0c940
    Call Trace:
     [<c103c4c1>] ? dequeue_task_fair+0xa4/0xb7
     [<c125f162>] ? mutex_lock+0x9/0xa
     [<f8b0faca>] ? radeon_hotplug_work_func+0x17/0x57 [radeon]
     [<c1034741>] ? process_one_work+0xfc/0x194
     [<c1034b58>] ? worker_thread+0x18d/0x218
     [<c10349cb>] ? rescuer_thread+0x1d5/0x1d5
     [<c103742a>] ? kthread+0x7b/0x80
     [<c12601c0>] ? ret_from_kernel_thread+0x20/0x30
     [<c10373af>] ? init_completion+0x18/0x18
    Code: 42 08 e8 8e a6 dd ff c3 57 56 53 83 ec 0c 8b 35 48 f7 37 c1 8b 10 4a 74 1a 89 c3 8d 78 04 8b 40 08 89 63
    
    Reported-and-Tested-by: Meelis Roos <mroos@linux.ee>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 12ce3017a2f9b26aa00d29facfb631ef62aeac19
Author: Kamal Mostafa <kamal@canonical.com>
Date:   Wed Nov 11 14:25:34 2015 -0800

    tools: Add a "make all" rule
    
    commit f6ba98c5dc78708cb7fd29950c4a50c4c7e88f95 upstream.
    
    
    Signed-off-by: Kamal Mostafa <kamal@canonical.com>
    Acked-by: Pavel Machek <pavel@ucw.cz>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Jonathan Cameron <jic23@kernel.org>
    Cc: Pali Rohar <pali.rohar@gmail.com>
    Cc: Roberta Dobrescu <roberta.dobrescu@gmail.com>
    Link: http://lkml.kernel.org/r/1447280736-2161-2-git-send-email-kamal@canonical.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    [ kamal: backport to 3.14-stable: build all tools for this version ]
    Signed-off-by: Kamal Mostafa <kamal@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e5a1ede9082dce5da4883c92fa37d25b5e10cdfe
Author: Kent Overstreet <kent.overstreet@gmail.com>
Date:   Sun Nov 29 18:47:01 2015 -0800

    bcache: Change refill_dirty() to always scan entire disk if necessary
    
    commit 627ccd20b4ad3ba836472468208e2ac4dfadbf03 upstream.
    
    Previously, it would only scan the entire disk if it was starting from
    the very start of the disk - i.e. if the previous scan got to the end.
    
    This was broken by refill_full_stripes(), which updates last_scanned so
    that refill_dirty was never triggering the searched_from_start path.
    
    But if we change refill_dirty() to always scan the entire disk if
    necessary, regardless of what last_scanned was, the code gets cleaner
    and we fix that bug too.
    
    Signed-off-by: Kent Overstreet <kent.overstreet@gmail.com>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cf53efaa709add606265ff55acf35e90da4a926c
Author: Stefan Bader <stefan.bader@canonical.com>
Date:   Sun Nov 29 18:44:49 2015 -0800

    bcache: prevent crash on changing writeback_running
    
    commit 8d16ce540c94c9d366eb36fc91b7154d92d6397b upstream.
    
    Added a safeguard in the shutdown case. At least while not being
    attached it is also possible to trigger a kernel bug by writing into
    writeback_running. This change  adds the same check before trying to
    wake up the thread for that case.
    
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Cc: Kent Overstreet <kent.overstreet@gmail.com>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 283ab75762271a457f3547a36a586568547c5aa9
Author: Zheng Liu <wenqing.lz@taobao.com>
Date:   Sun Nov 29 17:21:57 2015 -0800

    bcache: unregister reboot notifier if bcache fails to unregister device
    
    commit 2ecf0cdb2b437402110ab57546e02abfa68a716b upstream.
    
    In bcache_init() function it forgot to unregister reboot notifier if
    bcache fails to unregister a block device.  This commit fixes this.
    
    Signed-off-by: Zheng Liu <wenqing.lz@taobao.com>
    Tested-by: Joshua Schmid <jschmid@suse.com>
    Tested-by: Eric Wheeler <bcache@linux.ewheeler.net>
    Cc: Kent Overstreet <kmo@daterainc.com>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dba6700e43c3ae56eb76b5013cc32500a21d0070
Author: Al Viro <viro@ZenIV.linux.org.uk>
Date:   Sun Nov 29 17:20:59 2015 -0800

    bcache: fix a leak in bch_cached_dev_run()
    
    commit 4d4d8573a8451acc9f01cbea24b7e55f04a252fe upstream.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Tested-by: Joshua Schmid <jschmid@suse.com>
    Tested-by: Eric Wheeler <bcache@linux.ewheeler.net>
    Cc: Kent Overstreet <kmo@daterainc.com>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ffed442c0186bc57af0761bdc55b217681d211cf
Author: Zheng Liu <wenqing.lz@taobao.com>
Date:   Sun Nov 29 17:19:32 2015 -0800

    bcache: clear BCACHE_DEV_UNLINK_DONE flag when attaching a backing device
    
    commit fecaee6f20ee122ad75402c53d8278f9bb142ddc upstream.
    
    This bug can be reproduced by the following script:
    
      #!/bin/bash
    
      bcache_sysfs="/sys/fs/bcache"
    
      function clear_cache()
      {
      	if [ ! -e $bcache_sysfs ]; then
      		echo "no bcache sysfs"
      		exit
      	fi
    
      	cset_uuid=$(ls -l $bcache_sysfs|head -n 2|tail -n 1|awk '{print $9}')
      	sudo sh -c "echo $cset_uuid > /sys/block/sdb/sdb1/bcache/detach"
      	sleep 5
      	sudo sh -c "echo $cset_uuid > /sys/block/sdb/sdb1/bcache/attach"
      }
    
      for ((i=0;i<10;i++)); do
      	clear_cache
      done
    
    The warning messages look like below:
    [  275.948611] ------------[ cut here ]------------
    [  275.963840] WARNING: at fs/sysfs/dir.c:512 sysfs_add_one+0xb8/0xd0() (Tainted: P        W
    ---------------   )
    [  275.979253] Hardware name: Tecal RH2285
    [  275.994106] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:09.0/0000:08:00.0/host4/target4:2:1/4:2:1:0/block/sdb/sdb1/bcache/cache'
    [  276.024105] Modules linked in: bcache tcp_diag inet_diag ipmi_devintf ipmi_si ipmi_msghandler
    bonding 8021q garp stp llc ipv6 ext3 jbd loop sg iomemory_vsl(P) bnx2 microcode serio_raw i2c_i801
    i2c_core iTCO_wdt iTCO_vendor_support i7core_edac edac_core shpchp ext4 jbd2 mbcache megaraid_sas
    pata_acpi ata_generic ata_piix dm_mod [last unloaded: scsi_wait_scan]
    [  276.072643] Pid: 2765, comm: sh Tainted: P        W  ---------------    2.6.32 #1
    [  276.089315] Call Trace:
    [  276.105801]  [<ffffffff81070fe7>] ? warn_slowpath_common+0x87/0xc0
    [  276.122650]  [<ffffffff810710d6>] ? warn_slowpath_fmt+0x46/0x50
    [  276.139361]  [<ffffffff81205c08>] ? sysfs_add_one+0xb8/0xd0
    [  276.156012]  [<ffffffff8120609b>] ? sysfs_do_create_link+0x12b/0x170
    [  276.172682]  [<ffffffff81206113>] ? sysfs_create_link+0x13/0x20
    [  276.189282]  [<ffffffffa03bda21>] ? bcache_device_link+0xc1/0x110 [bcache]
    [  276.205993]  [<ffffffffa03bfa08>] ? bch_cached_dev_attach+0x478/0x4f0 [bcache]
    [  276.222794]  [<ffffffffa03c4a17>] ? bch_cached_dev_store+0x627/0x780 [bcache]
    [  276.239680]  [<ffffffff8116783a>] ? alloc_pages_current+0xaa/0x110
    [  276.256594]  [<ffffffff81203b15>] ? sysfs_write_file+0xe5/0x170
    [  276.273364]  [<ffffffff811887b8>] ? vfs_write+0xb8/0x1a0
    [  276.290133]  [<ffffffff811890b1>] ? sys_write+0x51/0x90
    [  276.306368]  [<ffffffff8100c072>] ? system_call_fastpath+0x16/0x1b
    [  276.322301] ---[ end trace 9f5d4fcdd0c3edfb ]---
    [  276.338241] ------------[ cut here ]------------
    [  276.354109] WARNING: at /home/wenqing.lz/bcache/bcache/super.c:720
    bcache_device_link+0xdf/0x110 [bcache]() (Tainted: P        W  ---------------   )
    [  276.386017] Hardware name: Tecal RH2285
    [  276.401430] Couldn't create device <-> cache set symlinks
    [  276.401759] Modules linked in: bcache tcp_diag inet_diag ipmi_devintf ipmi_si ipmi_msghandler
    bonding 8021q garp stp llc ipv6 ext3 jbd loop sg iomemory_vsl(P) bnx2 microcode serio_raw i2c_i801
    i2c_core iTCO_wdt iTCO_vendor_support i7core_edac edac_core shpchp ext4 jbd2 mbcache megaraid_sas
    pata_acpi ata_generic ata_piix dm_mod [last unloaded: scsi_wait_scan]
    [  276.465477] Pid: 2765, comm: sh Tainted: P        W  ---------------    2.6.32 #1
    [  276.482169] Call Trace:
    [  276.498610]  [<ffffffff81070fe7>] ? warn_slowpath_common+0x87/0xc0
    [  276.515405]  [<ffffffff810710d6>] ? warn_slowpath_fmt+0x46/0x50
    [  276.532059]  [<ffffffffa03bda3f>] ? bcache_device_link+0xdf/0x110 [bcache]
    [  276.548808]  [<ffffffffa03bfa08>] ? bch_cached_dev_attach+0x478/0x4f0 [bcache]
    [  276.565569]  [<ffffffffa03c4a17>] ? bch_cached_dev_store+0x627/0x780 [bcache]
    [  276.582418]  [<ffffffff8116783a>] ? alloc_pages_current+0xaa/0x110
    [  276.599341]  [<ffffffff81203b15>] ? sysfs_write_file+0xe5/0x170
    [  276.616142]  [<ffffffff811887b8>] ? vfs_write+0xb8/0x1a0
    [  276.632607]  [<ffffffff811890b1>] ? sys_write+0x51/0x90
    [  276.648671]  [<ffffffff8100c072>] ? system_call_fastpath+0x16/0x1b
    [  276.664756] ---[ end trace 9f5d4fcdd0c3edfc ]---
    
    We forget to clear BCACHE_DEV_UNLINK_DONE flag in bcache_device_attach()
    function when we attach a backing device first time.  After detaching this
    backing device, this flag will be true and sysfs_remove_link() isn't called in
    bcache_device_unlink().  Then when we attach this backing device again,
    sysfs_create_link() will return EEXIST error in bcache_device_link().
    
    So the fix is trival and we clear this flag in bcache_device_link().
    
    Signed-off-by: Zheng Liu <wenqing.lz@taobao.com>
    Tested-by: Joshua Schmid <jschmid@suse.com>
    Tested-by: Eric Wheeler <bcache@linux.ewheeler.net>
    Cc: Kent Overstreet <kmo@daterainc.com>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b7ce521d6d1e6c2756f68f90db70f90c5e261348
Author: Kent Overstreet <kmo@daterainc.com>
Date:   Sun Nov 29 17:18:33 2015 -0800

    bcache: Add a cond_resched() call to gc
    
    commit c5f1e5adf956e3ba82d204c7c141a75da9fa449a upstream.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Tested-by: Eric Wheeler <bcache@linux.ewheeler.net>
    Cc: Kent Overstreet <kmo@daterainc.com>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1d348932eff4ceba5923002fe54ce807bceb0d93
Author: Zheng Liu <gnehzuil.liu@gmail.com>
Date:   Sun Nov 29 17:17:05 2015 -0800

    bcache: fix a livelock when we cause a huge number of cache misses
    
    commit 2ef9ccbfcb90cf84bdba320a571b18b05c41101b upstream.
    
    Subject :	[PATCH v2] bcache: fix a livelock in btree lock
    Date :	Wed, 25 Feb 2015 20:32:09 +0800 (02/25/2015 04:32:09 AM)
    
    This commit tries to fix a livelock in bcache.  This livelock might
    happen when we causes a huge number of cache misses simultaneously.
    
    When we get a cache miss, bcache will execute the following path.
    
    ->cached_dev_make_request()
      ->cached_dev_read()
        ->cached_lookup()
          ->bch->btree_map_keys()
            ->btree_root()  <------------------------
              ->bch_btree_map_keys_recurse()        |
                ->cache_lookup_fn()                 |
                  ->cached_dev_cache_miss()         |
                    ->bch_btree_insert_check_key() -|
                      [If btree->seq is not equal to seq + 1, we should return
                       EINTR and traverse btree again.]
    
    In bch_btree_insert_check_key() function we first need to check upgrade
    flag (op->lock == -1), and when this flag is true we need to release
    read btree->lock and try to take write btree->lock.  During taking and
    releasing this write lock, btree->seq will be monotone increased in
    order to prevent other threads modify this in cache miss (see btree.h:74).
    But if there are some cache misses caused by some requested, we could
    meet a livelock because btree->seq is always changed by others.  Thus no
    one can make progress.
    
    This commit will try to take write btree->lock if it encounters a race
    when we traverse btree.  Although it sacrifice the scalability but we
    can ensure that only one can modify the btree.
    
    Signed-off-by: Zheng Liu <wenqing.lz@taobao.com>
    Tested-by: Joshua Schmid <jschmid@suse.com>
    Tested-by: Eric Wheeler <bcache@linux.ewheeler.net>
    Cc: Joshua Schmid <jschmid@suse.com>
    Cc: Zhu Yanhai <zhu.yanhai@gmail.com>
    Cc: Kent Overstreet <kmo@daterainc.com>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d70966f182d52bc0032c7024393be7cd80991b41
Author: Phil Sutter <phil@nwl.cc>
Date:   Sun Aug 9 13:14:15 2015 +0200

    netfilter: ip6t_SYNPROXY: fix NULL pointer dereference
    
    commit 96fffb4f23f124f297d51dedc9cf51d19eb88ee1 upstream.
    
    This happens when networking namespaces are enabled.
    
    Suggested-by: Patrick McHardy <kaber@trash.net>
    Signed-off-by: Phil Sutter <phil@nwl.cc>
    Acked-by: Patrick McHardy <kaber@trash.net>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 905edc07a8b288953ed6571f19a84b64cce6b506
Author: lucien <lucien.xin@gmail.com>
Date:   Tue Oct 6 21:03:07 2015 +0800

    netfilter: ipt_rpfilter: remove the nh_scope test in rpfilter_lookup_reverse
    
    commit cc4998febd567d1c671684abce5595344bd4e8b2 upstream.
    
    --accept-local  option works for res.type == RTN_LOCAL, which should be
    from the local table, but there, the fib_info's nh->nh_scope =
    RT_SCOPE_NOWHERE ( > RT_SCOPE_HOST). in fib_create_info().
    
    	if (cfg->fc_scope == RT_SCOPE_HOST) {
    		struct fib_nh *nh = fi->fib_nh;
    
    		/* Local address is added. */
    		if (nhs != 1 || nh->nh_gw)
    			goto err_inval;
    		nh->nh_scope = RT_SCOPE_NOWHERE;   <===
    		nh->nh_dev = dev_get_by_index(net, fi->fib_nh->nh_oif);
    		err = -ENODEV;
    		if (!nh->nh_dev)
    			goto failure;
    
    but in our rpfilter_lookup_reverse():
    
    	if (dev_match || flags & XT_RPFILTER_LOOSE)
    		return FIB_RES_NH(res).nh_scope <= RT_SCOPE_HOST;
    
    if nh->nh_scope > RT_SCOPE_HOST, it will fail. --accept-local option
    will never be passed.
    
    it seems the test is bogus and can be removed to fix this issue.
    
    	if (dev_match || flags & XT_RPFILTER_LOOSE)
    		return FIB_RES_NH(res).nh_scope <= RT_SCOPE_HOST;
    
    ipv6 does not have this issue.
    
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7447ae218890f6cb5d500e26361fec215be8e606
Author: Mirek Kratochvil <exa.exa@gmail.com>
Date:   Fri May 15 21:15:29 2015 +0200

    netfilter: nf_tables: fix bogus warning in nft_data_uninit()
    
    commit 960bd2c26421d321e890f1936938196ead41976f upstream.
    
    The values 0x00000000-0xfffffeff are reserved for userspace datatype. When,
    deleting set elements with maps, a bogus warning is triggered.
    
    WARNING: CPU: 0 PID: 11133 at net/netfilter/nf_tables_api.c:4481 nft_data_uninit+0x35/0x40 [nf_tables]()
    
    This fixes the check accordingly to enum definition in
    include/linux/netfilter/nf_tables.h
    
    Fixes: https://bugzilla.netfilter.org/show_bug.cgi?id=1013
    Signed-off-by: Mirek Kratochvil <exa.exa@gmail.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 36913890c5cdeddec7c143d63f2892a6314686e5
Author: Egbert Eich <eich@suse.de>
Date:   Wed Jun 11 14:59:55 2014 +0200

    drm/ast: Initialized data needed to map fbdev memory
    
    commit 28fb4cb7fa6f63dc2fbdb5f2564dcbead8e3eee0 upstream.
    
    Due to a missing initialization there was no way to map fbdev memory.
    Thus for example using the Xserver with the fbdev driver failed.
    This fix adds initialization for fix.smem_start and fix.smem_len
    in the fb_info structure, which fixes this problem.
    
    Requested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Egbert Eich <eich@suse.de>
    [pulled from SuSE tree by me - airlied]
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit af0fc20f279df7177412be6d6f09fa3763a0cdd1
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Mon Feb 15 12:36:14 2016 -0500

    tracepoints: Do not trace when cpu is offline
    
    commit f37755490fe9bf76f6ba1d8c6591745d3574a6a6 upstream.
    
    The tracepoint infrastructure uses RCU sched protection to enable and
    disable tracepoints safely. There are some instances where tracepoints are
    used in infrastructure code (like kfree()) that get called after a CPU is
    going offline, and perhaps when it is coming back online but hasn't been
    registered yet.
    
    This can probuce the following warning:
    
     [ INFO: suspicious RCU usage. ]
     4.4.0-00006-g0fe53e8-dirty #34 Tainted: G S
     -------------------------------
     include/trace/events/kmem.h:141 suspicious rcu_dereference_check() usage!
    
     other info that might help us debug this:
    
     RCU used illegally from offline CPU!  rcu_scheduler_active = 1, debug_locks = 1
     no locks held by swapper/8/0.
    
     stack backtrace:
      CPU: 8 PID: 0 Comm: swapper/8 Tainted: G S              4.4.0-00006-g0fe53e8-dirty #34
      Call Trace:
      [c0000005b76c78d0] [c0000000008b9540] .dump_stack+0x98/0xd4 (unreliable)
      [c0000005b76c7950] [c00000000010c898] .lockdep_rcu_suspicious+0x108/0x170
      [c0000005b76c79e0] [c00000000029adc0] .kfree+0x390/0x440
      [c0000005b76c7a80] [c000000000055f74] .destroy_context+0x44/0x100
      [c0000005b76c7b00] [c0000000000934a0] .__mmdrop+0x60/0x150
      [c0000005b76c7b90] [c0000000000e3ff0] .idle_task_exit+0x130/0x140
      [c0000005b76c7c20] [c000000000075804] .pseries_mach_cpu_die+0x64/0x310
      [c0000005b76c7cd0] [c000000000043e7c] .cpu_die+0x3c/0x60
      [c0000005b76c7d40] [c0000000000188d8] .arch_cpu_idle_dead+0x28/0x40
      [c0000005b76c7db0] [c000000000101e6c] .cpu_startup_entry+0x50c/0x560
      [c0000005b76c7ed0] [c000000000043bd8] .start_secondary+0x328/0x360
      [c0000005b76c7f90] [c000000000008a6c] start_secondary_prolog+0x10/0x14
    
    This warning is not a false positive either. RCU is not protecting code that
    is being executed while the CPU is offline.
    
    Instead of playing "whack-a-mole(TM)" and adding conditional statements to
    the tracepoints we find that are used in this instance, simply add a
    cpu_online() test to the tracepoint code where the tracepoint will be
    ignored if the CPU is offline.
    
    Use of raw_smp_processor_id() is fine, as there should never be a case where
    the tracepoint code goes from running on a CPU that is online and suddenly
    gets migrated to a CPU that is offline.
    
    Link: http://lkml.kernel.org/r/1455387773-4245-1-git-send-email-kda@linux-powerpc.org
    
    Reported-by: Denis Kirjanov <kda@linux-powerpc.org>
    Fixes: 97e1c18e8d17b ("tracing: Kernel Tracepoints")
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>