Attachment 8079 Details for Bug 41058

v4.1.16..v4.1.33.log

v4.1.16..v4.1.33.log (text/x-log), 2.08 MB, created by Arvid Requate on 2016-10-10 20:42 CEST

(hide)

Description:

Filename:

MIME Type:

Creator: Arvid Requate

Created: 2016-10-10 20:42 CEST

Size: 2.08 MB

patch

obsolete

>commit 04cb720142764ebf3786eba1feb8fc4b6ef87fcf
>Author: Sasha Levin <alexander.levin@verizon.com>
>Date:   Sat Sep 17 18:54:14 2016 -0400
>
>    Linux 4.1.33
>    
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 131f437d2baf4205da41f6d6a40f7694d4617482
>Author: Sasha Levin <alexander.levin@verizon.com>
>Date:   Thu Sep 15 18:55:55 2016 -0400
>
>    Revert "ARC: mm: don't loose PTE_SPECIAL in pte_modify()"
>    
>    This reverts commit 93c0b008e79f11430ce07b6271b37671051d4298.
>    
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 706f890792bcc8abb5ca894e7c00bb415c903ad3
>Author: Emanuel Czirai <icanrealizeum@gmail.com>
>Date:   Fri Sep 2 07:35:50 2016 +0200
>
>    x86/AMD: Apply erratum 665 on machines without a BIOS fix
>    
>    [ Upstream commit d1992996753132e2dafe955cccb2fb0714d3cfc4 ]
>    
>    AMD F12h machines have an erratum which can cause DIV/IDIV to behave
>    unpredictably. The workaround is to set MSRC001_1029[31] but sometimes
>    there is no BIOS update containing that workaround so let's do it
>    ourselves unconditionally. It is simple enough.
>    
>    [ Borislav: Wrote commit message. ]
>    
>    Signed-off-by: Emanuel Czirai <icanrealizeum@gmail.com>
>    Signed-off-by: Borislav Petkov <bp@suse.de>
>    Cc: Yaowu Xu <yaowu@google.com>
>    Cc: stable@vger.kernel.org
>    Link: http://lkml.kernel.org/r/20160902053550.18097-1-bp@alien8.de
>    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 8fdbea47fa4873884fe06a24669cf1d4138b53ab
>Author: Steven Rostedt <rostedt@goodmis.org>
>Date:   Wed May 25 13:47:26 2016 -0400
>
>    x86/paravirt: Do not trace _paravirt_ident_*() functions
>    
>    [ Upstream commit 15301a570754c7af60335d094dd2d1808b0641a5 ]
>    
>    Åukasz Daniluk reported that on a RHEL kernel that his machine would lock up
>    after enabling function tracer. I asked him to bisect the functions within
>    available_filter_functions, which he did and it came down to three:
>    
>      _paravirt_nop(), _paravirt_ident_32() and _paravirt_ident_64()
>    
>    It was found that this is only an issue when noreplace-paravirt is added
>    to the kernel command line.
>    
>    This means that those functions are most likely called within critical
>    sections of the funtion tracer, and must not be traced.
>    
>    In newer kenels _paravirt_nop() is defined within gcc asm(), and is no
>    longer an issue.  But both _paravirt_ident_{32,64}() causes the
>    following splat when they are traced:
>    
>     mm/pgtable-generic.c:33: bad pmd ffff8800d2435150(0000000001d00054)
>     mm/pgtable-generic.c:33: bad pmd ffff8800d3624190(0000000001d00070)
>     mm/pgtable-generic.c:33: bad pmd ffff8800d36a5110(0000000001d00054)
>     mm/pgtable-generic.c:33: bad pmd ffff880118eb1450(0000000001d00054)
>     NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [systemd-journal:469]
>     Modules linked in: e1000e
>     CPU: 2 PID: 469 Comm: systemd-journal Not tainted 4.6.0-rc4-test+ #513
>     Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v02.05 05/07/2012
>     task: ffff880118f740c0 ti: ffff8800d4aec000 task.ti: ffff8800d4aec000
>     RIP: 0010:[<ffffffff81134148>]  [<ffffffff81134148>] queued_spin_lock_slowpath+0x118/0x1a0
>     RSP: 0018:ffff8800d4aefb90  EFLAGS: 00000246
>     RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88011eb16d40
>     RDX: ffffffff82485760 RSI: 000000001f288820 RDI: ffffea0000008030
>     RBP: ffff8800d4aefb90 R08: 00000000000c0000 R09: 0000000000000000
>     R10: ffffffff821c8e0e R11: 0000000000000000 R12: ffff880000200fb8
>     R13: 00007f7a4e3f7000 R14: ffffea000303f600 R15: ffff8800d4b562e0
>     FS:  00007f7a4e3d7840(0000) GS:ffff88011eb00000(0000) knlGS:0000000000000000
>     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>     CR2: 00007f7a4e3f7000 CR3: 00000000d3e71000 CR4: 00000000001406e0
>     Call Trace:
>       _raw_spin_lock+0x27/0x30
>       handle_pte_fault+0x13db/0x16b0
>       handle_mm_fault+0x312/0x670
>       __do_page_fault+0x1b1/0x4e0
>       do_page_fault+0x22/0x30
>       page_fault+0x28/0x30
>       __vfs_read+0x28/0xe0
>       vfs_read+0x86/0x130
>       SyS_read+0x46/0xa0
>       entry_SYSCALL_64_fastpath+0x1e/0xa8
>     Code: 12 48 c1 ea 0c 83 e8 01 83 e2 30 48 98 48 81 c2 40 6d 01 00 48 03 14 c5 80 6a 5d 82 48 89 0a 8b 41 08 85 c0 75 09 f3 90 8b 41 08 <85> c0 74 f7 4c 8b 09 4d 85 c9 74 08 41 0f 18 09 eb 02 f3 90 8b
>    
>    Reported-by: Åukasz Daniluk <lukasz.daniluk@intel.com>
>    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 7a173276f96f2d30c043c22ee98c9ea28622fb9e
>Author: Miklos Szeredi <mszeredi@redhat.com>
>Date:   Thu Sep 1 11:12:00 2016 +0200
>
>    ovl: listxattr: use strnlen()
>    
>    [ Upstream commit 7cb35119d067191ce9ebc380a599db0b03cbd9d9 ]
>    
>    Be defensive about what underlying fs provides us in the returned xattr
>    list buffer.  If it's not properly null terminated, bail out with a warning
>    insead of BUG.
>    
>    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 02b7c975b7730d37e8727880c1bf6c83d7bfa5c3
>Author: Miklos Szeredi <mszeredi@redhat.com>
>Date:   Thu Sep 1 11:11:59 2016 +0200
>
>    ovl: remove posix_acl_default from workdir
>    
>    [ Upstream commit c11b9fdd6a612f376a5e886505f1c54c16d8c380 ]
>    
>    Clear out posix acl xattrs on workdir and also reset the mode after
>    creation so that an inherited sgid bit is cleared.
>    
>    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 29c4d8dbfc793c9876db5c4193686ba6ffcb3cd6
>Author: Jimi Damon <jdamon@accesio.com>
>Date:   Wed Jul 20 17:00:40 2016 -0700
>
>    serial: 8250: added acces i/o products quad and octal serial cards
>    
>    [ Upstream commit c8d192428f52f244130b84650ad616df09f2b1e1 ]
>    
>    Added devices ids for acces i/o products quad and octal serial cards
>    that make use of existing Pericom PI7C9X7954 and PI7C9X7958
>    configurations .
>    
>    Signed-off-by: Jimi Damon <jdamon@accesio.com>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 8f96009a9d8e8085278e692764a38f52011fd2c4
>Author: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
>Date:   Wed Jun 22 21:42:16 2016 +0300
>
>    sysfs: correctly handle read offset on PREALLOC attrs
>    
>    [ Upstream commit 17d0774f80681020eccc9638d925a23f1fc4f671 ]
>    
>    Attributes declared with __ATTR_PREALLOC use sysfs_kf_read() which returns
>    zero bytes for non-zero offset. This breaks script checkarray in mdadm tool
>    in debian where /bin/sh is 'dash' because its builtin 'read' reads only one
>    byte at a time. Script gets 'i' instead of 'idle' when reads current action
>    from /sys/block/$dev/md/sync_action and as a result does nothing.
>    
>    This patch adds trivial implementation of partial read: generate whole
>    string and move required part into buffer head.
>    
>    Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
>    Fixes: 4ef67a8c95f3 ("sysfs/kernfs: make read requests on pre-alloc files use the buffer.")
>    Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787950
>    Cc: Stable <stable@vger.kernel.org> # v3.19+
>    Acked-by: Tejun Heo <tj@kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit f53680b1d8b0f1cd039b5328d194b8e72973919f
>Author: NeilBrown <neilb@suse.com>
>Date:   Thu Aug 6 08:27:55 2015 +1000
>
>    sysfs: correctly handle short reads on PREALLOC attrs.
>    
>    [ Upstream commit 65da3484d9be5664f5f7d2378e438bb2794f40b8 ]
>    
>    attributes declared with __ATTR_PREALLOC use sysfs_kf_read()
>    which ignores the 'count' arg.
>    So a 1-byte read request can return more bytes than that.
>    
>    This is seen with the 'dash' shell when 'read' is used on
>    some 'md' sysfs attributes.
>    
>    So only return the 'min' of count and the attribute length.
>    
>    Signed-off-by: NeilBrown <neilb@suse.com>
>    Acked-by: Tejun Heo <tj@kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 33d720d9108912b42b77bd4c6fa63d81032d773a
>Author: Tejun Heo <tj@kernel.org>
>Date:   Fri Jun 17 17:51:17 2016 -0400
>
>    kernfs: don't depend on d_find_any_alias() when generating notifications
>    
>    [ Upstream commit df6a58c5c5aa8ecb1e088ecead3fa33ae70181f1 ]
>    
>    kernfs_notify_workfn() sends out file modified events for the
>    scheduled kernfs_nodes.  Because the modifications aren't from
>    userland, it doesn't have the matching file struct at hand and can't
>    use fsnotify_modify().  Instead, it looked up the inode and then used
>    d_find_any_alias() to find the dentry and used fsnotify_parent() and
>    fsnotify() directly to generate notifications.
>    
>    The assumption was that the relevant dentries would have been pinned
>    if there are listeners, which isn't true as inotify doesn't pin
>    dentries at all and watching the parent doesn't pin the child dentries
>    even for dnotify.  This led to, for example, inotify watchers not
>    getting notifications if the system is under memory pressure and the
>    matching dentries got reclaimed.  It can also be triggered through
>    /proc/sys/vm/drop_caches or a remount attempt which involves shrinking
>    dcache.
>    
>    fsnotify_parent() only uses the dentry to access the parent inode,
>    which kernfs can do easily.  Update kernfs_notify_workfn() so that it
>    uses fsnotify() directly for both the parent and target inodes without
>    going through d_find_any_alias().  While at it, supply the target file
>    name to fsnotify() from kernfs_node->name.
>    
>    Signed-off-by: Tejun Heo <tj@kernel.org>
>    Reported-by: Evgeny Vereshchagin <evvers@ya.ru>
>    Fixes: d911d9874801 ("kernfs: make kernfs_notify() trigger inotify events too")
>    Cc: John McCutchan <john@johnmccutchan.com>
>    Cc: Robert Love <rlove@rlove.org>
>    Cc: Eric Paris <eparis@parisplace.org>
>    Cc: stable@vger.kernel.org # v3.16+
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit e1857183b9f00bc4aef95794a5215b386d540f33
>Author: Eric Biggers <ebiggers@google.com>
>Date:   Tue Aug 30 09:51:44 2016 -0700
>
>    dm crypt: fix free of bad values after tfm allocation failure
>    
>    [ Upstream commit 5d0be84ec0cacfc7a6d6ea548afdd07d481324cd ]
>    
>    If crypt_alloc_tfms() had to allocate multiple tfms and it failed before
>    the last allocation, then it would call crypt_free_tfms() and could free
>    pointers from uninitialized memory -- due to the crypt_free_tfms() check
>    for non-zero cc->tfms[i].  Fix by allocating zeroed memory.
>    
>    Signed-off-by: Eric Biggers <ebiggers@google.com>
>    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit af26eb1cc0535f5c59ef6241bb4f305c846b22d5
>Author: Mikulas Patocka <mpatocka@redhat.com>
>Date:   Tue Aug 30 16:38:42 2016 -0400
>
>    dm crypt: fix error with too large bios
>    
>    [ Upstream commit 4e870e948fbabf62b78e8410f04c67703e7c816b ]
>    
>    When dm-crypt processes writes, it allocates a new bio in
>    crypt_alloc_buffer().  The bio is allocated from a bio set and it can
>    have at most BIO_MAX_PAGES vector entries, however the incoming bio can be
>    larger (e.g. if it was allocated by bcache).  If the incoming bio is
>    larger, bio_alloc_bioset() fails and an error is returned.
>    
>    To avoid the error, we test for a too large bio in the function
>    crypt_map() and use dm_accept_partial_bio() to split the bio.
>    dm_accept_partial_bio() trims the current bio to the desired size and
>    asks DM core to send another bio with the rest of the data.
>    
>    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
>    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
>    Cc: stable@vger.kernel.org # v3.16+
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 14afdb21578a068c8c331e5695c5b7dd971dcb64
>Author: Vladimir Zapolskiy <vz@mleia.com>
>Date:   Thu Mar 10 01:22:19 2016 +0200
>
>    dm log writes: fix check of kthread_run() return value
>    
>    [ Upstream commit 91e630d9ae6de6f740ef7c8176736eb55366833e ]
>    
>    The kthread_run() function returns either a valid task_struct or
>    ERR_PTR() value, check for NULL is invalid.  This change fixes potential
>    for oops, e.g. in OOM situation.
>    
>    Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
>    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 6f3e5e4d8e4fc69a3aebe54d9073fa3418ef3fe1
>Author: Mikulas Patocka <mpatocka@redhat.com>
>Date:   Tue Aug 30 16:20:55 2016 -0400
>
>    dm log writes: fix bug with too large bios
>    
>    [ Upstream commit 7efb367320f56fc4d549875b6f3a6940018ef2e5 ]
>    
>    bio_alloc() can allocate a bio with at most BIO_MAX_PAGES (256) vector
>    entries.  However, the incoming bio may have more vector entries if it
>    was allocated by other means.  For example, bcache submits bios with
>    more than BIO_MAX_PAGES entries.  This results in bio_alloc() failure.
>    
>    To avoid the failure, change the code so that it allocates bio with at
>    most BIO_MAX_PAGES entries.  If the incoming bio has more entries,
>    bio_add_page() will fail and a new bio will be allocated - the code that
>    handles bio_add_page() failure already exists in the dm-log-writes
>    target.
>    
>    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
>    Reviewed-by: Josef Bacik <jbacik@fb,com>
>    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
>    Cc: stable@vger.kernel.org # v4.1+
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 0fe71822120598997bec6ac18b10e6348d06d80a
>Author: Mikulas Patocka <mpatocka@redhat.com>
>Date:   Tue Aug 30 16:11:53 2016 -0400
>
>    dm log writes: move IO accounting earlier to fix error path
>    
>    [ Upstream commit a5d60783df61fbb67b7596b8a0f6b4b2e05251d5 ]
>    
>    Move log_one_block()'s atomic_inc(&lc->io_blocks) before bio_alloc() to
>    fix a bug that the target hangs if bio_alloc() fails.  The error path
>    does put_io_block(lc), so atomic_inc(&lc->io_blocks) must occur before
>    invoking the error path to avoid underflow of lc->io_blocks.
>    
>    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
>    Reviewed-by: Josef Bacik <jbacik@fb,com>
>    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 99663cdecfa076d80d3a1f4bbfb9b3fc13c0a09a
>Author: Trond Myklebust <trond.myklebust@primarydata.com>
>Date:   Mon Aug 29 11:15:36 2016 -0400
>
>    NFSv4.x: Fix a refcount leak in nfs_callback_up_net
>    
>    [ Upstream commit 98b0f80c2396224bbbed81792b526e6c72ba9efa ]
>    
>    On error, the callers expect us to return without bumping
>    nn->cb_users[].
>    
>    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
>    Cc: stable@vger.kernel.org # v3.7+
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit f6b02c5ad3417caff26f3a5b41cf81d152df569c
>Author: Brian Foster <bfoster@redhat.com>
>Date:   Fri Aug 26 16:01:59 2016 +1000
>
>    xfs: prevent dropping ioend completions during buftarg wait
>    
>    [ Upstream commit 800b2694f890cc35a1bda63501fc71c94389d517 ]
>    
>    xfs_wait_buftarg() waits for all pending I/O, drains the ioend
>    completion workqueue and walks the LRU until all buffers in the cache
>    have been released. This is traditionally an unmount operation` but the
>    mechanism is also reused during filesystem freeze.
>    
>    xfs_wait_buftarg() invokes drain_workqueue() as part of the quiesce,
>    which is intended more for a shutdown sequence in that it indicates to
>    the queue that new operations are not expected once the drain has begun.
>    New work jobs after this point result in a WARN_ON_ONCE() and are
>    otherwise dropped.
>    
>    With filesystem freeze, however, read operations are allowed and can
>    proceed during or after the workqueue drain. If such a read occurs
>    during the drain sequence, the workqueue infrastructure complains about
>    the queued ioend completion work item and drops it on the floor. As a
>    result, the buffer remains on the LRU and the freeze never completes.
>    
>    Despite the fact that the overall buffer cache cleanup is not necessary
>    during freeze, fix up this operation such that it is safe to invoke
>    during non-unmount quiesce operations. Replace the drain_workqueue()
>    call with flush_workqueue(), which runs a similar serialization on
>    pending workqueue jobs without causing new jobs to be dropped. This is
>    safe for unmount as unmount independently locks out new operations by
>    the time xfs_wait_buftarg() is invoked.
>    
>    cc: <stable@vger.kernel.org>
>    Signed-off-by: Brian Foster <bfoster@redhat.com>
>    Reviewed-by: Christoph Hellwig <hch@lst.de>
>    Signed-off-by: Dave Chinner <david@fromorbit.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit d023f70ec430bc8431012e04117eb20d9d334fd1
>Author: Dave Chinner <dchinner@redhat.com>
>Date:   Fri Aug 26 16:01:30 2016 +1000
>
>    xfs: fix superblock inprogress check
>    
>    [ Upstream commit f3d7ebdeb2c297bd26272384e955033493ca291c ]
>    
>    From inspection, the superblock sb_inprogress check is done in the
>    verifier and triggered only for the primary superblock via a
>    "bp->b_bn == XFS_SB_DADDR" check.
>    
>    Unfortunately, the primary superblock is an uncached buffer, and
>    hence it is configured by xfs_buf_read_uncached() with:
>    
>    	bp->b_bn = XFS_BUF_DADDR_NULL;  /* always null for uncached buffers */
>    
>    And so this check never triggers. Fix it.
>    
>    cc: <stable@vger.kernel.org>
>    Signed-off-by: Dave Chinner <dchinner@redhat.com>
>    Reviewed-by: Brian Foster <bfoster@redhat.com>
>    Reviewed-by: Christoph Hellwig <hch@lst.de>
>    Signed-off-by: Dave Chinner <david@fromorbit.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 206538f128e7e3410e4042f7f15ccb1885adf477
>Author: Aleksandr Makarov <aleksandr.o.makarov@gmail.com>
>Date:   Wed Aug 24 13:06:22 2016 +0300
>
>    USB: serial: option: add WeTelecom 0x6802 and 0x6803 products
>    
>    [ Upstream commit 40d9c32525cba79130612650b1abc47c0c0f19a8 ]
>    
>    These product IDs are listed in Windows driver.
>    0x6803 corresponds to WeTelecom WM-D300.
>    0x6802 name is unknown.
>    
>    Signed-off-by: Aleksandr Makarov <aleksandr.o.makarov@gmail.com>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit b3e7cf060e94728eb7d791b824d52d2b93002934
>Author: Alan Stern <stern@rowland.harvard.edu>
>Date:   Tue Aug 23 15:32:51 2016 -0400
>
>    USB: avoid left shift by -1
>    
>    [ Upstream commit 53e5f36fbd2453ad69a3369a1db62dc06c30a4aa ]
>    
>    UBSAN complains about a left shift by -1 in proc_do_submiturb().  This
>    can occur when an URB is submitted for a bulk or control endpoint on
>    a high-speed device, since the code doesn't bother to check the
>    endpoint type; normally only interrupt or isochronous endpoints have
>    a nonzero bInterval value.
>    
>    Aside from the fact that the operation is illegal, it shouldn't matter
>    because the result isn't used.  Still, in theory it could cause a
>    hardware exception or other problem, so we should work around it.
>    This patch avoids doing the left shift unless the shift amount is >= 0.
>    
>    The same piece of code has another problem.  When checking the device
>    speed (the exponential encoding for interrupt endpoints is used only
>    by high-speed or faster devices), we need to look for speed >=
>    USB_SPEED_SUPER as well as speed == USB_SPEED HIGH.  The patch adds
>    this check.
>    
>    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
>    Reported-by: Vittorio Zecca <zeccav@gmail.com>
>    Tested-by: Vittorio Zecca <zeccav@gmail.com>
>    Suggested-by: BjÃ¸rn Mork <bjorn@mork.no>
>    CC: <stable@vger.kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit f3c774844e4950d7afab7a8d5518750cbcdcc5ed
>Author: Trond Myklebust <trond.myklebust@primarydata.com>
>Date:   Tue Aug 23 11:19:33 2016 -0400
>
>    pNFS: The client must not do I/O to the DS if it's lease has expired
>    
>    [ Upstream commit b88fa69eaa8649f11828158c7b65c4bcd886ebd5 ]
>    
>    Ensure that the client conforms to the normative behaviour described in
>    RFC5661 Section 12.7.2: "If a client believes its lease has expired,
>    it MUST NOT send I/O to the storage device until it has validated its
>    lease."
>    
>    So ensure that we wait for the lease to be validated before using
>    the layout.
>    
>    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
>    Cc: stable@vger.kernel.org # v3.20+
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 47998eb567e31b9b5f4b6ffcbacace83be60f915
>Author: Linus Walleij <linus.walleij@linaro.org>
>Date:   Tue Aug 16 15:33:28 2016 +0200
>
>    iio: accel: kxsd9: Fix raw read return
>    
>    [ Upstream commit 7ac61a062f3147dc23e3f12b9dfe7c4dd35f9cb8 ]
>    
>    Any readings from the raw interface of the KXSD9 driver will
>    return an empty string, because it does not return
>    IIO_VAL_INT but rather some random value from the accelerometer
>    to the caller.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit a29b7c9e11f7d494344c612a93dd2e9566e73189
>Author: Ian Abbott <abbotti@mev.co.uk>
>Date:   Tue Jul 19 12:17:39 2016 +0100
>
>    staging: comedi: ni_mio_common: fix AO inttrig backwards compatibility
>    
>    [ Upstream commit f0f4b0cc3a8cffd983f5940d46cd0227f3f5710a ]
>    
>    Commit ebb657babfa9 ("staging: comedi: ni_mio_common: clarify the
>    cmd->start_arg validation and use") introduced a backwards compatibility
>    issue in the use of asynchronous commands on the AO subdevice when
>    `start_src` is `TRIG_EXT`.  Valid values for `start_src` are `TRIG_INT`
>    (for internal, software trigger), and `TRIG_EXT` (for external trigger).
>    When set to `TRIG_EXT`.  In both cases, the driver relies on an
>    internal, software trigger to set things up (allowing the user
>    application to write sufficient samples to the data buffer before the
>    trigger), so it acts as a software "pre-trigger" in the `TRIG_EXT` case.
>    The software trigger is handled by `ni_ao_inttrig()`.
>    
>    Prior to the above change, when `start_src` was `TRIG_INT`, `start_arg`
>    was required to be 0, and `ni_ao_inttrig()` checked that the software
>    trigger number was also 0.  After the above change, when `start_src` was
>    `TRIG_INT`, any value was allowed for `start_arg`, and `ni_ao_inttrig()`
>    checked that the software trigger number matched this `start_arg` value.
>    The backwards compatibility issue is that the internal trigger number
>    now has to match `start_arg` when `start_src` is `TRIG_EXT` when it
>    previously had to be 0.
>    
>    Fix the backwards compatibility issue in `ni_ao_inttrig()` by always
>    allowing software trigger number 0 when `start_src` is something other
>    than `TRIG_INT`.
>    
>    Thanks to Spencer Olson for reporting the issue.
>    
>    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
>    Reported-by: Spencer Olson <olsonse@umich.edu>
>    Fixes: ebb657babfa9 ("staging: comedi: ni_mio_common: clarify the cmd->start_arg validation and use")
>    Cc: stable <stable@vger.kernel.org>
>    Reviewed-by: H Hartley Sweeten <hsweeten@visionengravers.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit f27b8038ac64fde76cc2910b82ec2e0f901a95f6
>Author: Ian Abbott <abbotti@mev.co.uk>
>Date:   Wed Jul 20 17:07:34 2016 +0100
>
>    staging: comedi: ni_mio_common: fix wrong insn_write handler
>    
>    [ Upstream commit 5ca05345c56cb979e1a25ab6146437002f95cac8 ]
>    
>    For counter subdevices, the `s->insn_write` handler is being set to the
>    wrong function, `ni_tio_insn_read()`.  It should be
>    `ni_tio_insn_write()`.
>    
>    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
>    Reported-by: Ãric Piel <piel@delmic.com>
>    Fixes: 10f74377eec3 ("staging: comedi: ni_tio: make ni_tio_winsn() a
>      proper comedi (*insn_write)"
>    Cc: <stable@vger.kernel.org> # 3.17+
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 33f100b86ffdb9bdfe682bb3b148dca1b8c1aefa
>Author: Ian Abbott <abbotti@mev.co.uk>
>Date:   Wed Jun 29 20:27:44 2016 +0100
>
>    staging: comedi: daqboard2000: bug fix board type matching code
>    
>    [ Upstream commit 80e162ee9b31d77d851b10f8c5299132be1e120f ]
>    
>    `daqboard2000_find_boardinfo()` is supposed to check if the
>    DaqBoard/2000 series model is supported, based on the PCI subvendor and
>    subdevice ID.  The current code is wrong as it is comparing the PCI
>    device's subdevice ID to an expected, fixed value for the subvendor ID.
>    It should be comparing the PCI device's subvendor ID to this fixed
>    value.  Correct it.
>    
>    Fixes: 7e8401b23e7f ("staging: comedi: daqboard2000: add back
>    subsystem_device check")
>    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
>    Cc: <stable@vger.kernel.org> # 3.7+
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit f8ce587f25d100e9afe29dfac5c6273e52311cc5
>Author: Aleksandr Makarov <aleksandr.o.makarov@gmail.com>
>Date:   Sat Aug 20 13:29:41 2016 +0300
>
>    USB: serial: option: add WeTelecom WM-D200
>    
>    [ Upstream commit 6695593e4a7659db49ac6eca98c164f7b5589f72 ]
>    
>    Add support for WeTelecom WM-D200.
>    
>    T:  Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  4 Spd=12  MxCh= 0
>    D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
>    P:  Vendor=22de ProdID=6801 Rev=00.00
>    S:  Manufacturer=WeTelecom Incorporated
>    S:  Product=WeTelecom Mobile Products
>    C:  #Ifs= 4 Cfg#= 1 Atr=80 MxPwr=500mA
>    I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
>    I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
>    I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
>    I:  If#= 3 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
>    
>    Signed-off-by: Aleksandr Makarov <aleksandr.o.makarov@gmail.com>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit b1918a087335a8ed6c8f1f090e3a41a62f8a3818
>Author: Li Jun <jun.li@nxp.com>
>Date:   Tue Aug 16 19:19:11 2016 +0800
>
>    usb: chipidea: udc: don't touch DP when controller is in host mode
>    
>    [ Upstream commit c4e94174983a86c935be1537a73e496b778b0287 ]
>    
>    When the controller is configured to be dual role and it's in host mode,
>    if bind udc and gadgt driver, those gadget operations will do gadget
>    disconnect and finally pull down DP line, which will break host function.
>    
>    Cc: <stable@vger.kernel.org> # 4.1+
>    Signed-off-by: Li Jun <jun.li@nxp.com>
>    Signed-off-by: Peter Chen <peter.chen@nxp.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 1898b62966e8c8d979278c66a977ba0fc3a2d128
>Author: Alexey Khoroshilov <khoroshilov@ispras.ru>
>Date:   Fri Aug 12 01:05:09 2016 +0300
>
>    USB: serial: mos7840: fix non-atomic allocation in write path
>    
>    [ Upstream commit 3b7c7e52efda0d4640060de747768360ba70a7c0 ]
>    
>    There is an allocation with GFP_KERNEL flag in mos7840_write(),
>    while it may be called from interrupt context.
>    
>    Follow-up for commit 191252837626 ("USB: kobil_sct: fix non-atomic
>    allocation in write path")
>    
>    Found by Linux Driver Verification project (linuxtesting.org).
>    
>    Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 9f4cc3bef0c5bbbec25390606b629821a953662e
>Author: Alexey Khoroshilov <khoroshilov@ispras.ru>
>Date:   Fri Aug 12 01:05:08 2016 +0300
>
>    USB: serial: mos7720: fix non-atomic allocation in write path
>    
>    [ Upstream commit 5a5a1d614287a647b36dff3f40c2b0ceabbc83ec ]
>    
>    There is an allocation with GFP_KERNEL flag in mos7720_write(),
>    while it may be called from interrupt context.
>    
>    Follow-up for commit 191252837626 ("USB: kobil_sct: fix non-atomic
>    allocation in write path")
>    
>    Found by Linux Driver Verification project (linuxtesting.org).
>    
>    Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 24628b51d97ff55e9a39ed87ea631af29604112f
>Author: Zefan Li <lizefan@huawei.com>
>Date:   Tue Aug 9 11:25:01 2016 +0800
>
>    cpuset: make sure new tasks conform to the current config of the cpuset
>    
>    [ Upstream commit 06f4e94898918bcad00cdd4d349313a439d6911e ]
>    
>    A new task inherits cpus_allowed and mems_allowed masks from its parent,
>    but if someone changes cpuset's config by writing to cpuset.cpus/cpuset.mems
>    before this new task is inserted into the cgroup's task list, the new task
>    won't be updated accordingly.
>    
>    Signed-off-by: Zefan Li <lizefan@huawei.com>
>    Signed-off-by: Tejun Heo <tj@kernel.org>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 214b2dab8107b130deeabec6db8d18439a64e738
>Author: Miklos Szeredi <mszeredi@redhat.com>
>Date:   Mon Aug 8 15:08:49 2016 +0200
>
>    ovl: don't copy up opaqueness
>    
>    [ Upstream commit 0956254a2d5b9e2141385514553aeef694dfe3b5 ]
>    
>    When a copy up of a directory occurs which has the opaque xattr set, the
>    xattr remains in the upper directory. The immediate behavior with overlayfs
>    is that the upper directory is not treated as opaque, however after a
>    remount the opaque flag is used and upper directory is treated as opaque.
>    This causes files created in the lower layer to be hidden when using
>    multiple lower directories.
>    
>    Fix by not copying up the opaque flag.
>    
>    To reproduce:
>    
>     ----8<---------8<---------8<---------8<---------8<---------8<----
>    mkdir -p l/d/s u v w mnt
>    mount -t overlay overlay -olowerdir=l,upperdir=u,workdir=w mnt
>    rm -rf mnt/d/
>    mkdir -p mnt/d/n
>    umount mnt
>    mount -t overlay overlay -olowerdir=u:l,upperdir=v,workdir=w mnt
>    touch mnt/d/foo
>    umount mnt
>    mount -t overlay overlay -olowerdir=u:l,upperdir=v,workdir=w mnt
>    ls mnt/d
>     ----8<---------8<---------8<---------8<---------8<---------8<----
>    
>    output should be:  "foo  n"
>    
>    Reported-by: Derek McGowan <dmcg@drizz.net>
>    Link: https://bugzilla.kernel.org/show_bug.cgi?id=151291
>    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit b9ee45d273cae7f7aa7dd82f7346f51812d4887e
>Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>Date:   Thu Aug 4 19:59:41 2016 +0900
>
>    dmaengine: usb-dmac: check CHCR.DE bit in usb_dmac_isr_channel()
>    
>    [ Upstream commit 626d2f07de89bf6be3d7301524d0ab3375b81b9c ]
>    
>    The USB-DMAC's interruption happens even if the CHCR.DE is not set to 1
>    because CHCR.NULLE is set to 1. So, this driver should call
>    usb_dmac_isr_transfer_end() if the DE bit is set to 1 only. Otherwise,
>    the desc is possible to be NULL in the usb_dmac_isr_transfer_end().
>    
>    Fixes: 0c1c8ff32fa2 ("dmaengine: usb-dmac: Add Renesas USB DMA Controller (USB-DMAC) driver)
>    Cc: <stable@vger.kernel.org> # v4.1+
>    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 0a6f7979199e0b976f39726feb0bbd96e9c04240
>Author: Theodore Ts'o <tytso@mit.edu>
>Date:   Mon Aug 1 00:51:02 2016 -0400
>
>    ext4: validate that metadata blocks do not overlap superblock
>    
>    [ Upstream commit 829fa70dddadf9dd041d62b82cd7cea63943899d ]
>    
>    A number of fuzzing failures seem to be caused by allocation bitmaps
>    or other metadata blocks being pointed at the superblock.
>    
>    This can cause kernel BUG or WARNings once the superblock is
>    overwritten, so validate the group descriptor blocks to make sure this
>    doesn't happen.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 469a242127b181656cb0a07de4584215bd4494fb
>Author: Al Viro <viro@zeniv.linux.org.uk>
>Date:   Mon Dec 28 20:47:08 2015 -0500
>
>    [PATCH] arm: fix handling of F_OFD_... in oabi_fcntl64()
>    
>    [ Upstream commit 76cc404bfdc0d419c720de4daaf2584542734f42 ]
>    
>    Cc: stable@vger.kernel.org # 3.15+
>    Reviewed-by: Jeff Layton <jeff.layton@primarydata.com>
>    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 871499e342fc0fe42e7dbef00fb680bef217c1c5
>Author: Ian Abbott <abbotti@mev.co.uk>
>Date:   Wed Sep 7 11:35:32 2016 -0400
>
>    staging: comedi: comedi_test: fix timer race conditions
>    
>    [ commit 403fe7f34e3327ddac2e06a15e76a293d613381e upstream.
>    
>      Patch is cut down a bit from upstream patch, as upstream patch fixed
>      parts that don't exist in this version.  Also, some identifiers were
>      renamed, so patch description has been edited accordingly
>      -- Ian Abbott
>    ]
>    
>    Commit 73e0e4dfed4c ("staging: comedi: comedi_test: fix timer lock-up")
>    fixed a lock-up in the timer routine `waveform_ai_interrupt()` caused by
>    commit 240512474424 ("staging: comedi: comedi_test: use
>    comedi_handle_events()").  However, it introduced a race condition that
>    can result in the timer routine misbehaving, such as accessing freed
>    memory or dereferencing a NULL pointer.
>    
>    73e0... changed the timer routine to do nothing unless a
>    `WAVEFORM_AI_RUNNING` flag was set, and changed `waveform_ai_cancel()`
>    to clear the flag and replace a call to `del_timer_sync()` with a call
>    to `del_timer()`.  `waveform_ai_cancel()` may be called from the timer
>    routine itself (via `comedi_handle_events()`), or from `do_cancel()`.
>    (`do_cancel()` is called as a result of a file operation (usually a
>    `COMEDI_CANCEL` ioctl command, or a release), or during device removal.)
>    When called from `do_cancel()`, the call to `waveform_ai_cancel()` is
>    followed by a call to `do_become_nonbusy()`, which frees up stuff for
>    the current asynchronous command under the assumption that it is now
>    safe to do so.  The race condition occurs when the timer routine
>    `waveform_ai_interrupt()` checks the `WAVEFORM_AI_RUNNING` flag just
>    before it is cleared by `waveform_ai_cancel()`, and is still running
>    during the call to `do_become_nonbusy()`.  In particular, it can lead to
>    a NULL pointer dereference because `do_become_nonbusy()` frees
>    `async->cmd.chanlist` and sets it to `NULL`, but
>    `waveform_ai_interrupt()` dereferences it.
>    
>    Fix the race by calling `del_timer_sync()` instead of `del_timer()` in
>    `waveform_ai_cancel()` when not in an interrupt context.  The only time
>    `waveform_ai_cancel()` is called in an interrupt context is when it is
>    called from the timer routine itself, via `comedi_handle_events()`.
>    
>    There is no longer any need for the `WAVEFORM_AI_RUNNING` flag, so get
>    rid of it.
>    
>    Fixes: 73e0e4dfed4c ("staging: comedi: comedi_test: fix timer lock-up")
>    Reported-by: Ãric Piel <piel@delmic.com>
>    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
>    Cc: Ãric Piel <piel@delmic.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 3b60b86aec06fbae1142ccc4e55b39b529ae2a25
>Author: Sasha Levin <alexander.levin@verizon.com>
>Date:   Fri Sep 2 22:46:14 2016 -0400
>
>    Linux 4.1.32
>    
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit dfd742cecf233b6b4a1d903a9c64f1b4bf04f1da
>Author: Simon Horman <simon.horman@netronome.com>
>Date:   Fri Dec 11 11:30:12 2015 +0900
>
>    PCI: Limit config space size for Netronome NFP4000
>    
>    [ Upstream commit c2e771b02792d222cbcd9617fe71482a64f52647 ]
>    
>    Like the NFP6000, the NFP4000 as an erratum where reading/writing to PCI
>    config space addresses above 0x600 can cause the NFP to generate PCIe
>    completion timeouts.
>    
>    Limit the NFP4000's PF's config space size to 0x600 bytes as is already
>    done for the NFP6000.
>    
>    The NFP4000's VF is 0x6004 (PCI_DEVICE_ID_NETRONOME_NFP6000_VF), the same
>    device ID as the NFP6000's VF.  Thus, its config space is already limited
>    by the existing use of quirk_nfp6000().
>    
>    Signed-off-by: Simon Horman <simon.horman@netronome.com>
>    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 8d3cd03ce36cf9673ce0625d648184b2fab25853
>Author: Simon Horman <simon.horman@netronome.com>
>Date:   Fri Dec 11 11:30:11 2015 +0900
>
>    PCI: Add Netronome NFP4000 PF device ID
>    
>    [ Upstream commit 69874ec233871a62e1bc8c89e643993af93a8630 ]
>    
>    Add the device ID for the PF of the NFP4000.  The device ID for the VF,
>    0x6003, is already present as PCI_DEVICE_ID_NETRONOME_NFP6000_VF.
>    
>    Signed-off-by: Simon Horman <simon.horman@netronome.com>
>    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 2ca638dd9ba7a92a75196831e48cd22536e54787
>Author: Jason S. McMullan <jason.mcmullan@netronome.com>
>Date:   Wed Sep 30 15:35:07 2015 +0900
>
>    PCI: Limit config space size for Netronome NFP6000 family
>    
>    [ Upstream commit 9f33a2ae59f24452c1076749deb615bccd435ca9 ]
>    
>    The NFP6000 has an erratum where reading/writing to PCI config space
>    addresses above 0x600 can cause the NFP to generate PCIe completion
>    timeouts.
>    
>    Limit the NFP6000's config space size to 0x600 bytes.
>    
>    Signed-off-by: Jason S. McMullan <jason.mcmullan@netronome.com>
>    [simon: edited changelog]
>    Signed-off-by: Simon Horman <simon.horman@netronome.com>
>    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>    
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit ebcd02166277b5754a731d48a8ee004133abc345
>Author: Jason S. McMullan <jason.mcmullan@netronome.com>
>Date:   Wed Sep 30 15:35:06 2015 +0900
>
>    PCI: Add Netronome vendor and device IDs
>    
>    [ Upstream commit a755e169031dac9ebaed03302c4921687c271d62 ]
>    
>    Device IDs for the Netronome NFP3200, NFP3240, NFP6000, and NFP6000 SR-IOV
>    devices.
>    
>    Signed-off-by: Jason S. McMullan <jason.mcmullan@netronome.com>
>    [simon: edited changelog]
>    Signed-off-by: Simon Horman <simon.horman@netronome.com>
>    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>    
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 884740187257c03adae546c2bd9ca2b851785924
>Author: Jason S. McMullan <jason.mcmullan@netronome.com>
>Date:   Wed Sep 30 15:35:05 2015 +0900
>
>    PCI: Support PCIe devices with short cfg_size
>    
>    [ Upstream commit c20aecf6963d1273d8f6d61c042b4845441ca592 ]
>    
>    If a device quirk modifies the pci_dev->cfg_size to be less than
>    PCI_CFG_SPACE_EXP_SIZE (4096), but greater than PCI_CFG_SPACE_SIZE (256),
>    the PCI sysfs interface truncates the readable size to PCI_CFG_SPACE_SIZE.
>    
>    Allow sysfs access to config space up to cfg_size, even if the device
>    doesn't support the entire 4096-byte PCIe config space.
>    
>    Note that pci_read_config() and pci_write_config() limit access to
>    dev->cfg_size even though pcie_config_attr contains 4096 (the maximum
>    size).
>    
>    Signed-off-by: Jason S. McMullan <jason.mcmullan@netronome.com>
>    [simon: edited changelog]
>    Signed-off-by: Simon Horman <simon.horman@netronome.com>
>    [bhelgaas: more changelog edits]
>    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>    
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit f7bb9ba34f4697790b144368377a268f3f2634e0
>Author: Vegard Nossum <vegard.nossum@oracle.com>
>Date:   Thu Aug 25 15:17:11 2016 -0700
>
>    fs/seq_file: fix out-of-bounds read
>    
>    [ Upstream commit 088bf2ff5d12e2e32ee52a4024fec26e582f44d3 ]
>    
>    seq_read() is a nasty piece of work, not to mention buggy.
>    
>    It has (I think) an old bug which allows unprivileged userspace to read
>    beyond the end of m->buf.
>    
>    I was getting these:
>    
>        BUG: KASAN: slab-out-of-bounds in seq_read+0xcd2/0x1480 at addr ffff880116889880
>        Read of size 2713 by task trinity-c2/1329
>        CPU: 2 PID: 1329 Comm: trinity-c2 Not tainted 4.8.0-rc1+ #96
>        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
>        Call Trace:
>          kasan_object_err+0x1c/0x80
>          kasan_report_error+0x2cb/0x7e0
>          kasan_report+0x4e/0x80
>          check_memory_region+0x13e/0x1a0
>          kasan_check_read+0x11/0x20
>          seq_read+0xcd2/0x1480
>          proc_reg_read+0x10b/0x260
>          do_loop_readv_writev.part.5+0x140/0x2c0
>          do_readv_writev+0x589/0x860
>          vfs_readv+0x7b/0xd0
>          do_readv+0xd8/0x2c0
>          SyS_readv+0xb/0x10
>          do_syscall_64+0x1b3/0x4b0
>          entry_SYSCALL64_slow_path+0x25/0x25
>        Object at ffff880116889100, in cache kmalloc-4096 size: 4096
>        Allocated:
>        PID = 1329
>          save_stack_trace+0x26/0x80
>          save_stack+0x46/0xd0
>          kasan_kmalloc+0xad/0xe0
>          __kmalloc+0x1aa/0x4a0
>          seq_buf_alloc+0x35/0x40
>          seq_read+0x7d8/0x1480
>          proc_reg_read+0x10b/0x260
>          do_loop_readv_writev.part.5+0x140/0x2c0
>          do_readv_writev+0x589/0x860
>          vfs_readv+0x7b/0xd0
>          do_readv+0xd8/0x2c0
>          SyS_readv+0xb/0x10
>          do_syscall_64+0x1b3/0x4b0
>          return_from_SYSCALL_64+0x0/0x6a
>        Freed:
>        PID = 0
>        (stack is not available)
>        Memory state around the buggy address:
>         ffff88011688a000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>         ffff88011688a080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>        >ffff88011688a100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>    		       ^
>         ffff88011688a180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>         ffff88011688a200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>        ==================================================================
>        Disabling lock debugging due to kernel taint
>    
>    This seems to be the same thing that Dave Jones was seeing here:
>    
>      https://lkml.org/lkml/2016/8/12/334
>    
>    There are multiple issues here:
>    
>      1) If we enter the function with a non-empty buffer, there is an attempt
>         to flush it. But it was not clearing m->from after doing so, which
>         means that if we try to do this flush twice in a row without any call
>         to traverse() in between, we are going to be reading from the wrong
>         place -- the splat above, fixed by this patch.
>    
>      2) If there's a short write to userspace because of page faults, the
>         buffer may already contain multiple lines (i.e. pos has advanced by
>         more than 1), but we don't save the progress that was made so the
>         next call will output what we've already returned previously. Since
>         that is a much less serious issue (and I have a headache after
>         staring at seq_read() for the past 8 hours), I'll leave that for now.
>    
>    Link: http://lkml.kernel.org/r/1471447270-32093-1-git-send-email-vegard.nossum@oracle.com
>    Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
>    Reported-by: Dave Jones <davej@codemonkey.org.uk>
>    Cc: Al Viro <viro@zeniv.linux.org.uk>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 942d5c08badb801dc6cddea30053840af05a6b43
>Author: Chen-Yu Tsai <wens@csie.org>
>Date:   Thu Aug 25 14:26:59 2016 +0800
>
>    clocksource/drivers/sun4i: Clear interrupts after stopping timer in probe function
>    
>    [ Upstream commit b53e7d000d9e6e9fd2c6eb6b82d2783c67fd599e ]
>    
>    The bootloader (U-boot) sometimes uses this timer for various delays.
>    It uses it as a ongoing counter, and does comparisons on the current
>    counter value. The timer counter is never stopped.
>    
>    In some cases when the user interacts with the bootloader, or lets
>    it idle for some time before loading Linux, the timer may expire,
>    and an interrupt will be pending. This results in an unexpected
>    interrupt when the timer interrupt is enabled by the kernel, at
>    which point the event_handler isn't set yet. This results in a NULL
>    pointer dereference exception, panic, and no way to reboot.
>    
>    Clear any pending interrupts after we stop the timer in the probe
>    function to avoid this.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>    Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 917f1531b13efbc52acbc9fc0a65c258f01bfbc4
>Author: Mike Snitzer <snitzer@redhat.com>
>Date:   Wed Aug 24 21:12:58 2016 -0400
>
>    dm flakey: fix reads to be issued if drop_writes configured
>    
>    [ Upstream commit 299f6230bc6d0ccd5f95bb0fb865d80a9c7d5ccc ]
>    
>    v4.8-rc3 commit 99f3c90d0d ("dm flakey: error READ bios during the
>    down_interval") overlooked the 'drop_writes' feature, which is meant to
>    allow reads to be issued rather than errored, during the down_interval.
>    
>    Fixes: 99f3c90d0d ("dm flakey: error READ bios during the down_interval")
>    Reported-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
>    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 1d6a6dc25a83afb263fcc961d3714b6e30ba7fd1
>Author: Jan Beulich <JBeulich@suse.com>
>Date:   Mon Aug 15 09:02:38 2016 -0600
>
>    xenbus: don't look up transaction IDs for ordinary writes
>    
>    [ Upstream commit 9a035a40f7f3f6708b79224b86c5777a3334f7ea ]
>    
>    This should really only be done for XS_TRANSACTION_END messages, or
>    else at least some of the xenstore-* tools don't work anymore.
>    
>    Fixes: 0beef634b8 ("xenbus: don't BUG() on user mode induced condition")
>    Reported-by: Richard SchÃ¼tz <rschuetz@uni-koblenz.de>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Jan Beulich <jbeulich@suse.com>
>    Tested-by: Richard SchÃ¼tz <rschuetz@uni-koblenz.de>
>    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 083e76a59d21becc555ebcfd23a3821044096fa2
>Author: Wanpeng Li <wanpeng.li@hotmail.com>
>Date:   Tue Aug 23 20:07:19 2016 +0800
>
>    x86/apic: Do not init irq remapping if ioapic is disabled
>    
>    [ Upstream commit 2e63ad4bd5dd583871e6602f9d398b9322d358d9 ]
>    
>    native_smp_prepare_cpus
>      -> default_setup_apic_routing
>        -> enable_IR_x2apic
>          -> irq_remapping_prepare
>            -> intel_prepare_irq_remapping
>              -> intel_setup_irq_remapping
>    
>    So IR table is setup even if "noapic" boot parameter is added. As a result we
>    crash later when the interrupt affinity is set due to a half initialized
>    remapping infrastructure.
>    
>    Prevent remap initialization when IOAPIC is disabled.
>    
>    Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Joerg Roedel <joro@8bytes.org>
>    Link: http://lkml.kernel.org/r/1471954039-3942-1-git-send-email-wanpeng.li@hotmail.com
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit a3f914be622e423eb9f8d24128d3b965fa3d9b8a
>Author: John Stultz <john.stultz@linaro.org>
>Date:   Tue Aug 23 16:08:22 2016 -0700
>
>    timekeeping: Cap array access in timekeeping_debug
>    
>    [ Upstream commit a4f8f6667f099036c88f231dcad4cf233652c824 ]
>    
>    It was reported that hibernation could fail on the 2nd attempt, where the
>    system hangs at hibernate() -> syscore_resume() -> i8237A_resume() ->
>    claim_dma_lock(), because the lock has already been taken.
>    
>    However there is actually no other process would like to grab this lock on
>    that problematic platform.
>    
>    Further investigation showed that the problem is triggered by setting
>    /sys/power/pm_trace to 1 before the 1st hibernation.
>    
>    Since once pm_trace is enabled, the rtc becomes unmeaningful after suspend,
>    and meanwhile some BIOSes would like to adjust the 'invalid' RTC (e.g, smaller
>    than 1970) to the release date of that motherboard during POST stage, thus
>    after resumed, it may seem that the system had a significant long sleep time
>    which is a completely meaningless value.
>    
>    Then in timekeeping_resume -> tk_debug_account_sleep_time, if the bit31 of the
>    sleep time happened to be set to 1, fls() returns 32 and we add 1 to
>    sleep_time_bin[32], which causes an out of bounds array access and therefor
>    memory being overwritten.
>    
>    As depicted by System.map:
>    0xffffffff81c9d080 b sleep_time_bin
>    0xffffffff81c9d100 B dma_spin_lock
>    the dma_spin_lock.val is set to 1, which caused this problem.
>    
>    This patch adds a sanity check in tk_debug_account_sleep_time()
>    to ensure we don't index past the sleep_time_bin array.
>    
>    [jstultz: Problem diagnosed and original patch by Chen Yu, I've solved the
>     issue slightly differently, but borrowed his excelent explanation of the
>     issue here.]
>    
>    Fixes: 5c83545f24ab "power: Add option to log time spent in suspend"
>    Reported-by: Janek Kozicki <cosurgi@gmail.com>
>    Reported-by: Chen Yu <yu.c.chen@intel.com>
>    Signed-off-by: John Stultz <john.stultz@linaro.org>
>    Cc: linux-pm@vger.kernel.org
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Xunlei Pang <xpang@redhat.com>
>    Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
>    Cc: stable <stable@vger.kernel.org>
>    Cc: Zhang Rui <rui.zhang@intel.com>
>    Link: http://lkml.kernel.org/r/1471993702-29148-3-git-send-email-john.stultz@linaro.org
>    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 0c7b2c2aea55b4e940e3de8b41658855aebcbca4
>Author: John Stultz <john.stultz@linaro.org>
>Date:   Tue Aug 23 16:08:21 2016 -0700
>
>    timekeeping: Avoid taking lock in NMI path with CONFIG_DEBUG_TIMEKEEPING
>    
>    [ Upstream commit 27727df240c7cc84f2ba6047c6f18d5addfd25ef ]
>    
>    When I added some extra sanity checking in timekeeping_get_ns() under
>    CONFIG_DEBUG_TIMEKEEPING, I missed that the NMI safe __ktime_get_fast_ns()
>    method was using timekeeping_get_ns().
>    
>    Thus the locking added to the debug checks broke the NMI-safety of
>    __ktime_get_fast_ns().
>    
>    This patch open-codes the timekeeping_get_ns() logic for
>    __ktime_get_fast_ns(), so can avoid any deadlocks in NMI.
>    
>    Fixes: 4ca22c2648f9 "timekeeping: Add warnings when overflows or underflows are observed"
>    Reported-by: Steven Rostedt <rostedt@goodmis.org>
>    Reported-by: Peter Zijlstra <peterz@infradead.org>
>    Signed-off-by: John Stultz <john.stultz@linaro.org>
>    Cc: stable <stable@vger.kernel.org>
>    Link: http://lkml.kernel.org/r/1471993702-29148-2-git-send-email-john.stultz@linaro.org
>    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 2d701beb5dd816fa4c1115c88d464a6cc0e7271f
>Author: Andrey Ryabinin <aryabinin@virtuozzo.com>
>Date:   Wed Aug 17 18:10:11 2016 +0300
>
>    um: Don't discard .text.exit section
>    
>    [ Upstream commit dad2232844073295c64e9cc2d734a0ade043e0f6 ]
>    
>    Commit e41f501d3912 ("vmlinux.lds: account for destructor sections")
>    added '.text.exit' to EXIT_TEXT which is discarded at link time by default.
>    This breaks compilation of UML:
>         `.text.exit' referenced in section `.fini_array' of
>         /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(sdlerror.o):
>         defined in discarded section `.text.exit' of
>         /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(sdlerror.o)
>    
>    Apparently UML doesn't want to discard exit text, so let's place all EXIT_TEXT
>    sections in .exit.text.
>    
>    Fixes: e41f501d3912 ("vmlinux.lds: account for destructor sections")
>    Reported-by: Stefan Traby <stefan@hello-penguin.com>
>    Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
>    Cc: <stable@vger.kernel.org>
>    Acked-by: Dmitry Vyukov <dvyukov@google.com>
>    Signed-off-by: Richard Weinberger <richard@nod.at>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit befdc6e859950c790f8b1c255049f036d3c7754a
>Author: Vincent StehlÃ© <vincent.stehle@intel.com>
>Date:   Fri Aug 12 15:26:30 2016 +0200
>
>    ubifs: Fix assertion in layout_in_gaps()
>    
>    [ Upstream commit c0082e985fdf77b02fc9e0dac3b58504dcf11b7a ]
>    
>    An assertion in layout_in_gaps() verifies that the gap_lebs pointer is
>    below the maximum bound. When computing this maximum bound the idx_lebs
>    count is multiplied by sizeof(int), while C pointers arithmetic does take
>    into account the size of the pointed elements implicitly already. Remove
>    the multiplication to fix the assertion.
>    
>    Fixes: 1e51764a3c2ac05a ("UBIFS: add new flash file system")
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Vincent StehlÃ© <vincent.stehle@intel.com>
>    Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
>    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
>    Signed-off-by: Richard Weinberger <richard@nod.at>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit d9a5bd9d810fdb2e66fa749b76bd1b8efecd290e
>Author: Benjamin Coddington <bcodding@redhat.com>
>Date:   Mon Jun 6 18:07:59 2016 -0400
>
>    vhost/scsi: fix reuse of &vq->iov[out] in response
>    
>    [ Upstream commit a77ec83a57890240c546df00ca5df1cdeedb1cc3 ]
>    
>    The address of the iovec &vq->iov[out] is not guaranteed to contain the scsi
>    command's response iovec throughout the lifetime of the command.  Rather, it
>    is more likely to contain an iovec from an immediately following command
>    after looping back around to vhost_get_vq_desc().  Pass along the iovec
>    entirely instead.
>    
>    Fixes: 79c14141a487 ("vhost/scsi: Convert completion path to use copy_to_iter")
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
>    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit f85090ffc9bf6cb6734f563fb42e878b20314bab
>Author: Masahiro Yamada <yamada.masahiro@socionext.com>
>Date:   Mon Aug 22 13:25:56 2016 -0700
>
>    Input: tegra-kbc - fix inverted reset logic
>    
>    [ Upstream commit fae16989be77b09bab86c79233e4b511ea769cea ]
>    
>    Commit fe6b0dfaba68 ("Input: tegra-kbc - use reset framework")
>    accidentally converted _deassert to _assert, so there is no code
>    to wake up this hardware.
>    
>    Fixes: fe6b0dfaba68 ("Input: tegra-kbc - use reset framework")
>    Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>    Acked-by: Thierry Reding <treding@nvidia.com>
>    Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit bdd62ec6d873be9e3bcdc34d2deb45a541873650
>Author: Andrej Krutak <dev@andree.sk>
>Date:   Thu Aug 18 23:52:12 2016 +0200
>
>    ALSA: line6: Fix POD sysfs attributes segfault
>    
>    [ Upstream commit b027d11263836a0cd335520175257dcb99b43757 ]
>    
>    The commit 02fc76f6a changed base of the sysfs attributes from device to card.
>    The "show" callbacks dereferenced wrong objects because of this.
>    
>    Fixes: 02fc76f6a7db ('ALSA: line6: Create sysfs via snd_card_add_dev_attr()')
>    Cc: <stable@vger.kernel.org> # v4.0+
>    Reviewed-by: Stefan Hajnoczi <stefanha@gmail.com>
>    Signed-off-by: Andrej Krutak <dev@andree.sk>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 571d36168dc246837e96ce40a7e535f1b70622e6
>Author: Andrej Krutak <dev@andree.sk>
>Date:   Thu Aug 18 23:52:11 2016 +0200
>
>    ALSA: line6: Give up on the lock while URBs are released.
>    
>    [ Upstream commit adc8a43a6d6688272ebffa81789fa857e603dec6 ]
>    
>    Done, because line6_stream_stop() locks and calls line6_unlink_audio_urbs(),
>    which in turn invokes audio_out_callback(), which tries to lock 2nd time.
>    
>    Fixes:
>    
>    =============================================
>    [ INFO: possible recursive locking detected ]
>    4.4.15+ #15 Not tainted
>    ---------------------------------------------
>    mplayer/3591 is trying to acquire lock:
>     (&(&line6pcm->out.lock)->rlock){-.-...}, at: [<bfa27655>] audio_out_callback+0x70/0x110 [snd_usb_line6]
>    
>    but task is already holding lock:
>     (&(&line6pcm->out.lock)->rlock){-.-...}, at: [<bfa26aad>] line6_stream_stop+0x24/0x5c [snd_usb_line6]
>    
>    other info that might help us debug this:
>     Possible unsafe locking scenario:
>    
>           CPU0
>           ----
>      lock(&(&line6pcm->out.lock)->rlock);
>      lock(&(&line6pcm->out.lock)->rlock);
>    
>     *** DEADLOCK ***
>    
>     May be due to missing lock nesting notation
>    
>    3 locks held by mplayer/3591:
>     #0:  (snd_pcm_link_rwlock){.-.-..}, at: [<bf8d49a7>] snd_pcm_stream_lock+0x1e/0x40 [snd_pcm]
>     #1:  (&(&substream->self_group.lock)->rlock){-.-...}, at: [<bf8d49af>] snd_pcm_stream_lock+0x26/0x40 [snd_pcm]
>     #2:  (&(&line6pcm->out.lock)->rlock){-.-...}, at: [<bfa26aad>] line6_stream_stop+0x24/0x5c [snd_usb_line6]
>    
>    stack backtrace:
>    CPU: 0 PID: 3591 Comm: mplayer Not tainted 4.4.15+ #15
>    Hardware name: Generic AM33XX (Flattened Device Tree)
>    [<c0015d85>] (unwind_backtrace) from [<c001253d>] (show_stack+0x11/0x14)
>    [<c001253d>] (show_stack) from [<c02f1bdf>] (dump_stack+0x8b/0xac)
>    [<c02f1bdf>] (dump_stack) from [<c0076f43>] (__lock_acquire+0xc8b/0x1780)
>    [<c0076f43>] (__lock_acquire) from [<c007810d>] (lock_acquire+0x99/0x1c0)
>    [<c007810d>] (lock_acquire) from [<c06171e7>] (_raw_spin_lock_irqsave+0x3f/0x4c)
>    [<c06171e7>] (_raw_spin_lock_irqsave) from [<bfa27655>] (audio_out_callback+0x70/0x110 [snd_usb_line6])
>    [<bfa27655>] (audio_out_callback [snd_usb_line6]) from [<c04294db>] (__usb_hcd_giveback_urb+0x53/0xd0)
>    [<c04294db>] (__usb_hcd_giveback_urb) from [<c046388d>] (musb_giveback+0x3d/0x98)
>    [<c046388d>] (musb_giveback) from [<c04647f5>] (musb_urb_dequeue+0x6d/0x114)
>    [<c04647f5>] (musb_urb_dequeue) from [<c042ac11>] (usb_hcd_unlink_urb+0x39/0x98)
>    [<c042ac11>] (usb_hcd_unlink_urb) from [<bfa26a87>] (line6_unlink_audio_urbs+0x6a/0x6c [snd_usb_line6])
>    [<bfa26a87>] (line6_unlink_audio_urbs [snd_usb_line6]) from [<bfa26acb>] (line6_stream_stop+0x42/0x5c [snd_usb_line6])
>    [<bfa26acb>] (line6_stream_stop [snd_usb_line6]) from [<bfa26fe7>] (snd_line6_trigger+0xb6/0xf4 [snd_usb_line6])
>    [<bfa26fe7>] (snd_line6_trigger [snd_usb_line6]) from [<bf8d47b7>] (snd_pcm_do_stop+0x36/0x38 [snd_pcm])
>    [<bf8d47b7>] (snd_pcm_do_stop [snd_pcm]) from [<bf8d462f>] (snd_pcm_action_single+0x22/0x40 [snd_pcm])
>    [<bf8d462f>] (snd_pcm_action_single [snd_pcm]) from [<bf8d46f9>] (snd_pcm_action+0xac/0xb0 [snd_pcm])
>    [<bf8d46f9>] (snd_pcm_action [snd_pcm]) from [<bf8d4b61>] (snd_pcm_drop+0x38/0x64 [snd_pcm])
>    [<bf8d4b61>] (snd_pcm_drop [snd_pcm]) from [<bf8d6233>] (snd_pcm_common_ioctl1+0x7fe/0xbe8 [snd_pcm])
>    [<bf8d6233>] (snd_pcm_common_ioctl1 [snd_pcm]) from [<bf8d6779>] (snd_pcm_playback_ioctl1+0x15c/0x51c [snd_pcm])
>    [<bf8d6779>] (snd_pcm_playback_ioctl1 [snd_pcm]) from [<bf8d6b59>] (snd_pcm_playback_ioctl+0x20/0x28 [snd_pcm])
>    [<bf8d6b59>] (snd_pcm_playback_ioctl [snd_pcm]) from [<c016714b>] (do_vfs_ioctl+0x3af/0x5c8)
>    
>    Fixes: 63e20df1e5b2 ('ALSA: line6: Reorganize PCM stream handling')
>    Cc: <stable@vger.kernel.org> # v4.0+
>    Reviewed-by: Stefan Hajnoczi <stefanha@gmail.com>
>    Signed-off-by: Andrej Krutak <dev@andree.sk>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit c717f88b1a8019a02d769cdefe27a4e38b49c2a3
>Author: Andrej Krutak <dev@andree.sk>
>Date:   Thu Aug 18 23:52:10 2016 +0200
>
>    ALSA: line6: Remove double line6_pcm_release() after failed acquire.
>    
>    [ Upstream commit 7e4379eae0e31994ea645db1d13006ea8e5ce539 ]
>    
>    If there's an error, pcm is released in line6_pcm_acquire already.
>    
>    Fixes: 247d95ee6dd2 ('ALSA: line6: Handle error from line6_pcm_acquire()')
>    Cc: <stable@vger.kernel.org> # v4.0+
>    Reviewed-by: Stefan Hajnoczi <stefanha@gmail.com>
>    Signed-off-by: Andrej Krutak <dev@andree.sk>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 6c000a45a7d0e667eef0e3e568c4ff7fdba8faab
>Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>Date:   Sat Aug 20 12:22:11 2016 +0200
>
>    drm: Reject page_flip for !DRIVER_MODESET
>    
>    [ Upstream commit 6f00975c619064a18c23fd3aced325ae165a73b9 ]
>    
>    Somehow this one slipped through, which means drivers without modeset
>    support can be oopsed (since those also don't call
>    drm_mode_config_init, which means the crtc lookup will chase an
>    uninitalized idr).
>    
>    Reported-by: Alexander Potapenko <glider@google.com>
>    Cc: Alexander Potapenko <glider@google.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
>    Signed-off-by: Dave Airlie <airlied@redhat.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit f4eaf28c0926c1cc03af31f5e0a115abec91a0b3
>Author: Helge Deller <deller@gmx.de>
>Date:   Sat Aug 20 11:51:38 2016 +0200
>
>    parisc: Fix order of EREFUSED define in errno.h
>    
>    [ Upstream commit 3eb53b20d7bd1374598cfb1feaa081fcac0e76cd ]
>    
>    When building gccgo in userspace, errno.h gets parsed and the go include file
>    sysinfo.go is generated.
>    
>    Since EREFUSED is defined to the same value as ECONNREFUSED, and ECONNREFUSED
>    is defined later on in errno.h, this leads to go complaining that EREFUSED
>    isn't defined yet.
>    
>    Fix this trivial problem by moving the define of EREFUSED down after
>    ECONNREFUSED in errno.h (and clean up the indenting while touching this line).
>    
>    Signed-off-by: Helge Deller <deller@gmx.de>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 66751ff14c7d5429e7f2d014748c8e7549dc2361
>Author: Vineet Gupta <vgupta@synopsys.com>
>Date:   Fri Aug 19 13:59:02 2016 -0700
>
>    ARC: export __udivdi3 for modules
>    
>    [ Upstream commit c57653dc94d0db7bf63067433ceaa97bdcd0a312 ]
>    
>    Some module using div_u64() was failing to link because the libgcc 64-bit
>    divide assist routine was not being exported for modules
>    
>    Reported-by: avinashp@quantenna.com
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 871b20f18e93a25aca3d1980589e5ae5ec1a4b9d
>Author: Vineet Gupta <vgupta@synopsys.com>
>Date:   Wed Aug 10 14:10:57 2016 -0700
>
>    ARC: Support syscall ABI v4
>    
>    [ Upstream commit 840c054fd0efb048df6fceb0c46385ec5b66dfe6 ]
>    
>    The syscall ABI includes the gcc functional calling ABI since a syscall
>    implies userland caller and kernel callee.
>    
>    The current gcc ABI (v3) for ARCv2 ISA required 64-bit data be passed in
>    even-odd register pairs, (potentially punching reg holes when passing such
>    values as args). This was partly driven by the fact that the double-word
>    LDD/STD instructions in ARCv2 expect the register alignment and thus gcc
>    forcing this avoids extra MOV at the cost of a few unused register (which we
>    have plenty anyways).
>    
>    This however was rejected as part of upstreaming gcc port to HS. So the new
>    ABI v4 doesn't enforce the even-odd reg restriction.
>    
>    Do note that for ARCompact ISA builds v3 and v4 are practically the same in
>    terms of gcc code generation.
>    
>    In terms of change management, we infer the new ABI if gcc 6.x onwards
>    is used for building the kernel.
>    
>    This also needs a stable backport to enable older kernels to work with
>    new tools/user-space
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 35de4db88c800c40f46959709674089d9e07743b
>Author: Liav Rehana <liavr@mellanox.com>
>Date:   Tue Aug 16 10:55:35 2016 +0300
>
>    ARC: use correct offset in pt_regs for saving/restoring user mode r25
>    
>    [ Upstream commit 86147e3cfa5e118b61e78f4f0bf29e920dcbd477 ]
>    
>    User mode callee regs are explicitly collected before signal delivery or
>    breakpoint trap. r25 is special for kernel as it serves as task pointer,
>    so user mode value is clobbered very early. It is saved in pt_regs where
>    generally only scratch (aka caller saved) regs are saved.
>    
>    The code to access the corresponding pt_regs location had a subtle bug as
>    it was using load/store with scaling of offset, whereas the offset was already
>    byte wise correct. So fix this by replacing LD.AS with a standard LD
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Liav Rehana <liavr@mellanox.com>
>    Reviewed-by: Alexey Brodkin <abrodkin@synopsys.com>
>    [vgupta: rewrote title and commit log]
>    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
>    
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 0798bebd877549b60e56ab59bef5eac65c1c6ed6
>Author: Vineet Gupta <vgupta@synopsys.com>
>Date:   Tue Oct 7 14:12:13 2014 +0530
>
>    ARCv2: STAR 9000808988: signals involving Delay Slot
>    
>    [ Upstream commit 0d7b8855a05c099a5c65a8d49a1e604198021f56 ]
>    
>    Reported by Anton as LTP:munmap01 failing with Illegal Instruction
>    Exception.
>    
>       --------------------->8--------------------------------------
>       mmap2(NULL, 24576, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0x200d2000
>       munmap(0x200d2000, 24576)               = 0
>       --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x200d2000}
>       ---
>       potentially unexpected fatal signal 4.
>       Path: /munmap01
>       CPU: 0 PID: 61 Comm: munmap01 Not tainted 3.13.0-g5d5c46d9a556 #8
>       task: 9f1a8000 ti: 9f154000 task.ti: 9f154000
>    
>       [ECR   ]: 0x00020100 => Illegal Insn
>       [EFA   ]: 0x0001354c
>       [BLINK ]: 0x200515d4
>       [ERET  ]: 0x1354c
>           @off 0x1354c in [/munmap01]
>           VMA: 0x00010000 to 0x00018000
>       [STAT32]: 0x800802c0
>       ...
>       --------------------->8--------------------------------------
>    
>    The issue was
>    1. munmap01 accessed unmapped memory (on purpose) with signal handler
>       installed for SIGSEGV
>    
>    2. The faulting instruction happened to be in Delay Slot
>       00011864 <main>:
>          11908:	bl.d       13284 <tst_resm>
>          1190c:	stb        r16,[r2]
>    
>    3. kernel sets up the reg file for signal handler and correctly clears
>       the DE bit in pt_regs->status32 placeholder
>    
>    4. However RESTORE_CALLEE_SAVED_USER macro is not adjusted for ARCv2,
>       and it over-writes the above with orig/stale value of status32
>    
>    5. After RTIE, userspace signal handler executes a non branch
>       instruction with DE bit set, triggering Illegal Instruction Exception.
>    
>    Reported-by: Anton Kolesov <akolesov@synopsys.com>
>    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit bc78e69d6f6d44b4ce34371c12e2af78f63935e1
>Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>Date:   Tue Aug 16 17:38:54 2016 -0700
>
>    Input: i8042 - set up shared ps2_cmd_mutex for AUX ports
>    
>    [ Upstream commit 47af45d684b5f3ae000ad448db02ce4f13f73273 ]
>    
>    The commit 4097461897df ("Input: i8042 - break load dependency ...")
>    correctly set up ps2_cmd_mutex pointer for the KBD port but forgot to do
>    the same for AUX port(s), which results in communication on KBD and AUX
>    ports to clash with each other.
>    
>    Fixes: 4097461897df ("Input: i8042 - break load dependency ...")
>    Reported-by: Bruno Wolff III <bruno@wolff.to>
>    Tested-by: Bruno Wolff III <bruno@wolff.to>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 146ed73fcafa760048514d4ddf791cfa943c9371
>Author: Christian KÃ¶nig <christian.koenig@amd.com>
>Date:   Wed Aug 17 09:46:42 2016 +0200
>
>    drm/radeon: fix radeon_move_blit on 32bit systems
>    
>    [ Upstream commit 13f479b9df4e2bbf2d16e7e1b02f3f55f70e2455 ]
>    
>    This bug seems to be present for a very long time.
>    
>    Signed-off-by: Christian KÃ¶nig <christian.koenig@amd.com>
>    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit bb6cf2c298a52ceb881d748188cefb07c08e7839
>Author: Linus Walleij <linus.walleij@linaro.org>
>Date:   Tue Aug 16 09:58:25 2016 +0200
>
>    gpio: Fix OF build problem on UM
>    
>    [ Upstream commit 2527ecc9195e9c66252af24c4689e8a67cd4ccb9 ]
>    
>    The UserMode (UM) Linux build was failing in gpiolib-of as it requires
>    ioremap()/iounmap() to exist, which is absent from UM. The non-existence
>    of IO memory is negatively defined as CONFIG_NO_IOMEM which means we
>    need to depend on HAS_IOMEM.
>    
>    Cc: stable@vger.kernel.org
>    Cc: Geert Uytterhoeven <geert@linux-m68k.org>
>    Reported-by: kbuild test robot <fengguang.wu@intel.com>
>    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit cb515bdff8293136e97dd5370d0a094d3074ab21
>Author: Kent Overstreet <kent.overstreet@gmail.com>
>Date:   Wed Aug 17 18:21:24 2016 -0700
>
>    bcache: RESERVE_PRIO is too small by one when prio_buckets() is a power of two.
>    
>    [ Upstream commit acc9cf8c66c66b2cbbdb4a375537edee72be64df ]
>    
>    This patch fixes a cachedev registration-time allocation deadlock.
>    This can deadlock on boot if your initrd auto-registeres bcache devices:
>    
>    Allocator thread:
>    [  720.727614] INFO: task bcache_allocato:3833 blocked for more than 120 seconds.
>    [  720.732361]  [<ffffffff816eeac7>] schedule+0x37/0x90
>    [  720.732963]  [<ffffffffa05192b8>] bch_bucket_alloc+0x188/0x360 [bcache]
>    [  720.733538]  [<ffffffff810e6950>] ? prepare_to_wait_event+0xf0/0xf0
>    [  720.734137]  [<ffffffffa05302bd>] bch_prio_write+0x19d/0x340 [bcache]
>    [  720.734715]  [<ffffffffa05190bf>] bch_allocator_thread+0x3ff/0x470 [bcache]
>    [  720.735311]  [<ffffffff816ee41c>] ? __schedule+0x2dc/0x950
>    [  720.735884]  [<ffffffffa0518cc0>] ? invalidate_buckets+0x980/0x980 [bcache]
>    
>    Registration thread:
>    [  720.710403] INFO: task bash:3531 blocked for more than 120 seconds.
>    [  720.715226]  [<ffffffff816eeac7>] schedule+0x37/0x90
>    [  720.715805]  [<ffffffffa05235cd>] __bch_btree_map_nodes+0x12d/0x150 [bcache]
>    [  720.716409]  [<ffffffffa0522d30>] ? bch_btree_insert_check_key+0x1c0/0x1c0 [bcache]
>    [  720.717008]  [<ffffffffa05236e4>] bch_btree_insert+0xf4/0x170 [bcache]
>    [  720.717586]  [<ffffffff810e6950>] ? prepare_to_wait_event+0xf0/0xf0
>    [  720.718191]  [<ffffffffa0527d9a>] bch_journal_replay+0x14a/0x290 [bcache]
>    [  720.718766]  [<ffffffff810cc90d>] ? ttwu_do_activate.constprop.94+0x5d/0x70
>    [  720.719369]  [<ffffffff810cf684>] ? try_to_wake_up+0x1d4/0x350
>    [  720.719968]  [<ffffffffa05317d0>] run_cache_set+0x580/0x8e0 [bcache]
>    [  720.720553]  [<ffffffffa053302e>] register_bcache+0xe2e/0x13b0 [bcache]
>    [  720.721153]  [<ffffffff81354cef>] kobj_attr_store+0xf/0x20
>    [  720.721730]  [<ffffffff812a2dad>] sysfs_kf_write+0x3d/0x50
>    [  720.722327]  [<ffffffff812a225a>] kernfs_fop_write+0x12a/0x180
>    [  720.722904]  [<ffffffff81225177>] __vfs_write+0x37/0x110
>    [  720.723503]  [<ffffffff81228048>] ? __sb_start_write+0x58/0x110
>    [  720.724100]  [<ffffffff812cedb3>] ? security_file_permission+0x23/0xa0
>    [  720.724675]  [<ffffffff812258a9>] vfs_write+0xa9/0x1b0
>    [  720.725275]  [<ffffffff8102479c>] ? do_audit_syscall_entry+0x6c/0x70
>    [  720.725849]  [<ffffffff81226755>] SyS_write+0x55/0xd0
>    [  720.726451]  [<ffffffff8106a390>] ? do_page_fault+0x30/0x80
>    [  720.727045]  [<ffffffff816f2cae>] system_call_fastpath+0x12/0x71
>    
>    The fifo code in upstream bcache can't use the last element in the buffer,
>    which was the cause of the bug: if you asked for a power of two size,
>    it'd give you a fifo that could hold one less than what you asked for
>    rather than allocating a buffer twice as big.
>    
>    Signed-off-by: Kent Overstreet <kent.overstreet@gmail.com>
>    Tested-by: Eric Wheeler <bcache@linux.ewheeler.net>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 220360d6ac0e1ef0cf364028c26f44ac99c306c4
>Author: Eric Wheeler <git@linux.ewheeler.net>
>Date:   Fri Jun 17 15:01:54 2016 -0700
>
>    bcache: register_bcache(): call blkdev_put() when cache_alloc() fails
>    
>    [ Upstream commit d9dc1702b297ec4a6bb9c0326a70641b322ba886 ]
>    
>    register_cache() is supposed to return an error string on error so that
>    register_bcache() will will blkdev_put and cleanup other user counters,
>    but it does not set 'char *err' when cache_alloc() fails (eg, due to
>    memory pressure) and thus register_bcache() performs no cleanup.
>    
>    register_bcache() <----------\  <- no jump to err_close, no blkdev_put()
>       |                         |
>       +->register_cache()       |  <- fails to set char *err
>             |                   |
>             +->cache_alloc() ---/  <- returns error
>    
>    This patch sets `char *err` for this failure case so that register_cache()
>    will cause register_bcache() to correctly jump to err_close and do
>    cleanup.  This was tested under OOM conditions that triggered the bug.
>    
>    Signed-off-by: Eric Wheeler <bcache@linux.ewheeler.net>
>    Cc: Kent Overstreet <kent.overstreet@gmail.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 35b8f91bf61afc5764e739e718651afba580f9e8
>Author: Christian KÃ¶nig <christian.koenig@amd.com>
>Date:   Thu Aug 18 11:51:14 2016 +0200
>
>    drm/radeon: only apply the SS fractional workaround to RS[78]80
>    
>    [ Upstream commit ae5b80d2b68eac945b124227dea34462118a6f01 ]
>    
>    Looks like some RV6xx have problems with that.
>    
>    bug:
>    https://bugs.freedesktop.org/show_bug.cgi?id=97099
>    
>    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>    Signed-off-by: Christian KÃ¶nig <christian.koenig@amd.com>
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 388bf264aef5c67b89edf78d51cb3b6637aab00f
>Author: Christian KÃ¶nig <christian.koenig@amd.com>
>Date:   Mon Jun 13 16:09:53 2016 +0200
>
>    drm/radeon: don't use fractional dividers on RS[78]80 if SS is enabled
>    
>    [ Upstream commit 9ef8537e68941d858924a3eacee5a1945767cbab ]
>    
>    Seems to cause problems for some older hardware. Kudos to Thom Kouwenhoven
>    for working a lot with the PLLs and figuring this out.
>    
>    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>    Signed-off-by: Christian KÃ¶nig <christian.koenig@amd.com>
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 31df33850d7a16bf7c67220d912638a066a701bf
>Author: Oleg Nesterov <oleg@redhat.com>
>Date:   Wed Aug 17 17:36:29 2016 +0200
>
>    uprobes: Fix the memcg accounting
>    
>    [ Upstream commit 6c4687cc17a788a6dd8de3e27dbeabb7cbd3e066 ]
>    
>    __replace_page() wronlgy calls mem_cgroup_cancel_charge() in "success" path,
>    it should only do this if page_check_address() fails.
>    
>    This means that every enable/disable leads to unbalanced mem_cgroup_uncharge()
>    from put_page(old_page), it is trivial to underflow the page_counter->count
>    and trigger OOM.
>    
>    Reported-and-tested-by: Brenden Blanco <bblanco@plumgrid.com>
>    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
>    Reviewed-by: Johannes Weiner <hannes@cmpxchg.org>
>    Acked-by: Michal Hocko <mhocko@kernel.org>
>    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
>    Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>
>    Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
>    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
>    Cc: Jiri Olsa <jolsa@redhat.com>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Cc: Vladimir Davydov <vdavydov@virtuozzo.com>
>    Cc: stable@vger.kernel.org # 3.17+
>    Fixes: 00501b531c47 ("mm: memcontrol: rewrite charge API")
>    Link: http://lkml.kernel.org/r/20160817153629.GB29724@redhat.com
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 26390c7073a70d57c5c0de7c44f909fc91f3c66b
>Author: Bart Van Assche <bart.vanassche@sandisk.com>
>Date:   Tue Aug 16 16:48:36 2016 -0700
>
>    block: Fix race triggered by blk_set_queue_dying()
>    
>    [ Upstream commit 1b856086813be9371929b6cc62045f9fd470f5a0 ]
>    
>    blk_set_queue_dying() can be called while another thread is
>    submitting I/O or changing queue flags, e.g. through dm_stop_queue().
>    Hence protect the QUEUE_FLAG_DYING flag change with locking.
>    
>    Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
>    Cc: Christoph Hellwig <hch@lst.de>
>    Cc: Mike Snitzer <snitzer@redhat.com>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Jens Axboe <axboe@fb.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 0df5268514aafd144b5b0402d03a21951961fa9f
>Author: Christoph Huber <c.huber@bct-electronic.com>
>Date:   Mon Aug 15 18:59:25 2016 +0200
>
>    ASoC: atmel_ssc_dai: Don't unconditionally reset SSC on stream startup
>    
>    [ Upstream commit 3e103a65514c2947e53f3171b21255fbde8b60c6 ]
>    
>    commit cbaadf0f90d6 ("ASoC: atmel_ssc_dai: refactor the startup and
>    shutdown") refactored code such that the SSC is reset on every
>    startup; this breaks duplex audio (e.g. first start audio playback,
>    then start record, causing the playback to stop/hang)
>    
>    Fixes: cbaadf0f90d6 (ASoC: atmel_ssc_dai: refactor the startup and shutdown)
>    Signed-off-by: Christoph Huber <c.huber@bct-electronic.com>
>    Signed-off-by: Peter Meerwald-Stadler <p.meerwald@bct-electronic.com>
>    Signed-off-by: Mark Brown <broonie@kernel.org>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 7ae87eebbcf7bb96467ea4f3c6563e32e1f600bc
>Author: Sasha Levin <alexander.levin@verizon.com>
>Date:   Tue Aug 30 22:04:29 2016 -0400
>
>    ARC: Elide redundant setup of DMA callbacks
>    
>    [ Upstream commit 45c3b08a117e2232fc8d7b9e849ead36386f4f96 ]
>    
>    For resources shared by all cores such as SLC and IOC, only the master
>    core needs to do any setups / enabling / disabling etc.
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 0e16c544ede2bc7954de7583cb2ff1594fb5db97
>Author: Sasha Levin <alexander.levin@verizon.com>
>Date:   Tue Aug 30 21:59:56 2016 -0400
>
>    ARC: Call trace_hardirqs_on() before enabling irqs
>    
>    [ Upstream commit 18b43e89d295cc65151c505c643c98fb2c320e59 ]
>    
>    trace_hardirqs_on_caller() in lockdep.c expects to be called before, not
>    after interrupts are actually enabled.
>    
>    The following comment in kernel/locking/lockdep.c substantiates this
>    claim:
>    
>    "
>    /*
>     * We're enabling irqs and according to our state above irqs weren't
>     * already enabled, yet we find the hardware thinks they are in fact
>     * enabled.. someone messed up their IRQ state tracing.
>     */
>    "
>    
>    An example can be found in include/linux/irqflags.h:
>    
>    	do { trace_hardirqs_on(); raw_local_irq_enable(); } while (0)
>    
>    Without this change, we hit the following DEBUG_LOCKS_WARN_ON.
>    
>    [    7.760000] ------------[ cut here ]------------
>    [    7.760000] WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2711 resume_user_mode_begin+0x48/0xf0
>    [    7.770000] DEBUG_LOCKS_WARN_ON(!irqs_disabled())
>    [    7.780000] Modules linked in:
>    [    7.780000] CPU: 0 PID: 1 Comm: init Not tainted 4.7.0-00003-gc668bb9-dirty #366
>    [    7.790000]
>    [    7.790000] Stack Trace:
>    [    7.790000]   arc_unwind_core.constprop.1+0xa4/0x118
>    [    7.800000]   warn_slowpath_fmt+0x72/0x158
>    [    7.800000]   resume_user_mode_begin+0x48/0xf0
>    [    7.810000] ---[ end trace 6f6a7a8fae20d2f0 ]---
>    
>    Signed-off-by: Daniel Mentz <danielmentz@google.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit e1052fbcb3d341d8088b8ffec73f3e5dbb37fe6d
>Author: Jim Lin <jilin@nvidia.com>
>Date:   Tue Aug 16 10:18:05 2016 +0300
>
>    usb: xhci: Fix panic if disconnect
>    
>    [ Upstream commit 88716a93766b8f095cdef37a8e8f2c93aa233b21 ]
>    
>    After a device is disconnected, xhci_stop_device() will be invoked
>    in xhci_bus_suspend().
>    Also the "disconnect" IRQ will have ISR to invoke
>    xhci_free_virt_device() in this sequence.
>    xhci_irq -> xhci_handle_event -> handle_cmd_completion ->
>    xhci_handle_cmd_disable_slot -> xhci_free_virt_device
>    
>    If xhci->devs[slot_id] has been assigned to NULL in
>    xhci_free_virt_device(), then virt_dev->eps[i].ring in
>    xhci_stop_device() may point to an invlid address to cause kernel
>    panic.
>    
>    virt_dev = xhci->devs[slot_id];
>    :
>    if (virt_dev->eps[i].ring && virt_dev->eps[i].ring->dequeue)
>    
>    [] Unable to handle kernel paging request at virtual address 00001a68
>    [] pgd=ffffffc001430000
>    [] [00001a68] *pgd=000000013c807003, *pud=000000013c807003,
>    *pmd=000000013c808003, *pte=0000000000000000
>    [] Internal error: Oops: 96000006 [#1] PREEMPT SMP
>    [] CPU: 0 PID: 39 Comm: kworker/0:1 Tainted: G     U
>    [] Workqueue: pm pm_runtime_work
>    [] task: ffffffc0bc0e0bc0 ti: ffffffc0bc0ec000 task.ti:
>    ffffffc0bc0ec000
>    [] PC is at xhci_stop_device.constprop.11+0xb4/0x1a4
>    
>    This issue is found when running with realtek ethernet device
>    (0bda:8153).
>    
>    Signed-off-by: Jim Lin <jilin@nvidia.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 23c50b25b252a8273baddf958f3468ec39b55e0f
>Author: Mathias Nyman <mathias.nyman@linux.intel.com>
>Date:   Tue Aug 16 10:18:03 2016 +0300
>
>    xhci: always handle "Command Ring Stopped" events
>    
>    [ Upstream commit 33be126510974e2eb9679f1ca9bca4f67ee4c4c7 ]
>    
>    Fix "Command completion event does not match command" errors by always
>    handling the command ring stopped events.
>    
>    The command ring stopped event is generated as a result of aborting
>    or stopping the command ring with a register write. It is not caused
>    by a command in the command queue, and thus won't have a matching command
>    in the comman list.
>    
>    Solve it by handling the command ring stopped event before checking for a
>    matching command.
>    
>    In most command time out cases we abort the command ring, and get
>    a command ring stopped event. The events command pointer will point at
>    the current command ring dequeue, which in most cases matches the timed
>    out command in the command list, and no error messages are seen.
>    
>    If we instead get a command aborted event before the command ring stopped
>    event, the abort event will increse the command ring dequeue pointer, and
>    the following command ring stopped events command pointer will point at the
>    next, not yet queued command. This case triggered the error message
>    
>    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
>    CC: <stable@vger.kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 9fd7c335115eb2a18b684bdc5c68627be60d4fdf
>Author: Gavin Li <git@thegavinli.com>
>Date:   Fri Aug 12 00:52:56 2016 -0700
>
>    cdc-acm: fix wrong pipe type on rx interrupt xfers
>    
>    [ Upstream commit add125054b8727103631dce116361668436ef6a7 ]
>    
>    This fixes the "BOGUS urb xfer" warning logged by usb_submit_urb().
>    
>    Signed-off-by: Gavin Li <git@thegavinli.com>
>    Acked-by: Oliver Neukum <oneukum@suse.com>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 1a8eadfa9c79c3d1b780e8081cc1e5e242f1632d
>Author: Lu Baolu <baolu.lu@linux.intel.com>
>Date:   Thu Aug 11 10:31:14 2016 +0800
>
>    usb: misc: usbtest: add fix for driver hang
>    
>    [ Upstream commit 539587511835ea12d8daa444cbed766cf2bc3612 ]
>    
>    In sg_timeout(), req->status is set to "-ETIMEDOUT" before calling
>    into usb_sg_cancel(). usb_sg_cancel() will do nothing and return
>    directly if req->status has been set to a non-zero value. This will
>    cause driver hang whenever transfer time out is triggered.
>    
>    This patch fixes this issue. It could be backported to stable kernel
>    with version later than v3.15.
>    
>    Cc: stable@vger.kernel.org # 3.15+
>    Cc: Alan Stern <stern@rowland.harvard.edu>
>    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
>    Suggested-by: Alan Stern <stern@rowland.harvard.edu>
>    Acked-by: Alan Stern <stern@rowland.harvard.edu>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 79e3a23fe5a319e5799f12585f6a74d1214c66c7
>Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>Date:   Mon Aug 8 21:50:53 2016 +0900
>
>    usb: renesas_usbhs: Use dmac only if the pipe type is bulk
>    
>    [ Upstream commit 700aa7ff8d2c2b9cc669c99375e2ccd06d3cd38d ]
>    
>    This patch fixes an issue that isochronous transfer's data is possible to
>    be lost as a workaround. Since this driver uses a workqueue to start
>    the dmac, the transfer is possible to be delayed when system load is high.
>    
>    Fixes: 6e4b74e4690d ("usb: renesas: fix scheduling in atomic context bug")
>    Cc: <stable@vger.kernel.org> # v3.4+
>    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 80a979e8212300af4464fa0872a025ac303a50d5
>Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>Date:   Mon Aug 8 21:50:52 2016 +0900
>
>    usb: renesas_usbhs: clear the BRDYSTS in usbhsg_ep_enable()
>    
>    [ Upstream commit 9ab967e6db7412b675ecbff80d5371d53c82cb2e ]
>    
>    This patch fixes an issue that unexpected BRDY interruption happens
>    when the usb_ep_{enable,disable}() are called with different direction.
>    In this case, the driver will cause the following message:
>    
>     renesas_usbhs e6590000.usb: irq_ready run_error 1 : -16
>    
>    This issue causes the followings:
>     1) A pipe is enabled as transmission
>     2) The pipe sent a data
>     3) The pipe is disabled and re-enabled as reception.
>     4) The pipe got a queue
>    
>    Since the driver doesn't clear the BRDYSTS flags after 2) above, the issue
>    happens. If we add such clearing the flags into the driver, the code will
>    become complicate. So, this patch clears the BRDYSTS flag of reception in
>    usbhsg_ep_enable() to avoid complicate.
>    
>    Cc: <stable@vger.kernel.org> # v4.1+ (usbhs_xxxsts_clear() is needed)
>    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 03b78ea5910da53e589db6b0f58e711b92dd0d90
>Author: Matthew Auld <matthew.auld@intel.com>
>Date:   Fri Aug 5 19:04:40 2016 +0100
>
>    drm/i915: fix aliasing_ppgtt leak
>    
>    [ Upstream commit 3871f42a57efcdc6a9da751a8cb6fa196c212289 ]
>    
>    In i915_ggtt_cleanup_hw we need to remember to free aliasing_ppgtt. This
>    fixes the following kmemleak message:
>    
>    unreferenced object 0xffff880213cca000 (size 8192):
>      comm "modprobe", pid 1298, jiffies 4294745402 (age 703.930s)
>      hex dump (first 32 bytes):
>        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>      backtrace:
>        [<ffffffff817c808e>] kmemleak_alloc+0x4e/0xb0
>        [<ffffffff8121f9c2>] kmem_cache_alloc_trace+0x142/0x1d0
>        [<ffffffffa06d11ef>] i915_gem_init_ggtt+0x10f/0x210 [i915]
>        [<ffffffffa06d71bb>] i915_gem_init+0x5b/0xd0 [i915]
>        [<ffffffffa069749a>] i915_driver_load+0x97a/0x1460 [i915]
>        [<ffffffffa06a26ef>] i915_pci_probe+0x4f/0x70 [i915]
>        [<ffffffff81423015>] local_pci_probe+0x45/0xa0
>        [<ffffffff81424463>] pci_device_probe+0x103/0x150
>        [<ffffffff81515e6c>] driver_probe_device+0x22c/0x440
>        [<ffffffff81516151>] __driver_attach+0xd1/0xf0
>        [<ffffffff8151379c>] bus_for_each_dev+0x6c/0xc0
>        [<ffffffff8151555e>] driver_attach+0x1e/0x20
>        [<ffffffff81514fa3>] bus_add_driver+0x1c3/0x280
>        [<ffffffff81516aa0>] driver_register+0x60/0xe0
>        [<ffffffff8142297c>] __pci_register_driver+0x4c/0x50
>        [<ffffffffa013605b>] 0xffffffffa013605b
>    
>    Signed-off-by: Matthew Auld <matthew.auld@intel.com>
>    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
>    Fixes: b18b6bde300e ("drm/i915/bdw: Free PPGTT struct")
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>    Link: http://patchwork.freedesktop.org/patch/msgid/1470420280-21417-1-git-send-email-matthew.auld@intel.com
>    (cherry picked from commit cb7f27601c81a1e0454e9461e96f65b31fafbea0)
>    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 46c9df4a3d9534fd230b7b85b3b0042080283ff7
>Author: Agrawal, Nitesh-kumar <Nitesh-kumar.Agrawal@amd.com>
>Date:   Tue Jul 26 08:28:19 2016 +0000
>
>    pinctrl/amd: Remove the default de-bounce time
>    
>    [ Upstream commit 8cf4345575a416e6856a6856ac6eaa31ad883126 ]
>    
>    In the function amd_gpio_irq_enable() and
>    amd_gpio_direction_input(), remove the code which is setting
>    the default de-bounce time to 2.75ms.
>    
>    The driver code shall use the same settings as specified in
>    BIOS. Any default assignment impacts TouchPad behaviour when
>    the LevelTrig is set to EDGE FALLING.
>    
>    Cc: stable@vger.kernel.org
>    Reviewed-by:Â  Ken Xue <Ken.Xue@amd.com>
>    Signed-off-by: Nitesh Kumar Agrawal <Nitesh-kumar.Agrawal@amd.com>
>    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit f079b0e5a9bba59b1befd390b81a1819dd41e19d
>Author: Heikki Krogerus <heikki.krogerus@linux.intel.com>
>Date:   Fri Apr 1 17:13:11 2016 +0300
>
>    usb: dwc3: pci: add Intel Kabylake PCI ID
>    
>    [ Upstream commit 4491ed5042f0419b22a4b08331adb54af31e2caa ]
>    
>    Intel Kabylake PCH has the same DWC3 than Intel
>    Sunrisepoint. Add the new ID to the supported devices.
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
>    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit f034f1c6e8075ca3e294babd578ada5daef9d4c1
>Author: Heikki Krogerus <heikki.krogerus@linux.intel.com>
>Date:   Wed Oct 21 14:37:04 2015 +0300
>
>    usb: dwc3: pci: add support for Intel Broxton SOC
>    
>    [ Upstream commit b4c580a43d520b7812c0fd064fbab929ce2f1da0 ]
>    
>    PCI IDs for Broxton based platforms.
>    
>    Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
>    Signed-off-by: Felipe Balbi <balbi@ti.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 888ea95a19eb3abde8373f68cd6fd8e65785570c
>Author: John Youn <John.Youn@synopsys.com>
>Date:   Fri Sep 25 23:47:53 2015 -0700
>
>    usb: dwc3: pci: trivial: Formatting
>    
>    [ Upstream commit 9a5a0783e4910d9e2063e87184fbd9cac7161a16 ]
>    
>    Fix the alignment of the PCI device definitions. Also change the hex
>    digit capitalization of one constant to make it consistent with the
>    rest of the file and driver.
>    
>    Signed-off-by: John Youn <johnyoun@synopsys.com>
>    Signed-off-by: Felipe Balbi <balbi@ti.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit b42468438321297c27cca67a20d09b22d0bc486f
>Author: Felipe Balbi <felipe.balbi@linux.intel.com>
>Date:   Wed Aug 10 12:35:30 2016 +0300
>
>    usb: dwc3: gadget: always cleanup all TRBs
>    
>    [ Upstream commit 7c705dfe2ebe731c8fd068623b6b4df2d3512c08 ]
>    
>    If we stop earlier due to short packet, we will
>    not be able to giveback all TRBs.
>    
>    Cc: <stable@vger.kernel.org>
>    Cc: Brian E Rogers <brian.e.rogers@intel.com>
>    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit a694f3fa30adc8be36d7e2f8e4911a3fe705adf2
>Author: Felipe Balbi <felipe.balbi@linux.intel.com>
>Date:   Wed Aug 10 11:13:26 2016 +0300
>
>    usb: dwc3: gadget: fix for short pkts during chained xfers
>    
>    [ Upstream commit e5b36ae2f851024d43c76e51f395d32ce8d769ce ]
>    
>    DWC3 has one interesting peculiarity with chained
>    transfers. If we setup N chained transfers and we
>    get a short packet before processing all N TRBs,
>    DWC3 will (conditionally) issue a XferComplete or
>    XferInProgress event and retire all TRBs from the
>    one which got a short packet to the last without
>    clearing their HWO bits.
>    
>    This means SW must clear HWO bit manually, which
>    this patch is doing.
>    
>    Cc: <stable@vger.kernel.org>
>    Cc: Brian E Rogers <brian.e.rogers@intel.com>
>    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 60b8bcfd6a911071c8eb7de6bb9c1afc964385f1
>Author: Felipe Balbi <felipe.balbi@linux.intel.com>
>Date:   Fri Jul 29 03:17:58 2016 +0300
>
>    usb: dwc3: gadget: increment request->actual once
>    
>    [ Upstream commit c7de573471832dff7d31f0c13b0f143d6f017799 ]
>    
>    When using SG lists, we would end up setting
>    request->actual to:
>    
>    	num_mapped_sgs * (request->length - count)
>    
>    Let's fix that up by incrementing request->actual
>    only once.
>    
>    Cc: <stable@vger.kernel.org>
>    Reported-by: Brian E Rogers <brian.e.rogers@intel.com>
>    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit d3c1edbd4f11a838785af3c48a1885f6b94935ad
>Author: Stefan Haberland <sth@linux.vnet.ibm.com>
>Date:   Mon Aug 8 14:08:17 2016 +0200
>
>    s390/dasd: fix hanging device after clear subchannel
>    
>    [ Upstream commit 9ba333dc55cbb9523553df973adb3024d223e905 ]
>    
>    When a device is in a status where CIO has killed all I/O by itself the
>    interrupt for a clear request may not contain an irb to determine the
>    clear function. Instead it contains an error pointer -EIO.
>    This was ignored by the DASD int_handler leading to a hanging device
>    waiting for a clear interrupt.
>    
>    Handle -EIO error pointer correctly for requests that are clear pending and
>    treat the clear as successful.
>    
>    Signed-off-by: Stefan Haberland <sth@linux.vnet.ibm.com>
>    Reviewed-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 5bd6b61399ab2a4c024389fd64c02b099c8fff95
>Author: Marc Ohlf <ohlf@mkt-sys.de>
>Date:   Wed Aug 3 11:51:54 2016 +0200
>
>    usb: ehci: change order of register cleanup during shutdown
>    
>    [ Upstream commit bc337b51508beb2d039aff5074a76cfe1c212030 ]
>    
>    In ehci_turn_off_all_ports() all EHCI port registers are cleared to zero.
>    On some hardware, this can lead to an system hang,
>    when ehci_port_power() accesses the already cleared registers.
>    
>    This patch changes the order of cleanup.
>    First call ehci_port_power() which respects the current bits in
>    port status registers
>    and afterwards cleanup the hard way by setting everything to zero.
>    
>    Signed-off-by: Marc Ohlf <ohlf@mkt-sys.de>
>    Acked-by: Alan Stern <stern@rowland.harvard.edu>
>    CC: <stable@vger.kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit fdcdf5bac083b93871d4762feeae99caf85bf325
>Author: Viresh Kumar <viresh.kumar@linaro.org>
>Date:   Thu Aug 4 13:32:22 2016 -0700
>
>    usb: hub: Fix unbalanced reference count/memory leak/deadlocks
>    
>    [ Upstream commit 6bb47e8ab98accb1319bd43c64966340ba3bba9a ]
>    
>    Memory leak and unbalanced reference count:
>    
>    If the hub gets disconnected while the core is still activating it, this
>    can result in leaking memory of few USB structures.
>    
>    This will happen if we have done a kref_get() from hub_activate() and
>    scheduled a delayed work item for HUB_INIT2/3. Now if hub_disconnect()
>    gets called before the delayed work expires, then we will cancel the
>    work from hub_quiesce(), but wouldn't do a kref_put(). And so the
>    unbalance.
>    
>    kmemleak reports this as (with the commit e50293ef9775 backported to
>    3.10 kernel with other changes, though the same is true for mainline as
>    well):
>    
>    unreferenced object 0xffffffc08af5b800 (size 1024):
>      comm "khubd", pid 73, jiffies 4295051211 (age 6482.350s)
>      hex dump (first 32 bytes):
>        30 68 f3 8c c0 ff ff ff 00 a0 b2 2e c0 ff ff ff  0h..............
>        01 00 00 00 00 00 00 00 00 94 7d 40 c0 ff ff ff  ..........}@....
>      backtrace:
>        [<ffffffc0003079ec>] create_object+0x148/0x2a0
>        [<ffffffc000cc150c>] kmemleak_alloc+0x80/0xbc
>        [<ffffffc000303a7c>] kmem_cache_alloc_trace+0x120/0x1ac
>        [<ffffffc0006fa610>] hub_probe+0x120/0xb84
>        [<ffffffc000702b20>] usb_probe_interface+0x1ec/0x298
>        [<ffffffc0005d50cc>] driver_probe_device+0x160/0x374
>        [<ffffffc0005d5308>] __device_attach+0x28/0x4c
>        [<ffffffc0005d3164>] bus_for_each_drv+0x78/0xac
>        [<ffffffc0005d4ee0>] device_attach+0x6c/0x9c
>        [<ffffffc0005d42b8>] bus_probe_device+0x28/0xa0
>        [<ffffffc0005d23a4>] device_add+0x324/0x604
>        [<ffffffc000700fcc>] usb_set_configuration+0x660/0x6cc
>        [<ffffffc00070a350>] generic_probe+0x44/0x84
>        [<ffffffc000702914>] usb_probe_device+0x54/0x74
>        [<ffffffc0005d50cc>] driver_probe_device+0x160/0x374
>        [<ffffffc0005d5308>] __device_attach+0x28/0x4c
>    
>    Deadlocks:
>    
>    If the hub gets disconnected early enough (i.e. before INIT2/INIT3 are
>    finished and the init_work is still queued), the core may call
>    hub_quiesce() after acquiring interface device locks and it will wait
>    for the work to be cancelled synchronously. But if the work handler is
>    already running in parallel, it may try to acquire the same interface
>    device lock and this may result in deadlock.
>    
>    Fix both the issues by removing the call to cancel_delayed_work_sync().
>    
>    CC: <stable@vger.kernel.org> #4.4+
>    Fixes: e50293ef9775 ("USB: fix invalid memory access in hub_activate()")
>    Reported-by: Manu Gautam <mgautam@codeaurora.org>
>    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
>    Acked-by: Alan Stern <stern@rowland.harvard.edu>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit aca78034833166c848505b391b258ecbb96c895b
>Author: Russell King <rmk+kernel@armlinux.org.uk>
>Date:   Tue Aug 9 08:27:17 2016 +0100
>
>    crypto: caam - fix non-hmac hashes
>    
>    [ Upstream commit a0118c8b2be9297aed8e915c60b4013326b256d4 ]
>    
>    Since 6de62f15b581 ("crypto: algif_hash - Require setkey before
>    accept(2)"), the AF_ALG interface requires userspace to provide a key
>    to any algorithm that has a setkey method.  However, the non-HMAC
>    algorithms are not keyed, so setting a key is unnecessary.
>    
>    Fix this by removing the setkey method from the non-keyed hash
>    algorithms.
>    
>    Fixes: 6de62f15b581 ("crypto: algif_hash - Require setkey before accept(2)")
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit e989e0c9bba5c1f8987629e2880a512d7b15e852
>Author: Dave Carroll <david.carroll@microsemi.com>
>Date:   Fri Aug 5 13:44:10 2016 -0600
>
>    aacraid: Check size values after double-fetch from user
>    
>    [ Upstream commit fa00c437eef8dc2e7b25f8cd868cfa405fcc2bb3 ]
>    
>    In aacraid's ioctl_send_fib() we do two fetches from userspace, one the
>    get the fib header's size and one for the fib itself. Later we use the
>    size field from the second fetch to further process the fib. If for some
>    reason the size from the second fetch is different than from the first
>    fix, we may encounter an out-of- bounds access in aac_fib_send(). We
>    also check the sender size to insure it is not out of bounds. This was
>    reported in https://bugzilla.kernel.org/show_bug.cgi?id=116751 and was
>    assigned CVE-2016-6480.
>    
>    Reported-by: Pengfei Wang <wpengfeinudt@gmail.com>
>    Fixes: 7c00ffa31 '[SCSI] 2.6 aacraid: Variable FIB size (updated patch)'
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Dave Carroll <david.carroll@microsemi.com>
>    Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
>    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 6a19c730de76c8b870a72035416a45ea47cb8e75
>Author: Alexey Klimov <klimov.linux@gmail.com>
>Date:   Mon Aug 8 02:34:46 2016 +0100
>
>    USB: serial: fix memleak in driver-registration error path
>    
>    [ Upstream commit 647024a7df36014bbc4479d92d88e6b77c0afcf6 ]
>    
>    udriver struct allocated by kzalloc() will not be freed
>    if usb_register() and next calls fail. This patch fixes this
>    by adding one more step with kfree(udriver) in error path.
>    
>    Signed-off-by: Alexey Klimov <klimov.linux@gmail.com>
>    Acked-by: Alan Stern <stern@rowland.harvard.edu>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 61882ca3c2050d4821738454cb4966dcf8097fc5
>Author: Daniele Palmas <dnlplm@gmail.com>
>Date:   Tue Aug 2 11:29:25 2016 +0200
>
>    USB: serial: option: add support for Telit LE920A4
>    
>    [ Upstream commit 01d7956b58e644ea0d2e8d9340c5727a8fc39d70 ]
>    
>    This patch adds a set of compositions for Telit LE920A4.
>    
>    Compositions in short are:
>    
>    0x1207: tty + tty
>    0x1208: tty + adb + tty + tty
>    0x1211: tty + adb + ecm
>    0x1212: tty + adb
>    0x1213: ecm + tty
>    0x1214: tty + adb + ecm + tty
>    
>    telit_le922_blacklist_usbcfg3 is reused for compositions 0x1211
>    and 0x1214 due to the same interfaces positions.
>    
>    Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 2980f143e9f9caaf53808f2106fbafc6151646ec
>Author: Sheng-Hui J. Chu <s.jeffrey.chu@gmail.com>
>Date:   Thu Jul 28 17:01:45 2016 -0400
>
>    USB: serial: ftdi_sio: add device ID for WICED USB UART dev board
>    
>    [ Upstream commit ae34d12cc1e212ffcd92e069030e54dae69c832f ]
>    
>    BCM20706V2_EVAL is a WICED dev board designed with FT2232H USB 2.0
>    UART/FIFO IC.
>    
>    To support BCM920706V2_EVAL dev board for WICED development on Linux.
>    Add the VID(0a5c) and PID(6422) to ftdi_sio driver to allow loading
>    ftdi_sio for this board.
>    
>    Signed-off-by: Sheng-Hui J. Chu <s.jeffrey.chu@gmail.com>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 65b2f0af0dfc3be7ac1f1302db7bf64184b3a821
>Author: Robert DeliÃ«n <robert@delien.nl>
>Date:   Thu Jul 28 18:52:55 2016 +0000
>
>    USB: serial: ftdi_sio: add PIDs for Ivium Technologies devices
>    
>    [ Upstream commit 6977495c06f7f47636a076ee5a0ca571279d9697 ]
>    
>    Ivium Technologies uses the FTDI VID with custom PIDs for their line of
>    electrochemical interfaces and the PalmSens they developed for PalmSens
>    BV.
>    
>    Signed-off-by: Robert Delien <robert@delien.nl>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit cbae57635b20802b211e281a7dc7fcf56316e36e
>Author: Lubomir Rintel <lkundrak@v3.sk>
>Date:   Sun Jul 24 13:53:30 2016 +0200
>
>    USB: serial: option: add D-Link DWM-156/A3
>    
>    [ Upstream commit cf1b18030de29e4e5b0a57695ae5db4a89da0ff7 ]
>    
>    The device has four interfaces; the three serial ports ought to be
>    handled by this driver:
>    
>    00 Diagnostic interface serial port
>    01 NMEA device serial port
>    02 Mass storage (sd card)
>    03 Modem serial port
>    
>    The other product ids listed in the Windows driver are present already.
>    
>    Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 4bb0ddaf9330fd4c1359cd98cb9aa2f3131d769c
>Author: Felix Fietkau <nbd@nbd.name>
>Date:   Tue Aug 2 11:13:41 2016 +0200
>
>    mac80211: fix purging multicast PS buffer queue
>    
>    [ Upstream commit 6b07d9ca9b5363dda959b9582a3fc9c0b89ef3b5 ]
>    
>    The code currently assumes that buffered multicast PS frames don't have
>    a pending ACK frame for tx status reporting.
>    However, hostapd sends a broadcast deauth frame on teardown for which tx
>    status is requested. This can lead to the "Have pending ack frames"
>    warning on module reload.
>    Fix this by using ieee80211_free_txskb/ieee80211_purge_tx_queue.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Felix Fietkau <nbd@nbd.name>
>    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 2dd916fce77144aaa8fb554a2b41be73635ee650
>Author: Jason Baron <jbaron@akamai.com>
>Date:   Thu Jul 14 11:38:40 2016 -0400
>
>    tcp: enable per-socket rate limiting of all 'challenge acks'
>    
>    [ Upstream commit 083ae308280d13d187512b9babe3454342a7987e ]
>    
>    The per-socket rate limit for 'challenge acks' was introduced in the
>    context of limiting ack loops:
>    
>    commit f2b2c582e824 ("tcp: mitigate ACK loops for connections as tcp_sock")
>    
>    And I think it can be extended to rate limit all 'challenge acks' on a
>    per-socket basis.
>    
>    Since we have the global tcp_challenge_ack_limit, this patch allows for
>    tcp_challenge_ack_limit to be set to a large value and effectively rely on
>    the per-socket limit, or set tcp_challenge_ack_limit to a lower value and
>    still prevents a single connections from consuming the entire challenge ack
>    quota.
>    
>    It further moves in the direction of eliminating the global limit at some
>    point, as Eric Dumazet has suggested. This a follow-up to:
>    Subject: tcp: make challenge acks less predictable
>    
>    Cc: Eric Dumazet <edumazet@google.com>
>    Cc: David S. Miller <davem@davemloft.net>
>    Cc: Neal Cardwell <ncardwell@google.com>
>    Cc: Yuchung Cheng <ycheng@google.com>
>    Cc: Yue Cao <ycao009@ucr.edu>
>    Signed-off-by: Jason Baron <jbaron@akamai.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 2b211174edd454376ab9bc85f7bae8e01016d87c
>Author: Eric Dumazet <edumazet@google.com>
>Date:   Sun Jul 10 10:04:02 2016 +0200
>
>    tcp: make challenge acks less predictable
>    
>    [ Upstream commit 75ff39ccc1bd5d3c455b6822ab09e533c551f758 ]
>    
>    Yue Cao claims that current host rate limiting of challenge ACKS
>    (RFC 5961) could leak enough information to allow a patient attacker
>    to hijack TCP sessions. He will soon provide details in an academic
>    paper.
>    
>    This patch increases the default limit from 100 to 1000, and adds
>    some randomization so that the attacker can no longer hijack
>    sessions without spending a considerable amount of probes.
>    
>    Based on initial analysis and patch from Linus.
>    
>    Note that we also have per socket rate limiting, so it is tempting
>    to remove the host limit in the future.
>    
>    v2: randomize the count of challenge acks per second, not the period.
>    
>    Fixes: 282f23c6ee34 ("tcp: implement RFC 5961 3.2")
>    Reported-by: Yue Cao <ycao009@ucr.edu>
>    Signed-off-by: Eric Dumazet <edumazet@google.com>
>    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Yuchung Cheng <ycheng@google.com>
>    Cc: Neal Cardwell <ncardwell@google.com>
>    Acked-by: Neal Cardwell <ncardwell@google.com>
>    Acked-by: Yuchung Cheng <ycheng@google.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit beebc82b1cf1710ffebebdff4e09b3455085fa94
>Author: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
>Date:   Fri Oct 23 17:19:46 2015 +1100
>
>    powerpc/eeh: eeh_pci_enable(): fix checking of post-request state
>    
>    [ Upstream commit 949e9b827eb4736d96df520c67d07a54c64e99b8 ]
>    
>    In eeh_pci_enable(), after making the request to set the new options, we
>    call eeh_ops->wait_state() to check that the request finished successfully.
>    
>    At the moment, if eeh_ops->wait_state() returns 0, we return 0 without
>    checking that it reflects the expected outcome. This can lead to callers
>    further up the chain incorrectly assuming the slot has been successfully
>    unfrozen and continuing to attempt recovery.
>    
>    On powernv, this will occur if pnv_eeh_get_pe_state() or
>    pnv_eeh_get_phb_state() return 0, which in turn occurs if the relevant OPAL
>    call returns OPAL_EEH_STOPPED_MMIO_DMA_FREEZE or
>    OPAL_EEH_PHB_ERROR respectively.
>    
>    On pseries, this will occur if pseries_eeh_get_state() returns 0, which in
>    turn occurs if RTAS reports that the PE is in the MMIO Stopped and DMA
>    Stopped states.
>    
>    Obviously, none of these cases represent a successful completion of a
>    request to thaw MMIO or DMA.
>    
>    Fix the check so that a wait_state() return value of 0 won't be considered
>    successful for the EEH_OPT_THAW_MMIO or EEH_OPT_THAW_DMA cases.
>    
>    Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
>    Acked-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
>    Reviewed-by: Daniel Axtens <dja@axtens.net>
>    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 99f614a3bb23603a947be2e95b78507112c484e5
>Author: Sasha Levin <alexander.levin@verizon.com>
>Date:   Mon Aug 22 09:50:48 2016 -0400
>
>    Linux 4.1.31
>    
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 432273c710ae564a9530f44c0deb92b9e7a463d8
>Author: James Hogan <james.hogan@imgtec.com>
>Date:   Thu Aug 18 10:01:29 2016 +0100
>
>    MIPS: KVM: Propagate kseg0/mapped tlb fault errors
>    
>    commit 9b731bcfdec4c159ad2e4312e25d69221709b96a upstream.
>    
>    Propagate errors from kvm_mips_handle_kseg0_tlb_fault() and
>    kvm_mips_handle_mapped_seg_tlb_fault(), usually triggering an internal
>    error since they normally indicate the guest accessed bad physical
>    memory or the commpage in an unexpected way.
>    
>    Fixes: 858dd5d45733 ("KVM/MIPS32: MMU/TLB operations for the Guest.")
>    Fixes: e685c689f3a8 ("KVM/MIPS32: Privileged instruction/target branch emulation.")
>    Signed-off-by: James Hogan <james.hogan@imgtec.com>
>    Cc: Paolo Bonzini <pbonzini@redhat.com>
>    Cc: "Radim KrÄmÃ¡Å" <rkrcmar@redhat.com>
>    Cc: Ralf Baechle <ralf@linux-mips.org>
>    Cc: linux-mips@linux-mips.org
>    Cc: kvm@vger.kernel.org
>    Signed-off-by: Radim KrÄmÃ¡Å <rkrcmar@redhat.com>
>    [james.hogan@imgtec.com: Backport to v4.7]
>    Signed-off-by: James Hogan <james.hogan@imgtec.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 7fe3930e1f146476e81eca06ca0833bd477b3da8
>Author: James Hogan <james.hogan@imgtec.com>
>Date:   Thu Aug 18 10:01:28 2016 +0100
>
>    MIPS: KVM: Fix gfn range check in kseg0 tlb faults
>    
>    commit 0741f52d1b980dbeb290afe67d88fc2928edd8ab upstream.
>    
>    Two consecutive gfns are loaded into host TLB, so ensure the range check
>    isn't off by one if guest_pmap_npages is odd.
>    
>    Fixes: 858dd5d45733 ("KVM/MIPS32: MMU/TLB operations for the Guest.")
>    Signed-off-by: James Hogan <james.hogan@imgtec.com>
>    Cc: Paolo Bonzini <pbonzini@redhat.com>
>    Cc: "Radim KrÄmÃ¡Å" <rkrcmar@redhat.com>
>    Cc: Ralf Baechle <ralf@linux-mips.org>
>    Cc: linux-mips@linux-mips.org
>    Cc: kvm@vger.kernel.org
>    Signed-off-by: Radim KrÄmÃ¡Å <rkrcmar@redhat.com>
>    [james.hogan@imgtec.com: Backport to v4.7]
>    Signed-off-by: James Hogan <james.hogan@imgtec.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 0fbddc006492a05e061bfa61170f155c989f6a15
>Author: James Hogan <james.hogan@imgtec.com>
>Date:   Thu Aug 18 10:01:27 2016 +0100
>
>    MIPS: KVM: Add missing gfn range check
>    
>    commit 8985d50382359e5bf118fdbefc859d0dbf6cebc7 upstream.
>    
>    kvm_mips_handle_mapped_seg_tlb_fault() calculates the guest frame number
>    based on the guest TLB EntryLo values, however it is not range checked
>    to ensure it lies within the guest_pmap. If the physical memory the
>    guest refers to is out of range then dump the guest TLB and emit an
>    internal error.
>    
>    Fixes: 858dd5d45733 ("KVM/MIPS32: MMU/TLB operations for the Guest.")
>    Signed-off-by: James Hogan <james.hogan@imgtec.com>
>    Cc: Paolo Bonzini <pbonzini@redhat.com>
>    Cc: "Radim KrÄmÃ¡Å" <rkrcmar@redhat.com>
>    Cc: Ralf Baechle <ralf@linux-mips.org>
>    Cc: linux-mips@linux-mips.org
>    Cc: kvm@vger.kernel.org
>    Signed-off-by: Radim KrÄmÃ¡Å <rkrcmar@redhat.com>
>    [james.hogan@imgtec.com: Backport to v4.7]
>    Signed-off-by: James Hogan <james.hogan@imgtec.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 342b88eb5999fc0c2c587082c4dce6e40eb62a20
>Author: James Hogan <james.hogan@imgtec.com>
>Date:   Thu Aug 18 10:01:26 2016 +0100
>
>    MIPS: KVM: Fix mapped fault broken commpage handling
>    
>    commit c604cffa93478f8888bec62b23d6073dad03d43a upstream.
>    
>    kvm_mips_handle_mapped_seg_tlb_fault() appears to map the guest page at
>    virtual address 0 to PFN 0 if the guest has created its own mapping
>    there. The intention is unclear, but it may have been an attempt to
>    protect the zero page from being mapped to anything but the comm page in
>    code paths you wouldn't expect from genuine commpage accesses (guest
>    kernel mode cache instructions on that address, hitting trapping
>    instructions when executing from that address with a coincidental TLB
>    eviction during the KVM handling, and guest user mode accesses to that
>    address).
>    
>    Fix this to check for mappings exactly at KVM_GUEST_COMMPAGE_ADDR (it
>    may not be at address 0 since commit 42aa12e74e91 ("MIPS: KVM: Move
>    commpage so 0x0 is unmapped")), and set the corresponding EntryLo to be
>    interpreted as 0 (invalid).
>    
>    Fixes: 858dd5d45733 ("KVM/MIPS32: MMU/TLB operations for the Guest.")
>    Signed-off-by: James Hogan <james.hogan@imgtec.com>
>    Cc: Paolo Bonzini <pbonzini@redhat.com>
>    Cc: "Radim KrÄmÃ¡Å" <rkrcmar@redhat.com>
>    Cc: Ralf Baechle <ralf@linux-mips.org>
>    Cc: linux-mips@linux-mips.org
>    Cc: kvm@vger.kernel.org
>    Signed-off-by: Radim KrÄmÃ¡Å <rkrcmar@redhat.com>
>    [james.hogan@imgtec.com: Backport to v4.7]
>    Signed-off-by: James Hogan <james.hogan@imgtec.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 867df5e12818bca1d37fc4c9a35346764879f2af
>Author: Vegard Nossum <vegard.nossum@oracle.com>
>Date:   Fri Jul 15 00:22:07 2016 -0400
>
>    ext4: verify extent header depth
>    
>    [ Upstream commit 7bc9491645118c9461bd21099c31755ff6783593 ]
>    
>    Although the extent tree depth of 5 should enough be for the worst
>    case of 2*32 extents of length 1, the extent tree code does not
>    currently to merge nodes which are less than half-full with a sibling
>    node, or to shrink the tree depth if possible.  So it's possible, at
>    least in theory, for the tree depth to be greater than 5.  However,
>    even in the worst case, a tree depth of 32 is highly unlikely, and if
>    the file system is maliciously corrupted, an insanely large eh_depth
>    can cause memory allocation failures that will trigger kernel warnings
>    (here, eh_depth = 65280):
>    
>        JBD2: ext4.exe wants too many credits credits:195849 rsv_credits:0 max:256
>        ------------[ cut here ]------------
>        WARNING: CPU: 0 PID: 50 at fs/jbd2/transaction.c:293 start_this_handle+0x569/0x580
>        CPU: 0 PID: 50 Comm: ext4.exe Not tainted 4.7.0-rc5+ #508
>        Stack:
>         604a8947 625badd8 0002fd09 00000000
>         60078643 00000000 62623910 601bf9bc
>         62623970 6002fc84 626239b0 900000125
>        Call Trace:
>         [<6001c2dc>] show_stack+0xdc/0x1a0
>         [<601bf9bc>] dump_stack+0x2a/0x2e
>         [<6002fc84>] __warn+0x114/0x140
>         [<6002fdff>] warn_slowpath_null+0x1f/0x30
>         [<60165829>] start_this_handle+0x569/0x580
>         [<60165d4e>] jbd2__journal_start+0x11e/0x220
>         [<60146690>] __ext4_journal_start_sb+0x60/0xa0
>         [<60120a81>] ext4_truncate+0x131/0x3a0
>         [<60123677>] ext4_setattr+0x757/0x840
>         [<600d5d0f>] notify_change+0x16f/0x2a0
>         [<600b2b16>] do_truncate+0x76/0xc0
>         [<600c3e56>] path_openat+0x806/0x1300
>         [<600c55c9>] do_filp_open+0x89/0xf0
>         [<600b4074>] do_sys_open+0x134/0x1e0
>         [<600b4140>] SyS_open+0x20/0x30
>         [<6001ea68>] handle_syscall+0x88/0x90
>         [<600295fd>] userspace+0x3fd/0x500
>         [<6001ac55>] fork_handler+0x85/0x90
>    
>        ---[ end trace 08b0b88b6387a244 ]---
>    
>    [ Commit message modified and the extent tree depath check changed
>    from 5 to 32 -- tytso ]
>    
>    Cc: Darrick J. Wong <darrick.wong@oracle.com>
>    Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
>    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit cd5108403bda69524fd07a035e804d64ee8ae5b8
>Author: Kangjie Lu <kangjielu@gmail.com>
>Date:   Tue May 3 16:44:32 2016 -0400
>
>    ALSA: timer: Fix leak in events via snd_timer_user_tinterrupt
>    
>    [ Upstream commit e4ec8cc8039a7063e24204299b462bd1383184a5 ]
>    
>    The stack object âr1â has a total size of 32 bytes. Its field
>    âeventâ and âvalâ both contain 4 bytes padding. These 8 bytes
>    padding bytes are sent to user without being initialized.
>    
>    Signed-off-by: Kangjie Lu <kjlu@gatech.edu>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 1fbc4fd13bd04fd7c7fd033fdfde97e96d2865e5
>Author: Kangjie Lu <kangjielu@gmail.com>
>Date:   Tue May 3 16:44:20 2016 -0400
>
>    ALSA: timer: Fix leak in events via snd_timer_user_ccallback
>    
>    [ Upstream commit 9a47e9cff994f37f7f0dbd9ae23740d0f64f9fe6 ]
>    
>    The stack object âr1â has a total size of 32 bytes. Its field
>    âeventâ and âvalâ both contain 4 bytes padding. These 8 bytes
>    padding bytes are sent to user without being initialized.
>    
>    Signed-off-by: Kangjie Lu <kjlu@gatech.edu>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 1b7d7bce7467cf10f21007a5c952688877ead95e
>Author: Kangjie Lu <kangjielu@gmail.com>
>Date:   Tue May 3 16:44:07 2016 -0400
>
>    ALSA: timer: Fix leak in SNDRV_TIMER_IOCTL_PARAMS
>    
>    [ Upstream commit cec8f96e49d9be372fdb0c3836dcf31ec71e457e ]
>    
>    The stack object âtreadâ has a total size of 32 bytes. Its field
>    âeventâ and âvalâ both contain 4 bytes padding. These 8 bytes
>    padding bytes are sent to user without being initialized.
>    
>    Signed-off-by: Kangjie Lu <kjlu@gatech.edu>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit c65b5c9c0085bab46706f35c4889dd03cf2b0c08
>Author: MichaÅ Pecio <michal.pecio@gmail.com>
>Date:   Tue Jun 7 12:34:45 2016 +0200
>
>    USB: OHCI: Don't mark EDs as ED_OPER if scheduling fails
>    
>    [ Upstream commit c66f59ee5050447b3da92d36f5385a847990a894 ]
>    
>    Since ed_schedule begins with marking the ED as "operational",
>    the ED may be left in such state even if scheduling actually
>    fails.
>    
>    This allows future submission attempts to smuggle this ED to the
>    hardware behind the scheduler's back and without linking it to
>    the ohci->eds_in_use list.
>    
>    The former causes bandwidth saturation and data loss on isoc
>    endpoints, the latter crashes the kernel when attempt is made
>    to unlink such ED from this list.
>    
>    Fix ed_schedule to update ED state only on successful return.
>    
>    Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
>    Acked-by: Alan Stern <stern@rowland.harvard.edu>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 6412c3ae6b415ca83264a2c11e24bfb63cd74629
>Author: Miklos Szeredi <mszeredi@redhat.com>
>Date:   Mon Mar 21 17:31:44 2016 +0100
>
>    ovl: verify upper dentry before unlink and rename
>    
>    [ Upstream commit 11f3710417d026ea2f4fcf362d866342c5274185 ]
>    
>    Unlink and rename in overlayfs checked the upper dentry for staleness by
>    verifying upper->d_parent against upperdir.  However the dentry can go
>    stale also by being unhashed, for example.
>    
>    Expand the verification to actually look up the name again (under parent
>    lock) and check if it matches the upper dentry.  This matches what the VFS
>    does before passing the dentry to filesytem's unlink/rename methods, which
>    excludes any inconsistency caused by overlayfs.
>    
>    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 40b9a8f49d1e1e75dfdedbc25d0a3c9fea716bab
>Author: Mark Brown <broonie@kernel.org>
>Date:   Mon Jun 20 13:53:34 2016 +0100
>
>    iio:ad7266: Fix probe deferral for vref
>    
>    [ Upstream commit 68b356eb3d9f5e38910fb62e22a78e2a18d544ae ]
>    
>    Currently the ad7266 driver treats any failure to get vref as though the
>    regulator were not present but this means that if probe deferral is
>    triggered the driver will act as though the regulator were not present.
>    Instead only use the internal reference if we explicitly got -ENODEV which
>    is what is returned for absent regulators.
>    
>    Signed-off-by: Mark Brown <broonie@kernel.org>
>    Cc: <Stable@vger.kernel.org>
>    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit fb079b49a29bf9e25c493525b228f7b33dbbe44f
>Author: Mark Brown <broonie@kernel.org>
>Date:   Mon Jun 20 13:53:33 2016 +0100
>
>    iio:ad7266: Fix support for optional regulators
>    
>    [ Upstream commit e5511c816e5ac4909bdd38e85ac344e2b9b8e984 ]
>    
>    The ad7266 driver attempts to support deciding between the use of internal
>    and external power supplies by checking to see if an error is returned when
>    requesting the regulator. This doesn't work with the current code since the
>    driver uses a normal regulator_get() which is for non-optional supplies
>    and so assumes that if a regulator is not provided by the platform then
>    this is a bug in the platform integration and so substitutes a dummy
>    regulator. Use regulator_get_optional() instead which indicates to the
>    framework that the regulator may be absent and provides a dummy regulator
>    instead.
>    
>    Signed-off-by: Mark Brown <broonie@kernel.org>
>    Cc: <Stable@vger.kernel.org>
>    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 44cdc9fa258bde621577ac36fcab6fd674f4bf98
>Author: Mark Brown <broonie@kernel.org>
>Date:   Mon Jun 20 13:53:32 2016 +0100
>
>    iio:ad7266: Fix broken regulator error handling
>    
>    [ Upstream commit 6b7f4e25f3309f106a5c7ff42c8231494cf285d3 ]
>    
>    All regulator_get() variants return either a pointer to a regulator or an
>    ERR_PTR() so testing for NULL makes no sense and may lead to bugs if we
>    use NULL as a valid regulator. Fix this by using IS_ERR() as expected.
>    
>    Signed-off-by: Mark Brown <broonie@kernel.org>
>    Cc: <Stable@vger.kernel.org>
>    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 94f93848624aea581967a37e462909b3b0e6f0cb
>Author: Linus Walleij <linus.walleij@linaro.org>
>Date:   Fri Jun 17 15:22:24 2016 +0200
>
>    iio: accel: kxsd9: fix the usage of spi_w8r8()
>    
>    [ Upstream commit 0c1f91b98552da49d9d8eed32b3132a58d2f4598 ]
>    
>    These two spi_w8r8() calls return a value with is used by the code
>    following the error check. The dubious use was caused by a cleanup
>    patch.
>    
>    Fixes: d34dbee8ac8e ("staging:iio:accel:kxsd9 cleanup and conversion to iio_chan_spec.")
>    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>    Cc: <Stable@vger.kernel.org>
>    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit b2372ff74a06656f67b24e73477f81e25956df89
>Author: Luis de Bethencourt <luisbg@osg.samsung.com>
>Date:   Wed Jun 22 20:43:30 2016 +0100
>
>    staging: iio: accel: fix error check
>    
>    [ Upstream commit ef3149eb3ddb7f9125e11c90f8330e371b55cffd ]
>    
>    sca3000_read_ctrl_reg() returns a negative number on failure, check for
>    this instead of zero.
>    
>    Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
>    Cc: <Stable@vger.kernel.org>
>    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit c1a8303fb95f6933709831d5d5c742caee13d592
>Author: Matt Ranostay <mranostay@gmail.com>
>Date:   Sat May 21 20:01:03 2016 -0700
>
>    iio: proximity: as3935: fix buffer stack trashing
>    
>    [ Upstream commit 37b1ba2c68cfbe37f5f45bb91bcfaf2b016ae6a1 ]
>    
>    Buffer wasn't of a valid size to allow the timestamp, and correct padding.
>    This patchset also moves the buffer off the stack, and onto the heap.
>    
>    Cc: george.mccollister@gmail.com
>    Signed-off-by: Matt Ranostay <mranostay@gmail.com>
>    Cc: <Stable@vger.kernel.org>
>    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 9db892c0c7d71779bafcac2e26121357519fc615
>Author: Matt Ranostay <mranostay@gmail.com>
>Date:   Sat May 21 20:01:02 2016 -0700
>
>    iio: proximity: as3935: remove triggered buffer processing
>    
>    [ Upstream commit 7d0643634ea567969bf3f3ed6193a9d6fc75653b ]
>    
>    Triggered buffers shouldn't return processed data, and the respective
>    conversion was overflowing the defined .realbits for the channel.
>    
>    Cc: george.mccollister@gmail.com
>    Signed-off-by: Matt Ranostay <mranostay@gmail.com>
>    Cc: <Stable@vger.kernel.org>
>    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit e2a296e94cabe8f39420bec1936d9ef146c3dcee
>Author: Matt Ranostay <mranostay@gmail.com>
>Date:   Sat May 21 20:01:01 2016 -0700
>
>    iio: proximity: as3935: correct IIO_CHAN_INFO_RAW output
>    
>    [ Upstream commit 5138806f16c74c7cb8ac3e408a859c79eb7c9567 ]
>    
>    IIO_CHAN_INFO_RAW was returning processed data which was incorrect.
>    This also adds the IIO_CHAN_INFO_SCALE value to convert to a processed value.
>    
>    Signed-off-by: Matt Ranostay <mranostay@gmail.com>
>    Cc: <Stable@vger.kernel.org>
>    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit f247adf96f98a21b130a5844435a36f917c2a98a
>Author: Gregor Boirie <gregor.boirie@parrot.com>
>Date:   Tue Apr 19 11:18:33 2016 +0200
>
>    iio:st_pressure: fix sampling gains (bring inline with ABI)
>    
>    [ Upstream commit d43a41152f8e9e4c0d19850884d1fada076dee10 ]
>    
>    Temperature channels report scaled samples in Celsius although expected as
>    milli degree Celsius in Documentation/ABI/testing/sysfs-bus-iio.
>    Gains are not implemented at all for LPS001WP pressure and temperature
>    channels.
>    
>    This patch ensures that proper offsets and scales are exposed to userpace
>    for both pressure and temperature channels.
>    Also fix a NULL pointer exception when userspace reads content of sysfs
>    scale attribute when gains are not defined.
>    
>    Signed-off-by: Gregor Boirie <gregor.boirie@parrot.com>
>    Cc: <Stable@vger.kernel.org>
>    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 3bdfc8b57f57425b6fc6d1bca4accfbb72d755f8
>Author: Crestez Dan Leonard <leonard.crestez@intel.com>
>Date:   Tue May 3 15:27:09 2016 +0300
>
>    iio: Fix error handling in iio_trigger_attach_poll_func
>    
>    [ Upstream commit 99543823357966ac938d9a310947e731b67338e6 ]
>    
>    When attaching a pollfunc iio_trigger_attach_poll_func will allocate a
>    virtual irq and call the driver's set_trigger_state function. Fix error
>    handling to undo previous steps if any fails.
>    
>    In particular this fixes handling errors from a driver's
>    set_trigger_state function. When using triggered buffers a failure to
>    enable the trigger used to make the buffer unusable.
>    
>    Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com>
>    Cc: <Stable@vger.kernel.org>
>    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit f3c7b15dc141f5b3c9deddf8164fae28a9b4de5f
>Author: Andrey Ryabinin <aryabinin@virtuozzo.com>
>Date:   Wed May 11 16:51:51 2016 +0300
>
>    perf/x86: Fix undefined shift on 32-bit kernels
>    
>    [ Upstream commit 6d6f2833bfbf296101f9f085e10488aef2601ba5 ]
>    
>    Jim reported:
>    
>    	UBSAN: Undefined behaviour in arch/x86/events/intel/core.c:3708:12
>    	shift exponent 35 is too large for 32-bit type 'long unsigned int'
>    
>    The use of 'unsigned long' type obviously is not correct here, make it
>    'unsigned long long' instead.
>    
>    Reported-by: Jim Cromie <jim.cromie@gmail.com>
>    Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
>    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>    Cc: <stable@vger.kernel.org>
>    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
>    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
>    Cc: H. Peter Anvin <hpa@zytor.com>
>    Cc: Imre Palik <imrep@amazon.de>
>    Cc: Jiri Olsa <jolsa@redhat.com>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Stephane Eranian <eranian@google.com>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Cc: Vince Weaver <vincent.weaver@maine.edu>
>    Fixes: 2c33645d366d ("perf/x86: Honor the architectural performance monitoring version")
>    Link: http://lkml.kernel.org/r/1462974711-10037-1-git-send-email-aryabinin@virtuozzo.com
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 7ceedf586399587f2d3c2ae33377bfcf8b654b6d
>Author: Michael S. Tsirkin <mst@redhat.com>
>Date:   Tue May 17 13:31:18 2016 +0300
>
>    virtio_balloon: fix PFN format for virtio-1
>    
>    [ Upstream commit 87c9403b0d1de4676b0bd273eea68fcf6de68e68 ]
>    
>    Everything should be LE when using virtio-1, but
>    the linux balloon driver does not seem to care about that.
>    
>    Reported-by: Cornelia Huck <cornelia.huck@de.ibm.com>
>    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>    Tested-by: Cornelia Huck <cornelia.huck@de.ibm.com>
>    Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 4dbc156a8610abfa9209d23ad2bdb4692cf63730
>Author: Denis V. Lunev <den@openvz.org>
>Date:   Thu Aug 20 00:49:49 2015 +0300
>
>    virtio_balloon: do not change memory amount visible via /proc/meminfo
>    
>    [ Upstream commit 997e120843e82609c8d99a9d5714e6cf91e14cbe ]
>    
>    Balloon device is frequently used as a mean of cooperative memory control
>    in between guest and host to manage memory overcommitment. This is the
>    typical case for any hosting workload when KVM guest is provided for
>    end-user.
>    
>    Though there is a problem in this setup. The end-user and hosting provider
>    have signed SLA agreement in which some amount of memory is guaranted for
>    the guest. The good thing is that this memory will be given to the guest
>    when the guest will really need it (f.e. with OOM in guest and with
>    VIRTIO_BALLOON_F_DEFLATE_ON_OOM configuration flag set). The bad thing
>    is that end-user does not know this.
>    
>    Balloon by default reduce the amount of memory exposed to the end-user
>    each time when the page is stolen from guest or returned back by using
>    adjust_managed_page_count and thus /proc/meminfo shows reduced amount
>    of memory.
>    
>    Fortunately the solution is simple, we should just avoid to call
>    adjust_managed_page_count with VIRTIO_BALLOON_F_DEFLATE_ON_OOM set.
>    
>    Signed-off-by: Denis V. Lunev <den@openvz.org>
>    CC: Michael S. Tsirkin <mst@redhat.com>
>    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 55f883cb777124d1f9c197c5f6c1bd80840fbe2a
>Author: Mark Rutland <mark.rutland@arm.com>
>Date:   Tue Mar 1 14:18:50 2016 +0000
>
>    arm64: Rework valid_user_regs
>    
>    [ Upstream commit dbd4d7ca563fd0a8949718d35ce197e5642d5d9d ]
>    
>    We validate pstate using PSR_MODE32_BIT, which is part of the
>    user-provided pstate (and cannot be trusted). Also, we conflate
>    validation of AArch32 and AArch64 pstate values, making the code
>    difficult to reason about.
>    
>    Instead, validate the pstate value based on the associated task. The
>    task may or may not be current (e.g. when using ptrace), so this must be
>    passed explicitly by callers. To avoid circular header dependencies via
>    sched.h, is_compat_task is pulled out of asm/ptrace.h.
>    
>    To make the code possible to reason about, the AArch64 and AArch32
>    validation is split into separate functions. Software must respect the
>    RES0 policy for SPSR bits, and thus the kernel mirrors the hardware
>    policy (RAZ/WI) for bits as-yet unallocated. When these acquire an
>    architected meaning writes may be permitted (potentially with additional
>    validation).
>    
>    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
>    Acked-by: Will Deacon <will.deacon@arm.com>
>    Cc: Dave Martin <dave.martin@arm.com>
>    Cc: James Morse <james.morse@arm.com>
>    Cc: Peter Maydell <peter.maydell@linaro.org>
>    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 5c4642407d9c696dadef7fba557244c2d69d96dd
>Author: BjÃ¸rn Mork <bjorn@mork.no>
>Date:   Sun Jul 3 22:24:50 2016 +0200
>
>    cdc_ncm: workaround for EM7455 "silent" data interface
>    
>    [ Upstream commit c086e7096170390594c425114d98172bc9aceb8a ]
>    
>    Several Lenovo users have reported problems with their Sierra
>    Wireless EM7455 modem. The driver has loaded successfully and
>    the MBIM management channel has appeared to work, including
>    establishing a connection to the mobile network. But no frames
>    have been received over the data interface.
>    
>    The problem affects all EM7455 and MC7455, and is assumed to
>    affect other modems based on the same Qualcomm chipset and
>    baseband firmware.
>    
>    Testing narrowed the problem down to what seems to be a
>    firmware timing bug during initialization. Adding a short sleep
>    while probing is sufficient to make the problem disappear.
>    Experiments have shown that 1-2 ms is too little to have any
>    effect, while 10-20 ms is enough to reliably succeed.
>    
>    Reported-by: Stefan Armbruster <ml001@armbruster-it.de>
>    Reported-by: Ralph Plawetzki <ralph@purejava.org>
>    Reported-by: Andreas Fett <andreas.fett@secunet.com>
>    Reported-by: Rasmus Lerdorf <rasmus@lerdorf.com>
>    Reported-by: Samo Ratnik <samo.ratnik@gmail.com>
>    Reported-and-tested-by: Aleksander Morgado <aleksander@aleksander.es>
>    Signed-off-by: BjÃ¸rn Mork <bjorn@mork.no>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 28a6d048eb841a6bca10558a6c9e30ec5ca2b1af
>Author: Ben Hutchings <ben@decadent.org.uk>
>Date:   Wed Jun 22 19:43:35 2016 +0100
>
>    nfsd: check permissions when setting ACLs
>    
>    [ Upstream commit 999653786df6954a31044528ac3f7a5dadca08f4 ]
>    
>    Use set_posix_acl, which includes proper permission checks, instead of
>    calling ->set_acl directly.  Without this anyone may be able to grant
>    themselves permissions to a file by setting the ACL.
>    
>    Lock the inode to make the new checks atomic with respect to set_acl.
>    (Also, nfsd was the only caller of set_acl not locking the inode, so I
>    suspect this may fix other races.)
>    
>    This also simplifies the code, and ensures our ACLs are checked by
>    posix_acl_valid.
>    
>    The permission checks and the inode locking were lost with commit
>    4ac7249e, which changed nfsd to use the set_acl inode operation directly
>    instead of going through xattr handlers.
>    
>    Reported-by: David Sinquin <david@sinquin.eu>
>    [agreunba@redhat.com: use set_posix_acl]
>    Fixes: 4ac7249e
>    Cc: Christoph Hellwig <hch@infradead.org>
>    Cc: Al Viro <viro@zeniv.linux.org.uk>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
>    
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 173f43c05f782df4fe42cc1152f9306ef76dc6eb
>Author: Andreas Gruenbacher <agruenba@redhat.com>
>Date:   Wed Jun 22 23:57:25 2016 +0200
>
>    posix_acl: Add set_posix_acl
>    
>    [ Upstream commit 485e71e8fb6356c08c7fc6bcce4bf02c9a9a663f ]
>    
>    Factor out part of posix_acl_xattr_set into a common function that takes
>    a posix_acl, which nfsd can also call.
>    
>    The prototype already exists in include/linux/posix_acl.h.
>    
>    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
>    Cc: stable@vger.kernel.org
>    Cc: Christoph Hellwig <hch@infradead.org>
>    Cc: Al Viro <viro@zeniv.linux.org.uk>
>    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 63933c775e08459df80b6e76ead685bf20105494
>Author: Gavin Shan <gwshan@linux.vnet.ibm.com>
>Date:   Thu May 26 09:56:07 2016 +1000
>
>    powerpc/pseries: Fix PCI config address for DDW
>    
>    [ Upstream commit 8a934efe94347eee843aeea65bdec8077a79e259 ]
>    
>    In commit 8445a87f7092 "powerpc/iommu: Remove the dependency on EEH
>    struct in DDW mechanism", the PE address was replaced with the PCI
>    config address in order to remove dependency on EEH. According to PAPR
>    spec, firmware (pHyp or QEMU) should accept "xxBBSSxx" format PCI config
>    address, not "xxxxBBSS" provided by the patch. Note that "BB" is PCI bus
>    number and "SS" is the combination of slot and function number.
>    
>    This fixes the PCI address passed to DDW RTAS calls.
>    
>    Fixes: 8445a87f7092 ("powerpc/iommu: Remove the dependency on EEH struct in DDW mechanism")
>    Cc: stable@vger.kernel.org # v3.4+
>    Reported-by: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
>    Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
>    Tested-by: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
>    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 049de1972f59980634d4b3a31ce7defaa194d471
>Author: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
>Date:   Mon Apr 11 16:17:23 2016 -0300
>
>    powerpc/iommu: Remove the dependency on EEH struct in DDW mechanism
>    
>    [ Upstream commit 8445a87f7092bc8336ea1305be9306f26b846d93 ]
>    
>    Commit 39baadbf36ce ("powerpc/eeh: Remove eeh information from pci_dn")
>    changed the pci_dn struct by removing its EEH-related members.
>    As part of this clean-up, DDW mechanism was modified to read the device
>    configuration address from eeh_dev struct.
>    
>    As a consequence, now if we disable EEH mechanism on kernel command-line
>    for example, the DDW mechanism will fail, generating a kernel oops by
>    dereferencing a NULL pointer (which turns to be the eeh_dev pointer).
>    
>    This patch just changes the configuration address calculation on DDW
>    functions to a manual calculation based on pci_dn members instead of
>    using eeh_dev-based address.
>    
>    No functional changes were made. This was tested on pSeries, both
>    in PHyp and qemu guest.
>    
>    Fixes: 39baadbf36ce ("powerpc/eeh: Remove eeh information from pci_dn")
>    Cc: stable@vger.kernel.org # v3.4+
>    Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
>    Signed-off-by: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
>    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit d9ee963b61b93366103b88f10495b4680b256273
>Author: Vegard Nossum <vegard.nossum@oracle.com>
>Date:   Fri Jul 29 10:40:31 2016 +0200
>
>    block: fix use-after-free in seq file
>    
>    [ Upstream commit 77da160530dd1dc94f6ae15a981f24e5f0021e84 ]
>    
>    I got a KASAN report of use-after-free:
>    
>        ==================================================================
>        BUG: KASAN: use-after-free in klist_iter_exit+0x61/0x70 at addr ffff8800b6581508
>        Read of size 8 by task trinity-c1/315
>        =============================================================================
>        BUG kmalloc-32 (Not tainted): kasan: bad access detected
>        -----------------------------------------------------------------------------
>    
>        Disabling lock debugging due to kernel taint
>        INFO: Allocated in disk_seqf_start+0x66/0x110 age=144 cpu=1 pid=315
>                ___slab_alloc+0x4f1/0x520
>                __slab_alloc.isra.58+0x56/0x80
>                kmem_cache_alloc_trace+0x260/0x2a0
>                disk_seqf_start+0x66/0x110
>                traverse+0x176/0x860
>                seq_read+0x7e3/0x11a0
>                proc_reg_read+0xbc/0x180
>                do_loop_readv_writev+0x134/0x210
>                do_readv_writev+0x565/0x660
>                vfs_readv+0x67/0xa0
>                do_preadv+0x126/0x170
>                SyS_preadv+0xc/0x10
>                do_syscall_64+0x1a1/0x460
>                return_from_SYSCALL_64+0x0/0x6a
>        INFO: Freed in disk_seqf_stop+0x42/0x50 age=160 cpu=1 pid=315
>                __slab_free+0x17a/0x2c0
>                kfree+0x20a/0x220
>                disk_seqf_stop+0x42/0x50
>                traverse+0x3b5/0x860
>                seq_read+0x7e3/0x11a0
>                proc_reg_read+0xbc/0x180
>                do_loop_readv_writev+0x134/0x210
>                do_readv_writev+0x565/0x660
>                vfs_readv+0x67/0xa0
>                do_preadv+0x126/0x170
>                SyS_preadv+0xc/0x10
>                do_syscall_64+0x1a1/0x460
>                return_from_SYSCALL_64+0x0/0x6a
>    
>        CPU: 1 PID: 315 Comm: trinity-c1 Tainted: G    B           4.7.0+ #62
>        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
>         ffffea0002d96000 ffff880119b9f918 ffffffff81d6ce81 ffff88011a804480
>         ffff8800b6581500 ffff880119b9f948 ffffffff8146c7bd ffff88011a804480
>         ffffea0002d96000 ffff8800b6581500 fffffffffffffff4 ffff880119b9f970
>        Call Trace:
>         [<ffffffff81d6ce81>] dump_stack+0x65/0x84
>         [<ffffffff8146c7bd>] print_trailer+0x10d/0x1a0
>         [<ffffffff814704ff>] object_err+0x2f/0x40
>         [<ffffffff814754d1>] kasan_report_error+0x221/0x520
>         [<ffffffff8147590e>] __asan_report_load8_noabort+0x3e/0x40
>         [<ffffffff83888161>] klist_iter_exit+0x61/0x70
>         [<ffffffff82404389>] class_dev_iter_exit+0x9/0x10
>         [<ffffffff81d2e8ea>] disk_seqf_stop+0x3a/0x50
>         [<ffffffff8151f812>] seq_read+0x4b2/0x11a0
>         [<ffffffff815f8fdc>] proc_reg_read+0xbc/0x180
>         [<ffffffff814b24e4>] do_loop_readv_writev+0x134/0x210
>         [<ffffffff814b4c45>] do_readv_writev+0x565/0x660
>         [<ffffffff814b8a17>] vfs_readv+0x67/0xa0
>         [<ffffffff814b8de6>] do_preadv+0x126/0x170
>         [<ffffffff814b92ec>] SyS_preadv+0xc/0x10
>    
>    This problem can occur in the following situation:
>    
>    open()
>     - pread()
>        - .seq_start()
>           - iter = kmalloc() // succeeds
>           - seqf->private = iter
>        - .seq_stop()
>           - kfree(seqf->private)
>     - pread()
>        - .seq_start()
>           - iter = kmalloc() // fails
>        - .seq_stop()
>           - class_dev_iter_exit(seqf->private) // boom! old pointer
>    
>    As the comment in disk_seqf_stop() says, stop is called even if start
>    failed, so we need to reinitialise the private pointer to NULL when seq
>    iteration stops.
>    
>    An alternative would be to set the private pointer to NULL when the
>    kmalloc() in disk_seqf_start() fails.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
>    Acked-by: Tejun Heo <tj@kernel.org>
>    Signed-off-by: Jens Axboe <axboe@fb.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 403f056afd87471b1ef68c0519c8723afae4babb
>Author: James Hogan <james.hogan@imgtec.com>
>Date:   Thu Aug 4 17:36:08 2016 +0100
>
>    metag: Fix __cmpxchg_u32 asm constraint for CMP
>    
>    [ Upstream commit 6154c187b97ee7513046bb4eb317a89f738f13ef ]
>    
>    The LNKGET based atomic sequence in __cmpxchg_u32 has slightly incorrect
>    constraints for the return value which under certain circumstances can
>    allow an address unit register to be used as the first operand of a CMP
>    instruction. This isn't a valid instruction however as the encodings
>    only allow a data unit to be specified. This would result in an
>    assembler error like the following:
>    
>      Error: failed to assemble instruction: "CMP A0.2,D0Ar6"
>    
>    Fix by changing the constraint from "=&da" (assigned, early clobbered,
>    data or address unit register) to "=&d" (data unit register only).
>    
>    The constraint for the second operand, "bd" (an op2 register where op1
>    is a data unit register and the instruction supports O2R) is already
>    correct assuming the first operand is a data unit register.
>    
>    Other cases of CMP in inline asm have had their constraints checked, and
>    appear to all be fine.
>    
>    Fixes: 6006c0d8ce94 ("metag: Atomics, locks and bitops")
>    Signed-off-by: James Hogan <james.hogan@imgtec.com>
>    Cc: linux-metag@vger.kernel.org
>    Cc: <stable@vger.kernel.org> # 3.9.x-
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit a2036fb1a801d2b75ddc1d407b97519f9cac5a0b
>Author: Hui Wang <hui.wang@canonical.com>
>Date:   Thu Aug 4 15:28:04 2016 +0800
>
>    ALSA: hda - Fix headset mic detection problem for two dell machines
>    
>    [ Upstream commit 59ec4b57bcaede46546d54d037a21004b9aa5cef ]
>    
>    One of the machines has ALC255 on it, another one has ALC298 on it.
>    
>    On the machine with the codec ALC298, it also has the speaker volume
>    problem, so we add the fixup chained to ALC298_FIXUP_SPK_VOLUME rather
>    than adding a group of pin definition in the pin quirk table, since
>    the speak volume problem does not happen on other machines yet.
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Hui Wang <hui.wang@canonical.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 31ebbeb6e1e57a61dc091c9d321eeb330fa49c16
>Author: Woodrow Shen <woodrow.shen@canonical.com>
>Date:   Sat Jul 25 10:36:16 2015 +0800
>
>    ALSA: hda - Fix the headset mic that will not work on Dell desktop machine
>    
>    [ Upstream commit e9c28e16a0b7071c88a206ad8ce0c73f6605bba7 ]
>    
>    When the headset was plugged in the Dell desktop, the mic of headset
>    can't be detected and workable.
>    According to the alsa-info, we found the differece between alsa and
>    init_pin_configs on the machine, so we need to add the pin configs to
>    make headset work.
>    
>    Codec: Realtek ALC3234
>    Vendor Id: 0x10ec0255
>    Subsystem Id: 0x102806bb
>    
>    BugLink: https://bugs.launchpad.net/bugs/1477900
>    Signed-off-by: Woodrow Shen <woodrow.shen@canonical.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 0224028e1bcf2d49531308b971b8485c552c1510
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Wed Aug 3 15:13:00 2016 +0200
>
>    ALSA: hda: Fix krealloc() with __GFP_ZERO usage
>    
>    [ Upstream commit 33baefe5e72f17a6df378e48196cd8cada11deec ]
>    
>    krealloc() doesn't work always properly with __GFP_ZERO flag as
>    expected.  For clearing the reallocated area, we need to clear
>    explicitly instead.
>    
>    Reported-by: Joe Perches <joe@perches.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit df75887f42357dd8392bd856280be8e835d10a02
>Author: Maruthi Srinivas Bayyavarapu <Maruthi.Bayyavarapu@amd.com>
>Date:   Wed Aug 3 16:46:39 2016 +0530
>
>    ALSA: hda: add AMD Bonaire AZ PCI ID with proper driver caps
>    
>    [ Upstream commit fd48331f9b71d2add941adaee3619f5b8527182d ]
>    
>    This commit fixes garbled audio on Bonaire HDMI
>    
>    Signed-off-by: Maruthi Bayyavarapu <maruthi.bayyavarapu@amd.com>
>    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 333c2cf51f6a01388d4e5962ed585176ef7b6a86
>Author: Matt Redfearn <matt.redfearn@imgtec.com>
>Date:   Tue Jun 14 14:59:38 2016 +0100
>
>    MIPS: mm: Fix definition of R6 cache instruction
>    
>    [ Upstream commit 4f53989b0652ffe2605221c81ca8ffcfc90aed2a ]
>    
>    Commit a168b8f1cde6 ("MIPS: mm: Add MIPS R6 instruction encodings") added
>    an incorrect definition of the redefined MIPSr6 cache instruction.
>    
>    Executing any kernel code including this instuction results in a
>    reserved instruction exception and kernel panic.
>    
>    Fix the instruction definition.
>    
>    Fixes: a168b8f1cde6588ff7a67699fa11e01bc77a5ddd
>    Signed-off-by: Matt Redfearn <matt.redfearn@imgtec.com>
>    Cc: <stable@vger.kernel.org> # 4.x-
>    Cc: linux-mips@linux-mips.org
>    Cc: linux-kernel@vger.kernel.org
>    Patchwork: https://patchwork.linux-mips.org/patch/13663/
>    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit e2b438fdfa4d7041b883e5f2acd2c39da1fe5e68
>Author: Fabian Frederick <fabf@skynet.be>
>Date:   Tue Aug 2 14:03:07 2016 -0700
>
>    sysv, ipc: fix security-layer leaking
>    
>    [ Upstream commit 9b24fef9f0410fb5364245d6cc2bd044cc064007 ]
>    
>    Commit 53dad6d3a8e5 ("ipc: fix race with LSMs") updated ipc_rcu_putref()
>    to receive rcu freeing function but used generic ipc_rcu_free() instead
>    of msg_rcu_free() which does security cleaning.
>    
>    Running LTP msgsnd06 with kmemleak gives the following:
>    
>      cat /sys/kernel/debug/kmemleak
>    
>      unreferenced object 0xffff88003c0a11f8 (size 8):
>        comm "msgsnd06", pid 1645, jiffies 4294672526 (age 6.549s)
>        hex dump (first 8 bytes):
>          1b 00 00 00 01 00 00 00                          ........
>        backtrace:
>          kmemleak_alloc+0x23/0x40
>          kmem_cache_alloc_trace+0xe1/0x180
>          selinux_msg_queue_alloc_security+0x3f/0xd0
>          security_msg_queue_alloc+0x2e/0x40
>          newque+0x4e/0x150
>          ipcget+0x159/0x1b0
>          SyS_msgget+0x39/0x40
>          entry_SYSCALL_64_fastpath+0x13/0x8f
>    
>    Manfred Spraul suggested to fix sem.c as well and Davidlohr Bueso to
>    only use ipc_rcu_free in case of security allocation failure in newary()
>    
>    Fixes: 53dad6d3a8e ("ipc: fix race with LSMs")
>    Link: http://lkml.kernel.org/r/1470083552-22966-1-git-send-email-fabf@skynet.be
>    Signed-off-by: Fabian Frederick <fabf@skynet.be>
>    Cc: Davidlohr Bueso <dbueso@suse.de>
>    Cc: Manfred Spraul <manfred@colorfullife.com>
>    Cc: <stable@vger.kernel.org>	[3.12+]
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 4ef5c9aa794064d8dd5bbe82921e26befb97a7c7
>Author: Jia He <hejianet@gmail.com>
>Date:   Tue Aug 2 14:02:31 2016 -0700
>
>    mm/hugetlb: avoid soft lockup in set_max_huge_pages()
>    
>    [ Upstream commit 649920c6ab93429b94bc7c1aa7c0e8395351be32 ]
>    
>    In powerpc servers with large memory(32TB), we watched several soft
>    lockups for hugepage under stress tests.
>    
>    The call traces are as follows:
>    1.
>    get_page_from_freelist+0x2d8/0xd50
>    __alloc_pages_nodemask+0x180/0xc20
>    alloc_fresh_huge_page+0xb0/0x190
>    set_max_huge_pages+0x164/0x3b0
>    
>    2.
>    prep_new_huge_page+0x5c/0x100
>    alloc_fresh_huge_page+0xc8/0x190
>    set_max_huge_pages+0x164/0x3b0
>    
>    This patch fixes such soft lockups.  It is safe to call cond_resched()
>    there because it is out of spin_lock/unlock section.
>    
>    Link: http://lkml.kernel.org/r/1469674442-14848-1-git-send-email-hejianet@gmail.com
>    Signed-off-by: Jia He <hejianet@gmail.com>
>    Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
>    Acked-by: Michal Hocko <mhocko@suse.com>
>    Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
>    Cc: Mike Kravetz <mike.kravetz@oracle.com>
>    Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
>    Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 834ced1a13bdf510eae34d08bae1f1ae49b33141
>Author: Mike Snitzer <snitzer@redhat.com>
>Date:   Tue Aug 2 13:07:20 2016 -0400
>
>    dm: set DMF_SUSPENDED* _before_ clearing DMF_NOFLUSH_SUSPENDING
>    
>    [ Upstream commit eaf9a7361f47727b166688a9f2096854eef60fbe ]
>    
>    Otherwise, there is potential for both DMF_SUSPENDED* and
>    DMF_NOFLUSH_SUSPENDING to not be set during dm_suspend() -- which is
>    definitely _not_ a valid state.
>    
>    This fix, in conjuction with "dm rq: fix the starting and stopping of
>    blk-mq queues", addresses the potential for request-based DM multipath's
>    __multipath_map() to see !dm_noflush_suspending() during suspend.
>    
>    Reported-by: Bart Van Assche <bart.vanassche@sandisk.com>
>    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 655fe78746d0b9141fe763535fc16d6652665c13
>Author: Sasha Levin <alexander.levin@verizon.com>
>Date:   Sat Aug 13 07:45:12 2016 -0400
>
>    dm rq: fix the starting and stopping of blk-mq queues
>    
>    [ Upstream commit 7d9595d848cdff5c7939f68eec39e0c5d36a1d67 ]
>    
>    Improve dm_stop_queue() to cancel any requeue_work.  Also, have
>    dm_start_queue() and dm_stop_queue() clear/set the QUEUE_FLAG_STOPPED
>    for the blk-mq request_queue.
>    
>    On suspend dm_stop_queue() handles stopping the blk-mq request_queue
>    BUT: even though the hw_queues are marked BLK_MQ_S_STOPPED at that point
>    there is still a race that is allowing block/blk-mq.c to call ->queue_rq
>    against a hctx that it really shouldn't.  Add a check to
>    dm_mq_queue_rq() that guards against this rarity (albeit _not_
>    race-free).
>    
>    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
>    Cc: stable@vger.kernel.org # must patch dm.c on < 4.8 kernels
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 980b6556a8df88e6160da185f72a4bc548e72199
>Author: Mike Snitzer <snitzer@redhat.com>
>Date:   Fri Jul 29 13:19:55 2016 -0400
>
>    dm flakey: error READ bios during the down_interval
>    
>    [ Upstream commit 99f3c90d0d85708e7401a81ce3314e50bf7f2819 ]
>    
>    When the corrupt_bio_byte feature was introduced it caused READ bios to
>    no longer be errored with -EIO during the down_interval.  This had to do
>    with the complexity of needing to submit READs if the corrupt_bio_byte
>    feature was used.
>    
>    Fix it so READ bios are properly errored with -EIO; doing so early in
>    flakey_map() as long as there isn't a match for the corrupt_bio_byte
>    feature.
>    
>    Fixes: a3998799fb4df ("dm flakey: add corrupt_bio_byte feature")
>    Reported-by: Akira Hayakawa <ruby.wktk@gmail.com>
>    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 0d88572753e332dedcb0d904b6033602326bd7c0
>Author: Laura Abbott <labbott@redhat.com>
>Date:   Fri Jul 8 12:18:50 2016 -0700
>
>    ftrace/recordmcount: Work around for addition of metag magic but not relocations
>    
>    [ Upstream commit b2e1c26f0b62531636509fbcb6dab65617ed8331 ]
>    
>    glibc recently did a sync up (94e73c95d9b5 "elf.h: Sync with the gabi
>    webpage") that added a #define for EM_METAG but did not add relocations
>    
>    This triggers build errors:
>    
>    scripts/recordmcount.c: In function 'do_file':
>    scripts/recordmcount.c:466:28: error: 'R_METAG_ADDR32' undeclared (first use in this function)
>      case EM_METAG:  reltype = R_METAG_ADDR32;
>                                ^~~~~~~~~~~~~~
>    scripts/recordmcount.c:466:28: note: each undeclared identifier is reported only once for each function it appears in
>    scripts/recordmcount.c:468:20: error: 'R_METAG_NONE' undeclared (first use in this function)
>         rel_type_nop = R_METAG_NONE;
>                        ^~~~~~~~~~~~
>    
>    Work around this change with some more #ifdefery for the relocations.
>    
>    Fedora Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1354034
>    
>    Link: http://lkml.kernel.org/r/1468005530-14757-1-git-send-email-labbott@redhat.com
>    
>    Cc: stable@vger.kernel.org # v3.9+
>    Cc: James Hogan <james.hogan@imgtec.com>
>    Fixes: 00512bdd4573 ("metag: ftrace support")
>    Reported-by: Ross Burton <ross.burton@intel.com>
>    Signed-off-by: Laura Abbott <labbott@redhat.com>
>    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 2876b1b0b51d0153b95a377a8d13758b39ac0032
>Author: Konstantin Neumoin <kneumoin@virtuozzo.com>
>Date:   Mon Jul 11 15:28:59 2016 +0300
>
>    balloon: check the number of available pages in leak balloon
>    
>    [ Upstream commit 37cf99e08c6fb4dcea0f9ad2b13b6daa8c76a711 ]
>    
>    The balloon has a special mechanism that is subscribed to the oom
>    notification which leads to deflation for a fixed number of pages.
>    The number is always fixed even when the balloon is fully deflated.
>    But leak_balloon did not expect that the pages to deflate will be more
>    than taken, and raise a "BUG" in balloon_page_dequeue when page list
>    will be empty.
>    
>    So, the simplest solution would be to check that the number of releases
>    pages is less or equal to the number taken pages.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Konstantin Neumoin <kneumoin@virtuozzo.com>
>    Signed-off-by: Denis V. Lunev <den@openvz.org>
>    CC: Michael S. Tsirkin <mst@redhat.com>
>    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit c6657f74f2c8c43b53afaabbf12b6bbf49874603
>Author: Sasha Levin <alexander.levin@verizon.com>
>Date:   Sun Aug 14 19:56:14 2016 -0400
>
>    x86/syscalls/64: Add compat_sys_keyctl for 32-bit userspace
>    
>    [ Upstream commit f7d665627e103e82d34306c7d3f6f46f387c0d8b ]
>    
>    x86_64 needs to use compat_sys_keyctl for 32-bit userspace rather than
>    calling sys_keyctl(). The latter will work in a lot of cases, thereby
>    hiding the issue.
>    
>    Reported-by: Stephan Mueller <smueller@chronox.de>
>    Tested-by: Stephan Mueller <smueller@chronox.de>
>    Signed-off-by: David Howells <dhowells@redhat.com>
>    Cc: Andy Lutomirski <luto@kernel.org>
>    Cc: Borislav Petkov <bp@alien8.de>
>    Cc: Brian Gerst <brgerst@gmail.com>
>    Cc: Denys Vlasenko <dvlasenk@redhat.com>
>    Cc: H. Peter Anvin <hpa@zytor.com>
>    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Cc: keyrings@vger.kernel.org
>    Cc: linux-security-module@vger.kernel.org
>    Cc: stable@vger.kernel.org
>    Link: http://lkml.kernel.org/r/146961615805.14395.5581949237156769439.stgit@warthog.procyon.org.uk
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 10855c6411044f502f0bde816fd8f6ea5f6c7206
>Author: Hui Wang <hui.wang@canonical.com>
>Date:   Mon Aug 1 10:20:32 2016 +0800
>
>    ALSA: hda/realtek - Can't adjust speaker's volume on a Dell AIO
>    
>    [ Upstream commit dd9aa335c88003d131ac874e7f6809902de0b847 ]
>    
>    We have a Dell AIO on which we can't adjust its speaker's volume.
>    The problem is it is connected to a Audio Output node without Amp-out
>    capability. To fix it, we change it to be connnected to a node with
>    Amp-out capability.
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Hui Wang <hui.wang@canonical.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 6cdb1649f74423f61f7425d7447f3182a676d76b
>Author: Keith Packard <keithp@keithp.com>
>Date:   Wed Jul 15 12:14:39 2015 -0700
>
>    ALSA: hda/realtek: Enable HP amp and mute LED on HP Folio 9480m [v3]
>    
>    [ Upstream commit 98973f2f083a5ec580da8bbb685e6baa93613546 ]
>    
>    This laptop needs GPIO4 pulled high to enable the headphone amplifier,
>    and has a mute LED on GPIO3. I modelled the patch on the existing
>    GPIO4 code which pulls the line low for the same purpose; this time,
>    the HP amp line is pulled high.
>    
>    v2: Disable the headphone amplifier when no headphone is connected.
>        Don't disable power savings to preserve the LED state.
>    
>    v3: Remove headset-specific hooks and code; this is just a headphone.
>    
>    Signed-off-by: Keith Packard <keithp@keithp.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit baea0d65a4810802ee865d123c84436c52b416fd
>Author: Ilia Mirkin <imirkin@alum.mit.edu>
>Date:   Wed Jul 27 19:16:39 2016 -0400
>
>    drm/nouveau/gr/nv3x: fix instobj write offsets in gr setup
>    
>    [ Upstream commit d0e62ef6ed257715a88d0e5d7cd850a1695429e2 ]
>    
>    This should fix some unaligned access warnings. This is also likely to
>    fix non-descript issues on nv30/nv34 as a result of incorrect channel
>    setup.
>    
>    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96836
>    Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit c1b4d25bc66d0c5f1552daeb0cb72b0794bb1e62
>Author: Mikulas Patocka <mpatocka@redhat.com>
>Date:   Thu Jul 28 18:56:13 2016 -0400
>
>    drm/nouveau/fbcon: fix font width not divisible by 8
>    
>    [ Upstream commit 28668f43b8e421634e1623f72a879812288dd06b ]
>    
>    The patch f045f459d925 ("drm/nouveau/fbcon: fix out-of-bounds memory accesses")
>    tries to fix some out of memory accesses. Unfortunatelly, the patch breaks the
>    display when using fonts with width that is not divisiable by 8.
>    
>    The monochrome bitmap for each character is stored in memory by lines from top
>    to bottom. Each line is padded to a full byte.
>    
>    For example, for 22x11 font, each line is padded to 16 bits, so each
>    character is consuming 44 bytes total, that is 11 32-bit words. The patch
>    f045f459d925 changed the logic to "dsize = ALIGN(image->width *
>    image->height, 32) >> 5", that is just 8 words - this is incorrect and it
>    causes display corruption.
>    
>    This patch adds the necesary padding of lines to 8 bytes.
>    
>    This patch should be backported to stable kernels where f045f459d925 was
>    backported.
>    
>    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
>    Fixes: f045f459d925 ("drm/nouveau/fbcon: fix out-of-bounds memory accesses")
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit c027bc0ce936ce9446b6b9e1e994555722567b04
>Author: Richard Weinberger <richard@nod.at>
>Date:   Thu Jun 23 19:30:38 2016 +0200
>
>    ubi: Make volume resize power cut aware
>    
>    [ Upstream commit 4946784bd3924b1374f05eebff2fd68660bae866 ]
>    
>    When the volume resize operation shrinks a volume,
>    LEBs will be unmapped. Since unmapping will not erase these
>    LEBs immediately we have to wait for that operation to finish.
>    Otherwise in case of a power cut right after writing the new
>    volume table the UBI attach process can find more LEBs than the
>    volume table knows. This will render the UBI image unattachable.
>    
>    Fix this issue by waiting for erase to complete and write the new
>    volume table afterward.
>    
>    Cc: <stable@vger.kernel.org>
>    Reported-by: Boris Brezillon <boris.brezillon@free-electrons.com>
>    Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
>    Signed-off-by: Richard Weinberger <richard@nod.at>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 304e9158144a340e4ce63d51d1ac62d8a3bb2964
>Author: Richard Weinberger <richard@nod.at>
>Date:   Mon Jul 4 22:06:51 2016 +0200
>
>    ubi: Fix early logging
>    
>    [ Upstream commit bc743f34dfa011e62edd0ea4ae8455be06c083b5 ]
>    
>    We cannot use ubi_* logging functions before the UBI
>    object is initialized.
>    
>    Cc: <stable@vger.kernel.org>
>    Fixes: 3260870331 ("UBI: Extend UBI layer debug/messaging capabilities")
>    Signed-off-by: Richard Weinberger <richard@nod.at>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit ae32d1b98ba29408df87c0ed47877ca0f248eae7
>Author: Iosif Harutyunov <iharutyunov@SonicWALL.com>
>Date:   Fri Jul 22 23:22:42 2016 +0000
>
>    ubi: Fix race condition between ubi device creation and udev
>    
>    [ Upstream commit 714fb87e8bc05ff78255afc0dca981e8c5242785 ]
>    
>    Install the UBI device object before we arm sysfs.
>    Otherwise udev tries to read sysfs attributes before UBI is ready and
>    udev rules will not match.
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Iosif Harutyunov <iharutyunov@sonicwall.com>
>    [rw: massaged commit message]
>    Signed-off-by: Richard Weinberger <richard@nod.at>
>    
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit eb61bdda28b0fc1b7bea16919e0d34a9702d30e2
>Author: Wei Fang <fangwei1@huawei.com>
>Date:   Mon Jul 25 21:17:04 2016 +0800
>
>    fuse: fix wrong assignment of ->flags in fuse_send_init()
>    
>    [ Upstream commit 9446385f05c9af25fed53dbed3cc75763730be52 ]
>    
>    FUSE_HAS_IOCTL_DIR should be assigned to ->flags, it may be a typo.
>    
>    Signed-off-by: Wei Fang <fangwei1@huawei.com>
>    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
>    Fixes: 69fe05c90ed5 ("fuse: add missing INIT flags")
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 614c3393382fc89c2fd42363b90594b9a666057b
>Author: Maxim Patlasov <mpatlasov@virtuozzo.com>
>Date:   Tue Jul 19 18:12:26 2016 -0700
>
>    fuse: fuse_flush must check mapping->flags for errors
>    
>    [ Upstream commit 9ebce595f63a407c5cec98f98f9da8459b73740a ]
>    
>    fuse_flush() calls write_inode_now() that triggers writeback, but actual
>    writeback will happen later, on fuse_sync_writes(). If an error happens,
>    fuse_writepage_end() will set error bit in mapping->flags. So, we have to
>    check mapping->flags after fuse_sync_writes().
>    
>    Signed-off-by: Maxim Patlasov <mpatlasov@virtuozzo.com>
>    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
>    Fixes: 4d99ff8f12eb ("fuse: Turn writeback cache on")
>    Cc: <stable@vger.kernel.org> # v3.15+
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 3fc4a4a2c647ecd3348ca55dbdb56a3c990d2432
>Author: Alexey Kuznetsov <kuznet@parallels.com>
>Date:   Tue Jul 19 12:48:01 2016 -0700
>
>    fuse: fsync() did not return IO errors
>    
>    [ Upstream commit ac7f052b9e1534c8248f814b6f0068ad8d4a06d2 ]
>    
>    Due to implementation of fuse writeback filemap_write_and_wait_range() does
>    not catch errors. We have to do this directly after fuse_sync_writes()
>    
>    Signed-off-by: Alexey Kuznetsov <kuznet@virtuozzo.com>
>    Signed-off-by: Maxim Patlasov <mpatlasov@virtuozzo.com>
>    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
>    Fixes: 4d99ff8f12eb ("fuse: Turn writeback cache on")
>    Cc: <stable@vger.kernel.org> # v3.15+
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 93c0b008e79f11430ce07b6271b37671051d4298
>Author: Vineet Gupta <vgupta@synopsys.com>
>Date:   Thu Jul 28 11:35:50 2016 -0700
>
>    ARC: mm: don't loose PTE_SPECIAL in pte_modify()
>    
>    [ Upstream commit 3925a16ae980c79d1a8fd182d7f9487da1edd4dc ]
>    
>    LTP madvise05 was generating mm splat
>    
>    | [ARCLinux]# /sd/ltp/testcases/bin/madvise05
>    | BUG: Bad page map in process madvise05  pte:80e08211 pmd:9f7d4000
>    | page:9fdcfc90 count:1 mapcount:-1 mapping:  (null) index:0x0 flags: 0x404(referenced|reserved)
>    | page dumped because: bad pte
>    | addr:200b8000 vm_flags:00000070 anon_vma:  (null) mapping:  (null) index:1005c
>    | file:  (null) fault:  (null) mmap:  (null) readpage:  (null)
>    | CPU: 2 PID: 6707 Comm: madvise05
>    
>    And for newer kernels, the system was rendered unusable afterwards.
>    
>    The problem was mprotect->pte_modify() clearing PTE_SPECIAL (which is
>    set to identify the special zero page wired to the pte).
>    When pte was finally unmapped, special casing for zero page was not
>    done, and instead it was treated as a "normal" page, tripping on the
>    map counts etc.
>    
>    This fixes ARC STAR 9001053308
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit ae9c7f35df23c4d187e0e9c3f8e23f3ca7587e40
>Author: Alex Deucher <alexander.deucher@amd.com>
>Date:   Wed Jul 27 15:28:56 2016 -0400
>
>    drm/radeon: fix firmware info version checks
>    
>    [ Upstream commit 3edc38a0facef45ee22af8afdce3737f421f36ab ]
>    
>    Some of the checks didn't handle frev 2 tables properly.
>    
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 7afd374e0c8db8e6306820fd95fb3838e0fdcae5
>Author: David Howells <dhowells@redhat.com>
>Date:   Wed Jul 27 11:43:37 2016 +0100
>
>    KEYS: 64-bit MIPS needs to use compat_sys_keyctl for 32-bit userspace
>    
>    [ Upstream commit 20f06ed9f61a185c6dabd662c310bed6189470df ]
>    
>    MIPS64 needs to use compat_sys_keyctl for 32-bit userspace rather than
>    calling sys_keyctl.  The latter will work in a lot of cases, thereby hiding
>    the issue.
>    
>    Reported-by: Stephan Mueller <smueller@chronox.de>
>    Signed-off-by: David Howells <dhowells@redhat.com>
>    cc: stable@vger.kernel.org
>    Cc: linux-mips@linux-mips.org
>    Cc: linux-kernel@vger.kernel.org
>    Cc: linux-security-module@vger.kernel.org
>    Cc: keyrings@vger.kernel.org
>    Patchwork: https://patchwork.linux-mips.org/patch/13832/
>    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit bd89870c4447cbf622dd50d4d179e26234833600
>Author: Paul Mackerras <paulus@ozlabs.org>
>Date:   Wed Jun 22 15:52:55 2016 +1000
>
>    KVM: PPC: Book3S HV: Save/restore TM state in H_CEDE
>    
>    [ Upstream commit 93d17397e4e2182fdaad503e2f9da46202c0f1c3 ]
>    
>    It turns out that if the guest does a H_CEDE while the CPU is in
>    a transactional state, and the H_CEDE does a nap, and the nap
>    loses the architected state of the CPU (which is is allowed to do),
>    then we lose the checkpointed state of the virtual CPU.  In addition,
>    the transactional-memory state recorded in the MSR gets reset back
>    to non-transactional, and when we try to return to the guest, we take
>    a TM bad thing type of program interrupt because we are trying to
>    transition from non-transactional to transactional with a hrfid
>    instruction, which is not permitted.
>    
>    The result of the program interrupt occurring at that point is that
>    the host CPU will hang in an infinite loop with interrupts disabled.
>    Thus this is a denial of service vulnerability in the host which can
>    be triggered by any guest (and depending on the guest kernel, it can
>    potentially triggered by unprivileged userspace in the guest).
>    
>    This vulnerability has been assigned the ID CVE-2016-5412.
>    
>    To fix this, we save the TM state before napping and restore it
>    on exit from the nap, when handling a H_CEDE in real mode.  The
>    case where H_CEDE exits to host virtual mode is already OK (as are
>    other hcalls which exit to host virtual mode) because the exit
>    path saves the TM state.
>    
>    Cc: stable@vger.kernel.org # v3.15+
>    Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit ae40dadbb81f553a053dcef39e5b0322f586c497
>Author: Paul Mackerras <paulus@ozlabs.org>
>Date:   Wed Jun 22 14:21:59 2016 +1000
>
>    KVM: PPC: Book3S HV: Pull out TM state save/restore into separate procedures
>    
>    [ Upstream commit f024ee098476a3e620232e4a78cfac505f121245 ]
>    
>    This moves the transactional memory state save and restore sequences
>    out of the guest entry/exit paths into separate procedures.  This is
>    so that these sequences can be used in going into and out of nap
>    in a subsequent patch.
>    
>    The only code changes here are (a) saving and restore LR on the
>    stack, since these new procedures get called with a bl instruction,
>    (b) explicitly saving r1 into the PACA instead of assuming that
>    HSTATE_HOST_R1(r13) is already set, and (c) removing an unnecessary
>    and redundant setting of MSR[TM] that should have been removed by
>    commit 9d4d0bdd9e0a ("KVM: PPC: Book3S HV: Add transactional memory
>    support", 2013-09-24) but wasn't.
>    
>    Cc: stable@vger.kernel.org # v3.15+
>    Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit a3b180a9da61b9be52e1bcf8ff54b4cea3ce332c
>Author: Pavel Shilovsky <pshilovsky@samba.org>
>Date:   Sun Jul 24 10:37:38 2016 +0300
>
>    CIFS: Fix a possible invalid memory access in smb2_query_symlink()
>    
>    [ Upstream commit 7893242e2465aea6f2cbc2639da8fa5ce96e8cc2 ]
>    
>    During following a symbolic link we received err_buf from SMB2_open().
>    While the validity of SMB2 error response is checked previously
>    in smb2_check_message() a symbolic link payload is not checked at all.
>    Fix it by adding such checks.
>    
>    Cc: Dan Carpenter <dan.carpenter@oracle.com>
>    CC: Stable <stable@vger.kernel.org>
>    Signed-off-by: Pavel Shilovsky <pshilovsky@samba.org>
>    Signed-off-by: Steve French <smfrench@gmail.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit b7e61a108f9fccd8d1b90ffe62704b929ba841eb
>Author: Aurelien Aptel <aaptel@suse.com>
>Date:   Wed May 25 19:59:09 2016 +0200
>
>    fs/cifs: make share unaccessible at root level mountable
>    
>    [ Upstream commit a6b5058fafdf508904bbf16c29b24042cef3c496 ]
>    
>    if, when mounting //HOST/share/sub/dir/foo we can query /sub/dir/foo but
>    not any of the path components above:
>    
>    - store the /sub/dir/foo prefix in the cifs super_block info
>    - in the superblock, set root dentry to the subpath dentry (instead of
>      the share root)
>    - set a flag in the superblock to remember it
>    - use prefixpath when building path from a dentry
>    
>    fixes bso#8950
>    
>    Signed-off-by: Aurelien Aptel <aaptel@suse.com>
>    CC: Stable <stable@vger.kernel.org>
>    Reviewed-by: Pavel Shilovsky <pshilovsky@samba.org>
>    Signed-off-by: Steve French <smfrench@gmail.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit b5e8e7f655d3d01430c357bdebe72a6ddc19e9a7
>Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>Date:   Mon Jul 25 11:36:54 2016 -0700
>
>    Input: i8042 - break load dependency between atkbd/psmouse and i8042
>    
>    [ Upstream commit 4097461897df91041382ff6fcd2bfa7ee6b2448c ]
>    
>    As explained in 1407814240-4275-1-git-send-email-decui@microsoft.com we
>    have a hard load dependency between i8042 and atkbd which prevents
>    keyboard from working on Gen2 Hyper-V VMs.
>    
>    > hyperv_keyboard invokes serio_interrupt(), which needs a valid serio
>    > driver like atkbd.c.  atkbd.c depends on libps2.c because it invokes
>    > ps2_command().  libps2.c depends on i8042.c because it invokes
>    > i8042_check_port_owner().  As a result, hyperv_keyboard actually
>    > depends on i8042.c.
>    >
>    > For a Generation 2 Hyper-V VM (meaning no i8042 device emulated), if a
>    > Linux VM (like Arch Linux) happens to configure CONFIG_SERIO_I8042=m
>    > rather than =y, atkbd.ko can't load because i8042.ko can't load(due to
>    > no i8042 device emulated) and finally hyperv_keyboard can't work and
>    > the user can't input: https://bugs.archlinux.org/task/39820
>    > (Ubuntu/RHEL/SUSE aren't affected since they use CONFIG_SERIO_I8042=y)
>    
>    To break the dependency we move away from using i8042_check_port_owner()
>    and instead allow serio port owner specify a mutex that clients should use
>    to serialize PS/2 command stream.
>    
>    Reported-by: Mark Laws <mdl@60hz.org>
>    Tested-by: Mark Laws <mdl@60hz.org>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit e9071d07878c865449c5afb062e6d305c62d1e85
>Author: Ben Hutchings <ben@decadent.org.uk>
>Date:   Thu Apr 28 09:24:05 2016 +0930
>
>    Documentation/module-signing.txt: Note need for version info if reusing a key
>    
>    [ Upstream commit b8612e517c3c9809e1200b72c474dbfd969e5a83 ]
>    
>    Signing a module should only make it trusted by the specific kernel it
>    was built for, not anything else.  If a module signing key is used for
>    multiple ABI-incompatible kernels, the modules need to include enough
>    version information to distinguish them.
>    
>    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 6ac9857245bfb71d836f46db817b0c11e3e4bf69
>Author: Ben Hutchings <ben@decadent.org.uk>
>Date:   Thu Apr 28 09:24:01 2016 +0930
>
>    module: Invalidate signatures on force-loaded modules
>    
>    [ Upstream commit bca014caaa6130e57f69b5bf527967aa8ee70fdd ]
>    
>    Signing a module should only make it trusted by the specific kernel it
>    was built for, not anything else.  Loading a signed module meant for a
>    kernel with a different ABI could have interesting effects.
>    Therefore, treat all signatures as invalid when a module is
>    force-loaded.
>    
>    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 7e6f0e1e3091dc9aada9d067aac7adbb5a9d9b06
>Author: Vegard Nossum <vegard.nossum@oracle.com>
>Date:   Sat Jul 23 07:43:50 2016 +0200
>
>    net/irda: fix NULL pointer dereference on memory allocation failure
>    
>    [ Upstream commit d3e6952cfb7ba5f4bfa29d4803ba91f96ce1204d ]
>    
>    I ran into this:
>    
>        kasan: CONFIG_KASAN_INLINE enabled
>        kasan: GPF could be caused by NULL-ptr deref or user memory access
>        general protection fault: 0000 [#1] PREEMPT SMP KASAN
>        CPU: 2 PID: 2012 Comm: trinity-c3 Not tainted 4.7.0-rc7+ #19
>        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
>        task: ffff8800b745f2c0 ti: ffff880111740000 task.ti: ffff880111740000
>        RIP: 0010:[<ffffffff82bbf066>]  [<ffffffff82bbf066>] irttp_connect_request+0x36/0x710
>        RSP: 0018:ffff880111747bb8  EFLAGS: 00010286
>        RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000069dd8358
>        RDX: 0000000000000009 RSI: 0000000000000027 RDI: 0000000000000048
>        RBP: ffff880111747c00 R08: 0000000000000000 R09: 0000000000000000
>        R10: 0000000069dd8358 R11: 1ffffffff0759723 R12: 0000000000000000
>        R13: ffff88011a7e4780 R14: 0000000000000027 R15: 0000000000000000
>        FS:  00007fc738404700(0000) GS:ffff88011af00000(0000) knlGS:0000000000000000
>        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>        CR2: 00007fc737fdfb10 CR3: 0000000118087000 CR4: 00000000000006e0
>        Stack:
>         0000000000000200 ffff880111747bd8 ffffffff810ee611 ffff880119f1f220
>         ffff880119f1f4f8 ffff880119f1f4f0 ffff88011a7e4780 ffff880119f1f232
>         ffff880119f1f220 ffff880111747d58 ffffffff82bca542 0000000000000000
>        Call Trace:
>         [<ffffffff82bca542>] irda_connect+0x562/0x1190
>         [<ffffffff825ae582>] SYSC_connect+0x202/0x2a0
>         [<ffffffff825b4489>] SyS_connect+0x9/0x10
>         [<ffffffff8100334c>] do_syscall_64+0x19c/0x410
>         [<ffffffff83295ca5>] entry_SYSCALL64_slow_path+0x25/0x25
>        Code: 41 89 ca 48 89 e5 41 57 41 56 41 55 41 54 41 89 d7 53 48 89 fb 48 83 c7 48 48 89 fa 41 89 f6 48 c1 ea 03 48 83 ec 20 4c 8b 65 10 <0f> b6 04 02 84 c0 74 08 84 c0 0f 8e 4c 04 00 00 80 7b 48 00 74
>        RIP  [<ffffffff82bbf066>] irttp_connect_request+0x36/0x710
>         RSP <ffff880111747bb8>
>        ---[ end trace 4cda2588bc055b30 ]---
>    
>    The problem is that irda_open_tsap() can fail and leave self->tsap = NULL,
>    and then irttp_connect_request() almost immediately dereferences it.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 7d06f7f8963d8a705aeda1a5b60a69bfca75935e
>Author: Wei Fang <fangwei1@huawei.com>
>Date:   Wed Jul 6 11:32:20 2016 +0800
>
>    fs/dcache.c: avoid soft-lockup in dput()
>    
>    [ Upstream commit 47be61845c775643f1aa4d2a54343549f943c94c ]
>    
>    We triggered soft-lockup under stress test which
>    open/access/write/close one file concurrently on more than
>    five different CPUs:
>    
>    WARN: soft lockup - CPU#0 stuck for 11s! [who:30631]
>    ...
>    [<ffffffc0003986f8>] dput+0x100/0x298
>    [<ffffffc00038c2dc>] terminate_walk+0x4c/0x60
>    [<ffffffc00038f56c>] path_lookupat+0x5cc/0x7a8
>    [<ffffffc00038f780>] filename_lookup+0x38/0xf0
>    [<ffffffc000391180>] user_path_at_empty+0x78/0xd0
>    [<ffffffc0003911f4>] user_path_at+0x1c/0x28
>    [<ffffffc00037d4fc>] SyS_faccessat+0xb4/0x230
>    
>    ->d_lock trylock may failed many times because of concurrently
>    operations, and dput() may execute a long time.
>    
>    Fix this by replacing cpu_relax() with cond_resched().
>    dput() used to be sleepable, so make it sleepable again
>    should be safe.
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Wei Fang <fangwei1@huawei.com>
>    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 49e3c9aeeaa4053af7aca53e76defe0f0908d4e3
>Author: Huacai Chen <chenhc@lemote.com>
>Date:   Fri Jul 22 11:46:31 2016 +0800
>
>    MIPS: Don't register r4k sched clock when CPUFREQ enabled
>    
>    [ Upstream commit 07d69579e7fec27e371296d8ca9d6076fc401b5c ]
>    
>    Don't register r4k sched clock when CPUFREQ enabled because sched clock
>    need a constant frequency.
>    
>    Signed-off-by: Huacai Chen <chenhc@lemote.com>
>    Cc: John Crispin <john@phrozen.org>
>    Cc: Steven J . Hill <Steven.Hill@caviumnetworks.com>
>    Cc: Fuxin Zhang <zhangfx@lemote.com>
>    Cc: Zhangjin Wu <wuzhangjin@gmail.com>
>    Cc: linux-mips@linux-mips.org
>    Cc: stable@vger.kernel.org
>    Patchwork: https://patchwork.linux-mips.org/patch/13820/
>    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 0e2cbad6d084a9c7370f25c991fcdc7bf811b197
>Author: Benjamin Coddington <bcodding@redhat.com>
>Date:   Mon Jul 18 10:41:57 2016 -0400
>
>    nfs: don't create zero-length requests
>    
>    [ Upstream commit 149a4fddd0a72d526abbeac0c8deaab03559836a ]
>    
>    NFS doesn't expect requests with wb_bytes set to zero and may make
>    unexpected decisions about how to handle that request at the page IO layer.
>    Skip request creation if we won't have any wb_bytes in the request.
>    
>    Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
>    Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
>    Reviewed-by: Weston Andros Adamson <dros@primarydata.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit e1cc0756ae6a4ff0a28542c38258b7a26cf3effe
>Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>Date:   Wed Jul 6 12:50:12 2016 +0300
>
>    gpio: intel-mid: Remove potentially harmful code
>    
>    [ Upstream commit 3dbd3212f81b2b410a34a922055e2da792864829 ]
>    
>    The commit d56d6b3d7d69 ("gpio: langwell: add Intel Merrifield support")
>    doesn't look at all as a proper support for Intel Merrifield and I dare to say
>    that it distorts the behaviour of the hardware.
>    
>    The register map is different on Intel Merrifield, i.e. only 6 out of 8
>    register have the same purpose but none of them has same location in the
>    address space. The current case potentially harmful to existing hardware since
>    it's poking registers on wrong offsets and may set some pin to be GPIO output
>    when connected hardware doesn't expect such.
>    
>    Besides the above GPIO and pinctrl on Intel Merrifield have been located in
>    different IP blocks. The functionality has been extended as well, i.e. added
>    support of level interrupts, special registers for wake capable sources and
>    thus, in my opinion, requires a completele separate driver.
>    
>    If someone wondering the existing gpio-intel-mid.c would be converted to actual
>    pinctrl (which by the fact it is now), though I wouldn't be a volunteer to do
>    that.
>    
>    Fixes: d56d6b3d7d69 ("gpio: langwell: add Intel Merrifield support")
>    Cc: stable@vger.kernel.org # v3.13+
>    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>    Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
>    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 7f5a3c76f3d4fe9a0aa9c659249757a2b31db42f
>Author: Feng Li <lifeng1519@gmail.com>
>Date:   Tue Jul 12 06:15:44 2016 +0800
>
>    iscsi-target: Fix panic when adding second TCP connection to iSCSI session
>    
>    [ Upstream commit 8abc718de6e9e52d8a6bfdb735060554aeae25e4 ]
>    
>    In MC/S scenario, the conn->sess has been set NULL in
>    iscsi_login_non_zero_tsih_s1 when the second connection comes here,
>    then kernel panic.
>    
>    The conn->sess will be assigned in iscsi_login_non_zero_tsih_s2. So
>    we should check whether it's NULL before calling.
>    
>    Signed-off-by: Feng Li <lifeng1519@gmail.com>
>    Tested-by: Sumit Rai <sumit.rai@calsoftinc.com>
>    Cc: stable@vger.kernel.org # 3.14+
>    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 634a3fc5f16470e9b78ccd7ce643305122d5ebb2
>Author: Paul Moore <paul@paul-moore.com>
>Date:   Tue Jul 19 17:42:57 2016 -0400
>
>    audit: fix a double fetch in audit_log_single_execve_arg()
>    
>    [ Upstream commit 43761473c254b45883a64441dd0bc85a42f3645c ]
>    
>    There is a double fetch problem in audit_log_single_execve_arg()
>    where we first check the execve(2) argumnets for any "bad" characters
>    which would require hex encoding and then re-fetch the arguments for
>    logging in the audit record[1].  Of course this leaves a window of
>    opportunity for an unsavory application to munge with the data.
>    
>    This patch reworks things by only fetching the argument data once[2]
>    into a buffer where it is scanned and logged into the audit
>    records(s).  In addition to fixing the double fetch, this patch
>    improves on the original code in a few other ways: better handling
>    of large arguments which require encoding, stricter record length
>    checking, and some performance improvements (completely unverified,
>    but we got rid of some strlen() calls, that's got to be a good
>    thing).
>    
>    As part of the development of this patch, I've also created a basic
>    regression test for the audit-testsuite, the test can be tracked on
>    GitHub at the following link:
>    
>     * https://github.com/linux-audit/audit-testsuite/issues/25
>    
>    [1] If you pay careful attention, there is actually a triple fetch
>    problem due to a strnlen_user() call at the top of the function.
>    
>    [2] This is a tiny white lie, we do make a call to strnlen_user()
>    prior to fetching the argument data.  I don't like it, but due to the
>    way the audit record is structured we really have no choice unless we
>    copy the entire argument at once (which would require a rather
>    wasteful allocation).  The good news is that with this patch the
>    kernel no longer relies on this strnlen_user() value for anything
>    beyond recording it in the log, we also update it with a trustworthy
>    value whenever possible.
>    
>    Reported-by: Pengfei Wang <wpengfeinudt@gmail.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Paul Moore <paul@paul-moore.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit a4664afa0dffd5340c61511d3da14e30bfd01517
>Author: Linus Torvalds <torvalds@linux-foundation.org>
>Date:   Wed Jul 8 09:33:38 2015 -0700
>
>    Fix broken audit tests for exec arg len
>    
>    [ Upstream commit 45820c294fe1b1a9df495d57f40585ef2d069a39 ]
>    
>    The "fix" in commit 0b08c5e5944 ("audit: Fix check of return value of
>    strnlen_user()") didn't fix anything, it broke things.  As reported by
>    Steven Rostedt:
>    
>     "Yes, strnlen_user() returns 0 on fault, but if you look at what len is
>      set to, than you would notice that on fault len would be -1"
>    
>    because we just subtracted one from the return value.  So testing
>    against 0 doesn't test for a fault condition, it tests against a
>    perfectly valid empty string.
>    
>    Also fix up the usual braindamage wrt using WARN_ON() inside a
>    conditional - make it part of the conditional and remove the explicit
>    unlikely() (which is already part of the WARN_ON*() logic, exactly so
>    that you don't have to write unreadable code.
>    
>    Reported-and-tested-by: Steven Rostedt <rostedt@goodmis.org>
>    Cc: Jan Kara <jack@suse.cz>
>    Cc: Paul Moore <pmoore@redhat.com>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit a49b282f08d96cd73838e4e1a5ace747d432ba7d
>Author: Jan Kara <jack@suse.cz>
>Date:   Tue Jun 2 17:08:29 2015 +0200
>
>    audit: Fix check of return value of strnlen_user()
>    
>    [ Upstream commit 0b08c5e59441d08ab4b5e72afefd5cd98a4d83df ]
>    
>    strnlen_user() returns 0 when it hits fault, not -1. Fix the test in
>    audit_log_single_execve_arg(). Luckily this shouldn't ever happen unless
>    there's a kernel bug so it's mostly a cosmetic fix.
>    
>    CC: Paul Moore <pmoore@redhat.com>
>    Signed-off-by: Jan Kara <jack@suse.cz>
>    Signed-off-by: Paul Moore <pmoore@redhat.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit dd265663a1a9a14d80ea34d9bde9b15d7b614bd2
>Author: Rabin Vincent <rabinv@axis.com>
>Date:   Tue Jul 19 09:26:21 2016 +0200
>
>    cifs: fix crash due to race in hmac(md5) handling
>    
>    [ Upstream commit bd975d1eead2558b76e1079e861eacf1f678b73b ]
>    
>    The secmech hmac(md5) structures are present in the TCP_Server_Info
>    struct and can be shared among multiple CIFS sessions.  However, the
>    server mutex is not currently held when these structures are allocated
>    and used, which can lead to a kernel crashes, as in the scenario below:
>    
>    mount.cifs(8) #1				mount.cifs(8) #2
>    
>    Is secmech.sdeschmaccmd5 allocated?
>    // false
>    
>    						Is secmech.sdeschmaccmd5 allocated?
>    						// false
>    
>    secmech.hmacmd = crypto_alloc_shash..
>    secmech.sdeschmaccmd5 = kzalloc..
>    sdeschmaccmd5->shash.tfm = &secmec.hmacmd;
>    
>    						secmech.sdeschmaccmd5 = kzalloc
>    						// sdeschmaccmd5->shash.tfm
>    						// not yet assigned
>    
>    crypto_shash_update()
>     deref NULL sdeschmaccmd5->shash.tfm
>    
>     Unable to handle kernel paging request at virtual address 00000030
>     epc   : 8027ba34 crypto_shash_update+0x38/0x158
>     ra    : 8020f2e8 setup_ntlmv2_rsp+0x4bc/0xa84
>     Call Trace:
>      crypto_shash_update+0x38/0x158
>      setup_ntlmv2_rsp+0x4bc/0xa84
>      build_ntlmssp_auth_blob+0xbc/0x34c
>      sess_auth_rawntlmssp_authenticate+0xac/0x248
>      CIFS_SessSetup+0xf0/0x178
>      cifs_setup_session+0x4c/0x84
>      cifs_get_smb_ses+0x2c8/0x314
>      cifs_mount+0x38c/0x76c
>      cifs_do_mount+0x98/0x440
>      mount_fs+0x20/0xc0
>      vfs_kern_mount+0x58/0x138
>      do_mount+0x1e8/0xccc
>      SyS_mount+0x88/0xd4
>      syscall_common+0x30/0x54
>    
>    Fix this by locking the srv_mutex around the code which uses these
>    hmac(md5) structures.  All the other secmech algos already have similar
>    locking.
>    
>    Fixes: 95dc8dd14e2e84cc ("Limit allocation of crypto mechanisms to dialect which requires")
>    Signed-off-by: Rabin Vincent <rabinv@axis.com>
>    Acked-by: Sachin Prabhu <sprabhu@redhat.com>
>    CC: Stable <stable@vger.kernel.org>
>    Signed-off-by: Steve French <smfrench@gmail.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit b9090fe48d172c2bb3d59d521fe6e9f317f39ad7
>Author: Nicholas Bellinger <nab@linux-iscsi.org>
>Date:   Thu Jun 2 14:56:45 2016 -0700
>
>    target: Fix race between iscsi-target connection shutdown + ABORT_TASK
>    
>    [ Upstream commit 064cdd2d91c2805d788876082f31cc63506f22c3 ]
>    
>    This patch fixes a race in iscsit_release_commands_from_conn() ->
>    iscsit_free_cmd() -> transport_generic_free_cmd() + wait_for_tasks=1,
>    where CMD_T_FABRIC_STOP could end up being set after the final
>    kref_put() is called from core_tmr_abort_task() context.
>    
>    This results in transport_generic_free_cmd() blocking indefinately
>    on se_cmd->cmd_wait_comp, because the target_release_cmd_kref()
>    check for CMD_T_FABRIC_STOP returns false.
>    
>    To address this bug, make iscsit_release_commands_from_conn()
>    do list_splice and set CMD_T_FABRIC_STOP early while holding
>    iscsi_conn->cmd_lock.  Also make iscsit_aborted_task() only
>    remove iscsi_cmd_t if CMD_T_FABRIC_STOP has not already been
>    set.
>    
>    Finally in target_release_cmd_kref(), only honor fabric_stop
>    if CMD_T_ABORTED has been set.
>    
>    Cc: Mike Christie <mchristi@redhat.com>
>    Cc: Quinn Tran <quinn.tran@qlogic.com>
>    Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
>    Cc: Christoph Hellwig <hch@lst.de>
>    Cc: Hannes Reinecke <hare@suse.de>
>    Cc: stable@vger.kernel.org # 3.14+
>    Tested-by: Nicholas Bellinger <nab@linux-iscsi.org>
>    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 6c631d3eb5c8b930911ca73ecf596eebd87a6be2
>Author: Nicholas Bellinger <nab@linux-iscsi.org>
>Date:   Wed May 25 12:25:04 2016 -0700
>
>    target: Fix missing complete during ABORT_TASK + CMD_T_FABRIC_STOP
>    
>    [ Upstream commit 5e2c956b8aa24d4f33ff7afef92d409eed164746 ]
>    
>    During transport_generic_free_cmd() with a concurrent TMR
>    ABORT_TASK and shutdown CMD_T_FABRIC_STOP bit set, the
>    caller will be blocked on se_cmd->cmd_wait_stop completion
>    until the final kref_put() -> target_release_cmd_kref()
>    has been invoked to call complete().
>    
>    However, when ABORT_TASK is completed with FUNCTION_COMPLETE
>    in core_tmr_abort_task(), the aborted se_cmd will have already
>    been removed from se_sess->sess_cmd_list via list_del_init().
>    
>    This results in target_release_cmd_kref() hitting the
>    legacy list_empty() == true check, invoking ->release_cmd()
>    but skipping complete() to wakeup se_cmd->cmd_wait_stop
>    blocked earlier in transport_generic_free_cmd() code.
>    
>    To address this bug, it's safe to go ahead and drop the
>    original list_empty() check so that fabric_stop invokes
>    the complete() as expected, since list_del_init() can
>    safely be used on a empty list.
>    
>    Cc: Mike Christie <mchristi@redhat.com>
>    Cc: Quinn Tran <quinn.tran@qlogic.com>
>    Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
>    Cc: Christoph Hellwig <hch@lst.de>
>    Cc: Hannes Reinecke <hare@suse.de>
>    Cc: stable@vger.kernel.org # 3.14+
>    Tested-by: Nicholas Bellinger <nab@linux-iscsi.org>
>    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 80d341fee312c8c1c039dcb73c8309551446b21c
>Author: Hector Palacios <hector.palacios@digi.com>
>Date:   Mon Jul 18 10:39:18 2016 +0200
>
>    mtd: nand: fix bug writing 1 byte less than page size
>    
>    [ Upstream commit 144f4c98399e2c0ca60eb414c15a2c68125c18b8 ]
>    
>    nand_do_write_ops() determines if it is writing a partial page with the
>    formula:
>    	part_pagewr = (column || writelen < (mtd->writesize - 1))
>    
>    When 'writelen' is exactly 1 byte less than the NAND page size the formula
>    equates to zero, so the code doesn't process it as a partial write,
>    although it should.
>    As a consequence the function remains in the while(1) loop with 'writelen'
>    becoming 0xffffffff and iterating endlessly.
>    
>    The bug may not be easy to reproduce in Linux since user space tools
>    usually force the padding or round-up the write size to a page-size
>    multiple.
>    This was discovered in U-Boot where the issue can be reproduced by
>    writing any size that is 1 byte less than a page-size multiple.
>    For example, on a NAND with 2K page (0x800):
>    	=> nand erase.part <partition>
>    	=> nand write $loadaddr <partition> 7ff
>    
>    [Editor's note: the bug was added in commit 29072b96078f, but moved
>    around in commit 66507c7bc8895 ("mtd: nand: Add support to use nand_base
>    poi databuf as bounce buffer")]
>    
>    Fixes: 29072b96078f ("[MTD] NAND: add subpage write support")
>    Signed-off-by: Hector Palacios <hector.palacios@digi.com>
>    Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Brian Norris <computersforpeace@gmail.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 8ae0073fa1cb99a655eb674cac241e10a03b02fe
>Author: Will Deacon <will.deacon@arm.com>
>Date:   Tue Jul 19 15:07:37 2016 +0100
>
>    arm64: debug: unmask PSTATE.D earlier
>    
>    [ Upstream commit 2ce39ad15182604beb6c8fa8bed5e46b59fd1082 ]
>    
>    Clearing PSTATE.D is one of the requirements for generating a debug
>    exception. The arm64 booting protocol requires that PSTATE.D is set,
>    since many of the debug registers (for example, the hw_breakpoint
>    registers) are UNKNOWN out of reset and could potentially generate
>    spurious, fatal debug exceptions in early boot code if PSTATE.D was
>    clear. Once the debug registers have been safely initialised, PSTATE.D
>    is cleared, however this is currently broken for two reasons:
>    
>    (1) The boot CPU clears PSTATE.D in a postcore_initcall and secondary
>        CPUs clear PSTATE.D in secondary_start_kernel. Since the initcall
>        runs after SMP (and the scheduler) have been initialised, there is
>        no guarantee that it is actually running on the boot CPU. In this
>        case, the boot CPU is left with PSTATE.D set and is not capable of
>        generating debug exceptions.
>    
>    (2) In a preemptible kernel, we may explicitly schedule on the IRQ
>        return path to EL1. If an IRQ occurs with PSTATE.D set in the idle
>        thread, then we may schedule the kthread_init thread, run the
>        postcore_initcall to clear PSTATE.D and then context switch back
>        to the idle thread before returning from the IRQ. The exception
>        return path will then restore PSTATE.D from the stack, and set it
>        again.
>    
>    This patch fixes the problem by moving the clearing of PSTATE.D earlier
>    to proc.S. This has the desirable effect of clearing it in one place for
>    all CPUs, long before we have to worry about the scheduler or any
>    exception handling. We ensure that the previous reset of MDSCR_EL1 has
>    completed before unmasking the exception, so that any spurious
>    exceptions resulting from UNKNOWN debug registers are not generated.
>    
>    Without this patch applied, the kprobes selftests have been seen to fail
>    under KVM, where we end up attempting to step the OOL instruction buffer
>    with PSTATE.D set and therefore fail to complete the step.
>    
>    Cc: <stable@vger.kernel.org>
>    Acked-by: Mark Rutland <mark.rutland@arm.com>
>    Reported-by: Catalin Marinas <catalin.marinas@arm.com>
>    Tested-by: Marc Zyngier <marc.zyngier@arm.com>
>    Signed-off-by: Will Deacon <will.deacon@arm.com>
>    Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
>    Tested-by: Catalin Marinas <catalin.marinas@arm.com>
>    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit f88ded2649b5d8345320e2ecdb24c4da64ff3f4f
>Author: Alim Akhtar <alim.akhtar@samsung.com>
>Date:   Tue Jul 5 15:28:53 2016 +0530
>
>    rtc: s3c: Add s3c_rtc_{enable/disable}_clk in s3c_rtc_setfreq()
>    
>    [ Upstream commit 70c96dfac0e231424e17743bd52f6cd2ff1f2439 ]
>    
>    As per code flow s3c_rtc_setfreq() will get called with rtc clock disabled
>    and in set_freq we perform h/w registers read/write, which results in a
>    kernel crash on exynos7 platform while probing rtc driver.
>    Below is code flow:
>    s3c_rtc_probe()
>        clk_prepare_enable(info->rtc_clk) // rtc clock enabled
>        s3c_rtc_gettime() // will enable clk if not done, and disable it upon exit
>        s3c_rtc_setfreq() //then this will be called with clk disabled
>    
>    This patch take cares of such issue by adding s3c_rtc_{enable/disable}_clk in
>    s3c_rtc_setfreq().
>    
>    Fixes: 24e1455493da ("drivers/rtc/rtc-s3c.c: delete duplicate clock control")
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
>    Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>    Reviewed-by: Pankaj Dubey <pankaj.dubey@samsung.com>
>    Tested-by: Pankaj Dubey <pankaj.dubey@samsung.com>
>    Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit abf9569225763ab83a538530454f7d280fd08e4a
>Author: Sasha Levin <alexander.levin@verizon.com>
>Date:   Sun Aug 14 18:50:25 2016 -0400
>
>    dm: fix second blk_delay_queue() parameter to be in msec units not jiffies
>    
>    [ Upstream commit bd9f55ea1cf6e14eb054b06ea877d2d1fa339514 ]
>    
>    Commit d548b34b062 ("dm: reduce the queue delay used in dm_request_fn
>    from 100ms to 10ms") always intended the value to be 10 msecs -- it
>    just expressed it in jiffies because earlier commit 7eaceaccab ("block:
>    remove per-queue plugging") did.
>    
>    Signed-off-by: Tahsin Erdogan <tahsin@google.com>
>    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
>    Fixes: d548b34b062 ("dm: reduce the queue delay used in dm_request_fn from 100ms to 10ms")
>    Cc: stable@vger.kernel.org # 4.1+ -- stable@ backports must be applied to drivers/md/dm.c
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 812925986c9f0398f9a15228580cf4d38fdd1577
>Author: Herbert Xu <herbert@gondor.apana.org.au>
>Date:   Tue Jul 12 13:17:57 2016 +0800
>
>    crypto: scatterwalk - Fix test in scatterwalk_done
>    
>    [ Upstream commit 5f070e81bee35f1b7bd1477bb223a873ff657803 ]
>    
>    When there is more data to be processed, the current test in
>    scatterwalk_done may prevent us from calling pagedone even when
>    we should.
>    
>    In particular, if we're on an SG entry spanning multiple pages
>    where the last page is not a full page, we will incorrectly skip
>    calling pagedone on the second last page.
>    
>    This patch fixes this by adding a separate test for whether we've
>    reached the end of a page.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 98953c4c44a70f6cecc9cd2df86412bba34e37e6
>Author: Amadeusz SÅawiÅski <amadeusz.slawinski@tieto.com>
>Date:   Thu Jul 14 10:50:23 2016 +0200
>
>    Bluetooth: Fix l2cap_sock_setsockopt() with optname BT_RCVMTU
>    
>    [ Upstream commit 23bc6ab0a0912146fd674a0becc758c3162baabc ]
>    
>    When we retrieve imtu value from userspace we should use 16 bit pointer
>    cast instead of 32 as it's defined that way in headers. Fixes setsockopt
>    calls on big-endian platforms.
>    
>    Signed-off-by: Amadeusz SÅawiÅski <amadeusz.slawinski@tieto.com>
>    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 5436aa6c963c736d49ff256ce51f632d2a65f6d0
>Author: Cao, Lei <Lei.Cao@stratus.com>
>Date:   Fri Jul 15 13:54:04 2016 +0000
>
>    KVM: VMX: handle PML full VMEXIT that occurs during event delivery
>    
>    [ Upstream commit b244c9fc251e14a083a1cbf04bef10bd99303a76 ]
>    
>    With PML enabled, guest will shut down if a PML full VMEXIT occurs during
>    event delivery. According to Intel SDM 27.2.3, PML full VMEXIT can occur when
>    event is being delivered through IDT, so KVM should not exit to user space
>    with error. Instead, it should let EXIT_REASON_PML_FULL go through and the
>    event will be re-injected on the next VMENTRY.
>    
>    Signed-off-by: Lei Cao <lei.cao@stratus.com>
>    Cc: stable@vger.kernel.org
>    Fixes: 843e4330573c ("KVM: VMX: Add PML support in VMX")
>    [Shortened the summary and Cc'd stable.]
>    Signed-off-by: Radim KrÄmÃ¡Å <rkrcmar@redhat.com>
>    
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit aef1e06da0d03039075d4b5ae8ff95b1a856c8ba
>Author: Daniele Palmas <dnlplm@gmail.com>
>Date:   Mon Jun 6 12:38:17 2016 +0200
>
>    USB: serial: option: add support for Telit LE910 PID 0x1206
>    
>    [ Upstream commit 3c0415fa08548e3bc63ef741762664497ab187ed ]
>    
>    This patch adds support for 0x1206 PID of Telit LE910.
>    
>    Since the interfaces positions are the same than the ones for
>    0x1043 PID of Telit LE922, telit_le922_blacklist_usbcfg3 is used.
>    
>    Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 4af80d9fc8c6c671da4d578a871e08dea92da26f
>Author: Michael Neuling <mikey@neuling.org>
>Date:   Wed Jul 6 14:58:06 2016 +1000
>
>    powerpc/tm: Fix stack pointer corruption in __tm_recheckpoint()
>    
>    [ Upstream commit 6bcb80143e792becfd2b9cc6a339ce523e4e2219 ]
>    
>    At the start of __tm_recheckpoint() we save the kernel stack pointer
>    (r1) in SPRG SCRATCH0 (SPRG2) so that we can restore it after the
>    trecheckpoint.
>    
>    Unfortunately, the same SPRG is used in the SLB miss handler.  If an
>    SLB miss is taken between the save and restore of r1 to the SPRG, the
>    SPRG is changed and hence r1 is also corrupted.  We can end up with
>    the following crash when we start using r1 again after the restore
>    from the SPRG:
>    
>      Oops: Bad kernel stack pointer, sig: 6 [#1]
>      SMP NR_CPUS=2048 NUMA pSeries
>      CPU: 658 PID: 143777 Comm: htm_demo Tainted: G            EL   X 4.4.13-0-default #1
>      task: c0000b56993a7810 ti: c00000000cfec000 task.ti: c0000b56993bc000
>      NIP: c00000000004f188 LR: 00000000100040b8 CTR: 0000000010002570
>      REGS: c00000000cfefd40 TRAP: 0300   Tainted: G            EL   X  (4.4.13-0-default)
>      MSR: 8000000300001033 <SF,ME,IR,DR,RI,LE>  CR: 02000424  XER: 20000000
>      CFAR: c000000000008468 DAR: 00003ffd84e66880 DSISR: 40000000 SOFTE: 0
>      PACATMSCRATCH: 00003ffbc865e680
>      GPR00: fffffffcfabc4268 00003ffd84e667a0 00000000100d8c38 000000030544bb80
>      GPR04: 0000000000000002 00000000100cf200 0000000000000449 00000000100cf100
>      GPR08: 000000000000c350 0000000000002569 0000000000002569 00000000100d6c30
>      GPR12: 00000000100d6c28 c00000000e6a6b00 00003ffd84660000 0000000000000000
>      GPR16: 0000000000000003 0000000000000449 0000000010002570 0000010009684f20
>      GPR20: 0000000000800000 00003ffd84e5f110 00003ffd84e5f7a0 00000000100d0f40
>      GPR24: 0000000000000000 0000000000000000 0000000000000000 00003ffff0673f50
>      GPR28: 00003ffd84e5e960 00000000003d0f00 00003ffd84e667a0 00003ffd84e5e680
>      NIP [c00000000004f188] restore_gprs+0x110/0x17c
>      LR [00000000100040b8] 0x100040b8
>      Call Trace:
>      Instruction dump:
>      f8a1fff0 e8e700a8 38a00000 7ca10164 e8a1fff8 e821fff0 7c0007dd 7c421378
>      7db142a6 7c3242a6 38800002 7c810164 <e9c100e0> e9e100e8 ea0100f0 ea2100f8
>    
>    We hit this on large memory machines (> 2TB) but it can also be hit on
>    smaller machines when 1TB segments are disabled.
>    
>    To hit this, you also need to be virtualised to ensure SLBs are
>    periodically removed by the hypervisor.
>    
>    This patches moves the saving of r1 to the SPRG to the region where we
>    are guaranteed not to take any further SLB misses.
>    
>    Fixes: 98ae22e15b43 ("powerpc: Add helper functions for transactional memory context switching")
>    Cc: stable@vger.kernel.org # v3.9+
>    Signed-off-by: Michael Neuling <mikey@neuling.org>
>    Acked-by: Cyril Bur <cyrilbur@gmail.com>
>    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 572c8b69051d58586accd392fc2699b84a1ae326
>Author: Michael Neuling <mikey@neuling.org>
>Date:   Tue Jun 28 13:01:04 2016 +1000
>
>    powerpc/tm: Avoid SLB faults in treclaim/trecheckpoint when RI=0
>    
>    [ Upstream commit 190ce8693c23eae09ba5f303a83bf2fbeb6478b1 ]
>    
>    Currently we have 2 segments that are bolted for the kernel linear
>    mapping (ie 0xc000... addresses). This is 0 to 1TB and also the kernel
>    stacks. Anything accessed outside of these regions may need to be
>    faulted in. (In practice machines with TM always have 1T segments)
>    
>    If a machine has < 2TB of memory we never fault on the kernel linear
>    mapping as these two segments cover all physical memory. If a machine
>    has > 2TB of memory, there may be structures outside of these two
>    segments that need to be faulted in. This faulting can occur when
>    running as a guest as the hypervisor may remove any SLB that's not
>    bolted.
>    
>    When we treclaim and trecheckpoint we have a window where we need to
>    run with the userspace GPRs. This means that we no longer have a valid
>    stack pointer in r1. For this window we therefore clear MSR RI to
>    indicate that any exceptions taken at this point won't be able to be
>    handled. This means that we can't take segment misses in this RI=0
>    window.
>    
>    In this RI=0 region, we currently access the thread_struct for the
>    process being context switched to or from. This thread_struct access
>    may cause a segment fault since it's not guaranteed to be covered by
>    the two bolted segment entries described above.
>    
>    We've seen this with a crash when running as a guest with > 2TB of
>    memory on PowerVM:
>    
>      Unrecoverable exception 4100 at c00000000004f138
>      Oops: Unrecoverable exception, sig: 6 [#1]
>      SMP NR_CPUS=2048 NUMA pSeries
>      CPU: 1280 PID: 7755 Comm: kworker/1280:1 Tainted: G                 X 4.4.13-46-default #1
>      task: c000189001df4210 ti: c000189001d5c000 task.ti: c000189001d5c000
>      NIP: c00000000004f138 LR: 0000000010003a24 CTR: 0000000010001b20
>      REGS: c000189001d5f730 TRAP: 4100   Tainted: G                 X  (4.4.13-46-default)
>      MSR: 8000000100001031 <SF,ME,IR,DR,LE>  CR: 24000048  XER: 00000000
>      CFAR: c00000000004ed18 SOFTE: 0
>      GPR00: ffffffffc58d7b60 c000189001d5f9b0 00000000100d7d00 000000003a738288
>      GPR04: 0000000000002781 0000000000000006 0000000000000000 c0000d1f4d889620
>      GPR08: 000000000000c350 00000000000008ab 00000000000008ab 00000000100d7af0
>      GPR12: 00000000100d7ae8 00003ffe787e67a0 0000000000000000 0000000000000211
>      GPR16: 0000000010001b20 0000000000000000 0000000000800000 00003ffe787df110
>      GPR20: 0000000000000001 00000000100d1e10 0000000000000000 00003ffe787df050
>      GPR24: 0000000000000003 0000000000010000 0000000000000000 00003fffe79e2e30
>      GPR28: 00003fffe79e2e68 00000000003d0f00 00003ffe787e67a0 00003ffe787de680
>      NIP [c00000000004f138] restore_gprs+0xd0/0x16c
>      LR [0000000010003a24] 0x10003a24
>      Call Trace:
>      [c000189001d5f9b0] [c000189001d5f9f0] 0xc000189001d5f9f0 (unreliable)
>      [c000189001d5fb90] [c00000000001583c] tm_recheckpoint+0x6c/0xa0
>      [c000189001d5fbd0] [c000000000015c40] __switch_to+0x2c0/0x350
>      [c000189001d5fc30] [c0000000007e647c] __schedule+0x32c/0x9c0
>      [c000189001d5fcb0] [c0000000007e6b58] schedule+0x48/0xc0
>      [c000189001d5fce0] [c0000000000deabc] worker_thread+0x22c/0x5b0
>      [c000189001d5fd80] [c0000000000e7000] kthread+0x110/0x130
>      [c000189001d5fe30] [c000000000009538] ret_from_kernel_thread+0x5c/0xa4
>      Instruction dump:
>      7cb103a6 7cc0e3a6 7ca222a6 78a58402 38c00800 7cc62838 08860000 7cc000a6
>      38a00006 78c60022 7cc62838 0b060000 <e8c701a0> 7ccff120 e8270078 e8a70098
>      ---[ end trace 602126d0a1dedd54 ]---
>    
>    This fixes this by copying the required data from the thread_struct to
>    the stack before we clear MSR RI. Then once we clear RI, we only access
>    the stack, guaranteeing there's no segment miss.
>    
>    We also tighten the region over which we set RI=0 on the treclaim()
>    path. This may have a slight performance impact since we're adding an
>    mtmsr instruction.
>    
>    Fixes: 090b9284d725 ("powerpc/tm: Clear MSR RI in non-recoverable TM code")
>    Signed-off-by: Michael Neuling <mikey@neuling.org>
>    Reviewed-by: Cyril Bur <cyrilbur@gmail.com>
>    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 881052c264a9a44481f1a29d4877478e54b4c690
>Author: Vegard Nossum <vegard.nossum@oracle.com>
>Date:   Thu Jul 14 23:21:35 2016 -0400
>
>    ext4: short-cut orphan cleanup on error
>    
>    [ Upstream commit c65d5c6c81a1f27dec5f627f67840726fcd146de ]
>    
>    If we encounter a filesystem error during orphan cleanup, we should stop.
>    Otherwise, we may end up in an infinite loop where the same inode is
>    processed again and again.
>    
>        EXT4-fs (loop0): warning: checktime reached, running e2fsck is recommended
>        EXT4-fs error (device loop0): ext4_mb_generate_buddy:758: group 2, block bitmap and bg descriptor inconsistent: 6117 vs 0 free clusters
>        Aborting journal on device loop0-8.
>        EXT4-fs (loop0): Remounting filesystem read-only
>        EXT4-fs error (device loop0) in ext4_free_blocks:4895: Journal has aborted
>        EXT4-fs error (device loop0) in ext4_do_update_inode:4893: Journal has aborted
>        EXT4-fs error (device loop0) in ext4_do_update_inode:4893: Journal has aborted
>        EXT4-fs error (device loop0) in ext4_ext_remove_space:3068: IO failure
>        EXT4-fs error (device loop0) in ext4_ext_truncate:4667: Journal has aborted
>        EXT4-fs error (device loop0) in ext4_orphan_del:2927: Journal has aborted
>        EXT4-fs error (device loop0) in ext4_do_update_inode:4893: Journal has aborted
>        EXT4-fs (loop0): Inode 16 (00000000618192a0): orphan list check failed!
>        [...]
>        EXT4-fs (loop0): Inode 16 (0000000061819748): orphan list check failed!
>        [...]
>        EXT4-fs (loop0): Inode 16 (0000000061819bf0): orphan list check failed!
>        [...]
>    
>    See-also: c9eb13a9105 ("ext4: fix hang when processing corrupted orphaned inode list")
>    Cc: Jan Kara <jack@suse.cz>
>    Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
>    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 3f7ed29b1299823a4460c7cf4bdebfe13db23bf9
>Author: Alex Deucher <alexander.deucher@amd.com>
>Date:   Fri Jul 8 17:27:04 2016 -0400
>
>    drm/radeon: support backlight control for UNIPHY3
>    
>    [ Upstream commit d3200be6c423afa1c34f7e39e9f6d04dd5b0af9d ]
>    
>    Same interface as other UNIPHY blocks
>    
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 6c2ca21665b99ce2f76389c353b985d8195387cc
>Author: Jim Mattson <jmattson@google.com>
>Date:   Fri Jul 8 15:36:06 2016 -0700
>
>    KVM: nVMX: Fix memory corruption when using VMCS shadowing
>    
>    [ Upstream commit 2f1fe81123f59271bddda673b60116bde9660385 ]
>    
>    When freeing the nested resources of a vcpu, there is an assumption that
>    the vcpu's vmcs01 is the current VMCS on the CPU that executes
>    nested_release_vmcs12(). If this assumption is violated, the vcpu's
>    vmcs01 may be made active on multiple CPUs at the same time, in
>    violation of Intel's specification. Moreover, since the vcpu's vmcs01 is
>    not VMCLEARed on every CPU on which it is active, it can linger in a
>    CPU's VMCS cache after it has been freed and potentially
>    repurposed. Subsequent eviction from the CPU's VMCS cache on a capacity
>    miss can result in memory corruption.
>    
>    It is not sufficient for vmx_free_vcpu() to call vmx_load_vmcs01(). If
>    the vcpu in question was last loaded on a different CPU, it must be
>    migrated to the current CPU before calling vmx_load_vmcs01().
>    
>    Signed-off-by: Jim Mattson <jmattson@google.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 53bb06cb222c5f03eacec544564e3751f7564fe9
>Author: Joseph Salisbury <joseph.salisbury@canonical.com>
>Date:   Wed Jul 6 21:18:51 2016 -0400
>
>    usb: quirks: Add no-lpm quirk for Elan
>    
>    [ Upstream commit 25b1f9acc452209ae0fcc8c1332be852b5c52f53 ]
>    
>    BugLink: http://bugs.launchpad.net/bugs/1498667
>    
>    As reported in BugLink, this device has an issue with Linux Power
>    Management so adding a quirk.  This quirk was reccomended by Alan Stern:
>    
>    http://lkml.iu.edu/hypermail/linux/kernel/1606.2/05590.html
>    
>    Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit bd0702ff1a33c5fd28844c57e5812e039ea168d6
>Author: Adrien VergÃ© <adrienverge@gmail.com>
>Date:   Tue Nov 24 16:02:04 2015 +0100
>
>    USB: quirks: Fix another ELAN touchscreen
>    
>    [ Upstream commit df36c5bede207f734e4750beb2b14fb892050280 ]
>    
>    Like other buggy models that had their fixes [1], the touchscreen with
>    id 04f3:21b8 from ELAN Microelectronics needs the device-qualifier
>    quirk. Otherwise, it fails to respond, blocks the boot for a random
>    amount of time and pollutes dmesg with:
>    
>    [ 2887.373196] usb 1-5: new full-speed USB device number 41 using xhci_hcd
>    [ 2889.502000] usb 1-5: unable to read config index 0 descriptor/start: -71
>    [ 2889.502005] usb 1-5: can't read configurations, error -71
>    [ 2889.654571] usb 1-5: new full-speed USB device number 42 using xhci_hcd
>    [ 2891.783438] usb 1-5: unable to read config index 0 descriptor/start: -71
>    [ 2891.783443] usb 1-5: can't read configurations, error -71
>    
>    [1]: See commits c68929f, 876af5d, d749947, a32c99e and dc703ec.
>    
>    Tested-by: Adrien VergÃ© <adrienverge@gmail.com>
>    Signed-off-by: Adrien VergÃ© <adrienverge@gmail.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 256679c2a67b4ec06c207bb8bfa9e9f64f482ed8
>Author: Sasha Levin <alexander.levin@verizon.com>
>Date:   Sun Aug 14 18:23:56 2016 -0400
>
>    s390/mm: fix gmap tlb flush issues
>    
>    [ Upstream commit f045402984404ddc11016358411e445192919047 ]
>    
>    __tlb_flush_asce() should never be used if multiple asce belong to a mm.
>    
>    As this function changes mm logic determining if local or global tlb
>    flushes will be neded, we might end up flushing only the gmap asce on all
>    CPUs and a follow up mm asce flushes will only flush on the local CPU,
>    although that asce ran on multiple CPUs.
>    
>    The missing tlb flushes will provoke strange faults in user space and even
>    low address protections in user space, crashing the kernel.
>    
>    Fixes: 1b948d6caec4 ("s390/mm,tlb: optimize TLB flushing for zEC12")
>    Cc: stable@vger.kernel.org # 3.15+
>    Reported-by: Sascha Silbe <silbe@linux.vnet.ibm.com>
>    Acked-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
>    Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
>    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 9b01eafbc9514e71056e0a1a4714606385a431a4
>Author: Sachin Prabhu <sprabhu@redhat.com>
>Date:   Thu Jul 7 21:28:27 2016 +0100
>
>    cifs: Check for existing directory when opening file with O_CREAT
>    
>    [ Upstream commit 8d9535b6efd86e6c07da59f97e68f44efb7fe080 ]
>    
>    When opening a file with O_CREAT flag, check to see if the file opened
>    is an existing directory.
>    
>    This prevents the directory from being opened which subsequently causes
>    a crash when the close function for directories cifs_closedir() is called
>    which frees up the file->private_data memory while the file is still
>    listed on the open file list for the tcon.
>    
>    Signed-off-by: Sachin Prabhu <sprabhu@redhat.com>
>    Signed-off-by: Steve French <smfrench@gmail.com>
>    CC: Stable <stable@vger.kernel.org>
>    Reported-by: Xiaoli Feng <xifeng@redhat.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit bdf3214616dd38384c9716ce96a18b779e233224
>Author: Matthew Leach <matthew@mattleach.net>
>Date:   Fri Jul 8 09:04:27 2016 -0300
>
>    [media] media: usbtv: prevent access to free'd resources
>    
>    [ Upstream commit 2a00932f082aff93c3a55426e0c7af6d0ec03997 ]
>    
>    When disconnecting the usbtv device, the sound card is unregistered
>    from ALSA and the snd member of the usbtv struct is set to NULL.  If
>    the usbtv snd_trigger work is running, this can cause a race condition
>    where the kernel will attempt to access free'd resources, shown in
>    [1].
>    
>    This patch fixes the disconnection code by cancelling any snd_trigger
>    work before unregistering the sound card from ALSA and checking that
>    the snd member still exists in the work function.
>    
>    [1]:
>     usb 3-1.2: USB disconnect, device number 6
>     BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
>     IP: [<ffffffff81093850>] process_one_work+0x30/0x480
>     PGD 405bbf067 PUD 405bbe067 PMD 0
>     Call Trace:
>      [<ffffffff81093ce8>] worker_thread+0x48/0x4e0
>      [<ffffffff81093ca0>] ? process_one_work+0x480/0x480
>      [<ffffffff81093ca0>] ? process_one_work+0x480/0x480
>      [<ffffffff81099998>] kthread+0xd8/0xf0
>      [<ffffffff815c73c2>] ret_from_fork+0x22/0x40
>      [<ffffffff810998c0>] ? kthread_worker_fn+0x170/0x170
>     ---[ end trace 0f3dac5c1a38e610 ]---
>    
>    Signed-off-by: Matthew Leach <matthew@mattleach.net>
>    Tested-by: Peter Sutton <foxxy@foxdogstudios.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
>    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 47c1628a3d5ea9803b4175ad8eb0b0f577f16e49
>Author: Dmitry Tunin <hanipouspilot@gmail.com>
>Date:   Tue Jul 12 01:35:18 2016 +0300
>
>    Bluetooth: Add support of 13d3:3490 AR3012 device
>    
>    [ Upstream commit 12d868964f7352e8b18e755488f7265a93431de1 ]
>    
>    T: Bus=01 Lev=01 Prnt=01 Port=07 Cnt=05 Dev#= 5 Spd=12 MxCh= 0
>    D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
>    P: Vendor=13d3 ProdID=3490 Rev=00.01
>    C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
>    I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
>    I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
>    
>    BugLink: https://bugs.launchpad.net/bugs/1600623
>    
>    Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
>    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 6e2c93c757ece77b43eb12f21c0ab2b985dbbfb4
>Author: Lauro Costa <lauro@polilinux.com.br>
>Date:   Mon May 9 17:36:11 2016 -0300
>
>    Bluetooth: Add USB ID 13D3:3487 to ath3k
>    
>    [ Upstream commit 72f9f8b58bc743e6b6abdc68f60db98486c3ffcf ]
>    
>    Add hw id to ath3k usb device list and btusb blacklist
>    
>    T:  Bus=01 Lev=01 Prnt=01 Port=08 Cnt=02 Dev#=  4 Spd=12  MxCh= 0
>    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
>    P:  Vendor=13d3 ProdID=3487 Rev=00.02
>    C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
>    I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
>    I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
>    
>    Requires these firmwares:
>    ar3k/AthrBT_0x11020100.dfu and ar3k/ramps_0x11020100_40.dfu
>    Firmwares are available in linux-firmware.
>    
>    Device found in a laptop ASUS model N552VW. It's an Atheros AR9462 chip.
>    
>    Signed-off-by: Lauro Costa <lauro@polilinux.com.br>
>    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 434d638db34386cdf03fb808dbc15e7966ad0745
>Author: Jonathan McDowell <noodles@earth.li>
>Date:   Sat May 14 14:01:26 2016 -0300
>
>    [media] Fix RC5 decoding with Fintek CIR chipset
>    
>    [ Upstream commit bbdb34c90aeb8b2253eae88029788ebe1d7f2fd4 ]
>    
>    Fix RC5 decoding with Fintek CIR chipset
>    
>    Commit e87b540be2dd02552fb9244d50ae8b4e4619a34b tightened up the RC5
>    decoding by adding a check for trailing silence to ensure a valid RC5
>    command had been received. Unfortunately the trailer length checked was
>    10 units and the Fintek CIR device does not want to provide details of a
>    space longer than 6350us. This meant that RC5 remotes working on a
>    Fintek setup on 3.16 failed on 3.17 and later. Fix this by shortening
>    the trailer check to 6 units (allowing for a previous space in the
>    received remote command).
>    
>    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=117221
>    
>    Signed-off-by: Jonathan McDowell <noodles@earth.li>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: David HÃ¤rdeman <david@hardeman.nu>
>    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 2342f6e61999e3ae252b42b617829eaa2d217cf2
>Author: Soeren Moch <smoch@web.de>
>Date:   Wed May 11 13:49:11 2016 -0300
>
>    [media] media: dvb_ringbuffer: Add memory barriers
>    
>    [ Upstream commit ca6e6126db5494f18c6c6615060d4d803b528bff ]
>    
>    Implement memory barriers according to Documentation/circular-buffers.txt:
>    - use smp_store_release() to update ringbuffer read/write pointers
>    - use smp_load_acquire() to load write pointer on reader side
>    - use ACCESS_ONCE() to load read pointer on writer side
>    
>    This fixes data stream corruptions observed e.g. on an ARM Cortex-A9
>    quad core system with different types (PCI, USB) of DVB tuners.
>    
>    Signed-off-by: Soeren Moch <smoch@web.de>
>    Cc: stable@vger.kernel.org # 3.14+
>    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 7235df953569546d2bab7c335635c13939ea6506
>Author: Lyude <cpaul@redhat.com>
>Date:   Fri Jun 24 17:54:31 2016 -0400
>
>    drm/radeon: Poll for both connect/disconnect on analog connectors
>    
>    [ Upstream commit 14ff8d48f2235295dfb3117693008e367b49cdb5 ]
>    
>    DRM_CONNECTOR_POLL_CONNECT only enables polling for connections, not
>    disconnections. Because of this, we end up losing hotplug polling for
>    analog connectors once they get connected.
>    
>    Easy way to reproduce:
>     - Grab a machine with a radeon GPU and a VGA port
>     - Plug a monitor into the VGA port, wait for it to update the connector
>       from disconnected to connected
>     - Disconnect the monitor on VGA, a hotplug event is never sent for the
>       removal of the connector.
>    
>    Originally, only using DRM_CONNECTOR_POLL_CONNECT might have been a good
>    idea since doing VGA polling can sometimes result in having to mess with
>    the DAC voltages to figure out whether or not there's actually something
>    there since VGA doesn't have HPD. Doing this would have the potential of
>    showing visible artifacts on the screen every time we ran a poll while a
>    VGA display was connected. Luckily, radeon_vga_detect() only resorts to
>    this sort of polling if the poll is forced, and DRM's polling helper
>    doesn't force it's polls.
>    
>    Additionally, this removes some assignments to connector->polled that
>    weren't actually doing anything.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Lyude <cpaul@redhat.com>
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 4613d5f66ff3b7914d7ae2e2e12ab097038772a6
>Author: Alex Deucher <alexander.deucher@amd.com>
>Date:   Wed Jun 1 12:58:36 2016 -0400
>
>    drm/radeon: add a delay after ATPX dGPU power off
>    
>    [ Upstream commit d814b24fb74cb9797d70cb8053961447c5879a5c ]
>    
>    ATPX dGPU power control requires a 200ms delay between
>    power off and on.  This should fix dGPU failures on
>    resume from power off.
>    
>    Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
>    Acked-by: Christian KÃ¶nig <christian.koenig@amd.com>
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 073435ae84da04fa8e3d27f740095382a950458d
>Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>Date:   Wed Jul 6 12:08:11 2016 +0300
>
>    spi: pxa2xx: Clear all RFT bits in reset_sccr1() on Intel Quark
>    
>    [ Upstream commit 152bc19e2fc2b7fce7ffbc2a9cea94b147223702 ]
>    
>    It seems the commit e5262d0568dc ("spi: spi-pxa2xx: SPI support for Intel Quark
>    X1000") misses one place to be adapted for Intel Quark, i.e. in reset_sccr1().
>    
>    Clear all RFT bits when call reset_sccr1() on Intel Quark.
>    
>    Fixes: e5262d0568dc ("spi: spi-pxa2xx: SPI support for Intel Quark X1000")
>    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>    Signed-off-by: Mark Brown <broonie@kernel.org>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit d4d783d829cd3ade06c6b39fd7d02f00026ba699
>Author: Theodore Ts'o <tytso@mit.edu>
>Date:   Tue Jul 5 20:01:52 2016 -0400
>
>    ext4: validate s_reserved_gdt_blocks on mount
>    
>    [ Upstream commit 5b9554dc5bf008ae7f68a52e3d7e76c0920938a2 ]
>    
>    If s_reserved_gdt_blocks is extremely large, it's possible for
>    ext4_init_block_bitmap(), which is called when ext4 sets up an
>    uninitialized block bitmap, to corrupt random kernel memory.  Add the
>    same checks which e2fsck has --- it must never be larger than
>    blocksize / sizeof(__u32) --- and then add a backup check in
>    ext4_init_block_bitmap() in case the superblock gets modified after
>    the file system is mounted.
>    
>    Reported-by: Vegard Nossum <vegard.nossum@oracle.com>
>    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit d579705ef92535db645c8eeac510f26bbc9a7e9d
>Author: Sasha Levin <alexander.levin@verizon.com>
>Date:   Sun Aug 14 18:08:43 2016 -0400
>
>    iwlwifi: add new 8260 PCI IDs
>    
>    [ Upstream commit 4b79deece5d45396422d469afa11f9d69ccb3d8b ]
>    
>    Add 3 new 8260 series PCI IDs:
>      - (0x24F3, 0x10B0)
>      - (0x24F3, 0xD0B0)
>      - (0x24F3, 0xB0B0)
>    
>    CC: <stable@vger.kernel.org> [4.1+]
>    Signed-off-by: Oren Givon <oren.givon@intel.com>
>    Signed-off-by: David Spinadel <david.spinadel@intel.com>
>    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 2fc0cdf6e9a858c5bf3a1f23a7b673fbf9a3abf4
>Author: Hans de Goede <hdegoede@redhat.com>
>Date:   Sat Jun 4 12:58:39 2016 +0200
>
>    ARM: dts: sunxi: Add a startup delay for fixed regulator enabled phys
>    
>    [ Upstream commit fc51b632c7b047c25807023b76f3877aed19c770 ]
>    
>    It seems that recent kernels have a shorter timeout when scanning for
>    ethernet phys causing us to hit a timeout on boards where the phy's
>    regulator gets enabled just before scanning, which leads to non working
>    ethernet.
>    
>    A 10ms startup delay seems to be enough to fix it, this commit adds a
>    20ms startup delay just to be safe.
>    
>    This has been tested on a sun4i-a10-a1000 and sun5i-a10s-wobo-i5 board,
>    both of which have non-working ethernet on recent kernels without this
>    fix.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>    Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit e19f0ec5aeb659cb7dd2bf6e4f1e842f5ad71fcf
>Author: Vegard Nossum <vegard.nossum@oracle.com>
>Date:   Mon Jul 4 11:03:00 2016 -0400
>
>    ext4: don't call ext4_should_journal_data() on the journal inode
>    
>    [ Upstream commit 6a7fd522a7c94cdef0a3b08acf8e6702056e635c ]
>    
>    If ext4_fill_super() fails early, it's possible for ext4_evict_inode()
>    to call ext4_should_journal_data() before superblock options and flags
>    are fully set up.  In that case, the iput() on the journal inode can
>    end up causing a BUG().
>    
>    Work around this problem by reordering the tests so we only call
>    ext4_should_journal_data() after we know it's not the journal inode.
>    
>    Fixes: 2d859db3e4 ("ext4: fix data corruption in inodes with journalled data")
>    Fixes: 2b405bfa84 ("ext4: fix data=journal fast mount/umount hang")
>    Cc: Jan Kara <jack@suse.cz>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
>    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
>    Reviewed-by: Jan Kara <jack@suse.cz>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 906d6f4d9cdc8509c505f29f6146ec627fef2f06
>Author: Jan Kara <jack@suse.cz>
>Date:   Mon Jul 4 10:14:01 2016 -0400
>
>    ext4: fix deadlock during page writeback
>    
>    [ Upstream commit 646caa9c8e196880b41cd3e3d33a2ebc752bdb85 ]
>    
>    Commit 06bd3c36a733 (ext4: fix data exposure after a crash) uncovered a
>    deadlock in ext4_writepages() which was previously much harder to hit.
>    After this commit xfstest generic/130 reproduces the deadlock on small
>    filesystems.
>    
>    The problem happens when ext4_do_update_inode() sets LARGE_FILE feature
>    and marks current inode handle as synchronous. That subsequently results
>    in ext4_journal_stop() called from ext4_writepages() to block waiting for
>    transaction commit while still holding page locks, reference to io_end,
>    and some prepared bio in mpd structure each of which can possibly block
>    transaction commit from completing and thus results in deadlock.
>    
>    Fix the problem by releasing page locks, io_end reference, and
>    submitting prepared bio before calling ext4_journal_stop().
>    
>    [ Changed to defer the call to ext4_journal_stop() only if the handle
>      is synchronous.  --tytso ]
>    
>    Reported-and-tested-by: Eryu Guan <eguan@redhat.com>
>    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
>    CC: stable@vger.kernel.org
>    Signed-off-by: Jan Kara <jack@suse.cz>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 547df96580692f69627c693cc1d1fe1ea99d652c
>Author: Trond Myklebust <trond.myklebust@primarydata.com>
>Date:   Fri Jun 24 10:55:44 2016 -0400
>
>    SUNRPC: Don't allocate a full sockaddr_storage for tracing
>    
>    [ Upstream commit db1bb44c4c7e8d49ed674dc59e5222d99c698088 ]
>    
>    We're always tracing IPv4 or IPv6 addresses, so we can save a lot
>    of space on the ringbuffer by allocating the correct sockaddr size.
>    
>    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
>    Cc: stable@vger.kernel.org
>    Fixes: 83a712e0afef "sunrpc: add some tracepoints around ..."
>    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit c580d82e1d5532b785e339450d43f82e5a8b4e79
>Author: Vegard Nossum <vegard.nossum@oracle.com>
>Date:   Thu Jun 30 11:53:46 2016 -0400
>
>    ext4: check for extents that wrap around
>    
>    [ Upstream commit f70749ca42943faa4d4dcce46dfdcaadb1d0c4b6 ]
>    
>    An extent with lblock = 4294967295 and len = 1 will pass the
>    ext4_valid_extent() test:
>    
>    	ext4_lblk_t last = lblock + len - 1;
>    
>    	if (len == 0 || lblock > last)
>    		return 0;
>    
>    since last = 4294967295 + 1 - 1 = 4294967295. This would later trigger
>    the BUG_ON(es->es_lblk + es->es_len < es->es_lblk) in ext4_es_end().
>    
>    We can simplify it by removing the - 1 altogether and changing the test
>    to use lblock + len <= lblock, since now if len = 0, then lblock + 0 ==
>    lblock and it fails, and if len > 0 then lblock + len > lblock in order
>    to pass (i.e. it doesn't overflow).
>    
>    Fixes: 5946d0893 ("ext4: check for overlapping extents in ext4_valid_extent_entries()")
>    Fixes: 2f974865f ("ext4: check for zero length extent explicitly")
>    Cc: Eryu Guan <guaneryu@gmail.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Phil Turnbull <phil.turnbull@oracle.com>
>    Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
>    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 988777b0ed921cbe607b1bf6d45434a39c07106e
>Author: Linus Walleij <linus.walleij@linaro.org>
>Date:   Wed Jun 22 08:27:17 2016 +0200
>
>    mfd: qcom_rpm: Parametrize also ack selector size
>    
>    [ Upstream commit f37be01e6dc606f2fcc5e95c9933d948ce19bd35 ]
>    
>    The RPM has two sets of selectors (IPC bit fields): request and
>    acknowledge. Apparently, some models use 4*32 bit words for select
>    and some use 7*32 bit words for request, but all use 7*32 words
>    for acknowledge bits.
>    
>    So apparently you can on the models with requests of 4*32 select
>    bits send 4*32 messages and get 7*32 different replies, so on ACK
>    interrupt, 7*32 bit words need to be read. This is how the vendor
>    code apparently works.
>    
>    Cc: stable@vger.kernel.org
>    Reported-by: Stephen Boyd <sboyd@codeaurora.org>
>    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>    Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>    Signed-off-by: Lee Jones <lee.jones@linaro.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit e6b04eb12d323bcea82654c90fbece3bf17dd2f1
>Author: Linus Walleij <linus.walleij@linaro.org>
>Date:   Wed Jun 15 01:02:26 2016 +0200
>
>    mfd: qcom_rpm: Fix offset error for msm8660
>    
>    [ Upstream commit 9835f1b70bb3890d38308b9be4fb9d7451ba67f1 ]
>    
>    The RPM in MSM8660/APQ8060 has different offsets to the selector
>    ACK and request context ACK registers. Make all these register
>    offsets part of the per-SoC data and assign the right values.
>    
>    The bug was found by verifying backwards to the vendor tree in
>    the out-of-tree files <mach/rpm-[8660|8064|8960]>: all were using
>    offsets 3,11,15,23 and a select size of 4, except the MSM8660/APQ8060
>    which was using offsets 3,11,19,27 and a select size of 7.
>    
>    All other platforms apart from msm8660 were affected by reading
>    excess registers, since 7 was hardcoded as the number of select
>    words, this patch makes also this part dynamic so we only write/read
>    as many select words as the platform actually use.
>    
>    Symptoms of this bug when using msm8660: the first RPM transaction
>    would work, but the next would stall or raise an error since the
>    previous transaction was not properly ACKed as the ACK words were
>    read at the wrong offset.
>    
>    Cc: stable@vger.kernel.org
>    Fixes: 58e214382bdd ("mfd: qcom-rpm: Driver for the Qualcomm RPM")
>    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>    Reviewed-by: BjÃ¶rn Andersson <bjorn.andersson@linaro.org>
>    Signed-off-by: Lee Jones <lee.jones@linaro.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 6997496351500fd6fb92f11e89e5024d8bd3f55e
>Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>Date:   Wed Jun 8 16:32:50 2016 +0900
>
>    usb: renesas_usbhs: protect the CFIFOSEL setting in usbhsg_ep_enable()
>    
>    [ Upstream commit 15e4292a2d21e9997fdb2b8c014cc461b3f268f0 ]
>    
>    This patch fixes an issue that the CFIFOSEL register value is possible
>    to be changed by usbhsg_ep_enable() wrongly. And then, a data transfer
>    using CFIFO may not work correctly.
>    
>    For example:
>     # modprobe g_multi file=usb-storage.bin
>     # ifconfig usb0 192.168.1.1 up
>     (During the USB host is sending file to the mass storage)
>     # ifconfig usb0 down
>    
>    In this case, since the u_ether.c may call usb_ep_enable() in
>    eth_stop(), if the renesas_usbhs driver is also using CFIFO for
>    mass storage, the mass storage may not work correctly.
>    
>    So, this patch adds usbhs_lock() and usbhs_unlock() calling in
>    usbhsg_ep_enable() to protect CFIFOSEL register. This is because:
>     - CFIFOSEL.CURPIPE = 0 is also needed for the pipe configuration
>     - The CFIFOSEL (fifo->sel) is already protected by usbhs_lock()
>    
>    Fixes: 97664a207bc2 ("usb: renesas_usbhs: shrink spin lock area")
>    Cc: <stable@vger.kernel.org> # v3.1+
>    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 83335cb773c6ee89b8517bf7c16e4c299a1c80f2
>Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>Date:   Wed Jun 8 16:32:49 2016 +0900
>
>    usb: renesas_usbhs: fix NULL pointer dereference in xfer_work()
>    
>    [ Upstream commit 4fdef698383db07d829da567e0e405fc41ff3a89 ]
>    
>    This patch fixes an issue that the xfer_work() is possible to cause
>    NULL pointer dereference if the usb cable is disconnected while data
>    transfer is running.
>    
>    In such case, a gadget driver may call usb_ep_disable()) before
>    xfer_work() is actually called. In this case, the usbhs_pkt_pop()
>    will call usbhsf_fifo_unselect(), and then usbhs_pipe_to_fifo()
>    in xfer_work() will return NULL.
>    
>    Fixes: e73a989 ("usb: renesas_usbhs: add DMAEngine support")
>    Cc: <stable@vger.kernel.org> # v3.1+
>    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 542330f7026d82c35314b59f52b0ec79eca2d822
>Author: Alex Hung <alex.hung@canonical.com>
>Date:   Mon Jun 13 19:44:00 2016 +0800
>
>    hp-wmi: Fix wifi cannot be hard-unblocked
>    
>    [ Upstream commit fc8a601e1175ae351f662506030f9939cb7fdbfe ]
>    
>    Several users reported wifi cannot be unblocked as discussed in [1].
>    This patch removes the use of the 2009 flag by BIOS but uses the actual
>    WMI function calls - it will be skipped if WMI reports unsupported.
>    
>    [1] https://bugzilla.kernel.org/show_bug.cgi?id=69131
>    
>    Signed-off-by: Alex Hung <alex.hung@canonical.com>
>    Tested-by: Evgenii Shatokhin <eugene.shatokhin@yandex.ru>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Darren Hart <dvhart@linux.intel.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 230dc3e923b42c95a113a7bb72e8854e16256a54
>Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>Date:   Thu Jun 16 08:27:35 2016 +0200
>
>    serial: samsung: Fix ERR pointer dereference on deferred probe
>    
>    [ Upstream commit e51e4d8a185de90424b03f30181b35f29c46a25a ]
>    
>    When the clk_get() of "uart" clock returns EPROBE_DEFER, the next re-probe
>    finishes with success but uses invalid (ERR_PTR) values.  This leads to
>    dereferencing of ERR_PTR stored under ourport->clk:
>    
>    	12c30000.serial: Controller clock not found
>    	(...)
>    	12c30000.serial: ttySAC3 at MMIO 0x12c30000 (irq = 61, base_baud = 0) is a S3C6400/10
>    	Unable to handle kernel paging request at virtual address fffffdfb
>    
>    	(clk_prepare) from [<c039f7d0>] (s3c24xx_serial_pm+0x20/0x128)
>    	(s3c24xx_serial_pm) from [<c0395414>] (uart_change_pm+0x38/0x40)
>    	(uart_change_pm) from [<c039689c>] (uart_add_one_port+0x31c/0x44c)
>    	(uart_add_one_port) from [<c03a035c>] (s3c24xx_serial_probe+0x2a8/0x418)
>    	(s3c24xx_serial_probe) from [<c03ee110>] (platform_drv_probe+0x50/0xb0)
>    	(platform_drv_probe) from [<c03ecb44>] (driver_probe_device+0x1f4/0x2b0)
>    	(driver_probe_device) from [<c03eb0c0>] (bus_for_each_drv+0x44/0x8c)
>    	(bus_for_each_drv) from [<c03ec8c8>] (__device_attach+0x9c/0x100)
>    	(__device_attach) from [<c03ebf54>] (bus_probe_device+0x84/0x8c)
>    	(bus_probe_device) from [<c03ec388>] (deferred_probe_work_func+0x60/0x8c)
>    	(deferred_probe_work_func) from [<c012fee4>] (process_one_work+0x120/0x328)
>    	(process_one_work) from [<c0130150>] (worker_thread+0x2c/0x4ac)
>    	(worker_thread) from [<c0135320>] (kthread+0xd8/0xf4)
>    	(kthread) from [<c0107978>] (ret_from_fork+0x14/0x3c)
>    
>    The first unsuccessful clk_get() causes s3c24xx_serial_init_port() to
>    exit with failure but the s3c24xx_uart_port is left half-configured
>    (e.g. port->mapbase is set, clk contains ERR_PTR).  On next re-probe,
>    the function s3c24xx_serial_init_port() will exit early with success
>    because of configured port->mapbase and driver will use old values,
>    including the ERR_PTR as clock.
>    
>    Fix this by cleaning the port->mapbase on error path so each re-probe
>    will initialize all of the port settings.
>    
>    Fixes: 60e93575476f ("serial: samsung: enable clock before clearing pending interrupts during init")
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>    Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
>    Tested-by: Javier Martinez Canillas <javier@osg.samsung.com>
>    Tested-by: Kevin Hilman <khilman@baylibre.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit cf61375fb14bbd7734c42df8a03e4efae6419583
>Author: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>Date:   Sat May 28 00:54:08 2016 +0200
>
>    tty/serial: atmel: fix RS485 half duplex with DMA
>    
>    [ Upstream commit 0058f0871efe7b01c6f2b3046c68196ab73e96da ]
>    
>    When using DMA, half duplex doesn't work properly because rx is not stopped
>    before starting tx. Ensure we call atmel_stop_rx() in the DMA case.
>    
>    Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>    Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit ebe139836e17beea5f6742f7c6e11a7cd9d053de
>Author: Cyrille Pitchen <cyrille.pitchen@atmel.com>
>Date:   Thu Jul 2 15:18:11 2015 +0200
>
>    tty/serial: at91: remove bunch of macros to access UART registers
>    
>    [ Upstream commit 4e7decdaaa67b287d6a13de8dedced68f1d7d716 ]
>    
>    This patch replaces the UART_PUT_*, resp. UART_GET_*, macros by
>    atmel_uart_writel(), resp. atmel_uart_readl(), inline function calls.
>    
>    Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 343c4efc3864c72b99669f6b214f145712202167
>Author: Frank Rowand <frank.rowand@am.sony.com>
>Date:   Thu Jun 16 10:51:46 2016 -0700
>
>    of: fix memory leak related to safe_name()
>    
>    [ Upstream commit d9fc880723321dbf16b2981e3f3e916b73942210 ]
>    
>    Fix a memory leak resulting from memory allocation in safe_name().
>    This patch fixes all call sites of safe_name().
>    
>    Mathieu Malaterre reported the memory leak on boot:
>    
>    On my PowerMac device-tree would generate a duplicate name:
>    
>    [    0.023043] device-tree: Duplicate name in PowerPC,G4@0, renamed to "l2-cache#1"
>    
>    in this case a newly allocated name is generated by `safe_name`. However
>    in this case it is never deallocated.
>    
>    The bug was found using kmemleak reported as:
>    
>    unreferenced object 0xdf532e60 (size 32):
>      comm "swapper", pid 1, jiffies 4294892300 (age 1993.532s)
>      hex dump (first 32 bytes):
>        6c 32 2d 63 61 63 68 65 23 31 00 dd e4 dd 1e c2  l2-cache#1......
>        ec d4 ba ce 04 ec cc de 8e 85 e9 ca c4 ec cc 9e  ................
>      backtrace:
>        [<c02d3350>] kvasprintf+0x64/0xc8
>        [<c02d3400>] kasprintf+0x4c/0x5c
>        [<c0453814>] safe_name.isra.1+0x80/0xc4
>        [<c04545d8>] __of_attach_node_sysfs+0x6c/0x11c
>        [<c075f21c>] of_core_init+0x8c/0xf8
>        [<c0729594>] kernel_init_freeable+0xd4/0x208
>        [<c00047e8>] kernel_init+0x24/0x11c
>        [<c00158ec>] ret_from_kernel_thread+0x5c/0x64
>    
>    Link: https://bugzilla.kernel.org/show_bug.cgi?id=120331
>    
>    Signed-off-by: Frank Rowand <frank.rowand@am.sony.com>
>    Reported-by: mathieu.malaterre@gmail.com
>    Tested-by: Mathieu Malaterre <mathieu.malaterre@gmail.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Rob Herring <robh@kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 843137840f140051965e0611fa95c831b5064737
>Author: Herbert Xu <herbert@gondor.apana.org.au>
>Date:   Wed Jun 15 22:27:05 2016 +0800
>
>    crypto: gcm - Filter out async ghash if necessary
>    
>    [ Upstream commit b30bdfa86431afbafe15284a3ad5ac19b49b88e3 ]
>    
>    As it is if you ask for a sync gcm you may actually end up with
>    an async one because it does not filter out async implementations
>    of ghash.
>    
>    This patch fixes this by adding the necessary filter when looking
>    for ghash.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit b42d3789eeabb4bdbe295645abc82d11b04db184
>Author: Konrad Leszczynski <konrad.leszczynski@intel.com>
>Date:   Mon Feb 8 16:13:12 2016 +0100
>
>    usb: dwc3: fix for the isoc transfer EP_BUSY flag
>    
>    [ Upstream commit 9cad39fe4e4a4fe95d8ea5a7b0692b0a6e89e38b ]
>    
>    commit f3af36511e60 ("usb: dwc3: gadget: always
>    enable IOC on bulk/interrupt transfers") ended up
>    regressing Isochronous endpoints by clearing
>    DWC3_EP_BUSY flag too early, which resulted in
>    choppy audio playback over USB.
>    
>    Fix that by partially reverting original commit and
>    making sure that we check for isochronous endpoints.
>    
>    Fixes: f3af36511e60 ("usb: dwc3: gadget: always enable IOC
>    		on bulk/interrupt transfers")
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Konrad Leszczynski <konrad.leszczynski@intel.com>
>    Signed-off-by: Rafal Redzimski <rafal.f.redzimski@intel.com>
>    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>    
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 4426cc65a19c0009761e03d44828da0508ccbcac
>Author: Dan O'Donovan <dan@emutex.com>
>Date:   Fri Jun 10 13:23:34 2016 +0100
>
>    pinctrl: cherryview: prevent concurrent access to GPIO controllers
>    
>    [ Upstream commit 0bd50d719b004110e791800450ad204399100a86 ]
>    
>    Due to a silicon issue on the Atom X5-Z8000 "Cherry Trail" processor
>    series, a common lock must be used to prevent concurrent accesses
>    across the 4 GPIO controllers managed by this driver.
>    
>    See Intel Atom Z8000 Processor Series Specification Update
>    (Rev. 005), errata #CHT34, for further information.
>    
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Dan O'Donovan <dan@emutex.com>
>    Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
>    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 40357fd7f29e7449b6bde0ec3f9cfc1f25b51123
>Author: Mika Westerberg <mika.westerberg@linux.intel.com>
>Date:   Mon Aug 17 16:13:30 2015 +0300
>
>    pinctrl: cherryview: Use raw_spinlock for locking
>    
>    [ Upstream commit 109fdf1572be86aaf681e69b30dc5ada90ce6f35 ]
>    
>    When running -rt kernel and an interrupt happens on a GPIO line controlled by
>    Intel Cherryview/Braswell pinctrl driver we get:
>    
>     BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917
>     in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/0
>     Preemption disabled at:[<ffffffff81092e9f>] cpu_startup_entry+0x17f/0x480
>    
>     CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.5-rt5 #16
>      ...
>     Call Trace:
>      <IRQ>  [<ffffffff816283c6>] dump_stack+0x4a/0x61
>      [<ffffffff81077e17>] ___might_sleep+0xe7/0x170
>      [<ffffffff8162d6cf>] rt_spin_lock+0x1f/0x50
>      [<ffffffff812e52ed>] chv_gpio_irq_ack+0x3d/0xa0
>      [<ffffffff810a72f5>] handle_edge_irq+0x75/0x180
>      [<ffffffff810a3457>] generic_handle_irq+0x27/0x40
>      [<ffffffff812e57de>] chv_gpio_irq_handler+0x7e/0x110
>      [<ffffffff810050aa>] handle_irq+0xaa/0x190
>      ...
>    
>    This is because desc->lock is raw_spinlock and is held when chv_gpio_irq_ack()
>    is called by the genirq core. chv_gpio_irq_ack() in turn takes pctrl->lock
>    which in -rt is an rt-mutex causing might_sleep() rightfully to complain about
>    sleeping function called from invalid context.
>    
>    In order to keep -rt happy but at the same time make sure that register
>    accesses get serialized, convert the driver to use raw_spinlock instead.
>    
>    Suggested-by: Linus Walleij <linus.walleij@linaro.org>
>    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
>    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit ba42156d9552903782ab2723e5dbf3fe7275ddc7
>Author: Mika Westerberg <mika.westerberg@linux.intel.com>
>Date:   Mon Aug 3 12:46:38 2015 +0300
>
>    pinctrl: cherryview: Serialize all register access
>    
>    [ Upstream commit 4585b000ace6438d0b142746baab658056b223d9 ]
>    
>    There is a hardware issue in Intel Braswell/Cherryview where concurrent
>    GPIO register access might results reads of 0xffffffff and writes might get
>    dropped.
>    
>    Prevent this from happening by taking the serializing lock for all places
>    where it is possible that more than one thread might be accessing the
>    hardware concurrently.
>    
>    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
>    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit e05777384e99ed3baef9459027e5318ed20f41f3
>Author: Mauro Carvalho Chehab <mchehab@s-opensource.com>
>Date:   Tue Jun 14 14:48:50 2016 -0300
>
>    Update my main e-mails at the Kernel tree
>    
>    [ Upstream commit dc19ed1571dd3882b35e12fdaf50acbcc9b69714 ]
>    
>    For the third time in three years, I'm changing my e-mail at
>    Samsung. That's bad, as it may stop communications with me for
>    a while. So, this time, I'll also the mchehab@kernel.org e-mail,
>    as it remains stable since ever.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 10dd8c104728611c5f58d7b19df323756d565443
>Author: Vignesh R <vigneshr@ti.com>
>Date:   Thu Jun 9 11:02:04 2016 +0530
>
>    gpio: pca953x: Fix NBANK calculation for PCA9536
>    
>    [ Upstream commit a246b8198f776a16d1d3a3bbfc2d437bad766b29 ]
>    
>    NBANK() macro assumes that ngpios is a multiple of 8(BANK_SZ) and
>    hence results in 0 banks for PCA9536 which has just 4 gpios. This is
>    wrong as PCA9356 has 1 bank with 4 gpios. This results in uninitialized
>    PCA953X_INVERT register. Fix this by using DIV_ROUND_UP macro in
>    NBANK().
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Vignesh R <vigneshr@ti.com>
>    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 27b549050db577d3bef3eb3409237563a115f9dd
>Author: Chris Blake <chrisrblake93@gmail.com>
>Date:   Mon May 30 07:26:37 2016 -0500
>
>    PCI: Mark Atheros AR9485 and QCA9882 to avoid bus reset
>    
>    [ Upstream commit 9ac0108c2bac3f1d0255f64fb89fc27e71131b24 ]
>    
>    Similar to the AR93xx series, the AR94xx and the Qualcomm QCA988x also have
>    the same quirk for the Bus Reset.
>    
>    Fixes: c3e59ee4e766 ("PCI: Mark Atheros AR93xx to avoid bus reset")
>    Signed-off-by: Chris Blake <chrisrblake93@gmail.com>
>    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>    CC: stable@vger.kernel.org  # v3.14+
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit b3780073dea394fee44f14e36883528893ad6f7a
>Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>Date:   Thu Jun 9 18:39:07 2016 +0200
>
>    Revert "drm/i915/ilk: Don't disable SSC source if it's in use"
>    
>    [ Upstream commit 8c07eb68330f3ed9a735023a0f0e7f4e873e0c63 ]
>    
>    This reverts commit f165d2834ceb3d5c29bebadadc27629bebf402ac.
>    
>    It breaks one of our CI systems. Quoting from Ville:
>    
>    [   13.100979] [drm:ironlake_init_pch_refclk] has_panel 1 has_lvds 1 has_ck505 0 using_ssc_source 1
>    [   13.101413] ------------[ cut here ]------------
>    [   13.101429] kernel BUG at drivers/gpu/drm/i915/intel_display.c:8528!
>    
>    "which is the 'BUG_ON(val != final)' at the end of ironlake_init_pch_refclk()."
>    
>    Cc: stable@vger.kernel.org
>    Cc: Ville SyrjÃ¤lÃ¤ <ville.syrjala@linux.intel.com>
>    Cc: Lyude <cpaul@redhat.com>
>    Cc: marius.c.vlad@intel.com
>    References: https://www.spinics.net/lists/dri-devel/msg109557.html
>    Acked-by: Lyude <cpaul@redhat.com>
>    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 7a85bf9e31a6449cc2a93fd8505a7523597ff266
>Author: Paul Moore <paul@paul-moore.com>
>Date:   Mon Jun 6 15:17:20 2016 -0400
>
>    netlabel: add address family checks to netlbl_{sock,req}_delattr()
>    
>    [ Upstream commit 0e0e36774081534783aa8eeb9f6fbddf98d3c061 ]
>    
>    It seems risky to always rely on the caller to ensure the socket's
>    address family is correct before passing it to the NetLabel kAPI,
>    especially since we see at least one LSM which didn't. Add address
>    family checks to the *_delattr() functions to help prevent future
>    problems.
>    
>    Cc: <stable@vger.kernel.org>
>    Reported-by: Maninder Singh <maninder1.s@samsung.com>
>    Signed-off-by: Paul Moore <paul@paul-moore.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 85470a568a4ceed060d9539c70e29b0707e78feb
>Author: Javier Martinez Canillas <javier@osg.samsung.com>
>Date:   Tue May 3 16:27:17 2016 -0400
>
>    s5p-mfc: Add release callback for memory region devs
>    
>    [ Upstream commit 6311f1261f59ce5e51fbe5cc3b5e7737197316ac ]
>    
>    When s5p_mfc_remove() calls put_device() for the reserved memory region
>    devs, the driver core warns that the dev doesn't have a release callback:
>    
>    WARNING: CPU: 0 PID: 591 at drivers/base/core.c:251 device_release+0x8c/0x90
>    Device 's5p-mfc-l' does not have a release() function, it is broken and must be fixed.
>    
>    Also, the declared DMA memory using dma_declare_coherent_memory() isn't
>    relased so add a dev .release that calls dma_release_declared_memory().
>    
>    Cc: <stable@vger.kernel.org>
>    Fixes: 6e83e6e25eb4 ("[media] s5p-mfc: Fix kernel warning on memory init")
>    Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>    Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>    Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 1dd12c31c91bf3d505a8496f62805b042cb5fa83
>Author: Javier Martinez Canillas <javier@osg.samsung.com>
>Date:   Tue May 3 16:27:16 2016 -0400
>
>    s5p-mfc: Set device name for reserved memory region devs
>    
>    [ Upstream commit 29debab0a94035a390801d1f177d171d014b7765 ]
>    
>    The devices don't have a name set, so makes dev_name() returns NULL which
>    makes harder to identify the devices that are causing issues, for example:
>    
>    WARNING: CPU: 2 PID: 616 at drivers/base/core.c:251 device_release+0x8c/0x90
>    Device '(null)' does not have a release() function, it is broken and must be fixed.
>    
>    And after setting the device name:
>    
>    WARNING: CPU: 0 PID: 591 at drivers/base/core.c:251 device_release+0x8c/0x90
>    Device 's5p-mfc-l' does not have a release() function, it is broken and must be fixed.
>    
>    Cc: <stable@vger.kernel.org>
>    Fixes: 6e83e6e25eb4 ("[media] s5p-mfc: Fix kernel warning on memory init")
>    Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>    Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>    Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit fce671617558b1dceb3471fbf2c3d3f00ef83664
>Author: Roderick Colenbrander <roderick.colenbrander@sony.com>
>Date:   Wed May 18 13:11:09 2016 -0700
>
>    HID: uhid: fix timeout when probe races with IO
>    
>    [ Upstream commit 67f8ecc550b5bda03335f845dc869b8501d25fd0 ]
>    
>    Many devices use userspace bluetooth stacks like BlueZ or Bluedroid in combination
>    with uhid. If any of these stacks is used with a HID device for which the driver
>    performs a HID request as part .probe (or technically another HID operation),
>    this results in a deadlock situation. The deadlock results in a 5 second timeout
>    for I/O operations in HID drivers, so isn't fatal, but none of the I/O operations
>    have a chance of succeeding.
>    
>    The root cause for the problem is that uhid only allows for one request to be
>    processed at a time per uhid instance and locks out other operations. This means
>    that if a user space is creating a new HID device through 'UHID_CREATE', which
>    ultimately triggers '.probe' through the HID layer. Then any HID request e.g. a
>    read for calibration data would trigger a HID operation on uhid again, but it
>    won't go out to userspace, because it is still stuck in UHID_CREATE.
>    In addition bluetooth stacks are typically single threaded, so they wouldn't be
>    able to handle any requests while waiting on uhid.
>    
>    Lucikly the UHID spec is somewhat flexible and allows for fixing the issue,
>    without breaking user space. The idea which the patch implements as discussed
>    with David Herrmann is to decouple adding of a hid device (which triggers .probe)
>    from UHID_CREATE. The work will kick off roughly once UHID_CREATE completed (or
>    else will wait a tiny bit of time in .probe for a lock). A HID driver has to call
>    HID to call 'hid_hw_start()' as part of .probe once it is ready for I/O, which
>    triggers UHID_START to user space. Any HID operations should function now within
>    .probe and won't deadlock because userspace is stuck on UHID_CREATE.
>    
>    We verified this patch on Bluedroid with Android 6.0 and on desktop Linux with
>    BlueZ stacks. Prior to the patch they had the deadlock issue.
>    
>    [jkosina@suse.cz: reword subject]
>    Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
>    
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 223b3917e224a83cf174ed3458804c9c35b5013e
>Author: James Morse <james.morse@arm.com>
>Date:   Fri Aug 12 14:11:19 2016 -0400
>
>    arm64: kernel: Save and restore addr_limit on exception entry
>    
>    commit e19a6ee2460bdd0d0055a6029383422773f9999a upstream.
>    
>    If we take an exception while at EL1, the exception handler inherits
>    the original context's addr_limit value. To be consistent always reset
>    addr_limit and PSTATE.UAO on (re-)entry to EL1. This prevents accidental
>    re-use of the original context's addr_limit.
>    
>    Based on a similar patch for arm from Russell King.
>    
>    Acked-by: Will Deacon <will.deacon@arm.com>
>    Reviewed-by: Mark Rutland <mark.rutland@arm.com>
>    Signed-off-by: James Morse <james.morse@arm.com>
>    Signed-off-by: Will Deacon <will.deacon@arm.com>
>    [ backport to stop perf misusing inherited addr_limit.
>      Removed code interacting with UAO and the irqstack ]
>    Link: https://bugs.chromium.org/p/project-zero/issues/detail?id=822
>    Signed-off-by: James Morse <james.morse@arm.com>
>    Cc: <stable@vger.kernel.org> #4.1
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 5c576457aca8fc07bdb800a4589357801133f81b
>Author: Kenny Keslar <kenny.keslar@oracle.com>
>Date:   Fri Aug 12 13:27:29 2016 -0400
>
>    fs/proc/task_mmu.c: fix mm_access() mode parameter in pagemap_read()
>    
>    Backport of caaee6234d05a58c5b4d05e7bf766131b810a657 ("ptrace: use fsuid,
>    fsgid, effective creds for fs access checks") to v4.1 failed to update the
>    mode parameter in the mm_access() call in pagemap_read() to have one of the
>    new PTRACE_MODE_*CREDS flags.
>    
>    Attempting to read any other process' pagemap results in a WARN()
>    
>    WARNING: CPU: 0 PID: 883 at kernel/ptrace.c:229 __ptrace_may_access+0x14a/0x160()
>    denying ptrace access check without PTRACE_MODE_*CREDS
>    Modules linked in: loop sg e1000 i2c_piix4 ppdev virtio_balloon virtio_pci parport_pc i2c_core virtio_ring ata_generic serio_raw pata_acpi virtio parport pcspkr floppy acpi_cpufreq ip_tables ext3 mbcache jbd sd_mod ata_piix crc32c_intel libata
>    CPU: 0 PID: 883 Comm: cat Tainted: G        W       4.1.12-51.el7uek.x86_64 #2
>    Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
>      0000000000000286 00000000619f225a ffff88003b6fbc18 ffffffff81717021
>      ffff88003b6fbc70 ffffffff819be870 ffff88003b6fbc58 ffffffff8108477a
>      000000003b6fbc58 0000000000000001 ffff88003d287000 0000000000000001
>    Call Trace:
>      [<ffffffff81717021>] dump_stack+0x63/0x81
>      [<ffffffff8108477a>] warn_slowpath_common+0x8a/0xc0
>      [<ffffffff81084805>] warn_slowpath_fmt+0x55/0x70
>      [<ffffffff8108e57a>] __ptrace_may_access+0x14a/0x160
>      [<ffffffff8108f372>] ptrace_may_access+0x32/0x50
>      [<ffffffff81081bad>] mm_access+0x6d/0xb0
>      [<ffffffff81278c81>] pagemap_read+0xe1/0x360
>      [<ffffffff811a046b>] ? lru_cache_add_active_or_unevictable+0x2b/0xa0
>      [<ffffffff8120d2e7>] __vfs_read+0x37/0x100
>      [<ffffffff812b9ab4>] ? security_file_permission+0x84/0xa0
>      [<ffffffff8120d8b6>] ? rw_verify_area+0x56/0xe0
>      [<ffffffff8120d9c6>] vfs_read+0x86/0x140
>      [<ffffffff8120e945>] SyS_read+0x55/0xd0
>      [<ffffffff8171eb6e>] system_call_fastpath+0x12/0x71
>    
>    Fixes: ab88ce5feca4 (ptrace: use fsuid, fsgid, effective creds for fs access checks)
>    Signed-off-by: Kenny Keslar <kenny.keslar@oracle.com>
>    Cc: Roland McGrath <roland@hack.frob.com>
>    Cc: Oleg Nesterov <oleg@redhat.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 6a468737c8c00bd6cdb208ca0b7f841e8970d466
>Author: Munehisa Kamata <kamatam@amazon.com>
>Date:   Mon Oct 26 19:10:52 2015 -0700
>
>    netfilter: nf_nat_redirect: add missing NULL pointer check
>    
>    [ Upstream commit 94f9cd81436c85d8c3a318ba92e236ede73752fc ]
>    
>    Commit 8b13eddfdf04cbfa561725cfc42d6868fe896f56 ("netfilter: refactor NAT
>    redirect IPv4 to use it from nf_tables") has introduced a trivial logic
>    change which can result in the following crash.
>    
>    BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
>    IP: [<ffffffffa033002d>] nf_nat_redirect_ipv4+0x2d/0xa0 [nf_nat_redirect]
>    PGD 3ba662067 PUD 3ba661067 PMD 0
>    Oops: 0000 [#1] SMP
>    Modules linked in: ipv6(E) xt_REDIRECT(E) nf_nat_redirect(E) xt_tcpudp(E) iptable_nat(E) nf_conntrack_ipv4(E) nf_defrag_ipv4(E) nf_nat_ipv4(E) nf_nat(E) nf_conntrack(E) ip_tables(E) x_tables(E) binfmt_misc(E) xfs(E) libcrc32c(E) evbug(E) evdev(E) psmouse(E) i2c_piix4(E) i2c_core(E) acpi_cpufreq(E) button(E) ext4(E) crc16(E) jbd2(E) mbcache(E) dm_mirror(E) dm_region_hash(E) dm_log(E) dm_mod(E)
>    CPU: 0 PID: 2536 Comm: ip Tainted: G            E   4.1.7-15.23.amzn1.x86_64 #1
>    Hardware name: Xen HVM domU, BIOS 4.2.amazon 05/06/2015
>    task: ffff8800eb438000 ti: ffff8803ba664000 task.ti: ffff8803ba664000
>    [...]
>    Call Trace:
>     <IRQ>
>     [<ffffffffa0334065>] redirect_tg4+0x15/0x20 [xt_REDIRECT]
>     [<ffffffffa02e2e99>] ipt_do_table+0x2b9/0x5e1 [ip_tables]
>     [<ffffffffa0328045>] iptable_nat_do_chain+0x25/0x30 [iptable_nat]
>     [<ffffffffa031777d>] nf_nat_ipv4_fn+0x13d/0x1f0 [nf_nat_ipv4]
>     [<ffffffffa0328020>] ? iptable_nat_ipv4_fn+0x20/0x20 [iptable_nat]
>     [<ffffffffa031785e>] nf_nat_ipv4_in+0x2e/0x90 [nf_nat_ipv4]
>     [<ffffffffa03280a5>] iptable_nat_ipv4_in+0x15/0x20 [iptable_nat]
>     [<ffffffff81449137>] nf_iterate+0x57/0x80
>     [<ffffffff814491f7>] nf_hook_slow+0x97/0x100
>     [<ffffffff814504d4>] ip_rcv+0x314/0x400
>    
>    unsigned int
>    nf_nat_redirect_ipv4(struct sk_buff *skb,
>    ...
>    {
>    ...
>    		rcu_read_lock();
>    		indev = __in_dev_get_rcu(skb->dev);
>    		if (indev != NULL) {
>    			ifa = indev->ifa_list;
>    			newdst = ifa->ifa_local; <---
>    		}
>    		rcu_read_unlock();
>    ...
>    }
>    
>    Before the commit, 'ifa' had been always checked before access. After the
>    commit, however, it could be accessed even if it's NULL. Interestingly,
>    this was once fixed in 2003.
>    
>    http://marc.info/?l=netfilter-devel&m=106668497403047&w=2
>    
>    In addition to the original one, we have seen the crash when packets that
>    need to be redirected somehow arrive on an interface which hasn't been
>    yet fully configured.
>    
>    This change just reverts the logic to the old behavior to avoid the crash.
>    
>    Fixes: 8b13eddfdf04 ("netfilter: refactor NAT redirect IPv4 to use it from nf_tables")
>    Signed-off-by: Munehisa Kamata <kamatam@amazon.com>
>    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 558ba5fd7d8dbe0b233c309ce89317c1d0858bd7
>Author: Sasha Levin <alexander.levin@verizon.com>
>Date:   Mon Aug 8 22:11:45 2016 -0400
>
>    Linux 4.1.30
>    
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 629d0452604e4e2acc7cd3b8efd4ce92330dc178
>Author: Lukas Wunner <lukas@wunner.de>
>Date:   Sun Jun 12 12:31:53 2016 +0200
>
>    x86/quirks: Reintroduce scanning of secondary buses
>    
>    [ Upstream commit 850c321027c2e31d0afc71588974719a4b565550 ]
>    
>    We used to scan secondary buses until the following commit that
>    was applied in 2009:
>    
>      8659c406ade3 ("x86: only scan the root bus in early PCI quirks")
>    
>    which commit constrained early quirks to the root bus only. Its
>    motivation was to prevent application of the nvidia_bugs quirk
>    on secondary buses.
>    
>    We're about to add a quirk to reset the Broadcom 4331 wireless card on
>    2011/2012 Macs, which is located on a secondary bus behind a PCIe root
>    port. To facilitate that, reintroduce scanning of secondary buses.
>    
>    The commit message of 8659c406ade3 notes that scanning only the root bus
>    "saves quite some unnecessary scanning work". The algorithm used prior
>    to 8659c406ade3 was particularly time consuming because it scanned
>    buses 0 to 31 brute force. To avoid lengthening boot time, employ a
>    recursive strategy which only scans buses that are actually reachable
>    from the root bus.
>    
>    Yinghai Lu pointed out that the secondary bus number read from a
>    bridge's config space may be invalid, in particular a value of 0 would
>    cause an infinite loop. The PCI core goes beyond that and recurses to a
>    child bus only if its bus number is greater than the parent bus number
>    (see pci_scan_bridge()). Since the root bus is numbered 0, this implies
>    that secondary buses may not be 0. Do the same on early scanning.
>    
>    If this algorithm is found to significantly impact boot time or cause
>    infinite loops on broken hardware, it would be possible to limit its
>    recursion depth: The Broadcom 4331 quirk applies at depth 1, all others
>    at depth 0, so the bus need not be scanned deeper than that for now. An
>    alternative approach would be to revert to scanning only the root bus,
>    and apply the Broadcom 4331 quirk to the root ports 8086:1c12, 8086:1e12
>    and 8086:1e16. Apple always positioned the card behind either of these
>    three ports. The quirk would then check presence of the card in slot 0
>    below the root port and do its deed.
>    
>    Signed-off-by: Lukas Wunner <lukas@wunner.de>
>    Cc: Andy Lutomirski <luto@kernel.org>
>    Cc: Bjorn Helgaas <bhelgaas@google.com>
>    Cc: Borislav Petkov <bp@alien8.de>
>    Cc: Brian Gerst <brgerst@gmail.com>
>    Cc: Denys Vlasenko <dvlasenk@redhat.com>
>    Cc: H. Peter Anvin <hpa@zytor.com>
>    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Cc: Yinghai Lu <yinghai@kernel.org>
>    Cc: linux-pci@vger.kernel.org
>    Link: http://lkml.kernel.org/r/f0daa70dac1a9b2483abdb31887173eb6ab77bdf.1465690253.git.lukas@wunner.de
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit f2da7dfdbd33243a6c7fd48f2aca9b6b3e3715d6
>Author: Lukas Wunner <lukas@wunner.de>
>Date:   Sun Jun 12 12:31:53 2016 +0200
>
>    x86/quirks: Apply nvidia_bugs quirk only on root bus
>    
>    [ Upstream commit 447d29d1d3aed839e74c2401ef63387780ac51ed ]
>    
>    Since the following commit:
>    
>      8659c406ade3 ("x86: only scan the root bus in early PCI quirks")
>    
>    ... early quirks are only applied to devices on the root bus.
>    
>    The motivation was to prevent application of the nvidia_bugs quirk on
>    secondary buses.
>    
>    We're about to reintroduce scanning of secondary buses for a quirk to
>    reset the Broadcom 4331 wireless card on 2011/2012 Macs. To prevent
>    regressions, open code the requirement to apply nvidia_bugs only on the
>    root bus.
>    
>    Signed-off-by: Lukas Wunner <lukas@wunner.de>
>    Cc: Andy Lutomirski <luto@kernel.org>
>    Cc: Bjorn Helgaas <bhelgaas@google.com>
>    Cc: Borislav Petkov <bp@alien8.de>
>    Cc: Brian Gerst <brgerst@gmail.com>
>    Cc: Denys Vlasenko <dvlasenk@redhat.com>
>    Cc: H. Peter Anvin <hpa@zytor.com>
>    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Cc: Yinghai Lu <yinghai@kernel.org>
>    Link: http://lkml.kernel.org/r/4d5477c1d76b2f0387a780f2142bbcdd9fee869b.1465690253.git.lukas@wunner.de
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 6264b57755b8abe09ba36ceefd76f5fa6f4aa3ce
>Author: Sasha Levin <alexander.levin@verizon.com>
>Date:   Sun Aug 7 21:35:12 2016 -0400
>
>    Revert "MIPS: Reserve nosave data for hibernation"
>    
>    This reverts commit e8ebd0cf882ba73a5c867bb7228dba1ae746c047.
>    
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 84d0821866aef5a218844891d6e33a231c79bd10
>Author: Sasha Levin <alexander.levin@verizon.com>
>Date:   Sun Aug 7 21:34:49 2016 -0400
>
>    Revert "sparc64: Fix numa node distance initialization"
>    
>    This reverts commit bfbe327d556707c59c5c0536d831078b41a68429.
>    
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit bd6d85d6ebaae18815d9c75157a2c86990c6e748
>Author: Jiri Slaby <jslaby@suse.cz>
>Date:   Wed Jul 20 15:45:08 2016 -0700
>
>    pps: do not crash when failed to register
>    
>    [ Upstream commit 368301f2fe4b07e5fb71dba3cc566bc59eb6705f ]
>    
>    With this command sequence:
>    
>      modprobe plip
>      modprobe pps_parport
>      rmmod pps_parport
>    
>    the partport_pps modules causes this crash:
>    
>      BUG: unable to handle kernel NULL pointer dereference at (null)
>      IP: parport_detach+0x1d/0x60 [pps_parport]
>      Oops: 0000 [#1] SMP
>      ...
>      Call Trace:
>        parport_unregister_driver+0x65/0xc0 [parport]
>        SyS_delete_module+0x187/0x210
>    
>    The sequence that builds up to this is:
>    
>     1) plip is loaded and takes the parport device for exclusive use:
>    
>        plip0: Parallel port at 0x378, using IRQ 7.
>    
>     2) pps_parport then fails to grab the device:
>    
>        pps_parport: parallel port PPS client
>        parport0: cannot grant exclusive access for device pps_parport
>        pps_parport: couldn't register with parport0
>    
>     3) rmmod of pps_parport is then killed because it tries to access
>        pardev->name, but pardev (taken from port->cad) is NULL.
>    
>    So add a check for NULL in the test there too.
>    
>    Link: http://lkml.kernel.org/r/20160714115245.12651-1-jslaby@suse.cz
>    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
>    Acked-by: Rodolfo Giometti <giometti@enneenne.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit bea9acd81cc894c89ac81335467278d189547d05
>Author: Andrey Ryabinin <aryabinin@virtuozzo.com>
>Date:   Wed Jul 20 15:45:00 2016 -0700
>
>    radix-tree: fix radix_tree_iter_retry() for tagged iterators.
>    
>    [ Upstream commit 3cb9185c67304b2a7ea9be73e7d13df6fb2793a1 ]
>    
>    radix_tree_iter_retry() resets slot to NULL, but it doesn't reset tags.
>    Then NULL slot and non-zero iter.tags passed to radix_tree_next_slot()
>    leading to crash:
>    
>      RIP: radix_tree_next_slot include/linux/radix-tree.h:473
>        find_get_pages_tag+0x334/0x930 mm/filemap.c:1452
>      ....
>      Call Trace:
>        pagevec_lookup_tag+0x3a/0x80 mm/swap.c:960
>        mpage_prepare_extent_to_map+0x321/0xa90 fs/ext4/inode.c:2516
>        ext4_writepages+0x10be/0x2b20 fs/ext4/inode.c:2736
>        do_writepages+0x97/0x100 mm/page-writeback.c:2364
>        __filemap_fdatawrite_range+0x248/0x2e0 mm/filemap.c:300
>        filemap_write_and_wait_range+0x121/0x1b0 mm/filemap.c:490
>        ext4_sync_file+0x34d/0xdb0 fs/ext4/fsync.c:115
>        vfs_fsync_range+0x10a/0x250 fs/sync.c:195
>        vfs_fsync fs/sync.c:209
>        do_fsync+0x42/0x70 fs/sync.c:219
>        SYSC_fdatasync fs/sync.c:232
>        SyS_fdatasync+0x19/0x20 fs/sync.c:230
>        entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207
>    
>    We must reset iterator's tags to bail out from radix_tree_next_slot()
>    and go to the slow-path in radix_tree_next_chunk().
>    
>    Fixes: 46437f9a554f ("radix-tree: fix race in gang lookup")
>    Link: http://lkml.kernel.org/r/1468495196-10604-1-git-send-email-aryabinin@virtuozzo.com
>    Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Acked-by: Konstantin Khlebnikov <koct9i@gmail.com>
>    Cc: Matthew Wilcox <willy@linux.intel.com>
>    Cc: Hugh Dickins <hughd@google.com>
>    Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 6831c98ce0b8a3e88db64aa224372effd0dcc694
>Author: Ilya Dryomov <idryomov@gmail.com>
>Date:   Tue Jul 19 03:50:28 2016 +0200
>
>    libceph: apply new_state before new_up_client on incrementals
>    
>    [ Upstream commit 930c532869774ebf8af9efe9484c597f896a7d46 ]
>    
>    Currently, osd_weight and osd_state fields are updated in the encoding
>    order.  This is wrong, because an incremental map may look like e.g.
>    
>        new_up_client: { osd=6, addr=... } # set osd_state and addr
>        new_state: { osd=6, xorstate=EXISTS } # clear osd_state
>    
>    Suppose osd6's current osd_state is EXISTS (i.e. osd6 is down).  After
>    applying new_up_client, osd_state is changed to EXISTS | UP.  Carrying
>    on with the new_state update, we flip EXISTS and leave osd6 in a weird
>    "!EXISTS but UP" state.  A non-existent OSD is considered down by the
>    mapping code
>    
>    2087    for (i = 0; i < pg->pg_temp.len; i++) {
>    2088            if (ceph_osd_is_down(osdmap, pg->pg_temp.osds[i])) {
>    2089                    if (ceph_can_shift_osds(pi))
>    2090                            continue;
>    2091
>    2092                    temp->osds[temp->size++] = CRUSH_ITEM_NONE;
>    
>    and so requests get directed to the second OSD in the set instead of
>    the first, resulting in OSD-side errors like:
>    
>    [WRN] : client.4239 192.168.122.21:0/2444980242 misdirected client.4239.1:2827 pg 2.5df899f2 to osd.4 not [1,4,6] in e680/680
>    
>    and hung rbds on the client:
>    
>    [  493.566367] rbd: rbd0: write 400000 at 11cc00000 (0)
>    [  493.566805] rbd: rbd0:   result -6 xferred 400000
>    [  493.567011] blk_update_request: I/O error, dev rbd0, sector 9330688
>    
>    The fix is to decouple application from the decoding and:
>    - apply new_weight first
>    - apply new_state before new_up_client
>    - twiddle osd_state flags if marking in
>    - clear out some of the state if osd is destroyed
>    
>    Fixes: http://tracker.ceph.com/issues/14901
>    
>    Cc: stable@vger.kernel.org # 3.15+: 6dd74e44dc1d: libceph: set 'exists' flag for newly up osd
>    Cc: stable@vger.kernel.org # 3.15+
>    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
>    Reviewed-by: Josh Durgin <jdurgin@redhat.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 5210f975ba197ead8b703ec818260191c0a51133
>Author: Yan, Zheng <zyan@redhat.com>
>Date:   Fri Aug 28 17:59:35 2015 +0800
>
>    libceph: set 'exists' flag for newly up osd
>    
>    [ Upstream commit 6dd74e44dc1df85f125982a8d6591bc4a76c9f5d ]
>    
>    Signed-off-by: Yan, Zheng <zyan@redhat.com>
>    Reviewed-by: Sage Weil <sage@redhat.com>
>    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 87076a0105bd74b97b0ec462dcaf385958010f37
>Author: Maxim Patlasov <mpatlasov@virtuozzo.com>
>Date:   Thu Jul 21 18:24:26 2016 -0700
>
>    ovl: verify upper dentry in ovl_remove_and_whiteout()
>    
>    [ Upstream commit cfc9fde0b07c3b44b570057c5f93dda59dca1c94 ]
>    
>    The upper dentry may become stale before we call ovl_lock_rename_workdir.
>    For example, someone could (mistakenly or maliciously) manually unlink(2)
>    it directly from upperdir.
>    
>    To ensure it is not stale, let's lookup it after ovl_lock_rename_workdir
>    and and check if it matches the upper dentry.
>    
>    Essentially, it is the same problem and similar solution as in
>    commit 11f3710417d0 ("ovl: verify upper dentry before unlink and rename").
>    
>    Signed-off-by: Maxim Patlasov <mpatlasov@virtuozzo.com>
>    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 9524cc41374df87b9c8d200e3561ad408bfa5844
>Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>Date:   Mon Jun 27 14:12:34 2016 -0700
>
>    tty/vt/keyboard: fix OOB access in do_compute_shiftstate()
>    
>    [ Upstream commit 510cccb5b0c8868a2b302a0ab524da7912da648b ]
>    
>    The size of individual keymap in drivers/tty/vt/keyboard.c is NR_KEYS,
>    which is currently 256, whereas number of keys/buttons in input device (and
>    therefor in key_down) is much larger - KEY_CNT - 768, and that can cause
>    out-of-bound access when we do
>    
>    	sym = U(key_maps[0][k]);
>    
>    with large 'k'.
>    
>    To fix it we should not attempt iterating beyond smaller of NR_KEYS and
>    KEY_CNT.
>    
>    Also while at it let's switch to for_each_set_bit() instead of open-coding
>    it.
>    
>    Reported-by: Sasha Levin <sasha.levin@oracle.com>
>    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit e77df443966296efb726712e064ee34b9ce42737
>Author: Tejun Heo <tj@kernel.org>
>Date:   Mon Jul 18 18:40:00 2016 -0400
>
>    libata: LITE-ON CX1-JB256-HP needs lower max_sectors
>    
>    [ Upstream commit 1488a1e3828d60d74c9b802a05e24c0487babe4e ]
>    
>    Since 34b48db66e08 ("block: remove artifical max_hw_sectors cap"),
>    max_sectors is no longer limited to BLK_DEF_MAX_SECTORS and LITE-ON
>    CX1-JB256-HP keeps timing out with higher max_sectors.  Revert it to
>    the previous value.
>    
>    Signed-off-by: Tejun Heo <tj@kernel.org>
>    Reported-by: dgerasimov@gmail.com
>    Link: https://bugzilla.kernel.org/show_bug.cgi?id=121671
>    Cc: stable@vger.kernel.org # v3.19+
>    Fixes: 34b48db66e08 ("block: remove artifical max_hw_sectors cap")
>    Signed-off-by: Tejun Heo <tj@kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit c30e87bae9b4bfa7918e30a18b8522eea08ae61f
>Author: Taras Kondratiuk <takondra@cisco.com>
>Date:   Wed Jul 13 22:05:38 2016 +0000
>
>    mmc: block: fix packed command header endianness
>    
>    [ Upstream commit f68381a70bb2b26c31b13fdaf67c778f92fd32b4 ]
>    
>    The code that fills packed command header assumes that CPU runs in
>    little-endian mode. Hence the header is malformed in big-endian mode
>    and causes MMC data transfer errors:
>    
>    [  563.200828] mmcblk0: error -110 transferring data, sector 2048, nr 8, cmd response 0x900, card status 0xc40
>    [  563.219647] mmcblk0: packed cmd failed, nr 2, sectors 16, failure index: -1
>    
>    Convert header data to LE.
>    
>    Signed-off-by: Taras Kondratiuk <takondra@cisco.com>
>    Fixes: ce39f9d17c14 ("mmc: support packed write command for eMMC4.5 devices")
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit ce05d315cec02835c77fa3f4b5119960e1654913
>Author: James Patrick-Evans <james@jmp-e.com>
>Date:   Fri Jul 15 16:40:45 2016 +0100
>
>    media: fix airspy usb probe error path
>    
>    [ Upstream commit aa93d1fee85c890a34f2510a310e55ee76a27848 ]
>    
>    Fix a memory leak on probe error of the airspy usb device driver.
>    
>    The problem is triggered when more than 64 usb devices register with
>    v4l2 of type VFL_TYPE_SDR or VFL_TYPE_SUBDEV.
>    
>    The memory leak is caused by the probe function of the airspy driver
>    mishandeling errors and not freeing the corresponding control structures
>    when an error occours registering the device to v4l2 core.
>    
>    A badusb device can emulate 64 of these devices, and then through
>    continual emulated connect/disconnect of the 65th device, cause the
>    kernel to run out of RAM and crash the kernel, thus causing a local DOS
>    vulnerability.
>    
>    Fixes CVE-2016-5400
>    
>    Signed-off-by: James Patrick-Evans <james@jmp-e.com>
>    Reviewed-by: Kees Cook <keescook@chromium.org>
>    Cc: stable@vger.kernel.org # 3.17+
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 371ac20be9fcc8acca7add6d43d77e6d53192f92
>Author: Dmitry Vyukov <dvyukov@google.com>
>Date:   Thu Jul 14 12:07:29 2016 -0700
>
>    vmlinux.lds: account for destructor sections
>    
>    [ Upstream commit e41f501d391265ff568f3e49d6128cc30856a36f ]
>    
>    If CONFIG_KASAN is enabled and gcc is configured with
>    --disable-initfini-array and/or gold linker is used, gcc emits
>    .ctors/.dtors and .text.startup/.text.exit sections instead of
>    .init_array/.fini_array.  .dtors section is not explicitly accounted in
>    the linker script and messes vvar/percpu layout.
>    
>    We want:
>      ffffffff822bfd80 D _edata
>      ffffffff822c0000 D __vvar_beginning_hack
>      ffffffff822c0000 A __vvar_page
>      ffffffff822c0080 0000000000000098 D vsyscall_gtod_data
>      ffffffff822c1000 A __init_begin
>      ffffffff822c1000 D init_per_cpu__irq_stack_union
>      ffffffff822c1000 A __per_cpu_load
>      ffffffff822d3000 D init_per_cpu__gdt_page
>    
>    We got:
>      ffffffff8279a600 D _edata
>      ffffffff8279b000 A __vvar_page
>      ffffffff8279c000 A __init_begin
>      ffffffff8279c000 D init_per_cpu__irq_stack_union
>      ffffffff8279c000 A __per_cpu_load
>      ffffffff8279e000 D __vvar_beginning_hack
>      ffffffff8279e080 0000000000000098 D vsyscall_gtod_data
>      ffffffff827ae000 D init_per_cpu__gdt_page
>    
>    This happens because __vvar_page and .vvar get different addresses in
>    arch/x86/kernel/vmlinux.lds.S:
>    
>    	. = ALIGN(PAGE_SIZE);
>    	__vvar_page = .;
>    
>    	.vvar : AT(ADDR(.vvar) - LOAD_OFFSET) {
>    		/* work around gold bug 13023 */
>    		__vvar_beginning_hack = .;
>    
>    Discard .dtors/.fini_array/.text.exit, since we don't call dtors.
>    Merge .text.startup into init text.
>    
>    Link: http://lkml.kernel.org/r/1467386363-120030-1-git-send-email-dvyukov@google.com
>    Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
>    Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
>    Cc: <stable@vger.kernel.org>	[4.0+]
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit fe071fb0d4e9fd40fe7c46c6a9f8f23d5f27e92f
>Author: David Rientjes <rientjes@google.com>
>Date:   Thu Jul 14 12:06:50 2016 -0700
>
>    mm, compaction: prevent VM_BUG_ON when terminating freeing scanner
>    
>    [ Upstream commit a46cbf3bc53b6a93fb84a5ffb288c354fa807954 ]
>    
>    It's possible to isolate some freepages in a pageblock and then fail
>    split_free_page() due to the low watermark check.  In this case, we hit
>    VM_BUG_ON() because the freeing scanner terminated early without a
>    contended lock or enough freepages.
>    
>    This should never have been a VM_BUG_ON() since it's not a fatal
>    condition.  It should have been a VM_WARN_ON() at best, or even handled
>    gracefully.
>    
>    Regardless, we need to terminate anytime the full pageblock scan was not
>    done.  The logic belongs in isolate_freepages_block(), so handle its
>    state gracefully by terminating the pageblock loop and making a note to
>    restart at the same pageblock next time since it was not possible to
>    complete the scan this time.
>    
>    [rientjes@google.com: don't rescan pages in a pageblock]
>      Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1607111244150.83138@chino.kir.corp.google.com
>    Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1606291436300.145590@chino.kir.corp.google.com
>    Signed-off-by: David Rientjes <rientjes@google.com>
>    Reported-by: Minchan Kim <minchan@kernel.org>
>    Tested-by: Minchan Kim <minchan@kernel.org>
>    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
>    Cc: Hugh Dickins <hughd@google.com>
>    Cc: Mel Gorman <mgorman@techsingularity.net>
>    Cc: Vlastimil Babka <vbabka@suse.cz>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit ca0d868322c49b0d6ee4dfaae94a28e12969552c
>Author: Vlastimil Babka <vbabka@suse.cz>
>Date:   Tue Sep 8 15:02:39 2015 -0700
>
>    mm, compaction: simplify handling restart position in free pages scanner
>    
>    [ Upstream commit f5f61a320bf6275f37fcabf6645b4ac8e683c007 ]
>    
>    Handling the position where compaction free scanner should restart
>    (stored in cc->free_pfn) got more complex with commit e14c720efdd7 ("mm,
>    compaction: remember position within pageblock in free pages scanner").
>    Currently the position is updated in each loop iteration of
>    isolate_freepages(), although it should be enough to update it only when
>    breaking from the loop.  There's also an extra check outside the loop
>    updates the position in case we have met the migration scanner.
>    
>    This can be simplified if we move the test for having isolated enough
>    from the for-loop header next to the test for contention, and
>    determining the restart position only in these cases.  We can reuse the
>    isolate_start_pfn variable for this instead of setting cc->free_pfn
>    directly.  Outside the loop, we can simply set cc->free_pfn to current
>    value of isolate_start_pfn without any extra check.
>    
>    Also add a VM_BUG_ON to catch possible mistake in the future, in case we
>    later add a new condition that terminates isolate_freepages_block()
>    prematurely without also considering the condition in
>    isolate_freepages().
>    
>    Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
>    Cc: Minchan Kim <minchan@kernel.org>
>    Acked-by: Mel Gorman <mgorman@suse.de>
>    Acked-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
>    Cc: Michal Nazarewicz <mina86@mina86.com>
>    Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
>    Cc: Christoph Lameter <cl@linux.com>
>    Cc: Rik van Riel <riel@redhat.com>
>    Cc: David Rientjes <rientjes@google.com>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 1602957c537ea8e5dd79fb393ab1055a71e13ac8
>Author: Chris Wilson <chris@chris-wilson.co.uk>
>Date:   Mon Jul 11 14:46:17 2016 +0100
>
>    drm/i915: Update ifdeffery for mutex->owner
>    
>    [ Upstream commit b19240062722c39fa92c99f04cbfd93034625123 ]
>    
>    In commit 7608a43d8f2e ("locking/mutexes: Use MUTEX_SPIN_ON_OWNER when
>    appropriate") the owner field in the mutex was updated from being
>    dependent upon CONFIG_SMP to using optimistic spin. Update our peek
>    function to suite.
>    
>    Fixes:7608a43d8f2e ("locking/mutexes: Use MUTEX_SPIN_ON_OWNER...")
>    Reported-by: Hong Liu <hong.liu@intel.com>
>    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>    Link: http://patchwork.freedesktop.org/patch/msgid/1468244777-4888-1-git-send-email-chris@chris-wilson.co.uk
>    Reviewed-by: Matthew Auld <matthew.auld@intel.com>
>    (cherry picked from commit 4f074a5393431a7d2cc0de7fcfe2f61d24854628)
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 627ec70f1de0227307f1a41ff58dd5ee0f2777d3
>Author: Awais Belal <awais_belal@mentor.com>
>Date:   Tue Jul 12 15:21:28 2016 +0500
>
>    ALSA: hda: add AMD Stoney PCI ID with proper driver caps
>    
>    [ Upstream commit d716fb03f76411fc7e138692e33b749cada5c094 ]
>    
>    This allows the device to correctly show up as ATI HDMI
>    rather than a generic one and allows the driver to use
>    the available caps.
>    
>    Signed-off-by: Awais Belal <awais_belal@mentor.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 282f757159a1b0ba666acc8d511a32c92e9d321e
>Author: Sasha Levin <alexander.levin@verizon.com>
>Date:   Sat Aug 6 12:55:50 2016 -0400
>
>    ALSA: hda - fix use-after-free after module unload
>    
>    [ Upstream commit ab58d8cc870ef3f0771c197700441936898d1f1d ]
>    
>    register_vga_switcheroo() sets the PM ops from the hda structure which
>    is freed later in azx_free. Make sure that these ops are cleared.
>    
>    Caught by KASAN, initially noticed due to a general protection fault.
>    
>    Fixes: 246efa4a072f ("snd/hda: add runtime suspend/resume on optimus support (v4)")
>    Signed-off-by: Peter Wu <peter@lekensteyn.nl>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit f8e307805ad3e4cd26d9d9ed7995ec36d82e4324
>Author: Alexey Dobriyan <adobriyan@gmail.com>
>Date:   Fri Jul 8 01:39:11 2016 +0300
>
>    posix_cpu_timer: Exit early when process has been reaped
>    
>    [ Upstream commit 2c13ce8f6b2f6fd9ba2f9261b1939fc0f62d1307 ]
>    
>    Variable "now" seems to be genuinely used unintialized
>    if branch
>    
>    	if (CPUCLOCK_PERTHREAD(timer->it_clock)) {
>    
>    is not taken and branch
>    
>    	if (unlikely(sighand == NULL)) {
>    
>    is taken. In this case the process has been reaped and the timer is marked as
>    disarmed anyway. So none of the postprocessing of the sample is
>    required. Return right away.
>    
>    Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
>    Cc: stable@vger.kernel.org
>    Link: http://lkml.kernel.org/r/20160707223911.GA26483@p183.telecom.by
>    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 47eec480c93227ddde8c4ee5c46cbb1d038c3b4d
>Author: Lukas Wunner <lukas@wunner.de>
>Date:   Sun Jun 12 12:31:53 2016 +0200
>
>    x86/quirks: Add early quirk to reset Apple AirPort card
>    
>    [ Upstream commit abb2bafd295fe962bbadc329dbfb2146457283ac ]
>    
>    The EFI firmware on Macs contains a full-fledged network stack for
>    downloading OS X images from osrecovery.apple.com. Unfortunately
>    on Macs introduced 2011 and 2012, EFI brings up the Broadcom 4331
>    wireless card on every boot and leaves it enabled even after
>    ExitBootServices has been called. The card continues to assert its IRQ
>    line, causing spurious interrupts if the IRQ is shared. It also corrupts
>    memory by DMAing received packets, allowing for remote code execution
>    over the air. This only stops when a driver is loaded for the wireless
>    card, which may be never if the driver is not installed or blacklisted.
>    
>    The issue seems to be constrained to the Broadcom 4331. Chris Milsted
>    has verified that the newer Broadcom 4360 built into the MacBookPro11,3
>    (2013/2014) does not exhibit this behaviour. The chances that Apple will
>    ever supply a firmware fix for the older machines appear to be zero.
>    
>    The solution is to reset the card on boot by writing to a reset bit in
>    its mmio space. This must be done as an early quirk and not as a plain
>    vanilla PCI quirk to successfully combat memory corruption by DMAed
>    packets: Matthew Garrett found out in 2012 that the packets are written
>    to EfiBootServicesData memory (http://mjg59.dreamwidth.org/11235.html).
>    This type of memory is made available to the page allocator by
>    efi_free_boot_services(). Plain vanilla PCI quirks run much later, in
>    subsys initcall level. In-between a time window would be open for memory
>    corruption. Random crashes occurring in this time window and attributed
>    to DMAed packets have indeed been observed in the wild by Chris
>    Bainbridge.
>    
>    When Matthew Garrett analyzed the memory corruption issue in 2012, he
>    sought to fix it with a grub quirk which transitions the card to D3hot:
>    http://git.savannah.gnu.org/cgit/grub.git/commit/?id=9d34bb85da56
>    
>    This approach does not help users with other bootloaders and while it
>    may prevent DMAed packets, it does not cure the spurious interrupts
>    emanating from the card. Unfortunately the card's mmio space is
>    inaccessible in D3hot, so to reset it, we have to undo the effect of
>    Matthew's grub patch and transition the card back to D0.
>    
>    Note that the quirk takes a few shortcuts to reduce the amount of code:
>    The size of BAR 0 and the location of the PM capability is identical
>    on all affected machines and therefore hardcoded. Only the address of
>    BAR 0 differs between models. Also, it is assumed that the BCMA core
>    currently mapped is the 802.11 core. The EFI driver seems to always take
>    care of this.
>    
>    Michael BÃ¼sch, Bjorn Helgaas and Matt Fleming contributed feedback
>    towards finding the best solution to this problem.
>    
>    The following should be a comprehensive list of affected models:
>        iMac13,1        2012  21.5"       [Root Port 00:1c.3 = 8086:1e16]
>        iMac13,2        2012  27"         [Root Port 00:1c.3 = 8086:1e16]
>        Macmini5,1      2011  i5 2.3 GHz  [Root Port 00:1c.1 = 8086:1c12]
>        Macmini5,2      2011  i5 2.5 GHz  [Root Port 00:1c.1 = 8086:1c12]
>        Macmini5,3      2011  i7 2.0 GHz  [Root Port 00:1c.1 = 8086:1c12]
>        Macmini6,1      2012  i5 2.5 GHz  [Root Port 00:1c.1 = 8086:1e12]
>        Macmini6,2      2012  i7 2.3 GHz  [Root Port 00:1c.1 = 8086:1e12]
>        MacBookPro8,1   2011  13"         [Root Port 00:1c.1 = 8086:1c12]
>        MacBookPro8,2   2011  15"         [Root Port 00:1c.1 = 8086:1c12]
>        MacBookPro8,3   2011  17"         [Root Port 00:1c.1 = 8086:1c12]
>        MacBookPro9,1   2012  15"         [Root Port 00:1c.1 = 8086:1e12]
>        MacBookPro9,2   2012  13"         [Root Port 00:1c.1 = 8086:1e12]
>        MacBookPro10,1  2012  15"         [Root Port 00:1c.1 = 8086:1e12]
>        MacBookPro10,2  2012  13"         [Root Port 00:1c.1 = 8086:1e12]
>    
>    For posterity, spurious interrupts caused by the Broadcom 4331 wireless
>    card resulted in splats like this (stacktrace omitted):
>    
>        irq 17: nobody cared (try booting with the "irqpoll" option)
>        handlers:
>        [<ffffffff81374370>] pcie_isr
>        [<ffffffffc0704550>] sdhci_irq [sdhci] threaded [<ffffffffc07013c0>] sdhci_thread_irq [sdhci]
>        [<ffffffffc0a0b960>] azx_interrupt [snd_hda_codec]
>        Disabling IRQ #17
>    
>    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79301
>    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=111781
>    Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=728916
>    Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=895951#c16
>    Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1009819
>    Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1098621
>    Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1149632#c5
>    Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1279130
>    Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1332732
>    Tested-by: Konstantin Simanov <k.simanov@stlk.ru>        # [MacBookPro8,1]
>    Tested-by: Lukas Wunner <lukas@wunner.de>                # [MacBookPro9,1]
>    Tested-by: Bryan Paradis <bryan.paradis@gmail.com>       # [MacBookPro9,2]
>    Tested-by: Andrew Worsley <amworsley@gmail.com>          # [MacBookPro10,1]
>    Tested-by: Chris Bainbridge <chris.bainbridge@gmail.com> # [MacBookPro10,2]
>    Signed-off-by: Lukas Wunner <lukas@wunner.de>
>    Acked-by: RafaÅ MiÅecki <zajec5@gmail.com>
>    Acked-by: Matt Fleming <matt@codeblueprint.co.uk>
>    Cc: Andy Lutomirski <luto@kernel.org>
>    Cc: Bjorn Helgaas <bhelgaas@google.com>
>    Cc: Borislav Petkov <bp@alien8.de>
>    Cc: Brian Gerst <brgerst@gmail.com>
>    Cc: Chris Milsted <cmilsted@redhat.com>
>    Cc: Denys Vlasenko <dvlasenk@redhat.com>
>    Cc: H. Peter Anvin <hpa@zytor.com>
>    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Matthew Garrett <mjg59@srcf.ucam.org>
>    Cc: Michael Buesch <m@bues.ch>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Cc: Yinghai Lu <yinghai@kernel.org>
>    Cc: b43-dev@lists.infradead.org
>    Cc: linux-pci@vger.kernel.org
>    Cc: linux-wireless@vger.kernel.org
>    Cc: stable@vger.kernel.org
>    Cc: stable@vger.kernel.org # 123456789abc: x86/quirks: Apply nvidia_bugs quirk only on root bus
>    Cc: stable@vger.kernel.org # 123456789abc: x86/quirks: Reintroduce scanning of secondary buses
>    Link: http://lkml.kernel.org/r/48d0972ac82a53d460e5fce77a07b2560db95203.1465690253.git.lukas@wunner.de
>    [ Did minor readability edits. ]
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 25334066b50e2bd08aaec68701a10be3544e0e02
>Author: Dmitri Epshtein <dima@marvell.com>
>Date:   Wed Jul 6 04:18:58 2016 +0200
>
>    net: mvneta: set real interrupt per packet for tx_done
>    
>    [ Upstream commit 06708f81528725148473c0869d6af5f809c6824b ]
>    
>    Commit aebea2ba0f74 ("net: mvneta: fix Tx interrupt delay") intended to
>    set coalescing threshold to a value guaranteeing interrupt generation
>    per each sent packet, so that buffers can be released with no delay.
>    
>    In fact setting threshold to '1' was wrong, because it causes interrupt
>    every two packets. According to the documentation a reason behind it is
>    following - interrupt occurs once sent buffers counter reaches a value,
>    which is higher than one specified in MVNETA_TXQ_SIZE_REG(q). This
>    behavior was confirmed during tests. Also when testing the SoC working
>    as a NAS device, better performance was observed with int-per-packet,
>    as it strongly depends on the fact that all transmitted packets are
>    released immediately.
>    
>    This commit enables NETA controller work in interrupt per sent packet mode
>    by setting coalescing threshold to 0.
>    
>    Signed-off-by: Dmitri Epshtein <dima@marvell.com>
>    Signed-off-by: Marcin Wojtas <mw@semihalf.com>
>    Cc: <stable@vger.kernel.org> # v3.10+
>    Fixes aebea2ba0f74 ("net: mvneta: fix Tx interrupt delay")
>    Acked-by: Willy Tarreau <w@1wt.eu>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 43506e749d3f8d7e012a1bc4cb57b18a03ecfee6
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Fri Jul 8 08:23:43 2016 +0200
>
>    ALSA: pcm: Free chmap at PCM free callback, too
>    
>    [ Upstream commit a8ff48cb70835f48de5703052760312019afea55 ]
>    
>    The chmap ctls assigned to PCM streams are freed in the PCM disconnect
>    callback.  However, since the disconnect callback isn't called when
>    the card gets freed before registering, the chmap ctls may still be
>    left assigned.  They are eventually freed together with other ctls,
>    but it may cause an Oops at pcm_chmap_ctl_private_free(), as the
>    function refers to the assigned PCM stream, while the PCM objects have
>    been already freed beforehand.
>    
>    The fix is to free the chmap ctls also at PCM free callback, not only
>    at PCM disconnect.
>    
>    Reported-by: Laxminath Kasam <b_lkasam@codeaurora.org>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 6b9d5616a24c26bd4a1c8e1a942241d03b102f76
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Fri Jul 8 08:05:19 2016 +0200
>
>    ALSA: ctl: Stop notification after disconnection
>    
>    [ Upstream commit f388cdcdd160687c6650833f286b9c89c50960ff ]
>    
>    snd_ctl_remove() has a notification for the removal event.  It's
>    superfluous when done during the device got disconnected.  Although
>    the notification itself is mostly harmless, it may potentially be
>    harmful, and should be suppressed.  Actually some components PCM may
>    free ctl elements during the disconnect or free callbacks, thus it's
>    no theoretical issue.
>    
>    This patch adds the check of card->shutdown flag for avoiding
>    unnecessary notifications after (or during) the disconnect.
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit fb1048540ec927d95acee9e08e96b064c08427e3
>Author: Hui Wang <hui.wang@canonical.com>
>Date:   Fri Jul 8 14:26:57 2016 +0800
>
>    ALSA: hda/realtek - add new pin definition in alc225 pin quirk table
>    
>    [ Upstream commit 8a132099f080d7384bb6ab4cc168f76cb4b47d08 ]
>    
>    We have some Dell laptops which can't detect headset mic, the machines
>    use the codec ALC225, they have some new pin configuration values,
>    after adding them in the alc225 pin quirk table, they work well.
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Hui Wang <hui.wang@canonical.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 31534f8fead7e0dff7ba68bd5dfcf6a9dfe908bc
>Author: Vivek Goyal <vgoyal@redhat.com>
>Date:   Fri Jul 1 16:34:25 2016 -0400
>
>    ovl: Copy up underlying inode's ->i_mode to overlay inode
>    
>    [ Upstream commit 07a2daab49c549a37b5b744cbebb6e3f445f12bc ]
>    
>    Right now when a new overlay inode is created, we initialize overlay
>    inode's ->i_mode from underlying inode ->i_mode but we retain only
>    file type bits (S_IFMT) and discard permission bits.
>    
>    This patch changes it and retains permission bits too. This should allow
>    overlay to do permission checks on overlay inode itself in task context.
>    
>    [SzM] It also fixes clearing suid/sgid bits on write.
>    
>    Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
>    Reported-by: Eryu Guan <eguan@redhat.com>
>    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
>    Fixes: 4bacc9c9234c ("overlayfs: Make f_path always point to the overlay and f_inode to the underlay")
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit cb75f65fe798bcac694f6bde299c52d31bdc8e96
>Author: Miklos Szeredi <mszeredi@redhat.com>
>Date:   Mon Jul 4 16:49:48 2016 +0200
>
>    ovl: handle ATTR_KILL*
>    
>    [ Upstream commit 51234eac5dd8b5feda9a3a8fa766f5398ecf91e3 ]
>    
>    commit b99c2d913810e56682a538c9f2394d76fca808f8 upstream.
>    
>    Before 4bacc9c9234c ("overlayfs: Make f_path...") file->f_path pointed to
>    the underlying file, hence suid/sgid removal on write worked fine.
>    
>    After that patch file->f_path pointed to the overlay file, and the file
>    mode bits weren't copied to overlay_inode->i_mode.  So the suid/sgid
>    removal simply stopped working.
>    
>    The fix is to copy the mode bits, but then ovl_setattr() needs to clear
>    ATTR_MODE to avoid the BUG() in notify_change().  So do this first, then in
>    the next patch copy the mode.
>    
>    Reported-by: Eryu Guan <eguan@redhat.com>
>    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
>    Fixes: 4bacc9c9234c ("overlayfs: Make f_path always point to the overlay and f_inode to the underlay")
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 97f28872a3148fb589125507e757163fef6a0b9b
>Author: Sinclair Yeh <syeh@vmware.com>
>Date:   Wed Jun 29 12:58:49 2016 -0700
>
>    drm/ttm: Make ttm_bo_mem_compat available
>    
>    [ Upstream commit 94477bff390aa4612d2332c8abafaae0a13d6923 ]
>    
>    There are cases where it is desired to see if a proposed placement
>    is compatible with a buffer object before calling ttm_bo_validate().
>    
>    Signed-off-by: Sinclair Yeh <syeh@vmware.com>
>    Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
>    Cc: <stable@vger.kernel.org>
>    ---
>    This is the first of a 3-patch series to fix a black screen
>    issue observed on Ubuntu 16.04 server.
>    
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 07761df8a174a27d498d87f0000409603627bb3c
>Author: Cameron Gutman <aicommander@gmail.com>
>Date:   Wed Jun 29 09:51:35 2016 -0700
>
>    Input: xpad - validate USB endpoint count during probe
>    
>    [ Upstream commit caca925fca4fb30c67be88cacbe908eec6721e43 ]
>    
>    This prevents a malicious USB device from causing an oops.
>    
>    Signed-off-by: Cameron Gutman <aicommander@gmail.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 70aaf49b1e719d3d25b9480a151133d00da00f49
>Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>Date:   Thu Jun 16 15:42:25 2016 +0200
>
>    ARM: mvebu: fix HW I/O coherency related deadlocks
>    
>    [ Upstream commit c5379ba8fccd99d5f99632c789f0393d84a57805 ]
>    
>    Until now, our understanding for HW I/O coherency to work on the
>    Cortex-A9 based Marvell SoC was that only the PCIe regions should be
>    mapped strongly-ordered. However, we were still encountering some
>    deadlocks, especially when testing the CESA crypto engine. After
>    checking with the HW designers, it was concluded that all the MMIO
>    registers should be mapped as strongly ordered for the HW I/O coherency
>    mechanism to work properly.
>    
>    This fixes some easy to reproduce deadlocks with the CESA crypto engine
>    driver (dmcrypt on a sufficiently large disk partition).
>    
>    Tested-by: Terry Stockert <stockert@inkblotadmirer.me>
>    Tested-by: Romain Perier <romain.perier@free-electrons.com>
>    Cc: Terry Stockert <stockert@inkblotadmirer.me>
>    Cc: Romain Perier <romain.perier@free-electrons.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>    Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 2686f12b26e217befd88357cf84e78d0ab3c86a1
>Author: Florian Westphal <fw@strlen.de>
>Date:   Wed Aug 3 11:31:54 2016 -0400
>
>    netfilter: x_tables: speed up jump target validation
>    
>    [ Upstream commit f4dc77713f8016d2e8a3295e1c9c53a21f296def ]
>    
>    The dummy ruleset I used to test the original validation change was broken,
>    most rules were unreachable and were not tested by mark_source_chains().
>    
>    In some cases rulesets that used to load in a few seconds now require
>    several minutes.
>    
>    sample ruleset that shows the behaviour:
>    
>    echo "*filter"
>    for i in $(seq 0 100000);do
>            printf ":chain_%06x - [0:0]\n" $i
>    done
>    for i in $(seq 0 100000);do
>       printf -- "-A INPUT -j chain_%06x\n" $i
>       printf -- "-A INPUT -j chain_%06x\n" $i
>       printf -- "-A INPUT -j chain_%06x\n" $i
>    done
>    echo COMMIT
>    
>    [ pipe result into iptables-restore ]
>    
>    This ruleset will be about 74mbyte in size, with ~500k searches
>    though all 500k[1] rule entries. iptables-restore will take forever
>    (gave up after 10 minutes)
>    
>    Instead of always searching the entire blob for a match, fill an
>    array with the start offsets of every single ipt_entry struct,
>    then do a binary search to check if the jump target is present or not.
>    
>    After this change ruleset restore times get again close to what one
>    gets when reverting 36472341017529e (~3 seconds on my workstation).
>    
>    [1] every user-defined rule gets an implicit RETURN, so we get
>    300k jumps + 100k userchains + 100k returns -> 500k rule entries
>    
>    Fixes: 36472341017529e ("netfilter: x_tables: validate targets of jumps")
>    Reported-by: Jeff Wu <wujiafu@gmail.com>
>    Tested-by: Jeff Wu <wujiafu@gmail.com>
>    Signed-off-by: Florian Westphal <fw@strlen.de>
>    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit c3ed55b836cff718dd0d654b6daf7c96be2a5ac2
>Author: Sasha Levin <alexander.levin@verizon.com>
>Date:   Fri Jul 29 21:39:34 2016 -0400
>
>    Linux 4.1.29
>    
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 74225a4cbea38034034add5da67a2f7ee23251c0
>Author: Steven Rostedt <rostedt@goodmis.org>
>Date:   Thu Jul 14 17:55:21 2016 -0400
>
>    4.1.28 Fix bad backport of 8f182270dfec "mm/swap.c: flush lru pvecs on compound page arrival"
>    
>    When I pulled in 4.1.28 into my stable 4.1-rt tree and ran the tests,
>    it crashed with a severe OOM killing everything. I then tested 4.1.28
>    without -rt and it had the same issue. I did a bisect between 4.1.27
>    and 4.1.28 and found that the bug started at:
>    
>    commit 8f182270dfec "mm/swap.c: flush lru pvecs on compound page
>    arrival"
>    
>    Looking at that patch and what's in mainline, I see that there's a
>    mismatch in one of the hunks:
>    
>    Mainline:
>    
>    @@ -391,9 +391,8 @@ static void __lru_cache_add(struct page *page)
>            struct pagevec *pvec = &get_cpu_var(lru_add_pvec);
>    
>            get_page(page);
>    -       if (!pagevec_space(pvec))
>    +       if (!pagevec_add(pvec, page) || PageCompound(page))
>                    __pagevec_lru_add(pvec);
>    -       pagevec_add(pvec, page);
>            put_cpu_var(lru_add_pvec);
>     }
>    
>    Stable 4.1.28:
>    
>    @@ -631,9 +631,8 @@ static void __lru_cache_add(struct page *page)
>            struct pagevec *pvec = &get_cpu_var(lru_add_pvec);
>    
>            page_cache_get(page);
>    -       if (!pagevec_space(pvec))
>    +       if (!pagevec_space(pvec) || PageCompound(page))
>                    __pagevec_lru_add(pvec);
>    -       pagevec_add(pvec, page);
>            put_cpu_var(lru_add_pvec);
>     }
>    
>    Where mainline replace pagevec_space() with pagevec_add, and stable did
>    not.
>    
>    Fixing this makes the OOM go away.
>    
>    Note, 3.18 has the same bug.
>    
>    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 62d7a4540e294d77c7c758ce7cd73264ba461fa8
>Author: Michael Ellerman <mpe@ellerman.id.au>
>Date:   Thu Jul 14 21:10:37 2016 +1000
>
>    powerpc: Fix build break due to missing PPC_FEATURE2_HTM_NOSC
>    
>    The backport of 4705e02498d6 ("powerpc: Update TM user feature bits in
>    scan_features()") (f49eb503f0f9), missed the fact that 4.1 doesn't
>    include the commit that added PPC_FEATURE2_HTM_NOSC.
>    
>    The correct fix is simply to omit PPC_FEATURE2_HTM_NOSC.
>    
>    Fixes: f49eb503f0f9 ("powerpc: Update TM user feature bits in scan_features()")
>    Reported-by: Christian Zigotzky <chzigotzky@bayern-mail.de>
>    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit bda373bb186b027786681f930959deb56f4de01b
>Author: Jeff Mahoney <jeffm@suse.com>
>Date:   Tue Jul 5 17:32:30 2016 -0400
>
>    ecryptfs: don't allow mmap when the lower fs doesn't support it
>    
>    [ Upstream commit f0fe970df3838c202ef6c07a4c2b36838ef0a88b ]
>    
>    There are legitimate reasons to disallow mmap on certain files, notably
>    in sysfs or procfs.  We shouldn't emulate mmap support on file systems
>    that don't offer support natively.
>    
>    CVE-2016-1583
>    
>    Signed-off-by: Jeff Mahoney <jeffm@suse.com>
>    Cc: stable@vger.kernel.org
>    [tyhicks: clean up f_op check by using ecryptfs_file_to_lower()]
>    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
>    
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit db86fac6fe0f05f02be9fbc5fcfa236f3209076c
>Author: Jan Beulich <JBeulich@suse.com>
>Date:   Fri Jul 8 06:15:07 2016 -0600
>
>    xen/acpi: allow xen-acpi-processor driver to load on Xen 4.7
>    
>    [ Upstream commit 6f2d9d99213514360034c6d52d2c3919290b3504 ]
>    
>    As of Xen 4.7 PV CPUID doesn't expose either of CPUID[1].ECX[7] and
>    CPUID[0x80000007].EDX[7] anymore, causing the driver to fail to load on
>    both Intel and AMD systems. Doing any kind of hardware capability
>    checks in the driver as a prerequisite was wrong anyway: With the
>    hypervisor being in charge, all such checking should be done by it. If
>    ACPI data gets uploaded despite some missing capability, the hypervisor
>    is free to ignore part or all of that data.
>    
>    Ditch the entire check_prereq() function, and do the only valid check
>    (xen_initial_domain()) in the caller in its place.
>    
>    Signed-off-by: Jan Beulich <jbeulich@suse.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit cd12064452e872ce0895450007f7820cd21422e8
>Author: Jan Beulich <JBeulich@suse.com>
>Date:   Thu Jul 7 01:32:04 2016 -0600
>
>    xenbus: don't bail early from xenbus_dev_request_and_reply()
>    
>    [ Upstream commit 7469be95a487319514adce2304ad2af3553d2fc9 ]
>    
>    xenbus_dev_request_and_reply() needs to track whether a transaction is
>    open.  For XS_TRANSACTION_START messages it calls transaction_start()
>    and for XS_TRANSACTION_END messages it calls transaction_end().
>    
>    If sending an XS_TRANSACTION_START message fails or responds with an
>    an error, the transaction is not open and transaction_end() must be
>    called.
>    
>    If sending an XS_TRANSACTION_END message fails, the transaction is
>    still open, but if an error response is returned the transaction is
>    closed.
>    
>    Commit 027bd7e89906 ("xen/xenbus: Avoid synchronous wait on XenBus
>    stalling shutdown/restart") introduced a regression where failed
>    XS_TRANSACTION_START messages were leaving the transaction open.  This
>    can cause problems with suspend (and migration) as all transactions
>    must be closed before suspending.
>    
>    It appears that the problematic change was added accidentally, so just
>    remove it.
>    
>    Signed-off-by: Jan Beulich <jbeulich@suse.com>
>    Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit f1e8b05914912c9a6309c450f266aa21d5667524
>Author: Jeff Mahoney <jeffm@suse.com>
>Date:   Tue Jul 5 17:32:29 2016 -0400
>
>    Revert "ecryptfs: forbid opening files without mmap handler"
>    
>    [ Upstream commit 78c4e172412de5d0456dc00d2b34050aa0b683b5 ]
>    
>    This reverts commit 2f36db71009304b3f0b95afacd8eba1f9f046b87.
>    
>    It fixed a local root exploit but also introduced a dependency on
>    the lower file system implementing an mmap operation just to open a file,
>    which is a bit of a heavy hammer.  The right fix is to have mmap depend
>    on the existence of the mmap handler instead.
>    
>    Signed-off-by: Jeff Mahoney <jeffm@suse.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 9c9497d5b1e93187ea6c0cdca3f3706fd7713acf
>Author: Jan Beulich <JBeulich@suse.com>
>Date:   Thu Jul 7 01:23:57 2016 -0600
>
>    xenbus: don't BUG() on user mode induced condition
>    
>    [ Upstream commit 0beef634b86a1350c31da5fcc2992f0d7c8a622b ]
>    
>    Inability to locate a user mode specified transaction ID should not
>    lead to a kernel crash. For other than XS_TRANSACTION_START also
>    don't issue anything to xenbus if the specified ID doesn't match that
>    of any active transaction.
>    
>    Signed-off-by: Jan Beulich <jbeulich@suse.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit f0d077da72f315e295d3a669af275edf608631b1
>Author: David Daney <david.daney@cavium.com>
>Date:   Thu Jun 16 15:50:31 2016 -0700
>
>    MIPS: Fix page table corruption on THP permission changes.
>    
>    [ Upstream commit 88d02a2ba6c52350f9a73ff1b01a5be839c3ca17 ]
>    
>    When the core THP code is modifying the permissions of a huge page it
>    calls pmd_modify(), which unfortunately was clearing the _PAGE_HUGE bit
>    of the page table entry.  The result can be kernel messages like:
>    
>    mm/memory.c:397: bad pmd 000000040080004d.
>    mm/memory.c:397: bad pmd 00000003ff00004d.
>    mm/memory.c:397: bad pmd 000000040100004d.
>    
>    or:
>    
>    ------------[ cut here ]------------
>    WARNING: at mm/mmap.c:3200 exit_mmap+0x150/0x158()
>    Modules linked in: ipv6 at24 octeon3_ethernet octeon_srio_nexus m25p80
>    CPU: 12 PID: 1295 Comm: pmderr Not tainted 3.10.87-rt80-Cavium-Octeon #4
>    Stack : 0000000040808000 0000000014009ce1 0000000000400004 ffffffff81076ba0
>              0000000000000000 0000000000000000 ffffffff85110000 0000000000000119
>              0000000000000004 0000000000000000 0000000000000119 43617669756d2d4f
>              0000000000000000 ffffffff850fda40 ffffffff85110000 0000000000000000
>              0000000000000000 0000000000000009 ffffffff809207a0 0000000000000c80
>              ffffffff80f1bf20 0000000000000001 000000ffeca36828 0000000000000001
>              0000000000000000 0000000000000001 000000ffeca7e700 ffffffff80886924
>              80000003fd7a0000 80000003fd7a39b0 80000003fdea8000 ffffffff80885780
>              80000003fdea8000 ffffffff80f12218 000000000000000c 000000000000050f
>              0000000000000000 ffffffff80865c4c 0000000000000000 0000000000000000
>              ...
>    Call Trace:
>    [<ffffffff80865c4c>] show_stack+0x6c/0xf8
>    [<ffffffff80885780>] warn_slowpath_common+0x78/0xa8
>    [<ffffffff809207a0>] exit_mmap+0x150/0x158
>    [<ffffffff80882d44>] mmput+0x5c/0x110
>    [<ffffffff8088b450>] do_exit+0x230/0xa68
>    [<ffffffff8088be34>] do_group_exit+0x54/0x1d0
>    [<ffffffff8088bfc0>] __wake_up_parent+0x0/0x18
>    
>    ---[ end trace c7b38293191c57dc ]---
>    BUG: Bad rss-counter state mm:80000003fa168000 idx:1 val:1536
>    
>    Fix by not clearing _PAGE_HUGE bit.
>    
>    Signed-off-by: David Daney <david.daney@cavium.com>
>    Tested-by: Aaro Koskinen <aaro.koskinen@nokia.com>
>    Cc: stable@vger.kernel.org
>    Cc: linux-mips@linux-mips.org
>    Patchwork: https://patchwork.linux-mips.org/patch/13687/
>    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit ebccd6ec99c6c0eff28849b262929472ca47ee8d
>Author: Torsten Hilbrich <torsten.hilbrich@secunet.com>
>Date:   Tue Jul 5 10:40:22 2016 +0200
>
>    ALSA: hda/realtek: Add Lenovo L460 to docking unit fixup
>    
>    [ Upstream commit 9cd25743765cfe851aed8d655a62d60156aed293 ]
>    
>    This solves the issue that a headphone is not working on the docking
>    unit.
>    
>    Signed-off-by: Torsten Hilbrich <torsten.hilbrich@secunet.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit df3f23d87fdbbb76f41949be380d1bdb094f033a
>Author: Ursula Braun <ubraun@linux.vnet.ibm.com>
>Date:   Mon Jul 4 14:07:16 2016 +0200
>
>    qeth: delete napi struct when removing a qeth device
>    
>    [ Upstream commit 7831b4ff0d926e0deeaabef9db8800ed069a2757 ]
>    
>    A qeth_card contains a napi_struct linked to the net_device during
>    device probing. This struct must be deleted when removing the qeth
>    device, otherwise Panic on oops can occur when qeth devices are
>    repeatedly removed and added.
>    
>    Fixes: a1c3ed4c9ca ("qeth: NAPI support for l2 and l3 discipline")
>    Cc: stable@vger.kernel.org # v2.6.37+
>    Signed-off-by: Ursula Braun <ubraun@linux.vnet.ibm.com>
>    Tested-by: Alexander Klein <ALKL@de.ibm.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 2c89e2e677535452251742a0b93da994a774e450
>Author: Colin Pitrat <colin.pitrat@gmail.com>
>Date:   Sat Jun 18 19:05:04 2016 +0100
>
>    gpio: sch: Fix Oops on module load on Asus Eee PC 1201
>    
>    [ Upstream commit 87041a58d3b19455d39baed2a5e5bb43b58fb915 ]
>    
>    This fixes the issue descirbe in bug 117531
>    (https://bugzilla.kernel.org/show_bug.cgi?id=117531).
>    It's a regression introduced in linux 4.5 that causes a Oops at load of
>    gpio_sch and prevents powering off the computer.
>    
>    The issue is that sch_gpio_reg_set is called in sch_gpio_probe before
>    gpio_chip data is initialized with the pointer to the sch_gpio struct. As
>    sch_gpio_reg_set calls gpiochip_get_data, it returns NULL which causes
>    the Oops.
>    
>    The patch follows Mika's advice (https://lkml.org/lkml/2016/5/9/61) and
>    consists in modifying sch_gpio_reg_get and sch_gpio_reg_set to take a
>    sch_gpio struct directly instead of a gpio_chip, which avoids the call to
>    gpiochip_get_data.
>    
>    Thanks Mika for your patience with me :-)
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Colin Pitrat <colin.pitrat@gmail.com>
>    Acked-by: Alexandre Courbot <acourbot@nvidia.com>
>    Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
>    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 1dd148a1b9beb04150bbd6deae2518b73bbe937c
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Mon Jul 4 14:02:15 2016 +0200
>
>    ALSA: timer: Fix negative queue usage by racy accesses
>    
>    [ Upstream commit 3fa6993fef634e05d200d141a85df0b044572364 ]
>    
>    The user timer tu->qused counter may go to a negative value when
>    multiple concurrent reads are performed since both the check and the
>    decrement of tu->qused are done in two individual locked contexts.
>    This results in bogus read outs, and the endless loop in the
>    user-space side.
>    
>    The fix is to move the decrement of the tu->qused counter into the
>    same spinlock context as the zero-check of the counter.
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 23c63b8c08fe3f0b21594ee1ac4de0fa52225f79
>Author: Omar Sandoval <osandov@fb.com>
>Date:   Fri Jul 1 00:39:35 2016 -0700
>
>    block: fix use-after-free in sys_ioprio_get()
>    
>    [ Upstream commit 8ba8682107ee2ca3347354e018865d8e1967c5f4 ]
>    
>    get_task_ioprio() accesses the task->io_context without holding the task
>    lock and thus can race with exit_io_context(), leading to a
>    use-after-free. The reproducer below hits this within a few seconds on
>    my 4-core QEMU VM:
>    
>    #define _GNU_SOURCE
>    #include <assert.h>
>    #include <unistd.h>
>    #include <sys/syscall.h>
>    #include <sys/wait.h>
>    
>    int main(int argc, char **argv)
>    {
>    	pid_t pid, child;
>    	long nproc, i;
>    
>    	/* ioprio_set(IOPRIO_WHO_PROCESS, 0, IOPRIO_PRIO_VALUE(IOPRIO_CLASS_IDLE, 0)); */
>    	syscall(SYS_ioprio_set, 1, 0, 0x6000);
>    
>    	nproc = sysconf(_SC_NPROCESSORS_ONLN);
>    
>    	for (i = 0; i < nproc; i++) {
>    		pid = fork();
>    		assert(pid != -1);
>    		if (pid == 0) {
>    			for (;;) {
>    				pid = fork();
>    				assert(pid != -1);
>    				if (pid == 0) {
>    					_exit(0);
>    				} else {
>    					child = wait(NULL);
>    					assert(child == pid);
>    				}
>    			}
>    		}
>    
>    		pid = fork();
>    		assert(pid != -1);
>    		if (pid == 0) {
>    			for (;;) {
>    				/* ioprio_get(IOPRIO_WHO_PGRP, 0); */
>    				syscall(SYS_ioprio_get, 2, 0);
>    			}
>    		}
>    	}
>    
>    	for (;;) {
>    		/* ioprio_get(IOPRIO_WHO_PGRP, 0); */
>    		syscall(SYS_ioprio_get, 2, 0);
>    	}
>    
>    	return 0;
>    }
>    
>    This gets us KASAN dumps like this:
>    
>    [   35.526914] ==================================================================
>    [   35.530009] BUG: KASAN: out-of-bounds in get_task_ioprio+0x7b/0x90 at addr ffff880066f34e6c
>    [   35.530009] Read of size 2 by task ioprio-gpf/363
>    [   35.530009] =============================================================================
>    [   35.530009] BUG blkdev_ioc (Not tainted): kasan: bad access detected
>    [   35.530009] -----------------------------------------------------------------------------
>    
>    [   35.530009] Disabling lock debugging due to kernel taint
>    [   35.530009] INFO: Allocated in create_task_io_context+0x2b/0x370 age=0 cpu=0 pid=360
>    [   35.530009] 	___slab_alloc+0x55d/0x5a0
>    [   35.530009] 	__slab_alloc.isra.20+0x2b/0x40
>    [   35.530009] 	kmem_cache_alloc_node+0x84/0x200
>    [   35.530009] 	create_task_io_context+0x2b/0x370
>    [   35.530009] 	get_task_io_context+0x92/0xb0
>    [   35.530009] 	copy_process.part.8+0x5029/0x5660
>    [   35.530009] 	_do_fork+0x155/0x7e0
>    [   35.530009] 	SyS_clone+0x19/0x20
>    [   35.530009] 	do_syscall_64+0x195/0x3a0
>    [   35.530009] 	return_from_SYSCALL_64+0x0/0x6a
>    [   35.530009] INFO: Freed in put_io_context+0xe7/0x120 age=0 cpu=0 pid=1060
>    [   35.530009] 	__slab_free+0x27b/0x3d0
>    [   35.530009] 	kmem_cache_free+0x1fb/0x220
>    [   35.530009] 	put_io_context+0xe7/0x120
>    [   35.530009] 	put_io_context_active+0x238/0x380
>    [   35.530009] 	exit_io_context+0x66/0x80
>    [   35.530009] 	do_exit+0x158e/0x2b90
>    [   35.530009] 	do_group_exit+0xe5/0x2b0
>    [   35.530009] 	SyS_exit_group+0x1d/0x20
>    [   35.530009] 	entry_SYSCALL_64_fastpath+0x1a/0xa4
>    [   35.530009] INFO: Slab 0xffffea00019bcd00 objects=20 used=4 fp=0xffff880066f34ff0 flags=0x1fffe0000004080
>    [   35.530009] INFO: Object 0xffff880066f34e58 @offset=3672 fp=0x0000000000000001
>    [   35.530009] ==================================================================
>    
>    Fix it by grabbing the task lock while we poke at the io_context.
>    
>    Cc: stable@vger.kernel.org
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Signed-off-by: Omar Sandoval <osandov@fb.com>
>    Signed-off-by: Jens Axboe <axboe@fb.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 784110017ee4dc5e9bbbe29a712993803afdb3fd
>Author: Borislav Petkov <bp@suse.de>
>Date:   Thu Jun 16 19:13:49 2016 +0200
>
>    x86/amd_nb: Fix boot crash on non-AMD systems
>    
>    [ Upstream commit 1ead852dd88779eda12cb09cc894a03d9abfe1ec ]
>    
>    Fix boot crash that triggers if this driver is built into a kernel and
>    run on non-AMD systems.
>    
>    AMD northbridges users call amd_cache_northbridges() and it returns
>    a negative value to signal that we weren't able to cache/detect any
>    northbridges on the system.
>    
>    At least, it should do so as all its callers expect it to do so. But it
>    does return a negative value only when kmalloc() fails.
>    
>    Fix it to return -ENODEV if there are no NBs cached as otherwise, amd_nb
>    users like amd64_edac, for example, which relies on it to know whether
>    it should load or not, gets loaded on systems like Intel Xeons where it
>    shouldn't.
>    
>    Reported-and-tested-by: Tony Battersby <tonyb@cybernetics.com>
>    Signed-off-by: Borislav Petkov <bp@suse.de>
>    Cc: <stable@vger.kernel.org>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Link: http://lkml.kernel.org/r/1466097230-5333-2-git-send-email-bp@alien8.de
>    Link: https://lkml.kernel.org/r/5761BEB0.9000807@cybernetics.com
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 9a6bc7f995b444b0a70f6d897a7f94fbb519f92a
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Wed Jun 29 15:23:08 2016 +0200
>
>    ALSA: au88x0: Fix calculation in vortex_wtdma_bufshift()
>    
>    [ Upstream commit 62db7152c924e4c060e42b34a69cd39658e8a0dc ]
>    
>    vortex_wtdma_bufshift() function does calculate the page index
>    wrongly, first masking then shift, which always results in zero.
>    The proper computation is to first shift, then mask.
>    
>    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 9e0303eb05f9c4f8920570a4b047e2ae3a7964eb
>Author: Brian King <brking@linux.vnet.ibm.com>
>Date:   Mon Jun 27 09:09:40 2016 -0500
>
>    ipr: Clear interrupt on croc/crocodile when running with LSI
>    
>    [ Upstream commit 54e430bbd490e18ab116afa4cd90dcc45787b3df ]
>    
>    If we fall back to using LSI on the Croc or Crocodile chip we need to
>    clear the interrupt so we don't hang the system.
>    
>    Cc: <stable@vger.kernel.org>
>    Tested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>    Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
>    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 029161e90ca98d024061cb50b0934b1ea06046b5
>Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
>Date:   Mon Jun 27 21:06:51 2016 +0200
>
>    ALSA: echoaudio: Fix memory allocation
>    
>    [ Upstream commit 9c6795a9b3cbb56a9fbfaf43909c5c22999ba317 ]
>    
>    'commpage_bak' is allocated with 'sizeof(struct echoaudio)' bytes.
>    We then copy 'sizeof(struct comm_page)' bytes in it.
>    On my system, smatch complains because one is 2960 and the other is 3072.
>    
>    This would result in memory corruption or a oops.
>    
>    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 1f96a54ce5861b18d3d59095f1b5d06cfddacd6c
>Author: Bob Copeland <me@bobcopeland.com>
>Date:   Sat Jun 25 07:58:45 2016 -0400
>
>    ALSA: hda - fix read before array start
>    
>    [ Upstream commit 81e43960dce1c8e58e682fb3ec26c1d8f83a9afc ]
>    
>    UBSAN reports the following warning from accessing path->path[-1]
>    in set_path_power():
>    
>    [   16.078040] ================================================================================
>    [   16.078124] UBSAN: Undefined behaviour in sound/pci/hda/hda_generic.c:3981:17
>    [   16.078198] index -1 is out of range for type 'hda_nid_t [10]'
>    [   16.078270] CPU: 2 PID: 1738 Comm: modprobe Not tainted 4.7.0-rc1-wt+ #47
>    [   16.078274] Hardware name: LENOVO 3443CTO/3443CTO, BIOS G6ET23WW (1.02 ) 08/14/2012
>    [   16.078278]  ffff8800cb246000 ffff8800cb3638b8 ffffffff815c4fe3 0000000000000032
>    [   16.078286]  ffff8800cb3638e0 ffffffffffffffff ffff8800cb3638d0 ffffffff8162443d
>    [   16.078294]  ffffffffa0894200 ffff8800cb363920 ffffffff81624af7 0000000000000292
>    [   16.078302] Call Trace:
>    [   16.078311]  [<ffffffff815c4fe3>] dump_stack+0x86/0xd3
>    [   16.078317]  [<ffffffff8162443d>] ubsan_epilogue+0xd/0x40
>    [   16.078324]  [<ffffffff81624af7>] __ubsan_handle_out_of_bounds+0x67/0x70
>    [   16.078335]  [<ffffffffa087665f>] set_path_power+0x1bf/0x230 [snd_hda_codec_generic]
>    [   16.078344]  [<ffffffffa087880d>] add_pin_power_ctls+0x8d/0xc0 [snd_hda_codec_generic]
>    [   16.078352]  [<ffffffffa087f190>] ? pin_power_down_callback+0x20/0x20 [snd_hda_codec_generic]
>    [   16.078360]  [<ffffffffa0878947>] add_all_pin_power_ctls+0x107/0x150 [snd_hda_codec_generic]
>    [   16.078370]  [<ffffffffa08842b3>] snd_hda_gen_parse_auto_config+0x2d73/0x49e0 [snd_hda_codec_generic]
>    [   16.078376]  [<ffffffff81173360>] ? trace_hardirqs_on_caller+0x1b0/0x2c0
>    [   16.078390]  [<ffffffffa089df27>] alc_parse_auto_config+0x147/0x310 [snd_hda_codec_realtek]
>    [   16.078402]  [<ffffffffa08a332a>] patch_alc269+0x23a/0x560 [snd_hda_codec_realtek]
>    [   16.078417]  [<ffffffffa0838644>] hda_codec_driver_probe+0xa4/0x1a0 [snd_hda_codec]
>    [   16.078424]  [<ffffffff817bbac1>] driver_probe_device+0x101/0x380
>    [   16.078430]  [<ffffffff817bbdf9>] __driver_attach+0xb9/0x100
>    [   16.078438]  [<ffffffff817bbd40>] ? driver_probe_device+0x380/0x380
>    [   16.078444]  [<ffffffff817b8d20>] bus_for_each_dev+0x70/0xc0
>    [   16.078449]  [<ffffffff817bb087>] driver_attach+0x27/0x50
>    [   16.078454]  [<ffffffff817ba956>] bus_add_driver+0x166/0x2c0
>    [   16.078460]  [<ffffffffa0369000>] ? 0xffffffffa0369000
>    [   16.078465]  [<ffffffff817bd13d>] driver_register+0x7d/0x130
>    [   16.078477]  [<ffffffffa083816f>] __hda_codec_driver_register+0x6f/0x90 [snd_hda_codec]
>    [   16.078488]  [<ffffffffa036901e>] realtek_driver_init+0x1e/0x1000 [snd_hda_codec_realtek]
>    [   16.078493]  [<ffffffff8100215e>] do_one_initcall+0x4e/0x1d0
>    [   16.078499]  [<ffffffff8119f54d>] ? rcu_read_lock_sched_held+0x6d/0x80
>    [   16.078504]  [<ffffffff813701b1>] ? kmem_cache_alloc_trace+0x391/0x560
>    [   16.078510]  [<ffffffff812bb314>] ? do_init_module+0x28/0x273
>    [   16.078515]  [<ffffffff812bb387>] do_init_module+0x9b/0x273
>    [   16.078522]  [<ffffffff811e3782>] load_module+0x20b2/0x3410
>    [   16.078527]  [<ffffffff811df140>] ? m_show+0x210/0x210
>    [   16.078533]  [<ffffffff813b2b26>] ? kernel_read+0x66/0xe0
>    [   16.078541]  [<ffffffff811e4cfa>] SYSC_finit_module+0xba/0xc0
>    [   16.078547]  [<ffffffff811e4d1e>] SyS_finit_module+0xe/0x10
>    [   16.078552]  [<ffffffff81a860fc>] entry_SYSCALL_64_fastpath+0x1f/0xbd
>    [   16.078556] ================================================================================
>    
>    Fix by checking path->depth before use.
>    
>    Signed-off-by: Bob Copeland <me@bobcopeland.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
>
>commit 5880876e94699ce010554f483ccf0009997955ca
>Author: Sasha Levin <sasha.levin@oracle.com>
>Date:   Wed Jul 13 14:17:46 2016 -0400
>
>    Linux 4.1.28
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 116c75f642ad4a6d267f399c9f1fe8b91fb822c5
>Author: Hugh Dickins <hughd@google.com>
>Date:   Sun Jul 10 16:46:32 2016 -0700
>
>    tmpfs: fix regression hang in fallocate undo
>    
>    [ Upstream commit 7f556567036cb7f89aabe2f0954b08566b4efb53 ]
>    
>    The well-spotted fallocate undo fix is good in most cases, but not when
>    fallocate failed on the very first page.  index 0 then passes lend -1
>    to shmem_undo_range(), and that has two bad effects: (a) that it will
>    undo every fallocation throughout the file, unrestricted by the current
>    range; but more importantly (b) it can cause the undo to hang, because
>    lend -1 is treated as truncation, which makes it keep on retrying until
>    every page has gone, but those already fully instantiated will never go
>    away.  Big thank you to xfstests generic/269 which demonstrates this.
>    
>    Fixes: b9b4bb26af01 ("tmpfs: don't undo fallocate past its last page")
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Hugh Dickins <hughd@google.com>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b7aa372fec2c1d4a1fcf4398ae88ba94134b9522
>Author: Florian Westphal <fw@strlen.de>
>Date:   Fri Apr 1 15:37:59 2016 +0200
>
>    netfilter: x_tables: introduce and use xt_copy_counters_from_user
>    
>    [ Upstream commit d7591f0c41ce3e67600a982bab6989ef0f07b3ce ]
>    
>    The three variants use same copy&pasted code, condense this into a
>    helper and use that.
>    
>    Make sure info.name is 0-terminated.
>    
>    Signed-off-by: Florian Westphal <fw@strlen.de>
>    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit af815d264b7ed1cdceb0e1fdf4fa7d3bd5fe9a99
>Author: Florian Westphal <fw@strlen.de>
>Date:   Fri Apr 1 14:17:34 2016 +0200
>
>    netfilter: x_tables: do compat validation via translate_table
>    
>    [ Upstream commit 09d9686047dbbe1cf4faa558d3ecc4aae2046054 ]
>    
>    This looks like refactoring, but its also a bug fix.
>    
>    Problem is that the compat path (32bit iptables, 64bit kernel) lacks a few
>    sanity tests that are done in the normal path.
>    
>    For example, we do not check for underflows and the base chain policies.
>    
>    While its possible to also add such checks to the compat path, its more
>    copy&pastry, for instance we cannot reuse check_underflow() helper as
>    e->target_offset differs in the compat case.
>    
>    Other problem is that it makes auditing for validation errors harder; two
>    places need to be checked and kept in sync.
>    
>    At a high level 32 bit compat works like this:
>    1- initial pass over blob:
>       validate match/entry offsets, bounds checking
>       lookup all matches and targets
>       do bookkeeping wrt. size delta of 32/64bit structures
>       assign match/target.u.kernel pointer (points at kernel
>       implementation, needed to access ->compatsize etc.)
>    
>    2- allocate memory according to the total bookkeeping size to
>       contain the translated ruleset
>    
>    3- second pass over original blob:
>       for each entry, copy the 32bit representation to the newly allocated
>       memory.  This also does any special match translations (e.g.
>       adjust 32bit to 64bit longs, etc).
>    
>    4- check if ruleset is free of loops (chase all jumps)
>    
>    5-first pass over translated blob:
>       call the checkentry function of all matches and targets.
>    
>    The alternative implemented by this patch is to drop steps 3&4 from the
>    compat process, the translation is changed into an intermediate step
>    rather than a full 1:1 translate_table replacement.
>    
>    In the 2nd pass (step #3), change the 64bit ruleset back to a kernel
>    representation, i.e. put() the kernel pointer and restore ->u.user.name .
>    
>    This gets us a 64bit ruleset that is in the format generated by a 64bit
>    iptables userspace -- we can then use translate_table() to get the
>    'native' sanity checks.
>    
>    This has two drawbacks:
>    
>    1. we re-validate all the match and target entry structure sizes even
>    though compat translation is supposed to never generate bogus offsets.
>    2. we put and then re-lookup each match and target.
>    
>    THe upside is that we get all sanity tests and ruleset validations
>    provided by the normal path and can remove some duplicated compat code.
>    
>    iptables-restore time of autogenerated ruleset with 300k chains of form
>    -A CHAIN0001 -m limit --limit 1/s -j CHAIN0002
>    -A CHAIN0002 -m limit --limit 1/s -j CHAIN0003
>    
>    shows no noticeable differences in restore times:
>    old:   0m30.796s
>    new:   0m31.521s
>    64bit: 0m25.674s
>    
>    Signed-off-by: Florian Westphal <fw@strlen.de>
>    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2756b2a32469316c98a46359710ea2bfdbfe331e
>Author: Florian Westphal <fw@strlen.de>
>Date:   Fri Apr 1 14:17:33 2016 +0200
>
>    netfilter: x_tables: xt_compat_match_from_user doesn't need a retval
>    
>    [ Upstream commit 0188346f21e6546498c2a0f84888797ad4063fc5 ]
>    
>    Always returned 0.
>    
>    Signed-off-by: Florian Westphal <fw@strlen.de>
>    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 05e089b3a29c6c965fa9c8801ea72d21a959ca46
>Author: Florian Westphal <fw@strlen.de>
>Date:   Fri Apr 1 14:17:31 2016 +0200
>
>    netfilter: ip6_tables: simplify translate_compat_table args
>    
>    [ Upstream commit 329a0807124f12fe1c8032f95d8a8eb47047fb0e ]
>    
>    Signed-off-by: Florian Westphal <fw@strlen.de>
>    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit cd76c8c82c48ca6c1e3da1df7c1dca7f44302c65
>Author: Florian Westphal <fw@strlen.de>
>Date:   Fri Apr 1 14:17:30 2016 +0200
>
>    netfilter: ip_tables: simplify translate_compat_table args
>    
>    [ Upstream commit 7d3f843eed29222254c9feab481f55175a1afcc9 ]
>    
>    Signed-off-by: Florian Westphal <fw@strlen.de>
>    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7bdf4f49826159635b21516296be211f420eefac
>Author: Florian Westphal <fw@strlen.de>
>Date:   Fri Apr 1 14:17:32 2016 +0200
>
>    netfilter: arp_tables: simplify translate_compat_table args
>    
>    [ Upstream commit 8dddd32756f6fe8e4e82a63361119b7e2384e02f ]
>    
>    Signed-off-by: Florian Westphal <fw@strlen.de>
>    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d97246b5d16b77b57d835b6b4d1bde8ea6566b46
>Author: Florian Westphal <fw@strlen.de>
>Date:   Wed Jun 1 02:04:44 2016 +0200
>
>    netfilter: x_tables: don't reject valid target size on some architectures
>    
>    [ Upstream commit 7b7eba0f3515fca3296b8881d583f7c1042f5226 ]
>    
>    Quoting John Stultz:
>      In updating a 32bit arm device from 4.6 to Linus' current HEAD, I
>      noticed I was having some trouble with networking, and realized that
>      /proc/net/ip_tables_names was suddenly empty.
>      Digging through the registration process, it seems we're catching on the:
>    
>       if (strcmp(t->u.user.name, XT_STANDARD_TARGET) == 0 &&
>           target_offset + sizeof(struct xt_standard_target) != next_offset)
>             return -EINVAL;
>    
>      Where next_offset seems to be 4 bytes larger then the
>      offset + standard_target struct size.
>    
>    next_offset needs to be aligned via XT_ALIGN (so we can access all members
>    of ip(6)t_entry struct).
>    
>    This problem didn't show up on i686 as it only needs 4-byte alignment for
>    u64, but iptables userspace on other 32bit arches does insert extra padding.
>    
>    Reported-by: John Stultz <john.stultz@linaro.org>
>    Tested-by: John Stultz <john.stultz@linaro.org>
>    Fixes: 7ed2abddd20cf ("netfilter: x_tables: check standard target size too")
>    Signed-off-by: Florian Westphal <fw@strlen.de>
>    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a605e7476c66a13312189026e6977bad6ed3050d
>Author: Florian Westphal <fw@strlen.de>
>Date:   Fri Apr 1 14:17:29 2016 +0200
>
>    netfilter: x_tables: validate all offsets and sizes in a rule
>    
>    [ Upstream commit 13631bfc604161a9d69cd68991dff8603edd66f9 ]
>    
>    Validate that all matches (if any) add up to the beginning of
>    the target and that each match covers at least the base structure size.
>    
>    The compat path should be able to safely re-use the function
>    as the structures only differ in alignment; added a
>    BUILD_BUG_ON just in case we have an arch that adds padding as well.
>    
>    Signed-off-by: Florian Westphal <fw@strlen.de>
>    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 451e4403bc4abc51539376d4314baa739ab9e996
>Author: Florian Westphal <fw@strlen.de>
>Date:   Fri Apr 1 14:17:28 2016 +0200
>
>    netfilter: x_tables: check for bogus target offset
>    
>    [ Upstream commit ce683e5f9d045e5d67d1312a42b359cb2ab2a13c ]
>    
>    We're currently asserting that targetoff + targetsize <= nextoff.
>    
>    Extend it to also check that targetoff is >= sizeof(xt_entry).
>    Since this is generic code, add an argument pointing to the start of the
>    match/target, we can then derive the base structure size from the delta.
>    
>    We also need the e->elems pointer in a followup change to validate matches.
>    
>    Signed-off-by: Florian Westphal <fw@strlen.de>
>    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 73bfda1c492bef7038a87adfa887b7e6b7cd6679
>Author: Florian Westphal <fw@strlen.de>
>Date:   Fri Apr 1 14:17:27 2016 +0200
>
>    netfilter: x_tables: check standard target size too
>    
>    [ Upstream commit 7ed2abddd20cf8f6bd27f65bd218f26fa5bf7f44 ]
>    
>    We have targets and standard targets -- the latter carries a verdict.
>    
>    The ip/ip6tables validation functions will access t->verdict for the
>    standard targets to fetch the jump offset or verdict for chainloop
>    detection, but this happens before the targets get checked/validated.
>    
>    Thus we also need to check for verdict presence here, else t->verdict
>    can point right after a blob.
>    
>    Spotted with UBSAN while testing malformed blobs.
>    
>    Signed-off-by: Florian Westphal <fw@strlen.de>
>    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit acbcf85306bd563910a2afe07f07d30381b031b0
>Author: Florian Westphal <fw@strlen.de>
>Date:   Fri Apr 1 14:17:26 2016 +0200
>
>    netfilter: x_tables: add compat version of xt_check_entry_offsets
>    
>    [ Upstream commit fc1221b3a163d1386d1052184202d5dc50d302d1 ]
>    
>    32bit rulesets have different layout and alignment requirements, so once
>    more integrity checks get added to xt_check_entry_offsets it will reject
>    well-formed 32bit rulesets.
>    
>    Signed-off-by: Florian Westphal <fw@strlen.de>
>    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit aae91919c9d6d1aa6d6390826979e6d2c89a7ba4
>Author: Florian Westphal <fw@strlen.de>
>Date:   Fri Apr 1 14:17:25 2016 +0200
>
>    netfilter: x_tables: assert minimum target size
>    
>    [ Upstream commit a08e4e190b866579896c09af59b3bdca821da2cd ]
>    
>    The target size includes the size of the xt_entry_target struct.
>    
>    Signed-off-by: Florian Westphal <fw@strlen.de>
>    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 801cd32774d12dccfcfc0c22b0b26d84ed995c6f
>Author: Florian Westphal <fw@strlen.de>
>Date:   Fri Apr 1 14:17:24 2016 +0200
>
>    netfilter: x_tables: kill check_entry helper
>    
>    [ Upstream commit aa412ba225dd3bc36d404c28cdc3d674850d80d0 ]
>    
>    Once we add more sanity testing to xt_check_entry_offsets it
>    becomes relvant if we're expecting a 32bit 'config_compat' blob
>    or a normal one.
>    
>    Since we already have a lot of similar-named functions (check_entry,
>    compat_check_entry, find_and_check_entry, etc.) and the current
>    incarnation is short just fold its contents into the callers.
>    
>    Signed-off-by: Florian Westphal <fw@strlen.de>
>    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a471ac817cf0e0d6e87779ca1fee216ba849e613
>Author: Florian Westphal <fw@strlen.de>
>Date:   Fri Apr 1 14:17:23 2016 +0200
>
>    netfilter: x_tables: add and use xt_check_entry_offsets
>    
>    [ Upstream commit 7d35812c3214afa5b37a675113555259cfd67b98 ]
>    
>    Currently arp/ip and ip6tables each implement a short helper to check that
>    the target offset is large enough to hold one xt_entry_target struct and
>    that t->u.target_size fits within the current rule.
>    
>    Unfortunately these checks are not sufficient.
>    
>    To avoid adding new tests to all of ip/ip6/arptables move the current
>    checks into a helper, then extend this helper in followup patches.
>    
>    Signed-off-by: Florian Westphal <fw@strlen.de>
>    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8163327a3a927c36f7c032bb67957e6c0f4ec27d
>Author: Florian Westphal <fw@strlen.de>
>Date:   Fri Apr 1 14:17:22 2016 +0200
>
>    netfilter: x_tables: validate targets of jumps
>    
>    [ Upstream commit 36472341017529e2b12573093cc0f68719300997 ]
>    
>    When we see a jump also check that the offset gets us to beginning of
>    a rule (an ipt_entry).
>    
>    The extra overhead is negible, even with absurd cases.
>    
>    300k custom rules, 300k jumps to 'next' user chain:
>    [ plus one jump from INPUT to first userchain ]:
>    
>    Before:
>    real    0m24.874s
>    user    0m7.532s
>    sys     0m16.076s
>    
>    After:
>    real    0m27.464s
>    user    0m7.436s
>    sys     0m18.840s
>    
>    Signed-off-by: Florian Westphal <fw@strlen.de>
>    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit cf756388f8f34e02a338356b3685c46938139871
>Author: Florian Westphal <fw@strlen.de>
>Date:   Fri Apr 1 14:17:21 2016 +0200
>
>    netfilter: x_tables: don't move to non-existent next rule
>    
>    [ Upstream commit f24e230d257af1ad7476c6e81a8dc3127a74204e ]
>    
>    Ben Hawkes says:
>    
>     In the mark_source_chains function (net/ipv4/netfilter/ip_tables.c) it
>     is possible for a user-supplied ipt_entry structure to have a large
>     next_offset field. This field is not bounds checked prior to writing a
>     counter value at the supplied offset.
>    
>    Base chains enforce absolute verdict.
>    
>    User defined chains are supposed to end with an unconditional return,
>    xtables userspace adds them automatically.
>    
>    But if such return is missing we will move to non-existent next rule.
>    
>    Reported-by: Ben Hawkes <hawkes@google.com>
>    Signed-off-by: Florian Westphal <fw@strlen.de>
>    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 850c377e0e2d76723884d610ff40827d26aa21eb
>Author: Florian Westphal <fw@strlen.de>
>Date:   Tue Mar 22 18:02:52 2016 +0100
>
>    netfilter: x_tables: fix unconditional helper
>    
>    [ Upstream commit 54d83fc74aa9ec72794373cb47432c5f7fb1a309 ]
>    
>    Ben Hawkes says:
>    
>     In the mark_source_chains function (net/ipv4/netfilter/ip_tables.c) it
>     is possible for a user-supplied ipt_entry structure to have a large
>     next_offset field. This field is not bounds checked prior to writing a
>     counter value at the supplied offset.
>    
>    Problem is that mark_source_chains should not have been called --
>    the rule doesn't have a next entry, so its supposed to return
>    an absolute verdict of either ACCEPT or DROP.
>    
>    However, the function conditional() doesn't work as the name implies.
>    It only checks that the rule is using wildcard address matching.
>    
>    However, an unconditional rule must also not be using any matches
>    (no -m args).
>    
>    The underflow validator only checked the addresses, therefore
>    passing the 'unconditional absolute verdict' test, while
>    mark_source_chains also tested for presence of matches, and thus
>    proceeeded to the next (not-existent) rule.
>    
>    Unify this so that all the callers have same idea of 'unconditional rule'.
>    
>    Reported-by: Ben Hawkes <hawkes@google.com>
>    Signed-off-by: Florian Westphal <fw@strlen.de>
>    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a1c49d8cf9aa2be958c34fae1f84b1e3006f0c67
>Author: Florian Westphal <fw@strlen.de>
>Date:   Tue Mar 22 18:02:50 2016 +0100
>
>    netfilter: x_tables: make sure e->next_offset covers remaining blob size
>    
>    [ Upstream commit 6e94e0cfb0887e4013b3b930fa6ab1fe6bb6ba91 ]
>    
>    Otherwise this function may read data beyond the ruleset blob.
>    
>    Signed-off-by: Florian Westphal <fw@strlen.de>
>    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 780daa25f811f1aeefb9da76ef93c32b17a5f102
>Author: Florian Westphal <fw@strlen.de>
>Date:   Tue Mar 22 18:02:49 2016 +0100
>
>    netfilter: x_tables: validate e->target_offset early
>    
>    [ Upstream commit bdf533de6968e9686df777dc178486f600c6e617 ]
>    
>    We should check that e->target_offset is sane before
>    mark_source_chains gets called since it will fetch the target entry
>    for loop detection.
>    
>    Signed-off-by: Florian Westphal <fw@strlen.de>
>    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1a1f239be5b547551adc3bc871521c21aa7966ab
>Author: Ralf Baechle <ralf@linux-mips.org>
>Date:   Thu Feb 4 01:24:40 2016 +0100
>
>    MIPS: Fix 64k page support for 32 bit kernels.
>    
>    [ Upstream commit d7de413475f443957a0c1d256e405d19b3a2cb22 ]
>    
>    TASK_SIZE was defined as 0x7fff8000UL which for 64k pages is not a
>    multiple of the page size.  Somewhere further down the math fails
>    such that executing an ELF binary fails.
>    
>    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>    Tested-by: Joshua Henderson <joshua.henderson@microchip.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 445ff22b967197364e31d6ee7f9bdfc3955c091b
>Author: David S. Miller <davem@davemloft.net>
>Date:   Sat May 28 20:41:12 2016 -0700
>
>    sparc64: Fix return from trap window fill crashes.
>    
>    [ Upstream commit 7cafc0b8bf130f038b0ec2dcdd6a9de6dc59b65a ]
>    
>    We must handle data access exception as well as memory address unaligned
>    exceptions from return from trap window fill faults, not just normal
>    TLB misses.
>    
>    Otherwise we can get an OOPS that looks like this:
>    
>    ld-linux.so.2(36808): Kernel bad sw trap 5 [#1]
>    CPU: 1 PID: 36808 Comm: ld-linux.so.2 Not tainted 4.6.0 #34
>    task: fff8000303be5c60 ti: fff8000301344000 task.ti: fff8000301344000
>    TSTATE: 0000004410001601 TPC: 0000000000a1a784 TNPC: 0000000000a1a788 Y: 00000002    Not tainted
>    TPC: <do_sparc64_fault+0x5c4/0x700>
>    g0: fff8000024fc8248 g1: 0000000000db04dc g2: 0000000000000000 g3: 0000000000000001
>    g4: fff8000303be5c60 g5: fff800030e672000 g6: fff8000301344000 g7: 0000000000000001
>    o0: 0000000000b95ee8 o1: 000000000000012b o2: 0000000000000000 o3: 0000000200b9b358
>    o4: 0000000000000000 o5: fff8000301344040 sp: fff80003013475c1 ret_pc: 0000000000a1a77c
>    RPC: <do_sparc64_fault+0x5bc/0x700>
>    l0: 00000000000007ff l1: 0000000000000000 l2: 000000000000005f l3: 0000000000000000
>    l4: fff8000301347e98 l5: fff8000024ff3060 l6: 0000000000000000 l7: 0000000000000000
>    i0: fff8000301347f60 i1: 0000000000102400 i2: 0000000000000000 i3: 0000000000000000
>    i4: 0000000000000000 i5: 0000000000000000 i6: fff80003013476a1 i7: 0000000000404d4c
>    I7: <user_rtt_fill_fixup+0x6c/0x7c>
>    Call Trace:
>     [0000000000404d4c] user_rtt_fill_fixup+0x6c/0x7c
>    
>    The window trap handlers are slightly clever, the trap table entries for them are
>    composed of two pieces of code.  First comes the code that actually performs
>    the window fill or spill trap handling, and then there are three instructions at
>    the end which are for exception processing.
>    
>    The userland register window fill handler is:
>    
>    	add	%sp, STACK_BIAS + 0x00, %g1;		\
>    	ldxa	[%g1 + %g0] ASI, %l0;			\
>    	mov	0x08, %g2;				\
>    	mov	0x10, %g3;				\
>    	ldxa	[%g1 + %g2] ASI, %l1;			\
>    	mov	0x18, %g5;				\
>    	ldxa	[%g1 + %g3] ASI, %l2;			\
>    	ldxa	[%g1 + %g5] ASI, %l3;			\
>    	add	%g1, 0x20, %g1;				\
>    	ldxa	[%g1 + %g0] ASI, %l4;			\
>    	ldxa	[%g1 + %g2] ASI, %l5;			\
>    	ldxa	[%g1 + %g3] ASI, %l6;			\
>    	ldxa	[%g1 + %g5] ASI, %l7;			\
>    	add	%g1, 0x20, %g1;				\
>    	ldxa	[%g1 + %g0] ASI, %i0;			\
>    	ldxa	[%g1 + %g2] ASI, %i1;			\
>    	ldxa	[%g1 + %g3] ASI, %i2;			\
>    	ldxa	[%g1 + %g5] ASI, %i3;			\
>    	add	%g1, 0x20, %g1;				\
>    	ldxa	[%g1 + %g0] ASI, %i4;			\
>    	ldxa	[%g1 + %g2] ASI, %i5;			\
>    	ldxa	[%g1 + %g3] ASI, %i6;			\
>    	ldxa	[%g1 + %g5] ASI, %i7;			\
>    	restored;					\
>    	retry; nop; nop; nop; nop;			\
>    	b,a,pt	%xcc, fill_fixup_dax;			\
>    	b,a,pt	%xcc, fill_fixup_mna;			\
>    	b,a,pt	%xcc, fill_fixup;
>    
>    And the way this works is that if any of those memory accesses
>    generate an exception, the exception handler can revector to one of
>    those final three branch instructions depending upon which kind of
>    exception the memory access took.  In this way, the fault handler
>    doesn't have to know if it was a spill or a fill that it's handling
>    the fault for.  It just always branches to the last instruction in
>    the parent trap's handler.
>    
>    For example, for a regular fault, the code goes:
>    
>    winfix_trampoline:
>    	rdpr	%tpc, %g3
>    	or	%g3, 0x7c, %g3
>    	wrpr	%g3, %tnpc
>    	done
>    
>    All window trap handlers are 0x80 aligned, so if we "or" 0x7c into the
>    trap time program counter, we'll get that final instruction in the
>    trap handler.
>    
>    On return from trap, we have to pull the register window in but we do
>    this by hand instead of just executing a "restore" instruction for
>    several reasons.  The largest being that from Niagara and onward we
>    simply don't have enough levels in the trap stack to fully resolve all
>    possible exception cases of a window fault when we are already at
>    trap level 1 (which we enter to get ready to return from the original
>    trap).
>    
>    This is executed inline via the FILL_*_RTRAP handlers.  rtrap_64.S's
>    code branches directly to these to do the window fill by hand if
>    necessary.  Now if you look at them, we'll see at the end:
>    
>    	    ba,a,pt    %xcc, user_rtt_fill_fixup;
>    	    ba,a,pt    %xcc, user_rtt_fill_fixup;
>    	    ba,a,pt    %xcc, user_rtt_fill_fixup;
>    
>    And oops, all three cases are handled like a fault.
>    
>    This doesn't work because each of these trap types (data access
>    exception, memory address unaligned, and faults) store their auxiliary
>    info in different registers to pass on to the C handler which does the
>    real work.
>    
>    So in the case where the stack was unaligned, the unaligned trap
>    handler sets up the arg registers one way, and then we branched to
>    the fault handler which expects them setup another way.
>    
>    So the FAULT_TYPE_* value ends up basically being garbage, and
>    randomly would generate the backtrace seen above.
>    
>    Reported-by: Nick Alcock <nix@esperi.org.uk>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6d3c93761479927258727fcdcf5e673aa5d8aaf4
>Author: David S. Miller <davem@davemloft.net>
>Date:   Sat May 28 21:21:31 2016 -0700
>
>    sparc: Harden signal return frame checks.
>    
>    [ Upstream commit d11c2a0de2824395656cf8ed15811580c9dd38aa ]
>    
>    All signal frames must be at least 16-byte aligned, because that is
>    the alignment we explicitly create when we build signal return stack
>    frames.
>    
>    All stack pointers must be at least 8-byte aligned.
>    
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ea312fcb4efc84b28f891485d6c4aca2163c2438
>Author: David S. Miller <davem@davemloft.net>
>Date:   Wed May 25 12:51:20 2016 -0700
>
>    sparc64: Take ctx_alloc_lock properly in hugetlb_setup().
>    
>    [ Upstream commit 9ea46abe22550e3366ff7cee2f8391b35b12f730 ]
>    
>    On cheetahplus chips we take the ctx_alloc_lock in order to
>    modify the TLB lookup parameters for the indexed TLBs, which
>    are stored in the context register.
>    
>    This is called with interrupts disabled, however ctx_alloc_lock
>    is an IRQ safe lock, therefore we must take acquire/release it
>    properly with spin_{lock,unlock}_irq().
>    
>    Reported-by: Meelis Roos <mroos@linux.ee>
>    Tested-by: Meelis Roos <mroos@linux.ee>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a74b2f239c2be446c4e7cdb0cdcb641e968a9ce0
>Author: Babu Moger <babu.moger@oracle.com>
>Date:   Thu Mar 24 13:02:22 2016 -0700
>
>    sparc/PCI: Fix for panic while enabling SR-IOV
>    
>    [ Upstream commit d0c31e02005764dae0aab130a57e9794d06b824d ]
>    
>    We noticed this panic while enabling SR-IOV in sparc.
>    
>    mlx4_core: Mellanox ConnectX core driver v2.2-1 (Jan  1 2015)
>    mlx4_core: Initializing 0007:01:00.0
>    mlx4_core 0007:01:00.0: Enabling SR-IOV with 5 VFs
>    mlx4_core: Initializing 0007:01:00.1
>    Unable to handle kernel NULL pointer dereference
>    insmod(10010): Oops [#1]
>    CPU: 391 PID: 10010 Comm: insmod Not tainted
>    		4.1.12-32.el6uek.kdump2.sparc64 #1
>    TPC: <dma_supported+0x20/0x80>
>    I7: <__mlx4_init_one+0x324/0x500 [mlx4_core]>
>    Call Trace:
>     [00000000104c5ea4] __mlx4_init_one+0x324/0x500 [mlx4_core]
>     [00000000104c613c] mlx4_init_one+0xbc/0x120 [mlx4_core]
>     [0000000000725f14] local_pci_probe+0x34/0xa0
>     [0000000000726028] pci_call_probe+0xa8/0xe0
>     [0000000000726310] pci_device_probe+0x50/0x80
>     [000000000079f700] really_probe+0x140/0x420
>     [000000000079fa24] driver_probe_device+0x44/0xa0
>     [000000000079fb5c] __device_attach+0x3c/0x60
>     [000000000079d85c] bus_for_each_drv+0x5c/0xa0
>     [000000000079f588] device_attach+0x88/0xc0
>     [000000000071acd0] pci_bus_add_device+0x30/0x80
>     [0000000000736090] virtfn_add.clone.1+0x210/0x360
>     [00000000007364a4] sriov_enable+0x2c4/0x520
>     [000000000073672c] pci_enable_sriov+0x2c/0x40
>     [00000000104c2d58] mlx4_enable_sriov+0xf8/0x180 [mlx4_core]
>     [00000000104c49ac] mlx4_load_one+0x42c/0xd40 [mlx4_core]
>    Disabling lock debugging due to kernel taint
>    Caller[00000000104c5ea4]: __mlx4_init_one+0x324/0x500 [mlx4_core]
>    Caller[00000000104c613c]: mlx4_init_one+0xbc/0x120 [mlx4_core]
>    Caller[0000000000725f14]: local_pci_probe+0x34/0xa0
>    Caller[0000000000726028]: pci_call_probe+0xa8/0xe0
>    Caller[0000000000726310]: pci_device_probe+0x50/0x80
>    Caller[000000000079f700]: really_probe+0x140/0x420
>    Caller[000000000079fa24]: driver_probe_device+0x44/0xa0
>    Caller[000000000079fb5c]: __device_attach+0x3c/0x60
>    Caller[000000000079d85c]: bus_for_each_drv+0x5c/0xa0
>    Caller[000000000079f588]: device_attach+0x88/0xc0
>    Caller[000000000071acd0]: pci_bus_add_device+0x30/0x80
>    Caller[0000000000736090]: virtfn_add.clone.1+0x210/0x360
>    Caller[00000000007364a4]: sriov_enable+0x2c4/0x520
>    Caller[000000000073672c]: pci_enable_sriov+0x2c/0x40
>    Caller[00000000104c2d58]: mlx4_enable_sriov+0xf8/0x180 [mlx4_core]
>    Caller[00000000104c49ac]: mlx4_load_one+0x42c/0xd40 [mlx4_core]
>    Caller[00000000104c5f90]: __mlx4_init_one+0x410/0x500 [mlx4_core]
>    Caller[00000000104c613c]: mlx4_init_one+0xbc/0x120 [mlx4_core]
>    Caller[0000000000725f14]: local_pci_probe+0x34/0xa0
>    Caller[0000000000726028]: pci_call_probe+0xa8/0xe0
>    Caller[0000000000726310]: pci_device_probe+0x50/0x80
>    Caller[000000000079f700]: really_probe+0x140/0x420
>    Caller[000000000079fa24]: driver_probe_device+0x44/0xa0
>    Caller[000000000079fb08]: __driver_attach+0x88/0xa0
>    Caller[000000000079d90c]: bus_for_each_dev+0x6c/0xa0
>    Caller[000000000079f29c]: driver_attach+0x1c/0x40
>    Caller[000000000079e35c]: bus_add_driver+0x17c/0x220
>    Caller[00000000007a02d4]: driver_register+0x74/0x120
>    Caller[00000000007263fc]: __pci_register_driver+0x3c/0x60
>    Caller[00000000104f62bc]: mlx4_init+0x60/0xcc [mlx4_core]
>    Kernel panic - not syncing: Fatal exception
>    Press Stop-A (L1-A) to return to the boot prom
>    ---[ end Kernel panic - not syncing: Fatal exception
>    
>    Details:
>    Here is the call sequence
>    virtfn_add->__mlx4_init_one->dma_set_mask->dma_supported
>    
>    The panic happened at line 760(file arch/sparc/kernel/iommu.c)
>    
>    758 int dma_supported(struct device *dev, u64 device_mask)
>    759 {
>    760         struct iommu *iommu = dev->archdata.iommu;
>    761         u64 dma_addr_mask = iommu->dma_addr_mask;
>    762
>    763         if (device_mask >= (1UL << 32UL))
>    764                 return 0;
>    765
>    766         if ((device_mask & dma_addr_mask) == dma_addr_mask)
>    767                 return 1;
>    768
>    769 #ifdef CONFIG_PCI
>    770         if (dev_is_pci(dev))
>    771		return pci64_dma_supported(to_pci_dev(dev), device_mask);
>    772 #endif
>    773
>    774         return 0;
>    775 }
>    776 EXPORT_SYMBOL(dma_supported);
>    
>    Same panic happened with Intel ixgbe driver also.
>    
>    SR-IOV code looks for arch specific data while enabling
>    VFs. When VF device is added, driver probe function makes set
>    of calls to initialize the pci device. Because the VF device is
>    added different way than the normal PF device(which happens via
>    of_create_pci_dev for sparc), some of the arch specific initialization
>    does not happen for VF device.  That causes panic when archdata is
>    accessed.
>    
>    To fix this, I have used already defined weak function
>    pcibios_setup_device to copy archdata from PF to VF.
>    Also verified the fix.
>    
>    Signed-off-by: Babu Moger <babu.moger@oracle.com>
>    Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
>    Reviewed-by: Ethan Zhao <ethan.zhao@oracle.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit dc316fc9cbd77586c674e92288ece8383b738dac
>Author: David S. Miller <davem@davemloft.net>
>Date:   Tue Mar 1 00:25:32 2016 -0500
>
>    sparc64: Fix sparc64_set_context stack handling.
>    
>    [ Upstream commit 397d1533b6cce0ccb5379542e2e6d079f6936c46 ]
>    
>    Like a signal return, we should use synchronize_user_stack() rather
>    than flush_user_windows().
>    
>    Reported-by: Ilya Malakhov <ilmalakhovthefirst@gmail.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 25f7f80eabe7a0553851990c8367aab1533b7021
>Author: Nitin Gupta <nitin.m.gupta@oracle.com>
>Date:   Tue Jan 5 22:35:35 2016 -0800
>
>    sparc64: Fix numa node distance initialization
>    
>    [ Upstream commit 36beca6571c941b28b0798667608239731f9bc3a ]
>    
>    Orabug: 22495713
>    
>    Currently, NUMA node distance matrix is initialized only
>    when a machine descriptor (MD) exists. However, sun4u
>    machines (e.g. Sun Blade 2500) do not have an MD and thus
>    distance values were left uninitialized. The initialization
>    is now moved such that it happens on both sun4u and sun4v.
>    
>    Signed-off-by: Nitin Gupta <nitin.m.gupta@oracle.com>
>    Tested-by: Mikael Pettersson <mikpelinux@gmail.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 693b8dc4b23b853c5636fc04909bff48e44758cc
>Author: David S. Miller <davem@davemloft.net>
>Date:   Wed Apr 27 17:27:37 2016 -0400
>
>    sparc64: Fix bootup regressions on some Kconfig combinations.
>    
>    [ Upstream commit 49fa5230462f9f2c4e97c81356473a6bdf06c422 ]
>    
>    The system call tracing bug fix mentioned in the Fixes tag
>    below increased the amount of assembler code in the sequence
>    of assembler files included by head_64.S
>    
>    This caused to total set of code to exceed 0x4000 bytes in
>    size, which overflows the expression in head_64.S that works
>    to place swapper_tsb at address 0x408000.
>    
>    When this is violated, the TSB is not properly aligned, and
>    also the trap table is not aligned properly either.  All of
>    this together results in failed boots.
>    
>    So, do two things:
>    
>    1) Simplify some code by using ba,a instead of ba/nop to get
>       those bytes back.
>    
>    2) Add a linker script assertion to make sure that if this
>       happens again the build will fail.
>    
>    Fixes: 1a40b95374f6 ("sparc: Fix system call tracing register handling.")
>    Reported-by: Meelis Roos <mroos@linux.ee>
>    Reported-by: Joerg Abraham <joerg.abraham@nokia.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d2e4e89ae871295c539334f50368bb48f74c3caf
>Author: Mike Frysinger <vapier@gentoo.org>
>Date:   Mon Jan 18 06:32:30 2016 -0500
>
>    sparc: Fix system call tracing register handling.
>    
>    [ Upstream commit 1a40b95374f680625318ab61d81958e949e0afe3 ]
>    
>    A system call trace trigger on entry allows the tracing
>    process to inspect and potentially change the traced
>    process's registers.
>    
>    Account for that by reloading the %g1 (syscall number)
>    and %i0-%i5 (syscall argument) values.  We need to be
>    careful to revalidate the range of %g1, and reload the
>    system call table entry it corresponds to into %l7.
>    
>    Reported-by: Mike Frysinger <vapier@gentoo.org>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Tested-by: Mike Frysinger <vapier@gentoo.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit daaaff2715757a241f178547cb39ae63882ad7da
>Author: Yuchung Cheng <ycheng@google.com>
>Date:   Mon Jun 6 15:07:18 2016 -0700
>
>    tcp: record TLP and ER timer stats in v6 stats
>    
>    [ Upstream commit ce3cf4ec0305919fc69a972f6c2b2efd35d36abc ]
>    
>    The v6 tcp stats scan do not provide TLP and ER timer information
>    correctly like the v4 version . This patch fixes that.
>    
>    Fixes: 6ba8a3b19e76 ("tcp: Tail loss probe (TLP)")
>    Fixes: eed530b6c676 ("tcp: early retransmit")
>    Signed-off-by: Yuchung Cheng <ycheng@google.com>
>    Signed-off-by: Neal Cardwell <ncardwell@google.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e2de678c191464580160b68b896d9078aca8b2fc
>Author: Edward Cree <ecree@solarflare.com>
>Date:   Tue May 24 18:53:36 2016 +0100
>
>    sfc: on MC reset, clear PIO buffer linkage in TXQs
>    
>    [ Upstream commit c0795bf64cba4d1b796fdc5b74b33772841ed1bb ]
>    
>    Otherwise, if we fail to allocate new PIO buffers, our TXQs will try to
>    use the old ones, which aren't there any more.
>    
>    Fixes: 183233bec810 "sfc: Allocate and link PIO buffers; map them with write-combining"
>    Signed-off-by: Edward Cree <ecree@solarflare.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 27b56c6154943a860c9266ec8f3dc96ba2b1aa19
>Author: Jason Wang <jasowang@redhat.com>
>Date:   Thu May 19 13:36:51 2016 +0800
>
>    tuntap: correctly wake up process during uninit
>    
>    [ Upstream commit addf8fc4acb1cf79492ac64966f07178793cb3d7 ]
>    
>    We used to check dev->reg_state against NETREG_REGISTERED after each
>    time we are woke up. But after commit 9e641bdcfa4e ("net-tun:
>    restructure tun_do_read for better sleep/wakeup efficiency"), it uses
>    skb_recv_datagram() which does not check dev->reg_state. This will
>    result if we delete a tun/tap device after a process is blocked in the
>    reading. The device will wait for the reference count which was held
>    by that process for ever.
>    
>    Fixes this by using RCV_SHUTDOWN which will be checked during
>    sk_recv_datagram() before trying to wake up the process during uninit.
>    
>    Fixes: 9e641bdcfa4e ("net-tun: restructure tun_do_read for better
>    sleep/wakeup efficiency")
>    Cc: Eric Dumazet <edumazet@google.com>
>    Cc: Xi Wang <xii@google.com>
>    Cc: Michael S. Tsirkin <mst@redhat.com>
>    Signed-off-by: Jason Wang <jasowang@redhat.com>
>    Acked-by: Eric Dumazet <edumazet@google.com>
>    Acked-by: Michael S. Tsirkin <mst@redhat.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8454d6443c84ee3501de20b9ff2034ea4767a0da
>Author: Richard Alpe <richard.alpe@ericsson.com>
>Date:   Tue May 17 16:57:37 2016 +0200
>
>    tipc: fix nametable publication field in nl compat
>    
>    [ Upstream commit 03aaaa9b941e136757b55c4cf775aab6068dfd94 ]
>    
>    The publication field of the old netlink API should contain the
>    publication key and not the publication reference.
>    
>    Fixes: 44a8ae94fd55 (tipc: convert legacy nl name table dump to nl compat)
>    Signed-off-by: Richard Alpe <richard.alpe@ericsson.com>
>    Acked-by: Jon Maloy <jon.maloy@ericsson.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e39cd93be0009ae4548a737756a947d2030956ab
>Author: Herbert Xu <herbert@gondor.apana.org.au>
>Date:   Mon May 16 17:28:16 2016 +0800
>
>    netlink: Fix dump skb leak/double free
>    
>    [ Upstream commit 92964c79b357efd980812c4de5c1fd2ec8bb5520 ]
>    
>    When we free cb->skb after a dump, we do it after releasing the
>    lock.  This means that a new dump could have started in the time
>    being and we'll end up freeing their skb instead of ours.
>    
>    This patch saves the skb and module before we unlock so we free
>    the right memory.
>    
>    Fixes: 16b304f3404f ("netlink: Eliminate kmalloc in netlink dump operation.")
>    Reported-by: Baozeng Ding <sploving1@gmail.com>
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 49956430d3d55b47e4a2d2f5f777d641cae137d6
>Author: Richard Alpe <richard.alpe@ericsson.com>
>Date:   Mon May 16 11:14:54 2016 +0200
>
>    tipc: check nl sock before parsing nested attributes
>    
>    [ Upstream commit 45e093ae2830cd1264677d47ff9a95a71f5d9f9c ]
>    
>    Make sure the socket for which the user is listing publication exists
>    before parsing the socket netlink attributes.
>    
>    Prior to this patch a call without any socket caused a NULL pointer
>    dereference in tipc_nl_publ_dump().
>    
>    Tested-and-reported-by: Baozeng Ding <sploving1@gmail.com>
>    Signed-off-by: Richard Alpe <richard.alpe@ericsson.com>
>    Acked-by: Jon Maloy <jon.maloy@ericsson.cm>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 186e7c38727f7a9fecbf238bbff9675e83842a99
>Author: Eric Sandeen <sandeen@redhat.com>
>Date:   Mon Jan 4 16:10:19 2016 +1100
>
>    xfs: print name of verifier if it fails
>    
>    [ Upstream commit 233135b763db7c64d07b728a9c66745fb0376275 ]
>    
>    This adds a name to each buf_ops structure, so that if
>    a verifier fails we can print the type of verifier that
>    failed it.  Should be a slight debugging aid, I hope.
>    
>    Signed-off-by: Eric Sandeen <sandeen@redhat.com>
>    Reviewed-by: Brian Foster <bfoster@redhat.com>
>    Signed-off-by: Dave Chinner <david@fromorbit.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2612a949cf5c2a868adee1ca6bcbf01cd4e2f01e
>Author: Willy Tarreau <w@1wt.eu>
>Date:   Mon Jan 18 16:36:09 2016 +0100
>
>    pipe: limit the per-user amount of pages allocated in pipes
>    
>    [ Upstream commit 759c01142a5d0f364a462346168a56de28a80f52 ]
>    
>    On no-so-small systems, it is possible for a single process to cause an
>    OOM condition by filling large pipes with data that are never read. A
>    typical process filling 4000 pipes with 1 MB of data will use 4 GB of
>    memory. On small systems it may be tricky to set the pipe max size to
>    prevent this from happening.
>    
>    This patch makes it possible to enforce a per-user soft limit above
>    which new pipes will be limited to a single page, effectively limiting
>    them to 4 kB each, as well as a hard limit above which no new pipes may
>    be created for this user. This has the effect of protecting the system
>    against memory abuse without hurting other users, and still allowing
>    pipes to work correctly though with less data at once.
>    
>    The limit are controlled by two new sysctls : pipe-user-pages-soft, and
>    pipe-user-pages-hard. Both may be disabled by setting them to zero. The
>    default soft limit allows the default number of FDs per process (1024)
>    to create pipes of the default size (64kB), thus reaching a limit of 64MB
>    before starting to create only smaller pipes. With 256 processes limited
>    to 1024 FDs each, this results in 1024*64kB + (256*1024 - 1024) * 4kB =
>    1084 MB of memory allocated for a user. The hard limit is disabled by
>    default to avoid breaking existing applications that make intensive use
>    of pipes (eg: for splicing).
>    
>    Reported-by: socketpair@gmail.com
>    Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
>    Mitigates: CVE-2013-4312 (Linux 2.0+)
>    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Willy Tarreau <w@1wt.eu>
>    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e8ebd0cf882ba73a5c867bb7228dba1ae746c047
>Author: Huacai Chen <chenhc@lemote.com>
>Date:   Thu Mar 17 20:37:10 2016 +0800
>
>    MIPS: Reserve nosave data for hibernation
>    
>    [ Upstream commit a95d069204e178f18476f5499abab0d0d9cbc32c ]
>    
>    After commit 92923ca3aacef63c92d ("mm: meminit: only set page reserved
>    in the memblock region"), the MIPS hibernation is broken. Because pages
>    in nosave data section should be "reserved", but currently they aren't
>    set to "reserved" at initialization. This patch makes hibernation work
>    again.
>    
>    Signed-off-by: Huacai Chen <chenhc@lemote.com>
>    Cc: Aurelien Jarno <aurelien@aurel32.net>
>    Cc: Steven J . Hill <sjhill@realitydiluted.com>
>    Cc: Fuxin Zhang <zhangfx@lemote.com>
>    Cc: Zhangjin Wu <wuzhangjin@gmail.com>
>    Cc: linux-mips@linux-mips.org
>    Cc: stable@vger.kernel.org
>    Patchwork: https://patchwork.linux-mips.org/patch/12888/
>    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 664fcc116904a7414f7bbd0831c973cbd28b59ad
>Author: Chanwoo Choi <cw00.choi@samsung.com>
>Date:   Thu Apr 21 18:58:31 2016 +0900
>
>    serial: samsung: Reorder the sequence of clock control when call s3c24xx_serial_set_termios()
>    
>    [ Upstream commit b8995f527aac143e83d3900ff39357651ea4e0f6 ]
>    
>    This patch fixes the broken serial log when changing the clock source
>    of uart device. Before disabling the original clock source, this patch
>    enables the new clock source to protect the clock off state for a split second.
>    
>    Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
>    Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5ec75b71be17201805f2e6b7ef9f17f2d6b412d3
>Author: Jiri Slaby <jslaby@suse.cz>
>Date:   Tue May 3 17:05:54 2016 +0200
>
>    tty: vt, return error when con_startup fails
>    
>    [ Upstream commit 6798df4c5fe0a7e6d2065cf79649a794e5ba7114 ]
>    
>    When csw->con_startup() fails in do_register_con_driver, we return no
>    error (i.e. 0). This was changed back in 2006 by commit 3e795de763.
>    Before that we used to return -ENODEV.
>    
>    So fix the return value to be -ENODEV in that case again.
>    
>    Fixes: 3e795de763 ("VT binding: Add binding/unbinding support for the VT console")
>    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
>    Reported-by: "Dan Carpenter" <dan.carpenter@oracle.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 87e0b5757eab598f4b55babdc8879e143a556b7a
>Author: Paolo Bonzini <pbonzini@redhat.com>
>Date:   Mon Mar 21 12:33:00 2016 +0100
>
>    KVM: x86: mask CPUID(0xD,0x1).EAX against host value
>    
>    [ Upstream commit 316314cae15fb0e3869b76b468f59a0c83ac3d4e ]
>    
>    This ensures that the guest doesn't see XSAVE extensions
>    (e.g. xgetbv1 or xsavec) that the host lacks.
>    
>    Cc: stable@vger.kernel.org
>    Reviewed-by: Radim KrÄmÃ¡Å <rkrcmar@redhat.com>
>    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4b6986fcceb200b2edd97d7cc5799d8a7ae53086
>Author: Lars-Peter Clausen <lars@metafoo.de>
>Date:   Wed Mar 30 13:49:14 2016 +0200
>
>    usb: gadget: f_fs: Fix EFAULT generation for async read operations
>    
>    [ Upstream commit 332a5b446b7916d272c2a659a3b20909ce34d2c1 ]
>    
>    In the current implementation functionfs generates a EFAULT for async read
>    operations if the read buffer size is larger than the URB data size. Since
>    a application does not necessarily know how much data the host side is
>    going to send it typically supplies a buffer larger than the actual data,
>    which will then result in a EFAULT error.
>    
>    This behaviour was introduced while refactoring the code to use iov_iter
>    interface in commit c993c39b8639 ("gadget/function/f_fs.c: use put iov_iter
>    into io_data"). The original code took the minimum over the URB size and
>    the user buffer size and then attempted to copy that many bytes using
>    copy_to_user(). If copy_to_user() could not copy all data a EFAULT error
>    was generated. Restore the original behaviour by only generating a EFAULT
>    error when the number of bytes copied is not the size of the URB and the
>    target buffer has not been fully filled.
>    
>    Commit 342f39a6c8d3 ("usb: gadget: f_fs: fix check in read operation")
>    already fixed the same problem for the synchronous read path.
>    
>    Fixes: c993c39b8639 ("gadget/function/f_fs.c: use put iov_iter into io_data")
>    Acked-by: Michal Nazarewicz <mina86@mina86.com>
>    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
>    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 616ffbf1a53617037e2e46d2f40232a5cb1ea8c0
>Author: Andy Gross <andy.gross@linaro.org>
>Date:   Tue May 3 15:24:11 2016 -0500
>
>    clk: qcom: msm8916: Fix crypto clock flags
>    
>    [ Upstream commit 2a0974aa1a0b40a92387ea03dbfeacfbc9ba182c ]
>    
>    This patch adds the CLK_SET_RATE_PARENT flag for the crypto core and
>    ahb blocks.  Without this flag, clk_set_rate can fail for certain
>    frequency requests.
>    
>    Signed-off-by: Andy Gross <andy.gross@linaro.org>
>    Fixes: 3966fab8b6ab ("clk: qcom: Add MSM8916 Global Clock Controller support")
>    Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ec2744d3c8e70f1beedeaa361dd8b162017a12e7
>Author: Josef Bacik <jbacik@fb.com>
>Date:   Fri Mar 25 10:02:41 2016 -0400
>
>    Btrfs: don't use src fd for printk
>    
>    [ Upstream commit c79b4713304f812d3d6c95826fc3e5fc2c0b0c14 ]
>    
>    The fd we pass in may not be on a btrfs file system, so don't try to do
>    BTRFS_I() on it.  Thanks,
>    
>    Signed-off-by: Josef Bacik <jbacik@fb.com>
>    Reviewed-by: David Sterba <dsterba@suse.com>
>    Signed-off-by: David Sterba <dsterba@suse.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 545655ed2eea768dc9abd8899b65b5c272bc5104
>Author: Lucas Stach <dev@lynxeye.de>
>Date:   Thu May 5 10:16:44 2016 -0400
>
>    drm/radeon: fix PLL sharing on DCE6.1 (v2)
>    
>    [ Upstream commit e3c00d87845ab375f90fa6e10a5e72a3a5778cd3 ]
>    
>    On DCE6.1 PPLL2 is exclusively available to UNIPHYA, so it should not
>    be taken into consideration when looking for an already enabled PLL
>    to be shared with other outputs.
>    
>    This fixes the broken VGA port (TRAVIS DP->VGA bridge) on my Richland
>    based laptop, where the internal display is connected to UNIPHYA through
>    a TRAVIS DP->LVDS bridge.
>    
>    Bug:
>    https://bugs.freedesktop.org/show_bug.cgi?id=78987
>    
>    v2: agd: add check in radeon_get_shared_nondp_ppll as well, drop
>        extra parameter.
>    
>    Signed-off-by: Lucas Stach <dev@lynxeye.de>
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a36c14ba24b1ba16964d0289fe8b282b780a5554
>Author: Gerald Schaefer <gerald.schaefer@de.ibm.com>
>Date:   Fri Apr 15 16:38:40 2016 +0200
>
>    s390/mm: fix asce_bits handling with dynamic pagetable levels
>    
>    [ Upstream commit 723cacbd9dc79582e562c123a0bacf8bfc69e72a ]
>    
>    There is a race with multi-threaded applications between context switch and
>    pagetable upgrade. In switch_mm() a new user_asce is built from mm->pgd and
>    mm->context.asce_bits, w/o holding any locks. A concurrent mmap with a
>    pagetable upgrade on another thread in crst_table_upgrade() could already
>    have set new asce_bits, but not yet the new mm->pgd. This would result in a
>    corrupt user_asce in switch_mm(), and eventually in a kernel panic from a
>    translation exception.
>    
>    Fix this by storing the complete asce instead of just the asce_bits, which
>    can then be read atomically from switch_mm(), so that it either sees the
>    old value or the new value, but no mixture. Both cases are OK. Having the
>    old value would result in a page fault on access to the higher level memory,
>    but the fault handler would see the new mm->pgd, if it was a valid access
>    after the mmap on the other thread has completed. So as worst-case scenario
>    we would have a page fault loop for the racing thread until the next time
>    slice.
>    
>    Also remove dead code and simplify the upgrade/downgrade path, there are no
>    upgrades from 2 levels, and only downgrades from 3 levels for compat tasks.
>    There are also no concurrent upgrades, because the mmap_sem is held with
>    down_write() in do_mmap, so the flush and table checks during upgrade can
>    be removed.
>    
>    Reported-by: Michael Munday <munday@ca.ibm.com>
>    Reviewed-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
>    Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
>    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 90eb6718b9db5c145f7c2d4a14df6a4b8d96e7b3
>Author: Eric Dumazet <edumazet@google.com>
>Date:   Mon May 9 20:55:16 2016 -0700
>
>    tcp: refresh skb timestamp at retransmit time
>    
>    [ Upstream commit 10a81980fc47e64ffac26a073139813d3f697b64 ]
>    
>    In the very unlikely case __tcp_retransmit_skb() can not use the cloning
>    done in tcp_transmit_skb(), we need to refresh skb_mstamp before doing
>    the copy and transmit, otherwise TCP TS val will be an exact copy of
>    original transmit.
>    
>    Fixes: 7faee5c0d514 ("tcp: remove TCP_SKB_CB(skb)->when")
>    Signed-off-by: Eric Dumazet <edumazet@google.com>
>    Cc: Yuchung Cheng <ycheng@google.com>
>    Acked-by: Yuchung Cheng <ycheng@google.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b2b95b3fbd93c910210922809f6c4d24be172b1c
>Author: Kangjie Lu <kangjielu@gmail.com>
>Date:   Sun May 8 12:10:14 2016 -0400
>
>    net: fix a kernel infoleak in x25 module
>    
>    [ Upstream commit 79e48650320e6fba48369fccf13fd045315b19b8 ]
>    
>    Stack object "dte_facilities" is allocated in x25_rx_call_request(),
>    which is supposed to be initialized in x25_negotiate_facilities.
>    However, 5 fields (8 bytes in total) are not initialized. This
>    object is then copied to userland via copy_to_user, thus infoleak
>    occurs.
>    
>    Signed-off-by: Kangjie Lu <kjlu@gatech.edu>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 806d70c7da5bc0dc43e54fe0362fc0fcf573bfe2
>Author: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
>Date:   Wed May 4 16:18:45 2016 +0200
>
>    net: bridge: fix old ioctl unlocked net device walk
>    
>    [ Upstream commit 31ca0458a61a502adb7ed192bf9716c6d05791a5 ]
>    
>    get_bridge_ifindices() is used from the old "deviceless" bridge ioctl
>    calls which aren't called with rtnl held. The comment above says that it is
>    called with rtnl but that is not really the case.
>    Here's a sample output from a test ASSERT_RTNL() which I put in
>    get_bridge_ifindices and executed "brctl show":
>    [  957.422726] RTNL: assertion failed at net/bridge//br_ioctl.c (30)
>    [  957.422925] CPU: 0 PID: 1862 Comm: brctl Tainted: G        W  O
>    4.6.0-rc4+ #157
>    [  957.423009] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
>    BIOS 1.8.1-20150318_183358- 04/01/2014
>    [  957.423009]  0000000000000000 ffff880058adfdf0 ffffffff8138dec5
>    0000000000000400
>    [  957.423009]  ffffffff81ce8380 ffff880058adfe58 ffffffffa05ead32
>    0000000000000001
>    [  957.423009]  00007ffec1a444b0 0000000000000400 ffff880053c19130
>    0000000000008940
>    [  957.423009] Call Trace:
>    [  957.423009]  [<ffffffff8138dec5>] dump_stack+0x85/0xc0
>    [  957.423009]  [<ffffffffa05ead32>]
>    br_ioctl_deviceless_stub+0x212/0x2e0 [bridge]
>    [  957.423009]  [<ffffffff81515beb>] sock_ioctl+0x22b/0x290
>    [  957.423009]  [<ffffffff8126ba75>] do_vfs_ioctl+0x95/0x700
>    [  957.423009]  [<ffffffff8126c159>] SyS_ioctl+0x79/0x90
>    [  957.423009]  [<ffffffff8163a4c0>] entry_SYSCALL_64_fastpath+0x23/0xc1
>    
>    Since it only reads bridge ifindices, we can use rcu to safely walk the net
>    device list. Also remove the wrong rtnl comment above.
>    
>    Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8817c1b1dad9fe118779eb3df237674856514fc8
>Author: Ian Campbell <ian.campbell@docker.com>
>Date:   Wed May 4 14:21:53 2016 +0100
>
>    VSOCK: do not disconnect socket when peer has shutdown SEND only
>    
>    [ Upstream commit dedc58e067d8c379a15a8a183c5db318201295bb ]
>    
>    The peer may be expecting a reply having sent a request and then done a
>    shutdown(SHUT_WR), so tearing down the whole socket at this point seems
>    wrong and breaks for me with a client which does a SHUT_WR.
>    
>    Looking at other socket family's stream_recvmsg callbacks doing a shutdown
>    here does not seem to be the norm and removing it does not seem to have
>    had any adverse effects that I can see.
>    
>    I'm using Stefan's RFC virtio transport patches, I'm unsure of the impact
>    on the vmci transport.
>    
>    Signed-off-by: Ian Campbell <ian.campbell@docker.com>
>    Cc: "David S. Miller" <davem@davemloft.net>
>    Cc: Stefan Hajnoczi <stefanha@redhat.com>
>    Cc: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com>
>    Cc: Andy King <acking@vmware.com>
>    Cc: Dmitry Torokhov <dtor@vmware.com>
>    Cc: Jorgen Hansen <jhansen@vmware.com>
>    Cc: Adit Ranadive <aditr@vmware.com>
>    Cc: netdev@vger.kernel.org
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8bba1625512245771bdb2cb1502697228fe7e1b2
>Author: Daniel Jurgens <danielj@mellanox.com>
>Date:   Wed May 4 15:00:33 2016 +0300
>
>    net/mlx4_en: Fix endianness bug in IPV6 csum calculation
>    
>    [ Upstream commit 82d69203df634b4dfa765c94f60ce9482bcc44d6 ]
>    
>    Use htons instead of unconditionally byte swapping nexthdr.  On a little
>    endian systems shifting the byte is correct behavior, but it results in
>    incorrect csums on big endian architectures.
>    
>    Fixes: f8c6455bb04b ('net/mlx4_en: Extend checksum offloading by CHECKSUM COMPLETE')
>    Signed-off-by: Daniel Jurgens <danielj@mellanox.com>
>    Reviewed-by: Carol Soto <clsoto@us.ibm.com>
>    Tested-by: Carol Soto <clsoto@us.ibm.com>
>    Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9a9390bcf56680c487a8e4c89c813a48bfedc4b6
>Author: Kangjie Lu <kangjielu@gmail.com>
>Date:   Tue May 3 16:46:24 2016 -0400
>
>    net: fix infoleak in rtnetlink
>    
>    [ Upstream commit 5f8e44741f9f216e33736ea4ec65ca9ac03036e6 ]
>    
>    The stack object âmapâ has a total size of 32 bytes. Its last 4
>    bytes are padding generated by compiler. These padding bytes are
>    not initialized and sent out via ânla_putâ.
>    
>    Signed-off-by: Kangjie Lu <kjlu@gatech.edu>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5923f46563d1ce74c1f1178cba5a67735bb83e6d
>Author: Kangjie Lu <kangjielu@gmail.com>
>Date:   Tue May 3 16:35:05 2016 -0400
>
>    net: fix infoleak in llc
>    
>    [ Upstream commit b8670c09f37bdf2847cc44f36511a53afc6161fd ]
>    
>    The stack object âinfoâ has a total size of 12 bytes. Its last byte
>    is padding which is not initialized and leaked via âput_cmsgâ.
>    
>    Signed-off-by: Kangjie Lu <kjlu@gatech.edu>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9a7e38d01e351fc5de11b2a033ced5ff04090b81
>Author: Uwe Kleine-KÃ¶nig <u.kleine-koenig@pengutronix.de>
>Date:   Tue May 3 16:38:53 2016 +0200
>
>    net: fec: only clear a queue's work bit if the queue was emptied
>    
>    [ Upstream commit 1c021bb717a70aaeaa4b25c91f43c2aeddd922de ]
>    
>    In the receive path a queue's work bit was cleared unconditionally even
>    if fec_enet_rx_queue only read out a part of the available packets from
>    the hardware. This resulted in not reading any packets in the next napi
>    turn and so packets were delayed or lost.
>    
>    The obvious fix is to only clear a queue's bit when the queue was
>    emptied.
>    
>    Fixes: 4d494cdc92b3 ("net: fec: change data structure to support multiqueue")
>    Signed-off-by: Uwe Kleine-KÃ¶nig <u.kleine-koenig@pengutronix.de>
>    Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
>    Tested-by: Fugang Duan <fugang.duan@nxp.com>
>    Acked-by: Fugang Duan <fugang.duan@nxp.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5305392b443d3ba1414deff068ca1542f197d5ec
>Author: Neil Horman <nhorman@tuxdriver.com>
>Date:   Mon May 2 12:20:15 2016 -0400
>
>    netem: Segment GSO packets on enqueue
>    
>    [ Upstream commit 6071bd1aa13ed9e41824bafad845b7b7f4df5cfd ]
>    
>    This was recently reported to me, and reproduced on the latest net kernel,
>    when attempting to run netperf from a host that had a netem qdisc attached
>    to the egress interface:
>    
>    [  788.073771] ---------------------[ cut here ]---------------------------
>    [  788.096716] WARNING: at net/core/dev.c:2253 skb_warn_bad_offload+0xcd/0xda()
>    [  788.129521] bnx2: caps=(0x00000001801949b3, 0x0000000000000000) len=2962
>    data_len=0 gso_size=1448 gso_type=1 ip_summed=3
>    [  788.182150] Modules linked in: sch_netem kvm_amd kvm crc32_pclmul ipmi_ssif
>    ghash_clmulni_intel sp5100_tco amd64_edac_mod aesni_intel lrw gf128mul
>    glue_helper ablk_helper edac_mce_amd cryptd pcspkr sg edac_core hpilo ipmi_si
>    i2c_piix4 k10temp fam15h_power hpwdt ipmi_msghandler shpchp acpi_power_meter
>    pcc_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c
>    sd_mod crc_t10dif crct10dif_generic mgag200 syscopyarea sysfillrect sysimgblt
>    i2c_algo_bit drm_kms_helper ahci ata_generic pata_acpi ttm libahci
>    crct10dif_pclmul pata_atiixp tg3 libata crct10dif_common drm crc32c_intel ptp
>    serio_raw bnx2 r8169 hpsa pps_core i2c_core mii dm_mirror dm_region_hash dm_log
>    dm_mod
>    [  788.465294] CPU: 16 PID: 0 Comm: swapper/16 Tainted: G        W
>    ------------   3.10.0-327.el7.x86_64 #1
>    [  788.511521] Hardware name: HP ProLiant DL385p Gen8, BIOS A28 12/17/2012
>    [  788.542260]  ffff880437c036b8 f7afc56532a53db9 ffff880437c03670
>    ffffffff816351f1
>    [  788.576332]  ffff880437c036a8 ffffffff8107b200 ffff880633e74200
>    ffff880231674000
>    [  788.611943]  0000000000000001 0000000000000003 0000000000000000
>    ffff880437c03710
>    [  788.647241] Call Trace:
>    [  788.658817]  <IRQ>  [<ffffffff816351f1>] dump_stack+0x19/0x1b
>    [  788.686193]  [<ffffffff8107b200>] warn_slowpath_common+0x70/0xb0
>    [  788.713803]  [<ffffffff8107b29c>] warn_slowpath_fmt+0x5c/0x80
>    [  788.741314]  [<ffffffff812f92f3>] ? ___ratelimit+0x93/0x100
>    [  788.767018]  [<ffffffff81637f49>] skb_warn_bad_offload+0xcd/0xda
>    [  788.796117]  [<ffffffff8152950c>] skb_checksum_help+0x17c/0x190
>    [  788.823392]  [<ffffffffa01463a1>] netem_enqueue+0x741/0x7c0 [sch_netem]
>    [  788.854487]  [<ffffffff8152cb58>] dev_queue_xmit+0x2a8/0x570
>    [  788.880870]  [<ffffffff8156ae1d>] ip_finish_output+0x53d/0x7d0
>    ...
>    
>    The problem occurs because netem is not prepared to handle GSO packets (as it
>    uses skb_checksum_help in its enqueue path, which cannot manipulate these
>    frames).
>    
>    The solution I think is to simply segment the skb in a simmilar fashion to the
>    way we do in __dev_queue_xmit (via validate_xmit_skb), with some minor changes.
>    When we decide to corrupt an skb, if the frame is GSO, we segment it, corrupt
>    the first segment, and enqueue the remaining ones.
>    
>    tested successfully by myself on the latest net kernel, to which this applies
>    
>    Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
>    CC: Jamal Hadi Salim <jhs@mojatatu.com>
>    CC: "David S. Miller" <davem@davemloft.net>
>    CC: netem@lists.linux-foundation.org
>    CC: eric.dumazet@gmail.com
>    CC: stephen@networkplumber.org
>    Acked-by: Eric Dumazet <edumazet@google.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit dfc58a04d16c3132f3691c021a67938617905679
>Author: WANG Cong <xiyou.wangcong@gmail.com>
>Date:   Thu Feb 25 14:55:03 2016 -0800
>
>    sch_dsmark: update backlog as well
>    
>    [ Upstream commit bdf17661f63a79c3cb4209b970b1cc39e34f7543 ]
>    
>    Similarly, we need to update backlog too when we update qlen.
>    
>    Cc: Jamal Hadi Salim <jhs@mojatatu.com>
>    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 64e1762ae4128508d4a9ef483d77ac52c89f5630
>Author: WANG Cong <xiyou.wangcong@gmail.com>
>Date:   Thu Feb 25 14:55:02 2016 -0800
>
>    sch_htb: update backlog as well
>    
>    [ Upstream commit 431e3a8e36a05a37126f34b41aa3a5a6456af04e ]
>    
>    We saw qlen!=0 but backlog==0 on our production machine:
>    
>    qdisc htb 1: dev eth0 root refcnt 2 r2q 10 default 1 direct_packets_stat 0 ver 3.17
>     Sent 172680457356 bytes 222469449 pkt (dropped 0, overlimits 123575834 requeues 0)
>     backlog 0b 72p requeues 0
>    
>    The problem is we only count qlen for HTB qdisc but not backlog.
>    We need to update backlog too when we update qlen, so that we
>    can at least know the average packet length.
>    
>    Cc: Jamal Hadi Salim <jhs@mojatatu.com>
>    Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
>    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 236094acb4b5c224d68d3b279941d24d555078d4
>Author: WANG Cong <xiyou.wangcong@gmail.com>
>Date:   Thu Feb 25 14:55:01 2016 -0800
>
>    net_sched: update hierarchical backlog too
>    
>    [ Upstream commit 2ccccf5fb43ff62b2b96cc58d95fc0b3596516e4 ]
>    
>    When the bottom qdisc decides to, for example, drop some packet,
>    it calls qdisc_tree_decrease_qlen() to update the queue length
>    for all its ancestors, we need to update the backlog too to
>    keep the stats on root qdisc accurate.
>    
>    Cc: Jamal Hadi Salim <jhs@mojatatu.com>
>    Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
>    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 11316d7eef2230000bb4fa3d4b9056690fda3ef2
>Author: WANG Cong <xiyou.wangcong@gmail.com>
>Date:   Thu Feb 25 14:55:00 2016 -0800
>
>    net_sched: introduce qdisc_replace() helper
>    
>    [ Upstream commit 86a7996cc8a078793670d82ed97d5a99bb4e8496 ]
>    
>    Remove nearly duplicated code and prepare for the following patch.
>    
>    Cc: Jamal Hadi Salim <jhs@mojatatu.com>
>    Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
>    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7b6460337ed23f3b29958e853f7d1f191bfd844d
>Author: Jann Horn <jannh@google.com>
>Date:   Tue Apr 26 22:26:26 2016 +0200
>
>    bpf: fix double-fdput in replace_map_fd_with_map_ptr()
>    
>    [ Upstream commit 8358b02bf67d3a5d8a825070e1aa73f25fb2e4c7 ]
>    
>    When bpf(BPF_PROG_LOAD, ...) was invoked with a BPF program whose bytecode
>    references a non-map file descriptor as a map file descriptor, the error
>    handling code called fdput() twice instead of once (in __bpf_map_get() and
>    in replace_map_fd_with_map_ptr()). If the file descriptor table of the
>    current task is shared, this causes f_count to be decremented too much,
>    allowing the struct file to be freed while it is still in use
>    (use-after-free). This can be exploited to gain root privileges by an
>    unprivileged user.
>    
>    This bug was introduced in
>    commit 0246e64d9a5f ("bpf: handle pseudo BPF_LD_IMM64 insn"), but is only
>    exploitable since
>    commit 1be7f75d1668 ("bpf: enable non-root eBPF programs") because
>    previously, CAP_SYS_ADMIN was required to reach the vulnerable code.
>    
>    (posted publicly according to request by maintainer)
>    
>    Signed-off-by: Jann Horn <jannh@google.com>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Acked-by: Alexei Starovoitov <ast@kernel.org>
>    Acked-by: Daniel Borkmann <daniel@iogearbox.net>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit eeee948a652e9ee02643bf031cd613339ccc6864
>Author: Eric Dumazet <edumazet@google.com>
>Date:   Sat Apr 23 11:35:46 2016 -0700
>
>    net/mlx4_en: fix spurious timestamping callbacks
>    
>    [ Upstream commit fc96256c906362e845d848d0f6a6354450059e81 ]
>    
>    When multiple skb are TX-completed in a row, we might incorrectly keep
>    a timestamp of a prior skb and cause extra work.
>    
>    Fixes: ec693d47010e8 ("net/mlx4_en: Add HW timestamping (TS) support")
>    Signed-off-by: Eric Dumazet <edumazet@google.com>
>    Cc: Willem de Bruijn <willemb@google.com>
>    Reviewed-by: Eran Ben Elisha <eranbe@mellanox.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2c5ac2bfe56da842b7c84e99e9811f118b6f7a17
>Author: Paolo Abeni <pabeni@redhat.com>
>Date:   Thu Apr 21 22:23:31 2016 +0200
>
>    ipv4/fib: don't warn when primary address is missing if in_dev is dead
>    
>    [ Upstream commit 391a20333b8393ef2e13014e6e59d192c5594471 ]
>    
>    After commit fbd40ea0180a ("ipv4: Don't do expensive useless work
>    during inetdev destroy.") when deleting an interface,
>    fib_del_ifaddr() can be executed without any primary address
>    present on the dead interface.
>    
>    The above is safe, but triggers some "bug: prim == NULL" warnings.
>    
>    This commit avoids warning if the in_dev is dead
>    
>    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 303c69a17dc9ec4c26682dfcf7be27805544354e
>Author: Simon Horman <simon.horman@netronome.com>
>Date:   Thu Apr 21 11:49:15 2016 +1000
>
>    openvswitch: use flow protocol when recalculating ipv6 checksums
>    
>    [ Upstream commit b4f70527f052b0c00be4d7cac562baa75b212df5 ]
>    
>    When using masked actions the ipv6_proto field of an action
>    to set IPv6 fields may be zero rather than the prevailing protocol
>    which will result in skipping checksum recalculation.
>    
>    This patch resolves the problem by relying on the protocol
>    in the flow key rather than that in the set field action.
>    
>    Fixes: 83d2b9ba1abc ("net: openvswitch: Support masked set actions.")
>    Cc: Jarno Rajahalme <jrajahalme@nicira.com>
>    Signed-off-by: Simon Horman <simon.horman@netronome.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a2e388f2537a23348810b20ae82468f13d3fb123
>Author: Ben Hutchings <ben@decadent.org.uk>
>Date:   Wed Apr 20 23:23:08 2016 +0100
>
>    atl2: Disable unimplemented scatter/gather feature
>    
>    [ Upstream commit f43bfaeddc79effbf3d0fcb53ca477cca66f3db8 ]
>    
>    atl2 includes NETIF_F_SG in hw_features even though it has no support
>    for non-linear skbs.  This bug was originally harmless since the
>    driver does not claim to implement checksum offload and that used to
>    be a requirement for SG.
>    
>    Now that SG and checksum offload are independent features, if you
>    explicitly enable SG *and* use one of the rare protocols that can use
>    SG without checkusm offload, this potentially leaks sensitive
>    information (before you notice that it just isn't working).  Therefore
>    this obscure bug has been designated CVE-2016-2117.
>    
>    Reported-by: Justin Yackoski <jyackoski@crypto-nite.com>
>    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
>    Fixes: ec5f06156423 ("net: Kill link between CSUM and SG features.")
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a4e1611c8bc5e331e07bea540d3571911df6ac52
>Author: Alexei Starovoitov <ast@fb.com>
>Date:   Tue Apr 12 10:26:19 2016 -0700
>
>    bpf/verifier: reject invalid LD_ABS | BPF_DW instruction
>    
>    [ Upstream commit d82bccc69041a51f7b7b9b4a36db0772f4cdba21 ]
>    
>    verifier must check for reserved size bits in instruction opcode and
>    reject BPF_LD | BPF_ABS | BPF_DW and BPF_LD | BPF_IND | BPF_DW instructions,
>    otherwise interpreter will WARN_RATELIMIT on them during execution.
>    
>    Fixes: ddd872bc3098 ("bpf: verifier: add checks for BPF_ABS | BPF_IND instructions")
>    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
>    Acked-by: Daniel Borkmann <daniel@iogearbox.net>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5730fd5d72071c9ae96929292351029ea56de7c0
>Author: Lars Persson <lars.persson@axis.com>
>Date:   Tue Apr 12 08:45:52 2016 +0200
>
>    net: sched: do not requeue a NULL skb
>    
>    [ Upstream commit 3dcd493fbebfd631913df6e2773cc295d3bf7d22 ]
>    
>    A failure in validate_xmit_skb_list() triggered an unconditional call
>    to dev_requeue_skb with skb=NULL. This slowly grows the queue
>    discipline's qlen count until all traffic through the queue stops.
>    
>    We take the optimistic approach and continue running the queue after a
>    failure since it is unknown if later packets also will fail in the
>    validate path.
>    
>    Fixes: 55a93b3ea780 ("qdisc: validate skb without holding lock")
>    Signed-off-by: Lars Persson <larper@axis.com>
>    Acked-by: Eric Dumazet <edumazet@google.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4b5223be98e1972e177f319159a29eb3bab2720e
>Author: Mathias Krause <minipli@googlemail.com>
>Date:   Sun Apr 10 12:52:28 2016 +0200
>
>    packet: fix heap info leak in PACKET_DIAG_MCLIST sock_diag interface
>    
>    [ Upstream commit 309cf37fe2a781279b7675d4bb7173198e532867 ]
>    
>    Because we miss to wipe the remainder of i->addr[] in packet_mc_add(),
>    pdiag_put_mclist() leaks uninitialized heap bytes via the
>    PACKET_DIAG_MCLIST netlink attribute.
>    
>    Fix this by explicitly memset(0)ing the remaining bytes in i->addr[].
>    
>    Fixes: eea68e2f1a00 ("packet: Report socket mclist info via diag module")
>    Signed-off-by: Mathias Krause <minipli@googlemail.com>
>    Cc: Eric W. Biederman <ebiederm@xmission.com>
>    Cc: Pavel Emelyanov <xemul@parallels.com>
>    Acked-by: Pavel Emelyanov <xemul@virtuozzo.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 80565d16c385958217a0c204f19475ce8210e64a
>Author: Chris Friesen <chris.friesen@windriver.com>
>Date:   Fri Apr 8 15:21:30 2016 -0600
>
>    route: do not cache fib route info on local routes with oif
>    
>    [ Upstream commit d6d5e999e5df67f8ec20b6be45e2229455ee3699 ]
>    
>    For local routes that require a particular output interface we do not want
>    to cache the result.  Caching the result causes incorrect behaviour when
>    there are multiple source addresses on the interface.  The end result
>    being that if the intended recipient is waiting on that interface for the
>    packet he won't receive it because it will be delivered on the loopback
>    interface and the IP_PKTINFO ipi_ifindex will be set to the loopback
>    interface as well.
>    
>    This can be tested by running a program such as "dhcp_release" which
>    attempts to inject a packet on a particular interface so that it is
>    received by another program on the same board.  The receiving process
>    should see an IP_PKTINFO ipi_ifndex value of the source interface
>    (e.g., eth1) instead of the loopback interface (e.g., lo).  The packet
>    will still appear on the loopback interface in tcpdump but the important
>    aspect is that the CMSG info is correct.
>    
>    Sample dhcp_release command line:
>    
>       dhcp_release eth1 192.168.204.222 02:11:33:22:44:66
>    
>    Signed-off-by: Allain Legacy <allain.legacy@windriver.com>
>    Signed off-by: Chris Friesen <chris.friesen@windriver.com>
>    Reviewed-by: Julian Anastasov <ja@ssi.bg>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1ea4df4a2642ba2856a70e4530ae922f0c8e672e
>Author: David S. Miller <davem@davemloft.net>
>Date:   Sun Apr 10 23:01:30 2016 -0400
>
>    decnet: Do not build routes to devices without decnet private data.
>    
>    [ Upstream commit a36a0d4008488fa545c74445d69eaf56377d5d4e ]
>    
>    In particular, make sure we check for decnet private presence
>    for loopback devices.
>    
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 51319f40e513500085f25ae42ace31b8bc4bcfc2
>Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
>Date:   Wed Mar 23 21:07:39 2016 -0700
>
>    ACPI / processor: Request native thermal interrupt handling via _OSC
>    
>    [ Upstream commit a21211672c9a1d730a39aa65d4a5b3414700adfb ]
>    
>    There are several reports of freeze on enabling HWP (Hardware PStates)
>    feature on Skylake-based systems by the Intel P-states driver. The root
>    cause is identified as the HWP interrupts causing BIOS code to freeze.
>    
>    HWP interrupts use the thermal LVT which can be handled by Linux
>    natively, but on the affected Skylake-based systems SMM will respond
>    to it by default.  This is a problem for several reasons:
>     - On the affected systems the SMM thermal LVT handler is broken (it
>       will crash when invoked) and a BIOS update is necessary to fix it.
>     - With thermal interrupt handled in SMM we lose all of the reporting
>       features of the arch/x86/kernel/cpu/mcheck/therm_throt driver.
>     - Some thermal drivers like x86-package-temp depend on the thermal
>       threshold interrupts signaled via the thermal LVT.
>     - The HWP interrupts are useful for debugging and tuning
>       performance (if the kernel can handle them).
>    The native handling of thermal interrupts needs to be enabled
>    because of that.
>    
>    This requires some way to tell SMM that the OS can handle thermal
>    interrupts.  That can be done by using _OSC/_PDC in processor
>    scope very early during ACPI initialization.
>    
>    The meaning of _OSC/_PDC bit 12 in processor scope is whether or
>    not the OS supports native handling of interrupts for Collaborative
>    Processor Performance Control (CPPC) notifications.  Since on
>    HWP-capable systems CPPC is a firmware interface to HWP, setting
>    this bit effectively tells the firmware that the OS will handle
>    thermal interrupts natively going forward.
>    
>    For details on _OSC/_PDC refer to:
>    http://www.intel.com/content/www/us/en/standards/processor-vendor-specific-acpi-specification.html
>    
>    To implement the _OSC/_PDC handshake as described, introduce a new
>    function, acpi_early_processor_osc(), that walks the ACPI
>    namespace looking for ACPI processor objects and invokes _OSC for
>    them with bit 12 in the capabilities buffer set and terminates the
>    namespace walk on the first success.
>    
>    Also modify intel_thermal_interrupt() to clear HWP status bits in
>    the HWP_STATUS MSR to acknowledge HWP interrupts (which prevents
>    them from firing continuously).
>    
>    Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
>    [ rjw: Subject & changelog, function rename ]
>    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit fd4453a9c8a4ccc784a51c71411b113f8a997ea1
>Author: Richard Leitner <dev@g0hl1n.net>
>Date:   Tue Apr 5 15:03:48 2016 +0200
>
>    iio: ak8975: fix maybe-uninitialized warning
>    
>    [ Upstream commit 05be8d4101d960bad271d32b4f6096af1ccb1534 ]
>    
>    If i2c_device_id *id is NULL and acpi_match_device returns NULL too,
>    then chipset may be unitialized when accessing &ak_def_array[chipset] in
>    ak8975_probe. Therefore initialize chipset to AK_MAX_TYPE, which will
>    return an error when not changed.
>    
>    This patch fixes the following maybe-uninitialized warning:
>    
>    drivers/iio/magnetometer/ak8975.c: In function âak8975_probeâ:
>    drivers/iio/magnetometer/ak8975.c:788:14: warning: âchipsetâ may be used
>    uninitialized in this function [-Wmaybe-uninitialized]
>      data->def = &ak_def_array[chipset];
>    
>    Signed-off-by: Richard Leitner <dev@g0hl1n.net>
>    Cc: <Stable@vger.kernel.org>
>    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b55c212a0f25d8999b9601a120506861d85f6fd3
>Author: Sven Eckelmann <sven@narfation.org>
>Date:   Sun Mar 20 12:27:53 2016 +0100
>
>    batman-adv: Reduce refcnt of removed router when updating route
>    
>    [ Upstream commit d1a65f1741bfd9c69f9e4e2ad447a89b6810427d ]
>    
>    _batadv_update_route rcu_derefences orig_ifinfo->router outside of a
>    spinlock protected region to print some information messages to the debug
>    log. But this pointer is not checked again when the new pointer is assigned
>    in the spinlock protected region. Thus is can happen that the value of
>    orig_ifinfo->router changed in the meantime and thus the reference counter
>    of the wrong router gets reduced after the spinlock protected region.
>    
>    Just rcu_dereferencing the value of orig_ifinfo->router inside the spinlock
>    protected region (which also set the new pointer) is enough to get the
>    correct old router object.
>    
>    Fixes: e1a5382f978b ("batman-adv: Make orig_node->router an rcu protected pointer")
>    Signed-off-by: Sven Eckelmann <sven@narfation.org>
>    Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
>    Signed-off-by: Antonio Quartulli <a@unstable.cc>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit eaa401a078fffcd5e1d078cb10b0efcd8e2d6c20
>Author: Linus LÃ¼ssing <linus.luessing@c0d3.blue>
>Date:   Fri Mar 11 14:04:49 2016 +0100
>
>    batman-adv: Fix broadcast/ogm queue limit on a removed interface
>    
>    [ Upstream commit c4fdb6cff2aa0ae740c5f19b6f745cbbe786d42f ]
>    
>    When removing a single interface while a broadcast or ogm packet is
>    still pending then we will free the forward packet without releasing the
>    queue slots again.
>    
>    This patch is supposed to fix this issue.
>    
>    Fixes: 6d5808d4ae1b ("batman-adv: Add missing hardif_free_ref in forw_packet_free")
>    Signed-off-by: Linus LÃ¼ssing <linus.luessing@c0d3.blue>
>    [sven@narfation.org: fix conflicts with current version]
>    Signed-off-by: Sven Eckelmann <sven@narfation.org>
>    Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
>    Signed-off-by: Antonio Quartulli <a@unstable.cc>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f7ac631102975609851be1969f7d89a77ecaa52e
>Author: Sven Eckelmann <sven@narfation.org>
>Date:   Fri Feb 26 17:56:13 2016 +0100
>
>    batman-adv: Check skb size before using encapsulated ETH+VLAN header
>    
>    [ Upstream commit c78296665c3d81f040117432ab9e1cb125521b0c ]
>    
>    The encapsulated ethernet and VLAN header may be outside the received
>    ethernet frame. Thus the skb buffer size has to be checked before it can be
>    parsed to find out if it encapsulates another batman-adv packet.
>    
>    Fixes: 420193573f11 ("batman-adv: softif bridge loop avoidance")
>    Signed-off-by: Sven Eckelmann <sven@narfation.org>
>    Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
>    Signed-off-by: Antonio Quartulli <a@unstable.cc>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7b1f624b9e5dbba4d7613a9b9050526eba6da626
>Author: Jason Baron <jbaron@akamai.com>
>Date:   Thu May 5 16:22:12 2016 -0700
>
>    mm: update min_free_kbytes from khugepaged after core initialization
>    
>    [ Upstream commit bc22af74f271ef76b2e6f72f3941f91f0da3f5f8 ]
>    
>    Khugepaged attempts to raise min_free_kbytes if its set too low.
>    However, on boot khugepaged sets min_free_kbytes first from
>    subsys_initcall(), and then the mm 'core' over-rides min_free_kbytes
>    after from init_per_zone_wmark_min(), via a module_init() call.
>    
>    Khugepaged used to use a late_initcall() to set min_free_kbytes (such
>    that it occurred after the core initialization), however this was
>    removed when the initialization of min_free_kbytes was integrated into
>    the starting of the khugepaged thread.
>    
>    The fix here is simply to invoke the core initialization using a
>    core_initcall() instead of module_init(), such that the previous
>    initialization ordering is restored.  I didn't restore the
>    late_initcall() since start_stop_khugepaged() already sets
>    min_free_kbytes via set_recommended_min_free_kbytes().
>    
>    This was noticed when we had a number of page allocation failures when
>    moving a workload to a kernel with this new initialization ordering.  On
>    an 8GB system this restores min_free_kbytes back to 67584 from 11365
>    when CONFIG_TRANSPARENT_HUGEPAGE=y is set and either
>    CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y or
>    CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y.
>    
>    Fixes: 79553da293d3 ("thp: cleanup khugepaged startup")
>    Signed-off-by: Jason Baron <jbaron@akamai.com>
>    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>    Acked-by: David Rientjes <rientjes@google.com>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 93c4863f4435023fcfdae542039860349189b334
>Author: Mathias Krause <minipli@googlemail.com>
>Date:   Thu May 5 16:22:26 2016 -0700
>
>    proc: prevent accessing /proc/<PID>/environ until it's ready
>    
>    [ Upstream commit 8148a73c9901a8794a50f950083c00ccf97d43b3 ]
>    
>    If /proc/<PID>/environ gets read before the envp[] array is fully set up
>    in create_{aout,elf,elf_fdpic,flat}_tables(), we might end up trying to
>    read more bytes than are actually written, as env_start will already be
>    set but env_end will still be zero, making the range calculation
>    underflow, allowing to read beyond the end of what has been written.
>    
>    Fix this as it is done for /proc/<PID>/cmdline by testing env_end for
>    zero.  It is, apparently, intentionally set last in create_*_tables().
>    
>    This bug was found by the PaX size_overflow plugin that detected the
>    arithmetic underflow of 'this_len = env_end - (env_start + src)' when
>    env_end is still zero.
>    
>    The expected consequence is that userland trying to access
>    /proc/<PID>/environ of a not yet fully set up process may get
>    inconsistent data as we're in the middle of copying in the environment
>    variables.
>    
>    Fixes: https://forums.grsecurity.net/viewtopic.php?f=3&t=4363
>    Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=116461
>    Signed-off-by: Mathias Krause <minipli@googlemail.com>
>    Cc: Emese Revfy <re.emese@gmail.com>
>    Cc: Pax Team <pageexec@freemail.hu>
>    Cc: Al Viro <viro@zeniv.linux.org.uk>
>    Cc: Mateusz Guzik <mguzik@redhat.com>
>    Cc: Alexey Dobriyan <adobriyan@gmail.com>
>    Cc: Cyrill Gorcunov <gorcunov@openvz.org>
>    Cc: Jarod Wilson <jarod@redhat.com>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d6c812a33d16d1e2dd9ab209c69d9755da5cc425
>Author: Knut Wohlrab <Knut.Wohlrab@de.bosch.com>
>Date:   Mon Apr 25 14:08:25 2016 -0700
>
>    Input: zforce_ts - fix dual touch recognition
>    
>    [ Upstream commit 6984ab1ab35f422292b7781c65284038bcc0f6a6 ]
>    
>    A wrong decoding of the touch coordinate message causes a wrong touch
>    ID. Touch ID for dual touch must be 0 or 1.
>    
>    According to the actual Neonode nine byte touch coordinate coding,
>    the state is transported in the lower nibble and the touch ID in
>    the higher nibble of payload byte five.
>    
>    Signed-off-by: Knut Wohlrab <Knut.Wohlrab@de.bosch.com>
>    Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
>    Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com>
>    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b7c61d507c7f67c6441da26942c5c65c49511d35
>Author: Arnd Bergmann <arnd@arndb.de>
>Date:   Mon Mar 14 15:29:44 2016 +0100
>
>    lpfc: fix misleading indentation
>    
>    [ Upstream commit aeb6641f8ebdd61939f462a8255b316f9bfab707 ]
>    
>    gcc-6 complains about the indentation of the lpfc_destroy_vport_work_array()
>    call in lpfc_online(), which clearly doesn't look right:
>    
>    drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_online':
>    drivers/scsi/lpfc/lpfc_init.c:2880:3: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation]
>       lpfc_destroy_vport_work_array(phba, vports);
>       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>    drivers/scsi/lpfc/lpfc_init.c:2863:2: note: ...this 'if' clause, but it is not
>      if (vports != NULL)
>      ^~
>    
>    Looking at the patch that introduced this code, it's clear that the
>    behavior is correct and the indentation is wrong.
>    
>    This fixes the indentation and adds curly braces around the previous
>    if() block for clarity, as that is most likely what caused the code
>    to be misindented in the first place.
>    
>    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>    Fixes: 549e55cd2a1b ("[SCSI] lpfc 8.2.2 : Fix locking around HBA's port_list")
>    Reviewed-by: Sebastian Herbszt <herbszt@gmx.de>
>    Reviewed-by: Hannes Reinecke <hare@suse.com>
>    Reviewed-by: Ewan D. Milne <emilne@redhat.com>
>    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8859f16ee6d1c3ceb81e7b295cd9b3ff0689228e
>Author: Stephen Boyd <sboyd@codeaurora.org>
>Date:   Tue Mar 1 17:26:48 2016 -0800
>
>    clk: qcom: msm8960: Fix ce3_src register offset
>    
>    [ Upstream commit 0f75e1a370fd843c9e508fc1ccf0662833034827 ]
>    
>    The offset seems to have been copied from the sata clk. Fix it so
>    that enabling the crypto engine source clk works.
>    
>    Tested-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>    Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>    Fixes: 5f775498bdc4 ("clk: qcom: Fully support apq8064 global clock control")
>    Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b1a774dd632be6ec5494b0eaf55981b561ddec22
>Author: Linus Walleij <linus.walleij@linaro.org>
>Date:   Wed Feb 24 09:39:11 2016 +0100
>
>    clk: versatile: sp810: support reentrance
>    
>    [ Upstream commit ec7957a6aa0aaf981fb8356dc47a2cdd01cde03c ]
>    
>    Despite care take to allocate clocks state containers the
>    SP810 driver actually just supports creating one instance:
>    all clocks registered for every instance will end up with the
>    exact same name and __clk_init() will fail.
>    
>    Rename the timclken<0> .. timclken<n> to sp810_<instance>_<n>
>    so every clock on every instance gets a unique name.
>    
>    This is necessary for the RealView PBA8 which has two SP810
>    blocks: the second block will not register its clocks unless
>    every clock on every instance is unique and results in boot
>    logs like this:
>    
>    ------------[ cut here ]------------
>    WARNING: CPU: 0 PID: 0 at ../drivers/clk/versatile/clk-sp810.c:137
>      clk_sp810_of_setup+0x110/0x154()
>    Modules linked in:
>    CPU: 0 PID: 0 Comm: swapper/0 Not tainted
>    4.5.0-rc2-00030-g352718fc39f6-dirty #225
>    Hardware name: ARM RealView Machine (Device Tree Support)
>    [<c00167f8>] (unwind_backtrace) from [<c0013204>]
>                 (show_stack+0x10/0x14)
>    [<c0013204>] (show_stack) from [<c01a049c>]
>                 (dump_stack+0x84/0x9c)
>    [<c01a049c>] (dump_stack) from [<c0024990>]
>                 (warn_slowpath_common+0x74/0xb0)
>    [<c0024990>] (warn_slowpath_common) from [<c0024a68>]
>                 (warn_slowpath_null+0x1c/0x24)
>    [<c0024a68>] (warn_slowpath_null) from [<c051eb44>]
>                 (clk_sp810_of_setup+0x110/0x154)
>    [<c051eb44>] (clk_sp810_of_setup) from [<c051e3a4>]
>                 (of_clk_init+0x12c/0x1c8)
>    [<c051e3a4>] (of_clk_init) from [<c0504714>]
>                 (time_init+0x20/0x2c)
>    [<c0504714>] (time_init) from [<c0501b18>]
>                 (start_kernel+0x244/0x3c4)
>    [<c0501b18>] (start_kernel) from [<7000807c>] (0x7000807c)
>    ---[ end trace cb88537fdc8fa200 ]---
>    
>    Cc: Michael Turquette <mturquette@baylibre.com>
>    Cc: Pawel Moll <pawel.moll@arm.com>
>    Fixes: 6e973d2c4385 "clk: vexpress: Add separate SP810 driver"
>    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>    Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5356deeafda4e139a44f6f82a99439d93a7b84cf
>Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>Date:   Mon Feb 22 11:43:39 2016 +0000
>
>    clk: qcom: msm8960: fix ce3_core clk enable register
>    
>    [ Upstream commit 732d6913691848db9fabaa6a25b4d6fad10ddccf ]
>    
>    This patch corrects the enable register offset which is actually 0x36cc
>    instead of 0x36c4
>    
>    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>    Fixes: 5f775498bdc4 ("clk: qcom: Fully support apq8064 global clock control")
>    Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ea0b24134918a838f1ff94ac4707d3dcc637630c
>Author: Shawn Lin <shawn.lin@rock-chips.com>
>Date:   Tue Feb 2 11:37:50 2016 +0800
>
>    clk: rockchip: free memory in error cases when registering clock branches
>    
>    [ Upstream commit 2467b6745e0ae9c6cdccff24c4cceeb14b1cce3f ]
>    
>    Add free memeory if rockchip_clk_register_branch fails.
>    
>    Fixes: a245fecbb806 ("clk: rockchip: add basic infrastructure...")
>    Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
>    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9eb52957b6a4a3e86ae25735c5cf1f1945ad33c4
>Author: Dan Streetman <dan.streetman@canonical.com>
>Date:   Thu Jan 14 13:42:32 2016 -0500
>
>    nbd: ratelimit error msgs after socket close
>    
>    [ Upstream commit da6ccaaa79caca4f38b540b651238f87215217a2 ]
>    
>    Make the "Attempted send on closed socket" error messages generated in
>    nbd_request_handler() ratelimited.
>    
>    When the nbd socket is shutdown, the nbd_request_handler() function emits
>    an error message for every request remaining in its queue.  If the queue
>    is large, this will spam a large amount of messages to the log.  There's
>    no need for a separate error message for each request, so this patch
>    ratelimits it.
>    
>    In the specific case this was found, the system was virtual and the error
>    messages were logged to the serial port, which overwhelmed it.
>    
>    Fixes: 4d48a542b427 ("nbd: fix I/O hang on disconnected nbds")
>    Signed-off-by: Dan Streetman <dan.streetman@canonical.com>
>    Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7361f006e36e20a81edede6724be39e718d4347f
>Author: Julian Anastasov <ja@ssi.bg>
>Date:   Sat Mar 5 15:03:22 2016 +0200
>
>    ipvs: drop first packet to redirect conntrack
>    
>    [ Upstream commit f719e3754ee2f7275437e61a6afd520181fdd43b ]
>    
>    Jiri Bohac is reporting for a problem where the attempt
>    to reschedule existing connection to another real server
>    needs proper redirect for the conntrack used by the IPVS
>    connection. For example, when IPVS connection is created
>    to NAT-ed real server we alter the reply direction of
>    conntrack. If we later decide to select different real
>    server we can not alter again the conntrack. And if we
>    expire the old connection, the new connection is left
>    without conntrack.
>    
>    So, the only way to redirect both the IPVS connection and
>    the Netfilter's conntrack is to drop the SYN packet that
>    hits existing connection, to wait for the next jiffie
>    to expire the old connection and its conntrack and to rely
>    on client's retransmission to create new connection as
>    usually.
>    
>    Jiri Bohac provided a fix that drops all SYNs on rescheduling,
>    I extended his patch to do such drops only for connections
>    that use conntrack. Here is the original report from Jiri Bohac:
>    
>    Since commit dc7b3eb900aa ("ipvs: Fix reuse connection if real server
>    is dead"), new connections to dead servers are redistributed
>    immediately to new servers.  The old connection is expired using
>    ip_vs_conn_expire_now() which sets the connection timer to expire
>    immediately.
>    
>    However, before the timer callback, ip_vs_conn_expire(), is run
>    to clean the connection's conntrack entry, the new redistributed
>    connection may already be established and its conntrack removed
>    instead.
>    
>    Fix this by dropping the first packet of the new connection
>    instead, like we do when the destination server is not available.
>    The timer will have deleted the old conntrack entry long before
>    the first packet of the new connection is retransmitted.
>    
>    Fixes: dc7b3eb900aa ("ipvs: Fix reuse connection if real server is dead")
>    Signed-off-by: Jiri Bohac <jbohac@suse.cz>
>    Signed-off-by: Julian Anastasov <ja@ssi.bg>
>    Signed-off-by: Simon Horman <horms@verge.net.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 98f453547cfb0e1a1295e13905214a9f592d1e1c
>Author: Marco Angaroni <marcoangaroni@gmail.com>
>Date:   Sat Mar 5 12:10:02 2016 +0100
>
>    ipvs: correct initial offset of Call-ID header search in SIP persistence engine
>    
>    [ Upstream commit 7617a24f83b5d67f4dab1844956be1cebc44aec8 ]
>    
>    The IPVS SIP persistence engine is not able to parse the SIP header
>    "Call-ID" when such header is inserted in the first positions of
>    the SIP message.
>    
>    When IPVS is configured with "--pe sip" option, like for example:
>    ipvsadm -A -u 1.2.3.4:5060 -s rr --pe sip -p 120 -o
>    some particular messages (see below for details) do not create entries
>    in the connection template table, which can be listed with:
>    ipvsadm -Lcn --persistent-conn
>    
>    Problematic SIP messages are SIP responses having "Call-ID" header
>    positioned just after message first line:
>    SIP/2.0 200 OK
>    [Call-ID header here]
>    [rest of the headers]
>    
>    When "Call-ID" header is positioned down (after a few other headers)
>    it is correctly recognized.
>    
>    This is due to the data offset used in get_callid function call inside
>    ip_vs_pe_sip.c file: since dptr already points to the start of the
>    SIP message, the value of dataoff should be initially 0.
>    Otherwise the header is searched starting from some bytes after the
>    first character of the SIP message.
>    
>    Fixes: 758ff0338722 ("IPVS: sip persistence engine")
>    Signed-off-by: Marco Angaroni <marcoangaroni@gmail.com>
>    Acked-by: Julian Anastasov <ja@ssi.bg>
>    Signed-off-by: Simon Horman <horms@verge.net.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7267c9680f5a0ca9e068bb8986b3c336fd02bb1e
>Author: Arnd Bergmann <arnd@arndb.de>
>Date:   Mon Mar 14 15:29:45 2016 +0100
>
>    megaraid_sas: add missing curly braces in ioctl handler
>    
>    [ Upstream commit 3deb9438d34a09f6796639b652a01d110aca9f75 ]
>    
>    gcc-6 found a dubious indentation in the megasas_mgmt_fw_ioctl
>    function:
>    
>    drivers/scsi/megaraid/megaraid_sas_base.c: In function 'megasas_mgmt_fw_ioctl':
>    drivers/scsi/megaraid/megaraid_sas_base.c:6658:4: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation]
>        kbuff_arr[i] = NULL;
>        ^~~~~~~~~
>    drivers/scsi/megaraid/megaraid_sas_base.c:6653:3: note: ...this 'if' clause, but it is not
>       if (kbuff_arr[i])
>       ^~
>    
>    The code is actually correct, as there is no downside in clearing a NULL
>    pointer again.
>    
>    This clarifies the code and avoids the warning by adding extra curly
>    braces.
>    
>    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>    Fixes: 90dc9d98f01b ("megaraid_sas : MFI MPT linked list corruption fix")
>    Reviewed-by: Hannes Reinecke <hare@suse.com>
>    Acked-by: Sumit Saxena <sumit.saxena@broadcom.com>
>    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e28574abf31fbce4ae38606989b3f18e72838b97
>Author: NeilBrown <neilb@suse.com>
>Date:   Fri Mar 4 17:20:13 2016 +1100
>
>    sunrpc/cache: drop reference when sunrpc_cache_pipe_upcall() detects a race
>    
>    [ Upstream commit a6ab1e8126d205238defbb55d23661a3a5c6a0d8 ]
>    
>    sunrpc_cache_pipe_upcall() can detect a race if CACHE_PENDING is no longer
>    set.  In this case it aborts the queuing of the upcall.
>    However it has already taken a new counted reference on "h" and
>    doesn't "put" it, even though it frees the data structure holding the reference.
>    
>    So let's delay the "cache_get" until we know we need it.
>    
>    Fixes: f9e1aedc6c79 ("sunrpc/cache: remove races with queuing an upcall.")
>    Signed-off-by: NeilBrown <neilb@suse.com>
>    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 00c0a9f44f68bfe9af73f84cdb93b1695da66b44
>Author: Guo-Fu Tseng <cooldavid@cooldavid.org>
>Date:   Sat Mar 5 08:11:56 2016 +0800
>
>    jme: Fix device PM wakeup API usage
>    
>    [ Upstream commit 81422e672f8181d7ad1ee6c60c723aac649f538f ]
>    
>    According to Documentation/power/devices.txt
>    
>    The driver should not use device_set_wakeup_enable() which is the policy
>    for user to decide.
>    
>    Using device_init_wakeup() to initialize dev->power.should_wakeup and
>    dev->power.can_wakeup on driver initialization.
>    
>    And use device_may_wakeup() on suspend to decide if WoL function should
>    be enabled on NIC.
>    
>    Reported-by: Diego Viola <diego.viola@gmail.com>
>    Signed-off-by: Guo-Fu Tseng <cooldavid@cooldavid.org>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 781fff9fdb879457cd067994f162fa2dc21f4bbc
>Author: Guo-Fu Tseng <cooldavid@cooldavid.org>
>Date:   Sat Mar 5 08:11:55 2016 +0800
>
>    jme: Do not enable NIC WoL functions on S0
>    
>    [ Upstream commit 0772a99b818079e628a1da122ac7ee023faed83e ]
>    
>    Otherwise it might be back on resume right after going to suspend in
>    some hardware.
>    
>    Reported-by: Diego Viola <diego.viola@gmail.com>
>    Signed-off-by: Guo-Fu Tseng <cooldavid@cooldavid.org>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 61116b29f126e6e7a6975f9a391d18ecd3bad83d
>Author: Pali RohÃ¡r <pali.rohar@gmail.com>
>Date:   Fri Feb 19 10:35:39 2016 -0800
>
>    ARM: OMAP3: Add cpuidle parameters table for omap3430
>    
>    [ Upstream commit 98f42221501353067251fbf11e732707dbb68ce3 ]
>    
>    Based on CPU type choose generic omap3 or omap3430 specific cpuidle
>    parameters. Parameters for omap3430 were measured on Nokia N900 device and
>    added by commit 5a1b1d3a9efa ("OMAP3: RX-51: Pass cpu idle parameters")
>    which were later removed by commit 231900afba52 ("ARM: OMAP3: cpuidle -
>    remove rx51 cpuidle parameters table") due to huge code complexity.
>    
>    This patch brings cpuidle parameters for omap3430 devices again, but uses
>    simple condition based on CPU type.
>    
>    Fixes: 231900afba52 ("ARM: OMAP3: cpuidle - remove rx51 cpuidle
>    parameters table")
>    Signed-off-by: Pali RohÃ¡r <pali.rohar@gmail.com>
>    Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>    Signed-off-by: Tony Lindgren <tony@atomide.com>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 95297bf99436694051ee91fd5eee3c3aa02fda5d
>Author: Borislav Petkov <bp@suse.de>
>Date:   Mon Mar 7 16:44:44 2016 -0300
>
>    perf stat: Document --detailed option
>    
>    [ Upstream commit f594bae08183fb6b57db55387794ece3e1edf6f6 ]
>    
>    I'm surprised this remained undocumented since at least 2011. And it is
>    actually a very useful switch, as Steve and I came to realize recently.
>    
>    Add the text from
>    
>      2cba3ffb9a9d ("perf stat: Add -d -d and -d -d -d options to show more CPU events")
>    
>    which added the incrementing aspect to -d.
>    
>    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
>    Signed-off-by: Borislav Petkov <bp@suse.de>
>    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
>    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
>    Cc: David Ahern <dsahern@gmail.com>
>    Cc: Davidlohr Bueso <dbueso@suse.com>
>    Cc: Jiri Olsa <jolsa@redhat.com>
>    Cc: Mel Gorman <mgorman@suse.com>
>    Cc: Namhyung Kim <namhyung@kernel.org>
>    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Steven Rostedt <rostedt@goodmis.org>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Fixes: 2cba3ffb9a9d ("perf stat: Add -d -d and -d -d -d options to show more CPU events")
>    Link: http://lkml.kernel.org/r/1457347294-32546-1-git-send-email-bp@alien8.de
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit cedfda9c15cbb1404ba6acdc2d3ea3fc73aa76f8
>Author: Marcin Ålusarz <marcin.slusarz@gmail.com>
>Date:   Tue Jan 19 20:03:03 2016 +0100
>
>    perf tools: handle spaces in file names obtained from /proc/pid/maps
>    
>    [ Upstream commit 89fee59b504f86925894fcc9ba79d5c933842f93 ]
>    
>    Steam frequently puts game binaries in folders with spaces.
>    
>    Note: "(deleted)" markers are now treated as part of the file name.
>    
>    Signed-off-by: Marcin Ålusarz <marcin.slusarz@gmail.com>
>    Acked-by: Namhyung Kim <namhyung@kernel.org>
>    Fixes: 6064803313ba ("perf tools: Use sscanf for parsing /proc/pid/maps")
>    Link: http://lkml.kernel.org/r/20160119190303.GA17579@marcin-Inspiron-7720
>    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7925f4fb3d8b5b0c1bb9c5ded85078197c6f87af
>Author: Eryu Guan <guaneryu@gmail.com>
>Date:   Sat Mar 12 21:40:32 2016 -0500
>
>    ext4: fix NULL pointer dereference in ext4_mark_inode_dirty()
>    
>    [ Upstream commit 5e1021f2b6dff1a86a468a1424d59faae2bc63c1 ]
>    
>    ext4_reserve_inode_write() in ext4_mark_inode_dirty() could fail on
>    error (e.g. EIO) and iloc.bh can be NULL in this case. But the error is
>    ignored in the following "if" condition and ext4_expand_extra_isize()
>    might be called with NULL iloc.bh set, which triggers NULL pointer
>    dereference.
>    
>    This is uncovered by commit 8b4953e13f4c ("ext4: reserve code points for
>    the project quota feature"), which enlarges the ext4_inode size, and
>    run the following script on new kernel but with old mke2fs:
>    
>      #/bin/bash
>      mnt=/mnt/ext4
>      devname=ext4-error
>      dev=/dev/mapper/$devname
>      fsimg=/home/fs.img
>    
>      trap cleanup 0 1 2 3 9 15
>    
>      cleanup()
>      {
>              umount $mnt >/dev/null 2>&1
>              dmsetup remove $devname
>              losetup -d $backend_dev
>              rm -f $fsimg
>              exit 0
>      }
>    
>      rm -f $fsimg
>      fallocate -l 1g $fsimg
>      backend_dev=`losetup -f --show $fsimg`
>      devsize=`blockdev --getsz $backend_dev`
>    
>      good_tab="0 $devsize linear $backend_dev 0"
>      error_tab="0 $devsize error $backend_dev 0"
>    
>      dmsetup create $devname --table "$good_tab"
>    
>      mkfs -t ext4 $dev
>      mount -t ext4 -o errors=continue,strictatime $dev $mnt
>    
>      dmsetup load $devname --table "$error_tab" && dmsetup resume $devname
>      echo 3 > /proc/sys/vm/drop_caches
>      ls -l $mnt
>      exit 0
>    
>    [ Patch changed to simplify the function a tiny bit. -- Ted ]
>    
>    Signed-off-by: Eryu Guan <guaneryu@gmail.com>
>    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6e939f787e830777bdafd5d70f13ed6498dc7ac0
>Author: Karol Herbst <nouveau@karolherbst.de>
>Date:   Thu Mar 3 02:03:11 2016 +0100
>
>    x86/mm/kmmio: Fix mmiotrace for hugepages
>    
>    [ Upstream commit cfa52c0cfa4d727aa3e457bf29aeff296c528a08 ]
>    
>    Because Linux might use bigger pages than the 4K pages to handle those mmio
>    ioremaps, the kmmio code shouldn't rely on the pade id as it currently does.
>    
>    Using the memory address instead of the page id lets us look up how big the
>    page is and what its base address is, so that we won't get a page fault
>    within the same page twice anymore.
>    
>    Tested-by: Pierre Moreau <pierre.morrow@free.fr>
>    Signed-off-by: Karol Herbst <nouveau@karolherbst.de>
>    Cc: Andrew Morton <akpm@linux-foundation.org>
>    Cc: Andy Lutomirski <luto@amacapital.net>
>    Cc: Borislav Petkov <bp@alien8.de>
>    Cc: Brian Gerst <brgerst@gmail.com>
>    Cc: Denys Vlasenko <dvlasenk@redhat.com>
>    Cc: H. Peter Anvin <hpa@zytor.com>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Luis R. Rodriguez <mcgrof@suse.com>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Cc: Toshi Kani <toshi.kani@hp.com>
>    Cc: linux-mm@kvack.org
>    Cc: linux-x86_64@vger.kernel.org
>    Cc: nouveau@lists.freedesktop.org
>    Cc: pq@iki.fi
>    Cc: rostedt@goodmis.org
>    Link: http://lkml.kernel.org/r/1456966991-6861-1-git-send-email-nouveau@karolherbst.de
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4385d1a4421af970858491b1c35676271c89c2d9
>Author: Michael Hennerich <michael.hennerich@analog.com>
>Date:   Mon Feb 22 10:20:24 2016 +0100
>
>    drivers/misc/ad525x_dpot: AD5274 fix RDAC read back errors
>    
>    [ Upstream commit f3df53e4d70b5736368a8fe8aa1bb70c1cb1f577 ]
>    
>    Fix RDAC read back errors caused by a typo. Value must shift by 2.
>    
>    Fixes: a4bd394956f2 ("drivers/misc/ad525x_dpot.c: new features")
>    Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d8b755902390e7ceb32a08a82f4c9e1ce72fb11e
>Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>Date:   Thu Feb 4 09:26:35 2016 +0900
>
>    rtc: max77686: Properly handle regmap_irq_get_virq() error code
>    
>    [ Upstream commit fb166ba1d7f0a662f7332f4ff660a0d6f4d76915 ]
>    
>    The regmap_irq_get_virq() can return 0 or -EINVAL in error conditions
>    but driver checked only for value of 0.
>    
>    This could lead to a cast of -EINVAL to an unsigned int used as a
>    interrupt number for devm_request_threaded_irq(). Although this is not
>    yet fatal (devm_request_threaded_irq() will just fail with -EINVAL) but
>    might be a misleading when diagnosing errors.
>    
>    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>    Fixes: 6f1c1e71d933 ("mfd: max77686: Convert to use regmap_irq")
>    Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
>    Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 49d22c01a3ee52d3783465079c64c3974ce53ab7
>Author: Dan Carpenter <dan.carpenter@oracle.com>
>Date:   Wed Mar 2 13:07:45 2016 +0300
>
>    rtc: ds1685: passing bogus values to irq_restore
>    
>    [ Upstream commit 8c09b9fdecab1f4a289f07b46e2ad174b6641928 ]
>    
>    We call spin_lock_irqrestore with "flags" set to zero instead of to the
>    value from spin_lock_irqsave().
>    
>    Fixes: aaaf5fbf56f1 ('rtc: add driver for DS1685 family of real time clocks')
>    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>    Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1d22cdabe02c2c89fa78fc29795336edcc4445c0
>Author: Geert Uytterhoeven <geert@linux-m68k.org>
>Date:   Tue Mar 1 09:50:01 2016 +0100
>
>    rtc: vr41xx: Wire up alarm_irq_enable
>    
>    [ Upstream commit a25f4a95ec3cded34c1250364eba704c5e4fdac4 ]
>    
>    drivers/rtc/rtc-vr41xx.c:229: warning: âvr41xx_rtc_alarm_irq_enableâ defined but not used
>    
>    Apparently the conversion to alarm_irq_enable forgot to wire up the
>    callback.
>    
>    Fixes: 16380c153a69c378 ("RTC: Convert rtc drivers to use the alarm_irq_enable method")
>    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
>    Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit aa9d9e960c1f06ff27438ab61194e877edd6ff83
>Author: Alexander Kochetkov <al.kochet@gmail.com>
>Date:   Sun Mar 6 12:43:57 2016 +0300
>
>    rtc: hym8563: fix invalid year calculation
>    
>    [ Upstream commit d5861262210067fc01b2fb4f7af2fd85a3453f15 ]
>    
>    Year field must be in BCD format, according to
>    hym8563 datasheet.
>    
>    Due to the bug year 2016 became 2010.
>    
>    Fixes: dcaf03849352 ("rtc: add hym8563 rtc-driver")
>    Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
>    Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2de533754013067d325cc1211edcc03e4d14096c
>Author: Ben Hutchings <ben@decadent.org.uk>
>Date:   Mon Dec 14 14:29:23 2015 +0000
>
>    misc/bmp085: Enable building as a module
>    
>    [ Upstream commit 50e6315dba721cbc24ccd6d7b299f1782f210a98 ]
>    
>    Commit 985087dbcb02 'misc: add support for bmp18x chips to the bmp085
>    driver' changed the BMP085 config symbol to a boolean.  I see no
>    reason why the shared code cannot be built as a module, so change it
>    back to tristate.
>    
>    Fixes: 985087dbcb02 ("misc: add support for bmp18x chips to the bmp085 driver")
>    Cc: Eric Andersson <eric.andersson@unixphere.com>
>    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
>    Acked-by: Arnd Bergmann <arnd@arndb.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a5e1649e0c4382a0994e91d958ffa70aa11ac226
>Author: Sushaanth Srirangapathi <sushaanth.s@ti.com>
>Date:   Mon Feb 29 18:42:19 2016 +0530
>
>    fbdev: da8xx-fb: fix videomodes of lcd panels
>    
>    [ Upstream commit 713fced8d10fa1c759c8fb6bf9aaa681bae68cad ]
>    
>    Commit 028cd86b794f4a ("video: da8xx-fb: fix the polarities of the
>    hsync/vsync pulse") fixes polarities of HSYNC/VSYNC pulse but
>    forgot to update known_lcd_panels[] which had sync values
>    according to old logic. This breaks LCD at least on DA850 EVM.
>    
>    This patch fixes this issue and I have tested this for panel
>    "Sharp_LK043T1DG01" using DA850 EVM board.
>    
>    Fixes: 028cd86b794f4a ("video: da8xx-fb: fix the polarities of the hsync/vsync pulse")
>    Signed-off-by: Sushaanth Srirangapathi <sushaanth.s@ti.com>
>    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2d7efc56371c93957871838253fefe2fb4446b77
>Author: Arnd Bergmann <arnd@arndb.de>
>Date:   Tue Mar 15 14:53:29 2016 -0700
>
>    paride: make 'verbose' parameter an 'int' again
>    
>    [ Upstream commit dec63a4dec2d6d01346fd5d96062e67c0636852b ]
>    
>    gcc-6.0 found an ancient bug in the paride driver, which had a
>    "module_param(verbose, bool, 0);" since before 2.6.12, but actually uses
>    it to accept '0', '1' or '2' as arguments:
>    
>      drivers/block/paride/pd.c: In function 'pd_init_dev_parms':
>      drivers/block/paride/pd.c:298:29: warning: comparison of constant '1' with boolean expression is always false [-Wbool-compare]
>       #define DBMSG(msg) ((verbose>1)?(msg):NULL)
>    
>    In 2012, Rusty did a cleanup patch that also changed the type of the
>    variable to 'bool', which introduced what is now a gcc warning.
>    
>    This changes the type back to 'int' and adapts the module_param() line
>    instead, so it should work as documented in case anyone ever cares about
>    running the ancient driver with debugging.
>    
>    Fixes: 90ab5ee94171 ("module_param: make bool parameters really bool (drivers & misc)")
>    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>    Rusty Russell <rusty@rustcorp.com.au>
>    Cc: Tim Waugh <tim@cyberelk.net>
>    Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
>    Cc: Jens Axboe <axboe@fb.com>
>    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1cc58547374cfa39193c7bc66119b50fcfbc9342
>Author: Arnd Bergmann <arnd@arndb.de>
>Date:   Tue Feb 16 15:53:11 2016 +0100
>
>    regulator: s5m8767: fix get_register() error handling
>    
>    [ Upstream commit e07ff9434167981c993a26d2edbbcb8e13801dbb ]
>    
>    The s5m8767_pmic_probe() function calls s5m8767_get_register() to
>    read data without checking the return code, which produces a compile-time
>    warning when that data is accessed:
>    
>    drivers/regulator/s5m8767.c: In function 's5m8767_pmic_probe':
>    drivers/regulator/s5m8767.c:924:7: error: 'enable_reg' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>    drivers/regulator/s5m8767.c:944:30: error: 'enable_val' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>    
>    This changes the s5m8767_get_register() function to return a -EINVAL
>    not just for an invalid register number but also for an invalid
>    regulator number, as both would result in returning uninitialized
>    data. The s5m8767_pmic_probe() function is then changed accordingly
>    to fail on a read error, as all the other callers of s5m8767_get_register()
>    already do.
>    
>    In practice this probably cannot happen, as we don't call
>    s5m8767_get_register() with invalid arguments, but the gcc
>    warning seems valid in principle, in terms writing safe
>    error checking.
>    
>    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>    Fixes: 9c4c60554acf ("regulator: s5m8767: Convert to use regulator_[enable|disable|is_enabled]_regmap")
>    Signed-off-by: Mark Brown <broonie@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 377e05c42b3078841377779f6f7f0f37b0ef31a2
>Author: Huibin Hong <huibin.hong@rock-chips.com>
>Date:   Wed Feb 24 18:00:04 2016 +0800
>
>    spi/rockchip: Make sure spi clk is on in rockchip_spi_set_cs
>    
>    [ Upstream commit b920cc3191d7612f26f36ee494e05b5ffd9044c0 ]
>    
>    Rockchip_spi_set_cs could be called by spi_setup, but
>    spi_setup may be called by device driver after runtime suspend.
>    Then the spi clock is closed, rockchip_spi_set_cs may access the
>    spi registers, which causes cpu block in some socs.
>    
>    Fixes: 64e36824b32 ("spi/rockchip: add driver for Rockchip RK3xxx")
>    Signed-off-by: Huibin Hong <huibin.hong@rock-chips.com>
>    Signed-off-by: Mark Brown <broonie@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 25c871c07f37b8cbaebc97403233185479af095d
>Author: Ignat Korchagin <ignat.korchagin@gmail.com>
>Date:   Thu Mar 17 18:00:29 2016 +0000
>
>    USB: usbip: fix potential out-of-bounds write
>    
>    [ Upstream commit b348d7dddb6c4fbfc810b7a0626e8ec9e29f7cbb ]
>    
>    Fix potential out-of-bounds write to urb->transfer_buffer
>    usbip handles network communication directly in the kernel. When receiving a
>    packet from its peer, usbip code parses headers according to protocol. As
>    part of this parsing urb->actual_length is filled. Since the input for
>    urb->actual_length comes from the network, it should be treated as untrusted.
>    Any entity controlling the network may put any value in the input and the
>    preallocated urb->transfer_buffer may not be large enough to hold the data.
>    Thus, the malicious entity is able to write arbitrary data to kernel memory.
>    
>    Signed-off-by: Ignat Korchagin <ignat.korchagin@gmail.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit cef12dbf18ab7617cacf7c271da43624afac5520
>Author: Tejun Heo <tj@kernel.org>
>Date:   Thu Jan 21 15:32:15 2016 -0500
>
>    cgroup: make sure a parent css isn't freed before its children
>    
>    [ Upstream commit 8bb5ef79bc0f4016ecf79e8dce6096a3c63603e4 ]
>    
>    There are three subsystem callbacks in css shutdown path -
>    css_offline(), css_released() and css_free().  Except for
>    css_released(), cgroup core didn't guarantee the order of invocation.
>    css_offline() or css_free() could be called on a parent css before its
>    children.  This behavior is unexpected and led to bugs in cpu and
>    memory controller.
>    
>    The previous patch updated ordering for css_offline() which fixes the
>    cpu controller issue.  While there currently isn't a known bug caused
>    by misordering of css_free() invocations, let's fix it too for
>    consistency.
>    
>    css_free() ordering can be trivially fixed by moving putting of the
>    parent css below css_free() invocation.
>    
>    Signed-off-by: Tejun Heo <tj@kernel.org>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 339861186370771cdf9df0ba6d1b2cb2440a1d61
>Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>Date:   Mon Feb 1 22:06:55 2016 +0000
>
>    efi: Expose non-blocking set_variable() wrapper to efivars
>    
>    [ Upstream commit 9c6672ac9c91f7eb1ec436be1442b8c26d098e55 ]
>    
>    Commit 6d80dba1c9fe ("efi: Provide a non-blocking SetVariable()
>    operation") implemented a non-blocking alternative for the UEFI
>    SetVariable() invocation performed by efivars, since it may
>    occur in atomic context. However, this version of the function
>    was never exposed via the efivars struct, so the non-blocking
>    versions was not actually callable. Fix that.
>    
>    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>    Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
>    Cc: Borislav Petkov <bp@alien8.de>
>    Cc: Brian Gerst <brgerst@gmail.com>
>    Cc: Denys Vlasenko <dvlasenk@redhat.com>
>    Cc: H. Peter Anvin <hpa@zytor.com>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Cc: linux-efi@vger.kernel.org
>    Fixes: 6d80dba1c9fe ("efi: Provide a non-blocking SetVariable() operation")
>    Link: http://lkml.kernel.org/r/1454364428-494-2-git-send-email-matt@codeblueprint.co.uk
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit fad61c46cc9c999169b95d14a67c60a0a7141d00
>Author: Lars-Peter Clausen <lars@metafoo.de>
>Date:   Wed Jan 27 14:26:18 2016 +0100
>
>    ASoC: ssm4567: Reset device before regcache_sync()
>    
>    [ Upstream commit 712a8038cc24dba668afe82f0413714ca87184e0 ]
>    
>    When the ssm4567 is powered up the driver calles regcache_sync() to restore
>    the register map content. regcache_sync() assumes that the device is in its
>    power-on reset state. Make sure that this is the case by explicitly
>    resetting the ssm4567 register map before calling regcache_sync() otherwise
>    we might end up with a incorrect register map which leads to undefined
>    behaviour.
>    
>    One such undefined behaviour was observed when returning from system
>    suspend while a playback stream is active, in that case the ssm4567 was
>    kept muted after resume.
>    
>    Fixes: 1ee44ce03011 ("ASoC: ssm4567: Add driver for Analog Devices SSM4567 amplifier")
>    Reported-by: Harsha Priya <harshapriya.n@intel.com>
>    Tested-by: Fang, Yang A <yang.a.fang@intel.com>
>    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
>    Signed-off-by: Mark Brown <broonie@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0cbc7967e970b92f2b60a5d935dc49eef08cfa2e
>Author: Arnd Bergmann <arnd@arndb.de>
>Date:   Mon Jan 25 18:07:33 2016 +0100
>
>    ASoC: s3c24xx: use const snd_soc_component_driver pointer
>    
>    [ Upstream commit ba4bc32eaa39ba7687f0958ae90eec94da613b46 ]
>    
>    An older patch to convert the API in the s3c i2s driver
>    ended up passing a const pointer into a function that takes
>    a non-const pointer, so we now get a warning:
>    
>    sound/soc/samsung/s3c2412-i2s.c: In function 's3c2412_iis_dev_probe':
>    sound/soc/samsung/s3c2412-i2s.c:172:9: error: passing argument 3 of 's3c_i2sv2_register_component' discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
>    
>    However, the s3c_i2sv2_register_component() function again
>    passes the pointer into another function taking a const, so
>    we just need to change its prototype.
>    
>    Fixes: eca3b01d0885 ("ASoC: switch over to use snd_soc_register_component() on s3c i2s")
>    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>    Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>    Signed-off-by: Mark Brown <broonie@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 44783088d3fea68985f644312b3e76cd6dde8d18
>Author: Javier Martinez Canillas <javier@osg.samsung.com>
>Date:   Sat Apr 16 21:14:52 2016 -0400
>
>    i2c: exynos5: Fix possible ABBA deadlock by keeping I2C clock prepared
>    
>    [ Upstream commit 10ff4c5239a137abfc896ec73ef3d15a0f86a16a ]
>    
>    The exynos5 I2C controller driver always prepares and enables a clock
>    before using it and then disables unprepares it when the clock is not
>    used anymore.
>    
>    But this can cause a possible ABBA deadlock in some scenarios since a
>    driver that uses regmap to access its I2C registers, will first grab
>    the regmap lock and then the I2C xfer function will grab the prepare
>    lock when preparing the I2C clock. But since the clock driver also
>    uses regmap for I2C accesses, preparing a clock will first grab the
>    prepare lock and then the regmap lock when using the regmap API.
>    
>    An example of this happens on the Exynos5422 Odroid XU4 board where a
>    s2mps11 PMIC is used and both the s2mps11 regulators and clk drivers
>    share the same I2C regmap.
>    
>    The possible deadlock is reported by the kernel lockdep:
>    
>      Possible unsafe locking scenario:
>    
>            CPU0                    CPU1
>            ----                    ----
>       lock(sec_core:428:(regmap)->lock);
>                                    lock(prepare_lock);
>                                    lock(sec_core:428:(regmap)->lock);
>       lock(prepare_lock);
>    
>      *** DEADLOCK ***
>    
>    Fix it by leaving the code prepared on probe and use {en,dis}able in
>    the I2C transfer function.
>    
>    This patch is similar to commit 34e81ad5f0b6 ("i2c: s3c2410: fix ABBA
>    deadlock by keeping clock prepared") that fixes the same bug in other
>    driver for an I2C controller found in Samsung SoCs.
>    
>    Reported-by: Anand Moon <linux.amoon@gmail.com>
>    Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>    Reviewed-by: Anand Moon <linux.amoon@gmail.com>
>    Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
>    Cc: stable@kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit be109716b05f8c1f2bd4c1389327c7848b894e20
>Author: Ville SyrjÃ¤lÃ¤ <ville.syrjala@linux.intel.com>
>Date:   Mon Jan 11 20:48:32 2016 +0200
>
>    drm/i915: Cleanup phys status page too
>    
>    [ Upstream commit 7d3fdfff23852fe458a0d0979a3555fe60f1e563 ]
>    
>    Restore the lost phys status page cleanup.
>    
>    Fixes the following splat with DMA_API_DEBUG=y:
>    
>    WARNING: CPU: 0 PID: 21615 at ../lib/dma-debug.c:974 dma_debug_device_change+0x190/0x1f0()
>    pci 0000:00:02.0: DMA-API: device driver has pending DMA allocations while released from device [count=1]
>                   One of leaked entries details: [device address=0x0000000023163000] [size=4096 bytes] [mapped with DMA_BIDIRECTIONAL] [mapped as coherent]
>    Modules linked in: i915(-) i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm sha256_generic hmac drbg ctr ccm sch_fq_codel binfmt_misc joydev mousedev arc4 ath5k iTCO_wdt mac80211 smsc_ircc2 ath snd_intel8x0m snd_intel8x0 snd_ac97_codec ac97_bus psmouse snd_pcm input_leds i2c_i801 pcspkr snd_timer cfg80211 snd soundcore i2c_core ehci_pci firewire_ohci ehci_hcd firewire_core lpc_ich 8139too rfkill crc_itu_t mfd_core mii usbcore rng_core intel_agp intel_gtt usb_common agpgart irda crc_ccitt fujitsu_laptop led_class parport_pc video parport evdev backlight
>    CPU: 0 PID: 21615 Comm: rmmod Tainted: G     U          4.4.0-rc4-mgm-ovl+ #4
>    Hardware name: FUJITSU SIEMENS LIFEBOOK S6120/FJNB16C, BIOS Version 1.26  05/10/2004
>     e31a3de0 e31a3de0 e31a3d9c c128d4bd e31a3dd0 c1045a0c c15e00c4 e31a3dfc
>     0000546f c15dfad2 000003ce c12b3740 000003ce c12b3740 00000000 00000001
>     f61fb8a0 e31a3de8 c1045a83 00000009 e31a3de0 c15e00c4 e31a3dfc e31a3e4c
>    Call Trace:
>     [<c128d4bd>] dump_stack+0x16/0x19
>     [<c1045a0c>] warn_slowpath_common+0x8c/0xd0
>     [<c12b3740>] ? dma_debug_device_change+0x190/0x1f0
>     [<c12b3740>] ? dma_debug_device_change+0x190/0x1f0
>     [<c1045a83>] warn_slowpath_fmt+0x33/0x40
>     [<c12b3740>] dma_debug_device_change+0x190/0x1f0
>     [<c1065499>] notifier_call_chain+0x59/0x70
>     [<c10655af>] __blocking_notifier_call_chain+0x3f/0x80
>     [<c106560f>] blocking_notifier_call_chain+0x1f/0x30
>     [<c134cfb3>] __device_release_driver+0xc3/0xf0
>     [<c134d0d7>] driver_detach+0x97/0xa0
>     [<c134c440>] bus_remove_driver+0x40/0x90
>     [<c134db18>] driver_unregister+0x28/0x60
>     [<c1079e8c>] ? trace_hardirqs_on_caller+0x12c/0x1d0
>     [<c12c0618>] pci_unregister_driver+0x18/0x80
>     [<f83e96e7>] drm_pci_exit+0x87/0xb0 [drm]
>     [<f8b3be2d>] i915_exit+0x1b/0x1ee [i915]
>     [<c10b999c>] SyS_delete_module+0x14c/0x210
>     [<c1079e8c>] ? trace_hardirqs_on_caller+0x12c/0x1d0
>     [<c115a9bd>] ? ____fput+0xd/0x10
>     [<c1002014>] do_fast_syscall_32+0xa4/0x450
>     [<c149f6fa>] sysenter_past_esp+0x3b/0x5d
>    ---[ end trace c2ecbc77760f10a0 ]---
>    Mapped at:
>     [<c12b3183>] debug_dma_alloc_coherent+0x33/0x90
>     [<f83e989c>] drm_pci_alloc+0x18c/0x1e0 [drm]
>     [<f8acd59f>] intel_init_ring_buffer+0x2af/0x490 [i915]
>     [<f8acd8b0>] intel_init_render_ring_buffer+0x130/0x750 [i915]
>     [<f8aaea4e>] i915_gem_init_rings+0x1e/0x110 [i915]
>    
>    v2: s/BUG_ON/WARN_ON/ since dim doens't like the former anymore
>    
>    Cc: Chris Wilson <chris@chris-wilson.co.uk>
>    Fixes: 5c6c600 ("drm/i915: Remove DRI1 ring accessors and API")
>    Signed-off-by: Ville SyrjÃ¤lÃ¤ <ville.syrjala@linux.intel.com>
>    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
>    Link: http://patchwork.freedesktop.org/patch/msgid/1452538112-5331-1-git-send-email-ville.syrjala@linux.intel.com
>    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4e57736de7ebcaf667ef07a8b7d34060ac3d153b
>Author: Keerthy <j-keerthy@ti.com>
>Date:   Thu Apr 14 10:29:16 2016 +0530
>
>    pinctrl: single: Fix pcs_parse_bits_in_pinctrl_entry to use __ffs than ffs
>    
>    [ Upstream commit 56b367c0cd67d4c3006738e7dc9dda9273fd2bfe ]
>    
>    pcs_parse_bits_in_pinctrl_entry uses ffs which gives bit indices
>    ranging from 1 to MAX. This leads to a corner case where we try to request
>    the pin number = MAX and fails.
>    
>    bit_pos value is being calculted using ffs. pin_num_from_lsb uses
>    bit_pos value. pins array is populated with:
>    
>    pin + pin_num_from_lsb.
>    
>    The above is 1 more than usual bit indices as bit_pos uses ffs to compute
>    first set bit. Hence the last of the pins array is populated with the MAX
>    value and not MAX - 1 which causes error when we call pin_request.
>    
>    mask_pos is rightly calculated as ((pcs->fmask) << (bit_pos - 1))
>    Consequently val_pos and submask are correct.
>    
>    Hence use __ffs which gives (ffs(x) - 1) as the first bit set.
>    
>    fixes: 4e7e8017a8 ("pinctrl: pinctrl-single: enhance to configure multiple pins of different modules")
>    Signed-off-by: Keerthy <j-keerthy@ti.com>
>    Acked-by: Tony Lindgren <tony@atomide.com>
>    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 372574134cc15a03608d87a3577885b049e40db3
>Author: Arnd Bergmann <arnd@arndb.de>
>Date:   Tue Feb 16 16:03:23 2016 +0100
>
>    xen kconfig: don't "select INPUT_XEN_KBDDEV_FRONTEND"
>    
>    [ Upstream commit 13aa38e291bdd4e4018f40dd2f75e464814dcbf3 ]
>    
>    The Xen framebuffer driver selects the xen keyboard driver, so the latter
>    will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT
>    is a loadable module, this configuration cannot work. On mainline kernels,
>    the symbol will be enabled but not used, while in combination with
>    a patch I have to detect such useless configurations, we get the
>    expected link failure:
>    
>    drivers/input/built-in.o: In function `xenkbd_remove':
>    xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device'
>    xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device'
>    
>    This removes the extra "select", as it just causes more trouble than
>    it helps. In theory, some defconfig file might break if it has
>    XEN_FBDEV_FRONTEND in it but not INPUT_XEN_KBDDEV_FRONTEND. The Kconfig
>    fragment we ship in the kernel (kernel/configs/xen.config) however
>    already enables both, and anyone using an old .config file would
>    keep having both enabled.
>    
>    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>    Suggested-by: David Vrabel <david.vrabel@citrix.com>
>    Fixes: 36c1132e34bd ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND")
>    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e9f20ca83ec68dddf1366fe99456a12072dc8bac
>Author: Stephen Boyd <sboyd@codeaurora.org>
>Date:   Sun Apr 17 05:21:42 2016 -0700
>
>    Input: pmic8xxx-pwrkey - fix algorithm for converting trigger delay
>    
>    [ Upstream commit eda5ecc0a6b865561997e177c393f0b0136fe3b7 ]
>    
>    The trigger delay algorithm that converts from microseconds to
>    the register value looks incorrect. According to most of the PMIC
>    documentation, the equation is
>    
>    	delay (Seconds) = (1 / 1024) * 2 ^ (x + 4)
>    
>    except for one case where the documentation looks to have a
>    formatting issue and the equation looks like
>    
>    	delay (Seconds) = (1 / 1024) * 2 x + 4
>    
>    Most likely this driver was written with the improper
>    documentation to begin with. According to the downstream sources
>    the valid delays are from 2 seconds to 1/64 second, and the
>    latter equation just doesn't make sense for that. Let's fix the
>    algorithm and the range check to match the documentation and the
>    downstream sources.
>    
>    Reported-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>    Fixes: 92d57a73e410 ("input: Add support for Qualcomm PMIC8XXX power key")
>    Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>    Tested-by: John Stultz <john.stultz@linaro.org>
>    Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f49eb503f0f9ab66874a81992b14249a1c59b6ad
>Author: Anton Blanchard <anton@samba.org>
>Date:   Fri Apr 15 12:08:19 2016 +1000
>
>    powerpc: Update TM user feature bits in scan_features()
>    
>    [ Upstream commit 4705e02498d6d5a7ab98dfee9595cd5e91db2017 ]
>    
>    We need to update the user TM feature bits (PPC_FEATURE2_HTM and
>    PPC_FEATURE2_HTM) to mirror what we do with the kernel TM feature
>    bit.
>    
>    At the moment, if firmware reports TM is not available we turn off
>    the kernel TM feature bit but leave the userspace ones on. Userspace
>    thinks it can execute TM instructions and it dies trying.
>    
>    This (together with a QEMU patch) fixes PR KVM, which doesn't currently
>    support TM.
>    
>    Signed-off-by: Anton Blanchard <anton@samba.org>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0ee1b6dbc57dc78541df83157e1251b983c51485
>Author: Davidlohr Bueso <dave@stgolabs.net>
>Date:   Wed Apr 20 20:09:24 2016 -0700
>
>    futex: Acknowledge a new waiter in counter before plist
>    
>    [ Upstream commit fe1bce9e2107ba3a8faffe572483b6974201a0e6 ]
>    
>    Otherwise an incoming waker on the dest hash bucket can miss
>    the waiter adding itself to the plist during the lockless
>    check optimization (small window but still the correct way
>    of doing this); similarly to the decrement counterpart.
>    
>    Suggested-by: Peter Zijlstra <peterz@infradead.org>
>    Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
>    Cc: Davidlohr Bueso <dave@stgolabs.net>
>    Cc: bigeasy@linutronix.de
>    Cc: dvhart@infradead.org
>    Cc: stable@kernel.org
>    Link: http://lkml.kernel.org/r/1461208164-29150-1-git-send-email-dave@stgolabs.net
>    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 17e8cd1e540985cd11cc6f007867fa1679b8f866
>Author: Michal Kazior <michal.kazior@tieto.com>
>Date:   Thu Jan 21 14:23:07 2016 +0100
>
>    mac80211: fix txq queue related crashes
>    
>    [ Upstream commit 2a58d42c1e018ad514d4e23fd33fb2ded95d3ee6 ]
>    
>    The driver can access the queue simultanously
>    while mac80211 tears down the interface. Without
>    spinlock protection this could lead to corrupting
>    sk_buff_head and subsequently to an invalid
>    pointer dereference.
>    
>    Fixes: ba8c3d6f16a1 ("mac80211: add an intermediate software queue implementation")
>    Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
>    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 193517ef5a16dedb1ba9bca6a9e490780cdf3f3a
>Author: Michal Kazior <michal.kazior@tieto.com>
>Date:   Mon Jan 25 14:43:24 2016 +0100
>
>    mac80211: fix unnecessary frame drops in mesh fwding
>    
>    [ Upstream commit cf44012810ccdd8fd947518e965cb04b7b8498be ]
>    
>    The ieee80211_queue_stopped() expects hw queue
>    number but it was given raw WMM AC number instead.
>    
>    This could cause frame drops and problems with
>    traffic in some cases - most notably if driver
>    doesn't map AC numbers to queue numbers 1:1 and
>    uses ieee80211_stop_queues() and
>    ieee80211_wake_queue() only without ever calling
>    ieee80211_wake_queues().
>    
>    On ath10k it was possible to hit this problem in
>    the following case:
>    
>      1. wlan0 uses queue 0
>         (ath10k maps queues per vif)
>      2. offchannel uses queue 15
>      3. queues 1-14 are unused
>      4. ieee80211_stop_queues()
>      5. ieee80211_wake_queue(q=0)
>      6. ieee80211_wake_queue(q=15)
>         (other queues are not woken up because both
>          driver and mac80211 know other queues are
>          unused)
>      7. ieee80211_rx_h_mesh_fwding()
>      8. ieee80211_select_queue_80211() returns 2
>      9. ieee80211_queue_stopped(q=2) returns true
>     10. frame is dropped (oops!)
>    
>    Fixes: d3c1597b8d1b ("mac80211: fix forwarded mesh frame queue mapping")
>    Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
>    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit bd6b2f89b2357c2daabd596d8c1c78940030042c
>Author: Sara Sharon <sara.sharon@intel.com>
>Date:   Mon Jan 25 15:46:35 2016 +0200
>
>    mac80211: fix ibss scan parameters
>    
>    [ Upstream commit d321cd014e51baab475efbdec468255b9e0ec822 ]
>    
>    When joining IBSS a full scan should be initiated in order to search
>    for existing cell, unless the fixed_channel parameter was set.
>    A default channel to create the IBSS on if no cell was found is
>    provided as well.
>    However - a scan is initiated only on the default channel provided
>    regardless of whether ifibss->fixed_channel is set or not, with the
>    obvious result of the cell not joining existing IBSS cell that is
>    on another channel.
>    
>    Fixes: 76bed0f43b27 ("mac80211: IBSS fix scan request")
>    Signed-off-by: Sara Sharon <sara.sharon@intel.com>
>    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
>    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6c59578f592a6873a71bc1397ccf60615d2abec0
>Author: Arnd Bergmann <arnd@arndb.de>
>Date:   Tue Jan 26 23:05:31 2016 +0100
>
>    mac80211: avoid excessive stack usage in sta_info
>    
>    [ Upstream commit 0ef049dc1167fe834d0ad5d63f89eddc5c70f6e4 ]
>    
>    When CONFIG_OPTIMIZE_INLINING is set, the sta_info_insert_finish
>    function consumes more stack than normally, exceeding the
>    1024 byte limit on ARM:
>    
>    net/mac80211/sta_info.c: In function 'sta_info_insert_finish':
>    net/mac80211/sta_info.c:561:1: error: the frame size of 1080 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
>    
>    It turns out that there are two functions that put a 'struct station_info'
>    on the stack: __sta_info_destroy_part2 and sta_info_insert_finish, and
>    this structure alone requires up to 792 bytes.
>    
>    Hoping that both are called rarely enough, this replaces the
>    on-stack structure with a dynamic allocation, which unfortunately
>    requires some suboptimal error handling for out-of-memory.
>    
>    The __sta_info_destroy_part2 function is actually affected by the
>    stack usage twice because it calls cfg80211_del_sta_sinfo(), which
>    has another instance of struct station_info on its stack.
>    
>    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>    Fixes: 98b6218388e3 ("mac80211/cfg80211: add station events")
>    Fixes: 6f7a8d26e266 ("mac80211: send statistics with delete station event")
>    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f46752f2993159836cb0591f5b6083f9ff2d7039
>Author: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
>Date:   Wed Sep 9 11:38:56 2015 -0300
>
>    [media] v4l: vsp1: Set the SRU CTRL0 register when starting the stream
>    
>    [ Upstream commit f6acfcdc5b8cdc9ddd53a459361820b9efe958c4 ]
>    
>    Commit 58f896d859ce ("[media] v4l: vsp1: sru: Make the intensity
>    controllable during streaming") refactored the stream start code and
>    removed the SRU CTRL0 register write by mistake. Add it back.
>    
>    Fixes: 58f896d859ce ("[media] v4l: vsp1: sru: Make the intensity controllable during streaming")
>    
>    Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
>    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 80a3bf1c098ce3e0b711695743037b859db536c0
>Author: Philipp Zabel <p.zabel@pengutronix.de>
>Date:   Fri Feb 26 08:21:35 2016 -0300
>
>    [media] coda: fix error path in case of missing pdata on non-DT platform
>    
>    [ Upstream commit bc717d5e92c8c079280eb4acbe335c6f25041aa2 ]
>    
>    If we bail out this early, v4l2_device_register() has not been called
>    yet, so no need to call v4l2_device_unregister().
>    
>    Fixes: b7bd660a51f0 ("[media] coda: Call v4l2_device_unregister() from a single location")
>    
>    Reported-by: Michael Olbrich <m.olbrich@pengutronix.de>
>    Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
>    Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
>    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 921aa6dd8753b3c81e3daaeb1ba2acd70ed36a2d
>Author: Linus Walleij <linus.walleij@linaro.org>
>Date:   Thu Mar 24 13:15:45 2016 +0100
>
>    pinctrl: nomadik: fix pull debug print inversion
>    
>    [ Upstream commit 6ee334559324a55725e22463de633b99ad99fcad ]
>    
>    Pull up was reported as pull down and vice versa. Fix this.
>    
>    Fixes: 8f1774a2a971 "pinctrl: nomadik: improve GPIO debug prints"
>    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 80618333cec2c6b69244c7a478580e5ffccb6d24
>Author: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
>Date:   Fri Apr 1 17:17:50 2016 -0300
>
>    ip6_tunnel: set rtnl_link_ops before calling register_netdevice
>    
>    [ Upstream commit b6ee376cb0b7fb4e7e07d6cd248bd40436fb9ba6 ]
>    
>    When creating an ip6tnl tunnel with ip tunnel, rtnl_link_ops is not set
>    before ip6_tnl_create2 is called. When register_netdevice is called, there
>    is no linkinfo attribute in the NEWLINK message because of that.
>    
>    Setting rtnl_link_ops before calling register_netdevice fixes that.
>    
>    Fixes: 0b112457229d ("ip6tnl: add support of link creation via rtnl")
>    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
>    Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1d8ad31a7ef1e1dcc4968518d5cefcd492bc2c58
>Author: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
>Date:   Sun Apr 3 22:09:24 2016 +0800
>
>    ipv6: l2tp: fix a potential issue in l2tp_ip6_recv
>    
>    [ Upstream commit be447f305494e019dfc37ea4cdf3b0e4200b4eba ]
>    
>    pskb_may_pull() can change skb->data, so we have to load ptr/optr at the
>    right place.
>    
>    Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a9c5107769719e76a895fd59408442e5629fc40f
>Author: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
>Date:   Sun Apr 3 22:09:23 2016 +0800
>
>    ipv4: l2tp: fix a potential issue in l2tp_ip_recv
>    
>    [ Upstream commit 5745b8232e942abd5e16e85fa9b27cc21324acf0 ]
>    
>    pskb_may_pull() can change skb->data, so we have to load ptr/optr at the
>    right place.
>    
>    Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5e6a091fd631b29332d3f61e92857ebd5d85a4be
>Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>Date:   Thu Mar 31 18:10:31 2016 +0200
>
>    rtnl: fix msg size calculation in if_nlmsg_size()
>    
>    [ Upstream commit c57c7a95da842807b475b823ed2e5435c42cb3b0 ]
>    
>    Size of the attribute IFLA_PHYS_PORT_NAME was missing.
>    
>    Fixes: db24a9044ee1 ("net: add support for phys_port_name")
>    CC: David Ahern <dsahern@gmail.com>
>    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>    Acked-by: David Ahern <dsahern@gmail.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b95228fd0efb56afd9aaec13a76f530f85fcb502
>Author: Eric Dumazet <edumazet@google.com>
>Date:   Tue Mar 29 08:43:41 2016 -0700
>
>    ipv6: udp: fix UDP_MIB_IGNOREDMULTI updates
>    
>    [ Upstream commit 2d4212261fdf13e29728ddb5ea9d60c342cc92b5 ]
>    
>    IPv6 counters updates use a different macro than IPv4.
>    
>    Fixes: 36cbb2452cbaf ("udp: Increment UDP_MIB_IGNOREDMULTI for arriving unmatched multicasts")
>    Signed-off-by: Eric Dumazet <edumazet@google.com>
>    Cc: Rick Jones <rick.jones2@hp.com>
>    Cc: Willem de Bruijn <willemb@google.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 95e4695bd33e9f8ddabaf4fa64857e9bed1bda80
>Author: BjÃ¸rn Mork <bjorn@mork.no>
>Date:   Mon Mar 28 22:38:16 2016 +0200
>
>    qmi_wwan: add "D-Link DWM-221 B1" device id
>    
>    [ Upstream commit e84810c7b85a2d7897797b3ad3e879168a8e032a ]
>    
>    Thomas reports:
>    "Windows:
>    
>    00 diagnostics
>    01 modem
>    02 at-port
>    03 nmea
>    04 nic
>    
>    Linux:
>    
>    T:  Bus=02 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=2001 ProdID=7e19 Rev=02.32
>    S:  Manufacturer=Mobile Connect
>    S:  Product=Mobile Connect
>    S:  SerialNumber=0123456789ABCDEF
>    C:  #Ifs= 6 Cfg#= 1 Atr=a0 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=ff Prot=ff Driver=qmi_wwan
>    I:  If#= 5 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: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a23597733aed572b2de06562f5d3913b76bddfdc
>Author: subashab@codeaurora.org <subashab@codeaurora.org>
>Date:   Wed Mar 23 22:39:50 2016 -0600
>
>    xfrm: Fix crash observed during device unregistration and decryption
>    
>    [ Upstream commit 071d36bf21bcc837be00cea55bcef8d129e7f609 ]
>    
>    A crash is observed when a decrypted packet is processed in receive
>    path. get_rps_cpus() tries to dereference the skb->dev fields but it
>    appears that the device is freed from the poison pattern.
>    
>    [<ffffffc000af58ec>] get_rps_cpu+0x94/0x2f0
>    [<ffffffc000af5f94>] netif_rx_internal+0x140/0x1cc
>    [<ffffffc000af6094>] netif_rx+0x74/0x94
>    [<ffffffc000bc0b6c>] xfrm_input+0x754/0x7d0
>    [<ffffffc000bc0bf8>] xfrm_input_resume+0x10/0x1c
>    [<ffffffc000ba6eb8>] esp_input_done+0x20/0x30
>    [<ffffffc0000b64c8>] process_one_work+0x244/0x3fc
>    [<ffffffc0000b7324>] worker_thread+0x2f8/0x418
>    [<ffffffc0000bb40c>] kthread+0xe0/0xec
>    
>    -013|get_rps_cpu(
>         |    dev = 0xFFFFFFC08B688000,
>         |    skb = 0xFFFFFFC0C76AAC00 -> (
>         |      dev = 0xFFFFFFC08B688000 -> (
>         |        name =
>    "......................................................
>         |        name_hlist = (next = 0xAAAAAAAAAAAAAAAA, pprev =
>    0xAAAAAAAAAAA
>    
>    Following are the sequence of events observed -
>    
>    - Encrypted packet in receive path from netdevice is queued
>    - Encrypted packet queued for decryption (asynchronous)
>    - Netdevice brought down and freed
>    - Packet is decrypted and returned through callback in esp_input_done
>    - Packet is queued again for process in network stack using netif_rx
>    
>    Since the device appears to have been freed, the dereference of
>    skb->dev in get_rps_cpus() leads to an unhandled page fault
>    exception.
>    
>    Fix this by holding on to device reference when queueing packets
>    asynchronously and releasing the reference on call back return.
>    
>    v2: Make the change generic to xfrm as mentioned by Steffen and
>    update the title to xfrm
>    
>    Suggested-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Jerome Stanislaus <jeromes@codeaurora.org>
>    Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit fc74ace8df9bffbab3b886686db02f0809bdc5e9
>Author: Guillaume Nault <g.nault@alphalink.fr>
>Date:   Wed Mar 23 16:38:55 2016 +0100
>
>    ppp: take reference on channels netns
>    
>    [ Upstream commit 1f461dcdd296eecedaffffc6bae2bfa90bd7eb89 ]
>    
>    Let channels hold a reference on their network namespace.
>    Some channel types, like ppp_async and ppp_synctty, can have their
>    userspace controller running in a different namespace. Therefore they
>    can't rely on them to preclude their netns from being removed from
>    under them.
>    
>    ==================================================================
>    BUG: KASAN: use-after-free in ppp_unregister_channel+0x372/0x3a0 at
>    addr ffff880064e217e0
>    Read of size 8 by task syz-executor/11581
>    =============================================================================
>    BUG net_namespace (Not tainted): kasan: bad access detected
>    -----------------------------------------------------------------------------
>    
>    Disabling lock debugging due to kernel taint
>    INFO: Allocated in copy_net_ns+0x6b/0x1a0 age=92569 cpu=3 pid=6906
>    [<      none      >] ___slab_alloc+0x4c7/0x500 kernel/mm/slub.c:2440
>    [<      none      >] __slab_alloc+0x4c/0x90 kernel/mm/slub.c:2469
>    [<     inline     >] slab_alloc_node kernel/mm/slub.c:2532
>    [<     inline     >] slab_alloc kernel/mm/slub.c:2574
>    [<      none      >] kmem_cache_alloc+0x23a/0x2b0 kernel/mm/slub.c:2579
>    [<     inline     >] kmem_cache_zalloc kernel/include/linux/slab.h:597
>    [<     inline     >] net_alloc kernel/net/core/net_namespace.c:325
>    [<      none      >] copy_net_ns+0x6b/0x1a0 kernel/net/core/net_namespace.c:360
>    [<      none      >] create_new_namespaces+0x2f6/0x610 kernel/kernel/nsproxy.c:95
>    [<      none      >] copy_namespaces+0x297/0x320 kernel/kernel/nsproxy.c:150
>    [<      none      >] copy_process.part.35+0x1bf4/0x5760 kernel/kernel/fork.c:1451
>    [<     inline     >] copy_process kernel/kernel/fork.c:1274
>    [<      none      >] _do_fork+0x1bc/0xcb0 kernel/kernel/fork.c:1723
>    [<     inline     >] SYSC_clone kernel/kernel/fork.c:1832
>    [<      none      >] SyS_clone+0x37/0x50 kernel/kernel/fork.c:1826
>    [<      none      >] entry_SYSCALL_64_fastpath+0x16/0x7a kernel/arch/x86/entry/entry_64.S:185
>    
>    INFO: Freed in net_drop_ns+0x67/0x80 age=575 cpu=2 pid=2631
>    [<      none      >] __slab_free+0x1fc/0x320 kernel/mm/slub.c:2650
>    [<     inline     >] slab_free kernel/mm/slub.c:2805
>    [<      none      >] kmem_cache_free+0x2a0/0x330 kernel/mm/slub.c:2814
>    [<     inline     >] net_free kernel/net/core/net_namespace.c:341
>    [<      none      >] net_drop_ns+0x67/0x80 kernel/net/core/net_namespace.c:348
>    [<      none      >] cleanup_net+0x4e5/0x600 kernel/net/core/net_namespace.c:448
>    [<      none      >] process_one_work+0x794/0x1440 kernel/kernel/workqueue.c:2036
>    [<      none      >] worker_thread+0xdb/0xfc0 kernel/kernel/workqueue.c:2170
>    [<      none      >] kthread+0x23f/0x2d0 kernel/drivers/block/aoe/aoecmd.c:1303
>    [<      none      >] ret_from_fork+0x3f/0x70 kernel/arch/x86/entry/entry_64.S:468
>    INFO: Slab 0xffffea0001938800 objects=3 used=0 fp=0xffff880064e20000
>    flags=0x5fffc0000004080
>    INFO: Object 0xffff880064e20000 @offset=0 fp=0xffff880064e24200
>    
>    CPU: 1 PID: 11581 Comm: syz-executor Tainted: G    B           4.4.0+
>    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
>    rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
>     00000000ffffffff ffff8800662c7790 ffffffff8292049d ffff88003e36a300
>     ffff880064e20000 ffff880064e20000 ffff8800662c77c0 ffffffff816f2054
>     ffff88003e36a300 ffffea0001938800 ffff880064e20000 0000000000000000
>    Call Trace:
>     [<     inline     >] __dump_stack kernel/lib/dump_stack.c:15
>     [<ffffffff8292049d>] dump_stack+0x6f/0xa2 kernel/lib/dump_stack.c:50
>     [<ffffffff816f2054>] print_trailer+0xf4/0x150 kernel/mm/slub.c:654
>     [<ffffffff816f875f>] object_err+0x2f/0x40 kernel/mm/slub.c:661
>     [<     inline     >] print_address_description kernel/mm/kasan/report.c:138
>     [<ffffffff816fb0c5>] kasan_report_error+0x215/0x530 kernel/mm/kasan/report.c:236
>     [<     inline     >] kasan_report kernel/mm/kasan/report.c:259
>     [<ffffffff816fb4de>] __asan_report_load8_noabort+0x3e/0x40 kernel/mm/kasan/report.c:280
>     [<     inline     >] ? ppp_pernet kernel/include/linux/compiler.h:218
>     [<ffffffff83ad71b2>] ? ppp_unregister_channel+0x372/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392
>     [<     inline     >] ppp_pernet kernel/include/linux/compiler.h:218
>     [<ffffffff83ad71b2>] ppp_unregister_channel+0x372/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392
>     [<     inline     >] ? ppp_pernet kernel/drivers/net/ppp/ppp_generic.c:293
>     [<ffffffff83ad6f26>] ? ppp_unregister_channel+0xe6/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392
>     [<ffffffff83ae18f3>] ppp_asynctty_close+0xa3/0x130 kernel/drivers/net/ppp/ppp_async.c:241
>     [<ffffffff83ae1850>] ? async_lcp_peek+0x5b0/0x5b0 kernel/drivers/net/ppp/ppp_async.c:1000
>     [<ffffffff82c33239>] tty_ldisc_close.isra.1+0x99/0xe0 kernel/drivers/tty/tty_ldisc.c:478
>     [<ffffffff82c332c0>] tty_ldisc_kill+0x40/0x170 kernel/drivers/tty/tty_ldisc.c:744
>     [<ffffffff82c34943>] tty_ldisc_release+0x1b3/0x260 kernel/drivers/tty/tty_ldisc.c:772
>     [<ffffffff82c1ef21>] tty_release+0xac1/0x13e0 kernel/drivers/tty/tty_io.c:1901
>     [<ffffffff82c1e460>] ? release_tty+0x320/0x320 kernel/drivers/tty/tty_io.c:1688
>     [<ffffffff8174de36>] __fput+0x236/0x780 kernel/fs/file_table.c:208
>     [<ffffffff8174e405>] ____fput+0x15/0x20 kernel/fs/file_table.c:244
>     [<ffffffff813595ab>] task_work_run+0x16b/0x200 kernel/kernel/task_work.c:115
>     [<     inline     >] exit_task_work kernel/include/linux/task_work.h:21
>     [<ffffffff81307105>] do_exit+0x8b5/0x2c60 kernel/kernel/exit.c:750
>     [<ffffffff813fdd20>] ? debug_check_no_locks_freed+0x290/0x290 kernel/kernel/locking/lockdep.c:4123
>     [<ffffffff81306850>] ? mm_update_next_owner+0x6f0/0x6f0 kernel/kernel/exit.c:357
>     [<ffffffff813215e6>] ? __dequeue_signal+0x136/0x470 kernel/kernel/signal.c:550
>     [<ffffffff8132067b>] ? recalc_sigpending_tsk+0x13b/0x180 kernel/kernel/signal.c:145
>     [<ffffffff81309628>] do_group_exit+0x108/0x330 kernel/kernel/exit.c:880
>     [<ffffffff8132b9d4>] get_signal+0x5e4/0x14f0 kernel/kernel/signal.c:2307
>     [<     inline     >] ? kretprobe_table_lock kernel/kernel/kprobes.c:1113
>     [<ffffffff8151d355>] ? kprobe_flush_task+0xb5/0x450 kernel/kernel/kprobes.c:1158
>     [<ffffffff8115f7d3>] do_signal+0x83/0x1c90 kernel/arch/x86/kernel/signal.c:712
>     [<ffffffff8151d2a0>] ? recycle_rp_inst+0x310/0x310 kernel/include/linux/list.h:655
>     [<ffffffff8115f750>] ? setup_sigcontext+0x780/0x780 kernel/arch/x86/kernel/signal.c:165
>     [<ffffffff81380864>] ? finish_task_switch+0x424/0x5f0 kernel/kernel/sched/core.c:2692
>     [<     inline     >] ? finish_lock_switch kernel/kernel/sched/sched.h:1099
>     [<ffffffff81380560>] ? finish_task_switch+0x120/0x5f0 kernel/kernel/sched/core.c:2678
>     [<     inline     >] ? context_switch kernel/kernel/sched/core.c:2807
>     [<ffffffff85d794e9>] ? __schedule+0x919/0x1bd0 kernel/kernel/sched/core.c:3283
>     [<ffffffff81003901>] exit_to_usermode_loop+0xf1/0x1a0 kernel/arch/x86/entry/common.c:247
>     [<     inline     >] prepare_exit_to_usermode kernel/arch/x86/entry/common.c:282
>     [<ffffffff810062ef>] syscall_return_slowpath+0x19f/0x210 kernel/arch/x86/entry/common.c:344
>     [<ffffffff85d88022>] int_ret_from_sys_call+0x25/0x9f kernel/arch/x86/entry/entry_64.S:281
>    Memory state around the buggy address:
>     ffff880064e21680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>     ffff880064e21700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>    >ffff880064e21780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>                                                           ^
>     ffff880064e21800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>     ffff880064e21880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>    ==================================================================
>    
>    Fixes: 273ec51dd7ce ("net: ppp_generic - introduce net-namespace functionality v2")
>    Reported-by: Baozeng Ding <sploving1@gmail.com>
>    Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
>    Reviewed-by: Cyrill Gorcunov <gorcunov@openvz.org>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 263a20bc8ce3c3cb2ad3078457dc7abd29bc9165
>Author: Paolo Abeni <pabeni@redhat.com>
>Date:   Tue Mar 22 09:19:38 2016 +0100
>
>    ipv4: fix broadcast packets reception
>    
>    [ Upstream commit ad0ea1989cc4d5905941d0a9e62c63ad6d859cef ]
>    
>    Currently, ingress ipv4 broadcast datagrams are dropped since,
>    in udp_v4_early_demux(), ip_check_mc_rcu() is invoked even on
>    bcast packets.
>    
>    This patch addresses the issue, invoking ip_check_mc_rcu()
>    only for mcast packets.
>    
>    Fixes: 6e5403093261 ("ipv4/udp: Verify multicast group is ours in upd_v4_early_demux()")
>    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
>    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6acfc65a07790d15de590a2441ab55f51d36733a
>Author: Eric Dumazet <edumazet@google.com>
>Date:   Thu Mar 17 17:23:36 2016 -0700
>
>    bonding: fix bond_get_stats()
>    
>    [ Upstream commit fe30937b65354c7fec244caebbdaae68e28ca797 ]
>    
>    bond_get_stats() can be called from rtnetlink (with RTNL held)
>    or from /proc/net/dev seq handler (with RCU held)
>    
>    The logic added in commit 5f0c5f73e5ef ("bonding: make global bonding
>    stats more reliable") kind of assumed only one cpu could run there.
>    
>    If multiple threads are reading /proc/net/dev, stats can be really
>    messed up after a while.
>    
>    A second problem is that some fields are 32bit, so we need to properly
>    handle the wrap around problem.
>    
>    Given that RTNL is not always held, we need to use
>    bond_for_each_slave_rcu().
>    
>    Fixes: 5f0c5f73e5ef ("bonding: make global bonding stats more reliable")
>    Signed-off-by: Eric Dumazet <edumazet@google.com>
>    Cc: Andy Gospodarek <gospo@cumulusnetworks.com>
>    Cc: Jay Vosburgh <j.vosburgh@gmail.com>
>    Cc: Veaceslav Falico <vfalico@gmail.com>
>    Reviewed-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1fdc6943a177598ea960188f8972808bfa20dd84
>Author: Eric Dumazet <edumazet@google.com>
>Date:   Thu Mar 17 11:57:06 2016 -0700
>
>    net: bcmgenet: fix dma api length mismatch
>    
>    [ Upstream commit eee577232203842b4dcadb7ab477a298479633ed ]
>    
>    When un-mapping skb->data in __bcmgenet_tx_reclaim(),
>    we must use the length that was used in original dma_map_single(),
>    instead of skb->len that might be bigger (includes the frags)
>    
>    We simply can store skb_len into tx_cb_ptr->dma_len and use it
>    at unmap time.
>    
>    Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file")
>    Signed-off-by: Eric Dumazet <edumazet@google.com>
>    Acked-by: Florian Fainelli <f.fainelli@gmail.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit bb9863ec605470a48c67b91a37c25d04136acab6
>Author: Manish Chopra <manish.chopra@qlogic.com>
>Date:   Tue Mar 15 07:13:45 2016 -0400
>
>    qlge: Fix receive packets drop.
>    
>    [ Upstream commit 2c9a266afefe137bff06bbe0fc48b4d3b3cb348c ]
>    
>    When running small packets [length < 256 bytes] traffic, packets were
>    being dropped due to invalid data in those packets which were
>    delivered by the driver upto the stack. Using pci_dma_sync_single_for_cpu
>    ensures copying latest and updated data into skb from the receive buffer.
>    
>    Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
>    Signed-off-by: Manish Chopra <manish.chopra@qlogic.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 827e50724c0009dc327627df1edb478cda1ca32a
>Author: Guillaume Nault <g.nault@alphalink.fr>
>Date:   Mon Mar 14 21:17:16 2016 +0100
>
>    ppp: ensure file->private_data can't be overridden
>    
>    [ Upstream commit e8e56ffd9d2973398b60ece1f1bebb8d67b4d032 ]
>    
>    Locking ppp_mutex must be done before dereferencing file->private_data,
>    otherwise it could be modified before ppp_unattached_ioctl() takes the
>    lock. This could lead ppp_unattached_ioctl() to override ->private_data,
>    thus leaking reference to the ppp_file previously pointed to.
>    
>    v2: lock all ppp_ioctl() instead of just checking private_data in
>        ppp_unattached_ioctl(), to avoid ambiguous behaviour.
>    
>    Fixes: f3ff8a4d80e8 ("ppp: push BKL down into the driver")
>    Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 58bcdf4573b78c0eecf682abe636ad7363e19635
>Author: Arnd Bergmann <arnd@arndb.de>
>Date:   Mon Mar 14 15:18:36 2016 +0100
>
>    ath9k: fix buffer overrun for ar9287
>    
>    [ Upstream commit 83d6f1f15f8cce844b0a131cbc63e444620e48b5 ]
>    
>    Code that was added back in 2.6.38 has an obvious overflow
>    when accessing a static array, and at the time it was added
>    only a code comment was put in front of it as a reminder
>    to have it reviewed properly.
>    
>    This has not happened, but gcc-6 now points to the specific
>    overflow:
>    
>    drivers/net/wireless/ath/ath9k/eeprom.c: In function 'ath9k_hw_get_gain_boundaries_pdadcs':
>    drivers/net/wireless/ath/ath9k/eeprom.c:483:44: error: array subscript is above array bounds [-Werror=array-bounds]
>         maxPwrT4[i] = data_9287[idxL].pwrPdg[i][4];
>                       ~~~~~~~~~~~~~~~~~~~~~~~~~^~~
>    
>    It turns out that the correct array length exists in the local
>    'intercepts' variable of this function, so we can just use that
>    instead of hardcoding '4', so this patch changes all three
>    instances to use that variable. The other two instances were
>    already correct, but it's more consistent this way.
>    
>    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>    Fixes: 940cd2c12ebf ("ath9k_hw: merge the ar9287 version of ath9k_hw_get_gain_boundaries_pdadcs")
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7b95465ef5afa3924fc3dbb5d27a9667a18f4f81
>Author: Arnd Bergmann <arnd@arndb.de>
>Date:   Mon Mar 14 15:18:35 2016 +0100
>
>    farsync: fix off-by-one bug in fst_add_one
>    
>    [ Upstream commit e725a66c0202b5f36c2f9d59d26a65c53bbf21f7 ]
>    
>    gcc-6 finds an out of bounds access in the fst_add_one function
>    when calculating the end of the mmio area:
>    
>    drivers/net/wan/farsync.c: In function 'fst_add_one':
>    drivers/net/wan/farsync.c:418:53: error: index 2 denotes an offset greater than size of 'u8[2][8192] {aka unsigned char[2][8192]}' [-Werror=array-bounds]
>     #define BUF_OFFSET(X)   (BFM_BASE + offsetof(struct buf_window, X))
>                                                         ^
>    include/linux/compiler-gcc.h:158:21: note: in definition of macro '__compiler_offsetof'
>      __builtin_offsetof(a, b)
>                         ^
>    drivers/net/wan/farsync.c:418:37: note: in expansion of macro 'offsetof'
>     #define BUF_OFFSET(X)   (BFM_BASE + offsetof(struct buf_window, X))
>                                         ^~~~~~~~
>    drivers/net/wan/farsync.c:2519:36: note: in expansion of macro 'BUF_OFFSET'
>                                      + BUF_OFFSET ( txBuffer[i][NUM_TX_BUFFER][0]);
>                                        ^~~~~~~~~~
>    
>    The warning is correct, but not critical because this appears
>    to be a write-only variable that is set by each WAN driver but
>    never accessed afterwards.
>    
>    I'm taking the minimal fix here, using the correct pointer by
>    pointing 'mem_end' to the last byte inside of the register area
>    as all other WAN drivers do, rather than the first byte outside of
>    it. An alternative would be to just remove the mem_end member
>    entirely.
>    
>    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c7c3a3219def53ece4b535f220deefa021ee09f7
>Author: Arnd Bergmann <arnd@arndb.de>
>Date:   Mon Mar 14 15:18:34 2016 +0100
>
>    mlx4: add missing braces in verify_qp_parameters
>    
>    [ Upstream commit baefd7015cdb304ce6c94f9679d0486c71954766 ]
>    
>    The implementation of QP paravirtualization back in linux-3.7 included
>    some code that looks very dubious, and gcc-6 has grown smart enough
>    to warn about it:
>    
>    drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function 'verify_qp_parameters':
>    drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:3154:5: error: statement is indented as if it were guarded by... [-Werror=misleading-indentation]
>         if (optpar & MLX4_QP_OPTPAR_ALT_ADDR_PATH) {
>         ^~
>    drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:3144:4: note: ...this 'if' clause, but it is not
>        if (slave != mlx4_master_func_num(dev))
>    
>    >From looking at the context, I'm reasonably sure that the indentation
>    is correct but that it should have contained curly braces from the
>    start, as the update_gid() function in the same patch correctly does.
>    
>    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>    Fixes: 54679e148287 ("mlx4: Implement QP paravirtualization and maintain phys_pkey_cache for smp_snoop")
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8ca7bf099ae0e6ff096b3910895b5285a112aeb5
>Author: Arnaldo Carvalho de Melo <acme@redhat.com>
>Date:   Mon Mar 14 09:56:35 2016 -0300
>
>    net: Fix use after free in the recvmmsg exit path
>    
>    [ Upstream commit 34b88a68f26a75e4fded796f1a49c40f82234b7d ]
>    
>    The syzkaller fuzzer hit the following use-after-free:
>    
>      Call Trace:
>       [<ffffffff8175ea0e>] __asan_report_load8_noabort+0x3e/0x40 mm/kasan/report.c:295
>       [<ffffffff851cc31a>] __sys_recvmmsg+0x6fa/0x7f0 net/socket.c:2261
>       [<     inline     >] SYSC_recvmmsg net/socket.c:2281
>       [<ffffffff851cc57f>] SyS_recvmmsg+0x16f/0x180 net/socket.c:2270
>       [<ffffffff86332bb6>] entry_SYSCALL_64_fastpath+0x16/0x7a
>      arch/x86/entry/entry_64.S:185
>    
>    And, as Dmitry rightly assessed, that is because we can drop the
>    reference and then touch it when the underlying recvmsg calls return
>    some packets and then hit an error, which will make recvmmsg to set
>    sock->sk->sk_err, oops, fix it.
>    
>    Reported-and-Tested-by: Dmitry Vyukov <dvyukov@google.com>
>    Cc: Alexander Potapenko <glider@google.com>
>    Cc: Eric Dumazet <edumazet@google.com>
>    Cc: Kostya Serebryany <kcc@google.com>
>    Cc: Sasha Levin <sasha.levin@oracle.com>
>    Fixes: a2e2725541fa ("net: Introduce recvmmsg socket syscall")
>    http://lkml.kernel.org/r/20160122211644.GC2470@redhat.com
>    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 86de8271be91cce66aace5a3ae8afd3f28094957
>Author: David S. Miller <davem@davemloft.net>
>Date:   Sun Mar 13 23:28:00 2016 -0400
>
>    ipv4: Don't do expensive useless work during inetdev destroy.
>    
>    [ Upstream commit fbd40ea0180a2d328c5adc61414dc8bab9335ce2 ]
>    
>    When an inetdev is destroyed, every address assigned to the interface
>    is removed.  And in this scenerio we do two pointless things which can
>    be very expensive if the number of assigned interfaces is large:
>    
>    1) Address promotion.  We are deleting all addresses, so there is no
>       point in doing this.
>    
>    2) A full nf conntrack table purge for every address.  We only need to
>       do this once, as is already caught by the existing
>       masq_dev_notifier so masq_inet_event() can skip this.
>    
>    Reported-by: Solar Designer <solar@openwall.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Tested-by: Cyrill Gorcunov <gorcunov@openvz.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 686263920d666722c42b5347123113bd85ec67cc
>Author: Willem de Bruijn <willemb@google.com>
>Date:   Tue Mar 8 15:18:54 2016 -0500
>
>    macvtap: always pass ethernet header in linear
>    
>    [ Upstream commit 8e2ad4113ce4671686740f808ff2795395c39eef ]
>    
>    The stack expects link layer headers in the skb linear section.
>    Macvtap can create skbs with llheader in frags in edge cases:
>    when (IFF_VNET_HDR is off or vnet_hdr.hdr_len < ETH_HLEN) and
>    prepad + len > PAGE_SIZE and vnet_hdr.flags has no or bad csum.
>    
>    Add checks to ensure linear is always at least ETH_HLEN.
>    At this point, len is already ensured to be >= ETH_HLEN.
>    
>    For backwards compatiblity, rounds up short vnet_hdr.hdr_len.
>    This differs from tap and packet, which return an error.
>    
>    Fixes b9fb9ee07e67 ("macvtap: add GSO/csum offload support")
>    Signed-off-by: Willem de Bruijn <willemb@google.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5284ee1e9da2f8f78b5b800109ef4c436c58876d
>Author: Rajesh Borundia <rajesh.borundia@qlogic.com>
>Date:   Tue Mar 8 02:39:58 2016 -0500
>
>    qlcnic: Fix mailbox completion handling during spurious interrupt
>    
>    [ Upstream commit 819bfe764dceec2f6b4551768453f374b4c60443 ]
>    
>    o While the driver is in the middle of a MB completion processing
>    and it receives a spurious MB interrupt, it is mistaken as a good MB
>    completion interrupt leading to premature completion of the next MB
>    request. Fix the driver to guard against this by checking the current
>    state of MB processing and ignore the spurious interrupt.
>    Also added a stats counter to record this condition.
>    
>    Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit fa565f5389b3886d3b28a8c12ad7ee8511098ca3
>Author: Rajesh Borundia <rajesh.borundia@qlogic.com>
>Date:   Tue Mar 8 02:39:57 2016 -0500
>
>    qlcnic: Remove unnecessary usage of atomic_t
>    
>    [ Upstream commit 5bf93251cee1fb66141d1d2eaff86e04a9397bdf ]
>    
>    o atomic_t usage is incorrect as we are not implementing
>    any atomicity.
>    
>    Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 52643323baa9f6aea370fb00c9a01798ff727302
>Author: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>Date:   Sat Oct 24 00:46:03 2015 +0300
>
>    sh_eth: fix RX buffer size alignment
>    
>    [ Upstream commit ab8579169b79c062935dade949287113c7c1ba73 ]
>    
>    Both  Renesas R-Car and RZ/A1 manuals state that RX buffer  length must be
>    a multiple of 32 bytes, while the driver  only uses 16 byte granularity...
>    
>    Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c5e6283a4379eaae2d7fe596fc29ea02a14ac818
>Author: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>Date:   Tue Mar 8 01:36:28 2016 +0300
>
>    sh_eth: fix NULL pointer dereference in sh_eth_ring_format()
>    
>    [ Upstream commit c1b7fca65070bfadca94dd53a4e6b71cd4f69715 ]
>    
>    In a low memory situation, if netdev_alloc_skb() fails on a first RX ring
>    loop iteration  in sh_eth_ring_format(), 'rxdesc' is still NULL.  Avoid
>    kernel oops by adding the 'rxdesc' check after the loop.
>    
>    Reported-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
>    Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 795f5dc952b62c0a4afe5d8872f6f16372243293
>Author: Willem de Bruijn <willemb@google.com>
>Date:   Wed Mar 9 21:58:34 2016 -0500
>
>    packet: validate variable length ll headers
>    
>    [ Upstream commit 9ed988cd591500c040b2a6257bc68543e08ceeef ]
>    
>    Replace link layer header validation check ll_header_truncate with
>    more generic dev_validate_header.
>    
>    Validation based on hard_header_len incorrectly drops valid packets
>    in variable length protocols, such as AX25. dev_validate_header
>    calls header_ops.validate for such protocols to ensure correctness
>    below hard_header_len.
>    
>    See also http://comments.gmane.org/gmane.linux.network/401064
>    
>    Fixes 9c7077622dd9 ("packet: make packet_snd fail on len smaller than l2 header")
>    Signed-off-by: Willem de Bruijn <willemb@google.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 58ba5f64ecb7c1909c060793be9e46cc28b417db
>Author: Willem de Bruijn <willemb@google.com>
>Date:   Wed Mar 9 21:58:33 2016 -0500
>
>    ax25: add link layer header validation function
>    
>    [ Upstream commit ea47781c26510e5d97f80f9aceafe9065bd5e3aa ]
>    
>    As variable length protocol, AX25 fails link layer header validation
>    tests based on a minimum length. header_ops.validate allows protocols
>    to validate headers that are shorter than hard_header_len. Implement
>    this callback for AX25.
>    
>    See also http://comments.gmane.org/gmane.linux.network/401064
>    
>    Signed-off-by: Willem de Bruijn <willemb@google.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1df16498dfd0d5a129bdf2982d9a08df73e8923d
>Author: Willem de Bruijn <willemb@google.com>
>Date:   Wed Mar 9 21:58:32 2016 -0500
>
>    net: validate variable length ll headers
>    
>    [ Upstream commit 2793a23aacbd754dbbb5cb75093deb7e4103bace ]
>    
>    Netdevice parameter hard_header_len is variously interpreted both as
>    an upper and lower bound on link layer header length. The field is
>    used as upper bound when reserving room at allocation, as lower bound
>    when validating user input in PF_PACKET.
>    
>    Clarify the definition to be maximum header length. For validation
>    of untrusted headers, add an optional validate member to header_ops.
>    
>    Allow bypassing of validation by passing CAP_SYS_RAWIO, for instance
>    for deliberate testing of corrupt input. In this case, pad trailing
>    bytes, as some device drivers expect completely initialized headers.
>    
>    See also http://comments.gmane.org/gmane.linux.network/401064
>    
>    Signed-off-by: Willem de Bruijn <willemb@google.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 58c92f1359c6811478159cfe3cc3118bdb995608
>Author: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>Date:   Sun Nov 22 17:46:09 2015 +0100
>
>    packet: Allow packets with only a header (but no payload)
>    
>    [ Upstream commit 880621c2605b82eb5af91a2c94223df6f5a3fb64 ]
>    
>    Commit 9c7077622dd91 ("packet: make packet_snd fail on len smaller
>    than l2 header") added validation for the packet size in packet_snd.
>    This change enforces that every packet needs a header (with at least
>    hard_header_len bytes) plus a payload with at least one byte. Before
>    this change the payload was optional.
>    
>    This fixes PPPoE connections which do not have a "Service" or
>    "Host-Uniq" configured (which is violating the spec, but is still
>    widely used in real-world setups). Those are currently failing with the
>    following message: "pppd: packet size is too short (24 <= 24)"
>    
>    Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6def7a990b10af3532caed172e7ada9dbb596a53
>Author: Bill Sommerfeld <wsommerfeld@google.com>
>Date:   Fri Mar 4 14:47:21 2016 -0800
>
>    udp6: fix UDP/IPv6 encap resubmit path
>    
>    [ Upstream commit 59dca1d8a6725a121dae6c452de0b2611d5865dc ]
>    
>    IPv4 interprets a negative return value from a protocol handler as a
>    request to redispatch to a new protocol.  In contrast, IPv6 interprets a
>    negative value as an error, and interprets a positive value as a request
>    for redispatch.
>    
>    UDP for IPv6 was unaware of this difference.  Change __udp6_lib_rcv() to
>    return a positive value for redispatch.  Note that the socket's
>    encap_rcv hook still needs to return a negative value to request
>    dispatch, and in the case of IPv6 packets, adjust IP6CB(skb)->nhoff to
>    identify the byte containing the next protocol.
>    
>    Signed-off-by: Bill Sommerfeld <wsommerfeld@google.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 900aa9788446a8bc7fc40f21199bbe1dbdc1bf19
>Author: Oliver Neukum <oneukum@suse.com>
>Date:   Mon Mar 7 11:31:10 2016 +0100
>
>    usbnet: cleanup after bind() in probe()
>    
>    [ Upstream commit 1666984c8625b3db19a9abc298931d35ab7bc64b ]
>    
>    In case bind() works, but a later error forces bailing
>    in probe() in error cases work and a timer may be scheduled.
>    They must be killed. This fixes an error case related to
>    the double free reported in
>    http://www.spinics.net/lists/netdev/msg367669.html
>    and needs to go on top of Linus' fix to cdc-ncm.
>    
>    Signed-off-by: Oliver Neukum <ONeukum@suse.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit cf852e989018e95f25e8a620f77e380812a9460f
>Author: BjÃ¸rn Mork <bjorn@mork.no>
>Date:   Thu Mar 3 22:20:53 2016 +0100
>
>    cdc_ncm: toggle altsetting to force reset before setup
>    
>    [ Upstream commit 48906f62c96cc2cd35753e59310cb70eb08cc6a5 ]
>    
>    Some devices will silently fail setup unless they are reset first.
>    This is necessary even if the data interface is already in
>    altsetting 0, which it will be when the device is probed for the
>    first time.  Briefly toggling the altsetting forces a function
>    reset regardless of the initial state.
>    
>    This fixes a setup problem observed on a number of Huawei devices,
>    appearing to operate in NTB-32 mode even if we explicitly set them
>    to NTB-16 mode.
>    
>    Signed-off-by: BjÃ¸rn Mork <bjorn@mork.no>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit af4f7a3ca6a0928551220a7a8bea3cd3e70b873e
>Author: Florian Westphal <fw@strlen.de>
>Date:   Tue Mar 1 16:15:16 2016 +0100
>
>    ipv6: re-enable fragment header matching in ipv6_find_hdr
>    
>    [ Upstream commit 5d150a985520bbe3cb2aa1ceef24a7e32f20c15f ]
>    
>    When ipv6_find_hdr is used to find a fragment header
>    (caller specifies target NEXTHDR_FRAGMENT) we erronously return
>    -ENOENT for all fragments with nonzero offset.
>    
>    Before commit 9195bb8e381d, when target was specified, we did not
>    enter the exthdr walk loop as nexthdr == target so this used to work.
>    
>    Now we do (so we can skip empty route headers). When we then stumble upon
>    a frag with nonzero frag_off we must return -ENOENT ("header not found")
>    only if the caller did not specifically request NEXTHDR_FRAGMENT.
>    
>    This allows nfables exthdr expression to match ipv6 fragments, e.g. via
>    
>    nft add rule ip6 filter input frag frag-off gt 0
>    
>    Fixes: 9195bb8e381d ("ipv6: improve ipv6_find_hdr() to skip empty routing headers")
>    Signed-off-by: Florian Westphal <fw@strlen.de>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4ded71d9c776483496b7249fafd375e7e09bb205
>Author: BjÃ¸rn Mork <bjorn@mork.no>
>Date:   Tue Mar 1 14:31:02 2016 +0100
>
>    qmi_wwan: add Sierra Wireless EM74xx device ID
>    
>    [ Upstream commit bf13c94ccb33c3182efc92ce4989506a0f541243 ]
>    
>    The MC74xx and EM74xx modules use different IDs by default, according
>    to the Lenovo EM7455 driver for Windows.
>    
>    Signed-off-by: BjÃ¸rn Mork <bjorn@mork.no>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit fda740f68c700b1da33a512ec8005d86f275265a
>Author: Benjamin Poirier <bpoirier@suse.com>
>Date:   Mon Feb 29 15:03:33 2016 -0800
>
>    mld, igmp: Fix reserved tailroom calculation
>    
>    [ Upstream commit 1837b2e2bcd23137766555a63867e649c0b637f0 ]
>    
>    The current reserved_tailroom calculation fails to take hlen and tlen into
>    account.
>    
>    skb:
>    [__hlen__|__data____________|__tlen___|__extra__]
>    ^                                               ^
>    head                                            skb_end_offset
>    
>    In this representation, hlen + data + tlen is the size passed to alloc_skb.
>    "extra" is the extra space made available in __alloc_skb because of
>    rounding up by kmalloc. We can reorder the representation like so:
>    
>    [__hlen__|__data____________|__extra__|__tlen___]
>    ^                                               ^
>    head                                            skb_end_offset
>    
>    The maximum space available for ip headers and payload without
>    fragmentation is min(mtu, data + extra). Therefore,
>    reserved_tailroom
>    = data + extra + tlen - min(mtu, data + extra)
>    = skb_end_offset - hlen - min(mtu, skb_end_offset - hlen - tlen)
>    = skb_tailroom - min(mtu, skb_tailroom - tlen) ; after skb_reserve(hlen)
>    
>    Compare the second line to the current expression:
>    reserved_tailroom = skb_end_offset - min(mtu, skb_end_offset)
>    and we can see that hlen and tlen are not taken into account.
>    
>    The min() in the third line can be expanded into:
>    if mtu < skb_tailroom - tlen:
>    	reserved_tailroom = skb_tailroom - mtu
>    else:
>    	reserved_tailroom = tlen
>    
>    Depending on hlen, tlen, mtu and the number of multicast address records,
>    the current code may output skbs that have less tailroom than
>    dev->needed_tailroom or it may output more skbs than needed because not all
>    space available is used.
>    
>    Fixes: 4c672e4b ("ipv6: mld: fix add_grhead skb_over_panic for devs with large MTUs")
>    Signed-off-by: Benjamin Poirier <bpoirier@suse.com>
>    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
>    Acked-by: Daniel Borkmann <daniel@iogearbox.net>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 67eab3249eacc0861cf57f6d929e66bf78159379
>Author: Xin Long <lucien.xin@gmail.com>
>Date:   Sun Feb 28 10:03:51 2016 +0800
>
>    sctp: lack the check for ports in sctp_v6_cmp_addr
>    
>    [ Upstream commit 40b4f0fd74e46c017814618d67ec9127ff20f157 ]
>    
>    As the member .cmp_addr of sctp_af_inet6, sctp_v6_cmp_addr should also check
>    the port of addresses, just like sctp_v4_cmp_addr, cause it's invoked by
>    sctp_cmp_addr_exact().
>    
>    Now sctp_v6_cmp_addr just check the port when two addresses have different
>    family, and lack the port check for two ipv6 addresses. that will make
>    sctp_hash_cmp() cannot work well.
>    
>    so fix it by adding ports comparison in sctp_v6_cmp_addr().
>    
>    Signed-off-by: Xin Long <lucien.xin@gmail.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8590142dc5b464c3bbf60ef0b14322850983c1c1
>Author: Stefan Wahren <stefan.wahren@i2se.com>
>Date:   Tue Feb 23 19:23:24 2016 +0000
>
>    net: qca_spi: clear IFF_TX_SKB_SHARING
>    
>    [ Upstream commit a4690afeb0d2d7ba4d60dfa98a89f3bb1ce60ecd ]
>    
>    ether_setup sets IFF_TX_SKB_SHARING but this is not supported by
>    qca_spi as it modifies the skb on xmit.
>    
>    Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>    Fixes: 291ab06ecf67 (net: qualcomm: new Ethernet over SPI driver for QCA7000)
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 830b50eabc046fee60aedf8dc6384a9894033f31
>Author: Stefan Wahren <stefan.wahren@i2se.com>
>Date:   Tue Feb 23 19:23:23 2016 +0000
>
>    net: qca_spi: Don't clear IFF_BROADCAST
>    
>    [ Upstream commit 2b70bad23c89b121a3e4a00f8968d14ebb78887d ]
>    
>    Currently qcaspi_netdev_setup accidentally clears IFF_BROADCAST.
>    So fix this by keeping the flags from ether_setup.
>    
>    Reported-by: Michael Heimpold <michael.heimpold@i2se.com>
>    Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>    Fixes: 291ab06ecf67 (net: qualcomm: new Ethernet over SPI driver for QCA7000)
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2131abc39f1033260ffc66a37e26bef9ddab8b16
>Author: Diego Viola <diego.viola@gmail.com>
>Date:   Tue Feb 23 12:04:04 2016 -0300
>
>    net: jme: fix suspend/resume on JMC260
>    
>    [ Upstream commit ee50c130c82175eaa0820c96b6d3763928af2241 ]
>    
>    The JMC260 network card fails to suspend/resume because the call to
>    jme_start_irq() was too early, moving the call to jme_start_irq() after
>    the call to jme_reset_link() makes it work.
>    
>    Prior this change suspend/resume would fail unless /sys/power/pm_async=0
>    was explicitly specified.
>    
>    Relevant bug report: https://bugzilla.kernel.org/show_bug.cgi?id=112351
>    
>    Signed-off-by: Diego Viola <diego.viola@gmail.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ea82b38fce682e4277cb20f385b3cebbb91cd1e5
>Author: Bernie Harris <bernie.harris@alliedtelesis.co.nz>
>Date:   Mon Feb 22 12:58:05 2016 +1300
>
>    tunnel: Clear IPCB(skb)->opt before dst_link_failure called
>    
>    [ Upstream commit 5146d1f151122e868e594c7b45115d64825aee5f ]
>    
>    IPCB may contain data from previous layers (in the observed case the
>    qdisc layer). In the observed scenario, the data was misinterpreted as
>    ip header options, which later caused the ihl to be set to an invalid
>    value (<5). This resulted in an infinite loop in the mips implementation
>    of ip_fast_csum.
>    
>    This patch clears IPCB(skb)->opt before dst_link_failure can be called for
>    various types of tunnels. This change only applies to encapsulated ipv4
>    packets.
>    
>    The code introduced in 11c21a30 which clears all of IPCB has been removed
>    to be consistent with these changes, and instead the opt field is cleared
>    unconditionally in ip_tunnel_xmit. The change in ip_tunnel_xmit applies to
>    SIT, GRE, and IPIP tunnels.
>    
>    The relevant vti, l2tp, and pptp functions already contain similar code for
>    clearing the IPCB.
>    
>    Signed-off-by: Bernie Harris <bernie.harris@alliedtelesis.co.nz>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3de6011e6ba781498f9a5ba52638c0dbcd346832
>Author: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
>Date:   Sun Feb 21 10:12:39 2016 +0300
>
>    tcp: convert cached rtt from usec to jiffies when feeding initial rto
>    
>    [ Upstream commit 9bdfb3b79e61c60e1a3e2dc05ad164528afa6b8a ]
>    
>    Currently it's converted into msecs, thus HZ=1000 intact.
>    
>    Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
>    Fixes: 740b0f1841f6 ("tcp: switch rtt estimations to usec resolution")
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d393b6c7cba4d7e9fd07e0d774e875e6ff0d1dd2
>Author: Alex Deucher <alexander.deucher@amd.com>
>Date:   Mon Mar 28 10:21:20 2016 -0400
>
>    drm/radeon: add a dpm quirk for all R7 370 parts
>    
>    [ Upstream commit 0e5585dc870af947fab2af96a88c2d8b4270247c ]
>    
>    Higher mclk values are not stable due to a bug somewhere.
>    Limit them for now.
>    
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit cd18a79a6445fecf42114a9124c5ff23d72201cd
>Author: Alex Deucher <alexander.deucher@amd.com>
>Date:   Fri Mar 25 10:31:04 2016 -0400
>
>    drm/radeon: add a dpm quirk for sapphire Dual-X R7 370 2G D5
>    
>    [ Upstream commit f971f2263deaa4a441e377b385c11aee0f3b3f9a ]
>    
>    bug:
>    https://bugs.freedesktop.org/show_bug.cgi?id=94692
>    
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 28a201e2e8323ffeb3ac2fc51b454a410dde3527
>Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>Date:   Wed Mar 30 11:40:43 2016 +0200
>
>    drm/udl: Use unlocked gem unreferencing
>    
>    [ Upstream commit 72b9ff0612ad8fc969b910cd00ac16b57a1a9ba4 ]
>    
>    For drm_gem_object_unreference callers are required to hold
>    dev->struct_mutex, which these paths don't. Enforcing this requirement
>    has become a bit more strict with
>    
>    commit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663
>    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>    Date:   Thu Oct 15 09:36:25 2015 +0200
>    
>        drm/gem: Check locking in drm_gem_object_unreference
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>    Signed-off-by: Dave Airlie <airlied@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit da38a239f06b9bd2e8338c0f8c468d2ae04eb046
>Author: Todd Previte <tprevite@gmail.com>
>Date:   Sat Apr 18 00:04:18 2015 -0700
>
>    drm: Fix for DP CTS test 4.2.2.5 - I2C DEFER handling
>    
>    [ Upstream commit 396aa4451e865d1e36d6d4e0686a9303c038b606 ]
>    
>    For test 4.2.2.5 to pass per the Link CTS Core 1.2 rev1.1 spec, the source
>    device must attempt at least 7 times to read the EDID when it receives an
>    I2C defer. The normal DRM code makes only 7 retries, regardless of whether
>    or not the response is a native defer or an I2C defer. Test 4.2.2.5 fails
>    since there are native defers interspersed with the I2C defers which
>    results in less than 7 EDID read attempts.
>    
>    The solution is to add the numer of defers to the retry counter when an I2C
>    DEFER is returned such that another read attempt will be made. This situation
>    should normally only occur in compliance testing, however, as a worse case
>    real-world scenario, it would result in 13 attempts ( 6 native defers, 7 I2C
>    defers) for a single transaction to complete. The net result is a slightly
>    slower response to an EDID read that shouldn't significantly impact overall
>    performance.
>    
>    V2:
>    - Added a check on the number of I2C Defers to limit the number
>      of times that the retries variable will be decremented. This
>      is to address review feedback regarding possible infinite loops
>      from misbehaving sink devices.
>    V3:
>    - Fixed the limit value to 7 instead of 8 to get the correct retry
>      count.
>    - Combined the increment of the defer count into the if-statement
>    V4:
>    - Removed i915 tag from subject as the patch is not i915-specific
>    V5:
>    - Updated the for-loop to add the number of i2c defers to the retry
>      counter such that the correct number of retry attempts will be
>      made
>    
>    Signed-off-by: Todd Previte <tprevite@gmail.com>
>    Cc: dri-devel@lists.freedesktop.org
>    Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
>    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7e69c7b26e03e6f573d8613326c94f7ddc5935b8
>Author: Sebastian Siewior <bigeasy@linutronix.de>
>Date:   Tue Mar 8 10:03:56 2016 +0100
>
>    powerpc/mm: Fixup preempt underflow with huge pages
>    
>    [ Upstream commit 08a5bb2921e490939f78f38fd0d02858bb709942 ]
>    
>    hugepd_free() used __get_cpu_var() once. Nothing ensured that the code
>    accessing the variable did not migrate from one CPU to another and soon
>    this was noticed by Tiejun Chen in 94b09d755462 ("powerpc/hugetlb:
>    Replace __get_cpu_var with get_cpu_var"). So we had it fixed.
>    
>    Christoph Lameter was doing his __get_cpu_var() replaces and forgot
>    PowerPC. Then he noticed this and sent his fixed up batch again which
>    got applied as 69111bac42f5 ("powerpc: Replace __get_cpu_var uses").
>    
>    The careful reader will noticed one little detail: get_cpu_var() got
>    replaced with this_cpu_ptr(). So now we have a put_cpu_var() which does
>    a preempt_enable() and nothing that does preempt_disable() so we
>    underflow the preempt counter.
>    
>    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>    Cc: Christoph Lameter <cl@linux.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>    Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 39bf5645d861cb5dc7913b183fecfc6fad033b4e
>Author: Xishi Qiu <qiuxishi@huawei.com>
>Date:   Fri Apr 1 14:31:20 2016 -0700
>
>    mm: fix invalid node in alloc_migrate_target()
>    
>    [ Upstream commit 6f25a14a7053b69917e2ebea0d31dd444cd31fd5 ]
>    
>    It is incorrect to use next_node to find a target node, it will return
>    MAX_NUMNODES or invalid node.  This will lead to crash in buddy system
>    allocation.
>    
>    Fixes: c8721bbbdd36 ("mm: memory-hotplug: enable memory hotplug to handle hugepage")
>    Signed-off-by: Xishi Qiu <qiuxishi@huawei.com>
>    Acked-by: Vlastimil Babka <vbabka@suse.cz>
>    Acked-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
>    Cc: Joonsoo Kim <js1304@gmail.com>
>    Cc: David Rientjes <rientjes@google.com>
>    Cc: "Laura Abbott" <lauraa@codeaurora.org>
>    Cc: Hui Zhu <zhuhui@xiaomi.com>
>    Cc: Wang Xiaoqiang <wangxq10@lzu.edu.cn>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b9f2aab60bfe7f85dc9ffaeb6f258bfcd4d5bc1a
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Fri Apr 1 12:28:16 2016 +0200
>
>    ALSA: timer: Use mod_timer() for rearming the system timer
>    
>    [ Upstream commit 4a07083ed613644c96c34a7dd2853dc5d7c70902 ]
>    
>    ALSA system timer backend stops the timer via del_timer() without sync
>    and leaves del_timer_sync() at the close instead.  This is because of
>    the restriction by the design of ALSA timer: namely, the stop callback
>    may be called from the timer handler, and calling the sync shall lead
>    to a hangup.  However, this also triggers a kernel BUG() when the
>    timer is rearmed immediately after stopping without sync:
>     kernel BUG at kernel/time/timer.c:966!
>     Call Trace:
>      <IRQ>
>      [<ffffffff8239c94e>] snd_timer_s_start+0x13e/0x1a0
>      [<ffffffff8239e1f4>] snd_timer_interrupt+0x504/0xec0
>      [<ffffffff8122fca0>] ? debug_check_no_locks_freed+0x290/0x290
>      [<ffffffff8239ec64>] snd_timer_s_function+0xb4/0x120
>      [<ffffffff81296b72>] call_timer_fn+0x162/0x520
>      [<ffffffff81296add>] ? call_timer_fn+0xcd/0x520
>      [<ffffffff8239ebb0>] ? snd_timer_interrupt+0xec0/0xec0
>      ....
>    
>    It's the place where add_timer() checks the pending timer.  It's clear
>    that this may happen after the immediate restart without sync in our
>    cases.
>    
>    So, the workaround here is just to use mod_timer() instead of
>    add_timer().  This looks like a band-aid fix, but it's a right move,
>    as snd_timer_interrupt() takes care of the continuous rearm of timer.
>    
>    Reported-by: Jiri Slaby <jslaby@suse.cz>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit fb7a806fe08816a6fd2eb258db5e28218624bd07
>Author: Nicolai Stange <nicstange@gmail.com>
>Date:   Sun Mar 20 23:23:46 2016 +0100
>
>    PKCS#7: pkcs7_validate_trust(): initialize the _trusted output argument
>    
>    [ Upstream commit e54358915d0a00399c11c2c23ae1be674cba188a ]
>    
>    Despite what the DocBook comment to pkcs7_validate_trust() says, the
>    *_trusted argument is never set to false.
>    
>    pkcs7_validate_trust() only positively sets *_trusted upon encountering
>    a trusted PKCS#7 SignedInfo block.
>    
>    This is quite unfortunate since its callers, system_verify_data() for
>    example, depend on pkcs7_validate_trust() clearing *_trusted on non-trust.
>    
>    Indeed, UBSAN splats when attempting to load the uninitialized local
>    variable 'trusted' from system_verify_data() in pkcs7_validate_trust():
>    
>      UBSAN: Undefined behaviour in crypto/asymmetric_keys/pkcs7_trust.c:194:14
>      load of value 82 is not a valid value for type '_Bool'
>      [...]
>      Call Trace:
>        [<ffffffff818c4d35>] dump_stack+0xbc/0x117
>        [<ffffffff818c4c79>] ? _atomic_dec_and_lock+0x169/0x169
>        [<ffffffff8194113b>] ubsan_epilogue+0xd/0x4e
>        [<ffffffff819419fa>] __ubsan_handle_load_invalid_value+0x111/0x158
>        [<ffffffff819418e9>] ? val_to_string.constprop.12+0xcf/0xcf
>        [<ffffffff818334a4>] ? x509_request_asymmetric_key+0x114/0x370
>        [<ffffffff814b83f0>] ? kfree+0x220/0x370
>        [<ffffffff818312c2>] ? public_key_verify_signature_2+0x32/0x50
>        [<ffffffff81835e04>] pkcs7_validate_trust+0x524/0x5f0
>        [<ffffffff813c391a>] system_verify_data+0xca/0x170
>        [<ffffffff813c3850>] ? top_trace_array+0x9b/0x9b
>        [<ffffffff81510b29>] ? __vfs_read+0x279/0x3d0
>        [<ffffffff8129372f>] mod_verify_sig+0x1ff/0x290
>        [...]
>    
>    The implication is that pkcs7_validate_trust() effectively grants trust
>    when it really shouldn't have.
>    
>    Fix this by explicitly setting *_trusted to false at the very beginning
>    of pkcs7_validate_trust().
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Nicolai Stange <nicstange@gmail.com>
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit bf15ba34c2a9afb0090294597ec4122f92616b38
>Author: Guenter Roeck <linux@roeck-us.net>
>Date:   Sat Mar 26 12:28:05 2016 -0700
>
>    hwmon: (max1111) Return -ENODEV from max1111_read_channel if not instantiated
>    
>    [ Upstream commit 3c2e2266a5bd2d1cef258e6e54dca1d99946379f ]
>    
>    arm:pxa_defconfig can result in the following crash if the max1111 driver
>    is not instantiated.
>    
>    Unhandled fault: page domain fault (0x01b) at 0x00000000
>    pgd = c0004000
>    [00000000] *pgd=00000000
>    Internal error: : 1b [#1] PREEMPT ARM
>    Modules linked in:
>    CPU: 0 PID: 300 Comm: kworker/0:1 Not tainted 4.5.0-01301-g1701f680407c #10
>    Hardware name: SHARP Akita
>    Workqueue: events sharpsl_charge_toggle
>    task: c390a000 ti: c391e000 task.ti: c391e000
>    PC is at max1111_read_channel+0x20/0x30
>    LR is at sharpsl_pm_pxa_read_max1111+0x2c/0x3c
>    pc : [<c03aaab0>]    lr : [<c0024b50>]    psr: 20000013
>    ...
>    [<c03aaab0>] (max1111_read_channel) from [<c0024b50>]
>    					(sharpsl_pm_pxa_read_max1111+0x2c/0x3c)
>    [<c0024b50>] (sharpsl_pm_pxa_read_max1111) from [<c00262e0>]
>    					(spitzpm_read_devdata+0x5c/0xc4)
>    [<c00262e0>] (spitzpm_read_devdata) from [<c0024094>]
>    					(sharpsl_check_battery_temp+0x78/0x110)
>    [<c0024094>] (sharpsl_check_battery_temp) from [<c0024f9c>]
>    					(sharpsl_charge_toggle+0x48/0x110)
>    [<c0024f9c>] (sharpsl_charge_toggle) from [<c004429c>]
>    					(process_one_work+0x14c/0x48c)
>    [<c004429c>] (process_one_work) from [<c0044618>] (worker_thread+0x3c/0x5d4)
>    [<c0044618>] (worker_thread) from [<c004a238>] (kthread+0xd0/0xec)
>    [<c004a238>] (kthread) from [<c000a670>] (ret_from_fork+0x14/0x24)
>    
>    This can occur because the SPI controller driver (SPI_PXA2XX) is built as
>    module and thus not necessarily loaded. While building SPI_PXA2XX into the
>    kernel would make the problem disappear, it appears prudent to ensure that
>    the driver is instantiated before accessing its data structures.
>    
>    Cc: Arnd Bergmann <arnd@arndb.de>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4c06bf7e573a4e8cd8bf42ed99524e30b3aa8cbd
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Thu Mar 10 20:56:20 2016 +0100
>
>    ALSA: pcm: Avoid "BUG:" string for warnings again
>    
>    [ Upstream commit 0ab1ace856205d10cbc1924b2d931c01ffd216a6 ]
>    
>    The commit [d507941beb1e: ALSA: pcm: Correct PCM BUG error message]
>    made the warning prefix back to "BUG:" due to its previous wrong
>    prefix.  But a kernel message containing "BUG:" seems taken as an Oops
>    message wrongly by some brain-dead daemons, and it annoys users in the
>    end.  Instead of teaching daemons, change the string again to a more
>    reasonable one.
>    
>    Fixes: 507941beb1e ('ALSA: pcm: Correct PCM BUG error message')
>    Cc: <stable@vger.kernel.org> # v3.19+
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit cab680963342190c38a0df2e16b6184f9f67189a
>Author: Asai Thambi SP <asamymuthupa@micron.com>
>Date:   Wed Feb 24 21:16:00 2016 -0800
>
>    mtip32xx: Fix broken service thread handling
>    
>    [ Upstream commit 1b899eb4833d3394f37272d38b4b1a26eac30feb ]
>    
>    commit cfc05bd31384c4898bf2437a4de5557f3cf9803a upstream.
>    
>    Service thread does not detect the need for taskfile error hanlding. Fixed the
>    flag condition to process taskfile error.
>    
>    Signed-off-by: Selvan Mani <smani@micron.com>
>    Signed-off-by: Asai Thambi S P <asamymuthupa@micron.com>
>    Signed-off-by: Jens Axboe <axboe@fb.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 30dbed7b3dcc4b968ec050589f7acdcdabea8c7a
>Author: Asai Thambi SP <asamymuthupa@micron.com>
>Date:   Wed Feb 24 21:17:47 2016 -0800
>
>    mtip32xx: Fix for rmmod crash when drive is in FTL rebuild
>    
>    [ Upstream commit 59cf70e236c96594d9f1e065755d8fce9df5356b ]
>    
>    When FTL rebuild is in progress, alloc_disk() initializes the disk
>    but device node will be created by add_disk() only after successful
>    completion of FTL rebuild. So, skip deletion of device node in
>    removal path when FTL rebuild is in progress.
>    
>    Signed-off-by: Selvan Mani <smani@micron.com>
>    Signed-off-by: Asai Thambi S P <asamymuthupa@micron.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Jens Axboe <axboe@fb.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c6aa8bae477bf2fdaacbc8683f5801511aa3b859
>Author: Sebastian Frias <sf84@laposte.net>
>Date:   Fri Dec 18 17:40:05 2015 +0100
>
>    8250: use callbacks to access UART_DLL/UART_DLM
>    
>    [ Upstream commit 0b41ce991052022c030fd868e03877700220b090 ]
>    
>    Some UART HW has a single register combining UART_DLL/UART_DLM
>    (this was probably forgotten in the change that introduced the
>    callbacks, commit b32b19b8ffc05cbd3bf91c65e205f6a912ca15d9)
>    
>    Fixes: b32b19b8ffc0 ("[SERIAL] 8250: set divisor register correctly ...")
>    
>    Signed-off-by: Sebastian Frias <sf84@laposte.net>
>    Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e4e503b2a3c6ad22375010933041f05b2ef00367
>Author: Grazvydas Ignotas <notasas@gmail.com>
>Date:   Sat Feb 13 22:41:51 2016 +0200
>
>    HID: logitech: fix Dual Action gamepad support
>    
>    [ Upstream commit 5d74325a2201376a95520a4a38a1ce2c65761c49 ]
>    
>    The patch that added Logitech Dual Action gamepad support forgot to
>    update the special driver list for the device. This caused the logitech
>    driver not to probe unless kernel module load order was favorable.
>    Update the special driver list to fix it. Thanks to Simon Wood for the
>    idea.
>    
>    Cc: Vitaly Katraew <zawullon@gmail.com>
>    Fixes: 56d0c8b7c8fb ("HID: add support for Logitech Dual Action gamepads")
>    Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
>    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit eae5f796a5de5ebc33e745126ce232f534fd0d0e
>Author: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
>Date:   Mon Feb 8 22:31:08 2016 +0200
>
>    tpm: fix the cleanup of struct tpm_chip
>    
>    [ Upstream commit 8e0ee3c9faed7ca68807ea45141775856c438ac0 ]
>    
>    If the initialization fails before tpm_chip_register(), put_device()
>    will be not called, which causes release callback not to be called.
>    This patch fixes the issue by adding put_device() to devres list of
>    the parent device.
>    
>    Fixes: 313d21eeab ("tpm: device class for tpm")
>    Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
>    cc: stable@vger.kernel.org
>    Reviewed-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 03e046efdbd3bccaac952553065adb70fb6976aa
>Author: Vladis Dronov <vdronov@redhat.com>
>Date:   Thu Mar 31 12:05:43 2016 -0400
>
>    ALSA: usb-audio: Fix double-free in error paths after snd_usb_add_audio_stream() call
>    
>    [ Upstream commit 836b34a935abc91e13e63053d0a83b24dfb5ea78 ]
>    
>    create_fixed_stream_quirk(), snd_usb_parse_audio_interface() and
>    create_uaxx_quirk() functions allocate the audioformat object by themselves
>    and free it upon error before returning. However, once the object is linked
>    to a stream, it's freed again in snd_usb_audio_pcm_free(), thus it'll be
>    double-freed, eventually resulting in a memory corruption.
>    
>    This patch fixes these failures in the error paths by unlinking the audioformat
>    object before freeing it.
>    
>    Based on a patch by Takashi Iwai <tiwai@suse.de>
>    
>    [Note for stable backports:
>     this patch requires the commit 902eb7fd1e4a ('ALSA: usb-audio: Minor
>     code cleanup in create_fixed_stream_quirk()')]
>    
>    Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1283358
>    Reported-by: Ralf Spenneberg <ralf@spenneberg.net>
>    Cc: <stable@vger.kernel.org> # see the note above
>    Signed-off-by: Vladis Dronov <vdronov@redhat.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 00ef5df8687ff1a51660a5d27c202417a69b5018
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Tue Mar 15 12:14:49 2016 +0100
>
>    ALSA: usb-audio: Minor code cleanup in create_fixed_stream_quirk()
>    
>    [ Upstream commit 902eb7fd1e4af3ac69b9b30f8373f118c92b9729 ]
>    
>    Just a minor code cleanup: unify the error paths.
>    
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b5ba0d06632445b3810b50093cd22a2ab06900de
>Author: DingXiang <dingxiang@huawei.com>
>Date:   Tue Feb 2 12:29:18 2016 +0800
>
>    dm snapshot: disallow the COW and origin devices from being identical
>    
>    [ Upstream commit 4df2bf466a9c9c92f40d27c4aa9120f4e8227bfc ]
>    
>    Otherwise loading a "snapshot" table using the same device for the
>    origin and COW devices, e.g.:
>    
>    echo "0 20971520 snapshot 253:3 253:3 P 8" | dmsetup create snap
>    
>    will trigger:
>    
>    BUG: unable to handle kernel NULL pointer dereference at 0000000000000098
>    [ 1958.979934] IP: [<ffffffffa040efba>] dm_exception_store_set_chunk_size+0x7a/0x110 [dm_snapshot]
>    [ 1958.989655] PGD 0
>    [ 1958.991903] Oops: 0000 [#1] SMP
>    ...
>    [ 1959.059647] CPU: 9 PID: 3556 Comm: dmsetup Tainted: G          IO    4.5.0-rc5.snitm+ #150
>    ...
>    [ 1959.083517] task: ffff8800b9660c80 ti: ffff88032a954000 task.ti: ffff88032a954000
>    [ 1959.091865] RIP: 0010:[<ffffffffa040efba>]  [<ffffffffa040efba>] dm_exception_store_set_chunk_size+0x7a/0x110 [dm_snapshot]
>    [ 1959.104295] RSP: 0018:ffff88032a957b30  EFLAGS: 00010246
>    [ 1959.110219] RAX: 0000000000000000 RBX: 0000000000000008 RCX: 0000000000000001
>    [ 1959.118180] RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff880329334a00
>    [ 1959.126141] RBP: ffff88032a957b50 R08: 0000000000000000 R09: 0000000000000001
>    [ 1959.134102] R10: 000000000000000a R11: f000000000000000 R12: ffff880330884d80
>    [ 1959.142061] R13: 0000000000000008 R14: ffffc90001c13088 R15: ffff880330884d80
>    [ 1959.150021] FS:  00007f8926ba3840(0000) GS:ffff880333440000(0000) knlGS:0000000000000000
>    [ 1959.159047] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>    [ 1959.165456] CR2: 0000000000000098 CR3: 000000032f48b000 CR4: 00000000000006e0
>    [ 1959.173415] Stack:
>    [ 1959.175656]  ffffc90001c13040 ffff880329334a00 ffff880330884ed0 ffff88032a957bdc
>    [ 1959.183946]  ffff88032a957bb8 ffffffffa040f225 ffff880329334a30 ffff880300000000
>    [ 1959.192233]  ffffffffa04133e0 ffff880329334b30 0000000830884d58 00000000569c58cf
>    [ 1959.200521] Call Trace:
>    [ 1959.203248]  [<ffffffffa040f225>] dm_exception_store_create+0x1d5/0x240 [dm_snapshot]
>    [ 1959.211986]  [<ffffffffa040d310>] snapshot_ctr+0x140/0x630 [dm_snapshot]
>    [ 1959.219469]  [<ffffffffa0005c44>] ? dm_split_args+0x64/0x150 [dm_mod]
>    [ 1959.226656]  [<ffffffffa0005ea7>] dm_table_add_target+0x177/0x440 [dm_mod]
>    [ 1959.234328]  [<ffffffffa0009203>] table_load+0x143/0x370 [dm_mod]
>    [ 1959.241129]  [<ffffffffa00090c0>] ? retrieve_status+0x1b0/0x1b0 [dm_mod]
>    [ 1959.248607]  [<ffffffffa0009e35>] ctl_ioctl+0x255/0x4d0 [dm_mod]
>    [ 1959.255307]  [<ffffffff813304e2>] ? memzero_explicit+0x12/0x20
>    [ 1959.261816]  [<ffffffffa000a0c3>] dm_ctl_ioctl+0x13/0x20 [dm_mod]
>    [ 1959.268615]  [<ffffffff81215eb6>] do_vfs_ioctl+0xa6/0x5c0
>    [ 1959.274637]  [<ffffffff81120d2f>] ? __audit_syscall_entry+0xaf/0x100
>    [ 1959.281726]  [<ffffffff81003176>] ? do_audit_syscall_entry+0x66/0x70
>    [ 1959.288814]  [<ffffffff81216449>] SyS_ioctl+0x79/0x90
>    [ 1959.294450]  [<ffffffff8167e4ae>] entry_SYSCALL_64_fastpath+0x12/0x71
>    ...
>    [ 1959.323277] RIP  [<ffffffffa040efba>] dm_exception_store_set_chunk_size+0x7a/0x110 [dm_snapshot]
>    [ 1959.333090]  RSP <ffff88032a957b30>
>    [ 1959.336978] CR2: 0000000000000098
>    [ 1959.344121] ---[ end trace b049991ccad1169e ]---
>    
>    Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1195899
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Ding Xiang <dingxiang@huawei.com>
>    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8f82841376c2dc033b6b3f976cfb463678c8b80f
>Author: Arnd Bergmann <arnd@arndb.de>
>Date:   Wed Nov 18 15:25:23 2015 +0100
>
>    ASoC: samsung: pass DMA channels as pointers
>    
>    [ Upstream commit b9a1a743818ea3265abf98f9431623afa8c50c86 ]
>    
>    ARM64 allmodconfig produces a bunch of warnings when building the
>    samsung ASoC code:
>    
>    sound/soc/samsung/dmaengine.c: In function 'samsung_asoc_init_dma_data':
>    sound/soc/samsung/dmaengine.c:53:32: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
>       playback_data->filter_data = (void *)playback->channel;
>    sound/soc/samsung/dmaengine.c:60:31: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
>       capture_data->filter_data = (void *)capture->channel;
>    
>    We could easily shut up the warning by adding an intermediate cast,
>    but there is a bigger underlying problem: The use of IORESOURCE_DMA
>    to pass data from platform code to device drivers is dubious to start
>    with, as what we really want is a pointer that can be passed into
>    a filter function.
>    
>    Note that on s3c64xx, the pl08x DMA data is already a pointer, but
>    gets cast to resource_size_t so we can pass it as a resource, and it
>    then gets converted back to a pointer. In contrast, the data we pass
>    for s3c24xx is an index into a device specific table, and we artificially
>    convert that into a pointer for the filter function.
>    
>    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>    Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>    Signed-off-by: Mark Brown <broonie@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 85aa23b07fabe1d50a26968d07b0e040feb4007c
>Author: Krzysztof HaÅasa <khalasa@piap.pl>
>Date:   Tue Mar 1 07:07:18 2016 +0100
>
>    PCI: Allow a NULL "parent" pointer in pci_bus_assign_domain_nr()
>    
>    [ Upstream commit 54c6e2dd00c313d0add58e5befe62fe6f286d03b ]
>    
>    pci_create_root_bus() passes a "parent" pointer to
>    pci_bus_assign_domain_nr().  When CONFIG_PCI_DOMAINS_GENERIC is defined,
>    pci_bus_assign_domain_nr() dereferences that pointer.  Many callers of
>    pci_create_root_bus() supply a NULL "parent" pointer, which leads to a NULL
>    pointer dereference error.
>    
>    7c674700098c ("PCI: Move domain assignment from arm64 to generic code")
>    moved the "parent" dereference from arm64 to generic code.  Only arm64 used
>    that code (because only arm64 defined CONFIG_PCI_DOMAINS_GENERIC), and it
>    always supplied a valid "parent" pointer.  Other arches supplied NULL
>    "parent" pointers but didn't defined CONFIG_PCI_DOMAINS_GENERIC, so they
>    used a no-op version of pci_bus_assign_domain_nr().
>    
>    8c7d14746abc ("ARM/PCI: Move to generic PCI domains") defined
>    CONFIG_PCI_DOMAINS_GENERIC on ARM, and many ARM platforms use
>    pci_common_init(), which supplies a NULL "parent" pointer.
>    These platforms (cns3xxx, dove, footbridge, iop13xx, etc.) crash
>    with a NULL pointer dereference like this while probing PCI:
>    
>      Unable to handle kernel NULL pointer dereference at virtual address 000000a4
>      PC is at pci_bus_assign_domain_nr+0x10/0x84
>      LR is at pci_create_root_bus+0x48/0x2e4
>      Kernel panic - not syncing: Attempted to kill init!
>    
>    [bhelgaas: changelog, add "Reported:" and "Fixes:" tags]
>    Reported: http://forum.doozan.com/read.php?2,17868,22070,quote=1
>    Fixes: 8c7d14746abc ("ARM/PCI: Move to generic PCI domains")
>    Fixes: 7c674700098c ("PCI: Move domain assignment from arm64 to generic code")
>    Signed-off-by: Krzysztof HaÅasa <khalasa@piap.pl>
>    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>    Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>    CC: stable@vger.kernel.org	# v4.0+
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a1f678e55da552523dd45a531580a7e533b3bd8f
>Author: Miklos Szeredi <mszeredi@redhat.com>
>Date:   Fri Jul 1 14:56:07 2016 +0200
>
>    locks: use file_inode()
>    
>    [ Upstream commit 6343a2120862f7023006c8091ad95c1f16a32077 ]
>    
>    (Another one for the f_path debacle.)
>    
>    ltp fcntl33 testcase caused an Oops in selinux_file_send_sigiotask.
>    
>    The reason is that generic_add_lease() used filp->f_path.dentry->inode
>    while all the others use file_inode().  This makes a difference for files
>    opened on overlayfs since the former will point to the overlay inode the
>    latter to the underlying inode.
>    
>    So generic_add_lease() added the lease to the overlay inode and
>    generic_delete_lease() removed it from the underlying inode.  When the file
>    was released the lease remained on the overlay inode's lock list, resulting
>    in use after free.
>    
>    Reported-by: Eryu Guan <eguan@redhat.com>
>    Fixes: 4bacc9c9234c ("overlayfs: Make f_path always point to the overlay and f_inode to the underlay")
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
>    Reviewed-by: Jeff Layton <jlayton@redhat.com>
>    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2119a62b133e4b4ade51cbc446f31b728662eed8
>Author: Andrey Ulanov <andreyu@google.com>
>Date:   Fri Apr 15 14:24:41 2016 -0700
>
>    namespace: update event counter when umounting a deleted dentry
>    
>    [ Upstream commit e06b933e6ded42384164d28a2060b7f89243b895 ]
>    
>    - m_start() in fs/namespace.c expects that ns->event is incremented each
>      time a mount added or removed from ns->list.
>    - umount_tree() removes items from the list but does not increment event
>      counter, expecting that it's done before the function is called.
>    - There are some codepaths that call umount_tree() without updating
>      "event" counter. e.g. from __detach_mounts().
>    - When this happens m_start may reuse a cached mount structure that no
>      longer belongs to ns->list (i.e. use after free which usually leads
>      to infinite loop).
>    
>    This change fixes the above problem by incrementing global event counter
>    before invoking umount_tree().
>    
>    Change-Id: I622c8e84dcb9fb63542372c5dbf0178ee86bb589
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Andrey Ulanov <andreyu@google.com>
>    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4a883b820416683360258a08becad92d99f7fab1
>Author: Trond Myklebust <trond.myklebust@primarydata.com>
>Date:   Sat Jun 25 19:19:28 2016 -0400
>
>    NFS: Fix another OPEN_DOWNGRADE bug
>    
>    [ Upstream commit e547f2628327fec6afd2e03b46f113f614cca05b ]
>    
>    Olga Kornievskaia reports that the following test fails to trigger
>    an OPEN_DOWNGRADE on the wire, and only triggers the final CLOSE.
>    
>    	fd0 = open(foo, RDRW)   -- should be open on the wire for "both"
>    	fd1 = open(foo, RDONLY)  -- should be open on the wire for "read"
>    	close(fd0) -- should trigger an open_downgrade
>    	read(fd1)
>    	close(fd1)
>    
>    The issue is that we're missing a check for whether or not the current
>    state transitioned from an O_RDWR state as opposed to having transitioned
>    from a combination of O_RDONLY and O_WRONLY.
>    
>    Reported-by: Olga Kornievskaia <aglo@umich.edu>
>    Fixes: cd9288ffaea4 ("NFSv4: Fix another bug in the close/open_downgrade code")
>    Cc: stable@vger.kernel.org # 2.6.33+
>    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
>    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2bbd6a57310cd7dd8fd4c484e629bb5389b78d9b
>Author: Michael Holzheu <holzheu@linux.vnet.ibm.com>
>Date:   Mon Jun 13 17:03:48 2016 +0200
>
>    Revert "s390/kdump: Clear subchannel ID to signal non-CCW/SCSI IPL"
>    
>    [ Upstream commit 5419447e2142d6ed68c9f5c1a28630b3a290a845 ]
>    
>    This reverts commit 852ffd0f4e23248b47531058e531066a988434b5.
>    
>    There are use cases where an intermediate boot kernel (1) uses kexec
>    to boot the final production kernel (2). For this scenario we should
>    provide the original boot information to the production kernel (2).
>    Therefore clearing the boot information during kexec() should not
>    be done.
>    
>    Cc: stable@vger.kernel.org # v3.17+
>    Reported-by: Steffen Maier <maier@linux.vnet.ibm.com>
>    Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
>    Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
>    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 49cacd2b68d3dfc88bbf5cf16c885138ba947561
>Author: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
>Date:   Thu Jun 23 11:00:39 2016 +0300
>
>    arc: unwind: warn only once if DW2_UNWIND is disabled
>    
>    [ Upstream commit 9bd54517ee86cb164c734f72ea95aeba4804f10b ]
>    
>    If CONFIG_ARC_DW2_UNWIND is disabled every time arc_unwind_core()
>    gets called following message gets printed in debug console:
>    ----------------->8---------------
>    CONFIG_ARC_DW2_UNWIND needs to be enabled
>    ----------------->8---------------
>    
>    That message makes sense if user indeed wants to see a backtrace or
>    get nice function call-graphs in perf but what if user disabled
>    unwinder for the purpose? Why pollute his debug console?
>    
>    So instead we'll warn user about possibly missing feature once and
>    let him decide if that was what he or she really wanted.
>    
>    Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7678c949a43aefb98ac7e64d6b8b2c32ad442fc3
>Author: Vineet Gupta <vgupta@synopsys.com>
>Date:   Tue Jun 28 09:42:25 2016 +0530
>
>    ARC: unwind: ensure that .debug_frame is generated (vs. .eh_frame)
>    
>    [ Upstream commit f52e126cc7476196f44f3c313b7d9f0699a881fc ]
>    
>    With recent binutils update to support dwarf CFI pseudo-ops in gas, we
>    now get .eh_frame vs. .debug_frame. Although the call frame info is
>    exactly the same in both, the CIE differs, which the current kernel
>    unwinder can't cope with.
>    
>    This broke both the kernel unwinder as well as loadable modules (latter
>    because of a new unhandled relo R_ARC_32_PCREL from .rela.eh_frame in
>    the module loader)
>    
>    The ideal solution would be to switch unwinder to .eh_frame.
>    For now however we can make do by just ensureing .debug_frame is
>    generated by removing -fasynchronous-unwind-tables
>    
>     .eh_frame    generated with -gdwarf-2 -fasynchronous-unwind-tables
>     .debug_frame generated with -gdwarf-2
>    
>    Fixes STAR 9001058196
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7421921581dc77ffb4017ce747f95931f74a624b
>Author: Alan Stern <stern@rowland.harvard.edu>
>Date:   Mon Jun 27 10:23:10 2016 -0400
>
>    USB: don't free bandwidth_mutex too early
>    
>    [ Upstream commit ab2a4bf83902c170d29ba130a8abb5f9d90559e1 ]
>    
>    The USB core contains a bug that can show up when a USB-3 host
>    controller is removed.  If the primary (USB-2) hcd structure is
>    released before the shared (USB-3) hcd, the core will try to do a
>    double-free of the common bandwidth_mutex.
>    
>    The problem was described in graphical form by Chung-Geol Kim, who
>    first reported it:
>    
>    =================================================
>         At *remove USB(3.0) Storage
>         sequence <1> --> <5> ((Problem Case))
>    =================================================
>                                      VOLD
>    ------------------------------------|------------
>                                     (uevent)
>                                ________|_________
>                               |<1>               |
>                               |dwc3_otg_sm_work  |
>                               |usb_put_hcd       |
>                               |peer_hcd(kref=2)|
>                               |__________________|
>                                ________|_________
>                               |<2>               |
>                               |New USB BUS #2    |
>                               |                  |
>                               |peer_hcd(kref=1)  |
>                               |                  |
>                             --(Link)-bandXX_mutex|
>                             | |__________________|
>                             |
>        ___________________  |
>       |<3>                | |
>       |dwc3_otg_sm_work   | |
>       |usb_put_hcd        | |
>       |primary_hcd(kref=1)| |
>       |___________________| |
>        _________|_________  |
>       |<4>                | |
>       |New USB BUS #1     | |
>       |hcd_release        | |
>       |primary_hcd(kref=0)| |
>       |                   | |
>       |bandXX_mutex(free) |<-
>       |___________________|
>                                   (( VOLD ))
>                                ______|___________
>                               |<5>               |
>                               |      SCSI        |
>                               |usb_put_hcd       |
>                               |peer_hcd(kref=0)  |
>                               |*hcd_release      |
>                               |bandXX_mutex(free*)|<- double free
>                               |__________________|
>    
>    =================================================
>    
>    This happens because hcd_release() frees the bandwidth_mutex whenever
>    it sees a primary hcd being released (which is not a very good idea
>    in any case), but in the course of releasing the primary hcd, it
>    changes the pointers in the shared hcd in such a way that the shared
>    hcd will appear to be primary when it gets released.
>    
>    This patch fixes the problem by changing hcd_release() so that it
>    deallocates the bandwidth_mutex only when the _last_ hcd structure
>    referencing it is released.  The patch also removes an unnecessary
>    test, so that when an hcd is released, both the shared_hcd and
>    primary_hcd pointers in the hcd's peer will be cleared.
>    
>    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
>    Reported-by: Chung-Geol Kim <chunggeol.kim@samsung.com>
>    Tested-by: Chung-Geol Kim <chunggeol.kim@samsung.com>
>    CC: <stable@vger.kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3f3d3526c73a85950a3d963347b0de675fb3bea5
>Author: Al Viro <viro@ZenIV.linux.org.uk>
>Date:   Mon Jun 20 13:14:36 2016 -0400
>
>    make nfs_atomic_open() call d_drop() on all ->open_context() errors.
>    
>    [ Upstream commit d20cb71dbf3487f24549ede1a8e2d67579b4632e ]
>    
>    In "NFSv4: Move dentry instantiation into the NFSv4-specific atomic open code"
>    unconditional d_drop() after the ->open_context() had been removed.  It had
>    been correct for success cases (there ->open_context() itself had been doing
>    dcache manipulations), but not for error ones.  Only one of those (ENOENT)
>    got a compensatory d_drop() added in that commit, but in fact it should've
>    been done for all errors.  As it is, the case of O_CREAT non-exclusive open
>    on a hashed negative dentry racing with e.g. symlink creation from another
>    client ended up with ->open_context() getting an error and proceeding to
>    call nfs_lookup().  On a hashed dentry, which would've instantly triggered
>    BUG_ON() in d_materialise_unique() (or, these days, its equivalent in
>    d_splice_alias()).
>    
>    Cc: stable@vger.kernel.org # v3.10+
>    Tested-by: Oleg Drokin <green@linuxhacker.ru>
>    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
>    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
>    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d4b08964d00a0b99e999a2bb1ce417e54b5c607f
>Author: James Morse <james.morse@arm.com>
>Date:   Wed Jun 8 17:24:45 2016 +0100
>
>    KVM: arm/arm64: Stop leaking vcpu pid references
>    
>    [ Upstream commit 591d215afcc2f94e8e2c69a63c924c044677eb31 ]
>    
>    kvm provides kvm_vcpu_uninit(), which amongst other things, releases the
>    last reference to the struct pid of the task that was last running the vcpu.
>    
>    On arm64 built with CONFIG_DEBUG_KMEMLEAK, starting a guest with kvmtool,
>    then killing it with SIGKILL results (after some considerable time) in:
>    > cat /sys/kernel/debug/kmemleak
>    > unreferenced object 0xffff80007d5ea080 (size 128):
>    >  comm "lkvm", pid 2025, jiffies 4294942645 (age 1107.776s)
>    >  hex dump (first 32 bytes):
>    >    01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>    >    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>    >  backtrace:
>    >    [<ffff8000001b30ec>] create_object+0xfc/0x278
>    >    [<ffff80000071da34>] kmemleak_alloc+0x34/0x70
>    >    [<ffff80000019fa2c>] kmem_cache_alloc+0x16c/0x1d8
>    >    [<ffff8000000d0474>] alloc_pid+0x34/0x4d0
>    >    [<ffff8000000b5674>] copy_process.isra.6+0x79c/0x1338
>    >    [<ffff8000000b633c>] _do_fork+0x74/0x320
>    >    [<ffff8000000b66b0>] SyS_clone+0x18/0x20
>    >    [<ffff800000085cb0>] el0_svc_naked+0x24/0x28
>    >    [<ffffffffffffffff>] 0xffffffffffffffff
>    
>    On x86 kvm_vcpu_uninit() is called on the path from kvm_arch_destroy_vm(),
>    on arm no equivalent call is made. Add the call to kvm_arch_vcpu_free().
>    
>    Signed-off-by: James Morse <james.morse@arm.com>
>    Fixes: 749cf76c5a36 ("KVM: ARM: Initial skeleton to compile KVM support")
>    Cc: <stable@vger.kernel.org> # 3.10+
>    Acked-by: Marc Zyngier <marc.zyngier@arm.com>
>    Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 848be4770beb10fcc6f971c58e80aa2c2b6dad66
>Author: Cyril Bur <cyrilbur@gmail.com>
>Date:   Fri Jun 17 14:58:34 2016 +1000
>
>    powerpc/tm: Always reclaim in start_thread() for exec() class syscalls
>    
>    [ Upstream commit 8e96a87c5431c256feb65bcfc5aec92d9f7839b6 ]
>    
>    Userspace can quite legitimately perform an exec() syscall with a
>    suspended transaction. exec() does not return to the old process, rather
>    it load a new one and starts that, the expectation therefore is that the
>    new process starts not in a transaction. Currently exec() is not treated
>    any differently to any other syscall which creates problems.
>    
>    Firstly it could allow a new process to start with a suspended
>    transaction for a binary that no longer exists. This means that the
>    checkpointed state won't be valid and if the suspended transaction were
>    ever to be resumed and subsequently aborted (a possibility which is
>    exceedingly likely as exec()ing will likely doom the transaction) the
>    new process will jump to invalid state.
>    
>    Secondly the incorrect attempt to keep the transactional state while
>    still zeroing state for the new process creates at least two TM Bad
>    Things. The first triggers on the rfid to return to userspace as
>    start_thread() has given the new process a 'clean' MSR but the suspend
>    will still be set in the hardware MSR. The second TM Bad Thing triggers
>    in __switch_to() as the processor is still transactionally suspended but
>    __switch_to() wants to zero the TM sprs for the new process.
>    
>    This is an example of the outcome of calling exec() with a suspended
>    transaction. Note the first 700 is likely the first TM bad thing
>    decsribed earlier only the kernel can't report it as we've loaded
>    userspace registers. c000000000009980 is the rfid in
>    fast_exception_return()
>    
>      Bad kernel stack pointer 3fffcfa1a370 at c000000000009980
>      Oops: Bad kernel stack pointer, sig: 6 [#1]
>      CPU: 0 PID: 2006 Comm: tm-execed Not tainted
>      NIP: c000000000009980 LR: 0000000000000000 CTR: 0000000000000000
>      REGS: c00000003ffefd40 TRAP: 0700   Not tainted
>      MSR: 8000000300201031 <SF,ME,IR,DR,LE,TM[SE]>  CR: 00000000  XER: 00000000
>      CFAR: c0000000000098b4 SOFTE: 0
>      PACATMSCRATCH: b00000010000d033
>      GPR00: 0000000000000000 00003fffcfa1a370 0000000000000000 0000000000000000
>      GPR04: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>      GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>      GPR12: 00003fff966611c0 0000000000000000 0000000000000000 0000000000000000
>      NIP [c000000000009980] fast_exception_return+0xb0/0xb8
>      LR [0000000000000000]           (null)
>      Call Trace:
>      Instruction dump:
>      f84d0278 e9a100d8 7c7b03a6 e84101a0 7c4ff120 e8410170 7c5a03a6 e8010070
>      e8410080 e8610088 e8810090 e8210078 <4c000024> 48000000 e8610178 88ed023b
>    
>      Kernel BUG at c000000000043e80 [verbose debug info unavailable]
>      Unexpected TM Bad Thing exception at c000000000043e80 (msr 0x201033)
>      Oops: Unrecoverable exception, sig: 6 [#2]
>      CPU: 0 PID: 2006 Comm: tm-execed Tainted: G      D
>      task: c0000000fbea6d80 ti: c00000003ffec000 task.ti: c0000000fb7ec000
>      NIP: c000000000043e80 LR: c000000000015a24 CTR: 0000000000000000
>      REGS: c00000003ffef7e0 TRAP: 0700   Tainted: G      D
>      MSR: 8000000300201033 <SF,ME,IR,DR,RI,LE,TM[SE]>  CR: 28002828  XER: 00000000
>      CFAR: c000000000015a20 SOFTE: 0
>      PACATMSCRATCH: b00000010000d033
>      GPR00: 0000000000000000 c00000003ffefa60 c000000000db5500 c0000000fbead000
>      GPR04: 8000000300001033 2222222222222222 2222222222222222 00000000ff160000
>      GPR08: 0000000000000000 800000010000d033 c0000000fb7e3ea0 c00000000fe00004
>      GPR12: 0000000000002200 c00000000fe00000 0000000000000000 0000000000000000
>      GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>      GPR20: 0000000000000000 0000000000000000 c0000000fbea7410 00000000ff160000
>      GPR24: c0000000ffe1f600 c0000000fbea8700 c0000000fbea8700 c0000000fbead000
>      GPR28: c000000000e20198 c0000000fbea6d80 c0000000fbeab680 c0000000fbea6d80
>      NIP [c000000000043e80] tm_restore_sprs+0xc/0x1c
>      LR [c000000000015a24] __switch_to+0x1f4/0x420
>      Call Trace:
>      Instruction dump:
>      7c800164 4e800020 7c0022a6 f80304a8 7c0222a6 f80304b0 7c0122a6 f80304b8
>      4e800020 e80304a8 7c0023a6 e80304b0 <7c0223a6> e80304b8 7c0123a6 4e800020
>    
>    This fixes CVE-2016-5828.
>    
>    Fixes: bc2a9408fa65 ("powerpc: Hook in new transactional memory code")
>    Cc: stable@vger.kernel.org # v3.9+
>    Signed-off-by: Cyril Bur <cyrilbur@gmail.com>
>    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit cc6fd729b8a04fbb4b88e45209c1241dd89a3fbe
>Author: Torsten Hilbrich <torsten.hilbrich@secunet.com>
>Date:   Fri Jun 24 14:50:18 2016 -0700
>
>    fs/nilfs2: fix potential underflow in call to crc32_le
>    
>    [ Upstream commit 63d2f95d63396059200c391ca87161897b99e74a ]
>    
>    The value `bytes' comes from the filesystem which is about to be
>    mounted.  We cannot trust that the value is always in the range we
>    expect it to be.
>    
>    Check its value before using it to calculate the length for the crc32_le
>    call.  It value must be larger (or equal) sumoff + 4.
>    
>    This fixes a kernel bug when accidentially mounting an image file which
>    had the nilfs2 magic value 0x3434 at the right offset 0x406 by chance.
>    The bytes 0x01 0x00 were stored at 0x408 and were interpreted as a
>    s_bytes value of 1.  This caused an underflow when substracting sumoff +
>    4 (20) in the call to crc32_le.
>    
>      BUG: unable to handle kernel paging request at ffff88021e600000
>      IP:  crc32_le+0x36/0x100
>      ...
>      Call Trace:
>        nilfs_valid_sb.part.5+0x52/0x60 [nilfs2]
>        nilfs_load_super_block+0x142/0x300 [nilfs2]
>        init_nilfs+0x60/0x390 [nilfs2]
>        nilfs_mount+0x302/0x520 [nilfs2]
>        mount_fs+0x38/0x160
>        vfs_kern_mount+0x67/0x110
>        do_mount+0x269/0xe00
>        SyS_mount+0x9f/0x100
>        entry_SYSCALL_64_fastpath+0x16/0x71
>    
>    Link: http://lkml.kernel.org/r/1466778587-5184-2-git-send-email-konishi.ryusuke@lab.ntt.co.jp
>    Signed-off-by: Torsten Hilbrich <torsten.hilbrich@secunet.com>
>    Tested-by: Torsten Hilbrich <torsten.hilbrich@secunet.com>
>    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 284f69fb49e2e385203f52441b324b9a68461d6b
>Author: David Rientjes <rientjes@google.com>
>Date:   Fri Jun 24 14:50:10 2016 -0700
>
>    mm, compaction: abort free scanner if split fails
>    
>    [ Upstream commit a4f04f2c6955aff5e2c08dcb40aca247ff4d7370 ]
>    
>    If the memory compaction free scanner cannot successfully split a free
>    page (only possible due to per-zone low watermark), terminate the free
>    scanner rather than continuing to scan memory needlessly.  If the
>    watermark is insufficient for a free page of order <= cc->order, then
>    terminate the scanner since all future splits will also likely fail.
>    
>    This prevents the compaction freeing scanner from scanning all memory on
>    very large zones (very noticeable for zones > 128GB, for instance) when
>    all splits will likely fail while holding zone->lock.
>    
>    compaction_alloc() iterating a 128GB zone has been benchmarked to take
>    over 400ms on some systems whereas any free page isolated and ready to
>    be split ends up failing in split_free_page() because of the low
>    watermark check and thus the iteration continues.
>    
>    The next time compaction occurs, the freeing scanner will likely start
>    at the end of the zone again since no success was made previously and we
>    get the same lengthy iteration until the zone is brought above the low
>    watermark.  All thp page faults can take >400ms in such a state without
>    this fix.
>    
>    Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1606211820350.97086@chino.kir.corp.google.com
>    Signed-off-by: David Rientjes <rientjes@google.com>
>    Acked-by: Vlastimil Babka <vbabka@suse.cz>
>    Cc: Minchan Kim <minchan@kernel.org>
>    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
>    Cc: Mel Gorman <mgorman@techsingularity.net>
>    Cc: Hugh Dickins <hughd@google.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 683854270f84daa09baffe2b21d64ec88c614fa9
>Author: Vlastimil Babka <vbabka@suse.cz>
>Date:   Tue Sep 8 15:02:49 2015 -0700
>
>    mm, compaction: skip compound pages by order in free scanner
>    
>    [ Upstream commit 9fcd6d2e052eef525e94a9ae58dbe7ed4df4f5a7 ]
>    
>    The compaction free scanner is looking for PageBuddy() pages and
>    skipping all others.  For large compound pages such as THP or hugetlbfs,
>    we can save a lot of iterations if we skip them at once using their
>    compound_order().  This is generally unsafe and we can read a bogus
>    value of order due to a race, but if we are careful, the only danger is
>    skipping too much.
>    
>    When tested with stress-highalloc from mmtests on 4GB system with 1GB
>    hugetlbfs pages, the vmstat compact_free_scanned count decreased by at
>    least 15%.
>    
>    Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
>    Cc: Minchan Kim <minchan@kernel.org>
>    Cc: Mel Gorman <mgorman@suse.de>
>    Acked-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
>    Acked-by: Michal Nazarewicz <mina86@mina86.com>
>    Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
>    Cc: Christoph Lameter <cl@linux.com>
>    Cc: Rik van Riel <riel@redhat.com>
>    Cc: David Rientjes <rientjes@google.com>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c5ad33184354260be6d05de57e46a5498692f6d6
>Author: Lukasz Odzioba <lukasz.odzioba@intel.com>
>Date:   Fri Jun 24 14:50:01 2016 -0700
>
>    mm/swap.c: flush lru pvecs on compound page arrival
>    
>    [ Upstream commit 8f182270dfec432e93fae14f9208a6b9af01009f ]
>    
>    Currently we can have compound pages held on per cpu pagevecs, which
>    leads to a lot of memory unavailable for reclaim when needed.  In the
>    systems with hundreads of processors it can be GBs of memory.
>    
>    On of the way of reproducing the problem is to not call munmap
>    explicitly on all mapped regions (i.e.  after receiving SIGTERM).  After
>    that some pages (with THP enabled also huge pages) may end up on
>    lru_add_pvec, example below.
>    
>      void main() {
>      #pragma omp parallel
>      {
>    	size_t size = 55 * 1000 * 1000; // smaller than  MEM/CPUS
>    	void *p = mmap(NULL, size, PROT_READ | PROT_WRITE,
>    		MAP_PRIVATE | MAP_ANONYMOUS , -1, 0);
>    	if (p != MAP_FAILED)
>    		memset(p, 0, size);
>    	//munmap(p, size); // uncomment to make the problem go away
>      }
>      }
>    
>    When we run it with THP enabled it will leave significant amount of
>    memory on lru_add_pvec.  This memory will be not reclaimed if we hit
>    OOM, so when we run above program in a loop:
>    
>    	for i in `seq 100`; do ./a.out; done
>    
>    many processes (95% in my case) will be killed by OOM.
>    
>    The primary point of the LRU add cache is to save the zone lru_lock
>    contention with a hope that more pages will belong to the same zone and
>    so their addition can be batched.  The huge page is already a form of
>    batched addition (it will add 512 worth of memory in one go) so skipping
>    the batching seems like a safer option when compared to a potential
>    excess in the caching which can be quite large and much harder to fix
>    because lru_add_drain_all is way to expensive and it is not really clear
>    what would be a good moment to call it.
>    
>    Similarly we can reproduce the problem on lru_deactivate_pvec by adding:
>    madvise(p, size, MADV_FREE); after memset.
>    
>    This patch flushes lru pvecs on compound page arrival making the problem
>    less severe - after applying it kill rate of above example drops to 0%,
>    due to reducing maximum amount of memory held on pvec from 28MB (with
>    THP) to 56kB per CPU.
>    
>    Suggested-by: Michal Hocko <mhocko@suse.com>
>    Link: http://lkml.kernel.org/r/1466180198-18854-1-git-send-email-lukasz.odzioba@intel.com
>    Signed-off-by: Lukasz Odzioba <lukasz.odzioba@intel.com>
>    Acked-by: Michal Hocko <mhocko@suse.com>
>    Cc: Kirill Shutemov <kirill.shutemov@linux.intel.com>
>    Cc: Andrea Arcangeli <aarcange@redhat.com>
>    Cc: Vladimir Davydov <vdavydov@parallels.com>
>    Cc: Ming Li <mingli199x@qq.com>
>    Cc: Minchan Kim <minchan@kernel.org>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c5bcec6cbcbf520f088dc7939934bbf10c20c5a5
>Author: Anthony Romano <anthony.romano@coreos.com>
>Date:   Fri Jun 24 14:48:43 2016 -0700
>
>    tmpfs: don't undo fallocate past its last page
>    
>    [ Upstream commit b9b4bb26af017dbe930cd4df7f9b2fc3a0497bfe ]
>    
>    When fallocate is interrupted it will undo a range that extends one byte
>    past its range of allocated pages.  This can corrupt an in-use page by
>    zeroing out its first byte.  Instead, undo using the inclusive byte
>    range.
>    
>    Fixes: 1635f6a74152f1d ("tmpfs: undo fallocation on failure")
>    Link: http://lkml.kernel.org/r/1462713387-16724-1-git-send-email-anthony.romano@coreos.com
>    Signed-off-by: Anthony Romano <anthony.romano@coreos.com>
>    Cc: Vlastimil Babka <vbabka@suse.cz>
>    Cc: Hugh Dickins <hughd@google.com>
>    Cc: Brandon Philips <brandon@ifup.co>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7f3724b8951735ef1d5ae4f2846b8af98a665d73
>Author: Alan Stern <stern@rowland.harvard.edu>
>Date:   Thu Jun 23 14:54:37 2016 -0400
>
>    USB: EHCI: declare hostpc register as zero-length array
>    
>    [ Upstream commit 7e8b3dfef16375dbfeb1f36a83eb9f27117c51fd ]
>    
>    The HOSTPC extension registers found in some EHCI implementations form
>    a variable-length array, with one element for each port.  Therefore
>    the hostpc field in struct ehci_regs should be declared as a
>    zero-length array, not a single-element array.
>    
>    This fixes a problem reported by UBSAN.
>    
>    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
>    Reported-by: Wilfried Klaebe <linux-kernel@lebenslange-mailadresse.de>
>    Tested-by: Wilfried Klaebe <linux-kernel@lebenslange-mailadresse.de>
>    CC: <stable@vger.kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 655d8d195ad10e5bf3252eb7822136303d7c65fe
>Author: Steve French <smfrench@gmail.com>
>Date:   Wed Jun 22 21:07:32 2016 -0500
>
>    File names with trailing period or space need special case conversion
>    
>    [ Upstream commit 45e8a2583d97ca758a55c608f78c4cef562644d1 ]
>    
>    POSIX allows files with trailing spaces or a trailing period but
>    SMB3 does not, so convert these using the normal Services For Mac
>    mapping as we do for other reserved characters such as
>    	: < > | ? *
>    This is similar to what Macs do for the same problem over SMB3.
>    
>    CC: Stable <stable@vger.kernel.org>
>    Signed-off-by: Steve French <steve.french@primarydata.com>
>    Acked-by: Pavel Shilovsky <pshilovsky@samba.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e20c888e2b3576e5f498c167729d274ef60b86f8
>Author: Steve French <smfrench@gmail.com>
>Date:   Wed Jun 22 20:12:05 2016 -0500
>
>    Fix reconnect to not defer smb3 session reconnect long after socket reconnect
>    
>    [ Upstream commit 4fcd1813e6404dd4420c7d12fb483f9320f0bf93 ]
>    
>    Azure server blocks clients that open a socket and don't do anything on it.
>    In our reconnect scenarios, we can reconnect the tcp session and
>    detect the socket is available but we defer the negprot and SMB3 session
>    setup and tree connect reconnection until the next i/o is requested, but
>    this looks suspicous to some servers who expect SMB3 negprog and session
>    setup soon after a socket is created.
>    
>    In the echo thread, reconnect SMB3 sessions and tree connections
>    that are disconnected.  A later patch will replay persistent (and
>    resilient) handle opens.
>    
>    CC: Stable <stable@vger.kernel.org>
>    Signed-off-by: Steve French <steve.french@primarydata.com>
>    Acked-by: Pavel Shilovsky <pshilovsky@samba.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit eba391c749fe8a47aea9de2e78fadc02434b5417
>Author: Weston Andros Adamson <dros@monkey.org>
>Date:   Fri Jun 17 16:48:24 2016 -0400
>
>    pnfs_nfs: fix _cancel_empty_pagelist
>    
>    [ Upstream commit 5e3a98883e7ebdd1440f829a9e9dd5c3d2c5903b ]
>    
>    pnfs_generic_commit_cancel_empty_pagelist calls nfs_commitdata_release,
>    but that is wrong: nfs_commitdata_release puts the open context, something
>    that isn't valid until nfs_init_commit is called, which is never the case
>    when pnfs_generic_commit_cancel_empty_pagelist is called.
>    
>    This was introduced in "nfs: avoid race that crashes nfs_init_commit".
>    
>    Signed-off-by: Weston Andros Adamson <dros@primarydata.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
>    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 691c507ec01fa0cab2a9cfb5bd4398ddd5480a8a
>Author: Weston Andros Adamson <dros@monkey.org>
>Date:   Wed May 25 10:07:23 2016 -0400
>
>    nfs: avoid race that crashes nfs_init_commit
>    
>    [ Upstream commit ade8febde0271513360bac44883dbebad44276c3 ]
>    
>    Since the patch "NFS: Allow multiple commit requests in flight per file"
>    we can run multiple simultaneous commits on the same inode.  This
>    introduced a race over collecting pages to commit that made it possible
>    to call nfs_init_commit() with an empty list - which causes crashes like
>    the one below.
>    
>    The fix is to catch this race and avoid calling nfs_init_commit and
>    initiate_commit when there is no work to do.
>    
>    Here is the crash:
>    
>    [600522.076832] BUG: unable to handle kernel NULL pointer dereference at 0000000000000040
>    [600522.078475] IP: [<ffffffffa0479e72>] nfs_init_commit+0x22/0x130 [nfs]
>    [600522.078745] PGD 4272b1067 PUD 4272cb067 PMD 0
>    [600522.078972] Oops: 0000 [#1] SMP
>    [600522.079204] Modules linked in: nfsv3 nfs_layout_flexfiles rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache dcdbas ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw vmw_vsock_vmci_transport vsock bonding ipmi_devintf ipmi_msghandler coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel ppdev vmw_balloon parport_pc parport acpi_cpufreq vmw_vmci i2c_piix4 shpchp nfsd auth_rpcgss nfs_acl lockd grace sunrpc xfs libcrc32c vmwgfx drm_kms_helper ttm drm crc32c_intel serio_raw vmxnet3
>    [600522.081380]  vmw_pvscsi ata_generic pata_acpi
>    [600522.081809] CPU: 3 PID: 15667 Comm: /usr/bin/python Not tainted 4.1.9-100.pd.88.el7.x86_64 #1
>    [600522.082281] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 09/30/2014
>    [600522.082814] task: ffff8800bbbfa780 ti: ffff88042ae84000 task.ti: ffff88042ae84000
>    [600522.083378] RIP: 0010:[<ffffffffa0479e72>]  [<ffffffffa0479e72>] nfs_init_commit+0x22/0x130 [nfs]
>    [600522.083973] RSP: 0018:ffff88042ae87438  EFLAGS: 00010246
>    [600522.084571] RAX: 0000000000000000 RBX: ffff880003485e40 RCX: ffff88042ae87588
>    [600522.085188] RDX: 0000000000000000 RSI: ffff88042ae874b0 RDI: ffff880003485e40
>    [600522.085756] RBP: ffff88042ae87448 R08: ffff880003486010 R09: ffff88042ae874b0
>    [600522.086332] R10: 0000000000000000 R11: 0000000000000005 R12: ffff88042ae872d0
>    [600522.086905] R13: ffff88042ae874b0 R14: ffff880003485e40 R15: ffff88042704c840
>    [600522.087484] FS:  00007f4728ff2740(0000) GS:ffff88043fd80000(0000) knlGS:0000000000000000
>    [600522.088070] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>    [600522.088663] CR2: 0000000000000040 CR3: 000000042b6aa000 CR4: 00000000001406e0
>    [600522.089327] Stack:
>    [600522.089926]  0000000000000001 ffff88042ae87588 ffff88042ae874f8 ffffffffa04f09fa
>    [600522.090549]  0000000000017840 0000000000017840 ffff88042ae87588 ffff8803258d9930
>    [600522.091169]  ffff88042ae87578 ffffffffa0563d80 0000000000000000 ffff88042704c840
>    [600522.091789] Call Trace:
>    [600522.092420]  [<ffffffffa04f09fa>] pnfs_generic_commit_pagelist+0x1da/0x320 [nfsv4]
>    [600522.093052]  [<ffffffffa0563d80>] ? ff_layout_commit_prepare_v3+0x30/0x30 [nfs_layout_flexfiles]
>    [600522.093696]  [<ffffffffa0562645>] ff_layout_commit_pagelist+0x15/0x20 [nfs_layout_flexfiles]
>    [600522.094359]  [<ffffffffa047bc78>] nfs_generic_commit_list+0xe8/0x120 [nfs]
>    [600522.095032]  [<ffffffffa047bd6a>] nfs_commit_inode+0xba/0x110 [nfs]
>    [600522.095719]  [<ffffffffa046ac54>] nfs_release_page+0x44/0xd0 [nfs]
>    [600522.096410]  [<ffffffff811a8122>] try_to_release_page+0x32/0x50
>    [600522.097109]  [<ffffffff811bd4f1>] shrink_page_list+0x961/0xb30
>    [600522.097812]  [<ffffffff811bdced>] shrink_inactive_list+0x1cd/0x550
>    [600522.098530]  [<ffffffff811bea65>] shrink_lruvec+0x635/0x840
>    [600522.099250]  [<ffffffff811bed60>] shrink_zone+0xf0/0x2f0
>    [600522.099974]  [<ffffffff811bf312>] do_try_to_free_pages+0x192/0x470
>    [600522.100709]  [<ffffffff811bf6ca>] try_to_free_pages+0xda/0x170
>    [600522.101464]  [<ffffffff811b2198>] __alloc_pages_nodemask+0x588/0x970
>    [600522.102235]  [<ffffffff811fbbd5>] alloc_pages_vma+0xb5/0x230
>    [600522.103000]  [<ffffffff813a1589>] ? cpumask_any_but+0x39/0x50
>    [600522.103774]  [<ffffffff811d6115>] wp_page_copy.isra.55+0x95/0x490
>    [600522.104558]  [<ffffffff810e3438>] ? __wake_up+0x48/0x60
>    [600522.105357]  [<ffffffff811d7d3b>] do_wp_page+0xab/0x4f0
>    [600522.106137]  [<ffffffff810a1bbb>] ? release_task+0x36b/0x470
>    [600522.106902]  [<ffffffff8126dbd7>] ? eventfd_ctx_read+0x67/0x1c0
>    [600522.107659]  [<ffffffff811da2a8>] handle_mm_fault+0xc78/0x1900
>    [600522.108431]  [<ffffffff81067ef1>] __do_page_fault+0x181/0x420
>    [600522.109173]  [<ffffffff811446a6>] ? __audit_syscall_exit+0x1e6/0x280
>    [600522.109893]  [<ffffffff810681c0>] do_page_fault+0x30/0x80
>    [600522.110594]  [<ffffffff81024f36>] ? syscall_trace_leave+0xc6/0x120
>    [600522.111288]  [<ffffffff81790a58>] page_fault+0x28/0x30
>    [600522.111947] Code: 5d c3 0f 1f 80 00 00 00 00 0f 1f 44 00 00 55 4c 8d 87 d0 01 00 00 48 89 e5 53 48 89 fb 48 83 ec 08 4c 8b 0e 49 8b 41 18 4c 39 ce <48> 8b 40 40 4c 8b 50 30 74 24 48 8b 87 d0 01 00 00 48 8b 7e 08
>    [600522.113343] RIP  [<ffffffffa0479e72>] nfs_init_commit+0x22/0x130 [nfs]
>    [600522.114003]  RSP <ffff88042ae87438>
>    [600522.114636] CR2: 0000000000000040
>    
>    Fixes: af7cf057 (NFS: Allow multiple commit requests in flight per file)
>    CC: stable@vger.kernel.org
>    Signed-off-by: Weston Andros Adamson <dros@primarydata.com>
>    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 94d06a437eb0ad1a492ed75f929d82715b6c05f8
>Author: Trond Myklebust <trond.myklebust@primarydata.com>
>Date:   Mon Aug 3 17:38:33 2015 -0400
>
>    pNFS: Tighten up locking around DS commit buckets
>    
>    [ Upstream commit 27571297a7e9a2a845c232813a7ba7e1227f5ec6 ]
>    
>    I'm not aware of any bugreports around this issue, but the locking
>    around the pnfs_commit_bucket is inconsistent at best. This patch
>    tightens it up by ensuring that the 'bucket->committing' list is always
>    changed atomically w.r.t. the 'bucket->clseg' layout segment tracking.
>    
>    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1ff20a560eba527ba652502a2da1cd431e1e2fea
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Fri Jun 24 15:15:26 2016 +0200
>
>    ALSA: dummy: Fix a use-after-free at closing
>    
>    [ Upstream commit d5dbbe6569481bf12dcbe3e12cff72c5f78d272c ]
>    
>    syzkaller fuzzer spotted a potential use-after-free case in snd-dummy
>    driver when hrtimer is used as backend:
>    > ==================================================================
>    > BUG: KASAN: use-after-free in rb_erase+0x1b17/0x2010 at addr ffff88005e5b6f68
>    >  Read of size 8 by task syz-executor/8984
>    > =============================================================================
>    > BUG kmalloc-192 (Not tainted): kasan: bad access detected
>    > -----------------------------------------------------------------------------
>    >
>    > Disabling lock debugging due to kernel taint
>    > INFO: Allocated in 0xbbbbbbbbbbbbbbbb age=18446705582212484632
>    > ....
>    > [<      none      >] dummy_hrtimer_create+0x49/0x1a0 sound/drivers/dummy.c:464
>    > ....
>    > INFO: Freed in 0xfffd8e09 age=18446705496313138713 cpu=2164287125 pid=-1
>    > [<      none      >] dummy_hrtimer_free+0x68/0x80 sound/drivers/dummy.c:481
>    > ....
>    > Call Trace:
>    >  [<ffffffff8179e59e>] __asan_report_load8_noabort+0x3e/0x40 mm/kasan/report.c:333
>    >  [<     inline     >] rb_set_parent include/linux/rbtree_augmented.h:111
>    >  [<     inline     >] __rb_erase_augmented include/linux/rbtree_augmented.h:218
>    >  [<ffffffff82ca5787>] rb_erase+0x1b17/0x2010 lib/rbtree.c:427
>    >  [<ffffffff82cb02e8>] timerqueue_del+0x78/0x170 lib/timerqueue.c:86
>    >  [<ffffffff814d0c80>] __remove_hrtimer+0x90/0x220 kernel/time/hrtimer.c:903
>    >  [<     inline     >] remove_hrtimer kernel/time/hrtimer.c:945
>    >  [<ffffffff814d23da>] hrtimer_try_to_cancel+0x22a/0x570 kernel/time/hrtimer.c:1046
>    >  [<ffffffff814d2742>] hrtimer_cancel+0x22/0x40 kernel/time/hrtimer.c:1066
>    >  [<ffffffff85420531>] dummy_hrtimer_stop+0x91/0xb0 sound/drivers/dummy.c:417
>    >  [<ffffffff854228bf>] dummy_pcm_trigger+0x17f/0x1e0 sound/drivers/dummy.c:507
>    >  [<ffffffff85392170>] snd_pcm_do_stop+0x160/0x1b0 sound/core/pcm_native.c:1106
>    >  [<ffffffff85391b26>] snd_pcm_action_single+0x76/0x120 sound/core/pcm_native.c:956
>    >  [<ffffffff85391e01>] snd_pcm_action+0x231/0x290 sound/core/pcm_native.c:974
>    >  [<     inline     >] snd_pcm_stop sound/core/pcm_native.c:1139
>    >  [<ffffffff8539754d>] snd_pcm_drop+0x12d/0x1d0 sound/core/pcm_native.c:1784
>    >  [<ffffffff8539d3be>] snd_pcm_common_ioctl1+0xfae/0x2150 sound/core/pcm_native.c:2805
>    >  [<ffffffff8539ee91>] snd_pcm_capture_ioctl1+0x2a1/0x5e0 sound/core/pcm_native.c:2976
>    >  [<ffffffff8539f2ec>] snd_pcm_kernel_ioctl+0x11c/0x160 sound/core/pcm_native.c:3020
>    >  [<ffffffff853d9a44>] snd_pcm_oss_sync+0x3a4/0xa30 sound/core/oss/pcm_oss.c:1693
>    >  [<ffffffff853da27d>] snd_pcm_oss_release+0x1ad/0x280 sound/core/oss/pcm_oss.c:2483
>    >  .....
>    
>    A workaround is to call hrtimer_cancel() in dummy_hrtimer_sync() which
>    is called certainly before other blocking ops.
>    
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Tested-by: Dmitry Vyukov <dvyukov@google.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9bbe4e5d2bfb5a94cc40e75969df16f3cdf85927
>Author: Jaroslav Kysela <perex@perex.cz>
>Date:   Fri Jun 24 15:13:16 2016 +0200
>
>    ALSA: hda / realtek - add two more Thinkpad IDs (5050,5053) for tpt460 fixup
>    
>    [ Upstream commit 0f087ee3f3b86a4507db4ff1d2d5a3880e4cfd16 ]
>    
>      See: https://bugzilla.redhat.com/show_bug.cgi?id=1349539
>      See: https://bugzilla.kernel.org/show_bug.cgi?id=120961
>    
>    Signed-off-by: Jaroslav Kysela <perex@perex.cz>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 65f6fab102a9da8bbaf9e9fed3a8dec76f120636
>Author: Hui Wang <hui.wang@canonical.com>
>Date:   Wed Jul 22 10:33:34 2015 +0800
>
>    ALSA: hda - remove one pin from ALC292_STANDARD_PINS
>    
>    [ Upstream commit 21e9d017b88ea0baa367ef0b6516d794fa23e85e ]
>    
>    One more Dell laptop with alc293 codec needs
>    ALC293_FIXUP_DELL1_MIC_NO_PRESENCE, but the pin 0x1e does not match
>    the corresponding one in the ALC292_STANDARD_PINS. To use this macro
>    for this machine, we need to remove pin 0x1e from it.
>    
>    BugLink: https://bugs.launchpad.net/bugs/1476888
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Hui Wang <hui.wang@canonical.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f67b6920a0cf03d363c5f3bfb14f5d258168dc8c
>Author: Scott Bauer <sbauer@plzdonthack.me>
>Date:   Thu Jun 23 08:59:47 2016 -0600
>
>    HID: hiddev: validate num_values for HIDIOCGUSAGES, HIDIOCSUSAGES commands
>    
>    [ Upstream commit 93a2001bdfd5376c3dc2158653034c20392d15c5 ]
>    
>    This patch validates the num_values parameter from userland during the
>    HIDIOCGUSAGES and HIDIOCSUSAGES commands. Previously, if the report id was set
>    to HID_REPORT_ID_UNKNOWN, we would fail to validate the num_values parameter
>    leading to a heap overflow.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Scott Bauer <sbauer@plzdonthack.me>
>    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 32dc059d132c7fb4f45a7aeab70e08d2a47ed90d
>Author: Jerome Marchand <jmarchan@redhat.com>
>Date:   Thu May 26 11:52:25 2016 +0200
>
>    cifs: dynamic allocation of ntlmssp blob
>    
>    [ Upstream commit b8da344b74c822e966c6d19d6b2321efe82c5d97 ]
>    
>    In sess_auth_rawntlmssp_authenticate(), the ntlmssp blob is allocated
>    statically and its size is an "empirical" 5*sizeof(struct
>    _AUTHENTICATE_MESSAGE) (320B on x86_64). I don't know where this value
>    comes from or if it was ever appropriate, but it is currently
>    insufficient: the user and domain name in UTF16 could take 1kB by
>    themselves. Because of that, build_ntlmssp_auth_blob() might corrupt
>    memory (out-of-bounds write). The size of ntlmssp_blob in
>    SMB2_sess_setup() is too small too (sizeof(struct _NEGOTIATE_MESSAGE)
>    + 500).
>    
>    This patch allocates the blob dynamically in
>    build_ntlmssp_auth_blob().
>    
>    Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
>    Signed-off-by: Steve French <smfrench@gmail.com>
>    CC: Stable <stable@vger.kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 60243e6760bb680c9c6c6d5676a0669c44890c74
>Author: Sinclair Yeh <syeh@vmware.com>
>Date:   Thu Jun 23 17:37:34 2016 -0700
>
>    Input: vmmouse - remove port reservation
>    
>    [ Upstream commit 60842ef8128e7bf58c024814cd0dc14319232b6c ]
>    
>    The VMWare EFI BIOS will expose port 0x5658 as an ACPI resource.  This
>    causes the port to be reserved by the APCI module as the system comes up,
>    making it unavailable to be reserved again by other drivers, thus
>    preserving this VMWare port for special use in a VMWare guest.
>    
>    This port is designed to be shared among multiple VMWare services, such as
>    the VMMOUSE.  Because of this, VMMOUSE should not try to reserve this port
>    on its own.
>    
>    The VMWare non-EFI BIOS does not do this to preserve compatibility with
>    existing/legacy VMs.  It is known that there is small chance a VM may be
>    configured such that these ports get reserved by other non-VMWare devices,
>    and if this ever happens, the result is undefined.
>    
>    Signed-off-by: Sinclair Yeh <syeh@vmware.com>
>    Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
>    Cc: <stable@vger.kernel.org> # 4.1-
>    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6a2f15857e4debf46d34fd897e9d3eaf70590e33
>Author: Dmitrii Tcvetkov <demfloro@demfloro.ru>
>Date:   Mon Jun 20 13:52:14 2016 +0300
>
>    drm/nouveau: fix for disabled fbdev emulation
>    
>    [ Upstream commit 52dfcc5ccfbb6697ac3cac7f7ff1e712760e1216 ]
>    
>    Hello,
>    
>    after this commit:
>    
>    commit f045f459d925138fe7d6193a8c86406bda7e49da
>    Author: Ben Skeggs <bskeggs@redhat.com>
>    Date:   Thu Jun 2 12:23:31 2016 +1000
>        drm/nouveau/fbcon: fix out-of-bounds memory accesses
>    
>    kernel started to oops when loading nouveau module when using GTX 780 Ti
>    video adapter. This patch fixes the problem.
>    
>    Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=120591
>    
>    Signed-off-by: Dmitrii Tcvetkov <demfloro@demfloro.ru>
>    Suggested-by: Ilia Mirkin <imirkin@alum.mit.edu>
>    Fixes: f045f459d925 ("nouveau_fbcon_init()")
>    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 97e2a92930008f6087b6d59f761277f0839b30be
>Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>Date:   Tue Jun 21 16:09:00 2016 -0700
>
>    Input: elantech - add more IC body types to the list
>    
>    [ Upstream commit 226ba707744a51acb4244724e09caacb1d96aed9 ]
>    
>    The touchpad in HP Pavilion 14-ab057ca reports it's version as 12 and
>    according to Elan both 11 and 12 are valid IC types and should be
>    identified as hw_version 4.
>    
>    Reported-by: Patrick Lessard <Patrick.Lessard@cogeco.com>
>    Tested-by: Patrick Lessard <Patrick.Lessard@cogeco.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 37d925d2750f0efcbdc04e17d6bc46d3c82dc214
>Author: Ping Cheng <pinglinux@gmail.com>
>Date:   Thu Jun 23 10:54:17 2016 -0700
>
>    Input: wacom_w8001 - w8001_MAX_LENGTH should be 13
>    
>    [ Upstream commit 12afb34400eb2b301f06b2aa3535497d14faee59 ]
>    
>    Somehow the patch that added two-finger touch support forgot to update
>    W8001_MAX_LENGTH from 11 to 13.
>    
>    Signed-off-by: Ping Cheng <pingc@wacom.com>
>    Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 90a12c571f30254108126ee82ca7f4179e934b33
>Author: Andrey Grodzovsky <andrey2805@gmail.com>
>Date:   Tue Jun 21 14:26:36 2016 -0400
>
>    xen/pciback: Fix conf_space read/write overlap check.
>    
>    [ Upstream commit 02ef871ecac290919ea0c783d05da7eedeffc10e ]
>    
>    Current overlap check is evaluating to false a case where a filter
>    field is fully contained (proper subset) of a r/w request.  This
>    change applies classical overlap check instead to include all the
>    scenarios.
>    
>    More specifically, for (Hilscher GmbH CIFX 50E-DP(M/S)) device driver
>    the logic is such that the entire confspace is read and written in 4
>    byte chunks. In this case as an example, CACHE_LINE_SIZE,
>    LATENCY_TIMER and PCI_BIST are arriving together in one call to
>    xen_pcibk_config_write() with offset == 0xc and size == 4.  With the
>    exsisting overlap check the LATENCY_TIMER field (offset == 0xd, length
>    == 1) is fully contained in the write request and hence is excluded
>    from write, which is incorrect.
>    
>    Signed-off-by: Andrey Grodzovsky <andrey2805@gmail.com>
>    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>    Reviewed-by: Jan Beulich <JBeulich@suse.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 760102cd663d7a2f952177942f0cf44bbb06320d
>Author: Oliver Hartkopp <socketcan@hartkopp.net>
>Date:   Tue Jun 21 15:45:47 2016 +0200
>
>    can: fix oops caused by wrong rtnl dellink usage
>    
>    [ Upstream commit 25e1ed6e64f52a692ba3191c4fde650aab3ecc07 ]
>    
>    For 'real' hardware CAN devices the netlink interface is used to set CAN
>    specific communication parameters. Real CAN hardware can not be created nor
>    removed with the ip tool ...
>    
>    This patch adds a private dellink function for the CAN device driver interface
>    that does just nothing.
>    
>    It's a follow up to commit 993e6f2fd ("can: fix oops caused by wrong rtnl
>    newlink usage") but for dellink.
>    
>    Reported-by: ajneu <ajneu1@gmail.com>
>    Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 488ba7c5a08649e4f05075a8237135b2ae4c37b4
>Author: Oliver Hartkopp <socketcan@hartkopp.net>
>Date:   Tue Jun 21 12:14:07 2016 +0200
>
>    can: fix handling of unmodifiable configuration options fix
>    
>    [ Upstream commit bce271f255dae8335dc4d2ee2c4531e09cc67f5a ]
>    
>    With upstream commit bb208f144cf3f59 (can: fix handling of unmodifiable
>    configuration options) a new can_validate() function was introduced.
>    
>    When invoking 'ip link set can0 type can' without any configuration data
>    can_validate() tries to validate the content without taking into account that
>    there's totally no content. This patch adds a check for missing content.
>    
>    Reported-by: ajneu <ajneu1@gmail.com>
>    Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f3d1ae6f55fd1c9bedb26fd742693f629facd01a
>Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>Date:   Thu Jun 16 23:26:15 2016 +0200
>
>    UBIFS: Implement ->migratepage()
>    
>    [ Upstream commit 4ac1c17b2044a1b4b2fbed74451947e905fc2992 ]
>    
>    During page migrations UBIFS might get confused
>    and the following assert triggers:
>    [  213.480000] UBIFS assert failed in ubifs_set_page_dirty at 1451 (pid 436)
>    [  213.490000] CPU: 0 PID: 436 Comm: drm-stress-test Not tainted 4.4.4-00176-geaa802524636-dirty #1008
>    [  213.490000] Hardware name: Allwinner sun4i/sun5i Families
>    [  213.490000] [<c0015e70>] (unwind_backtrace) from [<c0012cdc>] (show_stack+0x10/0x14)
>    [  213.490000] [<c0012cdc>] (show_stack) from [<c02ad834>] (dump_stack+0x8c/0xa0)
>    [  213.490000] [<c02ad834>] (dump_stack) from [<c0236ee8>] (ubifs_set_page_dirty+0x44/0x50)
>    [  213.490000] [<c0236ee8>] (ubifs_set_page_dirty) from [<c00fa0bc>] (try_to_unmap_one+0x10c/0x3a8)
>    [  213.490000] [<c00fa0bc>] (try_to_unmap_one) from [<c00fadb4>] (rmap_walk+0xb4/0x290)
>    [  213.490000] [<c00fadb4>] (rmap_walk) from [<c00fb1bc>] (try_to_unmap+0x64/0x80)
>    [  213.490000] [<c00fb1bc>] (try_to_unmap) from [<c010dc28>] (migrate_pages+0x328/0x7a0)
>    [  213.490000] [<c010dc28>] (migrate_pages) from [<c00d0cb0>] (alloc_contig_range+0x168/0x2f4)
>    [  213.490000] [<c00d0cb0>] (alloc_contig_range) from [<c010ec00>] (cma_alloc+0x170/0x2c0)
>    [  213.490000] [<c010ec00>] (cma_alloc) from [<c001a958>] (__alloc_from_contiguous+0x38/0xd8)
>    [  213.490000] [<c001a958>] (__alloc_from_contiguous) from [<c001ad44>] (__dma_alloc+0x23c/0x274)
>    [  213.490000] [<c001ad44>] (__dma_alloc) from [<c001ae08>] (arm_dma_alloc+0x54/0x5c)
>    [  213.490000] [<c001ae08>] (arm_dma_alloc) from [<c035cecc>] (drm_gem_cma_create+0xb8/0xf0)
>    [  213.490000] [<c035cecc>] (drm_gem_cma_create) from [<c035cf20>] (drm_gem_cma_create_with_handle+0x1c/0xe8)
>    [  213.490000] [<c035cf20>] (drm_gem_cma_create_with_handle) from [<c035d088>] (drm_gem_cma_dumb_create+0x3c/0x48)
>    [  213.490000] [<c035d088>] (drm_gem_cma_dumb_create) from [<c0341ed8>] (drm_ioctl+0x12c/0x444)
>    [  213.490000] [<c0341ed8>] (drm_ioctl) from [<c0121adc>] (do_vfs_ioctl+0x3f4/0x614)
>    [  213.490000] [<c0121adc>] (do_vfs_ioctl) from [<c0121d30>] (SyS_ioctl+0x34/0x5c)
>    [  213.490000] [<c0121d30>] (SyS_ioctl) from [<c000f2c0>] (ret_fast_syscall+0x0/0x34)
>    
>    UBIFS is using PagePrivate() which can have different meanings across
>    filesystems. Therefore the generic page migration code cannot handle this
>    case correctly.
>    We have to implement our own migration function which basically does a
>    plain copy but also duplicates the page private flag.
>    UBIFS is not a block device filesystem and cannot use buffer_migrate_page().
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>    [rw: Massaged changelog, build fixes, etc...]
>    Signed-off-by: Richard Weinberger <richard@nod.at>
>    Acked-by: Christoph Hellwig <hch@lst.de>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a13b0f0a244b15e576f6edf4ffb9ce41ea6f3837
>Author: Richard Weinberger <richard@nod.at>
>Date:   Thu Jun 16 23:26:14 2016 +0200
>
>    mm: Export migrate_page_move_mapping and migrate_page_copy
>    
>    [ Upstream commit 1118dce773d84f39ebd51a9fe7261f9169cb056e ]
>    
>    Export these symbols such that UBIFS can implement
>    ->migratepage.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Richard Weinberger <richard@nod.at>
>    Acked-by: Christoph Hellwig <hch@lst.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 59523335cd4ae9e0b3359ce6577afea1fff9524d
>Author: Richard Weinberger <richard@nod.at>
>Date:   Tue Jun 21 00:31:50 2016 +0200
>
>    ubi: Make recover_peb power cut aware
>    
>    [ Upstream commit 972228d87445dc46c0a01f5f3de673ac017626f7 ]
>    
>    recover_peb() was never power cut aware,
>    if a power cut happened right after writing the VID header
>    upon next attach UBI would blindly use the new partial written
>    PEB and all data from the old PEB is lost.
>    
>    In order to make recover_peb() power cut aware, write the new
>    VID with a proper crc and copy_flag set such that the UBI attach
>    process will detect whether the new PEB is completely written
>    or not.
>    We cannot directly use ubi_eba_atomic_leb_change() since we'd
>    have to unlock the LEB which is facing a write error.
>    
>    Cc: stable@vger.kernel.org
>    Reported-by: JÃ¶rg PfÃ¤hler <pfaehler@isse.de>
>    Reviewed-by: JÃ¶rg PfÃ¤hler <pfaehler@isse.de>
>    Signed-off-by: Richard Weinberger <richard@nod.at>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0e16f4fb69810c58bdf142dd85ee92e46576b877
>Author: Tony Lindgren <tony@atomide.com>
>Date:   Tue May 31 14:17:06 2016 -0700
>
>    pinctrl: single: Fix missing flush of posted write for a wakeirq
>    
>    [ Upstream commit 0ac3c0a4025f41748a083bdd4970cb3ede802b15 ]
>    
>    With many repeated suspend resume cycles, the pin specific wakeirq
>    may not always work on omaps. This is because the write to enable the
>    pin interrupt may not have reached the device over the interconnect
>    before suspend happens.
>    
>    Let's fix the issue with a flush of posted write with a readback.
>    
>    Cc: stable@vger.kernel.org
>    Reported-by: Nishanth Menon <nm@ti.com>
>    Signed-off-by: Tony Lindgren <tony@atomide.com>
>    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 65c68fd8c1c79178d17217fb045b80badecdd472
>Author: Alexander Shiyan <shc_work@mail.ru>
>Date:   Wed Jun 1 22:21:53 2016 +0300
>
>    pinctrl: imx: Do not treat a PIN without MUX register as an error
>    
>    [ Upstream commit ba562d5e54fd3136bfea0457add3675850247774 ]
>    
>    Some PINs do not have a MUX register, it is not an error.
>    It is necessary to allow the continuation of the PINs configuration,
>    otherwise the whole PIN-group will be configured incorrectly.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
>    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 32bab0754d80dc086111d93bdc8ce39cf37c9eb9
>Author: Shaokun Zhang <zhangshaokun@hisilicon.com>
>Date:   Tue Jun 21 15:32:57 2016 +0800
>
>    arm64: mm: remove page_mapping check in __sync_icache_dcache
>    
>    [ Upstream commit 20c27a4270c775d7ed661491af8ac03264d60fc6 ]
>    
>    __sync_icache_dcache unconditionally skips the cache maintenance for
>    anonymous pages, under the assumption that flushing is only required in
>    the presence of D-side aliases [see 7249b79f6b4cc ("arm64: Do not flush
>    the D-cache for anonymous pages")].
>    
>    Unfortunately, this breaks migration of anonymous pages holding
>    self-modifying code, where userspace cannot be reasonably expected to
>    reissue maintenance instructions in response to a migration.
>    
>    This patch fixes the problem by removing the broken page_mapping(page)
>    check from the cache syncing code, otherwise we may end up fetching and
>    executing stale instructions from the PoU.
>    
>    Cc: Catalin Marinas <catalin.marinas@arm.com>
>    Cc: Will Deacon <will.deacon@arm.com>
>    Cc: Mark Rutland <mark.rutland@arm.com>
>    Cc: <stable@vger.kernel.org>
>    Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
>    Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com>
>    Signed-off-by: Will Deacon <will.deacon@arm.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 78016458e6bc8d2e3a352be3e7d879ab43a233e6
>Author: Boris Brezillon <boris.brezillon@free-electrons.com>
>Date:   Fri May 27 16:09:25 2016 +0200
>
>    drm: atmel-hlcdc: actually disable scaling when no scaling is required
>    
>    [ Upstream commit 1b7e38b92b0bbd363369f5160f13f4d26140972d ]
>    
>    The driver is only enabling scaling, but never disabling it, thus, if you
>    enable the scaling feature once it stays enabled forever.
>    
>    Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
>    Reported-by: Alex Vazquez <avazquez.dev@gmail.com>
>    Reviewed-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>    Fixes: 1a396789f65a ("drm: add Atmel HLCDC Display Controller support")
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 335f166ee3341efcf402c46ea0e7d6362e7c9122
>Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
>Date:   Fri Jun 17 16:10:42 2016 -0400
>
>    tracing: Handle NULL formats in hold_module_trace_bprintk_format()
>    
>    [ Upstream commit 70c8217acd4383e069fe1898bbad36ea4fcdbdcc ]
>    
>    If a task uses a non constant string for the format parameter in
>    trace_printk(), then the trace_printk_fmt variable is set to NULL. This
>    variable is then saved in the __trace_printk_fmt section.
>    
>    The function hold_module_trace_bprintk_format() checks to see if duplicate
>    formats are used by modules, and reuses them if so (saves them to the list
>    if it is new). But this function calls lookup_format() that does a strcmp()
>    to the value (which is now NULL) and can cause a kernel oops.
>    
>    This wasn't an issue till 3debb0a9ddb ("tracing: Fix trace_printk() to print
>    when not using bprintk()") which added "__used" to the trace_printk_fmt
>    variable, and before that, the kernel simply optimized it out (no NULL value
>    was saved).
>    
>    The fix is simply to handle the NULL pointer in lookup_format() and have the
>    caller ignore the value if it was NULL.
>    
>    Link: http://lkml.kernel.org/r/1464769870-18344-1-git-send-email-zhengjun.xing@intel.com
>    
>    Reported-by: xingzhen <zhengjun.xing@intel.com>
>    Acked-by: Namhyung Kim <namhyung@kernel.org>
>    Fixes: 3debb0a9ddb ("tracing: Fix trace_printk() to print when not using bprintk()")
>    Cc: stable@vger.kernel.org # v3.5+
>    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1105110de5bac70124e63663c618cab9d4e5c3b7
>Author: Wolfgang Grandegger <wg@grandegger.com>
>Date:   Mon Jun 13 15:44:19 2016 +0200
>
>    can: at91_can: RX queue could get stuck at high bus load
>    
>    [ Upstream commit 43200a4480cbbe660309621817f54cbb93907108 ]
>    
>    At high bus load it could happen that "at91_poll()" enters with all RX
>    message boxes filled up. If then at the end the "quota" is exceeded as
>    well, "rx_next" will not be reset to the first RX mailbox and hence the
>    interrupts remain disabled.
>    
>    Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
>    Tested-by: Amr Bekhit <amrbekhit@gmail.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 293745be2931d248a1244918b2318b7cbcdda542
>Author: Thor Thayer <tthayer@opensource.altera.com>
>Date:   Thu Jun 16 11:10:19 2016 -0500
>
>    can: c_can: Update D_CAN TX and RX functions to 32 bit - fix Altera Cyclone access
>    
>    [ Upstream commit 427460c83cdf55069eee49799a0caef7dde8df69 ]
>    
>    When testing CAN write floods on Altera's CycloneV, the first 2 bytes
>    are sometimes 0x00, 0x00 or corrupted instead of the values sent. Also
>    observed bytes 4 & 5 were corrupted in some cases.
>    
>    The D_CAN Data registers are 32 bits and changing from 16 bit writes to
>    32 bit writes fixes the problem.
>    
>    Testing performed on Altera CycloneV (D_CAN).  Requesting tests on other
>    C_CAN & D_CAN platforms.
>    
>    Reported-by: Richard Andrysek <richard.andrysek@gomtec.de>
>    Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0764832cd4b2472693529696578563892929701a
>Author: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
>Date:   Wed Jun 8 17:28:29 2016 -0600
>
>    IB/mlx4: Properly initialize GRH TClass and FlowLabel in AHs
>    
>    [ Upstream commit 8c5122e45a10a9262f872b53f151a592e870f905 ]
>    
>    When this code was reworked for IBoE support the order of assignments
>    for the sl_tclass_flowlabel got flipped around resulting in
>    TClass & FlowLabel being permanently set to 0 in the packet headers.
>    
>    This breaks IB routers that rely on these headers, but only affects
>    kernel users - libmlx4 does this properly for user space.
>    
>    Cc: stable@vger.kernel.org
>    Fixes: fa417f7b520e ("IB/mlx4: Add support for IBoE")
>    Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
>    Signed-off-by: Doug Ledford <dledford@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit efe098c364208b0d1fcc1b252290df0fd225d352
>Author: Jeff Mahoney <jeffm@suse.com>
>Date:   Wed Jun 8 00:36:38 2016 -0400
>
>    btrfs: account for non-CoW'd blocks in btrfs_abort_transaction
>    
>    [ Upstream commit 64c12921e11b3a0c10d088606e328c58e29274d8 ]
>    
>    The test for !trans->blocks_used in btrfs_abort_transaction is
>    insufficient to determine whether it's safe to drop the transaction
>    handle on the floor.  btrfs_cow_block, informed by should_cow_block,
>    can return blocks that have already been CoW'd in the current
>    transaction.  trans->blocks_used is only incremented for new block
>    allocations. If an operation overlaps the blocks in the current
>    transaction entirely and must abort the transaction, we'll happily
>    let it clean up the trans handle even though it may have modified
>    the blocks and will commit an incomplete operation.
>    
>    In the long-term, I'd like to do closer tracking of when the fs
>    is actually modified so we can still recover as gracefully as possible,
>    but that approach will need some discussion.  In the short term,
>    since this is the only code using trans->blocks_used, let's just
>    switch it to a bool indicating whether any blocks were used and set
>    it when should_cow_block returns false.
>    
>    Cc: stable@vger.kernel.org # 3.4+
>    Signed-off-by: Jeff Mahoney <jeffm@suse.com>
>    Reviewed-by: Filipe Manana <fdmanana@suse.com>
>    Signed-off-by: David Sterba <dsterba@suse.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0b1ca750b5fe6e457768c1b835f7f380a288ca58
>Author: Jaroslav Kysela <perex@perex.cz>
>Date:   Fri Jun 17 13:35:56 2016 +0200
>
>    ALSA: hdac_regmap - fix the register access for runtime PM
>    
>    [ Upstream commit 8198868f0a283eb23e264951632ce61ec2f82228 ]
>    
>    Call path:
>    
>      1) snd_hdac_power_up_pm()
>      2) snd_hdac_power_up()
>      3) pm_runtime_get_sync()
>      4) __pm_runtime_resume()
>      5) rpm_resume()
>    
>    The rpm_resume() returns 1 when the device is already active.
>    Because the return value is unmodified, the hdac regmap read/write
>    functions should allow this value for the retry I/O operation, too.
>    
>    Signed-off-by: Jaroslav Kysela <perex@perex.cz>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ec3e73223a8e5a5ec66ca6a2b12d37ddaf2530dd
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Thu Apr 21 17:49:11 2016 +0200
>
>    ALSA: hda - Fix possible race on regmap bypass flip
>    
>    [ Upstream commit 3194ed497939c6448005542e3ca4fa2386968fa0 ]
>    
>    HD-audio driver uses regmap cache bypass feature for reading a raw
>    value without the cache.  But this is racy since both the cached and
>    the uncached reads may occur concurrently.  The former is done via the
>    normal control API access while the latter comes from the proc file
>    read.
>    
>    Even though the regmap itself has the protection against the
>    concurrent accesses, the flag set/reset is done without the
>    protection, so it may lead to inconsistent state of bypass flag that
>    doesn't match with the current read and occasionally result in a
>    kernel WARNING like:
>      WARNING: CPU: 3 PID: 2731 at drivers/base/regmap/regcache.c:499 regcache_cache_only+0x78/0x93
>    
>    One way to work around such a problem is to wrap with a mutex.  But in
>    this case, the solution is simpler: for the uncached read, we just
>    skip the regmap and directly calls its accessor.  The verb execution
>    there is protected by itself, so basically it's safe to call
>    individually.
>    
>    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116171
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c262505cdb45765ddea20a1f85f0023990276772
>Author: Dan Carpenter <dan.carpenter@oracle.com>
>Date:   Thu Jun 16 15:48:57 2016 +0100
>
>    KEYS: potential uninitialized variable
>    
>    [ Upstream commit 38327424b40bcebe2de92d07312c89360ac9229a ]
>    
>    If __key_link_begin() failed then "edit" would be uninitialized.  I've
>    added a check to fix that.
>    
>    This allows a random user to crash the kernel, though it's quite
>    difficult to achieve.  There are three ways it can be done as the user
>    would have to cause an error to occur in __key_link():
>    
>     (1) Cause the kernel to run out of memory.  In practice, this is difficult
>         to achieve without ENOMEM cropping up elsewhere and aborting the
>         attempt.
>    
>     (2) Revoke the destination keyring between the keyring ID being looked up
>         and it being tested for revocation.  In practice, this is difficult to
>         time correctly because the KEYCTL_REJECT function can only be used
>         from the request-key upcall process.  Further, users can only make use
>         of what's in /sbin/request-key.conf, though this does including a
>         rejection debugging test - which means that the destination keyring
>         has to be the caller's session keyring in practice.
>    
>     (3) Have just enough key quota available to create a key, a new session
>         keyring for the upcall and a link in the session keyring, but not then
>         sufficient quota to create a link in the nominated destination keyring
>         so that it fails with EDQUOT.
>    
>    The bug can be triggered using option (3) above using something like the
>    following:
>    
>    	echo 80 >/proc/sys/kernel/keys/root_maxbytes
>    	keyctl request2 user debug:fred negate @t
>    
>    The above sets the quota to something much lower (80) to make the bug
>    easier to trigger, but this is dependent on the system.  Note also that
>    the name of the keyring created contains a random number that may be
>    between 1 and 10 characters in size, so may throw the test off by
>    changing the amount of quota used.
>    
>    Assuming the failure occurs, something like the following will be seen:
>    
>    	kfree_debugcheck: out of range ptr 6b6b6b6b6b6b6b68h
>    	------------[ cut here ]------------
>    	kernel BUG at ../mm/slab.c:2821!
>    	...
>    	RIP: 0010:[<ffffffff811600f9>] kfree_debugcheck+0x20/0x25
>    	RSP: 0018:ffff8804014a7de8  EFLAGS: 00010092
>    	RAX: 0000000000000034 RBX: 6b6b6b6b6b6b6b68 RCX: 0000000000000000
>    	RDX: 0000000000040001 RSI: 00000000000000f6 RDI: 0000000000000300
>    	RBP: ffff8804014a7df0 R08: 0000000000000001 R09: 0000000000000000
>    	R10: ffff8804014a7e68 R11: 0000000000000054 R12: 0000000000000202
>    	R13: ffffffff81318a66 R14: 0000000000000000 R15: 0000000000000001
>    	...
>    	Call Trace:
>    	  kfree+0xde/0x1bc
>    	  assoc_array_cancel_edit+0x1f/0x36
>    	  __key_link_end+0x55/0x63
>    	  key_reject_and_link+0x124/0x155
>    	  keyctl_reject_key+0xb6/0xe0
>    	  keyctl_negate_key+0x10/0x12
>    	  SyS_keyctl+0x9f/0xe7
>    	  do_syscall_64+0x63/0x13a
>    	  entry_SYSCALL64_slow_path+0x25/0x25
>    
>    Fixes: f70e2e06196a ('KEYS: Do preallocation for __key_link()')
>    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>    Signed-off-by: David Howells <dhowells@redhat.com>
>    cc: stable@vger.kernel.org
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0356b95fcc4e7eb670633be53db29147201ddce4
>Author: Tejun Heo <tj@kernel.org>
>Date:   Thu May 26 15:42:13 2016 -0400
>
>    cgroup: set css->id to -1 during init
>    
>    [ Upstream commit 8fa3b8d689a54d6d04ff7803c724fb7aca6ce98e ]
>    
>    If percpu_ref initialization fails during css_create(), the free path
>    can end up trying to free css->id of zero.  As ID 0 is unused, it
>    doesn't cause a critical breakage but it does trigger a warning
>    message.  Fix it by setting css->id to -1 from init_and_link_css().
>    
>    Signed-off-by: Tejun Heo <tj@kernel.org>
>    Cc: Wenwei Tao <ww.tao0320@gmail.com>
>    Fixes: 01e586598b22 ("cgroup: release css->id after css_free")
>    Cc: stable@vger.kernel.org # v4.0+
>    Signed-off-by: Tejun Heo <tj@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4c9b1064a186967df8c81f7305df533f56678abf
>Author: Ocquidant, Sebastien <sebastienocquidant@eaton.com>
>Date:   Wed Jun 15 13:47:35 2016 +0200
>
>    memory: omap-gpmc: Fix omap gpmc EXTRADELAY timing
>    
>    [ Upstream commit 8f50b8e57442d28e41bb736c173d8a2490549a82 ]
>    
>    In the omap gpmc driver it can be noticed that GPMC_CONFIG4_OEEXTRADELAY
>    is overwritten by the WEEXTRADELAY value from the device tree and
>    GPMC_CONFIG4_WEEXTRADELAY is not updated by the value from the device
>    tree.
>    
>    As a consequence, the memory accesses cannot be configured properly when
>    the extra delay are needed for OE and WE.
>    
>    Fix the update of GPMC_CONFIG4_WEEXTRADELAY with the value from the
>    device tree file and prevents GPMC_CONFIG4_OEXTRADELAY
>    being overwritten by the WEXTRADELAY value from the device tree.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Ocquidant, Sebastien <sebastienocquidant@eaton.com>
>    Signed-off-by: Roger Quadros <rogerq@ti.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 316515981206627bf97be37eca397234d604395d
>Author: Xiubo Li <lixiubo@cmss.chinamobile.com>
>Date:   Wed Jun 15 18:00:33 2016 +0800
>
>    kvm: Fix irq route entries exceeding KVM_MAX_IRQ_ROUTES
>    
>    [ Upstream commit caf1ff26e1aa178133df68ac3d40815fed2187d9 ]
>    
>    These days, we experienced one guest crash with 8 cores and 3 disks,
>    with qemu error logs as bellow:
>    
>    qemu-system-x86_64: /build/qemu-2.0.0/kvm-all.c:984:
>    kvm_irqchip_commit_routes: Assertion `ret == 0' failed.
>    
>    And then we found one patch(bdf026317d) in qemu tree, which said
>    could fix this bug.
>    
>    Execute the following script will reproduce the BUG quickly:
>    
>    irq_affinity.sh
>    ========================================================================
>    
>    vda_irq_num=25
>    vdb_irq_num=27
>    while [ 1 ]
>    do
>        for irq in {1,2,4,8,10,20,40,80}
>            do
>                echo $irq > /proc/irq/$vda_irq_num/smp_affinity
>                echo $irq > /proc/irq/$vdb_irq_num/smp_affinity
>                dd if=/dev/vda of=/dev/zero bs=4K count=100 iflag=direct
>                dd if=/dev/vdb of=/dev/zero bs=4K count=100 iflag=direct
>            done
>    done
>    ========================================================================
>    
>    The following qemu log is added in the qemu code and is displayed when
>    this bug reproduced:
>    
>    kvm_irqchip_commit_routes: max gsi: 1008, nr_allocated_irq_routes: 1024,
>    irq_routes->nr: 1024, gsi_count: 1024.
>    
>    That's to say when irq_routes->nr == 1024, there are 1024 routing entries,
>    but in the kernel code when routes->nr >= 1024, will just return -EINVAL;
>    
>    The nr is the number of the routing entries which is in of
>    [1 ~ KVM_MAX_IRQ_ROUTES], not the index in [0 ~ KVM_MAX_IRQ_ROUTES - 1].
>    
>    This patch fix the BUG above.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Xiubo Li <lixiubo@cmss.chinamobile.com>
>    Signed-off-by: Wei Tang <tangwei@cmss.chinamobile.com>
>    Signed-off-by: Zhang Zhuoyu <zhangzhuoyu@cmss.chinamobile.com>
>    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit aec2ddb9595f130759ca20c8f089e0361c95ca97
>Author: Jiri Slaby <jslaby@suse.cz>
>Date:   Fri Jun 10 10:54:32 2016 +0200
>
>    base: make module_create_drivers_dir race-free
>    
>    [ Upstream commit 7e1b1fc4dabd6ec8e28baa0708866e13fa93c9b3 ]
>    
>    Modules which register drivers via standard path (driver_register) in
>    parallel can cause a warning:
>    WARNING: CPU: 2 PID: 3492 at ../fs/sysfs/dir.c:31 sysfs_warn_dup+0x62/0x80
>    sysfs: cannot create duplicate filename '/module/saa7146/drivers'
>    Modules linked in: hexium_gemini(+) mxb(+) ...
>    ...
>    Call Trace:
>    ...
>     [<ffffffff812e63a2>] sysfs_warn_dup+0x62/0x80
>     [<ffffffff812e6487>] sysfs_create_dir_ns+0x77/0x90
>     [<ffffffff8140f2c4>] kobject_add_internal+0xb4/0x340
>     [<ffffffff8140f5b8>] kobject_add+0x68/0xb0
>     [<ffffffff8140f631>] kobject_create_and_add+0x31/0x70
>     [<ffffffff8157a703>] module_add_driver+0xc3/0xd0
>     [<ffffffff8155e5d4>] bus_add_driver+0x154/0x280
>     [<ffffffff815604c0>] driver_register+0x60/0xe0
>     [<ffffffff8145bed0>] __pci_register_driver+0x60/0x70
>     [<ffffffffa0273e14>] saa7146_register_extension+0x64/0x90 [saa7146]
>     [<ffffffffa0033011>] hexium_init_module+0x11/0x1000 [hexium_gemini]
>    ...
>    
>    As can be (mostly) seen, driver_register causes this call sequence:
>      -> bus_add_driver
>        -> module_add_driver
>          -> module_create_drivers_dir
>    The last one creates "drivers" directory in /sys/module/<...>. When
>    this is done in parallel, the directory is attempted to be created
>    twice at the same time.
>    
>    This can be easily reproduced by loading mxb and hexium_gemini in
>    parallel:
>    while :; do
>      modprobe mxb &
>      modprobe hexium_gemini
>      wait
>      rmmod mxb hexium_gemini saa7146_vv saa7146
>    done
>    
>    saa7146 calls pci_register_driver for both mxb and hexium_gemini,
>    which means /sys/module/saa7146/drivers is to be created for both of
>    them.
>    
>    Fix this by a new mutex in module_create_drivers_dir which makes the
>    test-and-create "drivers" dir atomic.
>    
>    I inverted the condition and removed 'return' to avoid multiple
>    unlocks or a goto.
>    
>    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
>    Fixes: fe480a2675ed (Modules: only add drivers/ direcory if needed)
>    Cc: v2.6.21+ <stable@vger.kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c2edadb9814a6ca12e1442c574d2191ca7352c06
>Author: J. Bruce Fields <bfields@redhat.com>
>Date:   Mon May 16 17:03:42 2016 -0400
>
>    nfsd4/rpc: move backchannel create logic into rpc code
>    
>    [ Upstream commit d50039ea5ee63c589b0434baa5ecf6e5075bb6f9 ]
>    
>    Also simplify the logic a bit.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
>    Acked-by: Trond Myklebust <trondmy@primarydata.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 040ad2a3262124ac7d4676a5409c194baca514a9
>Author: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com>
>Date:   Wed May 25 16:45:43 2016 -0400
>
>    drm/dp/mst: Always clear proposed vcpi table for port.
>    
>    [ Upstream commit fd2d2bac6e79b0be91ab86a6075a0c46ffda658a ]
>    
>    Not clearing mst manager's proposed vcpis table for destroyed connectors when the manager is stopped leaves it pointing to unrefernced memory, this causes pagefault when the manager is restarted when plugging back a branch.
>    
>    Fixes: 91a25e463130 ("drm/dp/mst: deallocate payload on port destruction")
>    Signed-off-by: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com>
>    Reviewed-by: Lyude <cpaul@redhat.com>
>    Cc: stable@vger.kernel.org
>    Cc: Mykola Lysenko <Mykola.Lysenko@amd.com>
>    Cc: Alex Deucher <alexander.deucher@amd.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5a6c735c13e0ad34cdb4fc24a782924b64efec92
>Author: Lyude <cpaul@redhat.com>
>Date:   Tue Jun 14 11:04:09 2016 -0400
>
>    drm/i915/ilk: Don't disable SSC source if it's in use
>    
>    [ Upstream commit 476490a945e1f0f6bd58e303058d2d8ca93a974c ]
>    
>    Thanks to Ville SyrjÃ¤lÃ¤ for pointing me towards the cause of this issue.
>    
>    Unfortunately one of the sideaffects of having the refclk for a DPLL set
>    to SSC is that as long as it's set to SSC, the GPU will prevent us from
>    powering down any of the pipes or transcoders using it. A couple of
>    BIOSes enable SSC in both PCH_DREF_CONTROL and in the DPLL
>    configurations. This causes issues on the first modeset, since we don't
>    expect SSC to be left on and as a result, can't successfully power down
>    the pipes or the transcoders using it. Here's an example from this Dell
>    OptiPlex 990:
>    
>    [drm:intel_modeset_init] SSC enabled by BIOS, overriding VBT which says disabled
>    [drm:intel_modeset_init] 2 display pipes available.
>    [drm:intel_update_cdclk] Current CD clock rate: 400000 kHz
>    [drm:intel_update_max_cdclk] Max CD clock rate: 400000 kHz
>    [drm:intel_update_max_cdclk] Max dotclock rate: 360000 kHz
>    vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
>    [drm:intel_crt_reset] crt adpa set to 0xf40000
>    [drm:intel_dp_init_connector] Adding DP connector on port C
>    [drm:intel_dp_aux_init] registering DPDDC-C bus for card0-DP-1
>    [drm:ironlake_init_pch_refclk] has_panel 0 has_lvds 0 has_ck505 0
>    [drm:ironlake_init_pch_refclk] Disabling SSC entirely
>    â¦ later we try committing the first modeset â¦
>    [drm:intel_dump_pipe_config] [CRTC:26][modeset] config ffff88041b02e800 for pipe A
>    [drm:intel_dump_pipe_config] cpu_transcoder: A
>    â¦
>    [drm:intel_dump_pipe_config] dpll_hw_state: dpll: 0xc4016001, dpll_md: 0x0, fp0: 0x20e08, fp1: 0x30d07
>    [drm:intel_dump_pipe_config] planes on this crtc
>    [drm:intel_dump_pipe_config] STANDARD PLANE:23 plane: 0.0 idx: 0 enabled
>    [drm:intel_dump_pipe_config]     FB:42, fb = 800x600 format = 0x34325258
>    [drm:intel_dump_pipe_config]     scaler:0 src (0, 0) 800x600 dst (0, 0) 800x600
>    [drm:intel_dump_pipe_config] CURSOR PLANE:25 plane: 0.1 idx: 1 disabled, scaler_id = 0
>    [drm:intel_dump_pipe_config] STANDARD PLANE:27 plane: 0.1 idx: 2 disabled, scaler_id = 0
>    [drm:intel_get_shared_dpll] CRTC:26 allocated PCH DPLL A
>    [drm:intel_get_shared_dpll] using PCH DPLL A for pipe A
>    [drm:ilk_audio_codec_disable] Disable audio codec on port C, pipe A
>    [drm:intel_disable_pipe] disabling pipe A
>    ------------[ cut here ]------------
>    WARNING: CPU: 1 PID: 130 at drivers/gpu/drm/i915/intel_display.c:1146 intel_disable_pipe+0x297/0x2d0 [i915]
>    pipe_off wait timed out
>    â¦
>    ---[ end trace 94fc8aa03ae139e8 ]---
>    [drm:intel_dp_link_down]
>    [drm:ironlake_crtc_disable [i915]] *ERROR* failed to disable transcoder A
>    
>    Later modesets succeed since they reset the DPLL's configuration anyway,
>    but this is enough to get stuck with a big fat warning in dmesg.
>    
>    A better solution would be to add refcounts for the SSC source, but for
>    now leaving the source clock on should suffice.
>    
>    Changes since v4:
>     - Fix calculation of final for systems with LVDS panels (fixes BUG() on
>       CI test suite)
>    Changes since v3:
>     - Move temp variable into loop
>     - Move checks for using_ssc_source to after we've figured out has_ck505
>     - Add using_ssc_source to debug output
>    Changes since v2:
>     - Fix debug output for when we disable the CPU source
>    Changes since v1:
>     - Leave the SSC source clock on instead of just shutting it off on all
>       of the DPLL configurations.
>    
>    Cc: stable@vger.kernel.org
>    Reviewed-by: Ville SyrjÃ¤lÃ¤ <ville.syrjala@linux.intel.com>
>    Signed-off-by: Lyude <cpaul@redhat.com>
>    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>    Link: http://patchwork.freedesktop.org/patch/msgid/1465916649-10228-1-git-send-email-cpaul@redhat.com
>    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 260c505e55b51645affb70a2c456b350f7e7460a
>Author: Rhyland Klein <rklein@nvidia.com>
>Date:   Thu Jun 9 17:28:39 2016 -0400
>
>    power_supply: power_supply_read_temp only if use_cnt > 0
>    
>    [ Upstream commit 5bc28b93a36e3cb3acc2870fb75cb6ffb182fece ]
>    
>    Change power_supply_read_temp() to use power_supply_get_property()
>    so that it will check the use_cnt and ensure it is > 0. The use_cnt
>    will be incremented at the end of __power_supply_register, so this
>    will block to case where get_property can be called before the supply
>    is fully registered. This fixes the issue show in the stack below:
>    
>    [    1.452598] power_supply_read_temp+0x78/0x80
>    [    1.458680] thermal_zone_get_temp+0x5c/0x11c
>    [    1.464765] thermal_zone_device_update+0x34/0xb4
>    [    1.471195] thermal_zone_device_register+0x87c/0x8cc
>    [    1.477974] __power_supply_register+0x364/0x424
>    [    1.484317] power_supply_register_no_ws+0x10/0x18
>    [    1.490833] bq27xxx_battery_setup+0x10c/0x164
>    [    1.497003] bq27xxx_battery_i2c_probe+0xd0/0x1b0
>    [    1.503435] i2c_device_probe+0x174/0x240
>    [    1.509172] driver_probe_device+0x1fc/0x29c
>    [    1.515167] __driver_attach+0xa4/0xa8
>    [    1.520643] bus_for_each_dev+0x58/0x98
>    [    1.526204] driver_attach+0x20/0x28
>    [    1.531505] bus_add_driver+0x1c8/0x22c
>    [    1.537067] driver_register+0x68/0x108
>    [    1.542630] i2c_register_driver+0x38/0x7c
>    [    1.548457] bq27xxx_battery_i2c_driver_init+0x18/0x20
>    [    1.555321] do_one_initcall+0x38/0x12c
>    [    1.560886] kernel_init_freeable+0x148/0x1ec
>    [    1.566972] kernel_init+0x10/0xfc
>    [    1.572101] ret_from_fork+0x10/0x40
>    
>    Also make the same change to ps_get_max_charge_cntl_limit() and
>    ps_get_cur_chrage_cntl_limit() to be safe. Lastly, change the return
>    value of power_supply_get_property() to -EAGAIN from -ENODEV if
>    use_cnt <= 0.
>    
>    Fixes: 297d716f6260 ("power_supply: Change ownership from driver to core")
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Rhyland Klein <rklein@nvidia.com>
>    Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>    Signed-off-by: Sebastian Reichel <sre@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9f67dcf663004c56aaf153835f624f9f87d9a643
>Author: Andrey Ryabinin <aryabinin@virtuozzo.com>
>Date:   Thu Jun 9 15:20:05 2016 +0300
>
>    kernel/sysrq, watchdog, sched/core: Reset watchdog on all CPUs while processing sysrq-w
>    
>    [ Upstream commit 57675cb976eff977aefb428e68e4e0236d48a9ff ]
>    
>    Lengthy output of sysrq-w may take a lot of time on slow serial console.
>    
>    Currently we reset NMI-watchdog on the current CPU to avoid spurious
>    lockup messages. Sometimes this doesn't work since softlockup watchdog
>    might trigger on another CPU which is waiting for an IPI to proceed.
>    We reset softlockup watchdogs on all CPUs, but we do this only after
>    listing all tasks, and this may be too late on a busy system.
>    
>    So, reset watchdogs CPUs earlier, in for_each_process_thread() loop.
>    
>    Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Cc: <stable@vger.kernel.org>
>    Link: http://lkml.kernel.org/r/1465474805-14641-1-git-send-email-aryabinin@virtuozzo.com
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c5ffc99b6e519420a791e942606d48fe030383d2
>Author: Masami Hiramatsu <mhiramat@kernel.org>
>Date:   Sat Jun 11 23:06:53 2016 +0900
>
>    kprobes/x86: Clear TF bit in fault on single-stepping
>    
>    [ Upstream commit dcfc47248d3f7d28df6f531e6426b933de94370d ]
>    
>    Fix kprobe_fault_handler() to clear the TF (trap flag) bit of
>    the flags register in the case of a fault fixup on single-stepping.
>    
>    If we put a kprobe on the instruction which caused a
>    page fault (e.g. actual mov instructions in copy_user_*),
>    that fault happens on the single-stepping buffer. In this
>    case, kprobes resets running instance so that the CPU can
>    retry execution on the original ip address.
>    
>    However, current code forgets to reset the TF bit. Since this
>    fault happens with TF bit set for enabling single-stepping,
>    when it retries, it causes a debug exception and kprobes
>    can not handle it because it already reset itself.
>    
>    On the most of x86-64 platform, it can be easily reproduced
>    by using kprobe tracer. E.g.
>    
>      # cd /sys/kernel/debug/tracing
>      # echo p copy_user_enhanced_fast_string+5 > kprobe_events
>      # echo 1 > events/kprobes/enable
>    
>    And you'll see a kernel panic on do_debug(), since the debug
>    trap is not handled by kprobes.
>    
>    To fix this problem, we just need to clear the TF bit when
>    resetting running kprobe.
>    
>    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
>    Reviewed-by: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
>    Acked-by: Steven Rostedt <rostedt@goodmis.org>
>    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
>    Cc: Andy Lutomirski <luto@kernel.org>
>    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
>    Cc: Borislav Petkov <bp@alien8.de>
>    Cc: Brian Gerst <brgerst@gmail.com>
>    Cc: Denys Vlasenko <dvlasenk@redhat.com>
>    Cc: H. Peter Anvin <hpa@zytor.com>
>    Cc: Jiri Olsa <jolsa@redhat.com>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Stephane Eranian <eranian@google.com>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Cc: Vince Weaver <vincent.weaver@maine.edu>
>    Cc: systemtap@sourceware.org
>    Cc: stable@vger.kernel.org # All the way back to ancient kernels
>    Link: http://lkml.kernel.org/r/20160611140648.25885.37482.stgit@devbox
>    [ Updated the comments. ]
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 01c93ba6d66687ff46116a46527b7d3b314e0787
>Author: Michal Suchanek <hramrach@gmail.com>
>Date:   Mon Jun 13 17:46:49 2016 +0000
>
>    spi: sunxi: fix transfer timeout
>    
>    [ Upstream commit 719bd6542044efd9b338a53dba1bef45f40ca169 ]
>    
>    The trasfer timeout is fixed at 1000 ms. Reading a 4Mbyte flash over
>    1MHz SPI bus takes way longer than that. Calculate the timeout from the
>    actual time the transfer is supposed to take and multiply by 2 for good
>    measure.
>    
>    Signed-off-by: Michal Suchanek <hramrach@gmail.com>
>    Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>    Signed-off-by: Mark Brown <broonie@kernel.org>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit fcc5d265d134e891abd67169c77358cd5ea2fc77
>Author: Michal Suchanek <hramrach@gmail.com>
>Date:   Mon Jun 13 17:46:49 2016 +0000
>
>    spi: sun4i: fix FIFO limit
>    
>    [ Upstream commit 6d9fe44bd73d567d04d3a68a2d2fa521ab9532f2 ]
>    
>    When testing SPI without DMA I noticed that filling the FIFO on the
>    spi controller causes timeout.
>    
>    Always leave room for one byte in the FIFO.
>    
>    Signed-off-by: Michal Suchanek <hramrach@gmail.com>
>    Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>    Signed-off-by: Mark Brown <broonie@kernel.org>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d1c7fc1c906d7f7ca1788a53ab67043f3094fd67
>Author: James Hogan <james.hogan@imgtec.com>
>Date:   Thu Jun 9 10:50:43 2016 +0100
>
>    MIPS: KVM: Fix modular KVM under QEMU
>    
>    [ Upstream commit 797179bc4fe06c89e47a9f36f886f68640b423f8 ]
>    
>    Copy __kvm_mips_vcpu_run() into unmapped memory, so that we can never
>    get a TLB refill exception in it when KVM is built as a module.
>    
>    This was observed to happen with the host MIPS kernel running under
>    QEMU, due to a not entirely transparent optimisation in the QEMU TLB
>    handling where TLB entries replaced with TLBWR are copied to a separate
>    part of the TLB array. Code in those pages continue to be executable,
>    but those mappings persist only until the next ASID switch, even if they
>    are marked global.
>    
>    An ASID switch happens in __kvm_mips_vcpu_run() at exception level after
>    switching to the guest exception base. Subsequent TLB mapped kernel
>    instructions just prior to switching to the guest trigger a TLB refill
>    exception, which enters the guest exception handlers without updating
>    EPC. This appears as a guest triggered TLB refill on a host kernel
>    mapped (host KSeg2) address, which is not handled correctly as user
>    (guest) mode accesses to kernel (host) segments always generate address
>    error exceptions.
>    
>    Signed-off-by: James Hogan <james.hogan@imgtec.com>
>    Cc: Paolo Bonzini <pbonzini@redhat.com>
>    Cc: Radim KrÄmÃ¡Å <rkrcmar@redhat.com>
>    Cc: Ralf Baechle <ralf@linux-mips.org>
>    Cc: kvm@vger.kernel.org
>    Cc: linux-mips@linux-mips.org
>    Cc: <stable@vger.kernel.org> # 3.10.x-
>    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 505291afa41b4918f3edbd775210853778b7939f
>Author: Oscar <oscar@naiandei.net>
>Date:   Tue Jun 14 14:14:35 2016 +0800
>
>    usb: common: otg-fsm: add license to usb-otg-fsm
>    
>    [ Upstream commit ea1d39a31d3b1b6060b6e83e5a29c069a124c68a ]
>    
>    Fix warning about tainted kernel because usb-otg-fsm has no license.
>    WARNING: with this patch usb-otg-fsm module can be loaded
>    but then the kernel will hang. Tested with a udoo quad board.
>    
>    Cc: <stable@vger.kernel.org> #v4.1+
>    Signed-off-by: Oscar <oscar@naiandei.net>
>    Signed-off-by: Peter Chen <peter.chen@nxp.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d7afed774eec54eabc25de2623cda1aa8176a2bb
>Author: Alex Deucher <alexander.deucher@amd.com>
>Date:   Mon Jun 13 15:37:34 2016 -0400
>
>    drm/radeon: fix asic initialization for virtualized environments
>    
>    [ Upstream commit 05082b8bbd1a0ffc74235449c4b8930a8c240f85 ]
>    
>    When executing in a PCI passthrough based virtuzliation environment, the
>    hypervisor will usually attempt to send a PCIe bus reset signal to the
>    ASIC when the VM reboots. In this scenario, the card is not correctly
>    initialized, but we still consider it to be posted. Therefore, in a
>    passthrough based environemnt we should always post the card to guarantee
>    it is in a good state for driver initialization.
>    
>    Ported from amdgpu commit:
>    amdgpu: fix asic initialization for virtualized environments
>    
>    Cc: Andres Rodriguez <andres.rodriguez@amd.com>
>    Cc: Alex Williamson <alex.williamson@redhat.com>
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7ac3a704d7dd6c0b8a72048ee66523f190afda8d
>Author: Junichi Nomura <j-nomura@ce.jp.nec.com>
>Date:   Fri Jun 10 04:31:52 2016 +0000
>
>    ipmi: Remove smi_msg from waiting_rcv_msgs list before handle_one_recv_msg()
>    
>    [ Upstream commit ae4ea9a2460c7fee2ae8feeb4dfe96f5f6c3e562 ]
>    
>    Commit 7ea0ed2b5be8 ("ipmi: Make the message handler easier to use for
>    SMI interfaces") changed handle_new_recv_msgs() to call handle_one_recv_msg()
>    for a smi_msg while the smi_msg is still connected to waiting_rcv_msgs list.
>    That could lead to following list corruption problems:
>    
>    1) low-level function treats smi_msg as not connected to list
>    
>      handle_one_recv_msg() could end up calling smi_send(), which
>      assumes the msg is not connected to list.
>    
>      For example, the following sequence could corrupt list by
>      doing list_add_tail() for the entry still connected to other list.
>    
>        handle_new_recv_msgs()
>          msg = list_entry(waiting_rcv_msgs)
>          handle_one_recv_msg(msg)
>            handle_ipmb_get_msg_cmd(msg)
>              smi_send(msg)
>                spin_lock(xmit_msgs_lock)
>                list_add_tail(msg)
>                spin_unlock(xmit_msgs_lock)
>    
>    2) race between multiple handle_new_recv_msgs() instances
>    
>      handle_new_recv_msgs() once releases waiting_rcv_msgs_lock before calling
>      handle_one_recv_msg() then retakes the lock and list_del() it.
>    
>      If others call handle_new_recv_msgs() during the window shown below
>      list_del() will be done twice for the same smi_msg.
>    
>      handle_new_recv_msgs()
>        spin_lock(waiting_rcv_msgs_lock)
>        msg = list_entry(waiting_rcv_msgs)
>        spin_unlock(waiting_rcv_msgs_lock)
>      |
>      | handle_one_recv_msg(msg)
>      |
>        spin_lock(waiting_rcv_msgs_lock)
>        list_del(msg)
>        spin_unlock(waiting_rcv_msgs_lock)
>    
>    Fixes: 7ea0ed2b5be8 ("ipmi: Make the message handler easier to use for SMI interfaces")
>    Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
>    [Added a comment to describe why this works.]
>    Signed-off-by: Corey Minyard <cminyard@mvista.com>
>    Cc: stable@vger.kernel.org # 3.19
>    Tested-by: Ye Feng <yefeng.yl@alibaba-inc.com>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4a088cba60485acbdceee2c3f903e7b0c7846737
>Author: Linus Walleij <linus.walleij@linaro.org>
>Date:   Wed Jun 8 14:56:39 2016 +0200
>
>    crypto: ux500 - memmove the right size
>    
>    [ Upstream commit 19ced623db2fe91604d69f7d86b03144c5107739 ]
>    
>    The hash buffer is really HASH_BLOCK_SIZE bytes, someone
>    must have thought that memmove takes n*u32 words by mistake.
>    Tests work as good/bad as before after this patch.
>    
>    Cc: Joakim Bech <joakim.bech@linaro.org>
>    Cc: stable@vger.kernel.org
>    Reported-by: David Binderman <linuxdev.baldrick@gmail.com>
>    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9341331d504d3acd5b3ad0763bb9d23cd3b28944
>Author: Anton Blanchard <anton@samba.org>
>Date:   Fri Jun 10 16:47:03 2016 +1000
>
>    crypto: vmx - Increase priority of aes-cbc cipher
>    
>    [ Upstream commit 12d3f49e1ffbbf8cbbb60acae5a21103c5c841ac ]
>    
>    All of the VMX AES ciphers (AES, AES-CBC and AES-CTR) are set at
>    priority 1000. Unfortunately this means we never use AES-CBC and
>    AES-CTR, because the base AES-CBC cipher that is implemented on
>    top of AES inherits its priority.
>    
>    To fix this, AES-CBC and AES-CTR have to be a higher priority. Set
>    them to 2000.
>    
>    Testing on a POWER8 with:
>    
>    cryptsetup benchmark --cipher aes --key-size 256
>    
>    Shows decryption speed increase from 402.4 MB/s to 3069.2 MB/s,
>    over 7x faster. Thanks to Mike Strosaker for helping me debug
>    this issue.
>    
>    Fixes: 8c755ace357c ("crypto: vmx - Adding CBC routines for VMX module")
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Anton Blanchard <anton@samba.org>
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 515f30350a5e240febb0b710dbb68abe1f293464
>Author: Steve Capper <steve.capper@arm.com>
>Date:   Tue Jun 7 17:58:06 2016 +0100
>
>    ARM: 8579/1: mm: Fix definition of pmd_mknotpresent
>    
>    [ Upstream commit 56530f5d2ddc9b9fade7ef8db9cb886e9dc689b5 ]
>    
>    Currently pmd_mknotpresent will use a zero entry to respresent an
>    invalidated pmd.
>    
>    Unfortunately this definition clashes with pmd_none, thus it is
>    possible for a race condition to occur if zap_pmd_range sees pmd_none
>    whilst __split_huge_pmd_locked is running too with pmdp_invalidate
>    just called.
>    
>    This patch fixes the race condition by modifying pmd_mknotpresent to
>    create non-zero faulting entries (as is done in other architectures),
>    removing the ambiguity with pmd_none.
>    
>    [catalin.marinas@arm.com: using L_PMD_SECT_VALID instead of PMD_TYPE_SECT]
>    
>    Fixes: 8d9625070073 ("ARM: mm: Transparent huge page support for LPAE systems.")
>    Cc: <stable@vger.kernel.org> # 3.11+
>    Reported-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>    Acked-by: Will Deacon <will.deacon@arm.com>
>    Cc: Russell King <linux@armlinux.org.uk>
>    Signed-off-by: Steve Capper <steve.capper@arm.com>
>    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
>    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 017864ed4d67f66d11cf951ad8d8f497c81e915c
>Author: Will Deacon <will.deacon@arm.com>
>Date:   Tue Jun 7 17:57:54 2016 +0100
>
>    ARM: 8578/1: mm: ensure pmd_present only checks the valid bit
>    
>    [ Upstream commit 624531886987f0f1b5d01fb598034d039198e090 ]
>    
>    In a subsequent patch, pmd_mknotpresent will clear the valid bit of the
>    pmd entry, resulting in a not-present entry from the hardware's
>    perspective. Unfortunately, pmd_present simply checks for a non-zero pmd
>    value and will therefore continue to return true even after a
>    pmd_mknotpresent operation. Since pmd_mknotpresent is only used for
>    managing huge entries, this is only an issue for the 3-level case.
>    
>    This patch fixes the 3-level pmd_present implementation to take into
>    account the valid bit. For bisectability, the change is made before the
>    fix to pmd_mknotpresent.
>    
>    [catalin.marinas@arm.com: comment update regarding pmd_mknotpresent patch]
>    
>    Fixes: 8d9625070073 ("ARM: mm: Transparent huge page support for LPAE systems.")
>    Cc: <stable@vger.kernel.org> # 3.11+
>    Cc: Russell King <linux@armlinux.org.uk>
>    Cc: Steve Capper <Steve.Capper@arm.com>
>    Signed-off-by: Will Deacon <will.deacon@arm.com>
>    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
>    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit bcef1c817adc16f798ff75e7910ab8b3361b85c8
>Author: Wei Fang <fangwei1@huawei.com>
>Date:   Tue Jun 7 14:53:56 2016 +0800
>
>    scsi: fix race between simultaneous decrements of ->host_failed
>    
>    [ Upstream commit 72d8c36ec364c82bf1bf0c64dfa1041cfaf139f7 ]
>    
>    sas_ata_strategy_handler() adds the works of the ata error handler to
>    system_unbound_wq. This workqueue asynchronously runs work items, so the
>    ata error handler will be performed concurrently on different CPUs. In
>    this case, ->host_failed will be decreased simultaneously in
>    scsi_eh_finish_cmd() on different CPUs, and become abnormal.
>    
>    It will lead to permanently inequality between ->host_failed and
>    ->host_busy, and scsi error handler thread won't start running. IO
>    errors after that won't be handled.
>    
>    Since all scmds must have been handled in the strategy handler, just
>    remove the decrement in scsi_eh_finish_cmd() and zero ->host_busy after
>    the strategy handler to fix this race.
>    
>    Fixes: 50824d6c5657 ("[SCSI] libsas: async ata-eh")
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Wei Fang <fangwei1@huawei.com>
>    Reviewed-by: James Bottomley <jejb@linux.vnet.ibm.com>
>    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e342d574a6ce550e14ae1def0eaf2c7cbdc3d991
>Author: Thierry Reding <treding@nvidia.com>
>Date:   Thu May 26 17:23:29 2016 +0200
>
>    usb: host: ehci-tegra: Grab the correct UTMI pads reset
>    
>    [ Upstream commit f8a15a9650694feaa0dabf197b0c94d37cd3fb42 ]
>    
>    There are three EHCI controllers on Tegra SoCs, each with its own reset
>    line. However, the first controller contains a set of UTMI configuration
>    registers that are shared with its siblings. These registers will only
>    be reset as part of the first controller's reset. For proper operation
>    it must be ensured that the UTMI configuration registers are reset
>    before any of the EHCI controllers are enabled, irrespective of the
>    probe order.
>    
>    Commit a47cc24cd1e5 ("USB: EHCI: tegra: Fix probe order issue leading to
>    broken USB") introduced code that ensures the first controller is always
>    reset before setting up any of the controllers, and is never again reset
>    afterwards.
>    
>    This code, however, grabs the wrong reset. Each EHCI controller has two
>    reset controls attached: 1) the USB controller reset and 2) the UTMI
>    pads reset (really the first controller's reset). In order to reset the
>    UTMI pads registers the code must grab the second reset, but instead it
>    grabbing the first.
>    
>    Fixes: a47cc24cd1e5 ("USB: EHCI: tegra: Fix probe order issue leading to broken USB")
>    Acked-by: Jon Hunter <jonathanh@nvidia.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Thierry Reding <treding@nvidia.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5cf1329f2004c34966fd4de2bdba14b470c1895f
>Author: Andrew Goodbody <andrew.goodbody@cambrionix.com>
>Date:   Tue May 31 10:05:27 2016 -0500
>
>    usb: musb: Stop bulk endpoint while queue is rotated
>    
>    [ Upstream commit 7b2c17f829545df27a910e8d82e133c21c9a8c9c ]
>    
>    Ensure that the endpoint is stopped by clearing REQPKT before
>    clearing DATAERR_NAKTIMEOUT before rotating the queue on the
>    dedicated bulk endpoint.
>    This addresses an issue where a race could result in the endpoint
>    receiving data before it was reprogrammed resulting in a warning
>    about such data from musb_rx_reinit before it was thrown away.
>    The data thrown away was a valid packet that had been correctly
>    ACKed which meant the host and device got out of sync.
>    
>    Signed-off-by: Andrew Goodbody <andrew.goodbody@cambrionix.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Bin Liu <b-liu@ti.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ffb84c1774409125134fe0eebd5fd4da82993f22
>Author: Andrew Goodbody <andrew.goodbody@cambrionix.com>
>Date:   Tue May 31 10:05:26 2016 -0500
>
>    usb: musb: Ensure rx reinit occurs for shared_fifo endpoints
>    
>    [ Upstream commit f3eec0cf784e0d6c47822ca6b66df3d5812af7e6 ]
>    
>    shared_fifo endpoints would only get a previous tx state cleared
>    out, the rx state was only cleared for non shared_fifo endpoints
>    Change this so that the rx state is cleared for all endpoints.
>    This addresses an issue that resulted in rx packets being dropped
>    silently.
>    
>    Signed-off-by: Andrew Goodbody <andrew.goodbody@cambrionix.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Bin Liu <b-liu@ti.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 95cb83b7af2bf9d7a466b51427966eba42333977
>Author: Hans de Goede <hdegoede@redhat.com>
>Date:   Wed Jun 1 21:01:29 2016 +0200
>
>    USB: xhci: Add broken streams quirk for Frescologic device id 1009
>    
>    [ Upstream commit d95815ba6a0f287213118c136e64d8c56daeaeab ]
>    
>    I got one of these cards for testing uas with, it seems that with streams
>    it dma-s all over the place, corrupting memory. On my first tests it
>    managed to dma over the BIOS of the motherboard somehow and completely
>    bricked it.
>    
>    Tests on another motherboard show that it does work with streams disabled.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 378cd9e7d03774e60d58ad8fcbd67fd226234d40
>Author: Hans de Goede <hdegoede@redhat.com>
>Date:   Thu May 19 17:12:20 2016 +0200
>
>    usb: quirks: Add no-lpm quirk for Acer C120 LED Projector
>    
>    [ Upstream commit 32cb0b37098f4beeff5ad9e325f11b42a6ede56c ]
>    
>    The Acer C120 LED Projector is a USB-3 connected pico projector which
>    takes both its power and video data from USB-3.
>    
>    In combination with some hubs this device does not play well with
>    lpm, so disable lpm for it.
>    
>    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7d2831a8cd331f8d8d214b2a78a217a4ee1b5138
>Author: Hans de Goede <hdegoede@redhat.com>
>Date:   Thu May 19 17:12:19 2016 +0200
>
>    usb: quirks: Fix sorting
>    
>    [ Upstream commit 81099f97bd31e25ff2719a435b1860fc3876122f ]
>    
>    Properly sort all the entries by vendor id.
>    
>    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0c3f25d8c6aa0ff475a86cd5d3b7e2c7b6eb496f
>Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>Date:   Wed Jun 1 18:09:09 2016 +0300
>
>    usb: xhci-plat: properly handle probe deferral for devm_clk_get()
>    
>    [ Upstream commit de95c40d5beaa47f6dc8fe9ac4159b4672b51523 ]
>    
>    On some platforms, the clocks might be registered by a platform
>    driver. When this is the case, the clock platform driver may very well
>    be probed after xhci-plat, in which case the first probe() invocation
>    of xhci-plat will receive -EPROBE_DEFER as the return value of
>    devm_clk_get().
>    
>    The current code handles that as a normal error, and simply assumes
>    that this means that the system doesn't have a clock for the XHCI
>    controller, and continues probing without calling
>    clk_prepare_enable(). Unfortunately, this doesn't work on systems
>    where the XHCI controller does have a clock, but that clock is
>    provided by another platform driver. In order to fix this situation,
>    we handle the -EPROBE_DEFER error condition specially, and abort the
>    XHCI controller probe(). It will be retried later automatically, the
>    clock will be available, devm_clk_get() will succeed, and the probe()
>    will continue with the clock prepared and enabled as expected.
>    
>    In practice, such issue is seen on the ARM64 Marvell 7K/8K platform,
>    where the clocks are registered by a platform driver.
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e78c8a575fd956a4e8a04125c50c23264e012e8e
>Author: Mathias Nyman <mathias.nyman@linux.intel.com>
>Date:   Wed Jun 1 18:09:08 2016 +0300
>
>    xhci: Fix handling timeouted commands on hosts in weird states.
>    
>    [ Upstream commit 3425aa03f484d45dc21e0e791c2f6c74ea656421 ]
>    
>    If commands timeout we mark them for abortion, then stop the command
>    ring, and turn the commands to no-ops and finally restart the command
>    ring.
>    
>    If the host is working properly the no-op commands will finish and
>    pending completions are called.
>    If we notice the host is failing, driver clears the command ring and
>    completes, deletes and frees all pending commands.
>    
>    There are two separate cases reported where host is believed to work
>    properly but is not. In the first case we successfully stop the ring
>    but no abort or stop command ring event is ever sent and host locks up.
>    
>    The second case is if a host is removed, command times out and driver
>    believes the ring is stopped, and assumes it will be restarted, but
>    actually ends up timing out on the same command forever.
>    If one of the pending commands has the xhci->mutex held it will block
>    xhci_stop() in the remove codepath which otherwise would cleanup pending
>    commands.
>    
>    Add a check that clears all pending commands in case host is removed,
>    or we are stuck timing out on the same command. Also restart the
>    command timeout timer when stopping the command ring to ensure we
>    recive an ring stop/abort event.
>    
>    Cc: stable <stable@vger.kernel.org>
>    Tested-by: Joe Lawrence <joe.lawrence@stratus.com>
>    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b71d1794461e3be4e193b76a04132ac55afd5ae1
>Author: Oliver Neukum <oneukum@suse.com>
>Date:   Tue May 31 14:48:15 2016 +0200
>
>    HID: elo: kill not flush the work
>    
>    [ Upstream commit ed596a4a88bd161f868ccba078557ee7ede8a6ef ]
>    
>    Flushing a work that reschedules itself is not a sensible operation. It needs
>    to be killed. Failure to do so leads to a kernel panic in the timer code.
>    
>    CC: stable@vger.kernel.org
>    Signed-off-by: Oliver Neukum <ONeukum@suse.com>
>    Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1aaee5de33d2b615b35afd77cdc6002da8919f0d
>Author: Bin Liu <b-liu@ti.com>
>Date:   Thu May 26 11:43:45 2016 -0500
>
>    usb: gadget: fix spinlock dead lock in gadgetfs
>    
>    [ Upstream commit d246dcb2331c5783743720e6510892eb1d2801d9 ]
>    
>    [   40.467381] =============================================
>    [   40.473013] [ INFO: possible recursive locking detected ]
>    [   40.478651] 4.6.0-08691-g7f3db9a #37 Not tainted
>    [   40.483466] ---------------------------------------------
>    [   40.489098] usb/733 is trying to acquire lock:
>    [   40.493734]  (&(&dev->lock)->rlock){-.....}, at: [<bf129288>] ep0_complete+0x18/0xdc [gadgetfs]
>    [   40.502882]
>    [   40.502882] but task is already holding lock:
>    [   40.508967]  (&(&dev->lock)->rlock){-.....}, at: [<bf12a420>] ep0_read+0x20/0x5e0 [gadgetfs]
>    [   40.517811]
>    [   40.517811] other info that might help us debug this:
>    [   40.524623]  Possible unsafe locking scenario:
>    [   40.524623]
>    [   40.530798]        CPU0
>    [   40.533346]        ----
>    [   40.535894]   lock(&(&dev->lock)->rlock);
>    [   40.540088]   lock(&(&dev->lock)->rlock);
>    [   40.544284]
>    [   40.544284]  *** DEADLOCK ***
>    [   40.544284]
>    [   40.550461]  May be due to missing lock nesting notation
>    [   40.550461]
>    [   40.557544] 2 locks held by usb/733:
>    [   40.561271]  #0:  (&f->f_pos_lock){+.+.+.}, at: [<c02a6114>] __fdget_pos+0x40/0x48
>    [   40.569219]  #1:  (&(&dev->lock)->rlock){-.....}, at: [<bf12a420>] ep0_read+0x20/0x5e0 [gadgetfs]
>    [   40.578523]
>    [   40.578523] stack backtrace:
>    [   40.583075] CPU: 0 PID: 733 Comm: usb Not tainted 4.6.0-08691-g7f3db9a #37
>    [   40.590246] Hardware name: Generic AM33XX (Flattened Device Tree)
>    [   40.596625] [<c010ffbc>] (unwind_backtrace) from [<c010c1bc>] (show_stack+0x10/0x14)
>    [   40.604718] [<c010c1bc>] (show_stack) from [<c04207fc>] (dump_stack+0xb0/0xe4)
>    [   40.612267] [<c04207fc>] (dump_stack) from [<c01886ec>] (__lock_acquire+0xf68/0x1994)
>    [   40.620440] [<c01886ec>] (__lock_acquire) from [<c0189528>] (lock_acquire+0xd8/0x238)
>    [   40.628621] [<c0189528>] (lock_acquire) from [<c06ad6b4>] (_raw_spin_lock_irqsave+0x38/0x4c)
>    [   40.637440] [<c06ad6b4>] (_raw_spin_lock_irqsave) from [<bf129288>] (ep0_complete+0x18/0xdc [gadgetfs])
>    [   40.647339] [<bf129288>] (ep0_complete [gadgetfs]) from [<bf10a728>] (musb_g_giveback+0x118/0x1b0 [musb_hdrc])
>    [   40.657842] [<bf10a728>] (musb_g_giveback [musb_hdrc]) from [<bf108768>] (musb_g_ep0_queue+0x16c/0x188 [musb_hdrc])
>    [   40.668772] [<bf108768>] (musb_g_ep0_queue [musb_hdrc]) from [<bf12a944>] (ep0_read+0x544/0x5e0 [gadgetfs])
>    [   40.678963] [<bf12a944>] (ep0_read [gadgetfs]) from [<c0284470>] (__vfs_read+0x20/0x110)
>    [   40.687414] [<c0284470>] (__vfs_read) from [<c0285324>] (vfs_read+0x88/0x114)
>    [   40.694864] [<c0285324>] (vfs_read) from [<c0286150>] (SyS_read+0x44/0x9c)
>    [   40.702051] [<c0286150>] (SyS_read) from [<c0107820>] (ret_fast_syscall+0x0/0x1c)
>    
>    This is caused by the spinlock bug in ep0_read().
>    Fix the two other deadlock sources in gadgetfs_setup() too.
>    
>    Cc: <stable@vger.kernel.org> # v3.16+
>    Signed-off-by: Bin Liu <b-liu@ti.com>
>    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a56c72fc0cda3382a339172a35c76cea10df72ad
>Author: Steinar H. Gunderson <sesse@google.com>
>Date:   Tue May 24 20:13:15 2016 +0200
>
>    usb: dwc3: exynos: Fix deferred probing storm.
>    
>    [ Upstream commit 4879efb34f7d49235fac334d76d9c6a77a021413 ]
>    
>    dwc3-exynos has two problems during init if the regulators are slow
>    to come up (for instance if the I2C bus driver is not on the initramfs)
>    and return probe deferral. First, every time this happens, the driver
>    leaks the USB phys created; they need to be deallocated on error.
>    
>    Second, since the phy devices are created before the regulators fail,
>    this means that there's a new device to re-trigger deferred probing,
>    which causes it to essentially go into a busy loop of re-probing the
>    device until the regulators come up.
>    
>    Move the phy creation to after the regulators have succeeded, and also
>    fix cleanup on failure. On my ODROID XU4 system (with Debian's initramfs
>    which doesn't contain the I2C driver), this reduces the number of probe
>    attempts (for each of the two controllers) from more than 2000 to eight.
>    
>    Signed-off-by: Steinar H. Gunderson <sesse@google.com>
>    Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>    Reviewed-by: Vivek Gautam <gautam.vivek@samsung.com>
>    Fixes: d720f057fda4 ("usb: dwc3: exynos: add nop transceiver support")
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 01a129f8a323fc3c393a4d55851f5c671f4c9a4e
>Author: Heiko Stuebner <heiko@sntech.de>
>Date:   Tue May 17 20:57:50 2016 +0200
>
>    clk: rockchip: initialize flags of clk_init_data in mmc-phase clock
>    
>    [ Upstream commit 595144c1141c951a3c6bb9004ae6a2bc29aad66f ]
>    
>    The flags element of clk_init_data was never initialized for mmc-
>    phase-clocks resulting in the element containing a random value
>    and thus possibly enabling unwanted clock flags.
>    
>    Fixes: 89bf26cbc1a0 ("clk: rockchip: Add support for the mmc clock phases using the framework")
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 039f59796079951d6e0ffb40d7882b5597e5e16c
>Author: Ludovic Desroches <ludovic.desroches@atmel.com>
>Date:   Thu May 12 16:54:10 2016 +0200
>
>    dmaengine: at_xdmac: double FIFO flush needed to compute residue
>    
>    [ Upstream commit 9295c41d77ca93aac79cfca6fa09fa1ca5cab66f ]
>    
>    Due to the way CUBC register is updated, a double flush is needed to
>    compute an accurate residue. First flush aim is to get data from the DMA
>    FIFO and second one ensures that we won't report data which are not in
>    memory.
>    
>    Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
>    Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel
>    eXtended DMA Controller driver")
>    Cc: stable@vger.kernel.org #v4.1 and later
>    Reviewed-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6d8fde793d0efbf1e48bca89ee261c18ddafea84
>Author: Ludovic Desroches <ludovic.desroches@atmel.com>
>Date:   Thu May 12 16:54:09 2016 +0200
>
>    dmaengine: at_xdmac: fix residue corruption
>    
>    [ Upstream commit 53398f488821c2b5b15291e3debec6ad33f75d3d ]
>    
>    An unexpected value of CUBC can lead to a corrupted residue. A more
>    complex sequence is needed to detect an inaccurate value for NCA or CUBC.
>    
>    Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
>    Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel
>    eXtended DMA Controller driver")
>    Cc: stable@vger.kernel.org #v4.1 and later
>    Reviewed-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c6ec15d8965d03a604bdcfde28a5c506b9de7043
>Author: Ludovic Desroches <ludovic.desroches@atmel.com>
>Date:   Thu May 12 16:54:08 2016 +0200
>
>    dmaengine: at_xdmac: align descriptors on 64 bits
>    
>    [ Upstream commit 4a9723e8df68cfce4048517ee32e37f78854b6fb ]
>    
>    Having descriptors aligned on 64 bits allows update CNDA and CUBC in an
>    atomic way.
>    
>    Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
>    Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel
>    eXtended DMA Controller driver")
>    Cc: stable@vger.kernel.org #v4.1 and later
>    Reviewed-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6ef304587cf41e19312fa9fd81448ea6880ad475
>Author: Wenwei Tao <ww.tao0320@gmail.com>
>Date:   Fri May 13 22:59:20 2016 +0800
>
>    cgroup: remove redundant cleanup in css_create
>    
>    [ Upstream commit b00c52dae6d9ee8d0f2407118ef6544ae5524781 ]
>    
>    When create css failed, before call css_free_rcu_fn, we remove the css
>    id and exit the percpu_ref, but we will do these again in
>    css_free_work_fn, so they are redundant.  Especially the css id, that
>    would cause problem if we remove it twice, since it may be assigned to
>    another css after the first remove.
>    
>    tj: This was broken by two commits updating the free path without
>        synchronizing the creation failure path.  This can be easily
>        triggered by trying to create more than 64k memory cgroups.
>    
>    Signed-off-by: Wenwei Tao <ww.tao0320@gmail.com>
>    Signed-off-by: Tejun Heo <tj@kernel.org>
>    Cc: Vladimir Davydov <vdavydov@parallels.com>
>    Fixes: 9a1049da9bd2 ("percpu-refcount: require percpu_ref to be exited explicitly")
>    Fixes: 01e586598b22 ("cgroup: release css->id after css_free")
>    Cc: stable@vger.kernel.org # v3.17+
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 62f7175fa64005be2e090618da5a20f87752704d
>Author: Tejun Heo <tj@kernel.org>
>Date:   Wed May 25 11:48:25 2016 -0400
>
>    percpu: fix synchronization between synchronous map extension and chunk destruction
>    
>    [ Upstream commit 6710e594f71ccaad8101bc64321152af7cd9ea28 ]
>    
>    For non-atomic allocations, pcpu_alloc() can try to extend the area
>    map synchronously after dropping pcpu_lock; however, the extension
>    wasn't synchronized against chunk destruction and the chunk might get
>    freed while extension is in progress.
>    
>    This patch fixes the bug by putting most of non-atomic allocations
>    under pcpu_alloc_mutex to synchronize against pcpu_balance_work which
>    is responsible for async chunk management including destruction.
>    
>    Signed-off-by: Tejun Heo <tj@kernel.org>
>    Reported-and-tested-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
>    Reported-by: Vlastimil Babka <vbabka@suse.cz>
>    Reported-by: Sasha Levin <sasha.levin@oracle.com>
>    Cc: stable@vger.kernel.org # v3.18+
>    Fixes: 1a4d76076cda ("percpu: implement asynchronous chunk population")
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d273823dc63bb51e3adc11e0f7c324d86e2d2009
>Author: Tejun Heo <tj@kernel.org>
>Date:   Wed May 25 11:48:25 2016 -0400
>
>    percpu: fix synchronization between chunk->map_extend_work and chunk destruction
>    
>    [ Upstream commit 4f996e234dad488e5d9ba0858bc1bae12eff82c3 ]
>    
>    Atomic allocations can trigger async map extensions which is serviced
>    by chunk->map_extend_work.  pcpu_balance_work which is responsible for
>    destroying idle chunks wasn't synchronizing properly against
>    chunk->map_extend_work and may end up freeing the chunk while the work
>    item is still in flight.
>    
>    This patch fixes the bug by rolling async map extension operations
>    into pcpu_balance_work.
>    
>    Signed-off-by: Tejun Heo <tj@kernel.org>
>    Reported-and-tested-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
>    Reported-by: Vlastimil Babka <vbabka@suse.cz>
>    Reported-by: Sasha Levin <sasha.levin@oracle.com>
>    Cc: stable@vger.kernel.org # v3.18+
>    Fixes: 9c824b6a172c ("percpu: make sure chunk->map array has available space")
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 272d474fc6e9e4362c69df4b77adc0008b53b4ad
>Author: Rainer Weikusat <rweikusat@mobileactivedefense.com>
>Date:   Sun Jan 3 18:56:38 2016 +0000
>
>    af_unix: Fix splice-bind deadlock
>    
>    [ Upstream commit c845acb324aa85a39650a14e7696982ceea75dc1 ]
>    
>    On 2015/11/06, Dmitry Vyukov reported a deadlock involving the splice
>    system call and AF_UNIX sockets,
>    
>    http://lists.openwall.net/netdev/2015/11/06/24
>    
>    The situation was analyzed as
>    
>    (a while ago) A: socketpair()
>    B: splice() from a pipe to /mnt/regular_file
>    	does sb_start_write() on /mnt
>    C: try to freeze /mnt
>    	wait for B to finish with /mnt
>    A: bind() try to bind our socket to /mnt/new_socket_name
>    	lock our socket, see it not bound yet
>    	decide that it needs to create something in /mnt
>    	try to do sb_start_write() on /mnt, block (it's
>    	waiting for C).
>    D: splice() from the same pipe to our socket
>    	lock the pipe, see that socket is connected
>    	try to lock the socket, block waiting for A
>    B:	get around to actually feeding a chunk from
>    	pipe to file, try to lock the pipe.  Deadlock.
>    
>    on 2015/11/10 by Al Viro,
>    
>    http://lists.openwall.net/netdev/2015/11/10/4
>    
>    The patch fixes this by removing the kern_path_create related code from
>    unix_mknod and executing it as part of unix_bind prior acquiring the
>    readlock of the socket in question. This means that A (as used above)
>    will sb_start_write on /mnt before it acquires the readlock, hence, it
>    won't indirectly block B which first did a sb_start_write and then
>    waited for a thread trying to acquire the readlock. Consequently, A
>    being blocked by C waiting for B won't cause a deadlock anymore
>    (effectively, both A and B acquire two locks in opposite order in the
>    situation described above).
>    
>    Dmitry Vyukov(<dvyukov@google.com>) tested the original patch.
>    
>    Signed-off-by: Rainer Weikusat <rweikusat@mobileactivedefense.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 95123c0b81d9478b8155fe15093b88f57ef7d0bd
>Author: Sasha Levin <sasha.levin@oracle.com>
>Date:   Wed Jun 22 23:59:54 2016 -0400
>
>    Linux 4.1.27
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7cf9f2300c12ba5fba23e7c61a3477927b0cc6d1
>Author: Andy Lutomirski <luto@kernel.org>
>Date:   Tue May 24 15:13:02 2016 -0700
>
>    uvc: Forward compat ioctls to their handlers directly
>    
>    [ Upstream commit a44323e2a8f342848bb77e8e04fcd85fcb91b3b4 ]
>    
>    The current code goes through a lot of indirection just to call a
>    known handler.  Simplify it: just call the handlers directly.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Andy Lutomirski <luto@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ca1950cd168857c811f217a390ed8c91b57d2c09
>Author: Jann Horn <jannh@google.com>
>Date:   Wed Jun 1 11:55:06 2016 +0200
>
>    ecryptfs: forbid opening files without mmap handler
>    
>    [ Upstream commit 2f36db71009304b3f0b95afacd8eba1f9f046b87 ]
>    
>    This prevents users from triggering a stack overflow through a recursive
>    invocation of pagefault handling that involves mapping procfs files into
>    virtual memory.
>    
>    Signed-off-by: Jann Horn <jannh@google.com>
>    Acked-by: Tyler Hicks <tyhicks@canonical.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c96e6bf5705254a4c93ca25d6d3c68a04fc7ab5b
>Author: Jann Horn <jannh@google.com>
>Date:   Wed Jun 1 11:55:05 2016 +0200
>
>    proc: prevent stacking filesystems on top
>    
>    [ Upstream commit e54ad7f1ee263ffa5a2de9c609d58dfa27b21cd9 ]
>    
>    This prevents stacking filesystems (ecryptfs and overlayfs) from using
>    procfs as lower filesystem.  There is too much magic going on inside
>    procfs, and there is no good reason to stack stuff on top of procfs.
>    
>    (For example, procfs does access checks in VFS open handlers, and
>    ecryptfs by design calls open handlers from a kernel thread that doesn't
>    drop privileges or so.)
>    
>    Signed-off-by: Jann Horn <jannh@google.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e90b6fdf60b1e5b292c0b8a4eacc862da97e46fc
>Author: Prasun Maiti <prasunmaiti87@gmail.com>
>Date:   Mon Jun 6 20:04:19 2016 +0530
>
>    wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel
>    
>    [ Upstream commit 3d5fdff46c4b2b9534fa2f9fc78e90a48e0ff724 ]
>    
>    iwpriv app uses iw_point structure to send data to Kernel. The iw_point
>    structure holds a pointer. For compatibility Kernel converts the pointer
>    as required for WEXT IOCTLs (SIOCIWFIRST to SIOCIWLAST). Some drivers
>    may use iw_handler_def.private_args to populate iwpriv commands instead
>    of iw_handler_def.private. For those case, the IOCTLs from
>    SIOCIWFIRSTPRIV to SIOCIWLASTPRIV will follow the path ndo_do_ioctl().
>    Accordingly when the filled up iw_point structure comes from 32 bit
>    iwpriv to 64 bit Kernel, Kernel will not convert the pointer and sends
>    it to driver. So, the driver may get the invalid data.
>    
>    The pointer conversion for the IOCTLs (SIOCIWFIRSTPRIV to
>    SIOCIWLASTPRIV), which follow the path ndo_do_ioctl(), is mandatory.
>    This patch adds pointer conversion from 32 bit to 64 bit and vice versa,
>    if the ioctl comes from 32 bit iwpriv to 64 bit Kernel.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Prasun Maiti <prasunmaiti87@gmail.com>
>    Signed-off-by: Ujjal Roy <royujjal@gmail.com>
>    Tested-by: Dibyajyoti Ghosh <dibyajyotig@gmail.com>
>    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8921c300bb0f67ddced9e50330b894556c72c87d
>Author: Ben Dooks <ben.dooks@codethink.co.uk>
>Date:   Tue Jun 7 17:22:17 2016 +0100
>
>    gpio: bcm-kona: fix bcm_kona_gpio_reset() warnings
>    
>    [ Upstream commit b66b2a0adf0e48973b582e055758b9907a7eee7c ]
>    
>    The bcm_kona_gpio_reset() calls bcm_kona_gpio_write_lock_regs()
>    with what looks like the wrong parameter. The write_lock_regs
>    function takes a pointer to the registers, not the bcm_kona_gpio
>    structure.
>    
>    Fix the warning, and probably bug by changing the function to
>    pass reg_base instead of kona_gpio, fixing the following warning:
>    
>    drivers/gpio/gpio-bcm-kona.c:550:47: warning: incorrect type in argument 1
>      (different address spaces)
>      expected void [noderef] <asn:2>*reg_base
>      got struct bcm_kona_gpio *kona_gpio
>      warning: incorrect type in argument 1 (different address spaces)
>      expected void [noderef] <asn:2>*reg_base
>      got struct bcm_kona_gpio *kona_gpio
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
>    Acked-by: Ray Jui <ray.jui@broadcom.com>
>    Reviewed-by: Markus Mayer <mmayer@broadcom.com>
>    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 796795362c839447eadc671420f8c4bdd1deb182
>Author: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
>Date:   Fri Jun 3 19:10:01 2016 +0200
>
>    gpiolib: Fix NULL pointer deference
>    
>    [ Upstream commit 11f33a6d15bfa397867ac0d7f3481b6dd683286f ]
>    
>    Under some circumstances, a gpiochip might be half cleaned from the
>    gpio_device list.
>    
>    This patch makes sure that the chip pointer is still valid, before
>    calling the match function.
>    
>    [  104.088296] BUG: unable to handle kernel NULL pointer dereference at
>    0000000000000090
>    [  104.089772] IP: [<ffffffff813d2045>] of_gpiochip_find_and_xlate+0x15/0x80
>    [  104.128273] Call Trace:
>    [  104.129802]  [<ffffffff813d2030>] ? of_parse_own_gpio+0x1f0/0x1f0
>    [  104.131353]  [<ffffffff813cd910>] gpiochip_find+0x60/0x90
>    [  104.132868]  [<ffffffff813d21ba>] of_get_named_gpiod_flags+0x9a/0x120
>    ...
>    [  104.141586]  [<ffffffff8163d12b>] gpio_led_probe+0x11b/0x360
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
>    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7296467cfbe04536b8ccec5345a1fd0a2cab1cdc
>Author: Al Viro <viro@zeniv.linux.org.uk>
>Date:   Tue Jun 7 21:26:55 2016 -0400
>
>    fix d_walk()/non-delayed __d_free() race
>    
>    [ Upstream commit 3d56c25e3bb0726a5c5e16fc2d9e38f8ed763085 ]
>    
>    Ascend-to-parent logics in d_walk() depends on all encountered child
>    dentries not getting freed without an RCU delay.  Unfortunately, in
>    quite a few cases it is not true, with hard-to-hit oopsable race as
>    the result.
>    
>    Fortunately, the fix is simiple; right now the rule is "if it ever
>    been hashed, freeing must be delayed" and changing it to "if it
>    ever had a parent, freeing must be delayed" closes that hole and
>    covers all cases the old rule used to cover.  Moreover, pipes and
>    sockets remain _not_ covered, so we do not introduce RCU delay in
>    the cases which are the reason for having that delay conditional
>    in the first place.
>    
>    Cc: stable@vger.kernel.org # v3.2+ (and watch out for __d_materialise_dentry())
>    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1dbd163a91b5e778fe757cfa6286d3a7c0b7dc32
>Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
>Date:   Tue Jun 7 17:38:53 2016 -0700
>
>    cpufreq: intel_pstate: Fix ->set_policy() interface for no_turbo
>    
>    [ Upstream commit 983e600e88835f0321d1a0ea06f52d48b7b5a544 ]
>    
>    When turbo is disabled, the ->set_policy() interface is broken.
>    
>    For example, when turbo is disabled and cpuinfo.max = 2900000 (full
>    max turbo frequency), setting the limits results in frequency less
>    than the requested one:
>    Set 1000000 KHz results in 0700000 KHz
>    Set 1500000 KHz results in 1100000 KHz
>    Set 2000000 KHz results in  1500000 KHz
>    
>    This is because the limits->max_perf fraction is calculated using
>    the max turbo frequency as the reference, but when the max P-State is
>    capped in intel_pstate_get_min_max(), the reference is not the max
>    turbo P-State. This results in reducing max P-State.
>    
>    One option is to always use max turbo as reference for calculating
>    limits. But this will not be correct. By definition the intel_pstate
>    sysfs limits, shows percentage of available performance. So when
>    BIOS has disabled turbo, the available performance is max non turbo.
>    So the max_perf_pct should still show 100%.
>    
>    Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
>    [ rjw : Subject & changelog, rewrite in fewer lines of code ]
>    Cc: All applicable <stable@vger.kernel.org>
>    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d6126a7032f4af5477dedf6ca9c6f1ee3498135a
>Author: Sasha Levin <sasha.levin@oracle.com>
>Date:   Fri Jun 17 17:30:50 2016 -0400
>
>    of: fix autoloading due to broken modalias with no 'compatible'
>    
>    [ Upstream commit b3c0a4dab7e35a9b6d69c0415641d2280fdefb2b ]
>    
>    Because of an improper dereference, a stray 'C' character was output to
>    the modalias when no 'compatible' was specified. This is the case for
>    some old PowerMac drivers which only set the 'name' property. Fix it to
>    let them match again.
>    
>    Reported-by: Mathieu Malaterre <malat@debian.org>
>    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
>    Tested-by: Mathieu Malaterre <malat@debian.org>
>    Cc: Philipp Zabel <p.zabel@pengutronix.de>
>    Cc: Andreas Schwab <schwab@linux-m68k.org>
>    Fixes: 6543becf26fff6 ("mod/file2alias: make modalias generation safe for cross compiling")
>    Cc: stable@vger.kernel.org # v3.9+
>    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7c630ac4bf02eea4f0eb2aa266877b5d9c9d7efd
>Author: Michael Ellerman <mpe@ellerman.id.au>
>Date:   Wed Jun 8 10:01:23 2016 +1000
>
>    powerpc/pseries: Fix IBM_ARCH_VEC_NRCORES_OFFSET since POWER8NVL was added
>    
>    [ Upstream commit 2c2a63e301fd19ccae673e79de59b30a232ff7f9 ]
>    
>    The recent commit 7cc851039d64 ("powerpc/pseries: Add POWER8NVL support
>    to ibm,client-architecture-support call") added a new PVR mask & value
>    to the start of the ibm_architecture_vec[] array.
>    
>    However it missed the fact that further down in the array, we hard code
>    the offset of one of the fields, and then at boot use that value to
>    patch the value in the array. This means every update to the array must
>    also update the #define, ugh.
>    
>    This means that on pseries machines we will misreport to firmware the
>    number of cores we support, by a factor of threads_per_core.
>    
>    Fix it for now by updating the #define.
>    
>    Fixes: 7cc851039d64 ("powerpc/pseries: Add POWER8NVL support to ibm,client-architecture-support call")
>    Cc: stable@vger.kernel.org # v4.0+
>    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f0461457f13c2c7441b86a830c52724ec928b9ab
>Author: H. Peter Anvin <hpa@zytor.com>
>Date:   Tue Apr 5 17:01:33 2016 -0700
>
>    x86, build: copy ldlinux.c32 to image.iso
>    
>    [ Upstream commit 9c77679cadb118c0aa99e6f88533d91765a131ba ]
>    
>    For newer versions of Syslinux, we need ldlinux.c32 in addition to
>    isolinux.bin to reside on the boot disk, so if the latter is found,
>    copy it, too, to the isoimage tree.
>    
>    Signed-off-by: H. Peter Anvin <hpa@zytor.com>
>    Cc: Linux Stable Tree <stable@vger.kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 02813a36b33b46d5be433f230de2f064cb6c504b
>Author: Torsten Hilbrich <torsten.hilbrich@secunet.com>
>Date:   Tue Jun 7 13:14:21 2016 +0200
>
>    ALSA: hda/realtek: Add T560 docking unit fixup
>    
>    [ Upstream commit dab38e43b298501a4e8807b56117c029e2e98383 ]
>    
>    Tested with Lenovo Ultradock. Fixes the non-working headphone jack on
>    the docking unit.
>    
>    Signed-off-by: Torsten Hilbrich <torsten.hilbrich@secunet.com>
>    Tested-by: Torsten Hilbrich <torsten.hilbrich@secunet.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f530dd0176f24aa31dd76672777de06f735d7bdc
>Author: Eric W. Biederman <ebiederm@xmission.com>
>Date:   Fri May 27 14:50:05 2016 -0500
>
>    mnt: fs_fully_visible test the proper mount for MNT_LOCKED
>    
>    [ Upstream commit d71ed6c930ac7d8f88f3cef6624a7e826392d61f ]
>    
>    MNT_LOCKED implies on a child mount implies the child is locked to the
>    parent.  So while looping through the children the children should be
>    tested (not their parent).
>    
>    Typically an unshare of a mount namespace locks all mounts together
>    making both the parent and the slave as locked but there are a few
>    corner cases where other things work.
>    
>    Cc: stable@vger.kernel.org
>    Fixes: ceeb0e5d39fc ("vfs: Ignore unlocked mounts in fs_fully_visible")
>    Reported-by: Seth Forshee <seth.forshee@canonical.com>
>    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit fced2a819164c305544bcc8d9a45beea15374528
>Author: Eric W. Biederman <ebiederm@xmission.com>
>Date:   Mon Jun 6 15:36:07 2016 -0500
>
>    mnt: If fs_fully_visible fails call put_filesystem.
>    
>    [ Upstream commit 97c1df3e54e811aed484a036a798b4b25d002ecf ]
>    
>    Add this trivial missing error handling.
>    
>    Cc: stable@vger.kernel.org
>    Fixes: 1b852bceb0d1 ("mnt: Refactor the logic for mounting sysfs and proc in a user namespace")
>    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit eb1eba6ac8e902b378d1196acb1026e91c40e736
>Author: Helge Deller <deller@gmx.de>
>Date:   Sat Jun 4 17:21:33 2016 +0200
>
>    parisc: Fix pagefault crash in unaligned __get_user() call
>    
>    [ Upstream commit 8b78f260887df532da529f225c49195d18fef36b ]
>    
>    One of the debian buildd servers had this crash in the syslog without
>    any other information:
>    
>     Unaligned handler failed, ret = -2
>     clock_adjtime (pid 22578): Unaligned data reference (code 28)
>     CPU: 1 PID: 22578 Comm: clock_adjtime Tainted: G  E  4.5.0-2-parisc64-smp #1 Debian 4.5.4-1
>     task: 000000007d9960f8 ti: 00000001bde7c000 task.ti: 00000001bde7c000
>    
>          YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
>     PSW: 00001000000001001111100000001111 Tainted: G            E
>     r00-03  000000ff0804f80f 00000001bde7c2b0 00000000402d2be8 00000001bde7c2b0
>     r04-07  00000000409e1fd0 00000000fa6f7fff 00000001bde7c148 00000000fa6f7fff
>     r08-11  0000000000000000 00000000ffffffff 00000000fac9bb7b 000000000002b4d4
>     r12-15  000000000015241c 000000000015242c 000000000000002d 00000000fac9bb7b
>     r16-19  0000000000028800 0000000000000001 0000000000000070 00000001bde7c218
>     r20-23  0000000000000000 00000001bde7c210 0000000000000002 0000000000000000
>     r24-27  0000000000000000 0000000000000000 00000001bde7c148 00000000409e1fd0
>     r28-31  0000000000000001 00000001bde7c320 00000001bde7c350 00000001bde7c218
>     sr00-03  0000000001200000 0000000001200000 0000000000000000 0000000001200000
>     sr04-07  0000000000000000 0000000000000000 0000000000000000 0000000000000000
>    
>     IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000402d2e84 00000000402d2e88
>      IIR: 0ca0d089    ISR: 0000000001200000  IOR: 00000000fa6f7fff
>      CPU:        1   CR30: 00000001bde7c000 CR31: ffffffffffffffff
>      ORIG_R28: 00000002369fe628
>      IAOQ[0]: compat_get_timex+0x2dc/0x3c0
>      IAOQ[1]: compat_get_timex+0x2e0/0x3c0
>      RP(r2): compat_get_timex+0x40/0x3c0
>     Backtrace:
>      [<00000000402d4608>] compat_SyS_clock_adjtime+0x40/0xc0
>      [<0000000040205024>] syscall_exit+0x0/0x14
>    
>    This means the userspace program clock_adjtime called the clock_adjtime()
>    syscall and then crashed inside the compat_get_timex() function.
>    Syscalls should never crash programs, but instead return EFAULT.
>    
>    The IIR register contains the executed instruction, which disassebles
>    into "ldw 0(sr3,r5),r9".
>    This load-word instruction is part of __get_user() which tried to read the word
>    at %r5/IOR (0xfa6f7fff). This means the unaligned handler jumped in.  The
>    unaligned handler is able to emulate all ldw instructions, but it fails if it
>    fails to read the source e.g. because of page fault.
>    
>    The following program reproduces the problem:
>    
>    #define _GNU_SOURCE
>    #include <unistd.h>
>    #include <sys/syscall.h>
>    #include <sys/mman.h>
>    
>    int main(void) {
>            /* allocate 8k */
>            char *ptr = mmap(NULL, 2*4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
>            /* free second half (upper 4k) and make it invalid. */
>            munmap(ptr+4096, 4096);
>            /* syscall where first int is unaligned and clobbers into invalid memory region */
>            /* syscall should return EFAULT */
>            return syscall(__NR_clock_adjtime, 0, ptr+4095);
>    }
>    
>    To fix this issue we simply need to check if the faulting instruction address
>    is in the exception fixup table when the unaligned handler failed. If it
>    is, call the fixup routine instead of crashing.
>    
>    While looking at the unaligned handler I found another issue as well: The
>    target register should not be modified if the handler was unsuccessful.
>    
>    Signed-off-by: Helge Deller <deller@gmx.de>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7c8f7a240e802368d9788cc62cd2324dac53e735
>Author: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>Date:   Sat May 28 23:02:50 2016 +0300
>
>    of: irq: fix of_irq_get[_byname]() kernel-doc
>    
>    [ Upstream commit 3993546646baf1dab5f5c4f7d9bb58f2046fd1c1 ]
>    
>    The kernel-doc for the of_irq_get[_byname]()  is clearly inadequate in
>    describing the return values -- of_irq_get_byname() is documented better
>    than of_irq_get() but it  still doesn't mention that 0 is returned iff
>    irq_create_of_mapping() fails (it doesn't return an error code in this
>    case). Document all possible return value variants, making the writing
>    of the word "IRQ" consistent, while at it...
>    
>    Fixes: 9ec36cafe43b ("of/irq: do irq resolution in platform_get_irq")
>    Fixes: ad69674e73a1 ("of/irq: do irq resolution in platform_get_irq_byname()")
>    Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>    CC: stable@vger.kernel.org
>    Signed-off-by: Rob Herring <robh@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3821aa37f7bd4a98d7c9f01eb915cdae06dde1fb
>Author: Tony Luck <tony.luck@intel.com>
>Date:   Tue May 31 11:50:28 2016 -0700
>
>    EDAC, sb_edac: Fix rank lookup on Broadwell
>    
>    [ Upstream commit c7103f650a11328f28b9fa1c95027db331b7774b ]
>    
>    Broadwell made a small change to the rank target register moving the
>    target rank ID field up from bits 16:19 to bits 20:23.
>    
>    Also found that the offset field grew by one bit in the IVY_BRIDGE to
>    HASWELL transition, so fix the RIR_OFFSET() macro too.
>    
>    Signed-off-by: Tony Luck <tony.luck@intel.com>
>    Cc: stable@vger.kernel.org # v3.19+
>    Cc: Aristeu Rozanski <arozansk@redhat.com>
>    Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
>    Cc: linux-edac <linux-edac@vger.kernel.org>
>    Link: http://lkml.kernel.org/r/2943fb819b1f7e396681165db9c12bb3df0e0b16.1464735623.git.tony.luck@intel.com
>    Signed-off-by: Borislav Petkov <bp@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f518d7a9791398c181e77b0f645802678055a554
>Author: AceLan Kao <acelan.kao@canonical.com>
>Date:   Fri Jun 3 14:45:25 2016 +0800
>
>    ALSA: hda - Fix headset mic detection problem for Dell machine
>    
>    [ Upstream commit f90d83b301701026b2e4c437a3613f377f63290e ]
>    
>    Add the pin configuration value of this machine into the pin_quirk
>    table to make DELL1_MIC_NO_PRESENCE apply to this machine.
>    
>    Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5ec6f21ee5c6d2207708a8469771efbde823488f
>Author: Chris Wilson <chris@chris-wilson.co.uk>
>Date:   Thu May 26 21:08:17 2016 +0100
>
>    locking/ww_mutex: Report recursive ww_mutex locking early
>    
>    [ Upstream commit 0422e83d84ae24b933e4b0d4c1e0f0b4ae8a0a3b ]
>    
>    Recursive locking for ww_mutexes was originally conceived as an
>    exception. However, it is heavily used by the DRM atomic modesetting
>    code. Currently, the recursive deadlock is checked after we have queued
>    up for a busy-spin and as we never release the lock, we spin until
>    kicked, whereupon the deadlock is discovered and reported.
>    
>    A simple solution for the now common problem is to move the recursive
>    deadlock discovery to the first action when taking the ww_mutex.
>    
>    Suggested-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>    Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>    Cc: Andrew Morton <akpm@linux-foundation.org>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Cc: stable@vger.kernel.org
>    Link: http://lkml.kernel.org/r/1464293297-19777-1-git-send-email-chris@chris-wilson.co.uk
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c0410f18e2b4f62090b04743f0d5d8e672335225
>Author: Marc Zyngier <marc.zyngier@arm.com>
>Date:   Thu Jun 2 09:00:28 2016 +0100
>
>    irqchip/gic-v3: Fix ICC_SGI1R_EL1.INTID decoding mask
>    
>    [ Upstream commit dd5f1b049dc139876801db3cdd0f20d21fd428cc ]
>    
>    The INTID mask is wrong, and is made a signed value, which has
>    nteresting effects in the KVM emulation. Let's sanitize it.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 839c2669344ed8c10f3b6f968c467071b6288067
>Author: Paolo Bonzini <pbonzini@redhat.com>
>Date:   Wed Jun 1 14:09:23 2016 +0200
>
>    KVM: x86: fix OOPS after invalid KVM_SET_DEBUGREGS
>    
>    [ Upstream commit d14bdb553f9196169f003058ae1cdabe514470e6 ]
>    
>    MOV to DR6 or DR7 causes a #GP if an attempt is made to write a 1 to
>    any of bits 63:32.  However, this is not detected at KVM_SET_DEBUGREGS
>    time, and the next KVM_RUN oopses:
>    
>       general protection fault: 0000 [#1] SMP
>       CPU: 2 PID: 14987 Comm: a.out Not tainted 4.4.9-300.fc23.x86_64 #1
>       Hardware name: LENOVO 2325F51/2325F51, BIOS G2ET32WW (1.12 ) 05/30/2012
>       [...]
>       Call Trace:
>        [<ffffffffa072c93d>] kvm_arch_vcpu_ioctl_run+0x141d/0x14e0 [kvm]
>        [<ffffffffa071405d>] kvm_vcpu_ioctl+0x33d/0x620 [kvm]
>        [<ffffffff81241648>] do_vfs_ioctl+0x298/0x480
>        [<ffffffff812418a9>] SyS_ioctl+0x79/0x90
>        [<ffffffff817a0f2e>] entry_SYSCALL_64_fastpath+0x12/0x71
>       Code: 55 83 ff 07 48 89 e5 77 27 89 ff ff 24 fd 90 87 80 81 0f 23 fe 5d c3 0f 23 c6 5d c3 0f 23 ce 5d c3 0f 23 d6 5d c3 0f 23 de 5d c3 <0f> 23 f6 5d c3 0f 0b 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00
>       RIP  [<ffffffff810639eb>] native_set_debugreg+0x2b/0x40
>        RSP <ffff88005836bd50>
>    
>    Testcase (beautified/reduced from syzkaller output):
>    
>        #include <unistd.h>
>        #include <sys/syscall.h>
>        #include <string.h>
>        #include <stdint.h>
>        #include <linux/kvm.h>
>        #include <fcntl.h>
>        #include <sys/ioctl.h>
>    
>        long r[8];
>    
>        int main()
>        {
>            struct kvm_debugregs dr = { 0 };
>    
>            r[2] = open("/dev/kvm", O_RDONLY);
>            r[3] = ioctl(r[2], KVM_CREATE_VM, 0);
>            r[4] = ioctl(r[3], KVM_CREATE_VCPU, 7);
>    
>            memcpy(&dr,
>                   "\x5d\x6a\x6b\xe8\x57\x3b\x4b\x7e\xcf\x0d\xa1\x72"
>                   "\xa3\x4a\x29\x0c\xfc\x6d\x44\x00\xa7\x52\xc7\xd8"
>                   "\x00\xdb\x89\x9d\x78\xb5\x54\x6b\x6b\x13\x1c\xe9"
>                   "\x5e\xd3\x0e\x40\x6f\xb4\x66\xf7\x5b\xe3\x36\xcb",
>                   48);
>            r[7] = ioctl(r[4], KVM_SET_DEBUGREGS, &dr);
>            r[6] = ioctl(r[4], KVM_RUN, 0);
>        }
>    
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>    Signed-off-by: Radim KrÄmÃ¡Å <rkrcmar@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f9301f929c0a02505a1e151b636c5a9af4f04bfc
>Author: Paolo Bonzini <pbonzini@redhat.com>
>Date:   Wed Jun 1 14:09:21 2016 +0200
>
>    KVM: irqfd: fix NULL pointer dereference in kvm_irq_map_gsi
>    
>    [ Upstream commit c622a3c21ede892e370b56e1ceb9eb28f8bbda6b ]
>    
>    Found by syzkaller:
>    
>        BUG: unable to handle kernel NULL pointer dereference at 0000000000000120
>        IP: [<ffffffffa0797202>] kvm_irq_map_gsi+0x12/0x90 [kvm]
>        PGD 6f80b067 PUD b6535067 PMD 0
>        Oops: 0000 [#1] SMP
>        CPU: 3 PID: 4988 Comm: a.out Not tainted 4.4.9-300.fc23.x86_64 #1
>        [...]
>        Call Trace:
>         [<ffffffffa0795f62>] irqfd_update+0x32/0xc0 [kvm]
>         [<ffffffffa0796c7c>] kvm_irqfd+0x3dc/0x5b0 [kvm]
>         [<ffffffffa07943f4>] kvm_vm_ioctl+0x164/0x6f0 [kvm]
>         [<ffffffff81241648>] do_vfs_ioctl+0x298/0x480
>         [<ffffffff812418a9>] SyS_ioctl+0x79/0x90
>         [<ffffffff817a1062>] tracesys_phase2+0x84/0x89
>        Code: b5 71 a7 e0 5b 41 5c 41 5d 5d f3 c3 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 8b 8f 10 2e 00 00 31 c0 48 89 e5 <39> 91 20 01 00 00 76 6a 48 63 d2 48 8b 94 d1 28 01 00 00 48 85
>        RIP  [<ffffffffa0797202>] kvm_irq_map_gsi+0x12/0x90 [kvm]
>         RSP <ffff8800926cbca8>
>        CR2: 0000000000000120
>    
>    Testcase:
>    
>        #include <unistd.h>
>        #include <sys/syscall.h>
>        #include <string.h>
>        #include <stdint.h>
>        #include <linux/kvm.h>
>        #include <fcntl.h>
>        #include <sys/ioctl.h>
>    
>        long r[26];
>    
>        int main()
>        {
>            memset(r, -1, sizeof(r));
>            r[2] = open("/dev/kvm", 0);
>            r[3] = ioctl(r[2], KVM_CREATE_VM, 0);
>    
>            struct kvm_irqfd ifd;
>            ifd.fd = syscall(SYS_eventfd2, 5, 0);
>            ifd.gsi = 3;
>            ifd.flags = 2;
>            ifd.resamplefd = ifd.fd;
>            r[25] = ioctl(r[3], KVM_IRQFD, &ifd);
>            return 0;
>        }
>    
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>    Signed-off-by: Radim KrÄmÃ¡Å <rkrcmar@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5642859e6a68f8c8c1e0c5163fad29ad4497f6f5
>Author: Russell King <rmk+kernel@armlinux.org.uk>
>Date:   Mon May 30 23:14:56 2016 +0100
>
>    ARM: fix PTRACE_SETVFPREGS on SMP systems
>    
>    [ Upstream commit e2dfb4b880146bfd4b6aa8e138c0205407cebbaf ]
>    
>    PTRACE_SETVFPREGS fails to properly mark the VFP register set to be
>    reloaded, because it undoes one of the effects of vfp_flush_hwstate().
>    
>    Specifically vfp_flush_hwstate() sets thread->vfpstate.hard.cpu to
>    an invalid CPU number, but vfp_set() overwrites this with the original
>    CPU number, thereby rendering the hardware state as apparently "valid",
>    even though the software state is more recent.
>    
>    Fix this by reverting the previous change.
>    
>    Cc: <stable@vger.kernel.org>
>    Fixes: 8130b9d7b9d8 ("ARM: 7308/1: vfp: flush thread hwstate before copying ptrace registers")
>    Acked-by: Will Deacon <will.deacon@arm.com>
>    Tested-by: Simon Marchi <simon.marchi@ericsson.com>
>    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 34e6c73e0bebcec0ff4788170b1abd51cbf683ad
>Author: Ben Skeggs <bskeggs@redhat.com>
>Date:   Thu Jun 2 12:23:31 2016 +1000
>
>    drm/nouveau/fbcon: fix out-of-bounds memory accesses
>    
>    [ Upstream commit f045f459d925138fe7d6193a8c86406bda7e49da ]
>    
>    Reported by KASAN.
>    
>    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 063c66caefc18d026a1f9d5c49bf6bf761feb318
>Author: Ben Skeggs <bskeggs@redhat.com>
>Date:   Wed Jun 1 16:20:10 2016 +1000
>
>    drm/nouveau/gr/gf100-: update sm error decoding from gk20a nvgpu headers
>    
>    [ Upstream commit 383d0a419f8e63e3d65e706c3c515fa9505ce364 ]
>    
>    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3d69d142d6431c9daecc6e47daf22abd386311af
>Author: Ilia Mirkin <imirkin@alum.mit.edu>
>Date:   Wed Oct 7 18:39:32 2015 -0400
>
>    drm/nouveau/gr: document mp error 0x10
>    
>    [ Upstream commit 3988f645f053a6889d00324dac3e57bd62cb8900 ]
>    
>    NVIDIA provided the documentation for mp error 0x10, INVALID_ADDR_SPACE,
>    which apparently happens when trying to use an atomic operation on
>    local or shared memory (instead of global memory).
>    
>    Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
>    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1c4732bd6d31d8ded9b6ce802e60cd92fc1701bb
>Author: Lukasz Luba <lukasz.luba@arm.com>
>Date:   Tue May 31 11:32:02 2016 +0100
>
>    thermal: cpu_cooling: fix improper order during initialization
>    
>    [ Upstream commit f840ab18bdf2e415dac21d09fbbbd2873111bd48 ]
>    
>    The freq_table array is not populated before calling
>    thermal_of_cooling_register. The code which populates the freq table was
>    introduced in commit f6859014.
>    This should be done before registering new thermal cooling device.
>    The log shows effects of this wrong decision.
>    [    2.172614] cpu cpu1: Failed to get voltage for frequency 1984518656000: -34
>    [    2.220863] cpu cpu0: Failed to get voltage for frequency 1984524416000: -34
>    
>    Cc: <stable@vger.kernel.org> # 3.19+
>    Fixes: f6859014c7e7 ("thermal: cpu_cooling: Store frequencies in descending order")
>    Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
>    Acked-by: Javi Merino <javi.merino@arm.com>
>    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
>    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f5a826aa29aba9e2800ae8269df2f274d6bb322f
>Author: Viresh Kumar <viresh.kumar@linaro.org>
>Date:   Thu Jul 30 12:40:33 2015 +0530
>
>    thermal/cpu_cooling: rename cpufreq_val as clipped_freq
>    
>    [ Upstream commit 59f0d21883f39d27f14408d4ca211dce80658963 ]
>    
>    That's what it is for, lets name it properly.
>    
>    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
>    Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3327b0c01cf4941a7692e715c158bce85011e0a6
>Author: Thomas Huth <thuth@redhat.com>
>Date:   Tue May 31 07:51:17 2016 +0200
>
>    powerpc/pseries: Add POWER8NVL support to ibm,client-architecture-support call
>    
>    [ Upstream commit 7cc851039d643a2ee7df4d18177150f2c3a484f5 ]
>    
>    If we do not provide the PVR for POWER8NVL, a guest on this system
>    currently ends up in PowerISA 2.06 compatibility mode on KVM, since QEMU
>    does not provide a generic PowerISA 2.07 mode yet. So some new
>    instructions from POWER8 (like "mtvsrd") get disabled for the guest,
>    resulting in crashes when using code compiled explicitly for
>    POWER8 (e.g. with the "-mcpu=power8" option of GCC).
>    
>    Fixes: ddee09c099c3 ("powerpc: Add PVR for POWER8NVL processor")
>    Cc: stable@vger.kernel.org # v4.0+
>    Signed-off-by: Thomas Huth <thuth@redhat.com>
>    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit fbcda466f1b3cb237eb5416393671e9e1bece57b
>Author: Ewan D. Milne <emilne@redhat.com>
>Date:   Tue May 31 09:42:29 2016 -0400
>
>    scsi: Add QEMU CD-ROM to VPD Inquiry Blacklist
>    
>    [ Upstream commit fbd83006e3e536fcb103228d2422ea63129ccb03 ]
>    
>    Linux fails to boot as a guest with a QEMU CD-ROM:
>    
>    [    4.439488] ata2.00: ATAPI: QEMU CD-ROM, 0.8.2, max UDMA/100
>    [    4.443649] ata2.00: configured for MWDMA2
>    [    4.450267] scsi 1:0:0:0: CD-ROM            QEMU     QEMU CD-ROM      0.8. PQ: 0 ANSI: 5
>    [    4.464317] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
>    [    4.464319] ata2.00: BMDMA stat 0x5
>    [    4.464339] ata2.00: cmd a0/01:00:00:00:01/00:00:00:00:00/a0 tag 0 dma 16640 in
>    [    4.464339]          Inquiry 12 01 00 00 ff 00res 48/20:02:00:24:00/00:00:00:00:00/a0 Emask 0x2 (HSM violation)
>    [    4.464341] ata2.00: status: { DRDY DRQ }
>    [    4.465864] ata2: soft resetting link
>    [    4.625971] ata2.00: configured for MWDMA2
>    [    4.628290] ata2: EH complete
>    [    4.646670] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
>    [    4.646671] ata2.00: BMDMA stat 0x5
>    [    4.646683] ata2.00: cmd a0/01:00:00:00:01/00:00:00:00:00/a0 tag 0 dma 16640 in
>    [    4.646683]          Inquiry 12 01 00 00 ff 00res 48/20:02:00:24:00/00:00:00:00:00/a0 Emask 0x2 (HSM violation)
>    [    4.646685] ata2.00: status: { DRDY DRQ }
>    [    4.648193] ata2: soft resetting link
>    
>    ...
>    
>    Fix this by suppressing VPD inquiry for this device.
>    
>    Signed-off-by: Ewan D. Milne <emilne@redhat.com>
>    Reported-by: Jan Stancek <jstancek@redhat.com>
>    Tested-by: Jan Stancek <jstancek@redhat.com>
>    Cc: <stable@vger.kernel.org>
>    Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
>    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2b8944f05530cb759468c42895571e46d103b883
>Author: Bob Copeland <me@bobcopeland.com>
>Date:   Sun May 15 13:19:16 2016 -0400
>
>    mac80211: mesh: flush mesh paths unconditionally
>    
>    [ Upstream commit fe7a7c57629e8dcbc0e297363a9b2366d67a6dc5 ]
>    
>    Currently, the mesh paths associated with a nexthop station are cleaned
>    up in the following code path:
>    
>        __sta_info_destroy_part1
>        synchronize_net()
>        __sta_info_destroy_part2
>         -> cleanup_single_sta
>           -> mesh_sta_cleanup
>             -> mesh_plink_deactivate
>               -> mesh_path_flush_by_nexthop
>    
>    However, there are a couple of problems here:
>    
>    1) the paths aren't flushed at all if the MPM is running in userspace
>       (e.g. when using wpa_supplicant or authsae)
>    
>    2) there is no synchronize_rcu between removing the path and readers
>       accessing the nexthop, which means the following race is possible:
>    
>    CPU0                            CPU1
>    ~~~~                            ~~~~
>                                    sta_info_destroy_part1()
>                                    synchronize_net()
>    rcu_read_lock()
>    mesh_nexthop_resolve()
>      mpath = mesh_path_lookup()
>                                    [...] -> mesh_path_flush_by_nexthop()
>      sta = rcu_dereference(
>        mpath->next_hop)
>                                    kfree(sta)
>      access sta <-- CRASH
>    
>    Fix both of these by unconditionally flushing paths before destroying
>    the sta, and by adding a synchronize_net() after path flush to ensure
>    no active readers can still dereference the sta.
>    
>    Fixes this crash:
>    
>    [  348.529295] BUG: unable to handle kernel paging request at 00020040
>    [  348.530014] IP: [<f929245d>] ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211]
>    [  348.530014] *pde = 00000000
>    [  348.530014] Oops: 0000 [#1] PREEMPT
>    [  348.530014] Modules linked in: drbg ansi_cprng ctr ccm ppp_generic slhc ipt_MASQUERADE nf_nat_masquerade_ipv4 8021q ]
>    [  348.530014] CPU: 0 PID: 20597 Comm: wget Tainted: G           O 4.6.0-rc5-wt=V1 #1
>    [  348.530014] Hardware name: To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080016  11/07/2014
>    [  348.530014] task: f64fa280 ti: f4f9c000 task.ti: f4f9c000
>    [  348.530014] EIP: 0060:[<f929245d>] EFLAGS: 00010246 CPU: 0
>    [  348.530014] EIP is at ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211]
>    [  348.530014] EAX: f4ce63e0 EBX: 00000088 ECX: f3788416 EDX: 00020008
>    [  348.530014] ESI: 00000000 EDI: 00000088 EBP: f6409a4c ESP: f6409a40
>    [  348.530014]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
>    [  348.530014] CR0: 80050033 CR2: 00020040 CR3: 33190000 CR4: 00000690
>    [  348.530014] Stack:
>    [  348.530014]  00000000 f4ce63e0 f5f9bd80 f6409a64 f9291d80 0000ce67 f5d51e00 f4ce63e0
>    [  348.530014]  f3788416 f6409a80 f9291dc1 f4ce8320 f4ce63e0 f5d51e00 f4ce63e0 f4ce8320
>    [  348.530014]  f6409a98 f9277f6f 00000000 00000000 0000007c 00000000 f6409b2c f9278dd1
>    [  348.530014] Call Trace:
>    [  348.530014]  [<f9291d80>] mesh_nexthop_lookup+0xbb/0xc8 [mac80211]
>    [  348.530014]  [<f9291dc1>] mesh_nexthop_resolve+0x34/0xd8 [mac80211]
>    [  348.530014]  [<f9277f6f>] ieee80211_xmit+0x92/0xc1 [mac80211]
>    [  348.530014]  [<f9278dd1>] __ieee80211_subif_start_xmit+0x807/0x83c [mac80211]
>    [  348.530014]  [<c04df012>] ? sch_direct_xmit+0xd7/0x1b3
>    [  348.530014]  [<c022a8c6>] ? __local_bh_enable_ip+0x5d/0x7b
>    [  348.530014]  [<f956870c>] ? nf_nat_ipv4_out+0x4c/0xd0 [nf_nat_ipv4]
>    [  348.530014]  [<f957e036>] ? iptable_nat_ipv4_fn+0xf/0xf [iptable_nat]
>    [  348.530014]  [<c04c6f45>] ? netif_skb_features+0x14d/0x30a
>    [  348.530014]  [<f9278e10>] ieee80211_subif_start_xmit+0xa/0xe [mac80211]
>    [  348.530014]  [<c04c769c>] dev_hard_start_xmit+0x1f8/0x267
>    [  348.530014]  [<c04c7261>] ?  validate_xmit_skb.isra.120.part.121+0x10/0x253
>    [  348.530014]  [<c04defc6>] sch_direct_xmit+0x8b/0x1b3
>    [  348.530014]  [<c04c7a9c>] __dev_queue_xmit+0x2c8/0x513
>    [  348.530014]  [<c04c7cfb>] dev_queue_xmit+0xa/0xc
>    [  348.530014]  [<f91bfc7a>] batadv_send_skb_packet+0xd6/0xec [batman_adv]
>    [  348.530014]  [<f91bfdc4>] batadv_send_unicast_skb+0x15/0x4a [batman_adv]
>    [  348.530014]  [<f91b5938>] batadv_dat_send_data+0x27e/0x310 [batman_adv]
>    [  348.530014]  [<f91c30b5>] ? batadv_tt_global_hash_find.isra.11+0x8/0xa [batman_adv]
>    [  348.530014]  [<f91b63f3>] batadv_dat_snoop_outgoing_arp_request+0x208/0x23d [batman_adv]
>    [  348.530014]  [<f91c0cd9>] batadv_interface_tx+0x206/0x385 [batman_adv]
>    [  348.530014]  [<c04c769c>] dev_hard_start_xmit+0x1f8/0x267
>    [  348.530014]  [<c04c7261>] ?  validate_xmit_skb.isra.120.part.121+0x10/0x253
>    [  348.530014]  [<c04defc6>] sch_direct_xmit+0x8b/0x1b3
>    [  348.530014]  [<c04c7a9c>] __dev_queue_xmit+0x2c8/0x513
>    [  348.530014]  [<f80cbd2a>] ? igb_xmit_frame+0x57/0x72 [igb]
>    [  348.530014]  [<c04c7cfb>] dev_queue_xmit+0xa/0xc
>    [  348.530014]  [<f843a326>] br_dev_queue_push_xmit+0xeb/0xfb [bridge]
>    [  348.530014]  [<f843a35f>] br_forward_finish+0x29/0x74 [bridge]
>    [  348.530014]  [<f843a23b>] ? deliver_clone+0x3b/0x3b [bridge]
>    [  348.530014]  [<f843a714>] __br_forward+0x89/0xe7 [bridge]
>    [  348.530014]  [<f843a336>] ? br_dev_queue_push_xmit+0xfb/0xfb [bridge]
>    [  348.530014]  [<f843a234>] deliver_clone+0x34/0x3b [bridge]
>    [  348.530014]  [<f843a68b>] ? br_flood+0x95/0x95 [bridge]
>    [  348.530014]  [<f843a66d>] br_flood+0x77/0x95 [bridge]
>    [  348.530014]  [<f843a809>] br_flood_forward+0x13/0x1a [bridge]
>    [  348.530014]  [<f843a68b>] ? br_flood+0x95/0x95 [bridge]
>    [  348.530014]  [<f843b877>] br_handle_frame_finish+0x392/0x3db [bridge]
>    [  348.530014]  [<c04e9b2b>] ? nf_iterate+0x2b/0x6b
>    [  348.530014]  [<f843baa6>] br_handle_frame+0x1e6/0x240 [bridge]
>    [  348.530014]  [<f843b4e5>] ? br_handle_local_finish+0x6a/0x6a [bridge]
>    [  348.530014]  [<c04c4ba0>] __netif_receive_skb_core+0x43a/0x66b
>    [  348.530014]  [<f843b8c0>] ? br_handle_frame_finish+0x3db/0x3db [bridge]
>    [  348.530014]  [<c023cea4>] ? resched_curr+0x19/0x37
>    [  348.530014]  [<c0240707>] ? check_preempt_wakeup+0xbf/0xfe
>    [  348.530014]  [<c0255dec>] ? ktime_get_with_offset+0x5c/0xfc
>    [  348.530014]  [<c04c4fc1>] __netif_receive_skb+0x47/0x55
>    [  348.530014]  [<c04c57ba>] netif_receive_skb_internal+0x40/0x5a
>    [  348.530014]  [<c04c61ef>] napi_gro_receive+0x3a/0x94
>    [  348.530014]  [<f80ce8d5>] igb_poll+0x6fd/0x9ad [igb]
>    [  348.530014]  [<c0242bd8>] ? swake_up_locked+0x14/0x26
>    [  348.530014]  [<c04c5d29>] net_rx_action+0xde/0x250
>    [  348.530014]  [<c022a743>] __do_softirq+0x8a/0x163
>    [  348.530014]  [<c022a6b9>] ? __hrtimer_tasklet_trampoline+0x19/0x19
>    [  348.530014]  [<c021100f>] do_softirq_own_stack+0x26/0x2c
>    [  348.530014]  <IRQ>
>    [  348.530014]  [<c022a957>] irq_exit+0x31/0x6f
>    [  348.530014]  [<c0210eb2>] do_IRQ+0x8d/0xa0
>    [  348.530014]  [<c058152c>] common_interrupt+0x2c/0x40
>    [  348.530014] Code: e7 8c 00 66 81 ff 88 00 75 12 85 d2 75 0e b2 c3 b8 83 e9 29 f9 e8 a7 5f f9 c6 eb 74 66 81 e3 8c 005
>    [  348.530014] EIP: [<f929245d>] ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211] SS:ESP 0068:f6409a40
>    [  348.530014] CR2: 0000000000020040
>    [  348.530014] ---[ end trace 48556ac26779732e ]---
>    [  348.530014] Kernel panic - not syncing: Fatal exception in interrupt
>    [  348.530014] Kernel Offset: disabled
>    
>    Cc: stable@vger.kernel.org
>    Reported-by: Fred Veldini <fred.veldini@gmail.com>
>    Tested-by: Fred Veldini <fred.veldini@gmail.com>
>    Signed-off-by: Bob Copeland <me@bobcopeland.com>
>    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6e19f72011a87e576c00b2c38108cfa461542fca
>Author: Martin Willi <martin@strongswan.org>
>Date:   Fri May 13 12:41:48 2016 +0200
>
>    mac80211_hwsim: Add missing check for HWSIM_ATTR_SIGNAL
>    
>    [ Upstream commit 62397da50bb20a6b812c949ef465d7e69fe54bb6 ]
>    
>    A wmediumd that does not send this attribute causes a NULL pointer
>    dereference, as the attribute is accessed even if it does not exist.
>    
>    The attribute was required but never checked ever since userspace frame
>    forwarding has been introduced. The issue gets more problematic once we
>    allow wmediumd registration from user namespaces.
>    
>    Cc: stable@vger.kernel.org
>    Fixes: 7882513bacb1 ("mac80211_hwsim driver support userspace frame tx/rx")
>    Signed-off-by: Martin Willi <martin@strongswan.org>
>    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit dd254ba2b75a05dd7e2d843a30aa6371bb7dd67a
>Author: Thomas Huth <thuth@redhat.com>
>Date:   Thu May 12 13:29:11 2016 +0200
>
>    powerpc: Use privileged SPR number for MMCR2
>    
>    [ Upstream commit 8dd75ccb571f3c92c48014b3dabd3d51a115ab41 ]
>    
>    We are already using the privileged versions of MMCR0, MMCR1
>    and MMCRA in the kernel, so for MMCR2, we should better use
>    the privileged versions, too, to be consistent.
>    
>    Fixes: 240686c13687 ("powerpc: Initialise PMU related regs on Power8")
>    Cc: stable@vger.kernel.org # v3.10+
>    Suggested-by: Paul Mackerras <paulus@ozlabs.org>
>    Signed-off-by: Thomas Huth <thuth@redhat.com>
>    Acked-by: Paul Mackerras <paulus@ozlabs.org>
>    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d58d489f2e03ceb48f8dd979d94cac9b3451d0cd
>Author: Thomas Huth <thuth@redhat.com>
>Date:   Thu May 12 13:26:44 2016 +0200
>
>    powerpc: Fix definition of SIAR and SDAR registers
>    
>    [ Upstream commit d23fac2b27d94aeb7b65536a50d32bfdc21fe01e ]
>    
>    The SIAR and SDAR registers are available twice, one time as SPRs
>    780 / 781 (unprivileged, but read-only), and one time as the SPRs
>    796 / 797 (privileged, but read and write). The Linux kernel code
>    currently uses the unprivileged  SPRs - while this is OK for reading,
>    writing to that register of course does not work.
>    Since the KVM code tries to write to this register, too (see the mtspr
>    in book3s_hv_rmhandlers.S), the contents of this register sometimes get
>    lost for the guests, e.g. during migration of a VM.
>    To fix this issue, simply switch to the privileged SPR numbers instead.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Thomas Huth <thuth@redhat.com>
>    Acked-by: Paul Mackerras <paulus@ozlabs.org>
>    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 466a158ee7f1913f104b04b7e14baccd95af15bf
>Author: hongkun.cao <hongkun.cao@mediatek.com>
>Date:   Sat May 21 15:23:39 2016 +0800
>
>    pinctrl: mediatek: fix dual-edge code defect
>    
>    [ Upstream commit 5edf673d07fdcb6498be24914f3f38f8d8843199 ]
>    
>    When a dual-edge irq is triggered, an incorrect irq will be reported on
>    condition that the external signal is not stable and this incorrect irq
>    has been registered.
>    Correct the register offset.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Hongkun Cao <hongkun.cao@mediatek.com>
>    Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
>    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3de5aac328d5006b251fff8b3bf0c4940898ad42
>Author: Kailang Yang <kailang@realtek.com>
>Date:   Mon May 30 15:58:28 2016 +0800
>
>    ALSA: hda/realtek - ALC256 speaker noise issue
>    
>    [ Upstream commit e69e7e03ed225abf3e1c43545aa3bcb68dc81d5f ]
>    
>    That is some different register for ALC255 and ALC256.
>    ALC256 can't fit with some ALC255 register.
>    This issue is cause from LDO output voltage control.
>    This patch is updated the right LDO register value.
>    
>    Signed-off-by: Kailang Yang <kailang@realtek.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f98a3feb04c264bdb6b1127831bca65484b6185e
>Author: Russell Currey <ruscur@russell.cc>
>Date:   Thu Apr 7 16:28:26 2016 +1000
>
>    powerpc/pseries/eeh: Handle RTAS delay requests in configure_bridge
>    
>    [ Upstream commit 871e178e0f2c4fa788f694721a10b4758d494ce1 ]
>    
>    In the "ibm,configure-pe" and "ibm,configure-bridge" RTAS calls, the
>    spec states that values of 9900-9905 can be returned, indicating that
>    software should delay for 10^x (where x is the last digit, i.e. 990x)
>    milliseconds and attempt the call again. Currently, the kernel doesn't
>    know about this, and respecting it fixes some PCI failures when the
>    hypervisor is busy.
>    
>    The delay is capped at 0.2 seconds.
>    
>    Cc: <stable@vger.kernel.org> # 3.10+
>    Signed-off-by: Russell Currey <ruscur@russell.cc>
>    Acked-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
>    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b182f703e49b54b6a7d135b279f4ac53abf337a2
>Author: Tom Lendacky <thomas.lendacky@amd.com>
>Date:   Fri May 20 17:33:03 2016 -0500
>
>    crypto: ccp - Fix AES XTS error for request sizes above 4096
>    
>    [ Upstream commit ab6a11a7c8ef47f996974dd3c648c2c0b1a36ab1 ]
>    
>    The ccp-crypto module for AES XTS support has a bug that can allow requests
>    greater than 4096 bytes in size to be passed to the CCP hardware. The CCP
>    hardware does not support request sizes larger than 4096, resulting in
>    incorrect output. The request should actually be handled by the fallback
>    mechanism instantiated by the ccp-crypto module.
>    
>    Add a check to insure the request size is less than or equal to the maximum
>    supported size and use the fallback mechanism if it is not.
>    
>    Cc: <stable@vger.kernel.org> # 3.14.x-
>    Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8cdfb73d8c344384469ddd019320ea9cd9e718a9
>Author: James Bottomley <James.Bottomley@HansenPartnership.com>
>Date:   Fri May 13 12:04:06 2016 -0700
>
>    scsi_lib: correctly retry failed zero length REQ_TYPE_FS commands
>    
>    [ Upstream commit a621bac3044ed6f7ec5fa0326491b2d4838bfa93 ]
>    
>    When SCSI was written, all commands coming from the filesystem
>    (REQ_TYPE_FS commands) had data.  This meant that our signal for needing
>    to complete the command was the number of bytes completed being equal to
>    the number of bytes in the request.  Unfortunately, with the advent of
>    flush barriers, we can now get zero length REQ_TYPE_FS commands, which
>    confuse this logic because they satisfy the condition every time.  This
>    means they never get retried even for retryable conditions, like UNIT
>    ATTENTION because we complete them early assuming they're done.  Fix
>    this by special casing the early completion condition to recognise zero
>    length commands with errors and let them drop through to the retry code.
>    
>    Cc: stable@vger.kernel.org
>    Reported-by: Sebastian Parschauer <s.parschauer@gmx.de>
>    Signed-off-by: James E.J. Bottomley <jejb@linux.vnet.ibm.com>
>    Tested-by: Jack Wang <jinpu.wang@profitbricks.com>
>    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4dbfb8be1989118cd013c058c2f0ce199ecaf93f
>Author: Arnd Bergmann <arnd@arndb.de>
>Date:   Wed May 18 16:55:56 2016 +0200
>
>    crypto: public_key: select CRYPTO_AKCIPHER
>    
>    [ Upstream commit bad6a185b4d6f81d0ed2b6e4c16307969f160b95 ]
>    
>    In some rare randconfig builds, we can end up with
>    ASYMMETRIC_PUBLIC_KEY_SUBTYPE enabled but CRYPTO_AKCIPHER disabled,
>    which fails to link because of the reference to crypto_alloc_akcipher:
>    
>    crypto/built-in.o: In function `public_key_verify_signature':
>    :(.text+0x110e4): undefined reference to `crypto_alloc_akcipher'
>    
>    This adds a Kconfig 'select' statement to ensure the dependency
>    is always there.
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 888172862fa78505c4e4674c205a06586443d83f
>Author: Sasha Levin <sasha.levin@oracle.com>
>Date:   Mon Jun 6 19:13:11 2016 -0400
>
>    Linux 4.1.26
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3b14279924b57534832b3c1a0f5b890191777c4e
>Author: Mikulas Patocka <mikulas@twibright.com>
>Date:   Tue May 24 22:49:18 2016 +0200
>
>    hpfs: implement the show_options method
>    
>    [ Upstream commit 037369b872940cd923835a0a589763180c4a36bc ]
>    
>    The HPFS filesystem used generic_show_options to produce string that is
>    displayed in /proc/mounts.  However, there is a problem that the options
>    may disappear after remount.  If we mount the filesystem with option1
>    and then remount it with option2, /proc/mounts should show both option1
>    and option2, however it only shows option2 because the whole option
>    string is replaced with replace_mount_options in hpfs_remount_fs.
>    
>    To fix this bug, implement the hpfs_show_options function that prints
>    options that are currently selected.
>    
>    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9df75cfc33830bc3aaf625728e01f3e80a1c711e
>Author: Mikulas Patocka <mikulas@twibright.com>
>Date:   Tue May 24 22:48:33 2016 +0200
>
>    affs: fix remount failure when there are no options changed
>    
>    [ Upstream commit 01d6e08711bf90bc4d7ead14a93a0cbd73b1896a ]
>    
>    Commit c8f33d0bec99 ("affs: kstrdup() memory handling") checks if the
>    kstrdup function returns NULL due to out-of-memory condition.
>    
>    However, if we are remounting a filesystem with no change to
>    filesystem-specific options, the parameter data is NULL.  In this case,
>    kstrdup returns NULL (because it was passed NULL parameter), although no
>    out of memory condition exists.  The mount syscall then fails with
>    ENOMEM.
>    
>    This patch fixes the bug.  We fail with ENOMEM only if data is non-NULL.
>    
>    The patch also changes the call to replace_mount_options - if we didn't
>    pass any filesystem-specific options, we don't call
>    replace_mount_options (thus we don't erase existing reported options).
>    
>    Fixes: c8f33d0bec99 ("affs: kstrdup() memory handling")
>    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
>    Cc: stable@vger.kernel.org	# v4.1+
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ffd9e8e871d65a6fb87433fe0811289e5dadcd5d
>Author: Mikulas Patocka <mikulas@twibright.com>
>Date:   Tue May 24 22:47:00 2016 +0200
>
>    hpfs: fix remount failure when there are no options changed
>    
>    [ Upstream commit 44d51706b4685f965cd32acde3fe0fcc1e6198e8 ]
>    
>    Commit ce657611baf9 ("hpfs: kstrdup() out of memory handling") checks if
>    the kstrdup function returns NULL due to out-of-memory condition.
>    
>    However, if we are remounting a filesystem with no change to
>    filesystem-specific options, the parameter data is NULL.  In this case,
>    kstrdup returns NULL (because it was passed NULL parameter), although no
>    out of memory condition exists.  The mount syscall then fails with
>    ENOMEM.
>    
>    This patch fixes the bug.  We fail with ENOMEM only if data is non-NULL.
>    
>    The patch also changes the call to replace_mount_options - if we didn't
>    pass any filesystem-specific options, we don't call
>    replace_mount_options (thus we don't erase existing reported options).
>    
>    Fixes: ce657611baf9 ("hpfs: kstrdup() out of memory handling")
>    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b289a9dc95c5967d453762a6f33147b3638cb30b
>Author: Manfred Schlaegl <manfred.schlaegl@gmx.at>
>Date:   Fri May 27 16:36:36 2016 -0700
>
>    Input: pwm-beeper - fix - scheduling while atomic
>    
>    [ Upstream commit f49cf3b8b4c841457244c461c66186a719e13bcc ]
>    
>    Pwm config may sleep so defer it using a worker.
>    
>    On a Freescale i.MX53 based board we ran into "BUG: scheduling while
>    atomic" because input_inject_event locks interrupts, but
>    imx_pwm_config_v2 sleeps.
>    
>    Tested on Freescale i.MX53 SoC with 4.6.0.
>    
>    Signed-off-by: Manfred Schlaegl <manfred.schlaegl@gmx.at>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 25fda3aef19fc295e7e0e978ad39445548ef48af
>Author: Ville SyrjÃ¤lÃ¤ <ville.syrjala@linux.intel.com>
>Date:   Thu May 26 15:16:25 2016 -0700
>
>    dma-debug: avoid spinlock recursion when disabling dma-debug
>    
>    [ Upstream commit 3017cd63f26fc655d56875aaf497153ba60e9edf ]
>    
>    With netconsole (at least) the pr_err("...  disablingn") call can
>    recurse back into the dma-debug code, where it'll try to grab
>    free_entries_lock again.  Avoid the problem by doing the printk after
>    dropping the lock.
>    
>    Link: http://lkml.kernel.org/r/1463678421-18683-1-git-send-email-ville.syrjala@linux.intel.com
>    Signed-off-by: Ville SyrjÃ¤lÃ¤ <ville.syrjala@linux.intel.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 88fe30012aa53af5929155b95800d125cb258147
>Author: Richard Weinberger <richard@nod.at>
>Date:   Tue Apr 26 16:39:48 2016 +0200
>
>    UBI: Fix static volume checks when Fastmap is used
>    
>    [ Upstream commit 1900149c835ab5b48bea31a823ea5e5a401fb560 ]
>    
>    Ezequiel reported that he's facing UBI going into read-only
>    mode after power cut. It turned out that this behavior happens
>    only when updating a static volume is interrupted and Fastmap is
>    used.
>    
>    A possible trace can look like:
>    ubi0 warning: ubi_io_read_vid_hdr [ubi]: no VID header found at PEB 2323, only 0xFF bytes
>    ubi0 warning: ubi_eba_read_leb [ubi]: switch to read-only mode
>    CPU: 0 PID: 833 Comm: ubiupdatevol Not tainted 4.6.0-rc2-ARCH #4
>    Hardware name: SAMSUNG ELECTRONICS CO., LTD. 300E4C/300E5C/300E7C/NP300E5C-AD8AR, BIOS P04RAP 10/15/2012
>    0000000000000286 00000000eba949bd ffff8800c45a7b38 ffffffff8140d841
>    ffff8801964be000 ffff88018eaa4800 ffff8800c45a7bb8 ffffffffa003abf6
>    ffffffff850e2ac0 8000000000000163 ffff8801850e2ac0 ffff8801850e2ac0
>    Call Trace:
>    [<ffffffff8140d841>] dump_stack+0x63/0x82
>    [<ffffffffa003abf6>] ubi_eba_read_leb+0x486/0x4a0 [ubi]
>    [<ffffffffa00453b3>] ubi_check_volume+0x83/0xf0 [ubi]
>    [<ffffffffa0039d97>] ubi_open_volume+0x177/0x350 [ubi]
>    [<ffffffffa00375d8>] vol_cdev_open+0x58/0xb0 [ubi]
>    [<ffffffff8124b08e>] chrdev_open+0xae/0x1d0
>    [<ffffffff81243bcf>] do_dentry_open+0x1ff/0x300
>    [<ffffffff8124afe0>] ? cdev_put+0x30/0x30
>    [<ffffffff81244d36>] vfs_open+0x56/0x60
>    [<ffffffff812545f4>] path_openat+0x4f4/0x1190
>    [<ffffffff81256621>] do_filp_open+0x91/0x100
>    [<ffffffff81263547>] ? __alloc_fd+0xc7/0x190
>    [<ffffffff812450df>] do_sys_open+0x13f/0x210
>    [<ffffffff812451ce>] SyS_open+0x1e/0x20
>    [<ffffffff81a99e32>] entry_SYSCALL_64_fastpath+0x1a/0xa4
>    
>    UBI checks static volumes for data consistency and reads the
>    whole volume upon first open. If the volume is found erroneous
>    users of UBI cannot read from it, but another volume update is
>    possible to fix it. The check is performed by running
>    ubi_eba_read_leb() on every allocated LEB of the volume.
>    For static volumes ubi_eba_read_leb() computes the checksum of all
>    data stored in a LEB. To verify the computed checksum it has to read
>    the LEB's volume header which stores the original checksum.
>    If the volume header is not found UBI treats this as fatal internal
>    error and switches to RO mode. If the UBI device was attached via a
>    full scan the assumption is correct, the volume header has to be
>    present as it had to be there while scanning to get known as mapped.
>    If the attach operation happened via Fastmap the assumption is no
>    longer correct. When attaching via Fastmap UBI learns the mapping
>    table from Fastmap's snapshot of the system state and not via a full
>    scan. It can happen that a LEB got unmapped after a Fastmap was
>    written to the flash. Then UBI can learn the LEB still as mapped and
>    accessing it returns only 0xFF bytes. As UBI is not a FTL it is
>    allowed to have mappings to empty PEBs, it assumes that the layer
>    above takes care of LEB accounting and referencing.
>    UBIFS does so using the LEB property tree (LPT).
>    For static volumes UBI blindly assumes that all LEBs are present and
>    therefore special actions have to be taken.
>    
>    The described situation can happen when updating a static volume is
>    interrupted, either by a user or a power cut.
>    The volume update code first unmaps all LEBs of a volume and then
>    writes LEB by LEB. If the sequence of operations is interrupted UBI
>    detects this either by the absence of LEBs, no volume header present
>    at scan time, or corrupted payload, detected via checksum.
>    In the Fastmap case the former method won't trigger as no scan
>    happened and UBI automatically thinks all LEBs are present.
>    Only by reading data from a LEB it detects that the volume header is
>    missing and incorrectly treats this as fatal error.
>    To deal with the situation ubi_eba_read_leb() from now on checks
>    whether we attached via Fastmap and handles the absence of a
>    volume header like a data corruption error.
>    This way interrupted static volume updates will correctly get detected
>    also when Fastmap is used.
>    
>    Cc: <stable@vger.kernel.org>
>    Reported-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
>    Tested-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
>    Signed-off-by: Richard Weinberger <richard@nod.at>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 22ada7cca2bf9fe6f214d83cb79c6bd95b2313cc
>Author: Ross Lagerwall <ross.lagerwall@citrix.com>
>Date:   Tue May 10 16:11:00 2016 +0100
>
>    xen/events: Don't move disabled irqs
>    
>    [ Upstream commit f0f393877c71ad227d36705d61d1e4062bc29cf5 ]
>    
>    Commit ff1e22e7a638 ("xen/events: Mask a moving irq") open-coded
>    irq_move_irq() but left out checking if the IRQ is disabled. This broke
>    resuming from suspend since it tries to move a (disabled) irq without
>    holding the IRQ's desc->lock. Fix it by adding in a check for disabled
>    IRQs.
>    
>    The resulting stacktrace was:
>    kernel BUG at /build/linux-UbQGH5/linux-4.4.0/kernel/irq/migration.c:31!
>    invalid opcode: 0000 [#1] SMP
>    Modules linked in: xenfs xen_privcmd ...
>    CPU: 0 PID: 9 Comm: migration/0 Not tainted 4.4.0-22-generic #39-Ubuntu
>    Hardware name: Xen HVM domU, BIOS 4.6.1-xs125180 05/04/2016
>    task: ffff88003d75ee00 ti: ffff88003d7bc000 task.ti: ffff88003d7bc000
>    RIP: 0010:[<ffffffff810e26e2>]  [<ffffffff810e26e2>] irq_move_masked_irq+0xd2/0xe0
>    RSP: 0018:ffff88003d7bfc50  EFLAGS: 00010046
>    RAX: 0000000000000000 RBX: ffff88003d40ba00 RCX: 0000000000000001
>    RDX: 0000000000000001 RSI: 0000000000000100 RDI: ffff88003d40bad8
>    RBP: ffff88003d7bfc68 R08: 0000000000000000 R09: ffff88003d000000
>    R10: 0000000000000000 R11: 000000000000023c R12: ffff88003d40bad0
>    R13: ffffffff81f3a4a0 R14: 0000000000000010 R15: 00000000ffffffff
>    FS:  0000000000000000(0000) GS:ffff88003da00000(0000) knlGS:0000000000000000
>    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>    CR2: 00007fd4264de624 CR3: 0000000037922000 CR4: 00000000003406f0
>    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>    Stack:
>     ffff88003d40ba38 0000000000000024 0000000000000000 ffff88003d7bfca0
>     ffffffff814c8d92 00000010813ef89d 00000000805ea732 0000000000000009
>     0000000000000024 ffff88003cc39b80 ffff88003d7bfce0 ffffffff814c8f66
>    Call Trace:
>     [<ffffffff814c8d92>] eoi_pirq+0xb2/0xf0
>     [<ffffffff814c8f66>] __startup_pirq+0xe6/0x150
>     [<ffffffff814ca659>] xen_irq_resume+0x319/0x360
>     [<ffffffff814c7e75>] xen_suspend+0xb5/0x180
>     [<ffffffff81120155>] multi_cpu_stop+0xb5/0xe0
>     [<ffffffff811200a0>] ? cpu_stop_queue_work+0x80/0x80
>     [<ffffffff811203d0>] cpu_stopper_thread+0xb0/0x140
>     [<ffffffff810a94e6>] ? finish_task_switch+0x76/0x220
>     [<ffffffff810ca731>] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20
>     [<ffffffff810a3935>] smpboot_thread_fn+0x105/0x160
>     [<ffffffff810a3830>] ? sort_range+0x30/0x30
>     [<ffffffff810a0588>] kthread+0xd8/0xf0
>     [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0
>     [<ffffffff8182568f>] ret_from_fork+0x3f/0x70
>     [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0
>    
>    Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
>    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1cf63e8af115eb4bb83d28528d16e62c1d6cfa4f
>Author: Stefano Stabellini <sstabellini@kernel.org>
>Date:   Wed Apr 20 14:15:01 2016 +0100
>
>    xen/x86: actually allocate legacy interrupts on PV guests
>    
>    [ Upstream commit 702f926067d2a4b28c10a3c41a1172dd62d9e735 ]
>    
>    b4ff8389ed14 is incomplete: relies on nr_legacy_irqs() to get the number
>    of legacy interrupts when actually nr_legacy_irqs() returns 0 after
>    probe_8259A(). Use NR_IRQS_LEGACY instead.
>    
>    Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
>    CC: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 448691a78243ae617a77689847a5c2232939fbc4
>Author: Oleg Nesterov <oleg@redhat.com>
>Date:   Mon May 23 16:23:50 2016 -0700
>
>    wait/ptrace: assume __WALL if the child is traced
>    
>    [ Upstream commit bf959931ddb88c4e4366e96dd22e68fa0db9527c ]
>    
>    The following program (simplified version of generated by syzkaller)
>    
>    	#include <pthread.h>
>    	#include <unistd.h>
>    	#include <sys/ptrace.h>
>    	#include <stdio.h>
>    	#include <signal.h>
>    
>    	void *thread_func(void *arg)
>    	{
>    		ptrace(PTRACE_TRACEME, 0,0,0);
>    		return 0;
>    	}
>    
>    	int main(void)
>    	{
>    		pthread_t thread;
>    
>    		if (fork())
>    			return 0;
>    
>    		while (getppid() != 1)
>    			;
>    
>    		pthread_create(&thread, NULL, thread_func, NULL);
>    		pthread_join(thread, NULL);
>    		return 0;
>    	}
>    
>    creates an unreapable zombie if /sbin/init doesn't use __WALL.
>    
>    This is not a kernel bug, at least in a sense that everything works as
>    expected: debugger should reap a traced sub-thread before it can reap the
>    leader, but without __WALL/__WCLONE do_wait() ignores sub-threads.
>    
>    Unfortunately, it seems that /sbin/init in most (all?) distributions
>    doesn't use it and we have to change the kernel to avoid the problem.
>    Note also that most init's use sys_waitid() which doesn't allow __WALL, so
>    the necessary user-space fix is not that trivial.
>    
>    This patch just adds the "ptrace" check into eligible_child().  To some
>    degree this matches the "tsk->ptrace" in exit_notify(), ->exit_signal is
>    mostly ignored when the tracee reports to debugger.  Or WSTOPPED, the
>    tracer doesn't need to set this flag to wait for the stopped tracee.
>    
>    This obviously means the user-visible change: __WCLONE and __WALL no
>    longer have any meaning for debugger.  And I can only hope that this won't
>    break something, but at least strace/gdb won't suffer.
>    
>    We could make a more conservative change.  Say, we can take __WCLONE into
>    account, or !thread_group_leader().  But it would be nice to not
>    complicate these historical/confusing checks.
>    
>    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Cc: Denys Vlasenko <dvlasenk@redhat.com>
>    Cc: Jan Kratochvil <jan.kratochvil@redhat.com>
>    Cc: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
>    Cc: Pedro Alves <palves@redhat.com>
>    Cc: Roland McGrath <roland@hack.frob.com>
>    Cc: <syzkaller@googlegroups.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9a9586d6bd8e09d49f17ccf50a4a371565e204f7
>Author: TomÃ¡Å¡ Trnka <ttrnka@mail.muni.cz>
>Date:   Fri May 20 16:41:10 2016 +0200
>
>    sunrpc: fix stripping of padded MIC tokens
>    
>    [ Upstream commit c0cb8bf3a8e4bd82e640862cdd8891400405cb89 ]
>    
>    The length of the GSS MIC token need not be a multiple of four bytes.
>    It is then padded by XDR to a multiple of 4 B, but unwrap_integ_data()
>    would previously only trim mic.len + 4 B. The remaining up to three
>    bytes would then trigger a check in nfs4svc_decode_compoundargs(),
>    leading to a "garbage args" error and mount failure:
>    
>    nfs4svc_decode_compoundargs: compound not properly padded!
>    nfsd: failed to decode arguments!
>    
>    This would prevent older clients using the pre-RFC 4121 MIC format
>    (37-byte MIC including a 9-byte OID) from mounting exports from v3.9+
>    servers using krb5i.
>    
>    The trimming was introduced by commit 4c190e2f913f ("sunrpc: trim off
>    trailing checksum before returning decrypted or integrity authenticated
>    buffer").
>    
>    Fixes: 4c190e2f913f "unrpc: trim off trailing checksum..."
>    Signed-off-by: TomÃ¡Å¡ Trnka <ttrnka@mail.muni.cz>
>    Cc: stable@vger.kernel.org
>    Acked-by: Jeff Layton <jlayton@poochiereds.net>
>    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit bd41a6cc5996b394b48b2f1a47b61cb6bb4d0bd3
>Author: Adrian Hunter <adrian.hunter@intel.com>
>Date:   Fri May 20 10:33:48 2016 +0300
>
>    mmc: sdhci-acpi: Remove MMC_CAP_BUS_WIDTH_TEST for Intel controllers
>    
>    [ Upstream commit 265984b36ce82fec67957d452dd2b22e010611e4 ]
>    
>    The CMD19/CMD14 bus width test has been found to be unreliable in
>    some cases.  It is not essential, so simply remove it.
>    
>    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a0b7f5619bd13ac231bae4931358d0199b019892
>Author: Matt Gumbel <matthew.k.gumbel@intel.com>
>Date:   Fri May 20 10:33:46 2016 +0300
>
>    mmc: longer timeout for long read time quirk
>    
>    [ Upstream commit 32ecd320db39bcb007679ed42f283740641b81ea ]
>    
>    008GE0 Toshiba mmc in some Intel Baytrail tablets responds to
>    MMC_SEND_EXT_CSD in 450-600ms.
>    
>    This patch will...
>    
>    () Increase the long read time quirk timeout from 300ms to 600ms. Original
>       author of that quirk says 300ms was only a guess and that the number
>       may need to be raised in the future.
>    
>    () Add this specific MMC to the quirk
>    
>    Signed-off-by: Matt Gumbel <matthew.k.gumbel@intel.com>
>    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9b78827acea8c1d39c9d88b19d713c17b0e2bf74
>Author: Ville SyrjÃ¤lÃ¤ <ville.syrjala@linux.intel.com>
>Date:   Fri May 13 17:55:17 2016 +0300
>
>    drm/i915: Don't leave old junk in ilk active watermarks on readout
>    
>    [ Upstream commit 7045c3689f148a0c95f42bae8ef3eb2829ac7de9 ]
>    
>    When we read out the watermark state from the hardware we're supposed to
>    transfer that into the active watermarks, but currently we fail to any
>    part of the active watermarks that isn't explicitly written. Let's clear
>    it all upfront.
>    
>    Looks like this has been like this since the beginning, when I added the
>    readout. No idea why I didn't clear it up.
>    
>    Cc: Matt Roper <matthew.d.roper@intel.com>
>    Fixes: 243e6a44b9ca ("drm/i915: Init HSW watermark tracking in intel_modeset_setup_hw_state()")
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Ville SyrjÃ¤lÃ¤ <ville.syrjala@linux.intel.com>
>    Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
>    Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
>    Link: http://patchwork.freedesktop.org/patch/msgid/1463151318-14719-2-git-send-email-ville.syrjala@linux.intel.com
>    (cherry picked from commit 15606534bf0a65d8a74a90fd57b8712d147dbca6)
>    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a6fccead2b1285eb96e15e219467f985db0871b9
>Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>Date:   Fri May 20 23:09:49 2016 +0200
>
>    PM / sleep: Handle failures in device_suspend_late() consistently
>    
>    [ Upstream commit 3a17fb329da68cb00558721aff876a80bba2fdb9 ]
>    
>    Grygorii Strashko reports:
>    
>     The PM runtime will be left disabled for the device if its
>     .suspend_late() callback fails and async suspend is not allowed
>     for this device. In this case device will not be added in
>     dpm_late_early_list and dpm_resume_early() will ignore this
>     device, as result PM runtime will be disabled for it forever
>     (side effect: after 8 subsequent failures for the same device
>     the PM runtime will be reenabled due to disable_depth overflow).
>    
>    To fix this problem, add devices to dpm_late_early_list regardless
>    of whether or not device_suspend_late() returns errors for them.
>    
>    That will ensure failures in there to be handled consistently for
>    all devices regardless of their async suspend/resume status.
>    
>    Reported-by: Grygorii Strashko <grygorii.strashko@ti.com>
>    Tested-by: Grygorii Strashko <grygorii.strashko@ti.com>
>    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>    Cc: All applicable <stable@vger.kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8a1a3f78830798b519870ce05fd68e65848a9da3
>Author: Ricky Liang <jcliang@chromium.org>
>Date:   Fri May 20 10:58:59 2016 -0700
>
>    Input: uinput - handle compat ioctl for UI_SET_PHYS
>    
>    [ Upstream commit affa80bd97f7ca282d1faa91667b3ee9e4c590e6 ]
>    
>    When running a 32-bit userspace on a 64-bit kernel, the UI_SET_PHYS
>    ioctl needs to be treated with special care, as it has the pointer
>    size encoded in the command.
>    
>    Signed-off-by: Ricky Liang <jcliang@chromium.org>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit fb4e7a0a3fc65ccdd3600970d3e225808a61a81a
>Author: Matt Evans <matt.evans@arm.com>
>Date:   Mon May 16 13:54:56 2016 +0100
>
>    kvm: arm64: Fix EC field in inject_abt64
>    
>    [ Upstream commit e4fe9e7dc3828bf6a5714eb3c55aef6260d823a2 ]
>    
>    The EC field of the constructed ESR is conditionally modified by ORing in
>    ESR_ELx_EC_DABT_LOW for a data abort.  However, ESR_ELx_EC_SHIFT is missing
>    from this condition.
>    
>    Signed-off-by: Matt Evans <matt.evans@arm.com>
>    Acked-by: Marc Zyngier <marc.zyngier@arm.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0d4a4eba82e4334897d7577b69cdc58fb150c5a5
>Author: Kai-Heng Feng <kaihengfeng@gmail.com>
>Date:   Fri May 20 15:47:23 2016 +0800
>
>    ALSA: hda - Fix headphone noise on Dell XPS 13 9360
>    
>    [ Upstream commit 423cd785619ac6778252fbdb916505aa1c153959 ]
>    
>    The headphone has noise when playing sound or switching microphone sources.
>    It uses the same codec on XPS 13 9350, but with different subsystem ID.
>    Applying the fixup can solve the issue.
>    Also, changing the model name to better differentiate models.
>    
>    v2: Reorder by device ID.
>    
>    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 71f788d68dbe931b42c7318f5cb5cb0dfae0773b
>Author: David Henningsson <david.henningsson@canonical.com>
>Date:   Tue Dec 15 14:44:03 2015 +0100
>
>    ALSA: hda - Fix headphone mic input on a few Dell ALC293 machines
>    
>    [ Upstream commit c04017ea81dc1eccae87be7ac7b82b2972f9931f ]
>    
>    These laptops support both headphone, headset and mic modes
>    for the 3.5mm jack.
>    
>    Cc: stable@vger.kernel.org
>    BugLink: https://bugs.launchpad.net/bugs/1526330
>    Signed-off-by: David Henningsson <david.henningsson@canonical.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f1f125da12d365c4459aa356ea33459039966355
>Author: Sachin Prabhu <sprabhu@redhat.com>
>Date:   Tue May 17 18:20:13 2016 -0500
>
>    cifs: Create dedicated keyring for spnego operations
>    
>    [ Upstream commit b74cb9a80268be5c80cf4c87c74debf0ff2129ac ]
>    
>    The session key is the default keyring set for request_key operations.
>    This session key is revoked when the user owning the session logs out.
>    Any long running daemon processes started by this session ends up with
>    revoked session keyring which prevents these processes from using the
>    request_key mechanism from obtaining the krb5 keys.
>    
>    The problem has been reported by a large number of autofs users. The
>    problem is also seen with multiuser mounts where the share may be used
>    by processes run by a user who has since logged out. A reproducer using
>    automount is available on the Red Hat bz.
>    
>    The patch creates a new keyring which is used to cache cifs spnego
>    upcalls.
>    
>    Red Hat bz: 1267754
>    
>    Signed-off-by: Sachin Prabhu <sprabhu@redhat.com>
>    Reported-by: Scott Mayhew <smayhew@redhat.com>
>    Reviewed-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
>    CC: Stable <stable@vger.kernel.org>
>    Signed-off-by: Steve French <smfrench@gmail.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ded044fcdd60ec9fea0e3cc512d85073f88d129b
>Author: Mark Brown <broonie@kernel.org>
>Date:   Wed May 18 18:30:39 2016 +0100
>
>    ASoC: ak4642: Enable cache usage to fix crashes on resume
>    
>    [ Upstream commit d3030d11961a8c103cf07aed59905276ddfc06c2 ]
>    
>    The ak4642 driver is using a regmap cache sync to restore the
>    configuration of the chip on resume but (as Peter observed) does not
>    actually define a register cache which means that the resume is never
>    going to work and we trigger asserts in regmap.  Fix this by enabling
>    caching.
>    
>    Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
>    Reported-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
>    Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
>    Signed-off-by: Mark Brown <broonie@kernel.org>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 141afa30231ef169dc4d1bcc00c00478068cf2f7
>Author: Axel Lin <axel.lin@ingics.com>
>Date:   Wed Jul 1 00:56:36 2015 +0800
>
>    ASoC: ak4642: Fix up max_register setting
>    
>    [ Upstream commit f8ea6cebcfa6499949392da71fc427567c9e5a0e ]
>    
>    The max_register setting for ak4642, ak4643 and ak4648 are wrong, fix it.
>    
>    According to the datasheet:
>            the maximum valid register for ak4642 is 0x1f
>            the maximum valid register for ak4643 is 0x24
>            the maximum valid register for ak4648 is 0x27
>    
>    The default settings for ak4642 and ak4643 are the same for 0x0 ~ 0x1f
>    registers, so it's fine to use the same reg_default table with differnt
>    num_reg_defaults setting.
>    
>    Signed-off-by: Axel Lin <axel.lin@ingics.com>
>    Tested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>    Signed-off-by: Mark Brown <broonie@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4b126ba9fab396983926238ab018c727a086996e
>Author: Dave Chinner <dchinner@redhat.com>
>Date:   Wed May 18 13:54:23 2016 +1000
>
>    xfs: skip stale inodes in xfs_iflush_cluster
>    
>    [ Upstream commit 7d3aa7fe970791f1a674b14572a411accf2f4d4e ]
>    
>    We don't write back stale inodes so we should skip them in
>    xfs_iflush_cluster, too.
>    
>    cc: <stable@vger.kernel.org> # 3.10.x-
>    Signed-off-by: Dave Chinner <dchinner@redhat.com>
>    Reviewed-by: Brian Foster <bfoster@redhat.com>
>    Reviewed-by: Christoph Hellwig <hch@lst.de>
>    Signed-off-by: Dave Chinner <david@fromorbit.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3eeb7e764de82bba421e04154bb62b8dc518c3a1
>Author: Dave Chinner <dchinner@redhat.com>
>Date:   Wed May 18 13:54:22 2016 +1000
>
>    xfs: fix inode validity check in xfs_iflush_cluster
>    
>    [ Upstream commit 51b07f30a71c27405259a0248206ed4e22adbee2 ]
>    
>    Some careless idiot(*) wrote crap code in commit 1a3e8f3 ("xfs:
>    convert inode cache lookups to use RCU locking") back in late 2010,
>    and so xfs_iflush_cluster checks the wrong inode for whether it is
>    still valid under RCU protection. Fix it to lock and check the
>    correct inode.
>    
>    (*) Careless-idiot: Dave Chinner <dchinner@redhat.com>
>    
>    cc: <stable@vger.kernel.org> # 3.10.x-
>    Discovered-by: Brain Foster <bfoster@redhat.com>
>    Signed-off-by: Dave Chinner <dchinner@redhat.com>
>    Reviewed-by: Christoph Hellwig <hch@lst.de>
>    Signed-off-by: Dave Chinner <david@fromorbit.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6659d79405e4c4ec1abac74aaf551fb822081112
>Author: Dave Chinner <dchinner@redhat.com>
>Date:   Wed May 18 13:53:42 2016 +1000
>
>    xfs: xfs_iflush_cluster fails to abort on error
>    
>    [ Upstream commit b1438f477934f5a4d5a44df26f3079a7575d5946 ]
>    
>    When a failure due to an inode buffer occurs, the error handling
>    fails to abort the inode writeback correctly. This can result in the
>    inode being reclaimed whilst still in the AIL, leading to
>    use-after-free situations as well as filesystems that cannot be
>    unmounted as the inode log items left in the AIL never get removed.
>    
>    Fix this by ensuring fatal errors from xfs_imap_to_bp() result in
>    the inode flush being aborted correctly.
>    
>    cc: <stable@vger.kernel.org> # 3.10.x-
>    Reported-by: Shyam Kaushik <shyam@zadarastorage.com>
>    Diagnosed-by: Shyam Kaushik <shyam@zadarastorage.com>
>    Tested-by: Shyam Kaushik <shyam@zadarastorage.com>
>    Signed-off-by: Dave Chinner <dchinner@redhat.com>
>    Reviewed-by: Christoph Hellwig <hch@lst.de>
>    Signed-off-by: Dave Chinner <david@fromorbit.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c504b774bcd91a3c5963c8a81573a46dc0a8d0f8
>Author: Daniel Lezcano <daniel.lezcano@linaro.org>
>Date:   Tue May 17 16:54:00 2016 +0200
>
>    cpuidle: Fix cpuidle_state_is_coupled() argument in cpuidle_enter()
>    
>    [ Upstream commit e7387da52028b072489c45efeb7a916c0205ebd2 ]
>    
>    Commit 0b89e9aa2856 (cpuidle: delay enabling interrupts until all
>    coupled CPUs leave idle) rightfully fixed a regression by letting
>    the coupled idle state framework to handle local interrupt enabling
>    when the CPU is exiting an idle state.
>    
>    The current code checks if the idle state is coupled and, if so, it
>    will let the coupled code to enable interrupts. This way, it can
>    decrement the ready-count before handling the interrupt. This
>    mechanism prevents the other CPUs from waiting for a CPU which is
>    handling interrupts.
>    
>    But the check is done against the state index returned by the back
>    end driver's ->enter functions which could be different from the
>    initial index passed as parameter to the cpuidle_enter_state()
>    function.
>    
>     entered_state = target_state->enter(dev, drv, index);
>    
>     [ ... ]
>    
>     if (!cpuidle_state_is_coupled(drv, entered_state))
>    	local_irq_enable();
>    
>     [ ... ]
>    
>    If the 'index' is referring to a coupled idle state but the
>    'entered_state' is *not* coupled, then the interrupts are enabled
>    again. All CPUs blocked on the sync barrier may busy loop longer
>    if the CPU has interrupts to handle before decrementing the
>    ready-count. That's consuming more energy than saving.
>    
>    Fixes: 0b89e9aa2856 (cpuidle: delay enabling interrupts until all coupled CPUs leave idle)
>    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>    Cc: 3.15+ <stable@vger.kernel.org> # 3.15+
>    [ rjw: Subject & changelog ]
>    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d3bbf7b3c6c919f9b19dcc8277603c1885e487b7
>Author: Xunlei Pang <pang.xunlei@linaro.org>
>Date:   Tue Aug 4 13:48:56 2015 +0800
>
>    cpuidle/coupled: Remove redundant 'dev' argument of cpuidle_state_is_coupled()
>    
>    [ Upstream commit 4c1ed5a6079078699128064664913ae7b079648f ]
>    
>    For cpuidle_state_is_coupled(), 'dev' is not used, so remove it.
>    
>    Signed-off-by: Xunlei Pang <pang.xunlei@linaro.org>
>    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit cde02e3a5b143885f6b68b7e687eb4326d5da99d
>Author: Steve French <smfrench@gmail.com>
>Date:   Thu May 12 21:20:36 2016 -0500
>
>    remove directory incorrectly tries to set delete on close on non-empty directories
>    
>    [ Upstream commit 897fba1172d637d344f009d700f7eb8a1fa262f1 ]
>    
>    Wrong return code was being returned on SMB3 rmdir of
>    non-empty directory.
>    
>    For SMB3 (unlike for cifs), we attempt to delete a directory by
>    set of delete on close flag on the open. Windows clients set
>    this flag via a set info (SET_FILE_DISPOSITION to set this flag)
>    which properly checks if the directory is empty.
>    
>    With this patch on smb3 mounts we correctly return
>     "DIRECTORY NOT EMPTY"
>    on attempts to remove a non-empty directory.
>    
>    Signed-off-by: Steve French <steve.french@primarydata.com>
>    CC: Stable <stable@vger.kernel.org>
>    Acked-by: Sachin Prabhu <sprabhu@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b6044542f162483636dae70bb691d50e483fb438
>Author: Stefan Metzmacher <metze@samba.org>
>Date:   Tue May 3 10:52:30 2016 +0200
>
>    fs/cifs: correctly to anonymous authentication for the NTLM(v2) authentication
>    
>    [ Upstream commit 1a967d6c9b39c226be1b45f13acd4d8a5ab3dc44 ]
>    
>    Only server which map unknown users to guest will allow
>    access using a non-null NTLMv2_Response.
>    
>    For Samba it's the "map to guest = bad user" option.
>    
>    BUG: https://bugzilla.samba.org/show_bug.cgi?id=11913
>    
>    Signed-off-by: Stefan Metzmacher <metze@samba.org>
>    CC: Stable <stable@vger.kernel.org>
>    Signed-off-by: Steve French <smfrench@gmail.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6842cd24b8ce4f6f540184a16d134cf4ebfe337c
>Author: Stefan Metzmacher <metze@samba.org>
>Date:   Tue May 3 10:52:30 2016 +0200
>
>    fs/cifs: correctly to anonymous authentication for the NTLM(v1) authentication
>    
>    [ Upstream commit 777f69b8d26bf35ade4a76b08f203c11e048365d ]
>    
>    Only server which map unknown users to guest will allow
>    access using a non-null NTChallengeResponse.
>    
>    For Samba it's the "map to guest = bad user" option.
>    
>    BUG: https://bugzilla.samba.org/show_bug.cgi?id=11913
>    
>    Signed-off-by: Stefan Metzmacher <metze@samba.org>
>    CC: Stable <stable@vger.kernel.org>
>    Signed-off-by: Steve French <smfrench@gmail.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8f83c4496e5a08bc834a7475129f64d6e21789aa
>Author: Stefan Metzmacher <metze@samba.org>
>Date:   Tue May 3 10:52:30 2016 +0200
>
>    fs/cifs: correctly to anonymous authentication for the LANMAN authentication
>    
>    [ Upstream commit fa8f3a354bb775ec586e4475bcb07f7dece97e0c ]
>    
>    Only server which map unknown users to guest will allow
>    access using a non-null LMChallengeResponse.
>    
>    For Samba it's the "map to guest = bad user" option.
>    
>    BUG: https://bugzilla.samba.org/show_bug.cgi?id=11913
>    
>    Signed-off-by: Stefan Metzmacher <metze@samba.org>
>    CC: Stable <stable@vger.kernel.org>
>    Signed-off-by: Steve French <smfrench@gmail.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f39b179308d938c7bb6da74fd0699c0eb4356ef8
>Author: Stefan Metzmacher <metze@samba.org>
>Date:   Tue May 3 10:52:30 2016 +0200
>
>    fs/cifs: correctly to anonymous authentication via NTLMSSP
>    
>    [ Upstream commit cfda35d98298131bf38fbad3ce4cd5ecb3cf18db ]
>    
>    See [MS-NLMP] 3.2.5.1.2 Server Receives an AUTHENTICATE_MESSAGE from the Client:
>    
>       ...
>       Set NullSession to FALSE
>       If (AUTHENTICATE_MESSAGE.UserNameLen == 0 AND
>          AUTHENTICATE_MESSAGE.NtChallengeResponse.Length == 0 AND
>          (AUTHENTICATE_MESSAGE.LmChallengeResponse == Z(1)
>           OR
>           AUTHENTICATE_MESSAGE.LmChallengeResponse.Length == 0))
>           -- Special case: client requested anonymous authentication
>           Set NullSession to TRUE
>       ...
>    
>    Only server which map unknown users to guest will allow
>    access using a non-null NTChallengeResponse.
>    
>    For Samba it's the "map to guest = bad user" option.
>    
>    BUG: https://bugzilla.samba.org/show_bug.cgi?id=11913
>    
>    CC: Stable <stable@vger.kernel.org>
>    Signed-off-by: Stefan Metzmacher <metze@samba.org>
>    Signed-off-by: Steve French <smfrench@gmail.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9a2257ff4ccf1ccd1ed0446f9ff5813232594ffc
>Author: Lyude <cpaul@redhat.com>
>Date:   Thu May 12 10:56:59 2016 -0400
>
>    drm/fb_helper: Fix references to dev->mode_config.num_connector
>    
>    [ Upstream commit 255f0e7c418ad95a4baeda017ae6182ba9b3c423 ]
>    
>    During boot, MST hotplugs are generally expected (even if no physical
>    hotplugging occurs) and result in DRM's connector topology changing.
>    This means that using num_connector from the current mode configuration
>    can lead to the number of connectors changing under us. This can lead to
>    some nasty scenarios in fbcon:
>    
>    - We allocate an array to the size of dev->mode_config.num_connectors.
>    - MST hotplug occurs, dev->mode_config.num_connectors gets incremented.
>    - We try to loop through each element in the array using the new value
>      of dev->mode_config.num_connectors, and end up going out of bounds
>      since dev->mode_config.num_connectors is now larger then the array we
>      allocated.
>    
>    fb_helper->connector_count however, will always remain consistent while
>    we do a modeset in fb_helper.
>    
>    Note: This is just polish for 4.7, Dave Airlie's drm_connector
>    refcounting fixed these bugs for real. But it's good enough duct-tape
>    for stable kernel backporting, since backporting the refcounting
>    changes is way too invasive.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Lyude <cpaul@redhat.com>
>    [danvet: Clarify why we need this. Also remove the now unused "dev"
>    local variable to appease gcc.]
>    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>    Link: http://patchwork.freedesktop.org/patch/msgid/1463065021-18280-3-git-send-email-cpaul@redhat.com
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d648fcdb0adc44bafa01dc1cd0fbc3e4c9375488
>Author: Lyude <cpaul@redhat.com>
>Date:   Thu May 12 10:56:58 2016 -0400
>
>    drm/i915/fbdev: Fix num_connector references in intel_fb_initial_config()
>    
>    [ Upstream commit 14a3842a1d5945067d1dd0788f314e14d5b18e5b ]
>    
>    During boot time, MST devices usually send a ton of hotplug events
>    irregardless of whether or not any physical hotplugs actually occurred.
>    Hotplugs mean connectors being created/destroyed, and the number of DRM
>    connectors changing under us. This isn't a problem if we use
>    fb_helper->connector_count since we only set it once in the code,
>    however if we use num_connector from struct drm_mode_config we risk it's
>    value changing under us. On top of that, there's even a chance that
>    dev->mode_config.num_connector != fb_helper->connector_count. If the
>    number of connectors happens to increase under us, we'll end up using
>    the wrong array size for memcpy and start writing beyond the actual
>    length of the array, occasionally resulting in kernel panics.
>    
>    Note: This is just polish for 4.7, Dave Airlie's drm_connector
>    refcounting fixed these bugs for real. But it's good enough duct-tape
>    for stable kernel backporting, since backporting the refcounting
>    changes is way too invasive.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Lyude <cpaul@redhat.com>
>    [danvet: Clarify why we need this.]
>    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>    Link: http://patchwork.freedesktop.org/patch/msgid/1463065021-18280-2-git-send-email-cpaul@redhat.com
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f52a1b990cc3b4d4c4f0135ea3569848dca16784
>Author: Maciej W. Rozycki <macro@imgtec.com>
>Date:   Tue May 17 06:12:27 2016 +0100
>
>    MIPS: MSA: Fix a link error on `_init_msa_upper' with older GCC
>    
>    [ Upstream commit e49d38488515057dba8f0c2ba4cfde5be4a7281f ]
>    
>    Fix a build regression from commit c9017757c532 ("MIPS: init upper 64b
>    of vector registers when MSA is first used"):
>    
>    arch/mips/built-in.o: In function `enable_restore_fp_context':
>    traps.c:(.text+0xbb90): undefined reference to `_init_msa_upper'
>    traps.c:(.text+0xbb90): relocation truncated to fit: R_MIPS_26 against `_init_msa_upper'
>    traps.c:(.text+0xbef0): undefined reference to `_init_msa_upper'
>    traps.c:(.text+0xbef0): relocation truncated to fit: R_MIPS_26 against `_init_msa_upper'
>    
>    to !CONFIG_CPU_HAS_MSA configurations with older GCC versions, which are
>    unable to figure out that calls to `_init_msa_upper' are indeed dead.
>    Of the many ways to tackle this failure choose the approach we have
>    already taken in `thread_msa_context_live'.
>    
>    [ralf@linux-mips.org: Drop patch segment to junk file.]
>    
>    Signed-off-by: Maciej W. Rozycki <macro@imgtec.com>
>    Cc: stable@vger.kernel.org # v3.16+
>    Cc: linux-mips@linux-mips.org
>    Patchwork: https://patchwork.linux-mips.org/patch/13271/
>    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8f25a2f3345dcee6608b55d50b34f8c1bb782f7b
>Author: Prarit Bhargava <prarit@redhat.com>
>Date:   Wed May 11 12:27:16 2016 -0400
>
>    PCI: Disable all BAR sizing for devices with non-compliant BARs
>    
>    [ Upstream commit ad67b437f187ea818b2860524d10f878fadfdd99 ]
>    
>    b84106b4e229 ("PCI: Disable IO/MEM decoding for devices with non-compliant
>    BARs") disabled BAR sizing for BARs 0-5 of devices that don't comply with
>    the PCI spec.  But it didn't do anything for expansion ROM BARs, so we
>    still try to size them, resulting in warnings like this on Broadwell-EP:
>    
>      pci 0000:ff:12.0: BAR 6: failed to assign [mem size 0x00000001 pref]
>    
>    Move the non-compliant BAR check from __pci_read_base() up to
>    pci_read_bases() so it applies to the expansion ROM BAR as well as
>    to BARs 0-5.
>    
>    Note that direct callers of __pci_read_base(), like sriov_init(), will now
>    bypass this check.  We haven't had reports of devices with broken SR-IOV
>    BARs yet.
>    
>    [bhelgaas: changelog]
>    Fixes: b84106b4e229 ("PCI: Disable IO/MEM decoding for devices with non-compliant BARs")
>    Signed-off-by: Prarit Bhargava <prarit@redhat.com>
>    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>    CC: stable@vger.kernel.org
>    CC: Thomas Gleixner <tglx@linutronix.de>
>    CC: Ingo Molnar <mingo@redhat.com>
>    CC: "H. Peter Anvin" <hpa@zytor.com>
>    CC: Andi Kleen <ak@linux.intel.com>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a87165993a3702ec5ec8f3af87df8edcce26b3da
>Author: Adrian Hunter <adrian.hunter@intel.com>
>Date:   Thu May 5 08:12:28 2016 +0300
>
>    mmc: mmc: Fix partition switch timeout for some eMMCs
>    
>    [ Upstream commit 1c447116d017a98c90f8f71c8c5a611e0aa42178 ]
>    
>    Some eMMCs set the partition switch timeout too low.
>    
>    Now typically eMMCs are considered a critical component (e.g. because
>    they store the root file system) and consequently are expected to be
>    reliable.  Thus we can neglect the use case where eMMCs can't switch
>    reliably and we might want a lower timeout to facilitate speedy
>    recovery.
>    
>    Although we could employ a quirk for the cards that are affected (if
>    we could identify them all), as described above, there is little
>    benefit to having a low timeout, so instead simply set a minimum
>    timeout.
>    
>    The minimum is set to 300ms somewhat arbitrarily - the examples that
>    have been seen had a timeout of 10ms but were sometimes taking 60-70ms.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
>    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ab2cfdb8ef5da3d4cd237a3f15cc2d7ad4623260
>Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
>Date:   Fri May 13 09:34:12 2016 -0400
>
>    ring-buffer: Prevent overflow of size in ring_buffer_resize()
>    
>    [ Upstream commit 59643d1535eb220668692a5359de22545af579f6 ]
>    
>    If the size passed to ring_buffer_resize() is greater than MAX_LONG - BUF_PAGE_SIZE
>    then the DIV_ROUND_UP() will return zero.
>    
>    Here's the details:
>    
>      # echo 18014398509481980 > /sys/kernel/debug/tracing/buffer_size_kb
>    
>    tracing_entries_write() processes this and converts kb to bytes.
>    
>     18014398509481980 << 10 = 18446744073709547520
>    
>    and this is passed to ring_buffer_resize() as unsigned long size.
>    
>     size = DIV_ROUND_UP(size, BUF_PAGE_SIZE);
>    
>    Where DIV_ROUND_UP(a, b) is (a + b - 1)/b
>    
>    BUF_PAGE_SIZE is 4080 and here
>    
>     18446744073709547520 + 4080 - 1 = 18446744073709551599
>    
>    where 18446744073709551599 is still smaller than 2^64
>    
>     2^64 - 18446744073709551599 = 17
>    
>    But now 18446744073709551599 / 4080 = 4521260802379792
>    
>    and size = size * 4080 = 18446744073709551360
>    
>    This is checked to make sure its still greater than 2 * 4080,
>    which it is.
>    
>    Then we convert to the number of buffer pages needed.
>    
>     nr_page = DIV_ROUND_UP(size, BUF_PAGE_SIZE)
>    
>    but this time size is 18446744073709551360 and
>    
>     2^64 - (18446744073709551360 + 4080 - 1) = -3823
>    
>    Thus it overflows and the resulting number is less than 4080, which makes
>    
>      3823 / 4080 = 0
>    
>    an nr_pages is set to this. As we already checked against the minimum that
>    nr_pages may be, this causes the logic to fail as well, and we crash the
>    kernel.
>    
>    There's no reason to have the two DIV_ROUND_UP() (that's just result of
>    historical code changes), clean up the code and fix this bug.
>    
>    Cc: stable@vger.kernel.org # 3.5+
>    Fixes: 83f40318dab00 ("ring-buffer: Make removal of ring buffer pages atomic")
>    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 453babf108cade06562021a1ce8787f28e5fee08
>Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
>Date:   Thu May 12 11:01:24 2016 -0400
>
>    ring-buffer: Use long for nr_pages to avoid overflow failures
>    
>    [ Upstream commit 9b94a8fba501f38368aef6ac1b30e7335252a220 ]
>    
>    The size variable to change the ring buffer in ftrace is a long. The
>    nr_pages used to update the ring buffer based on the size is int. On 64 bit
>    machines this can cause an overflow problem.
>    
>    For example, the following will cause the ring buffer to crash:
>    
>     # cd /sys/kernel/debug/tracing
>     # echo 10 > buffer_size_kb
>     # echo 8556384240 > buffer_size_kb
>    
>    Then you get the warning of:
>    
>     WARNING: CPU: 1 PID: 318 at kernel/trace/ring_buffer.c:1527 rb_update_pages+0x22f/0x260
>    
>    Which is:
>    
>      RB_WARN_ON(cpu_buffer, nr_removed);
>    
>    Note each ring buffer page holds 4080 bytes.
>    
>    This is because:
>    
>     1) 10 causes the ring buffer to have 3 pages.
>        (10kb requires 3 * 4080 pages to hold)
>    
>     2) (2^31 / 2^10  + 1) * 4080 = 8556384240
>        The value written into buffer_size_kb is shifted by 10 and then passed
>        to ring_buffer_resize(). 8556384240 * 2^10 = 8761737461760
>    
>     3) The size passed to ring_buffer_resize() is then divided by BUF_PAGE_SIZE
>        which is 4080. 8761737461760 / 4080 = 2147484672
>    
>     4) nr_pages is subtracted from the current nr_pages (3) and we get:
>        2147484669. This value is saved in a signed integer nr_pages_to_update
>    
>     5) 2147484669 is greater than 2^31 but smaller than 2^32, a signed int
>        turns into the value of -2147482627
>    
>     6) As the value is a negative number, in update_pages_handler() it is
>        negated and passed to rb_remove_pages() and 2147482627 pages will
>        be removed, which is much larger than 3 and it causes the warning
>        because not all the pages asked to be removed were removed.
>    
>    Link: https://bugzilla.kernel.org/show_bug.cgi?id=118001
>    
>    Cc: stable@vger.kernel.org # 2.6.28+
>    Fixes: 7a8e76a3829f1 ("tracing: unified trace buffer")
>    Reported-by: Hao Qin <QEver.cn@gmail.com>
>    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d6bdff22c8511e4f7d489d180997c929fa7b55b8
>Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
>Date:   Wed May 27 10:27:47 2015 -0400
>
>    ring-buffer: Move recursive check to per_cpu descriptor
>    
>    [ Upstream commit 58a09ec6e3ec88c9c7e061479f1ef7fe93324a87 ]
>    
>    Instead of using a global per_cpu variable to perform the recursive
>    checks into the ring buffer, use the already existing per_cpu descriptor
>    that is part of the ring buffer itself.
>    
>    Not only does this simplify the code, it also allows for one ring buffer
>    to be used within the guts of the use of another ring buffer. For example
>    trace_printk() can now be used within the ring buffer to record changes
>    done by an instance into the main ring buffer. The recursion checks
>    will prevent the trace_printk() itself from causing recursive issues
>    with the main ring buffer (it is just ignored), but the recursive
>    checks wont prevent the trace_printk() from recording other ring buffers.
>    
>    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ac4e03df07cba1d92e4555c577bc3179a10c6a72
>Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
>Date:   Thu May 21 17:39:29 2015 -0400
>
>    ring-buffer: Add unlikelys to make fast path the default
>    
>    [ Upstream commit 3205f8063b6cc54b20d5080fb79dfcbd9c39e93d ]
>    
>    I was running the trace_event benchmark and noticed that the times
>    to record a trace_event was all over the place. I looked at the assembly
>    of the ring_buffer_lock_reserver() and saw this:
>    
>     <ring_buffer_lock_reserve>:
>           31 c0                   xor    %eax,%eax
>           48 83 3d 76 47 bd 00    cmpq   $0x1,0xbd4776(%rip)        # ffffffff81d10d60 <ring_buffer_flags>
>           01
>           55                      push   %rbp
>           48 89 e5                mov    %rsp,%rbp
>           75 1d                   jne    ffffffff8113c60d <ring_buffer_lock_reserve+0x2d>
>           65 ff 05 69 e3 ec 7e    incl   %gs:0x7eece369(%rip)        # a960 <__preempt_count>
>           8b 47 08                mov    0x8(%rdi),%eax
>           85 c0                   test   %eax,%eax
>     +---- 74 12                   je     ffffffff8113c610 <ring_buffer_lock_reserve+0x30>
>     |     65 ff 0d 5b e3 ec 7e    decl   %gs:0x7eece35b(%rip)        # a960 <__preempt_count>
>     |     0f 84 85 00 00 00       je     ffffffff8113c690 <ring_buffer_lock_reserve+0xb0>
>     |     31 c0                   xor    %eax,%eax
>     |     5d                      pop    %rbp
>     |     c3                      retq
>     |     90                      nop
>     +---> 65 44 8b 05 48 e3 ec    mov    %gs:0x7eece348(%rip),%r8d        # a960 <__preempt_count>
>           7e
>           41 81 e0 ff ff ff 7f    and    $0x7fffffff,%r8d
>           b0 08                   mov    $0x8,%al
>           65 8b 0d 58 36 ed 7e    mov    %gs:0x7eed3658(%rip),%ecx        # fc80 <current_context>
>           41 f7 c0 00 ff 1f 00    test   $0x1fff00,%r8d
>           74 1e                   je     ffffffff8113c64f <ring_buffer_lock_reserve+0x6f>
>           41 f7 c0 00 00 10 00    test   $0x100000,%r8d
>           b0 01                   mov    $0x1,%al
>           75 13                   jne    ffffffff8113c64f <ring_buffer_lock_reserve+0x6f>
>           41 81 e0 00 00 0f 00    and    $0xf0000,%r8d
>           49 83 f8 01             cmp    $0x1,%r8
>           19 c0                   sbb    %eax,%eax
>           83 e0 02                and    $0x2,%eax
>           83 c0 02                add    $0x2,%eax
>           85 c8                   test   %ecx,%eax
>           75 ab                   jne    ffffffff8113c5fe <ring_buffer_lock_reserve+0x1e>
>           09 c8                   or     %ecx,%eax
>           65 89 05 24 36 ed 7e    mov    %eax,%gs:0x7eed3624(%rip)        # fc80 <current_context>
>    
>    The arrow is the fast path.
>    
>    After adding the unlikely's, the fast path looks a bit better:
>    
>     <ring_buffer_lock_reserve>:
>           31 c0                   xor    %eax,%eax
>           48 83 3d 76 47 bd 00    cmpq   $0x1,0xbd4776(%rip)        # ffffffff81d10d60 <ring_buffer_flags>
>           01
>           55                      push   %rbp
>           48 89 e5                mov    %rsp,%rbp
>           75 7b                   jne    ffffffff8113c66b <ring_buffer_lock_reserve+0x8b>
>           65 ff 05 69 e3 ec 7e    incl   %gs:0x7eece369(%rip)        # a960 <__preempt_count>
>           8b 47 08                mov    0x8(%rdi),%eax
>           85 c0                   test   %eax,%eax
>           0f 85 9f 00 00 00       jne    ffffffff8113c6a1 <ring_buffer_lock_reserve+0xc1>
>           65 8b 0d 57 e3 ec 7e    mov    %gs:0x7eece357(%rip),%ecx        # a960 <__preempt_count>
>           81 e1 ff ff ff 7f       and    $0x7fffffff,%ecx
>           b0 08                   mov    $0x8,%al
>           65 8b 15 68 36 ed 7e    mov    %gs:0x7eed3668(%rip),%edx        # fc80 <current_context>
>           f7 c1 00 ff 1f 00       test   $0x1fff00,%ecx
>           75 50                   jne    ffffffff8113c670 <ring_buffer_lock_reserve+0x90>
>           85 d0                   test   %edx,%eax
>           75 7d                   jne    ffffffff8113c6a1 <ring_buffer_lock_reserve+0xc1>
>           09 d0                   or     %edx,%eax
>           65 89 05 53 36 ed 7e    mov    %eax,%gs:0x7eed3653(%rip)        # fc80 <current_context>
>           65 8b 05 fc da ec 7e    mov    %gs:0x7eecdafc(%rip),%eax        # a130 <cpu_number>
>           89 c2                   mov    %eax,%edx
>    
>    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit daf7322babd9946b7c2e2eae53d1f68f7665766b
>Author: Paul Burton <paul.burton@imgtec.com>
>Date:   Thu Apr 21 12:43:57 2016 +0100
>
>    MIPS: Disable preemption during prctl(PR_SET_FP_MODE, ...)
>    
>    [ Upstream commit bd239f1e1429e7781096bf3884bdb1b2b1bb4f28 ]
>    
>    Whilst a PR_SET_FP_MODE prctl is performed there are decisions made
>    based upon whether the task is executing on the current CPU. This may
>    change if we're preempted, so disable preemption to avoid such changes
>    for the lifetime of the mode switch.
>    
>    Signed-off-by: Paul Burton <paul.burton@imgtec.com>
>    Fixes: 9791554b45a2 ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS")
>    Reviewed-by: Maciej W. Rozycki <macro@imgtec.com>
>    Tested-by: Aurelien Jarno <aurelien@aurel32.net>
>    Cc: Adam Buchbinder <adam.buchbinder@gmail.com>
>    Cc: James Hogan <james.hogan@imgtec.com>
>    Cc: stable <stable@vger.kernel.org> # v4.0+
>    Cc: linux-mips@linux-mips.org
>    Cc: linux-kernel@vger.kernel.org
>    Patchwork: https://patchwork.linux-mips.org/patch/13144/
>    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 49dc90fd14c0ce2ec494d44f1cd6594603d7c4a0
>Author: Maciej W. Rozycki <macro@imgtec.com>
>Date:   Thu May 12 10:19:08 2016 +0100
>
>    MIPS: ptrace: Prevent writes to read-only FCSR bits
>    
>    [ Upstream commit abf378be49f38c4d3e23581d3df3fa9f1b1b11d2 ]
>    
>    Correct the cases missed with commit 9b26616c8d9d ("MIPS: Respect the
>    ISA level in FCSR handling") and prevent writes to read-only FCSR bits
>    there.
>    
>    This in particular applies to FP context initialisation where any IEEE
>    754-2008 bits preset by `mips_set_personality_nan' are cleared before
>    the relevant ptrace(2) call takes effect and the PTRACE_POKEUSR request
>    addressing FPC_CSR where no masking of read-only FCSR bits is done.
>    
>    Remove the FCSR clearing from FP context initialisation then and unify
>    PTRACE_POKEUSR/FPC_CSR and PTRACE_SETFPREGS handling, by factoring out
>    code from `ptrace_setfpregs' and calling it from both places.
>    
>    This mostly matters to soft float configurations where the emulator can
>    be switched this way to a mode which should not be accessible and cannot
>    be set with the CTC1 instruction.  With hard float configurations any
>    effect is transient anyway as read-only bits will retain their values at
>    the time the FP context is restored.
>    
>    Signed-off-by: Maciej W. Rozycki <macro@imgtec.com>
>    Cc: stable@vger.kernel.org # v4.0+
>    Cc: linux-mips@linux-mips.org
>    Patchwork: https://patchwork.linux-mips.org/patch/13239/
>    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ba1ccd8e28e1009a1866bea1580fa565c244a353
>Author: Maciej W. Rozycki <macro@imgtec.com>
>Date:   Thu May 12 10:18:27 2016 +0100
>
>    MIPS: ptrace: Fix FP context restoration FCSR regression
>    
>    [ Upstream commit 4249548454f7ba4581aeee26bd83f42b48a14d15 ]
>    
>    Fix a floating-point context restoration regression introduced with
>    commit 9b26616c8d9d ("MIPS: Respect the ISA level in FCSR handling")
>    that causes a Floating Point exception and consequently a kernel oops
>    with hard float configurations when one or more FCSR Enable and their
>    corresponding Cause bits are set both at a time via a ptrace(2) call.
>    
>    To do so reinstate Cause bit masking originally introduced with commit
>    b1442d39fac2 ("MIPS: Prevent user from setting FCSR cause bits") to
>    address this exact problem and then inadvertently removed from the
>    PTRACE_SETFPREGS request with the commit referred above.
>    
>    Signed-off-by: Maciej W. Rozycki <macro@imgtec.com>
>    Cc: stable@vger.kernel.org # v4.0+
>    Cc: linux-mips@linux-mips.org
>    Patchwork: https://patchwork.linux-mips.org/patch/13238/
>    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit fc39f274bfb6bcff688b099ccbcc081460bb0325
>Author: Paul Burton <paul.burton@imgtec.com>
>Date:   Thu Apr 21 14:04:55 2016 +0100
>
>    MIPS: math-emu: Fix jalr emulation when rd == $0
>    
>    [ Upstream commit ab4a92e66741b35ca12f8497896bafbe579c28a1 ]
>    
>    When emulating a jalr instruction with rd == $0, the code in
>    isBranchInstr was incorrectly writing to GPR $0 which should actually
>    always remain zeroed. This would lead to any further instructions
>    emulated which use $0 operating on a bogus value until the task is next
>    context switched, at which point the value of $0 in the task context
>    would be restored to the correct zero by a store in SAVE_SOME. Fix this
>    by not writing to rd if it is $0.
>    
>    Fixes: 102cedc32a6e ("MIPS: microMIPS: Floating point support.")
>    Signed-off-by: Paul Burton <paul.burton@imgtec.com>
>    Cc: Maciej W. Rozycki <macro@imgtec.com>
>    Cc: James Hogan <james.hogan@imgtec.com>
>    Cc: linux-mips@linux-mips.org
>    Cc: linux-kernel@vger.kernel.org
>    Cc: stable <stable@vger.kernel.org> # v3.10
>    Patchwork: https://patchwork.linux-mips.org/patch/13160/
>    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4a16f41bf4a45e70a73e0fdc9bfcc81776387783
>Author: James Hogan <james.hogan@imgtec.com>
>Date:   Mon Feb 8 18:43:51 2016 +0000
>
>    MIPS: Fix uapi include in exported asm/siginfo.h
>    
>    [ Upstream commit 987e5b834467c9251ca584febda65ef8f66351a9 ]
>    
>    Since commit 8cb48fe169dd ("MIPS: Provide correct siginfo_t.si_stime"),
>    MIPS' uapi/asm/siginfo.h has included uapi/asm-generic/siginfo.h
>    directly before defining MIPS' struct siginfo, in order to get the
>    necessary definitions needed for the siginfo struct without the generic
>    copy_siginfo() hitting compiler errors due to struct siginfo not yet
>    being defined.
>    
>    Now that the generic copy_siginfo() is moved out to linux/signal.h we
>    can safely include asm-generic/siginfo.h before defining the MIPS
>    specific struct siginfo, which avoids the uapi/ include as well as
>    breakage due to generic copy_siginfo() being defined before struct
>    siginfo.
>    
>    Reported-by: Christopher Ferris <cferris@google.com>
>    Fixes: 8cb48fe169dd ("MIPS: Provide correct siginfo_t.si_stime")
>    Signed-off-by: James Hogan <james.hogan@imgtec.com>
>    Cc: Petr Malat <oss@malat.biz>
>    Cc: linux-mips@linux-mips.org
>    Cc: <stable@vger.kernel.org> # 4.0-
>    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 175c648589e0b55645854a95895554b0887af9af
>Author: James Hogan <james.hogan@imgtec.com>
>Date:   Mon Feb 8 18:43:50 2016 +0000
>
>    SIGNAL: Move generic copy_siginfo() to signal.h
>    
>    [ Upstream commit ca9eb49aa9562eaadf3cea071ec7018ad6800425 ]
>    
>    The generic copy_siginfo() is currently defined in
>    asm-generic/siginfo.h, after including uapi/asm-generic/siginfo.h which
>    defines the generic struct siginfo. However this makes it awkward for an
>    architecture to use it if it has to define its own struct siginfo (e.g.
>    MIPS and potentially IA64), since it means that asm-generic/siginfo.h
>    can only be included after defining the arch-specific siginfo, which may
>    be problematic if the arch-specific definition needs definitions from
>    uapi/asm-generic/siginfo.h.
>    
>    It is possible to work around this by first including
>    uapi/asm-generic/siginfo.h to get the constants before defining the
>    arch-specific siginfo, and include asm-generic/siginfo.h after. However
>    uapi headers can't be included by other uapi headers, so that first
>    include has to be in an ifdef __kernel__, with the non __kernel__ case
>    including the non-UAPI header instead.
>    
>    Instead of that mess, move the generic copy_siginfo() definition into
>    linux/signal.h, which allows an arch-specific uapi/asm/siginfo.h to
>    include asm-generic/siginfo.h and define the arch-specific siginfo, and
>    for the generic copy_siginfo() to see that arch-specific definition.
>    
>    Signed-off-by: James Hogan <james.hogan@imgtec.com>
>    Cc: Arnd Bergmann <arnd@arndb.de>
>    Cc: Ralf Baechle <ralf@linux-mips.org>
>    Cc: Petr Malat <oss@malat.biz>
>    Cc: Tony Luck <tony.luck@intel.com>
>    Cc: Fenghua Yu <fenghua.yu@intel.com>
>    Cc: Christopher Ferris <cferris@google.com>
>    Cc: linux-arch@vger.kernel.org
>    Cc: linux-mips@linux-mips.org
>    Cc: linux-ia64@vger.kernel.org
>    Cc: linux-kernel@vger.kernel.org
>    Cc: <stable@vger.kernel.org> # 4.0-
>    Patchwork: https://patchwork.linux-mips.org/patch/12478/
>    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit de444b25c68049fb560e0530ee0425fd9db981f0
>Author: Paul Burton <paul.burton@imgtec.com>
>Date:   Tue Mar 1 02:37:59 2016 +0000
>
>    MIPS: Sync icache & dcache in set_pte_at
>    
>    [ Upstream commit 37d22a0d798b5c938b277d32cfd86dc231381342 ]
>    
>    It's possible for pages to become visible prior to update_mmu_cache
>    running if a thread within the same address space preempts the current
>    thread or runs simultaneously on another CPU. That is, the following
>    scenario is possible:
>    
>        CPU0                            CPU1
>    
>        write to page
>        flush_dcache_page
>        flush_icache_page
>        set_pte_at
>                                        map page
>        update_mmu_cache
>    
>    If CPU1 maps the page in between CPU0's set_pte_at, which marks it valid
>    & visible, and update_mmu_cache where the dcache flush occurs then CPU1s
>    icache will fill from stale data (unless it fills from the dcache, in
>    which case all is good, but most MIPS CPUs don't have this property).
>    Commit 4d46a67a3eb8 ("MIPS: Fix race condition in lazy cache flushing.")
>    attempted to fix that by performing the dcache flush in
>    flush_icache_page such that it occurs before the set_pte_at call makes
>    the page visible. However it has the problem that not all code that
>    writes to pages exposed to userland call flush_icache_page. There are
>    many callers of set_pte_at under mm/ and only 2 of them do call
>    flush_icache_page. Thus the race window between a page becoming visible
>    & being coherent between the icache & dcache remains open in some cases.
>    
>    To illustrate some of the cases, a WARN was added to __update_cache with
>    this patch applied that triggered in cases where a page about to be
>    flushed from the dcache was not the last page provided to
>    flush_icache_page. That is, backtraces were obtained for cases in which
>    the race window is left open without this patch. The 2 standout examples
>    follow.
>    
>    When forking a process:
>    
>    [   15.271842] [<80417630>] __update_cache+0xcc/0x188
>    [   15.277274] [<80530394>] copy_page_range+0x56c/0x6ac
>    [   15.282861] [<8042936c>] copy_process.part.54+0xd40/0x17ac
>    [   15.289028] [<80429f80>] do_fork+0xe4/0x420
>    [   15.293747] [<80413808>] handle_sys+0x128/0x14c
>    
>    When exec'ing an ELF binary:
>    
>    [   14.445964] [<80417630>] __update_cache+0xcc/0x188
>    [   14.451369] [<80538d88>] move_page_tables+0x414/0x498
>    [   14.457075] [<8055d848>] setup_arg_pages+0x220/0x318
>    [   14.462685] [<805b0f38>] load_elf_binary+0x530/0x12a0
>    [   14.468374] [<8055ec3c>] search_binary_handler+0xbc/0x214
>    [   14.474444] [<8055f6c0>] do_execveat_common+0x43c/0x67c
>    [   14.480324] [<8055f938>] do_execve+0x38/0x44
>    [   14.485137] [<80413808>] handle_sys+0x128/0x14c
>    
>    These code paths write into a page, call flush_dcache_page then call
>    set_pte_at without flush_icache_page inbetween. The end result is that
>    the icache can become corrupted & userland processes may execute
>    unexpected or invalid code, typically resulting in a reserved
>    instruction exception, a trap or a segfault.
>    
>    Fix this race condition fully by performing any cache maintenance
>    required to keep the icache & dcache in sync in set_pte_at, before the
>    page is made valid. This has the added bonus of ensuring the cache
>    maintenance always happens in one location, rather than being duplicated
>    in flush_icache_page & update_mmu_cache. It also matches the way other
>    architectures solve the same problem (see arm, ia64 & powerpc).
>    
>    Signed-off-by: Paul Burton <paul.burton@imgtec.com>
>    Reported-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
>    Cc: Lars Persson <lars.persson@axis.com>
>    Fixes: 4d46a67a3eb8 ("MIPS: Fix race condition in lazy cache flushing.")
>    Cc: Steven J. Hill <sjhill@realitydiluted.com>
>    Cc: David Daney <david.daney@cavium.com>
>    Cc: Huacai Chen <chenhc@lemote.com>
>    Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>    Cc: Andrew Morton <akpm@linux-foundation.org>
>    Cc: Jerome Marchand <jmarchan@redhat.com>
>    Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>    Cc: linux-mips@linux-mips.org
>    Cc: linux-kernel@vger.kernel.org
>    Cc: stable <stable@vger.kernel.org> # v4.1+
>    Patchwork: https://patchwork.linux-mips.org/patch/12722/
>    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8c99d76129a9a429a9410df4811b13c091aaa889
>Author: Paul Burton <paul.burton@imgtec.com>
>Date:   Tue Mar 1 02:37:58 2016 +0000
>
>    MIPS: Handle highmem pages in __update_cache
>    
>    [ Upstream commit f4281bba818105c7c91799abe40bc05c0dbdaa25 ]
>    
>    The following patch will expose __update_cache to highmem pages. Handle
>    them by mapping them in for the duration of the cache maintenance, just
>    like in __flush_dcache_page. The code for that isn't shared because we
>    need the page address in __update_cache so sharing became messy. Given
>    that the entirity is an extra 5 lines, just duplicate it.
>    
>    Signed-off-by: Paul Burton <paul.burton@imgtec.com>
>    Cc: Lars Persson <lars.persson@axis.com>
>    Cc: Andrew Morton <akpm@linux-foundation.org>
>    Cc: Jerome Marchand <jmarchan@redhat.com>
>    Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>    Cc: linux-mips@linux-mips.org
>    Cc: linux-kernel@vger.kernel.org
>    Cc: stable <stable@vger.kernel.org> # v4.1+
>    Patchwork: https://patchwork.linux-mips.org/patch/12721/
>    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e7c735b01d8fdfd7215a133dfe9072d73502acfd
>Author: Paul Burton <paul.burton@imgtec.com>
>Date:   Tue Mar 1 02:37:57 2016 +0000
>
>    MIPS: Flush highmem pages in __flush_dcache_page
>    
>    [ Upstream commit 234859e49a15323cf1b2331bdde7f658c4cb45fb ]
>    
>    When flush_dcache_page is called on an executable page, that page is
>    about to be provided to userland & we can presume that the icache
>    contains no valid entries for its address range. However if the icache
>    does not fill from the dcache then we cannot presume that the pages
>    content has been written back as far as the memories that the dcache
>    will fill from (ie. L2 or further out).
>    
>    This was being done for lowmem pages, but not for highmem which can lead
>    to icache corruption. Fix this by mapping highmem pages & flushing their
>    content from the dcache in __flush_dcache_page before providing the page
>    to userland, just as is done for lowmem pages.
>    
>    Signed-off-by: Paul Burton <paul.burton@imgtec.com>
>    Cc: Lars Persson <lars.persson@axis.com>
>    Cc: Andrew Morton <akpm@linux-foundation.org>
>    Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>    Cc: linux-mips@linux-mips.org
>    Cc: linux-kernel@vger.kernel.org
>    Patchwork: https://patchwork.linux-mips.org/patch/12720/
>    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit deee8f00eda629080d81bf57de8e5d174fb3fce8
>Author: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
>Date:   Mon Apr 11 16:17:22 2016 -0300
>
>    Revert "powerpc/eeh: Fix crash in eeh_add_device_early() on Cell"
>    
>    [ Upstream commit c2078d9ef600bdbe568c89e5ddc2c6f15b7982c8 ]
>    
>    This reverts commit 89a51df5ab1d38b257300b8ac940bbac3bb0eb9b.
>    
>    The function eeh_add_device_early() is used to perform EEH
>    initialization in devices added later on the system, like in
>    hotplug/DLPAR scenarios. Since the commit 89a51df5ab1d ("powerpc/eeh:
>    Fix crash in eeh_add_device_early() on Cell") a new check was introduced
>    in this function - Cell has no EEH capabilities which led to kernel oops
>    if hotplug was performed, so checking for eeh_enabled() was introduced
>    to avoid the issue.
>    
>    However, in architectures that EEH is present like pSeries or PowerNV,
>    we might reach a case in which no PCI devices are present on boot time
>    and so EEH is not initialized. Then, if a device is added via DLPAR for
>    example, eeh_add_device_early() fails because eeh_enabled() is false,
>    and EEH end up not being enabled at all.
>    
>    This reverts the aforementioned patch since a new verification was
>    introduced by the commit d91dafc02f42 ("powerpc/eeh: Delay probing EEH
>    device during hotplug") and so the original Cell issue does not happen
>    anymore.
>    
>    Cc: stable@vger.kernel.org # v4.1+
>    Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
>    Signed-off-by: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
>    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 75d03a9ef249f1ce07e8aad0411e04b0bbfb5910
>Author: Gavin Shan <gwshan@linux.vnet.ibm.com>
>Date:   Wed Apr 27 11:14:51 2016 +1000
>
>    powerpc/eeh: Restore initial state in eeh_pe_reset_and_recover()
>    
>    [ Upstream commit 5a0cdbfd17b90a89c64a71d8aec9773ecdb20d0d ]
>    
>    The function eeh_pe_reset_and_recover() is used to recover EEH
>    error when the passthrou device are transferred to guest and
>    backwards. The content in the device's config space will be lost
>    on PE reset issued in the middle of the recovery. The function
>    saves/restores it before/after the reset. However, config access
>    to some adapters like Broadcom BCM5719 at this point will causes
>    fenced PHB. The config space is always blocked and we save 0xFF's
>    that are restored at late point. The memory BARs are totally
>    corrupted, causing another EEH error upon access to one of the
>    memory BARs.
>    
>    This restores the config space on those adapters like BCM5719
>    from the content saved to the EEH device when it's populated,
>    to resolve above issue.
>    
>    Fixes: 5cfb20b9 ("powerpc/eeh: Emulate EEH recovery for VFIO devices")
>    Cc: stable@vger.kernel.org #v3.18+
>    Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
>    Reviewed-by: Russell Currey <ruscur@russell.cc>
>    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b7ccd2a25cc0b57564f7d446b97c3ce7295f2919
>Author: Gavin Shan <gwshan@linux.vnet.ibm.com>
>Date:   Wed Apr 27 11:14:50 2016 +1000
>
>    powerpc/eeh: Don't report error in eeh_pe_reset_and_recover()
>    
>    [ Upstream commit affeb0f2d3a9af419ad7ef4ac782e1540b2f7b28 ]
>    
>    The function eeh_pe_reset_and_recover() is used to recover EEH
>    error when the passthrough device are transferred to guest and
>    backwards, meaning the device's driver is vfio-pci or none.
>    When the driver is vfio-pci that provides error_detected() error
>    handler only, the handler simply stops the guest and it's not
>    expected behaviour. On the other hand, no error handlers will
>    be called if we don't have a bound driver.
>    
>    This ignores the error handler in eeh_pe_reset_and_recover()
>    that reports the error to device driver to avoid the exceptional
>    behaviour.
>    
>    Fixes: 5cfb20b9 ("powerpc/eeh: Emulate EEH recovery for VFIO devices")
>    Cc: stable@vger.kernel.org #v3.18+
>    Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
>    Reviewed-by: Russell Currey <ruscur@russell.cc>
>    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 18fc656941a1e06de8bbcf642cc3c43757b890ae
>Author: Sasha Levin <sasha.levin@oracle.com>
>Date:   Tue May 31 21:11:00 2016 -0400
>
>    sched/loadavg: Fix loadavg artifacts on fully idle and on fully loaded systems
>    
>    [ Upstream commit 20878232c52329f92423d27a60e48b6a6389e0dd ]
>    
>    Systems show a minimal load average of 0.00, 0.01, 0.05 even when they
>    have no load at all.
>    
>    Uptime and /proc/loadavg on all systems with kernels released during the
>    last five years up until kernel version 4.6-rc5, show a 5- and 15-minute
>    minimum loadavg of 0.01 and 0.05 respectively. This should be 0.00 on
>    idle systems, but the way the kernel calculates this value prevents it
>    from getting lower than the mentioned values.
>    
>    Likewise but not as obviously noticeable, a fully loaded system with no
>    processes waiting, shows a maximum 1/5/15 loadavg of 1.00, 0.99, 0.95
>    (multiplied by number of cores).
>    
>    Once the (old) load becomes 93 or higher, it mathematically can never
>    get lower than 93, even when the active (load) remains 0 forever.
>    This results in the strange 0.00, 0.01, 0.05 uptime values on idle
>    systems.  Note: 93/2048 = 0.0454..., which rounds up to 0.05.
>    
>    It is not correct to add a 0.5 rounding (=1024/2048) here, since the
>    result from this function is fed back into the next iteration again,
>    so the result of that +0.5 rounding value then gets multiplied by
>    (2048-2037), and then rounded again, so there is a virtual "ghost"
>    load created, next to the old and active load terms.
>    
>    By changing the way the internally kept value is rounded, that internal
>    value equivalent now can reach 0.00 on idle, and 1.00 on full load. Upon
>    increasing load, the internally kept load value is rounded up, when the
>    load is decreasing, the load value is rounded down.
>    
>    The modified code was tested on nohz=off and nohz kernels. It was tested
>    on vanilla kernel 4.6-rc5 and on centos 7.1 kernel 3.10.0-327. It was
>    tested on single, dual, and octal cores system. It was tested on virtual
>    hosts and bare hardware. No unwanted effects have been observed, and the
>    problems that the patch intended to fix were indeed gone.
>    
>    Tested-by: Damien Wyart <damien.wyart@free.fr>
>    Signed-off-by: Vik Heyndrickx <vik.heyndrickx@veribox.net>
>    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>    Cc: <stable@vger.kernel.org>
>    Cc: Doug Smythies <dsmythies@telus.net>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Mike Galbraith <efault@gmx.de>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Fixes: 0f004f5a696a ("sched: Cure more NO_HZ load average woes")
>    Link: http://lkml.kernel.org/r/e8d32bff-d544-7748-72b5-3c86cc71f09f@veribox.net
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit fa5c124f7dbee615a8e1fe7c1cb8f65a29040202
>Author: Sasha Levin <sasha.levin@oracle.com>
>Date:   Tue May 31 21:07:16 2016 -0400
>
>    rtlwifi: pci: use dev_kfree_skb_irq instead of kfree_skb in rtl_pci_reset_trx_ring
>    
>    [ Upstream commit cf968937d27751296920e6b82ffa89735e3a0023 ]
>    
>    We can't use kfree_skb in irq disable context, because spin_lock_irqsave
>    make sure we are always in irq disable context, use dev_kfree_skb_irq
>    instead of kfree_skb is better than dev_kfree_skb_any.
>    
>    This patch fix below kernel warning:
>    [ 7612.095528] ------------[ cut here ]------------
>    [ 7612.095546] WARNING: CPU: 3 PID: 4460 at kernel/softirq.c:150 __local_bh_enable_ip+0x58/0x80()
>    [ 7612.095550] Modules linked in: rtl8723be x86_pkg_temp_thermal btcoexist rtl_pci rtlwifi rtl8723_common
>    [ 7612.095567] CPU: 3 PID: 4460 Comm: ifconfig Tainted: G        W       4.4.0+ #4
>    [ 7612.095570] Hardware name: LENOVO 20DFA04FCD/20DFA04FCD, BIOS J5ET48WW (1.19 ) 08/27/2015
>    [ 7612.095574]  00000000 00000000 da37fc70 c12ce7c5 00000000 da37fca0 c104cc59 c19d4454
>    [ 7612.095584]  00000003 0000116c c19d4784 00000096 c10508a8 c10508a8 00000200 c1b42400
>    [ 7612.095594]  f29be780 da37fcb0 c104ccad 00000009 00000000 da37fcbc c10508a8 f21f08b8
>    [ 7612.095604] Call Trace:
>    [ 7612.095614]  [<c12ce7c5>] dump_stack+0x41/0x5c
>    [ 7612.095620]  [<c104cc59>] warn_slowpath_common+0x89/0xc0
>    [ 7612.095628]  [<c10508a8>] ? __local_bh_enable_ip+0x58/0x80
>    [ 7612.095634]  [<c10508a8>] ? __local_bh_enable_ip+0x58/0x80
>    [ 7612.095640]  [<c104ccad>] warn_slowpath_null+0x1d/0x20
>    [ 7612.095646]  [<c10508a8>] __local_bh_enable_ip+0x58/0x80
>    [ 7612.095653]  [<c16b7d34>] destroy_conntrack+0x64/0xa0
>    [ 7612.095660]  [<c16b300f>] nf_conntrack_destroy+0xf/0x20
>    [ 7612.095665]  [<c1677565>] skb_release_head_state+0x55/0xa0
>    [ 7612.095670]  [<c16775bb>] skb_release_all+0xb/0x20
>    [ 7612.095674]  [<c167760b>] __kfree_skb+0xb/0x60
>    [ 7612.095679]  [<c16776f0>] kfree_skb+0x30/0x70
>    [ 7612.095686]  [<f81b869d>] ? rtl_pci_reset_trx_ring+0x22d/0x370 [rtl_pci]
>    [ 7612.095692]  [<f81b869d>] rtl_pci_reset_trx_ring+0x22d/0x370 [rtl_pci]
>    [ 7612.095698]  [<f81b87f9>] rtl_pci_start+0x19/0x190 [rtl_pci]
>    [ 7612.095705]  [<f81970e6>] rtl_op_start+0x56/0x90 [rtlwifi]
>    [ 7612.095712]  [<c17e3f16>] drv_start+0x36/0xc0
>    [ 7612.095717]  [<c17f5ab3>] ieee80211_do_open+0x2d3/0x890
>    [ 7612.095725]  [<c16820fe>] ? call_netdevice_notifiers_info+0x2e/0x60
>    [ 7612.095730]  [<c17f60bd>] ieee80211_open+0x4d/0x50
>    [ 7612.095736]  [<c16891b3>] __dev_open+0xa3/0x130
>    [ 7612.095742]  [<c183fa53>] ? _raw_spin_unlock_bh+0x13/0x20
>    [ 7612.095748]  [<c1689499>] __dev_change_flags+0x89/0x140
>    [ 7612.095753]  [<c127c70d>] ? selinux_capable+0xd/0x10
>    [ 7612.095759]  [<c1689589>] dev_change_flags+0x29/0x60
>    [ 7612.095765]  [<c1700b93>] devinet_ioctl+0x553/0x670
>    [ 7612.095772]  [<c12db758>] ? _copy_to_user+0x28/0x40
>    [ 7612.095777]  [<c17018b5>] inet_ioctl+0x85/0xb0
>    [ 7612.095783]  [<c166e647>] sock_ioctl+0x67/0x260
>    [ 7612.095788]  [<c166e5e0>] ? sock_fasync+0x80/0x80
>    [ 7612.095795]  [<c115c99b>] do_vfs_ioctl+0x6b/0x550
>    [ 7612.095800]  [<c127c812>] ? selinux_file_ioctl+0x102/0x1e0
>    [ 7612.095807]  [<c10a8914>] ? timekeeping_suspend+0x294/0x320
>    [ 7612.095813]  [<c10a256a>] ? __hrtimer_run_queues+0x14a/0x210
>    [ 7612.095820]  [<c1276e24>] ? security_file_ioctl+0x34/0x50
>    [ 7612.095827]  [<c115cef0>] SyS_ioctl+0x70/0x80
>    [ 7612.095832]  [<c1001804>] do_fast_syscall_32+0x84/0x120
>    [ 7612.095839]  [<c183ff91>] sysenter_past_esp+0x36/0x55
>    [ 7612.095844] ---[ end trace 97e9c637a20e8348 ]---
>    
>    Signed-off-by: Wang YanQing <udknight@gmail.com>
>    Cc: Stable <stable@vger.kernel.org>
>    Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
>    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5de658d6f56a158f29baa789880732dbc4375e33
>Author: Sasha Levin <sasha.levin@oracle.com>
>Date:   Tue May 31 21:04:01 2016 -0400
>
>    rtlwifi: Fix logic error in enter/exit power-save mode
>    
>    [ Upstream commit 873ffe154ae074c46ed2d72dbd9a2a99f06f55b4 ]
>    
>    In commit a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and
>    rtl_lps_enter() to use work queue"), the tests for enter/exit
>    power-save mode were inverted. With this change applied, the
>    wifi connection becomes much more stable.
>    
>    Fixes: a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter() to use work queue")
>    Signed-off-by: Wang YanQing <udknight@gmail.com>
>    CC: Stable <stable@vger.kernel.org> [3.10+]
>    Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
>    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4cfbd2198055655a81aef121a6031867765fa64f
>Author: Arnd Bergmann <arnd@arndb.de>
>Date:   Tue May 10 23:30:01 2016 +0200
>
>    kbuild: move -Wunused-const-variable to W=1 warning level
>    
>    [ Upstream commit c9c6837d39311b0cc14cdbe7c18e815ab44aefb1 ]
>    
>    gcc-6 started warning by default about variables that are not
>    used anywhere and that are marked 'const', generating many
>    false positives in an allmodconfig build, e.g.:
>    
>    arch/arm/mach-davinci/board-da830-evm.c:282:20: warning: 'da830_evm_emif25_pins' defined but not used [-Wunused-const-variable=]
>    arch/arm/plat-omap/dmtimer.c:958:34: warning: 'omap_timer_match' defined but not used [-Wunused-const-variable=]
>    drivers/bluetooth/hci_bcm.c:625:39: warning: 'acpi_bcm_default_gpios' defined but not used [-Wunused-const-variable=]
>    drivers/char/hw_random/omap-rng.c:92:18: warning: 'reg_map_omap4' defined but not used [-Wunused-const-variable=]
>    drivers/devfreq/exynos/exynos5_bus.c:381:32: warning: 'exynos5_busfreq_int_pm' defined but not used [-Wunused-const-variable=]
>    drivers/dma/mv_xor.c:1139:34: warning: 'mv_xor_dt_ids' defined but not used [-Wunused-const-variable=]
>    
>    This is similar to the existing -Wunused-but-set-variable warning
>    that was added in an earlier release and that we disable by default
>    now and only enable when W=1 is set, so it makes sense to do
>    the same here. Once we have eliminated the majority of the
>    warnings for both, we can put them back into the default list.
>    
>    We probably want this in backport kernels as well, to allow building
>    them with gcc-6 without introducing extra warnings.
>    
>    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>    Acked-by: Olof Johansson <olof@lixom.net>
>    Acked-by: Lee Jones <lee.jones@linaro.org>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Michal Marek <mmarek@suse.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 10443b37022d55e8ff0c705f167b43855155ae81
>Author: Marc Zyngier <marc.zyngier@arm.com>
>Date:   Fri May 6 19:41:56 2016 +0100
>
>    irqchip/gic-v3: Configure all interrupts as non-secure Group-1
>    
>    [ Upstream commit 7c9b973061b03af62734f613f6abec46c0dd4a88 ]
>    
>    The GICv3 driver wrongly assumes that it runs on the non-secure
>    side of a secure-enabled system, while it could be on a system
>    with a single security state, or a GICv3 with GICD_CTLR.DS set.
>    
>    Either way, it is important to configure this properly, or
>    interrupts will simply not be delivered on this HW.
>    
>    Cc: stable@vger.kernel.org
>    Reported-by: Peter Maydell <peter.maydell@linaro.org>
>    Tested-by: Peter Maydell <peter.maydell@linaro.org>
>    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit bfc9ab721fdd1d0a9669cc979c52242c92c586d2
>Author: Will Deacon <will.deacon@arm.com>
>Date:   Tue Apr 26 12:00:00 2016 +0100
>
>    irqchip/gic: Ensure ordering between read of INTACK and shared data
>    
>    [ Upstream commit f86c4fbd930ff6fecf3d8a1c313182bd0f49f496 ]
>    
>    When an IPI is generated by a CPU, the pattern looks roughly like:
>    
>      <write shared data>
>      smp_wmb();
>      <write to GIC to signal SGI>
>    
>    On the receiving CPU we rely on the fact that, once we've taken the
>    interrupt, then the freshly written shared data must be visible to us.
>    Put another way, the CPU isn't going to speculate taking an interrupt.
>    
>    Unfortunately, this assumption turns out to be broken.
>    
>    Consider that CPUx wants to send an IPI to CPUy, which will cause CPUy
>    to read some shared_data. Before CPUx has done anything, a random
>    peripheral raises an IRQ to the GIC and the IRQ line on CPUy is raised.
>    CPUy then takes the IRQ and starts executing the entry code, heading
>    towards gic_handle_irq. Furthermore, let's assume that a bunch of the
>    previous interrupts handled by CPUy were SGIs, so the branch predictor
>    kicks in and speculates that irqnr will be <16 and we're likely to
>    head into handle_IPI. The prefetcher then grabs a speculative copy of
>    shared_data which contains a stale value.
>    
>    Meanwhile, CPUx gets round to updating shared_data and asking the GIC
>    to send an SGI to CPUy. Internally, the GIC decides that the SGI is
>    more important than the peripheral interrupt (which hasn't yet been
>    ACKed) but doesn't need to do anything to CPUy, because the IRQ line
>    is already raised.
>    
>    CPUy then reads the ACK register on the GIC, sees the SGI value which
>    confirms the branch prediction and we end up with a stale shared_data
>    value.
>    
>    This patch fixes the problem by adding an smp_rmb() to the IPI entry
>    code in gic_handle_irq. As it turns out, the combination of a control
>    dependency and an ISB instruction from the EOI in the GICv3 driver is
>    enough to provide the ordering we need, so we add a comment there
>    justifying the absence of an explicit smp_rmb().
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Will Deacon <will.deacon@arm.com>
>    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ff0ee291ab639071bf868d904ec7f99de37480c5
>Author: Arnd Bergmann <arnd@arndb.de>
>Date:   Mon Apr 25 17:35:30 2016 +0200
>
>    gcov: disable tree-loop-im to reduce stack usage
>    
>    [ Upstream commit c87bf431448b404a6ef5fbabd74c0e3e42157a7f ]
>    
>    Enabling CONFIG_GCOV_PROFILE_ALL produces us a lot of warnings like
>    
>    lib/lz4/lz4hc_compress.c: In function 'lz4_compresshcctx':
>    lib/lz4/lz4hc_compress.c:514:1: warning: the frame size of 1504 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>    
>    After some investigation, I found that this behavior started with gcc-4.9,
>    and opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69702.
>    A suggested workaround for it is to use the -fno-tree-loop-im
>    flag that turns off one of the optimization stages in gcc, so the
>    code runs a little slower but does not use excessive amounts
>    of stack.
>    
>    We could make this conditional on the gcc version, but I could not
>    find an easy way to do this in Kbuild and the benefit would be
>    fairly small, given that most of the gcc version in production are
>    affected now.
>    
>    I'm marking this for 'stable' backports because it addresses a bug
>    with code generation in gcc that exists in all kernel versions
>    with the affected gcc releases.
>    
>    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>    Acked-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Michal Marek <mmarek@suse.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 456b98fed981449d4304b4a6bf0fbfd8ddc266e7
>Author: James Hogan <james.hogan@imgtec.com>
>Date:   Fri Apr 22 10:38:46 2016 +0100
>
>    MIPS: KVM: Fix timer IRQ race when writing CP0_Compare
>    
>    [ Upstream commit b45bacd2d048f405c7760e5cc9b60dd67708734f ]
>    
>    Writing CP0_Compare clears the timer interrupt pending bit
>    (CP0_Cause.TI), but this wasn't being done atomically. If a timer
>    interrupt raced with the write of the guest CP0_Compare, the timer
>    interrupt could end up being pending even though the new CP0_Compare is
>    nowhere near CP0_Count.
>    
>    We were already updating the hrtimer expiry with
>    kvm_mips_update_hrtimer(), which used both kvm_mips_freeze_hrtimer() and
>    kvm_mips_resume_hrtimer(). Close the race window by expanding out
>    kvm_mips_update_hrtimer(), and clearing CP0_Cause.TI and setting
>    CP0_Compare between the freeze and resume. Since the pending timer
>    interrupt should not be cleared when CP0_Compare is written via the KVM
>    user API, an ack argument is added to distinguish the source of the
>    write.
>    
>    Fixes: e30492bbe95a ("MIPS: KVM: Rewrite count/compare timer emulation")
>    Signed-off-by: James Hogan <james.hogan@imgtec.com>
>    Cc: Paolo Bonzini <pbonzini@redhat.com>
>    Cc: "Radim KrÃÂmÃÂ¡Ãâ¢" <rkrcmar@redhat.com>
>    Cc: Ralf Baechle <ralf@linux-mips.org>
>    Cc: linux-mips@linux-mips.org
>    Cc: kvm@vger.kernel.org
>    Cc: <stable@vger.kernel.org> # 3.16.x-
>    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8106278c3064f730d8257f74498b1c18dbb66e93
>Author: James Hogan <james.hogan@imgtec.com>
>Date:   Fri Apr 22 10:38:45 2016 +0100
>
>    MIPS: KVM: Fix timer IRQ race when freezing timer
>    
>    [ Upstream commit 4355c44f063d3de4f072d796604c7f4ba4085cc3 ]
>    
>    There's a particularly narrow and subtle race condition when the
>    software emulated guest timer is frozen which can allow a guest timer
>    interrupt to be missed.
>    
>    This happens due to the hrtimer expiry being inexact, so very
>    occasionally the freeze time will be after the moment when the emulated
>    CP0_Count transitions to the same value as CP0_Compare (so an IRQ should
>    be generated), but before the moment when the hrtimer is due to expire
>    (so no IRQ is generated). The IRQ won't be generated when the timer is
>    resumed either, since the resume CP0_Count will already match CP0_Compare.
>    
>    With VZ guests in particular this is far more likely to happen, since
>    the soft timer may be frozen frequently in order to restore the timer
>    state to the hardware guest timer. This happens after 5-10 hours of
>    guest soak testing, resulting in an overflow in guest kernel timekeeping
>    calculations, hanging the guest. A more focussed test case to
>    intentionally hit the race (with the help of a new hypcall to cause the
>    timer state to migrated between hardware & software) hits the condition
>    fairly reliably within around 30 seconds.
>    
>    Instead of relying purely on the inexact hrtimer expiry to determine
>    whether an IRQ should be generated, read the guest CP0_Compare and
>    directly check whether the freeze time is before or after it. Only if
>    CP0_Count is on or after CP0_Compare do we check the hrtimer expiry to
>    determine whether the last IRQ has already been generated (which will
>    have pushed back the expiry by one timer period).
>    
>    Fixes: e30492bbe95a ("MIPS: KVM: Rewrite count/compare timer emulation")
>    Signed-off-by: James Hogan <james.hogan@imgtec.com>
>    Cc: Paolo Bonzini <pbonzini@redhat.com>
>    Cc: "Radim KrÃÂmÃÂ¡Ãâ¢" <rkrcmar@redhat.com>
>    Cc: Ralf Baechle <ralf@linux-mips.org>
>    Cc: linux-mips@linux-mips.org
>    Cc: kvm@vger.kernel.org
>    Cc: <stable@vger.kernel.org> # 3.16.x-
>    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ceee7b2f9dbb0c8ac05b00f2095662587c98f861
>Author: Catalin Vasile <cata.vasile@nxp.com>
>Date:   Fri May 6 16:18:53 2016 +0300
>
>    crypto: caam - fix caam_jr_alloc() ret code
>    
>    [ Upstream commit e930c765ca5c6b039cd22ebfb4504ea7b5dab43d ]
>    
>    caam_jr_alloc() used to return NULL if a JR device could not be
>    allocated for a session. In turn, every user of this function used
>    IS_ERR() function to verify if anything went wrong, which does NOT look
>    for NULL values. This made the kernel crash if the sanity check failed,
>    because the driver continued to think it had allocated a valid JR dev
>    instance to the session and at some point it tries to do a caam_jr_free()
>    on a NULL JR dev pointer.
>    This patch is a fix for this issue.
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Catalin Vasile <cata.vasile@nxp.com>
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7124f5dfff7b22fd91546ce7dbf9e80b56f0d61f
>Author: Johan Hovold <johan@kernel.org>
>Date:   Sun May 8 20:08:02 2016 +0200
>
>    USB: serial: quatech2: fix use-after-free in probe error path
>    
>    [ Upstream commit 028c49f5e02a257c94129cd815f7c8485f51d4ef ]
>    
>    The interface read URB is submitted in attach, but was only unlinked by
>    the driver at disconnect.
>    
>    In case of a late probe error (e.g. due to failed minor allocation),
>    disconnect is never called and we would end up with active URBs for an
>    unbound interface. This in turn could lead to deallocated memory being
>    dereferenced in the completion callback.
>    
>    Fixes: f7a33e608d9a ("USB: serial: add quatech2 usb to serial driver")
>    Cc: stable <stable@vger.kernel.org>	# v3.5: 40d04738491d
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 17e958ca3f508c361325688ab1da7144febb35fe
>Author: Johan Hovold <johan@kernel.org>
>Date:   Sun May 8 20:08:01 2016 +0200
>
>    USB: serial: mxuport: fix use-after-free in probe error path
>    
>    [ Upstream commit 9e45284984096314994777f27e1446dfbfd2f0d7 ]
>    
>    The interface read and event URBs are submitted in attach, but were
>    never explicitly unlinked by the driver. Instead the URBs would have
>    been killed by usb-serial core on disconnect.
>    
>    In case of a late probe error (e.g. due to failed minor allocation),
>    disconnect is never called and we could end up with active URBs for an
>    unbound interface. This in turn could lead to deallocated memory being
>    dereferenced in the completion callbacks.
>    
>    Fixes: ee467a1f2066 ("USB: serial: add Moxa UPORT 12XX/14XX/16XX
>    driver")
>    Cc: stable <stable@vger.kernel.org>	# v3.14
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d2e9eeb2504c73c09c415e5d4fc4cc33ffc4cb9f
>Author: Johan Hovold <johan@kernel.org>
>Date:   Sun May 8 20:07:58 2016 +0200
>
>    USB: serial: keyspan: fix use-after-free in probe error path
>    
>    [ Upstream commit 35be1a71d70775e7bd7e45fa6d2897342ff4c9d2 ]
>    
>    The interface instat and indat URBs were submitted in attach, but never
>    unlinked in release before deallocating the corresponding transfer
>    buffers.
>    
>    In the case of a late probe error (e.g. due to failed minor allocation),
>    disconnect would not have been called before release, causing the
>    buffers to be freed while the URBs are still in use. We'd also end up
>    with active URBs for an unbound interface.
>    
>    Fixes: f9c99bb8b3a1 ("USB: usb-serial: replace shutdown with disconnect,
>    release")
>    Cc: stable <stable@vger.kernel.org>	# v2.6.31
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 90eb29f547e7de02d663257a3e8b042b80940925
>Author: Johan Hovold <johan@kernel.org>
>Date:   Sun May 8 20:07:57 2016 +0200
>
>    USB: serial: io_edgeport: fix memory leaks in probe error path
>    
>    [ Upstream commit c8d62957d450cc1a22ce3242908709fe367ddc8e ]
>    
>    URBs and buffers allocated in attach for Epic devices would never be
>    deallocated in case of a later probe error (e.g. failure to allocate
>    minor numbers) as disconnect is then never called.
>    
>    Fix by moving deallocation to release and making sure that the
>    URBs are first unlinked.
>    
>    Fixes: f9c99bb8b3a1 ("USB: usb-serial: replace shutdown with disconnect,
>    release")
>    Cc: stable <stable@vger.kernel.org>	# v2.6.31
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7bbc1379766b1887cd7b3c225c78acca5b82ec5e
>Author: Johan Hovold <johan@kernel.org>
>Date:   Sun May 8 20:07:56 2016 +0200
>
>    USB: serial: io_edgeport: fix memory leaks in attach error path
>    
>    [ Upstream commit c5c0c55598cefc826d6cfb0a417eeaee3631715c ]
>    
>    Private data, URBs and buffers allocated for Epic devices during
>    attach were never released on errors (e.g. missing endpoints).
>    
>    Fixes: 6e8cf7751f9f ("USB: add EPIC support to the io_edgeport driver")
>    Cc: stable <stable@vger.kernel.org>	# v2.6.21
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ec391566f8e498f5f3d92ff6c6abfdf6ac5a164b
>Author: Roger Quadros <rogerq@ti.com>
>Date:   Mon May 9 11:28:37 2016 +0300
>
>    mfd: omap-usb-tll: Fix scheduling while atomic BUG
>    
>    [ Upstream commit b49b927f16acee626c56a1af4ab4cb062f75b5df ]
>    
>    We shouldn't be calling clk_prepare_enable()/clk_prepare_disable()
>    in an atomic context.
>    
>    Fixes the following issue:
>    
>    [    5.830970] ehci-omap: OMAP-EHCI Host Controller driver
>    [    5.830974] driver_register 'ehci-omap'
>    [    5.895849] driver_register 'wl1271_sdio'
>    [    5.896870] BUG: scheduling while atomic: udevd/994/0x00000002
>    [    5.896876] 4 locks held by udevd/994:
>    [    5.896904]  #0:  (&dev->mutex){......}, at: [<c049597c>] __driver_attach+0x60/0xac
>    [    5.896923]  #1:  (&dev->mutex){......}, at: [<c049598c>] __driver_attach+0x70/0xac
>    [    5.896946]  #2:  (tll_lock){+.+...}, at: [<c04c2630>] omap_tll_enable+0x2c/0xd0
>    [    5.896966]  #3:  (prepare_lock){+.+...}, at: [<c05ce9c8>] clk_prepare_lock+0x48/0xe0
>    [    5.897042] Modules linked in: wlcore_sdio(+) ehci_omap(+) dwc3_omap snd_soc_ts3a225e leds_is31fl319x bq27xxx_battery_i2c tsc2007 bq27xxx_battery bq2429x_charger ina2xx tca8418_keypad as5013 leds_tca6507 twl6040_vibra gpio_twl6040 bmp085_i2c(+) palmas_gpadc usb3503 palmas_pwrbutton bmg160_i2c(+) bmp085 bma150(+) bmg160_core bmp280 input_polldev snd_soc_omap_mcbsp snd_soc_omap_mcpdm snd_soc_omap snd_pcm_dmaengine
>    [    5.897048] Preemption disabled at:[<  (null)>]   (null)
>    [    5.897051]
>    [    5.897059] CPU: 0 PID: 994 Comm: udevd Not tainted 4.6.0-rc5-letux+ #233
>    [    5.897062] Hardware name: Generic OMAP5 (Flattened Device Tree)
>    [    5.897076] [<c010e714>] (unwind_backtrace) from [<c010af34>] (show_stack+0x10/0x14)
>    [    5.897087] [<c010af34>] (show_stack) from [<c040aa7c>] (dump_stack+0x88/0xc0)
>    [    5.897099] [<c040aa7c>] (dump_stack) from [<c020c558>] (__schedule_bug+0xac/0xd0)
>    [    5.897111] [<c020c558>] (__schedule_bug) from [<c06f3d44>] (__schedule+0x88/0x7e4)
>    [    5.897120] [<c06f3d44>] (__schedule) from [<c06f46d8>] (schedule+0x9c/0xc0)
>    [    5.897129] [<c06f46d8>] (schedule) from [<c06f4904>] (schedule_preempt_disabled+0x14/0x20)
>    [    5.897140] [<c06f4904>] (schedule_preempt_disabled) from [<c06f64e4>] (mutex_lock_nested+0x258/0x43c)
>    [    5.897150] [<c06f64e4>] (mutex_lock_nested) from [<c05ce9c8>] (clk_prepare_lock+0x48/0xe0)
>    [    5.897160] [<c05ce9c8>] (clk_prepare_lock) from [<c05d0e7c>] (clk_prepare+0x10/0x28)
>    [    5.897169] [<c05d0e7c>] (clk_prepare) from [<c04c2668>] (omap_tll_enable+0x64/0xd0)
>    [    5.897180] [<c04c2668>] (omap_tll_enable) from [<c04c1728>] (usbhs_runtime_resume+0x18/0x17c)
>    [    5.897192] [<c04c1728>] (usbhs_runtime_resume) from [<c049d404>] (pm_generic_runtime_resume+0x2c/0x40)
>    [    5.897202] [<c049d404>] (pm_generic_runtime_resume) from [<c049f180>] (__rpm_callback+0x38/0x68)
>    [    5.897210] [<c049f180>] (__rpm_callback) from [<c049f220>] (rpm_callback+0x70/0x88)
>    [    5.897218] [<c049f220>] (rpm_callback) from [<c04a0a00>] (rpm_resume+0x4ec/0x7ec)
>    [    5.897227] [<c04a0a00>] (rpm_resume) from [<c04a0f48>] (__pm_runtime_resume+0x4c/0x64)
>    [    5.897236] [<c04a0f48>] (__pm_runtime_resume) from [<c04958dc>] (driver_probe_device+0x30/0x70)
>    [    5.897246] [<c04958dc>] (driver_probe_device) from [<c04959a4>] (__driver_attach+0x88/0xac)
>    [    5.897256] [<c04959a4>] (__driver_attach) from [<c04940f8>] (bus_for_each_dev+0x50/0x84)
>    [    5.897267] [<c04940f8>] (bus_for_each_dev) from [<c0494e40>] (bus_add_driver+0xcc/0x1e4)
>    [    5.897276] [<c0494e40>] (bus_add_driver) from [<c0496914>] (driver_register+0xac/0xf4)
>    [    5.897286] [<c0496914>] (driver_register) from [<c01018e0>] (do_one_initcall+0x100/0x1b8)
>    [    5.897296] [<c01018e0>] (do_one_initcall) from [<c01c7a54>] (do_init_module+0x58/0x1c0)
>    [    5.897304] [<c01c7a54>] (do_init_module) from [<c01c8a3c>] (SyS_finit_module+0x88/0x90)
>    [    5.897313] [<c01c8a3c>] (SyS_finit_module) from [<c0107120>] (ret_fast_syscall+0x0/0x1c)
>    [    5.912697] ------------[ cut here ]------------
>    [    5.912711] WARNING: CPU: 0 PID: 994 at kernel/sched/core.c:2996 _raw_spin_unlock+0x28/0x58
>    [    5.912717] DEBUG_LOCKS_WARN_ON(val > preempt_count())
>    
>    Cc: <stable@vger.kernel.org>
>    Reported-by: H. Nikolaus Schaller <hns@goldelico.com>
>    Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
>    Signed-off-by: Roger Quadros <rogerq@ti.com>
>    Signed-off-by: Lee Jones <lee.jones@linaro.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1187e91bc7a476df4c2d78baa257517c33bca5dc
>Author: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
>Date:   Tue Apr 28 12:53:35 2015 -0700
>
>    MIPS64: R6: R2 emulation bugfix
>    
>    [ Upstream commit 41fa29e4d8cf4150568a0fe9bb4d62229f9caed5 ]
>    
>    Error recovery pointers for fixups was improperly set as ".word"
>    which is unsuitable for MIPS64.
>    
>    Replaced by STR(PTR)
>    
>    [ralf@linux-mips.org: Apply changes as requested in the review process.]
>    
>    Signed-off-by: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
>    Reviewed-by: James Hogan <james.hogan@imgtec.com>
>    Reviewed-by: Markos Chandras <markos.chandras@imgtec.com>
>    Fixes: b0a668fb2038 ("MIPS: kernel: mips-r2-to-r6-emul: Add R2 emulator for MIPS R6")
>    Cc: macro@linux-mips.org
>    Cc: linux-mips@linux-mips.org
>    Cc: linux-kernel@vger.kernel.org
>    Cc: <stable@vger.kernel.org> # 4.0+
>    Patchwork: https://patchwork.linux-mips.org/patch/9911/
>    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c2915ee9fcb019acacd50015e6f9dd01e878d966
>Author: James Hogan <james.hogan@imgtec.com>
>Date:   Fri Dec 4 22:25:02 2015 +0000
>
>    MIPS: Avoid using unwind_stack() with usermode
>    
>    [ Upstream commit 81a76d7119f63c359750e4adeff922a31ad1135f ]
>    
>    When showing backtraces in response to traps, for example crashes and
>    address errors (usually unaligned accesses) when they are set in debugfs
>    to be reported, unwind_stack will be used if the PC was in the kernel
>    text address range. However since EVA it is possible for user and kernel
>    address ranges to overlap, and even without EVA userland can still
>    trigger an address error by jumping to a KSeg0 address.
>    
>    Adjust the check to also ensure that it was running in kernel mode. I
>    don't believe any harm can come of this problem, since unwind_stack() is
>    sufficiently defensive, however it is only meant for unwinding kernel
>    code, so to be correct it should use the raw backtracing instead.
>    
>    Signed-off-by: James Hogan <james.hogan@imgtec.com>
>    Reviewed-by: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
>    Cc: linux-mips@linux-mips.org
>    Cc: <stable@vger.kernel.org> # 3.15+
>    Patchwork: https://patchwork.linux-mips.org/patch/11701/
>    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>    (cherry picked from commit d2941a975ac745c607dfb590e92bb30bc352dad9)
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit dd95033f7d938a3c8521bb0f4abeeee032fb35a1
>Author: James Hogan <james.hogan@imgtec.com>
>Date:   Fri Dec 4 22:25:01 2015 +0000
>
>    MIPS: Don't unwind to user mode with EVA
>    
>    [ Upstream commit a816b306c62195b7c43c92cb13330821a96bdc27 ]
>    
>    When unwinding through IRQs and exceptions, the unwinding only continues
>    if the PC is a kernel text address, however since EVA it is possible for
>    user and kernel address ranges to overlap, potentially allowing
>    unwinding to continue to user mode if the user PC happens to be in the
>    kernel text address range.
>    
>    Adjust the check to also ensure that the register state from before the
>    exception is actually running in kernel mode, i.e. !user_mode(regs).
>    
>    I don't believe any harm can come of this problem, since the PC is only
>    output, the stack pointer is checked to ensure it resides within the
>    task's stack page before it is dereferenced in search of the return
>    address, and the return address register is similarly only output (if
>    the PC is in a leaf function or the beginning of a non-leaf function).
>    
>    However unwind_stack() is only meant for unwinding kernel code, so to be
>    correct the unwind should stop there.
>    
>    Signed-off-by: James Hogan <james.hogan@imgtec.com>
>    Reviewed-by: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
>    Cc: linux-mips@linux-mips.org
>    Cc: <stable@vger.kernel.org> # 3.15+
>    Patchwork: https://patchwork.linux-mips.org/patch/11700/
>    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 22a4a25999d813d6256077de45f859411b766cd9
>Author: James Hogan <james.hogan@imgtec.com>
>Date:   Mon Feb 8 18:43:49 2016 +0000
>
>    MIPS: Fix siginfo.h to use strict posix types
>    
>    [ Upstream commit 5daebc477da4dfeb31ae193d83084def58fd2697 ]
>    
>    Commit 85efde6f4e0d ("make exported headers use strict posix types")
>    changed the asm-generic siginfo.h to use the __kernel_* types, and
>    commit 3a471cbc081b ("remove __KERNEL_STRICT_NAMES") make the internal
>    types accessible only to the kernel, but the MIPS implementation hasn't
>    been updated to match.
>    
>    Switch to proper types now so that the exported asm/siginfo.h won't
>    produce quite so many compiler errors when included alone by a user
>    program.
>    
>    Signed-off-by: James Hogan <james.hogan@imgtec.com>
>    Cc: Christopher Ferris <cferris@google.com>
>    Cc: linux-mips@linux-mips.org
>    Cc: <stable@vger.kernel.org> # 2.6.30-
>    Cc: linux-kernel@vger.kernel.org
>    Patchwork: https://patchwork.linux-mips.org/patch/12477/
>    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5b59ae1ed02bc606b5c32e4ce3f5afd6691cafb4
>Author: Oliver Hartkopp <socketcan@hartkopp.net>
>Date:   Mon Mar 21 20:18:21 2016 +0100
>
>    can: fix handling of unmodifiable configuration options
>    
>    [ Upstream commit bb208f144cf3f59d8f89a09a80efd04389718907 ]
>    
>    As described in 'can: m_can: tag current CAN FD controllers as non-ISO'
>    (6cfda7fbebe) it is possible to define fixed configuration options by
>    setting the according bit in 'ctrlmode' and clear it in 'ctrlmode_supported'.
>    This leads to the incovenience that the fixed configuration bits can not be
>    passed by netlink even when they have the correct values (e.g. non-ISO, FD).
>    
>    This patch fixes that issue and not only allows fixed set bit values to be set
>    again but now requires(!) to provide these fixed values at configuration time.
>    A valid CAN FD configuration consists of a nominal/arbitration bittiming, a
>    data bittiming and a control mode with CAN_CTRLMODE_FD set - which is now
>    enforced by a new can_validate() function. This fix additionally removed the
>    inconsistency that was prohibiting the support of 'CANFD-only' controller
>    drivers, like the RCar CAN FD.
>    
>    For this reason a new helper can_set_static_ctrlmode() has been introduced to
>    provide a proper interface to handle static enabled CAN controller options.
>    
>    Reported-by: Ramesh Shanmugasundaram <ramesh.shanmugasundaram@bp.renesas.com>
>    Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
>    Reviewed-by: Ramesh Shanmugasundaram  <ramesh.shanmugasundaram@bp.renesas.com>
>    Cc: <stable@vger.kernel.org> # >= 3.18
>    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0839058ab07fde8fb6edbebcc4046dd3b49a951f
>Author: Catalin Marinas <catalin.marinas@arm.com>
>Date:   Thu May 5 10:44:02 2016 +0100
>
>    arm64: Ensure pmd_present() returns false after pmd_mknotpresent()
>    
>    [ Upstream commit 5bb1cc0ff9a6b68871970737e6c4c16919928d8b ]
>    
>    Currently, pmd_present() only checks for a non-zero value, returning
>    true even after pmd_mknotpresent() (which only clears the type bits).
>    This patch converts pmd_present() to using pte_present(), similar to the
>    other pmd_*() checks. As a side effect, it will return true for
>    PROT_NONE mappings, though they are not yet used by the kernel with
>    transparent huge pages.
>    
>    For consistency, also change pmd_mknotpresent() to only clear the
>    PMD_SECT_VALID bit, even though the PMD_TABLE_BIT is already 0 for block
>    mappings (no functional change). The unused PMD_SECT_PROT_NONE
>    definition is removed as transparent huge pages use the pte page prot
>    values.
>    
>    Fixes: 9c7e535fcc17 ("arm64: mm: Route pmd thp functions through pte equivalents")
>    Cc: <stable@vger.kernel.org> # 3.15+
>    Reviewed-by: Will Deacon <will.deacon@arm.com>
>    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
>    Signed-off-by: Will Deacon <will.deacon@arm.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7346b8742de4bd56008f26cf36a1d59a0534f430
>Author: Nicolai Stange <nicstange@gmail.com>
>Date:   Thu May 5 19:46:19 2016 -0400
>
>    ext4: silence UBSAN in ext4_mb_init()
>    
>    [ Upstream commit 935244cd54b86ca46e69bc6604d2adfb1aec2d42 ]
>    
>    Currently, in ext4_mb_init(), there's a loop like the following:
>    
>      do {
>        ...
>        offset += 1 << (sb->s_blocksize_bits - i);
>        i++;
>      } while (i <= sb->s_blocksize_bits + 1);
>    
>    Note that the updated offset is used in the loop's next iteration only.
>    
>    However, at the last iteration, that is at i == sb->s_blocksize_bits + 1,
>    the shift count becomes equal to (unsigned)-1 > 31 (c.f. C99 6.5.7(3))
>    and UBSAN reports
>    
>      UBSAN: Undefined behaviour in fs/ext4/mballoc.c:2621:15
>      shift exponent 4294967295 is too large for 32-bit type 'int'
>      [...]
>      Call Trace:
>       [<ffffffff818c4d25>] dump_stack+0xbc/0x117
>       [<ffffffff818c4c69>] ? _atomic_dec_and_lock+0x169/0x169
>       [<ffffffff819411ab>] ubsan_epilogue+0xd/0x4e
>       [<ffffffff81941cac>] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254
>       [<ffffffff81941ab1>] ? __ubsan_handle_load_invalid_value+0x158/0x158
>       [<ffffffff814b6dc1>] ? kmem_cache_alloc+0x101/0x390
>       [<ffffffff816fc13b>] ? ext4_mb_init+0x13b/0xfd0
>       [<ffffffff814293c7>] ? create_cache+0x57/0x1f0
>       [<ffffffff8142948a>] ? create_cache+0x11a/0x1f0
>       [<ffffffff821c2168>] ? mutex_lock+0x38/0x60
>       [<ffffffff821c23ab>] ? mutex_unlock+0x1b/0x50
>       [<ffffffff814c26ab>] ? put_online_mems+0x5b/0xc0
>       [<ffffffff81429677>] ? kmem_cache_create+0x117/0x2c0
>       [<ffffffff816fcc49>] ext4_mb_init+0xc49/0xfd0
>       [...]
>    
>    Observe that the mentioned shift exponent, 4294967295, equals (unsigned)-1.
>    
>    Unless compilers start to do some fancy transformations (which at least
>    GCC 6.0.0 doesn't currently do), the issue is of cosmetic nature only: the
>    such calculated value of offset is never used again.
>    
>    Silence UBSAN by introducing another variable, offset_incr, holding the
>    next increment to apply to offset and adjust that one by right shifting it
>    by one position per loop iteration.
>    
>    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114701
>    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112161
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Nicolai Stange <nicstange@gmail.com>
>    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 76caa7178c24de91cdb2ed0033650c623ad580e3
>Author: Nicolai Stange <nicstange@gmail.com>
>Date:   Thu May 5 17:38:03 2016 -0400
>
>    ext4: address UBSAN warning in mb_find_order_for_block()
>    
>    [ Upstream commit b5cb316cdf3a3f5f6125412b0f6065185240cfdc ]
>    
>    Currently, in mb_find_order_for_block(), there's a loop like the following:
>    
>      while (order <= e4b->bd_blkbits + 1) {
>        ...
>        bb += 1 << (e4b->bd_blkbits - order);
>      }
>    
>    Note that the updated bb is used in the loop's next iteration only.
>    
>    However, at the last iteration, that is at order == e4b->bd_blkbits + 1,
>    the shift count becomes negative (c.f. C99 6.5.7(3)) and UBSAN reports
>    
>      UBSAN: Undefined behaviour in fs/ext4/mballoc.c:1281:11
>      shift exponent -1 is negative
>      [...]
>      Call Trace:
>       [<ffffffff818c4d35>] dump_stack+0xbc/0x117
>       [<ffffffff818c4c79>] ? _atomic_dec_and_lock+0x169/0x169
>       [<ffffffff819411bb>] ubsan_epilogue+0xd/0x4e
>       [<ffffffff81941cbc>] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254
>       [<ffffffff81941ac1>] ? __ubsan_handle_load_invalid_value+0x158/0x158
>       [<ffffffff816e93a0>] ? ext4_mb_generate_from_pa+0x590/0x590
>       [<ffffffff816502c8>] ? ext4_read_block_bitmap_nowait+0x598/0xe80
>       [<ffffffff816e7b7e>] mb_find_order_for_block+0x1ce/0x240
>       [...]
>    
>    Unless compilers start to do some fancy transformations (which at least
>    GCC 6.0.0 doesn't currently do), the issue is of cosmetic nature only: the
>    such calculated value of bb is never used again.
>    
>    Silence UBSAN by introducing another variable, bb_incr, holding the next
>    increment to apply to bb and adjust that one by right shifting it by one
>    position per loop iteration.
>    
>    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114701
>    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112161
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Nicolai Stange <nicstange@gmail.com>
>    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f245ed015ed94730b9a9fea17029d7d79fa88dd7
>Author: Jan Kara <jack@suse.cz>
>Date:   Thu May 5 11:10:15 2016 -0400
>
>    ext4: fix oops on corrupted filesystem
>    
>    [ Upstream commit 74177f55b70e2f2be770dd28684dd6d17106a4ba ]
>    
>    When filesystem is corrupted in the right way, it can happen
>    ext4_mark_iloc_dirty() in ext4_orphan_add() returns error and we
>    subsequently remove inode from the in-memory orphan list. However this
>    deletion is done with list_del(&EXT4_I(inode)->i_orphan) and thus we
>    leave i_orphan list_head with a stale content. Later we can look at this
>    content causing list corruption, oops, or other issues. The reported
>    trace looked like:
>    
>    WARNING: CPU: 0 PID: 46 at lib/list_debug.c:53 __list_del_entry+0x6b/0x100()
>    list_del corruption, 0000000061c1d6e0->next is LIST_POISON1
>    0000000000100100)
>    CPU: 0 PID: 46 Comm: ext4.exe Not tainted 4.1.0-rc4+ #250
>    Stack:
>     60462947 62219960 602ede24 62219960
>     602ede24 603ca293 622198f0 602f02eb
>     62219950 6002c12c 62219900 601b4d6b
>    Call Trace:
>     [<6005769c>] ? vprintk_emit+0x2dc/0x5c0
>     [<602ede24>] ? printk+0x0/0x94
>     [<600190bc>] show_stack+0xdc/0x1a0
>     [<602ede24>] ? printk+0x0/0x94
>     [<602ede24>] ? printk+0x0/0x94
>     [<602f02eb>] dump_stack+0x2a/0x2c
>     [<6002c12c>] warn_slowpath_common+0x9c/0xf0
>     [<601b4d6b>] ? __list_del_entry+0x6b/0x100
>     [<6002c254>] warn_slowpath_fmt+0x94/0xa0
>     [<602f4d09>] ? __mutex_lock_slowpath+0x239/0x3a0
>     [<6002c1c0>] ? warn_slowpath_fmt+0x0/0xa0
>     [<60023ebf>] ? set_signals+0x3f/0x50
>     [<600a205a>] ? kmem_cache_free+0x10a/0x180
>     [<602f4e88>] ? mutex_lock+0x18/0x30
>     [<601b4d6b>] __list_del_entry+0x6b/0x100
>     [<601177ec>] ext4_orphan_del+0x22c/0x2f0
>     [<6012f27c>] ? __ext4_journal_start_sb+0x2c/0xa0
>     [<6010b973>] ? ext4_truncate+0x383/0x390
>     [<6010bc8b>] ext4_write_begin+0x30b/0x4b0
>     [<6001bb50>] ? copy_from_user+0x0/0xb0
>     [<601aa840>] ? iov_iter_fault_in_readable+0xa0/0xc0
>     [<60072c4f>] generic_perform_write+0xaf/0x1e0
>     [<600c4166>] ? file_update_time+0x46/0x110
>     [<60072f0f>] __generic_file_write_iter+0x18f/0x1b0
>     [<6010030f>] ext4_file_write_iter+0x15f/0x470
>     [<60094e10>] ? unlink_file_vma+0x0/0x70
>     [<6009b180>] ? unlink_anon_vmas+0x0/0x260
>     [<6008f169>] ? free_pgtables+0xb9/0x100
>     [<600a6030>] __vfs_write+0xb0/0x130
>     [<600a61d5>] vfs_write+0xa5/0x170
>     [<600a63d6>] SyS_write+0x56/0xe0
>     [<6029fcb0>] ? __libc_waitpid+0x0/0xa0
>     [<6001b698>] handle_syscall+0x68/0x90
>     [<6002633d>] userspace+0x4fd/0x600
>     [<6002274f>] ? save_registers+0x1f/0x40
>     [<60028bd7>] ? arch_prctl+0x177/0x1b0
>     [<60017bd5>] fork_handler+0x85/0x90
>    
>    Fix the problem by using list_del_init() as we always should with
>    i_orphan list.
>    
>    CC: stable@vger.kernel.org
>    Reported-by: Vegard Nossum <vegard.nossum@oracle.com>
>    Signed-off-by: Jan Kara <jack@suse.cz>
>    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e4e5983477fd480a044bbaef62a4c53529879b2e
>Author: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com>
>Date:   Wed May 4 16:56:52 2016 -0500
>
>    USB: serial: cp210x: fix hardware flow-control disable
>    
>    [ Upstream commit a377f9e906af4df9071ba8ddba60188cb4013d93 ]
>    
>    A bug in the CRTSCTS handling caused RTS to alternate between
>    
>    CRTSCTS=0 => "RTS is transmit active signal" and
>    CRTSCTS=1 => "RTS is used for receive flow control"
>    
>    instead of
>    
>    CRTSCTS=0 => "RTS is statically active" and
>    CRTSCTS=1 => "RTS is used for receive flow control"
>    
>    This only happened after first having enabled CRTSCTS.
>    
>    Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com>
>    Fixes: 39a66b8d22a3 ("[PATCH] USB: CP2101 Add support for flow control")
>    Cc: stable <stable@vger.kernel.org>
>    [johan: reword commit message ]
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f26c00e60f4ddac7cf972f2752d50094b0d60ff7
>Author: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com>
>Date:   Wed Oct 28 16:02:34 2015 -0500
>
>    USB: cp210x: relocate private data from USB interface to port
>    
>    [ Upstream commit e2ae67a3b55188b0342522d8139acf013feb2a69 ]
>    
>    This change is preparation for implementing a cp2108 bug workaround.
>    The workaround requires storing some private data. Right now the data is
>    attached to the USB interface and allocated in the attach() callback.
>    The bug detection requires USB I/O which is done easier from port_probe()
>    callback rather than attach(). Since the USB access functions take port
>    as a parameter, and since the private data is used exclusively by these
>    functions, it can be allocated in port_probe(). Also, all cp210x devices
>    have exactly 1 port per USB iterface, so moving private data from the USB
>    interface to port is trivial.
>    
>    Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com>
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 18a6470484918d01746712ce33e5fbbd1373edff
>Author: Lv Zheng <lv.zheng@intel.com>
>Date:   Tue May 3 16:48:20 2016 +0800
>
>    ACPI / osi: Fix an issue that acpi_osi=!* cannot disable ACPICA internal strings
>    
>    [ Upstream commit 30c9bb0d7603e7b3f4d6a0ea231e1cddae020c32 ]
>    
>    The order of the _OSI related functionalities is as follows:
>    
>      acpi_blacklisted()
>        acpi_dmi_osi_linux()
>          acpi_osi_setup()
>        acpi_osi_setup()
>          acpi_update_interfaces() if "!*"
>          <<<<<<<<<<<<<<<<<<<<<<<<
>      parse_args()
>        __setup("acpi_osi=")
>          acpi_osi_setup_linux()
>            acpi_update_interfaces() if "!*"
>            <<<<<<<<<<<<<<<<<<<<<<<<
>      acpi_early_init()
>        acpi_initialize_subsystem()
>          acpi_ut_initialize_interfaces()
>          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>      acpi_bus_init()
>        acpi_os_initialize1()
>          acpi_install_interface_handler(acpi_osi_handler)
>          acpi_osi_setup_late()
>            acpi_update_interfaces() for "!"
>            >>>>>>>>>>>>>>>>>>>>>>>>
>      acpi_osi_handler()
>    
>    Since acpi_osi_setup_linux() can override acpi_dmi_osi_linux(), the command
>    line setting can override the DMI detection. That's why acpi_blacklisted()
>    is put before __setup("acpi_osi=").
>    
>    Then we can notice the following wrong invocation order. There are
>    acpi_update_interfaces() (marked by <<<<) calls invoked before
>    acpi_ut_initialize_interfaces() (marked by ^^^^). This makes it impossible
>    to use acpi_osi=!* correctly from OSI DMI table or from the command line.
>    The use of acpi_osi=!* is meant to disable both ACPICA
>    (acpi_gbl_supported_interfaces) and Linux specific strings
>    (osi_setup_entries) while the ACPICA part should have stopped working
>    because of the order issue.
>    
>    This patch fixes this issue by moving acpi_update_interfaces() to where
>    it is invoked for acpi_osi=! (marked by >>>>) as this is ensured to be
>    invoked after acpi_ut_initialize_interfaces() (marked by ^^^^). Linux
>    specific strings are still handled in the original place in order to make
>    the following command line working: acpi_osi=!* acpi_osi="Module Device".
>    
>    Note that since acpi_osi=!* is meant to further disable linux specific
>    string comparing to the acpi_osi=!, there is no such use case in our bug
>    fixing work and hence there is no one using acpi_osi=!* either from the
>    command line or from the DMI quirks, this issue is just a theoretical
>    issue.
>    
>    Fixes: 741d81280ad2 (ACPI: Add facility to remove all _OSI strings)
>    Cc: 3.12+ <stable@vger.kernel.org> # 3.12+
>    Tested-by: Lukas Wunner <lukas@wunner.de>
>    Tested-by: Chen Yu <yu.c.chen@intel.com>
>    Signed-off-by: Lv Zheng <lv.zheng@intel.com>
>    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4d5aaca6145b49ef9fe82dfa6db61a90e83ba912
>Author: Lei Liu <lei35151@163.com>
>Date:   Wed May 4 16:34:22 2016 +0800
>
>    USB: serial: option: add even more ZTE device ids
>    
>    [ Upstream commit 74d2a91aec97ab832790c9398d320413ad185321 ]
>    
>    Add even more ZTE device ids.
>    
>    Signed-off-by: lei liu <liu.lei78@zte.com.cn>
>    Cc: stable <stable@vger.kernel.org>
>    [johan: rebase and replace commit message ]
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit feb498621fc35eb2d8e4929a466abf38c7c60543
>Author: lei liu <liu.lei78@zte.com.cn>
>Date:   Tue May 3 14:44:19 2016 -0700
>
>    USB: serial: option: add more ZTE device ids
>    
>    [ Upstream commit f0d09463c59c2d764a6c6d492cbe6d2c77f27153 ]
>    
>    More ZTE device ids.
>    
>    Signed-off-by: lei liu <liu.lei78@zte.com.cn>
>    Cc: stable <stable@vger.kernel.org>
>    [properly sort them - gregkh]
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 39a8fc74ecc0eaea82f2e32a35f93d584b3de615
>Author: Andreas Werner <andreas.werner@men.de>
>Date:   Tue May 3 12:42:00 2016 +0200
>
>    mcb: Fixed bar number assignment for the gdd
>    
>    [ Upstream commit f75564d343010b025301d9548f2304f48eb25f01 ]
>    
>    The bar number is found in reg2 within the gdd. Therefore
>    we need to change the assigment from reg1 to reg2 which
>    is the correct location.
>    
>    Signed-off-by: Andreas Werner <andreas.werner@men.de>
>    Fixes: '3764e82e5' drivers: Introduce MEN Chameleon Bus
>    Cc: stable@vger.kernel.org # v3.15+
>    Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 27094468938ac9cc4a0b87ed7d5899bd8717e73b
>Author: Mathias Nyman <mathias.nyman@linux.intel.com>
>Date:   Mon May 2 11:39:03 2016 +0300
>
>    usb: misc: usbtest: fix pattern tests for scatterlists.
>    
>    [ Upstream commit cdc77c82a8286b1181b81b6e5ef60c8e83ded7bc ]
>    
>    The current implemenentation restart the sent pattern for each entry in
>    the sg list. The receiving end expects a continuous pattern, and test
>    will fail unless scatterilst entries happen to be aligned with the
>    pattern
>    
>    Fix this by calculating the pattern byte based on total sent size
>    instead of just the current sg entry.
>    
>    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
>    Fixes: 8b5249019352 ("[PATCH] USB: usbtest: scatterlist OUT data pattern testing")
>    Cc: <stable@vger.kernel.org> # v2.6.18+
>    Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>    Acked-by: Alan Stern <stern@rowland.harvard.edu>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit cf2f44ddb7bb3deaee324cc549300484946b19c7
>Author: Alan Stern <stern@rowland.harvard.edu>
>Date:   Tue Sep 1 09:48:01 2015 +0800
>
>    usb: misc: usbtest: format the data pattern according to max packet size
>    
>    [ Upstream commit b9a6e8e1001e28fecbd74c073f5503dac2790563 ]
>    
>    With this change, the host and gadget doesn't need to agree with transfer
>    length for comparing the data, since they doesn't know each other's
>    transfer size, but know max packet size.
>    
>    Signed-off-by: Peter Chen <peter.chen@freescale.com>
>    Acked-by: Michal Nazarewicz <mina86@mina86.com>
>    (Fixed the 'line over 80 characters warning' by Peter Chen)
>    Tested-by: Peter Chen <peter.chen@freescale.com>
>    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
>    Signed-off-by: Felipe Balbi <balbi@ti.com>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d0270cd8487a8cfef918e2a9cd7b6348a4c74618
>Author: Alan Stern <stern@rowland.harvard.edu>
>Date:   Fri Apr 29 15:25:17 2016 -0400
>
>    USB: leave LPM alone if possible when binding/unbinding interface drivers
>    
>    [ Upstream commit 6fb650d43da3e7054984dc548eaa88765a94d49f ]
>    
>    When a USB driver is bound to an interface (either through probing or
>    by claiming it) or is unbound from an interface, the USB core always
>    disables Link Power Management during the transition and then
>    re-enables it afterward.  The reason is because the driver might want
>    to prevent hub-initiated link power transitions, in which case the HCD
>    would have to recalculate the various LPM parameters.  This
>    recalculation takes place when LPM is re-enabled and the new
>    parameters are sent to the device and its parent hub.
>    
>    However, if the driver does not want to prevent hub-initiated link
>    power transitions then none of this work is necessary.  The parameters
>    don't need to be recalculated, and LPM doesn't need to be disabled and
>    re-enabled.
>    
>    It turns out that disabling and enabling LPM can be time-consuming,
>    enough so that it interferes with user programs that want to claim and
>    release interfaces rapidly via usbfs.  Since the usbfs kernel driver
>    doesn't set the disable_hub_initiated_lpm flag, we can speed things up
>    and get the user programs to work by leaving LPM alone whenever the
>    flag isn't set.
>    
>    And while we're improving the way disable_hub_initiated_lpm gets used,
>    let's also fix its kerneldoc.
>    
>    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
>    Tested-by: Matthew Giassa <matthew@giassa.net>
>    CC: Mathias Nyman <mathias.nyman@intel.com>
>    CC: <stable@vger.kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 38f005d9fe711b883f9d836c3ee67b4c1275bd9a
>Author: Schemmel Hans-Christoph <Hans-Christoph.Schemmel@gemalto.com>
>Date:   Fri Apr 29 08:51:06 2016 +0000
>
>    USB: serial: option: add support for Cinterion PH8 and AHxx
>    
>    [ Upstream commit 444f94e9e625f6ec6bbe2cb232a6451c637f35a3 ]
>    
>    Added support for Gemalto's Cinterion PH8 and AHxx products
>    with 2 RmNet Interfaces and products with 1 RmNet + 1 USB Audio interface.
>    
>    In addition some minor renaming and formatting.
>    
>    Signed-off-by: Hans-Christoph Schemmel <hans-christoph.schemmel@gemalto.com>
>    [johan: sort current entries and trim trailing whitespace ]
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1dab35a8a62e5e7c49bf89b844b6efbdebdd34c1
>Author: Andreas Noever <andreas.noever@gmail.com>
>Date:   Sun Apr 10 12:48:27 2016 +0200
>
>    thunderbolt: Fix double free of drom buffer
>    
>    [ Upstream commit 2ffa9a5d76a75abbc1f95c17959fced666095bdd ]
>    
>    If tb_drom_read() fails, sw->drom is freed but not set to NULL.  sw->drom
>    is then freed again in the error path of tb_switch_alloc().
>    
>    The bug can be triggered by unplugging a thunderbolt device shortly after
>    it is detected by the thunderbolt driver.
>    
>    Clear sw->drom if tb_drom_read() fails.
>    
>    [bhelgaas: add Fixes:, stable versions of interest]
>    Fixes: 343fcb8c70d7 ("thunderbolt: Fix nontrivial endpoint devices.")
>    Signed-off-by: Andreas Noever <andreas.noever@gmail.com>
>    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>    CC: stable@vger.kernel.org	# v3.17+
>    CC: Lukas Wunner <lukas@wunner.de>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4efcad5278a3a11312b3b2c9afa3d4bed60b318f
>Author: Zhao Qiang <qiang.zhao@nxp.com>
>Date:   Wed Mar 9 09:48:11 2016 +0800
>
>    QE-UART: add "fsl,t1040-ucc-uart" to of_device_id
>    
>    [ Upstream commit 11ca2b7ab432eb90906168c327733575e68d388f ]
>    
>    New bindings use "fsl,t1040-ucc-uart" as the compatible for qe-uart.
>    So add it.
>    
>    Signed-off-by: Zhao Qiang <qiang.zhao@nxp.com>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 29a7543e33dbb168c1e044a3ad411ce96286924b
>Author: Brian Bloniarz <brian.bloniarz@gmail.com>
>Date:   Sun Mar 6 13:16:30 2016 -0800
>
>    Fix OpenSSH pty regression on close
>    
>    [ Upstream commit 0f40fbbcc34e093255a2b2d70b6b0fb48c3f39aa ]
>    
>    OpenSSH expects the (non-blocking) read() of pty master to return
>    EAGAIN only if it has received all of the slave-side output after
>    it has received SIGCHLD. This used to work on pre-3.12 kernels.
>    
>    This fix effectively forces non-blocking read() and poll() to
>    block for parallel i/o to complete for all ttys. It also unwinds
>    these changes:
>    
>    1) f8747d4a466ab2cafe56112c51b3379f9fdb7a12
>       tty: Fix pty master read() after slave closes
>    
>    2) 52bce7f8d4fc633c9a9d0646eef58ba6ae9a3b73
>       pty, n_tty: Simplify input processing on final close
>    
>    3) 1a48632ffed61352a7810ce089dc5a8bcd505a60
>       pty: Fix input race when closing
>    
>    Inspired by analysis and patch from Marc Aurele La France <tsi@tuyoix.net>
>    
>    Reported-by: Volth <openssh@volth.com>
>    Reported-by: Marc Aurele La France <tsi@tuyoix.net>
>    BugLink: https://bugzilla.mindrot.org/show_bug.cgi?id=52
>    BugLink: https://bugzilla.mindrot.org/show_bug.cgi?id=2492
>    Signed-off-by: Brian Bloniarz <brian.bloniarz@gmail.com>
>    Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d46be34398ab85c4d80ce2747eeef71497d8a01e
>Author: Matthias Schiffer <mschiffer@universe-factory.net>
>Date:   Thu Mar 24 16:02:52 2016 +0100
>
>    MIPS: ath79: make bootconsole wait for both THRE and TEMT
>    
>    [ Upstream commit f5b556c94c8490d42fea79d7b4ae0ecbc291e69d ]
>    
>    This makes the ath79 bootconsole behave the same way as the generic 8250
>    bootconsole.
>    
>    Also waiting for TEMT (transmit buffer is empty) instead of just THRE
>    (transmit buffer is not full) ensures that all characters have been
>    transmitted before the real serial driver starts reconfiguring the serial
>    controller (which would sometimes result in garbage being transmitted.)
>    This change does not cause a visible performance loss.
>    
>    In addition, this seems to fix a hang observed in certain configurations on
>    many AR7xxx/AR9xxx SoCs during autoconfig of the real serial driver.
>    
>    A more complete follow-up patch will disable 8250 autoconfig for ath79
>    altogether (the serial controller is detected as a 16550A, which is not
>    fully compatible with the ath79 serial, and the autoconfig may lead to
>    undefined behavior on ath79.)
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e0934da7eb12fe444a9b9225a9f2c9281d3e2b8a
>Author: Theodore Ts'o <tytso@mit.edu>
>Date:   Sat Apr 30 00:49:54 2016 -0400
>
>    ext4: clean up error handling when orphan list is corrupted
>    
>    [ Upstream commit 7827a7f6ebfcb7f388dc47fddd48567a314701ba ]
>    
>    Instead of just printing warning messages, if the orphan list is
>    corrupted, declare the file system is corrupted.  If there are any
>    reserved inodes in the orphaned inode list, declare the file system
>    corrupted and stop right away to avoid doing more potential damage to
>    the file system.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 06c6dcb86328d114709b2f464ce9c6f015acad70
>Author: Theodore Ts'o <tytso@mit.edu>
>Date:   Sat Apr 30 00:48:54 2016 -0400
>
>    ext4: fix hang when processing corrupted orphaned inode list
>    
>    [ Upstream commit c9eb13a9105e2e418f72e46a2b6da3f49e696902 ]
>    
>    If the orphaned inode list contains inode #5, ext4_iget() returns a
>    bad inode (since the bootloader inode should never be referenced
>    directly).  Because of the bad inode, we end up processing the inode
>    repeatedly and this hangs the machine.
>    
>    This can be reproduced via:
>    
>       mke2fs -t ext4 /tmp/foo.img 100
>       debugfs -w -R "ssv last_orphan 5" /tmp/foo.img
>       mount -o loop /tmp/foo.img /mnt
>    
>    (But don't do this if you are using an unpatched kernel if you care
>    about the system staying functional.  :-)
>    
>    This bug was found by the port of American Fuzzy Lop into the kernel
>    to find file system problems[1].  (Since it *only* happens if inode #5
>    shows up on the orphan list --- 3, 7, 8, etc. won't do it, it's not
>    surprising that AFL needed two hours before it found it.)
>    
>    [1] http://events.linuxfoundation.org/sites/events/files/slides/AFL%20filesystem%20fuzzing%2C%20Vault%202016_0.pdf
>    
>    Cc: stable@vger.kernel.org
>    Reported by: Vegard Nossum <vegard.nossum@oracle.com>
>    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit bb3412ec3763dd295615e164c1ae898df670bf99
>Author: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com>
>Date:   Mon Apr 25 23:32:37 2016 -0700
>
>    aacraid: Fix for KDUMP driver hang
>    
>    [ Upstream commit 78cbccd3bd683c295a44af8050797dc4a41376ff ]
>    
>    When KDUMP is triggered the driver first talks to the firmware in INTX
>    mode, but the adapter firmware is still in MSIX mode. Therefore the first
>    driver command hangs since the driver is waiting for an INTX response and
>    firmware gives a MSIX response. If when the OS is installed on a RAID
>    drive created by the adapter KDUMP will hang since the driver does not
>    receive a response in sync mode.
>    
>    Fixed by: Change the firmware to INTX mode if it is in MSIX mode before
>    sending the first sync command.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com>
>    Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
>    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ca7bb254849946e13eaf3adf23e1220cb863bca9
>Author: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com>
>Date:   Mon Apr 25 23:31:57 2016 -0700
>
>    aacraid: Fix for aac_command_thread hang
>    
>    [ Upstream commit fc4bf75ea300a5e62a2419f89dd0e22189dd7ab7 ]
>    
>    Typically under error conditions, it is possible for aac_command_thread()
>    to miss the wakeup from kthread_stop() and go back to sleep, causing it
>    to hang aac_shutdown.
>    
>    In the observed scenario, the adapter is not functioning correctly and so
>    aac_fib_send() never completes (or time-outs depending on how it was
>    called). Shortly after aac_command_thread() starts it performs
>    aac_fib_send(SendHostTime) which hangs. When aac_probe_one
>    /aac_get_adapter_info send time outs, kthread_stop is called which breaks
>    the command thread out of it's hang.
>    
>    The code will still go back to sleep in schedule_timeout() without
>    checking kthread_should_stop() so it causes aac_probe_one to hang until
>    the schedule_timeout() which is 30 minutes.
>    
>    Fixed by: Adding another kthread_should_stop() before schedule_timeout()
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com>
>    Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
>    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e452f7382f5715d7d8b1d5f1129ded8870eaed5e
>Author: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com>
>Date:   Mon Apr 25 23:31:26 2016 -0700
>
>    aacraid: Relinquish CPU during timeout wait
>    
>    [ Upstream commit 07beca2be24cc710461c0b131832524c9ee08910 ]
>    
>    aac_fib_send has a special function case for initial commands during
>    driver initialization using wait < 0(pseudo sync mode). In this case,
>    the command does not sleep but rather spins checking for timeout.This
>    loop is calls cpu_relax() in an attempt to allow other processes/threads
>    to use the CPU, but this function does not relinquish the CPU and so the
>    command will hog the processor. This was observed in a KDUMP
>    "crashkernel" and that prevented the "command thread" (which is
>    responsible for completing the command from being timed out) from
>    starting because it could not get the CPU.
>    
>    Fixed by replacing "cpu_relax()" call with "schedule()"
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com>
>    Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
>    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 660cd2235c5ac7a4d3aa5c3370b63124fb50cf81
>Author: Marc Zyngier <marc.zyngier@arm.com>
>Date:   Thu Apr 28 16:16:31 2016 +0100
>
>    arm/arm64: KVM: Enforce Break-Before-Make on Stage-2 page tables
>    
>    [ Upstream commit d4b9e0790aa764c0b01e18d4e8d33e93ba36d51f ]
>    
>    The ARM architecture mandates that when changing a page table entry
>    from a valid entry to another valid entry, an invalid entry is first
>    written, TLB invalidated, and only then the new entry being written.
>    
>    The current code doesn't respect this, directly writing the new
>    entry and only then invalidating TLBs. Let's fix it up.
>    
>    Cc: <stable@vger.kernel.org>
>    Reported-by: Christoffer Dall <christoffer.dall@linaro.org>
>    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>    Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 788da6ee7dc349b45047212f7dbce31e3fdc82b0
>Author: H Hartley Sweeten <hsweeten@visionengravers.com>
>Date:   Fri Apr 8 10:14:58 2016 -0700
>
>    staging: comedi: das1800: fix possible NULL dereference
>    
>    [ Upstream commit d375278d666760e195693b57415ba0a125cadd55 ]
>    
>    DMA is optional with this driver. If it was not enabled the devpriv->dma
>    pointer will be NULL.
>    
>    Fix the possible NULL pointer dereference when trying to disable the DMA
>    channels in das1800_ai_cancel() and tidy up the comments to fix the
>    checkpatch.pl issues:
>    WARNING: line over 80 characters
>    
>    It's probably harmless in das1800_ai_setup_dma() because the 'desc' pointer
>    will not be used if DMA is disabled but fix it there also.
>    
>    Fixes: 99dfc3357e98 ("staging: comedi: das1800: remove depends on ISA_DMA_API limitation")
>    Cc: <stable@vger.kernel.org> # 4.0+
>    Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
>    Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 14023eff33a9a587f6d5ca65d8298802ffeae811
>Author: Jiri Slaby <jslaby@suse.cz>
>Date:   Tue Mar 22 18:09:51 2016 +0100
>
>    TTY: n_gsm, fix false positive WARN_ON
>    
>    [ Upstream commit d175feca89a1c162f60f4e3560ca7bc9437c65eb ]
>    
>    Dmitry reported, that the current cleanup code in n_gsm can trigger a
>    warning:
>    WARNING: CPU: 2 PID: 24238 at drivers/tty/n_gsm.c:2048 gsm_cleanup_mux+0x166/0x6b0()
>    ...
>    Call Trace:
>    ...
>     [<ffffffff81247ab9>] warn_slowpath_null+0x29/0x30 kernel/panic.c:490
>     [<ffffffff828d0456>] gsm_cleanup_mux+0x166/0x6b0 drivers/tty/n_gsm.c:2048
>     [<ffffffff828d4d87>] gsmld_open+0x5b7/0x7a0 drivers/tty/n_gsm.c:2386
>     [<ffffffff828b9078>] tty_ldisc_open.isra.2+0x78/0xd0 drivers/tty/tty_ldisc.c:447
>     [<ffffffff828b973a>] tty_set_ldisc+0x1ca/0xa70 drivers/tty/tty_ldisc.c:567
>     [<     inline     >] tiocsetd drivers/tty/tty_io.c:2650
>     [<ffffffff828a14ea>] tty_ioctl+0xb2a/0x2140 drivers/tty/tty_io.c:2883
>    ...
>    
>    But this is a legal path when open fails to find a space in the
>    gsm_mux array and tries to clean up. So make it a standard test
>    instead of a warning.
>    
>    Reported-by: "Dmitry Vyukov" <dvyukov@google.com>
>    Cc: Alan Cox <alan@linux.intel.com>
>    Link: http://lkml.kernel.org/r/CACT4Y+bHQbAB68VFi7Romcs-Z9ZW3kQRvcq+BvHH1oa5NcAdLA@mail.gmail.com
>    Fixes: 5a640967 ("tty/n_gsm.c: fix a memory leak in gsmld_open()")
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c91d8c2d38843168a5b58bdc6b809495f5f31863
>Author: David MÃ¼ller <d.mueller@elsoft.ch>
>Date:   Wed Apr 27 11:58:32 2016 +0200
>
>    serial: 8250_pci: fix divide error bug if baud rate is 0
>    
>    [ Upstream commit 6f210c18c1c0f016772c8cd51ae12a02bfb9e7ef ]
>    
>    Since commit 21947ba654a6 ("serial: 8250_pci: replace switch-case by
>    formula"), the 8250 driver crashes in the byt_set_termios() function
>    with a divide error. This is caused by the fact that a baud rate of 0 (B0)
>    is not handled properly. Fix it by falling back to B9600 in this case.
>    
>    Signed-off-by: David MÃ¼ller <d.mueller@elsoft.ch>
>    Fixes: 21947ba654a6 ("serial: 8250_pci: replace switch-case by formula")
>    Cc: stable@vger.kernel.org
>    Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3afbd3e3a9a95054c0a2a4bb14cf07aaf0c8cde7
>Author: Chris Bainbridge <chris.bainbridge@gmail.com>
>Date:   Mon Apr 25 13:48:38 2016 +0100
>
>    usb: core: hub: hub_port_init lock controller instead of bus
>    
>    [ Upstream commit feb26ac31a2a5cb88d86680d9a94916a6343e9e6 ]
>    
>    The XHCI controller presents two USB buses to the system - one for USB2
>    and one for USB3. The hub init code (hub_port_init) is reentrant but
>    only locks one bus per thread, leading to a race condition failure when
>    two threads attempt to simultaneously initialise a USB2 and USB3 device:
>    
>    [    8.034843] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
>    [   13.183701] usb 3-3: device descriptor read/all, error -110
>    
>    On a test system this failure occurred on 6% of all boots.
>    
>    The call traces at the point of failure are:
>    
>    Call Trace:
>     [<ffffffff81b9bab7>] schedule+0x37/0x90
>     [<ffffffff817da7cd>] usb_kill_urb+0x8d/0xd0
>     [<ffffffff8111e5e0>] ? wake_up_atomic_t+0x30/0x30
>     [<ffffffff817dafbe>] usb_start_wait_urb+0xbe/0x150
>     [<ffffffff817db10c>] usb_control_msg+0xbc/0xf0
>     [<ffffffff817d07de>] hub_port_init+0x51e/0xb70
>     [<ffffffff817d4697>] hub_event+0x817/0x1570
>     [<ffffffff810f3e6f>] process_one_work+0x1ff/0x620
>     [<ffffffff810f3dcf>] ? process_one_work+0x15f/0x620
>     [<ffffffff810f4684>] worker_thread+0x64/0x4b0
>     [<ffffffff810f4620>] ? rescuer_thread+0x390/0x390
>     [<ffffffff810fa7f5>] kthread+0x105/0x120
>     [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
>     [<ffffffff81ba183f>] ret_from_fork+0x3f/0x70
>     [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
>    
>    Call Trace:
>     [<ffffffff817fd36d>] xhci_setup_device+0x53d/0xa40
>     [<ffffffff817fd87e>] xhci_address_device+0xe/0x10
>     [<ffffffff817d047f>] hub_port_init+0x1bf/0xb70
>     [<ffffffff811247ed>] ? trace_hardirqs_on+0xd/0x10
>     [<ffffffff817d4697>] hub_event+0x817/0x1570
>     [<ffffffff810f3e6f>] process_one_work+0x1ff/0x620
>     [<ffffffff810f3dcf>] ? process_one_work+0x15f/0x620
>     [<ffffffff810f4684>] worker_thread+0x64/0x4b0
>     [<ffffffff810f4620>] ? rescuer_thread+0x390/0x390
>     [<ffffffff810fa7f5>] kthread+0x105/0x120
>     [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
>     [<ffffffff81ba183f>] ret_from_fork+0x3f/0x70
>     [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
>    
>    Which results from the two call chains:
>    
>    hub_port_init
>     usb_get_device_descriptor
>      usb_get_descriptor
>       usb_control_msg
>        usb_internal_control_msg
>         usb_start_wait_urb
>          usb_submit_urb / wait_for_completion_timeout / usb_kill_urb
>    
>    hub_port_init
>     hub_set_address
>      xhci_address_device
>       xhci_setup_device
>    
>    Mathias Nyman explains the current behaviour violates the XHCI spec:
>    
>     hub_port_reset() will end up moving the corresponding xhci device slot
>     to default state.
>    
>     As hub_port_reset() is called several times in hub_port_init() it
>     sounds reasonable that we could end up with two threads having their
>     xhci device slots in default state at the same time, which according to
>     xhci 4.5.3 specs still is a big no no:
>    
>     "Note: Software shall not transition more than one Device Slot to the
>      Default State at a time"
>    
>     So both threads fail at their next task after this.
>     One fails to read the descriptor, and the other fails addressing the
>     device.
>    
>    Fix this in hub_port_init by locking the USB controller (instead of an
>    individual bus) to prevent simultaneous initialisation of both buses.
>    
>    Fixes: 638139eb95d2 ("usb: hub: allow to process more usb hub events in parallel")
>    Link: https://lkml.org/lkml/2016/2/8/312
>    Link: https://lkml.org/lkml/2016/2/4/748
>    Signed-off-by: Chris Bainbridge <chris.bainbridge@gmail.com>
>    Cc: stable <stable@vger.kernel.org>
>    Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7ac47d24c2c58732650b40e87c616b2778c985a3
>Author: Luke Dashjr <luke@dashjr.org>
>Date:   Thu Oct 29 08:22:21 2015 +0000
>
>    btrfs: bugfix: handle FS_IOC32_{GETFLAGS,SETFLAGS,GETVERSION} in btrfs_ioctl
>    
>    [ Upstream commit 4c63c2454eff996c5e27991221106eb511f7db38 ]
>    
>    32-bit ioctl uses these rather than the regular FS_IOC_* versions. They can
>    be handled in btrfs using the same code. Without this, 32-bit {ch,ls}attr
>    fail.
>    
>    Signed-off-by: Luke Dashjr <luke-jr+git@utopios.org>
>    Cc: stable@vger.kernel.org
>    Reviewed-by: Josef Bacik <jbacik@fb.com>
>    Reviewed-by: David Sterba <dsterba@suse.com>
>    Signed-off-by: David Sterba <dsterba@suse.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 93ddb49f922bc625f6abe56169bca3d642befc16
>Author: Andrew Jeffery <andrew@aj.id.au>
>Date:   Wed Apr 20 11:24:17 2016 +0930
>
>    pinctrl: exynos5440: Use off-stack memory for pinctrl_gpio_range
>    
>    [ Upstream commit 71324fdc72ef0163e57631aa814a9a81e9e4770b ]
>    
>    The range is registered into a linked list which can be referenced
>    throughout the lifetime of the driver. Ensure the range's memory is useful
>    for the same lifetime by adding it to the driver's private data structure.
>    
>    The bug was introduced in the driver's initial commit, which was present in
>    v3.10.
>    
>    Fixes: f0b9a7e521fa ("pinctrl: exynos5440: add pinctrl driver for Samsung EXYNOS5440 SoC")
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
>    Acked-by: Tomasz Figa <tomasz.figa@gmail.com>
>    Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a774710f2d27a61ad7cfd0b449e6708e03d70c7d
>Author: Vittorio Gambaletta (VittGam) <linux-wireless@vittgam.net>
>Date:   Mon Apr 11 04:48:55 2016 +0200
>
>    ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards.
>    
>    [ Upstream commit 0f9edcdd88a993914fa1d1dc369b35dc503979db ]
>    
>    The Wistron DNMA-92 and Compex WLM200NX have inverted LED polarity
>    (active high instead of active low).
>    
>    The same PCI Subsystem ID is used by both cards, which are based on
>    the same Atheros MB92 design.
>    
>    Cc: <linux-wireless@vger.kernel.org>
>    Cc: <ath9k-devel@qca.qualcomm.com>
>    Cc: <ath9k-devel@lists.ath9k.org>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
>    Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d24f503d5c01eb3f33a2dde74b6893c7ec2816ad
>Author: Vittorio Gambaletta (VittGam) <linux-wireless@vittgam.net>
>Date:   Mon Apr 11 04:48:54 2016 +0200
>
>    ath9k: Add a module parameter to invert LED polarity.
>    
>    [ Upstream commit cd84042ce9040ad038e958bc67a46fcfc015c736 ]
>    
>    The LED can be active high instead of active low on some hardware.
>    
>    Add the led_active_high module parameter. It defaults to -1 to obey
>    platform data as before.
>    
>    Setting the parameter to 1 or 0 will force the LED respectively
>    active high or active low.
>    
>    Cc: <linux-wireless@vger.kernel.org>
>    Cc: <ath9k-devel@qca.qualcomm.com>
>    Cc: <ath9k-devel@lists.ath9k.org>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
>    Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6be9e6ec17c65c289f5bb0afabe977d2d748b4c2
>Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>Date:   Fri Apr 22 14:15:23 2016 +0200
>
>    crypto: s5p-sss - Fix missed interrupts when working with 8 kB blocks
>    
>    [ Upstream commit 79152e8d085fd64484afd473ef6830b45518acba ]
>    
>    The tcrypt testing module on Exynos5422-based Odroid XU3/4 board failed on
>    testing 8 kB size blocks:
>    
>    	$ sudo modprobe tcrypt sec=1 mode=500
>    	testing speed of async ecb(aes) (ecb-aes-s5p) encryption
>    	test 0 (128 bit key, 16 byte blocks): 21971 operations in 1 seconds (351536 bytes)
>    	test 1 (128 bit key, 64 byte blocks): 21731 operations in 1 seconds (1390784 bytes)
>    	test 2 (128 bit key, 256 byte blocks): 21932 operations in 1 seconds (5614592 bytes)
>    	test 3 (128 bit key, 1024 byte blocks): 21685 operations in 1 seconds (22205440 bytes)
>    	test 4 (128 bit key, 8192 byte blocks):
>    
>    This was caused by a race issue of missed BRDMA_DONE ("Block cipher
>    Receiving DMA") interrupt. Device starts processing the data in DMA mode
>    immediately after setting length of DMA block: receiving (FCBRDMAL) or
>    transmitting (FCBTDMAL). The driver sets these lengths from interrupt
>    handler through s5p_set_dma_indata() function (or xxx_setdata()).
>    
>    However the interrupt handler was first dealing with receive buffer
>    (dma-unmap old, dma-map new, set receive block length which starts the
>    operation), then with transmit buffer and finally was clearing pending
>    interrupts (FCINTPEND). Because of the time window between setting
>    receive buffer length and clearing pending interrupts, the operation on
>    receive buffer could end already and driver would miss new interrupt.
>    
>    User manual for Exynos5422 confirms in example code that setting DMA
>    block lengths should be the last operation.
>    
>    The tcrypt hang could be also observed in following blocked-task dmesg:
>    
>    INFO: task modprobe:258 blocked for more than 120 seconds.
>          Not tainted 4.6.0-rc4-next-20160419-00005-g9eac8b7b7753-dirty #42
>    "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>    modprobe        D c06b09d8     0   258    256 0x00000000
>    [<c06b09d8>] (__schedule) from [<c06b0f24>] (schedule+0x40/0xac)
>    [<c06b0f24>] (schedule) from [<c06b49f8>] (schedule_timeout+0x124/0x178)
>    [<c06b49f8>] (schedule_timeout) from [<c06b17fc>] (wait_for_common+0xb8/0x144)
>    [<c06b17fc>] (wait_for_common) from [<bf0013b8>] (test_acipher_speed+0x49c/0x740 [tcrypt])
>    [<bf0013b8>] (test_acipher_speed [tcrypt]) from [<bf003e8c>] (do_test+0x2240/0x30ec [tcrypt])
>    [<bf003e8c>] (do_test [tcrypt]) from [<bf008048>] (tcrypt_mod_init+0x48/0xa4 [tcrypt])
>    [<bf008048>] (tcrypt_mod_init [tcrypt]) from [<c010177c>] (do_one_initcall+0x3c/0x16c)
>    [<c010177c>] (do_one_initcall) from [<c0191ff0>] (do_init_module+0x5c/0x1ac)
>    [<c0191ff0>] (do_init_module) from [<c0185610>] (load_module+0x1a30/0x1d08)
>    [<c0185610>] (load_module) from [<c0185ab0>] (SyS_finit_module+0x8c/0x98)
>    [<c0185ab0>] (SyS_finit_module) from [<c01078c0>] (ret_fast_syscall+0x0/0x3c)
>    
>    Fixes: a49e490c7a8a ("crypto: s5p-sss - add S5PV210 advanced crypto engine support")
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>    Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit cc706ae1a874eab7f5bc6a09286c95a5ca75b59c
>Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>Date:   Tue Apr 19 15:44:12 2016 +0200
>
>    crypto: s5p-sss - Remove useless hash interrupt handler
>    
>    [ Upstream commit 5512442553bbe8d4fcdba3e17b30f187706384a7 ]
>    
>    Beside regular feed control interrupt, the driver requires also hash
>    interrupt for older SoCs (samsung,s5pv210-secss). However after
>    requesting it, the interrupt handler isn't doing anything with it, not
>    even clearing the hash interrupt bit.
>    
>    Driver does not provide hash functions so it is safe to remove the hash
>    interrupt related code and to not require the interrupt in Device Tree.
>    
>    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit dae205d180835de781ef49edd47c46e31b43e1e4
>Author: Ulf Hansson <ulf.hansson@linaro.org>
>Date:   Fri Apr 8 13:10:23 2016 +0200
>
>    PM / Runtime: Fix error path in pm_runtime_force_resume()
>    
>    [ Upstream commit 0ae3aeefabbeef26294e7a349b51f1c761d46c9f ]
>    
>    As pm_runtime_set_active() may fail because the device's parent isn't
>    active, we can end up executing the ->runtime_resume() callback for the
>    device when it isn't allowed.
>    
>    Fix this by invoking pm_runtime_set_active() before running the callback
>    and let's also deal with the error code.
>    
>    Fixes: 37f204164dfb (PM: Add pm_runtime_suspend|resume_force functions)
>    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>    Cc: 3.15+ <stable@vger.kernel.org> # 3.15+
>    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b9a5eef06ce1e717f119ed5312216b6dfd80c935
>Author: Hari Bathini <hbathini@linux.vnet.ibm.com>
>Date:   Fri Apr 15 22:48:02 2016 +1000
>
>    powerpc/book3s64: Fix branching to OOL handlers in relocatable kernel
>    
>    [ Upstream commit 8ed8ab40047a570fdd8043a40c104a57248dd3fd ]
>    
>    Some of the interrupt vectors on 64-bit POWER server processors are only
>    32 bytes long (8 instructions), which is not enough for the full
>    first-level interrupt handler. For these we need to branch to an
>    out-of-line (OOL) handler. But when we are running a relocatable kernel,
>    interrupt vectors till __end_interrupts marker are copied down to real
>    address 0x100. So, branching to labels (ie. OOL handlers) outside this
>    section must be handled differently (see LOAD_HANDLER()), considering
>    relocatable kernel, which would need at least 4 instructions.
>    
>    However, branching from interrupt vector means that we corrupt the
>    CFAR (come-from address register) on POWER7 and later processors as
>    mentioned in commit 1707dd16. So, EXCEPTION_PROLOG_0 (6 instructions)
>    that contains the part up to the point where the CFAR is saved in the
>    PACA should be part of the short interrupt vectors before we branch out
>    to OOL handlers.
>    
>    But as mentioned already, there are interrupt vectors on 64-bit POWER
>    server processors that are only 32 bytes long (like vectors 0x4f00,
>    0x4f20, etc.), which cannot accomodate the above two cases at the same
>    time owing to space constraint. Currently, in these interrupt vectors,
>    we simply branch out to OOL handlers, without using LOAD_HANDLER(),
>    which leaves us vulnerable when running a relocatable kernel (eg. kdump
>    case). While this has been the case for sometime now and kdump is used
>    widely, we were fortunate not to see any problems so far, for three
>    reasons:
>    
>      1. In almost all cases, production kernel (relocatable) is used for
>         kdump as well, which would mean that crashed kernel's OOL handler
>         would be at the same place where we end up branching to, from short
>         interrupt vector of kdump kernel.
>      2. Also, OOL handler was unlikely the reason for crash in almost all
>         the kdump scenarios, which meant we had a sane OOL handler from
>         crashed kernel that we branched to.
>      3. On most 64-bit POWER server processors, page size is large enough
>         that marking interrupt vector code as executable (see commit
>         429d2e83) leads to marking OOL handler code from crashed kernel,
>         that sits right below interrupt vector code from kdump kernel, as
>         executable as well.
>    
>    Let us fix this by moving the __end_interrupts marker down past OOL
>    handlers to make sure that we also copy OOL handlers to real address
>    0x100 when running a relocatable kernel.
>    
>    This fix has been tested successfully in kdump scenario, on an LPAR with
>    4K page size by using different default/production kernel and kdump
>    kernel.
>    
>    Also tested by manually corrupting the OOL handlers in the first kernel
>    and then kdump'ing, and then causing the OOL handlers to fire - mpe.
>    
>    Fixes: c1fb6816fb1b ("powerpc: Add relocation on exception vector handlers")
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
>    Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 599a6fc37a01f5b77f9ebf6e03f70375e4d236b4
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Thu Apr 14 17:32:19 2016 +0200
>
>    Bluetooth: vhci: Fix race at creating hci device
>    
>    [ Upstream commit c7c999cb18da88a881e10e07f0724ad0bfaff770 ]
>    
>    hci_vhci driver creates a hci device object dynamically upon each
>    HCI_VENDOR_PKT write.  Although it checks the already created object
>    and returns an error, it's still racy and may build multiple hci_dev
>    objects concurrently when parallel writes are performed, as the device
>    tracks only a single hci_dev object.
>    
>    This patch introduces a mutex to protect against the concurrent device
>    creations.
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ef83ef608320a02f1fa84e5e77743038ee134e54
>Author: Akshay Bhat <akshay.bhat@timesys.com>
>Date:   Mon Apr 18 15:47:53 2016 -0400
>
>    hwmon: (ads7828) Enable internal reference
>    
>    [ Upstream commit 7a18afe8097731b8ffb6cb5b2b3b418ded77c105 ]
>    
>    On ads7828 the internal reference defaults to off upon power up. When
>    using internal reference, it needs to be turned on and the voltage needs
>    to settle before normal conversion cycle can be started. Hence perform a
>    dummy read in the probe to enable the internal reference allowing the
>    voltage to settle before performing a normal read.
>    
>    Without this fix, the first read from the ADC when using internal
>    reference always returns incorrect data.
>    
>    Signed-off-by: Akshay Bhat <akshay.bhat@timesys.com>
>    Cc: stable@vger.kernel.org # v4.1+
>    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f5a300ce8c288f470af4cfdcc16294515cb61753
>Author: Michal Nazarewicz <mina86@mina86.com>
>Date:   Fri Apr 8 10:24:11 2016 +0200
>
>    usb: f_mass_storage: test whether thread is running before starting another
>    
>    [ Upstream commit f78bbcae86e676fad9e6c6bb6cd9d9868ba23696 ]
>    
>    When binding the function to usb_configuration, check whether the thread
>    is running before starting another one.  Without that, when function
>    instance is added to multiple configurations, fsg_bing starts multiple
>    threads with all but the latest one being forgotten by the driver.  This
>    leads to obvious thread leaks, possible lockups when trying to halt the
>    machine and possible more issues.
>    
>    This fixes issues with legacy/multiÂ¹ gadget as well as configfs gadgets
>    when mass_storage function is added to multiple configurations.
>    
>    This change also simplifies API since the legacy gadgets no longer need
>    to worry about starting the thread by themselves (which was where bug
>    in legacy/multi was in the first place).
>    
>    N.B., this patch doesnât address adding single mass_storage function
>    instance to a single configuration twice.  Thankfully, thereâs no
>    legitimate reason for such setup plus, if Iâm not mistaken, configfs
>    gadget doesnât even allow it to be expressed.
>    
>    Â¹ I have no example failure though.  Conclusion that legacy/multi has
>      a bug is based purely on me reading the code.
>    
>    Acked-by: Alan Stern <stern@rowland.harvard.edu>
>    Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
>    Tested-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
>    Cc: Alan Stern <stern@rowland.harvard.edu>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 799f55d219e12c930eb248dbb5403adf4dc78edc
>Author: Krzysztof Opasiak <k.opasiak@samsung.com>
>Date:   Fri Jul 31 13:46:07 2015 +0200
>
>    usb: gadget: mass_storage: Use static array for luns
>    
>    [ Upstream commit dd02ea5a33059e4a753ae8bb877b698c54ee2907 ]
>    
>    This patch replace dynamicly allocated luns array with static one.
>    This simplifies the code of mass storage function and modules.
>    
>    Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
>    Acked-by: Michal Nazarewicz <mina86@mina86.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a27b3984f7fdea785e67195f6de3d06c4835e325
>Author: Krzysztof Opasiak <k.opasiak@samsung.com>
>Date:   Fri Jul 31 13:37:45 2015 +0200
>
>    usb: gadget: mass_storage: Fix freeing luns sysfs implementation
>    
>    [ Upstream commit 5542f58c95aef67bc9016855f7c0bd6117b43100 ]
>    
>    Use device_is_registered() instad of sysfs flag to determine if
>    we should free sysfs representation of particular LUN.
>    
>    sysfs flag in fsg common determines if luns attributes should be
>    exposed using sysfs. This flag is used when creating and freeing
>    luns. Unfortunately there is no guarantee that this flag will not
>    be changed between creation and removal of particular LUN. Especially
>    because of lun.0 which is created during allocating instance of
>    function. This may lead to resource leak or NULL pointer dereference:
>    
>    [   62.539925] Unable to handle kernel NULL pointer dereference at virtual address 00000044
>    [   62.548014] pgd = ec994000
>    [   62.550679] [00000044] *pgd=6d7be831, *pte=00000000, *ppte=00000000
>    [   62.556933] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
>    [   62.562310] Modules linked in: g_mass_storage(+)
>    [   62.566916] CPU: 2 PID: 613 Comm: insmod Not tainted 4.2.0-rc4-00077-ge29ee91-dirty #125
>    [   62.574984] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>    [   62.581061] task: eca56e80 ti: eca76000 task.ti: eca76000
>    [   62.586450] PC is at kernfs_find_ns+0x8/0xe8
>    [   62.590698] LR is at kernfs_find_and_get_ns+0x30/0x48
>    [   62.595732] pc : [<c01277c0>]    lr : [<c0127b88>]    psr: 40010053
>    [   62.595732] sp : eca77c40  ip : eca77c38  fp : 000008c1
>    [   62.607187] r10: 00000001  r9 : c0082f38  r8 : ed41ce40
>    [   62.612395] r7 : c05c1484  r6 : 00000000  r5 : 00000000  r4 : c0814488
>    [   62.618904] r3 : 00000000  r2 : 00000000  r1 : c05c1484  r0 : 00000000
>    [   62.625417] Flags: nZcv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment user
>    [   62.632620] Control: 10c5387d  Table: 6c99404a  DAC: 00000015
>    [   62.638348] Process insmod (pid: 613, stack limit = 0xeca76210)
>    [   62.644251] Stack: (0xeca77c40 to 0xeca78000)
>    [   62.648594] 7c40: c0814488 00000000 00000000 c05c1484 ed41ce40 c0127b88 00000000 c0824888
>    [   62.656753] 7c60: ed41d038 ed41d030 ed41d000 c012af4c 00000000 c0824858 ed41d038 c02e3314
>    [   62.664912] 7c80: ed41d030 00000000 ed41ce04 c02d9e8c c070eda8 eca77cb4 000008c1 c058317c
>    [   62.673071] 7ca0: 000008c1 ed41d030 ed41ce00 ed41ce04 ed41d000 c02da044 ed41cf48 c0375870
>    [   62.681230] 7cc0: ed9d3c04 ed9d3c00 ed52df80 bf000940 fffffff0 c03758f4 c03758c0 00000000
>    [   62.689389] 7ce0: bf000564 c03614e0 ed9d3c04 bf000194 c0082f38 00000001 00000000 c0000100
>    [   62.697548] 7d00: c0814488 c0814488 c086b1dc c05893a8 00000000 ed7e8320 00000000 c0128b88
>    [   62.705707] 7d20: ed8a6b40 00000000 00000000 ed410500 ed8a6b40 c0594818 ed7e8320 00000000
>    [   62.713867] 7d40: 00000000 c0129f20 00000000 c082c444 ed8a6b40 c012a684 00001000 00000000
>    [   62.722026] 7d60: c0594818 c082c444 00000000 00000000 ed52df80 ed52df80 00000000 00000000
>    [   62.730185] 7d80: 00000000 00000000 00000001 00000002 ed8e9b70 ed52df80 bf0006d0 00000000
>    [   62.738345] 7da0: ed8e9b70 ed410500 ed618340 c036129c ed8c1c00 bf0006d0 c080b158 ed8c1c00
>    [   62.746504] 7dc0: bf0006d0 c080b158 ed8c1c08 ed410500 c0082f38 ed618340 000008c1 c03640ac
>    [   62.754663] 7de0: 00000000 bf0006d0 c082c8dc c080b158 c080b158 c03642d4 00000000 bf003000
>    [   62.762822] 7e00: 00000000 c0009784 00000000 00000001 00000000 c05849b0 00000002 ee7ab780
>    [   62.770981] 7e20: 00000002 ed4105c0 0000c53e 000000d0 c0808600 eca77e5c 00000004 00000000
>    [   62.779140] 7e40: bf000000 c0095680 c08075a0 ee001f00 ed4105c0 c00cadc0 ed52df80 bf000780
>    [   62.787300] 7e60: ed4105c0 bf000780 00000001 bf0007c8 c0082f38 ed618340 000008c1 c0083e24
>    [   62.795459] 7e80: 00000001 bf000780 00000001 eca77f58 00000001 bf000780 00000001 c00857f4
>    [   62.803618] 7ea0: bf00078c 00007fff 00000000 c00835b4 eca77f58 00000000 c0082fac eca77f58
>    [   62.811777] 7ec0: f05038c0 0003b008 bf000904 00000000 00000000 bf00078c 6e72656b 00006c65
>    [   62.819936] 7ee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>    [   62.828095] 7f00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>    [   62.836255] 7f20: 00000000 00000000 00000000 00000000 00000000 00000000 00000003 0003b008
>    [   62.844414] 7f40: 0000017b c000f5c8 eca76000 00000000 0003b008 c0085df8 f04ef000 0001b8a9
>    [   62.852573] 7f60: f0503258 f05030c2 f0509fe8 00000968 00000dc8 00000000 00000000 00000000
>    [   62.860732] 7f80: 00000029 0000002a 00000011 00000000 0000000a 00000000 33f6eb00 0003b008
>    [   62.868892] 7fa0: bef01cac c000f400 33f6eb00 0003b008 00000003 0003b008 00000000 00000003
>    [   62.877051] 7fc0: 33f6eb00 0003b008 bef01cac 0000017b 00000000 0003b008 0000000b 0003b008
>    [   62.885210] 7fe0: bef01ae0 bef01ad0 0001dc23 b6e8c162 800b0070 00000003 c0c0c0c0 c0c0c0c0
>    [   62.893380] [<c01277c0>] (kernfs_find_ns) from [<c0824888>] (pm_qos_latency_tolerance_attr_group+0x0/0x10)
>    [   62.903005] Code: e28dd00c e8bd80f0 e92d41f0 e2923000 (e1d0e4b4)
>    [   62.909115] ---[ end trace 02fb4373ef095c7b ]---
>    
>    Acked-by: Michal Nazarewicz <mina86@mina86.com>
>    Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
>    Signed-off-by: Felipe Balbi <balbi@ti.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c387f28f6f54fc8bd5d9c05d9c4b35cc0910d207
>Author: Krzysztof Opasiak <k.opasiak@samsung.com>
>Date:   Mon Jul 20 20:15:17 2015 +0200
>
>    usb: gadget: mass_storage: Free buffers if create lun fails
>    
>    [ Upstream commit 903588a99c26ed6f103eaa0cfa4ccbe9cd779398 ]
>    
>    Creation of LUN 0 may fail (for example due to ENOMEM).
>    As fsg_common_set_num_buffers() does some memory allocation
>    we should free it before it becomes unavailable.
>    
>    Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
>    Acked-by: Michal Nazarewicz <mina86@mina86.com>
>    Signed-off-by: Felipe Balbi <balbi@ti.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5b1e48946e2d73a1b332ca84c2d7aba2136911e2
>Author: Tiffany Lin <tiffany.lin@mediatek.com>
>Date:   Mon Mar 14 08:16:14 2016 -0300
>
>    [media] media: v4l2-compat-ioctl32: fix missing reserved field copy in put_v4l2_create32
>    
>    [ Upstream commit baf43c6eace43868e490f18560287fa3481b2159 ]
>    
>    In v4l2-compliance utility, test VIDIOC_CREATE_BUFS will check whether reserved
>    filed of v4l2_create_buffers filled with zero
>    Reserved field is filled with zero in v4l_create_bufs.
>    This patch copy reserved field of v4l2_create_buffer from kernel space to user
>    space
>    
>    Signed-off-by: Tiffany Lin <tiffany.lin@mediatek.com>
>    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
>    Cc: <stable@vger.kernel.org>      # for v3.19 and up
>    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 633b243bb2fcc9546f87123598130831c406e629
>Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>Date:   Fri Oct 23 12:16:42 2015 +0300
>
>    mfd: intel_quark_i2c_gpio: load gpio driver first
>    
>    [ Upstream commit c39dc960e9c5196022cbc46507d4782b6fc314f6 ]
>    
>    On Intel Galileo boards the GPIO expander is connected to i2c bus. Moreover it
>    is able to generate interrupt, but interrupt line is connected to GPIO. That's
>    why we have to have GPIO driver in place when we will probe i2c host with
>    device connected to it.
>    
>    Acked-by: Lee Jones <lee.jones@linaro.org>
>    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 16de798078e646c2f668c8d03be79dfdd53db3a1
>Author: Dave Gerlach <d-gerlach@ti.com>
>Date:   Tue Apr 5 14:05:38 2016 -0500
>
>    cpuidle: Indicate when a device has been unregistered
>    
>    [ Upstream commit c998c07836f985b24361629dc98506ec7893e7a0 ]
>    
>    Currently the 'registered' member of the cpuidle_device struct is set
>    to 1 during cpuidle_register_device. In this same function there are
>    checks to see if the device is already registered to prevent duplicate
>    calls to register the device, but this value is never set to 0 even on
>    unregister of the device. Because of this, any attempt to call
>    cpuidle_register_device after a call to cpuidle_unregister_device will
>    fail which shouldn't be the case.
>    
>    To prevent this, set registered to 0 when the device is unregistered.
>    
>    Fixes: c878a52d3c7c (cpuidle: Check if device is already registered)
>    Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>    Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>    Cc: All applicable <stable@vger.kernel.org>
>    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b2df540f5e80e7d8106fe3e8113f22bc359ed15c
>Author: Jiri Slaby <jslaby@suse.cz>
>Date:   Sat Mar 19 11:49:43 2016 +0100
>
>    Bluetooth: vhci: purge unhandled skbs
>    
>    [ Upstream commit 13407376b255325fa817798800117a839f3aa055 ]
>    
>    The write handler allocates skbs and queues them into data->readq.
>    Read side should read them, if there is any. If there is none, skbs
>    should be dropped by hdev->flush. But this happens only if the device
>    is HCI_UP, i.e. hdev->power_on work was triggered already. When it was
>    not, skbs stay allocated in the queue when /dev/vhci is closed. So
>    purge the queue in ->release.
>    
>    Program to reproduce:
>    	#include <err.h>
>    	#include <fcntl.h>
>    	#include <stdio.h>
>    	#include <unistd.h>
>    
>    	#include <sys/stat.h>
>    	#include <sys/types.h>
>    	#include <sys/uio.h>
>    
>    	int main()
>    	{
>    		char buf[] = { 0xff, 0 };
>    		struct iovec iov = {
>    			.iov_base = buf,
>    			.iov_len = sizeof(buf),
>    		};
>    		int fd;
>    
>    		while (1) {
>    			fd = open("/dev/vhci", O_RDWR);
>    			if (fd < 0)
>    				err(1, "open");
>    
>    			usleep(50);
>    
>    			if (writev(fd, &iov, 1) < 0)
>    				err(1, "writev");
>    
>    			usleep(50);
>    
>    			close(fd);
>    		}
>    
>    		return 0;
>    	}
>    
>    Result:
>    kmemleak: 4609 new suspected memory leaks
>    unreferenced object 0xffff88059f4d5440 (size 232):
>      comm "vhci", pid 1084, jiffies 4294912542 (age 37569.296s)
>      hex dump (first 32 bytes):
>        20 f0 23 87 05 88 ff ff 20 f0 23 87 05 88 ff ff   .#..... .#.....
>        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>      backtrace:
>    ...
>        [<ffffffff81ece010>] __alloc_skb+0x0/0x5a0
>        [<ffffffffa021886c>] vhci_create_device+0x5c/0x580 [hci_vhci]
>        [<ffffffffa0219436>] vhci_write+0x306/0x4c8 [hci_vhci]
>    
>    Fixes: 23424c0d31 (Bluetooth: Add support creating virtual AMP controllers)
>    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
>    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
>    Cc: stable 3.13+ <stable@vger.kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 497519c4a3bf22c5d7fa2e6da6424e07e6ac543c
>Author: Jiri Slaby <jslaby@suse.cz>
>Date:   Sat Mar 19 11:05:18 2016 +0100
>
>    Bluetooth: vhci: fix open_timeout vs. hdev race
>    
>    [ Upstream commit 373a32c848ae3a1c03618517cce85f9211a6facf ]
>    
>    Both vhci_get_user and vhci_release race with open_timeout work. They
>    both contain cancel_delayed_work_sync, but do not test whether the
>    work actually created hdev or not. Since the work can be in progress
>    and _sync will wait for finishing it, we can have data->hdev allocated
>    when cancel_delayed_work_sync returns. But the call sites do 'if
>    (data->hdev)' *before* cancel_delayed_work_sync.
>    
>    As a result:
>    * vhci_get_user allocates a second hdev and puts it into
>      data->hdev. The former is leaked.
>    * vhci_release does not release data->hdev properly as it thinks there
>      is none.
>    
>    Fix both cases by moving the actual test *after* the call to
>    cancel_delayed_work_sync.
>    
>    This can be hit by this program:
>    	#include <err.h>
>    	#include <fcntl.h>
>    	#include <stdio.h>
>    	#include <stdlib.h>
>    	#include <time.h>
>    	#include <unistd.h>
>    
>    	#include <sys/stat.h>
>    	#include <sys/types.h>
>    
>    	int main(int argc, char **argv)
>    	{
>    		int fd;
>    
>    		srand(time(NULL));
>    
>    		while (1) {
>    			const int delta = (rand() % 200 - 100) * 100;
>    
>    			fd = open("/dev/vhci", O_RDWR);
>    			if (fd < 0)
>    				err(1, "open");
>    
>    			usleep(1000000 + delta);
>    
>    			close(fd);
>    		}
>    
>    		return 0;
>    	}
>    
>    And the result is:
>    BUG: KASAN: use-after-free in skb_queue_tail+0x13e/0x150 at addr ffff88006b0c1228
>    Read of size 8 by task kworker/u13:1/32068
>    =============================================================================
>    BUG kmalloc-192 (Tainted: G            E     ): kasan: bad access detected
>    -----------------------------------------------------------------------------
>    
>    Disabling lock debugging due to kernel taint
>    INFO: Allocated in vhci_open+0x50/0x330 [hci_vhci] age=260 cpu=3 pid=32040
>    ...
>    	kmem_cache_alloc_trace+0x150/0x190
>    	vhci_open+0x50/0x330 [hci_vhci]
>    	misc_open+0x35b/0x4e0
>    	chrdev_open+0x23b/0x510
>    ...
>    INFO: Freed in vhci_release+0xa4/0xd0 [hci_vhci] age=9 cpu=2 pid=32040
>    ...
>    	__slab_free+0x204/0x310
>    	vhci_release+0xa4/0xd0 [hci_vhci]
>    ...
>    INFO: Slab 0xffffea0001ac3000 objects=16 used=13 fp=0xffff88006b0c1e00 flags=0x5fffff80004080
>    INFO: Object 0xffff88006b0c1200 @offset=4608 fp=0xffff88006b0c0600
>    Bytes b4 ffff88006b0c11f0: 09 df 00 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
>    Object ffff88006b0c1200: 00 06 0c 6b 00 88 ff ff 00 00 00 00 00 00 00 00  ...k............
>    Object ffff88006b0c1210: 10 12 0c 6b 00 88 ff ff 10 12 0c 6b 00 88 ff ff  ...k.......k....
>    Object ffff88006b0c1220: c0 46 c2 6b 00 88 ff ff c0 46 c2 6b 00 88 ff ff  .F.k.....F.k....
>    Object ffff88006b0c1230: 01 00 00 00 01 00 00 00 e0 ff ff ff 0f 00 00 00  ................
>    Object ffff88006b0c1240: 40 12 0c 6b 00 88 ff ff 40 12 0c 6b 00 88 ff ff  @..k....@..k....
>    Object ffff88006b0c1250: 50 0d 6e a0 ff ff ff ff 00 02 00 00 00 00 ad de  P.n.............
>    Object ffff88006b0c1260: 00 00 00 00 00 00 00 00 ab 62 02 00 01 00 00 00  .........b......
>    Object ffff88006b0c1270: 90 b9 19 81 ff ff ff ff 38 12 0c 6b 00 88 ff ff  ........8..k....
>    Object ffff88006b0c1280: 03 00 20 00 ff ff ff ff ff ff ff ff 00 00 00 00  .. .............
>    Object ffff88006b0c1290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>    Object ffff88006b0c12a0: 00 00 00 00 00 00 00 00 00 80 cd 3d 00 88 ff ff  ...........=....
>    Object ffff88006b0c12b0: 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00  . ..............
>    Redzone ffff88006b0c12c0: bb bb bb bb bb bb bb bb                          ........
>    Padding ffff88006b0c13f8: 00 00 00 00 00 00 00 00                          ........
>    CPU: 3 PID: 32068 Comm: kworker/u13:1 Tainted: G    B       E      4.4.6-0-default #1
>    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.1-0-g4adadbd-20151112_172657-sheep25 04/01/2014
>    Workqueue: hci0 hci_cmd_work [bluetooth]
>     00000000ffffffff ffffffff81926cfa ffff88006be37c68 ffff88006bc27180
>     ffff88006b0c1200 ffff88006b0c1234 ffffffff81577993 ffffffff82489320
>     ffff88006bc24240 0000000000000046 ffff88006a100000 000000026e51eb80
>    Call Trace:
>    ...
>     [<ffffffff81ec8ebe>] ? skb_queue_tail+0x13e/0x150
>     [<ffffffffa06e027c>] ? vhci_send_frame+0xac/0x100 [hci_vhci]
>     [<ffffffffa0c61268>] ? hci_send_frame+0x188/0x320 [bluetooth]
>     [<ffffffffa0c61515>] ? hci_cmd_work+0x115/0x310 [bluetooth]
>     [<ffffffff811a1375>] ? process_one_work+0x815/0x1340
>     [<ffffffff811a1f85>] ? worker_thread+0xe5/0x11f0
>     [<ffffffff811a1ea0>] ? process_one_work+0x1340/0x1340
>     [<ffffffff811b3c68>] ? kthread+0x1c8/0x230
>    ...
>    Memory state around the buggy address:
>     ffff88006b0c1100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>     ffff88006b0c1180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>    >ffff88006b0c1200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>                                      ^
>     ffff88006b0c1280: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
>     ffff88006b0c1300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>    
>    Fixes: 23424c0d31 (Bluetooth: Add support creating virtual AMP controllers)
>    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
>    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
>    Cc: Dmitry Vyukov <dvyukov@google.com>
>    Cc: stable 3.13+ <stable@vger.kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit dde143909bd9e295cf6c89c3e7606f15fcc693a4
>Author: Itai Handler <itai_handler@hotmail.com>
>Date:   Tue Nov 3 00:20:56 2015 +0200
>
>    drm/gma500: Fix possible out of bounds read
>    
>    [ Upstream commit 7ccca1d5bf69fdd1d3c5fcf84faf1659a6e0ad11 ]
>    
>    Fix possible out of bounds read, by adding missing comma.
>    The code may read pass the end of the dsi_errors array
>    when the most significant bit (bit #31) in the intr_stat register
>    is set.
>    This bug has been detected using CppCheck (static analysis tool).
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Itai Handler <itai_handler@hotmail.com>
>    Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f448f47758d1e23385fd0846dc27015330908f0d
>Author: Larry Finger <Larry.Finger@lwfinger.net>
>Date:   Wed Mar 16 13:33:35 2016 -0500
>
>    rtlwifi: btcoexist: Implement antenna selection
>    
>    [ Upstream commit baa1702290953295e421f0f433e2b1ff4815827c ]
>    
>    The previous patch added an option to rtl8723be to manually select the
>    antenna for those cases when only a single antenna is present, and the
>    on-board EEPROM is incorrectly programmed. This patch implements the
>    necessary changes in the Bluetooth coexistence driver.
>    
>    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>    Cc: Stable <stable@vger.kernel.org> [V4.0+]
>    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7138f9840bea22badaeea76433957f8d88596554
>Author: Larry Finger <Larry.Finger@lwfinger.net>
>Date:   Wed Mar 16 13:33:34 2016 -0500
>
>    rtlwifi: rtl8723be: Add antenna select module parameter
>    
>    [ Upstream commit c18d8f5095715c56bb3cd9cba64242542632054b ]
>    
>    A number of new laptops have been delivered with only a single antenna.
>    In principle, this is OK; however, a problem arises when the on-board
>    EEPROM is programmed to use the other antenna connection. The option
>    of opening the computer and moving the connector is not always possible
>    as it will void the warranty in some cases. In addition, this solution
>    breaks the Windows driver when the box dual boots Linux and Windows.
>    
>    A fix involving a new module parameter has been developed.  This commit
>    adds the new parameter and implements the changes needed for the driver.
>    
>    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>    Cc: Stable <stable@vger.kernel.org> [V4.0+]
>    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit db4ec7cf24d08d9da4d17fd78294cb8e7f0574d6
>Author: Sasha Levin <sasha.levin@oracle.com>
>Date:   Mon May 30 18:24:55 2016 -0400
>
>    rtlwifi: rtl8723be: Fix module parameter initialization
>    
>    [ Upstream commit 7079604ddb83f428359feace3aeaf8a9f435be4a ]
>    
>    This driver has a number of errors in the module initialization. These
>    include the following:
>    
>    Parameter msi_support is stored in two places - one is removed.
>    Paramters sw_crypto and disable_watchdog were never stored in the final
>    locations, nor were they initialized properly.
>    
>    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>    Cc: Stable <stable@vger.kernel.org>
>    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e8663801545a5e1059da85b5210a9a23939f3a82
>Author: Darrick J. Wong <darrick.wong@oracle.com>
>Date:   Mon Jan 4 16:13:21 2016 +1100
>
>    libxfs: pack the agfl header structure so XFS_AGFL_SIZE is correct
>    
>    [ Upstream commit 96f859d52bcb1c6ea6f3388d39862bf7143e2f30 ]
>    
>    Because struct xfs_agfl is 36 bytes long and has a 64-bit integer
>    inside it, gcc will quietly round the structure size up to the nearest
>    64 bits -- in this case, 40 bytes.  This results in the XFS_AGFL_SIZE
>    macro returning incorrect results for v5 filesystems on 64-bit
>    machines (118 items instead of 119).  As a result, a 32-bit xfs_repair
>    will see garbage in AGFL item 119 and complain.
>    
>    Therefore, tell gcc not to pad the structure so that the AGFL size
>    calculation is correct.
>    
>    cc: <stable@vger.kernel.org> # 3.10 - 4.4
>    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
>    Reviewed-by: Dave Chinner <dchinner@redhat.com>
>    Signed-off-by: Dave Chinner <david@fromorbit.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1fe949f6d0036130e1c62d2e5bee01d9b4ef0e51
>Author: Dave Chinner <dchinner@redhat.com>
>Date:   Wed Apr 6 07:06:20 2016 +1000
>
>    xfs: Don't wrap growfs AGFL indexes
>    
>    [ Upstream commit ad747e3b299671e1a53db74963cc6c5f6cdb9f6d ]
>    
>    Commit 96f859d ("libxfs: pack the agfl header structure so
>    XFS_AGFL_SIZE is correct") allowed the freelist to use the empty
>    slot at the end of the freelist on 64 bit systems that was not
>    being used due to sizeof() rounding up the structure size.
>    
>    This has caused versions of xfs_repair prior to 4.5.0 (which also
>    has the fix) to report this as a corruption once the filesystem has
>    been grown. Older kernels can also have problems (seen from a whacky
>    container/vm management environment) mounting filesystems grown on a
>    system with a newer kernel than the vm/container it is deployed on.
>    
>    To avoid this problem, change the initial free list indexes not to
>    wrap across the end of the AGFL, hence avoiding the initialisation
>    of agf_fllast to the last index in the AGFL.
>    
>    cc: <stable@vger.kernel.org> # 4.4-4.5
>    Signed-off-by: Dave Chinner <dchinner@redhat.com>
>    Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
>    Signed-off-by: Dave Chinner <david@fromorbit.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9c153a82fb6f9a177d0ec2034005b4245973a28f
>Author: Eric Sandeen <sandeen@redhat.com>
>Date:   Wed Apr 6 07:05:41 2016 +1000
>
>    xfs: disallow rw remount on fs with unknown ro-compat features
>    
>    [ Upstream commit d0a58e833931234c44e515b5b8bede32bd4e6eed ]
>    
>    Today, a kernel which refuses to mount a filesystem read-write
>    due to unknown ro-compat features can still transition to read-write
>    via the remount path.  The old kernel is most likely none the wiser,
>    because it's unaware of the new feature, and isn't using it.  However,
>    writing to the filesystem may well corrupt metadata related to that
>    new feature, and moving to a newer kernel which understand the feature
>    will have problems.
>    
>    Right now the only ro-compat feature we have is the free inode btree,
>    which showed up in v3.16.  It would be good to push this back to
>    all the active stable kernels, I think, so that if anyone is using
>    newer mkfs (which enables the finobt feature) with older kernel
>    releases, they'll be protected.
>    
>    Cc: <stable@vger.kernel.org> # 3.10.x-
>    Signed-off-by: Eric Sandeen <sandeen@redhat.com>
>    Reviewed-by: Bill O'Donnell <billodo@redhat.com>
>    Reviewed-by: Dave Chinner <dchinner@redhat.com>
>    Signed-off-by: Dave Chinner <david@fromorbit.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 67b8cea5cc2222a2c7397161ea58b656793956e2
>Author: Joseph Salisbury <joseph.salisbury@canonical.com>
>Date:   Mon Mar 14 14:51:48 2016 -0400
>
>    ath5k: Change led pin configuration for compaq c700 laptop
>    
>    [ Upstream commit 7b9bc799a445aea95f64f15e0083cb19b5789abe ]
>    
>    BugLink: http://bugs.launchpad.net/bugs/972604
>    
>    Commit 09c9bae26b0d3c9472cb6ae45010460a2cee8b8d ("ath5k: add led pin
>    configuration for compaq c700 laptop") added a pin configuration for the Compaq
>    c700 laptop.  However, the polarity of the led pin is reversed.  It should be
>    red for wifi off and blue for wifi on, but it is the opposite.  This bug was
>    reported in the following bug report:
>    http://pad.lv/972604
>    
>    Fixes: 09c9bae26b0d3c9472cb6ae45010460a2cee8b8d ("ath5k: add led pin configuration for compaq c700 laptop")
>    Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit db9c6316bb5a33c02bba78b23101e917b012e399
>Author: Javier Martinez Canillas <javier@osg.samsung.com>
>Date:   Wed Mar 23 20:59:34 2016 -0300
>
>    regulator: Try to resolve regulators supplies on registration
>    
>    [ Upstream commit 5e3ca2b349b1e2c80b060b51bbf2af37448fad85 ]
>    
>    Commit 6261b06de565 ("regulator: Defer lookup of supply to regulator_get")
>    moved the regulator supplies lookup logic from the regulators registration
>    to the regulators get time.
>    
>    Unfortunately, that changed the behavior of the regulator core since now a
>    parent supply with a child regulator marked as always-on, won't be enabled
>    unless a client driver attempts to get the child regulator during boot.
>    
>    This patch tries to resolve the parent supply for the already registered
>    regulators each time that a new regulator is registered. So the regulators
>    that have child regulators marked as always on will be enabled regardless
>    if a driver gets the child regulator or not.
>    
>    That was the behavior before the mentioned commit, since parent supplies
>    were looked up at regulator registration time instead of during child get.
>    
>    Since regulator_resolve_supply() checks for rdev->supply, most of the times
>    it will be a no-op. Errors aren't checked to keep the possible out of order
>    dependencies which was the motivation for the mentioned commit.
>    
>    Also, the supply being available will be enforced on regulator get anyways
>    in case the resolve fails on regulators registration.
>    
>    Fixes: 6261b06de565 ("regulator: Defer lookup of supply to regulator_get")
>    Suggested-by: Mark Brown <broonie@kernel.org>
>    Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>    Signed-off-by: Mark Brown <broonie@kernel.org>
>    Cc: <stable@vger.kernel.org> # 4.1+
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 28c94eff0f24045ff56867196a8a564cc4c5419a
>Author: Mark Brown <broonie@kernel.org>
>Date:   Mon Aug 10 19:43:47 2015 +0100
>
>    regulator: core: Use class device list for regulator_list in late init
>    
>    [ Upstream commit 609ca5f3cb32c2d11fd8cabe293ff3689e7d2613 ]
>    
>    The regulator_list has exactly the same contents as the list that the
>    driver core maintains of regulator_class members so is redundant. As a
>    first step in converting over to use the class device list convert our
>    iteration in late_initcall() to use the class device iterator.
>    
>    Signed-off-by: Mark Brown <broonie@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3dec2ae8b610b459b1e37591149c4065ad343978
>Author: Anilkumar Kolli <akolli@qti.qualcomm.com>
>Date:   Fri Mar 11 11:46:39 2016 +0530
>
>    ath10k: fix debugfs pktlog_filter write
>    
>    [ Upstream commit 9ddc486aa09a3413a6c492fcf160ce61bfccb7b1 ]
>    
>    It is observed that, we are disabling the packet log if we write same
>    value to the pktlog_filter for the second time. Always enable pktlogs
>    on non zero filter.
>    
>    Fixes: 90174455ae05 ("ath10k: add support to configure pktlog filter")
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
>    Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 861c13e117c6c7a21e0a38ea18d68a1fa9d661eb
>Author: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
>Date:   Wed Mar 2 20:13:52 2016 +0530
>
>    ath10k: fix firmware assert in monitor mode
>    
>    [ Upstream commit 8a75fc54745fd3ce9062ab1cc6429a9da9ac2a68 ]
>    
>    commit 166de3f1895d ("ath10k: remove supported chain mask") had revealed
>    an issue on monitor mode. Configuring NSS upon monitor interface
>    creation is causing target assert in all qca9888x and qca6174 firmware.
>    Firmware assert issue can be reproduced by below sequence even after
>    reverting commit 166de3f1895d ("ath10k: remove supported chain mask").
>    
>    ip link set wlan0 down
>    iw wlan0 set type monitor
>    iw phy0 set antenna 7
>    ip link set wlan0 up
>    
>    This issue is originally reported on qca9888 with 10.1 firmware.
>    
>    Fixes: 5572a95b4b ("ath10k: apply chainmask settings to vdev on creation")
>    Cc: stable@vger.kernel.org
>    Reported-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
>    Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
>    Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9a243f2469d31682394673bfe37954789ba50176
>Author: Sasha Levin <sasha.levin@oracle.com>
>Date:   Mon May 30 17:50:36 2016 -0400
>
>    perf/x86/intel/pt: Generate PMI in the STOP region as well
>    
>    [ Upstream commit ab92b232ae05c382c3df0e3d6a5c6d16b639ac8c ]
>    
>    Currently, the PT driver always sets the PMI bit one region (page) before
>    the STOP region so that we can wake up the consumer before we run out of
>    room in the buffer and have to disable the event. However, we also need
>    an interrupt in the last output region, so that we actually get to disable
>    the event (if no more room from new data is available at that point),
>    otherwise hardware just quietly refuses to start, but the event is
>    scheduled in and we end up losing trace data till the event gets removed.
>    
>    For a cpu-wide event it is even worse since there may not be any
>    re-scheduling at all and no chance for the ring buffer code to notice
>    that its buffer is filled up and the event needs to be disabled (so that
>    the consumer can re-enable it when it finishes reading the data out). In
>    other words, all the trace data will be lost after the buffer gets filled
>    up.
>    
>    This patch makes PT also generate a PMI when the last output region is
>    full.
>    
>    Reported-by: Markus Metzger <markus.t.metzger@intel.com>
>    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
>    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>    Cc: <stable@vger.kernel.org>
>    Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
>    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
>    Cc: Borislav Petkov <bp@alien8.de>
>    Cc: Jiri Olsa <jolsa@redhat.com>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Stephane Eranian <eranian@google.com>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Cc: Vince Weaver <vincent.weaver@maine.edu>
>    Cc: vince@deater.net
>    Link: http://lkml.kernel.org/r/1462886313-13660-2-git-send-email-alexander.shishkin@linux.intel.com
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e429f243df2823451c92227317e5fce5f310b674
>Author: Sasha Levin <sasha.levin@oracle.com>
>Date:   Fri May 20 21:46:13 2016 -0400
>
>    Linux 4.1.25
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8de861b16d946b7c0ce246fcbb65d550c357c65c
>Author: Linus Torvalds <torvalds@linux-foundation.org>
>Date:   Sat May 14 11:11:44 2016 -0700
>
>    nf_conntrack: avoid kernel pointer value leak in slab name
>    
>    [ Upstream commit 31b0b385f69d8d5491a4bca288e25e63f1d945d0 ]
>    
>    The slab name ends up being visible in the directory structure under
>    /sys, and even if you don't have access rights to the file you can see
>    the filenames.
>    
>    Just use a 64-bit counter instead of the pointer to the 'net' structure
>    to generate a unique name.
>    
>    This code will go away in 4.7 when the conntrack code moves to a single
>    kmemcache, but this is the backportable simple solution to avoiding
>    leaking kernel pointers to user space.
>    
>    Fixes: 5b3501faa874 ("netfilter: nf_conntrack: per netns nf_conntrack_cachep")
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 631598a5c08505c92348b3907824072d0c1000ab
>Author: Junxiao Bi <junxiao.bi@oracle.com>
>Date:   Thu May 12 15:42:18 2016 -0700
>
>    ocfs2: fix posix_acl_create deadlock
>    
>    [ Upstream commit c25a1e0671fbca7b2c0d0757d533bd2650d6dc0c ]
>    
>    Commit 702e5bc68ad2 ("ocfs2: use generic posix ACL infrastructure")
>    refactored code to use posix_acl_create.  The problem with this function
>    is that it is not mindful of the cluster wide inode lock making it
>    unsuitable for use with ocfs2 inode creation with ACLs.  For example,
>    when used in ocfs2_mknod, this function can cause deadlock as follows.
>    The parent dir inode lock is taken when calling posix_acl_create ->
>    get_acl -> ocfs2_iop_get_acl which takes the inode lock again.  This can
>    cause deadlock if there is a blocked remote lock request waiting for the
>    lock to be downconverted.  And same deadlock happened in ocfs2_reflink.
>    This fix is to revert back using ocfs2_init_acl.
>    
>    Fixes: 702e5bc68ad2 ("ocfs2: use generic posix ACL infrastructure")
>    Signed-off-by: Tariq Saeed <tariq.x.saeed@oracle.com>
>    Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
>    Cc: Mark Fasheh <mfasheh@suse.de>
>    Cc: Joel Becker <jlbec@evilplan.org>
>    Cc: Joseph Qi <joseph.qi@huawei.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 533e936848522f8394709b64fba45f657ca26f10
>Author: Junxiao Bi <junxiao.bi@oracle.com>
>Date:   Thu May 12 15:42:15 2016 -0700
>
>    ocfs2: revert using ocfs2_acl_chmod to avoid inode cluster lock hang
>    
>    [ Upstream commit 5ee0fbd50fdf1c1329de8bee35ea9d7c6a81a2e0 ]
>    
>    Commit 743b5f1434f5 ("ocfs2: take inode lock in ocfs2_iop_set/get_acl()")
>    introduced this issue.  ocfs2_setattr called by chmod command holds
>    cluster wide inode lock when calling posix_acl_chmod.  This latter
>    function in turn calls ocfs2_iop_get_acl and ocfs2_iop_set_acl.  These
>    two are also called directly from vfs layer for getfacl/setfacl commands
>    and therefore acquire the cluster wide inode lock.  If a remote
>    conversion request comes after the first inode lock in ocfs2_setattr,
>    OCFS2_LOCK_BLOCKED will be set.  And this will cause the second call to
>    inode lock from the ocfs2_iop_get_acl() to block indefinetly.
>    
>    The deleted version of ocfs2_acl_chmod() calls __posix_acl_chmod() which
>    does not call back into the filesystem.  Therefore, we restore
>    ocfs2_acl_chmod(), modify it slightly for locking as needed, and use that
>    instead.
>    
>    Fixes: 743b5f1434f5 ("ocfs2: take inode lock in ocfs2_iop_set/get_acl()")
>    Signed-off-by: Tariq Saeed <tariq.x.saeed@oracle.com>
>    Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
>    Cc: Mark Fasheh <mfasheh@suse.de>
>    Cc: Joel Becker <jlbec@evilplan.org>
>    Cc: Joseph Qi <joseph.qi@huawei.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2239ca3f89e5dfb1f24e98207318d91e6c2cf0f7
>Author: Junxiao Bi <junxiao.bi@oracle.com>
>Date:   Fri Dec 11 13:41:03 2015 -0800
>
>    ocfs2: fix SGID not inherited issue
>    
>    [ Upstream commit 854ee2e944b4daf795e32562a7d2f9e90ab5a6a8 ]
>    
>    Commit 8f1eb48758aa ("ocfs2: fix umask ignored issue") introduced an
>    issue, SGID of sub dir was not inherited from its parents dir.  It is
>    because SGID is set into "inode->i_mode" in ocfs2_get_init_inode(), but
>    is overwritten by "mode" which don't have SGID set later.
>    
>    Fixes: 8f1eb48758aa ("ocfs2: fix umask ignored issue")
>    Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
>    Cc: Mark Fasheh <mfasheh@suse.de>
>    Cc: Joel Becker <jlbec@evilplan.org>
>    Acked-by: Srinivas Eeda <srinivas.eeda@oracle.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6bdf63fe8999171e65f6b65bf837d3c5f8571da1
>Author: Alex Deucher <alexander.deucher@amd.com>
>Date:   Wed May 11 16:16:53 2016 -0400
>
>    drm/radeon: fix DP mode validation
>    
>    [ Upstream commit ff0bd441bdfbfa09d05fdba9829a0401a46635c1 ]
>    
>    Switch the order of the loops to walk the rates on the top
>    so we exhaust all DP 1.1 rate/lane combinations before trying
>    DP 1.2 rate/lane combos.
>    
>    This avoids selecting rates that are supported by the monitor,
>    but not the connector leading to valid modes getting rejected.
>    
>    bug:
>    https://bugs.freedesktop.org/show_bug.cgi?id=95206
>    
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3a1b9a74de5c10995d1fd842e3d2344d4e826ae1
>Author: Wanpeng Li <wanpeng.li@hotmail.com>
>Date:   Wed May 11 17:55:18 2016 +0800
>
>    workqueue: fix rebind bound workers warning
>    
>    [ Upstream commit f7c17d26f43d5cc1b7a6b896cd2fa24a079739b9 ]
>    
>    ------------[ cut here ]------------
>    WARNING: CPU: 0 PID: 16 at kernel/workqueue.c:4559 rebind_workers+0x1c0/0x1d0
>    Modules linked in:
>    CPU: 0 PID: 16 Comm: cpuhp/0 Not tainted 4.6.0-rc4+ #31
>    Hardware name: IBM IBM System x3550 M4 Server -[7914IUW]-/00Y8603, BIOS -[D7E128FUS-1.40]- 07/23/2013
>     0000000000000000 ffff881037babb58 ffffffff8139d885 0000000000000010
>     0000000000000000 0000000000000000 0000000000000000 ffff881037babba8
>     ffffffff8108505d ffff881037ba0000 000011cf3e7d6e60 0000000000000046
>    Call Trace:
>     dump_stack+0x89/0xd4
>     __warn+0xfd/0x120
>     warn_slowpath_null+0x1d/0x20
>     rebind_workers+0x1c0/0x1d0
>     workqueue_cpu_up_callback+0xf5/0x1d0
>     notifier_call_chain+0x64/0x90
>     ? trace_hardirqs_on_caller+0xf2/0x220
>     ? notify_prepare+0x80/0x80
>     __raw_notifier_call_chain+0xe/0x10
>     __cpu_notify+0x35/0x50
>     notify_down_prepare+0x5e/0x80
>     ? notify_prepare+0x80/0x80
>     cpuhp_invoke_callback+0x73/0x330
>     ? __schedule+0x33e/0x8a0
>     cpuhp_down_callbacks+0x51/0xc0
>     cpuhp_thread_fun+0xc1/0xf0
>     smpboot_thread_fn+0x159/0x2a0
>     ? smpboot_create_threads+0x80/0x80
>     kthread+0xef/0x110
>     ? wait_for_completion+0xf0/0x120
>     ? schedule_tail+0x35/0xf0
>     ret_from_fork+0x22/0x50
>     ? __init_kthread_worker+0x70/0x70
>    ---[ end trace eb12ae47d2382d8f ]---
>    notify_down_prepare: attempt to take down CPU 0 failed
>    
>    This bug can be reproduced by below config w/ nohz_full= all cpus:
>    
>    CONFIG_BOOTPARAM_HOTPLUG_CPU0=y
>    CONFIG_DEBUG_HOTPLUG_CPU0=y
>    CONFIG_NO_HZ_FULL=y
>    
>    As Thomas pointed out:
>    
>    | If a down prepare callback fails, then DOWN_FAILED is invoked for all
>    | callbacks which have successfully executed DOWN_PREPARE.
>    |
>    | But, workqueue has actually two notifiers. One which handles
>    | UP/DOWN_FAILED/ONLINE and one which handles DOWN_PREPARE.
>    |
>    | Now look at the priorities of those callbacks:
>    |
>    | CPU_PRI_WORKQUEUE_UP        = 5
>    | CPU_PRI_WORKQUEUE_DOWN      = -5
>    |
>    | So the call order on DOWN_PREPARE is:
>    |
>    | CB 1
>    | CB ...
>    | CB workqueue_up() -> Ignores DOWN_PREPARE
>    | CB ...
>    | CB X ---> Fails
>    |
>    | So we call up to CB X with DOWN_FAILED
>    |
>    | CB 1
>    | CB ...
>    | CB workqueue_up() -> Handles DOWN_FAILED
>    | CB ...
>    | CB X-1
>    |
>    | So the problem is that the workqueue stuff handles DOWN_FAILED in the up
>    | callback, while it should do it in the down callback. Which is not a good idea
>    | either because it wants to be called early on rollback...
>    |
>    | Brilliant stuff, isn't it? The hotplug rework will solve this problem because
>    | the callbacks become symetric, but for the existing mess, we need some
>    | workaround in the workqueue code.
>    
>    The boot CPU handles housekeeping duty(unbound timers, workqueues,
>    timekeeping, ...) on behalf of full dynticks CPUs. It must remain
>    online when nohz full is enabled. There is a priority set to every
>    notifier_blocks:
>    
>    workqueue_cpu_up > tick_nohz_cpu_down > workqueue_cpu_down
>    
>    So tick_nohz_cpu_down callback failed when down prepare cpu 0, and
>    notifier_blocks behind tick_nohz_cpu_down will not be called any
>    more, which leads to workers are actually not unbound. Then hotplug
>    state machine will fallback to undo and online cpu 0 again. Workers
>    will be rebound unconditionally even if they are not unbound and
>    trigger the warning in this progress.
>    
>    This patch fix it by catching !DISASSOCIATED to avoid rebind bound
>    workers.
>    
>    Cc: Tejun Heo <tj@kernel.org>
>    Cc: Lai Jiangshan <jiangshanlai@gmail.com>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: FrÃ©dÃ©ric Weisbecker <fweisbec@gmail.com>
>    Cc: stable@vger.kernel.org
>    Suggested-by: Lai Jiangshan <jiangshanlai@gmail.com>
>    Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 47348e3fcc9aeeb64d792d05c735b37b2c22fbac
>Author: Steven Rostedt <rostedt@goodmis.org>
>Date:   Wed May 11 15:09:36 2016 -0400
>
>    tools lib traceevent: Do not reassign parg after collapse_tree()
>    
>    [ Upstream commit 106b816cb46ebd87408b4ed99a2e16203114daa6 ]
>    
>    At the end of process_filter(), collapse_tree() was changed to update
>    the parg parameter, but the reassignment after the call wasn't removed.
>    
>    What happens is that the "current_op" gets modified and freed and parg
>    is assigned to the new allocated argument. But after the call to
>    collapse_tree(), parg is assigned again to the just freed "current_op",
>    and this causes the tool to crash.
>    
>    The current_op variable must also be assigned to NULL in case of error,
>    otherwise it will cause it to be free()ed twice.
>    
>    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
>    Acked-by: Namhyung Kim <namhyung@kernel.org>
>    Cc: stable@vger.kernel.org # 3.14+
>    Fixes: 42d6194d133c ("tools lib traceevent: Refactor process_filter()")
>    Link: http://lkml.kernel.org/r/20160511150936.678c18a1@gandalf.local.home
>    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6f24160677ab5a2783b7f1f2ea5c2a23526d494e
>Author: Alexander Shishkin <alexander.shishkin@linux.intel.com>
>Date:   Tue May 10 16:18:33 2016 +0300
>
>    perf/core: Disable the event on a truncated AUX record
>    
>    [ Upstream commit 9f448cd3cbcec8995935e60b27802ae56aac8cc0 ]
>    
>    When the PMU driver reports a truncated AUX record, it effectively means
>    that there is no more usable room in the event's AUX buffer (even though
>    there may still be some room, so that perf_aux_output_begin() doesn't take
>    action). At this point the consumer still has to be woken up and the event
>    has to be disabled, otherwise the event will just keep spinning between
>    perf_aux_output_begin() and perf_aux_output_end() until its context gets
>    unscheduled.
>    
>    Again, for cpu-wide events this means never, so once in this condition,
>    they will be forever losing data.
>    
>    Fix this by disabling the event and waking up the consumer in case of a
>    truncated AUX record.
>    
>    Reported-by: Markus Metzger <markus.t.metzger@intel.com>
>    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
>    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>    Cc: <stable@vger.kernel.org>
>    Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
>    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
>    Cc: Borislav Petkov <bp@alien8.de>
>    Cc: Jiri Olsa <jolsa@redhat.com>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Stephane Eranian <eranian@google.com>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Cc: Vince Weaver <vincent.weaver@maine.edu>
>    Cc: vince@deater.net
>    Link: http://lkml.kernel.org/r/1462886313-13660-3-git-send-email-alexander.shishkin@linux.intel.com
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e5c1c3a557c8412a9afe7bc346976e93de95c1c5
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Wed May 11 17:48:00 2016 +0200
>
>    ALSA: usb-audio: Yet another Phoneix Audio device quirk
>    
>    [ Upstream commit 84add303ef950b8d85f54bc2248c2bc73467c329 ]
>    
>    Phoenix Audio has yet another device with another id (even a different
>    vendor id, 0556:0014) that requires the same quirk for the sample
>    rate.
>    
>    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=110221
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f9a461fc2d0ffc46b1b4372297ba051325013d11
>Author: Yura Pakhuchiy <pakhuchiy@gmail.com>
>Date:   Sat May 7 23:53:36 2016 +0700
>
>    ALSA: hda - Fix subwoofer pin on ASUS N751 and N551
>    
>    [ Upstream commit 3231e2053eaeee70bdfb216a78a30f11e88e2243 ]
>    
>    Subwoofer does not work out of the box on ASUS N751/N551 laptops. This
>    patch fixes it. Patch tested on N751 laptop. N551 part is not tested,
>    but according to [1] and [2] this laptop requires similar changes, so I
>    included them in the patch.
>    
>    1. https://github.com/honsiorovskyi/asus-n551-hda-fix
>    2. https://bugs.launchpad.net/ubuntu/+source/alsa-tools/+bug/1405691
>    
>    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=117781
>    Signed-off-by: Yura Pakhuchiy <pakhuchiy@gmail.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 41d234935fe0e793093bf98fc49d740c207f3729
>Author: Bobi Mihalca <bobbymihalca@touchtech.ro>
>Date:   Wed Mar 23 13:26:11 2016 +0200
>
>    ALSA: hda - Fix white noise on Asus N750JV headphone
>    
>    [ Upstream commit 9d4dc5840f93bcb002fa311693349deae7702bc5 ]
>    
>    For reducing the noise from the headphone output on ASUS N750JV,
>    call the existing fixup, alc_fixup_auto_mute_via_amp(), additionally.
>    
>    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=115181
>    Signed-off-by: Bobi Mihalca <bobbymihalca@touchtech.ro>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 87cc31ebd15957113ccdaaa6580264e460b2273c
>Author: Bobi Mihalca <bobbymihalca@touchtech.ro>
>Date:   Wed Mar 23 13:23:55 2016 +0200
>
>    ALSA: hda - Asus N750JV external subwoofer fixup
>    
>    [ Upstream commit 70cf2cbd685e218c3ffd105d9fb6cf0f8d767481 ]
>    
>    ASUS N750JV needs the same fixup as N550 for enabling its subwoofer.
>    
>    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=115181
>    Signed-off-by: Bobi Mihalca <bobbymihalca@touchtech.ro>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit da58c2eb0bdbfa02cd32d5c8e73ff21c7c49b601
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Tue May 10 10:24:02 2016 +0200
>
>    ALSA: hda - Fix broken reconfig
>    
>    [ Upstream commit addacd801e1638f41d659cb53b9b73fc14322cb1 ]
>    
>    The HD-audio reconfig function got broken in the recent kernels,
>    typically resulting in a failure like:
>      snd_hda_intel 0000:00:1b.0: control 3:0:0:Playback Channel Map:0 is already present
>    
>    This is because of the code restructuring to move the PCM and control
>    instantiation into the codec drive probe, by the commit [bcd96557bd0a:
>    ALSA: hda - Build PCMs and controls at codec driver probe].  Although
>    the commit above removed the calls of snd_hda_codec_build_pcms() and
>    *_build_controls() at the controller driver probe, the similar calls
>    in the reconfig were still left forgotten.  This caused the
>    conflicting and duplicated PCMs and controls.
>    
>    The fix is trivial: just remove these superfluous calls from
>    reconfig_codec().
>    
>    Fixes: bcd96557bd0a ('ALSA: hda - Build PCMs and controls at codec driver probe')
>    Reported-by: Jochen Henneberg <jh@henneberg-systemdesign.com>
>    Cc: <stable@vger.kernel.org> # v4.1+
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4a4c1df1af598459b550861f6bff17bfd8792295
>Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>Date:   Tue May 3 10:33:01 2016 +0200
>
>    drm/i915: Bail out of pipe config compute loop on LPT
>    
>    [ Upstream commit 2700818ac9f935d8590715eecd7e8cadbca552b6 ]
>    
>    LPT is pch, so might run into the fdi bandwidth constraint (especially
>    since it has only 2 lanes). But right now we just force pipe_bpp back
>    to 24, resulting in a nice loop (which we bail out with a loud
>    WARN_ON). Fix this.
>    
>    Cc: Chris Wilson <chris@chris-wilson.co.uk>
>    Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>    References: https://bugs.freedesktop.org/show_bug.cgi?id=93477
>    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>    Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
>    Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>    Link: http://patchwork.freedesktop.org/patch/msgid/1462264381-7573-1-git-send-email-daniel.vetter@ffwll.ch
>    (cherry picked from commit f58a1acc7e4a1f37d26124ce4c875c647fbcc61f)
>    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6225c54e09f0f22454cc08a2526765226559ede6
>Author: Marek Szyprowski <m.szyprowski@samsung.com>
>Date:   Mon May 9 09:31:47 2016 -0700
>
>    Input: max8997-haptic - fix NULL pointer dereference
>    
>    [ Upstream commit 6ae645d5fa385f3787bf1723639cd907fe5865e7 ]
>    
>    NULL pointer derefence happens when booting with DTB because the
>    platform data for haptic device is not set in supplied data from parent
>    MFD device.
>    
>    The MFD device creates only platform data (from Device Tree) for itself,
>    not for haptic child.
>    
>    Unable to handle kernel NULL pointer dereference at virtual address 0000009c
>    pgd = c0004000
>    	[0000009c] *pgd=00000000
>    	Internal error: Oops: 5 [#1] PREEMPT SMP ARM
>    	(max8997_haptic_probe) from [<c03f9cec>] (platform_drv_probe+0x4c/0xb0)
>    	(platform_drv_probe) from [<c03f8440>] (driver_probe_device+0x214/0x2c0)
>    	(driver_probe_device) from [<c03f8598>] (__driver_attach+0xac/0xb0)
>    	(__driver_attach) from [<c03f67ac>] (bus_for_each_dev+0x68/0x9c)
>    	(bus_for_each_dev) from [<c03f7a38>] (bus_add_driver+0x1a0/0x218)
>    	(bus_add_driver) from [<c03f8db0>] (driver_register+0x78/0xf8)
>    	(driver_register) from [<c0101774>] (do_one_initcall+0x90/0x1d8)
>    	(do_one_initcall) from [<c0a00dbc>] (kernel_init_freeable+0x15c/0x1fc)
>    	(kernel_init_freeable) from [<c06bb5b4>] (kernel_init+0x8/0x114)
>    	(kernel_init) from [<c0107938>] (ret_from_fork+0x14/0x3c)
>    
>    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>    Cc: <stable@vger.kernel.org>
>    Fixes: 104594b01ce7 ("Input: add driver support for MAX8997-haptic")
>    [k.kozlowski: Write commit message, add CC-stable]
>    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 53c60e1ab465c8032b1795a2192aa00dcedec5db
>Author: Kaho Ng <ngkaho1234@gmail.com>
>Date:   Mon May 9 00:27:49 2016 +0800
>
>    ALSA: hda - Fix white noise on Asus UX501VW headset
>    
>    [ Upstream commit 2da2dc9ead232f25601404335cca13c0f722d41b ]
>    
>    For reducing the noise from the headset output on ASUS UX501VW,
>    call the existing fixup, alc_fixup_headset_mode_alc668(), additionally.
>    
>    Thread: https://bbs.archlinux.org/viewtopic.php?id=209554
>    
>    Signed-off-by: Kaho Ng <ngkaho1234@gmail.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3f81442f44c1736e78a41afef728160f3dc9fae3
>Author: Bobi Mihalca <bobbymihalca@touchtech.ro>
>Date:   Wed Mar 23 13:32:33 2016 +0200
>
>    ALSA: hda - Apply fix for white noise on Asus N550JV, too
>    
>    [ Upstream commit 83a9efb5b8170b7cffef4f62656656e1d8ad2ccd ]
>    
>    Apply the new fixup that is used for ASUS N750JV to another similar
>    model, N500JV, too, for reducing the headphone noise.
>    
>    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=115181
>    Signed-off-by: Bobi Mihalca <bobbymihalca@touchtech.ro>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f1ee8222aed8d64bbf922ba9bf00dc7ac98ab63f
>Author: Al Viro <viro@zeniv.linux.org.uk>
>Date:   Thu May 5 16:25:35 2016 -0400
>
>    get_rock_ridge_filename(): handle malformed NM entries
>    
>    [ Upstream commit 99d825822eade8d827a1817357cbf3f889a552d6 ]
>    
>    Payloads of NM entries are not supposed to contain NUL.  When we run
>    into such, only the part prior to the first NUL goes into the
>    concatenation (i.e. the directory entry name being encoded by a bunch
>    of NM entries).  We do stop when the amount collected so far + the
>    claimed amount in the current NM entry exceed 254.  So far, so good,
>    but what we return as the total length is the sum of *claimed*
>    sizes, not the actual amount collected.  And that can grow pretty
>    large - not unlimited, since you'd need to put CE entries in
>    between to be able to get more than the maximum that could be
>    contained in one isofs directory entry / continuation chunk and
>    we are stop once we'd encountered 32 CEs, but you can get about 8Kb
>    easily.  And that's what will be passed to readdir callback as the
>    name length.  8Kb __copy_to_user() from a buffer allocated by
>    __get_free_page()
>    
>    Cc: stable@vger.kernel.org # 0.98pl6+ (yes, really)
>    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 53e7d7c9357328ba627204ebf8c14773ad514f58
>Author: Dmitry V. Levin <ldv@altlinux.org>
>Date:   Wed Apr 27 04:56:11 2016 +0300
>
>    parisc: fix a bug when syscall number of tracee is __NR_Linux_syscalls
>    
>    [ Upstream commit f0b22d1bb2a37a665a969e95785c75a4f49d1499 ]
>    
>    Do not load one entry beyond the end of the syscall table when the
>    syscall number of a traced process equals to __NR_Linux_syscalls.
>    Similar bug with regular processes was fixed by commit 3bb457af4fa8
>    ("[PARISC] Fix bug when syscall nr is __NR_Linux_syscalls").
>    
>    This bug was found by strace test suite.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
>    Acked-by: Helge Deller <deller@gmx.de>
>    Signed-off-by: Helge Deller <deller@gmx.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit fbb78d42a4923cca5a9322ae495a6e2c1d4455f5
>Author: Chen Yu <yu.c.chen@intel.com>
>Date:   Fri May 6 11:33:39 2016 +0800
>
>    x86/tsc: Read all ratio bits from MSR_PLATFORM_INFO
>    
>    [ Upstream commit 886123fb3a8656699dff40afa0573df359abeb18 ]
>    
>    Currently we read the tsc radio: ratio = (MSR_PLATFORM_INFO >> 8) & 0x1f;
>    
>    Thus we get bit 8-12 of MSR_PLATFORM_INFO, however according to the SDM
>    (35.5), the ratio bits are bit 8-15.
>    
>    Ignoring the upper bits can result in an incorrect tsc ratio, which causes the
>    TSC calibration and the Local APIC timer frequency to be incorrect.
>    
>    Fix this problem by masking 0xff instead.
>    
>    [ tglx: Massaged changelog ]
>    
>    Fixes: 7da7c1561366 "x86, tsc: Add static (MSR) TSC calibration on Intel Atom SoCs"
>    Signed-off-by: Chen Yu <yu.c.chen@intel.com>
>    Cc: "Rafael J. Wysocki" <rafael@kernel.org>
>    Cc: stable@vger.kernel.org
>    Cc: Bin Gao <bin.gao@intel.com>
>    Cc: Len Brown <lenb@kernel.org>
>    Link: http://lkml.kernel.org/r/1462505619-5516-1-git-send-email-yu.c.chen@intel.com
>    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c58ca6100b3d1b9890776d9fdd8aa12352d49bc8
>Author: Hugh Dickins <hughd@google.com>
>Date:   Thu May 5 16:22:15 2016 -0700
>
>    mm, cma: prevent nr_isolated_* counters from going negative
>    
>    [ Upstream commit 14af4a5e9b26ad251f81c174e8a43f3e179434a5 ]
>    
>    /proc/sys/vm/stat_refresh warns nr_isolated_anon and nr_isolated_file go
>    increasingly negative under compaction: which would add delay when
>    should be none, or no delay when should delay.  The bug in compaction
>    was due to a recent mmotm patch, but much older instance of the bug was
>    also noticed in isolate_migratepages_range() which is used for CMA and
>    gigantic hugepage allocations.
>    
>    The bug is caused by putback_movable_pages() in an error path
>    decrementing the isolated counters without them being previously
>    incremented by acct_isolated().  Fix isolate_migratepages_range() by
>    removing the error-path putback, thus reaching acct_isolated() with
>    migratepages still isolated, and leaving putback to caller like most
>    other places do.
>    
>    Fixes: edc2ca612496 ("mm, compaction: move pageblock checks up from isolate_migratepages_range()")
>    [vbabka@suse.cz: expanded the changelog]
>    Signed-off-by: Hugh Dickins <hughd@google.com>
>    Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
>    Acked-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
>    Cc: Michal Hocko <mhocko@kernel.org>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c42d74f018b072b30570856dd43ff582c4e5117e
>Author: Arindam Nath <arindam.nath@amd.com>
>Date:   Wed May 4 23:39:59 2016 +0530
>
>    drm/radeon: fix DP link training issue with second 4K monitor
>    
>    [ Upstream commit 1a738347df2ee4977459a8776fe2c62196bdcb1b ]
>    
>    There is an issue observed when we hotplug a second DP
>    4K monitor to the system. Sometimes, the link training
>    fails for the second monitor after HPD interrupt
>    generation.
>    
>    The issue happens when some queued or deferred transactions
>    are already present on the AUX channel when we initiate
>    a new transcation to (say) get DPCD or during link training.
>    
>    We set AUX_IGNORE_HPD_DISCON bit in the AUX_CONTROL
>    register so that we can ignore any such deferred
>    transactions when a new AUX transaction is initiated.
>    
>    Signed-off-by: Arindam Nath <arindam.nath@amd.com>
>    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 60f7e3a2dc30ae39574a7c7239a9a47c08b774bd
>Author: Eric W. Biederman <ebiederm@xmission.com>
>Date:   Thu May 5 09:29:29 2016 -0500
>
>    propogate_mnt: Handle the first propogated copy being a slave
>    
>    [ Upstream commit 5ec0811d30378ae104f250bfc9b3640242d81e3f ]
>    
>    When the first propgated copy was a slave the following oops would result:
>    > BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
>    > IP: [<ffffffff811fba4e>] propagate_one+0xbe/0x1c0
>    > PGD bacd4067 PUD bac66067 PMD 0
>    > Oops: 0000 [#1] SMP
>    > Modules linked in:
>    > CPU: 1 PID: 824 Comm: mount Not tainted 4.6.0-rc5userns+ #1523
>    > Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
>    > task: ffff8800bb0a8000 ti: ffff8800bac3c000 task.ti: ffff8800bac3c000
>    > RIP: 0010:[<ffffffff811fba4e>]  [<ffffffff811fba4e>] propagate_one+0xbe/0x1c0
>    > RSP: 0018:ffff8800bac3fd38  EFLAGS: 00010283
>    > RAX: 0000000000000000 RBX: ffff8800bb77ec00 RCX: 0000000000000010
>    > RDX: 0000000000000000 RSI: ffff8800bb58c000 RDI: ffff8800bb58c480
>    > RBP: ffff8800bac3fd48 R08: 0000000000000001 R09: 0000000000000000
>    > R10: 0000000000001ca1 R11: 0000000000001c9d R12: 0000000000000000
>    > R13: ffff8800ba713800 R14: ffff8800bac3fda0 R15: ffff8800bb77ec00
>    > FS:  00007f3c0cd9b7e0(0000) GS:ffff8800bfb00000(0000) knlGS:0000000000000000
>    > CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>    > CR2: 0000000000000010 CR3: 00000000bb79d000 CR4: 00000000000006e0
>    > Stack:
>    >  ffff8800bb77ec00 0000000000000000 ffff8800bac3fd88 ffffffff811fbf85
>    >  ffff8800bac3fd98 ffff8800bb77f080 ffff8800ba713800 ffff8800bb262b40
>    >  0000000000000000 0000000000000000 ffff8800bac3fdd8 ffffffff811f1da0
>    > Call Trace:
>    >  [<ffffffff811fbf85>] propagate_mnt+0x105/0x140
>    >  [<ffffffff811f1da0>] attach_recursive_mnt+0x120/0x1e0
>    >  [<ffffffff811f1ec3>] graft_tree+0x63/0x70
>    >  [<ffffffff811f1f6b>] do_add_mount+0x9b/0x100
>    >  [<ffffffff811f2c1a>] do_mount+0x2aa/0xdf0
>    >  [<ffffffff8117efbe>] ? strndup_user+0x4e/0x70
>    >  [<ffffffff811f3a45>] SyS_mount+0x75/0xc0
>    >  [<ffffffff8100242b>] do_syscall_64+0x4b/0xa0
>    >  [<ffffffff81988f3c>] entry_SYSCALL64_slow_path+0x25/0x25
>    > Code: 00 00 75 ec 48 89 0d 02 22 22 01 8b 89 10 01 00 00 48 89 05 fd 21 22 01 39 8e 10 01 00 00 0f 84 e0 00 00 00 48 8b 80 d8 00 00 00 <48> 8b 50 10 48 89 05 df 21 22 01 48 89 15 d0 21 22 01 8b 53 30
>    > RIP  [<ffffffff811fba4e>] propagate_one+0xbe/0x1c0
>    >  RSP <ffff8800bac3fd38>
>    > CR2: 0000000000000010
>    > ---[ end trace 2725ecd95164f217 ]---
>    
>    This oops happens with the namespace_sem held and can be triggered by
>    non-root users.  An all around not pleasant experience.
>    
>    To avoid this scenario when finding the appropriate source mount to
>    copy stop the walk up the mnt_master chain when the first source mount
>    is encountered.
>    
>    Further rewrite the walk up the last_source mnt_master chain so that
>    it is clear what is going on.
>    
>    The reason why the first source mount is special is that it it's
>    mnt_parent is not a mount in the dest_mnt propagation tree, and as
>    such termination conditions based up on the dest_mnt mount propgation
>    tree do not make sense.
>    
>    To avoid other kinds of confusion last_dest is not changed when
>    computing last_source.  last_dest is only used once in propagate_one
>    and that is above the point of the code being modified, so changing
>    the global variable is meaningless and confusing.
>    
>    Cc: stable@vger.kernel.org
>    fixes: f2ebb3a921c1ca1e2ddd9242e95a1989a50c4c68 ("smarter propagate_mnt()")
>    Reported-by: Tycho Andersen <tycho.andersen@canonical.com>
>    Reviewed-by: Seth Forshee <seth.forshee@canonical.com>
>    Tested-by: Seth Forshee <seth.forshee@canonical.com>
>    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2d7405bfccabafa2f0c2ecf535d251da640cfade
>Author: Maxim Patlasov <mpatlasov@virtuozzo.com>
>Date:   Tue Feb 16 11:45:33 2016 -0800
>
>    fs/pnode.c: treat zero mnt_group_id-s as unequal
>    
>    [ Upstream commit 7ae8fd0351f912b075149a1e03a017be8b903b9a ]
>    
>    propagate_one(m) calculates "type" argument for copy_tree() like this:
>    
>    >    if (m->mnt_group_id == last_dest->mnt_group_id) {
>    >        type = CL_MAKE_SHARED;
>    >    } else {
>    >        type = CL_SLAVE;
>    >        if (IS_MNT_SHARED(m))
>    >           type |= CL_MAKE_SHARED;
>    >   }
>    
>    The "type" argument then governs clone_mnt() behavior with respect to flags
>    and mnt_master of new mount. When we iterate through a slave group, it is
>    possible that both current "m" and "last_dest" are not shared (although,
>    both are slaves, i.e. have non-NULL mnt_master-s). Then the comparison
>    above erroneously makes new mount shared and sets its mnt_master to
>    last_source->mnt_master. The patch fixes the problem by handling zero
>    mnt_group_id-s as though they are unequal.
>    
>    The similar problem exists in the implementation of "else" clause above
>    when we have to ascend upward in the master/slave tree by calling:
>    
>    >    last_source = last_source->mnt_master;
>    >    last_dest = last_source->mnt_parent;
>    
>    proper number of times. The last step is governed by
>    "n->mnt_group_id != last_dest->mnt_group_id" condition that may lie if
>    both are zero. The patch fixes this case in the same way as the former one.
>    
>    [AV: don't open-code an obvious helper...]
>    
>    Signed-off-by: Maxim Patlasov <mpatlasov@virtuozzo.com>
>    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ade3716f4dff60c9aab9f71a5190615effbdf169
>Author: Wang YanQing <udknight@gmail.com>
>Date:   Thu May 5 14:14:21 2016 +0100
>
>    x86/sysfb_efi: Fix valid BAR address range check
>    
>    [ Upstream commit c10fcb14c7afd6688c7b197a814358fecf244222 ]
>    
>    The code for checking whether a BAR address range is valid will break
>    out of the loop when a start address of 0x0 is encountered.
>    
>    This behaviour is wrong since by breaking out of the loop we may miss
>    the BAR that describes the EFI frame buffer in a later iteration.
>    
>    Because of this bug I can't use video=efifb: boot parameter to get
>    efifb on my new ThinkPad E550 for my old linux system hard disk with
>    3.10 kernel. In 3.10, efifb is the only choice due to DRM/I915 not
>    supporting the GPU.
>    
>    This patch also add a trivial optimization to break out after we find
>    the frame buffer address range without testing later BARs.
>    
>    Signed-off-by: Wang YanQing <udknight@gmail.com>
>    [ Rewrote changelog. ]
>    Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
>    Reviewed-by: Peter Jones <pjones@redhat.com>
>    Cc: <stable@vger.kernel.org>
>    Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>    Cc: David Herrmann <dh.herrmann@gmail.com>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
>    Cc: linux-efi@vger.kernel.org
>    Link: http://lkml.kernel.org/r/1462454061-21561-2-git-send-email-matt@codeblueprint.co.uk
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1669540814a1cf57ff50e037c5bf84f831ea4e09
>Author: Herbert Xu <herbert@gondor.apana.org.au>
>Date:   Wed May 4 17:52:56 2016 +0800
>
>    crypto: hash - Fix page length clamping in hash walk
>    
>    [ Upstream commit 13f4bb78cf6a312bbdec367ba3da044b09bf0e29 ]
>    
>    The crypto hash walk code is broken when supplied with an offset
>    greater than or equal to PAGE_SIZE.  This patch fixes it by adjusting
>    walk->pg and walk->offset when this happens.
>    
>    Cc: <stable@vger.kernel.org>
>    Reported-by: Steffen Klassert <steffen.klassert@secunet.com>
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a10c059ad73b3b84c349592e72d445d9c73a1e27
>Author: Prarit Bhargava <prarit@redhat.com>
>Date:   Wed May 4 13:48:56 2016 +0800
>
>    ACPICA: Dispatcher: Update thread ID for recursive method calls
>    
>    [ Upstream commit 93d68841a23a5779cef6fb9aa0ef32e7c5bd00da ]
>    
>    ACPICA commit 7a3bd2d962f221809f25ddb826c9e551b916eb25
>    
>    Set the mutex owner thread ID.
>    Original patch from: Prarit Bhargava <prarit@redhat.com>
>    
>    Link: https://bugzilla.kernel.org/show_bug.cgi?id=115121
>    Link: https://github.com/acpica/acpica/commit/7a3bd2d9
>    Signed-off-by: Prarit Bhargava <prarit@redhat.com>
>    Tested-by: Andy Lutomirski <luto@kernel.org> # On a Dell XPS 13 9350
>    Signed-off-by: Bob Moore <robert.moore@intel.com>
>    Signed-off-by: Lv Zheng <lv.zheng@intel.com>
>    Cc: All applicable <stable@vger.kernel.org>
>    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d15451da634fffa57e013f7c2a9f7db6c65a9a1e
>Author: Matt Fleming <matt@codeblueprint.co.uk>
>Date:   Tue May 3 20:29:39 2016 +0100
>
>    MAINTAINERS: Remove asterisk from EFI directory names
>    
>    [ Upstream commit e8dfe6d8f6762d515fcd4f30577f7bfcf7659887 ]
>    
>    Mark reported that having asterisks on the end of directory names
>    confuses get_maintainer.pl when it encounters subdirectories, and that
>    my name does not appear when run on drivers/firmware/efi/libstub.
>    
>    Reported-by: Mark Rutland <mark.rutland@arm.com>
>    Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
>    Cc: <stable@vger.kernel.org>
>    Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>    Cc: Catalin Marinas <catalin.marinas@arm.com>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Cc: linux-efi@vger.kernel.org
>    Link: http://lkml.kernel.org/r/1462303781-8686-2-git-send-email-matt@codeblueprint.co.uk
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d102342c3a8e0e791ba934cc3a43b0ed80b28938
>Author: Alex Deucher <alexander.deucher@amd.com>
>Date:   Mon May 2 18:53:27 2016 -0400
>
>    drm/radeon: make sure vertical front porch is at least 1
>    
>    [ Upstream commit 3104b8128d4d646a574ed9d5b17c7d10752cd70b ]
>    
>    hw doesn't like a 0 value.
>    
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3216eb22857e515aa89f594f84c0ef2a36a59b08
>Author: Chunyu Hu <chuhu@redhat.com>
>Date:   Tue May 3 19:34:34 2016 +0800
>
>    tracing: Don't display trigger file for events that can't be enabled
>    
>    [ Upstream commit 854145e0a8e9a05f7366d240e2f99d9c1ca6d6dd ]
>    
>    Currently register functions for events will be called
>    through the 'reg' field of event class directly without
>    any check when seting up triggers.
>    
>    Triggers for events that don't support register through
>    debug fs (events under events/ftrace are for trace-cmd to
>    read event format, and most of them don't have a register
>    function except events/ftrace/functionx) can't be enabled
>    at all, and an oops will be hit when setting up trigger
>    for those events, so just not creating them is an easy way
>    to avoid the oops.
>    
>    Link: http://lkml.kernel.org/r/1462275274-3911-1-git-send-email-chuhu@redhat.com
>    
>    Cc: stable@vger.kernel.org # 3.14+
>    Fixes: 85f2b08268c01 ("tracing: Add basic event trigger framework")
>    Signed-off-by: Chunyu Hu <chuhu@redhat.com>
>    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9abc9e72c77166342589d02fb7c0dcabe78d9358
>Author: Linus Torvalds <torvalds@linux-foundation.org>
>Date:   Mon May 2 12:46:42 2016 -0700
>
>    Minimal fix-up of bad hashing behavior of hash_64()
>    
>    [ Upstream commit 689de1d6ca95b3b5bd8ee446863bf81a4883ea25 ]
>    
>    This is a fairly minimal fixup to the horribly bad behavior of hash_64()
>    with certain input patterns.
>    
>    In particular, because the multiplicative value used for the 64-bit hash
>    was intentionally bit-sparse (so that the multiply could be done with
>    shifts and adds on architectures without hardware multipliers), some
>    bits did not get spread out very much.  In particular, certain fairly
>    common bit ranges in the input (roughly bits 12-20: commonly with the
>    most information in them when you hash things like byte offsets in files
>    or memory that have block factors that mean that the low bits are often
>    zero) would not necessarily show up much in the result.
>    
>    There's a bigger patch-series brewing to fix up things more completely,
>    but this is the fairly minimal fix for the 64-bit hashing problem.  It
>    simply picks a much better constant multiplier, spreading the bits out a
>    lot better.
>    
>    NOTE! For 32-bit architectures, the bad old hash_64() remains the same
>    for now, since 64-bit multiplies are expensive.  The bigger hashing
>    cleanup will replace the 32-bit case with something better.
>    
>    The new constants were picked by George Spelvin who wrote that bigger
>    cleanup series.  I just picked out the constants and part of the comment
>    from that series.
>    
>    Cc: stable@vger.kernel.org
>    Cc: George Spelvin <linux@horizon.com>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 420b214c8f04158d05bf01ea95d00b0f1592966e
>Author: Anton Blanchard <anton@samba.org>
>Date:   Sat Apr 30 08:29:27 2016 +1000
>
>    powerpc: Fix bad inline asm constraint in create_zero_mask()
>    
>    [ Upstream commit b4c112114aab9aff5ed4568ca5e662bb02cdfe74 ]
>    
>    In create_zero_mask() we have:
>    
>    	addi	%1,%2,-1
>    	andc	%1,%1,%2
>    	popcntd	%0,%1
>    
>    using the "r" constraint for %2. r0 is a valid register in the "r" set,
>    but addi X,r0,X turns it into an li:
>    
>    	li	r7,-1
>    	andc	r7,r7,r0
>    	popcntd	r4,r7
>    
>    Fix this by using the "b" constraint, for which r0 is not a valid
>    register.
>    
>    This was found with a kernel build using gcc trunk, narrowed down to
>    when -frename-registers was enabled at -O2. It is just luck however
>    that we aren't seeing this on older toolchains.
>    
>    Thanks to Segher for working with me to find this issue.
>    
>    Cc: stable@vger.kernel.org
>    Fixes: d0cebfa650a0 ("powerpc: word-at-a-time optimization for 64-bit Little Endian")
>    Signed-off-by: Anton Blanchard <anton@samba.org>
>    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c172113994b7feb3f1d7fa92b9e803e31d03a256
>Author: K. Y. Srinivasan <kys@microsoft.com>
>Date:   Sat Apr 2 16:17:38 2016 -0700
>
>    Drivers: hv: vmbus: Fix signaling logic in hv_need_to_signal_on_read()
>    
>    [ Upstream commit 1db488d12894f1936360779d6ab2aede3dd7f06a ]
>    
>    On the consumer side, we have interrupt driven flow management of the
>    producer. It is sufficient to base the signaling decision on the
>    amount of space that is available to write after the read is complete.
>    The current code samples the previous available space and uses this
>    in making the signaling decision. This state can be stale and is
>    unnecessary. Since the state can be stale, we end up not signaling
>    the host (when we should) and this can result in a hang. Fix this
>    problem by removing the unnecessary check. I would like to thank
>    Arseney Romanenko <arseneyr@microsoft.com> for pointing out this issue.
>    
>    Also, issue a full memory barrier before making the signaling descision
>    to correctly deal with potential reordering of the write (read index)
>    followed by the read of pending_sz.
>    
>    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
>    Tested-by: Dexuan Cui <decui@microsoft.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 26ac029f2468a529bf5c9c3a5d9ef7a27376218a
>Author: Christopher Oo <t-chriso@microsoft.com>
>Date:   Wed Aug 5 00:52:40 2015 -0700
>
>    Drivers: hv_vmbus: Fix signal to host condition
>    
>    [ Upstream commit a5cca686ce0ef4909deaee4ed46dd991e3a9ece4 ]
>    
>    Fixes a bug where previously hv_ringbuffer_read would pass in the old
>    number of bytes available to read instead of the expected old read index
>    when calculating when to signal to the host that the ringbuffer is empty.
>    Since the previous write size is already saved, also changes the
>    hv_need_to_signal_on_read to use the previously read value rather than
>    recalculating it.
>    
>    Signed-off-by: Christopher Oo <t-chriso@microsoft.com>
>    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3807acbd300b39054d45460b19067ce7ef8b1ae9
>Author: Vitaly Kuznetsov <vkuznets@redhat.com>
>Date:   Mon Dec 14 19:01:57 2015 -0800
>
>    Drivers: hv: ring_buffer.c: fix comment style
>    
>    [ Upstream commit 822f18d4d3e9d4efb4996bbe562d0f99ab82d7dd ]
>    
>    Convert 6+-string comments repeating function names to normal kernel-style
>    comments and fix a couple of other comment style issues. No textual or
>    functional changes intended.
>    
>    Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9ddd834043f14442b4c40ffc7b86de9e4f5f0ffe
>Author: Al Viro <viro@zeniv.linux.org.uk>
>Date:   Wed Apr 27 01:11:55 2016 -0400
>
>    atomic_open(): fix the handling of create_error
>    
>    [ Upstream commit 10c64cea04d3c75c306b3f990586ffb343b63287 ]
>    
>    * if we have a hashed negative dentry and either CREAT|EXCL on
>    r/o filesystem, or CREAT|TRUNC on r/o filesystem, or CREAT|EXCL
>    with failing may_o_create(), we should fail with EROFS or the
>    error may_o_create() has returned, but not ENOENT.  Which is what
>    the current code ends up returning.
>    
>    * if we have CREAT|TRUNC hitting a regular file on a read-only
>    filesystem, we can't fail with EROFS here.  At the very least,
>    not until we'd done follow_managed() - we might have a writable
>    file (or a device, for that matter) bound on top of that one.
>    Moreover, the code downstream will see that O_TRUNC and attempt
>    to grab the write access (*after* following possible mount), so
>    if we really should fail with EROFS, it will happen.  No need
>    to do that inside atomic_open().
>    
>    The real logics is much simpler than what the current code is
>    trying to do - if we decided to go for simple lookup, ended
>    up with a negative dentry *and* had create_error set, fail with
>    create_error.  No matter whether we'd got that negative dentry
>    from lookup_real() or had found it in dcache.
>    
>    Cc: stable@vger.kernel.org # v3.6+
>    Acked-by: Miklos Szeredi <mszeredi@redhat.com>
>    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit cb4a26d103973231b1a4f6b4c1495f41aaeb9980
>Author: Tony Luck <tony.luck@intel.com>
>Date:   Fri Apr 29 15:42:25 2016 +0200
>
>    EDAC: i7core, sb_edac: Don't return NOTIFY_BAD from mce_decoder callback
>    
>    [ Upstream commit c4fc1956fa31003bfbe4f597e359d751568e2954 ]
>    
>    Both of these drivers can return NOTIFY_BAD, but this terminates
>    processing other callbacks that were registered later on the chain.
>    Since the driver did nothing to log the error it seems wrong to prevent
>    other interested parties from seeing it. E.g. neither of them had even
>    bothered to check the type of the error to see if it was a memory error
>    before the return NOTIFY_BAD.
>    
>    Signed-off-by: Tony Luck <tony.luck@intel.com>
>    Acked-by: Aristeu Rozanski <aris@redhat.com>
>    Acked-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
>    Cc: linux-edac <linux-edac@vger.kernel.org>
>    Cc: <stable@vger.kernel.org>
>    Link: http://lkml.kernel.org/r/72937355dd92318d2630979666063f8a2853495b.1461864507.git.tony.luck@intel.com
>    Signed-off-by: Borislav Petkov <bp@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 74e15f5d4bea6f5035641ed75c2c111a153ee7b2
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Fri Apr 29 11:20:15 2016 +0200
>
>    ALSA: usb-audio: Quirk for yet another Phoenix Audio devices (v2)
>    
>    [ Upstream commit 2d2c038a9999f423e820d89db2b5d7774b67ba49 ]
>    
>    Phoenix Audio MT202pcs (1de7:0114) and MT202exe (1de7:0013) need the
>    same workaround as TMX320 for avoiding the firmware bug.  It fixes the
>    frequent error about the sample rate inquiries and the slow device
>    probe as consequence.
>    
>    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=117321
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9de27bd72b3aba88cf7847e8834cc54745ea3352
>Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
>Date:   Thu Aug 6 15:47:08 2015 -0700
>
>    mm: check __PG_HWPOISON separately from PAGE_FLAGS_CHECK_AT_*
>    
>    [ Upstream commit f4c18e6f7b5bbb5b528b3334115806b0d76f50f9 ]
>    
>    The race condition addressed in commit add05cecef80 ("mm: soft-offline:
>    don't free target page in successful page migration") was not closed
>    completely, because that can happen not only for soft-offline, but also
>    for hard-offline.  Consider that a slab page is about to be freed into
>    buddy pool, and then an uncorrected memory error hits the page just
>    after entering __free_one_page(), then VM_BUG_ON_PAGE(page->flags &
>    PAGE_FLAGS_CHECK_AT_PREP) is triggered, despite the fact that it's not
>    necessary because the data on the affected page is not consumed.
>    
>    To solve it, this patch drops __PG_HWPOISON from page flag checks at
>    allocation/free time.  I think it's justified because __PG_HWPOISON
>    flags is defined to prevent the page from being reused, and setting it
>    outside the page's alloc-free cycle is a designed behavior (not a bug.)
>    
>    For recent months, I was annoyed about BUG_ON when soft-offlined page
>    remains on lru cache list for a while, which is avoided by calling
>    put_page() instead of putback_lru_page() in page migration's success
>    path.  This means that this patch reverts a major change from commit
>    add05cecef80 about the new refcounting rule of soft-offlined pages, so
>    "reuse window" revives.  This will be closed by a subsequent patch.
>    
>    Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
>    Cc: Andi Kleen <andi@firstfloor.org>
>    Cc: Dean Nelson <dnelson@redhat.com>
>    Cc: Tony Luck <tony.luck@intel.com>
>    Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
>    Cc: Hugh Dickins <hughd@google.com>
>    Cc: David Rientjes <rientjes@google.com>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6936c1672176fa8403818ff95cff1f4a972b787d
>Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
>Date:   Wed Jun 24 16:56:50 2015 -0700
>
>    mm: soft-offline: don't free target page in successful page migration
>    
>    [ Upstream commit add05cecef803f3372c5fc1d2a964171872daf9f ]
>    
>    Stress testing showed that soft offline events for a process iterating
>    "mmap-pagefault-munmap" loop can trigger
>    VM_BUG_ON(PAGE_FLAGS_CHECK_AT_PREP) in __free_one_page():
>    
>      Soft offlining page 0x70fe1 at 0x70100008d000
>      Soft offlining page 0x705fb at 0x70300008d000
>      page:ffffea0001c3f840 count:0 mapcount:0 mapping:          (null) index:0x2
>      flags: 0x1fffff80800000(hwpoison)
>      page dumped because: VM_BUG_ON_PAGE(page->flags & ((1 << 25) - 1))
>      ------------[ cut here ]------------
>      kernel BUG at /src/linux-dev/mm/page_alloc.c:585!
>      invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
>      Modules linked in: cfg80211 rfkill crc32c_intel microcode ppdev parport_pc pcspkr serio_raw virtio_balloon parport i2c_piix4 virtio_blk virtio_net ata_generic pata_acpi floppy
>      CPU: 3 PID: 1779 Comm: test_base_madv_ Not tainted 4.0.0-v4.0-150511-1451-00009-g82360a3730e6 #139
>      RIP: free_pcppages_bulk+0x52a/0x6f0
>      Call Trace:
>        drain_pages_zone+0x3d/0x50
>        drain_local_pages+0x1d/0x30
>        on_each_cpu_mask+0x46/0x80
>        drain_all_pages+0x14b/0x1e0
>        soft_offline_page+0x432/0x6e0
>        SyS_madvise+0x73c/0x780
>        system_call_fastpath+0x12/0x17
>      Code: ff 89 45 b4 48 8b 45 c0 48 83 b8 a8 00 00 00 00 0f 85 e3 fb ff ff 0f 1f 00 0f 0b 48 8b 7d 90 48 c7 c6 e8 95 a6 81 e8 e6 32 02 00 <0f> 0b 8b 45 cc 49 89 47 30 41 8b 47 18 83 f8 ff 0f 85 10 ff ff
>      RIP  [<ffffffff811a806a>] free_pcppages_bulk+0x52a/0x6f0
>       RSP <ffff88007a117d28>
>      ---[ end trace 53926436e76d1f35 ]---
>    
>    When soft offline successfully migrates page, the source page is supposed
>    to be freed.  But there is a race condition where a source page looks
>    isolated (i.e.  the refcount is 0 and the PageHWPoison is set) but
>    somewhat linked to pcplist.  Then another soft offline event calls
>    drain_all_pages() and tries to free such hwpoisoned page, which is
>    forbidden.
>    
>    This odd page state seems to happen due to the race between put_page() in
>    putback_lru_page() and __pagevec_lru_add_fn().  But I don't want to play
>    with tweaking drain code as done in commit 9ab3b598d2df "mm: hwpoison:
>    drop lru_add_drain_all() in __soft_offline_page()", or to change page
>    freeing code for this soft offline's purpose.
>    
>    Instead, let's think about the difference between hard offline and soft
>    offline.  There is an interesting difference in how to isolate the in-use
>    page between these, that is, hard offline marks PageHWPoison of the target
>    page at first, and doesn't free it by keeping its refcount 1.  OTOH, soft
>    offline tries to free the target page then marks PageHWPoison.  This
>    difference might be the source of complexity and result in bugs like the
>    above.  So making soft offline isolate with keeping refcount can be a
>    solution for this problem.
>    
>    We can pass to page migration code the "reason" which shows the caller, so
>    let's use this more to avoid calling putback_lru_page() when called from
>    soft offline, which effectively does the isolation for soft offline.  With
>    this change, target pages of soft offline never be reused without changing
>    migratetype, so this patch also removes the related code.
>    
>    Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
>    Cc: Andi Kleen <andi@firstfloor.org>
>    Cc: Tony Luck <tony.luck@intel.com>
>    Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 978d733ff9e591c384d1d43d89087943a78f9605
>Author: Minchan Kim <minchan@kernel.org>
>Date:   Thu Apr 28 16:18:38 2016 -0700
>
>    mm: vmscan: reclaim highmem zone if buffer_heads is over limit
>    
>    [ Upstream commit 7bf52fb891b64b8d61caf0b82060adb9db761aec ]
>    
>    We have been reclaimed highmem zone if buffer_heads is over limit but
>    commit 6b4f7799c6a5 ("mm: vmscan: invoke slab shrinkers from
>    shrink_zone()") changed the behavior so it doesn't reclaim highmem zone
>    although buffer_heads is over the limit.  This patch restores the logic.
>    
>    Fixes: 6b4f7799c6a5 ("mm: vmscan: invoke slab shrinkers from shrink_zone()")
>    Signed-off-by: Minchan Kim <minchan@kernel.org>
>    Cc: Johannes Weiner <hannes@cmpxchg.org>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9684dc001e986b11763b30c7bd71c0091fce28f8
>Author: Konstantin Khlebnikov <koct9i@gmail.com>
>Date:   Thu Apr 28 16:18:32 2016 -0700
>
>    mm/huge_memory: replace VM_NO_THP VM_BUG_ON with actual VMA check
>    
>    [ Upstream commit 3486b85a29c1741db99d0c522211c82d2b7a56d0 ]
>    
>    Khugepaged detects own VMAs by checking vm_file and vm_ops but this way
>    it cannot distinguish private /dev/zero mappings from other special
>    mappings like /dev/hpet which has no vm_ops and popultes PTEs in mmap.
>    
>    This fixes false-positive VM_BUG_ON and prevents installing THP where
>    they are not expected.
>    
>    Link: http://lkml.kernel.org/r/CACT4Y+ZmuZMV5CjSFOeXviwQdABAgT7T+StKfTqan9YDtgEi5g@mail.gmail.com
>    Fixes: 78f11a255749 ("mm: thp: fix /dev/zero MAP_PRIVATE and vm_flags cleanups")
>    Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com>
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Acked-by: Vlastimil Babka <vbabka@suse.cz>
>    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>    Cc: Dmitry Vyukov <dvyukov@google.com>
>    Cc: Andrea Arcangeli <aarcange@redhat.com>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5d43a619be6f1960702daafafe87ceab415be6bc
>Author: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
>Date:   Sun Apr 10 19:13:13 2016 -0600
>
>    IB/security: Restrict use of the write() interface
>    
>    [ Upstream commit e6bd18f57aad1a2d1ef40e646d03ed0f2515c9e3 ]
>    
>    The drivers/infiniband stack uses write() as a replacement for
>    bi-directional ioctl().  This is not safe. There are ways to
>    trigger write calls that result in the return structure that
>    is normally written to user space being shunted off to user
>    specified kernel memory instead.
>    
>    For the immediate repair, detect and deny suspicious accesses to
>    the write API.
>    
>    For long term, update the user space libraries and the kernel API
>    to something that doesn't present the same security vulnerabilities
>    (likely a structured ioctl() interface).
>    
>    The impacted uAPI interfaces are generally only available if
>    hardware from drivers/infiniband is installed in the system.
>    
>    Reported-by: Jann Horn <jann@thejh.net>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
>    [ Expanded check to all known write() entry points ]
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Doug Ledford <dledford@redhat.com>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5e17ef78bfd34f65f83f9fb5054843616ea1d073
>Author: James Morse <james.morse@arm.com>
>Date:   Tue Apr 26 12:15:01 2016 +0100
>
>    ARM: cpuidle: Pass on arm_cpuidle_suspend()'s return value
>    
>    [ Upstream commit 625fe4f8ffc1b915248558481bb94249f6bd411c ]
>    
>    arm_cpuidle_suspend() may return -EOPNOTSUPP, or any value returned
>    by the cpu_ops/cpuidle_ops suspend call. arm_enter_idle_state() doesn't
>    update 'ret' with this value, meaning we always signal success to
>    cpuidle_enter_state(), causing it to update the usage counters as if we
>    succeeded.
>    
>    Fixes: 191de17aa3c1 ("ARM64: cpuidle: Replace cpu_suspend by the common ARM/ARM64 function")
>    Signed-off-by: James Morse <james.morse@arm.com>
>    Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>    Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>    Cc: 4.1+ <stable@vger.kernel.org> # 4.1+
>    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5bde3f2abca17e834c4009d4fdc71e8edb6df8f0
>Author: Sascha Hauer <s.hauer@pengutronix.de>
>Date:   Wed Apr 20 13:34:31 2016 +0000
>
>    ARM: SoCFPGA: Fix secondary CPU startup in thumb2 kernel
>    
>    [ Upstream commit 5616f36713ea77f57ae908bf2fef641364403c9f ]
>    
>    The secondary CPU starts up in ARM mode. When the kernel is compiled in
>    thumb2 mode we have to explicitly compile the secondary startup
>    trampoline in ARM mode, otherwise the CPU will go to Nirvana.
>    
>    Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>    Reported-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
>    Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
>    Signed-off-by: Kevin Hilman <khilman@baylibre.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3b54e5f0a5415a9a8b8618fa61d1303e2ba8add6
>Author: Vitaly Prosyak <vitaly.prosyak@amd.com>
>Date:   Thu Apr 14 13:34:03 2016 -0400
>
>    drm/radeon: fix vertical bars appear on monitor (v2)
>    
>    [ Upstream commit 5d5b7803c49bbb01bdf4c6e95e8314d0515b9484 ]
>    
>    When crtc/timing is disabled on boot the dig block
>    should be stopped in order ignore timing from crtc,
>    reset the steering fifo otherwise we get display
>    corruption or hung in dp sst mode.
>    
>    v2: agd: fix coding style
>    
>    Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 344a144c6f7310bf40dd4a40daa4c0abb994d3c5
>Author: Ville SyrjÃ¤lÃ¤ <ville.syrjala@linux.intel.com>
>Date:   Wed Apr 20 16:43:56 2016 +0300
>
>    drm/i915: Make RPS EI/thresholds multiple of 25 on SNB-BDW
>    
>    [ Upstream commit 4ea3959018d09edfa36a9e7b5ccdbd4ec4b99e49 ]
>    
>    Somehow my SNB GT1 (Dell XPS 8300) gets very unhappy around
>    GPU hangs if the RPS EI/thresholds aren't suitably aligned.
>    It seems like scheduling/timer interupts stop working somehow
>    and things get stuck eg. in usleep_range().
>    
>    I bisected the problem down to
>    commit 8a5864377b12 ("drm/i915/skl: Restructured the gen6_set_rps_thresholds function")
>    I observed that before all the values were at least multiples of 25,
>    but afterwards they are not. And rounding things up to the next multiple
>    of 25 does seem to help, so lets' do that. I also tried roundup(..., 5)
>    but that wasn't sufficient. Also I have no idea if we might need this sort of
>    thing on gen9+ as well.
>    
>    These are the original EI/thresholds:
>     LOW_POWER
>      GEN6_RP_UP_EI          12500
>      GEN6_RP_UP_THRESHOLD   11800
>      GEN6_RP_DOWN_EI        25000
>      GEN6_RP_DOWN_THRESHOLD 21250
>     BETWEEN
>      GEN6_RP_UP_EI          10250
>      GEN6_RP_UP_THRESHOLD    9225
>      GEN6_RP_DOWN_EI        25000
>      GEN6_RP_DOWN_THRESHOLD 18750
>     HIGH_POWER
>      GEN6_RP_UP_EI           8000
>      GEN6_RP_UP_THRESHOLD    6800
>      GEN6_RP_DOWN_EI        25000
>      GEN6_RP_DOWN_THRESHOLD 15000
>    
>    These are after 8a5864377b12:
>     LOW_POWER
>      GEN6_RP_UP_EI          12500
>      GEN6_RP_UP_THRESHOLD   11875
>      GEN6_RP_DOWN_EI        25000
>      GEN6_RP_DOWN_THRESHOLD 21250
>     BETWEEN
>      GEN6_RP_UP_EI          10156
>      GEN6_RP_UP_THRESHOLD    9140
>      GEN6_RP_DOWN_EI        25000
>      GEN6_RP_DOWN_THRESHOLD 18750
>     HIGH_POWER
>      GEN6_RP_UP_EI           7812
>      GEN6_RP_UP_THRESHOLD    6640
>      GEN6_RP_DOWN_EI        25000
>      GEN6_RP_DOWN_THRESHOLD 15000
>    
>    And these are what we have after this patch:
>     LOW_POWER
>      GEN6_RP_UP_EI          12500
>      GEN6_RP_UP_THRESHOLD   11875
>      GEN6_RP_DOWN_EI        25000
>      GEN6_RP_DOWN_THRESHOLD 21250
>     BETWEEN
>      GEN6_RP_UP_EI          10175
>      GEN6_RP_UP_THRESHOLD    9150
>      GEN6_RP_DOWN_EI        25000
>      GEN6_RP_DOWN_THRESHOLD 18750
>     HIGH_POWER
>      GEN6_RP_UP_EI           7825
>      GEN6_RP_UP_THRESHOLD    6650
>      GEN6_RP_DOWN_EI        25000
>      GEN6_RP_DOWN_THRESHOLD 15000
>    
>    Cc: stable@vger.kernel.org
>    Cc: Akash Goel <akash.goel@intel.com>
>    Cc: Chris Wilson <chris@chris-wilson.co.uk>
>    Testcase: igt/kms_pipe_crc_basic/hang-read-crc-pipe-B
>    Fixes: 8a5864377b12 ("drm/i915/skl: Restructured the gen6_set_rps_thresholds function")
>    Signed-off-by: Ville SyrjÃ¤lÃ¤ <ville.syrjala@linux.intel.com>
>    Link: http://patchwork.freedesktop.org/patch/msgid/1461159836-9108-1-git-send-email-ville.syrjala@linux.intel.com
>    Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
>    Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
>    (cherry picked from commit 8a292d016d1cc4938ff14b4df25328230b08a408)
>    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 39161f8ab357bc5e13eca3a04828cb7aecab0f9d
>Author: Imre Deak <imre.deak@intel.com>
>Date:   Mon Apr 18 10:04:21 2016 +0300
>
>    drm/i915/ddi: Fix eDP VDD handling during booting and suspend/resume
>    
>    [ Upstream commit 5eaa60c7109b40f17ac81090bc8b90482da76cd1 ]
>    
>    The driver's VDD on/off logic assumes that whenever the VDD is on we
>    also hold an AUX power domain reference. Since BIOS can leave the VDD on
>    during booting and resuming and on DDI platforms we won't take a
>    corresponding power reference, the above assumption won't hold on those
>    platforms and an eventual delayed VDD off work will do an extraneous AUX
>    power domain put resulting in a refcount underflow. Fix this the same
>    way we did this for non-DDI DP encoders:
>    
>    commit 6d93c0c41760c0 ("drm/i915: fix VDD state tracking after system
>    resume")
>    
>    At the same time call the DP encoder suspend handler the same way as the
>    non-DDI DP encoders do to flush any pending VDD off work. Leaving the
>    work running may cause a HW access where we don't expect this (at a point
>    where power domains are suspended already).
>    
>    While at it remove an unnecessary function call indirection.
>    
>    This fixed for me AUX refcount underflow problems on BXT during
>    suspend/resume.
>    
>    CC: Ville SyrjÃ¤lÃ¤ <ville.syrjala@linux.intel.com>
>    CC: stable@vger.kernel.org
>    Signed-off-by: Imre Deak <imre.deak@intel.com>
>    Reviewed-by: Ville SyrjÃ¤lÃ¤ <ville.syrjala@linux.intel.com>
>    Link: http://patchwork.freedesktop.org/patch/msgid/1460963062-13211-4-git-send-email-imre.deak@intel.com
>    (cherry picked from commit bf93ba67e9c05882f05b7ca2d773cfc8bf462c2a)
>    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 86128809b5bf37d75b6bee83d0e83a32f9a80673
>Author: Michael Neuling <mikey@neuling.org>
>Date:   Fri Apr 22 14:57:48 2016 +1000
>
>    cxl: Keep IRQ mappings on context teardown
>    
>    [ Upstream commit d6776bba44d9752f6cdf640046070e71ee4bba7b ]
>    
>    Keep IRQ mappings on context teardown.  This won't leak IRQs as if we
>    allocate the mapping again, the generic code will give the same
>    mapping used last time.
>    
>    Doing this works around a race in the generic code. Masking the
>    interrupt introduces a race which can crash the kernel or result in
>    IRQ that is never EOIed. The lost of EOI results in all subsequent
>    mappings to the same HW IRQ never receiving an interrupt.
>    
>    We've seen this race with cxl test cases which are doing heavy context
>    startup and teardown at the same time as heavy interrupt load.
>    
>    A fix to the generic code is being investigated also.
>    
>    Signed-off-by: Michael Neuling <mikey@neuling.org>
>    Cc: stable@vger.kernel.org # 3.8
>    Tested-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
>    Acked-by: Ian Munsie <imunsie@au1.ibm.com>
>    Tested-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
>    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b61a5d5456479618426d25bec4175c011bcc9726
>Author: Lyude <cpaul@redhat.com>
>Date:   Wed Apr 13 16:50:18 2016 -0400
>
>    drm/dp/mst: Restore primary hub guid on resume
>    
>    [ Upstream commit 9dc0487d96a0396367a1451b31873482080b527f ]
>    
>    Some hubs are forgetful, and end up forgetting whatever GUID we set
>    previously after we do a suspend/resume cycle. This can lead to
>    hotplugging breaking (along with probably other things) since the hub
>    will start sending connection notifications with the wrong GUID. As
>    such, we need to check on resume whether or not the GUID the hub is
>    giving us is valid.
>    
>    Signed-off-by: Lyude <cpaul@redhat.com>
>    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
>    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>    Link: http://patchwork.freedesktop.org/patch/msgid/1460580618-7421-1-git-send-email-cpaul@redhat.com
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Dave Airlie <airlied@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 85489830a875eee4c5357b2ffa217f06676c1211
>Author: cpaul@redhat.com <cpaul@redhat.com>
>Date:   Fri Apr 22 16:08:46 2016 -0400
>
>    drm/dp/mst: Get validated port ref in drm_dp_update_payload_part1()
>    
>    [ Upstream commit 263efde31f97c498e1ebad30e4d2906609d7ad6b ]
>    
>    We can thank KASAN for finding this, otherwise I probably would have spent
>    hours on it. This fixes a somewhat harder to trigger kernel panic, occuring
>    while enabling MST where the port we were currently updating the payload on
>    would have all of it's refs dropped before we finished what we were doing:
>    
>    ==================================================================
>    BUG: KASAN: use-after-free in drm_dp_update_payload_part1+0xb3f/0xdb0 [drm_kms_helper] at addr ffff8800d29de018
>    Read of size 4 by task Xorg/973
>    =============================================================================
>    BUG kmalloc-2048 (Tainted: G    B   W      ): kasan: bad access detected
>    -----------------------------------------------------------------------------
>    
>    INFO: Allocated in drm_dp_add_port+0x1aa/0x1ed0 [drm_kms_helper] age=16477 cpu=0 pid=2175
>    	___slab_alloc+0x472/0x490
>    	__slab_alloc+0x20/0x40
>    	kmem_cache_alloc_trace+0x151/0x190
>    	drm_dp_add_port+0x1aa/0x1ed0 [drm_kms_helper]
>    	drm_dp_send_link_address+0x526/0x960 [drm_kms_helper]
>    	drm_dp_check_and_send_link_address+0x1ac/0x210 [drm_kms_helper]
>    	drm_dp_mst_link_probe_work+0x77/0xd0 [drm_kms_helper]
>    	process_one_work+0x562/0x1350
>    	worker_thread+0xd9/0x1390
>    	kthread+0x1c5/0x260
>    	ret_from_fork+0x22/0x40
>    INFO: Freed in drm_dp_free_mst_port+0x50/0x60 [drm_kms_helper] age=7521 cpu=0 pid=2175
>    	__slab_free+0x17f/0x2d0
>    	kfree+0x169/0x180
>    	drm_dp_free_mst_port+0x50/0x60 [drm_kms_helper]
>    	drm_dp_destroy_connector_work+0x2b8/0x490 [drm_kms_helper]
>    	process_one_work+0x562/0x1350
>    	worker_thread+0xd9/0x1390
>    	kthread+0x1c5/0x260
>    	ret_from_fork+0x22/0x40
>    
>    which on this T460s, would eventually lead to kernel panics in somewhat
>    random places later in intel_mst_enable_dp() if we got lucky enough.
>    
>    Signed-off-by: Lyude <cpaul@redhat.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Dave Airlie <airlied@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 14794cfb6c9bcca151dbe940f3d7b9f9f818499f
>Author: Roman Pen <roman.penyaev@profitbricks.com>
>Date:   Tue Apr 26 13:15:35 2016 +0200
>
>    workqueue: fix ghost PENDING flag while doing MQ IO
>    
>    [ Upstream commit 346c09f80459a3ad97df1816d6d606169a51001a ]
>    
>    The bug in a workqueue leads to a stalled IO request in MQ ctx->rq_list
>    with the following backtrace:
>    
>    [  601.347452] INFO: task kworker/u129:5:1636 blocked for more than 120 seconds.
>    [  601.347574]       Tainted: G           O    4.4.5-1-storage+ #6
>    [  601.347651] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>    [  601.348142] kworker/u129:5  D ffff880803077988     0  1636      2 0x00000000
>    [  601.348519] Workqueue: ibnbd_server_fileio_wq ibnbd_dev_file_submit_io_worker [ibnbd_server]
>    [  601.348999]  ffff880803077988 ffff88080466b900 ffff8808033f9c80 ffff880803078000
>    [  601.349662]  ffff880807c95000 7fffffffffffffff ffffffff815b0920 ffff880803077ad0
>    [  601.350333]  ffff8808030779a0 ffffffff815b01d5 0000000000000000 ffff880803077a38
>    [  601.350965] Call Trace:
>    [  601.351203]  [<ffffffff815b0920>] ? bit_wait+0x60/0x60
>    [  601.351444]  [<ffffffff815b01d5>] schedule+0x35/0x80
>    [  601.351709]  [<ffffffff815b2dd2>] schedule_timeout+0x192/0x230
>    [  601.351958]  [<ffffffff812d43f7>] ? blk_flush_plug_list+0xc7/0x220
>    [  601.352208]  [<ffffffff810bd737>] ? ktime_get+0x37/0xa0
>    [  601.352446]  [<ffffffff815b0920>] ? bit_wait+0x60/0x60
>    [  601.352688]  [<ffffffff815af784>] io_schedule_timeout+0xa4/0x110
>    [  601.352951]  [<ffffffff815b3a4e>] ? _raw_spin_unlock_irqrestore+0xe/0x10
>    [  601.353196]  [<ffffffff815b093b>] bit_wait_io+0x1b/0x70
>    [  601.353440]  [<ffffffff815b056d>] __wait_on_bit+0x5d/0x90
>    [  601.353689]  [<ffffffff81127bd0>] wait_on_page_bit+0xc0/0xd0
>    [  601.353958]  [<ffffffff81096db0>] ? autoremove_wake_function+0x40/0x40
>    [  601.354200]  [<ffffffff81127cc4>] __filemap_fdatawait_range+0xe4/0x140
>    [  601.354441]  [<ffffffff81127d34>] filemap_fdatawait_range+0x14/0x30
>    [  601.354688]  [<ffffffff81129a9f>] filemap_write_and_wait_range+0x3f/0x70
>    [  601.354932]  [<ffffffff811ced3b>] blkdev_fsync+0x1b/0x50
>    [  601.355193]  [<ffffffff811c82d9>] vfs_fsync_range+0x49/0xa0
>    [  601.355432]  [<ffffffff811cf45a>] blkdev_write_iter+0xca/0x100
>    [  601.355679]  [<ffffffff81197b1a>] __vfs_write+0xaa/0xe0
>    [  601.355925]  [<ffffffff81198379>] vfs_write+0xa9/0x1a0
>    [  601.356164]  [<ffffffff811c59d8>] kernel_write+0x38/0x50
>    
>    The underlying device is a null_blk, with default parameters:
>    
>      queue_mode    = MQ
>      submit_queues = 1
>    
>    Verification that nullb0 has something inflight:
>    
>    root@pserver8:~# cat /sys/block/nullb0/inflight
>           0        1
>    root@pserver8:~# find /sys/block/nullb0/mq/0/cpu* -name rq_list -print -exec cat {} \;
>    ...
>    /sys/block/nullb0/mq/0/cpu2/rq_list
>    CTX pending:
>            ffff8838038e2400
>    ...
>    
>    During debug it became clear that stalled request is always inserted in
>    the rq_list from the following path:
>    
>       save_stack_trace_tsk + 34
>       blk_mq_insert_requests + 231
>       blk_mq_flush_plug_list + 281
>       blk_flush_plug_list + 199
>       wait_on_page_bit + 192
>       __filemap_fdatawait_range + 228
>       filemap_fdatawait_range + 20
>       filemap_write_and_wait_range + 63
>       blkdev_fsync + 27
>       vfs_fsync_range + 73
>       blkdev_write_iter + 202
>       __vfs_write + 170
>       vfs_write + 169
>       kernel_write + 56
>    
>    So blk_flush_plug_list() was called with from_schedule == true.
>    
>    If from_schedule is true, that means that finally blk_mq_insert_requests()
>    offloads execution of __blk_mq_run_hw_queue() and uses kblockd workqueue,
>    i.e. it calls kblockd_schedule_delayed_work_on().
>    
>    That means, that we race with another CPU, which is about to execute
>    __blk_mq_run_hw_queue() work.
>    
>    Further debugging shows the following traces from different CPUs:
>    
>      CPU#0                                  CPU#1
>      ----------------------------------     -------------------------------
>      reqeust A inserted
>      STORE hctx->ctx_map[0] bit marked
>      kblockd_schedule...() returns 1
>      <schedule to kblockd workqueue>
>                                             request B inserted
>                                             STORE hctx->ctx_map[1] bit marked
>                                             kblockd_schedule...() returns 0
>      *** WORK PENDING bit is cleared ***
>      flush_busy_ctxs() is executed, but
>      bit 1, set by CPU#1, is not observed
>    
>    As a result request B pended forever.
>    
>    This behaviour can be explained by speculative LOAD of hctx->ctx_map on
>    CPU#0, which is reordered with clear of PENDING bit and executed _before_
>    actual STORE of bit 1 on CPU#1.
>    
>    The proper fix is an explicit full barrier <mfence>, which guarantees
>    that clear of PENDING bit is to be executed before all possible
>    speculative LOADS or STORES inside actual work function.
>    
>    Signed-off-by: Roman Pen <roman.penyaev@profitbricks.com>
>    Cc: Gioh Kim <gi-oh.kim@profitbricks.com>
>    Cc: Michael Wang <yun.wang@profitbricks.com>
>    Cc: Tejun Heo <tj@kernel.org>
>    Cc: Jens Axboe <axboe@kernel.dk>
>    Cc: linux-block@vger.kernel.org
>    Cc: linux-kernel@vger.kernel.org
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Tejun Heo <tj@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2519c9fc644c0fc14c54518bab9440765e0ea99a
>Author: Conrad Kostecki <ck+linuxkernel@bl4ckb0x.de>
>Date:   Tue Apr 26 10:08:10 2016 +0200
>
>    ALSA: hda - Add dock support for ThinkPad X260
>    
>    [ Upstream commit 037e119738120c1cdc460c6ae33871c3000531f3 ]
>    
>    Fixes audio output on a ThinkPad X260, when using Lenovo CES 2013
>    docking station series (basic, pro, ultra).
>    
>    Signed-off-by: Conrad Kostecki <ck+linuxkernel@bl4ckb0x.de>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit cdfac06ee2d5aabbe89724c6a4a3fbb1148fcc7a
>Author: Shaohua Li <shli@fb.com>
>Date:   Mon Apr 25 16:52:38 2016 -0700
>
>    MD: make bio mergeable
>    
>    [ Upstream commit 9c573de3283af007ea11c17bde1e4568d9417328 ]
>    
>    blk_queue_split marks bio unmergeable, which makes sense for normal bio.
>    But if dispatching the bio to underlayer disk, the blk_queue_split
>    checks are invalid, hence it's possible the bio becomes mergeable.
>    
>    In the reported bug, this bug causes trim against raid0 performance slash
>    https://bugzilla.kernel.org/show_bug.cgi?id=117051
>    
>    Reported-and-tested-by: Park Ju Hyung <qkrwngud825@gmail.com>
>    Fixes: 6ac45aeb6bca(block: avoid to merge splitted bio)
>    Cc: stable@vger.kernel.org (v4.3+)
>    Cc: Ming Lei <ming.lei@canonical.com>
>    Cc: Neil Brown <neilb@suse.de>
>    Reviewed-by: Jens Axboe <axboe@fb.com>
>    Signed-off-by: Shaohua Li <shli@fb.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4f1948989e9af00623bb23d321cae7bd4792002e
>Author: Hans Verkuil <hverkuil@xs4all.nl>
>Date:   Fri Apr 22 04:00:50 2016 -0300
>
>    [media] v4l2-dv-timings.h: fix polarity for 4k formats
>    
>    [ Upstream commit 3020ca711871fdaf0c15c8bab677a6bc302e28fe ]
>    
>    The VSync polarity was negative instead of positive for the 4k CEA formats.
>    I probably copy-and-pasted these from the DMT 4k format, which does have a
>    negative VSync polarity.
>    
>    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
>    Reported-by: Martin Bugge <marbugge@cisco.com>
>    Cc: <stable@vger.kernel.org>      # for v4.1 and up
>    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b4782b68dbabd15982bb417d1e75bdd36c4eefc6
>Author: Jasem Mutlaq <mutlaqja@ikarustech.com>
>Date:   Tue Apr 19 10:38:27 2016 +0300
>
>    USB: serial: cp210x: add Straizona Focusers device ids
>    
>    [ Upstream commit 613ac23a46e10d4d4339febdd534fafadd68e059 ]
>    
>    Adding VID:PID for Straizona Focusers to cp210x driver.
>    
>    Signed-off-by: Jasem Mutlaq <mutlaqja@ikarustech.com>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 35f45c8a07dbc749e3b0602f1d6def24ee8cc657
>Author: Mike Manning <michael@bsch.com.au>
>Date:   Mon Apr 18 12:13:23 2016 +0000
>
>    USB: serial: cp210x: add ID for Link ECU
>    
>    [ Upstream commit 1d377f4d690637a0121eac8701f84a0aa1e69a69 ]
>    
>    The Link ECU is an aftermarket ECU computer for vehicles that provides
>    full tuning abilities as well as datalogging and displaying capabilities
>    via the USB to Serial adapter built into the device.
>    
>    Signed-off-by: Mike Manning <michael@bsch.com.au>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 83619523130164cb525e35b6001755cd185055fb
>Author: Laszlo Ersek <lersek@redhat.com>
>Date:   Thu Apr 21 18:21:11 2016 +0200
>
>    efi: Fix out-of-bounds read in variable_matches()
>    
>    [ Upstream commit 630ba0cc7a6dbafbdee43795617c872b35cde1b4 ]
>    
>    The variable_matches() function can currently read "var_name[len]", for
>    example when:
>    
>     - var_name[0] == 'a',
>     - len == 1
>     - match_name points to the NUL-terminated string "ab".
>    
>    This function is supposed to accept "var_name" inputs that are not
>    NUL-terminated (hence the "len" parameter"). Document the function, and
>    access "var_name[*match]" only if "*match" is smaller than "len".
>    
>    Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
>    Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>    Cc: Peter Jones <pjones@redhat.com>
>    Cc: Matthew Garrett <mjg59@coreos.com>
>    Cc: Jason Andryuk <jandryuk@gmail.com>
>    Cc: Jani Nikula <jani.nikula@linux.intel.com>
>    Cc: <stable@vger.kernel.org> # v3.10+
>    Link: http://thread.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/86906
>    Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e7e16bb686861933ff351e945432bd607fc9fa02
>Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>Date:   Mon Apr 4 14:54:59 2016 +0900
>
>    iio: ak8975: Fix NULL pointer exception on early interrupt
>    
>    [ Upstream commit 07d2390e36ee5b3265e9cc8305f2a106c8721e16 ]
>    
>    In certain probe conditions the interrupt came right after registering
>    the handler causing a NULL pointer exception because of uninitialized
>    waitqueue:
>    
>    $ udevadm trigger
>    i2c-gpio i2c-gpio-1: using pins 143 (SDA) and 144 (SCL)
>    i2c-gpio i2c-gpio-3: using pins 53 (SDA) and 52 (SCL)
>    Unable to handle kernel NULL pointer dereference at virtual address 00000000
>    pgd = e8b38000
>    [00000000] *pgd=00000000
>    Internal error: Oops: 5 [#1] SMP ARM
>    Modules linked in: snd_soc_i2s(+) i2c_gpio(+) snd_soc_idma snd_soc_s3c_dma snd_soc_core snd_pcm_dmaengine snd_pcm snd_timer snd soundcore ac97_bus spi_s3c64xx pwm_samsung dwc2 exynos_adc phy_exynos_usb2 exynosdrm exynos_rng rng_core rtc_s3c
>    CPU: 0 PID: 717 Comm: data-provider-m Not tainted 4.6.0-rc1-next-20160401-00011-g1b8d87473b9e-dirty #101
>    Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>    (...)
>    (__wake_up_common) from [<c0379624>] (__wake_up+0x38/0x4c)
>    (__wake_up) from [<c0a41d30>] (ak8975_irq_handler+0x28/0x30)
>    (ak8975_irq_handler) from [<c0386720>] (handle_irq_event_percpu+0x88/0x140)
>    (handle_irq_event_percpu) from [<c038681c>] (handle_irq_event+0x44/0x68)
>    (handle_irq_event) from [<c0389c40>] (handle_edge_irq+0xf0/0x19c)
>    (handle_edge_irq) from [<c0385e04>] (generic_handle_irq+0x24/0x34)
>    (generic_handle_irq) from [<c05ee360>] (exynos_eint_gpio_irq+0x50/0x68)
>    (exynos_eint_gpio_irq) from [<c0386720>] (handle_irq_event_percpu+0x88/0x140)
>    (handle_irq_event_percpu) from [<c038681c>] (handle_irq_event+0x44/0x68)
>    (handle_irq_event) from [<c0389a70>] (handle_fasteoi_irq+0xb4/0x194)
>    (handle_fasteoi_irq) from [<c0385e04>] (generic_handle_irq+0x24/0x34)
>    (generic_handle_irq) from [<c03860b4>] (__handle_domain_irq+0x5c/0xb4)
>    (__handle_domain_irq) from [<c0301774>] (gic_handle_irq+0x54/0x94)
>    (gic_handle_irq) from [<c030c910>] (__irq_usr+0x50/0x80)
>    
>    The bug was reproduced on exynos4412-trats2 (with a max77693 device also
>    using i2c-gpio) after building max77693 as a module.
>    
>    Cc: <stable@vger.kernel.org>
>    Fixes: 94a6d5cf7caa ("iio:ak8975 Implement data ready interrupt handling")
>    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>    Tested-by: Gregor Boirie <gregor.boirie@parrot.com>
>    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 24a50739c3e4e9947f4f4a28a023c348d7bea042
>Author: Jack Pham <jackp@codeaurora.org>
>Date:   Thu Apr 14 23:37:26 2016 -0700
>
>    regmap: spmi: Fix regmap_spmi_ext_read in multi-byte case
>    
>    [ Upstream commit dec8e8f6e6504aa3496c0f7cc10c756bb0e10f44 ]
>    
>    Specifically for the case of reads that use the Extended Register
>    Read Long command, a multi-byte read operation is broken up into
>    8-byte chunks.  However the call to spmi_ext_register_readl() is
>    incorrectly passing 'val_size', which if greater than 8 will
>    always fail.  The argument should instead be 'len'.
>    
>    Fixes: c9afbb05a9ff ("regmap: spmi: support base and extended register spaces")
>    Signed-off-by: Jack Pham <jackp@codeaurora.org>
>    Signed-off-by: Mark Brown <broonie@kernel.org>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit eab51598c1b3a48f320ea66fe1e0d58b61fa6c70
>Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>Date:   Fri Apr 1 08:52:57 2016 +0100
>
>    ata: ahci-platform: Add ports-implemented DT bindings.
>    
>    [ Upstream commit 17dcc37e3e847bc0e67a5b1ec52471fcc6c18682 ]
>    
>    On some SOCs PORTS_IMPL register value is never programmed by the
>    firmware and left at zero value. Which means that no sata ports are
>    available for software. AHCI driver used to cope up with this by
>    fabricating the port_map if the PORTS_IMPL register is read zero,
>    but recent patch broke this workaround as zero value was valid for
>    NVMe disks.
>    
>    This patch adds ports-implemented DT bindings as workaround for this issue
>    in a way that DT can can override the PORTS_IMPL register in cases where
>    the firmware did not program it already.
>    
>    Fixes: 566d1827df2e ("libata: disable forced PORTS_IMPL for >= AHCI 1.3")
>    Cc: stable@vger.kernel.org # v4.5+
>    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>    Acked-by: Tejun Heo <tj@kernel.org>
>    Reviewed-by: Andy Gross <andy.gross@linaro.org>
>    Signed-off-by: Tejun Heo <tj@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a5d2af4cf04bd0d1a6c1cb178d4673d9ca32a298
>Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>Date:   Fri Apr 1 08:52:56 2016 +0100
>
>    libahci: save port map for forced port map
>    
>    [ Upstream commit 2fd0f46cb1b82587c7ae4a616d69057fb9bd0af7 ]
>    
>    In usecases where force_port_map is used saved_port_map is never set,
>    resulting in not programming the PORTS_IMPL register as part of initial
>    config. This patch fixes this by setting it to port_map even in case
>    where force_port_map is used, making it more inline with other parts of
>    the code.
>    
>    Fixes: 566d1827df2e ("libata: disable forced PORTS_IMPL for >= AHCI 1.3")
>    Cc: stable@vger.kernel.org # v4.5+
>    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>    Acked-by: Tejun Heo <tj@kernel.org>
>    Reviewed-by: Andy Gross <andy.gross@linaro.org>
>    Signed-off-by: Tejun Heo <tj@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e1bab7565919a5eb4765ba26f927a17898177c04
>Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>Date:   Mon Mar 28 13:09:56 2016 +0900
>
>    regulator: s2mps11: Fix invalid selector mask and voltages for buck9
>    
>    [ Upstream commit 3b672623079bb3e5685b8549e514f2dfaa564406 ]
>    
>    The buck9 regulator of S2MPS11 PMIC had incorrect vsel_mask (0xff
>    instead of 0x1f) thus reading entire register as buck9's voltage. This
>    effectively caused regulator core to interpret values as higher voltages
>    than they were and then to set real voltage much lower than intended.
>    
>    The buck9 provides power to other regulators, including LDO13
>    and LDO19 which supply the MMC2 (SD card). On Odroid XU3/XU4 the lower
>    voltage caused SD card detection errors on Odroid XU3/XU4:
>    	mmc1: card never left busy state
>    	mmc1: error -110 whilst initialising SD card
>    
>    During driver probe the regulator core was checking whether initial
>    voltage matches the constraints. With incorrect vsel_mask of 0xff and
>    default value of 0x50, the core interpreted this as 5 V which is outside
>    of constraints (3-3.775 V). Then the regulator core was adjusting the
>    voltage to match the constraints. With incorrect vsel_mask this new
>    voltage mapped to a vere low voltage in the driver.
>    
>    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>    Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
>    Tested-by: Javier Martinez Canillas <javier@osg.samsung.com>
>    Signed-off-by: Mark Brown <broonie@kernel.org>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 35d3478878eae689a9934dda6fc6f1cd55262bfd
>Author: Sugar Zhang <sugar.zhang@rock-chips.com>
>Date:   Fri Mar 18 14:54:22 2016 +0800
>
>    ASoC: rt5640: Correct the digital interface data select
>    
>    [ Upstream commit 653aa4645244042826f105aab1be3d01b3d493ca ]
>    
>    this patch corrects the interface adc/dac control register definition
>    according to datasheet.
>    
>    Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
>    Signed-off-by: Mark Brown <broonie@kernel.org>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 81aa039171d2efee11a93714385d8d35c5ce7665
>Author: Sasha Levin <sasha.levin@oracle.com>
>Date:   Thu May 12 22:08:02 2016 -0400
>
>    iwlwifi: pcie: lower the debug level for RSA semaphore access
>    
>    [ Upstream commit 9fc515bc9e735c10cd327f05c20f5ef69474188d ]
>    
>    IWL_INFO is not an error but still printed by default.
>    "can't access the RSA semaphore it is write protected" seems
>    worrisome but it is not really a problem.
>    
>    CC: <stable@vger.kernel.org> [4.1+]
>    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 686b2f5895f1ae7b5891e5cba3ad78e6f3346e64
>Author: Sasha Levin <sasha.levin@oracle.com>
>Date:   Thu May 12 22:04:35 2016 -0400
>
>    stable: remove artifact created on backport
>    
>    I have erroneously created a copy of said file when backporting
>    a commit back to the tree, and have ended up commiting it.
>    
>    Remove it from the tree.
>    
>    Reported-by: Jens Rottmann <Jens.Rottmann@adlinktech.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f94e3630d7cf37e59d9c8772e38d4d73fa59e59e
>Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>Date:   Sat Feb 20 14:19:34 2016 -0800
>
>    Revert "usb: hub: do not clear BOS field during reset device"
>    
>    This reverts commit 522dc09ca0451d118795e8a05c7b3717f3d1ad8b..
>    
>    Tony writes:
>    
>    This upstream commit is causing an oops:
>    d8f00cd685f5 ("usb: hub: do not clear BOS field during reset device")
>    
>    This patch has already been included in several -stable kernels.  Here
>    are the affected kernels:
>    4.5.0-rc4 (current git)
>    4.4.2
>    4.3.6 (currently in review)
>    4.1.18
>    3.18.27
>    3.14.61
>    
>    How to reproduce the problem:
>    Boot kernel with slub debugging enabled (otherwise memory corruption
>    will cause random oopses later instead of immediately)
>    Plug in USB 3.0 disk to xhci USB 3.0 port
>    dd if=/dev/sdc of=/dev/null bs=65536
>    (where /dev/sdc is the USB 3.0 disk)
>    Unplug USB cable while dd is still going
>    Oops is immediate:
>    
>    Reported-by: Tony Battersby <tonyb@cybernetics.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 648d744eff1aedea4ffe49dfca07aa465669e1f4
>Author: Sasha Levin <sasha.levin@oracle.com>
>Date:   Wed May 11 00:10:35 2016 -0400
>
>    Linux 4.1.24
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8e8ad4a07714556769f0bc5496b69c63b0fc902d
>Author: Tony Luck <tony.luck@intel.com>
>Date:   Thu Apr 14 10:21:52 2016 -0700
>
>    x86 EDAC, sb_edac.c: Repair damage introduced when "fixing" channel address
>    
>    [ Upstream commit ff15e95c82768d589957dbb17d7eb7dba7904659 ]
>    
>    In commit:
>    
>      eb1af3b71f9d ("Fix computation of channel address")
>    
>    I switched the "sck_way" variable from holding the log2 value read
>    from the h/w to instead be the actual number. Unfortunately it
>    is needed in log2 form when used to shift the address.
>    
>    Tested-by: Patrick Geary <patrickg@supermicro.com>
>    Signed-off-by: Tony Luck <tony.luck@intel.com>
>    Acked-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
>    Cc: Aristeu Rozanski <arozansk@redhat.com>
>    Cc: Borislav Petkov <bp@alien8.de>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Cc: linux-edac@vger.kernel.org
>    Cc: stable@vger.kernel.org
>    Fixes: eb1af3b71f9d ("Fix computation of channel address")
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 936d0871135e41fba0dc15095319ca106f55a584
>Author: Jan Beulich <JBeulich@suse.com>
>Date:   Thu Apr 21 00:27:04 2016 -0600
>
>    x86/mm/xen: Suppress hugetlbfs in PV guests
>    
>    [ Upstream commit 103f6112f253017d7062cd74d17f4a514ed4485c ]
>    
>    Huge pages are not normally available to PV guests. Not suppressing
>    hugetlbfs use results in an endless loop of page faults when user mode
>    code tries to access a hugetlbfs mapped area (since the hypervisor
>    denies such PTEs to be created, but error indications can't be
>    propagated out of xen_set_pte_at(), just like for various of its
>    siblings), and - once killed in an oops like this:
>    
>      kernel BUG at .../fs/hugetlbfs/inode.c:428!
>      invalid opcode: 0000 [#1] SMP
>      ...
>      RIP: e030:[<ffffffff811c333b>]  [<ffffffff811c333b>] remove_inode_hugepages+0x25b/0x320
>      ...
>      Call Trace:
>       [<ffffffff811c3415>] hugetlbfs_evict_inode+0x15/0x40
>       [<ffffffff81167b3d>] evict+0xbd/0x1b0
>       [<ffffffff8116514a>] __dentry_kill+0x19a/0x1f0
>       [<ffffffff81165b0e>] dput+0x1fe/0x220
>       [<ffffffff81150535>] __fput+0x155/0x200
>       [<ffffffff81079fc0>] task_work_run+0x60/0xa0
>       [<ffffffff81063510>] do_exit+0x160/0x400
>       [<ffffffff810637eb>] do_group_exit+0x3b/0xa0
>       [<ffffffff8106e8bd>] get_signal+0x1ed/0x470
>       [<ffffffff8100f854>] do_signal+0x14/0x110
>       [<ffffffff810030e9>] prepare_exit_to_usermode+0xe9/0xf0
>       [<ffffffff814178a5>] retint_user+0x8/0x13
>    
>    This is CVE-2016-3961 / XSA-174.
>    
>    Reported-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>    Signed-off-by: Jan Beulich <jbeulich@suse.com>
>    Cc: Andrew Morton <akpm@linux-foundation.org>
>    Cc: Andy Lutomirski <luto@amacapital.net>
>    Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>    Cc: Borislav Petkov <bp@alien8.de>
>    Cc: Brian Gerst <brgerst@gmail.com>
>    Cc: David Vrabel <david.vrabel@citrix.com>
>    Cc: Denys Vlasenko <dvlasenk@redhat.com>
>    Cc: H. Peter Anvin <hpa@zytor.com>
>    Cc: Juergen Gross <JGross@suse.com>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Luis R. Rodriguez <mcgrof@suse.com>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Cc: Toshi Kani <toshi.kani@hp.com>
>    Cc: stable@vger.kernel.org
>    Cc: xen-devel <xen-devel@lists.xenproject.org>
>    Link: http://lkml.kernel.org/r/57188ED802000078000E431C@prv-mh.provo.novell.com
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5a1b27489677535af7cf2ef082d0521f32fa145b
>Author: Dominik Dingel <dingel@linux.vnet.ibm.com>
>Date:   Fri Jul 17 16:23:39 2015 -0700
>
>    s390/hugetlb: add hugepages_supported define
>    
>    [ Upstream commit 7f9be77555bb2e52de84e9dddf7b4eb20cc6e171 ]
>    
>    On s390 we only can enable hugepages if the underlying hardware/hypervisor
>    also does support this.  Common code now would assume this to be
>    signaled by setting HPAGE_SHIFT to 0.  But on s390, where we only
>    support one hugepage size, there is a link between HPAGE_SHIFT and
>    pageblock_order.
>    
>    So instead of setting HPAGE_SHIFT to 0, we will implement the check for
>    the hardware capability.
>    
>    Signed-off-by: Dominik Dingel <dingel@linux.vnet.ibm.com>
>    Acked-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
>    Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
>    Cc: Christian Borntraeger <borntraeger@de.ibm.com>
>    Cc: Michael Holzheu <holzheu@linux.vnet.ibm.com>
>    Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ec8d85066c3a598ba747f578232d3dc89b33fa13
>Author: Dominik Dingel <dingel@linux.vnet.ibm.com>
>Date:   Fri Jul 17 16:23:37 2015 -0700
>
>    mm: hugetlb: allow hugepages_supported to be architecture specific
>    
>    [ Upstream commit 2531c8cf56a640cd7d17057df8484e570716a450 ]
>    
>    s390 has a constant hugepage size, by setting HPAGE_SHIFT we also change
>    e.g. the pageblock_order, which should be independent in respect to
>    hugepage support.
>    
>    With this patch every architecture is free to define how to check
>    for hugepage support.
>    
>    Signed-off-by: Dominik Dingel <dingel@linux.vnet.ibm.com>
>    Acked-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
>    Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
>    Cc: Christian Borntraeger <borntraeger@de.ibm.com>
>    Cc: Michael Holzheu <holzheu@linux.vnet.ibm.com>
>    Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b9a11c92d2060b6bafa8babb890d9e711e8b0f5e
>Author: Huacai Chen <chenhc@lemote.com>
>Date:   Tue Apr 19 19:19:11 2016 +0800
>
>    drm: Loongson-3 doesn't fully support wc memory
>    
>    [ Upstream commit 221004c66a58949a0f25c937a6789c0839feb530 ]
>    
>    Signed-off-by: Huacai Chen <chenhc@lemote.com>
>    Cc: stable@vger.kernel.org
>    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>    Signed-off-by: Dave Airlie <airlied@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2719d3c05d4c93054e7c5838cc5b1906f72b465e
>Author: JÃ©rÃ´me Glisse <jglisse@redhat.com>
>Date:   Tue Apr 19 09:07:50 2016 -0400
>
>    drm/radeon: forbid mapping of userptr bo through radeon device file
>    
>    [ Upstream commit b5dcec693f87cb8475f2291c0075b2422addd3d6 ]
>    
>    Allowing userptr bo which are basicly a list of page from some vma
>    (so either anonymous page or file backed page) would lead to serious
>    corruption of kernel structures and counters (because we overwrite
>    the page->mapping field when mapping buffer).
>    
>    This will already block if the buffer was populated before anyone does
>    try to mmap it because then TTM_PAGE_FLAG_SG would be set in in the
>    ttm_tt flags. But that flag is check before ttm_tt_populate in the ttm
>    vm fault handler.
>    
>    So to be safe just add a check to verify_access() callback.
>    
>    Reviewed-by: Christian KÃ¶nig <christian.koenig@amd.com>
>    Signed-off-by: JÃ©rÃ´me Glisse <jglisse@redhat.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8361444613b869bd65386042f5c217469adb0952
>Author: cpaul@redhat.com <cpaul@redhat.com>
>Date:   Mon Apr 4 19:58:47 2016 -0400
>
>    drm/dp/mst: Validate port in drm_dp_payload_send_msg()
>    
>    [ Upstream commit deba0a2af9592b2022a0bce7b085a318b53ce1db ]
>    
>    With the joys of things running concurrently, there's always a chance
>    that the port we get passed in drm_dp_payload_send_msg() isn't actually
>    valid anymore. Because of this, we need to make sure we validate the
>    reference to the port before we use it otherwise we risk running into
>    various race conditions. For instance, on the Dell MST monitor I have
>    here for testing, hotplugging it enough times causes us to kernel panic:
>    
>    [drm:intel_mst_enable_dp] 1
>    [drm:drm_dp_update_payload_part2] payload 0 1
>    [drm:intel_get_hpd_pins] hotplug event received, stat 0x00200000, dig 0x10101011, pins 0x00000020
>    [drm:intel_hpd_irq_handler] digital hpd port B - short
>    [drm:intel_dp_hpd_pulse] got hpd irq on port B - short
>    [drm:intel_dp_check_mst_status] got esi 00 10 00
>    [drm:drm_dp_update_payload_part2] payload 1 1
>    general protection fault: 0000 [#1] SMP
>    â¦
>    Call Trace:
>     [<ffffffffa012b632>] drm_dp_update_payload_part2+0xc2/0x130 [drm_kms_helper]
>     [<ffffffffa032ef08>] intel_mst_enable_dp+0xf8/0x180 [i915]
>     [<ffffffffa0310dbd>] haswell_crtc_enable+0x3ed/0x8c0 [i915]
>     [<ffffffffa030c84d>] intel_atomic_commit+0x5ad/0x1590 [i915]
>     [<ffffffffa01db877>] ? drm_atomic_set_crtc_for_connector+0x57/0xe0 [drm]
>     [<ffffffffa01dc4e7>] drm_atomic_commit+0x37/0x60 [drm]
>     [<ffffffffa0130a3a>] drm_atomic_helper_set_config+0x7a/0xb0 [drm_kms_helper]
>     [<ffffffffa01cc482>] drm_mode_set_config_internal+0x62/0x100 [drm]
>     [<ffffffffa01d02ad>] drm_mode_setcrtc+0x3cd/0x4e0 [drm]
>     [<ffffffffa01c18e3>] drm_ioctl+0x143/0x510 [drm]
>     [<ffffffffa01cfee0>] ? drm_mode_setplane+0x1b0/0x1b0 [drm]
>     [<ffffffff810f79a7>] ? hrtimer_start_range_ns+0x1b7/0x3a0
>     [<ffffffff81212962>] do_vfs_ioctl+0x92/0x570
>     [<ffffffff81590852>] ? __sys_recvmsg+0x42/0x80
>     [<ffffffff81212eb9>] SyS_ioctl+0x79/0x90
>     [<ffffffff816b4e32>] entry_SYSCALL_64_fastpath+0x1a/0xa4
>    RIP  [<ffffffffa012b026>] drm_dp_payload_send_msg+0x146/0x1f0 [drm_kms_helper]
>    
>    Which occurs because of the hotplug event shown in the log, which ends
>    up causing DRM's dp helpers to drop the port we're updating the payload
>    on and panic.
>    
>    CC: stable@vger.kernel.org
>    Signed-off-by: Lyude <cpaul@redhat.com>
>    Reviewed-by: David Airlie <airlied@linux.ie>
>    Signed-off-by: Dave Airlie <airlied@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit faaa136bc7a4ed96ffe9585b495ec8bfac0032a8
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Thu Apr 21 17:37:54 2016 +0200
>
>    ALSA: pcxhr: Fix missing mutex unlock
>    
>    [ Upstream commit 67f3754b51f22b18c4820fb84062f658c30e8644 ]
>    
>    The commit [9bef72bdb26e: ALSA: pcxhr: Use nonatomic PCM ops]
>    converted to non-atomic PCM ops, but shamelessly with an unbalanced
>    mutex locking, which leads to the hangup easily.  Fix it.
>    
>    Fixes: 9bef72bdb26e ('ALSA: pcxhr: Use nonatomic PCM ops')
>    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116441
>    Cc: <stable@vger.kernel.org> # 3.18+
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 28f83d2daecd97392c9a0580c00853a19a76a8bc
>Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>Date:   Fri Apr 15 14:35:39 2016 +0200
>
>    futex: Handle unlock_pi race gracefully
>    
>    [ Upstream commit 89e9e66ba1b3bde9d8ea90566c2aee20697ad681 ]
>    
>    If userspace calls UNLOCK_PI unconditionally without trying the TID -> 0
>    transition in user space first then the user space value might not have the
>    waiters bit set. This opens the following race:
>    
>    CPU0	    	      	    CPU1
>    uval = get_user(futex)
>    			    lock(hb)
>    lock(hb)
>    			    futex |= FUTEX_WAITERS
>    			    ....
>    			    unlock(hb)
>    
>    cmpxchg(futex, uval, newval)
>    
>    So the cmpxchg fails and returns -EINVAL to user space, which is wrong because
>    the futex value is valid.
>    
>    To handle this (yes, yet another) corner case gracefully, check for a flag
>    change and retry.
>    
>    [ tglx: Massaged changelog and slightly reworked implementation ]
>    
>    Fixes: ccf9e6a80d9e ("futex: Make unlock_pi more robust")
>    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>    Cc: stable@vger.kernel.org
>    Cc: Davidlohr Bueso <dave@stgolabs.net>
>    Cc: Darren Hart <dvhart@linux.intel.com>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Link: http://lkml.kernel.org/r/1460723739-5195-1-git-send-email-bigeasy@linutronix.de
>    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6024877a19556baa28a422ff555c1e1e6058504d
>Author: Lu, Han <han.lu@intel.com>
>Date:   Wed Apr 20 10:08:43 2016 +0800
>
>    ALSA: hda - add PCI ID for Intel Broxton-T
>    
>    [ Upstream commit 9859a971ca228725425238756ee89c6133306ec8 ]
>    
>    Add HD Audio Device PCI ID for the Intel Broxton-T platform.
>    It is an HDA Intel PCH controller.
>    
>    Signed-off-by: Lu, Han <han.lu@intel.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c58ef7831aa0ce786fe5cdaba579bc989ae7da6a
>Author: Lu, Han <han.lu@intel.com>
>Date:   Thu Nov 19 23:25:12 2015 +0800
>
>    ALSA: hda - add PCI IDs for Intel Broxton
>    
>    [ Upstream commit c87693da69f979f8a4370e7bc6115dd0898d8501 ]
>    
>    Add HD Audio Device PCI ID for the Intel Broxton platform.
>    It is an HDA Intel PCH controller.
>    
>    Signed-off-by: Lu, Han <han.lu@intel.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0763ce11708553fc7b2124f184ce2e4bb0cb186d
>Author: Lars-Peter Clausen <lars@metafoo.de>
>Date:   Thu Apr 14 17:01:17 2016 +0200
>
>    usb: gadget: f_fs: Fix use-after-free
>    
>    [ Upstream commit 38740a5b87d53ceb89eb2c970150f6e94e00373a ]
>    
>    When using asynchronous read or write operations on the USB endpoints the
>    issuer of the IO request is notified by calling the ki_complete() callback
>    of the submitted kiocb when the URB has been completed.
>    
>    Calling this ki_complete() callback will free kiocb. Make sure that the
>    structure is no longer accessed beyond that point, otherwise undefined
>    behaviour might occur.
>    
>    Fixes: 2e4c7553cd6f ("usb: gadget: f_fs: add aio support")
>    Cc: <stable@vger.kernel.org> # v3.15+
>    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
>    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 18e7c4b1a1b62cacc92e2373a14db6d1d177712a
>Author: Alex Deucher <alexander.deucher@amd.com>
>Date:   Mon Apr 18 11:19:19 2016 -0400
>
>    Revert "drm/radeon: disable runtime pm on PX laptops without dGPU power control"
>    
>    [ Upstream commit bfaddd9fc8ac048b99475f000dbef6f08297417f ]
>    
>    This reverts commit e64c952efb8e0c15ae82cec8e455ab4910690ef1.
>    
>    ATPX is the ACPI method for controlling AMD PowerXpress laptops.
>    There are flags to indicate which methods are supported.  If
>    the dGPU power down flag is not supported, the driver needs to
>    implement the dGPU power down manually.  We had previously
>    always forced the driver to assume the ATPX dGPU power down
>    was present, but this causes problems on boards where it is
>    not, leading to GPU hangs when attempting to power down the
>    dGPU.  Manual dGPU power down is not currently supported in
>    the Linux driver.  Some laptops indicate that the ATPX
>    dGPU power down method is not present, but it actually
>    apparently is.  I'm not sure if this is a bios bug and it should
>    be set or if there is a reason it was unset and the method should
>    not be used.  This is not an issue on other OSes since both the
>    ATPX and the manual driver power down methods are supported.
>    
>    This is apparently fairly widespread, so just revert for now.
>    
>    bugs:
>    https://bugzilla.kernel.org/show_bug.cgi?id=115321
>    https://bugzilla.kernel.org/show_bug.cgi?id=116581
>    https://bugzilla.kernel.org/show_bug.cgi?id=116251
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 13865e4edd08ca07a9ba83c7dee081585ba13f3c
>Author: Alex Deucher <alexander.deucher@amd.com>
>Date:   Thu Apr 14 14:15:16 2016 -0400
>
>    drm/radeon: add a quirk for a XFX R9 270X
>    
>    [ Upstream commit bcb31eba4a4ea356fd61cbd5dec5511c3883f57e ]
>    
>    bug:
>    https://bugs.freedesktop.org/show_bug.cgi?id=76490
>    
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9df249b47f59ba60b2e92a83ad75666e8e8bc4a2
>Author: Alex Deucher <alexander.deucher@amd.com>
>Date:   Mon Mar 28 10:16:40 2016 -0400
>
>    drm/radeon: add another R7 370 quirk
>    
>    [ Upstream commit a64663d9870364bd2a2df62bf0d3a9fbe5ea62a8 ]
>    
>    bug:
>    https://bugzilla.kernel.org/show_bug.cgi?id=115291
>    
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e388075f63d81be966dc967dc0e0332531f91b82
>Author: Alex Deucher <alexander.deucher@amd.com>
>Date:   Fri Oct 2 16:12:07 2015 -0400
>
>    drm/radeon: add quirk for ASUS R7 370
>    
>    [ Upstream commit 2b02ec79004388a8c65e227bc289ed891b5ac8c6 ]
>    
>    Bug:
>    https://bugs.freedesktop.org/show_bug.cgi?id=92260
>    
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 95a5fa7da14d5296105307dba58a84d47f6ce7df
>Author: Maxim Sheviakov <mrader3940@yandex.ru>
>Date:   Wed Sep 23 17:10:51 2015 -0400
>
>    drm/radeon: add quirk for MSI R7 370
>    
>    [ Upstream commit e78654799135a788a941bacad3452fbd7083e518 ]
>    
>    Just adds the quirk for MSI R7 370 Armor 2X
>    Bug:
>    https://bugs.freedesktop.org/show_bug.cgi?id=91294
>    
>    Signed-off-by: Maxim Sheviakov <mrader3940@yandex.ru>
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 90a6cf66d1112f32e4669dd99b7d0c8b6af23d01
>Author: Anton Blanchard <anton@samba.org>
>Date:   Fri Apr 15 12:07:24 2016 +1000
>
>    powerpc: Update cpu_user_features2 in scan_features()
>    
>    [ Upstream commit beff82374b259d726e2625ec6c518a5f2613f0ae ]
>    
>    scan_features() updates cpu_user_features but not cpu_user_features2.
>    
>    Amongst other things, cpu_user_features2 contains the user TM feature
>    bits which we must keep in sync with the kernel TM feature bit.
>    
>    Signed-off-by: Anton Blanchard <anton@samba.org>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 85f0cb09c6458014e7bb168bc764675a06dc4dca
>Author: Anton Blanchard <anton@samba.org>
>Date:   Fri Apr 15 12:06:13 2016 +1000
>
>    powerpc: scan_features() updates incorrect bits for REAL_LE
>    
>    [ Upstream commit 6997e57d693b07289694239e52a10d2f02c3a46f ]
>    
>    The REAL_LE feature entry in the ibm_pa_feature struct is missing an MMU
>    feature value, meaning all the remaining elements initialise the wrong
>    values.
>    
>    This means instead of checking for byte 5, bit 0, we check for byte 0,
>    bit 0, and then we incorrectly set the CPU feature bit as well as MMU
>    feature bit 1 and CPU user feature bits 0 and 2 (5).
>    
>    Checking byte 0 bit 0 (IBM numbering), means we're looking at the
>    "Memory Management Unit (MMU)" feature - ie. does the CPU have an MMU.
>    In practice that bit is set on all platforms which have the property.
>    
>    This means we set CPU_FTR_REAL_LE always. In practice that seems not to
>    matter because all the modern cpus which have this property also
>    implement REAL_LE, and we've never needed to disable it.
>    
>    We're also incorrectly setting MMU feature bit 1, which is:
>    
>      #define MMU_FTR_TYPE_8xx		0x00000002
>    
>    Luckily the only place that looks for MMU_FTR_TYPE_8xx is in Book3E
>    code, which can't run on the same cpus as scan_features(). So this also
>    doesn't matter in practice.
>    
>    Finally in the CPU user feature mask, we're setting bits 0 and 2. Bit 2
>    is not currently used, and bit 0 is:
>    
>      #define PPC_FEATURE_PPC_LE		0x00000001
>    
>    Which says the CPU supports the old style "PPC Little Endian" mode.
>    Again this should be harmless in practice as no 64-bit CPUs implement
>    that mode.
>    
>    Fix the code by adding the missing initialisation of the MMU feature.
>    
>    Also add a comment marking CPU user feature bit 2 (0x4) as reserved. It
>    would be unsafe to start using it as old kernels incorrectly set it.
>    
>    Fixes: 44ae3ab3358e ("powerpc: Free up some CPU feature bits by moving out MMU-related features")
>    Signed-off-by: Anton Blanchard <anton@samba.org>
>    Cc: stable@vger.kernel.org
>    [mpe: Flesh out changelog, add comment reserving 0x4]
>    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 38cadeda33b8bcbd3fa92870179cef3f39dff9a1
>Author: Bastien Nocera <hadess@hadess.net>
>Date:   Mon Apr 18 11:10:42 2016 +0200
>
>    ALSA: hda/realtek - Add ALC3234 headset mode for Optiplex 9020m
>    
>    [ Upstream commit afecb146d8d8a60a1dde9cdf570c278649617fde ]
>    
>    The Optiplex 9020m with Haswell-DT processor needs a quirk for the
>    headset jack at the front of the machine to be able to use microphones.
>    
>    A quirk for this model was originally added in 3127899, but c77900e
>    removed it in favour of a more generic version.
>    
>    Unfortunately, pin configurations can changed based on firmware/BIOS
>    versions, and the generic version doesn't have any effect on newer
>    versions of the machine/firmware anymore.
>    
>    With help from David Henningsson <diwic@ubuntu.com>
>    
>    Signed-off-by: Bastien Nocera <hadess@hadess.net>
>    Tested-by: Bastien Nocera <hadess@hadess.net>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b34e6a486eb70ba92192c877b2904ede0a792679
>Author: Ville SyrjÃ¤lÃ¤ <ville.syrjala@linux.intel.com>
>Date:   Thu Apr 14 14:39:02 2016 +0300
>
>    drm/i915: Use fw_domains_put_with_fifo() on HSW
>    
>    [ Upstream commit 31318a922395ec9e78d6e2ddf70779355afc7594 ]
>    
>    HSW still has the wake FIFO, so let's check it.
>    
>    Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
>    Cc: Deepak S <deepak.s@linux.intel.com>
>    Fixes: 05a2fb157e44 ("drm/i915: Consolidate forcewake code")
>    Signed-off-by: Ville SyrjÃ¤lÃ¤ <ville.syrjala@linux.intel.com>
>    Link: http://patchwork.freedesktop.org/patch/msgid/1460633942-24013-1-git-send-email-ville.syrjala@linux.intel.com
>    Cc: stable@vger.kernel.org
>    Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
>    (cherry picked from commit 3d7d0c85e41afb5a05e98b3a8a72c38357f02594)
>    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3fa5e41c8667e3856ba3191b7156157b8f8aaf1c
>Author: Tom Lendacky <thomas.lendacky@amd.com>
>Date:   Wed Apr 13 10:52:25 2016 -0500
>
>    crypto: ccp - Prevent information leakage on export
>    
>    [ Upstream commit f709b45ec461b548c41a00044dba1f1b572783bf ]
>    
>    Prevent information from leaking to userspace by doing a memset to 0 of
>    the export state structure before setting the structure values and copying
>    it. This prevents un-initialized padding areas from being copied into the
>    export area.
>    
>    Cc: <stable@vger.kernel.org> # 3.14.x-
>    Reported-by: Ben Hutchings <ben@decadent.org.uk>
>    Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f6a93797957220ead95f575047f43e1d4d085205
>Author: Xiaodong Liu <xiaodong.liu@intel.com>
>Date:   Tue Apr 12 09:45:51 2016 +0000
>
>    crypto: sha1-mb - use corrcet pointer while completing jobs
>    
>    [ Upstream commit 0851561d9c965df086ef8a53f981f5f95a57c2c8 ]
>    
>    In sha_complete_job, incorrect mcryptd_hash_request_ctx pointer is used
>    when check and complete other jobs. If the memory of first completed req
>    is freed, while still completing other jobs in the func, kernel will
>    crash since NULL pointer is assigned to RIP.
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Xiaodong Liu <xiaodong.liu@intel.com>
>    Acked-by: Tim Chen <tim.c.chen@linux.intel.com>
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 56c61a30de3ff2b2327a3f4333a81ddfe3e42516
>Author: Yingjoe Chen <yingjoe.chen@mediatek.com>
>Date:   Sat Apr 2 14:57:49 2016 +0800
>
>    pinctrl: mediatek: correct debounce time unit in mtk_gpio_set_debounce
>    
>    [ Upstream commit 5fedbb923936174ab4d1d5cc92bca1cf6b2e0ca2 ]
>    
>    The debounce time unit for gpio_chip.set_debounce is us but
>    mtk_gpio_set_debounce regard it as ms.
>    Fix this by correct debounce time array dbnc_arr so it can find correct
>    debounce setting. Debounce time for first debounce setting is 500us,
>    correct this as well.
>    
>    While I'm at it, also change the debounce time array name to
>    "debounce_time" for readability.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Yingjoe Chen <yingjoe.chen@mediatek.com>
>    Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
>    Acked-by: Hongzhou Yang <hongzhou.yang@mediatek.com>
>    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6e39cdfc828fc5938e9d4e99f446930009ac35f2
>Author: Alex Deucher <alexander.deucher@amd.com>
>Date:   Wed Apr 13 12:08:27 2016 -0400
>
>    drm/radeon: fix initial connector audio value
>    
>    [ Upstream commit 7403c515c49c033fec33df0814fffdc977e6acdc ]
>    
>    This got lost somewhere along the way.  This fixes
>    audio not working until set_property was called.
>    
>    Noticed-by: Hyungwon Hwang <hyungwon.hwang7@gmail.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2c8c83f64c0fb9764b486f14a08f2e3e51bcbc40
>Author: Dmitry Ivanov <dmitrijs.ivanovs@ubnt.com>
>Date:   Wed Apr 6 17:23:18 2016 +0300
>
>    nl80211: check netlink protocol in socket release notification
>    
>    [ Upstream commit 8f815cdde3e550e10c2736990d791f60c2ce43eb ]
>    
>    A non-privileged user can create a netlink socket with the same port_id as
>    used by an existing open nl80211 netlink socket (e.g. as used by a hostapd
>    process) with a different protocol number.
>    
>    Closing this socket will then lead to the notification going to nl80211's
>    socket release notification handler, and possibly cause an action such as
>    removing a virtual interface.
>    
>    Fix this issue by checking that the netlink protocol is NETLINK_GENERIC.
>    Since generic netlink has no notifier chain of its own, we can't fix the
>    problem more generically.
>    
>    Fixes: 026331c4d9b5 ("cfg80211/mac80211: allow registering for and sending action frames")
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Dmitry Ivanov <dima@ubnt.com>
>    [rewrite commit message]
>    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3254e46ceac3033a4f7b433d36e54da714a05bd8
>Author: Dmitry Ivanov <dmitrijs.ivanovs@ubnt.com>
>Date:   Thu Apr 7 09:31:38 2016 +0200
>
>    netlink: don't send NETLINK_URELEASE for unbound sockets
>    
>    [ Upstream commit e27260203912b40751fa353d009eaa5a642c739f ]
>    
>    All existing users of NETLINK_URELEASE use it to clean up resources that
>    were previously allocated to a socket via some command. As a result, no
>    users require getting this notification for unbound sockets.
>    
>    Sending it for unbound sockets, however, is a problem because any user
>    (including unprivileged users) can create a socket that uses the same ID
>    as an existing socket. Binding this new socket will fail, but if the
>    NETLINK_URELEASE notification is generated for such sockets, the users
>    thereof will be tricked into thinking the socket that they allocated the
>    resources for is closed.
>    
>    In the nl80211 case, this will cause destruction of virtual interfaces
>    that still belong to an existing hostapd process; this is the case that
>    Dmitry noticed. In the NFC case, it will cause a poll abort. In the case
>    of netlink log/queue it will cause them to stop reporting events, as if
>    NFULNL_CFG_CMD_UNBIND/NFQNL_CFG_CMD_UNBIND had been called.
>    
>    Fix this problem by checking that the socket is bound before generating
>    the NETLINK_URELEASE notification.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Dmitry Ivanov <dima@ubnt.com>
>    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9a447b1ba7d4e310a6921fe81e04e9e0ee0d31e4
>Author: Sebastian Ott <sebott@linux.vnet.ibm.com>
>Date:   Thu Mar 31 11:48:31 2016 +0200
>
>    s390/pci: add extra padding to function measurement block
>    
>    [ Upstream commit 9d89d9e61d361f3adb75e1aebe4bb367faf16cfa ]
>    
>    Newer machines might use a different (larger) format for function
>    measurement blocks. To ensure that we comply with the alignment
>    requirement on these machines and prevent memory corruption (when
>    firmware writes more data than we expect) add 16 padding bytes
>    at the end of the fmb.
>    
>    Cc: stable@vger.kernel.org # v4.1+
>    Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
>    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 464508beeb30376f277fbfbfd9137cf19cbfa785
>Author: Vladis Dronov <vdronov@redhat.com>
>Date:   Thu Mar 31 10:53:42 2016 -0700
>
>    Input: gtco - fix crash on detecting device without endpoints
>    
>    [ Upstream commit 162f98dea487206d9ab79fc12ed64700667a894d ]
>    
>    The gtco driver expects at least one valid endpoint. If given malicious
>    descriptors that specify 0 for the number of endpoints, it will crash in
>    the probe function. Ensure there is at least one endpoint on the interface
>    before using it.
>    
>    Also let's fix a minor coding style issue.
>    
>    The full correct report of this issue can be found in the public
>    Red Hat Bugzilla:
>    
>    https://bugzilla.redhat.com/show_bug.cgi?id=1283385
>    
>    Reported-by: Ralf Spenneberg <ralf@spenneberg.net>
>    Signed-off-by: Vladis Dronov <vdronov@redhat.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit fdfdfc7cdf6bfd1ec60d26f123a2b73caf9617f3
>Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
>Date:   Thu Mar 10 13:07:17 2016 +0200
>
>    iwlwifi: pcie: lower the debug level for RSA semaphore access
>    
>    [ Upstream commit 9fc515bc9e735c10cd327f05c20f5ef69474188d ]
>    
>    IWL_INFO is not an error but still printed by default.
>    "can't access the RSA semaphore it is write protected" seems
>    worrisome but it is not really a problem.
>    
>    CC: <stable@vger.kernel.org> [4.1+]
>    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 183c7c8e973b01358799d1718f67dd3a94451a59
>Author: Sasha Levin <sasha.levin@oracle.com>
>Date:   Wed May 4 11:43:55 2016 -0400
>
>    Revert "mei: bus: move driver api functions at the start of the file"
>    
>    This reverts commit 79b768dec5d354aeb143f51db11e0cbb758176fb.
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 54419e3efcd6677e4b0841666e2fc605d2e5df86
>Author: Sasha Levin <sasha.levin@oracle.com>
>Date:   Sat Apr 23 16:46:56 2016 -0400
>
>    Linux 4.1.23
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5640c4c37eee293451388cd5ee74dfed3a30f32d
>Author: Mike Galbraith <umgwanakikbuti@gmail.com>
>Date:   Fri Apr 22 20:30:39 2016 -0400
>
>    Correct backport of fa3c776 ("Thermal: Ignore invalid trip points")
>    
>    Backport of 81ad4276b505e987dd8ebbdf63605f92cd172b52 failed to adjust
>    for intervening ->get_trip_temp() argument type change, thus causing
>    stack protector to panic.
>    
>    drivers/thermal/thermal_core.c: In function âthermal_zone_device_registerâ:
>    drivers/thermal/thermal_core.c:1569:41: warning: passing argument 3 of
>    âtz->ops->get_trip_tempâ from incompatible pointer type [-Wincompatible-pointer-types]
>       if (tz->ops->get_trip_temp(tz, count, &trip_temp))
>                                             ^
>    drivers/thermal/thermal_core.c:1569:41: note: expected âlong unsigned int *â
>    but argument is of type âint *â
>    
>    CC: <stable@vger.kernel.org> #3.18,#4.1
>    Signed-off-by: Mike Galbraith <umgwanakikbuti@gmail.com>
>
>commit af05df01c7a9f4b3cf3dc29365f4c7c4e2cd53ff
>Author: Eric Dumazet <edumazet@google.com>
>Date:   Thu Sep 17 08:38:00 2015 -0700
>
>    tcp_cubic: do not set epoch_start in the future
>    
>    [ Upstream commit c2e7204d180f8efc80f27959ca9cf16fa17f67db ]
>    
>    Tracking idle time in bictcp_cwnd_event() is imprecise, as epoch_start
>    is normally set at ACK processing time, not at send time.
>    
>    Doing a proper fix would need to add an additional state variable,
>    and does not seem worth the trouble, given CUBIC bug has been there
>    forever before Jana noticed it.
>    
>    Let's simply not set epoch_start in the future, otherwise
>    bictcp_update() could overflow and CUBIC would again
>    grow cwnd too fast.
>    
>    This was detected thanks to a packetdrill test Neal wrote that was flaky
>    before applying this fix.
>    
>    Fixes: 30927520dbae ("tcp_cubic: better follow cubic curve after idle period")
>    Signed-off-by: Eric Dumazet <edumazet@google.com>
>    Signed-off-by: Neal Cardwell <ncardwell@google.com>
>    Signed-off-by: Yuchung Cheng <ycheng@google.com>
>    Cc: Jana Iyengar <jri@google.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1d155a6c311d0e7855181638b3b8b6e76302fe6d
>Author: Eric Dumazet <edumazet@google.com>
>Date:   Wed Sep 9 21:55:07 2015 -0700
>
>    tcp_cubic: better follow cubic curve after idle period
>    
>    [ Upstream commit 30927520dbae297182990bb21d08762bcc35ce1d ]
>    
>    Jana Iyengar found an interesting issue on CUBIC :
>    
>    The epoch is only updated/reset initially and when experiencing losses.
>    The delta "t" of now - epoch_start can be arbitrary large after app idle
>    as well as the bic_target. Consequentially the slope (inverse of
>    ca->cnt) would be really large, and eventually ca->cnt would be
>    lower-bounded in the end to 2 to have delayed-ACK slow-start behavior.
>    
>    This particularly shows up when slow_start_after_idle is disabled
>    as a dangerous cwnd inflation (1.5 x RTT) after few seconds of idle
>    time.
>    
>    Jana initial fix was to reset epoch_start if app limited,
>    but Neal pointed out it would ask the CUBIC algorithm to recalculate the
>    curve so that we again start growing steeply upward from where cwnd is
>    now (as CUBIC does just after a loss). Ideally we'd want the cwnd growth
>    curve to be the same shape, just shifted later in time by the amount of
>    the idle period.
>    
>    Reported-by: Jana Iyengar <jri@google.com>
>    Signed-off-by: Eric Dumazet <edumazet@google.com>
>    Signed-off-by: Yuchung Cheng <ycheng@google.com>
>    Signed-off-by: Neal Cardwell <ncardwell@google.com>
>    Cc: Stephen Hemminger <stephen@networkplumber.org>
>    Cc: Sangtae Ha <sangtae.ha@gmail.com>
>    Cc: Lawrence Brakmo <lawrence@brakmo.org>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b016f99b40071aed628a24d08c61960fd77e553e
>Author: Robert Dobrowolski <robert.dobrowolski@linux.intel.com>
>Date:   Thu Mar 24 03:30:07 2016 -0700
>
>    usb: hcd: out of bounds access in for_each_companion
>    
>    [ Upstream commit e86103a75705c7c530768f4ffaba74cf382910f2 ]
>    
>    On BXT platform Host Controller and Device Controller figure as
>    same PCI device but with different device function. HCD should
>    not pass data to Device Controller but only to Host Controllers.
>    Checking if companion device is Host Controller, otherwise skip.
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Robert Dobrowolski <robert.dobrowolski@linux.intel.com>
>    Acked-by: Alan Stern <stern@rowland.harvard.edu>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 17c094b05a35ac64023e412ea680dbef24560f06
>Author: Hans de Goede <hdegoede@redhat.com>
>Date:   Tue Apr 12 12:27:09 2016 +0200
>
>    USB: uas: Add a new NO_REPORT_LUNS quirk
>    
>    [ Upstream commit 1363074667a6b7d0507527742ccd7bbed5e3ceaa ]
>    
>    Add a new NO_REPORT_LUNS quirk and set it for Seagate drives with
>    an usb-id of: 0bc2:331a, as these will fail to respond to a
>    REPORT_LUNS command.
>    
>    Cc: stable@vger.kernel.org
>    Reported-and-tested-by: David Webb <djw@noc.ac.uk>
>    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>    Acked-by: Alan Stern <stern@rowland.harvard.edu>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c5fcfe5f47e72526d2f015da39a92cb79e54a36d
>Author: Mathias Nyman <mathias.nyman@linux.intel.com>
>Date:   Fri Apr 8 16:25:10 2016 +0300
>
>    xhci: fix 10 second timeout on removal of PCI hotpluggable xhci controllers
>    
>    [ Upstream commit 98d74f9ceaefc2b6c4a6440050163a83be0abede ]
>    
>    PCI hotpluggable xhci controllers such as some Alpine Ridge solutions will
>    remove the xhci controller from the PCI bus when the last USB device is
>    disconnected.
>    
>    Add a flag to indicate that the host is being removed to avoid queueing
>    configure_endpoint commands for the dropped endpoints.
>    For PCI hotplugged controllers this will prevent 5 second command timeouts
>    For static xhci controllers the configure_endpoint command is not needed
>    in the removal case as everything will be returned, freed, and the
>    controller is reset.
>    
>    For now the flag is only set for PCI connected host controllers.
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5d0b7d4792890a775d3765ba3e6e444b28c836cc
>Author: Roger Quadros <rogerq@ti.com>
>Date:   Fri May 29 17:01:49 2015 +0300
>
>    usb: xhci: fix xhci locking up during hcd remove
>    
>    [ Upstream commit ad6b1d914a9e07f3b9a9ae3396f3c840d0070539 ]
>    
>    The problem seems to be that if a new device is detected
>    while we have already removed the shared HCD, then many of the
>    xhci operations (e.g.  xhci_alloc_dev(), xhci_setup_device())
>    hang as command never completes.
>    
>    I don't think XHCI can operate without the shared HCD as we've
>    already called xhci_halt() in xhci_only_stop_hcd() when shared HCD
>    goes away. We need to prevent new commands from being queued
>    not only when HCD is dying but also when HCD is halted.
>    
>    The following lockup was detected while testing the otg state
>    machine.
>    
>    [  178.199951] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
>    [  178.205799] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 1
>    [  178.214458] xhci-hcd xhci-hcd.0.auto: hcc params 0x0220f04c hci version 0x100 quirks 0x00010010
>    [  178.223619] xhci-hcd xhci-hcd.0.auto: irq 400, io mem 0x48890000
>    [  178.230677] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
>    [  178.237796] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
>    [  178.245358] usb usb1: Product: xHCI Host Controller
>    [  178.250483] usb usb1: Manufacturer: Linux 4.0.0-rc1-00024-g6111320 xhci-hcd
>    [  178.257783] usb usb1: SerialNumber: xhci-hcd.0.auto
>    [  178.267014] hub 1-0:1.0: USB hub found
>    [  178.272108] hub 1-0:1.0: 1 port detected
>    [  178.278371] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
>    [  178.284171] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 2
>    [  178.294038] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
>    [  178.301183] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
>    [  178.308776] usb usb2: Product: xHCI Host Controller
>    [  178.313902] usb usb2: Manufacturer: Linux 4.0.0-rc1-00024-g6111320 xhci-hcd
>    [  178.321222] usb usb2: SerialNumber: xhci-hcd.0.auto
>    [  178.329061] hub 2-0:1.0: USB hub found
>    [  178.333126] hub 2-0:1.0: 1 port detected
>    [  178.567585] dwc3 48890000.usb: usb_otg_start_host 0
>    [  178.572707] xhci-hcd xhci-hcd.0.auto: remove, state 4
>    [  178.578064] usb usb2: USB disconnect, device number 1
>    [  178.586565] xhci-hcd xhci-hcd.0.auto: USB bus 2 deregistered
>    [  178.592585] xhci-hcd xhci-hcd.0.auto: remove, state 1
>    [  178.597924] usb usb1: USB disconnect, device number 1
>    [  178.603248] usb 1-1: new high-speed USB device number 2 using xhci-hcd
>    [  190.597337] INFO: task kworker/u4:0:6 blocked for more than 10 seconds.
>    [  190.604273]       Not tainted 4.0.0-rc1-00024-g6111320 #1058
>    [  190.610228] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>    [  190.618443] kworker/u4:0    D c05c0ac0     0     6      2 0x00000000
>    [  190.625120] Workqueue: usb_otg usb_otg_work
>    [  190.629533] [<c05c0ac0>] (__schedule) from [<c05c10ac>] (schedule+0x34/0x98)
>    [  190.636915] [<c05c10ac>] (schedule) from [<c05c1318>] (schedule_preempt_disabled+0xc/0x10)
>    [  190.645591] [<c05c1318>] (schedule_preempt_disabled) from [<c05c23d0>] (mutex_lock_nested+0x1ac/0x3fc)
>    [  190.655353] [<c05c23d0>] (mutex_lock_nested) from [<c046cf8c>] (usb_disconnect+0x3c/0x208)
>    [  190.664043] [<c046cf8c>] (usb_disconnect) from [<c0470cf0>] (_usb_remove_hcd+0x98/0x1d8)
>    [  190.672535] [<c0470cf0>] (_usb_remove_hcd) from [<c0485da8>] (usb_otg_start_host+0x50/0xf4)
>    [  190.681299] [<c0485da8>] (usb_otg_start_host) from [<c04849a4>] (otg_set_protocol+0x5c/0xd0)
>    [  190.690153] [<c04849a4>] (otg_set_protocol) from [<c0484b88>] (otg_set_state+0x170/0xbfc)
>    [  190.698735] [<c0484b88>] (otg_set_state) from [<c0485740>] (otg_statemachine+0x12c/0x470)
>    [  190.707326] [<c0485740>] (otg_statemachine) from [<c0053c84>] (process_one_work+0x1b4/0x4a0)
>    [  190.716162] [<c0053c84>] (process_one_work) from [<c00540f8>] (worker_thread+0x154/0x44c)
>    [  190.724742] [<c00540f8>] (worker_thread) from [<c0058f88>] (kthread+0xd4/0xf0)
>    [  190.732328] [<c0058f88>] (kthread) from [<c000e810>] (ret_from_fork+0x14/0x24)
>    [  190.739898] 5 locks held by kworker/u4:0/6:
>    [  190.744274]  #0:  ("%s""usb_otg"){.+.+.+}, at: [<c0053bf4>] process_one_work+0x124/0x4a0
>    [  190.752799]  #1:  ((&otgd->work)){+.+.+.}, at: [<c0053bf4>] process_one_work+0x124/0x4a0
>    [  190.761326]  #2:  (&otgd->fsm.lock){+.+.+.}, at: [<c048562c>] otg_statemachine+0x18/0x470
>    [  190.769934]  #3:  (usb_bus_list_lock){+.+.+.}, at: [<c0470ce8>] _usb_remove_hcd+0x90/0x1d8
>    [  190.778635]  #4:  (&dev->mutex){......}, at: [<c046cf8c>] usb_disconnect+0x3c/0x208
>    [  190.786700] INFO: task kworker/1:0:14 blocked for more than 10 seconds.
>    [  190.793633]       Not tainted 4.0.0-rc1-00024-g6111320 #1058
>    [  190.799567] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>    [  190.807783] kworker/1:0     D c05c0ac0     0    14      2 0x00000000
>    [  190.814457] Workqueue: usb_hub_wq hub_event
>    [  190.818866] [<c05c0ac0>] (__schedule) from [<c05c10ac>] (schedule+0x34/0x98)
>    [  190.826252] [<c05c10ac>] (schedule) from [<c05c4e40>] (schedule_timeout+0x13c/0x1ec)
>    [  190.834377] [<c05c4e40>] (schedule_timeout) from [<c05c19f0>] (wait_for_common+0xbc/0x150)
>    [  190.843062] [<c05c19f0>] (wait_for_common) from [<bf068a3c>] (xhci_setup_device+0x164/0x5cc [xhci_hcd])
>    [  190.852986] [<bf068a3c>] (xhci_setup_device [xhci_hcd]) from [<c046b7f4>] (hub_port_init+0x3f4/0xb10)
>    [  190.862667] [<c046b7f4>] (hub_port_init) from [<c046eb64>] (hub_event+0x704/0x1018)
>    [  190.870704] [<c046eb64>] (hub_event) from [<c0053c84>] (process_one_work+0x1b4/0x4a0)
>    [  190.878919] [<c0053c84>] (process_one_work) from [<c00540f8>] (worker_thread+0x154/0x44c)
>    [  190.887503] [<c00540f8>] (worker_thread) from [<c0058f88>] (kthread+0xd4/0xf0)
>    [  190.895076] [<c0058f88>] (kthread) from [<c000e810>] (ret_from_fork+0x14/0x24)
>    [  190.902650] 5 locks held by kworker/1:0/14:
>    [  190.907023]  #0:  ("usb_hub_wq"){.+.+.+}, at: [<c0053bf4>] process_one_work+0x124/0x4a0
>    [  190.915454]  #1:  ((&hub->events)){+.+.+.}, at: [<c0053bf4>] process_one_work+0x124/0x4a0
>    [  190.924070]  #2:  (&dev->mutex){......}, at: [<c046e490>] hub_event+0x30/0x1018
>    [  190.931768]  #3:  (&port_dev->status_lock){+.+.+.}, at: [<c046eb50>] hub_event+0x6f0/0x1018
>    [  190.940558]  #4:  (&bus->usb_address0_mutex){+.+.+.}, at: [<c046b458>] hub_port_init+0x58/0xb10
>    
>    Signed-off-by: Roger Quadros <rogerq@ti.com>
>    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit bd713f99caa8c08b9bbc57f7c19eefc2eca25fde
>Author: Lu Baolu <baolu.lu@linux.intel.com>
>Date:   Fri Apr 8 16:25:09 2016 +0300
>
>    usb: xhci: fix wild pointers in xhci_mem_cleanup
>    
>    [ Upstream commit 71504062a7c34838c3fccd92c447f399d3cb5797 ]
>    
>    This patch fixes some wild pointers produced by xhci_mem_cleanup.
>    These wild pointers will cause system crash if xhci_mem_cleanup()
>    is called twice.
>    
>    Reported-and-tested-by: Pengcheng Li <lpc.li@hisilicon.com>
>    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1edb54d144c10a0ddb9c83aa329d61b90966d667
>Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>Date:   Fri Apr 8 16:25:07 2016 +0300
>
>    usb: host: xhci: add a new quirk XHCI_NO_64BIT_SUPPORT
>    
>    [ Upstream commit 0a380be8233dbf8dd20795b801c5d5d5ef3992f7 ]
>    
>    On some xHCI controllers (e.g. R-Car SoCs), the AC64 bit (bit 0) of
>    HCCPARAMS1 is set to 1. However, the xHCs don't support 64-bit
>    address memory pointers actually. So, in this case, this driver should
>    call dma_set_coherent_mask(dev, DMA_BIT_MASK(32)) in xhci_gen_setup().
>    Otherwise, the xHCI controller will be died after a usb device is
>    connected if it runs on above 4GB physical memory environment.
>    
>    So, this patch adds a new quirk XHCI_NO_64BIT_SUPPORT to resolve
>    such an issue.
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>    Reviewed-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 52b5bfb04674964c48e5ecaf07d536d7a929e779
>Author: Mathias Nyman <mathias.nyman@linux.intel.com>
>Date:   Fri Apr 8 16:25:06 2016 +0300
>
>    xhci: resume USB 3 roothub first
>    
>    [ Upstream commit 671ffdff5b13314b1fc65d62cf7604b873fb5dc4 ]
>    
>    Give USB3 devices a better chance to enumerate at USB 3 speeds if
>    they are connected to a suspended host.
>    Solves an issue with NEC uPD720200 host hanging when partially
>    enumerating a USB3 device as USB2 after host controller runtime resume.
>    
>    Cc: <stable@vger.kernel.org>
>    Tested-by: Mike Murdoch <main.haarp@gmail.com>
>    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d49e9fc7997642421c13ef90760973320bd684b3
>Author: Rafal Redzimski <rafal.f.redzimski@intel.com>
>Date:   Fri Apr 8 16:25:05 2016 +0300
>
>    usb: xhci: applying XHCI_PME_STUCK_QUIRK to Intel BXT B0 host
>    
>    [ Upstream commit 0d46faca6f887a849efb07c1655b5a9f7c288b45 ]
>    
>    Broxton B0 also requires XHCI_PME_STUCK_QUIRK.
>    Adding PCI device ID for Broxton B and adding to quirk.
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Rafal Redzimski <rafal.f.redzimski@intel.com>
>    Signed-off-by: Robert Dobrowolski <robert.dobrowolski@linux.intel.com>
>    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit da56dbeaede73d918312d3b5f15b2944d35de9da
>Author: Rui Salvaterra <rsalvaterra@gmail.com>
>Date:   Sat Apr 9 22:05:34 2016 +0100
>
>    lib: lz4: fixed zram with lz4 on big endian machines
>    
>    [ Upstream commit 3e26a691fe3fe1e02a76e5bab0c143ace4b137b4 ]
>    
>    Based on Sergey's test patch [1], this fixes zram with lz4 compression
>    on big endian cpus.
>    
>    Note that the 64-bit preprocessor test is not a cleanup, it's part of
>    the fix, since those identifiers are bogus (for example, __ppc64__
>    isn't defined anywhere else in the kernel, which means we'd fall into
>    the 32-bit definitions on ppc64).
>    
>    Tested on ppc64 with no regression on x86_64.
>    
>    [1] http://marc.info/?l=linux-kernel&m=145994470805853&w=4
>    
>    Cc: stable@vger.kernel.org
>    Suggested-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
>    Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
>    Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit bd58e66e02c6d59997121936d755f2e39cb10653
>Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>Date:   Fri Apr 8 16:22:17 2016 +0300
>
>    dmaengine: dw: fix master selection
>    
>    [ Upstream commit 3fe6409c23e2bee4b2b1b6d671d2da8daa15271c ]
>    
>    The commit 895005202987 ("dmaengine: dw: apply both HS interfaces and remove
>    slave_id usage") cleaned up the code to avoid usage of depricated slave_id
>    member of generic slave configuration.
>    
>    Meanwhile it broke the master selection by removing important call to
>    dwc_set_masters() in ->device_alloc_chan_resources() which copied masters from
>    custom slave configuration to the internal channel structure.
>    
>    Everything works until now since there is no customized connection of
>    DesignWare DMA IP to the bus, i.e. one bus and one or more masters are in use.
>    The configurations where 2 masters are connected to the different masters are
>    not working anymore. We are expecting one user of such configuration and need
>    to select masters properly. Besides that it is obviously a performance
>    regression since only one master is in use in multi-master configuration.
>    
>    Select masters in accordance with what user asked for. Keep this patch in a form
>    more suitable for back porting.
>    
>    We are safe to take necessary data in ->device_alloc_chan_resources() because
>    we don't support generic slave configuration embedded into custom one, and thus
>    the only way to provide such is to use the parameter to a filter function which
>    is called exactly before channel resource allocation.
>    
>    While here, replase BUG_ON to less noisy dev_warn() and prevent channel
>    allocation in case of error.
>    
>    Fixes: 895005202987 ("dmaengine: dw: apply both HS interfaces and remove slave_id usage")
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6650ec2e27f912376ea9ec02fe2a144954ce8394
>Author: Seth Forshee <seth.forshee@canonical.com>
>Date:   Wed Mar 9 09:18:07 2016 -0600
>
>    debugfs: Make automount point inodes permanently empty
>    
>    [ Upstream commit 87243deb88671f70def4c52dfa7ca7830707bd31 ]
>    
>    Starting with 4.1 the tracing subsystem has its own filesystem
>    which is automounted in the tracing subdirectory of debugfs.
>    Prior to this debugfs could be bind mounted in a cloned mount
>    namespace, but if tracefs has been mounted under debugfs this
>    now fails because there is a locked child mount. This creates
>    a regression for container software which bind mounts debugfs
>    to satisfy the assumption of some userspace software.
>    
>    In other pseudo filesystems such as proc and sysfs we're already
>    creating mountpoints like this in such a way that no dirents can
>    be created in the directories, allowing them to be exceptions to
>    some MNT_LOCKED tests. In fact we're already do this for the
>    tracefs mountpoint in sysfs.
>    
>    Do the same in debugfs_create_automount(), since the intention
>    here is clearly to create a mountpoint. This fixes the regression,
>    as locked child mounts on permanently empty directories do not
>    cause a bind mount to fail.
>    
>    Cc: stable@vger.kernel.org # v4.1+
>    Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
>    Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a789498eaf5a5c5e0d12b170245aa663496e48e1
>Author: Kailang Yang <kailang@realtek.com>
>Date:   Tue Apr 12 10:55:03 2016 +0800
>
>    ALSA: usb-audio: Skip volume controls triggers hangup on Dell USB Dock
>    
>    [ Upstream commit adcdd0d5a1cb779f6d455ae70882c19c527627a8 ]
>    
>    This is Dell usb dock audio workaround.
>    It was fixed the master volume keep lower.
>    
>    [Some background: the patch essentially skips the controls of a couple
>     of FU volumes.  Although the firmware exposes the dB and the value
>     information via the usb descriptor, changing the values (we set the
>     min volume as default) screws up the device.  Although this has been
>     fixed in the newer firmware, the devices are shipped with the old
>     firmware, thus we need the workaround in the driver side.  -- tiwai]
>    
>    Signed-off-by: Kailang Yang <kailang@realtek.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 330d83a55c70b6dd85f5d6e21fb60e9bcb78df0a
>Author: Sven Eckelmann <sven@narfation.org>
>Date:   Mon Apr 11 16:55:26 2016 +0200
>
>    ALSA: hda/realtek - Enable the ALC292 dock fixup on the Thinkpad T460s
>    
>    [ Upstream commit c636b95ec5980345674ad7960a3c67135a84b687 ]
>    
>    The Lenovo Thinkpad T460s requires the alc_fixup_tpt440_dock as well in
>    order to get working sound output on the docking stations headphone jack.
>    
>    Patch tested on a Thinkpad T460s (20F9CT01WW) using a ThinkPad Ultradock
>    on kernel 4.4.6.
>    
>    Signed-off-by: Sven Eckelmann <sven@narfation.org>
>    Tested-by: Simon Wunderlich <sw@simonwunderlich.de>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b2eecded219e2923e0bae27b0a12e490d28f7c90
>Author: Hui Wang <hui.wang@canonical.com>
>Date:   Fri Apr 1 11:00:15 2016 +0800
>
>    ALSA: hda - fix front mic problem for a HP desktop
>    
>    [ Upstream commit e549d190f7b5f94e9ab36bd965028112914d010d ]
>    
>    The front mic jack (pink color) can't detect any plug or unplug. After
>    applying this fix, both detecting function and recording function
>    work well.
>    
>    BugLink: https://bugs.launchpad.net/bugs/1564712
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Hui Wang <hui.wang@canonical.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit da3bd147aeed487d0caa9eb00d59222407f3034e
>Author: David Matlack <dmatlack@google.com>
>Date:   Wed Mar 30 12:24:47 2016 -0700
>
>    kvm: x86: do not leak guest xcr0 into host interrupt handlers
>    
>    [ Upstream commit fc5b7f3bf1e1414bd4e91db6918c85ace0c873a5 ]
>    
>    An interrupt handler that uses the fpu can kill a KVM VM, if it runs
>    under the following conditions:
>     - the guest's xcr0 register is loaded on the cpu
>     - the guest's fpu context is not loaded
>     - the host is using eagerfpu
>    
>    Note that the guest's xcr0 register and fpu context are not loaded as
>    part of the atomic world switch into "guest mode". They are loaded by
>    KVM while the cpu is still in "host mode".
>    
>    Usage of the fpu in interrupt context is gated by irq_fpu_usable(). The
>    interrupt handler will look something like this:
>    
>    if (irq_fpu_usable()) {
>            kernel_fpu_begin();
>    
>            [... code that uses the fpu ...]
>    
>            kernel_fpu_end();
>    }
>    
>    As long as the guest's fpu is not loaded and the host is using eager
>    fpu, irq_fpu_usable() returns true (interrupted_kernel_fpu_idle()
>    returns true). The interrupt handler proceeds to use the fpu with
>    the guest's xcr0 live.
>    
>    kernel_fpu_begin() saves the current fpu context. If this uses
>    XSAVE[OPT], it may leave the xsave area in an undesirable state.
>    According to the SDM, during XSAVE bit i of XSTATE_BV is not modified
>    if bit i is 0 in xcr0. So it's possible that XSTATE_BV[i] == 1 and
>    xcr0[i] == 0 following an XSAVE.
>    
>    kernel_fpu_end() restores the fpu context. Now if any bit i in
>    XSTATE_BV == 1 while xcr0[i] == 0, XRSTOR generates a #GP. The
>    fault is trapped and SIGSEGV is delivered to the current process.
>    
>    Only pre-4.2 kernels appear to be vulnerable to this sequence of
>    events. Commit 653f52c ("kvm,x86: load guest FPU context more eagerly")
>    from 4.2 forces the guest's fpu to always be loaded on eagerfpu hosts.
>    
>    This patch fixes the bug by keeping the host's xcr0 loaded outside
>    of the interrupts-disabled region where KVM switches into guest mode.
>    
>    Cc: stable@vger.kernel.org
>    Suggested-by: Andy Lutomirski <luto@amacapital.net>
>    Signed-off-by: David Matlack <dmatlack@google.com>
>    [Move load after goto cancel_injection. - Paolo]
>    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e213cce42b7107f64521eb1434e9dd5637ad777b
>Author: Helge Deller <deller@gmx.de>
>Date:   Fri Apr 8 18:32:52 2016 +0200
>
>    parisc: Unbreak handling exceptions from kernel modules
>    
>    [ Upstream commit 2ef4dfd9d9f288943e249b78365a69e3ea3ec072 ]
>    
>    Handling exceptions from modules never worked on parisc.
>    It was just masked by the fact that exceptions from modules
>    don't happen during normal use.
>    
>    When a module triggers an exception in get_user() we need to load the
>    main kernel dp value before accessing the exception_data structure, and
>    afterwards restore the original dp value of the module on exit.
>    
>    Noticed-by: Mikulas Patocka <mpatocka@redhat.com>
>    Signed-off-by: Helge Deller <deller@gmx.de>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9ccccafe228ec2a71a6df4268ce95c27e3d3c8cf
>Author: Helge Deller <deller@gmx.de>
>Date:   Fri Apr 8 18:18:48 2016 +0200
>
>    parisc: Fix kernel crash with reversed copy_from_user()
>    
>    [ Upstream commit ef72f3110d8b19f4c098a0bff7ed7d11945e70c6 ]
>    
>    The kernel module testcase (lib/test_user_copy.c) exhibited a kernel
>    crash on parisc if the parameters for copy_from_user were reversed
>    ("illegal reversed copy_to_user" testcase).
>    
>    Fix this potential crash by checking the fault handler if the faulting
>    address is in the exception table.
>    
>    Signed-off-by: Helge Deller <deller@gmx.de>
>    Cc: stable@vger.kernel.org
>    Cc: Kees Cook <keescook@chromium.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 073cac90966d106bd0959dd44170ab73482f7ef5
>Author: Helge Deller <deller@gmx.de>
>Date:   Fri Apr 8 18:11:33 2016 +0200
>
>    parisc: Avoid function pointers for kernel exception routines
>    
>    [ Upstream commit e3893027a300927049efc1572f852201eb785142 ]
>    
>    We want to avoid the kernel module loader to create function pointers
>    for the kernel fixup routines of get_user() and put_user(). Changing
>    the external reference from function type to int type fixes this.
>    
>    This unbreaks exception handling for get_user() and put_user() when
>    called from a kernel module.
>    
>    Signed-off-by: Helge Deller <deller@gmx.de>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7227a0df99e50b2c5150e2fe0203e605a9d03033
>Author: Yong Li <sdliyong@gmail.com>
>Date:   Wed Mar 30 14:49:14 2016 +0800
>
>    gpio: pca953x: Use correct u16 value for register word write
>    
>    [ Upstream commit 9b8e3ec34318663affced3c14d960e78d760dd9a ]
>    
>    The current implementation only uses the first byte in val,
>    the second byte is always 0. Change it to use cpu_to_le16
>    to write the two bytes into the register
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Yong Li <sdliyong@gmail.com>
>    Reviewed-by: Phil Reid <preid@electromag.com.au>
>    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0ffbec8de4d115f236ea792c71f4ca123f53829c
>Author: Michael S. Tsirkin <mst@redhat.com>
>Date:   Sun Apr 3 15:23:37 2016 +0300
>
>    virtio: virtio 1.0 cs04 spec compliance for reset
>    
>    [ Upstream commit 05dbcb430795b2e1fb1d5c757f8619d3dbed0a1c ]
>    
>    The spec says: after writing 0 to device_status, the driver MUST wait
>    for a read of device_status to return 0 before reinitializing the
>    device.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>    Acked-by: Jason Wang <jasowang@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e649832a3ccad61b0c94fda4011e07c0391c82b1
>Author: BjÃ¸rn Mork <bjorn@mork.no>
>Date:   Thu Apr 7 12:09:17 2016 +0200
>
>    USB: option: add "D-Link DWM-221 B1" device id
>    
>    [ Upstream commit d48d5691ebf88a15d95ba96486917ffc79256536 ]
>    
>    Thomas reports:
>    "Windows:
>    
>    00 diagnostics
>    01 modem
>    02 at-port
>    03 nmea
>    04 nic
>    
>    Linux:
>    
>    T:  Bus=02 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=2001 ProdID=7e19 Rev=02.32
>    S:  Manufacturer=Mobile Connect
>    S:  Product=Mobile Connect
>    S:  SerialNumber=0123456789ABCDEF
>    C:  #Ifs= 6 Cfg#= 1 Atr=a0 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=ff Prot=ff Driver=qmi_wwan
>    I:  If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage"
>    
>    Reported-by: Thomas SchÃ¤fer <tschaefer@t-online.de>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: BjÃ¸rn Mork <bjorn@mork.no>
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ad660596dcb58ab17ff6dfd54b5f013e0af55134
>Author: Martyn Welch <martyn.welch@collabora.co.uk>
>Date:   Tue Mar 29 17:47:29 2016 +0100
>
>    USB: serial: cp210x: Adding GE Healthcare Device ID
>    
>    [ Upstream commit cddc9434e3dcc37a85c4412fb8e277d3a582e456 ]
>    
>    The CP2105 is used in the GE Healthcare Remote Alarm Box, with the
>    Manufacturer ID of 0x1901 and Product ID of 0x0194.
>    
>    Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2e007c671c51005d3b7c9076a2a034441f62d8ab
>Author: Josh Boyer <jwboyer@fedoraproject.org>
>Date:   Thu Mar 10 09:48:52 2016 -0500
>
>    USB: serial: ftdi_sio: Add support for ICP DAS I-756xU devices
>    
>    [ Upstream commit ea6db90e750328068837bed34cb1302b7a177339 ]
>    
>    A Fedora user reports that the ftdi_sio driver works properly for the
>    ICP DAS I-7561U device.  Further, the user manual for these devices
>    instructs users to load the driver and add the ids using the sysfs
>    interface.
>    
>    Add support for these in the driver directly so that the devices work
>    out of the box instead of needing manual configuration.
>    
>    Reported-by: <thesource@mail.ru>
>    CC: stable <stable@vger.kernel.org>
>    Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 033ad030df0ea932a21499582fea59e1df95769b
>Author: Filipe Manana <fdmanana@suse.com>
>Date:   Wed Mar 30 23:37:21 2016 +0100
>
>    Btrfs: fix file/data loss caused by fsync after rename and new inode
>    
>    [ Upstream commit 56f23fdbb600e6087db7b009775b95ce07cc3195 ]
>    
>    If we rename an inode A (be it a file or a directory), create a new
>    inode B with the old name of inode A and under the same parent directory,
>    fsync inode B and then power fail, at log tree replay time we end up
>    removing inode A completely. If inode A is a directory then all its files
>    are gone too.
>    
>    Example scenarios where this happens:
>    This is reproducible with the following steps, taken from a couple of
>    test cases written for fstests which are going to be submitted upstream
>    soon:
>    
>       # Scenario 1
>    
>       mkfs.btrfs -f /dev/sdc
>       mount /dev/sdc /mnt
>       mkdir -p /mnt/a/x
>       echo "hello" > /mnt/a/x/foo
>       echo "world" > /mnt/a/x/bar
>       sync
>       mv /mnt/a/x /mnt/a/y
>       mkdir /mnt/a/x
>       xfs_io -c fsync /mnt/a/x
>       <power failure happens>
>    
>       The next time the fs is mounted, log tree replay happens and
>       the directory "y" does not exist nor do the files "foo" and
>       "bar" exist anywhere (neither in "y" nor in "x", nor the root
>       nor anywhere).
>    
>       # Scenario 2
>    
>       mkfs.btrfs -f /dev/sdc
>       mount /dev/sdc /mnt
>       mkdir /mnt/a
>       echo "hello" > /mnt/a/foo
>       sync
>       mv /mnt/a/foo /mnt/a/bar
>       echo "world" > /mnt/a/foo
>       xfs_io -c fsync /mnt/a/foo
>       <power failure happens>
>    
>       The next time the fs is mounted, log tree replay happens and the
>       file "bar" does not exists anymore. A file with the name "foo"
>       exists and it matches the second file we created.
>    
>    Another related problem that does not involve file/data loss is when a
>    new inode is created with the name of a deleted snapshot and we fsync it:
>    
>       mkfs.btrfs -f /dev/sdc
>       mount /dev/sdc /mnt
>       mkdir /mnt/testdir
>       btrfs subvolume snapshot /mnt /mnt/testdir/snap
>       btrfs subvolume delete /mnt/testdir/snap
>       rmdir /mnt/testdir
>       mkdir /mnt/testdir
>       xfs_io -c fsync /mnt/testdir # or fsync some file inside /mnt/testdir
>       <power failure>
>    
>       The next time the fs is mounted the log replay procedure fails because
>       it attempts to delete the snapshot entry (which has dir item key type
>       of BTRFS_ROOT_ITEM_KEY) as if it were a regular (non-root) entry,
>       resulting in the following error that causes mount to fail:
>    
>       [52174.510532] BTRFS info (device dm-0): failed to delete reference to snap, inode 257 parent 257
>       [52174.512570] ------------[ cut here ]------------
>       [52174.513278] WARNING: CPU: 12 PID: 28024 at fs/btrfs/inode.c:3986 __btrfs_unlink_inode+0x178/0x351 [btrfs]()
>       [52174.514681] BTRFS: Transaction aborted (error -2)
>       [52174.515630] Modules linked in: btrfs dm_flakey dm_mod overlay crc32c_generic ppdev xor raid6_pq acpi_cpufreq parport_pc tpm_tis sg parport tpm evdev i2c_piix4 proc
>       [52174.521568] CPU: 12 PID: 28024 Comm: mount Tainted: G        W       4.5.0-rc6-btrfs-next-27+ #1
>       [52174.522805] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS by qemu-project.org 04/01/2014
>       [52174.524053]  0000000000000000 ffff8801df2a7710 ffffffff81264e93 ffff8801df2a7758
>       [52174.524053]  0000000000000009 ffff8801df2a7748 ffffffff81051618 ffffffffa03591cd
>       [52174.524053]  00000000fffffffe ffff88015e6e5000 ffff88016dbc3c88 ffff88016dbc3c88
>       [52174.524053] Call Trace:
>       [52174.524053]  [<ffffffff81264e93>] dump_stack+0x67/0x90
>       [52174.524053]  [<ffffffff81051618>] warn_slowpath_common+0x99/0xb2
>       [52174.524053]  [<ffffffffa03591cd>] ? __btrfs_unlink_inode+0x178/0x351 [btrfs]
>       [52174.524053]  [<ffffffff81051679>] warn_slowpath_fmt+0x48/0x50
>       [52174.524053]  [<ffffffffa03591cd>] __btrfs_unlink_inode+0x178/0x351 [btrfs]
>       [52174.524053]  [<ffffffff8118f5e9>] ? iput+0xb0/0x284
>       [52174.524053]  [<ffffffffa0359fe8>] btrfs_unlink_inode+0x1c/0x3d [btrfs]
>       [52174.524053]  [<ffffffffa038631e>] check_item_in_log+0x1fe/0x29b [btrfs]
>       [52174.524053]  [<ffffffffa0386522>] replay_dir_deletes+0x167/0x1cf [btrfs]
>       [52174.524053]  [<ffffffffa038739e>] fixup_inode_link_count+0x289/0x2aa [btrfs]
>       [52174.524053]  [<ffffffffa038748a>] fixup_inode_link_counts+0xcb/0x105 [btrfs]
>       [52174.524053]  [<ffffffffa038a5ec>] btrfs_recover_log_trees+0x258/0x32c [btrfs]
>       [52174.524053]  [<ffffffffa03885b2>] ? replay_one_extent+0x511/0x511 [btrfs]
>       [52174.524053]  [<ffffffffa034f288>] open_ctree+0x1dd4/0x21b9 [btrfs]
>       [52174.524053]  [<ffffffffa032b753>] btrfs_mount+0x97e/0xaed [btrfs]
>       [52174.524053]  [<ffffffff8108e1b7>] ? trace_hardirqs_on+0xd/0xf
>       [52174.524053]  [<ffffffff8117bafa>] mount_fs+0x67/0x131
>       [52174.524053]  [<ffffffff81193003>] vfs_kern_mount+0x6c/0xde
>       [52174.524053]  [<ffffffffa032af81>] btrfs_mount+0x1ac/0xaed [btrfs]
>       [52174.524053]  [<ffffffff8108e1b7>] ? trace_hardirqs_on+0xd/0xf
>       [52174.524053]  [<ffffffff8108c262>] ? lockdep_init_map+0xb9/0x1b3
>       [52174.524053]  [<ffffffff8117bafa>] mount_fs+0x67/0x131
>       [52174.524053]  [<ffffffff81193003>] vfs_kern_mount+0x6c/0xde
>       [52174.524053]  [<ffffffff8119590f>] do_mount+0x8a6/0x9e8
>       [52174.524053]  [<ffffffff811358dd>] ? strndup_user+0x3f/0x59
>       [52174.524053]  [<ffffffff81195c65>] SyS_mount+0x77/0x9f
>       [52174.524053]  [<ffffffff814935d7>] entry_SYSCALL_64_fastpath+0x12/0x6b
>       [52174.561288] ---[ end trace 6b53049efb1a3ea6 ]---
>    
>    Fix this by forcing a transaction commit when such cases happen.
>    This means we check in the commit root of the subvolume tree if there
>    was any other inode with the same reference when the inode we are
>    fsync'ing is a new inode (created in the current transaction).
>    
>    Test cases for fstests, covering all the scenarios given above, were
>    submitted upstream for fstests:
>    
>      * fstests: generic test for fsync after renaming directory
>        https://patchwork.kernel.org/patch/8694281/
>    
>      * fstests: generic test for fsync after renaming file
>        https://patchwork.kernel.org/patch/8694301/
>    
>      * fstests: add btrfs test for fsync after snapshot deletion
>        https://patchwork.kernel.org/patch/8670671/
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Filipe Manana <fdmanana@suse.com>
>    Signed-off-by: Chris Mason <clm@fb.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 091537b5b3102af4765256d2b527a2a1de4fb184
>Author: Filipe Manana <fdmanana@suse.com>
>Date:   Thu Jun 25 04:17:46 2015 +0100
>
>    Btrfs: fix fsync after truncate when no_holes feature is enabled
>    
>    [ Upstream commit a89ca6f24ffe435edad57de02eaabd37a2c6bff6 ]
>    
>    When we have the no_holes feature enabled, if a we truncate a file to a
>    smaller size, truncate it again but to a size greater than or equals to
>    its original size and fsync it, the log tree will not have any information
>    about the hole covering the range [truncate_1_offset, new_file_size[.
>    Which means if the fsync log is replayed, the file will remain with the
>    state it had before both truncate operations.
>    
>    Without the no_holes feature this does not happen, since when the inode
>    is logged (full sync flag is set) it will find in the fs/subvol tree a
>    leaf with a generation matching the current transaction id that has an
>    explicit extent item representing the hole.
>    
>    Fix this by adding an explicit extent item representing a hole between
>    the last extent and the inode's i_size if we are doing a full sync.
>    
>    The issue is easy to reproduce with the following test case for fstests:
>    
>      . ./common/rc
>      . ./common/filter
>      . ./common/dmflakey
>    
>      _need_to_be_root
>      _supported_fs generic
>      _supported_os Linux
>      _require_scratch
>      _require_dm_flakey
>    
>      # This test was motivated by an issue found in btrfs when the btrfs
>      # no-holes feature is enabled (introduced in kernel 3.14). So enable
>      # the feature if the fs being tested is btrfs.
>      if [ $FSTYP == "btrfs" ]; then
>          _require_btrfs_fs_feature "no_holes"
>          _require_btrfs_mkfs_feature "no-holes"
>          MKFS_OPTIONS="$MKFS_OPTIONS -O no-holes"
>      fi
>    
>      rm -f $seqres.full
>    
>      _scratch_mkfs >>$seqres.full 2>&1
>      _init_flakey
>      _mount_flakey
>    
>      # Create our test files and make sure everything is durably persisted.
>      $XFS_IO_PROG -f -c "pwrite -S 0xaa 0 64K"         \
>                      -c "pwrite -S 0xbb 64K 61K"       \
>                      $SCRATCH_MNT/foo | _filter_xfs_io
>      $XFS_IO_PROG -f -c "pwrite -S 0xee 0 64K"         \
>                      -c "pwrite -S 0xff 64K 61K"       \
>                      $SCRATCH_MNT/bar | _filter_xfs_io
>      sync
>    
>      # Now truncate our file foo to a smaller size (64Kb) and then truncate
>      # it to the size it had before the shrinking truncate (125Kb). Then
>      # fsync our file. If a power failure happens after the fsync, we expect
>      # our file to have a size of 125Kb, with the first 64Kb of data having
>      # the value 0xaa and the second 61Kb of data having the value 0x00.
>      $XFS_IO_PROG -c "truncate 64K" \
>                   -c "truncate 125K" \
>                   -c "fsync" \
>                   $SCRATCH_MNT/foo
>    
>      # Do something similar to our file bar, but the first truncation sets
>      # the file size to 0 and the second truncation expands the size to the
>      # double of what it was initially.
>      $XFS_IO_PROG -c "truncate 0" \
>                   -c "truncate 253K" \
>                   -c "fsync" \
>                   $SCRATCH_MNT/bar
>    
>      _load_flakey_table $FLAKEY_DROP_WRITES
>      _unmount_flakey
>    
>      # Allow writes again, mount to trigger log replay and validate file
>      # contents.
>      _load_flakey_table $FLAKEY_ALLOW_WRITES
>      _mount_flakey
>    
>      # We expect foo to have a size of 125Kb, the first 64Kb of data all
>      # having the value 0xaa and the remaining 61Kb to be a hole (all bytes
>      # with value 0x00).
>      echo "File foo content after log replay:"
>      od -t x1 $SCRATCH_MNT/foo
>    
>      # We expect bar to have a size of 253Kb and no extents (any byte read
>      # from bar has the value 0x00).
>      echo "File bar content after log replay:"
>      od -t x1 $SCRATCH_MNT/bar
>    
>      status=0
>      exit
>    
>    The expected file contents in the golden output are:
>    
>      File foo content after log replay:
>      0000000 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
>      *
>      0200000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>      *
>      0372000
>      File bar content after log replay:
>      0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>      *
>      0772000
>    
>    Without this fix, their contents are:
>    
>      File foo content after log replay:
>      0000000 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
>      *
>      0200000 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
>      *
>      0372000
>      File bar content after log replay:
>      0000000 ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee
>      *
>      0200000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>      *
>      0372000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>      *
>      0772000
>    
>    A test case submission for fstests follows soon.
>    
>    Signed-off-by: Filipe Manana <fdmanana@suse.com>
>    Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
>    Signed-off-by: Chris Mason <clm@fb.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit db4043dffa5b9f77160dfba088bbbbaa64dd9ed1
>Author: Filipe Manana <fdmanana@suse.com>
>Date:   Sat Jun 20 00:44:51 2015 +0100
>
>    Btrfs: fix fsync xattr loss in the fast fsync path
>    
>    [ Upstream commit 36283bf777d963fac099213297e155d071096994 ]
>    
>    After commit 4f764e515361 ("Btrfs: remove deleted xattrs on fsync log
>    replay"), we can end up in a situation where during log replay we end up
>    deleting xattrs that were never deleted when their file was last fsynced.
>    
>    This happens in the fast fsync path (flag BTRFS_INODE_NEEDS_FULL_SYNC is
>    not set in the inode) if the inode has the flag BTRFS_INODE_COPY_EVERYTHING
>    set, the xattr was added in a past transaction and the leaf where the
>    xattr is located was not updated (COWed or created) in the current
>    transaction. In this scenario the xattr item never ends up in the log
>    tree and therefore at log replay time, which makes the replay code delete
>    the xattr from the fs/subvol tree as it thinks that xattr was deleted
>    prior to the last fsync.
>    
>    Fix this by always logging all xattrs, which is the simplest and most
>    reliable way to detect deleted xattrs and replay the deletes at log replay
>    time.
>    
>    This issue is reproducible with the following test case for fstests:
>    
>      seq=`basename $0`
>      seqres=$RESULT_DIR/$seq
>      echo "QA output created by $seq"
>    
>      here=`pwd`
>      tmp=/tmp/$$
>      status=1	# failure is the default!
>    
>      _cleanup()
>      {
>          _cleanup_flakey
>          rm -f $tmp.*
>      }
>      trap "_cleanup; exit \$status" 0 1 2 3 15
>    
>      # get standard environment, filters and checks
>      . ./common/rc
>      . ./common/filter
>      . ./common/dmflakey
>      . ./common/attr
>    
>      # real QA test starts here
>    
>      # We create a lot of xattrs for a single file. Only btrfs and xfs are currently
>      # able to store such a large mount of xattrs per file, other filesystems such
>      # as ext3/4 and f2fs for example, fail with ENOSPC even if we attempt to add
>      # less than 1000 xattrs with very small values.
>      _supported_fs btrfs xfs
>      _supported_os Linux
>      _need_to_be_root
>      _require_scratch
>      _require_dm_flakey
>      _require_attrs
>      _require_metadata_journaling $SCRATCH_DEV
>    
>      rm -f $seqres.full
>    
>      _scratch_mkfs >> $seqres.full 2>&1
>      _init_flakey
>      _mount_flakey
>    
>      # Create the test file with some initial data and make sure everything is
>      # durably persisted.
>      $XFS_IO_PROG -f -c "pwrite -S 0xaa 0 32k" $SCRATCH_MNT/foo | _filter_xfs_io
>      sync
>    
>      # Add many small xattrs to our file.
>      # We create such a large amount because it's needed to trigger the issue found
>      # in btrfs - we need to have an amount that causes the fs to have at least 3
>      # btree leafs with xattrs stored in them, and it must work on any leaf size
>      # (maximum leaf/node size is 64Kb).
>      num_xattrs=2000
>      for ((i = 1; i <= $num_xattrs; i++)); do
>          name="user.attr_$(printf "%04d" $i)"
>          $SETFATTR_PROG -n $name -v "val_$(printf "%04d" $i)" $SCRATCH_MNT/foo
>      done
>    
>      # Sync the filesystem to force a commit of the current btrfs transaction, this
>      # is a necessary condition to trigger the bug on btrfs.
>      sync
>    
>      # Now update our file's data and fsync the file.
>      # After a successful fsync, if the fsync log/journal is replayed we expect to
>      # see all the xattrs we added before with the same values (and the updated file
>      # data of course). Btrfs used to delete some of these xattrs when it replayed
>      # its fsync log/journal.
>      $XFS_IO_PROG -c "pwrite -S 0xbb 8K 16K" \
>                   -c "fsync" \
>                   $SCRATCH_MNT/foo | _filter_xfs_io
>    
>      # Simulate a crash/power loss.
>      _load_flakey_table $FLAKEY_DROP_WRITES
>      _unmount_flakey
>    
>      # Allow writes again and mount. This makes the fs replay its fsync log.
>      _load_flakey_table $FLAKEY_ALLOW_WRITES
>      _mount_flakey
>    
>      echo "File content after crash and log replay:"
>      od -t x1 $SCRATCH_MNT/foo
>    
>      echo "File xattrs after crash and log replay:"
>      for ((i = 1; i <= $num_xattrs; i++)); do
>          name="user.attr_$(printf "%04d" $i)"
>          echo -n "$name="
>          $GETFATTR_PROG --absolute-names -n $name --only-values $SCRATCH_MNT/foo
>          echo
>      done
>    
>      status=0
>      exit
>    
>    The golden output expects all xattrs to be available, and with the correct
>    values, after the fsync log is replayed.
>    
>    Signed-off-by: Filipe Manana <fdmanana@suse.com>
>    Signed-off-by: Chris Mason <clm@fb.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 32d1b6727390b22cc58d28eb9d7b2d7055e588b7
>Author: Jerome Marchand <jmarchan@redhat.com>
>Date:   Wed Apr 6 14:06:48 2016 +0100
>
>    assoc_array: don't call compare_object() on a node
>    
>    [ Upstream commit 8d4a2ec1e0b41b0cf9a0c5cd4511da7f8e4f3de2 ]
>    
>    Changes since V1: fixed the description and added KASan warning.
>    
>    In assoc_array_insert_into_terminal_node(), we call the
>    compare_object() method on all non-empty slots, even when they're
>    not leaves, passing a pointer to an unexpected structure to
>    compare_object(). Currently it causes an out-of-bound read access
>    in keyring_compare_object detected by KASan (see below). The issue
>    is easily reproduced with keyutils testsuite.
>    Only call compare_object() when the slot is a leave.
>    
>    KASan warning:
>    ==================================================================
>    BUG: KASAN: slab-out-of-bounds in keyring_compare_object+0x213/0x240 at addr ffff880060a6f838
>    Read of size 8 by task keyctl/1655
>    =============================================================================
>    BUG kmalloc-192 (Not tainted): kasan: bad access detected
>    -----------------------------------------------------------------------------
>    
>    Disabling lock debugging due to kernel taint
>    INFO: Allocated in assoc_array_insert+0xfd0/0x3a60 age=69 cpu=1 pid=1647
>    	___slab_alloc+0x563/0x5c0
>    	__slab_alloc+0x51/0x90
>    	kmem_cache_alloc_trace+0x263/0x300
>    	assoc_array_insert+0xfd0/0x3a60
>    	__key_link_begin+0xfc/0x270
>    	key_create_or_update+0x459/0xaf0
>    	SyS_add_key+0x1ba/0x350
>    	entry_SYSCALL_64_fastpath+0x12/0x76
>    INFO: Slab 0xffffea0001829b80 objects=16 used=8 fp=0xffff880060a6f550 flags=0x3fff8000004080
>    INFO: Object 0xffff880060a6f740 @offset=5952 fp=0xffff880060a6e5d1
>    
>    Bytes b4 ffff880060a6f730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>    Object ffff880060a6f740: d1 e5 a6 60 00 88 ff ff 0e 00 00 00 00 00 00 00  ...`............
>    Object ffff880060a6f750: 02 cf 8e 60 00 88 ff ff 02 c0 8e 60 00 88 ff ff  ...`.......`....
>    Object ffff880060a6f760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>    Object ffff880060a6f770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>    Object ffff880060a6f780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>    Object ffff880060a6f790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>    Object ffff880060a6f7a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>    Object ffff880060a6f7b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>    Object ffff880060a6f7c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>    Object ffff880060a6f7d0: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>    Object ffff880060a6f7e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>    Object ffff880060a6f7f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>    CPU: 0 PID: 1655 Comm: keyctl Tainted: G    B           4.5.0-rc4-kasan+ #291
>    Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
>     0000000000000000 000000001b2800b4 ffff880060a179e0 ffffffff81b60491
>     ffff88006c802900 ffff880060a6f740 ffff880060a17a10 ffffffff815e2969
>     ffff88006c802900 ffffea0001829b80 ffff880060a6f740 ffff880060a6e650
>    Call Trace:
>     [<ffffffff81b60491>] dump_stack+0x85/0xc4
>     [<ffffffff815e2969>] print_trailer+0xf9/0x150
>     [<ffffffff815e9454>] object_err+0x34/0x40
>     [<ffffffff815ebe50>] kasan_report_error+0x230/0x550
>     [<ffffffff819949be>] ? keyring_get_key_chunk+0x13e/0x210
>     [<ffffffff815ec62d>] __asan_report_load_n_noabort+0x5d/0x70
>     [<ffffffff81994cc3>] ? keyring_compare_object+0x213/0x240
>     [<ffffffff81994cc3>] keyring_compare_object+0x213/0x240
>     [<ffffffff81bc238c>] assoc_array_insert+0x86c/0x3a60
>     [<ffffffff81bc1b20>] ? assoc_array_cancel_edit+0x70/0x70
>     [<ffffffff8199797d>] ? __key_link_begin+0x20d/0x270
>     [<ffffffff8199786c>] __key_link_begin+0xfc/0x270
>     [<ffffffff81993389>] key_create_or_update+0x459/0xaf0
>     [<ffffffff8128ce0d>] ? trace_hardirqs_on+0xd/0x10
>     [<ffffffff81992f30>] ? key_type_lookup+0xc0/0xc0
>     [<ffffffff8199e19d>] ? lookup_user_key+0x13d/0xcd0
>     [<ffffffff81534763>] ? memdup_user+0x53/0x80
>     [<ffffffff819983ea>] SyS_add_key+0x1ba/0x350
>     [<ffffffff81998230>] ? key_get_type_from_user.constprop.6+0xa0/0xa0
>     [<ffffffff828bcf4e>] ? retint_user+0x18/0x23
>     [<ffffffff8128cc7e>] ? trace_hardirqs_on_caller+0x3fe/0x580
>     [<ffffffff81004017>] ? trace_hardirqs_on_thunk+0x17/0x19
>     [<ffffffff828bc432>] entry_SYSCALL_64_fastpath+0x12/0x76
>    Memory state around the buggy address:
>     ffff880060a6f700: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00
>     ffff880060a6f780: 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc
>    >ffff880060a6f800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>                                            ^
>     ffff880060a6f880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>     ffff880060a6f900: fc fc fc fc fc fc 00 00 00 00 00 00 00 00 00 00
>    ==================================================================
>    
>    Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
>    Signed-off-by: David Howells <dhowells@redhat.com>
>    cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7ec80465e53df6f5d07e53a67c552f1bab33781d
>Author: Dennis Kadioglu <denk@post.com>
>Date:   Wed Apr 6 08:39:01 2016 +0200
>
>    ALSA: usb-audio: Add a quirk for Plantronics BT300
>    
>    [ Upstream commit b4203ff5464da00b7812e7b480192745b0d66bbf ]
>    
>    Plantronics BT300 does not support reading the sample rate which leads
>    to many lines of "cannot get freq at ep 0x1". This patch adds the USB
>    ID of the BT300 to quirks.c and avoids those error messages.
>    
>    Signed-off-by: Dennis Kadioglu <denk@post.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 54080a779fc01b934862bd6abfb0caa63a1d953c
>Author: David Disseldorp <ddiss@suse.de>
>Date:   Tue Apr 5 11:13:39 2016 +0200
>
>    rbd: use GFP_NOIO consistently for request allocations
>    
>    [ Upstream commit 2224d879c7c0f85c14183ef82eb48bd875ceb599 ]
>    
>    As of 5a60e87603c4c533492c515b7f62578189b03c9c, RBD object request
>    allocations are made via rbd_obj_request_create() with GFP_NOIO.
>    However, subsequent OSD request allocations in rbd_osd_req_create*()
>    use GFP_ATOMIC.
>    
>    With heavy page cache usage (e.g. OSDs running on same host as krbd
>    client), rbd_osd_req_create() order-1 GFP_ATOMIC allocations have been
>    observed to fail, where direct reclaim would have allowed GFP_NOIO
>    allocations to succeed.
>    
>    Cc: stable@vger.kernel.org # 3.18+
>    Suggested-by: Vlastimil Babka <vbabka@suse.cz>
>    Suggested-by: Neil Brown <neilb@suse.com>
>    Signed-off-by: David Disseldorp <ddiss@suse.de>
>    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9b561b878bc40703e21144def6a5c2c8d436b883
>Author: Paolo Bonzini <pbonzini@redhat.com>
>Date:   Thu Mar 31 09:38:51 2016 +0200
>
>    compiler-gcc: disable -ftracer for __noclone functions
>    
>    [ Upstream commit 95272c29378ee7dc15f43fa2758cb28a5913a06d ]
>    
>    -ftracer can duplicate asm blocks causing compilation to fail in
>    noclone functions.  For example, KVM declares a global variable
>    in an asm like
>    
>        asm("2: ... \n
>             .pushsection data \n
>             .global vmx_return \n
>             vmx_return: .long 2b");
>    
>    and -ftracer causes a double declaration.
>    
>    Cc: Andrew Morton <akpm@linux-foundation.org>
>    Cc: Michal Marek <mmarek@suse.cz>
>    Cc: stable@vger.kernel.org
>    Cc: kvm@vger.kernel.org
>    Reported-by: Linda Walsh <lkml@tlinx.org>
>    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f320793e52aee78f0fbb8bcaf10e6614d2e67bfc
>Author: Joe Perches <joe@perches.com>
>Date:   Thu Jun 25 15:01:02 2015 -0700
>
>    compiler-gcc: integrate the various compiler-gcc[345].h files
>    
>    [ Upstream commit cb984d101b30eb7478d32df56a0023e4603cba7f ]
>    
>    As gcc major version numbers are going to advance rather rapidly in the
>    future, there's no real value in separate files for each compiler
>    version.
>    
>    Deduplicate some of the macros #defined in each file too.
>    
>    Neaten comments using normal kernel commenting style.
>    
>    Signed-off-by: Joe Perches <joe@perches.com>
>    Cc: Andi Kleen <andi@firstfloor.org>
>    Cc: Michal Marek <mmarek@suse.cz>
>    Cc: Segher Boessenkool <segher@kernel.crashing.org>
>    Cc: Sasha Levin <levinsasha928@gmail.com>
>    Cc: Anton Blanchard <anton@samba.org>
>    Cc: Alan Modra <amodra@gmail.com>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d2bccdc948e21a48d593181c05667d454f423fcd
>Author: Johannes Berg <johannes.berg@intel.com>
>Date:   Thu Mar 31 17:22:45 2016 +0200
>
>    mac80211: properly deal with station hashtable insert errors
>    
>    [ Upstream commit 62b14b241ca6f790a17ccd9dd9f62ce1b006d406 ]
>    
>    The original hand-implemented hash-table in mac80211 couldn't result
>    in insertion errors, and while converting to rhashtable I evidently
>    forgot to check the errors.
>    
>    This surfaced now only because Ben is adding many identical keys and
>    that resulted in hidden insertion errors.
>    
>    Cc: stable@vger.kernel.org
>    Fixes: 7bedd0cfad4e1 ("mac80211: use rhashtable for station table")
>    Reported-by: Ben Greear <greearb@candelatech.com>
>    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e4ad83b41115d3e57318874474cb655f3d6f6378
>Author: Lyude <cpaul@redhat.com>
>Date:   Wed Mar 16 15:18:04 2016 -0400
>
>    drm/i915: Fix race condition in intel_dp_destroy_mst_connector()
>    
>    [ Upstream commit 9e60290dbafdf577766e5fc5f2fdb3be450cf9a6 ]
>    
>    After unplugging a DP MST display from the system, we have to go through
>    and destroy all of the DRM connectors associated with it since none of
>    them are valid anymore. Unfortunately, intel_dp_destroy_mst_connector()
>    doesn't do a good enough job of ensuring that throughout the destruction
>    process that no modesettings can be done with the connectors. As it is
>    right now, intel_dp_destroy_mst_connector() works like this:
>    
>    * Take all modeset locks
>    * Clear the configuration of the crtc on the connector, if there is one
>    * Drop all modeset locks, this is required because of circular
>      dependency issues that arise with trying to remove the connector from
>      sysfs with modeset locks held
>    * Unregister the connector
>    * Take all modeset locks, again
>    * Do the rest of the required cleaning for destroying the connector
>    * Finally drop all modeset locks for good
>    
>    This only works sometimes. During the destruction process, it's very
>    possible that a userspace application will attempt to do a modesetting
>    using the connector. When we drop the modeset locks, an ioctl handler
>    such as drm_mode_setcrtc has the oppurtunity to take all of the modeset
>    locks from us. When this happens, one thing leads to another and
>    eventually we end up committing a mode with the non-existent connector:
>    
>    	[drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* failed to enable link training
>    	[drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
>    	[drm:intel_dp_start_link_train [i915]] *ERROR* failed to start channel equalization
>    	[drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
>    	[drm:intel_mst_pre_enable_dp [i915]] *ERROR* failed to allocate vcpi
>    
>    And in some cases, such as with the T460s using an MST dock, this
>    results in breaking modesetting and/or panicking the system.
>    
>    To work around this, we now unregister the connector at the very
>    beginning of intel_dp_destroy_mst_connector(), grab all the modesetting
>    locks, and then hold them until we finish the rest of the function.
>    
>    CC: stable@vger.kernel.org
>    Signed-off-by: Lyude <cpaul@redhat.com>
>    Signed-off-by: Rob Clark <rclark@redhat.com>
>    Reviewed-by: Ville SyrjÃ¤lÃ¤ <ville.syrjala@linux.intel.com>
>    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>    Link: http://patchwork.freedesktop.org/patch/msgid/1458155884-13877-1-git-send-email-cpaul@redhat.com
>    (cherry picked from commit 1f7717552ef1306be3b7ed28c66c6eff550e3a23)
>    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit fc72648861fe32b02aa3052815dbd1b5b1bb2675
>Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>Date:   Thu Aug 6 13:47:36 2015 +0200
>
>    drm/i915: Update atomic state when removing mst connector, v3.
>    
>    [ Upstream commit 20fae983c6667d038e810c618e3340946b8dc506 ]
>    
>    Fully remove the MST connector from the atomic state, and remove the
>    early returns in check_*_state for MST connectors.
>    
>    With atomic the state can be made consistent all the time.
>    
>    Thanks to Sivakumar Thulasimani for the idea of using
>    drm_atomic_helper_set_config.
>    
>    Changes since v1:
>    - Remove the MST check in intel_connector_check_state too.
>    Changes since v2:
>    - Use drm_atomic_helper_set_config.
>    
>    Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>    Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
>    Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
>    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2d6e4631986ca03cde760acd1c76181559ddc997
>Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>Date:   Fri Mar 18 14:26:32 2016 +0200
>
>    dmaengine: hsu: correct use of channel status register
>    
>    [ Upstream commit 4f4bc0abff79dc9d7ccbd3143adbf8ad1f4fe6ab ]
>    
>    There is a typo in documentation regarding to descriptor empty bit (DESCE)
>    which is set to 1 when descriptor is empty. Thus, status register at the end of
>    a transfer usually returns all DESCE bits set and thus it will never be zero.
>    
>    Moreover, there are 2 bits (CDESC) that encode current descriptor, on which
>    interrupt has been asserted. In case when we have few descriptors programmed we
>    might have non-zero value.
>    
>    Remove DESCE and CDESC bits from DMA channel status register (HSU_CH_SR) when
>    reading it.
>    
>    Fixes: 2b49e0c56741 ("dmaengine: append hsu DMA driver")
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit be851fafe2b011c725e107b8b70e6ec72bcf0d05
>Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>Date:   Mon Apr 4 20:40:20 2016 +0900
>
>    usb: renesas_usbhs: fix to avoid using a disabled ep in usbhsg_queue_done()
>    
>    [ Upstream commit 4fccb0767fdbdb781a9c5b5c15ee7b219443c89d ]
>    
>    This patch fixes an issue that usbhsg_queue_done() may cause kernel
>    panic when dma callback is running and usb_ep_disable() is called
>    by interrupt handler. (Especially, we can reproduce this issue using
>    g_audio with usb-dmac driver.)
>    
>    For example of a flow:
>     usbhsf_dma_complete (on tasklet)
>      --> usbhsf_pkt_handler (on tasklet)
>       --> usbhsg_queue_done (on tasklet)
>        *** interrupt happened and usb_ep_disable() is called ***
>        --> usbhsg_queue_pop (on tasklet)
>         Then, oops happened.
>    
>    Fixes: e73a989 ("usb: renesas_usbhs: add DMAEngine support")
>    Cc: <stable@vger.kernel.org> # v3.1+
>    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 413917195fe1c4f2e02e4a85515587f63cc65c8d
>Author: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>Date:   Fri Mar 18 10:11:07 2016 -0400
>
>    xen/events: Mask a moving irq
>    
>    [ Upstream commit ff1e22e7a638a0782f54f81a6c9cb139aca2da35 ]
>    
>    Moving an unmasked irq may result in irq handler being invoked on both
>    source and target CPUs.
>    
>    With 2-level this can happen as follows:
>    
>    On source CPU:
>            evtchn_2l_handle_events() ->
>                generic_handle_irq() ->
>                    handle_edge_irq() ->
>                       eoi_pirq():
>                           irq_move_irq(data);
>    
>                           /***** WE ARE HERE *****/
>    
>                           if (VALID_EVTCHN(evtchn))
>                               clear_evtchn(evtchn);
>    
>    If at this moment target processor is handling an unrelated event in
>    evtchn_2l_handle_events()'s loop it may pick up our event since target's
>    cpu_evtchn_mask claims that this event belongs to it *and* the event is
>    unmasked and still pending. At the same time, source CPU will continue
>    executing its own handle_edge_irq().
>    
>    With FIFO interrupt the scenario is similar: irq_move_irq() may result
>    in a EVTCHNOP_unmask hypercall which, in turn, may make the event
>    pending on the target CPU.
>    
>    We can avoid this situation by moving and clearing the event while
>    keeping event masked.
>    
>    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit fc4d092ba90e46f614022eb2cab62c48f1d05aab
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Mon Apr 4 11:47:50 2016 +0200
>
>    ALSA: usb-audio: Add a sample rate quirk for Phoenix Audio TMX320
>    
>    [ Upstream commit f03b24a851d32ca85dacab01785b24a7ee717d37 ]
>    
>    Phoenix Audio TMX320 gives the similar error when the sample rate is
>    asked:
>      usb 2-1.3: 2:1: cannot get freq at ep 0x85
>      usb 2-1.3: 1:1: cannot get freq at ep 0x2
>      ....
>    
>    Add the corresponding USB-device ID (1de7:0014) to
>    snd_usb_get_sample_rate_quirk() list.
>    
>    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=110221
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c1f5eb609164d190f1204998767b00ec25a6fb06
>Author: Theodore Ts'o <tytso@mit.edu>
>Date:   Sun Apr 3 17:03:37 2016 -0400
>
>    ext4: ignore quota mount options if the quota feature is enabled
>    
>    [ Upstream commit c325a67c72903e1cc30e990a15ce745bda0dbfde ]
>    
>    Previously, ext4 would fail the mount if the file system had the quota
>    feature enabled and quota mount options (used for the older quota
>    setups) were present.  This broke xfstests, since xfs silently ignores
>    the usrquote and grpquota mount options if they are specified.  This
>    commit changes things so that we are consistent with xfs; having the
>    mount options specified is harmless, so no sense break users by
>    forbidding them.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit cc157620a5ac58f16660f269ec4226cc4e85937d
>Author: Yuki Shibuya <shibuya.yk@ncos.nec.co.jp>
>Date:   Thu Mar 24 05:17:03 2016 +0000
>
>    KVM: x86: Inject pending interrupt even if pending nmi exist
>    
>    [ Upstream commit 321c5658c5e9192dea0d58ab67cf1791e45b2b26 ]
>    
>    Non maskable interrupts (NMI) are preferred to interrupts in current
>    implementation. If a NMI is pending and NMI is blocked by the result
>    of nmi_allowed(), pending interrupt is not injected and
>    enable_irq_window() is not executed, even if interrupts injection is
>    allowed.
>    
>    In old kernel (e.g. 2.6.32), schedule() is often called in NMI context.
>    In this case, interrupts are needed to execute iret that intends end
>    of NMI. The flag of blocking new NMI is not cleared until the guest
>    execute the iret, and interrupts are blocked by pending NMI. Due to
>    this, iret can't be invoked in the guest, and the guest is starved
>    until block is cleared by some events (e.g. canceling injection).
>    
>    This patch injects pending interrupts, when it's allowed, even if NMI
>    is blocked. And, If an interrupts is pending after executing
>    inject_pending_event(), enable_irq_window() is executed regardless of
>    NMI pending counter.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Yuki Shibuya <shibuya.yk@ncos.nec.co.jp>
>    Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
>    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 031b34ddc5b7714d957f7e8ed229e1c1a4c22a8f
>Author: Theodore Ts'o <tytso@mit.edu>
>Date:   Fri Apr 1 01:31:28 2016 -0400
>
>    ext4: add lockdep annotations for i_data_sem
>    
>    [ Upstream commit daf647d2dd58cec59570d7698a45b98e580f2076 ]
>    
>    With the internal Quota feature, mke2fs creates empty quota inodes and
>    quota usage tracking is enabled as soon as the file system is mounted.
>    Since quotacheck is no longer preallocating all of the blocks in the
>    quota inode that are likely needed to be written to, we are now seeing
>    a lockdep false positive caused by needing to allocate a quota block
>    from inside ext4_map_blocks(), while holding i_data_sem for a data
>    inode.  This results in this complaint:
>    
>      Possible unsafe locking scenario:
>    
>            CPU0                    CPU1
>            ----                    ----
>       lock(&ei->i_data_sem);
>                                    lock(&s->s_dquot.dqio_mutex);
>                                    lock(&ei->i_data_sem);
>       lock(&s->s_dquot.dqio_mutex);
>    
>    Google-Bug-Id: 27907753
>    
>    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9dcc54b46e2c231877dfdf28f883789925985891
>Author: Martin K. Petersen <martin.petersen@oracle.com>
>Date:   Mon Mar 28 21:18:56 2016 -0400
>
>    sd: Fix excessive capacity printing on devices with blocks bigger than 512 bytes
>    
>    [ Upstream commit f08bb1e0dbdd0297258d0b8cd4dbfcc057e57b2a ]
>    
>    During revalidate we check whether device capacity has changed before we
>    decide whether to output disk information or not.
>    
>    The check for old capacity failed to take into account that we scaled
>    sdkp->capacity based on the reported logical block size. And therefore
>    the capacity test would always fail for devices with sectors bigger than
>    512 bytes and we would print several copies of the same discovery
>    information.
>    
>    Avoid scaling sdkp->capacity and instead adjust the value on the fly
>    when setting the block device capacity and generating fake C/H/S
>    geometry.
>    
>    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
>    Cc: <stable@vger.kernel.org>
>    Reported-by: Hannes Reinecke <hare@suse.de>
>    Reviewed-by: Hannes Reinicke <hare@suse.de>
>    Reviewed-by: Ewan Milne <emilne@redhat.com>
>    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6175a5af31d191c3b866820fe875ff30b9222dd3
>Author: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
>Date:   Tue Mar 22 09:21:57 2016 -0300
>
>    [media] au0828: Fix dev_state handling
>    
>    [ Upstream commit e8e3039f5b941f7825d335f8ca11c12a8104db11 ]
>    
>    The au0828 dev_state is actually a bit mask. It should not be
>    checking with "==" but, instead, with a logic and. There are some
>    places where it was doing it wrong.
>    
>    Fix that by replacing the dev_state set/clear/test with the
>    bitops.
>    
>    As reviewed by Shuah:
>    	"Looks good. Tested running bind/unbind au0828 loop for 1000 times.
>    	Didn't see any problems and the v4l2_querycap() problem has been
>    	fixed with this patch.
>    
>    	After the above test, ran bind/unbind snd_usb_audio 1000 times.
>    	Didn't see any problems. Generated media graph and the graph
>    	looks good."
>    
>    Cc: stable@vger.kernel.org
>    Reviewed-by: Shuah Khan <shuahkh@osg.samsung.com>
>    Tested-by: Shuah Khan <shuahkh@osg.samsung.com>
>    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ec91ceae833f0d1f48daad19e5d5f52b9de44e74
>Author: Shuah Khan <shuahkh@osg.samsung.com>
>Date:   Tue Mar 22 01:04:05 2016 -0300
>
>    [media] au0828: fix au0828_v4l2_close() dev_state race condition
>    
>    [ Upstream commit ed940cd27416f9887864b95e1f8f8845aa9d6391 ]
>    
>    au0828_v4l2_close() check for dev_state == DEV_DISCONNECTED will fail to
>    detect the device disconnected state correctly, if au0828_v4l2_open() runs
>    to set the DEV_INITIALIZED bit. A loop test of bind/unbind found this bug
>    by increasing the likelihood of au0828_v4l2_open() occurring while unbind
>    is in progress. When au0828_v4l2_close() fails to detect that the device
>    is in disconnect state, it attempts to power down the device and fails with
>    the following general protection fault:
>    
>    [  260.992962] Call Trace:
>    [  260.993008]  [<ffffffffa0f80f0f>] ? xc5000_sleep+0x8f/0xd0 [xc5000]
>    [  260.993095]  [<ffffffffa0f6803c>] ? fe_standby+0x3c/0x50 [tuner]
>    [  260.993186]  [<ffffffffa0ef541c>] au0828_v4l2_close+0x53c/0x620 [au0828]
>    [  260.993298]  [<ffffffffa0d08ec0>] v4l2_release+0xf0/0x210 [videodev]
>    [  260.993382]  [<ffffffff81570f9c>] __fput+0x1fc/0x6c0
>    [  260.993449]  [<ffffffff815714ce>] ____fput+0xe/0x10
>    [  260.993519]  [<ffffffff8116eb83>] task_work_run+0x133/0x1f0
>    [  260.993602]  [<ffffffff810035d0>] exit_to_usermode_loop+0x140/0x170
>    [  260.993681]  [<ffffffff810061ca>] syscall_return_slowpath+0x16a/0x1a0
>    [  260.993754]  [<ffffffff82835fb3>] entry_SYSCALL_64_fastpath+0xa6/0xa8
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
>    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 15f572246983bd2f733b82b35e013d7eaa801e94
>Author: Oliver Neukum <oneukum@suse.com>
>Date:   Thu Mar 31 12:04:26 2016 -0400
>
>    USB: digi_acceleport: do sanity checking for the number of ports
>    
>    [ Upstream commit 5a07975ad0a36708c6b0a5b9fea1ff811d0b0c1f ]
>    
>    The driver can be crashed with devices that expose crafted descriptors
>    with too few endpoints.
>    
>    See: http://seclists.org/bugtraq/2016/Mar/61
>    
>    Signed-off-by: Oliver Neukum <ONeukum@suse.com>
>    [johan: fix OOB endpoint check and add error messages ]
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 45f4b9ca0cf8e53df5adc20d11ffb4b2076dd2c5
>Author: Oliver Neukum <oneukum@suse.com>
>Date:   Thu Mar 31 12:04:25 2016 -0400
>
>    USB: cypress_m8: add endpoint sanity check
>    
>    [ Upstream commit c55aee1bf0e6b6feec8b2927b43f7a09a6d5f754 ]
>    
>    An attack using missing endpoints exists.
>    
>    CVE-2016-3137
>    
>    Signed-off-by: Oliver Neukum <ONeukum@suse.com>
>    CC: stable@vger.kernel.org
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4b8d00f5056e278b053ca183e15f4a8e48d79336
>Author: Oliver Neukum <oneukum@suse.com>
>Date:   Thu Mar 31 12:04:24 2016 -0400
>
>    USB: mct_u232: add sanity checking in probe
>    
>    [ Upstream commit 4e9a0b05257f29cf4b75f3209243ed71614d062e ]
>    
>    An attack using the lack of sanity checking in probe is known. This
>    patch checks for the existence of a second port.
>    
>    CVE-2016-3136
>    
>    Signed-off-by: Oliver Neukum <ONeukum@suse.com>
>    CC: stable@vger.kernel.org
>    [johan: add error message ]
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6b659bbd154edee7a34aedebc925dc611922e472
>Author: John Keeping <john@metanate.com>
>Date:   Wed Nov 18 11:17:25 2015 +0000
>
>    drm/qxl: fix cursor position with non-zero hotspot
>    
>    [ Upstream commit d59a1f71ff1aeda4b4630df92d3ad4e3b1dfc885 ]
>    
>    The SPICE protocol considers the position of a cursor to be the location
>    of its active pixel on the display, so the cursor is drawn with its
>    top-left corner at "(x - hot_spot_x, y - hot_spot_y)" but the DRM cursor
>    position gives the location where the top-left corner should be drawn,
>    with the hotspot being a hint for drivers that need it.
>    
>    This fixes the location of the window resize cursors when using Fluxbox
>    with the QXL DRM driver and both the QXL and modesetting X drivers.
>    
>    Signed-off-by: John Keeping <john@metanate.com>
>    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>    Cc: stable@vger.kernel.org
>    Link: http://patchwork.freedesktop.org/patch/msgid/1447845445-2116-1-git-send-email-john@metanate.com
>    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5c059995372c2861bb71cd761fc50cf773015d14
>Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>Date:   Thu Mar 10 11:30:15 2016 +0900
>
>    usb: renesas_usbhs: disable TX IRQ before starting TX DMAC transfer
>    
>    [ Upstream commit 6490865c67825277b29638e839850882600b48ec ]
>    
>    This patch adds a code to surely disable TX IRQ of the pipe before
>    starting TX DMAC transfer. Otherwise, a lot of unnecessary TX IRQs
>    may happen in rare cases when DMAC is used.
>    
>    Fixes: e73a989 ("usb: renesas_usbhs: add DMAEngine support")
>    Cc: <stable@vger.kernel.org> # v3.1+
>    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 250443d81ea8150c3445c87a291a3ef482cd3ad7
>Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>Date:   Thu Mar 10 11:30:14 2016 +0900
>
>    usb: renesas_usbhs: avoid NULL pointer derefernce in usbhsf_pkt_handler()
>    
>    [ Upstream commit 894f2fc44f2f3f48c36c973b1123f6ab298be160 ]
>    
>    When unexpected situation happened (e.g. tx/rx irq happened while
>    DMAC is used), the usbhsf_pkt_handler() was possible to cause NULL
>    pointer dereference like the followings:
>    
>    Unable to handle kernel NULL pointer dereference at virtual address 00000000
>    pgd = c0004000
>    [00000000] *pgd=00000000
>    Internal error: Oops: 80000007 [#1] SMP ARM
>    Modules linked in: usb_f_acm u_serial g_serial libcomposite
>    CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.5.0-rc6-00842-gac57066-dirty #63
>    Hardware name: Generic R8A7790 (Flattened Device Tree)
>    task: c0729c00 ti: c0724000 task.ti: c0724000
>    PC is at 0x0
>    LR is at usbhsf_pkt_handler+0xac/0x118
>    pc : [<00000000>]    lr : [<c03257e0>]    psr: 60000193
>    sp : c0725db8  ip : 00000000  fp : c0725df4
>    r10: 00000001  r9 : 00000193  r8 : ef3ccab4
>    r7 : ef3cca10  r6 : eea4586c  r5 : 00000000  r4 : ef19ceb4
>    r3 : 00000000  r2 : 0000009c  r1 : c0725dc4  r0 : ef19ceb4
>    
>    This patch adds a condition to avoid the dereference.
>    
>    Fixes: e73a989 ("usb: renesas_usbhs: add DMAEngine support")
>    Cc: <stable@vger.kernel.org> # v3.1+
>    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 071072ef2e0aa829bccd11f5cf9054cd9806a007
>Author: Lokesh Vutla <lokeshvutla@ti.com>
>Date:   Sat Mar 26 23:08:55 2016 -0600
>
>    ARM: OMAP2+: hwmod: Fix updating of sysconfig register
>    
>    [ Upstream commit 3ca4a238106dedc285193ee47f494a6584b6fd2f ]
>    
>    Commit 127500ccb766f ("ARM: OMAP2+: Only write the sysconfig on idle
>    when necessary") talks about verification of sysconfig cache value before
>    updating it, only during idle path. But the patch is adding the
>    verification in the enable path. So, adding the check in a proper place
>    as per the commit description.
>    
>    Not keeping this check during enable path as there is a chance of losing
>    context and it is safe to do on idle as the context of the register will
>    never be lost while the device is active.
>    
>    Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
>    Acked-by: Tero Kristo <t-kristo@ti.com>
>    Cc: Jon Hunter <jonathanh@nvidia.com>
>    Cc: <stable@vger.kernel.org> # 3.12+
>    Fixes: commit 127500ccb766 "ARM: OMAP2+: Only write the sysconfig on idle when necessary"
>    [paul@pwsan.com: appears to have been caused by my own mismerge of the
>     originally posted patch]
>    Signed-off-by: Paul Walmsley <paul@pwsan.com>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8db1fb6a6e0fdc6f6fbfabfc4c9c5a183a7527ac
>Author: Alan Stern <stern@rowland.harvard.edu>
>Date:   Wed Mar 23 12:17:09 2016 -0400
>
>    HID: usbhid: fix inconsistent reset/resume/reset-resume behavior
>    
>    [ Upstream commit 972e6a993f278b416a8ee3ec65475724fc36feb2 ]
>    
>    The usbhid driver has inconsistently duplicated code in its post-reset,
>    resume, and reset-resume pathways.
>    
>    	reset-resume doesn't check HID_STARTED before trying to
>    	restart the I/O queues.
>    
>    	resume fails to clear the HID_SUSPENDED flag if HID_STARTED
>    	isn't set.
>    
>    	resume calls usbhid_restart_queues() with usbhid->lock held
>    	and the others call it without holding the lock.
>    
>    The first item in particular causes a problem following a reset-resume
>    if the driver hasn't started up its I/O.  URB submission fails because
>    usbhid->urbin is NULL, and this triggers an unending reset-retry loop.
>    
>    This patch fixes the problem by creating a new subroutine,
>    hid_restart_io(), to carry out all the common activities.  It also
>    adds some checks that were missing in the original code:
>    
>    	After a reset, there's no need to clear any halted endpoints.
>    
>    	After a resume, if a reset is pending there's no need to
>    	restart any I/O until the reset is finished.
>    
>    	After a resume, if the interrupt-IN endpoint is halted there's
>    	no need to submit the input URB until the halt has been
>    	cleared.
>    
>    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
>    Reported-by: Daniel Fraga <fragabr@gmail.com>
>    Tested-by: Daniel Fraga <fragabr@gmail.com>
>    CC: <stable@vger.kernel.org>
>    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6fe78bc1bfcddabbf3d210e18f91da44fa796d8a
>Author: Sasha Levin <sasha.levin@oracle.com>
>Date:   Tue Apr 19 07:58:05 2016 -0400
>
>    Linux 4.1.22
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 00e1d655592109ea61e6a1316539ae8ce9cc3813
>Author: Hyungwon Hwang <hyungwon.hwang7@gmail.com>
>Date:   Wed Apr 13 09:27:39 2016 +0900
>
>    ALSA: hda - Fix regression of monitor_present flag in eld proc file
>    
>    [ Upstream commit 023d8218ec0dfc30e11d4ec54f640e8f127d1fbe ]
>    
>    The commit [bd48128539ab: ALSA: hda - Fix forgotten HDMI
>    monitor_present update] covered the missing update of monitor_present
>    flag, but this caused a regression for devices without the i915 eld
>    notifier.  Since the old code supposed that pin_eld->monitor_present
>    was updated by the caller side, the hdmi_present_sense_via_verbs()
>    doesn't update the temporary eld->monitor_present but only
>    pin_eld->monitor_present, which is now overridden in update_eld().
>    
>    The fix is to update pin_eld->monitor_present as well before calling
>    update_eld().
>    
>    Note that this may still leave monitor_present flag in an inconsistent
>    state when the driver repolls, but this is at least the old behavior.
>    More proper fix will follow in the later patch.
>    
>    Fixes: bd48128539ab ('ALSA: hda - Fix forgotten HDMI monitor_present update')
>    Signed-off-by: Hyungwon Hwang <hyungwon.hwang7@gmail.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a9e524e20d53b67328c1ba0301c19efae260a0a0
>Author: Cyrille Pitchen <cyrille.pitchen@atmel.com>
>Date:   Fri Feb 5 13:45:12 2016 +0100
>
>    crypto: atmel - fix checks of error code returned by devm_ioremap_resource()
>    
>    [ Upstream commit 9b52d55f4f0e2bb9a34abbcf99e05e17f1b3b281 ]
>    
>    The change fixes potential oops while accessing iomem on invalid
>    address, if devm_ioremap_resource() fails due to some reason.
>    
>    The devm_ioremap_resource() function returns ERR_PTR() and never
>    returns NULL, which makes useless a following check for NULL.
>    
>    Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
>    Fixes: b0e8b3417a62 ("crypto: atmel - use devm_xxx() managed function")
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9cd462227bd3eae177704b9f1d8e160cec511d15
>Author: dann frazier <dann.frazier@canonical.com>
>Date:   Mon Jan 25 16:52:16 2016 -0700
>
>    arm64: errata: Add -mpc-relative-literal-loads to build flags
>    
>    [ Upstream commit 67dfa1751ce71e629aad7c438e1678ad41054677 ]
>    
>    GCC6 (and Linaro's 2015.12 snapshot of GCC5) has a new default that uses
>    adrp/ldr or adrp/add to address literal pools. When CONFIG_ARM64_ERRATUM_843419
>    is enabled, modules built with this toolchain fail to load:
>    
>      module libahci: unsupported RELA relocation: 275
>    
>    This patch fixes the problem by passing '-mpc-relative-literal-loads'
>    to the compiler.
>    
>    Cc: stable@vger.kernel.org
>    Fixes: df057cc7b4fa ("arm64: errata: add module build workaround for erratum #843419")
>    BugLink: http://bugs.launchpad.net/bugs/1533009
>    Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>    Suggested-by: Christophe Lyon <christophe.lyon@linaro.org>
>    Signed-off-by: Dann Frazier <dann.frazier@canonical.com>
>    Signed-off-by: Will Deacon <will.deacon@arm.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit da2041b6c4bf60904a7732eec0b20c89f54d9693
>Author: Vlastimil Babka <vbabka@suse.cz>
>Date:   Fri Mar 25 14:21:50 2016 -0700
>
>    mm/page_alloc: prevent merging between isolated and other pageblocks
>    
>    [ Upstream commit d9dddbf556674bf125ecd925b24e43a5cf2a568a ]
>    
>    Hanjun Guo has reported that a CMA stress test causes broken accounting of
>    CMA and free pages:
>    
>    > Before the test, I got:
>    > -bash-4.3# cat /proc/meminfo | grep Cma
>    > CmaTotal:         204800 kB
>    > CmaFree:          195044 kB
>    >
>    >
>    > After running the test:
>    > -bash-4.3# cat /proc/meminfo | grep Cma
>    > CmaTotal:         204800 kB
>    > CmaFree:         6602584 kB
>    >
>    > So the freed CMA memory is more than total..
>    >
>    > Also the the MemFree is more than mem total:
>    >
>    > -bash-4.3# cat /proc/meminfo
>    > MemTotal:       16342016 kB
>    > MemFree:        22367268 kB
>    > MemAvailable:   22370528 kB
>    
>    Laura Abbott has confirmed the issue and suspected the freepage accounting
>    rewrite around 3.18/4.0 by Joonsoo Kim.  Joonsoo had a theory that this is
>    caused by unexpected merging between MIGRATE_ISOLATE and MIGRATE_CMA
>    pageblocks:
>    
>    > CMA isolates MAX_ORDER aligned blocks, but, during the process,
>    > partialy isolated block exists. If MAX_ORDER is 11 and
>    > pageblock_order is 9, two pageblocks make up MAX_ORDER
>    > aligned block and I can think following scenario because pageblock
>    > (un)isolation would be done one by one.
>    >
>    > (each character means one pageblock. 'C', 'I' means MIGRATE_CMA,
>    > MIGRATE_ISOLATE, respectively.
>    >
>    > CC -> IC -> II (Isolation)
>    > II -> CI -> CC (Un-isolation)
>    >
>    > If some pages are freed at this intermediate state such as IC or CI,
>    > that page could be merged to the other page that is resident on
>    > different type of pageblock and it will cause wrong freepage count.
>    
>    This was supposed to be prevented by CMA operating on MAX_ORDER blocks,
>    but since it doesn't hold the zone->lock between pageblocks, a race
>    window does exist.
>    
>    It's also likely that unexpected merging can occur between
>    MIGRATE_ISOLATE and non-CMA pageblocks.  This should be prevented in
>    __free_one_page() since commit 3c605096d315 ("mm/page_alloc: restrict
>    max order of merging on isolated pageblock").  However, we only check
>    the migratetype of the pageblock where buddy merging has been initiated,
>    not the migratetype of the buddy pageblock (or group of pageblocks)
>    which can be MIGRATE_ISOLATE.
>    
>    Joonsoo has suggested checking for buddy migratetype as part of
>    page_is_buddy(), but that would add extra checks in allocator hotpath
>    and bloat-o-meter has shown significant code bloat (the function is
>    inline).
>    
>    This patch reduces the bloat at some expense of more complicated code.
>    The buddy-merging while-loop in __free_one_page() is initially bounded
>    to pageblock_border and without any migratetype checks.  The checks are
>    placed outside, bumping the max_order if merging is allowed, and
>    returning to the while-loop with a statement which can't be possibly
>    considered harmful.
>    
>    This fixes the accounting bug and also removes the arguably weird state
>    in the original commit 3c605096d315 where buddies could be left
>    unmerged.
>    
>    Fixes: 3c605096d315 ("mm/page_alloc: restrict max order of merging on isolated pageblock")
>    Link: https://lkml.org/lkml/2016/3/2/280
>    Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
>    Reported-by: Hanjun Guo <guohanjun@huawei.com>
>    Tested-by: Hanjun Guo <guohanjun@huawei.com>
>    Acked-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
>    Debugged-by: Laura Abbott <labbott@redhat.com>
>    Debugged-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
>    Cc: Mel Gorman <mgorman@techsingularity.net>
>    Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
>    Cc: Johannes Weiner <hannes@cmpxchg.org>
>    Cc: Minchan Kim <minchan@kernel.org>
>    Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
>    Cc: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
>    Cc: Michal Nazarewicz <mina86@mina86.com>
>    Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
>    Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>    Cc: <stable@vger.kernel.org>	[3.18+]
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4686552323f938fc04e4e6101a271810a1880f73
>Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>Date:   Fri Nov 6 16:29:57 2015 -0800
>
>    mm: use 'unsigned int' for page order
>    
>    [ Upstream commit d00181b96eb86c914cb327d1de974a1b71366e1b ]
>    
>    Let's try to be consistent about data type of page order.
>    
>    [sfr@canb.auug.org.au: fix build (type of pageblock_order)]
>    [hughd@google.com: some configs end up with MAX_ORDER and pageblock_order having different types]
>    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>    Acked-by: Michal Hocko <mhocko@suse.com>
>    Acked-by: Vlastimil Babka <vbabka@suse.cz>
>    Reviewed-by: Andrea Arcangeli <aarcange@redhat.com>
>    Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
>    Cc: Andi Kleen <ak@linux.intel.com>
>    Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>    Cc: Christoph Lameter <cl@linux.com>
>    Cc: David Rientjes <rientjes@google.com>
>    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
>    Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
>    Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>    Signed-off-by: Hugh Dickins <hughd@google.com>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit bbd0b13f917860a686ccaf40cda003332a640a70
>Author: Mel Gorman <mgorman@suse.de>
>Date:   Tue Jun 30 14:56:52 2015 -0700
>
>    mm: page_alloc: pass PFN to __free_pages_bootmem
>    
>    [ Upstream commit d70ddd7a5d9aa335f9b4b0c3d879e1e70ee1e4e3 ]
>    
>    __free_pages_bootmem prepares a page for release to the buddy allocator
>    and assumes that the struct page is initialised.  Parallel initialisation
>    of struct pages defers initialisation and __free_pages_bootmem can be
>    called for struct pages that cannot yet map struct page to PFN.  This
>    patch passes PFN to __free_pages_bootmem with no other functional change.
>    
>    Signed-off-by: Mel Gorman <mgorman@suse.de>
>    Tested-by: Nate Zimmer <nzimmer@sgi.com>
>    Tested-by: Waiman Long <waiman.long@hp.com>
>    Tested-by: Daniel J Blueman <daniel@numascale.com>
>    Acked-by: Pekka Enberg <penberg@kernel.org>
>    Cc: Robin Holt <robinmholt@gmail.com>
>    Cc: Nate Zimmer <nzimmer@sgi.com>
>    Cc: Dave Hansen <dave.hansen@intel.com>
>    Cc: Waiman Long <waiman.long@hp.com>
>    Cc: Scott Norton <scott.norton@hp.com>
>    Cc: "Luck, Tony" <tony.luck@intel.com>
>    Cc: Ingo Molnar <mingo@elte.hu>
>    Cc: "H. Peter Anvin" <hpa@zytor.com>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 474b8c6d329cfc40680ef308878d22f5a1a3b02b
>Author: Joseph Qi <joseph.qi@huawei.com>
>Date:   Fri Mar 25 14:21:29 2016 -0700
>
>    ocfs2/dlm: fix BUG in dlm_move_lockres_to_recovery_list
>    
>    [ Upstream commit be12b299a83fc807bbaccd2bcb8ec50cbb0cb55c ]
>    
>    When master handles convert request, it queues ast first and then
>    returns status.  This may happen that the ast is sent before the request
>    status because the above two messages are sent by two threads.  And
>    right after the ast is sent, if master down, it may trigger BUG in
>    dlm_move_lockres_to_recovery_list in the requested node because ast
>    handler moves it to grant list without clear lock->convert_pending.  So
>    remove BUG_ON statement and check if the ast is processed in
>    dlmconvert_remote.
>    
>    Signed-off-by: Joseph Qi <joseph.qi@huawei.com>
>    Reported-by: Yiwen Jiang <jiangyiwen@huawei.com>
>    Cc: Junxiao Bi <junxiao.bi@oracle.com>
>    Cc: Mark Fasheh <mfasheh@suse.de>
>    Cc: Joel Becker <jlbec@evilplan.org>
>    Cc: Tariq Saeed <tariq.x.saeed@oracle.com>
>    Cc: Junxiao Bi <junxiao.bi@oracle.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d5865dc7deb118b1db82dcaf4d249668bc81a311
>Author: Joseph Qi <joseph.qi@huawei.com>
>Date:   Fri Mar 25 14:21:26 2016 -0700
>
>    ocfs2/dlm: fix race between convert and recovery
>    
>    [ Upstream commit ac7cf246dfdbec3d8fed296c7bf30e16f5099dac ]
>    
>    There is a race window between dlmconvert_remote and
>    dlm_move_lockres_to_recovery_list, which will cause a lock with
>    OCFS2_LOCK_BUSY in grant list, thus system hangs.
>    
>    dlmconvert_remote
>    {
>            spin_lock(&res->spinlock);
>            list_move_tail(&lock->list, &res->converting);
>            lock->convert_pending = 1;
>            spin_unlock(&res->spinlock);
>    
>            status = dlm_send_remote_convert_request();
>            >>>>>> race window, master has queued ast and return DLM_NORMAL,
>                   and then down before sending ast.
>                   this node detects master down and calls
>                   dlm_move_lockres_to_recovery_list, which will revert the
>                   lock to grant list.
>                   Then OCFS2_LOCK_BUSY won't be cleared as new master won't
>                   send ast any more because it thinks already be authorized.
>    
>            spin_lock(&res->spinlock);
>            lock->convert_pending = 0;
>            if (status != DLM_NORMAL)
>                    dlm_revert_pending_convert(res, lock);
>            spin_unlock(&res->spinlock);
>    }
>    
>    In this case, check if res->state has DLM_LOCK_RES_RECOVERING bit set
>    (res is still in recovering) or res master changed (new master has
>    finished recovery), reset the status to DLM_RECOVERING, then it will
>    retry convert.
>    
>    Signed-off-by: Joseph Qi <joseph.qi@huawei.com>
>    Reported-by: Yiwen Jiang <jiangyiwen@huawei.com>
>    Reviewed-by: Junxiao Bi <junxiao.bi@oracle.com>
>    Cc: Mark Fasheh <mfasheh@suse.de>
>    Cc: Joel Becker <jlbec@evilplan.org>
>    Cc: Tariq Saeed <tariq.x.saeed@oracle.com>
>    Cc: Junxiao Bi <junxiao.bi@oracle.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4b586dc3d736a43659acb575c90d33370ba2fb0d
>Author: Vladis Dronov <vdronov@redhat.com>
>Date:   Wed Mar 23 11:53:46 2016 -0700
>
>    Input: ati_remote2 - fix crashes on detecting device with invalid descriptor
>    
>    [ Upstream commit 950336ba3e4a1ffd2ca60d29f6ef386dd2c7351d ]
>    
>    The ati_remote2 driver expects at least two interfaces with one
>    endpoint each. If given malicious descriptor that specify one
>    interface or no endpoints, it will crash in the probe function.
>    Ensure there is at least two interfaces and one endpoint for each
>    interface before using it.
>    
>    The full disclosure: http://seclists.org/bugtraq/2016/Mar/90
>    
>    Reported-by: Ralf Spenneberg <ralf@spenneberg.net>
>    Signed-off-by: Vladis Dronov <vdronov@redhat.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9f1aa2840b8f95558470720572f10bd3b046100f
>Author: John Dahlstrom <jodarom@SDF.ORG>
>Date:   Sat Feb 27 00:09:58 2016 -0600
>
>    ideapad-laptop: Add ideapad Y700 (15) to the no_hw_rfkill DMI list
>    
>    [ Upstream commit 4db9675d927a71faa66e5ab128d2390d6329750b ]
>    
>    Some Lenovo ideapad models lack a physical rfkill switch.
>    On Lenovo models ideapad Y700 Touch-15ISK and ideapad Y700-15ISK,
>    ideapad-laptop would wrongly report all radios as blocked by
>    hardware which caused wireless network connections to fail.
>    
>    Add these models without an rfkill switch to the no_hw_rfkill list.
>    
>    Signed-off-by: John Dahlstrom <jodarom@sdf.org>
>    Cc: <stable@vger.kernel.org> # 3.17.x-: 4fa9dab: ideapad_laptop: Lenovo G50-30 fix rfkill reports wireless blocked
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Darren Hart <dvhart@linux.intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 30c63e3abff9d92d89e3c7132df09188982a6c66
>Author: H Hartley Sweeten <hsweeten@visionengravers.com>
>Date:   Tue Mar 22 10:04:48 2016 -0700
>
>    staging: comedi: ni_mio_common: fix the ni_write[blw]() functions
>    
>    [ Upstream commit bd3a3cd6c27b117fb9a43a38c8072c95332beecc ]
>    
>    Memory mapped io (dev->mmio) should not also be writing to the ioport
>    (dev->iobase) registers. Add the missing 'else' to these functions.
>    
>    Fixes: 0953ee4acca0 ("staging: comedi: ni_mio_common: checkpatch.pl cleanup (else not useful)")
>    Cc: <stable@vger.kernel.org> # 3.17+
>    Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
>    Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e025091aa3a343703375c66e0bd02675b251411a
>Author: Aurelien Jacquiot <a-jacquiot@ti.com>
>Date:   Tue Mar 22 14:25:42 2016 -0700
>
>    rapidio/rionet: fix deadlock on SMP
>    
>    [ Upstream commit 36915976eca58f2eefa040ba8f9939672564df61 ]
>    
>    Fix deadlocking during concurrent receive and transmit operations on SMP
>    platforms caused by the use of incorrect lock: on transmit 'tx_lock'
>    spinlock should be used instead of 'lock' which is used for receive
>    operation.
>    
>    This fix is applicable to kernel versions starting from v2.15.
>    
>    Signed-off-by: Aurelien Jacquiot <a-jacquiot@ti.com>
>    Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
>    Cc: Matt Porter <mporter@kernel.crashing.org>
>    Cc: Andre van Herk <andre.van.herk@prodrive-technologies.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2e840836fdf9ba0767134dcc5103dd25e442023b
>Author: Jann Horn <jann@thejh.net>
>Date:   Tue Mar 22 14:25:36 2016 -0700
>
>    fs/coredump: prevent fsuid=0 dumps into user-controlled directories
>    
>    [ Upstream commit 378c6520e7d29280f400ef2ceaf155c86f05a71a ]
>    
>    This commit fixes the following security hole affecting systems where
>    all of the following conditions are fulfilled:
>    
>     - The fs.suid_dumpable sysctl is set to 2.
>     - The kernel.core_pattern sysctl's value starts with "/". (Systems
>       where kernel.core_pattern starts with "|/" are not affected.)
>     - Unprivileged user namespace creation is permitted. (This is
>       true on Linux >=3.8, but some distributions disallow it by
>       default using a distro patch.)
>    
>    Under these conditions, if a program executes under secure exec rules,
>    causing it to run with the SUID_DUMP_ROOT flag, then unshares its user
>    namespace, changes its root directory and crashes, the coredump will be
>    written using fsuid=0 and a path derived from kernel.core_pattern - but
>    this path is interpreted relative to the root directory of the process,
>    allowing the attacker to control where a coredump will be written with
>    root privileges.
>    
>    To fix the security issue, always interpret core_pattern for dumps that
>    are written under SUID_DUMP_ROOT relative to the root directory of init.
>    
>    Signed-off-by: Jann Horn <jann@thejh.net>
>    Acked-by: Kees Cook <keescook@chromium.org>
>    Cc: Al Viro <viro@zeniv.linux.org.uk>
>    Cc: "Eric W. Biederman" <ebiederm@xmission.com>
>    Cc: Andy Lutomirski <luto@kernel.org>
>    Cc: Oleg Nesterov <oleg@redhat.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0fea20fcc6806c82232a046a872838c0f06999e4
>Author: Arnd Bergmann <arnd@arndb.de>
>Date:   Wed Nov 25 16:22:25 2015 +0100
>
>    coredump: Use 64bit time for unix time of coredump
>    
>    [ Upstream commit 03927c8acb63100046260711c06ba28b6b5936fb ]
>    
>    struct timeval on 32-bit systems will have its tv_sec
>    value overflow in year 2038 and beyond.
>    Use a 64 bit value to print time of the coredump in seconds.
>    ktime_get_real_seconds is chosen here for efficiency reasons.
>    
>    Suggested by: Arnd Bergmann <arnd@arndb.de>
>    Signed-off-by: Tina Ruchandani <ruchandani.tina@gmail.com>
>    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit bef794e8c891b60da2dec86c90f1e46fa142ea1e
>Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
>Date:   Tue Mar 22 17:30:58 2016 -0400
>
>    tracing: Fix trace_printk() to print when not using bprintk()
>    
>    [ Upstream commit 3debb0a9ddb16526de8b456491b7db60114f7b5e ]
>    
>    The trace_printk() code will allocate extra buffers if the compile detects
>    that a trace_printk() is used. To do this, the format of the trace_printk()
>    is saved to the __trace_printk_fmt section, and if that section is bigger
>    than zero, the buffers are allocated (along with a message that this has
>    happened).
>    
>    If trace_printk() uses a format that is not a constant, and thus something
>    not guaranteed to be around when the print happens, the compiler optimizes
>    the fmt out, as it is not used, and the __trace_printk_fmt section is not
>    filled. This means the kernel will not allocate the special buffers needed
>    for the trace_printk() and the trace_printk() will not write anything to the
>    tracing buffer.
>    
>    Adding a "__used" to the variable in the __trace_printk_fmt section will
>    keep it around, even though it is set to NULL. This will keep the string
>    from being printed in the debugfs/tracing/printk_formats section as it is
>    not needed.
>    
>    Reported-by: Vlastimil Babka <vbabka@suse.cz>
>    Fixes: 07d777fe8c398 "tracing: Add percpu buffers for trace_printk()"
>    Cc: stable@vger.kernel.org # v3.5+
>    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 01954dfd48d936199204ae0860897b8aed18c1e2
>Author: Paolo Bonzini <pbonzini@redhat.com>
>Date:   Mon Mar 21 10:15:25 2016 +0100
>
>    KVM: fix spin_lock_init order on x86
>    
>    [ Upstream commit e9ad4ec8379ad1ba6f68b8ca1c26b50b5ae0a327 ]
>    
>    Moving the initialization earlier is needed in 4.6 because
>    kvm_arch_init_vm is now using mmu_lock, causing lockdep to
>    complain:
>    
>    [  284.440294] INFO: trying to register non-static key.
>    [  284.445259] the code is fine but needs lockdep annotation.
>    [  284.450736] turning off the locking correctness validator.
>    ...
>    [  284.528318]  [<ffffffff810aecc3>] lock_acquire+0xd3/0x240
>    [  284.533733]  [<ffffffffa0305aa0>] ? kvm_page_track_register_notifier+0x20/0x60 [kvm]
>    [  284.541467]  [<ffffffff81715581>] _raw_spin_lock+0x41/0x80
>    [  284.546960]  [<ffffffffa0305aa0>] ? kvm_page_track_register_notifier+0x20/0x60 [kvm]
>    [  284.554707]  [<ffffffffa0305aa0>] kvm_page_track_register_notifier+0x20/0x60 [kvm]
>    [  284.562281]  [<ffffffffa02ece70>] kvm_mmu_init_vm+0x20/0x30 [kvm]
>    [  284.568381]  [<ffffffffa02dbf7a>] kvm_arch_init_vm+0x1ea/0x200 [kvm]
>    [  284.574740]  [<ffffffffa02bff3f>] kvm_dev_ioctl+0xbf/0x4d0 [kvm]
>    
>    However, it also helps fixing a preexisting problem, which is why this
>    patch is also good for stable kernels: kvm_create_vm was incrementing
>    current->mm->mm_count but not decrementing it at the out_err label (in
>    case kvm_init_mmu_notifier failed).  The new initialization order makes
>    it possible to add the required mmdrop without adding a new error label.
>    
>    Cc: stable@vger.kernel.org
>    Reported-by: Borislav Petkov <bp@alien8.de>
>    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7a33539146bdcbbce25dbe93e853f39058c640a9
>Author: Paolo Bonzini <pbonzini@redhat.com>
>Date:   Fri Mar 18 16:53:29 2016 +0100
>
>    KVM: VMX: avoid guest hang on invalid invept instruction
>    
>    [ Upstream commit 2849eb4f99d54925c543db12917127f88b3c38ff ]
>    
>    A guest executing an invalid invept instruction would hang
>    because the instruction pointer was not updated.
>    
>    Cc: stable@vger.kernel.org
>    Fixes: bfd0a56b90005f8c8a004baf407ad90045c2b11e
>    Reviewed-by: David Matlack <dmatlack@google.com>
>    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b90311472f0dc0aa7a7223c1220db47ce4db5447
>Author: Himanshu Madhani <himanshu.madhani@qlogic.com>
>Date:   Mon Mar 14 22:47:37 2016 -0700
>
>    target: Fix target_release_cmd_kref shutdown comp leak
>    
>    [ Upstream commit 5e47f1985d7107331c3f64fb3ec83d66fd73577e ]
>    
>    This patch fixes an active I/O shutdown bug for fabric
>    drivers using target_wait_for_sess_cmds(), where se_cmd
>    descriptor shutdown would result in hung tasks waiting
>    indefinitely for se_cmd->cmd_wait_comp to complete().
>    
>    To address this bug, drop the incorrect list_del_init()
>    usage in target_wait_for_sess_cmds() and always complete()
>    during se_cmd target_release_cmd_kref() put, in order to
>    let caller invoke the final fabric release callback
>    into se_cmd->se_tfo->release_cmd() code.
>    
>    Reported-by: Himanshu Madhani <himanshu.madhani@qlogic.com>
>    Tested-by: Himanshu Madhani <himanshu.madhani@qlogic.com>
>    Signed-off-by: Himanshu Madhani <himanshu.madhani@qlogic.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 20b25a3a2ce6ab20ceab54a2650809cc191c3287
>Author: Peter Zijlstra <peterz@infradead.org>
>Date:   Wed Mar 9 12:40:54 2016 +0100
>
>    bitops: Do not default to __clear_bit() for __clear_bit_unlock()
>    
>    [ Upstream commit f75d48644c56a31731d17fa693c8175328957e1d ]
>    
>    __clear_bit_unlock() is a special little snowflake. While it carries the
>    non-atomic '__' prefix, it is specifically documented to pair with
>    test_and_set_bit() and therefore should be 'somewhat' atomic.
>    
>    Therefore the generic implementation of __clear_bit_unlock() cannot use
>    the fully non-atomic __clear_bit() as a default.
>    
>    If an arch is able to do better; is must provide an implementation of
>    __clear_bit_unlock() itself.
>    
>    Specifically, this came up as a result of hackbench livelock'ing in
>    slab_lock() on ARC with SMP + SLUB + !LLSC.
>    
>    The issue was incorrect pairing of atomic ops.
>    
>     slab_lock() -> bit_spin_lock() -> test_and_set_bit()
>     slab_unlock() -> __bit_spin_unlock() -> __clear_bit()
>    
>    The non serializing __clear_bit() was getting "lost"
>    
>     80543b8e:	ld_s       r2,[r13,0] <--- (A) Finds PG_locked is set
>     80543b90:	or         r3,r2,1    <--- (B) other core unlocks right here
>     80543b94:	st_s       r3,[r13,0] <--- (C) sets PG_locked (overwrites unlock)
>    
>    Fixes ARC STAR 9000817404 (and probably more).
>    
>    Reported-by: Vineet Gupta <Vineet.Gupta1@synopsys.com>
>    Tested-by: Vineet Gupta <Vineet.Gupta1@synopsys.com>
>    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>    Cc: Andrew Morton <akpm@linux-foundation.org>
>    Cc: Christoph Lameter <cl@linux.com>
>    Cc: David Rientjes <rientjes@google.com>
>    Cc: Helge Deller <deller@gmx.de>
>    Cc: James E.J. Bottomley <jejb@parisc-linux.org>
>    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Noam Camus <noamc@ezchip.com>
>    Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>    Cc: Pekka Enberg <penberg@kernel.org>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Cc: stable@vger.kernel.org
>    Link: http://lkml.kernel.org/r/20160309114054.GJ6356@twins.programming.kicks-ass.net
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 35fe4a174248f3433e8017177a606fba74c86c4c
>Author: Victor ClÃ©ment <victor.clement@openmailbox.org>
>Date:   Sat Mar 19 13:17:42 2016 +0100
>
>    ALSA: usb-audio: add Microsoft HD-5001 to quirks
>    
>    [ Upstream commit 0ef21100ae912f76ed89f76ecd894f4ffb3689c1 ]
>    
>    The Microsoft HD-5001 webcam microphone does not support sample rate
>    reading as the HD-5000 one.
>    This results in dmesg errors and sound hanging with pulseaudio.
>    
>    Signed-off-by: Victor ClÃ©ment <victor.clement@openmailbox.org>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ff6c4184945bb5ec843cde5c3936b93823cf5641
>Author: Rabin Vincent <rabin@rab.in>
>Date:   Thu Mar 10 21:19:06 2016 +0100
>
>    splice: handle zero nr_pages in splice_to_pipe()
>    
>    [ Upstream commit d6785d9152147596f60234157da2b02540c3e60f ]
>    
>    Running the following command:
>    
>     busybox cat /sys/kernel/debug/tracing/trace_pipe > /dev/null
>    
>    with any tracing enabled pretty very quickly leads to various NULL
>    pointer dereferences and VM BUG_ON()s, such as these:
>    
>     BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
>     IP: [<ffffffff8119df6c>] generic_pipe_buf_release+0xc/0x40
>     Call Trace:
>      [<ffffffff811c48a3>] splice_direct_to_actor+0x143/0x1e0
>      [<ffffffff811c42e0>] ? generic_pipe_buf_nosteal+0x10/0x10
>      [<ffffffff811c49cf>] do_splice_direct+0x8f/0xb0
>      [<ffffffff81196869>] do_sendfile+0x199/0x380
>      [<ffffffff81197600>] SyS_sendfile64+0x90/0xa0
>      [<ffffffff8192cbee>] entry_SYSCALL_64_fastpath+0x12/0x6d
>    
>     page dumped because: VM_BUG_ON_PAGE(atomic_read(&page->_count) == 0)
>     kernel BUG at include/linux/mm.h:367!
>     invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
>     RIP: [<ffffffff8119df9c>] generic_pipe_buf_release+0x3c/0x40
>     Call Trace:
>      [<ffffffff811c48a3>] splice_direct_to_actor+0x143/0x1e0
>      [<ffffffff811c42e0>] ? generic_pipe_buf_nosteal+0x10/0x10
>      [<ffffffff811c49cf>] do_splice_direct+0x8f/0xb0
>      [<ffffffff81196869>] do_sendfile+0x199/0x380
>      [<ffffffff81197600>] SyS_sendfile64+0x90/0xa0
>      [<ffffffff8192cd1e>] tracesys_phase2+0x84/0x89
>    
>    (busybox's cat uses sendfile(2), unlike the coreutils version)
>    
>    This is because tracing_splice_read_pipe() can call splice_to_pipe()
>    with spd->nr_pages == 0.  spd_pages underflows in splice_to_pipe() and
>    we fill the page pointers and the other fields of the pipe_buffers with
>    garbage.
>    
>    All other callers of splice_to_pipe() avoid calling it when nr_pages ==
>    0, and we could make tracing_splice_read_pipe() do that too, but it
>    seems reasonable to have splice_to_page() handle this condition
>    gracefully.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Rabin Vincent <rabin@rab.in>
>    Reviewed-by: Christoph Hellwig <hch@lst.de>
>    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ab31b690cdf88cf5cb0493718b89dbc37dd784a3
>Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
>Date:   Fri Mar 18 15:46:48 2016 -0400
>
>    tracing: Fix crash from reading trace_pipe with sendfile
>    
>    [ Upstream commit a29054d9478d0435ab01b7544da4f674ab13f533 ]
>    
>    If tracing contains data and the trace_pipe file is read with sendfile(),
>    then it can trigger a NULL pointer dereference and various BUG_ON within the
>    VM code.
>    
>    There's a patch to fix this in the splice_to_pipe() code, but it's also a
>    good idea to not let that happen from trace_pipe either.
>    
>    Link: http://lkml.kernel.org/r/1457641146-9068-1-git-send-email-rabin@rab.in
>    
>    Cc: stable@vger.kernel.org # 2.6.30+
>    Reported-by: Rabin Vincent <rabin.vincent@gmail.com>
>    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e4fc9a7c67d779795033235a2b5d2c84e39424c2
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Fri Mar 18 18:01:53 2016 +0100
>
>    ALSA: hda - Fix forgotten HDMI monitor_present update
>    
>    [ Upstream commit bd48128539ab89986b24ad08ecd3e027dd1993a1 ]
>    
>    We forgot to copy monitor_present value when updating the ELD
>    information.  This won't change the ELD retrieval and the jack
>    notification behavior, but appears only in the proc output.   In that
>    sense, it's no fatal error, but a bug is a bug is a bug.
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b3d43aeef165fd0df7ba1b59d29eaee019df4923
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Fri Nov 13 09:12:12 2015 +0100
>
>    ALSA: hda - Split ELD update code from hdmi_present_sense()
>    
>    [ Upstream commit e90247f9fceeebe5bdaac2d87e301e73bae9bc1f ]
>    
>    This is a preliminary patch for the later change to support ELD/jack
>    handling with i915 audio component.  This splits the ELD update code
>    from hdmi_present_sense() so that it can be called from other places.
>    
>    Just a code refactoring, no functional change.
>    
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0b914b30c534502d1d6a68a5859ee65c3d7d8aa5
>Author: Hans de Goede <hdegoede@redhat.com>
>Date:   Mon Mar 7 20:11:52 2016 +0100
>
>    USB: uas: Reduce can_queue to MAX_CMNDS
>    
>    [ Upstream commit 55ff8cfbc4e12a7d2187df523938cc671fbebdd1 ]
>    
>    The uas driver can never queue more then MAX_CMNDS (- 1) tags and tags
>    are shared between luns, so there is no need to claim that we can_queue
>    some random large number.
>    
>    Not claiming that we can_queue 65536 commands, fixes the uas driver
>    failing to initialize while allocating the tag map with a "Page allocation
>    failure (order 7)" error on systems which have been running for a while
>    and thus have fragmented memory.
>    
>    Cc: stable@vger.kernel.org
>    Reported-and-tested-by: Yves-Alexis Perez <corsac@corsac.net>
>    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a635bc779e7b7748c9b0b773eaf08a7f2184ec50
>Author: Oliver Neukum <oneukum@suse.com>
>Date:   Tue Mar 15 10:14:04 2016 +0100
>
>    USB: cdc-acm: more sanity checking
>    
>    [ Upstream commit 8835ba4a39cf53f705417b3b3a94eb067673f2c9 ]
>    
>    An attack has become available which pretends to be a quirky
>    device circumventing normal sanity checks and crashes the kernel
>    by an insufficient number of interfaces. This patch adds a check
>    to the code path for quirky devices.
>    
>    Signed-off-by: Oliver Neukum <ONeukum@suse.com>
>    CC: stable@vger.kernel.org
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit febfaffe4aa9b0600028f46f50156e3354e34208
>Author: Oliver Neukum <oneukum@suse.com>
>Date:   Wed Mar 16 13:26:17 2016 +0100
>
>    USB: usb_driver_claim_interface: add sanity checking
>    
>    [ Upstream commit 0b818e3956fc1ad976bee791eadcbb3b5fec5bfd ]
>    
>    Attacks that trick drivers into passing a NULL pointer
>    to usb_driver_claim_interface() using forged descriptors are
>    known. This thwarts them by sanity checking.
>    
>    Signed-off-by: Oliver Neukum <ONeukum@suse.com>
>    CC: stable@vger.kernel.org
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 14a710bbf6b4095876ff682b3066ac485480049c
>Author: Josh Boyer <jwboyer@fedoraproject.org>
>Date:   Mon Mar 14 10:42:38 2016 -0400
>
>    USB: iowarrior: fix oops with malicious USB descriptors
>    
>    [ Upstream commit 4ec0ef3a82125efc36173062a50624550a900ae0 ]
>    
>    The iowarrior driver expects at least one valid endpoint.  If given
>    malicious descriptors that specify 0 for the number of endpoints,
>    it will crash in the probe function.  Ensure there is at least
>    one endpoint on the interface before using it.
>    
>    The full report of this issue can be found here:
>    http://seclists.org/bugtraq/2016/Mar/87
>    
>    Reported-by: Ralf Spenneberg <ralf@spenneberg.net>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e69b0c2d1686a3344265e26a2ea6197e856f0459
>Author: Dave Jones <davej@codemonkey.org.uk>
>Date:   Mon Mar 14 21:20:54 2016 -0400
>
>    x86/apic: Fix suspicious RCU usage in smp_trace_call_function_interrupt()
>    
>    [ Upstream commit 7834c10313fb823e538f2772be78edcdeed2e6e3 ]
>    
>    Since 4.4, I've been able to trigger this occasionally:
>    
>    ===============================
>    [ INFO: suspicious RCU usage. ]
>    4.5.0-rc7-think+ #3 Not tainted
>    Cc: Andi Kleen <ak@linux.intel.com>
>    Link: http://lkml.kernel.org/r/20160315012054.GA17765@codemonkey.org.uk
>    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>    
>    -------------------------------
>    ./arch/x86/include/asm/msr-trace.h:47 suspicious rcu_dereference_check() usage!
>    
>    other info that might help us debug this:
>    
>    RCU used illegally from idle CPU!
>    rcu_scheduler_active = 1, debug_locks = 1
>    RCU used illegally from extended quiescent state!
>    no locks held by swapper/3/0.
>    
>    stack backtrace:
>    CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.5.0-rc7-think+ #3
>     ffffffff92f821e0 1f3e5c340597d7fc ffff880468e07f10 ffffffff92560c2a
>     ffff880462145280 0000000000000001 ffff880468e07f40 ffffffff921376a6
>     ffffffff93665ea0 0000cc7c876d28da 0000000000000005 ffffffff9383dd60
>    Call Trace:
>     <IRQ>  [<ffffffff92560c2a>] dump_stack+0x67/0x9d
>     [<ffffffff921376a6>] lockdep_rcu_suspicious+0xe6/0x100
>     [<ffffffff925ae7a7>] do_trace_write_msr+0x127/0x1a0
>     [<ffffffff92061c83>] native_apic_msr_eoi_write+0x23/0x30
>     [<ffffffff92054408>] smp_trace_call_function_interrupt+0x38/0x360
>     [<ffffffff92d1ca60>] trace_call_function_interrupt+0x90/0xa0
>     <EOI>  [<ffffffff92ac5124>] ? cpuidle_enter_state+0x1b4/0x520
>    
>    Move the entering_irq() call before ack_APIC_irq(), because entering_irq()
>    tells the RCU susbstems to end the extended quiescent state, so that the
>    following trace call in ack_APIC_irq() works correctly.
>    
>    Suggested-by: Andi Kleen <ak@linux.intel.com>
>    Fixes: 4787c368a9bc "x86/tracing: Add irq_enter/exit() in smp_trace_reschedule_interrupt()"
>    Signed-off-by: Dave Jones <davej@codemonkey.org.uk>
>    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit fa3c776f1c47bd8cdbaaf1080420a67d4bfdc867
>Author: Zhang Rui <rui.zhang@intel.com>
>Date:   Fri Mar 18 10:03:24 2016 +0800
>
>    Thermal: Ignore invalid trip points
>    
>    [ Upstream commit 81ad4276b505e987dd8ebbdf63605f92cd172b52 ]
>    
>    In some cases, platform thermal driver may report invalid trip points,
>    thermal core should not take any action for these trip points.
>    
>    This fixed a regression that bogus trip point starts to screw up thermal
>    control on some Lenovo laptops, after
>    commit bb431ba26c5cd0a17c941ca6c3a195a3a6d5d461
>    Author: Zhang Rui <rui.zhang@intel.com>
>    Date:   Fri Oct 30 16:31:47 2015 +0800
>    
>        Thermal: initialize thermal zone device correctly
>    
>        After thermal zone device registered, as we have not read any
>        temperature before, thus tz->temperature should not be 0,
>        which actually means 0C, and thermal trend is not available.
>        In this case, we need specially handling for the first
>        thermal_zone_device_update().
>    
>        Both thermal core framework and step_wise governor is
>        enhanced to handle this. And since the step_wise governor
>        is the only one that uses trends, so it's the only thermal
>        governor that needs to be updated.
>    
>        Tested-by: Manuel Krause <manuelkrause@netscape.net>
>        Tested-by: szegad <szegadlo@poczta.onet.pl>
>        Tested-by: prash <prash.n.rao@gmail.com>
>        Tested-by: amish <ammdispose-arch@yahoo.com>
>        Tested-by: Matthias <morpheusxyz123@yahoo.de>
>        Reviewed-by: Javi Merino <javi.merino@arm.com>
>        Signed-off-by: Zhang Rui <rui.zhang@intel.com>
>        Signed-off-by: Chen Yu <yu.c.chen@intel.com>
>    
>    CC: <stable@vger.kernel.org> #3.18+
>    Link: https://bugzilla.redhat.com/show_bug.cgi?id=1317190
>    Link: https://bugzilla.kernel.org/show_bug.cgi?id=114551
>    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit dfeccb29d75a2a7dc75d8b2c68b53bd7601d8686
>Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>Date:   Thu Mar 17 17:12:54 2016 -0700
>
>    Input: synaptics - handle spurious release of trackstick buttons, again
>    
>    [ Upstream commit 82be788c96ed5978d3cb4a00079e26b981a3df3f ]
>    
>    Looks like the fimware 8.2 still has the extra buttons spurious release
>    bug.
>    
>    Link: https://bugzilla.kernel.org/show_bug.cgi?id=114321
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 62b3bd2a4f98852cefd0df17333362638246aa8f
>Author: Johannes Weiner <hannes@cmpxchg.org>
>Date:   Thu Mar 17 14:20:25 2016 -0700
>
>    mm: memcontrol: reclaim when shrinking memory.high below usage
>    
>    [ Upstream commit 588083bb37a3cea8533c392370a554417c8f29cb ]
>    
>    When setting memory.high below usage, nothing happens until the next
>    charge comes along, and then it will only reclaim its own charge and not
>    the now potentially huge excess of the new memory.high.  This can cause
>    groups to stay in excess of their memory.high indefinitely.
>    
>    To fix that, when shrinking memory.high, kick off a reclaim cycle that
>    goes after the delta.
>    
>    Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
>    Acked-by: Michal Hocko <mhocko@suse.com>
>    Cc: Vladimir Davydov <vdavydov@virtuozzo.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 15207f3ca364563c590ba170ce40c1f90fd78268
>Author: Joshua Hunt <johunt@akamai.com>
>Date:   Thu Mar 17 14:17:23 2016 -0700
>
>    watchdog: don't run proc_watchdog_update if new value is same as old
>    
>    [ Upstream commit a1ee1932aa6bea0bb074f5e3ced112664e4637ed ]
>    
>    While working on a script to restore all sysctl params before a series of
>    tests I found that writing any value into the
>    /proc/sys/kernel/{nmi_watchdog,soft_watchdog,watchdog,watchdog_thresh}
>    causes them to call proc_watchdog_update().
>    
>      NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.
>      NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.
>      NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.
>      NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.
>    
>    There doesn't appear to be a reason for doing this work every time a write
>    occurs, so only do it when the values change.
>    
>    Signed-off-by: Josh Hunt <johunt@akamai.com>
>    Acked-by: Don Zickus <dzickus@redhat.com>
>    Reviewed-by: Aaron Tomlin <atomlin@redhat.com>
>    Cc: Ulrich Obergfell <uobergfe@redhat.com>
>    Cc: <stable@vger.kernel.org>	[4.1.x+]
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3ec245e8591a183e276df89cd7f9e7a15645b9da
>Author: Oliver Neukum <oneukum@suse.com>
>Date:   Thu Mar 17 14:00:17 2016 -0700
>
>    Input: ims-pcu - sanity check against missing interfaces
>    
>    [ Upstream commit a0ad220c96692eda76b2e3fd7279f3dcd1d8a8ff ]
>    
>    A malicious device missing interface can make the driver oops.
>    Add sanity checking.
>    
>    Signed-off-by: Oliver Neukum <ONeukum@suse.com>
>    CC: stable@vger.kernel.org
>    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0db0888f18f37d9ee10e99a7f3e90861b4d525a2
>Author: Brent Taylor <motobud@gmail.com>
>Date:   Sun Mar 13 00:25:31 2016 -0600
>
>    mmc: atmel-mci: Check pdata for NULL before dereferencing it at DMA config
>    
>    [ Upstream commit 93c77d2999b09f2084b033ea6489915e0104ad9c ]
>    
>    Using an at91sam9g20ek development board with DTS configuration may trigger
>    a kernel panic because of a NULL pointer dereference exception, while
>    configuring DMA. Let's fix this by adding a check for pdata before
>    dereferencing it.
>    
>    Signed-off-by: Brent Taylor <motobud@gmail.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7fa28eeed844c4388957095e5c485eb6f87a14de
>Author: Mans Rullgard <mans@mansr.com>
>Date:   Sat Jan 9 12:45:10 2016 +0000
>
>    mmc: atmel-mci: restore dma on AVR32
>    
>    [ Upstream commit 74843787158e9dff249f0528e7d4806102cc2c26 ]
>    
>    Commit ecb89f2f5f3e7 ("mmc: atmel-mci: remove compat for non DT board
>    when requesting dma chan") broke dma on AVR32 and any other boards not
>    using DT.  This restores a fallback mechanism for such cases.
>    
>    Signed-off-by: Mans Rullgard <mans@mansr.com>
>    Acked-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no>
>    Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
>    Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 112958c534636b0cb8614adef3c7b758409fb27b
>Author: Adrian Hunter <adrian.hunter@intel.com>
>Date:   Mon Mar 7 13:33:55 2016 +0200
>
>    mmc: sdhci: Fix override of timeout clk wrt max_busy_timeout
>    
>    [ Upstream commit 995136247915c5cee633d55ba23f6eebf67aa567 ]
>    
>    Normally the timeout clock frequency is read from the capabilities
>    register.  It is also possible to set the value prior to calling
>    sdhci_add_host() in which case that value will override the
>    capabilities register value.  However that was being done after
>    calculating max_busy_timeout so that max_busy_timeout was being
>    calculated using the wrong value of timeout_clk.
>    
>    Fix that by moving the override before max_busy_timeout is
>    calculated.
>    
>    The result is that the max_busy_timeout and max_discard
>    increase for BSW devices so that, for example, the time for
>    mkfs.ext4 on a 64GB eMMC drops from about 1 minute 40 seconds
>    to about 20 seconds.
>    
>    Note, in the future, the capabilities setting will be tidied up
>    and this override won't be used anymore.  However this fix is
>    needed for stable.
>    
>    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
>    Cc: stable@vger.kernel.org # v3.18+
>    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1a2b820966601499b51d9bfd28c00932f5357e09
>Author: Andy Lutomirski <luto@kernel.org>
>Date:   Wed Mar 16 14:14:22 2016 -0700
>
>    x86/iopl: Fix iopl capability check on Xen PV
>    
>    [ Upstream commit c29016cf41fe9fa994a5ecca607cf5f1cd98801e ]
>    
>    iopl(3) is supposed to work if iopl is already 3, even if
>    unprivileged.  This didn't work right on Xen PV.  Fix it.
>    
>    Reviewewd-by: Jan Beulich <JBeulich@suse.com>
>    Signed-off-by: Andy Lutomirski <luto@kernel.org>
>    Cc: Andrew Cooper <andrew.cooper3@citrix.com>
>    Cc: Andy Lutomirski <luto@amacapital.net>
>    Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>    Cc: Borislav Petkov <bp@alien8.de>
>    Cc: Brian Gerst <brgerst@gmail.com>
>    Cc: David Vrabel <david.vrabel@citrix.com>
>    Cc: Denys Vlasenko <dvlasenk@redhat.com>
>    Cc: H. Peter Anvin <hpa@zytor.com>
>    Cc: Jan Beulich <JBeulich@suse.com>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Cc: stable@vger.kernel.org
>    Link: http://lkml.kernel.org/r/8ce12013e6e4c0a44a97e316be4a6faff31bd5ea.1458162709.git.luto@kernel.org
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 452718f54822d63ffff0aebb713c5ccd722fd050
>Author: Dmitry V. Levin <ldv@altlinux.org>
>Date:   Thu Mar 19 11:10:54 2015 +0000
>
>    vfs: show_vfsstat: do not ignore errors from show_devname method
>    
>    [ Upstream commit 5f8d498d4364f544fee17125787a47553db02afa ]
>    
>    Explicitly check show_devname method return code and bail out in case
>    of an error.  This fixes regression introduced by commit 9d4d65748a5c.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
>    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 03d44e3d9dd7744fe97ca472fce1725b7179fa2f
>Author: J. Bruce Fields <bfields@redhat.com>
>Date:   Wed Mar 2 16:36:21 2016 -0800
>
>    nfsd: fix deadlock secinfo+readdir compound
>    
>    [ Upstream commit 2f6fc056e899bd0144a08da5cacaecbe8997cd74 ]
>    
>    nfsd_lookup_dentry exits with the parent filehandle locked.  fh_put also
>    unlocks if necessary (nfsd filehandle locking is probably too lenient),
>    so it gets unlocked eventually, but if the following op in the compound
>    needs to lock it again, we can deadlock.
>    
>    A fuzzer ran into this; normal clients don't send a secinfo followed by
>    a readdir in the same compound.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4fa1657957f668fcc9606268df01bc0f3e4f1379
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Tue Mar 15 15:20:58 2016 +0100
>
>    ALSA: usb-audio: Add sanity checks for endpoint accesses
>    
>    [ Upstream commit 447d6275f0c21f6cc97a88b3a0c601436a4cdf2a ]
>    
>    Add some sanity check codes before actually accessing the endpoint via
>    get_endpoint() in order to avoid the invalid access through a
>    malformed USB descriptor.  Mostly just checking bNumEndpoints, but in
>    one place (snd_microii_spdif_default_get()), the validity of iface and
>    altsetting index is checked as well.
>    
>    Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=971125
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6ed72ce6ab8b38803b12df8c62a3a52becf19017
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Tue Mar 15 12:09:10 2016 +0100
>
>    ALSA: usb-audio: Fix NULL dereference in create_fixed_stream_quirk()
>    
>    [ Upstream commit 0f886ca12765d20124bd06291c82951fd49a33be ]
>    
>    create_fixed_stream_quirk() may cause a NULL-pointer dereference by
>    accessing the non-existing endpoint when a USB device with a malformed
>    USB descriptor is used.
>    
>    This patch avoids it simply by adding a sanity check of bNumEndpoints
>    before the accesses.
>    
>    Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=971125
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4084f3ab4ddb216046de8e3d8652398e9477c03e
>Author: Magnus Damm <damm+renesas@opensource.se>
>Date:   Tue Feb 16 13:06:41 2016 +0900
>
>    mmc: mmc_spi: Add Card Detect comments and fix CD GPIO case
>    
>    [ Upstream commit bcdc9f260bdce09913db1464be9817170d51044a ]
>    
>    This patch fixes the MMC SPI driver from doing polling card detect when a
>    CD GPIO that supports interrupts is specified using the gpios DT property.
>    
>    Without this patch the DT node below results in the following output:
>    
>     spi_gpio: spi-gpio { /* SD2 @ CN12 */
>             compatible = "spi-gpio";
>             #address-cells = <1>;
>             #size-cells = <0>;
>             gpio-sck = <&gpio6 16 GPIO_ACTIVE_HIGH>;
>             gpio-mosi = <&gpio6 17 GPIO_ACTIVE_HIGH>;
>             gpio-miso = <&gpio6 18 GPIO_ACTIVE_HIGH>;
>             num-chipselects = <1>;
>             cs-gpios = <&gpio6 21 GPIO_ACTIVE_LOW>;
>             status = "okay";
>    
>             spi@0 {
>                     compatible = "mmc-spi-slot";
>                     reg = <0>;
>                     voltage-ranges = <3200 3400>;
>                     spi-max-frequency = <25000000>;
>                     gpios = <&gpio6 22 GPIO_ACTIVE_LOW>;   /* CD */
>             };
>     };
>    
>     # dmesg | grep mmc
>     mmc_spi spi32766.0: SD/MMC host mmc0, no WP, no poweroff, cd polling
>     mmc0: host does not support reading read-only switch, assuming write-enable
>     mmc0: new SDHC card on SPI
>     mmcblk0: mmc0:0000 SU04G 3.69 GiB
>     mmcblk0: p1
>    
>    With this patch applied the "cd polling" portion above disappears.
>    
>    Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
>    Cc: stable@vger.kernel.org # v3.18+
>    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 44a3704dbaf34034426db30963d453d1796693fe
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Tue Mar 15 16:44:55 2016 +0100
>
>    ALSA: hda - Fix unconditional GPIO toggle via automute
>    
>    [ Upstream commit 1f7c6658962fa1260c1658d681bd6bb0c746b99a ]
>    
>    Cirrus HD-audio driver may adjust GPIO pins for EAPD dynamically
>    depending on the jack plug state.  This works fine for the auto-mute
>    mode where the speaker gets muted upon the HP jack plug.   OTOH, when
>    the auto-mute mode is off, this turns off the EAPD unexpectedly
>    depending on the jack state, which results in the silent speaker
>    output.
>    
>    This patch fixes the silent speaker output issue by setting GPIO bits
>    constantly when the auto-mute mode is off.
>    
>    Reported-and-tested-by: moosotc@gmail.com
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 33184f68f4b527a6582e8fc5e94a7a7b6ba9c588
>Author: Dmitry Torokhov <dtor@chromium.org>
>Date:   Mon Mar 14 15:21:04 2016 -0700
>
>    HID: i2c-hid: fix OOB write in i2c_hid_set_or_send_report()
>    
>    [ Upstream commit 3b654288b196ceaa156029d9457ccbded0489b98 ]
>    
>    Even though hid_hw_* checks that passed in data_len is less than
>    HID_MAX_BUFFER_SIZE it is not enough, as i2c-hid does not necessarily
>    allocate buffers of HID_MAX_BUFFER_SIZE but rather checks all device
>    reports and select largest size. In-kernel users normally just send as much
>    data as report needs, so there is no problem, but hidraw users can do
>    whatever they please:
>    
>    BUG: KASAN: slab-out-of-bounds in memcpy+0x34/0x54 at addr ffffffc07135ea80
>    Write of size 4101 by task syz-executor/8747
>    CPU: 2 PID: 8747 Comm: syz-executor Tainted: G    BU         3.18.0 #37
>    Hardware name: Google Tegra210 Smaug Rev 1,3+ (DT)
>    Call trace:
>    [<ffffffc00020ebcc>] dump_backtrace+0x0/0x258 arch/arm64/kernel/traps.c:83
>    [<ffffffc00020ee40>] show_stack+0x1c/0x2c arch/arm64/kernel/traps.c:172
>    [<     inline     >] __dump_stack lib/dump_stack.c:15
>    [<ffffffc001958114>] dump_stack+0x90/0x140 lib/dump_stack.c:50
>    [<     inline     >] print_error_description mm/kasan/report.c:97
>    [<     inline     >] kasan_report_error mm/kasan/report.c:278
>    [<ffffffc0004597dc>] kasan_report+0x268/0x530 mm/kasan/report.c:305
>    [<ffffffc0004592e8>] __asan_storeN+0x20/0x150 mm/kasan/kasan.c:718
>    [<ffffffc0004594e0>] memcpy+0x30/0x54 mm/kasan/kasan.c:299
>    [<ffffffc001306354>] __i2c_hid_command+0x2b0/0x7b4 drivers/hid/i2c-hid/i2c-hid.c:178
>    [<     inline     >] i2c_hid_set_or_send_report drivers/hid/i2c-hid/i2c-hid.c:321
>    [<ffffffc0013079a0>] i2c_hid_output_raw_report.isra.2+0x3d4/0x4b8 drivers/hid/i2c-hid/i2c-hid.c:589
>    [<ffffffc001307ad8>] i2c_hid_output_report+0x54/0x68 drivers/hid/i2c-hid/i2c-hid.c:602
>    [<     inline     >] hid_hw_output_report include/linux/hid.h:1039
>    [<ffffffc0012cc7a0>] hidraw_send_report+0x400/0x414 drivers/hid/hidraw.c:154
>    [<ffffffc0012cc7f4>] hidraw_write+0x40/0x64 drivers/hid/hidraw.c:177
>    [<ffffffc0004681dc>] vfs_write+0x1d4/0x3cc fs/read_write.c:534
>    [<     inline     >] SYSC_pwrite64 fs/read_write.c:627
>    [<ffffffc000468984>] SyS_pwrite64+0xec/0x144 fs/read_write.c:614
>    Object at ffffffc07135ea80, in cache kmalloc-512
>    Object allocated with size 268 bytes.
>    
>    Let's check data length against the buffer size before attempting to copy
>    data over.
>    
>    Cc: stable@vger.kernel.org
>    Reported-by: Alexander Potapenko <glider@google.com>
>    Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
>    Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit deba7b5dcc897d28bb84c0c029ec13f738416580
>Author: Dmitri Epshtein <dima@marvell.com>
>Date:   Sat Mar 12 18:44:18 2016 +0100
>
>    net: mvneta: enable change MAC address when interface is up
>    
>    [ Upstream commit 928b6519afeb2a5e2dc61154380b545ed66c476a ]
>    
>    Function eth_prepare_mac_addr_change() is called as part of MAC
>    address change. This function check if interface is running.
>    To enable change MAC address when interface is running:
>    IFF_LIVE_ADDR_CHANGE flag must be set to dev->priv_flags field
>    
>    Fixes: c5aff18204da ("net: mvneta: driver for Marvell Armada 370/XP
>    network unit")
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Dmitri Epshtein <dima@marvell.com>
>    Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 79deb9b280a508c77f6cc233e083544712bc2458
>Author: Ming Lei <ming.lei@canonical.com>
>Date:   Sat Mar 12 09:29:40 2016 +0800
>
>    md: multipath: don't hardcopy bio in .make_request path
>    
>    [ Upstream commit fafcde3ac1a418688a734365203a12483b83907a ]
>    
>    Inside multipath_make_request(), multipath maps the incoming
>    bio into low level device's bio, but it is totally wrong to
>    copy the bio into mapped bio via '*mapped_bio = *bio'. For
>    example, .__bi_remaining is kept in the copy, especially if
>    the incoming bio is chained to via bio splitting, so .bi_end_io
>    can't be called for the mapped bio at all in the completing path
>    in this kind of situation.
>    
>    This patch fixes the issue by using clone style.
>    
>    Cc: stable@vger.kernel.org (v3.14+)
>    Reported-and-tested-by: Andrea Righi <righi.andrea@gmail.com>
>    Signed-off-by: Ming Lei <ming.lei@canonical.com>
>    Signed-off-by: Shaohua Li <shli@fb.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1a5aee1aaa9110ee4ba03f665f75b8b9ab21fd2c
>Author: Alex Deucher <alexander.deucher@amd.com>
>Date:   Thu Mar 10 15:55:26 2016 -0500
>
>    drm/radeon: rework fbdev handling on chips with no connectors
>    
>    [ Upstream commit e5f243bd2edd95c6cc1d90c1878f821068e83fba ]
>    
>    Move all the logic to radeon_fb.c and add checks to functions
>    called frome elsewhere.
>    
>    bug:
>    https://bugzilla.kernel.org/show_bug.cgi?id=112781
>    
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 76b69dfeb5f1bf19a6bd65991506bbb00647716b
>Author: Josh Boyer <jwboyer@fedoraproject.org>
>Date:   Mon Mar 14 09:33:40 2016 -0700
>
>    Input: powermate - fix oops with malicious USB descriptors
>    
>    [ Upstream commit 9c6ba456711687b794dcf285856fc14e2c76074f ]
>    
>    The powermate driver expects at least one valid USB endpoint in its
>    probe function.  If given malicious descriptors that specify 0 for
>    the number of endpoints, it will crash.  Validate the number of
>    endpoints on the interface before using them.
>    
>    The full report for this issue can be found here:
>    http://seclists.org/bugtraq/2016/Mar/85
>    
>    Reported-by: Ralf Spenneberg <ralf@spenneberg.net>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
>    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1ee3901b99f165a4fa3ba85ff08d11bc2f61eec4
>Author: Sebastian Ott <sebott@linux.vnet.ibm.com>
>Date:   Mon Mar 14 15:47:23 2016 +0100
>
>    s390/pci: enforce fmb page boundary rule
>    
>    [ Upstream commit 80c544ded25ac14d7cc3e555abb8ed2c2da99b84 ]
>    
>    The function measurement block must not cross a page boundary. Ensure
>    that by raising the alignment requirement to the smallest power of 2
>    larger than the size of the fmb.
>    
>    Fixes: d0b088531 ("s390/pci: performance statistics and debug infrastructure")
>    Cc: stable@vger.kernel.org # v3.8+
>    Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
>    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit bbd5f23b1eaba29f46f97846b361fab4c5becc78
>Author: Seth Forshee <seth.forshee@canonical.com>
>Date:   Fri Mar 11 10:35:34 2016 -0600
>
>    fuse: Add reference counting for fuse_io_priv
>    
>    [ Upstream commit 744742d692e37ad5c20630e57d526c8f2e2fe3c9 ]
>    
>    The 'reqs' member of fuse_io_priv serves two purposes. First is to track
>    the number of oustanding async requests to the server and to signal that
>    the io request is completed. The second is to be a reference count on the
>    structure to know when it can be freed.
>    
>    For sync io requests these purposes can be at odds.  fuse_direct_IO() wants
>    to block until the request is done, and since the signal is sent when
>    'reqs' reaches 0 it cannot keep a reference to the object. Yet it needs to
>    use the object after the userspace server has completed processing
>    requests. This leads to some handshaking and special casing that it
>    needlessly complicated and responsible for at least one race condition.
>    
>    It's much cleaner and safer to maintain a separate reference count for the
>    object lifecycle and to let 'reqs' just be a count of outstanding requests
>    to the userspace server. Then we can know for sure when it is safe to free
>    the object without any handshaking or special cases.
>    
>    The catch here is that most of the time these objects are stack allocated
>    and should not be freed. Initializing these objects with a single reference
>    that is never released prevents accidental attempts to free the objects.
>    
>    Fixes: 9d5722b7777e ("fuse: handle synchronous iocbs internally")
>    Cc: stable@vger.kernel.org # v4.1+
>    Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
>    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 19167d65fabb60ff11fc5f9c4a5248c17a12f615
>Author: Robert Doebbelin <robert@quobyte.com>
>Date:   Mon Mar 7 09:50:56 2016 +0100
>
>    fuse: do not use iocb after it may have been freed
>    
>    [ Upstream commit 7cabc61e01a0a8b663bd2b4c982aa53048218734 ]
>    
>    There's a race in fuse_direct_IO(), whereby is_sync_kiocb() is called on an
>    iocb that could have been freed if async io has already completed.  The fix
>    in this case is simple and obvious: cache the result before starting io.
>    
>    It was discovered by KASan:
>    
>    kernel: ==================================================================
>    kernel: BUG: KASan: use after free in fuse_direct_IO+0xb1a/0xcc0 at addr ffff88036c414390
>    
>    Signed-off-by: Robert Doebbelin <robert@quobyte.com>
>    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
>    Fixes: bcba24ccdc82 ("fuse: enable asynchronous processing direct IO")
>    Cc: <stable@vger.kernel.org> # 3.10+
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f9162af6d940378c5fc24ec379f13a63edd15308
>Author: Vittorio Gambaletta (VittGam) <linuxbugs@vittgam.net>
>Date:   Sun Mar 13 22:19:34 2016 +0100
>
>    ALSA: intel8x0: Add clock quirk entry for AD1981B on IBM ThinkPad X41.
>    
>    [ Upstream commit 4061db03dd71d195b9973ee466f6ed32f6a3fc16 ]
>    
>    The clock measurement on the AC'97 audio card found in the IBM ThinkPad X41
>    will often fail, so add a quirk entry to fix it.
>    
>    Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=441087
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e484f76c1c1a601a7db84b4b6fb83f5243bf9951
>Author: Sasha Levin <sasha.levin@oracle.com>
>Date:   Thu Apr 7 18:19:07 2016 -0400
>
>    ALSA: hda - Add new GPU codec ID 0x10de0083 to snd-hda
>    
>    [ Upstream commit 3ec622f40913ae036f218e5e7e92df9c1f1753d9 ]
>    
>    Vendor ID 0x10de0083 is used by a yet-to-be-named GPU chip.
>    
>    This chip also has the 2-ch audio swapping bug, so patch_nvhdmi is
>    appropriate here.
>    
>    Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 84d5e27af4b08156ee63e73ca40cf247bcfeb760
>Author: Aaron Plattner <aplattner@nvidia.com>
>Date:   Sun Mar 13 13:58:57 2016 -0700
>
>    ALSA: hda - Add new GPU codec ID 0x10de0082 to snd-hda
>    
>    [ Upstream commit 2d369c748c2ecc2a012ee85412a04007e67913ec ]
>    
>    Vendor ID 0x10de0082 is used by a yet-to-be-named GPU chip.
>    
>    This chip also has the 2-ch audio swapping bug, so patch_nvhdmi is
>    appropriate here.
>    
>    Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e805ad22beb02c746c741c60508867ffd76463f4
>Author: Fabio Estevam <fabio.estevam@nxp.com>
>Date:   Mon Feb 22 09:01:53 2016 -0300
>
>    bus: imx-weim: Take the 'status' property value into account
>    
>    [ Upstream commit 33b96d2c9579213cf3f36d7b29841b1e464750c4 ]
>    
>    Currently we have an incorrect behaviour when multiple devices
>    are present under the weim node. For example:
>    
>    &weim {
>    	...
>    	status = "okay";
>    
>    	sram@0,0 {
>    		...
>            	status = "okay";
>    	};
>    
>    	mram@0,0 {
>    		...
>            	status = "disabled";
>        	};
>    };
>    
>    In this case only the 'sram' device should be probed and not 'mram'.
>    
>    However what happens currently is that the status variable is ignored,
>    causing the 'sram' device to be disabled and 'mram' to be enabled.
>    
>    Change the weim_parse_dt() function to use
>    for_each_available_child_of_node()so that the devices marked with
>    'status = disabled' are not probed.
>    
>    Cc: <stable@vger.kernel.org>
>    Suggested-by: Wolfgang Netbal <wolfgang.netbal@sigmatek.at>
>    Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
>    Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
>    Acked-by: Shawn Guo <shawnguo@kernel.org>
>    Signed-off-by: Olof Johansson <olof@lixom.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e0247000f2d3bd6e8e6061f4ed536d50cbf4f077
>Author: Max Filippov <jcmvbkbc@gmail.com>
>Date:   Thu Mar 3 18:34:29 2016 +0300
>
>    xtensa: clear all DBREAKC registers on start
>    
>    [ Upstream commit 7de7ac785ae18a2cdc78d7560f48e3213d9ea0ab ]
>    
>    There are XCHAL_NUM_DBREAK registers, clear them all.
>    This also fixes cryptic assembler error message with binutils 2.25 when
>    XCHAL_NUM_DBREAK is 0:
>    
>      as: out of memory allocating 18446744073709551575 bytes after a total
>      of 495616 bytes
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8375d5ea6e7810b56bf9c43f4fc3abef8a3fcdfe
>Author: Max Filippov <jcmvbkbc@gmail.com>
>Date:   Thu Feb 25 23:27:51 2016 +0300
>
>    xtensa: fix preemption in {clear,copy}_user_highpage
>    
>    [ Upstream commit a67cc9aa2dfc6e66addf240bbd79e16e01565e81 ]
>    
>    Disabling pagefault makes little sense there, preemption disabling is
>    what was meant.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1ef6e487322a28195a9e68bd376944b7ec6db6c2
>Author: Max Filippov <jcmvbkbc@gmail.com>
>Date:   Tue Feb 9 01:02:38 2016 +0300
>
>    xtensa: ISS: don't hang if stdin EOF is reached
>    
>    [ Upstream commit 362014c8d9d51d504c167c44ac280169457732be ]
>    
>    Simulator stdin may be connected to a file, when its end is reached
>    kernel hangs in infinite loop inside rs_poll, because simc_poll always
>    signals that descriptor 0 is readable and simc_read always returns 0.
>    Check simc_read return value and exit loop if it's not positive. Also
>    don't rewind polling timer if it's zero.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a14fea4d0284643ffd8538d2204cfb1fa8ac804d
>Author: Hui Wang <hui.wang@canonical.com>
>Date:   Fri Mar 11 12:04:02 2016 +0800
>
>    ALSA: hda - fix the mic mute button and led problem for a Lenovo AIO
>    
>    [ Upstream commit 6ef2f68fa38bf415830f67903d87180d933e0f47 ]
>    
>    This Lenovo ThinkCentre AIO also uses Line2 as mic mute button and
>    uses GPIO2 to control the mic mute led, so applying this quirk can
>    make both the button and led work.
>    
>    Cc: stable@vger.kernel.org
>    BugLink: https://bugs.launchpad.net/bugs/1555912
>    Signed-off-by: Hui Wang <hui.wang@canonical.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 843513677254865b92c551339103e8eaa2b07669
>Author: Jenny Derzhavetz <jennyf@mellanox.com>
>Date:   Wed Feb 24 19:24:00 2016 +0200
>
>    iser-target: Separate flows for np listeners and connections cma events
>    
>    [ Upstream commit f81bf458208ef6d12b2fc08091204e3859dcdba4 ]
>    
>    No need to restrict this check to specific events.
>    
>    Signed-off-by: Jenny Derzhavetz <jennyf@mellanox.com>
>    Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
>    Cc: stable@vger.kernel.org # v3.10+
>    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 82ba90c00ba7e4ffd31a1ad8a5ed224c8e6f3d37
>Author: Jenny Derzhavetz <jennyf@mellanox.com>
>Date:   Wed Feb 24 19:23:59 2016 +0200
>
>    iser-target: Add new state ISER_CONN_BOUND to isert_conn
>    
>    [ Upstream commit aea92980601f7ddfcb3c54caa53a43726314fe46 ]
>    
>    We need an indication that isert_conn->iscsi_conn binding has
>    happened so we'll know not to invoke a connection reinstatement
>    on an unbound connection which will lead to a bogus isert_conn->conn
>    dereferece.
>    
>    Signed-off-by: Jenny Derzhavetz <jennyf@mellanox.com>
>    Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
>    Cc: stable@vger.kernel.org # v3.10+
>    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3c6961458165c0ec909d68191bff4de7bdf50549
>Author: Jenny Derzhavetz <jennyf@mellanox.com>
>Date:   Wed Feb 24 19:23:58 2016 +0200
>
>    iser-target: Fix identification of login rx descriptor type
>    
>    [ Upstream commit b89a7c25462b164db280abc3b05d4d9d888d40e9 ]
>    
>    Once connection request is accepted, one rx descriptor
>    is posted to receive login request. This descriptor has rx type,
>    but is outside the main pool of rx descriptors, and thus
>    was mistreated as tx type.
>    
>    Signed-off-by: Jenny Derzhavetz <jennyf@mellanox.com>
>    Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
>    Cc: stable@vger.kernel.org # v3.10+
>    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 78243d0a1221f06af96a8952cd5ac71cd1fe5376
>Author: Joe Thornber <ejt@redhat.com>
>Date:   Tue Mar 1 10:58:44 2016 +0000
>
>    dm thin metadata: don't issue prefetches if a transaction abort has failed
>    
>    [ Upstream commit 2eae9e4489b4cf83213fa3bd508b5afca3f01780 ]
>    
>    If a transaction abort has failed then we can no longer use the metadata
>    device.  Typically this happens if the superblock is unreadable.
>    
>    This fix addresses a crash seen during metadata device failure testing.
>    
>    Fixes: 8a01a6af75 ("dm thin: prefetch missing metadata pages")
>    Cc: stable@vger.kernel.org # 3.19+
>    Signed-off-by: Joe Thornber <ejt@redhat.com>
>    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 14a33fc00969143f9d5935f486f238e98cc839d8
>Author: Dmitry Tunin <hanipouspilot@gmail.com>
>Date:   Fri Mar 4 01:32:19 2016 +0300
>
>    Bluetooth: btusb: Add a new AR3012 ID 13d3:3472
>    
>    [ Upstream commit 75c6aca4765dbe3d0c1507ab5052f2e373dc2331 ]
>    
>    T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
>    D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
>    P: Vendor=13d3 ProdID=3472 Rev=00.01
>    C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
>    I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
>    I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
>    
>    BugLink: https://bugs.launchpad.net/bugs/1552925
>    
>    Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
>    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b314ace942506718f3c3bc2787f700bf49d84ea2
>Author: Luck, Tony <tony.luck@intel.com>
>Date:   Wed Mar 9 16:40:48 2016 -0800
>
>    EDAC/sb_edac: Fix computation of channel address
>    
>    [ Upstream commit eb1af3b71f9d83e45f2fd2fd649356e98e1c582c ]
>    
>    Large memory Haswell-EX systems with multiple DIMMs per channel were
>    sometimes reporting the wrong DIMM.
>    
>    Found three problems:
>    
>     1) Debug printouts for socket and channel interleave were not interpreting
>        the register fields correctly. The socket interleave field is a 2^X
>        value (0=1, 1=2, 2=4, 3=8). The channel interleave is X+1 (0=1, 1=2,
>        2=3. 3=4).
>    
>     2) Actual use of the socket interleave value didn't interpret as 2^X
>    
>     3) Conversion of address to channel address was complicated, and wrong.
>    
>    Signed-off-by: Tony Luck <tony.luck@intel.com>
>    Acked-by: Aristeu Rozanski <arozansk@redhat.com>
>    Cc: Borislav Petkov <bp@alien8.de>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Cc: linux-edac@vger.kernel.org
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3b6a70271a4e1e72585b3a7236cbd17d646b38d1
>Author: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
>Date:   Wed Mar 9 23:47:25 2016 -0500
>
>    jbd2: fix FS corruption possibility in jbd2_journal_destroy() on umount path
>    
>    [ Upstream commit c0a2ad9b50dd80eeccd73d9ff962234590d5ec93 ]
>    
>    On umount path, jbd2_journal_destroy() writes latest transaction ID
>    (->j_tail_sequence) to be used at next mount.
>    
>    The bug is that ->j_tail_sequence is not holding latest transaction ID
>    in some cases. So, at next mount, there is chance to conflict with
>    remaining (not overwritten yet) transactions.
>    
>    	mount (id=10)
>    	write transaction (id=11)
>    	write transaction (id=12)
>    	umount (id=10) <= the bug doesn't write latest ID
>    
>    	mount (id=10)
>    	write transaction (id=11)
>    	crash
>    
>    	mount
>    	[recovery process]
>    		transaction (id=11)
>    		transaction (id=12) <= valid transaction ID, but old commit
>                                           must not replay
>    
>    Like above, this bug become the cause of recovery failure, or FS
>    corruption.
>    
>    So why ->j_tail_sequence doesn't point latest ID?
>    
>    Because if checkpoint transactions was reclaimed by memory pressure
>    (i.e. bdev_try_to_free_page()), then ->j_tail_sequence is not updated.
>    (And another case is, __jbd2_journal_clean_checkpoint_list() is called
>    with empty transaction.)
>    
>    So in above cases, ->j_tail_sequence is not pointing latest
>    transaction ID at umount path. Plus, REQ_FLUSH for checkpoint is not
>    done too.
>    
>    So, to fix this problem with minimum changes, this patch updates
>    ->j_tail_sequence, and issue REQ_FLUSH.  (With more complex changes,
>    some optimizations would be possible to avoid unnecessary REQ_FLUSH
>    for example though.)
>    
>    BTW,
>    
>    	journal->j_tail_sequence =
>    		++journal->j_transaction_sequence;
>    
>    Increment of ->j_transaction_sequence seems to be unnecessary, but
>    ext3 does this.
>    
>    Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
>    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6908e712e3f0df114e64f71de084ea8c4829e19f
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Thu Mar 10 11:33:43 2016 +0100
>
>    ALSA: hda - Apply reboot D3 fix for CX20724 codec, too
>    
>    [ Upstream commit 56dc66ff1c6d71f9a38c4a7c000b72b921fe4c89 ]
>    
>    Just like CX20722, CX7024 codec also requires the power down at reboot
>    in order to reduce the noise at reboot/shutdown.
>    
>    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=113511
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 685a50b681ddd07ff2b7714797b5793adcc691e7
>Author: Douglas Gilbert <dgilbert@interlog.com>
>Date:   Thu Mar 3 00:31:29 2016 -0500
>
>    sg: fix dxferp in from_to case
>    
>    [ Upstream commit 5ecee0a3ee8d74b6950cb41e8989b0c2174568d4 ]
>    
>    One of the strange things that the original sg driver did was let the
>    user provide both a data-out buffer (it followed the sg_header+cdb)
>    _and_ specify a reply length greater than zero. What happened was that
>    the user data-out buffer was copied into some kernel buffers and then
>    the mid level was told a read type operation would take place with the
>    data from the device overwriting the same kernel buffers. The user would
>    then read those kernel buffers back into the user space.
>    
>    From what I can tell, the above action was broken by commit fad7f01e61bf
>    ("sg: set dxferp to NULL for READ with the older SG interface") in 2008
>    and syzkaller found that out recently.
>    
>    Make sure that a user space pointer is passed through when data follows
>    the sg_header structure and command.  Fix the abnormal case when a
>    non-zero reply_len is also given.
>    
>    Fixes: fad7f01e61bf737fe8a3740d803f000db57ecac6
>    Cc: <stable@vger.kernel.org> #v2.6.28+
>    Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
>    Reviewed-by: Ewan Milne <emilne@redhat.com>
>    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d61ff6bc3f68be716226091e6ffa3b47b01a29cb
>Author: Mario Kleiner <mario.kleiner.de@gmail.com>
>Date:   Sun Mar 6 02:39:53 2016 +0100
>
>    drm/radeon: Don't drop DP 2.7 Ghz link setup on some cards.
>    
>    [ Upstream commit 459ee1c3fd097ab56ababd8ff4bb7ef6a792de33 ]
>    
>    As observed on Apple iMac10,1, DCE-3.2, RV-730,
>    link rate of 2.7 Ghz is not selected, because
>    the args.v1.ucConfig flag setting for 2.7 Ghz
>    gets overwritten by a following assignment of
>    the transmitter to use.
>    
>    Move link rate setup a few lines down to fix this.
>    In practice this didn't have any positive or
>    negative effect on display setup on the tested
>    iMac10,1 so i don't know if backporting to stable
>    makes sense or not.
>    
>    Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0dd18e03c1bdfe39f01b2e56dc66c3be90fa67a0
>Author: Alex Deucher <alexander.deucher@amd.com>
>Date:   Wed Mar 2 11:47:29 2016 -0500
>
>    drm/radeon: disable runtime pm on PX laptops without dGPU power control
>    
>    [ Upstream commit e64c952efb8e0c15ae82cec8e455ab4910690ef1 ]
>    
>    Some PX laptops don't provide an ACPI method to control dGPU power.  On
>    those systems, the driver is responsible for handling the dGPU power
>    state.  Disable runtime PM on them until support for this is implemented.
>    
>    Reviewed-by: Michel DÃ¤nzer <michel.daenzer@amd.com>
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 88e2df1b99cfc0087ccd2faa8ca61d7263fc007a
>Author: NeilBrown <neilb@suse.com>
>Date:   Wed Mar 9 12:58:25 2016 +1100
>
>    md/raid5: preserve STRIPE_PREREAD_ACTIVE in break_stripe_batch_list
>    
>    [ Upstream commit 550da24f8d62fe81f3c13e3ec27602d6e44d43dc ]
>    
>    break_stripe_batch_list breaks up a batch and copies some flags from
>    the batch head to the members, preserving others.
>    
>    It doesn't preserve or copy STRIPE_PREREAD_ACTIVE.  This is not
>    normally a problem as STRIPE_PREREAD_ACTIVE is cleared when a
>    stripe_head is added to a batch, and is not set on stripe_heads
>    already in a batch.
>    
>    However there is no locking to ensure one thread doesn't set the flag
>    after it has just been cleared in another.  This does occasionally happen.
>    
>    md/raid5 maintains a count of the number of stripe_heads with
>    STRIPE_PREREAD_ACTIVE set: conf->preread_active_stripes.  When
>    break_stripe_batch_list clears STRIPE_PREREAD_ACTIVE inadvertently
>    this could becomes incorrect and will never again return to zero.
>    
>    md/raid5 delays the handling of some stripe_heads until
>    preread_active_stripes becomes zero.  So when the above mention race
>    happens, those stripe_heads become blocked and never progress,
>    resulting is write to the array handing.
>    
>    So: change break_stripe_batch_list to preserve STRIPE_PREREAD_ACTIVE
>    in the members of a batch.
>    
>    URL: https://bugzilla.kernel.org/show_bug.cgi?id=108741
>    URL: https://bugzilla.redhat.com/show_bug.cgi?id=1258153
>    URL: http://thread.gmane.org/5649C0E9.2030204@zoner.cz
>    Reported-by: Martin Svec <martin.svec@zoner.cz> (and others)
>    Tested-by: Tom Weber <linux@junkyard.4t2.com>
>    Fixes: 1b956f7a8f9a ("md/raid5: be more selective about distributing flags across batch.")
>    Cc: stable@vger.kernel.org (v4.1 and later)
>    Signed-off-by: NeilBrown <neilb@suse.com>
>    Signed-off-by: Shaohua Li <shli@fb.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d5226186331401679a52df554a9607022e470983
>Author: Maurizio Lombardi <mlombard@redhat.com>
>Date:   Fri Mar 4 10:41:49 2016 +0100
>
>    be2iscsi: set the boot_kset pointer to NULL in case of failure
>    
>    [ Upstream commit 84bd64993f916bcf86270c67686ecf4cea7b8933 ]
>    
>    In beiscsi_setup_boot_info(), the boot_kset pointer should be set to
>    NULL in case of failure otherwise an invalid pointer dereference may
>    occur later.
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
>    Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
>    Reviewed-by: Jitendra Bhivare <jitendra.bhivare@broadcom.com>
>    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit fcc5834794fdcb62637a1deb25bff5787bf73757
>Author: Bjorn Helgaas <bhelgaas@google.com>
>Date:   Fri Feb 26 09:15:11 2016 -0600
>
>    x86/PCI: Mark Broadwell-EP Home Agent & PCU as having non-compliant BARs
>    
>    [ Upstream commit b894157145e4ac7598d7062bc93320898a5e059e ]
>    
>    The Home Agent and PCU PCI devices in Broadwell-EP have a non-BAR register
>    where a BAR should be.  We don't know what the side effects of sizing the
>    "BAR" would be, and we don't know what address space the "BAR" might appear
>    to describe.
>    
>    Mark these devices as having non-compliant BARs so the PCI core doesn't
>    touch them.
>    
>    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>    Tested-by: Andi Kleen <ak@linux.intel.com>
>    CC: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d09a05998d79dcfaa25de84624dce9f806fe4e7c
>Author: Eric Wheeler <git@linux.ewheeler.net>
>Date:   Mon Mar 7 15:17:50 2016 -0800
>
>    bcache: fix cache_set_flush() NULL pointer dereference on OOM
>    
>    [ Upstream commit f8b11260a445169989d01df75d35af0f56178f95 ]
>    
>    When bch_cache_set_alloc() fails to kzalloc the cache_set, the
>    asyncronous closure handling tries to dereference a cache_set that
>    hadn't yet been allocated inside of cache_set_flush() which is called
>    by __cache_set_unregister() during cleanup.  This appears to happen only
>    during an OOM condition on bcache_register.
>    
>    Signed-off-by: Eric Wheeler <bcache@linux.ewheeler.net>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0e6555443a206655885bc4126d9a3a0e2d9d17a3
>Author: Eric Wheeler <git@linux.ewheeler.net>
>Date:   Fri Feb 26 14:33:56 2016 -0800
>
>    bcache: cleaned up error handling around register_cache()
>    
>    [ Upstream commit 9b299728ed777428b3908ac72ace5f8f84b97789 ]
>    
>    Fix null pointer dereference by changing register_cache() to return an int
>    instead of being void.  This allows it to return -ENOMEM or -ENODEV and
>    enables upper layers to handle the OOM case without NULL pointer issues.
>    
>    See this thread:
>      http://thread.gmane.org/gmane.linux.kernel.bcache.devel/3521
>    
>    Fixes this error:
>      gargamel:/sys/block/md5/bcache# echo /dev/sdh2 > /sys/fs/bcache/register
>    
>      bcache: register_cache() error opening sdh2: cannot allocate memory
>      BUG: unable to handle kernel NULL pointer dereference at 00000000000009b8
>      IP: [<ffffffffc05a7e8d>] cache_set_flush+0x102/0x15c [bcache]
>      PGD 120dff067 PUD 1119a3067 PMD 0
>      Oops: 0000 [#1] SMP
>      Modules linked in: veth ip6table_filter ip6_tables
>      (...)
>      CPU: 4 PID: 3371 Comm: kworker/4:3 Not tainted 4.4.2-amd64-i915-volpreempt-20160213bc1 #3
>      Hardware name: System manufacturer System Product Name/P8H67-M PRO, BIOS 3904 04/27/2013
>      Workqueue: events cache_set_flush [bcache]
>      task: ffff88020d5dc280 ti: ffff88020b6f8000 task.ti: ffff88020b6f8000
>      RIP: 0010:[<ffffffffc05a7e8d>]  [<ffffffffc05a7e8d>] cache_set_flush+0x102/0x15c [bcache]
>    
>    Signed-off-by: Eric Wheeler <bcache@linux.ewheeler.net>
>    Tested-by: Marc MERLIN <marc@merlins.org>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7269554a57352f66aefb3e85cb7e11c4b63bba59
>Author: Eric Wheeler <git@linux.ewheeler.net>
>Date:   Fri Feb 26 14:39:06 2016 -0800
>
>    bcache: fix race of writeback thread starting before complete initialization
>    
>    [ Upstream commit 07cc6ef8edc47f8b4fc1e276d31127a0a5863d4d ]
>    
>    The bch_writeback_thread might BUG_ON in read_dirty() if
>    dc->sb==BDEV_STATE_DIRTY and bch_sectors_dirty_init has not yet completed
>    its related initialization.  This patch downs the dc->writeback_lock until
>    after initialization is complete, thus preventing bch_writeback_thread
>    from proceeding prematurely.
>    
>    See this thread:
>      http://thread.gmane.org/gmane.linux.kernel.bcache.devel/3453
>    
>    Signed-off-by: Eric Wheeler <bcache@linux.ewheeler.net>
>    Tested-by: Marc MERLIN <marc@merlins.org>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Jens Axboe <axboe@fb.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 23745ba7ffac8cffbe648812fe7dc485d6df9404
>Author: Chris Friesen <cbf123@mail.usask.ca>
>Date:   Sat Mar 5 23:18:48 2016 -0600
>
>    sched/cputime: Fix steal_account_process_tick() to always return jiffies
>    
>    [ Upstream commit f9c904b7613b8b4c85b10cd6b33ad41b2843fa9d ]
>    
>    The callers of steal_account_process_tick() expect it to return
>    whether a jiffy should be considered stolen or not.
>    
>    Currently the return value of steal_account_process_tick() is in
>    units of cputime, which vary between either jiffies or nsecs
>    depending on CONFIG_VIRT_CPU_ACCOUNTING_GEN.
>    
>    If cputime has nsecs granularity and there is a tiny amount of
>    stolen time (a few nsecs, say) then we will consider the entire
>    tick stolen and will not account the tick on user/system/idle,
>    causing /proc/stats to show invalid data.
>    
>    The fix is to change steal_account_process_tick() to accumulate
>    the stolen time and only account it once it's worth a jiffy.
>    
>    (Thanks to Frederic Weisbecker for suggestions to fix a bug in my
>    first version of the patch.)
>    
>    Signed-off-by: Chris Friesen <chris.friesen@windriver.com>
>    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
>    Cc: <stable@vger.kernel.org>
>    Cc: Frederic Weisbecker <fweisbec@gmail.com>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Link: http://lkml.kernel.org/r/56DBBDB8.40305@mail.usask.ca
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 559920294e5db893cf5abedb00f56c2d72bca8c8
>Author: Stephane Eranian <eranian@google.com>
>Date:   Thu Mar 3 20:50:40 2016 +0100
>
>    perf/x86/intel: Add definition for PT PMI bit
>    
>    [ Upstream commit 5690ae28e472d25e330ad0c637a5cea3fc39fb32 ]
>    
>    This patch adds a definition for GLOBAL_OVFL_STATUS bit 55
>    which is used with the Processor Trace (PT) feature.
>    
>    Signed-off-by: Stephane Eranian <eranian@google.com>
>    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>    Cc: <stable@vger.kernel.org>
>    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
>    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
>    Cc: Jiri Olsa <jolsa@redhat.com>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Cc: Vince Weaver <vincent.weaver@maine.edu>
>    Cc: adrian.hunter@intel.com
>    Cc: kan.liang@intel.com
>    Cc: namhyung@kernel.org
>    Link: http://lkml.kernel.org/r/1457034642-21837-2-git-send-email-eranian@google.com
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c7af1256a07538167fe1b14a6714e7b92cf82179
>Author: Andi Kleen <ak@linux.intel.com>
>Date:   Sun May 10 12:22:41 2015 -0700
>
>    x86: Add new MSRs and MSR bits used for Intel Skylake PMU support
>    
>    [ Upstream commit b83ff1c8617aac03a1cf807aafa848fe0f0908f2 ]
>    
>    Add new MSRs (LBR_INFO) and some new MSR bits used by the Intel Skylake
>    PMU driver.
>    
>    Signed-off-by: Andi Kleen <ak@linux.intel.com>
>    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Cc: eranian@google.com
>    Link: http://lkml.kernel.org/r/1431285767-27027-4-git-send-email-andi@firstfloor.org
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3068107c9442d27ab2f37d08fca7eb3e862d412a
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Fri Jul 17 16:27:33 2015 +0200
>
>    ALSA: hda - Check the return value from pm_runtime_get/put*()
>    
>    [ Upstream commit fbce23a0b95763dfc4961ce6240e055c39f497ed ]
>    
>    This patch changes the return type of snd_hdac_power_up/down() and
>    variants to pass the error code from the underlying
>    pm_runtime_get/put() calls.  Currently they are ignored, but in most
>    places, these should be handled properly.
>    
>    As an example, the regmap handler is updated to check the return value
>    and accesses the register only when the wakeup succeeds.
>    
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f05c1ef89e7a97f2b1345736574dbef033231001
>Author: Phil Elwell <phil@raspberrypi.org>
>Date:   Mon Feb 29 17:30:08 2016 -0800
>
>    pinctrl-bcm2835: Fix cut-and-paste error in "pull" parsing
>    
>    [ Upstream commit 2c7e3306d23864d49f686f22e56e180ff0fffb7f ]
>    
>    The DT bindings for pinctrl-bcm2835 allow both the function and pull
>    to contain either one entry or one per pin. However, an error in the
>    DT parsing can cause failures if the number of pulls differs from the
>    number of functions.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Eric Anholt <eric@anholt.net>
>    Signed-off-by: Phil Elwell <phil@raspberrypi.org>
>    Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
>    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7ba075c0574015dc329241f7754aed97c9cffae9
>Author: Radim KrÄmÃ¡Å <rkrcmar@redhat.com>
>Date:   Wed Mar 2 22:56:38 2016 +0100
>
>    KVM: i8254: change PIT discard tick policy
>    
>    [ Upstream commit 7dd0fdff145c5be7146d0ac06732ae3613412ac1 ]
>    
>    Discard policy uses ack_notifiers to prevent injection of PIT interrupts
>    before EOI from the last one.
>    
>    This patch changes the policy to always try to deliver the interrupt,
>    which makes a difference when its vector is in ISR.
>    Old implementation would drop the interrupt, but proposed one injects to
>    IRR, like real hardware would.
>    
>    The old policy breaks legacy NMI watchdogs, where PIT is used through
>    virtual wire (LVT0): PIT never sends an interrupt before receiving EOI,
>    thus a guest deadlock with disabled interrupts will stop NMIs.
>    
>    Note that NMI doesn't do EOI, so PIT also had to send a normal interrupt
>    through IOAPIC.  (KVM's PIT is deeply rotten and luckily not used much
>    in modern systems.)
>    
>    Even though there is a chance of regressions, I think we can fix the
>    LVT0 NMI bug without introducing a new tick policy.
>    
>    Cc: <stable@vger.kernel.org>
>    Reported-by: Yuki Shibuya <shibuya.yk@ncos.nec.co.jp>
>    Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
>    Signed-off-by: Radim KrÄmÃ¡Å <rkrcmar@redhat.com>
>    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8e1682fddbd122a565965a83a5f8235e8bcadc10
>Author: Oliver Neukum <oneukum@suse.com>
>Date:   Wed Feb 17 11:52:43 2016 +0100
>
>    usb: hub: fix a typo in hub_port_init() leading to wrong logic
>    
>    [ Upstream commit 0d5ce778c43bf888328231bcdce05d5c860655aa ]
>    
>    A typo of j for i led to a logic bug. To rule out future
>    confusion, the variable names are made meaningful.
>    
>    Signed-off-by: Oliver Neukum <ONeukum@suse.com>
>    CC: stable@vger.kernel.org
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 444cf5487d5f51a3ecce2a0dfe237156290dfc7f
>Author: Vinayak Menon <vinmenon@codeaurora.org>
>Date:   Mon Feb 22 19:15:44 2016 +0530
>
>    of: alloc anywhere from memblock if range not specified
>    
>    [ Upstream commit e53b50c0cbe392c946807abf7d07615a3c588642 ]
>    
>    early_init_dt_alloc_reserved_memory_arch passes end as 0 to
>    __memblock_alloc_base, when limits are not specified. But
>    __memblock_alloc_base takes end value of 0 as MEMBLOCK_ALLOC_ACCESSIBLE
>    and limits the end to memblock.current_limit. This results in regions
>    never being placed in HIGHMEM area, for e.g. CMA.
>    Let __memblock_alloc_base allocate from anywhere in memory if limits are
>    not specified.
>    
>    Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>    Signed-off-by: Vinayak Menon <vinmenon@codeaurora.org>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Rob Herring <robh@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 65963ead8aefa685ec2e22d403461101c243683e
>Author: Asai Thambi SP <asamymuthupa@micron.com>
>Date:   Wed Feb 24 21:18:20 2016 -0800
>
>    mtip32xx: Handle FTL rebuild failure state during device initialization
>    
>    [ Upstream commit aae4a033868c496adae86fc6f9c3e0c405bbf360 ]
>    
>    Allow device initialization to finish gracefully when it is in
>    FTL rebuild failure state. Also, recover device out of this state
>    after successfully secure erasing it.
>    
>    Signed-off-by: Selvan Mani <smani@micron.com>
>    Signed-off-by: Vignesh Gunasekaran <vgunasekaran@micron.com>
>    Signed-off-by: Asai Thambi S P <asamymuthupa@micron.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Jens Axboe <axboe@fb.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0e536ed27652e8d5d74e13378a8f48b52cb21c95
>Author: Asai Thambi SP <asamymuthupa@micron.com>
>Date:   Mon May 11 15:50:50 2015 -0700
>
>    mtip32xx: fix incorrectly setting MTIP_DDF_SEC_LOCK_BIT
>    
>    [ Upstream commit ee04bed690cb49a49512a641405bac42d13c2b2a ]
>    
>    Fix incorrectly setting MTIP_DDF_SEC_LOCK_BIT
>    
>    Signed-off-by: Selvan Mani <smani@micron.com>
>    Signed-off-by: Asai Thambi S P <asamymuthupa@micron.com>
>    Signed-off-by: Jens Axboe <axboe@fb.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit afc16b3aab195d12ad40546d3cffcab5e3511ead
>Author: Asai Thambi SP <asamymuthupa@micron.com>
>Date:   Wed Feb 24 21:18:10 2016 -0800
>
>    mtip32xx: Handle safe removal during IO
>    
>    [ Upstream commit 51c6570eb922146470c2fe660c34585414679bd6 ]
>    
>    Flush inflight IOs using fsync_bdev() when the device is safely
>    removed. Also, block further IOs in device open function.
>    
>    Signed-off-by: Selvan Mani <smani@micron.com>
>    Signed-off-by: Rajesh Kumar Sambandam <rsambandam@micron.com>
>    Signed-off-by: Asai Thambi S P <asamymuthupa@micron.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Jens Axboe <axboe@fb.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 13af0df20f8e78dc1e7239a29b2862addde3953e
>Author: Asai Thambi SP <asamymuthupa@micron.com>
>Date:   Mon May 11 15:53:18 2015 -0700
>
>    mtip32xx: fix crash on surprise removal of the drive
>    
>    [ Upstream commit 2132a544727eb17f76bfef8b550a016a41c38821 ]
>    
>    pci and block layers have changed a lot compared to when SRSI support was added.
>    Given the current state of pci and block layers, this driver do not have to do
>    any specific handling.
>    
>    Signed-off-by: Asai Thambi S P <asamymuthupa@micron.com>
>    Signed-off-by: Selvan Mani <smani@micron.com>
>    Signed-off-by: Jens Axboe <axboe@fb.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6b9d9c35930bd75ddcfafb8eb7db909ceb63af10
>Author: Asai Thambi SP <asamymuthupa@micron.com>
>Date:   Mon May 11 15:48:00 2015 -0700
>
>    mtip32xx: fix rmmod issue
>    
>    [ Upstream commit 02b48265e7437bfe153af16337b14ee74f00905f ]
>    
>    put_disk() need to be called after del_gendisk() to free the disk object structure.
>    
>    Signed-off-by: Selvan Mani <smani@micron.com>
>    Signed-off-by: Asai Thambi S P <asamymuthupa@micron.com>
>    Signed-off-by: Jens Axboe <axboe@fb.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 15d38f73263562c2ebe3cdb7c6380e0b9a98c76c
>Author: Asai Thambi SP <asamymuthupa@micron.com>
>Date:   Wed Feb 24 21:17:32 2016 -0800
>
>    mtip32xx: Avoid issuing standby immediate cmd during FTL rebuild
>    
>    [ Upstream commit d8a18d2d8f5de55666c6011ed175939d22c8e3d8 ]
>    
>    Prevent standby immediate command from being issued in remove,
>    suspend and shutdown paths, while drive is in FTL rebuild process.
>    
>    Signed-off-by: Selvan Mani <smani@micron.com>
>    Signed-off-by: Vignesh Gunasekaran <vgunasekaran@micron.com>
>    Signed-off-by: Asai Thambi S P <asamymuthupa@micron.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Jens Axboe <axboe@fb.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c9d3e69a692eed01045bfa718505c3e887e87d85
>Author: Asai Thambi SP <asamymuthupa@micron.com>
>Date:   Wed Feb 24 21:16:38 2016 -0800
>
>    mtip32xx: Print exact time when an internal command is interrupted
>    
>    [ Upstream commit 5b7e0a8ac85e2dfd83830dc9e0b3554d153a37e3 ]
>    
>    Print exact time when an internal command is interrupted.
>    
>    Signed-off-by: Selvan Mani <smani@micron.com>
>    Signed-off-by: Rajesh Kumar Sambandam <rsambandam@micron.com>
>    Signed-off-by: Asai Thambi S P <asamymuthupa@micron.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Jens Axboe <axboe@fb.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ab1cc52b3f62f2445c60cbe390d26c50ebc0f3bd
>Author: Nikolay Borisov <kernel@kyup.com>
>Date:   Thu Mar 3 10:54:57 2016 +0100
>
>    quota: Fix possible GPF due to uninitialised pointers
>    
>    [ Upstream commit ab73ef46398e2c0159f3a71de834586422d2a44a ]
>    
>    When dqget() in __dquot_initialize() fails e.g. due to IO error,
>    __dquot_initialize() will pass an array of uninitialized pointers to
>    dqput_all() and thus can lead to deference of random data. Fix the
>    problem by properly initializing the array.
>    
>    CC: stable@vger.kernel.org
>    Signed-off-by: Nikolay Borisov <kernel@kyup.com>
>    Signed-off-by: Jan Kara <jack@suse.cz>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 594103da3005639712b3123a612791c8f4d3f4e9
>Author: Mateusz Guzik <mguzik@redhat.com>
>Date:   Wed Mar 2 09:51:09 2016 +1100
>
>    xfs: fix two memory leaks in xfs_attr_list.c error paths
>    
>    [ Upstream commit 2e83b79b2d6c78bf1b4aa227938a214dcbddc83f ]
>    
>    This plugs 2 trivial leaks in xfs_attr_shortform_list and
>    xfs_attr3_leaf_list_int.
>    
>    Signed-off-by: Mateusz Guzik <mguzik@redhat.com>
>    Cc: <stable@vger.kernel.org>
>    Reviewed-by: Eric Sandeen <sandeen@redhat.com>
>    Signed-off-by: Dave Chinner <david@fromorbit.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d876f71611ad9b720cc890075b3c4bec25bd54b5
>Author: J. Bruce Fields <bfields@redhat.com>
>Date:   Mon Feb 29 20:21:21 2016 -0500
>
>    nfsd4: fix bad bounds checking
>    
>    [ Upstream commit 4aed9c46afb80164401143aa0fdcfe3798baa9d5 ]
>    
>    A number of spots in the xdr decoding follow a pattern like
>    
>    	n = be32_to_cpup(p++);
>    	READ_BUF(n + 4);
>    
>    where n is a u32.  The only bounds checking is done in READ_BUF itself,
>    but since it's checking (n + 4), it won't catch cases where n is very
>    large, (u32)(-4) or higher.  I'm not sure exactly what the consequences
>    are, but we've seen crashes soon after.
>    
>    Instead, just break these up into two READ_BUF()s.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 58d550f06dfefe06ae1afed7a2ffaa333d19dfec
>Author: Michael S. Tsirkin <mst@redhat.com>
>Date:   Sun Feb 28 17:44:09 2016 +0200
>
>    watchdog: rc32434_wdt: fix ioctl error handling
>    
>    [ Upstream commit 10e7ac22cdd4d211cef99afcb9371b70cb175be6 ]
>    
>    Calling return copy_to_user(...) in an ioctl will not do the right thing
>    if there's a pagefault: copy_to_user returns the number of bytes not
>    copied in this case.
>    
>    Fix up watchdog/rc32434_wdt to do
>    	return copy_to_user(...)) ?  -EFAULT : 0;
>    
>    instead.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
>    Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 463c16b5e65df60c9404e0755378a85f581a3145
>Author: Hans de Goede <hdegoede@redhat.com>
>Date:   Sun Feb 7 09:24:29 2016 -0200
>
>    [media] bttv: Width must be a multiple of 16 when capturing planar formats
>    
>    [ Upstream commit 5c915c68763889f0183a1cc61c84bb228b60124a ]
>    
>    On my bttv card "Hauppauge WinTV [card=10]" capturing in YV12 fmt at max
>    size results in a solid green rectangle being captured (all colors 0 in
>    YUV).
>    
>    This turns out to be caused by max-width (924) not being a multiple of 16.
>    
>    We've likely never hit this problem before since normally xawtv / tvtime,
>    etc. will prefer packed pixel formats. But when using a video card which
>    is using xf86-video-modesetting + glamor, only planar XVideo fmts are
>    available, and xawtv will chose a matching capture format to avoid needing
>    to do conversion, triggering the solid green window problem.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>    Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
>    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 179e72b561d3d331c850e1a5779688d7a7de5246
>Author: Bart Van Assche <bart.vanassche@sandisk.com>
>Date:   Thu Feb 11 11:03:09 2016 -0800
>
>    IB/srpt: Simplify srpt_handle_tsk_mgmt()
>    
>    [ Upstream commit 51093254bf879bc9ce96590400a87897c7498463 ]
>    
>    Let the target core check task existence instead of the SRP target
>    driver. Additionally, let the target core check the validity of the
>    task management request instead of the ib_srpt driver.
>    
>    This patch fixes the following kernel crash:
>    
>    BUG: unable to handle kernel NULL pointer dereference at 0000000000000001
>    IP: [<ffffffffa0565f37>] srpt_handle_new_iu+0x6d7/0x790 [ib_srpt]
>    Oops: 0002 [#1] SMP
>    Call Trace:
>     [<ffffffffa05660ce>] srpt_process_completion+0xde/0x570 [ib_srpt]
>     [<ffffffffa056669f>] srpt_compl_thread+0x13f/0x160 [ib_srpt]
>     [<ffffffff8109726f>] kthread+0xcf/0xe0
>     [<ffffffff81613cfc>] ret_from_fork+0x7c/0xb0
>    
>    Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
>    Fixes: 3e4f574857ee ("ib_srpt: Convert TMR path to target_submit_tmr")
>    Tested-by: Alex Estrin <alex.estrin@intel.com>
>    Reviewed-by: Christoph Hellwig <hch@lst.de>
>    Cc: Nicholas Bellinger <nab@linux-iscsi.org>
>    Cc: Sagi Grimberg <sagig@mellanox.com>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Doug Ledford <dledford@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e62c5259a62f3da2a911f8fe6275dbf43d3b624f
>Author: David Howells <dhowells@redhat.com>
>Date:   Wed Feb 24 14:37:15 2016 +0000
>
>    X.509: Fix leap year handling again
>    
>    [ Upstream commit ac4cbedfdf55455b4c447f17f0fa027dbf02b2a6 ]
>    
>    There are still a couple of minor issues in the X.509 leap year handling:
>    
>     (1) To avoid doing a modulus-by-400 in addition to a modulus-by-100 when
>         determining whether the year is a leap year or not, I divided the year
>         by 100 after doing the modulus-by-100, thereby letting the compiler do
>         one instruction for both, and then did a modulus-by-4.
>    
>         Unfortunately, I then passed the now-modified year value to mktime64()
>         to construct a time value.
>    
>         Since this isn't a fast path and since mktime64() does a bunch of
>         divisions, just condense down to "% 400".  It's also easier to read.
>    
>     (2) The default month length for any February where the year doesn't
>         divide by four exactly is obtained from the month_length[] array where
>         the value is 29, not 28.
>    
>         This is fixed by altering the table.
>    
>    Reported-by: Rudolf Polzer <rpolzer@google.com>
>    Signed-off-by: David Howells <dhowells@redhat.com>
>    Acked-by: David Woodhouse <David.Woodhouse@intel.com>
>    Acked-by: Arnd Bergmann <arnd@arndb.de>
>    cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f85d91f88486b34679c532a5687466eaf335258f
>Author: David Howells <dhowells@redhat.com>
>Date:   Wed Jul 29 16:58:32 2015 +0100
>
>    PKCS#7: Improve and export the X.509 ASN.1 time object decoder
>    
>    [ Upstream commit fd19a3d195be23e8d9d0d66576b96ea25eea8323 ]
>    
>    Make the X.509 ASN.1 time object decoder fill in a time64_t rather than a
>    struct tm to make comparison easier (unfortunately, this makes readable
>    display less easy) and export it so that it can be used by the PKCS#7 code
>    too.
>    
>    Further, tighten up its parsing to reject invalid dates (eg. weird
>    characters, non-existent hour numbers) and unsupported dates (eg. timezones
>    other than 'Z' or dates earlier than 1970).
>    
>    Signed-off-by: David Howells <dhowells@redhat.com>
>    Reviewed-by: David Woodhouse <David.Woodhouse@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3ccbbbf7b5ceb75bef47692c39f443a3efb38437
>Author: David Howells <dhowells@redhat.com>
>Date:   Mon Jul 20 21:16:26 2015 +0100
>
>    X.509: Extract both parts of the AuthorityKeyIdentifier
>    
>    [ Upstream commit b92e6570a992c7d793a209db282f68159368201c ]
>    
>    Extract both parts of the AuthorityKeyIdentifier, not just the keyIdentifier,
>    as the second part can be used to match X.509 certificates by issuer and
>    serialNumber.
>    
>    Signed-off-by: David Howells <dhowells@redhat.com>
>    Tested-by: Vivek Goyal <vgoyal@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d836abef23b662030fe8f5a2206d5274fe670155
>Author: Russell King <rmk+kernel@arm.linux.org.uk>
>Date:   Tue Jan 26 13:41:04 2016 +0000
>
>    mmc: sdhci: fix data timeout (part 2)
>    
>    [ Upstream commit 7f05538af71c7d30b5fc821cbe9f318edc645961 ]
>    
>    The calculation for the timeout based on the number of card clocks is
>    incorrect.  The calculation assumed:
>    
>    	timeout in microseconds = clock cycles / clock in Hz
>    
>    which is clearly a several orders of magnitude wrong.  Fix this by
>    multiplying the clock cycles by 1000000 prior to dividing by the Hz
>    based clock.  Also, as per part 1, ensure that the division rounds
>    up.
>    
>    As this needs 64-bit math via do_div(), avoid it if the clock cycles
>    is zero.
>    
>    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
>    Cc: stable@vger.kernel.org # v3.15+
>    Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 68c533586b56051041b35477691d649fb90951c4
>Author: Russell King <rmk+kernel@arm.linux.org.uk>
>Date:   Tue Jan 26 13:40:58 2016 +0000
>
>    mmc: sdhci: fix data timeout (part 1)
>    
>    [ Upstream commit fafcfda9e78cae8796d1799f14e6457790797555 ]
>    
>    The data timeout gives the minimum amount of time that should be
>    waited before timing out if no data is received from the card.
>    Simply dividing the nanosecond part by 1000 does not give this
>    required guarantee, since such a division rounds down.  Use
>    DIV_ROUND_UP() to give the desired timeout.
>    
>    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
>    Cc: stable@vger.kernel.org # v3.15+
>    Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8b9af4307d02d83bef51f35bc1f0b046a331de13
>Author: Russell King <rmk+kernel@arm.linux.org.uk>
>Date:   Tue Jan 26 13:40:47 2016 +0000
>
>    mmc: sdhci-pxav3: fix higher speed mode capabilities
>    
>    [ Upstream commit 0ca33b4ad9cfc133bb3d93eec1ad0eea83d6f252 ]
>    
>    Commit 1140011ee9d9 ("mmc: sdhci-pxav3: Modify clock settings for the
>    SDR50 and DDR50 modes") broke any chance of the SDR50 or DDR50 modes
>    being used.
>    
>    The commit claims that SDR50 and DDR50 require clock adjustments in
>    the SDIO3 Configuration register, which is located via the "conf-sdio3"
>    resource.  However, when this resource is given, we fail to read the
>    host capabilities 1 register, resulting in host->caps1 being zero.
>    Hence, both SDHCI_SUPPORT_SDR50 and SDHCI_SUPPORT_DDR50 bits remain
>    zero, disabling the SDR50 and DDR50 modes.
>    
>    The underlying idea in this function appears to be to read the device
>    capabilities, modify them, and set SDHCI_QUIRK_MISSING_CAPS to cause
>    our modified capabilities to be used.  Implement exactly that.
>    
>    Fixes: 1140011ee9d9 ("mmc: sdhci-pxav3: Modify clock settings for the SDR50 and DDR50 modes")
>    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>    Cc: stable@vger.kernel.org # v4.5+
>    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
>    Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 39786b624c79881f3caf3bc0af05d0a0fb08e759
>Author: Dmitry Tunin <hanipouspilot@gmail.com>
>Date:   Sun Feb 28 11:04:06 2016 +0300
>
>    Bluetooth: btusb: Add a new AR3012 ID 04ca:3014
>    
>    [ Upstream commit 81d90442eac779938217c3444b240aa51fd3db47 ]
>    
>    T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=03 Dev#= 5 Spd=12 MxCh= 0
>    D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
>    P: Vendor=04ca ProdID=3014 Rev=00.02
>    C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
>    I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
>    I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
>    
>    BugLink: https://bugs.launchpad.net/bugs/1546694
>    
>    Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
>    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit dad41d54081e1bd2ef601c702ff4ea0f7428a965
>Author: Tom Lendacky <thomas.lendacky@amd.com>
>Date:   Thu Feb 25 16:48:13 2016 -0600
>
>    crypto: ccp - memset request context to zero during import
>    
>    [ Upstream commit ce0ae266feaf35930394bd770c69778e4ef03ba9 ]
>    
>    Since a crypto_ahash_import() can be called against a request context
>    that has not had a crypto_ahash_init() performed, the request context
>    needs to be cleared to insure there is no random data present. If not,
>    the random data can result in a kernel oops during crypto_ahash_update().
>    
>    Cc: <stable@vger.kernel.org> # 3.14.x-
>    Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 503f8305ab1b82d8788a2f161e7c52c0c0f6aeac
>Author: Shaohua Li <shli@fb.com>
>Date:   Wed Feb 24 17:38:28 2016 -0800
>
>    RAID5: check_reshape() shouldn't call mddev_suspend
>    
>    [ Upstream commit 27a353c026a879a1001e5eac4bda75b16262c44a ]
>    
>    check_reshape() is called from raid5d thread. raid5d thread shouldn't
>    call mddev_suspend(), because mddev_suspend() waits for all IO finish
>    but IO is handled in raid5d thread, we could easily deadlock here.
>    
>    This issue is introduced by
>    738a273 ("md/raid5: fix allocation of 'scribble' array.")
>    
>    Cc: stable@vger.kernel.org (v4.1+)
>    Reported-and-tested-by: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
>    Reviewed-by: NeilBrown <neilb@suse.com>
>    Signed-off-by: Shaohua Li <shli@fb.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5255a738ee6ecc0e479728efe5668efd64901197
>Author: Jes Sorensen <Jes.Sorensen@redhat.com>
>Date:   Tue Feb 16 16:44:24 2016 -0500
>
>    md/raid5: Compare apples to apples (or sectors to sectors)
>    
>    [ Upstream commit e7597e69dec59b65c5525db1626b9d34afdfa678 ]
>    
>    'max_discard_sectors' is in sectors, while 'stripe' is in bytes.
>    
>    This fixes the problem where DISCARD would get disabled on some larger
>    RAID5 configurations (6 or more drives in my testing), while it worked
>    as expected with smaller configurations.
>    
>    Fixes: 620125f2bf8 ("MD: raid5 trim support")
>    Cc: stable@vger.kernel.org v3.7+
>    Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
>    Signed-off-by: Shaohua Li <shli@fb.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit aa57ba13f44426a076ac567e965654453d4be1f1
>Author: Bjorn Helgaas <bhelgaas@google.com>
>Date:   Thu Feb 25 14:35:57 2016 -0600
>
>    PCI: Disable IO/MEM decoding for devices with non-compliant BARs
>    
>    [ Upstream commit b84106b4e2290c081cdab521fa832596cdfea246 ]
>    
>    The PCI config header (first 64 bytes of each device's config space) is
>    defined by the PCI spec so generic software can identify the device and
>    manage its usage of I/O, memory, and IRQ resources.
>    
>    Some non-spec-compliant devices put registers other than BARs where the
>    BARs should be.  When the PCI core sizes these "BARs", the reads and writes
>    it does may have unwanted side effects, and the "BAR" may appear to
>    describe non-sensical address space.
>    
>    Add a flag bit to mark non-compliant devices so we don't touch their BARs.
>    Turn off IO/MEM decoding to prevent the devices from consuming address
>    space, since we can't read the BARs to find out what that address space
>    would be.
>    
>    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>    Tested-by: Andi Kleen <ak@linux.intel.com>
>    CC: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 517a021fdba44206722c85bd9267dabd67475fa6
>Author: Yijing Wang <wangyijing@huawei.com>
>Date:   Thu May 21 15:05:02 2015 +0800
>
>    PCI: Add dev->has_secondary_link to track downstream PCIe links
>    
>    [ Upstream commit d0751b98dfa391f862e02dc36a233a54615e3f1d ]
>    
>    A PCIe Port is an interface to a Link.  A Root Port is a PCI-PCI bridge in
>    a Root Complex and has a Link on its secondary (downstream) side.  For
>    other Ports, the Link may be on either the upstream (closer to the Root
>    Complex) or downstream side of the Port.
>    
>    The usual topology has a Root Port connected to an Upstream Port.  We
>    previously assumed this was the only possible topology, and that a
>    Downstream Port's Link was always on its downstream side, like this:
>    
>                      +---------------------+
>      +------+        |          Downstream |
>      | Root |        | Upstream       Port +--Link--
>      | Port +--Link--+ Port                |
>      +------+        |          Downstream |
>                      |                Port +--Link--
>                      +---------------------+
>    
>    But systems do exist (see URL below) where the Root Port is connected to a
>    Downstream Port.  In this case, a Downstream Port's Link may be on either
>    the upstream or downstream side:
>    
>                      +---------------------+
>      +------+        |            Upstream |
>      | Root |        | Downstream     Port +--Link--
>      | Port +--Link--+ Port                |
>      +------+        |          Downstream |
>                      |                Port +--Link--
>                      +---------------------+
>    
>    We can't use the Port type to determine which side the Link is on, so add a
>    bit in struct pci_dev to keep track.
>    
>    A Root Port's Link is always on the Port's secondary side.  A component
>    (Endpoint or Port) on the other end of the Link obviously has the Link on
>    its upstream side.  If that component is a Port, it is part of a Switch or
>    a Bridge.  A Bridge has a PCI or PCI-X bus on its secondary side, not a
>    Link.  The internal bus of a Switch connects the Port to another Port whose
>    Link is on the downstream side.
>    
>    [bhelgaas: changelog, comment, cache "type", use if/else]
>    Link: http://lkml.kernel.org/r/54EB81B2.4050904@pobox.com
>    Link: https://bugzilla.kernel.org/show_bug.cgi?id=94361
>    Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
>    Signed-off-by: Yijing Wang <wangyijing@huawei.com>
>    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 084b44e9cbc6eec0b0b13138918fb5935208f3b4
>Author: Aaro Koskinen <aaro.koskinen@iki.fi>
>Date:   Sat Feb 20 22:27:48 2016 +0200
>
>    mtd: onenand: fix deadlock in onenand_block_markbad
>    
>    [ Upstream commit 5e64c29e98bfbba1b527b0a164f9493f3db9e8cb ]
>    
>    Commit 5942ddbc500d ("mtd: introduce mtd_block_markbad interface")
>    incorrectly changed onenand_block_markbad() to call mtd_block_markbad
>    instead of onenand_chip's block_markbad function. As a result the function
>    will now recurse and deadlock. Fix by reverting the change.
>    
>    Fixes: 5942ddbc500d ("mtd: introduce mtd_block_markbad interface")
>    Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
>    Acked-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Brian Norris <computersforpeace@gmail.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit cf438ddac48b27e7de0514f96d912e132c908df4
>Author: Alan <gnomes@lxorguk.ukuu.org.uk>
>Date:   Mon Feb 15 18:53:15 2016 +0000
>
>    aic7xxx: Fix queue depth handling
>    
>    [ Upstream commit 5a51a7abca133860a6f4429655a9eda3c4afde32 ]
>    
>    We were setting the queue depth correctly, then setting it back to
>    two. If you hit this as a bisection point then please send me an email
>    as it would imply we've been hiding other bugs with this one.
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Alan Cox <alan@linux.intel.com>
>    Reviewed-by: Hannes Reinicke <hare@suse.de>
>    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6d2cd58f288e320c5a023219ac8726b30657ddbb
>Author: Raghava Aditya Renukunta <raghavaaditya.renukunta@pmcs.com>
>Date:   Wed Feb 3 15:06:02 2016 -0800
>
>    aacraid: Fix memory leak in aac_fib_map_free
>    
>    [ Upstream commit f88fa79a61726ce9434df9b4aede36961f709f17 ]
>    
>    aac_fib_map_free() calls pci_free_consistent() without checking that
>    dev->hw_fib_va is not NULL and dev->max_fib_size is not zero.If they are
>    indeed NULL/0, this will result in a hang as pci_free_consistent() will
>    attempt to invalidate cache for the entire 64-bit address space
>    (which would take a very long time).
>    
>    Fixed by adding a check to make sure that dev->hw_fib_va and
>    dev->max_fib_size are not NULL and 0 respectively.
>    
>    Fixes: 9ad5204d6 - "[SCSI]aacraid: incorrect dma mapping mask during blinked recover or user initiated reset"
>    Cc: stable@vger.kernel.org
>    
>    Signed-off-by: Raghava Aditya Renukunta <raghavaaditya.renukunta@pmcs.com>
>    Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
>    Reviewed-by: Tomas Henzl <thenzl@redhat.com>
>    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 34bb7098221c2a37f5d9ef3591971a25719ae21a
>Author: Raghava Aditya Renukunta <raghavaaditya.renukunta@pmcs.com>
>Date:   Wed Feb 3 15:06:00 2016 -0800
>
>    aacraid: Fix RRQ overload
>    
>    [ Upstream commit 3f4ce057d51a9c0ed9b01ba693df685d230ffcae ]
>    
>    The driver utilizes an array of atomic variables to keep track of IO
>    submissions to each vector. To submit an IO multiple threads iterate
>    through the array to find a vector which has empty slots to send an
>    IO. The reading and updating of the variable is not atomic, causing race
>    conditions when a thread uses a full vector to submit an IO.
>    
>    Fixed by mapping each FIB to a vector, the submission path then uses
>    said vector to submit IO thereby removing the possibly of a race
>    condition.The vector assignment is started from 1 since vector 0 is
>    reserved for the use of AIF management FIBS.If the number of MSIx
>    vectors is 1 (MSI or INTx mode) then all the fibs are allocated to
>    vector 0.
>    
>    Fixes: 495c0217 "aacraid: MSI-x support"
>    Cc: stable@vger.kernel.org # v4.1
>    
>    Signed-off-by: Raghava Aditya Renukunta <raghavaaditya.renukunta@pmcs.com>
>    Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
>    Reviewed-by: Tomas Henzl <thenzl@redhat.com>
>    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit acab7e2cae96f3b69a6d9df27c727d515ab298b7
>Author: Dmitry Tunin <hanipouspilot@gmail.com>
>Date:   Wed Feb 10 00:49:11 2016 +0300
>
>    Bluetooth: Add new AR3012 ID 0489:e095
>    
>    [ Upstream commit 28c971d82fb58ef7cba22e5308be6d2d2590473d ]
>    
>    T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=02 Dev#= 3 Spd=12 MxCh= 0
>    D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
>    P: Vendor=0489 ProdID=e095 Rev=00.01
>    C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
>    I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
>    I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
>    
>    This device requires ar3k/AthrBT_0x31010100.dfu and
>    ar3k/ramps_0x31010100_40.dfu firmware files that are not in
>    linux-firmware yet.
>    
>    BugLink: https://bugs.launchpad.net/bugs/1542944
>    
>    Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
>    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 64f25c62a61af96dacbfa8a22b2d30949853f362
>Author: Dmitry Tunin <hanipouspilot@gmail.com>
>Date:   Wed Feb 10 15:33:17 2016 +0300
>
>    Bluetooth: btusb: Add new AR3012 ID 13d3:3395
>    
>    [ Upstream commit 609574eb46335cfac1421a07c0505627cbbab1f0 ]
>    
>    T: Bus=03 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
>    D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
>    P: Vendor=13d3 ProdID=3395 Rev=00.01
>    C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
>    I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
>    I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
>    
>    BugLink: https://bugs.launchpad.net/bugs/1542564
>    
>    Reported-and-tested-by: Christopher Simerly <kilikopela29@gmail.com>
>    Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
>    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a6455f2f43dda60c52c857c2332ca5a557c8c449
>Author: Andi Kleen <ak@linux.intel.com>
>Date:   Wed Feb 17 14:44:55 2016 -0800
>
>    perf tools: Dont stop PMU parsing on alias parse error
>    
>    [ Upstream commit 940db6dcd3f4659303fdf6befe7416adc4d24118 ]
>    
>    When an error happens during alias parsing currently the complete
>    parsing of all attributes of the PMU is stopped. This is breaks old perf
>    on a newer kernel that may have not-yet-know alias attributes (such as
>    .scale or .per-pkg).
>    
>    Continue when some attribute is unparseable.
>    
>    This is IMHO a stable candidate and should be backported to older
>    versions to avoid problems with newer kernels.
>    
>    v2: Print warnings when something goes wrong.
>    v3: Change warning to debug output
>    
>    Signed-off-by: Andi Kleen <ak@linux.intel.com>
>    Cc: Jiri Olsa <jolsa@kernel.org>
>    Cc: stable@vger.kernel.org # v3.6+
>    Link: http://lkml.kernel.org/r/1455749095-18358-1-git-send-email-andi@firstfloor.org
>    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit fb1840e257d26b6aad69b864cb7ed4a67ab986b6
>Author: Mike Snitzer <snitzer@redhat.com>
>Date:   Fri Feb 5 08:49:01 2016 -0500
>
>    dm: fix excessive dm-mq context switching
>    
>    [ Upstream commit 6acfe68bac7e6f16dc312157b1fa6e2368985013 ]
>    
>    Request-based DM's blk-mq support (dm-mq) was reported to be 50% slower
>    than if an underlying null_blk device were used directly.  One of the
>    reasons for this drop in performance is that blk_insert_clone_request()
>    was calling blk_mq_insert_request() with @async=true.  This forced the
>    use of kblockd_schedule_delayed_work_on() to run the blk-mq hw queues
>    which ushered in ping-ponging between process context (fio in this case)
>    and kblockd's kworker to submit the cloned request.  The ftrace
>    function_graph tracer showed:
>    
>      kworker-2013  =>   fio-12190
>      fio-12190    =>  kworker-2013
>      ...
>      kworker-2013  =>   fio-12190
>      fio-12190    =>  kworker-2013
>      ...
>    
>    Fixing blk_insert_clone_request()'s blk_mq_insert_request() call to
>    _not_ use kblockd to submit the cloned requests isn't enough to
>    eliminate the observed context switches.
>    
>    In addition to this dm-mq specific blk-core fix, there are 2 DM core
>    fixes to dm-mq that (when paired with the blk-core fix) completely
>    eliminate the observed context switching:
>    
>    1)  don't blk_mq_run_hw_queues in blk-mq request completion
>    
>        Motivated by desire to reduce overhead of dm-mq, punting to kblockd
>        just increases context switches.
>    
>        In my testing against a really fast null_blk device there was no benefit
>        to running blk_mq_run_hw_queues() on completion (and no other blk-mq
>        driver does this).  So hopefully this change doesn't induce the need for
>        yet another revert like commit 621739b00e16ca2d !
>    
>    2)  use blk_mq_complete_request() in dm_complete_request()
>    
>        blk_complete_request() doesn't offer the traditional q->mq_ops vs
>        .request_fn branching pattern that other historic block interfaces
>        do (e.g. blk_get_request).  Using blk_mq_complete_request() for
>        blk-mq requests is important for performance.  It should be noted
>        that, like blk_complete_request(), blk_mq_complete_request() doesn't
>        natively handle partial completions -- but the request-based
>        DM-multipath target does provide the required partial completion
>        support by dm.c:end_clone_bio() triggering requeueing of the request
>        via dm-mpath.c:multipath_end_io()'s return of DM_ENDIO_REQUEUE.
>    
>    dm-mq fix #2 is _much_ more important than #1 for eliminating the
>    context switches.
>    Before: cpu          : usr=15.10%, sys=59.39%, ctx=7905181, majf=0, minf=475
>    After:  cpu          : usr=20.60%, sys=79.35%, ctx=2008, majf=0, minf=472
>    
>    With these changes multithreaded async read IOPs improved from ~950K
>    to ~1350K for this dm-mq stacked on null_blk test-case.  The raw read
>    IOPs of the underlying null_blk device for the same workload is ~1950K.
>    
>    Fixes: 7fb4898e0 ("block: add blk-mq support to blk_insert_cloned_request()")
>    Fixes: bfebd1cdb ("dm: add full blk-mq support to request-based DM")
>    Cc: stable@vger.kernel.org # 4.1+
>    Reported-by: Sagi Grimberg <sagig@dev.mellanox.co.il>
>    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
>    Acked-by: Jens Axboe <axboe@kernel.dk>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 31a37d7c7ef7b4f90b600fcddd1c385a39f9d34c
>Author: Eryu Guan <guaneryu@gmail.com>
>Date:   Sun Feb 21 18:38:44 2016 -0500
>
>    ext4: iterate over buffer heads correctly in move_extent_per_page()
>    
>    [ Upstream commit 87f9a031af48defee9f34c6aaf06d6f1988c244d ]
>    
>    In commit bcff24887d00 ("ext4: don't read blocks from disk after extents
>    being swapped") bh is not updated correctly in the for loop and wrong
>    data has been written to disk. generic/324 catches this on sub-page
>    block size ext4.
>    
>    Fixes: bcff24887d00 ("ext4: don't read blocks from disk after extentsbeing swapped")
>    Signed-off-by: Eryu Guan <guaneryu@gmail.com>
>    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3a4db9eef86e230e3b441ea14ab4ed5492b5bf02
>Author: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
>Date:   Thu Feb 18 22:11:29 2016 +0200
>
>    tpm_crb: tpm2_shutdown() must be called before tpm_chip_unregister()
>    
>    [ Upstream commit 99cda8cb4639de81cde785b5bab9bc52e916e594 ]
>    
>    Wrong call order.
>    
>    Reported-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
>    Fixes: 74d6b3ceaa17
>    Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
>    cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2ecb9996d53c218a536ad796b766c2c1cd06c3c0
>Author: Hans de Goede <hdegoede@redhat.com>
>Date:   Sun Feb 14 17:51:37 2016 -0200
>
>    [media] saa7134: Fix bytesperline not being set correctly for planar formats
>    
>    [ Upstream commit 3e71da19f9dc22e39a755d6ae9678661abb66adc ]
>    
>    bytesperline should be the bytesperline for the first plane for planar
>    formats, not that of all planes combined.
>    
>    This fixes a crash in xawtv caused by the wrong bpl.
>    
>    BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1305389
>    Reported-and-tested-by: Stas Sergeev <stsp@list.ru>
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-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: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3aae1bb07b59d62e9ea4b1883d787091070ffe1e
>Author: Hans Verkuil <hverkuil@xs4all.nl>
>Date:   Wed Feb 10 09:32:25 2016 -0200
>
>    [media] adv7511: TX_EDID_PRESENT is still 1 after a disconnect
>    
>    [ Upstream commit b339a72e04a62f0b1882c43492fc712f1176b3e6 ]
>    
>    The V4L2_CID_TX_EDID_PRESENT control reports if an EDID is present.
>    The adv7511 however still reported the EDID present after disconnecting
>    the HDMI cable. Fix the logic regarding this control. And when the EDID
>    is disconnected also call ADV7511_EDID_DETECT to notify the bridge driver.
>    This was also missing.
>    
>    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
>    Cc: <stable@vger.kernel.org>      # for v3.12 and up
>    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ba390f4e74ab0e9b62930f7da629e8b55027c564
>Author: Julia Lawall <Julia.Lawall@lip6.fr>
>Date:   Thu Feb 18 00:16:14 2016 +0100
>
>    scripts/coccinelle: modernize &
>    
>    [ Upstream commit 1b669e713f277a4d4b3cec84e13d16544ac8286d ]
>    
>    & is no longer allowed in column 0, since Coccinelle 1.0.4.
>    
>    Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
>    Tested-by: Nishanth Menon <nm@ti.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Michal Marek <mmarek@suse.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 23c41c6589cacd98e5028217d1db364f5081de03
>Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>Date:   Fri Feb 12 17:10:37 2016 +0100
>
>    HID: fix hid_ignore_special_drivers module parameter
>    
>    [ Upstream commit 4392bf333388cabdad5afe5b1500002d7b9c318e ]
>    
>    hid_ignore_special_drivers works fine until hid_scan_report autodetects and
>    reassign devices (for hid-multitouch, hid-microsoft and hid-rmi).
>    
>    Simplify the handling of the parameter: if it is there, use hid-generic, no
>    matter what, and if not, scan the device or rely on the hid_have_special_driver
>    table.
>    
>    This was detected while trying to disable hid-multitouch on a Surface Pro cover
>    which prevented to use the keyboard.
>    
>    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>    CC: stable@vger.kernel.org
>    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 619464b00951d21aa1bc66c542b947c4a8835dba
>Author: Oliver Neukum <oneukum@suse.com>
>Date:   Wed Feb 10 11:33:18 2016 +0100
>
>    usb: retry reset if a device times out
>    
>    [ Upstream commit 264904ccc33c604d4b3141bbd33808152dfac45b ]
>    
>    Some devices I got show an inability to operate right after
>    power on if they are already connected. They are beyond recovery
>    if the descriptors are requested multiple times. So in case of
>    a timeout we rather bail early and reset again. But it must be
>    done only on the first loop lest we get into a reset/time out
>    spiral that can be overcome with a retry.
>    
>    This patch is a rework of a patch that fell through the cracks.
>    http://www.spinics.net/lists/linux-usb/msg103263.html
>    
>    Signed-off-by: Oliver Neukum <oneukum@suse.com>
>    CC: stable@vger.kernel.org
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3bab1a558c159d9a8388e11270add2acc100d5c5
>Author: Lior Amsalem <alior@marvell.com>
>Date:   Wed Feb 10 17:29:15 2016 +0100
>
>    ARM: dts: armada-375: use armada-370-sata for SATA
>    
>    [ Upstream commit b3a7f31eb7375633cd6a742f19488fc5a4208b36 ]
>    
>    The Armada 375 has the same SATA IP as Armada 370 and Armada XP, which
>    requires the PHY speed to be set in the LP_PHY_CTL register for SATA
>    hotplug to work.
>    
>    Therefore, this commit updates the compatible string used to describe
>    the SATA IP in Armada 375 from marvell,orion-sata to
>    marvell,armada-370-sata.
>    
>    Fixes: 4de59085091f753d08c8429d756b46756ab94665 ("ARM: mvebu: add Device Tree description of the Armada 375 SoC")
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Lior Amsalem <alior@marvell.com>
>    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
>    Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2168661199ff5eeab52a8aa2408a6b21fbf4f743
>Author: Kamal Mostafa <kamal@canonical.com>
>Date:   Wed Jan 27 22:29:33 2016 -0800
>
>    tools/hv: Use include/uapi with __EXPORTED_HEADERS__
>    
>    [ Upstream commit 50fe6dd10069e7c062e27f29606f6e91ea979399 ]
>    
>    Use the local uapi headers to keep in sync with "recently" added #define's
>    (e.g. VSS_OP_REGISTER1).
>    
>    Fixes: 3eb2094c59e8 ("Adding makefile for tools/hv")
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Kamal Mostafa <kamal@canonical.com>
>    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 349420036cac88d1a0ef3fb77ddc9a297cd4d17e
>Author: Spencer E. Olson <olsonse@umich.edu>
>Date:   Tue Jan 12 10:33:18 2016 -0700
>
>    staging: comedi: ni_tiocmd: change mistaken use of start_src for start_arg
>    
>    [ Upstream commit 1fd24a4702d2af0ea4d5845126cf57d4d1796216 ]
>    
>    This fixes a bug in function ni_tio_input_inttrig().  The trigger number
>    should be compared to cmd->start_arg, not cmd->start_src.
>    
>    Fixes: 6a760394d7eb ("staging: comedi: ni_tiocmd: clarify the cmd->start_arg validation and use")
>    Cc: <stable@vger.kernel.org> # 3.17+
>    Signed-off-by: Spencer E. Olson <olsonse@umich.edu>
>    Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 79b768dec5d354aeb143f51db11e0cbb758176fb
>Author: Alexander Usyskin <alexander.usyskin@intel.com>
>Date:   Sun Feb 7 23:35:32 2016 +0200
>
>    mei: bus: move driver api functions at the start of the file
>    
>    [ Upstream commit 6238299774377b12c3e24507b100b2687eb5ea32 ]
>    
>    To make the file more organize move mei client driver api
>    to the start of the file and add Kdoc.
>    
>    There are no functional changes in this patch.
>    
>    Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0f412b8aa88883f7e3059c5a2c1e56ce0dd8bf86
>Author: Peter Hurley <peter@hurleysoftware.com>
>Date:   Sat Jan 9 17:48:45 2016 -0800
>
>    net: irda: Fix use-after-free in irtty_open()
>    
>    [ Upstream commit 401879c57f01cbf2da204ad2e8db910525c6dbea ]
>    
>    The N_IRDA line discipline may access the previous line discipline's closed
>    and already-fre private data on open [1].
>    
>    The tty->disc_data field _never_ refers to valid data on entry to the
>    line discipline's open() method. Rather, the ldisc is expected to
>    initialize that field for its own use for the lifetime of the instance
>    (ie. from open() to close() only).
>    
>    [1]
>        ==================================================================
>        BUG: KASAN: use-after-free in irtty_open+0x422/0x550 at addr ffff8800331dd068
>        Read of size 4 by task a.out/13960
>        =============================================================================
>        BUG kmalloc-512 (Tainted: G    B          ): kasan: bad access detected
>        -----------------------------------------------------------------------------
>        ...
>        Call Trace:
>         [<ffffffff815fa2ae>] __asan_report_load4_noabort+0x3e/0x40 mm/kasan/report.c:279
>         [<ffffffff836938a2>] irtty_open+0x422/0x550 drivers/net/irda/irtty-sir.c:436
>         [<ffffffff829f1b80>] tty_ldisc_open.isra.2+0x60/0xa0 drivers/tty/tty_ldisc.c:447
>         [<ffffffff829f21c0>] tty_set_ldisc+0x1a0/0x940 drivers/tty/tty_ldisc.c:567
>         [<     inline     >] tiocsetd drivers/tty/tty_io.c:2650
>         [<ffffffff829da49e>] tty_ioctl+0xace/0x1fd0 drivers/tty/tty_io.c:2883
>         [<     inline     >] vfs_ioctl fs/ioctl.c:43
>         [<ffffffff816708ac>] do_vfs_ioctl+0x57c/0xe60 fs/ioctl.c:607
>         [<     inline     >] SYSC_ioctl fs/ioctl.c:622
>         [<ffffffff81671204>] SyS_ioctl+0x74/0x80 fs/ioctl.c:613
>         [<ffffffff852a7876>] entry_SYSCALL_64_fastpath+0x16/0x7a
>    
>    Reported-and-tested-by: Dmitry Vyukov <dvyukov@google.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b053d66b66e702f74ddc986863b30eaac41e7f4c
>Author: Tom Lendacky <thomas.lendacky@amd.com>
>Date:   Tue Feb 2 11:38:21 2016 -0600
>
>    crypto: ccp - Don't assume export/import areas are aligned
>    
>    [ Upstream commit b31dde2a5cb1bf764282abf934266b7193c2bc7c ]
>    
>    Use a local variable for the exported and imported state so that
>    alignment is not an issue. On export, set a local variable from the
>    request context and then memcpy the contents of the local variable to
>    the export memory area. On import, memcpy the import memory area into
>    a local variable and then use the local variable to set the request
>    context.
>    
>    Cc: <stable@vger.kernel.org> # 3.14.x-
>    Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5badf7e00f0968d820bf7bba9081339bfca3489c
>Author: Tom Lendacky <thomas.lendacky@amd.com>
>Date:   Fri Jan 29 12:45:14 2016 -0600
>
>    crypto: ccp - Limit the amount of information exported
>    
>    [ Upstream commit d1662165ae612ec8b5f94a6b07e65ea58b6dce34 ]
>    
>    Since the exported information can be exposed to user-space, instead of
>    exporting the entire request context only export the minimum information
>    needed.
>    
>    Cc: <stable@vger.kernel.org> # 3.14.x-
>    Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6896d28d701c95df209e15ce82bcc8024a7dbd90
>Author: Hans de Goede <hdegoede@redhat.com>
>Date:   Fri Jan 22 08:53:55 2016 -0200
>
>    [media] pwc: Add USB id for Philips Spc880nc webcam
>    
>    [ Upstream commit 7445e45d19a09e5269dc85f17f9635be29d2f76c ]
>    
>    SPC 880NC PC camera discussions:
>    	http://www.pclinuxos.com/forum/index.php/topic,135688.0.html
>    
>    Cc: stable@vger.kernel.org
>    Reported-by: Kikim <klucznik0@op.pl>
>    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4dc695f3116ba454f9624f15b512b8caa23e5221
>Author: Tiffany Lin <tiffany.lin@mediatek.com>
>Date:   Tue Jan 19 05:56:50 2016 -0200
>
>    [media] media: v4l2-compat-ioctl32: fix missing length copy in put_v4l2_buffer32
>    
>    [ Upstream commit 7df5ab8774aa383c6d2bff00688d004585d96dfd ]
>    
>    In v4l2-compliance utility, test QUERYBUF required correct length
>    value to go through each planar to check planar's length in
>    multi-planar buffer type
>    
>    Signed-off-by: Tiffany Lin <tiffany.lin@mediatek.com>
>    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
>    Cc: <stable@vger.kernel.org>      # for v3.7 and up
>    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3beac2b0bffd8e977ef1d464dd424f22af965a96
>Author: Peter Hurley <peter@hurleysoftware.com>
>Date:   Sun Jan 10 20:36:12 2016 -0800
>
>    tty: Fix GPF in flush_to_ldisc(), part 2
>    
>    [ Upstream commit f33798deecbd59a2955f40ac0ae2bc7dff54c069 ]
>    
>    commit 9ce119f318ba ("tty: Fix GPF in flush_to_ldisc()") fixed a
>    GPF caused by a line discipline which does not define a receive_buf()
>    method.
>    
>    However, the vt driver (and speakup driver also) pushes selection
>    data directly to the line discipline receive_buf() method via
>    tty_ldisc_receive_buf(). Fix the same problem in tty_ldisc_receive_buf().
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d3e5b294c6a3e78b9a544eede572e239555224db
>Author: Alexander Kochetkov <al.kochet@gmail.com>
>Date:   Tue Jan 26 16:34:00 2016 +0300
>
>    clk: rockchip: add hclk_cpubus to the list of rk3188 critical clocks
>    
>    [ Upstream commit e8b63288b37dbb8457b510c9d96f6006da4653f6 ]
>    
>    hclk_cpubus needs to keep running because it is needed for devices like
>    the rom, i2s0 or spdif to be accessible via cpu. Without that all
>    accesses to devices (readl/writel) return wrong data. So add it
>    to the list of critical clocks.
>    
>    Fixes: 78eaf6095cc763c ("clk: rockchip: disable unused clocks")
>    Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
>    Cc: stable@vger.kernel.org # 4.1.x-
>    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a0723dc0436813a4bb543a823b146045eb97f35b
>Author: Romain Perier <romain.perier@gmail.com>
>Date:   Sun Aug 23 11:32:37 2015 +0200
>
>    clk: rockchip: Add pclk_peri to critical clocks on RK3066/RK3188
>    
>    [ Upstream commit 3bba75a2ec32bd5fa7024a4de3b8cf9ee113a76a ]
>    
>    Now that the rockchip clock subsystem does clock gating with GPIO banks,
>    these are no longer enabled once during probe and no longer stay enabled
>    for eternity. When all these clocks are disabled, the parent clock pclk_peri
>    might be disabled too, as no other child claims it. So, we need to add pclk_peri
>    to the critical clocks.
>    
>    Signed-off-by: Romain Perier <romain.perier@gmail.com>
>    Tested-by: Michael Niewoehner <linux@mniewoehner.de>
>    Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 754d2b7064ccfe6ca116323553f3f44d6f6f9d96
>Author: Michael Niewoehner <linux@mniewoehner.de>
>Date:   Tue Aug 25 22:22:07 2015 +0200
>
>    clk: rockchip: add pclk_cpu to the list of rk3188 critical clocks
>    
>    [ Upstream commit 1166160ab531198f7abc773992c0e04d0f9b7600 ]
>    
>    pclk_cpu needs to keep running because it is needed for devices like
>    the act8865 regulator but with the recent gpio clock handling this is
>    not always the case anymore. So add it to the list of critical clocks.
>    
>    Signed-off-by: Michael Niewoehner <linux@mniewoehner.de>
>    Reviewed-by: Heiko Stuebner <heiko@sntech.de>
>    Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1ad241d40ef8d9a50ced5c35bf55e9a21a997516
>Author: Tom Lendacky <thomas.lendacky@amd.com>
>Date:   Tue Jan 12 11:17:38 2016 -0600
>
>    crypto: ccp - Add hash state import and export support
>    
>    [ Upstream commit 952bce9792e6bf36fda09c2e5718abb5d9327369 ]
>    
>    Commit 8996eafdcbad ("crypto: ahash - ensure statesize is non-zero")
>    added a check to prevent ahash algorithms from successfully registering
>    if the import and export functions were not implemented. This prevents
>    an oops in the hash_accept function of algif_hash. This commit causes
>    the ccp-crypto module SHA support and AES CMAC support from successfully
>    registering and causing the ccp-crypto module load to fail because the
>    ahash import and export functions are not implemented.
>    
>    Update the CCP Crypto API support to provide import and export support
>    for ahash algorithms.
>    
>    Cc: <stable@vger.kernel.org> # 3.14.x-
>    Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 05d13aa39e8c81ad8c4af8dcc3c29129f5634b8a
>Author: Dan Carpenter <dan.carpenter@oracle.com>
>Date:   Wed Jan 20 12:54:51 2016 +0300
>
>    EDAC, amd64_edac: Shift wrapping issue in f1x_get_norm_dct_addr()
>    
>    [ Upstream commit 6f3508f61c814ee852c199988a62bd954c50dfc1 ]
>    
>    dct_sel_base_off is declared as a u64 but we're only using the lower 32
>    bits because of a shift wrapping bug. This can possibly truncate the
>    upper 16 bits of DctSelBaseOffset[47:26], causing us to misdecode the CS
>    row.
>    
>    Fixes: c8e518d5673d ('amd64_edac: Sanitize f10_get_base_addr_offset')
>    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>    Cc: Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>
>    Cc: linux-edac <linux-edac@vger.kernel.org>
>    Cc: <stable@vger.kernel.org>
>    Link: http://lkml.kernel.org/r/20160120095451.GB19898@mwanda
>    Signed-off-by: Borislav Petkov <bp@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2cc58a1e06ea8b6c9aa6d25ec74d8d1671e500eb
>Author: Andy Lutomirski <luto@kernel.org>
>Date:   Tue Apr 5 12:24:24 2016 -0700
>
>    x86/iopl/64: Properly context-switch IOPL on Xen PV
>    
>    commit b7a584598aea7ca73140cb87b40319944dd3393f upstream.
>    
>    On Xen PV, regs->flags doesn't reliably reflect IOPL and the
>    exit-to-userspace code doesn't change IOPL.  We need to context
>    switch it manually.
>    
>    I'm doing this without going through paravirt because this is
>    specific to Xen PV.  After the dust settles, we can merge this with
>    the 32-bit code, tidy up the iopl syscall implementation, and remove
>    the set_iopl pvop entirely.
>    
>    Fixes XSA-171.
>    
>    Reviewewd-by: Jan Beulich <JBeulich@suse.com>
>    Signed-off-by: Andy Lutomirski <luto@kernel.org>
>    Cc: Andrew Cooper <andrew.cooper3@citrix.com>
>    Cc: Andy Lutomirski <luto@amacapital.net>
>    Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>    Cc: Borislav Petkov <bp@alien8.de>
>    Cc: Brian Gerst <brgerst@gmail.com>
>    Cc: David Vrabel <david.vrabel@citrix.com>
>    Cc: Denys Vlasenko <dvlasenk@redhat.com>
>    Cc: H. Peter Anvin <hpa@zytor.com>
>    Cc: Jan Beulich <JBeulich@suse.com>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Link: http://lkml.kernel.org/r/693c3bd7aeb4d3c27c92c622b7d0f554a458173c.1458162709.git.luto@kernel.org
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    [ kamal: backport to 4.2-stable: no X86_FEATURE_XENPV so just call
>      xen_pv_domain() directly ]
>    Acked-by: Andy Lutomirski <luto@kernel.org>
>    Signed-off-by: Kamal Mostafa <kamal@canonical.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 37dee22181885e7847e8c95843b6e94138edbd43
>Author: Vladis Dronov <vdronov@redhat.com>
>Date:   Mon Nov 16 15:55:11 2015 -0200
>
>    [media] usbvision: fix crash on detecting device with invalid configuration
>    
>    [ Upstream commit fa52bd506f274b7619955917abfde355e3d19ffe ]
>    
>    The usbvision driver crashes when a specially crafted usb device with invalid
>    number of interfaces or endpoints is detected. This fix adds checks that the
>    device has proper configuration expected by the driver.
>    
>    Reported-by: Ralf Spenneberg <ralf@spenneberg.net>
>    Signed-off-by: Vladis Dronov <vdronov@redhat.com>
>    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 46460a03f44f1915ded434057fa46332438b3a6e
>Author: Vasily Kulikov <segoon@openwall.com>
>Date:   Wed Sep 9 15:36:00 2015 -0700
>
>    include/linux/poison.h: fix LIST_POISON{1,2} offset
>    
>    [ Upstream commit 8a5e5e02fc83aaf67053ab53b359af08c6c49aaf ]
>    
>    Poison pointer values should be small enough to find a room in
>    non-mmap'able/hardly-mmap'able space.  E.g.  on x86 "poison pointer space"
>    is located starting from 0x0.  Given unprivileged users cannot mmap
>    anything below mmap_min_addr, it should be safe to use poison pointers
>    lower than mmap_min_addr.
>    
>    The current poison pointer values of LIST_POISON{1,2} might be too big for
>    mmap_min_addr values equal or less than 1 MB (common case, e.g.  Ubuntu
>    uses only 0x10000).  There is little point to use such a big value given
>    the "poison pointer space" below 1 MB is not yet exhausted.  Changing it
>    to a smaller value solves the problem for small mmap_min_addr setups.
>    
>    The values are suggested by Solar Designer:
>    http://www.openwall.com/lists/oss-security/2015/05/02/6
>    
>    Signed-off-by: Vasily Kulikov <segoon@openwall.com>
>    Cc: Solar Designer <solar@openwall.com>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d979e967f848caf908a1401b7ad67cf13f06ef9f
>Author: David Howells <dhowells@redhat.com>
>Date:   Tue Nov 24 21:36:31 2015 +0000
>
>    KEYS: Fix handling of stored error in a negatively instantiated user key
>    
>    [ Upstream commit 096fe9eaea40a17e125569f9e657e34cdb6d73bd ]
>    
>    If a user key gets negatively instantiated, an error code is cached in the
>    payload area.  A negatively instantiated key may be then be positively
>    instantiated by updating it with valid data.  However, the ->update key
>    type method must be aware that the error code may be there.
>    
>    The following may be used to trigger the bug in the user key type:
>    
>        keyctl request2 user user "" @u
>        keyctl add user user "a" @u
>    
>    which manifests itself as:
>    
>    	BUG: unable to handle kernel paging request at 00000000ffffff8a
>    	IP: [<ffffffff810a376f>] __call_rcu.constprop.76+0x1f/0x280 kernel/rcu/tree.c:3046
>    	PGD 7cc30067 PUD 0
>    	Oops: 0002 [#1] SMP
>    	Modules linked in:
>    	CPU: 3 PID: 2644 Comm: a.out Not tainted 4.3.0+ #49
>    	Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>    	task: ffff88003ddea700 ti: ffff88003dd88000 task.ti: ffff88003dd88000
>    	RIP: 0010:[<ffffffff810a376f>]  [<ffffffff810a376f>] __call_rcu.constprop.76+0x1f/0x280
>    	 [<ffffffff810a376f>] __call_rcu.constprop.76+0x1f/0x280 kernel/rcu/tree.c:3046
>    	RSP: 0018:ffff88003dd8bdb0  EFLAGS: 00010246
>    	RAX: 00000000ffffff82 RBX: 0000000000000000 RCX: 0000000000000001
>    	RDX: ffffffff81e3fe40 RSI: 0000000000000000 RDI: 00000000ffffff82
>    	RBP: ffff88003dd8bde0 R08: ffff88007d2d2da0 R09: 0000000000000000
>    	R10: 0000000000000000 R11: ffff88003e8073c0 R12: 00000000ffffff82
>    	R13: ffff88003dd8be68 R14: ffff88007d027600 R15: ffff88003ddea700
>    	FS:  0000000000b92880(0063) GS:ffff88007fd00000(0000) knlGS:0000000000000000
>    	CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>    	CR2: 00000000ffffff8a CR3: 000000007cc5f000 CR4: 00000000000006e0
>    	Stack:
>    	 ffff88003dd8bdf0 ffffffff81160a8a 0000000000000000 00000000ffffff82
>    	 ffff88003dd8be68 ffff88007d027600 ffff88003dd8bdf0 ffffffff810a39e5
>    	 ffff88003dd8be20 ffffffff812a31ab ffff88007d027600 ffff88007d027620
>    	Call Trace:
>    	 [<ffffffff810a39e5>] kfree_call_rcu+0x15/0x20 kernel/rcu/tree.c:3136
>    	 [<ffffffff812a31ab>] user_update+0x8b/0xb0 security/keys/user_defined.c:129
>    	 [<     inline     >] __key_update security/keys/key.c:730
>    	 [<ffffffff8129e5c1>] key_create_or_update+0x291/0x440 security/keys/key.c:908
>    	 [<     inline     >] SYSC_add_key security/keys/keyctl.c:125
>    	 [<ffffffff8129fc21>] SyS_add_key+0x101/0x1e0 security/keys/keyctl.c:60
>    	 [<ffffffff8185f617>] entry_SYSCALL_64_fastpath+0x12/0x6a arch/x86/entry/entry_64.S:185
>    
>    Note the error code (-ENOKEY) in EDX.
>    
>    A similar bug can be tripped by:
>    
>        keyctl request2 trusted user "" @u
>        keyctl add trusted user "a" @u
>    
>    This should also affect encrypted keys - but that has to be correctly
>    parameterised or it will fail with EINVAL before getting to the bit that
>    will crashes.
>    
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Signed-off-by: David Howells <dhowells@redhat.com>
>    Acked-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
>    Signed-off-by: James Morris <james.l.morris@oracle.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 90352f3f473a29db1289ec31facc1ac18cc66e9e
>Author: Andrew Honig <ahonig@google.com>
>Date:   Wed Nov 18 14:50:23 2015 -0800
>
>    KVM: x86: Reload pit counters for all channels when restoring state
>    
>    [ Upstream commit 0185604c2d82c560dab2f2933a18f797e74ab5a8 ]
>    
>    Currently if userspace restores the pit counters with a count of 0
>    on channels 1 or 2 and the guest attempts to read the count on those
>    channels, then KVM will perform a mod of 0 and crash.  This will ensure
>    that 0 values are converted to 65536 as per the spec.
>    
>    This is CVE-2015-7513.
>    
>    Signed-off-by: Andy Honig <ahonig@google.com>
>    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ea44bf73d956729f3122bbed0661db7b18864277
>Author: Roman Gushchin <klamm@yandex-team.ru>
>Date:   Mon Oct 12 16:33:44 2015 +0300
>
>    fuse: break infinite loop in fuse_fill_write_pages()
>    
>    [ Upstream commit 3ca8138f014a913f98e6ef40e939868e1e9ea876 ]
>    
>    I got a report about unkillable task eating CPU. Further
>    investigation shows, that the problem is in the fuse_fill_write_pages()
>    function. If iov's first segment has zero length, we get an infinite
>    loop, because we never reach iov_iter_advance() call.
>    
>    Fix this by calling iov_iter_advance() before repeating an attempt to
>    copy data from userspace.
>    
>    A similar problem is described in 124d3b7041f ("fix writev regression:
>    pan hanging unkillable and un-straceable"). If zero-length segmend
>    is followed by segment with invalid address,
>    iov_iter_fault_in_readable() checks only first segment (zero-length),
>    iov_iter_copy_from_user_atomic() skips it, fails at second and
>    returns zero -> goto again without skipping zero-length segment.
>    
>    Patch calls iov_iter_advance() before goto again: we'll skip zero-length
>    segment at second iteraction and iov_iter_fault_in_readable() will detect
>    invalid address.
>    
>    Special thanks to Konstantin Khlebnikov, who helped a lot with the commit
>    description.
>    
>    Cc: Andrew Morton <akpm@linux-foundation.org>
>    Cc: Maxim Patlasov <mpatlasov@parallels.com>
>    Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
>    Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
>    Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
>    Fixes: ea9b9907b82a ("fuse: implement perform_write")
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2cadb57dff500076a87b934cac64bb5a2293b644
>Author: Miklos Szeredi <miklos@szeredi.hu>
>Date:   Fri Dec 4 19:18:48 2015 +0100
>
>    ovl: fix permission checking for setattr
>    
>    [ Upstream commit acff81ec2c79492b180fade3c2894425cd35a545 ]
>    
>    [Al Viro] The bug is in being too enthusiastic about optimizing ->setattr()
>    away - instead of "copy verbatim with metadata" + "chmod/chown/utimes"
>    (with the former being always safe and the latter failing in case of
>    insufficient permissions) it tries to combine these two.  Note that copyup
>    itself will have to do ->setattr() anyway; _that_ is where the elevated
>    capabilities are right.  Having these two ->setattr() (one to set verbatim
>    copy of metadata, another to do what overlayfs ->setattr() had been asked
>    to do in the first place) combined is where it breaks.
>    
>    Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 50d93d381508139a35a0f91a364fbdc1a38885d4
>Author: James Hogan <james.hogan@imgtec.com>
>Date:   Fri Mar 4 10:10:51 2016 +0000
>
>    MIPS: smp.c: Fix uninitialised temp_foreign_map
>    
>    [ Upstream commit d825c06bfe8b885b797f917ad47365d0e9c21fbb ]
>    
>    When calculate_cpu_foreign_map() recalculates the cpu_foreign_map
>    cpumask it uses the local variable temp_foreign_map without initialising
>    it to zero. Since the calculation only ever sets bits in this cpumask
>    any existing bits at that memory location will remain set and find their
>    way into cpu_foreign_map too. This could potentially lead to cache
>    operations suboptimally doing smp calls to multiple VPEs in the same
>    core, even though the VPEs share primary caches.
>    
>    Therefore initialise temp_foreign_map using cpumask_clear() before use.
>    
>    Fixes: cccf34e9411c ("MIPS: c-r4k: Fix cache flushing for MT cores")
>    Signed-off-by: James Hogan <james.hogan@imgtec.com>
>    Cc: Paul Burton <paul.burton@imgtec.com>
>    Cc: linux-mips@linux-mips.org
>    Patchwork: https://patchwork.linux-mips.org/patch/12759/
>    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9c99016a364ab695755e3a66c4dbfb53b9c07a0f
>Author: Andreas Schwab <schwab@linux-m68k.org>
>Date:   Fri Feb 5 19:50:03 2016 +0100
>
>    powerpc: Fix dedotify for binutils >= 2.26
>    
>    [ Upstream commit f15838e9cac8f78f0cc506529bb9d3b9fa589c1f ]
>    
>    Since binutils 2.26 BFD is doing suffix merging on STRTAB sections.  But
>    dedotify modifies the symbol names in place, which can also modify
>    unrelated symbols with a name that matches a suffix of a dotted name.  To
>    remove the leading dot of a symbol name we can just increment the pointer
>    into the STRTAB section instead.
>    
>    Backport to all stables to avoid breakage when people update their
>    binutils - mpe.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
>    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a490e8a46260de7257bbb0bfed9316f4a74cf524
>Author: Linus Torvalds <torvalds@linux-foundation.org>
>Date:   Mon Mar 7 13:15:09 2016 -0800
>
>    Revert "drm/radeon: call hpd_irq_event on resume"
>    
>    [ Upstream commit 256faedcfd646161477d47a1a78c32a562d2e845 ]
>    
>    This reverts commit dbb17a21c131eca94eb31136eee9a7fe5aff00d9.
>    
>    It turns out that commit can cause problems for systems with multiple
>    GPUs, and causes X to hang on at least a HP Pavilion dv7 with hybrid
>    graphics.
>    
>    This got noticed originally in 4.4.4, where this patch had already
>    gotten back-ported, but 4.5-rc7 was verified to have the same problem.
>    
>    Alexander Deucher says:
>     "It looks like you have a muxed system so I suspect what's happening is
>      that one of the display is being reported as connected for both the
>      IGP and the dGPU and then the desktop environment gets confused or
>      there some sort problem in the detect functions since the mux is not
>      switched to the dGPU.  I don't see an easy fix unless Dave has any
>      ideas.  I'd say just revert for now"
>    
>    Reported-by: JÃ¶rg-Volker Peetz <jvpeetz@web.de>
>    Acked-by: Alexander Deucher <Alexander.Deucher@amd.com>
>    Cc: Dave Airlie <airlied@gmail.com>
>    Cc: stable@kernel.org  # wherever dbb17a21c131 got back-ported
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit fc7260739ac5739520454788f2e8e667f92f1a29
>Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>Date:   Tue Mar 8 21:09:29 2016 +0700
>
>    arm64: account for sparsemem section alignment when choosing vmemmap offset
>    
>    [ Upstream commit 36e5cd6b897e17d03008f81e075625d8e43e52d0 ]
>    
>    Commit dfd55ad85e4a ("arm64: vmemmap: use virtual projection of linear
>    region") fixed an issue where the struct page array would overflow into the
>    adjacent virtual memory region if system RAM was placed so high up in
>    physical memory that its addresses were not representable in the build time
>    configured virtual address size.
>    
>    However, the fix failed to take into account that the vmemmap region needs
>    to be relatively aligned with respect to the sparsemem section size, so that
>    a sequence of page structs corresponding with a sparsemem section in the
>    linear region appears naturally aligned in the vmemmap region.
>    
>    So round up vmemmap to sparsemem section size. Since this essentially moves
>    the projection of the linear region up in memory, also revert the reduction
>    of the size of the vmemmap region.
>    
>    Cc: <stable@vger.kernel.org>
>    Fixes: dfd55ad85e4a ("arm64: vmemmap: use virtual projection of linear region")
>    Tested-by: Mark Langsdorf <mlangsdo@redhat.com>
>    Tested-by: David Daney <david.daney@cavium.com>
>    Tested-by: Robert Richter <rrichter@cavium.com>
>    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
>    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>    Signed-off-by: Will Deacon <will.deacon@arm.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6d7ac2feca9c07d9ce489dbaab2f51beb3e5c107
>Author: Rusty Russell <rusty@rustcorp.com.au>
>Date:   Wed Feb 3 16:55:26 2016 +1030
>
>    modules: fix longstanding /proc/kallsyms vs module insertion race.
>    
>    [ Upstream commit 8244062ef1e54502ef55f54cced659913f244c3e ]
>    
>    For CONFIG_KALLSYMS, we keep two symbol tables and two string tables.
>    There's one full copy, marked SHF_ALLOC and laid out at the end of the
>    module's init section.  There's also a cut-down version that only
>    contains core symbols and strings, and lives in the module's core
>    section.
>    
>    After module init (and before we free the module memory), we switch
>    the mod->symtab, mod->num_symtab and mod->strtab to point to the core
>    versions.  We do this under the module_mutex.
>    
>    However, kallsyms doesn't take the module_mutex: it uses
>    preempt_disable() and rcu tricks to walk through the modules, because
>    it's used in the oops path.  It's also used in /proc/kallsyms.
>    There's nothing atomic about the change of these variables, so we can
>    get the old (larger!) num_symtab and the new symtab pointer; in fact
>    this is what I saw when trying to reproduce.
>    
>    By grouping these variables together, we can use a
>    carefully-dereferenced pointer to ensure we always get one or the
>    other (the free of the module init section is already done in an RCU
>    callback, so that's safe).  We allocate the init one at the end of the
>    module init section, and keep the core one inside the struct module
>    itself (it could also have been allocated at the end of the module
>    core, but that's probably overkill).
>    
>    Reported-by: Weilong Chen <chenweilong@huawei.com>
>    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=111541
>    Cc: stable@kernel.org
>    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit abae284042df82086a1edbf3512c9f4cd355c6e4
>Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>Date:   Fri Feb 26 17:57:13 2016 +0100
>
>    arm64: vmemmap: use virtual projection of linear region
>    
>    [ Upstream commit dfd55ad85e4a7fbaa82df12467515ac3c81e8a3e ]
>    
>    Commit dd006da21646 ("arm64: mm: increase VA range of identity map") made
>    some changes to the memory mapping code to allow physical memory to reside
>    at an offset that exceeds the size of the virtual mapping.
>    
>    However, since the size of the vmemmap area is proportional to the size of
>    the VA area, but it is populated relative to the physical space, we may
>    end up with the struct page array being mapped outside of the vmemmap
>    region. For instance, on my Seattle A0 box, I can see the following output
>    in the dmesg log.
>    
>       vmemmap : 0xffffffbdc0000000 - 0xffffffbfc0000000   (     8 GB maximum)
>                 0xffffffbfc0000000 - 0xffffffbfd0000000   (   256 MB actual)
>    
>    We can fix this by deciding that the vmemmap region is not a projection of
>    the physical space, but of the virtual space above PAGE_OFFSET, i.e., the
>    linear region. This way, we are guaranteed that the vmemmap region is of
>    sufficient size, and we can even reduce the size by half.
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>    Signed-off-by: Will Deacon <will.deacon@arm.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b9a54ed91c7bbd5c18a4170be078d9f7e28560ed
>Author: Qu Wenruo <quwenruo@cn.fujitsu.com>
>Date:   Fri Jan 22 09:28:38 2016 +0800
>
>    btrfs: async-thread: Fix a use-after-free error for trace
>    
>    [ Upstream commit 0a95b851370b84a4b9d92ee6d1fa0926901d0454 ]
>    
>    Parameter of trace_btrfs_work_queued() can be freed in its workqueue.
>    So no one use use that pointer after queue_work().
>    
>    Fix the user-after-free bug by move the trace line before queue_work().
>    
>    Reported-by: Dave Jones <davej@codemonkey.org.uk>
>    Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
>    Reviewed-by: David Sterba <dsterba@suse.com>
>    Signed-off-by: Chris Mason <clm@fb.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d5b55a7aae08c0e0785430126bcc4a9ae7f5c737
>Author: Zhao Lei <zhaolei@cn.fujitsu.com>
>Date:   Tue Dec 1 18:39:40 2015 +0800
>
>    btrfs: Fix no_space in write and rm loop
>    
>    [ Upstream commit 08acfd9dd845dc052c5eae33e6c3976338070069 ]
>    
>    commit e1746e8381cd2af421f75557b5cae3604fc18b35 upstream.
>    
>    I see no_space in v4.4-rc1 again in xfstests generic/102.
>    It happened randomly in some node only.
>    (one of 4 phy-node, and a kvm with non-virtio block driver)
>    
>    By bisect, we can found the first-bad is:
>     commit bdced438acd8 ("block: setup bi_phys_segments after splitting")'
>    But above patch only triggered the bug by making bio operation
>    faster(or slower).
>    
>    Main reason is in our space_allocating code, we need to commit
>    page writeback before wait it complish, this patch fixed above
>    bug.
>    
>    BTW, there is another reason for generic/102 fail, caused by
>    disable default mixed-blockgroup, I'll fix it in xfstests.
>    
>    Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
>    Signed-off-by: Chris Mason <clm@fb.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 42bd8f4fda813558c3045c60ad6436b1c7430ec7
>Author: Zhao Lei <zhaolei@cn.fujitsu.com>
>Date:   Thu Apr 9 12:34:43 2015 +0800
>
>    btrfs: wait for delayed iputs on no space
>    
>    [ Upstream commit 9a4e7276d39071576d369e607d7accb84b41d0b4 ]
>    
>    btrfs will report no_space when we run following write and delete
>    file loop:
>     # FILE_SIZE_M=[ 75% of fs space ]
>     # DEV=[ some dev ]
>     # MNT=[ some dir ]
>     #
>     # mkfs.btrfs -f "$DEV"
>     # mount -o nodatacow "$DEV" "$MNT"
>     # for ((i = 0; i < 100; i++)); do dd if=/dev/zero of="$MNT"/file0 bs=1M count="$FILE_SIZE_M"; rm -f "$MNT"/file0; done
>     #
>    
>    Reason:
>     iput() and evict() is run after write pages to block device, if
>     write pages work is not finished before next write, the "rm"ed space
>     is not freed, and caused above bug.
>    
>    Fix:
>     We can add "-o flushoncommit" mount option to avoid above bug, but
>     it have performance problem. Actually, we can to wait for on-the-fly
>     writes only when no-space happened, it is which this patch do.
>    
>    Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
>    Signed-off-by: Chris Mason <clm@fb.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ee6ad435c9872610c5a52cad02e331951cf2fb25
>Author: Jann Horn <jann@thejh.net>
>Date:   Wed Jan 20 15:00:01 2016 -0800
>
>    security: let security modules use PTRACE_MODE_* with bitmasks
>    
>    [ Upstream commit 3dfb7d8cdbc7ea0c2970450e60818bb3eefbad69 ]
>    
>    It looks like smack and yama weren't aware that the ptrace mode
>    can have flags ORed into it - PTRACE_MODE_NOAUDIT until now, but
>    only for /proc/$pid/stat, and with the PTRACE_MODE_*CREDS patch,
>    all modes have flags ORed into them.
>    
>    Signed-off-by: Jann Horn <jann@thejh.net>
>    Acked-by: Kees Cook <keescook@chromium.org>
>    Acked-by: Casey Schaufler <casey@schaufler-ca.com>
>    Cc: Oleg Nesterov <oleg@redhat.com>
>    Cc: Ingo Molnar <mingo@redhat.com>
>    Cc: James Morris <james.l.morris@oracle.com>
>    Cc: "Serge E. Hallyn" <serge.hallyn@ubuntu.com>
>    Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>    Cc: Andy Lutomirski <luto@kernel.org>
>    Cc: Al Viro <viro@zeniv.linux.org.uk>
>    Cc: "Eric W. Biederman" <ebiederm@xmission.com>
>    Cc: Willy Tarreau <w@1wt.eu>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1f9780e372264c0cd71571c94da08cc49ae327e3
>Author: Andy Lutomirski <luto@kernel.org>
>Date:   Wed Feb 24 12:18:49 2016 -0800
>
>    x86/entry/compat: Add missing CLAC to entry_INT80_32
>    
>    [ Upstream commit 3d44d51bd339766f0178f0cf2e8d048b4a4872aa ]
>    
>    This doesn't seem to fix a regression -- I don't think the CLAC was
>    ever there.
>    
>    I double-checked in a debugger: entries through the int80 gate do
>    not automatically clear AC.
>    
>    Stable maintainers: I can provide a backport to 4.3 and earlier if
>    needed.  This needs to be backported all the way to 3.10.
>    
>    Reported-by: Brian Gerst <brgerst@gmail.com>
>    Signed-off-by: Andy Lutomirski <luto@kernel.org>
>    Cc: Andy Lutomirski <luto@amacapital.net>
>    Cc: Borislav Petkov <bp@alien8.de>
>    Cc: Denys Vlasenko <dvlasenk@redhat.com>
>    Cc: H. Peter Anvin <hpa@zytor.com>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Cc: <stable@vger.kernel.org> # v3.10 and later
>    Fixes: 63bcff2a307b ("x86, smap: Add STAC and CLAC instructions to control user space access")
>    Link: http://lkml.kernel.org/r/b02b7e71ae54074be01fc171cbd4b72517055c0e.1456345086.git.luto@kernel.org
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit aa1311b426d5cc249887c8cbfa21a6dda2c5a201
>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()
>    
>    [ Upstream commit 59ceeaaf355fa0fb16558ef7c24413c804932ada ]
>    
>    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>
>    Cc: stable@kernel.org
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 474510b43af63bc2bddf394270432e6f3ea22433
>Author: Hans de Goede <hdegoede@redhat.com>
>Date:   Fri Jan 22 11:41:05 2016 +0100
>
>    ACPI: Revert "ACPI / video: Add Dell Inspiron 5737 to the blacklist"
>    
>    [ Upstream commit b186b4dcb79b1914c3dadb27ac72dafaa4267998 ]
>    
>    The quirk to get "acpi_backlight=vendor" behavior by default on the
>    Dell Inspiron 5737 was added before we started doing
>    "acpi_backlight=native" by default on Win8 ready machines.
>    
>    Since we now avoid using acpi-video as backlight driver on these machines
>    by default (using the native driver instead) we no longer need this quirk.
>    
>    Moreover the vendor driver does not work after a suspend/resume where
>    as the native driver does.
>    
>    This reverts commit 08a56226d847 (ACPI / video: Add Dell Inspiron 5737
>    to the blacklist).
>    
>    Link: https://bugzilla.kernel.org/show_bug.cgi?id=111061
>    Cc: 3.19+ <stable@vger.kernel.org> # 3.19+
>    Reported-and-tested-by: erusan@gmail.com
>    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e159282ea85a27ebeb4d9c4869b41bf192bcf5f8
>Author: Mykola Lysenko <Mykola.Lysenko@amd.com>
>Date:   Wed Jan 27 09:39:36 2016 -0500
>
>    drm/dp/mst: deallocate payload on port destruction
>    
>    [ Upstream commit 91a25e463130c8e19bdb42f2d827836c7937992e ]
>    
>    This is needed to properly deallocate port payload
>    after downstream branch get unplugged.
>    
>    In order to do this unplugged MST topology should
>    be preserved, to find first alive port on path to
>    unplugged MST topology, and send payload deallocation
>    request to branch device of found port.
>    
>    For this mstb and port kref's are used in reversed
>    order to track when port and branch memory could be
>    freed.
>    
>    Added additional functions to find appropriate mstb
>    as described above.
>    
>    Signed-off-by: Mykola Lysenko <Mykola.Lysenko@amd.com>
>    Reviewed-by: Harry Wentland <Harry.Wentland@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Dave Airlie <airlied@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9cc696013c324d36c1ffbc4160d5cdf698ee490b
>Author: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com>
>Date:   Fri Jan 22 17:07:29 2016 -0500
>
>    drm/dp/mst: Reverse order of MST enable and clearing VC payload table.
>    
>    [ Upstream commit c175cd16df272119534058f28cbd5eeac6ff2d24 ]
>    
>    On DELL U3014 if you clear the table before enabling MST it sometimes
>    hangs the receiver.
>    
>    Signed-off-by: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com>
>    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
>    Cc: stable@vger.kernel.org
>    Acked-by: Alex Deucher <alexander.deucher@amd.com>
>    Signed-off-by: Dave Airlie <airlied@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 11dd4e27c5ef9fed4d10a35303903227c5df689d
>Author: Hersen Wu <hersenxs.wu@amd.com>
>Date:   Fri Jan 22 17:07:28 2016 -0500
>
>    drm/dp/mst: move GUID storage from mgr, port to only mst branch
>    
>    [ Upstream commit 5e93b8208d3c419b515fb75e2601931c027e12ab ]
>    
>    Previous implementation does not handle case below: boot up one MST branch
>    to DP connector of ASIC. After boot up, hot plug 2nd MST branch to DP output
>    of 1st MST, GUID is not created for 2nd MST branch. When downstream port of
>    2nd MST branch send upstream request, it fails because 2nd MST branch GUID
>    is not available.
>    
>    New Implementation: only create GUID for MST branch and save it within Branch.
>    
>    Signed-off-by: Hersen Wu <hersenxs.wu@amd.com>
>    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
>    Cc: stable@vger.kernel.org
>    Acked-by: Alex Deucher <alexander.deucher@amd.com>
>    Signed-off-by: Dave Airlie <airlied@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1505f5ae8ac52b4c9cda088ca8113e1f0ec2f32f
>Author: Sekhar Nori <nsekhar@ti.com>
>Date:   Tue Dec 15 19:56:12 2015 +0530
>
>    irqchip/omap-intc: Add support for spurious irq handling
>    
>    [ Upstream commit d3b421cd07e4c0d4d6c0bbd55ca169c054fc081d ]
>    
>    Under some conditions, irq sorting procedure used by INTC can go wrong
>    resulting in a spurious irq getting reported.
>    
>    If this condition is not handled, it results in endless stream of:
>    
>        unexpected IRQ trap at vector 00
>    
>    messages from ack_bad_irq()
>    
>    Handle the spurious interrupt condition in omap-intc driver to prevent this.
>    
>    Measurements using kernel function profiler on AM335x EVM running at 720MHz
>    show that after this patch omap_intc_handle_irq() takes about 37.4us against
>    34us before this patch.
>    
>    Signed-off-by: Sekhar Nori <nsekhar@ti.com>
>    Acked-by: Tony Lindgren <tony@atomide.com>
>    Cc: John Ogness <john.ogness@linutronix.de>
>    Cc: Felipe Balbi <balbi@ti.com>
>    Cc: Jason Cooper <jason@lakedaemon.net>
>    Cc: Marc Zyngier <marc.zyngier@arm.com>
>    Link: http://lkml.kernel.org/r/9c78a6db02ac55f7af7371b417b6e414d2c3095b.1450188128.git.nsekhar@ti.com
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 249ee7541e9bfc313cbe11f2816e902f9612ceec
>Author: Felipe Balbi <balbi@ti.com>
>Date:   Fri Jan 2 16:18:54 2015 -0600
>
>    irqchip: omap-intc: Improve IRQ handler
>    
>    [ Upstream commit 6ed3464897cc825a75218653c710d673282dfcf8 ]
>    
>    As it turns out the current IRQ number will *always* be available from
>    SIR register which renders the reads of PENDING registers as plain
>    unnecessary overhead.
>    
>    In order to catch any situation where SIR reads as zero, we're adding
>    a WARN() to turn it into a very verbose error and users actually
>    report it.
>    
>    With this patch average running time of omap_intc_handle_irq() reduced
>    from about 28.5us to 19.8us as measured by the kernel function
>    profiler.
>    
>    Tested with BeagleBoneBlack Rev A5C.
>    
>    Tested-by: Tony Lindgren <tony@atomide.com>
>    Signed-off-by: Felipe Balbi <balbi@ti.com>
>    Cc: Linux ARM Kernel Mailing List <linux-arm-kernel@lists.infradead.org>
>    Link: http://lkml.kernel.org/r/20150720204910.GH5394@saruman.tx.rr.com
>    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 610ed2802923b6d0204513b6cb7cf22fdbeec38b
>Author: Laura Abbott <labbott@fedoraproject.org>
>Date:   Mon Oct 5 19:33:29 2015 -0300
>
>    [media] si2157: return -EINVAL if firmware blob is too big
>    
>    [ Upstream commit d2cc2f0b35465951eaaf0387fd55e29835ed7ea6 ]
>    
>    A previous patch added a check if the firmware is too big, but it didn't
>    set the return error code with the right value.
>    
>    [mchehab@osg.samsung.com: I ended by applying a v1 of Laura's patch, without
>     the proper return code. This patch contains the difference between v2 and v1 of
>     the Laura's "si2157: Bounds check firmware" patch]
>    Cc: stable@kernel.org
>    Signed-off-by: Laura Abbott <labbott@fedoraproject.org>
>    Reviewed-by: Olli Salonen <olli.salonen@iki.fi>
>    Tested-by: Olli Salonen <olli.salonen@iki.fi>
>    
>    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2068256b08824ad53b28fb08952b62dd35e66593
>Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>Date:   Fri Jan 15 14:37:15 2016 +0100
>
>    btrfs: initialize the seq counter in struct btrfs_device
>    
>    [ Upstream commit 546bed631203344611f42b2af1d224d2eedb4e6b ]
>    
>    I managed to trigger this:
>    | INFO: trying to register non-static key.
>    | the code is fine but needs lockdep annotation.
>    | turning off the locking correctness validator.
>    | CPU: 1 PID: 781 Comm: systemd-gpt-aut Not tainted 4.4.0-rt2+ #14
>    | Hardware name: ARM-Versatile Express
>    | [<80307cec>] (dump_stack)
>    | [<80070e98>] (__lock_acquire)
>    | [<8007184c>] (lock_acquire)
>    | [<80287800>] (btrfs_ioctl)
>    | [<8012a8d4>] (do_vfs_ioctl)
>    | [<8012ac14>] (SyS_ioctl)
>    
>    so I think that btrfs_device_data_ordered_init() is not invoked behind
>    a macro somewhere.
>    
>    Fixes: 7cc8e58d53cd ("Btrfs: fix unprotected device's variants on 32bits machine")
>    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>    Reviewed-by: David Sterba <dsterba@suse.com>
>    Signed-off-by: David Sterba <dsterba@suse.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c19cd7e350c5ad9f3f4b3e486dbb4dab737a22a4
>Author: Chandan Rajendra <chandan@linux.vnet.ibm.com>
>Date:   Thu Jan 7 18:56:59 2016 +0530
>
>    Btrfs: Initialize btrfs_root->highest_objectid when loading tree root and subvolume roots
>    
>    [ Upstream commit f32e48e925964c4f8ab917850788a87e1cef3bad ]
>    
>    The following call trace is seen when btrfs/031 test is executed in a loop,
>    
>    [  158.661848] ------------[ cut here ]------------
>    [  158.662634] WARNING: CPU: 2 PID: 890 at /home/chandan/repos/linux/fs/btrfs/ioctl.c:558 create_subvol+0x3d1/0x6ea()
>    [  158.664102] BTRFS: Transaction aborted (error -2)
>    [  158.664774] Modules linked in:
>    [  158.665266] CPU: 2 PID: 890 Comm: btrfs Not tainted 4.4.0-rc6-g511711a #2
>    [  158.666251] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>    [  158.667392]  ffffffff81c0a6b0 ffff8806c7c4f8e8 ffffffff81431fc8 ffff8806c7c4f930
>    [  158.668515]  ffff8806c7c4f920 ffffffff81051aa1 ffff880c85aff000 ffff8800bb44d000
>    [  158.669647]  ffff8808863b5c98 0000000000000000 00000000fffffffe ffff8806c7c4f980
>    [  158.670769] Call Trace:
>    [  158.671153]  [<ffffffff81431fc8>] dump_stack+0x44/0x5c
>    [  158.671884]  [<ffffffff81051aa1>] warn_slowpath_common+0x81/0xc0
>    [  158.672769]  [<ffffffff81051b27>] warn_slowpath_fmt+0x47/0x50
>    [  158.673620]  [<ffffffff813bc98d>] create_subvol+0x3d1/0x6ea
>    [  158.674440]  [<ffffffff813777c9>] btrfs_mksubvol.isra.30+0x369/0x520
>    [  158.675376]  [<ffffffff8108a4aa>] ? percpu_down_read+0x1a/0x50
>    [  158.676235]  [<ffffffff81377a81>] btrfs_ioctl_snap_create_transid+0x101/0x180
>    [  158.677268]  [<ffffffff81377b52>] btrfs_ioctl_snap_create+0x52/0x70
>    [  158.678183]  [<ffffffff8137afb4>] btrfs_ioctl+0x474/0x2f90
>    [  158.678975]  [<ffffffff81144b8e>] ? vma_merge+0xee/0x300
>    [  158.679751]  [<ffffffff8115be31>] ? alloc_pages_vma+0x91/0x170
>    [  158.680599]  [<ffffffff81123f62>] ? lru_cache_add_active_or_unevictable+0x22/0x70
>    [  158.681686]  [<ffffffff813d99cf>] ? selinux_file_ioctl+0xff/0x1d0
>    [  158.682581]  [<ffffffff8117b791>] do_vfs_ioctl+0x2c1/0x490
>    [  158.683399]  [<ffffffff813d3cde>] ? security_file_ioctl+0x3e/0x60
>    [  158.684297]  [<ffffffff8117b9d4>] SyS_ioctl+0x74/0x80
>    [  158.685051]  [<ffffffff819b2bd7>] entry_SYSCALL_64_fastpath+0x12/0x6a
>    [  158.685958] ---[ end trace 4b63312de5a2cb76 ]---
>    [  158.686647] BTRFS: error (device loop0) in create_subvol:558: errno=-2 No such entry
>    [  158.709508] BTRFS info (device loop0): forced readonly
>    [  158.737113] BTRFS info (device loop0): disk space caching is enabled
>    [  158.738096] BTRFS error (device loop0): Remounting read-write after error is not allowed
>    [  158.851303] BTRFS error (device loop0): cleaner transaction attach returned -30
>    
>    This occurs because,
>    
>    Mount filesystem
>    Create subvol with ID 257
>    Unmount filesystem
>    Mount filesystem
>    Delete subvol with ID 257
>      btrfs_drop_snapshot()
>        Add root corresponding to subvol 257 into
>        btrfs_transaction->dropped_roots list
>    Create new subvol (i.e. create_subvol())
>      257 is returned as the next free objectid
>      btrfs_read_fs_root_no_name()
>        Finds the btrfs_root instance corresponding to the old subvol with ID 257
>        in btrfs_fs_info->fs_roots_radix.
>        Returns error since btrfs_root_item->refs has the value of 0.
>    
>    To fix the issue the commit initializes tree root's and subvolume root's
>    highest_objectid when loading the roots from disk.
>    
>    Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
>    Signed-off-by: David Sterba <dsterba@suse.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9bf972e8aa6110d750cf1ddab68511f478a6a751
>Author: Filipe Manana <fdmanana@suse.com>
>Date:   Tue Jan 5 16:24:05 2016 +0000
>
>    Btrfs: fix transaction handle leak on failure to create hard link
>    
>    [ Upstream commit 271dba4521aed0c37c063548f876b49f5cd64b2e ]
>    
>    If we failed to create a hard link we were not always releasing the
>    the transaction handle we got before, resulting in a memory leak and
>    preventing any other tasks from being able to commit the current
>    transaction.
>    Fix this by always releasing our transaction handle.
>    
>    Signed-off-by: Filipe Manana <fdmanana@suse.com>
>    Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a1f535acffbd95ae6ae81656e8bba39af094c3f0
>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
>    
>    [ Upstream commit 9269d12b2d57d9e3d13036bb750762d1110d425c ]
>    
>    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: Sasha Levin <sasha.levin@oracle.com>
>
>commit e92c51b734d57e04f0c9b43106b5294834339be6
>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
>    
>    [ Upstream commit a879719b8c90e15c9e7fa7266d5e3c0ca962f9df ]
>    
>    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: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4e3fa12f124507ad17f999c28ef35803596ff2c6
>Author: David Sterba <dsterba@suse.com>
>Date:   Sat Oct 10 17:59:53 2015 +0200
>
>    btrfs: statfs: report zero available if metadata are exhausted
>    
>    [ Upstream commit ca8a51b3a979d57b082b14eda38602b7f52d81d1 ]
>    
>    There is one ENOSPC case that's very confusing. There's Available
>    greater than zero but no file operation succeds (besides removing
>    files). This happens when the metadata are exhausted and there's no
>    possibility to allocate another chunk.
>    
>    In this scenario it's normal that there's still some space in the data
>    chunk and the calculation in df reflects that in the Avail value.
>    
>    To at least give some clue about the ENOSPC situation, let statfs report
>    zero value in Avail, even if there's still data space available.
>    
>    Current:
>      /dev/sdb1             4.0G  3.3G  719M  83% /mnt/test
>    
>    New:
>      /dev/sdb1             4.0G  3.3G     0 100% /mnt/test
>    
>    We calculate the remaining metadata space minus global reserve. If this
>    is (supposedly) smaller than zero, there's no space. But this does not
>    hold in practice, the exhausted state happens where's still some
>    positive delta. So we apply some guesswork and compare the delta to a 4M
>    threshold. (Practically observed delta was 2M.)
>    
>    We probably cannot calculate the exact threshold value because this
>    depends on the internal reservations requested by various operations, so
>    some operations that consume a few metadata will succeed even if the
>    Avail is zero. But this is better than the other way around.
>    
>    Signed-off-by: David Sterba <dsterba@suse.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit bb055e837f904fdc80d4d82819b0a9aaf35dce4a
>Author: Josef Bacik <jbacik@fb.com>
>Date:   Thu Oct 22 15:05:09 2015 -0400
>
>    Btrfs: igrab inode in writepage
>    
>    [ Upstream commit be7bd730841e69fe8f70120098596f648cd1f3ff ]
>    
>    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: Sasha Levin <sasha.levin@oracle.com>
>
>commit c0109d289de5a48e54a2d070981a629fc241f112
>Author: Anand Jain <anand.jain@oracle.com>
>Date:   Wed Oct 7 17:23:23 2015 +0800
>
>    Btrfs: add missing brelse when superblock checksum fails
>    
>    [ Upstream commit b2acdddfad13c38a1e8b927d83c3cf321f63601a ]
>    
>    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: Sasha Levin <sasha.levin@oracle.com>
>
>commit dd25a5d97400cb10a85a09eac07d541975e39522
>Author: Hariprasad S <hariprasad@chelsio.com>
>Date:   Fri Dec 11 13:59:17 2015 +0530
>
>    iw_cxgb3: Fix incorrectly returning error on success
>    
>    [ Upstream commit 67f1aee6f45059fd6b0f5b0ecb2c97ad0451f6b3 ]
>    
>    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>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2f53ace471375e60b3ba1b5341f673e8b36684aa
>Author: Jason Andryuk <jandryuk@gmail.com>
>Date:   Fri Feb 12 23:13:33 2016 +0000
>
>    lib/ucs2_string: Correct ucs2 -> utf8 conversion
>    
>    [ Upstream commit a68075908a37850918ad96b056acc9ac4ce1bd90 ]
>    
>    The comparisons should be >= since 0x800 and 0x80 require an additional bit
>    to store.
>    
>    For the 3 byte case, the existing shift would drop off 2 more bits than
>    intended.
>    
>    For the 2 byte case, there should be 5 bits bits in byte 1, and 6 bits in
>    byte 2.
>    
>    Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
>    Reviewed-by: Laszlo Ersek <lersek@redhat.com>
>    Cc: Peter Jones <pjones@redhat.com>
>    Cc: Matthew Garrett <mjg59@coreos.com>
>    Cc: "Lee, Chun-Yi" <jlee@suse.com>
>    Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit cbf3d65e135a43cf654f10037eafe6f9be14baf5
>Author: Matt Fleming <matt@codeblueprint.co.uk>
>Date:   Mon Feb 15 10:34:05 2016 +0000
>
>    efi: Add pstore variables to the deletion whitelist
>    
>    [ Upstream commit e246eb568bc4cbbdd8a30a3c11151ff9b7ca7312 ]
>    
>    Laszlo explains why this is a good idea,
>    
>     'This is because the pstore filesystem can be backed by UEFI variables,
>      and (for example) a crash might dump the last kilobytes of the dmesg
>      into a number of pstore entries, each entry backed by a separate UEFI
>      variable in the above GUID namespace, and with a variable name
>      according to the above pattern.
>    
>      Please see "drivers/firmware/efi/efi-pstore.c".
>    
>      While this patch series will not prevent the user from deleting those
>      UEFI variables via the pstore filesystem (i.e., deleting a pstore fs
>      entry will continue to delete the backing UEFI variable), I think it
>      would be nice to preserve the possibility for the sysadmin to delete
>      Linux-created UEFI variables that carry portions of the crash log,
>      *without* having to mount the pstore filesystem.'
>    
>    There's also no chance of causing machines to become bricked by
>    deleting these variables, which is the whole purpose of excluding
>    things from the whitelist.
>    
>    Use the LINUX_EFI_CRASH_GUID guid and a wildcard '*' for the match so
>    that we don't have to update the string in the future if new variable
>    name formats are created for crash dump variables.
>    
>    Reported-by: Laszlo Ersek <lersek@redhat.com>
>    Acked-by: Peter Jones <pjones@redhat.com>
>    Tested-by: Peter Jones <pjones@redhat.com>
>    Cc: Matthew Garrett <mjg59@srcf.ucam.org>
>    Cc: "Lee, Chun-Yi" <jlee@suse.com>
>    Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3e49b9ec16de14ec3210e87c4307ffdb75cfe0b0
>Author: Peter Jones <pjones@redhat.com>
>Date:   Mon Feb 8 14:48:15 2016 -0500
>
>    efi: Make efivarfs entries immutable by default
>    
>    [ Upstream commit ed8b0de5a33d2a2557dce7f9429dca8cb5bc5879 ]
>    
>    "rm -rf" is bricking some peoples' laptops because of variables being
>    used to store non-reinitializable firmware driver data that's required
>    to POST the hardware.
>    
>    These are 100% bugs, and they need to be fixed, but in the mean time it
>    shouldn't be easy to *accidentally* brick machines.
>    
>    We have to have delete working, and picking which variables do and don't
>    work for deletion is quite intractable, so instead make everything
>    immutable by default (except for a whitelist), and make tools that
>    aren't quite so broad-spectrum unset the immutable flag.
>    
>    Signed-off-by: Peter Jones <pjones@redhat.com>
>    Tested-by: Lee, Chun-Yi <jlee@suse.com>
>    Acked-by: Matthew Garrett <mjg59@coreos.com>
>    Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c3f517d4cd9a1478ae99f873697444a8690de482
>Author: Peter Jones <pjones@redhat.com>
>Date:   Mon Feb 8 14:48:14 2016 -0500
>
>    efi: Make our variable validation list include the guid
>    
>    [ Upstream commit 8282f5d9c17fe15a9e658c06e3f343efae1a2a2f ]
>    
>    All the variables in this list so far are defined to be in the global
>    namespace in the UEFI spec, so this just further ensures we're
>    validating the variables we think we are.
>    
>    Including the guid for entries will become more important in future
>    patches when we decide whether or not to allow deletion of variables
>    based on presence in this list.
>    
>    Signed-off-by: Peter Jones <pjones@redhat.com>
>    Tested-by: Lee, Chun-Yi <jlee@suse.com>
>    Acked-by: Matthew Garrett <mjg59@coreos.com>
>    Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d5181a51587102a71e7b05021603693f463dcab2
>Author: Peter Jones <pjones@redhat.com>
>Date:   Mon Feb 8 14:48:13 2016 -0500
>
>    efi: Do variable name validation tests in utf8
>    
>    [ Upstream commit 3dcb1f55dfc7631695e69df4a0d589ce5274bd07 ]
>    
>    Actually translate from ucs2 to utf8 before doing the test, and then
>    test against our other utf8 data, instead of fudging it.
>    
>    Signed-off-by: Peter Jones <pjones@redhat.com>
>    Acked-by: Matthew Garrett <mjg59@coreos.com>
>    Tested-by: Lee, Chun-Yi <jlee@suse.com>
>    Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4181c95f943d60cff60e36e25368d0f627458ada
>Author: Peter Jones <pjones@redhat.com>
>Date:   Mon Feb 8 14:48:12 2016 -0500
>
>    efi: Use ucs2_as_utf8 in efivarfs instead of open coding a bad version
>    
>    [ Upstream commit e0d64e6a880e64545ad7d55786aa84ab76bac475 ]
>    
>    Translate EFI's UCS-2 variable names to UTF-8 instead of just assuming
>    all variable names fit in ASCII.
>    
>    Signed-off-by: Peter Jones <pjones@redhat.com>
>    Acked-by: Matthew Garrett <mjg59@coreos.com>
>    Tested-by: Lee, Chun-Yi <jlee@suse.com>
>    Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 973fc47992c915d37b1b802188bdfda1cfd2ed51
>Author: Dan Carpenter <dan.carpenter@oracle.com>
>Date:   Tue Apr 21 12:21:53 2015 +0300
>
>    efi: efivar_create_sysfs_entry() should return negative error codes
>    
>    [ Upstream commit f7ef7e3e506023f826c1ee60b7e59b985316e180 ]
>    
>    It's not very normal to return 1 on failure and 0 on success.  There
>    isn't a reason for it here, the callers don't care so long as it's
>    non-zero on failure.
>    
>    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 809f952a39a2ccb9667f8b88b4ad283459b2880a
>Author: Peter Jones <pjones@redhat.com>
>Date:   Mon Feb 8 14:48:11 2016 -0500
>
>    lib/ucs2_string: Add ucs2 -> utf8 helper functions
>    
>    [ Upstream commit 73500267c930baadadb0d02284909731baf151f7 ]
>    
>    This adds ucs2_utf8size(), which tells us how big our ucs2 string is in
>    bytes, and ucs2_as_utf8, which translates from ucs2 to utf8..
>    
>    Signed-off-by: Peter Jones <pjones@redhat.com>
>    Tested-by: Lee, Chun-Yi <jlee@suse.com>
>    Acked-by: Matthew Garrett <mjg59@coreos.com>
>    Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 17cd5f95550aff7619ed4e2b2b0a0f9607d09431
>Author: Arnd Bergmann <arnd@arndb.de>
>Date:   Thu Nov 19 15:03:57 2015 +0100
>
>    ARM: 8457/1: psci-smp is built only for SMP
>    
>    [ Upstream commit be95485a0b8288a93402705730d3ea32f9f812b9 ]
>    
>    The PSCI SMP implementation is built only when both CONFIG_SMP and
>    CONFIG_ARM_PSCI are set, so a configuration that has the latter
>    but not the former can get a link error when it tries to call
>    psci_smp_available().
>    
>    arch/arm/mach-tegra/built-in.o: In function `tegra114_cpuidle_init':
>    cpuidle-tegra114.c:(.init.text+0x52a): undefined reference to `psci_smp_available'
>    
>    This corrects the #ifdef in the psci.h header file to match the
>    Makefile conditional we have for building that function.
>    
>    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 527435d6f08f8b42d23b4ec3616169dc9ab1c40b
>Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>Date:   Mon Nov 23 10:32:49 2015 +0100
>
>    drm/gma500: Use correct unref in the gem bo create function
>    
>    [ Upstream commit d3e376f52d095103ca51dbda4d6ff8aaf488f98f ]
>    
>    This is called without dev->struct_mutex held, we need to use the
>    _unlocked variant.
>    
>    Never caught in the wild since you'd need an evil userspace which
>    races a gem_close ioctl call with the in-progress open.
>    
>    Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
>    Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
>    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>    Link: http://patchwork.freedesktop.org/patch/msgid/1448271183-20523-17-git-send-email-daniel.vetter@ffwll.ch
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a7635d6a0849007d2192bc02c038cc1b9d91b274
>Author: Jan Kara <jack@suse.com>
>Date:   Fri Feb 19 00:18:25 2016 -0500
>
>    ext4: fix bh->b_state corruption
>    
>    [ Upstream commit ed8ad83808f009ade97ebbf6519bc3a97fefbc0c ]
>    
>    ext4 can update bh->b_state non-atomically in _ext4_get_block() and
>    ext4_da_get_block_prep(). Usually this is fine since bh is just a
>    temporary storage for mapping information on stack but in some cases it
>    can be fully living bh attached to a page. In such case non-atomic
>    update of bh->b_state can race with an atomic update which then gets
>    lost. Usually when we are mapping bh and thus updating bh->b_state
>    non-atomically, nobody else touches the bh and so things work out fine
>    but there is one case to especially worry about: ext4_finish_bio() uses
>    BH_Uptodate_Lock on the first bh in the page to synchronize handling of
>    PageWriteback state. So when blocksize < pagesize, we can be atomically
>    modifying bh->b_state of a buffer that actually isn't under IO and thus
>    can race e.g. with delalloc trying to map that buffer. The result is
>    that we can mistakenly set / clear BH_Uptodate_Lock bit resulting in the
>    corruption of PageWriteback state or missed unlock of BH_Uptodate_Lock.
>    
>    Fix the problem by always updating bh->b_state bits atomically.
>    
>    CC: stable@vger.kernel.org
>    Reported-by: Nikolay Borisov <kernel@kyup.com>
>    Signed-off-by: Jan Kara <jack@suse.cz>
>    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0e3029cfab4a7884b32e1b2d3c19c12eded9804a
>Author: Dave Chinner <dchinner@redhat.com>
>Date:   Thu Jun 4 09:18:18 2015 +1000
>
>    dax: don't abuse get_block mapping for endio callbacks
>    
>    [ Upstream commit e842f2903908934187af7232fb5b21da527d1757 ]
>    
>    dax_fault() currently relies on the get_block callback to attach an
>    io completion callback to the mapping buffer head so that it can
>    run unwritten extent conversion after zeroing allocated blocks.
>    
>    Instead of this hack, pass the conversion callback directly into
>    dax_fault() similar to the get_block callback. When the filesystem
>    allocates unwritten extents, it will set the buffer_unwritten()
>    flag, and hence the dax_fault code can call the completion function
>    in the contexts where it is necessary without overloading the
>    mapping buffer head.
>    
>    Note: The changes to ext4 to use this interface are suspect at best.
>    In fact, the way ext4 did this end_io assignment in the first place
>    looks suspect because it only set a completion callback when there
>    wasn't already some other write() call taking place on the same
>    inode. The ext4 end_io code looks rather intricate and fragile with
>    all it's reference counting and passing to different contexts for
>    modification via inode private pointers that aren't protected by
>    locks...
>    
>    Signed-off-by: Dave Chinner <dchinner@redhat.com>
>    Acked-by: Jan Kara <jack@suse.cz>
>    Signed-off-by: Dave Chinner <david@fromorbit.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 89d27e325a9cb38435074039a43c9d95c1f389ec
>Author: Rusty Russell <rusty@rustcorp.com.au>
>Date:   Wed Feb 3 16:55:26 2016 +1030
>
>    module: wrapper for symbol name.
>    
>    [ Upstream commit 2e7bac536106236104e9e339531ff0fcdb7b8147 ]
>    
>    This trivial wrapper adds clarity and makes the following patch
>    smaller.
>    
>    Cc: stable@kernel.org
>    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b7fcd843be1d376f5e43226227707422f74901c7
>Author: Rich Felker <dalias@libc.org>
>Date:   Fri Jan 22 15:11:05 2016 -0800
>
>    MAINTAINERS: return arch/sh to maintained state, with new maintainers
>    
>    [ Upstream commit 114bf37e04d839b555b3dc460b5e6ce156f49cf0 ]
>    
>    Add Yoshinori Sato and Rich Felker as maintainers for arch/sh
>    (SUPERH).
>    
>    Signed-off-by: Rich Felker <dalias@libc.org>
>    Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp>
>    Acked-by: D. Jeff Dionne <jeff@uClinux.org>
>    Acked-by: Rob Landley <rob@landley.net>
>    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>    Acked-by: Simon Horman <horms+renesas@verge.net.au>
>    Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 24e6deaf40a702d1f6bf3cc7b809945cca867c58
>Author: Tony Lindgren <tony@atomide.com>
>Date:   Thu Jan 14 12:20:47 2016 -0800
>
>    ARM: OMAP2+: Fix l2_inv_api_params for rodata
>    
>    [ Upstream commit 0a0b13275558c32bbf6241464a7244b1ffd5afb3 ]
>    
>    We don't want to write to .text, so let's move l2_inv_api_params
>    to .data and access it via a pointer.
>    
>    Cc: Kees Cook <keescook@chromium.org>
>    Cc: Laura Abbott <labbott@redhat.com>
>    Cc: Nishanth Menon <nm@ti.com>
>    Cc: Richard Woodruff <r-woodruff2@ti.com>
>    Cc: Russell King <linux@arm.linux.org.uk>
>    Cc: Tero Kristo <t-kristo@ti.com>
>    Acked-by: Nicolas Pitre <nico@linaro.org>
>    Cc: stable@vger.kernel.org # v4.0+
>    Fixes: 1e6b48116a95 ("ARM: mm: allow non-text sections to be
>    non-executable")
>    Signed-off-by: Tony Lindgren <tony@atomide.com>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 17fe8c8b306e4b76078b8b103e1f344970409378
>Author: Akinobu Mita <akinobu.mita@gmail.com>
>Date:   Thu Jan 21 01:07:31 2016 +0900
>
>    iio: pressure: mpl115: fix temperature offset sign
>    
>    [ Upstream commit 431386e783a3a6c8b7707bee32d18c353b8688b2 ]
>    
>    According to the datasheet, the resolusion of temperature sensor is
>    -5.35 counts/C. Temperature ADC is 472 counts at 25C.
>    (https://www.sparkfun.com/datasheets/Sensors/Pressure/MPL115A1.pdf
>    NOTE: This is older revision, but this information is removed from the
>    latest datasheet from nxp somehow)
>    
>    Temp [C] = (Tadc - 472) / -5.35 + 25
>             = (Tadc - 605.750000) * -0.186915888
>    
>    So the correct offset is -605.750000.
>    
>    Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
>    Acked-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
>    Cc: <Stable@vger.kernel.org>
>    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5b20b25abab6faba0c91a4d7ccde93e134f29d6d
>Author: Yong Li <sdliyong@gmail.com>
>Date:   Wed Jan 6 09:09:43 2016 +0800
>
>    iio: dac: mcp4725: set iio name property in sysfs
>    
>    [ Upstream commit 97a249e98a72d6b79fb7350a8dd56b147e9d5bdb ]
>    
>    Without this change, the name entity for mcp4725 is missing in
>    /sys/bus/iio/devices/iio\:device*/name
>    
>    With this change, name is reported correctly
>    
>    Signed-off-by: Yong Li <sdliyong@gmail.com>
>    Cc: <Stable@vger.kernel.org>
>    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3e77cb858ce67861e142186e3b131c04ddbc6edd
>Author: Lars-Peter Clausen <lars@metafoo.de>
>Date:   Fri Nov 27 14:55:56 2015 +0100
>
>    iio: adis_buffer: Fix out-of-bounds memory access
>    
>    [ Upstream commit d590faf9e8f8509a0a0aa79c38e87fcc6b913248 ]
>    
>    The SPI tx and rx buffers are both supposed to be scan_bytes amount of
>    bytes large and a common allocation is used to allocate both buffers. This
>    puts the beginning of the tx buffer scan_bytes bytes after the rx buffer.
>    The initialization of the tx buffer pointer is done adding scan_bytes to
>    the beginning of the rx buffer, but since the rx buffer is of type __be16
>    this will actually add two times as much and the tx buffer ends up pointing
>    after the allocated buffer.
>    
>    Fix this by using scan_count, which is scan_bytes / 2, instead of
>    scan_bytes when initializing the tx buffer pointer.
>    
>    Fixes: aacff892cbd5 ("staging:iio:adis: Preallocate transfer message")
>    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
>    Cc: <Stable@vger.kernel.org>
>    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ab88ce5feca4204ecf4e7ef6c6693ff67edc2169
>Author: Jann Horn <jann@thejh.net>
>Date:   Wed Jan 20 15:00:04 2016 -0800
>
>    ptrace: use fsuid, fsgid, effective creds for fs access checks
>    
>    [ Upstream commit caaee6234d05a58c5b4d05e7bf766131b810a657 ]
>    
>    By checking the effective credentials instead of the real UID / permitted
>    capabilities, ensure that the calling process actually intended to use its
>    credentials.
>    
>    To ensure that all ptrace checks use the correct caller credentials (e.g.
>    in case out-of-tree code or newly added code omits the PTRACE_MODE_*CREDS
>    flag), use two new flags and require one of them to be set.
>    
>    The problem was that when a privileged task had temporarily dropped its
>    privileges, e.g.  by calling setreuid(0, user_uid), with the intent to
>    perform following syscalls with the credentials of a user, it still passed
>    ptrace access checks that the user would not be able to pass.
>    
>    While an attacker should not be able to convince the privileged task to
>    perform a ptrace() syscall, this is a problem because the ptrace access
>    check is reused for things in procfs.
>    
>    In particular, the following somewhat interesting procfs entries only rely
>    on ptrace access checks:
>    
>     /proc/$pid/stat - uses the check for determining whether pointers
>         should be visible, useful for bypassing ASLR
>     /proc/$pid/maps - also useful for bypassing ASLR
>     /proc/$pid/cwd - useful for gaining access to restricted
>         directories that contain files with lax permissions, e.g. in
>         this scenario:
>         lrwxrwxrwx root root /proc/13020/cwd -> /root/foobar
>         drwx------ root root /root
>         drwxr-xr-x root root /root/foobar
>         -rw-r--r-- root root /root/foobar/secret
>    
>    Therefore, on a system where a root-owned mode 6755 binary changes its
>    effective credentials as described and then dumps a user-specified file,
>    this could be used by an attacker to reveal the memory layout of root's
>    processes or reveal the contents of files he is not allowed to access
>    (through /proc/$pid/cwd).
>    
>    [akpm@linux-foundation.org: fix warning]
>    Signed-off-by: Jann Horn <jann@thejh.net>
>    Acked-by: Kees Cook <keescook@chromium.org>
>    Cc: Casey Schaufler <casey@schaufler-ca.com>
>    Cc: Oleg Nesterov <oleg@redhat.com>
>    Cc: Ingo Molnar <mingo@redhat.com>
>    Cc: James Morris <james.l.morris@oracle.com>
>    Cc: "Serge E. Hallyn" <serge.hallyn@ubuntu.com>
>    Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>    Cc: Andy Lutomirski <luto@kernel.org>
>    Cc: Al Viro <viro@zeniv.linux.org.uk>
>    Cc: "Eric W. Biederman" <ebiederm@xmission.com>
>    Cc: Willy Tarreau <w@1wt.eu>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 93d310f6cfd51d7158e2901b0f75babeaf97f3c3
>Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>Date:   Tue Dec 1 12:41:38 2015 +0100
>
>    HID: multitouch: fix input mode switching on some Elan panels
>    
>    [ Upstream commit 73e7d63efb4d774883a338997943bfa59e127085 ]
>    
>    as reported by https://bugzilla.kernel.org/show_bug.cgi?id=108481
>    
>    This bug reports mentions 6d4f5440 ("HID: multitouch: Fetch feature
>    reports on demand for Win8 devices") as the origin of the problem but this
>    commit actually masked 2 firmware bugs that are annihilating each other:
>    
>    The report descriptor declares two features in reports 3 and 5:
>    
>    0x05, 0x0d,                    // Usage Page (Digitizers)             318
>    0x09, 0x0e,                    // Usage (Device Configuration)        320
>    0xa1, 0x01,                    // Collection (Application)            322
>    0x85, 0x03,                    //  Report ID (3)                      324
>    0x09, 0x22,                    //  Usage (Finger)                     326
>    0xa1, 0x00,                    //  Collection (Physical)              328
>    0x09, 0x52,                    //   Usage (Inputmode)                 330
>    0x15, 0x00,                    //   Logical Minimum (0)               332
>    0x25, 0x0a,                    //   Logical Maximum (10)              334
>    0x75, 0x08,                    //   Report Size (8)                   336
>    0x95, 0x02,                    //   Report Count (2)                  338
>    0xb1, 0x02,                    //   Feature (Data,Var,Abs)            340
>    0xc0,                          //  End Collection                     342
>    0x09, 0x22,                    //  Usage (Finger)                     343
>    0xa1, 0x00,                    //  Collection (Physical)              345
>    0x85, 0x05,                    //   Report ID (5)                     347
>    0x09, 0x57,                    //   Usage (Surface Switch)            349
>    0x09, 0x58,                    //   Usage (Button Switch)             351
>    0x15, 0x00,                    //   Logical Minimum (0)               353
>    0x75, 0x01,                    //   Report Size (1)                   355
>    0x95, 0x02,                    //   Report Count (2)                  357
>    0x25, 0x03,                    //   Logical Maximum (3)               359
>    0xb1, 0x02,                    //   Feature (Data,Var,Abs)            361
>    0x95, 0x0e,                    //   Report Count (14)                 363
>    0xb1, 0x03,                    //   Feature (Cnst,Var,Abs)            365
>    0xc0,                          //  End Collection                     367
>    
>    The report ID 3 presents 2 input mode features, while only the first one
>    is handled by the device. Given that we did not checked if one was
>    previously assigned, we were dealing with the ignored featured and we
>    should never have been able to switch this panel into the multitouch mode.
>    
>    However, the firmware presents an other bugs which allowed 6d4f5440
>    to counteract the faulty report descriptor. When we request the values
>    of the feature 5, the firmware answers "03 03 00". The fields are correct
>    but the report id is wrong. Before 6d4f5440, we retrieved all the features
>    and injected them in the system. So when we called report 5, we injected
>    in the system the report 3 with the values "03 00".
>    Setting the second input mode to 03 in this report changed it to "03 03"
>    and the touchpad switched to the mt mode. We could have set anything
>    in the second field because the actual value (the first 03 in this report)
>    was given by the query of report ID 5.
>    
>    To sum up: 2 bugs in the firmware were hiding that we were accessing the
>    wrong feature.
>    
>    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8cf0abcfb3b1ce60a9bd866db451a093dc015233
>Author: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
>Date:   Sat Jan 16 00:31:23 2016 +0530
>
>    sched: Fix crash in sched_init_numa()
>    
>    [ Upstream commit 9c03ee147193645be4c186d3688232fa438c57c7 ]
>    
>    The following PowerPC commit:
>    
>      c118baf80256 ("arch/powerpc/mm/numa.c: do not allocate bootmem memory for non existing nodes")
>    
>    avoids allocating bootmem memory for non existent nodes.
>    
>    But when DEBUG_PER_CPU_MAPS=y is enabled, my powerNV system failed to boot
>    because in sched_init_numa(), cpumask_or() operation was done on
>    unallocated nodes.
>    
>    Fix that by making cpumask_or() operation only on existing nodes.
>    
>    [ Tested with and w/o DEBUG_PER_CPU_MAPS=y on x86 and PowerPC. ]
>    
>    Reported-by: Jan Stancek <jstancek@redhat.com>
>    Tested-by: Jan Stancek <jstancek@redhat.com>
>    Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
>    Cc: <gkurz@linux.vnet.ibm.com>
>    Cc: <grant.likely@linaro.org>
>    Cc: <nikunj@linux.vnet.ibm.com>
>    Cc: <vdavydov@parallels.com>
>    Cc: <linuxppc-dev@lists.ozlabs.org>
>    Cc: <linux-mm@kvack.org>
>    Cc: <peterz@infradead.org>
>    Cc: <benh@kernel.crashing.org>
>    Cc: <paulus@samba.org>
>    Cc: <mpe@ellerman.id.au>
>    Cc: <anton@samba.org>
>    Link: http://lkml.kernel.org/r/1452884483-11676-1-git-send-email-raghavendra.kt@linux.vnet.ibm.com
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7abe6e3537a321a332dc6320f22f27e3e11db750
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Tue Dec 8 17:00:42 2015 +0100
>
>    ALSA: hda - Implement loopback control switch for Realtek and other codecs
>    
>    [ Upstream commit e7fdd52779a6c2b49d457f452296a77c8cffef6a ]
>    
>    Many codecs, typically found on Realtek codecs, have the analog
>    loopback path merged to the secondary input of the middle of the
>    output paths.  Currently, we don't offer the dynamic switching in such
>    configuration but let each loopback path mute by itself.
>    
>    This should work well in theory, but in reality, we often see that
>    such a dead loopback path causes some background noises even if all
>    the elements get muted.  Such a problem has been fixed by adding the
>    quirk accordingly to disable aamix, and it's the right fix, per se.
>    The only problem is that it's not so trivial to achieve it; user needs
>    to pass a hint string via patch module option or sysfs.
>    
>    This patch gives a bit improvement on the situation: it adds "Loopback
>    Mixing" control element for such codecs like other codecs (e.g. IDT or
>    VIA codecs) with the individual loopback paths.  User can turn on/off
>    the loopback path simply via a mixer app.
>    
>    For keeping the compatibility, the loopback is still enabled on these
>    codecs.  But user can try to turn it off if experiencing a suspicious
>    background or click noise on the fly, then build a static fixup later
>    once after the problem is addressed.
>    
>    Other than the addition of the loopback enable/disablement control,
>    there should be no changes.
>    
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit af24c621219ec87b221c1bbade56a506bf09deb9
>Author: Ioan-Adrian Ratiu <adi@adirat.com>
>Date:   Fri Nov 20 22:19:02 2015 +0200
>
>    HID: usbhid: fix recursive deadlock
>    
>    [ Upstream commit e470127e9606b1fa151c4184243e61296d1e0c0f ]
>    
>    The critical section protected by usbhid->lock in hid_ctrl() is too
>    big and because of this it causes a recursive deadlock. "Too big" means
>    the case statement and the call to hid_input_report() do not need to be
>    protected by the spinlock (no URB operations are done inside them).
>    
>    The deadlock happens because in certain rare cases drivers try to grab
>    the lock while handling the ctrl irq which grabs the lock before them
>    as described above. For example newer wacom tablets like 056a:033c try
>    to reschedule proximity reads from wacom_intuos_schedule_prox_event()
>    calling hid_hw_request() -> usbhid_request() -> usbhid_submit_report()
>    which tries to grab the usbhid lock already held by hid_ctrl().
>    
>    There are two ways to get out of this deadlock:
>        1. Make the drivers work "around" the ctrl critical region, in the
>        wacom case for ex. by delaying the scheduling of the proximity read
>        request itself to a workqueue.
>        2. Shrink the critical region so the usbhid lock protects only the
>        instructions which modify usbhid state, calling hid_input_report()
>        with the spinlock unlocked, allowing the device driver to grab the
>        lock first, finish and then grab the lock afterwards in hid_ctrl().
>    
>    This patch implements the 2nd solution.
>    
>    Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com>
>    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1c0c659983aeb05bbc500f1d3f9ba8082313bb12
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Fri Jan 15 12:59:25 2016 +0100
>
>    ALSA: hda - Add fixup for Dell Latitidue E6540
>    
>    [ Upstream commit cf52103a218744f3fd18111325c28e95aa9cd226 ]
>    
>    Another Dell model, another fixup entry: Latitude E6540 needs the same
>    fixup as other Latitude E series as workaround for noise problems.
>    
>    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=104341
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a0eb05f661f7b67c497e9647f4fb7593260d4e58
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Sat Nov 14 17:46:31 2015 +0100
>
>    ALSA: hda - Fix noise on Dell Latitude E6440
>    
>    [ Upstream commit 86f799b82f5c011404ddef54600bc5e99b7e0cf2 ]
>    
>    Dell Latitude E6440 (1028:05bd) needs the same fixup as applied to
>    other Latitude E7xxx models for the click noise due to the recent
>    power-saving changes.
>    
>    Bugzilla: http://bugzilla.opensuse.org/show_bug.cgi?id=954876
>    Cc: <stable@vger.kernel.org> # v4.1+
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 46a190e6a3cd8223534614d306ab76b4811b6cc5
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Tue Jan 12 14:03:33 2016 +0100
>
>    ALSA: usb-audio: Avoid calling usb_autopm_put_interface() at disconnect
>    
>    [ Upstream commit 5c06d68bc2a174a6b82dce9f100f55173b9a5189 ]
>    
>    ALSA PCM may still have a leftover instance after disconnection and
>    it delays its release.  The problem is that the PCM close code path of
>    USB-audio driver has a call of snd_usb_autosuspend().  This involves
>    with the call of usb_autopm_put_interface() and it may lead to a
>    kernel Oops due to the NULL object like:
>    
>     BUG: unable to handle kernel NULL pointer dereference at 0000000000000190
>     IP: [<ffffffff815ae7ef>] usb_autopm_put_interface+0xf/0x30 PGD 0
>     Call Trace:
>      [<ffffffff8173bd94>] snd_usb_autosuspend+0x14/0x20
>      [<ffffffff817461bc>] snd_usb_pcm_close.isra.14+0x5c/0x90
>      [<ffffffff8174621f>] snd_usb_playback_close+0xf/0x20
>      [<ffffffff816ef58a>] snd_pcm_release_substream.part.36+0x3a/0x90
>      [<ffffffff816ef6b3>] snd_pcm_release+0xa3/0xb0
>      [<ffffffff816debb0>] snd_disconnect_release+0xd0/0xe0
>      [<ffffffff8114d417>] __fput+0x97/0x1d0
>      [<ffffffff8114d589>] ____fput+0x9/0x10
>      [<ffffffff8109e452>] task_work_run+0x72/0x90
>      [<ffffffff81088510>] do_exit+0x280/0xa80
>      [<ffffffff8108996a>] do_group_exit+0x3a/0xa0
>      [<ffffffff8109261f>] get_signal+0x1df/0x540
>      [<ffffffff81040903>] do_signal+0x23/0x620
>      [<ffffffff8114c128>] ? do_readv_writev+0x128/0x200
>      [<ffffffff810012e1>] prepare_exit_to_usermode+0x91/0xd0
>      [<ffffffff810013ba>] syscall_return_slowpath+0x9a/0x120
>      [<ffffffff817587cd>] ? __sys_recvmsg+0x5d/0x70
>      [<ffffffff810d2765>] ? ktime_get_ts64+0x45/0xe0
>      [<ffffffff8115dea0>] ? SyS_poll+0x60/0xf0
>      [<ffffffff818d2327>] int_ret_from_sys_call+0x25/0x8f
>    
>    We have already a check of disconnection in snd_usb_autoresume(), but
>    the check is missing its counterpart.  The fix is just to put the same
>    check in snd_usb_autosuspend(), too.
>    
>    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109431
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 30e821e1c1f3a6a2d11616a7bb65da28da388f78
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Tue Aug 25 16:09:00 2015 +0200
>
>    ALSA: usb-audio: Avoid nested autoresume calls
>    
>    [ Upstream commit 47ab154593827b1a8f0713a2b9dd445753d551d8 ]
>    
>    After the recent fix of runtime PM for USB-audio driver, we got a
>    lockdep warning like:
>    
>      =============================================
>      [ INFO: possible recursive locking detected ]
>      4.2.0-rc8+ #61 Not tainted
>      ---------------------------------------------
>      pulseaudio/980 is trying to acquire lock:
>       (&chip->shutdown_rwsem){.+.+.+}, at: [<ffffffffa0355dac>] snd_usb_autoresume+0x1d/0x52 [snd_usb_audio]
>      but task is already holding lock:
>       (&chip->shutdown_rwsem){.+.+.+}, at: [<ffffffffa0355dac>] snd_usb_autoresume+0x1d/0x52 [snd_usb_audio]
>    
>    This comes from snd_usb_autoresume() invoking down_read() and it's
>    used in a nested way.  Although it's basically safe, per se (as these
>    are read locks), it's better to reduce such spurious warnings.
>    
>    The read lock is needed to guarantee the execution of "shutdown"
>    (cleanup at disconnection) task after all concurrent tasks are
>    finished.  This can be implemented in another better way.
>    
>    Also, the current check of chip->in_pm isn't good enough for
>    protecting the racy execution of multiple auto-resumes.
>    
>    This patch rewrites the logic of snd_usb_autoresume() & co; namely,
>    - The recursive call of autopm is avoided by the new refcount,
>      chip->active.  The chip->in_pm flag is removed accordingly.
>    - Instead of rwsem, another refcount, chip->usage_count, is introduced
>      for tracking the period to delay the shutdown procedure.  At
>      the last clear of this refcount, wake_up() to the shutdown waiter is
>      called.
>    - The shutdown flag is replaced with shutdown atomic count; this is
>      for reducing the lock.
>    - Two new helpers are introduced to simplify the management of these
>      refcounts; snd_usb_lock_shutdown() increases the usage_count, checks
>      the shutdown state, and does autoresume.  snd_usb_unlock_shutdown()
>      does the opposite.  Most of mixer and other codes just need this,
>      and simply returns an error if it receives an error from lock.
>    
>    Fixes: 9003ebb13f61 ('ALSA: usb-audio: Fix runtime PM unbalance')
>    Reported-and-tested-by: Alexnader Kuleshov <kuleshovmail@gmail.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8d34309045f7d29641305cb2340df008b22c4c5c
>Author: Julian Scheel <julian@jusst.de>
>Date:   Fri Aug 14 16:14:45 2015 +0200
>
>    ALSA: usb-audio: Fix parameter block size for UAC2 control requests
>    
>    [ Upstream commit bc18e31c3042f14fa5f2ff5c21136e2fdf4140f8 ]
>    
>    USB Audio Class version 2.0 supports three different parameter block sizes for
>    CUR requests, which are 1 byte (5.2.3.1 Layout 1 Parameter Block), 2 bytes
>    (5.2.3.2 Layout 2 Parameter Block) and 4 bytes (5.2.3.3 Layout 3 Parameter
>    Block). Use the correct size according to the specific control as it was
>    already done for UACv1. The allocated block size for control requests is
>    increased to support the 4 byte worst case.
>    
>    Signed-off-by: Julian Scheel <julian@jusst.de>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 97828b710a99325ef8ffeeac7f9f3e356419ed51
>Author: Johan RastÃ©n <johan@oljud.se>
>Date:   Thu Jun 11 10:04:51 2015 +0200
>
>    ALSA: usb-audio: Set correct type for some UAC2 mixer controls.
>    
>    [ Upstream commit 27c41dad3a012c5acead1d903d1743297457b69c ]
>    
>    Changed ctl type for Input Gain Control and Input Gain Pad Control to
>    USB_MIXER_S16 as per section 5.2.5.7.11-12 in the USB Audio Class 2.0
>    definition.
>    
>    Signed-off-by: Johan RastÃ©n <johan@oljud.se>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6abe3345f34c113503a5b3f66bd8eb65d980c27f
>Author: David Henningsson <david.henningsson@canonical.com>
>Date:   Mon Jan 11 09:33:14 2016 +0100
>
>    ALSA: hda - Fixup inverted internal mic for Lenovo E50-80
>    
>    [ Upstream commit 56f27013482c0803d978b667fe85de04ce9357cd ]
>    
>    Inform userspace that one channel of the internal mic has reversed
>    polarity, so it does not attempt to add both channels together and
>    end up with silence.
>    
>    Cc: stable@vger.kernel.org
>    Reported-by: Andrzej Mendel <andrzej.mendel@gmail.com>
>    Alsa-info: http://www.alsa-project.org/db/?f=3088f82a0cf977855f92af9db8ad406c04f71efa
>    BugLink: https://bugs.launchpad.net/bugs/1529624
>    Signed-off-by: David Henningsson <david.henningsson@canonical.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 206f91a12c5f69c9b4dfd4e0029043794a046933
>Author: Sasha Levin <sasha.levin@oracle.com>
>Date:   Sun Apr 3 18:26:26 2016 -0400
>
>    Linux 4.1.21
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 919e67a63aa967566a909f4f6e1c13f8e88cf76e
>Author: Alexander Shishkin <alexander.shishkin@linux.intel.com>
>Date:   Thu Mar 24 11:14:53 2016 +0000
>
>    perf/core: Fix perf_sched_count derailment
>    
>    [ Upstream commit 927a5570855836e5d5859a80ce7e91e963545e8f ]
>    
>    The error path in perf_event_open() is such that asking for a sampling
>    event on a PMU that doesn't generate interrupts will end up in dropping
>    the perf_sched_count even though it hasn't been incremented for this
>    event yet.
>    
>    Given a sufficient amount of these calls, we'll end up disabling
>    scheduler's jump label even though we'd still have active events in the
>    system, thereby facilitating the arrival of the infernal regions upon us.
>    
>    I'm fixing this by moving account_event() inside perf_event_alloc().
>    
>    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
>    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>    Cc: <stable@vger.kernel.org>
>    Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
>    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
>    Cc: Jiri Olsa <jolsa@redhat.com>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Stephane Eranian <eranian@google.com>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Cc: Vince Weaver <vincent.weaver@maine.edu>
>    Cc: vince@deater.net
>    Link: http://lkml.kernel.org/r/1456917854-29427-1-git-send-email-alexander.shishkin@linux.intel.com
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    Signed-off-by: He Kuang <hekuang@huawei.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 882f862db7f3509f055208b2e3e5bd263265a03b
>Author: Peter Zijlstra <peterz@infradead.org>
>Date:   Thu Mar 24 11:14:52 2016 +0000
>
>    perf: Cure event->pending_disable race
>    
>    [ Upstream commit 28a967c3a2f99fa3b5f762f25cb2a319d933571b ]
>    
>    Because event_sched_out() checks event->pending_disable _before_
>    actually disabling the event, it can happen that the event fires after
>    it checks but before it gets disabled.
>    
>    This would leave event->pending_disable set and the queued irq_work
>    will try and process it.
>    
>    However, if the event trigger was during schedule(), the event might
>    have been de-scheduled by the time the irq_work runs, and
>    perf_event_disable_local() will fail.
>    
>    Fix this by checking event->pending_disable _after_ we call
>    event->pmu->del(). This depends on the latter being a compiler
>    barrier, such that the compiler does not lift the load and re-creates
>    the problem.
>    
>    Tested-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
>    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>    Reviewed-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
>    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
>    Cc: Jiri Olsa <jolsa@redhat.com>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Cc: dvyukov@google.com
>    Cc: eranian@google.com
>    Cc: oleg@redhat.com
>    Cc: panand@redhat.com
>    Cc: sasha.levin@oracle.com
>    Cc: vince@deater.net
>    Link: http://lkml.kernel.org/r/20160224174948.040469884@infradead.org
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    Signed-off-by: He Kuang <hekuang@huawei.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5709e7ba03717ab760b5ad6ebcf4a9e2f633dcc4
>Author: Peter Zijlstra <peterz@infradead.org>
>Date:   Thu Mar 24 11:14:51 2016 +0000
>
>    perf: Do not double free
>    
>    [ Upstream commit 130056275ade730e7a79c110212c8815202773ee ]
>    
>    In case of: err_file: fput(event_file), we'll end up calling
>    perf_release() which in turn will free the event.
>    
>    Do not then free the event _again_.
>    
>    Tested-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
>    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>    Reviewed-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
>    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
>    Cc: Jiri Olsa <jolsa@redhat.com>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Cc: dvyukov@google.com
>    Cc: eranian@google.com
>    Cc: oleg@redhat.com
>    Cc: panand@redhat.com
>    Cc: sasha.levin@oracle.com
>    Cc: vince@deater.net
>    Link: http://lkml.kernel.org/r/20160224174947.697350349@infradead.org
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    Signed-off-by: He Kuang <hekuang@huawei.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 143cf26c48278bd438a97a8bd3e18b6460192981
>Author: Yang Shi <yang.shi@linaro.org>
>Date:   Thu Mar 24 11:14:50 2016 +0000
>
>    arm64: replace read_lock to rcu lock in call_step_hook
>    
>    [ Upstream commit cf0a25436f05753aca5151891aea4fd130556e2a ]
>    
>    BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917
>    in_atomic(): 1, irqs_disabled(): 128, pid: 383, name: sh
>    Preemption disabled at:[<ffff800000124c18>] kgdb_cpu_enter+0x158/0x6b8
>    
>    CPU: 3 PID: 383 Comm: sh Tainted: G        W       4.1.13-rt13 #2
>    Hardware name: Freescale Layerscape 2085a RDB Board (DT)
>    Call trace:
>    [<ffff8000000885e8>] dump_backtrace+0x0/0x128
>    [<ffff800000088734>] show_stack+0x24/0x30
>    [<ffff80000079a7c4>] dump_stack+0x80/0xa0
>    [<ffff8000000bd324>] ___might_sleep+0x18c/0x1a0
>    [<ffff8000007a20ac>] __rt_spin_lock+0x2c/0x40
>    [<ffff8000007a2268>] rt_read_lock+0x40/0x58
>    [<ffff800000085328>] single_step_handler+0x38/0xd8
>    [<ffff800000082368>] do_debug_exception+0x58/0xb8
>    Exception stack(0xffff80834a1e7c80 to 0xffff80834a1e7da0)
>    7c80: ffffff9c ffffffff 92c23ba0 0000ffff 4a1e7e40 ffff8083 001bfcc4 ffff8000
>    7ca0: f2000400 00000000 00000000 00000000 4a1e7d80 ffff8083 0049501c ffff8000
>    7cc0: 00005402 00000000 00aaa210 ffff8000 4a1e7ea0 ffff8083 000833f4 ffff8000
>    7ce0: ffffff9c ffffffff 92c23ba0 0000ffff 4a1e7ea0 ffff8083 001bfcc0 ffff8000
>    7d00: 4a0fc400 ffff8083 00005402 00000000 4a1e7d40 ffff8083 00490324 ffff8000
>    7d20: ffffff9c 00000000 92c23ba0 0000ffff 000a0000 00000000 00000000 00000000
>    7d40: 00000008 00000000 00080000 00000000 92c23b8b 0000ffff 92c23b8e 0000ffff
>    7d60: 00000038 00000000 00001cb2 00000000 00000005 00000000 92d7b498 0000ffff
>    7d80: 01010101 01010101 92be9000 0000ffff 00000000 00000000 00000030 00000000
>    [<ffff8000000833f4>] el1_dbg+0x18/0x6c
>    
>    This issue is similar with 62c6c61("arm64: replace read_lock to rcu lock in
>    call_break_hook"), but comes to single_step_handler.
>    
>    This also solves kgdbts boot test silent hang issue on 4.4 -rt kernel.
>    
>    Signed-off-by: Yang Shi <yang.shi@linaro.org>
>    Acked-by: Will Deacon <will.deacon@arm.com>
>    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
>    Signed-off-by: He Kuang <hekuang@huawei.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1a138f3e487026aede3642cbe09aee0f64c2f66b
>Author: Yang Shi <yang.shi@linaro.org>
>Date:   Thu Mar 24 11:14:49 2016 +0000
>
>    arm64: replace read_lock to rcu lock in call_break_hook
>    
>    [ Upstream commit 62c6c61adbc623cdacf74b8f29c278e539060c48 ]
>    
>    BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917
>    in_atomic(): 0, irqs_disabled(): 128, pid: 342, name: perf
>    1 lock held by perf/342:
>     #0:  (break_hook_lock){+.+...}, at: [<ffffffc0000851ac>] call_break_hook+0x34/0xd0
>    irq event stamp: 62224
>    hardirqs last  enabled at (62223): [<ffffffc00010b7bc>] __call_rcu.constprop.59+0x104/0x270
>    hardirqs last disabled at (62224): [<ffffffc0000fbe20>] vprintk_emit+0x68/0x640
>    softirqs last  enabled at (0): [<ffffffc000097928>] copy_process.part.8+0x428/0x17f8
>    softirqs last disabled at (0): [<          (null)>]           (null)
>    CPU: 0 PID: 342 Comm: perf Not tainted 4.1.6-rt5 #4
>    Hardware name: linux,dummy-virt (DT)
>    Call trace:
>    [<ffffffc000089968>] dump_backtrace+0x0/0x128
>    [<ffffffc000089ab0>] show_stack+0x20/0x30
>    [<ffffffc0007030d0>] dump_stack+0x7c/0xa0
>    [<ffffffc0000c878c>] ___might_sleep+0x174/0x260
>    [<ffffffc000708ac8>] __rt_spin_lock+0x28/0x40
>    [<ffffffc000708db0>] rt_read_lock+0x60/0x80
>    [<ffffffc0000851a8>] call_break_hook+0x30/0xd0
>    [<ffffffc000085a70>] brk_handler+0x30/0x98
>    [<ffffffc000082248>] do_debug_exception+0x50/0xb8
>    Exception stack(0xffffffc00514fe30 to 0xffffffc00514ff50)
>    fe20:                                     00000000 00000000 c1594680 0000007f
>    fe40: ffffffff ffffffff 92063940 0000007f 0550dcd8 ffffffc0 00000000 00000000
>    fe60: 0514fe70 ffffffc0 000be1f8 ffffffc0 0514feb0 ffffffc0 0008948c ffffffc0
>    fe80: 00000004 00000000 0514fed0 ffffffc0 ffffffff ffffffff 9282a948 0000007f
>    fea0: 00000000 00000000 9282b708 0000007f c1592820 0000007f 00083914 ffffffc0
>    fec0: 00000000 00000000 00000010 00000000 00000064 00000000 00000001 00000000
>    fee0: 005101e0 00000000 c1594680 0000007f c1594740 0000007f ffffffd8 ffffff80
>    ff00: 00000000 00000000 00000000 00000000 c1594770 0000007f c1594770 0000007f
>    ff20: 00665e10 00000000 7f7f7f7f 7f7f7f7f 01010101 01010101 00000000 00000000
>    ff40: 928e4cc0 0000007f 91ff11e8 0000007f
>    
>    call_break_hook is called in atomic context (hard irq disabled), so replace
>    the sleepable lock to rcu lock, replace relevant list operations to rcu
>    version and call synchronize_rcu() in unregister_break_hook().
>    
>    And, replace write lock to spinlock in {un}register_break_hook.
>    
>    Signed-off-by: Yang Shi <yang.shi@linaro.org>
>    Signed-off-by: Will Deacon <will.deacon@arm.com>
>    Signed-off-by: He Kuang <hekuang@huawei.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f2b132595b89d9236b386e1d6ed3fcf5e9edf4cb
>Author: Jan Kara <jack@suse.com>
>Date:   Mon Dec 7 14:34:49 2015 -0500
>
>    ext4: fix races of writeback with punch hole and zero range
>    
>    When doing delayed allocation, update of on-disk inode size is postponed
>    until IO submission time. However hole punch or zero range fallocate
>    calls can end up discarding the tail page cache page and thus on-disk
>    inode size would never be properly updated.
>    
>    Make sure the on-disk inode size is updated before truncating page
>    cache.
>    
>    Signed-off-by: Jan Kara <jack@suse.com>
>    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
>    Reviewed-by: Mingming Cao <mingming.cao@oracle.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 181aaebde9360b8235df647ee36dafdc041d4964
>Author: Jan Kara <jack@suse.com>
>Date:   Mon Dec 7 14:31:11 2015 -0500
>
>    ext4: fix races between buffered IO and collapse / insert range
>    
>    Current code implementing FALLOC_FL_COLLAPSE_RANGE and
>    FALLOC_FL_INSERT_RANGE is prone to races with buffered writes and page
>    faults. If buffered write or write via mmap manages to squeeze between
>    filemap_write_and_wait_range() and truncate_pagecache() in the fallocate
>    implementations, the written data is simply discarded by
>    truncate_pagecache() although it should have been shifted.
>    
>    Fix the problem by moving filemap_write_and_wait_range() call inside
>    i_mutex and i_mmap_sem. That way we are protected against races with
>    both buffered writes and page faults.
>    
>    Signed-off-by: Jan Kara <jack@suse.com>
>    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
>    Reviewed-by: Mingming Cao <mingming.cao@oracle.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9621787d69783fc23d14e1332377d7170d6928ed
>Author: Jan Kara <jack@suse.com>
>Date:   Mon Dec 7 14:29:17 2015 -0500
>
>    ext4: move unlocked dio protection from ext4_alloc_file_blocks()
>    
>    Currently ext4_alloc_file_blocks() was handling protection against
>    unlocked DIO. However we now need to sometimes call it under i_mmap_sem
>    and sometimes not and DIO protection ranks above it (although strictly
>    speaking this cannot currently create any deadlocks). Also
>    ext4_zero_range() was actually getting & releasing unlocked DIO
>    protection twice in some cases. Luckily it didn't introduce any real bug
>    but it was a land mine waiting to be stepped on.  So move DIO protection
>    out from ext4_alloc_file_blocks() into the two callsites.
>    
>    Signed-off-by: Jan Kara <jack@suse.com>
>    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
>    Reviewed-by: Mingming Cao <mingming.cao@oracle.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 248766f068fd1d3d95479f470bc926d1136141d6
>Author: Jan Kara <jack@suse.com>
>Date:   Mon Dec 7 14:28:03 2015 -0500
>
>    ext4: fix races between page faults and hole punching
>    
>    Currently, page faults and hole punching are completely unsynchronized.
>    This can result in page fault faulting in a page into a range that we
>    are punching after truncate_pagecache_range() has been called and thus
>    we can end up with a page mapped to disk blocks that will be shortly
>    freed. Filesystem corruption will shortly follow. Note that the same
>    race is avoided for truncate by checking page fault offset against
>    i_size but there isn't similar mechanism available for punching holes.
>    
>    Fix the problem by creating new rw semaphore i_mmap_sem in inode and
>    grab it for writing over truncate, hole punching, and other functions
>    removing blocks from extent tree and for read over page faults. We
>    cannot easily use i_data_sem for this since that ranks below transaction
>    start and we need something ranking above it so that it can be held over
>    the whole truncate / hole punching operation. Also remove various
>    workarounds we had in the code to reduce race window when page fault
>    could have created pages with stale mapping information.
>    
>    Signed-off-by: Jan Kara <jack@suse.com>
>    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
>    Reviewed-by: Mingming Cao <mingming.cao@oracle.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 14b4d1419ee6e71e672926d90a5bd87f698014d3
>Author: Hauke Mehrtens <hauke@hauke-m.de>
>Date:   Sun Mar 6 22:28:56 2016 +0100
>
>    MIPS: Fix build error when SMP is used without GIC
>    
>    [ Upstream commit 588bad2ef32cae7abad24d5ca2f4611a7a7fb2a2 ]
>    
>    commit 7a50e4688dabb8005df39b2b992d76629b8af8aa upstream.
>    
>    The MIPS_GIC_IPI should only be selected when MIPS_GIC is also
>    selected, otherwise it results in a compile error. smp-gic.c uses some
>    functions from include/linux/irqchip/mips-gic.h like
>    plat_ipi_call_int_xlate() which are only added to the header file when
>    MIPS_GIC is set. The Lantiq SoC does not use the GIC, but supports SMP.
>    The calls top the functions from smp-gic.c are already protected by
>    some #ifdefs
>    
>    The first part of this was introduced in commit 72e20142b2bf ("MIPS:
>    Move GIC IPI functions out of smp-cmp.c")
>    
>    Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
>    Cc: Paul Burton <paul.burton@imgtec.com>
>    Cc: linux-mips@linux-mips.org
>    Patchwork: https://patchwork.linux-mips.org/patch/12774/
>    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7c196e5a2e90d172ce2bca85bb368f70a016b02c
>Author: Markos Chandras <markos.chandras@imgtec.com>
>Date:   Thu Jul 9 10:40:38 2015 +0100
>
>    MIPS: Kconfig: Disable MIPS MT and SMP implementations for R6
>    
>    [ Upstream commit 5676319c91c8d668635ac0b9b6d9145c4fa418ac ]
>    
>    R6 does not support the MIPS MT ASE and the CMP/SMP options so
>    restrict them in order to prevent users from selecting incompatible
>    SMP configuration for R6 cores. We also disable the CPS/SMP option
>    because its support hasn't been added to the CPS code yet.
>    
>    Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
>    Cc: linux-mips@linux-mips.org
>    Patchwork: https://patchwork.linux-mips.org/patch/10637/
>    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e652be4b177954875b8d2d842abfda3626cb1d6a
>Author: Markos Chandras <markos.chandras@imgtec.com>
>Date:   Wed Jul 1 09:31:14 2015 +0100
>
>    Revert "MIPS: Kconfig: Disable SMP/CPS for 64-bit"
>    
>    [ Upstream commit 1c885357da2d3cf62132e611c0beaf4cdf607dd9 ]
>    
>    This reverts commit 6ca716f2e5571d25a3899c6c5c91ff72ea6d6f5e.
>    
>    SMP/CPS is now supported on 64bit cores.
>    
>    Cc: <stable@vger.kernel.org> # 4.1
>    Reviewed-by: Paul Burton <paul.burton@imgtec.com>
>    Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
>    Cc: linux-mips@linux-mips.org
>    Cc: stable@vger.kernel.org
>    Patchwork: https://patchwork.linux-mips.org/patch/10592/
>    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c839d6e6b096f1c9f2d9be880aedd796095b7a80
>Author: James Hogan <james.hogan@imgtec.com>
>Date:   Tue Mar 8 16:47:53 2016 +0000
>
>    ld-version: Fix awk regex compile failure
>    
>    [ Upstream commit 4b7b1ef2c2f83d702272555e8adb839a50ba0f8e ]
>    
>    The ld-version.sh script fails on some versions of awk with the
>    following error, resulting in build failures for MIPS:
>    
>    awk: scripts/ld-version.sh: line 4: regular expression compile failed (missing '(')
>    
>    This is due to the regular expression ".*)", meant to strip off the
>    beginning of the ld version string up to the close bracket, however
>    brackets have a meaning in regular expressions, so lets escape it so
>    that awk doesn't expect a corresponding open bracket.
>    
>    Fixes: ccbef1674a15 ("Kbuild, lto: add ld-version and ld-ifversion ...")
>    Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
>    Signed-off-by: James Hogan <james.hogan@imgtec.com>
>    Tested-by: Michael S. Tsirkin <mst@redhat.com>
>    Acked-by: Michael S. Tsirkin <mst@redhat.com>
>    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
>    Cc: Michal Marek <mmarek@suse.com>
>    Cc: Andi Kleen <ak@linux.intel.com>
>    Cc: Geert Uytterhoeven <geert@linux-m68k.org>
>    Cc: linux-mips@linux-mips.org
>    Cc: linux-kbuild@vger.kernel.org
>    Cc: linux-kernel@vger.kernel.org
>    Cc: stable@vger.kernel.org # 4.4.x-
>    Patchwork: https://patchwork.linux-mips.org/patch/12838/
>    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c7d4bd1d975e3fa1dd4ecf557ada0e792d551a6c
>Author: Ludovic Desroches <ludovic.desroches@atmel.com>
>Date:   Thu Mar 10 10:17:55 2016 +0100
>
>    dmaengine: at_xdmac: fix residue computation
>    
>    [ Upstream commit 25c5e9626ca4d40928dc9c44f009ce2ed0a739e7 ]
>    
>    When computing the residue we need two pieces of information: the current
>    descriptor and the remaining data of the current descriptor. To get
>    that information, we need to read consecutively two registers but we
>    can't do it in an atomic way. For that reason, we have to check manually
>    that current descriptor has not changed.
>    
>    Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
>    Suggested-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
>    Reported-by: David Engraf <david.engraf@sysgo.com>
>    Tested-by: David Engraf <david.engraf@sysgo.com>
>    Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel
>    eXtended DMA Controller driver")
>    Cc: stable@vger.kernel.org #4.1 and later
>    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit eac525506a083a389ba173880979a6291401af2d
>Author: Paolo Bonzini <pbonzini@redhat.com>
>Date:   Tue Mar 8 12:13:39 2016 +0100
>
>    KVM: MMU: fix ept=0/pte.u=1/pte.w=0/CR0.WP=0/CR4.SMEP=1/EFER.NX=0 combo
>    
>    [ Upstream commit 844a5fe219cf472060315971e15cbf97674a3324 ]
>    
>    Yes, all of these are needed. :) This is admittedly a bit odd, but
>    kvm-unit-tests access.flat tests this if you run it with "-cpu host"
>    and of course ept=0.
>    
>    KVM runs the guest with CR0.WP=1, so it must handle supervisor writes
>    specially when pte.u=1/pte.w=0/CR0.WP=0.  Such writes cause a fault
>    when U=1 and W=0 in the SPTE, but they must succeed because CR0.WP=0.
>    When KVM gets the fault, it sets U=0 and W=1 in the shadow PTE and
>    restarts execution.  This will still cause a user write to fault, while
>    supervisor writes will succeed.  User reads will fault spuriously now,
>    and KVM will then flip U and W again in the SPTE (U=1, W=0).  User reads
>    will be enabled and supervisor writes disabled, going back to the
>    originary situation where supervisor writes fault spuriously.
>    
>    When SMEP is in effect, however, U=0 will enable kernel execution of
>    this page.  To avoid this, KVM also sets NX=1 in the shadow PTE together
>    with U=0.  If the guest has not enabled NX, the result is a continuous
>    stream of page faults due to the NX bit being reserved.
>    
>    The fix is to force EFER.NX=1 even if the CPU is taking care of the EFER
>    switch.  (All machines with SMEP have the CPU_LOAD_IA32_EFER vm-entry
>    control, so they do not use user-return notifiers for EFER---if they did,
>    EFER.NX would be forced to the same value as the host).
>    
>    There is another bug in the reserved bit check, which I've split to a
>    separate patch for easier application to stable kernels.
>    
>    Cc: stable@vger.kernel.org
>    Cc: Andy Lutomirski <luto@amacapital.net>
>    Reviewed-by: Xiao Guangrong <guangrong.xiao@linux.intel.com>
>    Fixes: f6577a5fa15d82217ca73c74cd2dcbc0f6c781dd
>    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 09b4fd2014b1ef7d46df8df553f94254ba2a0497
>Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
>Date:   Mon Feb 15 14:46:49 2016 +0100
>
>    s390/mm: four page table levels vs. fork
>    
>    [ Upstream commit 3446c13b268af86391d06611327006b059b8bab1 ]
>    
>    The fork of a process with four page table levels is broken since
>    git commit 6252d702c5311ce9 "[S390] dynamic page tables."
>    
>    All new mm contexts are created with three page table levels and
>    an asce limit of 4TB. If the parent has four levels dup_mmap will
>    add vmas to the new context which are outside of the asce limit.
>    The subsequent call to copy_page_range will walk the three level
>    page table structure of the new process with non-zero pgd and pud
>    indexes. This leads to memory clobbers as the pgd_index *and* the
>    pud_index is added to the mm->pgd pointer without a pgd_deref
>    in between.
>    
>    The init_new_context() function is selecting the number of page
>    table levels for a new context. The function is used by mm_init()
>    which in turn is called by dup_mm() and mm_alloc(). These two are
>    used by fork() and exec(). The init_new_context() function can
>    distinguish the two cases by looking at mm->context.asce_limit,
>    for fork() the mm struct has been copied and the number of page
>    table levels may not change. For exec() the mm_alloc() function
>    set the new mm structure to zero, in this case a three-level page
>    table is created as the temporary stack space is located at
>    STACK_TOP_MAX = 4TB.
>    
>    This fixes CVE-2016-2143.
>    
>    Reported-by: Marcin KoÅcielnicki <koriakin@0x04.net>
>    Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1b3ce90bcd25ea9ba08450e605df29e16387a7ca
>Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
>Date:   Wed Mar 9 11:58:41 2016 -0500
>
>    tracing: Fix check for cpu online when event is disabled
>    
>    [ Upstream commit dc17147de328a74bbdee67c1bf37d2f1992de756 ]
>    
>    Commit f37755490fe9b ("tracepoints: Do not trace when cpu is offline") added
>    a check to make sure that tracepoints only get called when the cpu is
>    online, as it uses rcu_read_lock_sched() for protection.
>    
>    Commit 3a630178fd5f3 ("tracing: generate RCU warnings even when tracepoints
>    are disabled") added lockdep checks (including rcu checks) for events that
>    are not enabled to catch possible RCU issues that would only be triggered if
>    a trace event was enabled. Commit f37755490fe9b only stopped the warnings
>    when the trace event was enabled but did not prevent warnings if the trace
>    event was called when disabled.
>    
>    To fix this, the cpu online check is moved to where the condition is added
>    to the trace event. This will place the cpu online check in all places that
>    it may be used now and in the future.
>    
>    Cc: stable@vger.kernel.org # v3.18+
>    Fixes: f37755490fe9b ("tracepoints: Do not trace when cpu is offline")
>    Fixes: 3a630178fd5f3 ("tracing: generate RCU warnings even when tracepoints are disabled")
>    Reported-by: Sudeep Holla <sudeep.holla@arm.com>
>    Tested-by: Sudeep Holla <sudeep.holla@arm.com>
>    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3b9f9280aa1321618fc5024314aca23a8716ffd6
>Author: Alex Deucher <alexander.deucher@amd.com>
>Date:   Tue Mar 8 11:31:00 2016 -0500
>
>    Revert "drm/radeon/pm: adjust display configuration after powerstate"
>    
>    [ Upstream commit d74e766e1916d0e09b86e4b5b9d0f819628fd546 ]
>    
>    This reverts commit 39d4275058baf53e89203407bf3841ff2c74fa32.
>    
>    This caused a regression on some older hardware.
>    
>    bug:
>    https://bugzilla.kernel.org/show_bug.cgi?id=113891
>    
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8fc3813ab4b3a863b44b56013f02d8c955ffd954
>Author: Alex Deucher <alexander.deucher@amd.com>
>Date:   Thu Mar 3 19:26:24 2016 -0500
>
>    drm/radeon/dp: add back special handling for NUTMEG
>    
>    [ Upstream commit c8213a638f65bf487c10593c216525952cca3690 ]
>    
>    When I fixed the dp rate selection in:
>    092c96a8ab9d1bd60ada2ed385cc364ce084180e
>    drm/radeon: fix dp link rate selection (v2)
>    I accidently dropped the special handling for NUTMEG
>    DP bridge chips.  They require a fixed link rate.
>    
>    Reviewed-by: Christian KÃ¶nig <christian.koenig@amd.com>
>    Reviewed-by: Ken Wang <Qingqing.Wang@amd.com>
>    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
>    Tested-by: Ken Moffat <zarniwhoop@ntlworld.com>
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit fddbe6c2569a24f097a9973d08a8e282c977ecf3
>Author: Alex Deucher <alexander.deucher@amd.com>
>Date:   Thu Dec 17 10:23:34 2015 -0500
>
>    drm/radeon: fix dp link rate selection (v2)
>    
>    [ Upstream commit 092c96a8ab9d1bd60ada2ed385cc364ce084180e ]
>    
>    Need to properly handle the max link rate in the dpcd.
>    This prevents some cases where 5.4 Ghz is selected when
>    it shouldn't be.
>    
>    v2: simplify logic, add array bounds check
>    
>    Reviewed-by: Tom St Denis <tom.stdenis@amd.com>
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7dac6e4062f42f37ef99e86e7f0369ff476af5f6
>Author: Alex Deucher <alexander.deucher@amd.com>
>Date:   Thu May 14 12:47:45 2015 -0400
>
>    drm/radeon: make dpcd parameters const
>    
>    [ Upstream commit 0c3a88407ef2be8bb7c302c298d6ff58ebde4a43 ]
>    
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit eb34a645aee3906baac9cad7defdabf61ac40bfd
>Author: Radim KrÄmÃ¡Å <rkrcmar@redhat.com>
>Date:   Fri Mar 4 15:08:42 2016 +0100
>
>    KVM: VMX: disable PEBS before a guest entry
>    
>    [ Upstream commit 7099e2e1f4d9051f31bbfa5803adf954bb5d76ef ]
>    
>    Linux guests on Haswell (and also SandyBridge and Broadwell, at least)
>    would crash if you decided to run a host command that uses PEBS, like
>      perf record -e 'cpu/mem-stores/pp' -a
>    
>    This happens because KVM is using VMX MSR switching to disable PEBS, but
>    SDM [2015-12] 18.4.4.4 Re-configuring PEBS Facilities explains why it
>    isn't safe:
>      When software needs to reconfigure PEBS facilities, it should allow a
>      quiescent period between stopping the prior event counting and setting
>      up a new PEBS event. The quiescent period is to allow any latent
>      residual PEBS records to complete its capture at their previously
>      specified buffer address (provided by IA32_DS_AREA).
>    
>    There might not be a quiescent period after the MSR switch, so a CPU
>    ends up using host's MSR_IA32_DS_AREA to access an area in guest's
>    memory.  (Or MSR switching is just buggy on some models.)
>    
>    The guest can learn something about the host this way:
>    If the guest doesn't map address pointed by MSR_IA32_DS_AREA, it results
>    in #PF where we leak host's MSR_IA32_DS_AREA through CR2.
>    
>    After that, a malicious guest can map and configure memory where
>    MSR_IA32_DS_AREA is pointing and can therefore get an output from
>    host's tracing.
>    
>    This is not a critical leak as the host must initiate with PEBS tracing
>    and I have not been able to get a record from more than one instruction
>    before vmentry in vmx_vcpu_run() (that place has most registers already
>    overwritten with guest's).
>    
>    We could disable PEBS just few instructions before vmentry, but
>    disabling it earlier shouldn't affect host tracing too much.
>    We also don't need to switch MSR_IA32_PEBS_ENABLE on VMENTRY, but that
>    optimization isn't worth its code, IMO.
>    
>    (If you are implementing PEBS for guests, be sure to handle the case
>     where both host and guest enable PEBS, because this patch doesn't.)
>    
>    Fixes: 26a4f3c08de4 ("perf/x86: disable PEBS on a guest entry.")
>    Cc: <stable@vger.kernel.org>
>    Reported-by: JiÅÃ OlÅ¡a <jolsa@redhat.com>
>    Signed-off-by: Radim KrÄmÃ¡Å <rkrcmar@redhat.com>
>    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c62aadae234ffad0901c20ac1a1aa4e13cce1c20
>Author: Al Viro <viro@zeniv.linux.org.uk>
>Date:   Mon Mar 7 23:07:10 2016 -0500
>
>    jffs2: reduce the breakage on recovery from halfway failed rename()
>    
>    [ Upstream commit f93812846f31381d35c04c6c577d724254355e7f ]
>    
>    d_instantiate(new_dentry, old_inode) is absolutely wrong thing to
>    do - it will oops if new_dentry used to be positive, for starters.
>    What we need is d_invalidate() the target and be done with that.
>    
>    Cc: stable@vger.kernel.org # v3.18+
>    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 906e5a6e6e73316fa4741ca53be014c9477a100c
>Author: Al Viro <viro@zeniv.linux.org.uk>
>Date:   Mon Mar 7 22:17:07 2016 -0500
>
>    ncpfs: fix a braino in OOM handling in ncp_fill_cache()
>    
>    [ Upstream commit 803c00123a8012b3a283c0530910653973ef6d8f ]
>    
>    Failing to allocate an inode for child means that cache for *parent* is
>    incompletely populated.  So it's parent directory inode ('dir') that
>    needs NCPI_DIR_CACHE flag removed, *not* the child inode ('inode', which
>    is what we'd failed to allocate in the first place).
>    
>    Fucked-up-in: commit 5e993e25 ("ncpfs: get rid of d_validate() nonsense")
>    Fucked-up-by: Al Viro <viro@zeniv.linux.org.uk>
>    Cc: stable@vger.kernel.org # v3.19
>    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6d44ac3f884b220573b2d46c691127fb6fee0707
>Author: Paul Mackerras <paulus@samba.org>
>Date:   Sat Mar 5 19:34:39 2016 +1100
>
>    KVM: PPC: Book3S HV: Sanitize special-purpose register values on guest exit
>    
>    [ Upstream commit ccec44563b18a0ce90e2d4f332784b3cb25c8e9c ]
>    
>    Thomas Huth discovered that a guest could cause a hard hang of a
>    host CPU by setting the Instruction Authority Mask Register (IAMR)
>    to a suitable value.  It turns out that this is because when the
>    code was added to context-switch the new special-purpose registers
>    (SPRs) that were added in POWER8, we forgot to add code to ensure
>    that they were restored to a sane value on guest exit.
>    
>    This adds code to set those registers where a bad value could
>    compromise the execution of the host kernel to a suitable neutral
>    value on guest exit.
>    
>    Cc: stable@vger.kernel.org # v3.14+
>    Fixes: b005255e12a3
>    Reported-by: Thomas Huth <thuth@redhat.com>
>    Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
>    Signed-off-by: Paul Mackerras <paulus@samba.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0d00dbe120f15fd798e7b0e2c69d67da887a9bfb
>Author: Mugunthan V N <mugunthanvnm@ti.com>
>Date:   Mon Mar 7 01:41:22 2016 -0700
>
>    ARM: dts: dra7: do not gate cpsw clock due to errata i877
>    
>    [ Upstream commit 0f514e690740e54815441a87708c3326f8aa8709 ]
>    
>    Errata id: i877
>    
>    Description:
>    ------------
>    The RGMII 1000 Mbps Transmit timing is based on the output clock
>    (rgmiin_txc) being driven relative to the rising edge of an internal
>    clock and the output control/data (rgmiin_txctl/txd) being driven relative
>    to the falling edge of an internal clock source. If the internal clock
>    source is allowed to be static low (i.e., disabled) for an extended period
>    of time then when the clock is actually enabled the timing delta between
>    the rising edge and falling edge can change over the lifetime of the
>    device. This can result in the device switching characteristics degrading
>    over time, and eventually failing to meet the Data Manual Delay Time/Skew
>    specs.
>    To maintain RGMII 1000 Mbps IO Timings, SW should minimize the
>    duration that the Ethernet internal clock source is disabled. Note that
>    the device reset state for the Ethernet clock is "disabled".
>    Other RGMII modes (10 Mbps, 100Mbps) are not affected
>    
>    Workaround:
>    -----------
>    If the SoC Ethernet interface(s) are used in RGMII mode at 1000 Mbps,
>    SW should minimize the time the Ethernet internal clock source is disabled
>    to a maximum of 200 hours in a device life cycle. This is done by enabling
>    the clock as early as possible in IPL (QNX) or SPL/u-boot (Linux/Android)
>    by setting the register CM_GMAC_CLKSTCTRL[1:0]CLKTRCTRL = 0x2:SW_WKUP.
>    
>    So, do not allow to gate the cpsw clocks using ti,no-idle property in
>    cpsw node assuming 1000 Mbps is being used all the time. If someone does
>    not need 1000 Mbps and wants to gate clocks to cpsw, this property needs
>    to be deleted in their respective board files.
>    
>    Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
>    Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>    Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Paul Walmsley <paul@pwsan.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a7029eb2f16ad28aee80f16998bfb1a2f2a787c5
>Author: Lokesh Vutla <lokeshvutla@ti.com>
>Date:   Mon Mar 7 01:41:21 2016 -0700
>
>    ARM: OMAP2+: hwmod: Introduce ti,no-idle dt property
>    
>    [ Upstream commit 6327a31a3f875c438ca13058bc4c73f1a752cd8a ]
>    
>    commit 2e18f5a1bc18e8af7031b3b26efde25307014837 upstream.
>    
>    Introduce a dt property, ti,no-idle, that prevents an IP to idle at any
>    point. This is to handle Errata i877, which tells that GMAC clocks
>    cannot be disabled.
>    
>    Acked-by: Roger Quadros <rogerq@ti.com>
>    Tested-by: Mugunthan V N <mugunthanvnm@ti.com>
>    Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
>    Signed-off-by: Sekhar Nori <nsekhar@ti.com>
>    Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>    Acked-by: Rob Herring <robh@kernel.org>
>    Signed-off-by: Paul Walmsley <paul@pwsan.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6991aaf3004c32f5e3e856b0bfb0874e122db65d
>Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
>Date:   Thu Nov 12 09:32:58 2015 +0200
>
>    ARM: OMAP2+: hwmod: Add hwmod flag for HWMOD_OPT_CLKS_NEEDED
>    
>    [ Upstream commit c12ba8ce2335389ce5416f88391cd67c7325c963 ]
>    
>    Some module needs more than one functional clock in order to be accessible,
>    like the McASPs found in DRA7xx family.
>    This flag will indicate that the opt_clks need to be handled at the same
>    time as the main_clk for the given hwmod, ensuring that all needed clocks
>    are enabled before we try to access the module's address space.
>    
>    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
>    Acked-by: Paul Walmsley <paul@pwsan.com>
>    Tested-by: Felipe Balbi <balbi@ti.com>
>    Signed-off-by: Tony Lindgren <tony@atomide.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit bde1cccf1a837d6905fe71543c2f4a4e3328dce0
>Author: Nicholas Bellinger <nab@linux-iscsi.org>
>Date:   Sat Mar 5 20:00:12 2016 -0800
>
>    target: Drop incorrect ABORT_TASK put for completed commands
>    
>    [ Upstream commit 7f54ab5ff52fb0b91569bc69c4a6bc5cac1b768d ]
>    
>    This patch fixes a recent ABORT_TASK regression associated
>    with commit febe562c, where a left-over target_put_sess_cmd()
>    would still be called when __target_check_io_state() detected
>    a command has already been completed, and explicit ABORT must
>    be avoided.
>    
>    Note commit febe562c dropped the local kref_get_unless_zero()
>    check in core_tmr_abort_task(), but did not drop this extra
>    corresponding target_put_sess_cmd() in the failure path.
>    
>    So go ahead and drop this now bogus target_put_sess_cmd(),
>    and avoid this potential use-after-free.
>    
>    Reported-by: Dan Lane <dracodan@gmail.com>
>    Cc: Quinn Tran <quinn.tran@qlogic.com>
>    Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
>    Cc: Sagi Grimberg <sagig@mellanox.com>
>    Cc: Christoph Hellwig <hch@lst.de>
>    Cc: Hannes Reinecke <hare@suse.de>
>    Cc: Andy Grover <agrover@redhat.com>
>    Cc: Mike Christie <mchristi@redhat.com>
>    Cc: stable@vger.kernel.org # 3.14+
>    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 546a8b3c4059af5fd8466f3d1848321e7613904c
>Author: Konstantin Khlebnikov <koct9i@gmail.com>
>Date:   Sun Jan 31 16:21:29 2016 +0300
>
>    ovl: copy new uid/gid into overlayfs runtime inode
>    
>    [ Upstream commit b81de061fa59f17d2730aabb1b84419ef3913810 ]
>    
>    Overlayfs must update uid/gid after chown, otherwise functions
>    like inode_owner_or_capable() will check user against stale uid.
>    Catched by xfstests generic/087, it chowns file and calls utimes.
>    
>    Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com>
>    Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 091baa9c784fe57b8778a4b754931ffe57245db3
>Author: Konstantin Khlebnikov <koct9i@gmail.com>
>Date:   Sun Jan 31 16:17:53 2016 +0300
>
>    ovl: ignore lower entries when checking purity of non-directory entries
>    
>    [ Upstream commit 45d11738969633ec07ca35d75d486bf2d8918df6 ]
>    
>    After rename file dentry still holds reference to lower dentry from
>    previous location. This doesn't matter for data access because data comes
>    from upper dentry. But this stale lower dentry taints dentry at new
>    location and turns it into non-pure upper. Such file leaves visible
>    whiteout entry after remove in directory which shouldn't have whiteouts at
>    all.
>    
>    Overlayfs already tracks pureness of file location in oe->opaque.  This
>    patch just uses that for detecting actual path type.
>    
>    Comment from Vivek Goyal's patch:
>    
>    Here are the details of the problem. Do following.
>    
>    $ mkdir upper lower work merged upper/dir/
>    $ touch lower/test
>    $ sudo mount -t overlay overlay -olowerdir=lower,upperdir=upper,workdir=
>    work merged
>    $ mv merged/test merged/dir/
>    $ rm merged/dir/test
>    $ ls -l merged/dir/
>    /usr/bin/ls: cannot access merged/dir/test: No such file or directory
>    total 0
>    c????????? ? ? ? ?            ? test
>    
>    Basic problem seems to be that once a file has been unlinked, a whiteout
>    has been left behind which was not needed and hence it becomes visible.
>    
>    Whiteout is visible because parent dir is of not type MERGE, hence
>    od->is_real is set during ovl_dir_open(). And that means ovl_iterate()
>    passes on iterate handling directly to underlying fs. Underlying fs does
>    not know/filter whiteouts so it becomes visible to user.
>    
>    Why did we leave a whiteout to begin with when we should not have.
>    ovl_do_remove() checks for OVL_TYPE_PURE_UPPER() and does not leave
>    whiteout if file is pure upper. In this case file is not found to be pure
>    upper hence whiteout is left.
>    
>    So why file was not PURE_UPPER in this case? I think because dentry is
>    still carrying some leftover state which was valid before rename. For
>    example, od->numlower was set to 1 as it was a lower file. After rename,
>    this state is not valid anymore as there is no such file in lower.
>    
>    Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com>
>    Reported-by: Viktor Stanchev <me@viktorstanchev.com>
>    Suggested-by: Vivek Goyal <vgoyal@redhat.com>
>    Link: https://bugzilla.kernel.org/show_bug.cgi?id=109611
>    Acked-by: Vivek Goyal <vgoyal@redhat.com>
>    Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e786702fff38e2b5142029d6de615abf1c8e436f
>Author: Rui Wang <rui.y.wang@intel.com>
>Date:   Fri Jan 8 23:09:59 2016 +0800
>
>    ovl: fix getcwd() failure after unsuccessful rmdir
>    
>    [ Upstream commit ce9113bbcbf45a57c082d6603b9a9f342be3ef74 ]
>    
>    ovl_remove_upper() should do d_drop() only after it successfully
>    removes the dir, otherwise a subsequent getcwd() system call will
>    fail, breaking userspace programs.
>    
>    This is to fix: https://bugzilla.kernel.org/show_bug.cgi?id=110491
>    
>    Signed-off-by: Rui Wang <rui.y.wang@intel.com>
>    Reviewed-by: Konstantin Khlebnikov <koct9i@gmail.com>
>    Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7ce08a0c9992da8986b06154a768646e41012469
>Author: Jouni Malinen <jouni@qca.qualcomm.com>
>Date:   Tue Mar 1 00:29:00 2016 +0200
>
>    mac80211: Fix Public Action frame RX in AP mode
>    
>    [ Upstream commit 1ec7bae8bec9b72e347e01330c745ab5cdd66f0e ]
>    
>    Public Action frames use special rules for how the BSSID field (Address
>    3) is set. A wildcard BSSID is used in cases where the transmitter and
>    recipient are not members of the same BSS. As such, we need to accept
>    Public Action frames with wildcard BSSID.
>    
>    Commit db8e17324553 ("mac80211: ignore frames between TDLS peers when
>    operating as AP") added a rule that drops Action frames to TDLS-peers
>    based on an Action frame having different DA (Address 1) and BSSID
>    (Address 3) values. This is not correct since it misses the possibility
>    of BSSID being a wildcard BSSID in which case the Address 1 would not
>    necessarily match.
>    
>    Fix this by allowing mac80211 to accept wildcard BSSID in an Action
>    frame when in AP mode.
>    
>    Fixes: db8e17324553 ("mac80211: ignore frames between TDLS peers when operating as AP")
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
>    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 87e0016ccb1f9cbe377d4af19cb840acbbdff206
>Author: Johannes Berg <johannes.berg@intel.com>
>Date:   Fri Feb 26 22:13:40 2016 +0100
>
>    mac80211: check PN correctly for GCMP-encrypted fragmented MPDUs
>    
>    [ Upstream commit 9acc54beb474c81148e2946603d141cf8716b19f ]
>    
>    Just like for CCMP we need to check that for GCMP the fragments
>    have PNs that increment by one; the spec was updated to fix this
>    security issue and now has the following text:
>    
>    	The receiver shall discard MSDUs and MMPDUs whose constituent
>    	MPDU PN values are not incrementing in steps of 1.
>    
>    Adapt the code for CCMP to work for GCMP as well, luckily the
>    relevant fields already alias each other so no code duplication
>    is needed (just check the aliasing with BUILD_BUG_ON.)
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a60ebc3d637071d56b66aac189dd3fcdfa707704
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Mon Feb 29 18:01:18 2016 +0100
>
>    ASoC: wm_adsp: Fix enum ctl accesses in a wrong type
>    
>    [ Upstream commit 15c665700bf6f4543f003ac0fbb1e9ec692e93f2 ]
>    
>    The firmware ctls like "DSP1 Firmware" in wm_adsp codec driver are
>    enum, while the current driver accesses wrongly via
>    value.integer.value[].  They have to be via value.enumerated.item[]
>    instead.
>    
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Mark Brown <broonie@kernel.org>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f4d57e47121afdfad04a82cbd07b246873ec1e19
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Mon Feb 29 18:01:15 2016 +0100
>
>    ASoC: wm8994: Fix enum ctl accesses in a wrong type
>    
>    [ Upstream commit 8019c0b37cd5a87107808300a496388b777225bf ]
>    
>    The DRC Mode like "AIF1DRC1 Mode" and EQ Mode like "AIF1.1 EQ Mode" in
>    wm8994 codec driver are enum ctls, while the current driver accesses
>    wrongly via value.integer.value[].  They have to be via
>    value.enumerated.item[] instead.
>    
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Mark Brown <broonie@kernel.org>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 58de29e6c58f7830826f48d7b0454cc1cec630ca
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Mon Feb 29 18:01:12 2016 +0100
>
>    ASoC: wm8958: Fix enum ctl accesses in a wrong type
>    
>    [ Upstream commit d0784829ae3b0beeb69b476f017d5c8a2eb95198 ]
>    
>    "MBC Mode", "VSS Mode", "VSS HPF Mode" and "Enhanced EQ Mode" ctls in
>    wm8958 codec driver are enum, while the current driver accesses
>    wrongly via value.integer.value[].  They have to be via
>    value.enumerated.item[] instead.
>    
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Mark Brown <broonie@kernel.org>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 33824bb3cb275aa931c996c2f67bf8bf9babe301
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Mon Feb 29 17:20:48 2016 +0100
>
>    ASoC: dapm: Fix ctl value accesses in a wrong type
>    
>    [ Upstream commit 741338f99f16dc24d2d01ac777b0798ae9d10a90 ]
>    
>    snd_soc_dapm_dai_link_get() and _put() access the associated ctl
>    values as value.integer.value[].  However, this is an enum ctl, and it
>    has to be accessed via value.enumerated.item[].  The former is long
>    while the latter is unsigned int, so they don't align.
>    
>    Fixes: c66150824b8a ('ASoC: dapm: add code to configure dai link parameters')
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Mark Brown <broonie@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 01ff3a0a01366a231593476cfe775596ebdba30f
>Author: Maximilain Schneider <max@schneidersoft.net>
>Date:   Tue Feb 23 01:17:28 2016 +0000
>
>    can: gs_usb: fixed disconnect bug by removing erroneous use of kfree()
>    
>    [ Upstream commit e9a2d81b1761093386a0bb8a4f51642ac785ef63 ]
>    
>    gs_destroy_candev() erroneously calls kfree() on a struct gs_can *, which is
>    allocated through alloc_candev() and should instead be freed using
>    free_candev() alone.
>    
>    The inappropriate use of kfree() causes the kernel to hang when
>    gs_destroy_candev() is called.
>    
>    Only the struct gs_usb * which is allocated through kzalloc() should be freed
>    using kfree() when the device is disconnected.
>    
>    Signed-off-by: Maximilian Schneider <max@schneidersoft.net>
>    Cc: linux-stable <stable@vger.kernel.org>
>    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 870be7d2ade42485fa40ac3d2ac8bcffa3afc957
>Author: Felix Fietkau <nbd@openwrt.org>
>Date:   Thu Feb 18 19:49:18 2016 +0100
>
>    mac80211: minstrel_ht: set default tx aggregation timeout to 0
>    
>    [ Upstream commit 7a36b930e6ed4702c866dc74a5ad07318a57c688 ]
>    
>    The value 5000 was put here with the addition of the timeout field to
>    ieee80211_start_tx_ba_session. It was originally added in mac80211 to
>    save resources for drivers like iwlwifi, which only supports a limited
>    number of concurrent aggregation sessions.
>    
>    Since iwlwifi does not use minstrel_ht and other drivers don't need
>    this, 0 is a better default - especially since there have been
>    recent reports of aggregation setup related issues reproduced with
>    ath9k. This should improve stability without causing any adverse
>    effects.
>    
>    Cc: stable@vger.kernel.org
>    Acked-by: Avery Pennarun <apenwarr@gmail.com>
>    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
>    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ea46df70efaa589117dce85dec3e3707362e514a
>Author: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
>Date:   Thu Feb 18 15:47:13 2016 +0000
>
>    ASoC: samsung: Use IRQ safe spin lock calls
>    
>    [ Upstream commit 316fa9e09ad76e095b9d7e9350c628b918370a22 ]
>    
>    Lockdep warns of a potential lock inversion, i2s->lock is held numerous
>    times whilst we are under the substream lock (snd_pcm_stream_lock). If
>    we use the IRQ unsafe spin lock calls, you can also end up locking
>    snd_pcm_stream_lock whilst under i2s->lock (if an IRQ happens whilst we
>    are holding i2s->lock). This could result in deadlock.
>    
>    [   18.147001]        CPU0                    CPU1
>    [   18.151509]        ----                    ----
>    [   18.156022]   lock(&(&pri_dai->spinlock)->rlock);
>    [   18.160701]                                local_irq_disable();
>    [   18.166622]                                lock(&(&substream->self_group.lock)->rlock);
>    [   18.174595]                                lock(&(&pri_dai->spinlock)->rlock);
>    [   18.181806]   <Interrupt>
>    [   18.184408]     lock(&(&substream->self_group.lock)->rlock);
>    [   18.190045]
>    [   18.190045]  *** DEADLOCK ***
>    
>    This patch changes to using the irq safe spinlock calls, to avoid this
>    issue.
>    
>    Fixes: ce8bcdbb61d9 ("ASoC: samsung: i2s: Protect more registers with a spinlock")
>    Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
>    Tested-by: Anand Moon <linux.amoon@gmail.com>
>    Signed-off-by: Mark Brown <broonie@kernel.org>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7e62b968351c3759db1ad78b4aaaeff72ab2b998
>Author: Liad Kaufman <liad.kaufman@intel.com>
>Date:   Sun Feb 14 15:32:58 2016 +0200
>
>    iwlwifi: mvm: inc pending frames counter also when txing non-sta
>    
>    [ Upstream commit fb896c44f88a75843a072cd6961b1615732f7811 ]
>    
>    Until this patch, when TXing non-sta the pending_frames counter
>    wasn't increased, but it WAS decreased in
>    iwl_mvm_rx_tx_cmd_single(), what makes it negative in certain
>    conditions. This in turn caused much trouble when we need to
>    remove the station since we won't be waiting forever until
>    pending_frames gets 0. In certain cases, we were exhausting
>    the station table even in BSS mode, because we had a lot of
>    stale stations.
>    
>    Increase the counter also in iwl_mvm_tx_skb_non_sta() after a
>    successful TX to avoid this outcome.
>    
>    CC: <stable@vger.kernel.org> [3.18+]
>    Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
>    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 60ca0012a0965fe57712eef8361ec99b9c76eb06
>Author: Sven Eckelmann <sven.eckelmann@open-mesh.com>
>Date:   Tue Feb 2 08:12:26 2016 +0100
>
>    mac80211: minstrel: Change expected throughput unit back to Kbps
>    
>    [ Upstream commit 212c5a5e6ba61678be6b5fee576e38bccb50b613 ]
>    
>    The change from cur_tp to the function
>    minstrel_get_tp_avg/minstrel_ht_get_tp_avg changed the unit used for the
>    current throughput. For example in minstrel_ht the correct
>    conversion between them would be:
>    
>        mrs->cur_tp / 10 == minstrel_ht_get_tp_avg(..).
>    
>    This factor 10 must also be included in the calculation of
>    minstrel_get_expected_throughput and minstrel_ht_get_expected_throughput to
>    return values with the unit [Kbps] instead of [10Kbps]. Otherwise routing
>    algorithms like B.A.T.M.A.N. V will make incorrect decision based on these
>    values. Its kernel based implementation expects expected_throughput always
>    to have the unit [Kbps] and not sometimes [10Kbps] and sometimes [Kbps].
>    
>    The same requirement has iw or olsrdv2's nl80211 based statistics module
>    which retrieve the same data via NL80211_STA_INFO_TX_BITRATE.
>    
>    Cc: stable@vger.kernel.org
>    Fixes: 6a27b2c40b48 ("mac80211: restructure per-rate throughput calculation into function")
>    Signed-off-by: Sven Eckelmann <sven@open-mesh.com>
>    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d5bb89facc7b689292d85471be1fdbae1928e224
>Author: Chris Bainbridge <chris.bainbridge@gmail.com>
>Date:   Wed Jan 27 15:46:18 2016 +0000
>
>    mac80211: fix use of uninitialised values in RX aggregation
>    
>    [ Upstream commit f39ea2690bd61efec97622c48323f40ed6e16317 ]
>    
>    Use kzalloc instead of kmalloc for struct tid_ampdu_rx to
>    initialize the "removed" field (all others are initialized
>    manually). That fixes:
>    
>    UBSAN: Undefined behaviour in net/mac80211/rx.c:932:29
>    load of value 2 is not a valid value for type '_Bool'
>    CPU: 3 PID: 1134 Comm: kworker/u16:7 Not tainted 4.5.0-rc1+ #265
>    Workqueue: phy0 rt2x00usb_work_rxdone
>     0000000000000004 ffff880254a7ba50 ffffffff8181d866 0000000000000007
>     ffff880254a7ba78 ffff880254a7ba68 ffffffff8188422d ffffffff8379b500
>     ffff880254a7bab8 ffffffff81884747 0000000000000202 0000000348620032
>    Call Trace:
>     [<ffffffff8181d866>] dump_stack+0x45/0x5f
>     [<ffffffff8188422d>] ubsan_epilogue+0xd/0x40
>     [<ffffffff81884747>] __ubsan_handle_load_invalid_value+0x67/0x70
>     [<ffffffff82227b4d>] ieee80211_sta_reorder_release.isra.16+0x5ed/0x730
>     [<ffffffff8222ca14>] ieee80211_prepare_and_rx_handle+0xd04/0x1c00
>     [<ffffffff8222db03>] __ieee80211_rx_handle_packet+0x1f3/0x750
>     [<ffffffff8222e4a7>] ieee80211_rx_napi+0x447/0x990
>    
>    While at it, convert to use sizeof(*tid_agg_rx) instead.
>    
>    Fixes: 788211d81bfdf ("mac80211: fix RX A-MPDU session reorder timer deletion")
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Chris Bainbridge <chris.bainbridge@gmail.com>
>    [reword commit message, use sizeof(*tid_agg_rx)]
>    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6d5202f35ff2277d76eb53da93ed70080d6f4ec1
>Author: Johannes Berg <johannes.berg@intel.com>
>Date:   Wed Jan 27 13:29:34 2016 +0100
>
>    cfg80211/wext: fix message ordering
>    
>    [ Upstream commit cb150b9d23be6ee7f3a0fff29784f1c5b5ac514d ]
>    
>    Since cfg80211 frequently takes actions from its netdev notifier
>    call, wireless extensions messages could still be ordered badly
>    since the wext netdev notifier, since wext is built into the
>    kernel, runs before the cfg80211 netdev notifier. For example,
>    the following can happen:
>    
>    5: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN group default
>        link/ether 02:00:00:00:01:00 brd ff:ff:ff:ff:ff:ff
>    5: wlan1: <BROADCAST,MULTICAST,UP>
>        link/ether
>    
>    when setting the interface down causes the wext message.
>    
>    To also fix this, export the wireless_nlevent_flush() function
>    and also call it from the cfg80211 notifier.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 746ba2ee59997437988060c709324057b761bd96
>Author: Johannes Berg <johannes.berg@intel.com>
>Date:   Wed Jan 27 12:37:52 2016 +0100
>
>    wext: fix message delay/ordering
>    
>    [ Upstream commit 8bf862739a7786ae72409220914df960a0aa80d8 ]
>    
>    Beniamino reported that he was getting an RTM_NEWLINK message for a
>    given interface, after the RTM_DELLINK for it. It turns out that the
>    message is a wireless extensions message, which was sent because the
>    interface had been connected and disconnection while it was deleted
>    caused a wext message.
>    
>    For its netlink messages, wext uses RTM_NEWLINK, but the message is
>    without all the regular rtnetlink attributes, so "ip monitor link"
>    prints just rudimentary information:
>    
>    5: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN group default
>        link/ether 02:00:00:00:01:00 brd ff:ff:ff:ff:ff:ff
>    Deleted 5: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default
>        link/ether 02:00:00:00:01:00 brd ff:ff:ff:ff:ff:ff
>    5: wlan1: <BROADCAST,MULTICAST,UP>
>        link/ether
>    (from my hwsim reproduction)
>    
>    This can cause userspace to get confused since it doesn't expect an
>    RTM_NEWLINK message after RTM_DELLINK.
>    
>    The reason for this is that wext schedules a worker to send out the
>    messages, and the scheduling delay can cause the messages to get out
>    to userspace in different order.
>    
>    To fix this, have wext register a netdevice notifier and flush out
>    any pending messages when netdevice state changes. This fixes any
>    ordering whenever the original message wasn't sent by a notifier
>    itself.
>    
>    Cc: stable@vger.kernel.org
>    Reported-by: Beniamino Galvani <bgalvani@redhat.com>
>    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7f30737678023b5becaf0e2e012665f71b886a7d
>Author: Sasha Levin <sasha.levin@oracle.com>
>Date:   Thu Mar 17 14:11:03 2016 -0400
>
>    Linux 4.1.20
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b014bae072a1dad1767c5c6e7e7b480165685c3e
>Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
>Date:   Thu Oct 8 18:19:53 2015 +0200
>
>    ipv6: drop frames with attached skb->sk in forwarding
>    
>    [ Upstream commit 9ef2e965e55481a52d6d91ce61977a27836268d3 ]
>    
>    This is a clone of commit 2ab957492d13b ("ip_forward: Drop frames with
>    attached skb->sk") for ipv6.
>    
>    This commit has exactly the same reasons as the above mentioned commit,
>    namely to prevent panics during netfilter reload or a misconfigured stack.
>    
>    Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b5c41530ef442dba667c4d964c722e8157f7da72
>Author: Marcelo Tosatti <mtosatti@redhat.com>
>Date:   Fri Mar 11 16:53:11 2016 +0800
>
>    KVM: x86: move steal time initialization to vcpu entry time
>    
>    [ Upstream commit 7cae2bedcbd4680b155999655e49c27b9cf020fa ]
>    
>    As reported at https://bugs.launchpad.net/qemu/+bug/1494350,
>    it is possible to have vcpu->arch.st.last_steal initialized
>    from a thread other than vcpu thread, say the iothread, via
>    KVM_SET_MSRS.
>    
>    Which can cause an overflow later (when subtracting from vcpu threads
>    sched_info.run_delay).
>    
>    To avoid that, move steal time accumulation to vcpu entry time,
>    before copying steal time data to guest.
>    
>    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
>    Reviewed-by: David Matlack <dmatlack@google.com>
>    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 325940deb74b23351f507d5f1e1e01592c1efa1c
>Author: Richard Weinberger <richard@nod.at>
>Date:   Sun Feb 21 10:53:03 2016 +0100
>
>    ubi: Fix out of bounds write in volume update code
>    
>    [ Upstream commit e4f6daac20332448529b11f09388f1d55ef2084c ]
>    
>    ubi_start_leb_change() allocates too few bytes.
>    ubi_more_leb_change_data() will write up to req->upd_bytes +
>    ubi->min_io_size bytes.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Richard Weinberger <richard@nod.at>
>    Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5a4557b0eb8a2a0b3bccdcbc7a66b8b04262f878
>Author: Maciej W. Rozycki <macro@imgtec.com>
>Date:   Fri Mar 4 01:42:49 2016 +0000
>
>    MIPS: traps: Fix SIGFPE information leak from `do_ov' and `do_trap_or_bp'
>    
>    [ Upstream commit e723e3f7f9591b79e8c56b3d7c5a204a9c571b55 ]
>    
>    Avoid sending a partially initialised `siginfo_t' structure along SIGFPE
>    signals issued from `do_ov' and `do_trap_or_bp', leading to information
>    leaking from the kernel stack.
>    
>    Signed-off-by: Maciej W. Rozycki <macro@imgtec.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f00b04c358d1583826a7340dc661eff6f8399898
>Author: Simon South <simon@simonsouth.com>
>Date:   Wed Mar 2 23:10:44 2016 -0500
>
>    ALSA: hda - Fix mic issues on Acer Aspire E1-472
>    
>    [ Upstream commit 02322ac9dee9aff8d8862e8d6660ebe102f492ea ]
>    
>    This patch applies the microphone-related fix created for the Acer
>    Aspire E1-572 to the E1-472 as well, as it uses the same Realtek ALC282
>    CODEC and demonstrates the same issues.
>    
>    This patch allows an external, headset microphone to be used and limits
>    the gain on the (quite noisy) internal microphone.
>    
>    Signed-off-by: Simon South <simon@simonsouth.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8ef267aabd98f9df0279b9bb4245a3b985ead692
>Author: Todd E Brandt <todd.e.brandt@linux.intel.com>
>Date:   Wed Mar 2 16:05:29 2016 -0800
>
>    PM / sleep / x86: Fix crash on graph trace through x86 suspend
>    
>    [ Upstream commit 92f9e179a702a6adbc11e2fedc76ecd6ffc9e3f7 ]
>    
>    Pause/unpause graph tracing around do_suspend_lowlevel as it has
>    inconsistent call/return info after it jumps to the wakeup vector.
>    The graph trace buffer will otherwise become misaligned and
>    may eventually crash and hang on suspend.
>    
>    To reproduce the issue and test the fix:
>    Run a function_graph trace over suspend/resume and set the graph
>    function to suspend_devices_and_enter. This consistently hangs the
>    system without this fix.
>    
>    Signed-off-by: Todd Brandt <todd.e.brandt@linux.intel.com>
>    Cc: All applicable <stable@vger.kernel.org>
>    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b13b243e312d56d7ff491a553056454c2723b021
>Author: Alex Deucher <alexander.deucher@amd.com>
>Date:   Wed Feb 24 17:38:38 2016 -0500
>
>    drm/radeon/pm: update current crtc info after setting the powerstate
>    
>    [ Upstream commit 5e031d9fe8b0741f11d49667dfc3ebf5454121fd ]
>    
>    On CI, we need to see if the number of crtcs changes to determine
>    whether or not we need to upload the mclk table again.  In practice
>    we don't currently upload the mclk table again after the initial load.
>    The only reason you would would be to add new states, e.g., for
>    arbitrary mclk setting which is not currently supported.
>    
>    Acked-by: Christian KÃ¶nig <christian.koenig@amd.com>
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4765409e36975036eeb5a79ca58d0b3da6131101
>Author: BjÃ¸rn Mork <bjorn@mork.no>
>Date:   Tue Mar 1 14:36:32 2016 +0100
>
>    USB: qcserial: add Sierra Wireless EM74xx device ID
>    
>    [ Upstream commit 04fdbc825ffc02fb098964b92de802fff44e73fd ]
>    
>    The MC74xx and EM74xx modules use different IDs by default, according
>    to the Lenovo EM7455 driver for Windows.
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: BjÃ¸rn Mork <bjorn@mork.no>
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f0adda6a9f5b1689cbf47dd56cf73da201c014d8
>Author: Timothy Pearson <tpearson@raptorengineeringinc.com>
>Date:   Fri Feb 26 15:29:32 2016 -0600
>
>    drm/ast: Fix incorrect register check for DRAM width
>    
>    [ Upstream commit 2d02b8bdba322b527c5f5168ce1ca10c2d982a78 ]
>    
>    During DRAM initialization on certain ASpeed devices, an incorrect
>    bit (bit 10) was checked in the "SDRAM Bus Width Status" register
>    to determine DRAM width.
>    
>    Query bit 6 instead in accordance with the Aspeed AST2050 datasheet v1.05.
>    
>    Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Dave Airlie <airlied@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b8ad68546922dd5acb6cd32628bc9ae69a4795f9
>Author: Helge Deller <deller@gmx.de>
>Date:   Tue Jan 19 16:08:49 2016 +0100
>
>    parisc: Fix ptrace syscall number and return value modification
>    
>    [ Upstream commit 98e8b6c9ac9d1b1e9d1122dfa6783d5d566bb8f7 ]
>    
>    Mike Frysinger reported that his ptrace testcase showed strange
>    behaviour on parisc: It was not possible to avoid a syscall and the
>    return value of a syscall couldn't be changed.
>    
>    To modify a syscall number, we were missing to save the new syscall
>    number to gr20 which is then picked up later in assembly again.
>    
>    The effect that the return value couldn't be changed is a side-effect of
>    another bug in the assembly code. When a process is ptraced, userspace
>    expects each syscall to report entrance and exit of a syscall.  If a
>    syscall number was given which doesn't exist, we jumped to the normal
>    syscall exit code instead of informing userspace that the (non-existant)
>    syscall exits. This unexpected behaviour confuses userspace and thus the
>    bug was misinterpreted as if we can't change the return value.
>    
>    This patch fixes both problems and was tested on 64bit kernel with
>    32bit userspace.
>    
>    Signed-off-by: Helge Deller <deller@gmx.de>
>    Cc: Mike Frysinger <vapier@gentoo.org>
>    Cc: stable@vger.kernel.org  # v4.0+
>    Tested-by: Mike Frysinger <vapier@gentoo.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ebe15c00057a4efad2bae1a90b04a20766cefc8c
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Tue Mar 1 18:30:18 2016 +0100
>
>    ALSA: seq: oss: Don't drain at closing a client
>    
>    [ Upstream commit 197b958c1e76a575d77038cc98b4bebc2134279f ]
>    
>    The OSS sequencer client tries to drain the pending events at
>    releasing.  Unfortunately, as spotted by syzkaller fuzzer, this may
>    lead to an unkillable process state when the event has been queued at
>    the far future.  Since the process being released can't be signaled
>    any longer, it remains and waits for the echo-back event in that far
>    future.
>    
>    Back to history, the draining feature was implemented at the time we
>    misinterpreted POSIX definition for blocking file operation.
>    Actually, such a behavior is superfluous at release, and we should
>    just release the device as is instead of keeping it up forever.
>    
>    This patch just removes the draining call that may block the release
>    for too long time unexpectedly.
>    
>    BugLink: http://lkml.kernel.org/r/CACT4Y+Y4kD-aBGj37rf-xBw9bH3GMU6P+MYg4W1e-s-paVD2pg@mail.gmail.com
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 74a8e4d036f86999d15a4f1c24fc6f33423eb338
>Author: Dennis Kadioglu <denk@post.com>
>Date:   Tue Mar 1 14:23:29 2016 +0100
>
>    ALSA: usb-audio: Add a quirk for Plantronics DA45
>    
>    [ Upstream commit 17e2df4613be57d0fab68df749f6b8114e453152 ]
>    
>    Plantronics DA45 does not support reading the sample rate which leads
>    to many lines of "cannot get freq at ep 0x4" and "cannot get freq at
>    ep 0x84". This patch adds the USB ID of the DA45 to quirks.c and
>    avoids those error messages.
>    
>    Signed-off-by: Dennis Kadioglu <denk@post.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 63e289a204c69536706706e31a6805035029852d
>Author: Yegor Yefremov <yegorslists@googlemail.com>
>Date:   Mon Feb 29 16:39:57 2016 +0100
>
>    USB: serial: option: add support for Quectel UC20
>    
>    [ Upstream commit c0992d0f54847d0d1d85c60fcaa054f175ab1ccd ]
>    
>    Add support for Quectel UC20 and blacklist the QMI interface.
>    
>    Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
>    Cc: stable <stable@vger.kernel.org>
>    [johan: amend commit message ]
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 09757912c869346ec88920263aa37a3a854aa038
>Author: Daniele Palmas <dnlplm@gmail.com>
>Date:   Mon Feb 29 15:36:11 2016 +0100
>
>    USB: serial: option: add support for Telit LE922 PID 0x1045
>    
>    [ Upstream commit 5deef5551c77e488922cc4bf4bc76df63be650d0 ]
>    
>    This patch adds support for 0x1045 PID of Telit LE922.
>    
>    Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit fcc00f16ba5e947136d81d2c8efbccce1c564548
>Author: Vittorio Alfieri <vittorio88@gmail.com>
>Date:   Sun Feb 28 14:40:24 2016 +0100
>
>    USB: cp210x: Add ID for Parrot NMEA GPS Flight Recorder
>    
>    [ Upstream commit 3c4c615d70c8cbdc8ba8c79ed702640930652a79 ]
>    
>    The Parrot NMEA GPS Flight Recorder is a USB composite device
>    consisting of hub, flash storage, and cp210x usb to serial chip.
>    It is an accessory to the mass-produced Parrot AR Drone 2.
>    The device emits standard NMEA messages which make the it compatible
>    with NMEA compatible software. It was tested using gpsd version 3.11-3
>    as an NMEA interpreter and using the official Parrot Flight Recorder.
>    
>    Signed-off-by: Vittorio Alfieri <vittorio88@gmail.com>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 369ac9cea85f7eea546ddea7e712672ffeabd5ce
>Author: Patrik Halfar <patrik_halfar@halfarit.cz>
>Date:   Sat Feb 20 18:49:56 2016 +0100
>
>    USB: qcserial: add Dell Wireless 5809e Gobi 4G HSPA+ (rev3)
>    
>    [ Upstream commit 013dd239d6220a4e0dfdf0d45a82c34f1fd73deb ]
>    
>    New revision of Dell Wireless 5809e Gobi 4G HSPA+ Mobile Broadband Card
>    has new idProduct.
>    
>    Bus 002 Device 006: ID 413c:81b3 Dell Computer Corp.
>    Device Descriptor:
>      bLength                18
>      bDescriptorType         1
>      bcdUSB               2.00
>      bDeviceClass            0
>      bDeviceSubClass         0
>      bDeviceProtocol         0
>      bMaxPacketSize0        64
>      idVendor           0x413c Dell Computer Corp.
>      idProduct          0x81b3
>      bcdDevice            0.06
>      iManufacturer           1 Sierra Wireless, Incorporated
>      iProduct                2 Dell Wireless 5809e Gobiâ¢ 4G HSPA+ Mobile Broadband Card
>      iSerial                 3
>      bNumConfigurations      2
>    
>    Signed-off-by: Patrik Halfar <patrik_halfar@halfarit.cz>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c8ce76e3c6cd937e8b3fd8ae3573f23767b70eca
>Author: Al Viro <viro@zeniv.linux.org.uk>
>Date:   Mon Feb 29 12:12:46 2016 -0500
>
>    use ->d_seq to get coherency between ->d_inode and ->d_flags
>    
>    [ Upstream commit a528aca7f359f4b0b1d72ae406097e491a5ba9ea ]
>    
>    Games with ordering and barriers are way too brittle.  Just
>    bump ->d_seq before and after updating ->d_inode and ->d_flags
>    type bits, so that verifying ->d_seq would guarantee they are
>    coherent.
>    
>    Cc: stable@vger.kernel.org # v3.13+
>    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4950beba6231d72c54aa5f52d96487fdda8292ed
>Author: Peter Zijlstra <peterz@infradead.org>
>Date:   Thu Jun 11 14:46:46 2015 +0200
>
>    seqcount: Rename write_seqcount_barrier()
>    
>    [ Upstream commit a7c6f571ff51cc77d90dd54968f7c5c938c43998 ]
>    
>    I'll shortly be introducing another seqcount primitive that's useful
>    to provide ordering semantics and would like to use the
>    write_seqcount_barrier() name for that.
>    
>    Seeing how there's only one user of the current primitive, lets rename
>    it to invalidate, as that appears what its doing.
>    
>    While there, employ lockdep_assert_held() instead of
>    assert_spin_locked() to not generate debug code for regular kernels.
>    
>    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 Nesterov <oleg@redhat.com>
>    Cc: wanpeng.li@linux.intel.com
>    Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
>    Cc: Al Viro <viro@ZenIV.linux.org.uk>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: umgwanakikbuti@gmail.com
>    Link: http://lkml.kernel.org/r/20150611124743.279926217@infradead.org
>    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 67d352da6e0e14bd5987661a2be95bbaaf4c3d53
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Mon Feb 29 14:26:43 2016 +0100
>
>    ALSA: hdsp: Fix wrong boolean ctl value accesses
>    
>    [ Upstream commit eab3c4db193f5fcccf70e884de9a922ca2c63d80 ]
>    
>    snd-hdsp driver accesses enum item values (int) instead of boolean
>    values (long) wrongly for some ctl elements.  This patch fixes them.
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6177e82a6b6586a057e2f00940e2e220b993547e
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Mon Feb 29 14:32:42 2016 +0100
>
>    ALSA: hdspm: Fix zero-division
>    
>    [ Upstream commit c1099c3294c2344110085a38c50e478a5992b368 ]
>    
>    HDSPM driver contains a code issuing zero-division potentially in
>    system sample rate ctl code.  This patch fixes it by not processing
>    a zero or invalid rate value as a divisor, as well as excluding the
>    invalid value to be passed via the given ctl element.
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b9800dd1d9eeb4b5f81a485b270702a02b142b9b
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Mon Feb 29 14:25:16 2016 +0100
>
>    ALSA: hdspm: Fix wrong boolean ctl value accesses
>    
>    [ Upstream commit 537e48136295c5860a92138c5ea3959b9542868b ]
>    
>    snd-hdspm driver accesses enum item values (int) instead of boolean
>    values (long) wrongly for some ctl elements.  This patch fixes them.
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d850c054f3aeedf5e18290d14b097b5ed67fa9fb
>Author: Michael S. Tsirkin <mst@redhat.com>
>Date:   Sun Feb 28 17:35:59 2016 +0200
>
>    MIPS: kvm: Fix ioctl error handling.
>    
>    [ Upstream commit 887349f69f37e71e2a8bfbd743831625a0b2ff51 ]
>    
>    Calling return copy_to_user(...) or return copy_from_user in an ioctl
>    will not do the right thing if there's a pagefault:
>    copy_to_user/copy_from_user return the number of bytes not copied in
>    this case.
>    
>    Fix up kvm on mips to do
>    	return copy_to_user(...)) ?  -EFAULT : 0;
>    and
>    	return copy_from_user(...)) ?  -EFAULT : 0;
>    
>    everywhere.
>    
>    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>    Cc: Paolo Bonzini <pbonzini@redhat.com>
>    Cc: James Hogan <james.hogan@imgtec.com>
>    Cc: linux-kernel@vger.kernel.org
>    Cc: linux-mips@linux-mips.org
>    Cc: stable@vger.kernel.org
>    Cc: kvm@vger.kernel.org
>    Patchwork: https://patchwork.linux-mips.org/patch/12709/
>    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 222b341c1063cb7aa497d7ed051ccb60349f54bb
>Author: Michael S. Tsirkin <mst@redhat.com>
>Date:   Sun Feb 28 17:32:07 2016 +0200
>
>    arm/arm64: KVM: Fix ioctl error handling
>    
>    [ Upstream commit 4cad67fca3fc952d6f2ed9e799621f07666a560f ]
>    
>    Calling return copy_to_user(...) in an ioctl will not
>    do the right thing if there's a pagefault:
>    copy_to_user returns the number of bytes not copied
>    in this case.
>    
>    Fix up kvm to do
>    	return copy_to_user(...)) ?  -EFAULT : 0;
>    
>    everywhere.
>    
>    Cc: stable@vger.kernel.org
>    Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
>    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 092bb6bd432857cde601ab6f2716ef313f6f7023
>Author: Yadan Fan <ydfan@novell.com>
>Date:   Mon Feb 29 14:44:57 2016 +0800
>
>    Fix cifs_uniqueid_to_ino_t() function for s390x
>    
>    [ Upstream commit 1ee9f4bd1a97026a7b2d7ae9f1f74b45680d0003 ]
>    
>    This issue is caused by commit 02323db17e3a7 ("cifs: fix
>    cifs_uniqueid_to_ino_t not to ever return 0"), when BITS_PER_LONG
>    is 64 on s390x, the corresponding cifs_uniqueid_to_ino_t()
>    function will cast 64-bit fileid to 32-bit by using (ino_t)fileid,
>    because ino_t (typdefed __kernel_ino_t) is int type.
>    
>    It's defined in arch/s390/include/uapi/asm/posix_types.h
>    
>        #ifndef __s390x__
>    
>        typedef unsigned long   __kernel_ino_t;
>        ...
>        #else /* __s390x__ */
>    
>        typedef unsigned int    __kernel_ino_t;
>    
>    So the #ifdef condition is wrong for s390x, we can just still use
>    one cifs_uniqueid_to_ino_t() function with comparing sizeof(ino_t)
>    and sizeof(u64) to choose the correct execution accordingly.
>    
>    Signed-off-by: Yadan Fan <ydfan@suse.com>
>    CC: stable <stable@vger.kernel.org>
>    Signed-off-by: Steve French <smfrench@gmail.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 78b821d76e779822877604052f06219294e9e038
>Author: Pavel Shilovsky <pshilovsky@samba.org>
>Date:   Sat Feb 27 11:58:18 2016 +0300
>
>    CIFS: Fix SMB2+ interim response processing for read requests
>    
>    [ Upstream commit 6cc3b24235929b54acd5ecc987ef11a425bd209e ]
>    
>    For interim responses we only need to parse a header and update
>    a number credits. Now it is done for all SMB2+ command except
>    SMB2_READ which is wrong. Fix this by adding such processing.
>    
>    Signed-off-by: Pavel Shilovsky <pshilovsky@samba.org>
>    Tested-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
>    CC: Stable <stable@vger.kernel.org>
>    Signed-off-by: Steve French <smfrench@gmail.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 94a7d752e43717119822fee8b04be903e694017e
>Author: Justin Maggard <jmaggard10@gmail.com>
>Date:   Tue Feb 9 15:52:08 2016 -0800
>
>    cifs: fix out-of-bounds access in lease parsing
>    
>    [ Upstream commit deb7deff2f00bdbbcb3d560dad2a89ef37df837d ]
>    
>    When opening a file, SMB2_open() attempts to parse the lease state from the
>    SMB2 CREATE Response.  However, the parsing code was not careful to ensure
>    that the create contexts are not empty or invalid, which can lead to out-
>    of-bounds memory access.  This can be seen easily by trying
>    to read a file from a OSX 10.11 SMB3 server.  Here is sample crash output:
>    
>    BUG: unable to handle kernel paging request at ffff8800a1a77cc6
>    IP: [<ffffffff8828a734>] SMB2_open+0x804/0x960
>    PGD 8f77067 PUD 0
>    Oops: 0000 [#1] SMP
>    Modules linked in:
>    CPU: 3 PID: 2876 Comm: cp Not tainted 4.5.0-rc3.x86_64.1+ #14
>    Hardware name: NETGEAR ReadyNAS 314          /ReadyNAS 314          , BIOS 4.6.5 10/11/2012
>    task: ffff880073cdc080 ti: ffff88005b31c000 task.ti: ffff88005b31c000
>    RIP: 0010:[<ffffffff8828a734>]  [<ffffffff8828a734>] SMB2_open+0x804/0x960
>    RSP: 0018:ffff88005b31fa08  EFLAGS: 00010282
>    RAX: 0000000000000015 RBX: 0000000000000000 RCX: 0000000000000006
>    RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff88007eb8c8b0
>    RBP: ffff88005b31fad8 R08: 666666203d206363 R09: 6131613030383866
>    R10: 3030383866666666 R11: 00000000000002b0 R12: ffff8800660fd800
>    R13: ffff8800a1a77cc2 R14: 00000000424d53fe R15: ffff88005f5a28c0
>    FS:  00007f7c8a2897c0(0000) GS:ffff88007eb80000(0000) knlGS:0000000000000000
>    CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>    CR2: ffff8800a1a77cc6 CR3: 000000005b281000 CR4: 00000000000006e0
>    Stack:
>     ffff88005b31fa70 ffffffff88278789 00000000000001d3 ffff88005f5a2a80
>     ffffffff00000003 ffff88005d029d00 ffff88006fde05a0 0000000000000000
>     ffff88005b31fc78 ffff88006fde0780 ffff88005b31fb2f 0000000100000fe0
>    Call Trace:
>     [<ffffffff88278789>] ? cifsConvertToUTF16+0x159/0x2d0
>     [<ffffffff8828cf68>] smb2_open_file+0x98/0x210
>     [<ffffffff8811e80c>] ? __kmalloc+0x1c/0xe0
>     [<ffffffff882685f4>] cifs_open+0x2a4/0x720
>     [<ffffffff88122cef>] do_dentry_open+0x1ff/0x310
>     [<ffffffff88268350>] ? cifsFileInfo_get+0x30/0x30
>     [<ffffffff88123d92>] vfs_open+0x52/0x60
>     [<ffffffff88131dd0>] path_openat+0x170/0xf70
>     [<ffffffff88097d48>] ? remove_wait_queue+0x48/0x50
>     [<ffffffff88133a29>] do_filp_open+0x79/0xd0
>     [<ffffffff8813f2ca>] ? __alloc_fd+0x3a/0x170
>     [<ffffffff881240c4>] do_sys_open+0x114/0x1e0
>     [<ffffffff881241a9>] SyS_open+0x19/0x20
>     [<ffffffff8896e257>] entry_SYSCALL_64_fastpath+0x12/0x6a
>    Code: 4d 8d 6c 07 04 31 c0 4c 89 ee e8 47 6f e5 ff 31 c9 41 89 ce 44 89 f1 48 c7 c7 28 b1 bd 88 31 c0 49 01 cd 4c 89 ee e8 2b 6f e5 ff <45> 0f b7 75 04 48 c7 c7 31 b1 bd 88 31 c0 4d 01 ee 4c 89 f6 e8
>    RIP  [<ffffffff8828a734>] SMB2_open+0x804/0x960
>     RSP <ffff88005b31fa08>
>    CR2: ffff8800a1a77cc6
>    ---[ end trace d9f69ba64feee469 ]---
>    
>    Signed-off-by: Justin Maggard <jmaggard@netgear.com>
>    Signed-off-by: Steve French <smfrench@gmail.com>
>    CC: Stable <stable@vger.kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit fb5b8ac0043cc2c0e8816341f8a875ab320563fe
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Sun Feb 28 11:41:47 2016 +0100
>
>    ALSA: timer: Fix ioctls for X32 ABI
>    
>    [ Upstream commit b24e7ad1fdc22177eb3e51584e1cfcb45d818488 ]
>    
>    X32 ABI takes the 64bit timespec, thus the timer user status ioctl becomes
>    incompatible with IA32.  This results in NOTTY error when the ioctl is
>    issued.
>    
>    Meanwhile, this struct in X32 is essentially identical with the one in
>    X86-64, so we can just bypassing to the existing code for this
>    specific compat ioctl.
>    
>    Cc: <stable@vger.kernel.org> # v3.4+
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6dcecec27d0ec5869503ff31b0316c3956a3aa89
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Sun Feb 28 11:36:14 2016 +0100
>
>    ALSA: timer: Fix broken compat timer user status ioctl
>    
>    [ Upstream commit 3a72494ac2a3bd229db941d51e7efe2f6ccd947b ]
>    
>    The timer user status compat ioctl returned the bogus struct used for
>    64bit architectures instead of the 32bit one.  This patch addresses
>    it to return the proper struct.
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e59edea51ad3491f1c110acc1a3f2b0b6ee31f62
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Sun Feb 28 11:28:08 2016 +0100
>
>    ALSA: rawmidi: Fix ioctls X32 ABI
>    
>    [ Upstream commit 2251fbbc1539f05b0b206b37a602d5776be37252 ]
>    
>    Like the previous fixes for ctl and PCM, we need a fix for
>    incompatible X32 ABI regarding the rawmidi: namely, struct
>    snd_rawmidi_status has the timespec, and the size and the alignment on
>    X32 differ from IA32.
>    
>    This patch fixes the incompatible ioctl for X32.
>    
>    Cc: <stable@vger.kernel.org> # v3.4+
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit bffe692e21f78b45735efd8aa0dd17f7141888db
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Sun Feb 28 11:23:09 2016 +0100
>
>    ALSA: pcm: Fix ioctls for X32 ABI
>    
>    [ Upstream commit 513ace79b657e2022a592e77f24074e088681ecc ]
>    
>    X32 ABI uses the 64bit timespec in addition to 64bit alignment of
>    64bit values.  This leads to incompatibilities in some PCM ioctls
>    involved with snd_pcm_channel_info, snd_pcm_status and
>    snd_pcm_sync_ptr structs.  Fix the PCM compat ABI for these ioctls
>    like the previous commit for ctl API.
>    
>    Reported-by: Steven Newbury <steve@snewbury.org.uk>
>    Cc: <stable@vger.kernel.org> # v3.4+
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3aa7c24c31ee77017718dea1e4e43a2cbc969b53
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Sat Feb 27 17:52:42 2016 +0100
>
>    ALSA: ctl: Fix ioctls for X32 ABI
>    
>    [ Upstream commit 6236d8bb2afcfe71b88ecea554e0dc638090a45f ]
>    
>    The X32 ABI takes the same alignment like x86-64, and this may result
>    in the incompatible struct size from ia32.  Unfortunately, we hit this
>    in some control ABI: struct snd_ctl_elem_value differs between them
>    due to the position of 64bit variable array.  This ends up with the
>    unknown ioctl (ENOTTY) error.
>    
>    The fix is to add the compat entries for the new aligned struct.
>    
>    Reported-and-tested-by: Steven Newbury <steve@snewbury.org.uk>
>    Cc: <stable@vger.kernel.org> # v3.4+
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1590808b43559d8330599158453f28f1b16ffd54
>Author: Michael S. Tsirkin <mst@redhat.com>
>Date:   Sun Feb 28 16:31:39 2016 +0200
>
>    vfio: fix ioctl error handling
>    
>    [ Upstream commit 8160c4e455820d5008a1116d2dca35f0363bb062 ]
>    
>    Calling return copy_to_user(...) in an ioctl will not
>    do the right thing if there's a pagefault:
>    copy_to_user returns the number of bytes not copied
>    in this case.
>    
>    Fix up vfio to do
>    	return copy_to_user(...)) ?
>    		-EFAULT : 0;
>    
>    everywhere.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9b77cd137fd841d7a14e1c9428cfc49f4df0306e
>Author: Al Viro <viro@zeniv.linux.org.uk>
>Date:   Sat Feb 27 19:23:16 2016 -0500
>
>    namei: ->d_inode of a pinned dentry is stable only for positives
>    
>    [ Upstream commit d4565649b6d6923369112758212b851adc407f0c ]
>    
>    both do_last() and walk_component() risk picking a NULL inode out
>    of dentry about to become positive, *then* checking its flags and
>    seeing that it's not negative anymore and using (already stale by
>    then) value they'd fetched earlier.  Usually ends up oopsing soon
>    after that...
>    
>    Cc: stable@vger.kernel.org # v3.13+
>    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3960cde3e356057bd60adce1b625a7d178b9581c
>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
>    
>    [ Upstream commit c80567c82ae4814a41287618e315a60ecf513be6 ]
>    
>    ... 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.
>    
>    Cc: stable@vger.kernel.org # v3.6+, at least
>    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6cb69cb2840d3c18a469d6c42dbdb060bdf2bb04
>Author: Mikulas Patocka <mikulas@twibright.com>
>Date:   Thu Feb 25 18:17:38 2016 +0100
>
>    hpfs: don't truncate the file when delete fails
>    
>    [ Upstream commit b6853f78e763d42c7a158d8de3549c9827c604ab ]
>    
>    The delete opration can allocate additional space on the HPFS filesystem
>    due to btree split. The HPFS driver checks in advance if there is
>    available space, so that it won't corrupt the btree if we run out of space
>    during splitting.
>    
>    If there is not enough available space, the HPFS driver attempted to
>    truncate the file, but this results in a deadlock since the commit
>    7dd29d8d865efdb00c0542a5d2c87af8c52ea6c7 ("HPFS: Introduce a global mutex
>    and lock it on every callback from VFS").
>    
>    This patch removes the code that tries to truncate the file and -ENOSPC is
>    returned instead. If the user hits -ENOSPC on delete, he should try to
>    delete other files (that are stored in a leaf btree node), so that the
>    delete operation will make some space for deleting the file stored in
>    non-leaf btree node.
>    
>    Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
>    Signed-off-by: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
>    Cc: stable@vger.kernel.org	# 2.6.39+
>    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 419ddc3099727a291a67d41498c3d1caddb75392
>Author: Mel Gorman <mgorman@techsingularity.net>
>Date:   Fri Feb 26 15:19:31 2016 -0800
>
>    mm: numa: quickly fail allocations for NUMA balancing on full nodes
>    
>    [ Upstream commit 8479eba7781fa9ffb28268840de6facfc12c35a7 ]
>    
>    Commit 4167e9b2cf10 ("mm: remove GFP_THISNODE") removed the GFP_THISNODE
>    flag combination due to confusing semantics.  It noted that
>    alloc_misplaced_dst_page() was one such user after changes made by
>    commit e97ca8e5b864 ("mm: fix GFP_THISNODE callers and clarify").
>    
>    Unfortunately when GFP_THISNODE was removed, users of
>    alloc_misplaced_dst_page() started waking kswapd and entering direct
>    reclaim because the wrong GFP flags are cleared.  The consequence is
>    that workloads that used to fit into memory now get reclaimed which is
>    addressed by this patch.
>    
>    The problem can be demonstrated with "mutilate" that exercises memcached
>    which is software dedicated to memory object caching.  The configuration
>    uses 80% of memory and is run 3 times for varying numbers of clients.
>    The results on a 4-socket NUMA box are
>    
>    mutilate
>                                4.4.0                 4.4.0
>                              vanilla           numaswap-v1
>    Hmean    1      8394.71 (  0.00%)     8395.32 (  0.01%)
>    Hmean    4     30024.62 (  0.00%)    34513.54 ( 14.95%)
>    Hmean    7     32821.08 (  0.00%)    70542.96 (114.93%)
>    Hmean    12    55229.67 (  0.00%)    93866.34 ( 69.96%)
>    Hmean    21    39438.96 (  0.00%)    85749.21 (117.42%)
>    Hmean    30    37796.10 (  0.00%)    50231.49 ( 32.90%)
>    Hmean    47    18070.91 (  0.00%)    38530.13 (113.22%)
>    
>    The metric is queries/second with the more the better.  The results are
>    way outside of the noise and the reason for the improvement is obvious
>    from some of the vmstats
>    
>                                     4.4.0       4.4.0
>                                   vanillanumaswap-v1r1
>    Minor Faults                1929399272  2146148218
>    Major Faults                  19746529        3567
>    Swap Ins                      57307366        9913
>    Swap Outs                     50623229       17094
>    Allocation stalls                35909         443
>    DMA allocs                           0           0
>    DMA32 allocs                  72976349   170567396
>    Normal allocs               5306640898  5310651252
>    Movable allocs                       0           0
>    Direct pages scanned         404130893      799577
>    Kswapd pages scanned         160230174           0
>    Kswapd pages reclaimed        55928786           0
>    Direct pages reclaimed         1843936       41921
>    Page writes file                  2391           0
>    Page writes anon              50623229       17094
>    
>    The vanilla kernel is swapping like crazy with large amounts of direct
>    reclaim and kswapd activity.  The figures are aggregate but it's known
>    that the bad activity is throughout the entire test.
>    
>    Note that simple streaming anon/file memory consumers also see this
>    problem but it's not as obvious.  In those cases, kswapd is awake when
>    it should not be.
>    
>    As there are at least two reclaim-related bugs out there, it's worth
>    spelling out the user-visible impact.  This patch only addresses bugs
>    related to excessive reclaim on NUMA hardware when the working set is
>    larger than a NUMA node.  There is a bug related to high kswapd CPU
>    usage but the reports are against laptops and other UMA hardware and is
>    not addressed by this patch.
>    
>    Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
>    Cc: Vlastimil Babka <vbabka@suse.cz>
>    Cc: Johannes Weiner <hannes@cmpxchg.org>
>    Cc: David Rientjes <rientjes@google.com>
>    Cc: <stable@vger.kernel.org>	[4.1+]
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d347d0e9ae617bd44ca7679786ebf11a06d50372
>Author: Andrea Arcangeli <aarcange@redhat.com>
>Date:   Fri Feb 26 15:19:28 2016 -0800
>
>    mm: thp: fix SMP race condition between THP page fault and MADV_DONTNEED
>    
>    [ Upstream commit ad33bb04b2a6cee6c1f99fabb15cddbf93ff0433 ]
>    
>    pmd_trans_unstable()/pmd_none_or_trans_huge_or_clear_bad() were
>    introduced to locklessy (but atomically) detect when a pmd is a regular
>    (stable) pmd or when the pmd is unstable and can infinitely transition
>    from pmd_none() and pmd_trans_huge() from under us, while only holding
>    the mmap_sem for reading (for writing not).
>    
>    While holding the mmap_sem only for reading, MADV_DONTNEED can run from
>    under us and so before we can assume the pmd to be a regular stable pmd
>    we need to compare it against pmd_none() and pmd_trans_huge() in an
>    atomic way, with pmd_trans_unstable().  The old pmd_trans_huge() left a
>    tiny window for a race.
>    
>    Useful applications are unlikely to notice the difference as doing
>    MADV_DONTNEED concurrently with a page fault would lead to undefined
>    behavior.
>    
>    [akpm@linux-foundation.org: tidy up comment grammar/layout]
>    Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
>    Reported-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit bb2b7d4ee6fc2c2dea54c12df9c0aea15e1a019c
>Author: Colin Ian King <colin.king@canonical.com>
>Date:   Fri Feb 26 18:55:31 2016 +0000
>
>    x86/mpx: Fix off-by-one comparison with nr_registers
>    
>    [ Upstream commit 9bf148cb0812595bfdf5100bd2c07e9bec9c6ef5 ]
>    
>    In the unlikely event that regno == nr_registers then we get an array
>    overrun on regoff because the invalid register check is currently
>    off-by-one. Fix this with a check that regno is >= nr_registers instead.
>    
>    Detected with static analysis using CoverityScan.
>    
>    Fixes: fcc7ffd67991 "x86, mpx: Decode MPX instruction to get bound violation information"
>    Signed-off-by: Colin Ian King <colin.king@canonical.com>
>    Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
>    Cc: Borislav Petkov <bp@alien8.de>
>    Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
>    Cc: stable@vger.kernel.org
>    Link: http://lkml.kernel.org/r/1456512931-3388-1-git-send-email-colin.king@canonical.com
>    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 18d609bb0b8c6823a750b32106be5685ca3daff7
>Author: Paolo Bonzini <pbonzini@redhat.com>
>Date:   Fri Feb 26 12:28:40 2016 +0100
>
>    KVM: x86: fix root cause for missed hardware breakpoints
>    
>    [ Upstream commit 70e4da7a8ff62f2775337b705f45c804bb450454 ]
>    
>    Commit 172b2386ed16 ("KVM: x86: fix missed hardware breakpoints",
>    2016-02-10) worked around a case where the debug registers are not loaded
>    correctly on preemption and on the first entry to KVM_RUN.
>    
>    However, Xiao Guangrong pointed out that the root cause must be that
>    KVM_DEBUGREG_BP_ENABLED is not being set correctly.  This can indeed
>    happen due to the lazy debug exit mechanism, which does not call
>    kvm_update_dr7.  Fix it by replacing the existing loop (more or less
>    equivalent to kvm_update_dr0123) with calls to all the kvm_update_dr*
>    functions.
>    
>    Cc: stable@vger.kernel.org   # 4.1+
>    Fixes: 172b2386ed16a9143d9a456aae5ec87275c61489
>    Reviewed-by: Xiao Guangrong <guangrong.xiao@linux.intel.com>
>    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d017f850a3b6f84e6d847c6cbb01eaf6ce61f4f6
>Author: Harvey Hunt <harvey.hunt@imgtec.com>
>Date:   Wed Feb 24 15:16:43 2016 +0000
>
>    libata: Align ata_device's id on a cacheline
>    
>    [ Upstream commit 4ee34ea3a12396f35b26d90a094c75db95080baa ]
>    
>    The id buffer in ata_device is a DMA target, but it isn't explicitly
>    cacheline aligned. Due to this, adjacent fields can be overwritten with
>    stale data from memory on non coherent architectures. As a result, the
>    kernel is sometimes unable to communicate with an ATA device.
>    
>    Fix this by ensuring that the id buffer is cacheline aligned.
>    
>    This issue is similar to that fixed by Commit 84bda12af31f
>    ("libata: align ap->sector_buf").
>    
>    Signed-off-by: Harvey Hunt <harvey.hunt@imgtec.com>
>    Cc: linux-kernel@vger.kernel.org
>    Cc: <stable@vger.kernel.org> # 2.6.18
>    Signed-off-by: Tejun Heo <tj@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 15115bf3b764c4f2b36ea202f45181fd18d4a574
>Author: Jay Cornwall <jay@jcornwall.me>
>Date:   Wed Feb 10 15:48:01 2016 -0600
>
>    iommu/amd: Apply workaround for ATS write permission check
>    
>    [ Upstream commit 358875fd52ab8f00f66328cbf1a1d2486f265829 ]
>    
>    The AMD Family 15h Models 30h-3Fh (Kaveri) BIOS and Kernel Developer's
>    Guide omitted part of the BIOS IOMMU L2 register setup specification.
>    Without this setup the IOMMU L2 does not fully respect write permissions
>    when handling an ATS translation request.
>    
>    The IOMMU L2 will set PTE dirty bit when handling an ATS translation with
>    write permission request, even when PTE RW bit is clear. This may occur by
>    direct translation (which would cause a PPR) or by prefetch request from
>    the ATC.
>    
>    This is observed in practice when the IOMMU L2 modifies a PTE which maps a
>    pagecache page. The ext4 filesystem driver BUGs when asked to writeback
>    these (non-modified) pages.
>    
>    Enable ATS write permission check in the Kaveri IOMMU L2 if BIOS has not.
>    
>    Signed-off-by: Jay Cornwall <jay@jcornwall.me>
>    Cc: <stable@vger.kernel.org> # v3.19+
>    Signed-off-by: Joerg Roedel <jroedel@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 91d212c02743084892b687fb5cf166fffc01d0f9
>Author: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
>Date:   Tue Feb 23 13:03:30 2016 +0100
>
>    iommu/amd: Fix boot warning when device 00:00.0 is not iommu covered
>    
>    [ Upstream commit 38e45d02ea9f194b89d6bf41e52ccafc8e2c2b47 ]
>    
>    The setup code for the performance counters in the AMD IOMMU driver
>    tests whether the counters can be written. It tests to setup a counter
>    for device 00:00.0, which fails on systems where this particular device
>    is not covered by the IOMMU.
>    
>    Fix this by not relying on device 00:00.0 but only on the IOMMU being
>    present.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
>    Signed-off-by: Joerg Roedel <jroedel@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 715b09c999aeb1c6e48a1d10b93443d4cdbab01b
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Thu Feb 25 14:31:59 2016 +0100
>
>    ALSA: hda - Fix headset support and noise on HP EliteBook 755 G2
>    
>    [ Upstream commit f883982dc1b117f04579f0896821cd9f2e397f94 ]
>    
>    HP EliteBook 755 G2 with ALC3228 (ALC280) codec [103c:221c] requires
>    the known fixup (ALC269_FIXUP_HEADSET_MIC) for making the headset mic
>    working.  Also, it suffers from the loopback noise problem, so we
>    should disable aamix path as well.
>    
>    Reported-by: Derick Eddington <derick.eddington@gmail.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit fdd575639f6beb61e90be54fcdd14dd9f9b9627f
>Author: David Henningsson <david.henningsson@canonical.com>
>Date:   Thu Feb 25 09:37:05 2016 +0100
>
>    ALSA: hda - Fixup speaker pass-through control for nid 0x14 on ALC225
>    
>    [ Upstream commit 2ae955774f29bbd7d16149cb0ae8d0319bf2ecc4 ]
>    
>    On one of the machines we enable, we found that the actual speaker volume
>    did not always correspond to the volume set in alsamixer. This patch
>    fixes that problem.
>    
>    This patch was orginally written by Kailang @ Realtek, I've rebased it
>    to fit sound git master.
>    
>    Cc: stable@vger.kernel.org
>    BugLink: https://bugs.launchpad.net/bugs/1549660
>    Co-Authored-By: Kailang <kailang@realtek.com>
>    Signed-off-by: David Henningsson <david.henningsson@canonical.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b3c3bdf0959ee2c27305d70bc737da8d5153cdfc
>Author: Kailang Yang <kailang@realtek.com>
>Date:   Wed Feb 3 15:20:39 2016 +0800
>
>    ALSA: hda/realtek - Support Dell headset mode for ALC225
>    
>    [ Upstream commit cfc5a845e62853edd36e564c23c64588f4adcae6 ]
>    
>    Dell create new platform with ALC298 codec.
>    This patch will enable headset mode for ALC225/ALC3253 platform.
>    
>    Signed-off-by: Kailang Yang <kailang@realtek.com>
>    Cc: <stable@vger.kernel.org> # v4.4+
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 49f76896f87b49592781f09d6e6c3f868051a6d7
>Author: David Woodhouse <David.Woodhouse@intel.com>
>Date:   Mon Feb 1 14:04:46 2016 +0000
>
>    Fix directory hardlinks from deleted directories
>    
>    [ Upstream commit be629c62a603e5935f8177fd8a19e014100a259e ]
>    
>    When a directory is deleted, we don't take too much care about killing off
>    all the dirents that belong to it â on the basis that on remount, the scan
>    will conclude that the directory is dead anyway.
>    
>    This doesn't work though, when the deleted directory contained a child
>    directory which was moved *out*. In the early stages of the fs build
>    we can then end up with an apparent hard link, with the child directory
>    appearing both in its true location, and as a child of the original
>    directory which are this stage of the mount process we don't *yet* know
>    is defunct.
>    
>    To resolve this, take out the early special-casing of the "directories
>    shall not have hard links" rule in jffs2_build_inode_pass1(), and let the
>    normal nlink processing happen for directories as well as other inodes.
>    
>    Then later in the build process we can set ic->pino_nlink to the parent
>    inode#, as is required for directories during normal operaton, instead
>    of the nlink. And complain only *then* about hard links which are still
>    in evidence even after killing off all the unreachable paths.
>    
>    Reported-by: Liu Song <liu.song11@zte.com.cn>
>    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e0dae728bf0878ad831440ff5d2e90ec10b794a4
>Author: David Woodhouse <David.Woodhouse@intel.com>
>Date:   Mon Feb 1 12:37:20 2016 +0000
>
>    jffs2: Fix page lock / f->sem deadlock
>    
>    [ Upstream commit 49e91e7079febe59a20ca885a87dd1c54240d0f1 ]
>    
>    With this fix, all code paths should now be obtaining the page lock before
>    f->sem.
>    
>    Reported-by: SzabÃ³ TamÃ¡s <sztomi89@gmail.com>
>    Tested-by: Thomas Betker <thomas.betker@rohde-schwarz.com>
>    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 74d11976ff45dfe15b8a965d72237ac98533f788
>Author: Thomas Betker <thomas.betker@rohde-schwarz.com>
>Date:   Tue Nov 10 22:18:15 2015 +0100
>
>    Revert "jffs2: Fix lock acquisition order bug in jffs2_write_begin"
>    
>    [ Upstream commit 157078f64b8a9cd7011b6b900b2f2498df850748 ]
>    
>    This reverts commit 5ffd3412ae55
>    ("jffs2: Fix lock acquisition order bug in jffs2_write_begin").
>    
>    The commit modified jffs2_write_begin() to remove a deadlock with
>    jffs2_garbage_collect_live(), but this introduced new deadlocks found
>    by multiple users. page_lock() actually has to be called before
>    mutex_lock(&c->alloc_sem) or mutex_lock(&f->sem) because
>    jffs2_write_end() and jffs2_readpage() are called with the page locked,
>    and they acquire c->alloc_sem and f->sem, resp.
>    
>    In other words, the lock order in jffs2_write_begin() was correct, and
>    it is the jffs2_garbage_collect_live() path that has to be changed.
>    
>    Revert the commit to get rid of the new deadlocks, and to clear the way
>    for a better fix of the original deadlock.
>    
>    Reported-by: Deng Chao <deng.chao1@zte.com.cn>
>    Reported-by: Ming Liu <liu.ming50@gmail.com>
>    Reported-by: wangzaiwei <wangzaiwei@top-vision.cn>
>    Signed-off-by: Thomas Betker <thomas.betker@rohde-schwarz.com>
>    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 79e6eddd93bc3dfa020a57886d666dea9b9f452e
>Author: Mike Krinkin <krinkin.m.u@gmail.com>
>Date:   Wed Feb 24 21:02:31 2016 +0300
>
>    KVM: x86: MMU: fix ubsan index-out-of-range warning
>    
>    [ Upstream commit 17e4bce0ae63c7e03f3c7fa8d80890e7af3d4971 ]
>    
>    Ubsan reports the following warning due to a typo in
>    update_accessed_dirty_bits template, the patch fixes
>    the typo:
>    
>    [  168.791851] ================================================================================
>    [  168.791862] UBSAN: Undefined behaviour in arch/x86/kvm/paging_tmpl.h:252:15
>    [  168.791866] index 4 is out of range for type 'u64 [4]'
>    [  168.791871] CPU: 0 PID: 2950 Comm: qemu-system-x86 Tainted: G           O L  4.5.0-rc5-next-20160222 #7
>    [  168.791873] Hardware name: LENOVO 23205NG/23205NG, BIOS G2ET95WW (2.55 ) 07/09/2013
>    [  168.791876]  0000000000000000 ffff8801cfcaf208 ffffffff81c9f780 0000000041b58ab3
>    [  168.791882]  ffffffff82eb2cc1 ffffffff81c9f6b4 ffff8801cfcaf230 ffff8801cfcaf1e0
>    [  168.791886]  0000000000000004 0000000000000001 0000000000000000 ffffffffa1981600
>    [  168.791891] Call Trace:
>    [  168.791899]  [<ffffffff81c9f780>] dump_stack+0xcc/0x12c
>    [  168.791904]  [<ffffffff81c9f6b4>] ? _atomic_dec_and_lock+0xc4/0xc4
>    [  168.791910]  [<ffffffff81da9e81>] ubsan_epilogue+0xd/0x8a
>    [  168.791914]  [<ffffffff81daafa2>] __ubsan_handle_out_of_bounds+0x15c/0x1a3
>    [  168.791918]  [<ffffffff81daae46>] ? __ubsan_handle_shift_out_of_bounds+0x2bd/0x2bd
>    [  168.791922]  [<ffffffff811287ef>] ? get_user_pages_fast+0x2bf/0x360
>    [  168.791954]  [<ffffffffa1794050>] ? kvm_largepages_enabled+0x30/0x30 [kvm]
>    [  168.791958]  [<ffffffff81128530>] ? __get_user_pages_fast+0x360/0x360
>    [  168.791987]  [<ffffffffa181b818>] paging64_walk_addr_generic+0x1b28/0x2600 [kvm]
>    [  168.792014]  [<ffffffffa1819cf0>] ? init_kvm_mmu+0x1100/0x1100 [kvm]
>    [  168.792019]  [<ffffffff8129e350>] ? debug_check_no_locks_freed+0x350/0x350
>    [  168.792044]  [<ffffffffa1819cf0>] ? init_kvm_mmu+0x1100/0x1100 [kvm]
>    [  168.792076]  [<ffffffffa181c36d>] paging64_gva_to_gpa+0x7d/0x110 [kvm]
>    [  168.792121]  [<ffffffffa181c2f0>] ? paging64_walk_addr_generic+0x2600/0x2600 [kvm]
>    [  168.792130]  [<ffffffff812e848b>] ? debug_lockdep_rcu_enabled+0x7b/0x90
>    [  168.792178]  [<ffffffffa17d9a4a>] emulator_read_write_onepage+0x27a/0x1150 [kvm]
>    [  168.792208]  [<ffffffffa1794d44>] ? __kvm_read_guest_page+0x54/0x70 [kvm]
>    [  168.792234]  [<ffffffffa17d97d0>] ? kvm_task_switch+0x160/0x160 [kvm]
>    [  168.792238]  [<ffffffff812e848b>] ? debug_lockdep_rcu_enabled+0x7b/0x90
>    [  168.792263]  [<ffffffffa17daa07>] emulator_read_write+0xe7/0x6d0 [kvm]
>    [  168.792290]  [<ffffffffa183b620>] ? em_cr_write+0x230/0x230 [kvm]
>    [  168.792314]  [<ffffffffa17db005>] emulator_write_emulated+0x15/0x20 [kvm]
>    [  168.792340]  [<ffffffffa18465f8>] segmented_write+0xf8/0x130 [kvm]
>    [  168.792367]  [<ffffffffa1846500>] ? em_lgdt+0x20/0x20 [kvm]
>    [  168.792374]  [<ffffffffa14db512>] ? vmx_read_guest_seg_ar+0x42/0x1e0 [kvm_intel]
>    [  168.792400]  [<ffffffffa1846d82>] writeback+0x3f2/0x700 [kvm]
>    [  168.792424]  [<ffffffffa1846990>] ? em_sidt+0xa0/0xa0 [kvm]
>    [  168.792449]  [<ffffffffa185554d>] ? x86_decode_insn+0x1b3d/0x4f70 [kvm]
>    [  168.792474]  [<ffffffffa1859032>] x86_emulate_insn+0x572/0x3010 [kvm]
>    [  168.792499]  [<ffffffffa17e71dd>] x86_emulate_instruction+0x3bd/0x2110 [kvm]
>    [  168.792524]  [<ffffffffa17e6e20>] ? reexecute_instruction.part.110+0x2e0/0x2e0 [kvm]
>    [  168.792532]  [<ffffffffa14e9a81>] handle_ept_misconfig+0x61/0x460 [kvm_intel]
>    [  168.792539]  [<ffffffffa14e9a20>] ? handle_pause+0x450/0x450 [kvm_intel]
>    [  168.792546]  [<ffffffffa15130ea>] vmx_handle_exit+0xd6a/0x1ad0 [kvm_intel]
>    [  168.792572]  [<ffffffffa17f6a6c>] ? kvm_arch_vcpu_ioctl_run+0xbdc/0x6090 [kvm]
>    [  168.792597]  [<ffffffffa17f6bcd>] kvm_arch_vcpu_ioctl_run+0xd3d/0x6090 [kvm]
>    [  168.792621]  [<ffffffffa17f6a6c>] ? kvm_arch_vcpu_ioctl_run+0xbdc/0x6090 [kvm]
>    [  168.792627]  [<ffffffff8293b530>] ? __ww_mutex_lock_interruptible+0x1630/0x1630
>    [  168.792651]  [<ffffffffa17f5e90>] ? kvm_arch_vcpu_runnable+0x4f0/0x4f0 [kvm]
>    [  168.792656]  [<ffffffff811eeb30>] ? preempt_notifier_unregister+0x190/0x190
>    [  168.792681]  [<ffffffffa17e0447>] ? kvm_arch_vcpu_load+0x127/0x650 [kvm]
>    [  168.792704]  [<ffffffffa178e9a3>] kvm_vcpu_ioctl+0x553/0xda0 [kvm]
>    [  168.792727]  [<ffffffffa178e450>] ? vcpu_put+0x40/0x40 [kvm]
>    [  168.792732]  [<ffffffff8129e350>] ? debug_check_no_locks_freed+0x350/0x350
>    [  168.792735]  [<ffffffff82946087>] ? _raw_spin_unlock+0x27/0x40
>    [  168.792740]  [<ffffffff8163a943>] ? handle_mm_fault+0x1673/0x2e40
>    [  168.792744]  [<ffffffff8129daa8>] ? trace_hardirqs_on_caller+0x478/0x6c0
>    [  168.792747]  [<ffffffff8129dcfd>] ? trace_hardirqs_on+0xd/0x10
>    [  168.792751]  [<ffffffff812e848b>] ? debug_lockdep_rcu_enabled+0x7b/0x90
>    [  168.792756]  [<ffffffff81725a80>] do_vfs_ioctl+0x1b0/0x12b0
>    [  168.792759]  [<ffffffff817258d0>] ? ioctl_preallocate+0x210/0x210
>    [  168.792763]  [<ffffffff8174aef3>] ? __fget+0x273/0x4a0
>    [  168.792766]  [<ffffffff8174acd0>] ? __fget+0x50/0x4a0
>    [  168.792770]  [<ffffffff8174b1f6>] ? __fget_light+0x96/0x2b0
>    [  168.792773]  [<ffffffff81726bf9>] SyS_ioctl+0x79/0x90
>    [  168.792777]  [<ffffffff82946880>] entry_SYSCALL_64_fastpath+0x23/0xc1
>    [  168.792780] ================================================================================
>    
>    Signed-off-by: Mike Krinkin <krinkin.m.u@gmail.com>
>    Reviewed-by: Xiao Guangrong <guangrong.xiao@linux.intel.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4c3192278b461a23930dd39eaaa683898c1d0009
>Author: Kai-Heng Feng <kaihengfeng@gmail.com>
>Date:   Thu Feb 25 15:19:38 2016 +0800
>
>    ALSA: hda - Fixing background noise on Dell Inspiron 3162
>    
>    [ Upstream commit 7cb32ae09a6490c27bc3c110ee42d808a5670142 ]
>    
>    commit 3b43b71f05d3ecd01c4116254666d9492301697d upstream.
>    
>    After login to the desktop on Dell Inspiron 3162,
>    there's a very loud background noise comes from the builtin speaker.
>    The noise does not go away even if the speaker is muted.
>    
>    The noise disappears after using the aamix fixup.
>    
>    Codec: Realtek ALC3234
>    Address: 0
>    AFG Function Id: 0x1 (unsol 1)
>        Vendor Id: 0x10ec0255
>        Subsystem Id: 0x10280725
>        Revision Id: 0x100002
>        No Modem Function Group found
>    
>    BugLink: http://bugs.launchpad.net/bugs/1549620
>    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 42929fe6d85ae5a3916f79d5c70792fb35d48603
>Author: Kailang <kailang@realtek.com>
>Date:   Mon Dec 28 11:35:24 2015 +0800
>
>    ALSA: hda - Add mic mute hotkey quirk for Lenovo ThinkCentre AIO
>    
>    [ Upstream commit 3694cb2947db50753caf432db067487eafae7b9b ]
>    
>    The Lenovo ThinkCenter AIO uses Line2 (NID 0x1b) to implement the
>    micmute hotkey, here we register an input device and use Line2 unsol
>    event to collect the hotkey pressing or releasing.
>    
>    In the meanwhile, the micmute led is controlled by GPIO2, so we
>    use an existing function alc_fixup_gpio_mic_mute_hook() to control
>    the led.
>    
>    [Hui: And there are two places to register the input device, to make
>    the code simple and clean, move the two same code sections into a
>    function.]
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Kailang <kailang@realtek.com>
>    Signed-off-by: Hui Wang <hui.wang@canonical.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 559e8bf80c9676b40f1ddcb7a90e1eaa2f3c6a2a
>Author: Hui Wang <hui.wang@canonical.com>
>Date:   Tue Dec 8 12:27:18 2015 +0800
>
>    ALSA: hda - Fixing speaker noise on the two latest thinkpad models
>    
>    [ Upstream commit 23adc192b862b69ad80a40bd5206e337f41264ac ]
>    
>    We have two latest thinkpad laptop models which are all based on the
>    Intel skylake platforms, and all of them have the codec alc293 on
>    them. When the machines boot to the desktop, an greeting dialogue
>    shows up with the notification sound. But on these two models, there
>    is noise with the notification sound. We have 3 SKUs for each of
>    the models, all of them have this problem.
>    
>    So far, this problem is only specific to these two thinkpad models,
>    we did not find this problem on the old thinkpad models with the
>    codec alc293 or alc292.
>    
>    A workaround for this problem is disabling the aamix.
>    
>    Cc: stable@vger.kernel.org
>    BugLink: https://bugs.launchpad.net/bugs/1523517
>    Signed-off-by: Hui Wang <hui.wang@canonical.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4c440d72709998411c30c9bf6e503980bd655dc3
>Author: Hui Wang <hui.wang@canonical.com>
>Date:   Tue Nov 24 11:08:18 2015 +0800
>
>    ALSA: hda - Fix headphone noise after Dell XPS 13 resume back from S3
>    
>    [ Upstream commit 8c69729b4439bbda88c3073df7243f755cc418ed ]
>    
>    We have a machine Dell XPS 13 with the codec alc256, after resume back
>    from S3, the headphone has noise when play sound.
>    
>    Through comparing with the coeff vaule before and after S3, we found
>    restoring a coeff register will help remove noise.
>    
>    BugLink: https://bugs.launchpad.net/bugs/1519168
>    Cc: Kailang Yang <kailang@realtek.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Hui Wang <hui.wang@canonical.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5352c4b683d846849860a8235ee0a2eaf34147d6
>Author: Kailang Yang <kailang@realtek.com>
>Date:   Mon Oct 26 15:37:39 2015 +0800
>
>    ALSA: hda/realtek - Dell XPS one ALC3260 speaker no sound after resume back
>    
>    [ Upstream commit 6ed1131fe196ad7ffc13acc1a1eadc08a1db0303 ]
>    
>    This machine had I2S codec for speaker output.
>    It need to refill the I2S codec initial verb after resume back.
>    
>    Signed-off-by: Kailang Yang <kailang@realtek.com>
>    Reported-and-tested-by: George Gugulea <gugulea@gmail.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0f1b871592766fbadf7074a414d602fd7be5570a
>Author: Kailang Yang <kailang@realtek.com>
>Date:   Mon May 18 15:31:20 2015 +0800
>
>    ALSA: hda/realtek - Support Dell headset mode for ALC298
>    
>    [ Upstream commit 977e627684df0f60bdf2a768ec4772f42fe843fc ]
>    
>    Dell create new platform with ALC298 codec.
>    This patch will enable headset mode for ALC298/ALC3266 platform.
>    
>    Signed-off-by: Kailang Yang <kailang@realtek.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 49670184289e48451171179470a7dbbdb63f9549
>Author: Peter Chen <peter.chen@nxp.com>
>Date:   Wed Feb 24 11:05:25 2016 +0800
>
>    usb: chipidea: otg: change workqueue ci_otg as freezable
>    
>    [ Upstream commit d144dfea8af7108f613139623e63952ed7e69c0c ]
>    
>    If we use USB ID pin as wakeup source, and there is a USB block
>    device on this USB OTG (ID) cable, the system will be deadlock
>    after system resume.
>    
>    The root cause for this problem is: the workqueue ci_otg may try
>    to remove hcd before the driver resume has finished, and hcd will
>    disconnect the device on it, then, it will call device_release_driver,
>    and holds the device lock "dev->mutex", but it is never unlocked since
>    it waits workqueue writeback to run to flush the block information, but
>    the workqueue writeback is freezable, it is not thawed before driver
>    resume has finished.
>    
>    When the driver (device: sd 0:0:0:0:) resume goes to dpm_complete, it
>    tries to get its device lock "dev->mutex", but it can't get it forever,
>    then the deadlock occurs. Below call stacks show the situation.
>    
>    So, in order to fix this problem, we need to change workqueue ci_otg
>    as freezable, then the work item in this workqueue will be run after
>    driver's resume, this workqueue will not be blocked forever like above
>    case since the workqueue writeback has been thawed too.
>    
>    Tested at: i.mx6qdl-sabresd and i.mx6sx-sdb.
>    
>    [  555.178869] kworker/u2:13   D c07de74c     0   826      2 0x00000000
>    [  555.185310] Workqueue: ci_otg ci_otg_work
>    [  555.189353] Backtrace:
>    [  555.191849] [<c07de4fc>] (__schedule) from [<c07dec6c>] (schedule+0x48/0xa0)
>    [  555.198912]  r10:ee471ba0 r9:00000000 r8:00000000 r7:00000002 r6:ee470000 r5:ee471ba4
>    [  555.206867]  r4:ee470000
>    [  555.209453] [<c07dec24>] (schedule) from [<c07e2fc4>] (schedule_timeout+0x15c/0x1e0)
>    [  555.217212]  r4:7fffffff r3:edc2b000
>    [  555.220862] [<c07e2e68>] (schedule_timeout) from [<c07df6c8>] (wait_for_common+0x94/0x144)
>    [  555.229140]  r8:00000000 r7:00000002 r6:ee470000 r5:ee471ba4 r4:7fffffff
>    [  555.235980] [<c07df634>] (wait_for_common) from [<c07df790>] (wait_for_completion+0x18/0x1c)
>    [  555.244430]  r10:00000001 r9:c0b5563c r8:c0042e48 r7:ef086000 r6:eea4372c r5:ef131b00
>    [  555.252383]  r4:00000000
>    [  555.254970] [<c07df778>] (wait_for_completion) from [<c0043cb8>] (flush_work+0x19c/0x234)
>    [  555.263177] [<c0043b1c>] (flush_work) from [<c0043fac>] (flush_delayed_work+0x48/0x4c)
>    [  555.271106]  r8:ed5b5000 r7:c0b38a3c r6:eea439cc r5:eea4372c r4:eea4372c
>    [  555.277958] [<c0043f64>] (flush_delayed_work) from [<c00eae18>] (bdi_unregister+0x84/0xec)
>    [  555.286236]  r4:eea43520 r3:20000153
>    [  555.289885] [<c00ead94>] (bdi_unregister) from [<c02c2154>] (blk_cleanup_queue+0x180/0x29c)
>    [  555.298250]  r5:eea43808 r4:eea43400
>    [  555.301909] [<c02c1fd4>] (blk_cleanup_queue) from [<c0417914>] (__scsi_remove_device+0x48/0xb8)
>    [  555.310623]  r7:00000000 r6:20000153 r5:ededa950 r4:ededa800
>    [  555.316403] [<c04178cc>] (__scsi_remove_device) from [<c0415e90>] (scsi_forget_host+0x64/0x68)
>    [  555.325028]  r5:ededa800 r4:ed5b5000
>    [  555.328689] [<c0415e2c>] (scsi_forget_host) from [<c0409828>] (scsi_remove_host+0x78/0x104)
>    [  555.337054]  r5:ed5b5068 r4:ed5b5000
>    [  555.340709] [<c04097b0>] (scsi_remove_host) from [<c04cdfcc>] (usb_stor_disconnect+0x50/0xb4)
>    [  555.349247]  r6:ed5b56e4 r5:ed5b5818 r4:ed5b5690 r3:00000008
>    [  555.355025] [<c04cdf7c>] (usb_stor_disconnect) from [<c04b3bc8>] (usb_unbind_interface+0x78/0x25c)
>    [  555.363997]  r8:c13919b4 r7:edd3c000 r6:edd3c020 r5:ee551c68 r4:ee551c00 r3:c04cdf7c
>    [  555.371892] [<c04b3b50>] (usb_unbind_interface) from [<c03dc248>] (__device_release_driver+0x8c/0x118)
>    [  555.381213]  r10:00000001 r9:edd90c00 r8:c13919b4 r7:ee551c68 r6:c0b546e0 r5:c0b5563c
>    [  555.389167]  r4:edd3c020
>    [  555.391752] [<c03dc1bc>] (__device_release_driver) from [<c03dc2fc>] (device_release_driver+0x28/0x34)
>    [  555.401071]  r5:edd3c020 r4:edd3c054
>    [  555.404721] [<c03dc2d4>] (device_release_driver) from [<c03db304>] (bus_remove_device+0xe0/0x110)
>    [  555.413607]  r5:edd3c020 r4:ef17f04c
>    [  555.417253] [<c03db224>] (bus_remove_device) from [<c03d8128>] (device_del+0x114/0x21c)
>    [  555.425270]  r6:edd3c028 r5:edd3c020 r4:ee551c00 r3:00000000
>    [  555.431045] [<c03d8014>] (device_del) from [<c04b1560>] (usb_disable_device+0xa4/0x1e8)
>    [  555.439061]  r8:edd3c000 r7:eded8000 r6:00000000 r5:00000001 r4:ee551c00
>    [  555.445906] [<c04b14bc>] (usb_disable_device) from [<c04a8e54>] (usb_disconnect+0x74/0x224)
>    [  555.454271]  r9:edd90c00 r8:ee551000 r7:ee551c68 r6:ee551c9c r5:ee551c00 r4:00000001
>    [  555.462156] [<c04a8de0>] (usb_disconnect) from [<c04a8fb8>] (usb_disconnect+0x1d8/0x224)
>    [  555.470259]  r10:00000001 r9:edd90000 r8:ee471e2c r7:ee551468 r6:ee55149c r5:ee551400
>    [  555.478213]  r4:00000001
>    [  555.480797] [<c04a8de0>] (usb_disconnect) from [<c04ae5ec>] (usb_remove_hcd+0xa0/0x1ac)
>    [  555.488813]  r10:00000001 r9:ee471eb0 r8:00000000 r7:ef3d9500 r6:eded810c r5:eded80b0
>    [  555.496765]  r4:eded8000
>    [  555.499351] [<c04ae54c>] (usb_remove_hcd) from [<c04d4158>] (host_stop+0x28/0x64)
>    [  555.506847]  r6:eeb50010 r5:eded8000 r4:eeb51010
>    [  555.511563] [<c04d4130>] (host_stop) from [<c04d09b8>] (ci_otg_work+0xc4/0x124)
>    [  555.518885]  r6:00000001 r5:eeb50010 r4:eeb502a0 r3:c04d4130
>    [  555.524665] [<c04d08f4>] (ci_otg_work) from [<c00454f0>] (process_one_work+0x194/0x420)
>    [  555.532682]  r6:ef086000 r5:eeb502a0 r4:edc44480
>    [  555.537393] [<c004535c>] (process_one_work) from [<c00457b0>] (worker_thread+0x34/0x514)
>    [  555.545496]  r10:edc44480 r9:ef086000 r8:c0b1a100 r7:ef086034 r6:00000088 r5:edc44498
>    [  555.553450]  r4:ef086000
>    [  555.556032] [<c004577c>] (worker_thread) from [<c004bab4>] (kthread+0xdc/0xf8)
>    [  555.563268]  r10:00000000 r9:00000000 r8:00000000 r7:c004577c r6:edc44480 r5:eddc15c0
>    [  555.571221]  r4:00000000
>    [  555.573804] [<c004b9d8>] (kthread) from [<c000fef0>] (ret_from_fork+0x14/0x24)
>    [  555.581040]  r7:00000000 r6:00000000 r5:c004b9d8 r4:eddc15c0
>    
>    [  553.429383] sh              D c07de74c     0   694    691 0x00000000
>    [  553.435801] Backtrace:
>    [  553.438295] [<c07de4fc>] (__schedule) from [<c07dec6c>] (schedule+0x48/0xa0)
>    [  553.445358]  r10:edd3c054 r9:edd3c078 r8:edddbd50 r7:edcbbc00 r6:c1377c34 r5:60000153
>    [  553.453313]  r4:eddda000
>    [  553.455896] [<c07dec24>] (schedule) from [<c07deff8>] (schedule_preempt_disabled+0x10/0x14)
>    [  553.464261]  r4:edd3c058 r3:0000000a
>    [  553.467910] [<c07defe8>] (schedule_preempt_disabled) from [<c07e0bbc>] (mutex_lock_nested+0x1a0/0x3e8)
>    [  553.477254] [<c07e0a1c>] (mutex_lock_nested) from [<c03e927c>] (dpm_complete+0xc0/0x1b0)
>    [  553.485358]  r10:00561408 r9:edd3c054 r8:c0b4863c r7:edddbd90 r6:c0b485d8 r5:edd3c020
>    [  553.493313]  r4:edd3c0d0
>    [  553.495896] [<c03e91bc>] (dpm_complete) from [<c03e9388>] (dpm_resume_end+0x1c/0x20)
>    [  553.503652]  r9:00000000 r8:c0b1a9d0 r7:c1334ec0 r6:c1334edc r5:00000003 r4:00000010
>    [  553.511544] [<c03e936c>] (dpm_resume_end) from [<c0079894>] (suspend_devices_and_enter+0x158/0x504)
>    [  553.520604]  r4:00000000 r3:c1334efc
>    [  553.524250] [<c007973c>] (suspend_devices_and_enter) from [<c0079e74>] (pm_suspend+0x234/0x2cc)
>    [  553.532961]  r10:00561408 r9:ed6b7300 r8:00000004 r7:c1334eec r6:00000000 r5:c1334ee8
>    [  553.540914]  r4:00000003
>    [  553.543493] [<c0079c40>] (pm_suspend) from [<c0078a6c>] (state_store+0x6c/0xc0)
>    
>    [  555.703684] 7 locks held by kworker/u2:13/826:
>    [  555.708140]  #0:  ("%s""ci_otg"){++++.+}, at: [<c0045484>] process_one_work+0x128/0x420
>    [  555.716277]  #1:  ((&ci->work)){+.+.+.}, at: [<c0045484>] process_one_work+0x128/0x420
>    [  555.724317]  #2:  (usb_bus_list_lock){+.+.+.}, at: [<c04ae5e4>] usb_remove_hcd+0x98/0x1ac
>    [  555.732626]  #3:  (&dev->mutex){......}, at: [<c04a8e28>] usb_disconnect+0x48/0x224
>    [  555.740403]  #4:  (&dev->mutex){......}, at: [<c04a8e28>] usb_disconnect+0x48/0x224
>    [  555.748179]  #5:  (&dev->mutex){......}, at: [<c03dc2f4>] device_release_driver+0x20/0x34
>    [  555.756487]  #6:  (&shost->scan_mutex){+.+.+.}, at: [<c04097d0>] scsi_remove_host+0x20/0x104
>    
>    Cc: <stable@vger.kernel.org> #v3.14+
>    Cc: Jun Li <jun.li@nxp.com>
>    Signed-off-by: Peter Chen <peter.chen@nxp.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 66333f910d64623fa9cc886c259d57e6d24863cd
>Author: Ilya Dryomov <idryomov@gmail.com>
>Date:   Fri Feb 19 11:38:57 2016 +0100
>
>    libceph: use the right footer size when skipping a message
>    
>    [ Upstream commit dbc0d3caff5b7591e0cf8e34ca686ca6f4479ee1 ]
>    
>    ceph_msg_footer is 21 bytes long, while ceph_msg_footer_old is only 13.
>    Don't skip too much when CEPH_FEATURE_MSG_AUTH isn't negotiated.
>    
>    Cc: stable@vger.kernel.org # 3.19+
>    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
>    Reviewed-by: Alex Elder <elder@linaro.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 265570c9977908479db74fd07b710ec5d5c96e12
>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
>    
>    [ Upstream commit e7a88e82fe380459b864e05b372638aeacb0f52d ]
>    
>    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.
>    
>    Cc: stable@vger.kernel.org # 3.10+
>    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: Sasha Levin <sasha.levin@oracle.com>
>
>commit 621a963c422618d1793d9245302766e87cdabb83
>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
>    
>    [ Upstream commit d045437a169f899dfb0f6f7ede24cc042543ced9 ]
>    
>    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"
>    Cc: stable@vger.kernel.org # 3.4+
>    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 56029ce94469d7e183e8241e214837ac92c8520b
>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
>    
>    [ Upstream commit d7444794a02ff655eda87e3cc54e86b940e7736f ]
>    
>    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
>    
>    Cc: stable@vger.kernel.org
>    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: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0ccb848f62b5c9077cdeb903e324ca635806f804
>Author: Paolo Bonzini <pbonzini@redhat.com>
>Date:   Wed Feb 10 17:50:23 2016 +0100
>
>    KVM: x86: fix missed hardware breakpoints
>    
>    [ Upstream commit 172b2386ed16a9143d9a456aae5ec87275c61489 ]
>    
>    Sometimes when setting a breakpoint a process doesn't stop on it.
>    This is because the debug registers are not loaded correctly on
>    VCPU load.
>    
>    The following simple reproducer from Oleg Nesterov tries using debug
>    registers in two threads.  To see the bug, run a 2-VCPU guest with
>    "taskset -c 0" and run "./bp 0 1" inside the guest.
>    
>        #include <unistd.h>
>        #include <signal.h>
>        #include <stdlib.h>
>        #include <stdio.h>
>        #include <sys/wait.h>
>        #include <sys/ptrace.h>
>        #include <sys/user.h>
>        #include <asm/debugreg.h>
>        #include <assert.h>
>    
>        #define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
>    
>        unsigned long encode_dr7(int drnum, int enable, unsigned int type, unsigned int len)
>        {
>            unsigned long dr7;
>    
>            dr7 = ((len | type) & 0xf)
>                << (DR_CONTROL_SHIFT + drnum * DR_CONTROL_SIZE);
>            if (enable)
>                dr7 |= (DR_GLOBAL_ENABLE << (drnum * DR_ENABLE_SIZE));
>    
>            return dr7;
>        }
>    
>        int write_dr(int pid, int dr, unsigned long val)
>        {
>            return ptrace(PTRACE_POKEUSER, pid,
>                    offsetof (struct user, u_debugreg[dr]),
>                    val);
>        }
>    
>        void set_bp(pid_t pid, void *addr)
>        {
>            unsigned long dr7;
>            assert(write_dr(pid, 0, (long)addr) == 0);
>            dr7 = encode_dr7(0, 1, DR_RW_EXECUTE, DR_LEN_1);
>            assert(write_dr(pid, 7, dr7) == 0);
>        }
>    
>        void *get_rip(int pid)
>        {
>            return (void*)ptrace(PTRACE_PEEKUSER, pid,
>                    offsetof(struct user, regs.rip), 0);
>        }
>    
>        void test(int nr)
>        {
>            void *bp_addr = &&label + nr, *bp_hit;
>            int pid;
>    
>            printf("test bp %d\n", nr);
>            assert(nr < 16); // see 16 asm nops below
>    
>            pid = fork();
>            if (!pid) {
>                assert(ptrace(PTRACE_TRACEME, 0,0,0) == 0);
>                kill(getpid(), SIGSTOP);
>                for (;;) {
>                    label: asm (
>                        "nop; nop; nop; nop;"
>                        "nop; nop; nop; nop;"
>                        "nop; nop; nop; nop;"
>                        "nop; nop; nop; nop;"
>                    );
>                }
>            }
>    
>            assert(pid == wait(NULL));
>            set_bp(pid, bp_addr);
>    
>            for (;;) {
>                assert(ptrace(PTRACE_CONT, pid, 0, 0) == 0);
>                assert(pid == wait(NULL));
>    
>                bp_hit = get_rip(pid);
>                if (bp_hit != bp_addr)
>                    fprintf(stderr, "ERR!! hit wrong bp %ld != %d\n",
>                        bp_hit - &&label, nr);
>            }
>        }
>    
>        int main(int argc, const char *argv[])
>        {
>            while (--argc) {
>                int nr = atoi(*++argv);
>                if (!fork())
>                    test(nr);
>            }
>    
>            while (wait(NULL) > 0)
>                ;
>            return 0;
>        }
>    
>    Cc: stable@vger.kernel.org
>    Suggested-by: Nadav Amit <namit@cs.technion.ac.il>
>    Reported-by: Andrey Wagin <avagin@gmail.com>
>    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b29de09dab6c486a7cecdf4741632fa48d903428
>Author: Mark Rutland <mark.rutland@arm.com>
>Date:   Tue Feb 16 14:47:31 2016 +0000
>
>    KVM: arm/arm64: vgic: Ensure bitmaps are long enough
>    
>    [ Upstream commit 236cf17c2502007a9d2dda3c39fb0d9a6bd03cc2 ]
>    
>    When we allocate bitmaps in vgic_vcpu_init_maps, we divide the number of
>    bits we need by 8 to figure out how many bytes to allocate. However,
>    bitmap elements are always accessed as unsigned longs, and if we didn't
>    happen to allocate a size such that size % sizeof(unsigned long) == 0,
>    bitmap accesses may go past the end of the allocation.
>    
>    When using KASAN (which does byte-granular access checks), this results
>    in a continuous stream of BUGs whenever these bitmaps are accessed:
>    
>    =============================================================================
>    BUG kmalloc-128 (Tainted: G    B          ): kasan: bad access detected
>    -----------------------------------------------------------------------------
>    
>    INFO: Allocated in vgic_init.part.25+0x55c/0x990 age=7493 cpu=3 pid=1730
>    INFO: Slab 0xffffffbde6d5da40 objects=16 used=15 fp=0xffffffc935769700 flags=0x4000000000000080
>    INFO: Object 0xffffffc935769500 @offset=1280 fp=0x          (null)
>    
>    Bytes b4 ffffffc9357694f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>    Object ffffffc935769500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>    Object ffffffc935769510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>    Object ffffffc935769520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>    Object ffffffc935769530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>    Object ffffffc935769540: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>    Object ffffffc935769550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>    Object ffffffc935769560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>    Object ffffffc935769570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>    Padding ffffffc9357695b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>    Padding ffffffc9357695c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>    Padding ffffffc9357695d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>    Padding ffffffc9357695e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>    Padding ffffffc9357695f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>    CPU: 3 PID: 1740 Comm: kvm-vcpu-0 Tainted: G    B           4.4.0+ #17
>    Hardware name: ARM Juno development board (r1) (DT)
>    Call trace:
>    [<ffffffc00008e770>] dump_backtrace+0x0/0x280
>    [<ffffffc00008ea04>] show_stack+0x14/0x20
>    [<ffffffc000726360>] dump_stack+0x100/0x188
>    [<ffffffc00030d324>] print_trailer+0xfc/0x168
>    [<ffffffc000312294>] object_err+0x3c/0x50
>    [<ffffffc0003140fc>] kasan_report_error+0x244/0x558
>    [<ffffffc000314548>] __asan_report_load8_noabort+0x48/0x50
>    [<ffffffc000745688>] __bitmap_or+0xc0/0xc8
>    [<ffffffc0000d9e44>] kvm_vgic_flush_hwstate+0x1bc/0x650
>    [<ffffffc0000c514c>] kvm_arch_vcpu_ioctl_run+0x2ec/0xa60
>    [<ffffffc0000b9a6c>] kvm_vcpu_ioctl+0x474/0xa68
>    [<ffffffc00036b7b0>] do_vfs_ioctl+0x5b8/0xcb0
>    [<ffffffc00036bf34>] SyS_ioctl+0x8c/0xa0
>    [<ffffffc000086cb0>] el0_svc_naked+0x24/0x28
>    Memory state around the buggy address:
>     ffffffc935769400: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>     ffffffc935769480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>    >ffffffc935769500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>                       ^
>     ffffffc935769580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>     ffffffc935769600: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc
>    ==================================================================
>    
>    Fix the issue by always allocating a multiple of sizeof(unsigned long),
>    as we do elsewhere in the vgic code.
>    
>    Fixes: c1bfb577a ("arm/arm64: KVM: vgic: switch to dynamic allocation")
>    Cc: stable@vger.kernel.org
>    Acked-by: Marc Zyngier <marc.zyngier@arm.com>
>    Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
>    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
>    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4ba9f8051f7fc263cc5915fd6c2ac6d9195418b4
>Author: Stefan Hajnoczi <stefanha@redhat.com>
>Date:   Thu Feb 18 18:55:54 2016 +0000
>
>    sunrpc/cache: fix off-by-one in qword_get()
>    
>    [ Upstream commit b7052cd7bcf3c1478796e93e3dff2b44c9e82943 ]
>    
>    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>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a7927a04ac273abc6e15ffe31120f95d1f49b023
>Author: Alex Deucher <alexander.deucher@amd.com>
>Date:   Fri Feb 19 18:05:10 2016 -0500
>
>    drm/radeon/pm: adjust display configuration after powerstate
>    
>    [ Upstream commit 39d4275058baf53e89203407bf3841ff2c74fa32 ]
>    
>    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>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 907c39407e1407d50768943367852c5abd5cde14
>Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
>Date:   Fri Feb 19 14:44:14 2016 +0100
>
>    s390/compat: correct restore of high gprs on signal return
>    
>    [ Upstream commit 342300cc9cd3428bc6bfe5809bfcc1b9a0f06702 ]
>    
>    git commit 8070361799ae1e3f4ef347bd10f0a508ac10acfb
>    "s390: add support for vector extension"
>    broke 31-bit compat processes in regard to signal handling.
>    
>    The restore_sigregs_ext32() function is used to restore the additional
>    elements from the user space signal frame. Among the additional elements
>    are the upper registers halves for 64-bit register support for 31-bit
>    processes. The copy_from_user that is used to retrieve the high-gprs
>    array from the user stack uses an incorrect length, 8 bytes instead of
>    64 bytes. This causes incorrect upper register halves to get loaded.
>    
>    Cc: stable@vger.kernel.org # 3.8+
>    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 82f8c49d31dc618d1508a2870595eab2f7d5cbbd
>Author: Mike Snitzer <snitzer@redhat.com>
>Date:   Sun Feb 21 19:09:22 2016 -0500
>
>    dm: fix dm_rq_target_io leak on faults with .request_fn DM w/ blk-mq paths
>    
>    [ Upstream commit 4328daa2e79ed904a42ce00a9f38b9c36b44b21a ]
>    
>    Using request-based DM mpath configured with the following stacking
>    (.request_fn DM mpath ontop of scsi-mq paths):
>    
>    echo Y > /sys/module/scsi_mod/parameters/use_blk_mq
>    echo N > /sys/module/dm_mod/parameters/use_blk_mq
>    
>    'struct dm_rq_target_io' would leak if a request is requeued before a
>    blk-mq clone is allocated (or fails to allocate).  free_rq_tio()
>    wasn't being called.
>    
>    kmemleak reported:
>    
>    unreferenced object 0xffff8800b90b98c0 (size 112):
>      comm "kworker/7:1H", pid 5692, jiffies 4295056109 (age 78.589s)
>      hex dump (first 32 bytes):
>        00 d0 5c 2c 03 88 ff ff 40 00 bf 01 00 c9 ff ff  ..\,....@.......
>        e0 d9 b1 34 00 88 ff ff 00 00 00 00 00 00 00 00  ...4............
>      backtrace:
>        [<ffffffff81672b6e>] kmemleak_alloc+0x4e/0xb0
>        [<ffffffff811dbb63>] kmem_cache_alloc+0xc3/0x1e0
>        [<ffffffff8117eae5>] mempool_alloc_slab+0x15/0x20
>        [<ffffffff8117ec1e>] mempool_alloc+0x6e/0x170
>        [<ffffffffa00029ac>] dm_old_prep_fn+0x3c/0x180 [dm_mod]
>        [<ffffffff812fbd78>] blk_peek_request+0x168/0x290
>        [<ffffffffa0003e62>] dm_request_fn+0xb2/0x1b0 [dm_mod]
>        [<ffffffff812f66e3>] __blk_run_queue+0x33/0x40
>        [<ffffffff812f9585>] blk_delay_work+0x25/0x40
>        [<ffffffff81096fff>] process_one_work+0x14f/0x3d0
>        [<ffffffff81097715>] worker_thread+0x125/0x4b0
>        [<ffffffff8109ce88>] kthread+0xd8/0xf0
>        [<ffffffff8167cb8f>] ret_from_fork+0x3f/0x70
>        [<ffffffffffffffff>] 0xffffffffffffffff
>    
>    crash> struct -o dm_rq_target_io
>    struct dm_rq_target_io {
>        ...
>    }
>    SIZE: 112
>    
>    Fixes: e5863d9ad7 ("dm: allocate requests in target when stacking on blk-mq devices")
>    Cc: stable@vger.kernel.org # 4.0+
>    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0861e96600db2ecbd9659b3eafc292641e3ec69c
>Author: Gerhard Uttenthaler <uttenthaler@ems-wuensche.com>
>Date:   Tue Dec 22 17:29:16 2015 +0100
>
>    can: ems_usb: Fix possible tx overflow
>    
>    [ Upstream commit 90cfde46586d2286488d8ed636929e936c0c9ab2 ]
>    
>    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>
>    Cc: linux-stable <stable@vger.kernel.org>
>    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit cbd382759e953e56701202591e765e7e17957eef
>Author: Lisa Du <cldu@marvell.com>
>Date:   Wed Feb 17 09:32:52 2016 +0800
>
>    drivers: android: correct the size of struct binder_uintptr_t for BC_DEAD_BINDER_DONE
>    
>    [ Upstream commit 7a64cd887fdb97f074c3fda03bee0bfb9faceac3 ]
>    
>    There's one point was missed in the patch commit da49889deb34 ("staging:
>    binder: Support concurrent 32 bit and 64 bit processes."). When configure
>    BINDER_IPC_32BIT, the size of binder_uintptr_t was 32bits, but size of
>    void * is 64bit on 64bit system. Correct it here.
>    
>    Signed-off-by: Lisa Du <cldu@marvell.com>
>    Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
>    Fixes: da49889deb34 ("staging: binder: Support concurrent 32 bit and 64 bit processes.")
>    Cc: <stable@vger.kernel.org>
>    Acked-by: Olof Johansson <olof@lixom.net>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e0a8bcb7cd5e71dfb3d8d5ed3e2db6d9a7c2b0df
>Author: Nishanth Menon <nm@ti.com>
>Date:   Fri Feb 19 18:09:51 2016 -0600
>
>    hwmon: (gpio-fan) Remove un-necessary speed_index lookup for thermal hook
>    
>    [ Upstream commit 000e0949148382c4962489593a2f05504c2a6771 ]
>    
>    Thermal hook gpio_fan_get_cur_state is only interested in knowing
>    the current speed index that was setup in the system, this is
>    already available as part of fan_data->speed_index which is always
>    set by set_fan_speed. Using get_fan_speed_index is useful when we
>    have no idea about the fan speed configuration (for example during
>    fan_ctrl_init).
>    
>    When thermal framework invokes
>    gpio_fan_get_cur_state=>get_fan_speed_index via gpio_fan_get_cur_state
>    especially in a polled configuration for thermal governor, we
>    basically hog the i2c interface to the extent that other functions
>    fail to get any traffic out :(.
>    
>    Instead, just provide the last state set in the driver - since the gpio
>    fan driver is responsible for the fan state immaterial of override, the
>    fan_data->speed_index should accurately reflect the state.
>    
>    Fixes: b5cf88e46bad ("(gpio-fan): Add thermal control hooks")
>    Reported-by: Tony Lindgren <tony@atomide.com>
>    Cc: Guenter Roeck <linux@roeck-us.net>
>    Cc: Eduardo Valentin <edubezval@gmail.com>
>    Signed-off-by: Nishanth Menon <nm@ti.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9077dc77a92526b028111db2943a26ff8e475d03
>Author: Peter Rosin <peda@axentia.se>
>Date:   Thu Feb 18 14:07:52 2016 +0100
>
>    hwmon: (ads1015) Handle negative conversion values correctly
>    
>    [ Upstream commit acc146943957d7418a6846f06e029b2c5e87e0d5 ]
>    
>    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>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5294fcf306de471172dd4a1ed7b35592fea858cd
>Author: Alexandra Yates <alexandra.yates@linux.intel.com>
>Date:   Wed Feb 17 19:36:20 2016 -0800
>
>    Adding Intel Lewisburg device IDs for SATA
>    
>    [ Upstream commit f5bdd66c705484b4bc77eb914be15c1b7881fae7 ]
>    
>    This patch complements the list of device IDs previously
>    added for lewisburg sata.
>    
>    Signed-off-by: Alexandra Yates <alexandra.yates@linux.intel.com>
>    Signed-off-by: Tejun Heo <tj@kernel.org>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2340493041d9a65fd16a3f356f0a0fda4e48934b
>Author: Alexandra Yates <alexandra.yates@linux.intel.com>
>Date:   Tue Nov 3 14:14:18 2015 -0800
>
>    ahci: add new Intel device IDs
>    
>    [ Upstream commit 56e74338a535cbcc2f2da08b1ea1a92920194364 ]
>    
>    Adding Intel codename Lewisburg platform device IDs for SATA.
>    
>    Signed-off-by: Alexandra Yates <alexandra.yates@linux.intel.com>
>    Signed-off-by: Tejun Heo <tj@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 79151933d58376c5d7429047b397c6d59fad8968
>Author: Alexandra Yates <alexandra.yates@linux.intel.com>
>Date:   Mon Nov 16 11:22:16 2015 -0500
>
>    ahci: Order SATA device IDs for codename Lewisburg
>    
>    [ Upstream commit 4d92f0099a06ef0e36c7673f7c090f1a448b2d1b ]
>    
>    This change was to preserve the ascending order of device IDs.
>    There was an exception with the first two Lewisburg device IDs to
>    keep all device IDs of the same kind grouped by code name.
>    
>    Signed-off-by: Alexandra Yates <alexandra.yates@linux.intel.com>
>    signed-off-by: Tejun Heo <tj@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 664a608ef37cf8f8bf155d865876314618686756
>Author: BjÃ¸rn Mork <bjorn@mork.no>
>Date:   Fri Feb 12 16:40:00 2016 +0100
>
>    USB: option: add "4G LTE usb-modem U901"
>    
>    [ Upstream commit d061c1caa31d4d9792cfe48a2c6b309a0e01ef46 ]
>    
>    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
>    
>    Cc: <stable@vger.kernel.org>
>    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: Sasha Levin <sasha.levin@oracle.com>
>
>commit d15706c9c9d206bb2ad9c8a589da380daf1356aa
>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
>    
>    [ Upstream commit 6627ae19385283b89356a199d7f03c75ba35fb29 ]
>    
>    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>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 619400280f304285af5ae99fe674f11ebf9e40cc
>Author: Andrey Skvortsov <andrej.skvortzov@gmail.com>
>Date:   Fri Jan 29 00:07:30 2016 +0300
>
>    USB: option: add support for SIM7100E
>    
>    [ Upstream commit 3158a8d416f4e1b79dcc867d67cb50013140772c ]
>    
>    $ 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>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 038d8248fc62423b16810878f14d59070a0076cb
>Author: Benjamin Coddington <bcodding@redhat.com>
>Date:   Wed Feb 17 10:41:41 2016 -0500
>
>    NFSv4: Fix a dentry leak on alias use
>    
>    [ Upstream commit d9dfd8d741683347ee159d25f5b50c346a0df557 ]
>    
>    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-...")
>    Cc: stable@vger.kernel.org # 3.10+
>    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 40b43e3cc942d3149c4a6ef4692703ee64e8ba62
>Author: John Youn <John.Youn@synopsys.com>
>Date:   Tue Feb 16 20:10:53 2016 -0800
>
>    usb: dwc3: Fix assignment of EP transfer resources
>    
>    [ Upstream commit c450960187f45d4260db87c7dd4fc0bceb5565d8 ]
>    
>    The assignement of EP transfer resources was not handled properly in the
>    dwc3 driver. Commit aebda6187181 ("usb: dwc3: Reset the transfer
>    resource index on SET_INTERFACE") previously fixed one aspect of this
>    where resources may be exhausted with multiple calls to SET_INTERFACE.
>    However, it introduced an issue where composite devices with multiple
>    interfaces can be assigned the same transfer resources for different
>    endpoints. This patch solves both issues.
>    
>    The assignment of transfer resources cannot perfectly follow the data
>    book due to the fact that the controller driver does not have all
>    knowledge of the configuration in advance. It is given this information
>    piecemeal by the composite gadget framework after every
>    SET_CONFIGURATION and SET_INTERFACE. Trying to follow the databook
>    programming model in this scenario can cause errors. For two reasons:
>    
>    1) The databook says to do DEPSTARTCFG for every SET_CONFIGURATION and
>    SET_INTERFACE (8.1.5). This is incorrect in the scenario of multiple
>    interfaces.
>    
>    2) The databook does not mention doing more DEPXFERCFG for new endpoint
>    on alt setting (8.1.6).
>    
>    The following simplified method is used instead:
>    
>    All hardware endpoints can be assigned a transfer resource and this
>    setting will stay persistent until either a core reset or hibernation.
>    So whenever we do a DEPSTARTCFG(0) we can go ahead and do DEPXFERCFG for
>    every hardware endpoint as well. We are guaranteed that there are as
>    many transfer resources as endpoints.
>    
>    This patch triggers off of the calling dwc3_gadget_start_config() for
>    EP0-out, which always happens first, and which should only happen in one
>    of the above conditions.
>    
>    Fixes: aebda6187181 ("usb: dwc3: Reset the transfer resource index on SET_INTERFACE")
>    Cc: <stable@vger.kernel.org> # v3.2+
>    Reported-by: Ravi Babu <ravibabu@ti.com>
>    Signed-off-by: John Youn <johnyoun@synopsys.com>
>    Signed-off-by: Felipe Balbi <balbi@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f0b73a580df467705a7a316daf03a0ecdac1ec8c
>Author: Hans Verkuil <hansverk@cisco.com>
>Date:   Wed Feb 10 08:09:10 2016 -0200
>
>    [media] adv7604: fix tx 5v detect regression
>    
>    [ Upstream commit 0ba4581c84cfb39fd527f6b3457f1c97f6356c04 ]
>    
>    The 5 volt detect functionality broke in 3.14: the code reads IO register 0x70
>    again after it has already been cleared. Instead it should use the cached
>    irq_reg_0x70 value and the io_write to 0x71 to clear 0x70 can be dropped since
>    this has already been done.
>    
>    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
>    Cc: <stable@vger.kernel.org>      # for v3.14 and up
>    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9a30ae51a5bb55570004afba8016611cff882cb2
>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.
>    
>    [ Upstream commit 4d8c8bd6f2062c9988817183a91fe2e623c8aa5e ]
>    
>    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>
>    Cc: <stable@vger.kernel.org>
>    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a7b4133de42f7eb7a926e1a5a1aaf0c1e7bfad12
>Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>Date:   Thu Feb 11 16:10:23 2016 -0500
>
>    xen/pciback: Check PF instead of VF for PCI_COMMAND_MEMORY
>    
>    [ Upstream commit d52a24819677bbb45eb1ce93a42daa1ae6c4d61d ]
>    
>    commit 8d47065f7d1980dde52abb874b301054f3013602 upstream.
>    
>    Commit 408fb0e5aa7fda0059db282ff58c3b2a4278baa0 (xen/pciback: Don't
>    allow MSI-X ops if PCI_COMMAND_MEMORY is not set) prevented enabling
>    MSI-X on passed-through virtual functions, because it checked the VF
>    for PCI_COMMAND_MEMORY but this is not a valid bit for VFs.
>    
>    Instead, check the physical function for PCI_COMMAND_MEMORY.
>    
>    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>    Reviewed-by: Jan Beulich <jbeulich@suse.com>
>    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit fda3e3e7b638f742149fb32aa9b691413bb91f41
>Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>Date:   Mon Nov 2 18:13:27 2015 -0500
>
>    xen/pciback: Don't allow MSI-X ops if PCI_COMMAND_MEMORY is not set.
>    
>    [ Upstream commit 408fb0e5aa7fda0059db282ff58c3b2a4278baa0 ]
>    
>    commit f598282f51 ("PCI: Fix the NIU MSI-X problem in a better way")
>    teaches us that dealing with MSI-X can be troublesome.
>    
>    Further checks in the MSI-X architecture shows that if the
>    PCI_COMMAND_MEMORY bit is turned of in the PCI_COMMAND we
>    may not be able to access the BAR (since they are memory regions).
>    
>    Since the MSI-X tables are located in there.. that can lead
>    to us causing PCIe errors. Inhibit us performing any
>    operation on the MSI-X unless the MEMORY bit is set.
>    
>    Note that Xen hypervisor with:
>    "x86/MSI-X: access MSI-X table only after having enabled MSI-X"
>    will return:
>    xen_pciback: 0000:0a:00.1: error -6 enabling MSI-X for guest 3!
>    
>    When the generic MSI code tries to setup the PIRQ without
>    MEMORY bit set. Which means with later versions of Xen
>    (4.6) this patch is not neccessary.
>    
>    This is part of XSA-157
>    
>    CC: stable@vger.kernel.org
>    Reviewed-by: Jan Beulich <jbeulich@suse.com>
>    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a6c762381cc34ff6df5f75afa46e7f153116cf78
>Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>Date:   Mon Nov 2 18:07:44 2015 -0500
>
>    xen/pciback: Return error on XEN_PCI_OP_enable_msix when device has MSI or MSI-X enabled
>    
>    [ Upstream commit 5e0ce1455c09dd61d029b8ad45d82e1ac0b6c4c9 ]
>    
>    The guest sequence of:
>    
>      a) XEN_PCI_OP_enable_msix
>      b) XEN_PCI_OP_enable_msix
>    
>    results in hitting an NULL pointer due to using freed pointers.
>    
>    The device passed in the guest MUST have MSI-X capability.
>    
>    The a) constructs and SysFS representation of MSI and MSI groups.
>    The b) adds a second set of them but adding in to SysFS fails (duplicate entry).
>    'populate_msi_sysfs' frees the newly allocated msi_irq_groups (note that
>    in a) pdev->msi_irq_groups is still set) and also free's ALL of the
>    MSI-X entries of the device (the ones allocated in step a) and b)).
>    
>    The unwind code: 'free_msi_irqs' deletes all the entries and tries to
>    delete the pdev->msi_irq_groups (which hasn't been set to NULL).
>    However the pointers in the SysFS are already freed and we hit an
>    NULL pointer further on when 'strlen' is attempted on a freed pointer.
>    
>    The patch adds a simple check in the XEN_PCI_OP_enable_msix to guard
>    against that. The check for msi_enabled is not stricly neccessary.
>    
>    This is part of XSA-157
>    
>    CC: stable@vger.kernel.org
>    Reviewed-by: David Vrabel <david.vrabel@citrix.com>
>    Reviewed-by: Jan Beulich <jbeulich@suse.com>
>    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 05584b5815ecb05a6b8f394eef566781eb66b821
>Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>Date:   Thu Feb 11 16:10:24 2016 -0500
>
>    xen/pciback: Save the number of MSI-X entries to be copied later.
>    
>    [ Upstream commit 4cf5aa2ffe17403385d75a5b1d9d97071500ea18 ]
>    
>    commit d159457b84395927b5a52adb72f748dd089ad5e5 upstream.
>    
>    Commit 8135cf8b092723dbfcc611fe6fdcb3a36c9951c5 (xen/pciback: Save
>    xen_pci_op commands before processing it) broke enabling MSI-X because
>    it would never copy the resulting vectors into the response.  The
>    number of vectors requested was being overwritten by the return value
>    (typically zero for success).
>    
>    Save the number of vectors before processing the op, so the correct
>    number of vectors are copied afterwards.
>    
>    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>    Reviewed-by: Jan Beulich <jbeulich@suse.com>
>    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b0a4f565b1dba16cb98842d3129fa0f57445b044
>Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>Date:   Mon Nov 16 12:40:48 2015 -0500
>
>    xen/pciback: Save xen_pci_op commands before processing it
>    
>    [ Upstream commit 8135cf8b092723dbfcc611fe6fdcb3a36c9951c5 ]
>    
>    Double fetch vulnerabilities that happen when a variable is
>    fetched twice from shared memory but a security check is only
>    performed the first time.
>    
>    The xen_pcibk_do_op function performs a switch statements on the op->cmd
>    value which is stored in shared memory. Interestingly this can result
>    in a double fetch vulnerability depending on the performed compiler
>    optimization.
>    
>    This patch fixes it by saving the xen_pci_op command before
>    processing it. We also use 'barrier' to make sure that the
>    compiler does not perform any optimization.
>    
>    This is part of XSA155.
>    
>    CC: stable@vger.kernel.org
>    Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>    Signed-off-by: Jan Beulich <JBeulich@suse.com>
>    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 18ddf12c2de57556909778af1ab31177bf53d5cb
>Author: Sasha Levin <sasha.levin@oracle.com>
>Date:   Mon Mar 7 12:23:04 2016 -0500
>
>    iwlwifi: mvm: don't allow sched scans without matches to be started
>    
>    [ Upstream commit 5e56276e7555b34550d51459a801ff75eca8b907 ]
>    
>    The firmware can perform a scheduled scan with not matchsets passed,
>    but it can't send notification that results were found.  Since the
>    userspace then cannot know when we got new results and the firmware
>    wouldn't trigger a wake in case we are sleeping, it's better not to
>    allow scans without matchsets.
>    
>    This fixes https://bugzilla.kernel.org/show_bug.cgi?id=110831
>    
>    Cc: <stable@vger.kernel.org> [3.17+]
>    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
>    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
>    [SL: Backport to 4.1]
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 891985fa8e08d0c625ee71096fc3d10350eb051b
>Author: Arnd Bergmann <arnd@arndb.de>
>Date:   Thu Feb 11 14:16:27 2016 +0100
>
>    libata: fix HDIO_GET_32BIT ioctl
>    
>    [ Upstream commit 287e6611ab1eac76c2c5ebf6e345e04c80ca9c61 ]
>    
>    As reported by Soohoon Lee, the HDIO_GET_32BIT ioctl does not
>    work correctly in compat mode with libata.
>    
>    I have investigated the issue further and found multiple problems
>    that all appeared with the same commit that originally introduced
>    HDIO_GET_32BIT handling in libata back in linux-2.6.8 and presumably
>    also linux-2.4, as the code uses "copy_to_user(arg, &val, 1)" to copy
>    a 'long' variable containing either 0 or 1 to user space.
>    
>    The problems with this are:
>    
>    * On big-endian machines, this will always write a zero because it
>      stores the wrong byte into user space.
>    
>    * In compat mode, the upper three bytes of the variable are updated
>      by the compat_hdio_ioctl() function, but they now contain
>      uninitialized stack data.
>    
>    * The hdparm tool calling this ioctl uses a 'static long' variable
>      to store the result. This means at least the upper bytes are
>      initialized to zero, but calling another ioctl like HDIO_GET_MULTCOUNT
>      would fill them with data that remains stale when the low byte
>      is overwritten. Fortunately libata doesn't implement any of the
>      affected ioctl commands, so this would only happen when we query
>      both an IDE and an ATA device in the same command such as
>      "hdparm -N -c /dev/hda /dev/sda"
>    
>    * The libata code for unknown reasons started using ATA_IOC_GET_IO32
>      and ATA_IOC_SET_IO32 as aliases for HDIO_GET_32BIT and HDIO_SET_32BIT,
>      while the ioctl commands that were added later use the normal
>      HDIO_* names. This is harmless but rather confusing.
>    
>    This addresses all four issues by changing the code to use put_user()
>    on an 'unsigned long' variable in HDIO_GET_32BIT, like the IDE subsystem
>    does, and by clarifying the names of the ioctl commands.
>    
>    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>    Reported-by: Soohoon Lee <Soohoon.Lee@f5.com>
>    Tested-by: Soohoon Lee <Soohoon.Lee@f5.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Tejun Heo <tj@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 64ecdd296041c4eb9522c7cebed877c47d92a278
>Author: Christoph Hellwig <hch@lst.de>
>Date:   Mon Feb 8 21:11:50 2016 +0100
>
>    nfs: fix nfs_size_to_loff_t
>    
>    [ Upstream commit 50ab8ec74a153eb30db26529088bc57dd700b24c ]
>    
>    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()")
>    Cc: stable@vger.kernel.org # 2.6.23+
>    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 86708275f1c1ba89c2d1ef7cd4a1c66a10b35b45
>Author: Juergen Gross <jgross@suse.com>
>Date:   Mon Feb 8 15:30:18 2016 +0100
>
>    xen/scsiback: correct frontend counting
>    
>    [ Upstream commit f285aa8db7cc4432c1a03f8b55ff34fe96317c11 ]
>    
>    When adding a new frontend to xen-scsiback don't decrement the number
>    of active frontends in case of no error. Doing so results in a failure
>    when trying to remove the xen-pvscsi nexus even if no domain is using
>    it.
>    
>    Signed-off-by: Juergen Gross <jgross@suse.com>
>    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit eef85746c932a90df78492598c501315c7e0c5c1
>Author: David Ahern <david.ahern@oracle.com>
>Date:   Fri Jun 5 13:42:53 2015 -0400
>
>    perf tools: Update MANIFEST per files removed from kernel
>    
>    [ Upstream commit c8ad7063626406181a7ebab10cb31b4f741b13d4 ]
>    
>    Building perf out of kernel tree is currently broken because the
>    MANIFEST file refers to kernel files that have been removed. With this
>    patch make perf-targz-src-pkg succeeds as does building perf using the
>    generated tarfile.
>    
>    Signed-off-by: David Ahern <david.ahern@oracle.com>
>    Link: http://lkml.kernel.org/r/1433526173-172332-1-git-send-email-david.ahern@oracle.com
>    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e94991ebb5b4d95735731683770cde961cdf9cb4
>Author: Nicholas Bellinger <nab@linux-iscsi.org>
>Date:   Sun Mar 6 01:24:29 2016 +0000
>
>    target: Fix linux-4.1.y specific compile warning
>    
>    The linux-4.1.y specific patch to fix a previous v4.1 UNIT_ATTENTION
>    read-copy-update conversion regression:
>    
>      commit 35afa65642a9a88c81913377b93a3a66220f8b9d
>      Author: Nicholas Bellinger <nab@linux-iscsi.org>
>      Date:   Wed Sep 23 07:49:26 2015 +0000
>    
>          target: Fix v4.1 UNIT_ATTENTION se_node_acl->device_list[] NULL pointer
>    
>    introduced the following compile warning:
>    
>      drivers/target/target_core_pr.c: In function âcore_scsi3_pr_seq_non_holderâ:
>      drivers/target/target_core_pr.c:332:3: warning: âreturnâ with no value, in function returning non-void [-Wreturn-type]
>    
>    Go ahead and fix this up to always returning zero when no ACL
>    device list exists within core_scsi3_pr_seq_non_holder().
>    
>    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4aa04a257993e90d573a5dbfa4d3f3259e3f8ba1
>Author: Nicholas Bellinger <nab@linux-iscsi.org>
>Date:   Sun Mar 6 01:24:28 2016 +0000
>
>    target: Fix race with SCF_SEND_DELAYED_TAS handling
>    
>    commit 310d3d314be7f0a84011ebdc4bdccbcae9755a87 upstream.
>    
>    This patch fixes a race between setting of SCF_SEND_DELAYED_TAS
>    in transport_send_task_abort(), and check of the same bit in
>    transport_check_aborted_status().
>    
>    It adds a __transport_check_aborted_status() version that is
>    used by target_execute_cmd() when se_cmd->t_state_lock is
>    held, and a transport_check_aborted_status() wrapper for
>    all other existing callers.
>    
>    Also, it handles the case where the check happens before
>    transport_send_task_abort() gets called.  For this, go
>    ahead and set SCF_SEND_DELAYED_TAS early when necessary,
>    and have transport_send_task_abort() send the abort.
>    
>    Cc: Quinn Tran <quinn.tran@qlogic.com>
>    Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
>    Cc: Sagi Grimberg <sagig@mellanox.com>
>    Cc: Christoph Hellwig <hch@lst.de>
>    Cc: Hannes Reinecke <hare@suse.de>
>    Cc: Andy Grover <agrover@redhat.com>
>    Cc: Mike Christie <mchristi@redhat.com>
>    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 08367c9e8f0337b0fea23acb459fb4bc40cb7be7
>Author: Nicholas Bellinger <nab@linux-iscsi.org>
>Date:   Sun Mar 6 01:24:27 2016 +0000
>
>    target: Fix remote-port TMR ABORT + se_cmd fabric stop
>    
>    commit 0f4a943168f31d29a1701908931acaba518b131a upstream.
>    
>    To address the bug where fabric driver level shutdown
>    of se_cmd occurs at the same time when TMR CMD_T_ABORTED
>    is happening resulting in a -1 ->cmd_kref, this patch
>    adds a CMD_T_FABRIC_STOP bit that is used to determine
>    when TMR + driver I_T nexus shutdown is happening
>    concurrently.
>    
>    It changes target_sess_cmd_list_set_waiting() to obtain
>    se_cmd->cmd_kref + set CMD_T_FABRIC_STOP, and drop local
>    reference in target_wait_for_sess_cmds() and invoke extra
>    target_put_sess_cmd() during Task Aborted Status (TAS)
>    when necessary.
>    
>    Also, it adds a new target_wait_free_cmd() wrapper around
>    transport_wait_for_tasks() for the special case within
>    transport_generic_free_cmd() to set CMD_T_FABRIC_STOP,
>    and is now aware of CMD_T_ABORTED + CMD_T_TAS status
>    bits to know when an extra transport_put_cmd() during
>    TAS is required.
>    
>    Note transport_generic_free_cmd() is expected to block on
>    cmd->cmd_wait_comp in order to follow what iscsi-target
>    expects during iscsi_conn context se_cmd shutdown.
>    
>    Cc: Quinn Tran <quinn.tran@qlogic.com>
>    Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
>    Cc: Sagi Grimberg <sagig@mellanox.com>
>    Cc: Christoph Hellwig <hch@lst.de>
>    Cc: Hannes Reinecke <hare@suse.de>
>    Cc: Andy Grover <agrover@redhat.com>
>    Cc: Mike Christie <mchristi@redhat.com>
>    Signed-off-by: Nicholas Bellinger <nab@daterainc.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 29190c778c5d98b03a9bedf03b5d6771aa140e0c
>Author: Nicholas Bellinger <nab@linux-iscsi.org>
>Date:   Sun Mar 6 01:24:26 2016 +0000
>
>    target: Fix TAS handling for multi-session se_node_acls
>    
>    commit ebde1ca5a908b10312db4ecd7553e3ba039319ab upstream.
>    
>    This patch fixes a bug in TMR task aborted status (TAS)
>    handling when multiple sessions are connected to the
>    same target WWPN endpoint and se_node_acl descriptor,
>    resulting in TASK_ABORTED status to not be generated
>    for aborted se_cmds on the remote port.
>    
>    This is due to core_tmr_handle_tas_abort() incorrectly
>    comparing se_node_acl instead of se_session, for which
>    the multi-session case is expected to be sharing the
>    same se_node_acl.
>    
>    Instead, go ahead and update core_tmr_handle_tas_abort()
>    to compare tmr_sess + cmd->se_sess in order to determine
>    if the LUN_RESET was received on a different I_T nexus,
>    and TASK_ABORTED status response needs to be generated.
>    
>    Reviewed-by: Christoph Hellwig <hch@lst.de>
>    Cc: Quinn Tran <quinn.tran@qlogic.com>
>    Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
>    Cc: Sagi Grimberg <sagig@mellanox.com>
>    Cc: Hannes Reinecke <hare@suse.de>
>    Cc: Andy Grover <agrover@redhat.com>
>    Cc: Mike Christie <mchristi@redhat.com>
>    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3286a2fea80a6ee53eadb95fdd900e3e81b0fbce
>Author: Nicholas Bellinger <nab@linux-iscsi.org>
>Date:   Sun Mar 6 01:24:25 2016 +0000
>
>    target: Fix LUN_RESET active I/O handling for ACK_KREF
>    
>    commit febe562c20dfa8f33bee7d419c6b517986a5aa33 upstream.
>    
>    This patch fixes a NULL pointer se_cmd->cmd_kref < 0
>    refcount bug during TMR LUN_RESET with active se_cmd
>    I/O, that can be triggered during se_cmd descriptor
>    shutdown + release via core_tmr_drain_state_list() code.
>    
>    To address this bug, add common __target_check_io_state()
>    helper for ABORT_TASK + LUN_RESET w/ CMD_T_COMPLETE
>    checking, and set CMD_T_ABORTED + obtain ->cmd_kref for
>    both cases ahead of last target_put_sess_cmd() after
>    TFO->aborted_task() -> transport_cmd_finish_abort()
>    callback has completed.
>    
>    It also introduces SCF_ACK_KREF to determine when
>    transport_cmd_finish_abort() needs to drop the second
>    extra reference, ahead of calling target_put_sess_cmd()
>    for the final kref_put(&se_cmd->cmd_kref).
>    
>    It also updates transport_cmd_check_stop() to avoid
>    holding se_cmd->t_state_lock while dropping se_cmd
>    device state via target_remove_from_state_list(), now
>    that core_tmr_drain_state_list() is holding the
>    se_device lock while checking se_cmd state from
>    within TMR logic.
>    
>    Finally, move transport_put_cmd() release of SGL +
>    TMR + extended CDB memory into target_free_cmd_mem()
>    in order to avoid potential resource leaks in TMR
>    ABORT_TASK + LUN_RESET code-paths.  Also update
>    target_release_cmd_kref() accordingly.
>    
>    Reviewed-by: Quinn Tran <quinn.tran@qlogic.com>
>    Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
>    Cc: Sagi Grimberg <sagig@mellanox.com>
>    Cc: Christoph Hellwig <hch@lst.de>
>    Cc: Hannes Reinecke <hare@suse.de>
>    Cc: Andy Grover <agrover@redhat.com>
>    Cc: Mike Christie <mchristi@redhat.com>
>    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7a2903243093459623817fa1b25a63c5d4c60f85
>Author: Jan Engelhardt <jengelh@inai.de>
>Date:   Sun Mar 6 01:24:24 2016 +0000
>
>    target: fix COMPARE_AND_WRITE non zero SGL offset data corruption
>    
>    [ Upstream commit d94e5a61357a04938ce14d6033b4d33a3c5fd780 ]
>    
>    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: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5dd73bb38031a5d8f81bf7d9b4f10135ab950f64
>Author: Nicholas Bellinger <nab@linux-iscsi.org>
>Date:   Sun Mar 6 01:24:23 2016 +0000
>
>    target: Fix race for SCF_COMPARE_AND_WRITE_POST checking
>    
>    [ Upstream commit 057085e522f8bf94c2e691a5b76880f68060f8ba ]
>    
>    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: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4b4bc57ac1c2fd740f39e5849d45b9bcf6fbaf8b
>Author: Nicholas Bellinger <nab@linux-iscsi.org>
>Date:   Sun Mar 6 01:24:22 2016 +0000
>
>    iscsi-target: Fix rx_login_comp hang after login failure
>    
>    [ Upstream commit ca82c2bded29b38d36140bfa1e76a7bbfcade390 ]
>    
>    This patch addresses a case where iscsi_target_do_tx_login_io()
>    fails sending the last login response PDU, after the RX/TX
>    threads have already been started.
>    
>    The case centers around iscsi_target_rx_thread() not invoking
>    allow_signal(SIGINT) before the send_sig(SIGINT, ...) occurs
>    from the failure path, resulting in RX thread hanging
>    indefinately on iscsi_conn->rx_login_comp.
>    
>    Note this bug is a regression introduced by:
>    
>      commit e54198657b65625085834847ab6271087323ffea
>      Author: Nicholas Bellinger <nab@linux-iscsi.org>
>      Date:   Wed Jul 22 23:14:19 2015 -0700
>    
>          iscsi-target: Fix iscsit_start_kthreads failure OOPs
>    
>    To address this bug, complete ->rx_login_complete for good
>    measure in the failure path, and immediately return from
>    RX thread context if connection state did not actually reach
>    full feature phase (TARG_CONN_STATE_LOGGED_IN).
>    
>    Cc: Sagi Grimberg <sagig@mellanox.com>
>    Cc: <stable@vger.kernel.org> # v3.10+
>    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b9a9cfdbf7254f4a231cc8ddf685cc29d3a9c6e5
>Author: Sasha Levin <sasha.levin@oracle.com>
>Date:   Fri Mar 4 16:55:54 2016 -0500
>
>    Linux 4.1.19
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 00731a62f0f167760ff7a536a30b9eb441794aaf
>Author: Neil Horman <nhorman@tuxdriver.com>
>Date:   Thu Feb 18 16:10:57 2016 -0500
>
>    sctp: Fix port hash table size computation
>    
>    [ Upstream commit d9749fb5942f51555dc9ce1ac0dbb1806960a975 ]
>    
>    Dmitry Vyukov noted recently that the sctp_port_hashtable had an error in
>    its size computation, observing that the current method never guaranteed
>    that the hashsize (measured in number of entries) would be a power of two,
>    which the input hash function for that table requires.  The root cause of
>    the problem is that two values need to be computed (one, the allocation
>    order of the storage requries, as passed to __get_free_pages, and two the
>    number of entries for the hash table).  Both need to be ^2, but for
>    different reasons, and the existing code is simply computing one order
>    value, and using it as the basis for both, which is wrong (i.e. it assumes
>    that ((1<<order)*PAGE_SIZE)/sizeof(bucket) is still ^2 when its not).
>    
>    To fix this, we change the logic slightly.  We start by computing a goal
>    allocation order (which is limited by the maximum size hash table we want
>    to support.  Then we attempt to allocate that size table, decreasing the
>    order until a successful allocation is made.  Then, with the resultant
>    successful order we compute the number of buckets that hash table supports,
>    which we then round down to the nearest power of two, giving us the number
>    of entries the table actually supports.
>    
>    I've tested this locally here, using non-debug and spinlock-debug kernels,
>    and the number of entries in the hashtable consistently work out to be
>    powers of two in all cases.
>    
>    Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    CC: Dmitry Vyukov <dvyukov@google.com>
>    CC: Vladislav Yasevich <vyasevich@gmail.com>
>    CC: "David S. Miller" <davem@davemloft.net>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit fdbc49cb20c7711e07010acd7bcf5e6839cf2a86
>Author: Dmitry V. Levin <ldv@altlinux.org>
>Date:   Fri Feb 19 04:27:48 2016 +0300
>
>    unix_diag: fix incorrect sign extension in unix_lookup_by_ino
>    
>    [ Upstream commit b5f0549231ffb025337be5a625b0ff9f52b016f0 ]
>    
>    The value passed by unix_diag_get_exact to unix_lookup_by_ino has type
>    __u32, but unix_lookup_by_ino's argument ino has type int, which is not
>    a problem yet.
>    However, when ino is compared with sock_i_ino return value of type
>    unsigned long, ino is sign extended to signed long, and this results
>    to incorrect comparison on 64-bit architectures for inode numbers
>    greater than INT_MAX.
>    
>    This bug was found by strace test suite.
>    
>    Fixes: 5d3cae8bc39d ("unix_diag: Dumping exact socket core")
>    Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
>    Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3aa450dcb11d582aab3a6aaf19b67380ab4322bc
>Author: Anton Protopopov <a.s.protopopov@gmail.com>
>Date:   Tue Feb 16 21:43:16 2016 -0500
>
>    rtnl: RTM_GETNETCONF: fix wrong return value
>    
>    [ Upstream commit a97eb33ff225f34a8124774b3373fd244f0e83ce ]
>    
>    An error response from a RTM_GETNETCONF request can return the positive
>    error value EINVAL in the struct nlmsgerr that can mislead userspace.
>    
>    Signed-off-by: Anton Protopopov <a.s.protopopov@gmail.com>
>    Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1610a64d0c495cd84d848e5ff4e92f1f9f0ec6e5
>Author: Xin Long <lucien.xin@gmail.com>
>Date:   Thu Feb 18 21:21:19 2016 +0800
>
>    route: check and remove route cache when we get route
>    
>    [ Upstream commit deed49df7390d5239024199e249190328f1651e7 ]
>    
>    Since the gc of ipv4 route was removed, the route cached would has
>    no chance to be removed, and even it has been timeout, it still could
>    be used, cause no code to check it's expires.
>    
>    Fix this issue by checking  and removing route cache when we get route.
>    
>    Signed-off-by: Xin Long <lucien.xin@gmail.com>
>    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit dda12d1bb3534b095c3d3e537e081339e0b7192f
>Author: Guillaume Nault <g.nault@alphalink.fr>
>Date:   Mon Feb 15 17:01:10 2016 +0100
>
>    pppoe: fix reference counting in PPPoE proxy
>    
>    [ Upstream commit 29e73269aa4d36f92b35610c25f8b01c789b0dc8 ]
>    
>    Drop reference on the relay_po socket when __pppoe_xmit() succeeds.
>    This is already handled correctly in the error path.
>    
>    Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 89afe37040ed95a8959d67efc784a27948f0a76f
>Author: Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz>
>Date:   Mon Feb 15 16:24:44 2016 +1300
>
>    l2tp: Fix error creating L2TP tunnels
>    
>    [ Upstream commit 853effc55b0f975abd6d318cca486a9c1b67e10f ]
>    
>    A previous commit (33f72e6) added notification via netlink for tunnels
>    when created/modified/deleted. If the notification returned an error,
>    this error was returned from the tunnel function. If there were no
>    listeners, the error code ESRCH was returned, even though having no
>    listeners is not an error. Other calls to this and other similar
>    notification functions either ignore the error code, or filter ESRCH.
>    This patch checks for ESRCH and does not flag this as an error.
>    
>    Reviewed-by: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
>    Signed-off-by: Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 29d526aca29faa3236c9787c2512c5ba4c82092a
>Author: Eugenia Emantayev <eugenia@mellanox.com>
>Date:   Wed Feb 17 17:24:27 2016 +0200
>
>    net/mlx4_en: Avoid changing dev->features directly in run-time
>    
>    [ Upstream commit 925ab1aa9394bbaeac47ee5b65d3fdf0fb8135cf ]
>    
>    It's forbidden to manually change dev->features in run-time. Currently, this is
>    done in the driver to make sure that GSO_UDP_TUNNEL is advertized only when
>    VXLAN tunnel is set. However, since the stack actually does features intersection
>    with hw_enc_features, we can safely revert to advertizing features early when
>    registering the netdevice.
>    
>    Fixes: f4a1edd56120 ('net/mlx4_en: Advertize encapsulation offloads [...]')
>    Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com>
>    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5c72a2dd6fedf29368fa67b15c7c076dd93cf3dd
>Author: Eugenia Emantayev <eugenia@mellanox.com>
>Date:   Wed Feb 17 17:24:23 2016 +0200
>
>    net/mlx4_en: Choose time-stamping shift value according to HW frequency
>    
>    [ Upstream commit 31c128b66e5b28f468076e4f3ca3025c35342041 ]
>    
>    Previously, the shift value used for time-stamping was constant and didn't
>    depend on the HW chip frequency. Change that to take the frequency into account
>    and calculate the maximal value in cycles per wraparound of ten seconds. This
>    time slot was chosen since it gives a good accuracy in time synchronization.
>    
>    Algorithm for shift value calculation:
>     * Round up the maximal value in cycles to nearest power of two
>    
>     * Calculate maximal multiplier by division of all 64 bits set
>       to above result
>    
>     * Then, invert the function clocksource_khz2mult() to get the shift from
>       maximal mult value
>    
>    Fixes: ec693d47010e ('net/mlx4_en: Add HW timestamping (TS) support')
>    Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com>
>    Reviewed-by: Matan Barak <matanb@mellanox.com>
>    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7a9a967fa8bd958586896bb89f5d44ebbbbeaec3
>Author: Amir Vadai <amir@vadai.me>
>Date:   Wed Feb 17 17:24:22 2016 +0200
>
>    net/mlx4_en: Count HW buffer overrun only once
>    
>    [ Upstream commit 281e8b2fdf8e4ef366b899453cae50e09b577ada ]
>    
>    RdropOvflw counts overrun of HW buffer, therefore should
>    be used for rx_fifo_errors only.
>    
>    Currently RdropOvflw counter is mistakenly also set into
>    rx_missed_errors and rx_over_errors too, which makes the
>    device total dropped packets accounting to show wrong results.
>    
>    Fix that. Use it for rx_fifo_errors only.
>    
>    Fixes: c27a02cd94d6 ('mlx4_en: Add driver for Mellanox ConnectX 10GbE NIC')
>    Signed-off-by: Amir Vadai <amir@vadai.me>
>    Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com>
>    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ce643bc32f94c94d5d018c116ed0138ec19bfb4a
>Author: BjÃ¸rn Mork <bjorn@mork.no>
>Date:   Fri Feb 12 16:42:14 2016 +0100
>
>    qmi_wwan: add "4G LTE usb-modem U901"
>    
>    [ Upstream commit aac8d3c282e024c344c5b86dc1eab7af88bb9716 ]
>    
>    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: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 73fd505d34328b113fb9743688f245991409a830
>Author: Rainer Weikusat <rweikusat@mobileactivedefense.com>
>Date:   Thu Feb 11 19:37:27 2016 +0000
>
>    af_unix: Guard against other == sk in unix_dgram_sendmsg
>    
>    [ Upstream commit a5527dda344fff0514b7989ef7a755729769daa1 ]
>    
>    The unix_dgram_sendmsg routine use the following test
>    
>    if (unlikely(unix_peer(other) != sk && unix_recvq_full(other))) {
>    
>    to determine if sk and other are in an n:1 association (either
>    established via connect or by using sendto to send messages to an
>    unrelated socket identified by address). This isn't correct as the
>    specified address could have been bound to the sending socket itself or
>    because this socket could have been connected to itself by the time of
>    the unix_peer_get but disconnected before the unix_state_lock(other). In
>    both cases, the if-block would be entered despite other == sk which
>    might either block the sender unintentionally or lead to trying to unlock
>    the same spin lock twice for a non-blocking send. Add a other != sk
>    check to guard against this.
>    
>    Fixes: 7d267278a9ec ("unix: avoid use-after-free in ep_remove_wait_queue")
>    Reported-By: Philipp Hahn <pmhahn@pmhahn.de>
>    Signed-off-by: Rainer Weikusat <rweikusat@mobileactivedefense.com>
>    Tested-by: Philipp Hahn <pmhahn@pmhahn.de>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ffe8615cbb6abdbb66b8c8b33a3e7ea06c6662f9
>Author: Eric Dumazet <edumazet@google.com>
>Date:   Thu Feb 4 06:23:28 2016 -0800
>
>    ipv4: fix memory leaks in ip_cmsg_send() callers
>    
>    [ Upstream commit 919483096bfe75dda338e98d56da91a263746a0a ]
>    
>    Dmitry reported memory leaks of IP options allocated in
>    ip_cmsg_send() when/if this function returns an error.
>    
>    Callers are responsible for the freeing.
>    
>    Many thanks to Dmitry for the report and diagnostic.
>    
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Signed-off-by: Eric Dumazet <edumazet@google.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 54d0901de6ecdfc72514f5c610fe89d65674c126
>Author: Jay Vosburgh <jay.vosburgh@canonical.com>
>Date:   Tue Feb 2 13:35:56 2016 -0800
>
>    bonding: Fix ARP monitor validation
>    
>    [ Upstream commit 21a75f0915dde8674708b39abfcda113911c49b1 ]
>    
>    The current logic in bond_arp_rcv will accept an incoming ARP for
>    validation if (a) the receiving slave is either "active" (which includes
>    the currently active slave, or the current ARP slave) or, (b) there is a
>    currently active slave, and it has received an ARP since it became active.
>    For case (b), the receiving slave isn't the currently active slave, and is
>    receiving the original broadcast ARP request, not an ARP reply from the
>    target.
>    
>    	This logic can fail if there is no currently active slave.  In
>    this situation, the ARP probe logic cycles through all slaves, assigning
>    each in turn as the "current_arp_slave" for one arp_interval, then setting
>    that one as "active," and sending an ARP probe from that slave.  The
>    current logic expects the ARP reply to arrive on the sending
>    current_arp_slave, however, due to switch FDB updating delays, the reply
>    may be directed to another slave.
>    
>    	This can arise if the bonding slaves and switch are working, but
>    the ARP target is not responding.  When the ARP target recovers, a
>    condition may result wherein the ARP target host replies faster than the
>    switch can update its forwarding table, causing each ARP reply to be sent
>    to the previous current_arp_slave.  This will never pass the logic in
>    bond_arp_rcv, as neither of the above conditions (a) or (b) are met.
>    
>    	Some experimentation on a LAN shows ARP reply round trips in the
>    200 usec range, but my available switches never update their FDB in less
>    than 4000 usec.
>    
>    	This patch changes the logic in bond_arp_rcv to additionally
>    accept an ARP reply for validation on any slave if there is a current ARP
>    slave and it sent an ARP probe during the previous arp_interval.
>    
>    Fixes: aeea64ac717a ("bonding: don't trust arp requests unless active slave really works")
>    Cc: Veaceslav Falico <vfalico@gmail.com>
>    Cc: Andy Gospodarek <gospo@cumulusnetworks.com>
>    Signed-off-by: Jay Vosburgh <jay.vosburgh@canonical.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0f912f6700a3f14481c13cbda2b9cc1b636948ac
>Author: Daniel Borkmann <daniel@iogearbox.net>
>Date:   Wed Feb 10 16:47:11 2016 +0100
>
>    bpf: fix branch offset adjustment on backjumps after patching ctx expansion
>    
>    [ Upstream commit a1b14d27ed0965838350f1377ff97c93ee383492 ]
>    
>    When ctx access is used, the kernel often needs to expand/rewrite
>    instructions, so after that patching, branch offsets have to be
>    adjusted for both forward and backward jumps in the new eBPF program,
>    but for backward jumps it fails to account the delta. Meaning, for
>    example, if the expansion happens exactly on the insn that sits at
>    the jump target, it doesn't fix up the back jump offset.
>    
>    Analysis on what the check in adjust_branches() is currently doing:
>    
>      /* adjust offset of jmps if necessary */
>      if (i < pos && i + insn->off + 1 > pos)
>        insn->off += delta;
>      else if (i > pos && i + insn->off + 1 < pos)
>        insn->off -= delta;
>    
>    First condition (forward jumps):
>    
>      Before:                         After:
>    
>      insns[0]                        insns[0]
>      insns[1] <--- i/insn            insns[1] <--- i/insn
>      insns[2] <--- pos               insns[P] <--- pos
>      insns[3]                        insns[P]  `------| delta
>      insns[4] <--- target_X          insns[P]   `-----|
>      insns[5]                        insns[3]
>                                      insns[4] <--- target_X
>                                      insns[5]
>    
>    First case is if we cross pos-boundary and the jump instruction was
>    before pos. This is handeled correctly. I.e. if i == pos, then this
>    would mean our jump that we currently check was the patchlet itself
>    that we just injected. Since such patchlets are self-contained and
>    have no awareness of any insns before or after the patched one, the
>    delta is correctly not adjusted. Also, for the second condition in
>    case of i + insn->off + 1 == pos, means we jump to that newly patched
>    instruction, so no offset adjustment are needed. That part is correct.
>    
>    Second condition (backward jumps):
>    
>      Before:                         After:
>    
>      insns[0]                        insns[0]
>      insns[1] <--- target_X          insns[1] <--- target_X
>      insns[2] <--- pos <-- target_Y  insns[P] <--- pos <-- target_Y
>      insns[3]                        insns[P]  `------| delta
>      insns[4] <--- i/insn            insns[P]   `-----|
>      insns[5]                        insns[3]
>                                      insns[4] <--- i/insn
>                                      insns[5]
>    
>    Second interesting case is where we cross pos-boundary and the jump
>    instruction was after pos. Backward jump with i == pos would be
>    impossible and pose a bug somewhere in the patchlet, so the first
>    condition checking i > pos is okay only by itself. However, i +
>    insn->off + 1 < pos does not always work as intended to trigger the
>    adjustment. It works when jump targets would be far off where the
>    delta wouldn't matter. But, for example, where the fixed insn->off
>    before pointed to pos (target_Y), it now points to pos + delta, so
>    that additional room needs to be taken into account for the check.
>    This means that i) both tests here need to be adjusted into pos + delta,
>    and ii) for the second condition, the test needs to be <= as pos
>    itself can be a target in the backjump, too.
>    
>    Fixes: 9bac3d6d548e ("bpf: allow extended BPF programs access skb fields")
>    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f68887de614bcf857651c0d2e24cfc3004dc20e4
>Author: Alexander Duyck <aduyck@mirantis.com>
>Date:   Tue Feb 9 06:14:43 2016 -0800
>
>    net: Copy inner L3 and L4 headers as unaligned on GRE TEB
>    
>    [ Upstream commit 78565208d73ca9b654fb9a6b142214d52eeedfd1 ]
>    
>    This patch corrects the unaligned accesses seen on GRE TEB tunnels when
>    generating hash keys.  Specifically what this patch does is make it so that
>    we force the use of skb_copy_bits when the GRE inner headers will be
>    unaligned due to NET_IP_ALIGNED being a non-zero value.
>    
>    Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
>    Acked-by: Tom Herbert <tom@herbertland.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 916f99656dc7d69355cb1045530c421cb1976590
>Author: Alexander Duyck <aduyck@mirantis.com>
>Date:   Tue Feb 9 02:49:54 2016 -0800
>
>    flow_dissector: Fix unaligned access in __skb_flow_dissector when used by eth_get_headlen
>    
>    [ Upstream commit 461547f3158978c180d74484d58e82be9b8e7357, since
>      we lack the flow dissector flags in this release we guard the
>      flow label access using a test on 'skb' being NULL ]
>    
>    This patch fixes an issue with unaligned accesses when using
>    eth_get_headlen on a page that was DMA aligned instead of being IP aligned.
>    The fact is when trying to check the length we don't need to be looking at
>    the flow label so we can reorder the checks to first check if we are
>    supposed to gather the flow label and then make the call to actually get
>    it.
>    
>    v2:  Updated path so that either STOP_AT_FLOW_LABEL or KEY_FLOW_LABEL can
>         cause us to check for the flow label.
>    
>    Reported-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
>    Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit bb6f76ba4c6b29e4650310982dc61639d34fa833
>Author: Xin Long <lucien.xin@gmail.com>
>Date:   Wed Feb 3 23:33:30 2016 +0800
>
>    sctp: translate network order to host order when users get a hmacid
>    
>    [ Upstream commit 7a84bd46647ff181eb2659fdc99590e6f16e501d ]
>    
>    Commit ed5a377d87dc ("sctp: translate host order to network order when
>    setting a hmacid") corrected the hmacid byte-order when setting a hmacid.
>    but the same issue also exists on getting a hmacid.
>    
>    We fix it by changing hmacids to host order when users get them with
>    getsockopt.
>    
>    Fixes: Commit ed5a377d87dc ("sctp: translate host order to network order when setting a hmacid")
>    Signed-off-by: Xin Long <lucien.xin@gmail.com>
>    Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit beb9881442593e9de581bf7d5396788cfedcdbd3
>Author: Siva Reddy Kallam <siva.kallam@broadcom.com>
>Date:   Wed Feb 3 14:09:38 2016 +0530
>
>    tg3: Fix for tg3 transmit queue 0 timed out when too many gso_segs
>    
>    [ Upstream commit b7d987295c74500b733a0ba07f9a9bcc4074fa83 ]
>    
>    tg3_tso_bug() can hit a condition where the entire tx ring is not big
>    enough to segment the GSO packet. For example, if MSS is very small,
>    gso_segs can exceed the tx ring size. When we hit the condition, it
>    will cause tx timeout.
>    
>    tg3_tso_bug() is called to handle TSO and DMA hardware bugs.
>    For TSO bugs, if tg3_tso_bug() cannot succeed, we have to drop the packet.
>    For DMA bugs, we can still fall back to linearize the SKB and let the
>    hardware transmit the TSO packet.
>    
>    This patch adds a function tg3_tso_bug_gso_check() to check if there
>    are enough tx descriptors for GSO before calling tg3_tso_bug().
>    The caller will then handle the error appropriately - drop or
>    lineraize the SKB.
>    
>    v2: Corrected patch description to avoid confusion.
>    
>    Signed-off-by: Siva Reddy Kallam <siva.kallam@broadcom.com>
>    Signed-off-by: Michael Chan <mchan@broadcom.com>
>    Acked-by: Prashant Sreedharan <prashant@broadcom.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3faf465445a1d8677b860eee894aecc3d2e32cc6
>Author: Hans Westgaard Ry <hans.westgaard.ry@oracle.com>
>Date:   Wed Feb 3 09:26:57 2016 +0100
>
>    net:Add sysctl_max_skb_frags
>    
>    [ Upstream commit 5f74f82ea34c0da80ea0b49192bb5ea06e063593 ]
>    
>    Devices may have limits on the number of fragments in an skb they support.
>    Current codebase uses a constant as maximum for number of fragments one
>    skb can hold and use.
>    When enabling scatter/gather and running traffic with many small messages
>    the codebase uses the maximum number of fragments and may thereby violate
>    the max for certain devices.
>    The patch introduces a global variable as max number of fragments.
>    
>    Signed-off-by: Hans Westgaard Ry <hans.westgaard.ry@oracle.com>
>    Reviewed-by: HÃ¥kon Bugge <haakon.bugge@oracle.com>
>    Acked-by: Eric Dumazet <edumazet@google.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 797c009c98dbb21127a2549d1106ed19d18661cf
>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
>    
>    [ Upstream commit 415e3d3e90ce9e18727e8843ae343eda5a58fad6 ]
>    
>    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: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6c92a8f0502d3e9a9036473408f7f67b58f22ea9
>Author: Eric Dumazet <edumazet@google.com>
>Date:   Tue Feb 2 17:55:01 2016 -0800
>
>    ipv6: fix a lockdep splat
>    
>    [ Upstream commit 44c3d0c1c0a880354e9de5d94175742e2c7c9683 ]
>    
>    Silence lockdep false positive about rcu_dereference() being
>    used in the wrong context.
>    
>    First one should use rcu_dereference_protected() as we own the spinlock.
>    
>    Second one should be a normal assignation, as no barrier is needed.
>    
>    Fixes: 18367681a10bd ("ipv6 flowlabel: Convert np->ipv6_fl_list to RCU.")
>    Reported-by: Dave Jones <davej@codemonkey.org.uk>
>    Signed-off-by: Eric Dumazet <edumazet@google.com>
>    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9f88ecf6c707ef3a6e26a8bd58e948728d2093d6
>Author: subashab@codeaurora.org <subashab@codeaurora.org>
>Date:   Tue Feb 2 02:11:10 2016 +0000
>
>    ipv6: addrconf: Fix recursive spin lock call
>    
>    [ Upstream commit 16186a82de1fdd868255448274e64ae2616e2640 ]
>    
>    A rcu stall with the following backtrace was seen on a system with
>    forwarding, optimistic_dad and use_optimistic set. To reproduce,
>    set these flags and allow ipv6 autoconf.
>    
>    This occurs because the device write_lock is acquired while already
>    holding the read_lock. Back trace below -
>    
>    INFO: rcu_preempt self-detected stall on CPU { 1}  (t=2100 jiffies
>     g=3992 c=3991 q=4471)
>    <6> Task dump for CPU 1:
>    <2> kworker/1:0     R  running task    12168    15   2 0x00000002
>    <2> Workqueue: ipv6_addrconf addrconf_dad_work
>    <6> Call trace:
>    <2> [<ffffffc000084da8>] el1_irq+0x68/0xdc
>    <2> [<ffffffc000cc4e0c>] _raw_write_lock_bh+0x20/0x30
>    <2> [<ffffffc000bc5dd8>] __ipv6_dev_ac_inc+0x64/0x1b4
>    <2> [<ffffffc000bcbd2c>] addrconf_join_anycast+0x9c/0xc4
>    <2> [<ffffffc000bcf9f0>] __ipv6_ifa_notify+0x160/0x29c
>    <2> [<ffffffc000bcfb7c>] ipv6_ifa_notify+0x50/0x70
>    <2> [<ffffffc000bd035c>] addrconf_dad_work+0x314/0x334
>    <2> [<ffffffc0000b64c8>] process_one_work+0x244/0x3fc
>    <2> [<ffffffc0000b7324>] worker_thread+0x2f8/0x418
>    <2> [<ffffffc0000bb40c>] kthread+0xe0/0xec
>    
>    v2: do addrconf_dad_kick inside read lock and then acquire write
>    lock for ipv6_ifa_notify as suggested by Eric
>    
>    Fixes: 7fd2561e4ebdd ("net: ipv6: Add a sysctl to make optimistic
>    addresses useful candidates")
>    
>    Cc: Eric Dumazet <edumazet@google.com>
>    Cc: Erik Kline <ek@google.com>
>    Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
>    Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
>    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
>    Acked-by: Eric Dumazet <edumazet@google.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d07f3017baa86b3e44eff41a41e3b297604ac8fb
>Author: Hangbin Liu <liuhangbin@gmail.com>
>Date:   Thu Jul 30 14:28:42 2015 +0800
>
>    net/ipv6: add sysctl option accept_ra_min_hop_limit
>    
>    [ Upstream commit 8013d1d7eafb0589ca766db6b74026f76b7f5cb4 ]
>    
>    Commit 6fd99094de2b ("ipv6: Don't reduce hop limit for an interface")
>    disabled accept hop limit from RA if it is smaller than the current hop
>    limit for security stuff. But this behavior kind of break the RFC definition.
>    
>    RFC 4861, 6.3.4.  Processing Received Router Advertisements
>       A Router Advertisement field (e.g., Cur Hop Limit, Reachable Time,
>       and Retrans Timer) may contain a value denoting that it is
>       unspecified.  In such cases, the parameter should be ignored and the
>       host should continue using whatever value it is already using.
>    
>       If the received Cur Hop Limit value is non-zero, the host SHOULD set
>       its CurHopLimit variable to the received value.
>    
>    So add sysctl option accept_ra_min_hop_limit to let user choose the minimum
>    hop limit value they can accept from RA. And set default to 1 to meet RFC
>    standards.
>    
>    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
>    Acked-by: YOSHIFUJI Hideaki <hideaki.yoshifuji@miraclelinux.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d04aa950dbd249222f87c96fac9c547890524f5a
>Author: Paolo Abeni <pabeni@redhat.com>
>Date:   Fri Jan 29 12:30:20 2016 +0100
>
>    ipv6/udp: use sticky pktinfo egress ifindex on connect()
>    
>    [ Upstream commit 1cdda91871470f15e79375991bd2eddc6e86ddb1 ]
>    
>    Currently, the egress interface index specified via IPV6_PKTINFO
>    is ignored by __ip6_datagram_connect(), so that RFC 3542 section 6.7
>    can be subverted when the user space application calls connect()
>    before sendmsg().
>    Fix it by initializing properly flowi6_oif in connect() before
>    performing the route lookup.
>    
>    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
>    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0c6943f31317d02178f55b882e36e03f4e5795f7
>Author: Paolo Abeni <pabeni@redhat.com>
>Date:   Fri Jan 29 12:30:19 2016 +0100
>
>    ipv6: enforce flowi6_oif usage in ip6_dst_lookup_tail()
>    
>    [ Upstream commit 6f21c96a78b835259546d8f3fb4edff0f651d478 ]
>    
>    The current implementation of ip6_dst_lookup_tail basically
>    ignore the egress ifindex match: if the saddr is set,
>    ip6_route_output() purposefully ignores flowi6_oif, due
>    to the commit d46a9d678e4c ("net: ipv6: Dont add RT6_LOOKUP_F_IFACE
>    flag if saddr set"), if the saddr is 'any' the first route lookup
>    in ip6_dst_lookup_tail fails, but upon failure a second lookup will
>    be performed with saddr set, thus ignoring the ifindex constraint.
>    
>    This commit adds an output route lookup function variant, which
>    allows the caller to specify lookup flags, and modify
>    ip6_dst_lookup_tail() to enforce the ifindex match on the second
>    lookup via said helper.
>    
>    ip6_route_output() becames now a static inline function build on
>    top of ip6_route_output_flags(); as a side effect, out-of-tree
>    modules need now a GPL license to access the output route lookup
>    functionality.
>    
>    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
>    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
>    Acked-by: David Ahern <dsa@cumulusnetworks.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1987c92ad0381beab46a65f79827d650de533584
>Author: Eric Dumazet <edumazet@google.com>
>Date:   Wed Jan 27 10:52:43 2016 -0800
>
>    tcp: beware of alignments in tcp_get_info()
>    
>    [ Upstream commit ff5d749772018602c47509bdc0093ff72acd82ec ]
>    
>    With some combinations of user provided flags in netlink command,
>    it is possible to call tcp_get_info() with a buffer that is not 8-bytes
>    aligned.
>    
>    It does matter on some arches, so we need to use put_unaligned() to
>    store the u64 fields.
>    
>    Current iproute2 package does not trigger this particular issue.
>    
>    Fixes: 0df48c26d841 ("tcp: add tcpi_bytes_acked to tcp_info")
>    Fixes: 977cb0ecf82e ("tcp: add pacing_rate information into tcp_info")
>    Signed-off-by: Eric Dumazet <edumazet@google.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4c62ddf7e39943b356157b4c2196a71825c8328c
>Author: Ido Schimmel <idosch@mellanox.com>
>Date:   Wed Jan 27 15:16:43 2016 +0100
>
>    switchdev: Require RTNL mutex to be held when sending FDB notifications
>    
>    [ Upstream commit 4f2c6ae5c64c353fb1b0425e4747e5603feadba1 ]
>    
>    When switchdev drivers process FDB notifications from the underlying
>    device they resolve the netdev to which the entry points to and notify
>    the bridge using the switchdev notifier.
>    
>    However, since the RTNL mutex is not held there is nothing preventing
>    the netdev from disappearing in the middle, which will cause
>    br_switchdev_event() to dereference a non-existing netdev.
>    
>    Make switchdev drivers hold the lock at the beginning of the
>    notification processing session and release it once it ends, after
>    notifying the bridge.
>    
>    Also, remove switchdev_mutex and fdb_lock, as they are no longer needed
>    when RTNL mutex is held.
>    
>    Fixes: 03bf0c281234 ("switchdev: introduce switchdev notifier")
>    Signed-off-by: Ido Schimmel <idosch@mellanox.com>
>    Signed-off-by: Jiri Pirko <jiri@mellanox.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 257a04782588b4b97ac005a044f85947f792be44
>Author: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
>Date:   Wed Jan 27 11:35:59 2016 +0100
>
>    tipc: fix connection abort during subscription cancel
>    
>    [ Upstream commit 4d5cfcba2f6ec494d8810b9e3c0a7b06255c8067 ]
>    
>    In 'commit 7fe8097cef5f ("tipc: fix nullpointer bug when subscribing
>    to events")', we terminate the connection if the subscription
>    creation fails.
>    In the same commit, the subscription creation result was based on
>    the value of the subscription pointer (set in the function) instead
>    of the return code.
>    
>    Unfortunately, the same function tipc_subscrp_create() handles
>    subscription cancel request. For a subscription cancellation request,
>    the subscription pointer cannot be set. Thus if a subscriber has
>    several subscriptions and cancels any of them, the connection is
>    terminated.
>    
>    In this commit, we terminate the connection based on the return value
>    of tipc_subscrp_create().
>    Fixes: commit 7fe8097cef5f ("tipc: fix nullpointer bug when subscribing to events")
>    
>    Reviewed-by:  Jon Maloy <jon.maloy@ericsson.com>
>    Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6e13e7b0183e0b9945ff350bd5fad573c2ece83c
>Author: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
>Date:   Fri Jan 22 18:29:49 2016 -0200
>
>    sctp: allow setting SCTP_SACK_IMMEDIATELY by the application
>    
>    [ Upstream commit 27f7ed2b11d42ab6d796e96533c2076ec220affc ]
>    
>    This patch extends commit b93d6471748d ("sctp: implement the sender side
>    for SACK-IMMEDIATELY extension") as it didn't white list
>    SCTP_SACK_IMMEDIATELY on sctp_msghdr_parse(), causing it to be
>    understood as an invalid flag and returning -EINVAL to the application.
>    
>    Note that the actual handling of the flag is already there in
>    sctp_datamsg_from_user().
>    
>    https://tools.ietf.org/html/rfc7053#section-7
>    
>    Fixes: b93d6471748d ("sctp: implement the sender side for SACK-IMMEDIATELY extension")
>    Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
>    Acked-by: Vlad Yasevich <vyasevich@gmail.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ce28c3ced53aa6385eafeabaeb9c70eca9e3b1ba
>Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
>Date:   Fri Jan 22 01:39:43 2016 +0100
>
>    pptp: fix illegal memory access caused by multiple bind()s
>    
>    [ Upstream commit 9a368aff9cb370298fa02feeffa861f2db497c18 ]
>    
>    Several times already this has been reported as kasan reports caused by
>    syzkaller and trinity and people always looked at RCU races, but it is
>    much more simple. :)
>    
>    In case we bind a pptp socket multiple times, we simply add it to
>    the callid_sock list but don't remove the old binding. Thus the old
>    socket stays in the bucket with unused call_id indexes and doesn't get
>    cleaned up. This causes various forms of kasan reports which were hard
>    to pinpoint.
>    
>    Simply don't allow multiple binds and correct error handling in
>    pptp_bind. Also keep sk_state bits in place in pptp_connect.
>    
>    Fixes: 00959ade36acad ("PPTP: PPP over IPv4 (Point-to-Point Tunneling Protocol)")
>    Cc: Dmitry Kozlov <xeb@mail.ru>
>    Cc: Sasha Levin <sasha.levin@oracle.com>
>    Cc: Dmitry Vyukov <dvyukov@google.com>
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Cc: Dave Jones <davej@codemonkey.org.uk>
>    Reported-by: Dave Jones <davej@codemonkey.org.uk>
>    Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8d988538da0c17711c0de0a53fc38cef49e3ed1b
>Author: Eric Dumazet <edumazet@google.com>
>Date:   Sun Jan 24 13:53:50 2016 -0800
>
>    af_unix: fix struct pid memory leak
>    
>    [ Upstream commit fa0dc04df259ba2df3ce1920e9690c7842f8fa4b ]
>    
>    Dmitry reported a struct pid leak detected by a syzkaller program.
>    
>    Bug happens in unix_stream_recvmsg() when we break the loop when a
>    signal is pending, without properly releasing scm.
>    
>    Fixes: b3ca9b02b007 ("net: fix multithreaded signal handling in unix recv routines")
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Signed-off-by: Eric Dumazet <edumazet@google.com>
>    Cc: Rainer Weikusat <rweikusat@mobileactivedefense.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 93493f5aaff542f0d542c48a3fda2dea1afe5e9e
>Author: Eric Dumazet <edumazet@google.com>
>Date:   Thu Jan 21 08:02:54 2016 -0800
>
>    tcp: fix NULL deref in tcp_v4_send_ack()
>    
>    [ Upstream commit e62a123b8ef7c5dc4db2c16383d506860ad21b47 ]
>    
>    Neal reported crashes with this stack trace :
>    
>     RIP: 0010:[<ffffffff8c57231b>] tcp_v4_send_ack+0x41/0x20f
>    ...
>     CR2: 0000000000000018 CR3: 000000044005c000 CR4: 00000000001427e0
>    ...
>      [<ffffffff8c57258e>] tcp_v4_reqsk_send_ack+0xa5/0xb4
>      [<ffffffff8c1a7caa>] tcp_check_req+0x2ea/0x3e0
>      [<ffffffff8c19e420>] tcp_rcv_state_process+0x850/0x2500
>      [<ffffffff8c1a6d21>] tcp_v4_do_rcv+0x141/0x330
>      [<ffffffff8c56cdb2>] sk_backlog_rcv+0x21/0x30
>      [<ffffffff8c098bbd>] tcp_recvmsg+0x75d/0xf90
>      [<ffffffff8c0a8700>] inet_recvmsg+0x80/0xa0
>      [<ffffffff8c17623e>] sock_aio_read+0xee/0x110
>      [<ffffffff8c066fcf>] do_sync_read+0x6f/0xa0
>      [<ffffffff8c0673a1>] SyS_read+0x1e1/0x290
>      [<ffffffff8c5ca262>] system_call_fastpath+0x16/0x1b
>    
>    The problem here is the skb we provide to tcp_v4_send_ack() had to
>    be parked in the backlog of a new TCP fastopen child because this child
>    was owned by the user at the time an out of window packet arrived.
>    
>    Before queuing a packet, TCP has to set skb->dev to NULL as the device
>    could disappear before packet is removed from the queue.
>    
>    Fix this issue by using the net pointer provided by the socket (being a
>    timewait or a request socket).
>    
>    IPv6 is immune to the bug : tcp_v6_send_response() already gets the net
>    pointer from the socket if provided.
>    
>    Fixes: 168a8f58059a ("tcp: TCP Fast Open Server - main code path")
>    Reported-by: Neal Cardwell <ncardwell@google.com>
>    Signed-off-by: Eric Dumazet <edumazet@google.com>
>    Cc: Jerry Chu <hkchu@google.com>
>    Cc: Yuchung Cheng <ycheng@google.com>
>    Acked-by: Neal Cardwell <ncardwell@google.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0c0c5254583eb9a77e62a4391094258907e08ea1
>Author: Manfred Rudigier <Manfred.Rudigier@omicron.at>
>Date:   Wed Jan 20 11:22:28 2016 +0100
>
>    net: dp83640: Fix tx timestamp overflow handling.
>    
>    [ Upstream commit 81e8f2e930fe76b9814c71b9d87c30760b5eb705 ]
>    
>    PHY status frames are not reliable, the PHY may not be able to send them
>    during heavy receive traffic. This overflow condition is signaled by the
>    PHY in the next status frame, but the driver did not make use of it.
>    Instead it always reported wrong tx timestamps to user space after an
>    overflow happened because it assigned newly received tx timestamps to old
>    packets in the queue.
>    
>    This commit fixes this issue by clearing the tx timestamp queue every time
>    an overflow happens, so that no timestamps are delivered for overflow
>    packets. This way time stamping will continue correctly after an overflow.
>    
>    Signed-off-by: Manfred Rudigier <manfred.rudigier@omicron.at>
>    Acked-by: Richard Cochran <richardcochran@gmail.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 257ed6d440536351b9ceca7005ee89fbcc352b75
>Author: Ursula Braun <ursula.braun@de.ibm.com>
>Date:   Tue Jan 19 10:41:33 2016 +0100
>
>    af_iucv: Validate socket address length in iucv_sock_bind()
>    
>    [ Upstream commit 52a82e23b9f2a9e1d429c5207f8575784290d008 ]
>    
>    Signed-off-by: Ursula Braun <ursula.braun@de.ibm.com>
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Reviewed-by: Evgeny Cherkashin <Eugene.Crosser@ru.ibm.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 35cc814663e4f3515fb6bae8a3b5c188aa2b6f89
>Author: Gavin Shan <gwshan@linux.vnet.ibm.com>
>Date:   Tue Mar 1 16:02:43 2016 +1100
>
>    powerpc/eeh: Fix build error caused by pci_dn
>    
>    eeh.h could be included when we have following condition. Then we
>    run into build error as below: (CONFIG_PPC64 && !CONFIG_EEH) ||
>    (!CONFIG_PPC64 && !CONFIG_EEH)
>    
>    In file included from arch/powerpc/kernel/of_platform.c:30:0:
>    ./arch/powerpc/include/asm/eeh.h:344:48: error: âstruct pci_dnâ \
>    declared inside parameter list [-Werror]
>        :
>    In file included from arch/powerpc/mm/hash_utils_64.c:49:0:
>    ./arch/powerpc/include/asm/eeh.h:344:48: error: âstruct pci_dnâ \
>    declared inside parameter list [-Werror]
>    
>    This fixes the issue by replacing those empty inline functions
>    with macro so that we don't rely on @pci_dn when CONFIG_EEH is
>    disabled.
>    
>    Cc: stable@vger.kernel.org # v4.1+
>    Fixes: ff57b45 ("powerpc/eeh: Do probe on pci_dn")
>    Reported-by: Guenter Roeck <linux@roeck-us.net>
>    Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 62adae8f26b918f4403129e355d81301a629b6a2
>Author: Jan Kara <jack@suse.cz>
>Date:   Fri Feb 19 00:33:21 2016 -0500
>
>    ext4: fix crashes in dioread_nolock mode
>    
>    [ Upstream commit 74dae4278546b897eb81784fdfcce872ddd8b2b8 ]
>    
>    Competing overwrite DIO in dioread_nolock mode will just overwrite
>    pointer to io_end in the inode. This may result in data corruption or
>    extent conversion happening from IO completion interrupt because we
>    don't properly set buffer_defer_completion() when unlocked DIO races
>    with locked DIO to unwritten extent.
>    
>    Since unlocked DIO doesn't need io_end for anything, just avoid
>    allocating it and corrupting pointer from inode for locked DIO.
>    A cleaner fix would be to avoid these games with io_end pointer from the
>    inode but that requires more intrusive changes so we leave that for
>    later.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Jan Kara <jack@suse.cz>
>    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5d0e8394db90caa6d06477f68cbdb48fe65f468d
>Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>Date:   Wed Feb 17 13:11:35 2016 -0800
>
>    ipc/shm: handle removed segments gracefully in shm_mmap()
>    
>    [ Upstream commit 15db15e2f10ae12d021c9a2e9edd8a03b9238551 ]
>    
>    commit 1ac0b6dec656f3f78d1c3dd216fad84cb4d0a01e upstream.
>    
>    remap_file_pages(2) emulation can reach file which represents removed
>    IPC ID as long as a memory segment is mapped.  It breaks expectations of
>    IPC subsystem.
>    
>    Test case (rewritten to be more human readable, originally autogenerated
>    by syzkaller[1]):
>    
>    	#define _GNU_SOURCE
>    	#include <stdlib.h>
>    	#include <sys/ipc.h>
>    	#include <sys/mman.h>
>    	#include <sys/shm.h>
>    
>    	#define PAGE_SIZE 4096
>    
>    	int main()
>    	{
>    		int id;
>    		void *p;
>    
>    		id = shmget(IPC_PRIVATE, 3 * PAGE_SIZE, 0);
>    		p = shmat(id, NULL, 0);
>    		shmctl(id, IPC_RMID, NULL);
>    		remap_file_pages(p, 3 * PAGE_SIZE, 0, 7, 0);
>    
>    	        return 0;
>    	}
>    
>    The patch changes shm_mmap() and code around shm_lock() to propagate
>    locking error back to caller of shm_mmap().
>    
>    [1] http://github.com/google/syzkaller
>    
>    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Cc: Davidlohr Bueso <dave@stgolabs.net>
>    Cc: Manfred Spraul <manfred@colorfullife.com>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6e82212c489fcdc50446bff12bd1ed5e8ef110a2
>Author: Davidlohr Bueso <dave@stgolabs.net>
>Date:   Wed Sep 9 15:39:20 2015 -0700
>
>    ipc: convert invalid scenarios to use WARN_ON
>    
>    [ Upstream commit d0edd8528362c07216498340e928159510595e7b ]
>    
>    Considering Linus' past rants about the (ab)use of BUG in the kernel, I
>    took a look at how we deal with such calls in ipc.  Given that any errors
>    or corruption in ipc code are most likely contained within the set of
>    processes participating in the broken mechanisms, there aren't really many
>    strong fatal system failure scenarios that would require a BUG call.
>    Also, if something is seriously wrong, ipc might not be the place for such
>    a BUG either.
>    
>    1. For example, recently, a customer hit one of these BUG_ONs in shm
>       after failing shm_lock().  A busted ID imho does not merit a BUG_ON,
>       and WARN would have been better.
>    
>    2. MSG_COPY functionality of posix msgrcv(2) for checkpoint/restore.
>       I don't see how we can hit this anyway -- at least it should be IS_ERR.
>        The 'copy' arg from do_msgrcv is always set by calling prepare_copy()
>       first and foremost.  We could also probably drop this check altogether.
>        Either way, it does not merit a BUG_ON.
>    
>    3. No ->fault() callback for the fs getting the corresponding page --
>       seems selfish to make the system unusable.
>    
>    Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
>    Cc: Manfred Spraul <manfred@colorfullife.com>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0eba52da056a131ae7d5715e9bae4e147356d3d9
>Author: Davidlohr Bueso <dave@stgolabs.net>
>Date:   Tue Jun 30 14:58:36 2015 -0700
>
>    ipc,shm: move BUG_ON check into shm_lock
>    
>    [ Upstream commit c5c8975b2eb4eb7604e8ce4f762987f56d2a96a2 ]
>    
>    Upon every shm_lock call, we BUG_ON if an error was returned, indicating
>    racing either in idr or in shm_destroy.  Move this logic into the locking.
>    
>    [akpm@linux-foundation.org: simplify code]
>    Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
>    Cc: Manfred Spraul <manfred@colorfullife.com>
>    Cc: Davidlohr Bueso <dave@stgolabs.net>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit aff5e5984051fb83578ef2a30db98747a6e39fa6
>Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>Date:   Wed Feb 17 13:11:15 2016 -0800
>
>    mm: fix regression in remap_file_pages() emulation
>    
>    [ Upstream commit 48f7df329474b49d83d0dffec1b6186647f11976 ]
>    
>    Grazvydas Ignotas has reported a regression in remap_file_pages()
>    emulation.
>    
>    Testcase:
>    	#define _GNU_SOURCE
>    	#include <assert.h>
>    	#include <stdlib.h>
>    	#include <stdio.h>
>    	#include <sys/mman.h>
>    
>    	#define SIZE    (4096 * 3)
>    
>    	int main(int argc, char **argv)
>    	{
>    		unsigned long *p;
>    		long i;
>    
>    		p = mmap(NULL, SIZE, PROT_READ | PROT_WRITE,
>    				MAP_SHARED | MAP_ANONYMOUS, -1, 0);
>    		if (p == MAP_FAILED) {
>    			perror("mmap");
>    			return -1;
>    		}
>    
>    		for (i = 0; i < SIZE / 4096; i++)
>    			p[i * 4096 / sizeof(*p)] = i;
>    
>    		if (remap_file_pages(p, 4096, 0, 1, 0)) {
>    			perror("remap_file_pages");
>    			return -1;
>    		}
>    
>    		if (remap_file_pages(p, 4096 * 2, 0, 1, 0)) {
>    			perror("remap_file_pages");
>    			return -1;
>    		}
>    
>    		assert(p[0] == 1);
>    
>    		munmap(p, SIZE);
>    
>    		return 0;
>    	}
>    
>    The second remap_file_pages() fails with -EINVAL.
>    
>    The reason is that remap_file_pages() emulation assumes that the target
>    vma covers whole area we want to over map.  That assumption is broken by
>    first remap_file_pages() call: it split the area into two vma.
>    
>    The solution is to check next adjacent vmas, if they map the same file
>    with the same flags.
>    
>    Fixes: c8d78c1823f4 ("mm: replace remap_file_pages() syscall with emulation")
>    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>    Reported-by: Grazvydas Ignotas <notasas@gmail.com>
>    Tested-by: Grazvydas Ignotas <notasas@gmail.com>
>    Cc: <stable@vger.kernel.org>	[4.0+]
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit cab48a095169b3f981c600b4365170a076ac9f3a
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Wed Feb 17 14:30:26 2016 +0100
>
>    ALSA: pcm: Fix rwsem deadlock for non-atomic PCM stream
>    
>    [ Upstream commit 67ec1072b053c15564e6090ab30127895dc77a89 ]
>    
>    A non-atomic PCM stream may take snd_pcm_link_rwsem rw semaphore twice
>    in the same code path, e.g. one in snd_pcm_action_nonatomic() and
>    another in snd_pcm_stream_lock().  Usually this is OK, but when a
>    write lock is issued between these two read locks, the problem
>    happens: the write lock is blocked due to the first reade lock, and
>    the second read lock is also blocked by the write lock.  This
>    eventually deadlocks.
>    
>    The reason is the way rwsem manages waiters; it's queued like FIFO, so
>    even if the writer itself doesn't take the lock yet, it blocks all the
>    waiters (including reads) queued after it.
>    
>    As a workaround, in this patch, we replace the standard down_write()
>    with an spinning loop.  This is far from optimal, but it's good
>    enough, as the spinning time is supposed to be relatively short for
>    normal PCM operations, and the code paths requiring the write lock
>    aren't called so often.
>    
>    Reported-by: Vinod Koul <vinod.koul@intel.com>
>    Tested-by: Ramesh Babu <ramesh.babu@intel.com>
>    Cc: <stable@vger.kernel.org> # v3.18+
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 468eeda0837d3e4f1574f800dc460d85e6b49fb7
>Author: Toshi Kani <toshi.kani@hpe.com>
>Date:   Wed Feb 17 18:16:54 2016 -0700
>
>    x86/mm: Fix vmalloc_fault() to handle large pages properly
>    
>    [ Upstream commit f4eafd8bcd5229e998aa252627703b8462c3b90f ]
>    
>    A kernel page fault oops with the callstack below was observed
>    when a read syscall was made to a pmem device after a huge amount
>    (>512GB) of vmalloc ranges was allocated by ioremap() on a x86_64
>    system:
>    
>         BUG: unable to handle kernel paging request at ffff880840000ff8
>         IP: vmalloc_fault+0x1be/0x300
>         PGD c7f03a067 PUD 0
>         Oops: 0000 [#1] SM
>         Call Trace:
>            __do_page_fault+0x285/0x3e0
>            do_page_fault+0x2f/0x80
>            ? put_prev_entity+0x35/0x7a0
>            page_fault+0x28/0x30
>            ? memcpy_erms+0x6/0x10
>            ? schedule+0x35/0x80
>            ? pmem_rw_bytes+0x6a/0x190 [nd_pmem]
>            ? schedule_timeout+0x183/0x240
>            btt_log_read+0x63/0x140 [nd_btt]
>             :
>            ? __symbol_put+0x60/0x60
>            ? kernel_read+0x50/0x80
>            SyS_finit_module+0xb9/0xf0
>            entry_SYSCALL_64_fastpath+0x1a/0xa4
>    
>    Since v4.1, ioremap() supports large page (pud/pmd) mappings in
>    x86_64 and PAE.  vmalloc_fault() however assumes that the vmalloc
>    range is limited to pte mappings.
>    
>    vmalloc faults do not normally happen in ioremap'd ranges since
>    ioremap() sets up the kernel page tables, which are shared by
>    user processes.  pgd_ctor() sets the kernel's PGD entries to
>    user's during fork().  When allocation of the vmalloc ranges
>    crosses a 512GB boundary, ioremap() allocates a new pud table
>    and updates the kernel PGD entry to point it.  If user process's
>    PGD entry does not have this update yet, a read/write syscall
>    to the range will cause a vmalloc fault, which hits the Oops
>    above as it does not handle a large page properly.
>    
>    Following changes are made to vmalloc_fault().
>    
>    64-bit:
>    
>     - No change for the PGD sync operation as it handles large
>       pages already.
>     - Add pud_huge() and pmd_huge() to the validation code to
>       handle large pages.
>     - Change pud_page_vaddr() to pud_pfn() since an ioremap range
>       is not directly mapped (while the if-statement still works
>       with a bogus addr).
>     - Change pmd_page() to pmd_pfn() since an ioremap range is not
>       backed by struct page (while the if-statement still works
>       with a bogus addr).
>    
>    32-bit:
>     - No change for the sync operation since the index3 PGD entry
>       covers the entire vmalloc range, which is always valid.
>       (A separate change to sync PGD entry is necessary if this
>        memory layout is changed regardless of the page size.)
>     - Add pmd_huge() to the validation code to handle large pages.
>       This is for completeness since vmalloc_fault() won't happen
>       in ioremap'd ranges as its PGD entry is always valid.
>    
>    Reported-by: Henning Schild <henning.schild@siemens.com>
>    Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
>    Acked-by: Borislav Petkov <bp@alien8.de>
>    Cc: <stable@vger.kernel.org> # 4.1+
>    Cc: Andrew Morton <akpm@linux-foundation.org>
>    Cc: Andy Lutomirski <luto@amacapital.net>
>    Cc: Brian Gerst <brgerst@gmail.com>
>    Cc: Denys Vlasenko <dvlasenk@redhat.com>
>    Cc: H. Peter Anvin <hpa@zytor.com>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Luis R. Rodriguez <mcgrof@suse.com>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Cc: Toshi Kani <toshi.kani@hp.com>
>    Cc: linux-mm@kvack.org
>    Cc: linux-nvdimm@lists.01.org
>    Link: http://lkml.kernel.org/r/1455758214-24623-1-git-send-email-toshi.kani@hpe.com
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1d1338cfb7c94ffa41b3839a31c5ae332315131e
>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
>    
>    [ Upstream commit 34855706c30d52b0a744da44348b5d1cc39fbe51 ]
>    
>    This avoids integer overflows on 32bit machines when calculating
>    reloc_info size, as reported by Alan Cox.
>    
>    Cc: stable@vger.kernel.org
>    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: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1a82e899582acee9df55a271fb8d6bb73de49fea
>Author: Rasmus Villemoes <linux@rasmusvillemoes.dk>
>Date:   Mon Feb 15 19:41:47 2016 +0100
>
>    drm/radeon: use post-decrement in error handling
>    
>    [ Upstream commit bc3f5d8c4ca01555820617eb3b6c0857e4df710d ]
>    
>    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>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ad4ad1ac3b0aef2779097a298ecc20ef9eef17d6
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Tue Feb 16 14:15:59 2016 +0100
>
>    ALSA: seq: Fix double port list deletion
>    
>    [ Upstream commit 13d5e5d4725c64ec06040d636832e78453f477b7 ]
>    
>    The commit [7f0973e973cd: ALSA: seq: Fix lockdep warnings due to
>    double mutex locks] split the management of two linked lists (source
>    and destination) into two individual calls for avoiding the AB/BA
>    deadlock.  However, this may leave the possible double deletion of one
>    of two lists when the counterpart is being deleted concurrently.
>    It ends up with a list corruption, as revealed by syzkaller fuzzer.
>    
>    This patch fixes it by checking the list emptiness and skipping the
>    deletion and the following process.
>    
>    BugLink: http://lkml.kernel.org/r/CACT4Y+bay9qsrz6dQu31EcGaH9XwfW7o3oBzSQUG9fMszoh=Sg@mail.gmail.com
>    Fixes: 7f0973e973cd ('ALSA: seq: Fix lockdep warnings due to 'double mutex locks)
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Tested-by: Dmitry Vyukov <dvyukov@google.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a77b1f3d1928a8c31ee0e088e52404331aed5dd5
>Author: Arnd Bergmann <arnd@arndb.de>
>Date:   Fri Feb 12 22:26:42 2016 +0100
>
>    tracing: Fix freak link error caused by branch tracer
>    
>    [ Upstream commit b33c8ff4431a343561e2319f17c14286f2aa52e2 ]
>    
>    In my randconfig tests, I came across a bug that involves several
>    components:
>    
>    * gcc-4.9 through at least 5.3
>    * CONFIG_GCOV_PROFILE_ALL enabling -fprofile-arcs for all files
>    * CONFIG_PROFILE_ALL_BRANCHES overriding every if()
>    * The optimized implementation of do_div() that tries to
>      replace a library call with an division by multiplication
>    * code in drivers/media/dvb-frontends/zl10353.c doing
>    
>            u32 adc_clock = 450560; /* 45.056 MHz */
>            if (state->config.adc_clock)
>                    adc_clock = state->config.adc_clock;
>            do_div(value, adc_clock);
>    
>    In this case, gcc fails to determine whether the divisor
>    in do_div() is __builtin_constant_p(). In particular, it
>    concludes that __builtin_constant_p(adc_clock) is false, while
>    __builtin_constant_p(!!adc_clock) is true.
>    
>    That in turn throws off the logic in do_div() that also uses
>    __builtin_constant_p(), and instead of picking either the
>    constant- optimized division, and the code in ilog2() that uses
>    __builtin_constant_p() to figure out whether it knows the answer at
>    compile time. The result is a link error from failing to find
>    multiple symbols that should never have been called based on
>    the __builtin_constant_p():
>    
>    dvb-frontends/zl10353.c:138: undefined reference to `____ilog2_NaN'
>    dvb-frontends/zl10353.c:138: undefined reference to `__aeabi_uldivmod'
>    ERROR: "____ilog2_NaN" [drivers/media/dvb-frontends/zl10353.ko] undefined!
>    ERROR: "__aeabi_uldivmod" [drivers/media/dvb-frontends/zl10353.ko] undefined!
>    
>    This patch avoids the problem by changing __trace_if() to check
>    whether the condition is known at compile-time to be nonzero, rather
>    than checking whether it is actually a constant.
>    
>    I see this one link error in roughly one out of 1600 randconfig builds
>    on ARM, and the patch fixes all known instances.
>    
>    Link: http://lkml.kernel.org/r/1455312410-1058841-1-git-send-email-arnd@arndb.de
>    
>    Acked-by: Nicolas Pitre <nico@linaro.org>
>    Fixes: ab3c9c686e22 ("branch tracer, intel-iommu: fix build with CONFIG_BRANCH_TRACER=y")
>    Cc: stable@vger.kernel.org # v2.6.30+
>    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 999c2ceac0bcd8cb773e627151e4afaefe653427
>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
>    
>    [ Upstream commit f37755490fe9bf76f6ba1d8c6591745d3574a6a6 ]
>    
>    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")
>    Cc: stable@vger.kernel.org # v2.6.28+
>    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6bdec2b3a4bf4ecc5f9ba5ea24457fe57943fc61
>Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>Date:   Wed Feb 10 15:59:42 2016 +0200
>
>    dmaengine: dw: disable BLOCK IRQs for non-cyclic xfer
>    
>    [ Upstream commit ee1cdcdae59563535485a5f56ee72c894ab7d7ad ]
>    
>    The commit 2895b2cad6e7 ("dmaengine: dw: fix cyclic transfer callbacks")
>    re-enabled BLOCK interrupts with regard to make cyclic transfers work. However,
>    this change becomes a regression for non-cyclic transfers as interrupt counters
>    under stress test had been grown enormously (approximately per 4-5 bytes in the
>    UART loop back test).
>    
>    Taking into consideration above enable BLOCK interrupts if and only if channel
>    is programmed to perform cyclic transfer.
>    
>    Fixes: 2895b2cad6e7 ("dmaengine: dw: fix cyclic transfer callbacks")
>    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>    Acked-by: Mans Rullgard <mans@mansr.com>
>    Tested-by: Mans Rullgard <mans@mansr.com>
>    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 800b26634a89a88bbbc341c4d1e84f5141c1e38a
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Mon Feb 15 16:37:24 2016 +0100
>
>    ALSA: hda - Cancel probe work instead of flush at remove
>    
>    [ Upstream commit 0b8c82190c12e530eb6003720dac103bf63e146e ]
>    
>    The commit [991f86d7ae4e: ALSA: hda - Flush the pending probe work at
>    remove] introduced the sync of async probe work at remove for fixing
>    the race.  However, this may lead to another hangup when the module
>    removal is performed quickly before starting the probe work, because
>    it issues flush_work() and it's blocked forever.
>    
>    The workaround is to use cancel_work_sync() instead of flush_work()
>    there.
>    
>    Fixes: 991f86d7ae4e ('ALSA: hda - Flush the pending probe work at remove')
>    Cc: <stable@vger.kernel.org> # v3.17+
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d26d8b485d21ecc9e466b2a1e02c5962e46624de
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Mon Feb 15 16:20:24 2016 +0100
>
>    ALSA: seq: Fix leak of pool buffer at concurrent writes
>    
>    [ Upstream commit d99a36f4728fcbcc501b78447f625bdcce15b842 ]
>    
>    When multiple concurrent writes happen on the ALSA sequencer device
>    right after the open, it may try to allocate vmalloc buffer for each
>    write and leak some of them.  It's because the presence check and the
>    assignment of the buffer is done outside the spinlock for the pool.
>    
>    The fix is to move the check and the assignment into the spinlock.
>    
>    (The current implementation is suboptimal, as there can be multiple
>     unnecessary vmallocs because the allocation is done before the check
>     in the spinlock.  But the pool size is already checked beforehand, so
>     this isn't a big problem; that is, the only possible path is the
>     multiple writes before any pool assignment, and practically seen, the
>     current coverage should be "good enough".)
>    
>    The issue was triggered by syzkaller fuzzer.
>    
>    BugLink: http://lkml.kernel.org/r/CACT4Y+bSzazpXNvtAr=WXaL8hptqjHwqEyFA+VN2AWEx=aurkg@mail.gmail.com
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Tested-by: Dmitry Vyukov <dvyukov@google.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 712394523149ed77377fcc9a264ac35245bd16a3
>Author: Gavin Shan <gwshan@linux.vnet.ibm.com>
>Date:   Tue Feb 9 15:50:21 2016 +1100
>
>    powerpc/eeh: Fix stale cached primary bus
>    
>    [ Upstream commit 05ba75f848647135f063199dc0e9f40fee769724 ]
>    
>    When PE is created, its primary bus is cached to pe->bus. At later
>    point, the cached primary bus is returned from eeh_pe_bus_get().
>    However, we could get stale cached primary bus and run into kernel
>    crash in one case: full hotplug as part of fenced PHB error recovery
>    releases all PCI busses under the PHB at unplugging time and recreate
>    them at plugging time. pe->bus is still dereferencing the PCI bus
>    that was released.
>    
>    This adds another PE flag (EEH_PE_PRI_BUS) to represent the validity
>    of pe->bus. pe->bus is updated when its first child EEH device is
>    online and the flag is set. Before unplugging in full hotplug for
>    error recovery, the flag is cleared.
>    
>    Fixes: 8cdb2833 ("powerpc/eeh: Trace PCI bus from PE")
>    Cc: stable@vger.kernel.org #v3.11+
>    Reported-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
>    Reported-by: Pradipta Ghosh <pradghos@in.ibm.com>
>    Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
>    Tested-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
>    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1ea63b629c9c53af6cdde4daf166b3d31b3e9cfe
>Author: Andrey Konovalov <andreyknvl@gmail.com>
>Date:   Sat Feb 13 11:08:06 2016 +0300
>
>    ALSA: usb-audio: avoid freeing umidi object twice
>    
>    [ Upstream commit 07d86ca93db7e5cdf4743564d98292042ec21af7 ]
>    
>    The 'umidi' object will be free'd on the error path by snd_usbmidi_free()
>    when tearing down the rawmidi interface. So we shouldn't try to free it
>    in snd_usbmidi_create() after having registered the rawmidi interface.
>    
>    Found by KASAN.
>    
>    Signed-off-by: Andrey Konovalov <andreyknvl@gmail.com>
>    Acked-by: Clemens Ladisch <clemens@ladisch.de>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f3dd341b9230ac943f317efa4c5b1bfae587434b
>Author: Hannes Reinecke <hare@suse.de>
>Date:   Fri Feb 12 09:39:15 2016 +0100
>
>    bio: return EINTR if copying to user space got interrupted
>    
>    [ Upstream commit 2d99b55d378c996b9692a0c93dd25f4ed5d58934 ]
>    
>    Commit 35dc248383bbab0a7203fca4d722875bc81ef091 introduced a check for
>    current->mm to see if we have a user space context and only copies data
>    if we do. Now if an IO gets interrupted by a signal data isn't copied
>    into user space any more (as we don't have a user space context) but
>    user space isn't notified about it.
>    
>    This patch modifies the behaviour to return -EINTR from bio_uncopy_user()
>    to notify userland that a signal has interrupted the syscall, otherwise
>    it could lead to a situation where the caller may get a buffer with
>    no data returned.
>    
>    This can be reproduced by issuing SG_IO ioctl()s in one thread while
>    constantly sending signals to it.
>    
>    Fixes: 35dc248 [SCSI] sg: Fix user memory corruption when SG_IO is interrupted by a signal
>    Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
>    Signed-off-by: Hannes Reinecke <hare@suse.de>
>    Cc: stable@vger.kernel.org # v.3.11+
>    Signed-off-by: Jens Axboe <axboe@fb.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d185fa457006e98aa975ed6c0e7d2ddfe3d26695
>Author: Ryan Ware <ware@linux.intel.com>
>Date:   Thu Feb 11 15:58:44 2016 -0800
>
>    EVM: Use crypto_memneq() for digest comparisons
>    
>    [ Upstream commit 613317bd212c585c20796c10afe5daaa95d4b0a1 ]
>    
>    This patch fixes vulnerability CVE-2016-2085.  The problem exists
>    because the vm_verify_hmac() function includes a use of memcmp().
>    Unfortunately, this allows timing side channel attacks; specifically
>    a MAC forgery complexity drop from 2^128 to 2^12.  This patch changes
>    the memcmp() to the cryptographically safe crypto_memneq().
>    
>    Reported-by: Xiaofei Rex Guo <xiaofei.rex.guo@intel.com>
>    Signed-off-by: Ryan Ware <ware@linux.intel.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
>    Signed-off-by: James Morris <james.l.morris@oracle.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a285eee1ce6b0efc4bcc2599cd3fd96dd6103e6d
>Author: Eryu Guan <guaneryu@gmail.com>
>Date:   Fri Feb 12 01:20:43 2016 -0500
>
>    ext4: don't read blocks from disk after extents being swapped
>    
>    [ Upstream commit bcff24887d00bce102e0857d7b0a8c44a40f53d1 ]
>    
>    I notice ext4/307 fails occasionally on ppc64 host, reporting md5
>    checksum mismatch after moving data from original file to donor file.
>    
>    The reason is that move_extent_per_page() calls __block_write_begin()
>    and block_commit_write() to write saved data from original inode blocks
>    to donor inode blocks, but __block_write_begin() not only maps buffer
>    heads but also reads block content from disk if the size is not block
>    size aligned.  At this time the physical block number in mapped buffer
>    head is pointing to the donor file not the original file, and that
>    results in reading wrong data to page, which get written to disk in
>    following block_commit_write call.
>    
>    This also can be reproduced by the following script on 1k block size ext4
>    on x86_64 host:
>    
>        mnt=/mnt/ext4
>        donorfile=$mnt/donor
>        testfile=$mnt/testfile
>        e4compact=~/xfstests/src/e4compact
>    
>        rm -f $donorfile $testfile
>    
>        # reserve space for donor file, written by 0xaa and sync to disk to
>        # avoid EBUSY on EXT4_IOC_MOVE_EXT
>        xfs_io -fc "pwrite -S 0xaa 0 1m" -c "fsync" $donorfile
>    
>        # create test file written by 0xbb
>        xfs_io -fc "pwrite -S 0xbb 0 1023" -c "fsync" $testfile
>    
>        # compute initial md5sum
>        md5sum $testfile | tee md5sum.txt
>        # drop cache, force e4compact to read data from disk
>        echo 3 > /proc/sys/vm/drop_caches
>    
>        # test defrag
>        echo "$testfile" | $e4compact -i -v -f $donorfile
>        # check md5sum
>        md5sum -c md5sum.txt
>    
>    Fix it by creating & mapping buffer heads only but not reading blocks
>    from disk, because all the data in page is guaranteed to be up-to-date
>    in mext_page_mkuptodate().
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Eryu Guan <guaneryu@gmail.com>
>    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9d7679794e9cd701890d997a76024b2239f90638
>Author: Insu Yun <wuninsu@gmail.com>
>Date:   Fri Feb 12 01:15:59 2016 -0500
>
>    ext4: fix potential integer overflow
>    
>    [ Upstream commit 46901760b46064964b41015d00c140c83aa05bcf ]
>    
>    Since sizeof(ext_new_group_data) > sizeof(ext_new_flex_group_data),
>    integer overflow could be happened.
>    Therefore, need to fix integer overflow sanitization.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Insu Yun <wuninsu@gmail.com>
>    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3a68deb6673cffe2d66f0f0ace615bc0cb4c1153
>Author: David Sterba <dsterba@suse.com>
>Date:   Fri Nov 13 13:44:28 2015 +0100
>
>    btrfs: properly set the termination value of ctx->pos in readdir
>    
>    [ Upstream commit bc4ef7592f657ae81b017207a1098817126ad4cb ]
>    
>    The value of ctx->pos in the last readdir call is supposed to be set to
>    INT_MAX due to 32bit compatibility, unless 'pos' is intentially set to a
>    larger value, then it's LLONG_MAX.
>    
>    There's a report from PaX SIZE_OVERFLOW plugin that "ctx->pos++"
>    overflows (https://forums.grsecurity.net/viewtopic.php?f=1&t=4284), on a
>    64bit arch, where the value is 0x7fffffffffffffff ie. LLONG_MAX before
>    the increment.
>    
>    We can get to that situation like that:
>    
>    * emit all regular readdir entries
>    * still in the same call to readdir, bump the last pos to INT_MAX
>    * next call to readdir will not emit any entries, but will reach the
>      bump code again, finds pos to be INT_MAX and sets it to LLONG_MAX
>    
>    Normally this is not a problem, but if we call readdir again, we'll find
>    'pos' set to LLONG_MAX and the unconditional increment will overflow.
>    
>    The report from Victor at
>    (http://thread.gmane.org/gmane.comp.file-systems.btrfs/49500) with debugging
>    print shows that pattern:
>    
>     Overflow: e
>     Overflow: 7fffffff
>     Overflow: 7fffffffffffffff
>     PAX: size overflow detected in function btrfs_real_readdir
>       fs/btrfs/inode.c:5760 cicus.935_282 max, count: 9, decl: pos; num: 0;
>       context: dir_context;
>     CPU: 0 PID: 2630 Comm: polkitd Not tainted 4.2.3-grsec #1
>     Hardware name: Gigabyte Technology Co., Ltd. H81ND2H/H81ND2H, BIOS F3 08/11/2015
>      ffffffff81901608 0000000000000000 ffffffff819015e6 ffffc90004973d48
>      ffffffff81742f0f 0000000000000007 ffffffff81901608 ffffc90004973d78
>      ffffffff811cb706 0000000000000000 ffff8800d47359e0 ffffc90004973ed8
>     Call Trace:
>      [<ffffffff81742f0f>] dump_stack+0x4c/0x7f
>      [<ffffffff811cb706>] report_size_overflow+0x36/0x40
>      [<ffffffff812ef0bc>] btrfs_real_readdir+0x69c/0x6d0
>      [<ffffffff811dafc8>] iterate_dir+0xa8/0x150
>      [<ffffffff811e6d8d>] ? __fget_light+0x2d/0x70
>      [<ffffffff811dba3a>] SyS_getdents+0xba/0x1c0
>     Overflow: 1a
>      [<ffffffff811db070>] ? iterate_dir+0x150/0x150
>      [<ffffffff81749b69>] entry_SYSCALL_64_fastpath+0x12/0x83
>    
>    The jump from 7fffffff to 7fffffffffffffff happens when new dir entries
>    are not yet synced and are processed from the delayed list. Then the code
>    could go to the bump section again even though it might not emit any new
>    dir entries from the delayed list.
>    
>    The fix avoids entering the "bump" section again once we've finished
>    emitting the entries, both for synced and delayed entries.
>    
>    References: https://forums.grsecurity.net/viewtopic.php?f=1&t=4284
>    Reported-by: Victor <services@swwu.com>
>    CC: stable@vger.kernel.org
>    Signed-off-by: David Sterba <dsterba@suse.com>
>    Tested-by: Holger HoffstÃ¤tte <holger.hoffstaette@googlemail.com>
>    Signed-off-by: Chris Mason <clm@fb.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1c35d875d020c798da316ddbac5da7be93b6901c
>Author: Linus Walleij <linus.walleij@linaro.org>
>Date:   Wed Feb 10 09:25:17 2016 +0100
>
>    ARM: 8519/1: ICST: try other dividends than 1
>    
>    [ Upstream commit e972c37459c813190461dabfeaac228e00aae259 ]
>    
>    Since the dawn of time the ICST code has only supported divide
>    by one or hang in an eternal loop. Luckily we were always dividing
>    by one because the reference frequency for the systems using
>    the ICSTs is 24MHz and the [min,max] values for the PLL input
>    if [10,320] MHz for ICST307 and [6,200] for ICST525, so the loop
>    will always terminate immediately without assigning any divisor
>    for the reference frequency.
>    
>    But for the code to make sense, let's insert the missing i++
>    
>    Reported-by: David Binderman <dcb314@hotmail.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5ae3f5ad236f18bda2486bc557333427ec8a6797
>Author: Stefan Haberland <stefan.haberland@de.ibm.com>
>Date:   Tue Dec 15 10:45:05 2015 +0100
>
>    s390/dasd: fix refcount for PAV reassignment
>    
>    [ Upstream commit 9d862ababb609439c5d6987f6d3ddd09e703aa0b ]
>    
>    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.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Stefan Haberland <stefan.haberland@de.ibm.com>
>    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2e35e9c4671925a7af5a2d3fe4f5f614e13a0d6d
>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
>    
>    [ Upstream commit 020bf042e5b397479c1174081b935d0ff15d1a64 ]
>    
>    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.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Stefan Haberland <stefan.haberland@de.ibm.com>
>    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4f55047bff0dd28d65e59455fb16d23b8dafcf73
>Author: Anton Protopopov <a.s.protopopov@gmail.com>
>Date:   Wed Feb 10 12:50:21 2016 -0500
>
>    cifs: fix erroneous return value
>    
>    [ Upstream commit 4b550af519854421dfec9f7732cdddeb057134b2 ]
>    
>    The setup_ntlmv2_rsp() function may return positive value ENOMEM instead
>    of -ENOMEM in case of kmalloc failure.
>    
>    Signed-off-by: Anton Protopopov <a.s.protopopov@gmail.com>
>    CC: Stable <stable@vger.kernel.org>
>    Signed-off-by: Steve French <smfrench@gmail.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7071cc9b4f9d4fd6dee20bb8dd760a8f9e1ceec7
>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
>    
>    [ Upstream commit f6ff4f67cdf8455d0a4226eeeaf5af17c37d05eb ]
>    
>    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>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f3d69fd89df665c1fa1931f4af846039a4ac5dc4
>Author: Tejun Heo <tj@kernel.org>
>Date:   Wed Feb 3 13:54:25 2016 -0500
>
>    workqueue: handle NUMA_NO_NODE for unbound pool_workqueue lookup
>    
>    [ Upstream commit d6e022f1d207a161cd88e08ef0371554680ffc46 ]
>    
>    When looking up the pool_workqueue to use for an unbound workqueue,
>    workqueue assumes that the target CPU is always bound to a valid NUMA
>    node.  However, currently, when a CPU goes offline, the mapping is
>    destroyed and cpu_to_node() returns NUMA_NO_NODE.
>    
>    This has always been broken but hasn't triggered often enough before
>    874bbfe600a6 ("workqueue: make sure delayed work run in local cpu").
>    After the commit, workqueue forcifully assigns the local CPU for
>    delayed work items without explicit target CPU to fix a different
>    issue.  This widens the window where CPU can go offline while a
>    delayed work item is pending causing delayed work items dispatched
>    with target CPU set to an already offlined CPU.  The resulting
>    NUMA_NO_NODE mapping makes workqueue try to queue the work item on a
>    NULL pool_workqueue and thus crash.
>    
>    While 874bbfe600a6 has been reverted for a different reason making the
>    bug less visible again, it can still happen.  Fix it by mapping
>    NUMA_NO_NODE to the default pool_workqueue from unbound_pwq_by_node().
>    This is a temporary workaround.  The long term solution is keeping CPU
>    -> NODE mapping stable across CPU off/online cycles which is being
>    worked on.
>    
>    Signed-off-by: Tejun Heo <tj@kernel.org>
>    Reported-by: Mike Galbraith <umgwanakikbuti@gmail.com>
>    Cc: Tang Chen <tangchen@cn.fujitsu.com>
>    Cc: Rafael J. Wysocki <rafael@kernel.org>
>    Cc: Len Brown <len.brown@intel.com>
>    Cc: stable@vger.kernel.org
>    Link: http://lkml.kernel.org/g/1454424264.11183.46.camel@gmail.com
>    Link: http://lkml.kernel.org/g/1453702100-2597-1-git-send-email-tangchen@cn.fujitsu.com
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d3c4dd8843bef1885fabaa9f61d5d354ec2a5e3a
>Author: Lai Jiangshan <laijs@cn.fujitsu.com>
>Date:   Tue May 12 20:32:29 2015 +0800
>
>    workqueue: wq_pool_mutex protects the attrs-installation
>    
>    [ Upstream commit 5b95e1af8d17d85a17728f6de7dbff538e6e3c49 ]
>    
>    Current wq_pool_mutex doesn't proctect the attrs-installation, it results
>    that ->unbound_attrs, ->numa_pwq_tbl[] and ->dfl_pwq can only be accessed
>    under wq->mutex and causes some inconveniences. Example, wq_update_unbound_numa()
>    has to acquire wq->mutex before fetching the wq->unbound_attrs->no_numa
>    and the old_pwq.
>    
>    attrs-installation is a short operation, so this change will no cause any
>    latency for other operations which also acquire the wq_pool_mutex.
>    
>    The only unprotected attrs-installation code is in apply_workqueue_attrs(),
>    so this patch touches code less than comments.
>    
>    It is also a preparation patch for next several patches which read
>    wq->unbound_attrs, wq->numa_pwq_tbl[] and wq->dfl_pwq with
>    only wq_pool_mutex held.
>    
>    Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
>    Signed-off-by: Tejun Heo <tj@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9e1a3771b412f52694e22a93cf188dbe9f0eab24
>Author: Lai Jiangshan <laijs@cn.fujitsu.com>
>Date:   Mon Apr 27 17:58:38 2015 +0800
>
>    workqueue: split apply_workqueue_attrs() into 3 stages
>    
>    [ Upstream commit 2d5f0764b5264d2954ba6e3deb04f4f5de8e4476 ]
>    
>    Current apply_workqueue_attrs() includes pwqs-allocation and pwqs-installation,
>    so when we batch multiple apply_workqueue_attrs()s as a transaction, we can't
>    ensure the transaction must succeed or fail as a complete unit.
>    
>    To solve this, we split apply_workqueue_attrs() into three stages.
>    The first stage does the preparation: allocation memory, pwqs.
>    The second stage does the attrs-installaion and pwqs-installation.
>    The third stage frees the allocated memory and (old or unused) pwqs.
>    
>    As the result, batching multiple apply_workqueue_attrs()s can
>    succeed or fail as a complete unit:
>    	1) batch do all the first stage for all the workqueues
>    	2) only commit all when all the above succeed.
>    
>    This patch is a preparation for the next patch ("Allow modifying low level
>    unbound workqueue cpumask") which will do a multiple apply_workqueue_attrs().
>    
>    The patch doesn't have functionality changed except two minor adjustment:
>    	1) free_unbound_pwq() for the error path is removed, we use the
>    	   heavier version put_pwq_unlocked() instead since the error path
>    	   is rare. this adjustment simplifies the code.
>    	2) the memory-allocation is also moved into wq_pool_mutex.
>    	   this is needed to avoid to do the further splitting.
>    
>    tj: minor updates to comments.
>    
>    Suggested-by: Tejun Heo <tj@kernel.org>
>    Cc: Christoph Lameter <cl@linux.com>
>    Cc: Kevin Hilman <khilman@linaro.org>
>    Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
>    Cc: Mike Galbraith <bitbucket@online.de>
>    Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>    Cc: Tejun Heo <tj@kernel.org>
>    Cc: Viresh Kumar <viresh.kumar@linaro.org>
>    Cc: Frederic Weisbecker <fweisbec@gmail.com>
>    Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
>    Signed-off-by: Tejun Heo <tj@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit de7b555fc95c1e54b6f4b1d0487ad0cc13e30eca
>Author: Alexandra Yates <alexandra.yates@linux.intel.com>
>Date:   Fri Feb 5 15:27:49 2016 -0800
>
>    ahci: Intel DNV device IDs SATA
>    
>    [ Upstream commit 342decff2b846b46fa61eb5ee40986fab79a9a32 ]
>    
>    Adding Intel codename DNV platform device IDs for SATA.
>    
>    Signed-off-by: Alexandra Yates <alexandra.yates@linux.intel.com>
>    Signed-off-by: Tejun Heo <tj@kernel.org>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit bb789d042685425c595b63a01ed555d5c1c404eb
>Author: Tony Lindgren <tony@atomide.com>
>Date:   Mon Nov 30 21:39:54 2015 -0800
>
>    phy: twl4030-usb: Fix unbalanced pm_runtime_enable on module reload
>    
>    [ Upstream commit 58a66dba1beac2121d931cda4682ae4d40816af5 ]
>    
>    If we reload phy-twl4030-usb, we get a warning about unbalanced
>    pm_runtime_enable. Let's fix the issue and also fix idling of the
>    device on unload before we attempt to shut it down.
>    
>    If we don't properly idle the PHY before shutting it down on removal,
>    the twl4030 ends up consuming about 62mW of extra power compared to
>    running idle with the module loaded.
>    
>    Cc: stable@vger.kernel.org
>    Cc: Bin Liu <b-liu@ti.com>
>    Cc: Felipe Balbi <balbi@ti.com>
>    Cc: Kishon Vijay Abraham I <kishon@ti.com>
>    Cc: NeilBrown <neil@brown.name>
>    Signed-off-by: Tony Lindgren <tony@atomide.com>
>    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit feebbdd7d01430b5ca620bec2b637909d498fa0f
>Author: Tony Lindgren <tony@atomide.com>
>Date:   Mon Nov 30 21:39:53 2015 -0800
>
>    phy: twl4030-usb: Relase usb phy on unload
>    
>    [ Upstream commit b241d31ef2f6a289d33dcaa004714b26e06f476f ]
>    
>    Otherwise rmmod omap2430; rmmod phy-twl4030-usb; modprobe omap2430
>    will try to use a non-existing phy and oops:
>    
>    Unable to handle kernel paging request at virtual address b6f7c1f0
>    ...
>    [<c048a284>] (devm_usb_get_phy_by_node) from [<bf0758ac>]
>    (omap2430_musb_init+0x44/0x2b4 [omap2430])
>    [<bf0758ac>] (omap2430_musb_init [omap2430]) from [<bf055ec0>]
>    (musb_init_controller+0x194/0x878 [musb_hdrc])
>    
>    Cc: stable@vger.kernel.org
>    Cc: Bin Liu <b-liu@ti.com>
>    Cc: Felipe Balbi <balbi@ti.com>
>    Cc: Kishon Vijay Abraham I <kishon@ti.com>
>    Cc: NeilBrown <neil@brown.name>
>    Signed-off-by: Tony Lindgren <tony@atomide.com>
>    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7822d8eb3551dce8f0e594807d030cf8be342540
>Author: Shawn Lin <shawn.lin@rock-chips.com>
>Date:   Thu Jan 28 16:14:18 2016 +0800
>
>    phy: core: fix wrong err handle for phy_power_on
>    
>    [ Upstream commit b82fcabe212a11698fd4b3e604d2f81d929d22f6 ]
>    
>    If phy_pm_runtime_get_sync failed but we already
>    enable regulator, current code return directly without
>    doing regulator_disable. This patch fix this problem
>    and cleanup err handle of phy_power_on to be more readable.
>    
>    Fixes: 3be88125d85d ("phy: core: Support regulator ...")
>    Cc: <stable@vger.kernel.org> # v3.18+
>    Cc: Roger Quadros <rogerq@ti.com>
>    Cc: Axel Lin <axel.lin@ingics.com>
>    Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
>    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 68fce03ba7901aa338a566292a59e6a753948861
>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"
>    
>    [ Upstream commit 041bd12e272c53a35c54c13875839bcb98c999ce ]
>    
>    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: stable@vger.kernel.org
>    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: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0163f1a71f10b25eae8d7019124cd7f1141b109a
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Mon Feb 8 17:26:58 2016 +0100
>
>    ALSA: timer: Fix race at concurrent reads
>    
>    [ Upstream commit 4dff5c7b7093b19c19d3a100f8a3ad87cb7cd9e7 ]
>    
>    snd_timer_user_read() has a potential race among parallel reads, as
>    qhead and qused are updated outside the critical section due to
>    copy_to_user() calls.  Move them into the critical section, and also
>    sanitize the relevant code a bit.
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit dbe8ccc27ee453e435597e636b4c7445fdc8c6d5
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Tue Feb 9 10:23:52 2016 +0100
>
>    ALSA: hda - Fix bad dereference of jack object
>    
>    [ Upstream commit 2ebab40eb74a0225d5dfba72bfae317dd948fa2d ]
>    
>    The hda_jack_tbl entries are managed by snd_array for allowing
>    multiple jacks.  It's good per se, but the problem is that struct
>    hda_jack_callback keeps the hda_jack_tbl pointer.  Since snd_array
>    doesn't preserve each pointer at resizing the array, we can't keep the
>    original pointer but have to deduce the pointer at each time via
>    snd_array_entry() instead.  Actually, this resulted in the deference
>    to the wrong pointer on codecs that have many pins such as CS4208.
>    
>    This patch replaces the pointer to the NID value as the search key.
>    As an unexpected good side effect, this even simplifies the code, as
>    only NID is needed in most cases.
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9b7283948d5f83ac692ed0243e17e2f1d3843c6c
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Tue Feb 9 12:02:32 2016 +0100
>
>    ALSA: timer: Fix race between stop and interrupt
>    
>    [ Upstream commit ed8b1d6d2c741ab26d60d499d7fbb7ac801f0f51 ]
>    
>    A slave timer element also unlinks at snd_timer_stop() but it takes
>    only slave_active_lock.  When a slave is assigned to a master,
>    however, this may become a race against the master's interrupt
>    handling, eventually resulting in a list corruption.  The actual bug
>    could be seen with a syzkaller fuzzer test case in BugLink below.
>    
>    As a fix, we need to take timeri->timer->lock when timer isn't NULL,
>    i.e. assigned to a master, while the assignment to a master itself is
>    protected by slave_active_lock.
>    
>    BugLink: http://lkml.kernel.org/r/CACT4Y+Y_Bm+7epAb=8Wi=AaWd+DYS7qawX52qxdCfOfY49vozQ@mail.gmail.com
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ca54f8d139ae5b261d3dba4c71bb08b46fc8f9ea
>Author: Linus Walleij <linus.walleij@linaro.org>
>Date:   Mon Feb 8 09:14:37 2016 +0100
>
>    ARM: 8517/1: ICST: avoid arithmetic overflow in icst_hz()
>    
>    [ Upstream commit 5070fb14a0154f075c8b418e5bc58a620ae85a45 ]
>    
>    When trying to set the ICST 307 clock to 25174000 Hz I ran into
>    this arithmetic error: the icst_hz_to_vco() correctly figure out
>    DIVIDE=2, RDW=100 and VDW=99 yielding a frequency of
>    25174000 Hz out of the VCO. (I replicated the icst_hz() function
>    in a spreadsheet to verify this.)
>    
>    However, when I called icst_hz() on these VCO settings it would
>    instead return 4122709 Hz. This causes an error in the common
>    clock driver for ICST as the common clock framework will call
>    .round_rate() on the clock which will utilize icst_hz_to_vco()
>    followed by icst_hz() suggesting the erroneous frequency, and
>    then the clock gets set to this.
>    
>    The error did not manifest in the old clock framework since
>    this high frequency was only used by the CLCD, which calls
>    clk_set_rate() without first calling clk_round_rate() and since
>    the old clock framework would not call clk_round_rate() before
>    setting the frequency, the correct values propagated into
>    the VCO.
>    
>    After some experimenting I figured out that it was due to a simple
>    arithmetic overflow: the divisor for 24Mhz reference frequency
>    as reference becomes 24000000*2*(99+8)=0x132212400 and the "1"
>    in bit 32 overflows and is lost.
>    
>    But introducing an explicit 64-by-32 bit do_div() and casting
>    the divisor into (u64) we get the right frequency back, and the
>    right frequency gets set.
>    
>    Tested on the ARM Versatile.
>    
>    Cc: stable@vger.kernel.org
>    Cc: linux-clk@vger.kernel.org
>    Cc: Pawel Moll <pawel.moll@arm.com>
>    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 47eef3475c5f3063fc20e938f2fe24cd84d731aa
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Mon Feb 8 17:36:25 2016 +0100
>
>    ALSA: timer: Fix wrong instance passed to slave callbacks
>    
>    [ Upstream commit 117159f0b9d392fb433a7871426fad50317f06f7 ]
>    
>    In snd_timer_notify1(), the wrong timer instance was passed for slave
>    ccallback function.  This leads to the access to the wrong data when
>    an incompatible master is handled (e.g. the master is the sequencer
>    timer and the slave is a user timer), as spotted by syzkaller fuzzer.
>    
>    This patch fixes that wrong assignment.
>    
>    BugLink: http://lkml.kernel.org/r/CACT4Y+Y_Bm+7epAb=8Wi=AaWd+DYS7qawX52qxdCfOfY49vozQ@mail.gmail.com
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6b20ea56ddee5353a29616692723c80793fb05c5
>Author: Jani Nikula <jani.nikula@intel.com>
>Date:   Thu Feb 4 12:50:50 2016 +0200
>
>    drm/i915/dsi: don't pass arbitrary data to sideband
>    
>    [ Upstream commit 26f6f2d301c1fb46acb1138ee155125815239b0d ]
>    
>    Since sequence block v2 the second byte contains flags other than just
>    pull up/down. Don't pass arbitrary data to the sideband interface.
>    
>    The rest may or may not work for sequence block v2, but there should be
>    no harm done.
>    
>    Cc: stable@vger.kernel.org
>    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/ebe3c2eee623afc4b3a134533b01f8d591d13f32.1454582914.git.jani.nikula@intel.com
>    (cherry picked from commit 4e1c63e3761b84ec7d87c75b58bbc8bcf18e98ee)
>    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3c9dc5750d0c3052ba7a3bf0173ba429bc96f323
>Author: Jani Nikula <jani.nikula@intel.com>
>Date:   Thu Feb 4 12:50:49 2016 +0200
>
>    drm/i915/dsi: defend gpio table against out of bounds access
>    
>    [ Upstream commit 4db3a2448ec8902310acb78de39b6227a9a56ac8 ]
>    
>    Do not blindly trust the VBT data used for indexing.
>    
>    Cc: stable@vger.kernel.org
>    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/cc32d40c2b47f2d2151811855ac2c3dabab1d57d.1454582914.git.jani.nikula@intel.com
>    (cherry picked from commit 5d2d0a12d3d08bf50434f0b5947bb73bac04b941)
>    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c5e67773f634806feecb3779baf2158e182ccd8a
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Tue Feb 2 15:27:36 2016 +0100
>
>    ALSA: dummy: Implement timer backend switching more safely
>    
>    [ Upstream commit ddce57a6f0a2d8d1bfacfa77f06043bc760403c2 ]
>    
>    Currently the selected timer backend is referred at any moment from
>    the running PCM callbacks.  When the backend is switched, it's
>    possible to lead to inconsistency from the running backend.  This was
>    pointed by syzkaller fuzzer, and the commit [7ee96216c31a: ALSA:
>    dummy: Disable switching timer backend via sysfs] disabled the dynamic
>    switching for avoiding the crash.
>    
>    This patch improves the handling of timer backend switching.  It keeps
>    the reference to the selected backend during the whole operation of an
>    opened stream so that it won't be changed by other streams.
>    
>    Together with this change, the hrtimer parameter is reenabled as
>    writable now.
>    
>    NOTE: this patch also turned out to fix the still remaining race.
>    Namely, ops was still replaced dynamically at dummy_pcm_open:
>    
>      static int dummy_pcm_open(struct snd_pcm_substream *substream)
>      {
>      ....
>              dummy->timer_ops = &dummy_systimer_ops;
>              if (hrtimer)
>                      dummy->timer_ops = &dummy_hrtimer_ops;
>    
>    Since dummy->timer_ops is common among all streams, and when the
>    replacement happens during accesses of other streams, it may lead to a
>    crash.  This was actually triggered by syzkaller fuzzer and KASAN.
>    
>    This patch rewrites the code not to use the ops shared by all streams
>    any longer, too.
>    
>    BugLink: http://lkml.kernel.org/r/CACT4Y+aZ+xisrpuM6cOXbL21DuM0yVxPYXf4cD4Md9uw0C3dBQ@mail.gmail.com
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 84ec02eecb3b257f14cb8b10ffcd73d5420c96c0
>Author: James Bottomley <James.Bottomley@HansenPartnership.com>
>Date:   Wed Jan 13 08:10:31 2016 -0800
>
>    klist: fix starting point removed bug in klist iterators
>    
>    [ Upstream commit 00cd29b799e3449f0c68b1cc77cd4a5f95b42d17 ]
>    
>    The starting node for a klist iteration is often passed in from
>    somewhere way above the klist infrastructure, meaning there's no
>    guarantee the node is still on the list.  We've seen this in SCSI where
>    we use bus_find_device() to iterate through a list of devices.  In the
>    face of heavy hotplug activity, the last device returned by
>    bus_find_device() can be removed before the next call.  This leads to
>    
>    Dec  3 13:22:02 localhost kernel: WARNING: CPU: 2 PID: 28073 at include/linux/kref.h:47 klist_iter_init_node+0x3d/0x50()
>    Dec  3 13:22:02 localhost kernel: Modules linked in: scsi_debug x86_pkg_temp_thermal kvm_intel kvm irqbypass crc32c_intel joydev iTCO_wdt dcdbas ipmi_devintf acpi_power_meter iTCO_vendor_support ipmi_si imsghandler pcspkr wmi acpi_cpufreq tpm_tis tpm shpchp lpc_ich mfd_core nfsd nfs_acl lockd grace sunrpc tg3 ptp pps_core
>    Dec  3 13:22:02 localhost kernel: CPU: 2 PID: 28073 Comm: cat Not tainted 4.4.0-rc1+ #2
>    Dec  3 13:22:02 localhost kernel: Hardware name: Dell Inc. PowerEdge R320/08VT7V, BIOS 2.0.22 11/19/2013
>    Dec  3 13:22:02 localhost kernel: ffffffff81a20e77 ffff880613acfd18 ffffffff81321eef 0000000000000000
>    Dec  3 13:22:02 localhost kernel: ffff880613acfd50 ffffffff8107ca52 ffff88061176b198 0000000000000000
>    Dec  3 13:22:02 localhost kernel: ffffffff814542b0 ffff880610cfb100 ffff88061176b198 ffff880613acfd60
>    Dec  3 13:22:02 localhost kernel: Call Trace:
>    Dec  3 13:22:02 localhost kernel: [<ffffffff81321eef>] dump_stack+0x44/0x55
>    Dec  3 13:22:02 localhost kernel: [<ffffffff8107ca52>] warn_slowpath_common+0x82/0xc0
>    Dec  3 13:22:02 localhost kernel: [<ffffffff814542b0>] ? proc_scsi_show+0x20/0x20
>    Dec  3 13:22:02 localhost kernel: [<ffffffff8107cb4a>] warn_slowpath_null+0x1a/0x20
>    Dec  3 13:22:02 localhost kernel: [<ffffffff8167225d>] klist_iter_init_node+0x3d/0x50
>    Dec  3 13:22:02 localhost kernel: [<ffffffff81421d41>] bus_find_device+0x51/0xb0
>    Dec  3 13:22:02 localhost kernel: [<ffffffff814545ad>] scsi_seq_next+0x2d/0x40
>    [...]
>    
>    And an eventual crash. It can actually occur in any hotplug system
>    which has a device finder and a starting device.
>    
>    We can fix this globally by making sure the starting node for
>    klist_iter_init_node() is actually a member of the list before using it
>    (and by starting from the beginning if it isn't).
>    
>    Reported-by: Ewan D. Milne <emilne@redhat.com>
>    Tested-by: Ewan D. Milne <emilne@redhat.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 485037307b65916364a5d9ac77e44d5cb64073f0
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Sun Feb 7 09:38:26 2016 +0100
>
>    ALSA: hda - Fix speaker output from VAIO AiO machines
>    
>    [ Upstream commit c44d9b1181cf34e0860c72cc8a00e0c47417aac0 ]
>    
>    Some Sony VAIO AiO models (VGC-JS4EF and VGC-JS25G, both with PCI SSID
>    104d:9044) need the same quirk to make the speaker working properly.
>    
>    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112031
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 38bdf7e3fb81c3d9cbbacab6f96e9fd28ff6c704
>Author: Herton R. Krzesinski <herton@redhat.com>
>Date:   Thu Jan 14 17:56:58 2016 -0200
>
>    pty: make sure super_block is still valid in final /dev/tty close
>    
>    [ Upstream commit 1f55c718c290616889c04946864a13ef30f64929 ]
>    
>    Considering current pty code and multiple devpts instances, it's possible
>    to umount a devpts file system while a program still has /dev/tty opened
>    pointing to a previosuly closed pty pair in that instance. In the case all
>    ptmx and pts/N files are closed, umount can be done. If the program closes
>    /dev/tty after umount is done, devpts_kill_index will use now an invalid
>    super_block, which was already destroyed in the umount operation after
>    running ->kill_sb. This is another "use after free" type of issue, but now
>    related to the allocated super_block instance.
>    
>    To avoid the problem (warning at ida_remove and potential crashes) for
>    this specific case, I added two functions in devpts which grabs additional
>    references to the super_block, which pty code now uses so it makes sure
>    the super block structure is still valid until pty shutdown is done.
>    I also moved the additional inode references to the same functions, which
>    also covered similar case with inode being freed before /dev/tty final
>    close/shutdown.
>    
>    Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
>    Cc: stable@vger.kernel.org # 2.6.29+
>    Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 614f8734d11ad22ee17a5faecf355b70756904ef
>Author: Herton R. Krzesinski <herton@redhat.com>
>Date:   Mon Jan 11 12:07:43 2016 -0200
>
>    pty: fix possible use after free of tty->driver_data
>    
>    [ Upstream commit 2831c89f42dcde440cfdccb9fee9f42d54bbc1ef ]
>    
>    This change fixes a bug for a corner case where we have the the last
>    release from a pty master/slave coming from a previously opened /dev/tty
>    file. When this happens, the tty->driver_data can be stale, due to all
>    ptmx or pts/N files having already been closed before (and thus the inode
>    related to these files, which tty->driver_data points to, being already
>    freed/destroyed).
>    
>    The fix here is to keep a reference on the opened master ptmx inode.
>    We maintain the inode referenced until the final pty_unix98_shutdown,
>    and only pass this inode to devpts_kill_index.
>    
>    Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
>    Cc: <stable@vger.kernel.org> # 2.6.29+
>    Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6ca45550112e975be2298b0feda49b686029cc32
>Author: Jeremy McNicoll <jmcnicol@redhat.com>
>Date:   Tue Feb 2 13:00:45 2016 -0800
>
>    tty: Add support for PCIe WCH382 2S multi-IO card
>    
>    [ Upstream commit 7dde55787b43a8f2b4021916db38d90c03a2ec64 ]
>    
>    WCH382 2S board is a PCIe card with 2 DB9 COM ports detected as
>    Serial controller: Device 1c00:3253 (rev 10) (prog-if 05 [16850])
>    
>    Signed-off-by: Jeremy McNicoll <jmcnicol@redhat.com>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 56819934d6148c68c85eb181f6153b36f028f99c
>Author: Peter Hurley <peter@hurleysoftware.com>
>Date:   Tue Jan 12 15:14:46 2016 -0800
>
>    serial: omap: Prevent DoS using unprivileged ioctl(TIOCSRS485)
>    
>    [ Upstream commit 308bbc9ab838d0ace0298268c7970ba9513e2c65 ]
>    
>    The omap-serial driver emulates RS485 delays using software timers,
>    but neglects to clamp the input values from the unprivileged
>    ioctl(TIOCSRS485). Because the software implementation busy-waits,
>    malicious userspace could stall the cpu for ~49 days.
>    
>    Clamp the input values to < 100ms.
>    
>    Fixes: 4a0ac0f55b18 ("OMAP: add RS485 support")
>    Cc: <stable@vger.kernel.org>  # 3.12+
>    Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8b6349ec0eefde22c3348b65804e343be1245a59
>Author: Quinn Tran <quinn.tran@qlogic.com>
>Date:   Thu Feb 4 11:45:16 2016 -0500
>
>    qla2xxx: Use pci_enable_msix_range() instead of pci_enable_msix()
>    
>    [ Upstream commit 84e32a06f4f8756ce9ec3c8dc7e97896575f0771 ]
>    
>    As result of deprecation of MSI-X/MSI enablement functions
>    pci_enable_msix() and pci_enable_msi_block() all drivers
>    using these two interfaces need to be updated to use the
>    new pci_enable_msi_range()  or pci_enable_msi_exact()
>    and pci_enable_msix_range() or pci_enable_msix_exact()
>    interfaces.
>    
>    Log message code 0x00c6 preserved, although it is reported
>    after successful call to pci_enable_msix_range(), not before
>    possibly unsuccessful call to pci_enable_msix(). Consumers
>    of the error code should not notice the difference.
>    
>    Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
>    Acked-by: Chad Dupuis <chad.dupuis@qlogic.com>
>    Cc: qla2xxx-upstream@qlogic.com
>    Cc: linux-scsi@vger.kernel.org
>    Cc: linux-pci@vger.kernel.org
>    Signed-off-by: Christoph Hellwig <hch@lst.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0a86238d2e2ad9b74329622c72e99cacbbaf6485
>Author: Cyrille Pitchen <cyrille.pitchen@atmel.com>
>Date:   Fri Feb 5 13:45:13 2016 +0100
>
>    crypto: atmel-sha - remove calls of clk_prepare() from atomic contexts
>    
>    [ Upstream commit ee36c87a655325a7b5e442a9650a782db4ea20d2 ]
>    
>    commit c033042aa8f69894df37dabcaa0231594834a4e4 upstream.
>    
>    clk_prepare()/clk_unprepare() must not be called within atomic context.
>    
>    This patch calls clk_prepare() once for all from atmel_sha_probe() and
>    clk_unprepare() from atmel_sha_remove().
>    
>    Then calls of clk_prepare_enable()/clk_disable_unprepare() were replaced
>    by calls of clk_enable()/clk_disable().
>    
>    Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
>    Reported-by: Matthias Mayr <matthias.mayr@student.kit.edu>
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 617c364c29ce8eefa9f0122fd01829adc2ac5d83
>Author: LABBE Corentin <clabbe.montjoie@gmail.com>
>Date:   Fri Oct 2 14:12:58 2015 +0200
>
>    crypto: atmel - Check for clk_prepare_enable() return value
>    
>    [ Upstream commit 9d83d299549d0e121245d56954242750d0c14338 ]
>    
>    clk_prepare_enable() can fail so add a check for this and
>    return the error code if it fails.
>    
>    Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5955bf64814d8663117e9397373fb20f9f71dff0
>Author: LABBE Corentin <clabbe.montjoie@gmail.com>
>Date:   Mon Oct 12 19:47:03 2015 +0200
>
>    crypto: atmel - use devm_xxx() managed function
>    
>    [ Upstream commit b0e8b3417a620e6e0a91fd526fbc6db78714198e ]
>    
>    Using the devm_xxx() managed function to stripdown the error and remove
>    code.
>    
>    Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 64c4131f16acba869e5280ee46e7dbf93fd8b960
>Author: Herbert Xu <herbert@gondor.apana.org.au>
>Date:   Fri Feb 26 12:44:11 2016 +0100
>
>    Backport fix for crypto: algif_skcipher - Fix race condition in skcipher_check_key
>    
>    commit 1822793a523e5d5730b19cc21160ff1717421bc8 upstream.
>    
>    We need to lock the child socket in skcipher_check_key as otherwise
>    two simultaneous calls can cause the parent socket to be freed.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7327b23abeb498c103125f234c7698115db5970b
>Author: Herbert Xu <herbert@gondor.apana.org.au>
>Date:   Fri Feb 26 12:44:10 2016 +0100
>
>    Backport fix for crypto: algif_skcipher - Remove custom release parent function
>    
>    commit d7b65aee1e7b4c87922b0232eaba56a8a143a4a0 upstream.
>    
>    This patch removes the custom release parent function as the
>    generic af_alg_release_parent now works for nokey sockets too.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1ce5c14e78a7c44a6f9c6af3548748dbe22a80af
>Author: Herbert Xu <herbert@gondor.apana.org.au>
>Date:   Fri Feb 26 12:44:09 2016 +0100
>
>    Backport fix for crypto: algif_skcipher - Add nokey compatibility path
>    
>    commit a0fa2d037129a9849918a92d91b79ed6c7bd2818 upstream.
>    
>    This patch adds a compatibility path to support old applications
>    that do acept(2) before setkey.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 762330b161c49c6d88ab689a0ee2a1a959dc5b6b
>Author: Herbert Xu <herbert@gondor.apana.org.au>
>Date:   Fri Feb 26 12:44:08 2016 +0100
>
>    Backport fix for crypto: algif_skcipher - Require setkey before accept(2)
>    
>    commit dd504589577d8e8e70f51f997ad487a4cb6c026f upstream.
>    
>    Some cipher implementations will crash if you try to use them
>    without calling setkey first.  This patch adds a check so that
>    the accept(2) call will fail with -ENOKEY if setkey hasn't been
>    done on the socket yet.
>    
>    Cc: stable@vger.kernel.org
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Tested-by: Dmitry Vyukov <dvyukov@google.com>
>    [backported to 4.1 by Milan Broz <gmazyland@gmail.com>]
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 09b09ced1e4e3afb2767ee96edc9d1d57fc1c55b
>Author: Mathias Krause <minipli@googlemail.com>
>Date:   Mon Feb 1 14:27:30 2016 +0100
>
>    crypto: user - lock crypto_alg_list on alg dump
>    
>    [ Upstream commit 63e41ebc6630f39422d87f8a4bade1e793f37a01 ]
>    
>    We miss to take the crypto_alg_sem semaphore when traversing the
>    crypto_alg_list for CRYPTO_MSG_GETALG dumps. This allows a race with
>    crypto_unregister_alg() removing algorithms from the list while we're
>    still traversing it, thereby leading to a use-after-free as show below:
>    
>    [ 3482.071639] general protection fault: 0000 [#1] SMP
>    [ 3482.075639] Modules linked in: aes_x86_64 glue_helper lrw ablk_helper cryptd gf128mul ipv6 pcspkr serio_raw virtio_net microcode virtio_pci virtio_ring virtio sr_mod cdrom [last unloaded: aesni_intel]
>    [ 3482.075639] CPU: 1 PID: 11065 Comm: crconf Not tainted 4.3.4-grsec+ #126
>    [ 3482.075639] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
>    [ 3482.075639] task: ffff88001cd41a40 ti: ffff88001cd422c8 task.ti: ffff88001cd422c8
>    [ 3482.075639] RIP: 0010:[<ffffffff93722bd3>]  [<ffffffff93722bd3>] strncpy+0x13/0x30
>    [ 3482.075639] RSP: 0018:ffff88001f713b60  EFLAGS: 00010202
>    [ 3482.075639] RAX: ffff88001f6c4430 RBX: ffff88001f6c43a0 RCX: ffff88001f6c4430
>    [ 3482.075639] RDX: 0000000000000040 RSI: fefefefefefeff16 RDI: ffff88001f6c4430
>    [ 3482.075639] RBP: ffff88001f713b60 R08: ffff88001f6c4470 R09: ffff88001f6c4480
>    [ 3482.075639] R10: 0000000000000002 R11: 0000000000000246 R12: ffff88001ce2aa28
>    [ 3482.075639] R13: ffff880000093700 R14: ffff88001f5e4bf8 R15: 0000000000003b20
>    [ 3482.075639] FS:  0000033826fa2700(0000) GS:ffff88001e900000(0000) knlGS:0000000000000000
>    [ 3482.075639] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>    [ 3482.075639] CR2: ffffffffff600400 CR3: 00000000139ec000 CR4: 00000000001606f0
>    [ 3482.075639] Stack:
>    [ 3482.075639]  ffff88001f713bd8 ffffffff936ccd00 ffff88001e5c4200 ffff880000093700
>    [ 3482.075639]  ffff88001f713bd0 ffffffff938ef4bf 0000000000000000 0000000000003b20
>    [ 3482.075639]  ffff88001f5e4bf8 ffff88001f5e4848 0000000000000000 0000000000003b20
>    [ 3482.075639] Call Trace:
>    [ 3482.075639]  [<ffffffff936ccd00>] crypto_report_alg+0xc0/0x3e0
>    [ 3482.075639]  [<ffffffff938ef4bf>] ? __alloc_skb+0x16f/0x300
>    [ 3482.075639]  [<ffffffff936cd08a>] crypto_dump_report+0x6a/0x90
>    [ 3482.075639]  [<ffffffff93935707>] netlink_dump+0x147/0x2e0
>    [ 3482.075639]  [<ffffffff93935f99>] __netlink_dump_start+0x159/0x190
>    [ 3482.075639]  [<ffffffff936ccb13>] crypto_user_rcv_msg+0xc3/0x130
>    [ 3482.075639]  [<ffffffff936cd020>] ? crypto_report_alg+0x3e0/0x3e0
>    [ 3482.075639]  [<ffffffff936cc4b0>] ? alg_test_crc32c+0x120/0x120
>    [ 3482.075639]  [<ffffffff93933145>] ? __netlink_lookup+0xd5/0x120
>    [ 3482.075639]  [<ffffffff936cca50>] ? crypto_add_alg+0x1d0/0x1d0
>    [ 3482.075639]  [<ffffffff93938141>] netlink_rcv_skb+0xe1/0x130
>    [ 3482.075639]  [<ffffffff936cc4f8>] crypto_netlink_rcv+0x28/0x40
>    [ 3482.075639]  [<ffffffff939375a8>] netlink_unicast+0x108/0x180
>    [ 3482.075639]  [<ffffffff93937c21>] netlink_sendmsg+0x541/0x770
>    [ 3482.075639]  [<ffffffff938e31e1>] sock_sendmsg+0x21/0x40
>    [ 3482.075639]  [<ffffffff938e4763>] SyS_sendto+0xf3/0x130
>    [ 3482.075639]  [<ffffffff93444203>] ? bad_area_nosemaphore+0x13/0x20
>    [ 3482.075639]  [<ffffffff93444470>] ? __do_page_fault+0x80/0x3a0
>    [ 3482.075639]  [<ffffffff939d80cb>] entry_SYSCALL_64_fastpath+0x12/0x6e
>    [ 3482.075639] Code: 88 4a ff 75 ed 5d 48 0f ba 2c 24 3f c3 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 85 d2 48 89 f8 48 89 f9 4c 8d 04 17 48 89 e5 74 15 <0f> b6 16 80 fa 01 88 11 48 83 de ff 48 83 c1 01 4c 39 c1 75 eb
>    [ 3482.075639] RIP  [<ffffffff93722bd3>] strncpy+0x13/0x30
>    
>    To trigger the race run the following loops simultaneously for a while:
>      $ while : ; do modprobe aesni-intel; rmmod aesni-intel; done
>      $ while : ; do crconf show all > /dev/null; done
>    
>    Fix the race by taking the crypto_alg_sem read lock, thereby preventing
>    crypto_unregister_alg() from modifying the algorithm list during the
>    dump.
>    
>    This bug has been detected by the PaX memory sanitize feature.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Mathias Krause <minipli@googlemail.com>
>    Cc: Steffen Klassert <steffen.klassert@secunet.com>
>    Cc: PaX Team <pageexec@freemail.hu>
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0951360a3c8e4633016836a1adec7c4b1f090f3c
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Fri Feb 5 20:12:24 2016 +0100
>
>    Revert "ALSA: hda - Fix noise on Gigabyte Z170X mobo"
>    
>    [ Upstream commit 6c361d10e0eb859233c71954abcd20d2d8700587 ]
>    
>    This reverts commit 0c25ad80408e95e0a4fbaf0056950206e95f726f.
>    
>    The original commit disabled the aamixer path due to the noise
>    problem, but it turned out that some mobo with the same PCI SSID
>    doesn't suffer from the issue, and the disabled function (analog
>    loopback) is still demanded by users.
>    
>    Since the recent commit [e7fdd52779a6: ALSA: hda - Implement loopback
>    control switch for Realtek and other codecs], we have the dynamic
>    mixer switch to enable/disable the aamix path, and we don't have to
>    disable the path statically any longer.  So, let's revert the
>    disablement, so that only the user suffering from the noise problem
>    can turn off the aamix on the fly.
>    
>    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=108301
>    Reported-by: <mutedbytes@gmail.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6cf9d4c32e8e2716eb8e9cb578dbcb2b2cad04b3
>Author: David Henningsson <david.henningsson@canonical.com>
>Date:   Fri Feb 5 09:05:41 2016 +0100
>
>    ALSA: hda - Fix static checker warning in patch_hdmi.c
>    
>    [ Upstream commit 360a8245680053619205a3ae10e6bfe624a5da1d ]
>    
>    The static checker warning is:
>    
>    	sound/pci/hda/patch_hdmi.c:460 hdmi_eld_ctl_get()
>    	error: __memcpy() 'eld->eld_buffer' too small (256 vs 512)
>    
>    I have a hard time figuring out if this can ever cause an information leak
>    (I don't think so), but nonetheless it does not hurt to increase the
>    robustness of the code.
>    
>    Fixes: 68e03de98507 ('ALSA: hda - hdmi: Do not expose eld data when eld is invalid')
>    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
>    Signed-off-by: David Henningsson <david.henningsson@canonical.com>
>    Cc: <stable@vger.kernel.org> # v3.9+
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 75b546e5147b81fe064454ba8a06ee58590f0f0d
>Author: Mika Westerberg <mika.westerberg@linux.intel.com>
>Date:   Wed Jan 27 16:19:13 2016 +0200
>
>    SCSI: Add Marvell Console to VPD blacklist
>    
>    [ Upstream commit 82c43310508eb19eb41fe7862e89afeb74030b84 ]
>    
>    I have a Marvell 88SE9230 SATA Controller that has some sort of
>    integrated console SCSI device attached to one of the ports.
>    
>      ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>      ata14.00: ATAPI: MARVELL VIRTUALL, 1.09, max UDMA/66
>      ata14.00: configured for UDMA/66
>      scsi 13:0:0:0: Processor         Marvell  Console 1.01 PQ: 0 ANSI: 5
>    
>    Sending it VPD INQUIRY command seem to always fail with following error:
>    
>      ata14.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
>      ata14.00: irq_stat 0x40000001
>      ata14.00: cmd a0/01:00:00:00:01/00:00:00:00:00/a0 tag 2 dma 16640 in
>                Inquiry 12 01 00 00 ff 00res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x3 (HSM violation)
>      ata14: hard resetting link
>    
>    This has been minor annoyance (only error printed on dmesg) until commit
>    09e2b0b14690 ("scsi: rescan VPD attributes") added call to scsi_attach_vpd()
>    in scsi_rescan_device(). The commit causes the system to splat out
>    following errors continuously without ever reaching the UI:
>    
>      ata14.00: configured for UDMA/66
>      ata14: EH complete
>      ata14.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
>      ata14.00: irq_stat 0x40000001
>      ata14.00: cmd a0/01:00:00:00:01/00:00:00:00:00/a0 tag 6 dma 16640 in
>                Inquiry 12 01 00 00 ff 00res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x3 (HSM violation)
>      ata14: hard resetting link
>      ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>      ata14.00: configured for UDMA/66
>      ata14: EH complete
>      ata14.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
>      ata14.00: irq_stat 0x40000001
>      ata14.00: cmd a0/01:00:00:00:01/00:00:00:00:00/a0 tag 7 dma 16640 in
>                Inquiry 12 01 00 00 ff 00res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x3 (HSM violation)
>    
>    Without in-depth understanding of SCSI layer and the Marvell controller,
>    I suspect this happens because when the link goes down (because of an
>    error) we schedule scsi_rescan_device() which again fails to read VPD
>    data... ad infinitum.
>    
>    Since VPD data cannot be read from the device anyway we prevent the SCSI
>    layer from even trying by blacklisting the device. This gets away the
>    error and the system starts up normally.
>    
>    [mkp: Widened the match to all revisions of this device]
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
>    Reported-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>    Reported-by: Alexander Duyck <alexander.duyck@gmail.com>
>    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d1d1545f542c5ab95d2bbec49f7b425fcf1f4166
>Author: Hannes Reinecke <hare@suse.de>
>Date:   Fri Jan 22 15:42:41 2016 +0100
>
>    scsi_dh_rdac: always retry MODE SELECT on command lock violation
>    
>    [ Upstream commit d2d06d4fe0f2cc2df9b17fefec96e6e1a1271d91 ]
>    
>    If MODE SELECT returns with sense '05/91/36' (command lock violation)
>    it should always be retried without counting the number of retries.
>    During an HBA upgrade or similar circumstances one might see a flood
>    of MODE SELECT command from various HBAs, which will easily trigger
>    the sense code and exceed the retry count.
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Hannes Reinecke <hare@suse.de>
>    Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
>    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 79179a68458a7fddcf35adb16d1f7a7880aa41e7
>Author: Filipe Manana <fdmanana@suse.com>
>Date:   Wed Feb 3 19:17:27 2016 +0000
>
>    Btrfs: fix hang on extent buffer lock caused by the inode_paths ioctl
>    
>    [ Upstream commit 0c0fe3b0fa45082cd752553fdb3a4b42503a118e ]
>    
>    While doing some tests I ran into an hang on an extent buffer's rwlock
>    that produced the following trace:
>    
>    [39389.800012] NMI watchdog: BUG: soft lockup - CPU#15 stuck for 22s! [fdm-stress:32166]
>    [39389.800016] NMI watchdog: BUG: soft lockup - CPU#14 stuck for 22s! [fdm-stress:32165]
>    [39389.800016] Modules linked in: btrfs dm_mod ppdev xor sha256_generic hmac raid6_pq drbg ansi_cprng aesni_intel i2c_piix4 acpi_cpufreq aes_x86_64 ablk_helper tpm_tis parport_pc i2c_core sg cryptd evdev psmouse lrw tpm parport gf128mul serio_raw pcspkr glue_helper processor button loop autofs4 ext4 crc16 mbcache jbd2 sd_mod sr_mod cdrom ata_generic virtio_scsi ata_piix libata virtio_pci virtio_ring crc32c_intel scsi_mod e1000 virtio floppy [last unloaded: btrfs]
>    [39389.800016] irq event stamp: 0
>    [39389.800016] hardirqs last  enabled at (0): [<          (null)>]           (null)
>    [39389.800016] hardirqs last disabled at (0): [<ffffffff8104e58d>] copy_process+0x638/0x1a35
>    [39389.800016] softirqs last  enabled at (0): [<ffffffff8104e58d>] copy_process+0x638/0x1a35
>    [39389.800016] softirqs last disabled at (0): [<          (null)>]           (null)
>    [39389.800016] CPU: 14 PID: 32165 Comm: fdm-stress Not tainted 4.4.0-rc6-btrfs-next-18+ #1
>    [39389.800016] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS by qemu-project.org 04/01/2014
>    [39389.800016] task: ffff880175b1ca40 ti: ffff8800a185c000 task.ti: ffff8800a185c000
>    [39389.800016] RIP: 0010:[<ffffffff810902af>]  [<ffffffff810902af>] queued_spin_lock_slowpath+0x57/0x158
>    [39389.800016] RSP: 0018:ffff8800a185fb80  EFLAGS: 00000202
>    [39389.800016] RAX: 0000000000000101 RBX: ffff8801710c4e9c RCX: 0000000000000101
>    [39389.800016] RDX: 0000000000000100 RSI: 0000000000000001 RDI: 0000000000000001
>    [39389.800016] RBP: ffff8800a185fb98 R08: 0000000000000001 R09: 0000000000000000
>    [39389.800016] R10: ffff8800a185fb68 R11: 6db6db6db6db6db7 R12: ffff8801710c4e98
>    [39389.800016] R13: ffff880175b1ca40 R14: ffff8800a185fc10 R15: ffff880175b1ca40
>    [39389.800016] FS:  00007f6d37fff700(0000) GS:ffff8802be9c0000(0000) knlGS:0000000000000000
>    [39389.800016] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>    [39389.800016] CR2: 00007f6d300019b8 CR3: 0000000037c93000 CR4: 00000000001406e0
>    [39389.800016] Stack:
>    [39389.800016]  ffff8801710c4e98 ffff8801710c4e98 ffff880175b1ca40 ffff8800a185fbb0
>    [39389.800016]  ffffffff81091e11 ffff8801710c4e98 ffff8800a185fbc8 ffffffff81091895
>    [39389.800016]  ffff8801710c4e98 ffff8800a185fbe8 ffffffff81486c5c ffffffffa067288c
>    [39389.800016] Call Trace:
>    [39389.800016]  [<ffffffff81091e11>] queued_read_lock_slowpath+0x46/0x60
>    [39389.800016]  [<ffffffff81091895>] do_raw_read_lock+0x3e/0x41
>    [39389.800016]  [<ffffffff81486c5c>] _raw_read_lock+0x3d/0x44
>    [39389.800016]  [<ffffffffa067288c>] ? btrfs_tree_read_lock+0x54/0x125 [btrfs]
>    [39389.800016]  [<ffffffffa067288c>] btrfs_tree_read_lock+0x54/0x125 [btrfs]
>    [39389.800016]  [<ffffffffa0622ced>] ? btrfs_find_item+0xa7/0xd2 [btrfs]
>    [39389.800016]  [<ffffffffa069363f>] btrfs_ref_to_path+0xd6/0x174 [btrfs]
>    [39389.800016]  [<ffffffffa0693730>] inode_to_path+0x53/0xa2 [btrfs]
>    [39389.800016]  [<ffffffffa0693e2e>] paths_from_inode+0x117/0x2ec [btrfs]
>    [39389.800016]  [<ffffffffa0670cff>] btrfs_ioctl+0xd5b/0x2793 [btrfs]
>    [39389.800016]  [<ffffffff8108a8b0>] ? arch_local_irq_save+0x9/0xc
>    [39389.800016]  [<ffffffff81276727>] ? __this_cpu_preempt_check+0x13/0x15
>    [39389.800016]  [<ffffffff8108a8b0>] ? arch_local_irq_save+0x9/0xc
>    [39389.800016]  [<ffffffff8118b3d4>] ? rcu_read_unlock+0x3e/0x5d
>    [39389.800016]  [<ffffffff811822f8>] do_vfs_ioctl+0x42b/0x4ea
>    [39389.800016]  [<ffffffff8118b4f3>] ? __fget_light+0x62/0x71
>    [39389.800016]  [<ffffffff8118240e>] SyS_ioctl+0x57/0x79
>    [39389.800016]  [<ffffffff814872d7>] entry_SYSCALL_64_fastpath+0x12/0x6f
>    [39389.800016] Code: b9 01 01 00 00 f7 c6 00 ff ff ff 75 32 83 fe 01 89 ca 89 f0 0f 45 d7 f0 0f b1 13 39 f0 74 04 89 c6 eb e2 ff ca 0f 84 fa 00 00 00 <8b> 03 84 c0 74 04 f3 90 eb f6 66 c7 03 01 00 e9 e6 00 00 00 e8
>    [39389.800012] Modules linked in: btrfs dm_mod ppdev xor sha256_generic hmac raid6_pq drbg ansi_cprng aesni_intel i2c_piix4 acpi_cpufreq aes_x86_64 ablk_helper tpm_tis parport_pc i2c_core sg cryptd evdev psmouse lrw tpm parport gf128mul serio_raw pcspkr glue_helper processor button loop autofs4 ext4 crc16 mbcache jbd2 sd_mod sr_mod cdrom ata_generic virtio_scsi ata_piix libata virtio_pci virtio_ring crc32c_intel scsi_mod e1000 virtio floppy [last unloaded: btrfs]
>    [39389.800012] irq event stamp: 0
>    [39389.800012] hardirqs last  enabled at (0): [<          (null)>]           (null)
>    [39389.800012] hardirqs last disabled at (0): [<ffffffff8104e58d>] copy_process+0x638/0x1a35
>    [39389.800012] softirqs last  enabled at (0): [<ffffffff8104e58d>] copy_process+0x638/0x1a35
>    [39389.800012] softirqs last disabled at (0): [<          (null)>]           (null)
>    [39389.800012] CPU: 15 PID: 32166 Comm: fdm-stress Tainted: G             L  4.4.0-rc6-btrfs-next-18+ #1
>    [39389.800012] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS by qemu-project.org 04/01/2014
>    [39389.800012] task: ffff880179294380 ti: ffff880034a60000 task.ti: ffff880034a60000
>    [39389.800012] RIP: 0010:[<ffffffff81091e8d>]  [<ffffffff81091e8d>] queued_write_lock_slowpath+0x62/0x72
>    [39389.800012] RSP: 0018:ffff880034a639f0  EFLAGS: 00000206
>    [39389.800012] RAX: 0000000000000101 RBX: ffff8801710c4e98 RCX: 0000000000000000
>    [39389.800012] RDX: 00000000000000ff RSI: 0000000000000000 RDI: ffff8801710c4e9c
>    [39389.800012] RBP: ffff880034a639f8 R08: 0000000000000001 R09: 0000000000000000
>    [39389.800012] R10: ffff880034a639b0 R11: 0000000000001000 R12: ffff8801710c4e98
>    [39389.800012] R13: 0000000000000001 R14: ffff880172cbc000 R15: ffff8801710c4e00
>    [39389.800012] FS:  00007f6d377fe700(0000) GS:ffff8802be9e0000(0000) knlGS:0000000000000000
>    [39389.800012] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>    [39389.800012] CR2: 00007f6d3d3c1000 CR3: 0000000037c93000 CR4: 00000000001406e0
>    [39389.800012] Stack:
>    [39389.800012]  ffff8801710c4e98 ffff880034a63a10 ffffffff81091963 ffff8801710c4e98
>    [39389.800012]  ffff880034a63a30 ffffffff81486f1b ffffffffa0672cb3 ffff8801710c4e00
>    [39389.800012]  ffff880034a63a78 ffffffffa0672cb3 ffff8801710c4e00 ffff880034a63a58
>    [39389.800012] Call Trace:
>    [39389.800012]  [<ffffffff81091963>] do_raw_write_lock+0x72/0x8c
>    [39389.800012]  [<ffffffff81486f1b>] _raw_write_lock+0x3a/0x41
>    [39389.800012]  [<ffffffffa0672cb3>] ? btrfs_tree_lock+0x119/0x251 [btrfs]
>    [39389.800012]  [<ffffffffa0672cb3>] btrfs_tree_lock+0x119/0x251 [btrfs]
>    [39389.800012]  [<ffffffffa061aeba>] ? rcu_read_unlock+0x5b/0x5d [btrfs]
>    [39389.800012]  [<ffffffffa061ce13>] ? btrfs_root_node+0xda/0xe6 [btrfs]
>    [39389.800012]  [<ffffffffa061ce83>] btrfs_lock_root_node+0x22/0x42 [btrfs]
>    [39389.800012]  [<ffffffffa062046b>] btrfs_search_slot+0x1b8/0x758 [btrfs]
>    [39389.800012]  [<ffffffff810fc6b0>] ? time_hardirqs_on+0x15/0x28
>    [39389.800012]  [<ffffffffa06365db>] btrfs_lookup_inode+0x31/0x95 [btrfs]
>    [39389.800012]  [<ffffffff8108d62f>] ? trace_hardirqs_on+0xd/0xf
>    [39389.800012]  [<ffffffff8148482b>] ? mutex_lock_nested+0x397/0x3bc
>    [39389.800012]  [<ffffffffa068821b>] __btrfs_update_delayed_inode+0x59/0x1c0 [btrfs]
>    [39389.800012]  [<ffffffffa068858e>] __btrfs_commit_inode_delayed_items+0x194/0x5aa [btrfs]
>    [39389.800012]  [<ffffffff81486ab7>] ? _raw_spin_unlock+0x31/0x44
>    [39389.800012]  [<ffffffffa0688a48>] __btrfs_run_delayed_items+0xa4/0x15c [btrfs]
>    [39389.800012]  [<ffffffffa0688d62>] btrfs_run_delayed_items+0x11/0x13 [btrfs]
>    [39389.800012]  [<ffffffffa064048e>] btrfs_commit_transaction+0x234/0x96e [btrfs]
>    [39389.800012]  [<ffffffffa0618d10>] btrfs_sync_fs+0x145/0x1ad [btrfs]
>    [39389.800012]  [<ffffffffa0671176>] btrfs_ioctl+0x11d2/0x2793 [btrfs]
>    [39389.800012]  [<ffffffff8108a8b0>] ? arch_local_irq_save+0x9/0xc
>    [39389.800012]  [<ffffffff81140261>] ? __might_fault+0x4c/0xa7
>    [39389.800012]  [<ffffffff81140261>] ? __might_fault+0x4c/0xa7
>    [39389.800012]  [<ffffffff8108a8b0>] ? arch_local_irq_save+0x9/0xc
>    [39389.800012]  [<ffffffff8118b3d4>] ? rcu_read_unlock+0x3e/0x5d
>    [39389.800012]  [<ffffffff811822f8>] do_vfs_ioctl+0x42b/0x4ea
>    [39389.800012]  [<ffffffff8118b4f3>] ? __fget_light+0x62/0x71
>    [39389.800012]  [<ffffffff8118240e>] SyS_ioctl+0x57/0x79
>    [39389.800012]  [<ffffffff814872d7>] entry_SYSCALL_64_fastpath+0x12/0x6f
>    [39389.800012] Code: f0 0f b1 13 85 c0 75 ef eb 2a f3 90 8a 03 84 c0 75 f8 f0 0f b0 13 84 c0 75 f0 ba ff 00 00 00 eb 0a f0 0f b1 13 ff c8 74 0b f3 90 <8b> 03 83 f8 01 75 f7 eb ed c6 43 04 00 5b 5d c3 0f 1f 44 00 00
>    
>    This happens because in the code path executed by the inode_paths ioctl we
>    end up nesting two calls to read lock a leaf's rwlock when after the first
>    call to read_lock() and before the second call to read_lock(), another
>    task (running the delayed items as part of a transaction commit) has
>    already called write_lock() against the leaf's rwlock. This situation is
>    illustrated by the following diagram:
>    
>             Task A                       Task B
>    
>      btrfs_ref_to_path()               btrfs_commit_transaction()
>        read_lock(&eb->lock);
>    
>                                          btrfs_run_delayed_items()
>                                            __btrfs_commit_inode_delayed_items()
>                                              __btrfs_update_delayed_inode()
>                                                btrfs_lookup_inode()
>    
>                                                  write_lock(&eb->lock);
>                                                    --> task waits for lock
>    
>        read_lock(&eb->lock);
>        --> makes this task hang
>            forever (and task B too
>    	of course)
>    
>    So fix this by avoiding doing the nested read lock, which is easily
>    avoidable. This issue does not happen if task B calls write_lock() after
>    task A does the second call to read_lock(), however there does not seem
>    to exist anything in the documentation that mentions what is the expected
>    behaviour for recursive locking of rwlocks (leaving the idea that doing
>    so is not a good usage of rwlocks).
>    
>    Also, as a side effect necessary for this fix, make sure we do not
>    needlessly read lock extent buffers when the input path has skip_locking
>    set (used when called from send).
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Filipe Manana <fdmanana@suse.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 422d2ab7e8cc67ed57d79a297f6832c74c0a0d80
>Author: Nicholas Bellinger <nab@linux-iscsi.org>
>Date:   Mon Jan 11 21:53:05 2016 -0800
>
>    target: Fix LUN_RESET active TMR descriptor handling
>    
>    [ Upstream commit a6d9bb1c9605cd4f44e2d8290dc4d0e88f20292d ]
>    
>    This patch fixes a NULL pointer se_cmd->cmd_kref < 0
>    refcount bug during TMR LUN_RESET with active TMRs,
>    triggered during se_cmd + se_tmr_req descriptor
>    shutdown + release via core_tmr_drain_tmr_list().
>    
>    To address this bug, go ahead and obtain a local
>    kref_get_unless_zero(&se_cmd->cmd_kref) for active I/O
>    to set CMD_T_ABORTED, and transport_wait_for_tasks()
>    followed by the final target_put_sess_cmd() to drop
>    the local ->cmd_kref.
>    
>    Also add two new checks within target_tmr_work() to
>    avoid CMD_T_ABORTED -> TFO->queue_tm_rsp() callbacks
>    ahead of invoking the backend -> fabric put in
>    transport_cmd_check_stop_to_fabric().
>    
>    For good measure, also change core_tmr_release_req()
>    to use list_del_init() ahead of se_tmr_req memory
>    free.
>    
>    Reviewed-by: Quinn Tran <quinn.tran@qlogic.com>
>    Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
>    Cc: Sagi Grimberg <sagig@mellanox.com>
>    Cc: Christoph Hellwig <hch@lst.de>
>    Cc: Hannes Reinecke <hare@suse.de>
>    Cc: Andy Grover <agrover@redhat.com>
>    Cc: Mike Christie <mchristi@redhat.com>
>    Cc: stable@vger.kernel.org # 3.10+
>    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6f04c5131ca6a50b8b7747eed79bf5efe9c51e8b
>Author: Bart Van Assche <bart.vanassche@sandisk.com>
>Date:   Mon Apr 27 13:52:36 2015 +0200
>
>    target: Remove first argument of target_{get,put}_sess_cmd()
>    
>    [ Upstream commit afc16604c06414223478df3e42301ab630b9960a ]
>    
>    The first argument of these two functions is always identical
>    to se_cmd->se_sess. Hence remove the first argument.
>    
>    Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
>    Reviewed-by: Sagi Grimberg <sagig@mellanox.com>
>    Reviewed-by: Christoph Hellwig <hch@lst.de>
>    Cc: Andy Grover <agrover@redhat.com>
>    Cc: <qla2xxx-upstream@qlogic.com>
>    Cc: Felipe Balbi <balbi@ti.com>
>    Cc: Michael S. Tsirkin <mst@redhat.com>
>    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 988ba6758fbc851c71505c3df18eb8af1e730fa7
>Author: Vinod Koul <vinod.koul@intel.com>
>Date:   Mon Feb 1 22:26:40 2016 +0530
>
>    ASoC: dpcm: fix the BE state on hw_free
>    
>    [ Upstream commit 5e82d2be6ee53275c72e964507518d7964c82753 ]
>    
>    While performing hw_free, DPCM checks the BE state but leaves out
>    the suspend state. The suspend state needs to be checked as well,
>    as we might be suspended and then usermode closes rather than
>    resuming the audio stream.
>    
>    This was found by a stress testing of system with playback in
>    loop and killed after few seconds running in background and second
>    script running suspend-resume test in loop
>    
>    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
>    Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
>    Signed-off-by: Mark Brown <broonie@kernel.org>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 992eab6ecc8255a005c6bfc9505eca9a8d08206a
>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()
>    
>    [ Upstream commit 0f26922fe5dc5724b1adbbd54b21bad03590b4f3 ]
>    
>    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>
>    Cc: stable@vger.kernel.org
>    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: Sasha Levin <sasha.levin@oracle.com>
>
>commit 35eacd10a054fb9658f8c15edd5cac19a476db9d
>Author: James Hogan <james.hogan@imgtec.com>
>Date:   Mon Jan 25 20:32:03 2016 +0000
>
>    MIPS: Fix buffer overflow in syscall_get_arguments()
>    
>    [ Upstream commit f4dce1ffd2e30fa31756876ef502ce6d2324be35 ]
>    
>    Since commit 4c21b8fd8f14 ("MIPS: seccomp: Handle indirect system calls
>    (o32)"), syscall_get_arguments() attempts to handle o32 indirect syscall
>    arguments by incrementing both the start argument number and the number
>    of arguments to fetch. However only the start argument number needs to
>    be incremented. The number of arguments does not change, they're just
>    shifted up by one, and in fact the output array is provided by the
>    caller and is likely only n entries long, so reading more arguments
>    overflows the output buffer.
>    
>    In the case of seccomp, this results in it fetching 7 arguments starting
>    at the 2nd one, which overflows the unsigned long args[6] in
>    populate_seccomp_data(). This clobbers the $s0 register from
>    syscall_trace_enter() which __seccomp_phase1_filter() saved onto the
>    stack, into which syscall_trace_enter() had placed its syscall number
>    argument. This caused Chromium to crash.
>    
>    Credit goes to Milko for tracking it down as far as $s0 being clobbered.
>    
>    Fixes: 4c21b8fd8f14 ("MIPS: seccomp: Handle indirect system calls (o32)")
>    Reported-by: Milko Leporis <milko.leporis@imgtec.com>
>    Signed-off-by: James Hogan <james.hogan@imgtec.com>
>    Cc: linux-mips@linux-mips.org
>    Cc: <stable@vger.kernel.org> # 3.15-
>    Patchwork: https://patchwork.linux-mips.org/patch/12213/
>    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3fa9638c67f6e7f3c4a242ecb21eaacda9dcff91
>Author: Tejun Heo <tj@kernel.org>
>Date:   Mon Feb 1 11:33:21 2016 -0500
>
>    libata: fix sff host state machine locking while polling
>    
>    [ Upstream commit 8eee1d3ed5b6fc8e14389567c9a6f53f82bb7224 ]
>    
>    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
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit abd62631a46c8a27fc607ea5525d3034e8d69781
>Author: Dan Carpenter <dan.carpenter@oracle.com>
>Date:   Tue Jan 26 12:24:25 2016 +0300
>
>    intel_scu_ipcutil: underflow in scu_reg_access()
>    
>    [ Upstream commit b1d353ad3d5835b16724653b33c05124e1b5acf1 ]
>    
>    "count" is controlled by the user and it can be negative.  Let's prevent
>    that by making it unsigned.  You have to have CAP_SYS_RAWIO to call this
>    function so the bug is not as serious as it could be.
>    
>    Fixes: 5369c02d951a ('intel_scu_ipc: Utility driver for intel scu ipc')
>    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Darren Hart <dvhart@linux.intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ce4f0721444eea05c31c072981a165750b8b243b
>Author: Alexei Potashnik <alexei@purestorage.com>
>Date:   Tue Jul 14 16:00:49 2015 -0400
>
>    qla2xxx: terminate exchange when command is aborted by LIO
>    
>    [ Upstream commit 7359df25a53386dd33c223672bbd12cb49d0ce4f ]
>    
>    The newly introduced aborted_task TFO callback has to terminate
>    exchange with QLogic driver, since command is being deleted and
>    no status will be queued to the driver at a later point.
>    
>    This patch also moves the burden of releasing one cmd refcount to
>    the aborted_task handler.
>    
>    Changed iSCSI aborted_task logic to satisfy the above requirement.
>    
>    Cc: <stable@vger.kernel.org> # v3.18+
>    Signed-off-by: Alexei Potashnik <alexei@purestorage.com>
>    Acked-by: Quinn Tran <quinn.tran@qlogic.com>
>    Signed-off-by: Himanshu Madhani <himanshu.madhani@qlogic.com>
>    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit eaaecc5e28b49dc00c4c36f1f5fd1acf1f4f4be1
>Author: Alexei Potashnik <alexei@purestorage.com>
>Date:   Tue Jul 14 16:00:46 2015 -0400
>
>    qla2xxx: added sess generations to detect RSCN update races
>    
>    [ Upstream commit df673274fa4896f25f0bf348d2a3535d74b4cbec ]
>    
>    RSCN processing in qla2xxx driver can run in parallel with ELS/IO
>    processing. As such the decision to remove disappeared fc port's
>    session could be stale, because a new login sequence has occurred
>    since and created a brand new session.
>    
>    Previous mechanism of dealing with this by delaying deletion request
>    was prone to erroneous deletions if the event that was supposed to
>    cancel the deletion never arrived or has been delayed in processing.
>    
>    New mechanism relies on a time-like generation counter to serialize
>    RSCN updates relative to ELS/IO updates.
>    
>    Cc: <stable@vger.kernel.org> # v3.18+
>    Signed-off-by: Alexei Potashnik <alexei@purestorage.com>
>    Signed-off-by: Himanshu Madhani <himanshu.madhani@qlogic.com>
>    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1226aefc12eef8b339bdaff0bfe11d72eb4978df
>Author: Alexei Potashnik <alexei@purestorage.com>
>Date:   Tue Jul 14 16:00:45 2015 -0400
>
>    qla2xxx: Abort stale cmds on qla_tgt_wq when plogi arrives
>    
>    [ Upstream commit daddf5cf9b5c68b81b2bb7133f1dd0fda4552d0b ]
>    
>    cancel any commands from initiator's s_id that are still waiting
>    on qla_tgt_wq when PLOGI arrives.
>    
>    Cc: <stable@vger.kernel.org> # v3.18+
>    Signed-off-by: Alexei Potashnik <alexei@purestorage.com>
>    Acked-by: Quinn Tran <quinn.tran@qlogic.com>
>    Signed-off-by: Himanshu Madhani <himanshu.madhani@qlogic.com>
>    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 772d56fecb6dde547473cf7b556f457555897da7
>Author: Alexei Potashnik <alexei@purestorage.com>
>Date:   Tue Jul 14 16:00:48 2015 -0400
>
>    qla2xxx: drop cmds/tmrs arrived while session is being deleted
>    
>    [ Upstream commit e52a8b45b9c782937f74b701f8c656d4e5619eb5 ]
>    
>    If a new initiator (different WWN) shows up on the same fcport, old
>    initiator's session is scheduled for deletion. But there is a small
>    window between it being marked with QLA_SESS_DELETION_IN_PROGRESS
>    and qlt_unret_sess getting called when new session's commands will
>    keep finding old session in the fcport map.
>    
>    This patch drops cmds/tmrs if they find session in the progress of
>    being deleted.
>    
>    Cc: <stable@vger.kernel.org> # v3.18+
>    Signed-off-by: Alexei Potashnik <alexei@purestorage.com>
>    Acked-by: Quinn Tran <quinn.tran@qlogic.com>
>    Signed-off-by: Himanshu Madhani <himanshu.madhani@qlogic.com>
>    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f89ace487f87aa90b7426ec94872cc38ee11fd1e
>Author: Alexei Potashnik <alexei@purestorage.com>
>Date:   Tue Jul 14 16:00:44 2015 -0400
>
>    qla2xxx: delay plogi/prli ack until existing sessions are deleted
>    
>    [ Upstream commit a6ca88780dd66b0700d89419abd17b6b4bb49483 ]
>    
>    - keep qla_tgt_sess object on the session list until it's freed
>    
>    - modify use of sess->deleted flag to differentiate delayed
>      session deletion that can be cancelled from irreversible one:
>      QLA_SESS_DELETION_PENDING vs QLA_SESS_DELETION_IN_PROGRESS
>    
>    - during IN_PROGRESS deletion all newly arrived commands and TMRs will
>      be rejected, existing commands and TMRs will be terminated when
>      given by the core to the fabric or simply dropped if session logout
>      has already happened (logout terminates all existing exchanges)
>    
>    - new PLOGI will initiate deletion of the following sessions
>      (unless deletion is already IN_PROGRESS):
>      - with the same port_name (with logout)
>      - different port_name, different loop_id but the same port_id
>        (with logout)
>      - different port_name, different port_id, but the same loop_id
>        (without logout)
>    
>    - additionally each new PLOGI will store imm notify iocb in the
>      same port_name session being deleted. When deletion process
>      completes this iocb will be acked. Only the most recent PLOGI
>      iocb is stored. The older ones will be terminated when replaced.
>    
>    - new PRLI will initiate deletion of the following sessions
>      (unless deletion is already IN_PROGRESS):
>      - different port_name, different port_id, but the same loop_id
>       (without logout)
>    
>    Cc: <stable@vger.kernel.org> # v3.18+
>    Signed-off-by: Alexei Potashnik <alexei@purestorage.com>
>    Acked-by: Quinn Tran <quinn.tran@qlogic.com>
>    Signed-off-by: Himanshu Madhani <himanshu.madhani@qlogic.com>
>    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ea116368a3680fc4ea10196736adae2109f96301
>Author: Swapnil Nagle <swapnil.nagle@purestorage.com>
>Date:   Tue Jul 14 16:00:43 2015 -0400
>
>    qla2xxx: cleanup cmd in qla workqueue before processing TMR
>    
>    [ Upstream commit 8b2f5ff3d05c2c48b722c3cc67b8226f1601042b ]
>    
>    Since cmds go into qla_tgt_wq and TMRs don't, it's possible that TMR
>    like TASK_ABORT can be queued over the cmd for which it was meant.
>    To avoid this race, use a per-port list to keep track of cmds that
>    are enqueued to qla_tgt_wq but not yet processed. When a TMR arrives,
>    iterate through this list and remove any cmds that match the TMR.
>    This patch supports TASK_ABORT and LUN_RESET.
>    
>    Cc: <stable@vger.kernel.org> # v3.18+
>    Signed-off-by: Swapnil Nagle <swapnil.nagle@purestorage.com>
>    Signed-off-by: Alexei Potashnik <alexei@purestorage.com>
>    Acked-by: Quinn Tran <quinn.tran@qlogic.com>
>    Signed-off-by: Himanshu Madhani <himanshu.madhani@qlogic.com>
>    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f5fa85b4e599a45e6d056d44eb920eb42ed63849
>Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>Date:   Sat Jan 16 10:04:49 2016 -0800
>
>    Input: vmmouse - fix absolute device registration
>    
>    [ Upstream commit d4f1b06d685d11ebdaccf11c0db1cb3c78736862 ]
>    
>    We should set device's capabilities first, and then register it,
>    otherwise various handlers already present in the kernel will not be
>    able to connect to the device.
>    
>    Reported-by: Lauri Kasanen <cand@gmx.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c77c01982668678a5fafe3036be4e757b7eddbaf
>Author: Tejun Heo <tj@kernel.org>
>Date:   Fri Jan 15 15:13:05 2016 -0500
>
>    libata: disable forced PORTS_IMPL for >= AHCI 1.3
>    
>    [ Upstream commit 566d1827df2ef0cbe921d3d6946ac3007b1a6938 ]
>    
>    Some early controllers incorrectly reported zero ports in PORTS_IMPL
>    register and the ahci driver fabricates PORTS_IMPL from the number of
>    ports in those cases.  This hasn't mattered but with the new nvme
>    controllers there are cases where zero PORTS_IMPL is valid and should
>    be honored.
>    
>    Disable the workaround for >= AHCI 1.3.
>    
>    Signed-off-by: Tejun Heo <tj@kernel.org>
>    Reported-by: Andy Lutomirski <luto@amacapital.net>
>    Link: http://lkml.kernel.org/g/CALCETrU7yMvXEDhjAUShoHEhDwifJGapdw--BKxsP0jmjKGmRw@mail.gmail.com
>    Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1e7516689817b56f78dc60497a4dd7c80319417e
>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
>    
>    [ Upstream commit 4ae2182b1e3407de369f8c5d799543b7db74221b ]
>    
>    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>
>    CC: stable@vger.kernel.org
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2b65014b4a1083a8715f3425b292723d9729e3d0
>Author: Tejun Heo <tj@kernel.org>
>Date:   Thu Jan 21 15:31:11 2016 -0500
>
>    cgroup: make sure a parent css isn't offlined before its children
>    
>    [ Upstream commit aa226ff4a1ce79f229c6b7a4c0a14e17fececd01 ]
>    
>    There are three subsystem callbacks in css shutdown path -
>    css_offline(), css_released() and css_free().  Except for
>    css_released(), cgroup core didn't guarantee the order of invocation.
>    css_offline() or css_free() could be called on a parent css before its
>    children.  This behavior is unexpected and led to bugs in cpu and
>    memory controller.
>    
>    This patch updates offline path so that a parent css is never offlined
>    before its children.  Each css keeps online_cnt which reaches zero iff
>    itself and all its children are offline and offline_css() is invoked
>    only after online_cnt reaches zero.
>    
>    This fixes the memory controller bug and allows the fix for cpu
>    controller.
>    
>    Signed-off-by: Tejun Heo <tj@kernel.org>
>    Reported-and-tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
>    Reported-by: Brian Christiansen <brian.o.christiansen@gmail.com>
>    Link: http://lkml.kernel.org/g/5698A023.9070703@de.ibm.com
>    Link: http://lkml.kernel.org/g/CAKB58ikDkzc8REt31WBkD99+hxNzjK4+FBmhkgS+NVrC9vjMSg@mail.gmail.com
>    Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 13a16b9e3907607e4a324373362701c26f6e1cea
>Author: Tejun Heo <tj@kernel.org>
>Date:   Wed May 13 15:38:40 2015 -0400
>
>    cgroup: separate out include/linux/cgroup-defs.h
>    
>    [ Upstream commit b4a04ab7a37b490cad48e69abfe14288cacb669c ]
>    
>    From 2d728f74bfc071df06773e2fd7577dd5dab6425d Mon Sep 17 00:00:00 2001
>    From: Tejun Heo <tj@kernel.org>
>    Date: Wed, 13 May 2015 15:37:01 -0400
>    
>    This patch separates out cgroup-defs.h from cgroup.h which has grown a
>    lot of dependencies.  cgroup-defs.h currently only contains constant
>    and type definitions and can be used to break circular include
>    dependency.  While moving, definitions are reordered so that
>    cgroup-defs.h has consistent logical structure.
>    
>    This patch is pure reorganization.
>    
>    Signed-off-by: Tejun Heo <tj@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 69cc9251b85d6ddfd8e94b6be60aacdceec98b22
>Author: Bard Liao <bardliao@realtek.com>
>Date:   Thu Jan 21 13:13:40 2016 +0800
>
>    ASoC: rt5645: fix the shift bit of IN1 boost
>    
>    [ Upstream commit b28785fa9cede0d4f47310ca0dd2a4e1d50478b5 ]
>    
>    The shift bit of IN1 boost gain control is 12.
>    
>    Signed-off-by: Bard Liao <bardliao@realtek.com>
>    Signed-off-by: Mark Brown <broonie@kernel.org>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 789a2e5a69bc3dd5197b8f51451359d06c4ac8a1
>Author: CQ Tang <cq.tang@intel.com>
>Date:   Wed Jan 13 21:15:03 2016 +0000
>
>    iommu/vt-d: Fix 64-bit accesses to 32-bit DMAR_GSTS_REG
>    
>    [ Upstream commit fda3bec12d0979aae3f02ee645913d66fbc8a26e ]
>    
>    This is a 32-bit register. Apparently harmless on real hardware, but
>    causing justified warnings in simulation.
>    
>    Signed-off-by: CQ Tang <cq.tang@intel.com>
>    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 83fdace666f72dbfc4a7681a04e3689b61dae3b9
>Author: Sasha Levin <sasha.levin@oracle.com>
>Date:   Mon Feb 15 15:46:24 2016 -0500
>
>    Linux 4.1.18
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0479b826457382c39d369acc95347621a347414e
>Author: David Howells <dhowells@redhat.com>
>Date:   Fri Sep 25 16:31:46 2015 +0100
>
>    X.509: Don't strip leading 00's from key ID when constructing key description
>    
>    [ Upstream commit e7c87bef7de2417b219d4dbfe8d33a0098a8df54 ]
>    
>    Don't strip leading zeros from the crypto key ID when using it to construct
>    the struct key description as the signature in kernels up to and including
>    4.2 matched this aspect of the key.  This means that 1 in 256 keys won't
>    actually match if their key ID begins with 00.
>    
>    The key ID is stored in the module signature as binary and so must be
>    converted to text in order to invoke request_key() - but it isn't stripped
>    at this point.
>    
>    Something like this is likely to be observed in dmesg when the key is loaded:
>    
>    [    1.572423] Loaded X.509 cert 'Build time autogenerated kernel
>        key: 62a7c3d2da278be024da4af8652c071f3fea33'
>    
>    followed by this when we try and use it:
>    
>      [    1.646153] Request for unknown module key 'Build time autogenerated
>        kernel key: 0062a7c3d2da278be024da4af8652c071f3fea33' err -11
>    
>    The 'Loaded' line should show an extra '00' on the front of the hex string.
>    
>    This problem should not affect 4.3-rc1 and onwards because there the key
>    should be matched on one of its auxiliary identities rather than the key
>    struct's description string.
>    
>    Reported-by: Arjan van de Ven <arjan@linux.intel.com>
>    Reported-by: Andy Whitcroft <apw@canonical.com>
>    Signed-off-by: David Howells <dhowells@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 42362e1f5a73d36fcaf3eb4950dfc17f633ea0d3
>Author: Konstantin Khlebnikov <koct9i@gmail.com>
>Date:   Fri Feb 5 15:37:01 2016 -0800
>
>    radix-tree: fix oops after radix_tree_iter_retry
>    
>    [ Upstream commit 732042821cfa106b3c20b9780e4c60fee9d68900 ]
>    
>    Helper radix_tree_iter_retry() resets next_index to the current index.
>    In following radix_tree_next_slot current chunk size becomes zero.  This
>    isn't checked and it tries to dereference null pointer in slot.
>    
>    Tagged iterator is fine because retry happens only at slot 0 where tag
>    bitmask in iter->tags is filled with single bit.
>    
>    Fixes: 46437f9a554f ("radix-tree: fix race in gang lookup")
>    Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com>
>    Cc: Matthew Wilcox <willy@linux.intel.com>
>    Cc: Hugh Dickins <hughd@google.com>
>    Cc: Ohad Ben-Cohen <ohad@wizery.com>
>    Cc: Jeremiah Mahler <jmmahler@gmail.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4b5eaa857d64ea737c3bed1eb9b3dd201dd2cecf
>Author: Konstantin Khlebnikov <koct9i@gmail.com>
>Date:   Fri Feb 5 15:36:50 2016 -0800
>
>    mm: replace vma_lock_anon_vma with anon_vma_lock_read/write
>    
>    [ Upstream commit 12352d3cae2cebe18805a91fab34b534d7444231 ]
>    
>    Sequence vma_lock_anon_vma() - vma_unlock_anon_vma() isn't safe if
>    anon_vma appeared between lock and unlock.  We have to check anon_vma
>    first or call anon_vma_prepare() to be sure that it's here.  There are
>    only few users of these legacy helpers.  Let's get rid of them.
>    
>    This patch fixes anon_vma lock imbalance in validate_mm().  Write lock
>    isn't required here, read lock is enough.
>    
>    And reorders expand_downwards/expand_upwards: security_mmap_addr() and
>    wrapping-around check don't have to be under anon vma lock.
>    
>    Link: https://lkml.kernel.org/r/CACT4Y+Y908EjM2z=706dv4rV6dWtxTLK9nFg9_7DhRMLppBo2g@mail.gmail.com
>    Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com>
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>    Cc: Andrea Arcangeli <aarcange@redhat.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ff5ecd2953a635bf70101dac550fcb01ced863e9
>Author: xuejiufei <xuejiufei@huawei.com>
>Date:   Fri Feb 5 15:36:47 2016 -0800
>
>    ocfs2/dlm: clear refmap bit of recovery lock while doing local recovery cleanup
>    
>    [ Upstream commit c95a51807b730e4681e2ecbdfd669ca52601959e ]
>    
>    When recovery master down, dlm_do_local_recovery_cleanup() only remove
>    the $RECOVERY lock owned by dead node, but do not clear the refmap bit.
>    Which will make umount thread falling in dead loop migrating $RECOVERY
>    to the dead node.
>    
>    Signed-off-by: xuejiufei <xuejiufei@huawei.com>
>    Reviewed-by: Joseph Qi <joseph.qi@huawei.com>
>    Cc: Mark Fasheh <mfasheh@suse.de>
>    Cc: Joel Becker <jlbec@evilplan.org>
>    Cc: Junxiao Bi <junxiao.bi@oracle.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8a4ebc74857af2377d9b3f756714ded686e01b66
>Author: Eric Dumazet <edumazet@google.com>
>Date:   Fri Feb 5 15:36:16 2016 -0800
>
>    dump_stack: avoid potential deadlocks
>    
>    [ Upstream commit d7ce36924344ace0dbdc855b1206cacc46b36d45 ]
>    
>    Some servers experienced fatal deadlocks because of a combination of
>    bugs, leading to multiple cpus calling dump_stack().
>    
>    The checksumming bug was fixed in commit 34ae6a1aa054 ("ipv6: update
>    skb->csum when CE mark is propagated").
>    
>    The second problem is a faulty locking in dump_stack()
>    
>    CPU1 runs in process context and calls dump_stack(), grabs dump_lock.
>    
>       CPU2 receives a TCP packet under softirq, grabs socket spinlock, and
>       call dump_stack() from netdev_rx_csum_fault().
>    
>       dump_stack() spins on atomic_cmpxchg(&dump_lock, -1, 2), since
>       dump_lock is owned by CPU1
>    
>    While dumping its stack, CPU1 is interrupted by a softirq, and happens
>    to process a packet for the TCP socket locked by CPU2.
>    
>    CPU1 spins forever in spin_lock() : deadlock
>    
>    Stack trace on CPU1 looked like :
>    
>        NMI backtrace for cpu 1
>        RIP: _raw_spin_lock+0x25/0x30
>        ...
>        Call Trace:
>          <IRQ>
>          tcp_v6_rcv+0x243/0x620
>          ip6_input_finish+0x11f/0x330
>          ip6_input+0x38/0x40
>          ip6_rcv_finish+0x3c/0x90
>          ipv6_rcv+0x2a9/0x500
>          process_backlog+0x461/0xaa0
>          net_rx_action+0x147/0x430
>          __do_softirq+0x167/0x2d0
>          call_softirq+0x1c/0x30
>          do_softirq+0x3f/0x80
>          irq_exit+0x6e/0xc0
>          smp_call_function_single_interrupt+0x35/0x40
>          call_function_single_interrupt+0x6a/0x70
>          <EOI>
>          printk+0x4d/0x4f
>          printk_address+0x31/0x33
>          print_trace_address+0x33/0x3c
>          print_context_stack+0x7f/0x119
>          dump_trace+0x26b/0x28e
>          show_trace_log_lvl+0x4f/0x5c
>          show_stack_log_lvl+0x104/0x113
>          show_stack+0x42/0x44
>          dump_stack+0x46/0x58
>          netdev_rx_csum_fault+0x38/0x3c
>          __skb_checksum_complete_head+0x6e/0x80
>          __skb_checksum_complete+0x11/0x20
>          tcp_rcv_established+0x2bd5/0x2fd0
>          tcp_v6_do_rcv+0x13c/0x620
>          sk_backlog_rcv+0x15/0x30
>          release_sock+0xd2/0x150
>          tcp_recvmsg+0x1c1/0xfc0
>          inet_recvmsg+0x7d/0x90
>          sock_recvmsg+0xaf/0xe0
>          ___sys_recvmsg+0x111/0x3b0
>          SyS_recvmsg+0x5c/0xb0
>          system_call_fastpath+0x16/0x1b
>    
>    Fixes: b58d977432c8 ("dump_stack: serialize the output from dump_stack()")
>    Signed-off-by: Eric Dumazet <edumazet@google.com>
>    Cc: Alex Thorlton <athorlton@sgi.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9e3ba11cb727f20a2aa74e90f1858c7c49ed8e64
>Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>Date:   Thu Jul 9 23:44:31 2015 +0200
>
>    drm/i915: Take all modeset locks for DP MST hotplug
>    
>    [ Upstream commit 8bb4da1df54a20d68c34427356e34315ba122c0f ]
>    
>    While auditing various users of the connector/encoder lists I realized
>    that the atomic code is a very prolific user of them. And it only ever
>    grabs the mode_config->connection_mutex, but not the
>    mode_config->mutex like all the other code walking encoder/connector
>    lists.
>    
>    The problem is that we can't grab the mode_config.mutex late in atomic
>    code since that would lead to locking inversions. And we don't want to
>    grab it unconditionally like the legacy set_config modeset path since
>    that would render all the fine-grained locking moot.
>    
>    Instead just grab more locks in the dp mst hotplug code. Note that
>    drm_connector_init (which is the one adding the connector to these
>    lists) already uses drm_modeset_lock_all.
>    
>    The other reason for grabbing all locks is that the dpms off in the
>    unplug function amounts to a modeset, so better to take all required
>    locks for that.
>    
>    Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit fde3cda03b3f681ecf3d92a56f045104174493e3
>Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>Date:   Thu Jul 9 23:44:32 2015 +0200
>
>    drm/radeon: Take all modeset locks for DP MST hotplug
>    
>    [ Upstream commit 2ee6bcdcfa4d8b56b20bc6308cd5f9bced5b5324 ]
>    
>    Similar with the i915 take all modeset locks for mst hotplug. This is
>    needed to make sure radeon holds both mode_config.mutex and
>    mode_config.connection_mutex when updating the connector_list, which
>    is the new (interim) locking regime we want for that.
>    
>    Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 06f4d7cebea5027bd8773df0557c6bbaaf2c77a2
>Author: Dave Airlie <airlied@redhat.com>
>Date:   Wed Sep 16 10:37:28 2015 +1000
>
>    drm/dp/mst: fixup handling hotplug on port removal.
>    
>    [ Upstream commit df4839fdc9b3c922586b945f062f38cbbda022bb ]
>    
>    output ports should always have a connector, unless
>    in the rare case connector allocation fails in the
>    driver.
>    
>    In this case we only need to teardown the pdt,
>    and free the struct, and there is no need to
>    send a hotplug msg.
>    
>    In the case were we add the port to the destroy
>    list we need to send a hotplug if we destroy
>    any connectors, so userspace knows to reprobe
>    stuff.
>    
>    this patch also handles port->connector allocation
>    failing which should be a rare event, but makes
>    the code consistent.
>    
>    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Dave Airlie <airlied@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7d1dc93a85c3593f35985b78ab5325085c2fa2e6
>Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>Date:   Tue Aug 11 09:54:29 2015 +0200
>
>    drm/dp/mst: Remove port after removing connector.
>    
>    [ Upstream commit 4772ff03df8094fd99d28de5fcf5df3a3e9c68bb ]
>    
>    The port is removed synchronously, but the connector delayed.
>    This causes a use after free which can cause a kernel BUG with
>    slug_debug=FPZU. This is fixed by freeing the port after the
>    connector.
>    
>    This fixes a regression introduced with
>    6b8eeca65b18ae77e175cc2b6571731f0ee413bf
>    "drm/dp/mst: close deadlock in connector destruction."
>    
>    Cc: stable@vger.kernel.org
>    Cc: Dave Airlie <airlied@redhat.com>
>    Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 95b098789dd20a09885c288fe8db200c26490c18
>Author: Harry Wentland <harry.wentland@amd.com>
>Date:   Fri Jan 22 17:07:26 2016 -0500
>
>    drm/dp/mst: Calculate MST PBN with 31.32 fixed point
>    
>    [ Upstream commit a9ebb3e46c7ef6112c0da466ef0954673ad36832 ]
>    
>    Our PBN value overflows the 20 bits integer part of the 20.12
>    fixed point. We need to use 31.32 fixed point to avoid this.
>    
>    This happens with display clocks larger than 293122 (at 24 bpp),
>    which we see with the Sharp (and similar) 4k tiled displays.
>    
>    Signed-off-by: Harry Wentland <harry.wentland@amd.com>
>    Cc: stable@vger.kernel.org
>    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>    Signed-off-by: Dave Airlie <airlied@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit bd31f0f4dfa04f1afe2ac88b32a745dad80718e2
>Author: Harry Wentland <harry.wentland@amd.com>
>Date:   Fri Jan 22 17:07:25 2016 -0500
>
>    drm: Add drm_fixp_from_fraction and drm_fixp2int_ceil
>    
>    [ Upstream commit 64566b5e767f9bc3161055ca1b443a51afb52aad ]
>    
>    drm_fixp_from_fraction allows us to create a fixed point directly
>    from a fraction, rather than creating fixed point values and dividing
>    later. This avoids overflow of our 64 bit value for large numbers.
>    
>    drm_fixp2int_ceil allows us to return the ceiling of our fixed point
>    value.
>    
>    [airlied: squash Jordan's fix]
>    32-bit-build-fix: Jordan Lazare <Jordan.Lazare@amd.com>
>    Signed-off-by: Harry Wentland <harry.wentland@amd.com>
>    Cc: stable@vger.kernel.org
>    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>    Signed-off-by: Dave Airlie <airlied@redhat.com>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 81c5fe348992a0896473724c556b6632b8acd4a7
>Author: Insu Yun <wuninsu@gmail.com>
>Date:   Mon Feb 1 11:08:29 2016 -0500
>
>    drm: fix missing reference counting decrease
>    
>    [ Upstream commit dabe19540af9e563d526113bb102e1b9b9fa73f9 ]
>    
>    In drm_dp_mst_allocate_vcpi, it returns true in two paths,
>    but in one path, there is no reference couting decrease.
>    
>    Signed-off-by: Insu Yun <wuninsu@gmail.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Dave Airlie <airlied@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit df2aeb317e3e6d1da2de045748064df63bc11944
>Author: Linus Walleij <linus.walleij@linaro.org>
>Date:   Mon Feb 1 14:18:57 2016 +0100
>
>    ARM: nomadik: fix up SD/MMC DT settings
>    
>    [ Upstream commit 418d5516568b3fdbc4e7b53677dd78aed8514565 ]
>    
>    The DTSI file for the Nomadik does not properly specify how the
>    PL180 levelshifter is connected: the Nomadik actually needs all
>    the five st,sig-dir-* flags set to properly control all lines out.
>    
>    Further this board supports full power cycling of the card, and
>    since this variant has no hardware clock gating, it needs a
>    ridiculously low frequency setting to keep up with the ever
>    overflowing FIFO.
>    
>    The pin configuration set-up is a bit of a mystery, because of
>    course these pins are a mix of inputs and outputs. However the
>    reference implementation sets all pins to "output" with
>    unspecified initial value, so let's do that here as well.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>    Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
>    Signed-off-by: Olof Johansson <olof@lixom.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit aec01beb5eed22fed5291dc73f9b5f70c4d34218
>Author: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
>Date:   Thu Feb 4 15:59:43 2016 -0200
>
>    [media] saa7134-alsa: Only frees registered sound cards
>    
>    [ Upstream commit ac75fe5d8fe4a0bf063be18fb29684405279e79e ]
>    
>    That prevents this bug:
>    [ 2382.269496] BUG: unable to handle kernel NULL pointer dereference at 0000000000000540
>    [ 2382.270013] IP: [<ffffffffa01fe616>] snd_card_free+0x36/0x70 [snd]
>    [ 2382.270013] PGD 0
>    [ 2382.270013] Oops: 0002 [#1] SMP
>    [ 2382.270013] Modules linked in: saa7134_alsa(-) tda1004x saa7134_dvb videobuf2_dvb dvb_core tda827x tda8290 tuner saa7134 tveeprom videobuf2_dma_sg videobuf2_memops videobuf2_v4l2 videobuf2_core v4l2_common videodev media auth_rpcgss nfsv4 dns_resolver nfs lockd grace sunrpc tun bridge stp llc ebtables ip6table_filter ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack it87 hwmon_vid snd_hda_codec_idt snd_hda_codec_generic iTCO_wdt iTCO_vendor_support snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_seq pcspkr i2c_i801 snd_seq_device snd_pcm snd_timer lpc_ich snd mfd_core soundcore binfmt_misc i915 video i2c_algo_bit drm_kms_helper drm r8169 ata_generic serio_raw pata_acpi mii i2c_core [last unloaded: videobuf2_memops]
>    [ 2382.270013] CPU: 0 PID: 4899 Comm: rmmod Not tainted 4.5.0-rc1+ #4
>    [ 2382.270013] Hardware name: PCCHIPS P17G/P17G, BIOS 080012  05/14/2008
>    [ 2382.270013] task: ffff880039c38000 ti: ffff88003c764000 task.ti: ffff88003c764000
>    [ 2382.270013] RIP: 0010:[<ffffffffa01fe616>]  [<ffffffffa01fe616>] snd_card_free+0x36/0x70 [snd]
>    [ 2382.270013] RSP: 0018:ffff88003c767ea0  EFLAGS: 00010286
>    [ 2382.270013] RAX: ffff88003c767eb8 RBX: 0000000000000000 RCX: 0000000000006260
>    [ 2382.270013] RDX: ffffffffa020a060 RSI: ffffffffa0206de1 RDI: ffff88003c767eb0
>    [ 2382.270013] RBP: ffff88003c767ed8 R08: 0000000000019960 R09: ffffffff811a5412
>    [ 2382.270013] R10: ffffea0000d7c200 R11: 0000000000000000 R12: ffff88003c767ea8
>    [ 2382.270013] R13: 00007ffe760617f7 R14: 0000000000000000 R15: 0000557625d7f1e0
>    [ 2382.270013] FS:  00007f80bb1c0700(0000) GS:ffff88003f400000(0000) knlGS:0000000000000000
>    [ 2382.270013] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>    [ 2382.270013] CR2: 0000000000000540 CR3: 000000003c00f000 CR4: 00000000000006f0
>    [ 2382.270013] Stack:
>    [ 2382.270013]  000000003c767ed8 ffffffff00000000 ffff880000000000 ffff88003c767eb8
>    [ 2382.270013]  ffff88003c767eb8 ffffffffa049a890 00007ffe76060060 ffff88003c767ef0
>    [ 2382.270013]  ffffffffa049889d ffffffffa049a500 ffff88003c767f48 ffffffff8111079c
>    [ 2382.270013] Call Trace:
>    [ 2382.270013]  [<ffffffffa049889d>] saa7134_alsa_exit+0x1d/0x780 [saa7134_alsa]
>    [ 2382.270013]  [<ffffffff8111079c>] SyS_delete_module+0x19c/0x1f0
>    [ 2382.270013]  [<ffffffff8170fc2e>] entry_SYSCALL_64_fastpath+0x12/0x71
>    [ 2382.270013] Code: 20 a0 48 c7 c6 e1 6d 20 a0 48 89 e5 41 54 53 4c 8d 65 d0 48 89 fb 48 83 ec 28 c7 45 d0 00 00 00 00 49 8d 7c 24 08 e8 7a 55 ed e0 <4c> 89 a3 40 05 00 00 48 89 df e8 eb fd ff ff 85 c0 75 1a 48 8d
>    [ 2382.270013] RIP  [<ffffffffa01fe616>] snd_card_free+0x36/0x70 [snd]
>    [ 2382.270013]  RSP <ffff88003c767ea0>
>    [ 2382.270013] CR2: 0000000000000540
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 451e9d9111a2c83d46cdd48d5eea2fa8e8d72d9a
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Thu Feb 4 17:06:13 2016 +0100
>
>    ALSA: timer: Fix leftover link at closing
>    
>    [ Upstream commit 094fd3be87b0f102589e2d5c3fa5d06b7e20496d ]
>    
>    In ALSA timer core, the active timer instance is managed in
>    active_list linked list.  Each element is added / removed dynamically
>    at timer start, stop and in timer interrupt.  The problem is that
>    snd_timer_interrupt() has a thinko and leaves the element in
>    active_list when it's the last opened element.  This eventually leads
>    to list corruption or use-after-free error.
>    
>    This hasn't been revealed because we used to delete the list forcibly
>    in snd_timer_stop() in the past.  However, the recent fix avoids the
>    double-stop behavior (in commit [f784beb75ce8: ALSA: timer: Fix link
>    corruption due to double start or stop]), and this leak hits reality.
>    
>    This patch fixes the link management in snd_timer_interrupt().  Now it
>    simply unlinks no matter which stream is.
>    
>    BugLink: http://lkml.kernel.org/r/CACT4Y+Yy2aukHP-EDp8-ziNqNNmb-NTf=jDWXMP7jB8HDa2vng@mail.gmail.com
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b35f45f2ebf224e06836ced6ccebb05ec700a6a9
>Author: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
>Date:   Wed Feb 3 17:33:48 2016 -0200
>
>    [media] tda1004x: only update the frontend properties if locked
>    
>    [ Upstream commit e8beb02343e7582980c6705816cd957cf4f74c7a ]
>    
>    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
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8552bea30320cc866c7fb5d9a687c3e6d15fb5c1
>Author: Mathias Nyman <mathias.nyman@linux.intel.com>
>Date:   Tue Jan 26 17:50:12 2016 +0200
>
>    xhci: Fix list corruption in urb dequeue at host removal
>    
>    [ Upstream commit 5c82171167adb8e4ac77b91a42cd49fb211a81a0 ]
>    
>    xhci driver frees data for all devices, both usb2 and and usb3 the
>    first time usb_remove_hcd() is called, including td_list and and xhci_ring
>    structures.
>    
>    When usb_remove_hcd() is called a second time for the second xhci bus it
>    will try to dequeue all pending urbs, and touches td_list which is already
>    freed for that endpoint.
>    
>    Cc: <stable@vger.kernel.org>
>    Reported-by: Joe Lawrence <joe.lawrence@stratus.com>
>    Tested-by: Joe Lawrence <joe.lawrence@stratus.com>
>    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4c54b01e7221db1d14ef2506ac0b81f9ff69e26f
>Author: Lu Baolu <baolu.lu@linux.intel.com>
>Date:   Tue Jan 26 17:50:08 2016 +0200
>
>    usb: xhci: apply XHCI_PME_STUCK_QUIRK to Intel Broxton-M platforms
>    
>    [ Upstream commit ccc04afb72cddbdf7c0e1c17e92886405a71b754 ]
>    
>    Intel Broxton M was verifed to require XHCI_PME_STUCK_QUIRK quirk as well.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
>    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c6fd1e6a4ffcfaf6fd6409e8fc3ada2e0cbd247d
>Author: Lu Baolu <baolu.lu@linux.intel.com>
>Date:   Tue Jan 26 17:50:07 2016 +0200
>
>    usb: xhci: set SSIC port unused only if xhci_suspend succeeds
>    
>    [ Upstream commit 92149c930cce1865d0d4aca2ab07c2b4b197b418 ]
>    
>    XHCI_SSIC_PORT_UNUSED quirk was applied to the xHCI host controllers
>    in some Intel SoC chips.  With this quirk applied, SSIC port is set
>    to "unused" prior to xhci_suspend(). This may cause problem if host
>    fails to suspend.  In this case, the port is set to unused without
>    host further entering D3, and the port will not be usable anymore.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Zhuang Jin Can <jin.can.zhuang@intel.com>
>    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
>    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1f8ad5557c9910b9853830ef202d092aa43806c9
>Author: Lu Baolu <baolu.lu@linux.intel.com>
>Date:   Tue Jan 26 17:50:06 2016 +0200
>
>    usb: xhci: add a quirk bit for ssic port unused
>    
>    [ Upstream commit 7e70cbffe236721051bbaff965e477df06dcb190 ]
>    
>    Two workarounds introduced by commit b8cb91e058cd ("xhci: Workaround
>    for PME stuck issues in Intel xhci") and commit abce329c27b3 ("xhci:
>    Workaround to get D3 working in Intel xHCI") share a single quirk bit
>    XHCI_PME_STUCK_QUIRK. These two workarounds actually are different and
>    might happen on different hardwares. Need to separate them by adding a
>    quirk bit for the later.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
>    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 69b8883209004c05eac885e53f67f37d6b0f8e11
>Author: Lu Baolu <baolu.lu@linux.intel.com>
>Date:   Tue Jan 26 17:50:05 2016 +0200
>
>    usb: xhci: handle both SSIC ports in PME stuck quirk
>    
>    [ Upstream commit fa89537783cb442263fa5a14df6c7693eaf32f11 ]
>    
>    Commit abce329c27b3 ("xhci: Workaround to get D3 working in Intel xHCI")
>    adds a workaround for a limitation of PME storm caused by SSIC port in
>    some Intel SoCs. This commit only handled one SSIC port, while there
>    are actually two SSIC ports in the chips. This patch handles both SSIC
>    ports. Without this fix, users still see PME storm.
>    
>    Cc: stable@vger.kernel.org # v4.2+
>    Signed-off-by: Zhuang Jin Can <jin.can.zhuang@intel.com>
>    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
>    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1c0232f6415b1c1c89f71fd3d98e2b497eaf988b
>Author: Mathias Nyman <mathias.nyman@linux.intel.com>
>Date:   Fri Oct 9 13:30:08 2015 +0300
>
>    xhci: create one unified function to calculate TRB TD remainder.
>    
>    [ Upstream commit c840d6ce772d47c777070ca4bbbfbf21d8d727a3 ]
>    
>    xhci versions 1.0 and later report the untransferred data remaining in a
>    TD a bit differently than older hosts.
>    
>    We used to have separate functions for these, and needed to check host
>    version before calling the right function.
>    
>    Now Mediatek host has an additional quirk on how it uses the TD Size
>    field for remaining data. To prevent yet another function for calculating
>    remainder we instead want to make one quirk friendly unified function.
>    
>    Tested-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
>    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 23159bb315f95c245ccfa9a248f8ecb786dbdc1e
>Author: Lu, Baolu <baolu.lu@linux.intel.com>
>Date:   Fri Oct 9 13:30:10 2015 +0300
>
>    usb: xhci: Makefile: move xhci-pci and xhci-plat-hcd after xhci-hcd
>    
>    [ Upstream commit 8451a34ff6c7c756e9e0f0094a3ba856c9734e5d ]
>    
>    Module xhci-pci and xhci-plat-hcd depend on xhci-hcd. Module xhci-hcd
>    should be put at a place before xhci-pci and xhci-plat-hcd. Otherwise,
>    xhci_hcd_init() might be executed after other functions in xhci-hcd if
>    they are all selected to be built in.
>    
>    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
>    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit fa91182ea7c3ea6476cf24ced5cb9878216d5f9e
>Author: Tomer Barletz <barletz@gmail.com>
>Date:   Mon Sep 21 17:46:11 2015 +0300
>
>    xhci: Move xhci_pme_quirk() behind #ifdef CONFIG_PM
>    
>    [ Upstream commit 2b7627b73e81e5d23d5ae1490fe8e690af86e053 ]
>    
>    xhci_pme_quirk() is only used when CONFIG_PM is defined.
>    Compiling a kernel without PM complains about this function
>    
>    [reworded commit message -Mathias]
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Tomer Barletz <barletz@gmail.com>
>    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5d3a10799e1199acef123e57a014b491a12044d4
>Author: Mathias Nyman <mathias.nyman@linux.intel.com>
>Date:   Tue Jul 21 17:20:25 2015 +0300
>
>    xhci: call BIOS workaround to enable runtime suspend on Intel Braswell
>    
>    [ Upstream commit c3c5819a350952439c3198aa46581f9e4c46557f ]
>    
>    Intel xhci hw that require XHCI_PME_STUCK quirk have as default disabled
>    xhci from going to D3 state in runtime suspend. Driver needs to verify
>    it can deal with the hw by calling an ACPI _DSM method to get D3 enabled.
>    
>    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit bba8f524da11a915f37835925cc602eb64383b56
>Author: Rajmohan Mani <rajmohan.mani@intel.com>
>Date:   Tue Jul 21 17:20:26 2015 +0300
>
>    xhci: Workaround to get D3 working in Intel xHCI
>    
>    [ Upstream commit abce329c27b315cfc01be1a305ee976ee13ed4cf ]
>    
>    The xHCI in Intel CherryView / Braswell Platform requires
>    a driver workaround to get xHCI D3 working. Without this
>    workaround, xHCI might not enter D3.
>    
>    Workaround is to configure SSIC PORT as "unused" before D3
>    entry and "used" after D3 exit. This is done through a
>    vendor specific register (PORT2_SSIC_CONFIG_REG2 at offset
>    0x883c), in xhci suspend / resume callbacks.
>    
>    Verified xHCI D3 works fine in CherryView / Braswell platform.
>    
>    Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com>
>    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit cd3c40afce6cd0209432e6690e60c2156a27c68d
>Author: Matthew Wilcox <willy@linux.intel.com>
>Date:   Tue Feb 2 16:57:52 2016 -0800
>
>    radix-tree: fix race in gang lookup
>    
>    [ Upstream commit 46437f9a554fbe3e110580ca08ab703b59f2f95a ]
>    
>    If the indirect_ptr bit is set on a slot, that indicates we need to redo
>    the lookup.  Introduce a new function radix_tree_iter_retry() which
>    forces the loop to retry the lookup by setting 'slot' to NULL and
>    turning the iterator back to point at the problematic entry.
>    
>    This is a pretty rare problem to hit at the moment; the lookup has to
>    race with a grow of the radix tree from a height of 0.  The consequences
>    of hitting this race are that gang lookup could return a pointer to a
>    radix_tree_node instead of a pointer to whatever the user had inserted
>    in the tree.
>    
>    Fixes: cebbd29e1c2f ("radix-tree: rewrite gang lookup using iterator")
>    Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
>    Cc: Hugh Dickins <hughd@google.com>
>    Cc: Ohad Ben-Cohen <ohad@wizery.com>
>    Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 46aef54fb8feb8158bfe0237ecec754ce5003f41
>Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>Date:   Tue Feb 2 16:57:35 2016 -0800
>
>    drivers/scsi/sg.c: mark VMA as VM_IO to prevent migration
>    
>    [ Upstream commit 461c7fa126794157484dca48e88effa4963e3af3 ]
>    
>    Reduced testcase:
>    
>        #include <fcntl.h>
>        #include <unistd.h>
>        #include <sys/mman.h>
>        #include <numaif.h>
>    
>        #define SIZE 0x2000
>    
>        int main()
>        {
>            int fd;
>            void *p;
>    
>            fd = open("/dev/sg0", O_RDWR);
>            p = mmap(NULL, SIZE, PROT_EXEC, MAP_PRIVATE | MAP_LOCKED, fd, 0);
>            mbind(p, SIZE, 0, NULL, 0, MPOL_MF_MOVE);
>            return 0;
>        }
>    
>    We shouldn't try to migrate pages in sg VMA as we don't have a way to
>    update Sg_scatter_hold::pages accordingly from mm core.
>    
>    Let's mark the VMA as VM_IO to indicate to mm core that the VMA is not
>    migratable.
>    
>    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Acked-by: Vlastimil Babka <vbabka@suse.cz>
>    Cc: Doug Gilbert <dgilbert@interlog.com>
>    Cc: David Rientjes <rientjes@google.com>
>    Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
>    Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
>    Cc: Shiraz Hashim <shashim@codeaurora.org>
>    Cc: Hugh Dickins <hughd@google.com>
>    Cc: Sasha Levin <sasha.levin@oracle.com>
>    Cc: syzkaller <syzkaller@googlegroups.com>
>    Cc: Kostya Serebryany <kcc@google.com>
>    Cc: Alexander Potapenko <glider@google.com>
>    Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 44660dacb478f79d7fbc7cec0ef342414b563b6a
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Wed Feb 3 08:32:44 2016 +0100
>
>    ALSA: seq: Fix lockdep warnings due to double mutex locks
>    
>    [ Upstream commit 7f0973e973cd74aa40747c9d38844560cd184ee8 ]
>    
>    The port subscription code uses double mutex locks for source and
>    destination ports, and this may become racy once when wrongly set up.
>    It leads to lockdep warning splat, typically triggered by fuzzer like
>    syzkaller, although the actual deadlock hasn't been seen, so far.
>    
>    This patch simplifies the handling by reducing to two single locks, so
>    that no lockdep warning will be trigger any longer.
>    
>    By splitting to two actions, a still-in-progress element shall be
>    added in one list while handling another.  For ignoring this element,
>    a new check is added in deliver_to_subscribers().
>    
>    Along with it, the code to add/remove the subscribers list element was
>    cleaned up and refactored.
>    
>    BugLink: http://lkml.kernel.org/r/CACT4Y+aKQXV7xkBW9hpQbzaDO7LrUvohxWh-UwMxXjDy-yBD=A@mail.gmail.com
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Tested-by: Dmitry Vyukov <dvyukov@google.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a2c892c31423bdef823c6f6b2d54c159be8f4e20
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Wed Feb 3 14:41:22 2016 +0100
>
>    ALSA: rawmidi: Fix race at copying & updating the position
>    
>    [ Upstream commit 81f577542af15640cbcb6ef68baa4caa610cbbfc ]
>    
>    The rawmidi read and write functions manage runtime stream status
>    such as runtime->appl_ptr and runtime->avail.  These point where to
>    copy the new data and how many bytes have been copied (or to be
>    read).  The problem is that rawmidi read/write call copy_from_user()
>    or copy_to_user(), and the runtime spinlock is temporarily unlocked
>    and relocked while copying user-space.  Since the current code
>    advances and updates the runtime status after the spin unlock/relock,
>    the copy and the update may be asynchronous, and eventually
>    runtime->avail might go to a negative value when many concurrent
>    accesses are done.  This may lead to memory corruption in the end.
>    
>    For fixing this race, in this patch, the status update code is
>    performed in the same lock before the temporary unlock.  Also, the
>    spinlock is now taken more widely in snd_rawmidi_kernel_read1() for
>    protecting more properly during the whole operation.
>    
>    BugLink: http://lkml.kernel.org/r/CACT4Y+b-dCmNf1GpgPKfDO0ih+uZCL2JV4__j-r1kdhPLSgQCQ@mail.gmail.com
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Tested-by: Dmitry Vyukov <dvyukov@google.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8bd8e5389ea62cdefa03d383daccb6474fef93a6
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Sun Jan 31 11:57:41 2016 +0100
>
>    ALSA: rawmidi: Make snd_rawmidi_transmit() race-free
>    
>    [ Upstream commit 06ab30034ed9c200a570ab13c017bde248ddb2a6 ]
>    
>    A kernel WARNING in snd_rawmidi_transmit_ack() is triggered by
>    syzkaller fuzzer:
>      WARNING: CPU: 1 PID: 20739 at sound/core/rawmidi.c:1136
>    Call Trace:
>     [<     inline     >] __dump_stack lib/dump_stack.c:15
>     [<ffffffff82999e2d>] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
>     [<ffffffff81352089>] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
>     [<ffffffff813522b9>] warn_slowpath_null+0x29/0x30 kernel/panic.c:515
>     [<ffffffff84f80bd5>] snd_rawmidi_transmit_ack+0x275/0x400 sound/core/rawmidi.c:1136
>     [<ffffffff84fdb3c1>] snd_virmidi_output_trigger+0x4b1/0x5a0 sound/core/seq/seq_virmidi.c:163
>     [<     inline     >] snd_rawmidi_output_trigger sound/core/rawmidi.c:150
>     [<ffffffff84f87ed9>] snd_rawmidi_kernel_write1+0x549/0x780 sound/core/rawmidi.c:1223
>     [<ffffffff84f89fd3>] snd_rawmidi_write+0x543/0xb30 sound/core/rawmidi.c:1273
>     [<ffffffff817b0323>] __vfs_write+0x113/0x480 fs/read_write.c:528
>     [<ffffffff817b1db7>] vfs_write+0x167/0x4a0 fs/read_write.c:577
>     [<     inline     >] SYSC_write fs/read_write.c:624
>     [<ffffffff817b50a1>] SyS_write+0x111/0x220 fs/read_write.c:616
>     [<ffffffff86336c36>] entry_SYSCALL_64_fastpath+0x16/0x7a arch/x86/entry/entry_64.S:185
>    
>    Also a similar warning is found but in another path:
>    Call Trace:
>     [<     inline     >] __dump_stack lib/dump_stack.c:15
>     [<ffffffff82be2c0d>] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
>     [<ffffffff81355139>] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
>     [<ffffffff81355369>] warn_slowpath_null+0x29/0x30 kernel/panic.c:515
>     [<ffffffff8527e69a>] rawmidi_transmit_ack+0x24a/0x3b0 sound/core/rawmidi.c:1133
>     [<ffffffff8527e851>] snd_rawmidi_transmit_ack+0x51/0x80 sound/core/rawmidi.c:1163
>     [<ffffffff852d9046>] snd_virmidi_output_trigger+0x2b6/0x570 sound/core/seq/seq_virmidi.c:185
>     [<     inline     >] snd_rawmidi_output_trigger sound/core/rawmidi.c:150
>     [<ffffffff85285a0b>] snd_rawmidi_kernel_write1+0x4bb/0x760 sound/core/rawmidi.c:1252
>     [<ffffffff85287b73>] snd_rawmidi_write+0x543/0xb30 sound/core/rawmidi.c:1302
>     [<ffffffff817ba5f3>] __vfs_write+0x113/0x480 fs/read_write.c:528
>     [<ffffffff817bc087>] vfs_write+0x167/0x4a0 fs/read_write.c:577
>     [<     inline     >] SYSC_write fs/read_write.c:624
>     [<ffffffff817bf371>] SyS_write+0x111/0x220 fs/read_write.c:616
>     [<ffffffff86660276>] entry_SYSCALL_64_fastpath+0x16/0x7a arch/x86/entry/entry_64.S:185
>    
>    In the former case, the reason is that virmidi has an open code
>    calling snd_rawmidi_transmit_ack() with the value calculated outside
>    the spinlock.   We may use snd_rawmidi_transmit() in a loop just for
>    consuming the input data, but even there, there is a race between
>    snd_rawmidi_transmit_peek() and snd_rawmidi_tranmit_ack().
>    
>    Similarly in the latter case, it calls snd_rawmidi_transmit_peek() and
>    snd_rawmidi_tranmit_ack() separately without protection, so they are
>    racy as well.
>    
>    The patch tries to address these issues by the following ways:
>    - Introduce the unlocked versions of snd_rawmidi_transmit_peek() and
>      snd_rawmidi_transmit_ack() to be called inside the explicit lock.
>    - Rewrite snd_rawmidi_transmit() to be race-free (the former case).
>    - Make the split calls (the latter case) protected in the rawmidi spin
>      lock.
>    
>    BugLink: http://lkml.kernel.org/r/CACT4Y+YPq1+cYLkadwjWa5XjzF1_Vki1eHnVn-Lm0hzhSpu5PA@mail.gmail.com
>    BugLink: http://lkml.kernel.org/r/CACT4Y+acG4iyphdOZx47Nyq_VHGbpJQK-6xNpiqUjaZYqsXOGw@mail.gmail.com
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Tested-by: Dmitry Vyukov <dvyukov@google.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d84572ebdb7320ab597f933d8f65df9a9c7f9537
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Wed Feb 3 12:32:51 2016 +0100
>
>    ALSA: hda - Add fixup for Mac Mini 7,1 model
>    
>    [ Upstream commit 2154cc0e2d4ae15132d005d17e473327c70c9a06 ]
>    
>    Mac Mini 7,1 model with CS4208 codec reports the headphone jack
>    detection wrongly in an inverted way.  Moreover, the advertised pins
>    for the audio input and SPDIF output have actually no jack detection.
>    
>    This patch addresses these issues.  The inv_jack_detect flag is set
>    for fixing the headphone jack detection, and the pin configs for audio
>    input and SPDIF output are marked as non-detectable.
>    
>    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105161
>    Report-and-tested-by: moosotc@gmail.com
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2b374ca06b3bba78733da7968b82330fad7b60ce
>Author: Oded Gabbay <oded.gabbay@gmail.com>
>Date:   Sat Jan 30 07:59:33 2016 +0200
>
>    drm/radeon: mask out WC from BO on unsupported arches
>    
>    [ Upstream commit c5244987394648913ae1a03879c58058a2fc2cee ]
>    
>    Reviewed-by: Christian KÃ¶nig <christian.koenig@amd.com>
>    Reviewed-by: Michel DÃ¤nzer <michel.daenzer@amd.com>
>    Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5e92a4058e7035fde9a623b5ca36d862e7677ea6
>Author: Michel DÃ¤nzer <michel.daenzer@amd.com>
>Date:   Thu Nov 5 17:25:27 2015 +0900
>
>    drm/radeon: Always disable RADEON_GEM_GTT_UC along with RADEON_GEM_GTT_WC
>    
>    [ Upstream commit a28bbd5824d4a2af98de45b300ab8d8fb39739fc ]
>    
>    Write-combining is a CPU feature. From the GPU POV, these both simply
>    mean no GPU<->CPU cache coherency.
>    
>    Reviewed-by: Christian KÃ¶nig <christian.koenig@amd.com>
>    Signed-off-by: Michel DÃ¤nzer <michel.daenzer@amd.com>
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2322974c5d55e8be4be4b7cbf8cf996daf72b0bd
>Author: Dave Airlie <airlied@redhat.com>
>Date:   Sat Jan 30 07:59:32 2016 +0200
>
>    drm: add helper to check for wc memory support
>    
>    [ Upstream commit 4b0e4e4af6c6dc8354dcb72182d52c1bc55f12fc ]
>    
>    Reviewed-by: Christian KÃ¶nig <christian.koenig@amd.com>
>    Reviewed-by: Michel DÃ¤nzer <michel.daenzer@amd.com>
>    Signed-off-by: Dave Airlie <airlied@redhat.com>
>    Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b99c635faf56fa3cbd1cf61632418b06543dc145
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Sat Jan 30 23:09:08 2016 +0100
>
>    ALSA: timer: Fix link corruption due to double start or stop
>    
>    [ Upstream commit f784beb75ce82f4136f8a0960d3ee872f7109e09 ]
>    
>    Although ALSA timer code got hardening for races, it still causes
>    use-after-free error.  This is however rather a corrupted linked list,
>    not actually the concurrent accesses.  Namely, when timer start is
>    triggered twice, list_add_tail() is called twice, too.  This ends
>    up with the link corruption and triggers KASAN error.
>    
>    The simplest fix would be replacing list_add_tail() with
>    list_move_tail(), but fundamentally it's the problem that we don't
>    check the double start/stop correctly.  So, the right fix here is to
>    add the proper checks to snd_timer_start() and snd_timer_stop() (and
>    their variants).
>    
>    BugLink: http://lkml.kernel.org/r/CACT4Y+ZyPRoMQjmawbvmCEDrkBD2BQuH7R09=eOkf5ESK8kJAw@mail.gmail.com
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit aef523ec3812f822fdd256f64c0d941a0588647f
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Thu Jan 14 17:01:46 2016 +0100
>
>    ALSA: timer: Code cleanup
>    
>    [ Upstream commit c3b1681375dc6e71d89a3ae00cc3ce9e775a8917 ]
>    
>    This is a minor code cleanup without any functional changes:
>    - Kill keep_flag argument from _snd_timer_stop(), as all callers pass
>      only it false.
>    - Remove redundant NULL check in _snd_timer_stop().
>    
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b55a0342e88343fbca10e8a1ac5f6aa1c001f40f
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Sat Jan 30 23:30:25 2016 +0100
>
>    ALSA: seq: Fix yet another races among ALSA timer accesses
>    
>    [ Upstream commit 2cdc7b636d55cbcf42e1e6c8accd85e62d3e9ae8 ]
>    
>    ALSA sequencer may open/close and control ALSA timer instance
>    dynamically either via sequencer events or direct ioctls.  These are
>    done mostly asynchronously, and it may call still some timer action
>    like snd_timer_start() while another is calling snd_timer_close().
>    Since the instance gets removed by snd_timer_close(), it may lead to
>    a use-after-free.
>    
>    This patch tries to address such a race by protecting each
>    snd_timer_*() call via the existing spinlock and also by avoiding the
>    access to timer during close call.
>    
>    BugLink: http://lkml.kernel.org/r/CACT4Y+Z6RzW5MBr-HUdV-8zwg71WQfKTdPpYGvOeS7v4cyurNQ@mail.gmail.com
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 666f365e85209f799819793d475cd7cde98a2be2
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Sun Jan 31 10:32:37 2016 +0100
>
>    ALSA: pcm: Fix potential deadlock in OSS emulation
>    
>    [ Upstream commit b248371628aad599a48540962f6b85a21a8a0c3f ]
>    
>    There are potential deadlocks in PCM OSS emulation code while
>    accessing read/write and mmap concurrently.  This comes from the
>    infamous mmap_sem usage in copy_from/to_user().  Namely,
>    
>       snd_pcm_oss_write() ->
>         &runtime->oss.params_lock ->
>            copy_to_user() ->
>              &mm->mmap_sem
>      mmap() ->
>        &mm->mmap_sem ->
>          snd_pcm_oss_mmap() ->
>            &runtime->oss.params_lock
>    
>    Since we can't avoid taking params_lock from mmap code path, use
>    trylock variant and aborts with -EAGAIN as a workaround of this AB/BA
>    deadlock.
>    
>    BugLink: http://lkml.kernel.org/r/CACT4Y+bVrBKDG0G2_AcUgUQa+X91VKTeS4v+wN7BSHwHtqn3kQ@mail.gmail.com
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 216b6d4f24b88ab70c58e0574e30b8da1b2b053b
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Mon Feb 1 12:04:55 2016 +0100
>
>    ALSA: rawmidi: Remove kernel WARNING for NULL user-space buffer check
>    
>    [ Upstream commit cc85f7a634cfaf9f0713c6aa06d08817424db37a ]
>    
>    NULL user-space buffer can be passed even in a normal path, thus it's
>    not good to spew a kernel warning with stack trace at each time.
>    Just drop snd_BUG_ON() macro usage there.
>    
>    BugLink: http://lkml.kernel.org/r/CACT4Y+YfVJ3L+q0i-4vyQVyyPD7V=OMX0PWPi29x9Bo3QaBLdw@mail.gmail.com
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 81bce29eec26617db18ff21543c7a091b5c10c92
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Mon Feb 1 12:06:42 2016 +0100
>
>    ALSA: seq: Fix race at closing in virmidi driver
>    
>    [ Upstream commit 2d1b5c08366acd46c35a2e9aba5d650cb5bf5c19 ]
>    
>    The virmidi driver has an open race at closing its assigned rawmidi
>    device, and this may lead to use-after-free in
>    snd_seq_deliver_single_event().
>    
>    Plug the hole by properly protecting the linked list deletion and
>    calling in the right order in snd_virmidi_input_close().
>    
>    BugLink: http://lkml.kernel.org/r/CACT4Y+Zd66+w12fNN85-425cVQT=K23kWbhnCEcMB8s3us-Frw@mail.gmail.com
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Tested-by: Dmitry Vyukov <dvyukov@google.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit bd92b10c95b37a4d6c043ad76d51d13dee45c477
>Author: Wang, Rui Y <rui.y.wang@intel.com>
>Date:   Wed Jan 27 17:08:37 2016 +0800
>
>    crypto: algif_hash - wait for crypto_ahash_init() to complete
>    
>    [ Upstream commit fe09786178f9df713a4b2dd6b93c0a722346bf5e ]
>    
>    hash_sendmsg/sendpage() need to wait for the completion
>    of crypto_ahash_init() otherwise it can cause panic.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Rui Wang <rui.y.wang@intel.com>
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit caec5c97583b7ea44c57be91a19d28b0ac447fe4
>Author: Lev Lybin <lev.lybin@gmail.com>
>Date:   Fri Jan 29 22:55:11 2016 +0700
>
>    ALSA: usb-audio: Add quirk for Microsoft LifeCam HD-6000
>    
>    [ Upstream commit 1b3c993a699bed282e47c3f7c49d539c331dae04 ]
>    
>    Microsoft LifeCam HD-6000 (045e:076f) requires the similar quirk for
>    avoiding the stall due to the invalid sample rate reads.
>    
>    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=111491
>    Signed-off-by: Lev Lybin <lev.lybin@gmail.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 29eccdaa46023d0c57c691ce047f9f424114c2b6
>Author: Jurgen Kramer <gtmkramer@xs4all.nl>
>Date:   Fri Jan 29 14:59:25 2016 +0100
>
>    ALSA: usb-audio: Add native DSD support for PS Audio NuWave DAC
>    
>    [ Upstream commit ad678b4ccd41aa51cf5f142c0e8cffe9d61fc2bf ]
>    
>    This patch adds native DSD support for the PS Audio NuWave DAC.
>    
>    Signed-off-by: Jurgen Kramer <gtmkramer@xs4all.nl>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a16d95b6a648c5d4761ec5988923421b4c0ecabb
>Author: Jurgen Kramer <gtmkramer@xs4all.nl>
>Date:   Fri Jan 29 14:49:55 2016 +0100
>
>    ALSA: usb-audio: Fix OPPO HA-1 vendor ID
>    
>    [ Upstream commit 5327d6ba975042fd3da50ac6e94d1e9551ebeaec ]
>    
>    In my patch adding native DSD support for the Oppo HA-1, the wrong vendor ID got
>    through. This patch fixes the vendor ID and aligns the comment.
>    
>    Fixes: a4eae3a506ea ('ALSA: usb: Add native DSD support for Oppo HA-1')
>    Signed-off-by: Jurgen Kramer <gtmkramer@xs4all.nl>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 43293f825820f7228871ff16b6ff34260113b62e
>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
>    
>    [ Upstream commit 5efd407674068dede403551bea3b0b134c32513a ]
>    
>    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
>    
>    Cc: stable@vger.kernel.org
>    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: Sasha Levin <sasha.levin@oracle.com>
>
>commit 73f876ae98498f5a929053e4d402062a5516aa73
>Author: Herbert Xu <herbert@gondor.apana.org.au>
>Date:   Wed Jan 27 00:16:37 2016 +0800
>
>    crypto: shash - Fix has_key setting
>    
>    [ Upstream commit 00420a65fa2beb3206090ead86942484df2275f3 ]
>    
>    The has_key logic is wrong for shash algorithms as they always
>    have a setkey function.  So we should instead be testing against
>    shash_no_setkey.
>    
>    Fixes: a5596d633278 ("crypto: hash - Add crypto_ahash_has_setkey")
>    Cc: stable@vger.kernel.org
>    Reported-by: Stephan Mueller <smueller@chronox.de>
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Tested-by: Stephan Mueller <smueller@chronox.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 505a9f25a6c33070eb51ea50aabf168b8aafa6d1
>Author: Nicolas Ferre <nicolas.ferre@atmel.com>
>Date:   Wed Jan 27 11:03:02 2016 +0100
>
>    ARM: dts: at91: sama5d4 xplained: fix phy0 IRQ type
>    
>    [ Upstream commit e873cc022ce5e2c04bbc53b5874494b657e29d3f ]
>    
>    For phy0 KSZ8081, the type of GPIO IRQ should be "level low" instead of
>    "edge falling".
>    
>    Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>    Fixes: 38153a017896 ("ARM: at91/dt: sama5d4: add dts for sama5d4 xplained board")
>    Cc: <stable@vger.kernel.org> # 4.1+
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 06fa2c9ac1aa1dfe3d7e55644c23e96214067040
>Author: Wenyou Yang <wenyou.yang@atmel.com>
>Date:   Wed Jan 27 13:16:24 2016 +0800
>
>    ARM: dts: at91: sama5d4ek: add phy address and IRQ for macb0
>    
>    [ Upstream commit aae6b18f5c95b9dc78de66d1e27e8afeee2763b7 ]
>    
>    On SAMA5D4EK board, the Ethernet doesn't work after resuming from the suspend
>    state.
>    
>    Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
>    [nicolas.ferre@atmel.com: adapt to newer kernel]
>    Fixes: 38153a017896 ("ARM: at91/dt: sama5d4: add dts for sama5d4 xplained board")
>    Cc: <stable@vger.kernel.org> # 4.1+
>    Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d54ed290a5011beeeeb38082aa4323af4c60e7be
>Author: Mohamed Jamsheeth Hajanajubudeen <mohamedjamsheeth.hajanajubudeen@atmel.com>
>Date:   Fri Dec 11 17:06:26 2015 +0530
>
>    ARM: dts: at91: sama5d4: fix instance id of DBGU
>    
>    [ Upstream commit 929e883f2bfdf68d4bd3aec43912e956417005c7 ]
>    
>    Change instance id of DBGU to 45.
>    
>    Signed-off-by: Mohamed Jamsheeth Hajanajubudeen <mohamedjamsheeth.hajanajubudeen@atmel.com>
>    Fixes: 7c661394c56c ("ARM: at91: dt: add device tree file for SAMA5D4 SoC")
>    Cc: stable@vger.kernel.org   # 3.18+
>    Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5abd25f01c03b52d8aa39813656782917aa10d9b
>Author: Johannes Berg <johannes.berg@intel.com>
>Date:   Tue Jan 26 11:29:03 2016 +0100
>
>    rfkill: fix rfkill_fop_read wait_event usage
>    
>    [ Upstream commit 6736fde9672ff6717ac576e9bba2fd5f3dfec822 ]
>    
>    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.
>    
>    Cc: stable@vger.kernel.org
>    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: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8448609ec0b8b36759338905a7a5f620555623d8
>Author: Sachin Kulkarni <Sachin.Kulkarni@imgtec.com>
>Date:   Tue Jan 12 14:30:19 2016 +0530
>
>    mac80211: Requeue work after scan complete for all VIF types.
>    
>    [ Upstream commit 4fa11ec726a32ea6dd768dbb2e2af3453a98ec0a ]
>    
>    During a sw scan ieee80211_iface_work ignores work items for all vifs.
>    However after the scan complete work is requeued only for STA, ADHOC
>    and MESH iftypes.
>    
>    This occasionally results in event processing getting delayed/not
>    processed for iftype AP when it coexists with a STA. This can result
>    in data halt and eventually disconnection on the AP interface.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sachin Kulkarni <Sachin.Kulkarni@imgtec.com>
>    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 22186aa8b53c158418f8c1f70b1a556a78ed1012
>Author: Tony Lindgren <tony@atomide.com>
>Date:   Thu Jan 14 12:20:48 2016 -0800
>
>    ARM: OMAP2+: Fix ppa_zero_params and ppa_por_params for rodata
>    
>    [ Upstream commit 4da597d16602d14405b71a18d45e1c59f28f0fd2 ]
>    
>    We don't want to write to .text so let's move ppa_zero_params and
>    ppa_por_params to .data and access them via pointers.
>    
>    Note that I have not been able to test as we I don't have a HS
>    omap4 to test with. The code has been changed in similar way as
>    for omap3 though.
>    
>    Cc: Kees Cook <keescook@chromium.org>
>    Cc: Laura Abbott <labbott@redhat.com>
>    Cc: Nishanth Menon <nm@ti.com>
>    Cc: Richard Woodruff <r-woodruff2@ti.com>
>    Cc: Russell King <linux@arm.linux.org.uk>
>    Cc: Tero Kristo <t-kristo@ti.com>
>    Acked-by: Nicolas Pitre <nico@linaro.org>
>    Cc: stable@vger.kernel.org # v4.0+
>    Fixes: 1e6b48116a95 ("ARM: mm: allow non-text sections to be
>    non-executable")
>    Signed-off-by: Tony Lindgren <tony@atomide.com>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b6204db55d575691f837a64fbc31eb9a4bcb3c52
>Author: Tony Lindgren <tony@atomide.com>
>Date:   Thu Jan 14 12:20:47 2016 -0800
>
>    ARM: OMAP2+: Fix save_secure_ram_context for rodata
>    
>    [ Upstream commit a5311d4d13df80bd71a9e47f9ecaf327f478fab1 ]
>    
>    We don't want to write to .text and we can move save_secure_ram_context
>    into .data as it all gets copied into SRAM anyways.
>    
>    Cc: Kees Cook <keescook@chromium.org>
>    Cc: Laura Abbott <labbott@redhat.com>
>    Cc: Nishanth Menon <nm@ti.com>
>    Cc: Richard Woodruff <r-woodruff2@ti.com>
>    Cc: Russell King <linux@arm.linux.org.uk>
>    Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>    Cc: Tero Kristo <t-kristo@ti.com>
>    Acked-by: Nicolas Pitre <nico@linaro.org>
>    Cc: stable@vger.kernel.org # v4.0+
>    Fixes: 1e6b48116a95 ("ARM: mm: allow non-text sections to be
>    non-executable")
>    Signed-off-by: Tony Lindgren <tony@atomide.com>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2c0fae21283fe4d8ca6475e40f56603f7426613d
>Author: Tony Lindgren <tony@atomide.com>
>Date:   Thu Jan 14 12:20:47 2016 -0800
>
>    ARM: OMAP2+: Fix l2dis_3630 for rodata
>    
>    [ Upstream commit eeaf9646aca89d097861caa24d9818434e48810e ]
>    
>    We don't want to write to .text section. Let's move l2dis_3630
>    to .data and access it via a pointer.
>    
>    For calculating the offset, let's optimize out the add and do it
>    in ldr/str as suggested by Nicolas Pitre <nicolas.pitre@linaro.org>.
>    
>    Cc: Kees Cook <keescook@chromium.org>
>    Cc: Laura Abbott <labbott@redhat.com>
>    Cc: Nishanth Menon <nm@ti.com>
>    Cc: Richard Woodruff <r-woodruff2@ti.com>
>    Cc: Russell King <linux@arm.linux.org.uk>
>    Cc: Tero Kristo <t-kristo@ti.com>
>    Cc: stable@vger.kernel.org # v4.0+
>    Acked-by: Nicolas Pitre <nico@linaro.org>
>    Cc: stable@vger.kernel.org # v4.0+
>    Fixes: 1e6b48116a95 ("ARM: mm: allow non-text sections to be
>    non-executable")
>    Signed-off-by: Tony Lindgren <tony@atomide.com>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 01c7c52c66428c45484b59dac950b613e38cc7dc
>Author: Tony Lindgren <tony@atomide.com>
>Date:   Thu Jan 14 12:20:47 2016 -0800
>
>    ARM: OMAP2+: Fix wait_dll_lock_timed for rodata
>    
>    [ Upstream commit d9db59103305eb5ec2a86369f32063e9921b6ac5 ]
>    
>    We don't want to be writing to .text so it can be set rodata.
>    Fix error "Unable to handle kernel paging request at virtual address
>    c012396c" in wait_dll_lock_timed if CONFIG_DEBUG_RODATA is selected.
>    
>    As these counters are for debugging only and unused, we can just
>    remove them.
>    
>    Cc: Kees Cook <keescook@chromium.org>
>    Cc: Laura Abbott <labbott@redhat.com>
>    Cc: Nishanth Menon <nm@ti.com>
>    Cc: Richard Woodruff <r-woodruff2@ti.com>
>    Cc: Russell King <linux@arm.linux.org.uk>
>    Cc: Tero Kristo <t-kristo@ti.com>
>    Acked-by: Nicolas Pitre <nico@linaro.org>
>    Cc: stable@vger.kernel.org # v4.0+
>    Fixes: 1e6b48116a95 ("ARM: mm: allow non-text sections to be
>    non-executable")
>    Signed-off-by: Tony Lindgren <tony@atomide.com>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9f4bab04f3788cd66b203c501fe30d093fe4d8d7
>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()
>    
>    [ Upstream commit 2c3033a0664dfae91e1dee7fabac10f24354b958 ]
>    
>    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>
>    Cc: All applicable <stable@vger.kernel.org>
>    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4470ba0e8a7f353cf3868eca475272d49605f823
>Author: Huacai Chen <chenhc@lemote.com>
>Date:   Thu Jan 21 21:09:52 2016 +0800
>
>    MIPS: Fix some missing CONFIG_CPU_MIPSR6 #ifdefs
>    
>    [ Upstream commit 4f33f6c522948fffc345261896042b58dea23754 ]
>    
>    Commit be0c37c985eddc4 (MIPS: Rearrange PTE bits into fixed positions.)
>    defines fixed PTE bits for MIPS R2. Then, commit d7b631419b3d230a4d383
>    (MIPS: pgtable-bits: Fix XPA damage to R6 definitions.) adds the MIPS
>    R6 definitions in the same way as MIPS R2. But some R6 #ifdefs in the
>    later commit are missing, so in this patch I fix that.
>    
>    Signed-off-by: Huacai Chen <chenhc@lemote.com>
>    Cc: Aurelien Jarno <aurelien@aurel32.net>
>    Cc: Steven J. Hill <Steven.Hill@imgtec.com>
>    Cc: Fuxin Zhang <zhangfx@lemote.com>
>    Cc: Zhangjin Wu <wuzhangjin@gmail.com>
>    Cc: linux-mips@linux-mips.org
>    Cc: stable@vger.kernel.org
>    Patchwork: https://patchwork.linux-mips.org/patch/12164/
>    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 156e0fd0ecf2f78b732584253a2f21c56a7e79ba
>Author: Mika Westerberg <mika.westerberg@linux.intel.com>
>Date:   Fri Jan 29 16:49:47 2016 +0200
>
>    serial: 8250_pci: Add Intel Broadwell ports
>    
>    [ Upstream commit 6c55d9b98335f7f6bd5f061866ff1633401f3a44 ]
>    
>    Some recent (early 2015) macbooks have Intel Broadwell where LPSS UARTs are
>    PCI enumerated instead of ACPI. The LPSS UART block is pretty much same as
>    used on Intel Baytrail so we can reuse the existing Baytrail setup code.
>    
>    Add both Broadwell LPSS UART ports to the list of supported devices.
>    
>    Signed-off-by: Leif Liddy <leif.liddy@gmail.com>
>    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
>    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3704a44fc2706841b7af21235e928e0be0bb251d
>Author: Matt Fleming <matt@codeblueprint.co.uk>
>Date:   Fri Jan 29 11:36:10 2016 +0000
>
>    x86/mm/pat: Avoid truncation when converting cpa->numpages to address
>    
>    [ Upstream commit 742563777e8da62197d6cb4b99f4027f59454735 ]
>    
>    There are a couple of nasty truncation bugs lurking in the pageattr
>    code that can be triggered when mapping EFI regions, e.g. when we pass
>    a cpa->pgd pointer. Because cpa->numpages is a 32-bit value, shifting
>    left by PAGE_SHIFT will truncate the resultant address to 32-bits.
>    
>    Viorel-CÄtÄlin managed to trigger this bug on his Dell machine that
>    provides a ~5GB EFI region which requires 1236992 pages to be mapped.
>    When calling populate_pud() the end of the region gets calculated
>    incorrectly in the following buggy expression,
>    
>      end = start + (cpa->numpages << PAGE_SHIFT);
>    
>    And only 188416 pages are mapped. Next, populate_pud() gets invoked
>    for a second time because of the loop in __change_page_attr_set_clr(),
>    only this time no pages get mapped because shifting the remaining
>    number of pages (1048576) by PAGE_SHIFT is zero. At which point the
>    loop in __change_page_attr_set_clr() spins forever because we fail to
>    map progress.
>    
>    Hitting this bug depends very much on the virtual address we pick to
>    map the large region at and how many pages we map on the initial run
>    through the loop. This explains why this issue was only recently hit
>    with the introduction of commit
>    
>      a5caa209ba9c ("x86/efi: Fix boot crash by mapping EFI memmap
>       entries bottom-up at runtime, instead of top-down")
>    
>    It's interesting to note that safe uses of cpa->numpages do exist in
>    the pageattr code. If instead of shifting ->numpages we multiply by
>    PAGE_SIZE, no truncation occurs because PAGE_SIZE is a UL value, and
>    so the result is unsigned long.
>    
>    To avoid surprises when users try to convert very large cpa->numpages
>    values to addresses, change the data type from 'int' to 'unsigned
>    long', thereby making it suitable for shifting by PAGE_SHIFT without
>    any type casting.
>    
>    The alternative would be to make liberal use of casting, but that is
>    far more likely to cause problems in the future when someone adds more
>    code and fails to cast properly; this bug was difficult enough to
>    track down in the first place.
>    
>    Reported-and-tested-by: Viorel-CÄtÄlin RÄpiÈeanu <rapiteanu.catalin@gmail.com>
>    Acked-by: Borislav Petkov <bp@alien8.de>
>    Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
>    Link: https://bugzilla.kernel.org/show_bug.cgi?id=110131
>    Link: http://lkml.kernel.org/r/1454067370-10374-1-git-send-email-matt@codeblueprint.co.uk
>    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b143adc3f446be7dbb5a0d4c63089078d7718f06
>Author: Samuel Thibault <samuel.thibault@ens-lyon.org>
>Date:   Fri Jan 15 00:47:41 2016 +0100
>
>    Staging: speakup: Fix getting port information
>    
>    [ Upstream commit 327b882d3bcc1fba82dbd39b5cf5a838c81218e2 ]
>    
>    Commit f79b0d9c223c ("staging: speakup: Fixed warning <linux/serial.h>
>    instead of <asm/serial.h>") broke the port information in the speakup
>    driver: SERIAL_PORT_DFNS only gets defined if asm/serial.h is included,
>    and no other header includes asm/serial.h.
>    
>    We here make sure serialio.c does get the arch-specific definition of
>    SERIAL_PORT_DFNS from asm/serial.h, if any.
>    
>    Along the way, this makes sure that we do have information for the
>    requested serial port number (index)
>    
>    Fixes: f79b0d9c223c ("staging: speakup: Fixed warning <linux/serial.h> instead of <asm/serial.h>")
>    Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
>    Cc: stable <stable@vger.kernel.org> # 3.18
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c4bbd2785e0ed7ed3e8c16776194ea9181fc3454
>Author: Rob Clark <robdclark@gmail.com>
>Date:   Wed Oct 15 15:00:47 2014 -0400
>
>    drm/vmwgfx: respect 'nomodeset'
>    
>    [ Upstream commit 96c5d076f0a5e2023ecdb44d8261f87641ee71e0 ]
>    
>    Signed-off-by: Rob Clark <robdclark@gmail.com>
>    Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>.
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Dave Airlie <airlied@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f6b4419806e546fb02f91bed03572362e2623879
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Thu Jan 28 07:54:16 2016 +0100
>
>    ALSA: dummy: Disable switching timer backend via sysfs
>    
>    [ Upstream commit 7ee96216c31aabe1eb42fb91ff50dae9fcd014b2 ]
>    
>    ALSA dummy driver can switch the timer backend between system timer
>    and hrtimer via its hrtimer module option.  This can be also switched
>    dynamically via sysfs, but it may lead to a memory corruption when
>    switching is done while a PCM stream is running; the stream instance
>    for the newly switched timer method tries to access the memory that
>    was allocated by another timer method although the sizes differ.
>    
>    As the simplest fix, this patch just disables the switch via sysfs by
>    dropping the writable bit.
>    
>    BugLink: http://lkml.kernel.org/r/CACT4Y+ZGEeEBntHW5WHn2GoeE0G_kRrCmUh6=dWyy-wfzvuJLg@mail.gmail.com
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2fbdb6c658f4a10c649fd57c42a5199d2a8032d8
>Author: Slava Grigorev <slava.grigorev@amd.com>
>Date:   Tue Jan 26 17:35:57 2016 -0500
>
>    drm/radeon: fix DP audio support for APU with DCE4.1 display engine
>    
>    [ Upstream commit fe6fc1f132b4300c1f6defd43a5d673eb60a820d ]
>    
>    Properly setup the DFS divider for DP audio for DCE4.1.
>    
>    Signed-off-by: Slava Grigorev <slava.grigorev@amd.com>
>    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>    Reviewed-by: Christian KÃ¶nig <christian.koenig@amd.com>
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2652823a09685084d3c1dc0abe17a2fa6596d19a
>Author: Slava Grigorev <slava.grigorev@amd.com>
>Date:   Tue Jan 26 16:56:25 2016 -0500
>
>    drm/radeon: Add a common function for DFS handling
>    
>    [ Upstream commit a64c9dab1c4d05c87ec8a1cb9b48915816462143 ]
>    
>    Move encoding of DFS (digital frequency synthesizer) divider into a
>    separate function and improve calculation precision.
>    
>    Signed-off-by: Slava Grigorev <slava.grigorev@amd.com>
>    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>    Reviewed-by: Christian KÃ¶nig <christian.koenig@amd.com>
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7fb7275ff91c477cc1a8fbbd9667343f8261998e
>Author: Slava Grigorev <slava.grigorev@amd.com>
>Date:   Tue Jan 26 16:45:10 2016 -0500
>
>    drm/radeon: cleaned up VCO output settings for DP audio
>    
>    [ Upstream commit c9a392eac18409f51a071520cf508c0b4ad990e2 ]
>    
>    This is preparation for the fixes in the following patches.
>    
>    Signed-off-by: Slava Grigorev <slava.grigorev@amd.com>
>    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>    Reviewed-by: Christian KÃ¶nig <christian.koenig@amd.com>
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9646e177106ce8154bf87cde52188f015250e8ed
>Author: Alex Deucher <alexander.deucher@amd.com>
>Date:   Fri Jul 24 00:42:02 2015 -0400
>
>    drm/radeon: rework audio modeset to handle non-audio hdmi features
>    
>    [ Upstream commit 7726e72b3d6879ee5fc743a230eb6f5afa12844b ]
>    
>    Need to setup the deep color and avi packets regardless of
>    audio setup.
>    
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 988590966531b9ab4d7c6101f02a6f065c5df7a5
>Author: Jann Horn <jann@thejh.net>
>Date:   Sat Dec 26 06:00:48 2015 +0100
>
>    seccomp: always propagate NO_NEW_PRIVS on tsync
>    
>    [ Upstream commit 103502a35cfce0710909da874f092cb44823ca03 ]
>    
>    Before this patch, a process with some permissive seccomp filter
>    that was applied by root without NO_NEW_PRIVS was able to add
>    more filters to itself without setting NO_NEW_PRIVS by setting
>    the new filter from a throwaway thread with NO_NEW_PRIVS.
>    
>    Signed-off-by: Jann Horn <jann@thejh.net>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Kees Cook <keescook@chromium.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit aa54b6de2b2ffbd6bb3086dbebd8fea61701202b
>Author: Milo Kim <milo.kim@ti.com>
>Date:   Wed Jan 13 16:19:50 2016 +0900
>
>    irqchip/atmel-aic: Fix wrong bit operation for IRQ priority
>    
>    [ Upstream commit 49f34134aea74f19ca016f055d25ee55ec359dee ]
>    
>    Atmel AIC has common structure for SMR (Source Mode Register).
>    
>      bit[6:5] Interrupt source type
>      bit[2:0] Priority level
>      Other bits are unused.
>    
>    To update new priority value, bit[2:0] should be cleared first and then
>    new priority level can be written. However, aic_common_set_priority()
>    helper clears source type bits instead of priority bits.
>    This patch fixes wrong mask bit operation.
>    
>    Fixes: b1479ebb7720 "irqchip: atmel-aic: Add atmel AIC/AIC5 drivers"
>    Signed-off-by: Milo Kim <milo.kim@ti.com>
>    Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
>    Cc: Jason Cooper <jason@lakedaemon.net>
>    Cc: Marc Zyngier <marc.zyngier@arm.com>
>    Cc: Ludovic Desroches <ludovic.desroches@atmel.com>
>    Cc: Nicholas Ferre <nicolas.ferre@atmel.com>
>    Cc: stable@vger.kernel.org #v3.17+
>    Link: http://lkml.kernel.org/r/1452669592-3401-2-git-send-email-milo.kim@ti.com
>    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d515d710883d98ee77819fe9b4848bfdcfd0a324
>Author: Peter Hurley <peter@hurleysoftware.com>
>Date:   Sun Jan 10 22:40:58 2016 -0800
>
>    staging/speakup: Use tty_ldisc_ref() for paste kworker
>    
>    [ Upstream commit f4f9edcf9b5289ed96113e79fa65a7bf27ecb096 ]
>    
>    As the function documentation for tty_ldisc_ref_wait() notes, it is
>    only callable from a tty file_operations routine; otherwise there
>    is no guarantee the ref won't be NULL.
>    
>    The key difference with the VT's paste_selection() is that is an ioctl,
>    where __speakup_paste_selection() is completely async kworker, kicked
>    off from interrupt context.
>    
>    Fixes: 28a821c30688 ("Staging: speakup: Update __speakup_paste_selection()
>           tty (ab)usage to match vt")
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 28b824966ab269de94e0ca640b7c61aedc6a83de
>Author: Peter Hurley <peter@hurleysoftware.com>
>Date:   Sun Jan 10 22:40:56 2016 -0800
>
>    n_tty: Fix unsafe reference to "other" ldisc
>    
>    [ Upstream commit 6d27a63caad3f13e96cf065d2d96828c2006be6b ]
>    
>    Although n_tty_check_unthrottle() has a valid ldisc reference (since
>    the tty core gets the ldisc ref in tty_read() before calling the line
>    discipline read() method), it does not have a valid ldisc reference to
>    the "other" pty of a pty pair. Since getting an ldisc reference for
>    tty->link essentially open-codes tty_wakeup(), just replace with the
>    equivalent tty_wakeup().
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 27055738c910ee29a9de4b496e198e17b38b0eed
>Author: Peter Hurley <peter@hurleysoftware.com>
>Date:   Sun Jan 10 22:40:55 2016 -0800
>
>    tty: Fix unsafe ldisc reference via ioctl(TIOCGETD)
>    
>    [ Upstream commit 5c17c861a357e9458001f021a7afa7aab9937439 ]
>    
>    ioctl(TIOCGETD) retrieves the line discipline id directly from the
>    ldisc because the line discipline id (c_line) in termios is untrustworthy;
>    userspace may have set termios via ioctl(TCSETS*) without actually
>    changing the line discipline via ioctl(TIOCSETD).
>    
>    However, directly accessing the current ldisc via tty->ldisc is
>    unsafe; the ldisc ptr dereferenced may be stale if the line discipline
>    is changing via ioctl(TIOCSETD) or hangup.
>    
>    Wait for the line discipline reference (just like read() or write())
>    to retrieve the "current" line discipline id.
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 91e65860a7fe55d3d8c150104084b54f2760bc3d
>Author: Alan Stern <stern@rowland.harvard.edu>
>Date:   Wed Jan 20 11:26:01 2016 -0500
>
>    SCSI: fix crashes in sd and sr runtime PM
>    
>    [ Upstream commit 13b4389143413a1f18127c07f72c74cad5b563e8 ]
>    
>    Runtime suspend during driver probe and removal can cause problems.
>    The driver's runtime_suspend or runtime_resume callbacks may invoked
>    before the driver has finished binding to the device or after the
>    driver has unbound from the device.
>    
>    This problem shows up with the sd and sr drivers, and can cause disk
>    or CD/DVD drives to become unusable as a result.  The fix is simple.
>    The drivers store a pointer to the scsi_disk or scsi_cd structure as
>    their private device data when probing is finished, so we simply have
>    to be sure to clear the private data during removal and test it during
>    runtime suspend/resume.
>    
>    This fixes <https://bugs.debian.org/801925>.
>    
>    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
>    Reported-by: Paul Menzel <paul.menzel@giantmonkey.de>
>    Reported-by: Erich Schubert <erich@debian.org>
>    Reported-by: Alexandre Rossi <alexandre.rossi@gmail.com>
>    Tested-by: Paul Menzel <paul.menzel@giantmonkey.de>
>    Tested-by: Erich Schubert <erich@debian.org>
>    CC: <stable@vger.kernel.org>
>    Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 329d4fd5f2af659d62fa6f6cea72233c7e033e9a
>Author: Gavin Shan <gwshan@linux.vnet.ibm.com>
>Date:   Wed Dec 2 16:25:32 2015 +1100
>
>    powerpc/eeh: Fix PE location code
>    
>    [ Upstream commit 7e56f627768da4e6480986b5145dc3422bc448a5 ]
>    
>    In eeh_pe_loc_get(), the PE location code is retrieved from the
>    "ibm,loc-code" property of the device node for the bridge of the
>    PE's primary bus. It's not correct because the property indicates
>    the parent PE's location code.
>    
>    This reads the correct PE location code from "ibm,io-base-loc-code"
>    or "ibm,slot-location-code" property of PE parent bus's device node.
>    
>    Cc: stable@vger.kernel.org # v3.16+
>    Fixes: 357b2f3dd9b7 ("powerpc/eeh: Dump PE location code")
>    Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
>    Tested-by: Russell Currey <ruscur@russell.cc>
>    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit bd6d701606119bbbc3b55a064a53c6789a1acab6
>Author: Jan Beulich <JBeulich@suse.com>
>Date:   Tue Jan 26 04:15:18 2016 -0700
>
>    x86/mm: Fix types used in pgprot cacheability flags translations
>    
>    [ Upstream commit 3625c2c234ef66acf21a72d47a5ffa94f6c5ebf2 ]
>    
>    For PAE kernels "unsigned long" is not suitable to hold page protection
>    flags, since _PAGE_NX doesn't fit there. This is the reason for quite a
>    few W+X pages getting reported as insecure during boot (observed namely
>    for the entire initrd range).
>    
>    Fixes: 281d4078be ("x86: Make page cache mode a real type")
>    Signed-off-by: Jan Beulich <jbeulich@suse.com>
>    Reviewed-by: Juergen Gross <JGross@suse.com>
>    Cc: stable@vger.kernel.org
>    Link: http://lkml.kernel.org/r/56A7635602000078000CAFF1@prv-mh.provo.novell.com
>    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit daab58866c29c4e9af4d3df2175f2dc485057e46
>Author: Mika PenttilÃ¤ <mika.penttila@nextfour.com>
>Date:   Tue Jan 26 15:47:25 2016 +0000
>
>    arm64: mm: avoid calling apply_to_page_range on empty range
>    
>    [ Upstream commit 57adec866c0440976c96a4b8f5b59fb411b1cacb ]
>    
>    Calling apply_to_page_range with an empty range results in a BUG_ON
>    from the core code. This can be triggered by trying to load the st_drv
>    module with CONFIG_DEBUG_SET_MODULE_RONX enabled:
>    
>      kernel BUG at mm/memory.c:1874!
>      Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
>      Modules linked in:
>      CPU: 3 PID: 1764 Comm: insmod Not tainted 4.5.0-rc1+ #2
>      Hardware name: ARM Juno development board (r0) (DT)
>      task: ffffffc9763b8000 ti: ffffffc975af8000 task.ti: ffffffc975af8000
>      PC is at apply_to_page_range+0x2cc/0x2d0
>      LR is at change_memory_common+0x80/0x108
>    
>    This patch fixes the issue by making change_memory_common (called by the
>    set_memory_* functions) a NOP when numpages == 0, therefore avoiding the
>    erroneous call to apply_to_page_range and bringing us into line with x86
>    and s390.
>    
>    Cc: <stable@vger.kernel.org>
>    Reviewed-by: Laura Abbott <labbott@redhat.com>
>    Acked-by: David Rientjes <rientjes@google.com>
>    Signed-off-by: Mika PenttilÃ¤ <mika.penttila@nextfour.com>
>    Signed-off-by: Will Deacon <will.deacon@arm.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2c68386075ac61d3bedbc34491a0ed828ff832b9
>Author: Lucas Tanure <tanure@linux.com>
>Date:   Mon Jan 25 19:30:23 2016 -0200
>
>    ALSA: bebob: Use a signed return type for get_formation_index
>    
>    [ Upstream commit 07905298e4d5777eb58516cdc242f7ac1ca387a2 ]
>    
>    The return type "unsigned int" was used by the get_formation_index function
>    despite of the aspect that it will eventually return a negative	error code.
>    So, change to signed int and get index by reference in the parameters.
>    
>    Done with the help of Coccinelle.
>    
>    [Fix the missing braces suggested by Julia Lawall -- tiwai]
>    
>    Signed-off-by: Lucas Tanure <tanure@linux.com>
>    Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
>    Tested-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 593bd1058b30eb4f0d6949afdfd9c2659d94ae1e
>Author: Michael S. Tsirkin <mst@redhat.com>
>Date:   Thu Jan 14 16:00:41 2016 +0200
>
>    virtio_pci: fix use after free on release
>    
>    [ Upstream commit 2989be09a8a9d62a785137586ad941f916e08f83 ]
>    
>    KASan detected a use-after-free error in virtio-pci remove code. In
>    virtio_pci_remove(), vp_dev is still used after being freed in
>    unregister_virtio_device() (in virtio_pci_release_dev() more
>    precisely).
>    
>    To fix, keep a reference until cleanup is done.
>    
>    Fixes: 63bd62a08ca4 ("virtio_pci: defer kfree until release callback")
>    Reported-by: Jerome Marchand <jmarchan@redhat.com>
>    Cc: stable@vger.kernel.org
>    Cc: Sasha Levin <sasha.levin@oracle.com>
>    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>    Tested-by: Jerome Marchand <jmarchan@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 465cc6de211a88a8af978fd8e1d07e6a453a31c4
>Author: Guillaume Fougnies <guillaume@eulerian.com>
>Date:   Tue Jan 26 00:28:27 2016 +0100
>
>    ALSA: usb-audio: Fix TEAC UD-501/UD-503/NT-503 usb delay
>    
>    [ Upstream commit 5a4ff9ec8d6edd2ab1cfe8ce6a080d6e57cbea9a ]
>    
>    TEAC UD-501/UD-503/NT-503 fail to switch properly between different
>    rate/format. Similar to 'Playback Design', this patch corrects the
>    invalid clock source error for TEAC products and avoids complete
>    freeze of the usb interface of 503 series.
>    
>    Signed-off-by: Guillaume Fougnies <guillaume@eulerian.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 488c5719648811d5b9bb174f2c77fe2f09dcd799
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Mon Jan 25 13:59:21 2016 +0100
>
>    ALSA: compress: Disable GET_CODEC_CAPS ioctl for some architectures
>    
>    [ Upstream commit 462b3f161beb62eeb290f4ec52f5ead29a2f8ac7 ]
>    
>    Some architectures like PowerPC can handle the maximum struct size in
>    an ioctl only up to 13 bits, and struct snd_compr_codec_caps used by
>    SNDRV_COMPRESS_GET_CODEC_CAPS ioctl overflows this limit.  This
>    problem was revealed recently by a powerpc change, as it's now treated
>    as a fatal build error.
>    
>    This patch is a stop-gap for that: for architectures with less than 14
>    bit ioctl struct size, get rid of the handling of the relevant ioctl.
>    We should provide an alternative equivalent ioctl code later, but for
>    now just paper over it.  Luckily, the compress API hasn't been used on
>    such architectures, so the impact must be effectively zero.
>    
>    Reviewed-by: Mark Brown <broonie@kernel.org>
>    Acked-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3f0333c42683452b2315dec5963a5b997e213387
>Author: John Ernberg <john.ernberg@actia.se>
>Date:   Mon Jan 25 12:27:17 2016 +0000
>
>    USB: option: fix Cinterion AHxx enumeration
>    
>    [ Upstream commit 4152b387da81617c80cb2946b2d56e3958906b3e ]
>    
>    In certain kernel configurations where the cdc_ether and option drivers
>    are compiled as modules there can occur a race condition in enumeration.
>    This causes the option driver to enumerate the ethernet(wwan) interface
>    as usb-serial interfaces.
>    
>    usb-devices output for the modem:
>    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  5 Spd=480 MxCh= 0
>    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
>    P:  Vendor=1e2d ProdID=0055 Rev=00.00
>    S:  Manufacturer=Cinterion
>    S:  Product=AHx
>    C:  #Ifs= 6 Cfg#= 1 Atr=e0 MxPwr=10mA
>    I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
>    I:  If#= 1 Alt= 0 #EPs= 2 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=option
>    I:  If#= 4 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether
>    I:  If#= 5 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
>    
>    Signed-off-by: John Ernberg <john.ernberg@actia.se>
>    Fixes: 1941138e1c02 ("USB: added support for Cinterion's products...")
>    Cc: stable <stable@vger.kernel.org>	# v3.9: 8ff10bdb14a52
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit be630626eccf643f4c2c7e276e1f25b9928ec2e4
>Author: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>Date:   Wed Jan 13 14:50:03 2016 +0000
>
>    arm64: kernel: fix architected PMU registers unconditional access
>    
>    [ Upstream commit f436b2ac90a095746beb6729b8ee8ed87c9eaede ]
>    
>    The Performance Monitors extension is an optional feature of the
>    AArch64 architecture, therefore, in order to access Performance
>    Monitors registers safely, the kernel should detect the architected
>    PMU unit presence through the ID_AA64DFR0_EL1 register PMUVer field
>    before accessing them.
>    
>    This patch implements a guard by reading the ID_AA64DFR0_EL1 register
>    PMUVer field to detect the architected PMU presence and prevent accessing
>    PMU system registers if the Performance Monitors extension is not
>    implemented in the core.
>    
>    Cc: Peter Maydell <peter.maydell@linaro.org>
>    Cc: Mark Rutland <mark.rutland@arm.com>
>    Cc: <stable@vger.kernel.org>
>    Fixes: 60792ad349f3 ("arm64: kernel: enforce pmuserenr_el0 initialization and restore")
>    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>    Reported-by: Guenter Roeck <linux@roeck-us.net>
>    Tested-by: Guenter Roeck <linux@roeck-us.net>
>    Signed-off-by: Will Deacon <will.deacon@arm.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5ebf917025ec0d6f62f7d8411744d16efe9745d0
>Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>Date:   Tue Jan 19 23:43:13 2016 -0800
>
>    USB: serial: ftdi_sio: add support for Yaesu SCU-18 cable
>    
>    [ Upstream commit e03cdf22a2727c60307be6a729233edab3bfda9c ]
>    
>    Harald Linden reports that the ftdi_sio driver works properly for the
>    Yaesu SCU-18 cable if the device ids are added to the driver.  So let's
>    add them.
>    
>    Reported-by: Harald Linden <harald.linden@7183.org>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 14a2303b85c63299dad236f0d2df9143d22b9242
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Mon Jan 25 11:24:56 2016 +0100
>
>    ALSA: seq: Degrade the error message for too many opens
>    
>    [ Upstream commit da10816e3d923565b470fec78a674baba794ed33 ]
>    
>    ALSA OSS sequencer spews a kernel error message ("ALSA: seq_oss: too
>    many applications") when user-space tries to open more than the
>    limit.  This means that it can easily fill the log buffer.
>    
>    Since it's merely a normal error, it's safe to suppress it via
>    pr_debug() instead.
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 16116a3de550c2341933f4b0c54d7e52ceee4edf
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Mon Jan 25 11:01:47 2016 +0100
>
>    ALSA: seq: Fix incorrect sanity check at snd_seq_oss_synth_cleanup()
>    
>    [ Upstream commit 599151336638d57b98d92338aa59c048e3a3e97d ]
>    
>    ALSA sequencer OSS emulation code has a sanity check for currently
>    opened devices, but there is a thinko there, eventually it spews
>    warnings and skips the operation wrongly like:
>      WARNING: CPU: 1 PID: 7573 at sound/core/seq/oss/seq_oss_synth.c:311
>    
>    Fix this off-by-one error.
>    
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a498ef85e10d1ad035499be0bdcef38bdc791c1a
>Author: Daniele Palmas <dnlplm@gmail.com>
>Date:   Tue Jan 12 17:22:06 2016 +0100
>
>    USB: serial: option: Adding support for Telit LE922
>    
>    [ Upstream commit ff4e2494dc17b173468e1713fdf6237fd8578bc7 ]
>    
>    This patch adds support for two PIDs of LE922.
>    
>    Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 85491ceb50c4bc446127776714b41d2b9ca627f1
>Author: Vladis Dronov <vdronov@redhat.com>
>Date:   Tue Jan 12 15:10:50 2016 +0100
>
>    USB: serial: visor: fix crash on detecting device without write_urbs
>    
>    [ Upstream commit cb3232138e37129e88240a98a1d2aba2187ff57c ]
>    
>    The visor driver crashes in clie_5_attach() when a specially crafted USB
>    device without bulk-out endpoint is detected. This fix adds a check that
>    the device has proper configuration expected by the driver.
>    
>    Reported-by: Ralf Spenneberg <ralf@spenneberg.net>
>    Signed-off-by: Vladis Dronov <vdronov@redhat.com>
>    Fixes: cfb8da8f69b8 ("USB: visor: fix initialisation of UX50/TH55 devices")
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5c9cad0a726131934408f3a9e66fc381204a9ba2
>Author: Johan Hovold <johan@kernel.org>
>Date:   Tue Jan 12 12:05:20 2016 +0100
>
>    USB: visor: fix null-deref at probe
>    
>    [ Upstream commit cac9b50b0d75a1d50d6c056ff65c005f3224c8e0 ]
>    
>    Fix null-pointer dereference at probe should a (malicious) Treo device
>    lack the expected endpoints.
>    
>    Specifically, the Treo port-setup hack was dereferencing the bulk-in and
>    interrupt-in urbs without first making sure they had been allocated by
>    core.
>    
>    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1c47f2c5aff5993647468e8476bb6bbc6e09a939
>Author: Peter Dedecker <peter.dedecker@hotmail.com>
>Date:   Fri Jan 8 12:34:41 2016 +0100
>
>    USB: cp210x: add ID for IAI USB to RS485 adaptor
>    
>    [ Upstream commit f487c54ddd544e1c9172cd510954f697b77b76e3 ]
>    
>    Added the USB serial console device ID for IAI Corp. RCB-CV-USB
>    USB to RS485 adaptor.
>    
>    Signed-off-by: Peter Dedecker <peter.dedecker@hotmail.com>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 522dc09ca0451d118795e8a05c7b3717f3d1ad8b
>Author: Du, Changbin <changbin.du@intel.com>
>Date:   Mon Jan 18 21:02:42 2016 +0800
>
>    usb: hub: do not clear BOS field during reset device
>    
>    [ Upstream commit d8f00cd685f5c8e0def8593e520a7fef12c22407 ]
>    
>    In function usb_reset_and_verify_device, the old BOS descriptor may
>    still be used before allocating a new one. (usb_unlocked_disable_lpm
>    function uses it under the situation that it fails to disable lpm.)
>    So we cannot set the udev->bos to NULL before that, just keep what it
>    was. It will be overwrite when allocating a new one.
>    
>    Crash log:
>    BUG: unable to handle kernel NULL pointer dereference at
>    0000000000000010
>    IP: [<ffffffff8171f98d>] usb_enable_link_state+0x2d/0x2f0
>    Call Trace:
>    [<ffffffff8171ed5b>] ? usb_set_lpm_timeout+0x12b/0x140
>    [<ffffffff8171fcd1>] usb_enable_lpm+0x81/0xa0
>    [<ffffffff8171fdd8>] usb_disable_lpm+0xa8/0xc0
>    [<ffffffff8171fe1c>] usb_unlocked_disable_lpm+0x2c/0x50
>    [<ffffffff81723933>] usb_reset_and_verify_device+0xc3/0x710
>    [<ffffffff8172c4ed>] ? usb_sg_wait+0x13d/0x190
>    [<ffffffff81724743>] usb_reset_device+0x133/0x280
>    [<ffffffff8179ccd1>] usb_stor_port_reset+0x61/0x70
>    [<ffffffff8179cd68>] usb_stor_invoke_transport+0x88/0x520
>    
>    Signed-off-by: Du, Changbin <changbin.du@intel.com>
>    Cc: stable <stable@vger.kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 08d717c38d856465804b1b1d3fea19b64d8214e7
>Author: Oliver Neukum <oneukum@suse.com>
>Date:   Mon Jan 18 15:45:18 2016 +0100
>
>    cdc-acm:exclude Samsung phone 04e8:685d
>    
>    [ Upstream commit e912e685f372ab62a2405a1acd923597f524e94a ]
>    
>    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>
>    CC: stable@vger.kernel.org
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a7b1bf8b60e4fd4deb414cabc9f218eff244d4f9
>Author: Lu Baolu <baolu.lu@linux.intel.com>
>Date:   Wed Jan 6 15:10:04 2016 +0800
>
>    usb: cdc-acm: send zero packet for intel 7260 modem
>    
>    [ Upstream commit ffdb1e369a73b380fce95b05f8498d92c43842b4 ]
>    
>    For Intel 7260 modem, it is needed for host side to send zero
>    packet if the BULK OUT size is equal to USB endpoint max packet
>    length. Otherwise, modem side may still wait for more data and
>    cannot give response to host side.
>    
>    Signed-off-by: Konrad Leszczynski <konrad.leszczynski@intel.com>
>    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6cdc037a9b649209051e3c982d5fcaf31274cb55
>Author: Lu Baolu <baolu.lu@linux.intel.com>
>Date:   Wed Dec 30 12:59:08 2015 +0800
>
>    usb: cdc-acm: handle unlinked urb in acm read callback
>    
>    [ Upstream commit 19454462acb1bdef80542061bdc9b410e4ed1ff6 ]
>    
>    In current acm driver, the bulk-in callback function ignores the
>    URBs unlinked in usb core.
>    
>    This causes unexpected data loss in some cases. For example,
>    runtime suspend entry will unlinked all urbs and set urb->status
>    to -ENOENT even those urbs might have data not processed yet.
>    Hence, data loss occurs.
>    
>    This patch lets bulk-in callback function handle unlinked urbs
>    to avoid data loss.
>    
>    Signed-off-by: Tang Jian Qiang <jianqiang.tang@intel.com>
>    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
>    Cc: stable@vger.kernel.org
>    Acked-by: Oliver Neukum <oneukum@suse.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f75f1b25fb42f28b59d6e050cbdd4440797ac9ad
>Author: Josh Boyer <jwboyer@fedoraproject.org>
>Date:   Sun Jan 24 10:46:42 2016 -0500
>
>    ideapad-laptop: Add Lenovo Yoga 700 to no_hw_rfkill dmi list
>    
>    [ Upstream commit 6b31de3e698582fe0b8f7f4bab15831b73204800 ]
>    
>    Like the Yoga 900 models the Lenovo Yoga 700 does not have a
>    hw rfkill switch, and trying to read the hw rfkill switch through the
>    ideapad module causes it to always reported blocking breaking wifi.
>    
>    This commit adds the Lenovo Yoga 700 to the no_hw_rfkill dmi list, fixing
>    the wifi breakage.
>    
>    BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1295272
>    Tested-by: <dinyar.rabady+spam@gmail.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
>    Signed-off-by: Darren Hart <dvhart@linux.intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 085c2863e0f3e3107ff50eb79d226462b7f4fd78
>Author: Hans de Goede <hdegoede@redhat.com>
>Date:   Mon Nov 9 17:09:05 2015 +0100
>
>    ideapad-laptop: Add Lenovo Yoga 900 to no_hw_rfkill dmi list
>    
>    [ Upstream commit f71c882dd4cfe4aa88ea07b1402ddd43605d4aef ]
>    
>    Like some of the other Yoga models the Lenovo Yoga 900 does not have a
>    hw rfkill switch, and trying to read the hw rfkill switch through the
>    ideapad module causes it to always reported blocking breaking wifi.
>    
>    This commit adds the Lenovo Yoga 900 to the no_hw_rfkill dmi list, fixing
>    the wifi breakage.
>    
>    BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1275490
>    Cc: stable@vger.kernel.org
>    Reported-and-tested-by: Kevin Fenzi <kevin@scrye.com>
>    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>    Signed-off-by: Darren Hart <dvhart@linux.intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9295dee2df7af7ea4233b664a8d4d4d057748e2f
>Author: Trond Myklebust <trond.myklebust@primarydata.com>
>Date:   Thu Jan 21 15:39:40 2016 -0500
>
>    pNFS/flexfiles: Fix an XDR encoding bug in layoutreturn
>    
>    [ Upstream commit 082fa37d1351a41afc491d44a1d095cb8d919aa2 ]
>    
>    We must not skip encoding the statistics, or the server will see an
>    XDR encoding error.
>    
>    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
>    Cc: stable@vger.kernel.org # 4.0+
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b085ab71a7e748a9edb77a36ceadbab514ce0947
>Author: Tariq Saeed <tariq.x.saeed@oracle.com>
>Date:   Thu Jan 21 16:40:39 2016 -0800
>
>    ocfs2: NFS hangs in __ocfs2_cluster_lock due to race with ocfs2_unblock_lock
>    
>    [ Upstream commit b1b1e15ef6b80facf76d6757649dfd7295eda29f ]
>    
>    NFS on a 2 node ocfs2 cluster each node exporting dir.  The lock causing
>    the hang is the global bit map inode lock.  Node 1 is master, has the
>    lock granted in PR mode; Node 2 is in the converting list (PR -> EX).
>    There are no holders of the lock on the master node so it should
>    downconvert to NL and grant EX to node 2 but that does not happen.
>    BLOCKED + QUEUED in lock res are set and it is on osb blocked list.
>    Threads are waiting in __ocfs2_cluster_lock on BLOCKED.  One thread
>    wants EX, rest want PR.  So it is as though the downconvert thread needs
>    to be kicked to complete the conv.
>    
>    The hang is caused by an EX req coming into __ocfs2_cluster_lock on the
>    heels of a PR req after it sets BUSY (drops l_lock, releasing EX
>    thread), forcing the incoming EX to wait on BUSY without doing anything.
>    PR has called ocfs2_dlm_lock, which sets the node 1 lock from NL -> PR,
>    queues ast.
>    
>    At this time, upconvert (PR ->EX) arrives from node 2, finds conflict
>    with node 1 lock in PR, so the lock res is put on dlm thread's dirty
>    listt.
>    
>    After ret from ocf2_dlm_lock, PR thread now waits behind EX on BUSY till
>    awoken by ast.
>    
>    Now it is dlm_thread that serially runs dlm_shuffle_lists, ast, bast, in
>    that order.  dlm_shuffle_lists ques a bast on behalf of node 2 (which
>    will be run by dlm_thread right after the ast).  ast does its part, sets
>    UPCONVERT_FINISHING, clears BUSY and wakes its waiters.  Next,
>    dlm_thread runs bast.  It sets BLOCKED and kicks dc thread.  dc thread
>    runs ocfs2_unblock_lock, but since UPCONVERT_FINISHING set, skips doing
>    anything and reques.
>    
>    Inside of __ocfs2_cluster_lock, since EX has been waiting on BUSY ahead
>    of PR, it wakes up first, finds BLOCKED set and skips doing anything but
>    clearing UPCONVERT_FINISHING (which was actually "meant" for the PR
>    thread), and this time waits on BLOCKED.  Next, the PR thread comes out
>    of wait but since UPCONVERT_FINISHING is not set, it skips updating the
>    l_ro_holders and goes straight to wait on BLOCKED.  So there, we have a
>    hang! Threads in __ocfs2_cluster_lock wait on BLOCKED, lock res in osb
>    blocked list.  Only when dc thread is awoken, it will run
>    ocfs2_unblock_lock and things will unhang.
>    
>    One way to fix this is to wake the dc thread on the flag after clearing
>    UPCONVERT_FINISHING
>    
>    Orabug: 20933419
>    Signed-off-by: Tariq Saeed <tariq.x.saeed@oracle.com>
>    Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
>    Reviewed-by: Wengang Wang <wen.gang.wang@oracle.com>
>    Reviewed-by: Mark Fasheh <mfasheh@suse.de>
>    Cc: Joel Becker <jlbec@evilplan.org>
>    Cc: Junxiao Bi <junxiao.bi@oracle.com>
>    Reviewed-by: Joseph Qi <joseph.qi@huawei.com>
>    Cc: Eric Ren <zren@suse.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d4dc115d9b67b7ec9769efd9b55d5bfce8d9ef20
>Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>Date:   Thu Jan 21 16:40:27 2016 -0800
>
>    mm: fix mlock accouting
>    
>    [ Upstream commit 7162a1e87b3e380133dadc7909081bb70d0a7041 ]
>    
>    Tetsuo Handa reported underflow of NR_MLOCK on munlock.
>    
>    Testcase:
>    
>        #include <stdio.h>
>        #include <stdlib.h>
>        #include <sys/mman.h>
>    
>        #define BASE ((void *)0x400000000000)
>        #define SIZE (1UL << 21)
>    
>        int main(int argc, char *argv[])
>        {
>            void *addr;
>    
>            system("grep Mlocked /proc/meminfo");
>            addr = mmap(BASE, SIZE, PROT_READ | PROT_WRITE,
>                    MAP_ANONYMOUS | MAP_PRIVATE | MAP_LOCKED | MAP_FIXED,
>                    -1, 0);
>            if (addr == MAP_FAILED)
>                printf("mmap() failed\n"), exit(1);
>            munmap(addr, SIZE);
>            system("grep Mlocked /proc/meminfo");
>            return 0;
>        }
>    
>    It happens on munlock_vma_page() due to unfortunate choice of nr_pages
>    data type:
>    
>        __mod_zone_page_state(zone, NR_MLOCK, -nr_pages);
>    
>    For unsigned int nr_pages, implicitly casted to long in
>    __mod_zone_page_state(), it becomes something around UINT_MAX.
>    
>    munlock_vma_page() usually called for THP as small pages go though
>    pagevec.
>    
>    Let's make nr_pages signed int.
>    
>    Similar fixes in 6cdb18ad98a4 ("mm/vmstat: fix overflow in
>    mod_zone_page_state()") used `long' type, but `int' here is OK for a
>    count of the number of sub-pages in a huge page.
>    
>    Fixes: ff6a6da60b89 ("mm: accelerate munlock() treatment of THP pages")
>    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>    Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
>    Tested-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
>    Cc: Michel Lespinasse <walken@google.com>
>    Acked-by: Michal Hocko <mhocko@suse.com>
>    Cc: <stable@vger.kernel.org>  [4.4+]
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 65a7633357c158ed164878d97e8a7fc09fb75946
>Author: Ilya Dryomov <idryomov@gmail.com>
>Date:   Mon Dec 28 13:18:34 2015 +0300
>
>    libceph: fix ceph_msg_revoke()
>    
>    [ Upstream commit 67645d7619738e51c668ca69f097cb90b5470422 ]
>    
>    There are a number of problems with revoking a "was sending" message:
>    
>    (1) We never make any attempt to revoke data - only kvecs contibute to
>    con->out_skip.  However, once the header (envelope) is written to the
>    socket, our peer learns data_len and sets itself to expect at least
>    data_len bytes to follow front or front+middle.  If ceph_msg_revoke()
>    is called while the messenger is sending message's data portion,
>    anything we send after that call is counted by the OSD towards the now
>    revoked message's data portion.  The effects vary, the most common one
>    is the eventual hang - higher layers get stuck waiting for the reply to
>    the message that was sent out after ceph_msg_revoke() returned and
>    treated by the OSD as a bunch of data bytes.  This is what Matt ran
>    into.
>    
>    (2) Flat out zeroing con->out_kvec_bytes worth of bytes to handle kvecs
>    is wrong.  If ceph_msg_revoke() is called before the tag is sent out or
>    while the messenger is sending the header, we will get a connection
>    reset, either due to a bad tag (0 is not a valid tag) or a bad header
>    CRC, which kind of defeats the purpose of revoke.  Currently the kernel
>    client refuses to work with header CRCs disabled, but that will likely
>    change in the future, making this even worse.
>    
>    (3) con->out_skip is not reset on connection reset, leading to one or
>    more spurious connection resets if we happen to get a real one between
>    con->out_skip is set in ceph_msg_revoke() and before it's cleared in
>    write_partial_skip().
>    
>    Fixing (1) and (3) is trivial.  The idea behind fixing (2) is to never
>    zero the tag or the header, i.e. send out tag+header regardless of when
>    ceph_msg_revoke() is called.  That way the header is always correct, no
>    unnecessary resets are induced and revoke stands ready for disabled
>    CRCs.  Since ceph_msg_revoke() rips out con->out_msg, introduce a new
>    "message out temp" and copy the header into it before sending.
>    
>    Cc: stable@vger.kernel.org # 4.0+
>    Reported-by: Matt Conner <matt.conner@keepertech.com>
>    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
>    Tested-by: Matt Conner <matt.conner@keepertech.com>
>    Reviewed-by: Sage Weil <sage@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 92d4a19886bcce4cca4c9f993a7324ac607d142c
>Author: Mateusz Guzik <mguzik@redhat.com>
>Date:   Wed Jan 20 15:01:02 2016 -0800
>
>    prctl: take mmap sem for writing to protect against others
>    
>    [ Upstream commit ddf1d398e517e660207e2c807f76a90df543a217 ]
>    
>    An unprivileged user can trigger an oops on a kernel with
>    CONFIG_CHECKPOINT_RESTORE.
>    
>    proc_pid_cmdline_read takes mmap_sem for reading and obtains args + env
>    start/end values. These get sanity checked as follows:
>            BUG_ON(arg_start > arg_end);
>            BUG_ON(env_start > env_end);
>    
>    These can be changed by prctl_set_mm. Turns out also takes the semaphore for
>    reading, effectively rendering it useless. This results in:
>    
>      kernel BUG at fs/proc/base.c:240!
>      invalid opcode: 0000 [#1] SMP
>      Modules linked in: virtio_net
>      CPU: 0 PID: 925 Comm: a.out Not tainted 4.4.0-rc8-next-20160105dupa+ #71
>      Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
>      task: ffff880077a68000 ti: ffff8800784d0000 task.ti: ffff8800784d0000
>      RIP: proc_pid_cmdline_read+0x520/0x530
>      RSP: 0018:ffff8800784d3db8  EFLAGS: 00010206
>      RAX: ffff880077c5b6b0 RBX: ffff8800784d3f18 RCX: 0000000000000000
>      RDX: 0000000000000002 RSI: 00007f78e8857000 RDI: 0000000000000246
>      RBP: ffff8800784d3e40 R08: 0000000000000008 R09: 0000000000000001
>      R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000050
>      R13: 00007f78e8857800 R14: ffff88006fcef000 R15: ffff880077c5b600
>      FS:  00007f78e884a740(0000) GS:ffff88007b200000(0000) knlGS:0000000000000000
>      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>      CR2: 00007f78e8361770 CR3: 00000000790a5000 CR4: 00000000000006f0
>      Call Trace:
>        __vfs_read+0x37/0x100
>        vfs_read+0x82/0x130
>        SyS_read+0x58/0xd0
>        entry_SYSCALL_64_fastpath+0x12/0x76
>      Code: 4c 8b 7d a8 eb e9 48 8b 9d 78 ff ff ff 4c 8b 7d 90 48 8b 03 48 39 45 a8 0f 87 f0 fe ff ff e9 d1 fe ff ff 4c 8b 7d 90 eb c6 0f 0b <0f> 0b 0f 0b 66 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00
>      RIP   proc_pid_cmdline_read+0x520/0x530
>      ---[ end trace 97882617ae9c6818 ]---
>    
>    Turns out there are instances where the code just reads aformentioned
>    values without locking whatsoever - namely environ_read and get_cmdline.
>    
>    Interestingly these functions look quite resilient against bogus values,
>    but I don't believe this should be relied upon.
>    
>    The first patch gets rid of the oops bug by grabbing mmap_sem for
>    writing.
>    
>    The second patch is optional and puts locking around aformentioned
>    consumers for safety.  Consumers of other fields don't seem to benefit
>    from similar treatment and are left untouched.
>    
>    This patch (of 2):
>    
>    The code was taking the semaphore for reading, which does not protect
>    against readers nor concurrent modifications.
>    
>    The problem could cause a sanity checks to fail in procfs's cmdline
>    reader, resulting in an OOPS.
>    
>    Note that some functions perform an unlocked read of various mm fields,
>    but they seem to be fine despite possible modificaton.
>    
>    Signed-off-by: Mateusz Guzik <mguzik@redhat.com>
>    Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
>    Cc: Alexey Dobriyan <adobriyan@gmail.com>
>    Cc: Jarod Wilson <jarod@redhat.com>
>    Cc: Jan Stancek <jstancek@redhat.com>
>    Cc: Al Viro <viro@zeniv.linux.org.uk>
>    Cc: Anshuman Khandual <anshuman.linux@gmail.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c81f4f0331deb1b482d93b3ac8da5f04ff20ad48
>Author: James Bottomley <JBottomley@Odin.com>
>Date:   Wed Jan 20 14:58:29 2016 -0800
>
>    string_helpers: fix precision loss for some inputs
>    
>    [ Upstream commit 564b026fbd0d28e9f70fb3831293d2922bb7855b ]
>    
>    It was noticed that we lose precision in the final calculation for some
>    inputs.  The most egregious example is size=3000 blk_size=1900 in units
>    of 10 should yield 5.70 MB but in fact yields 3.00 MB (oops).
>    
>    This is because the current algorithm doesn't correctly account for
>    all the remainders in the logarithms.  Fix this by doing a correct
>    calculation in the remainders based on napier's algorithm.
>    
>    Additionally, now we have the correct result, we have to account for
>    arithmetic rounding because we're printing 3 digits of precision.  This
>    means that if the fourth digit is five or greater, we have to round up,
>    so add a section to ensure correct rounding.  Finally account for all
>    possible inputs correctly, including zero for block size.
>    
>    Fixes: b9f28d863594c429e1df35a0474d2663ca28b307
>    Signed-off-by: James Bottomley <JBottomley@Odin.com>
>    Reported-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>    Cc: <stable@vger.kernel.org>	[delay until after 4.4 release]
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4aba5827e764110bd1462eecf79209e656090f9c
>Author: Vitaly Kuznetsov <vkuznets@redhat.com>
>Date:   Thu Sep 17 16:01:51 2015 -0700
>
>    lib/string_helpers.c: fix infinite loop in string_get_size()
>    
>    [ Upstream commit 62bef58a55dfa8ada2a22b2496c6340468ecd98a ]
>    
>    Some string_get_size() calls (e.g.:
>     string_get_size(1, 512, STRING_UNITS_10, ..., ...)
>     string_get_size(15, 64, STRING_UNITS_10, ..., ...)
>    ) result in an infinite loop. The problem is that if size is equal to
>    divisor[units]/blk_size and is smaller than divisor[units] we'll end
>    up with size == 0 when we start doing sf_cap calculations:
>    
>    For string_get_size(1, 512, STRING_UNITS_10, ..., ...) case:
>       ...
>       remainder = do_div(size, divisor[units]); -> size is 0, remainder is 1
>       remainder *= blk_size; -> remainder is 512
>       ...
>       size *= blk_size; -> size is still 0
>       size += remainder / divisor[units]; -> size is still 0
>    
>    The caller causing the issue is sd_read_capacity(), the problem was
>    noticed on Hyper-V, such weird size was reported by host when scanning
>    collides with device removal.  This is probably a separate issue worth
>    fixing, this patch is intended to prevent the library routine from
>    infinite looping.
>    
>    Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>    Acked-by: James Bottomley <JBottomley@Odin.com>
>    Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>    Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
>    Cc: "K. Y. Srinivasan" <kys@microsoft.com>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3730198645d95e2ac438ea9276402d3908b9449d
>Author: Junil Lee <junil0814.lee@lge.com>
>Date:   Wed Jan 20 14:58:18 2016 -0800
>
>    zsmalloc: fix migrate_zspage-zs_free race condition
>    
>    [ Upstream commit c102f07ca0b04f2cb49cfc161c83f6239d17f491 ]
>    
>    record_obj() in migrate_zspage() does not preserve handle's
>    HANDLE_PIN_BIT, set by find_aloced_obj()->trypin_tag(), and implicitly
>    (accidentally) un-pins the handle, while migrate_zspage() still performs
>    an explicit unpin_tag() on the that handle.  This additional explicit
>    unpin_tag() introduces a race condition with zs_free(), which can pin
>    that handle by this time, so the handle becomes un-pinned.
>    
>    Schematically, it goes like this:
>    
>      CPU0                                        CPU1
>      migrate_zspage
>        find_alloced_obj
>          trypin_tag
>            set HANDLE_PIN_BIT                    zs_free()
>                                                    pin_tag()
>      obj_malloc() -- new object, no tag
>      record_obj() -- remove HANDLE_PIN_BIT           set HANDLE_PIN_BIT
>      unpin_tag()  -- remove zs_free's HANDLE_PIN_BIT
>    
>    The race condition may result in a NULL pointer dereference:
>    
>      Unable to handle kernel NULL pointer dereference at virtual address 00000000
>      CPU: 0 PID: 19001 Comm: CookieMonsterCl Tainted:
>      PC is at get_zspage_mapping+0x0/0x24
>      LR is at obj_free.isra.22+0x64/0x128
>      Call trace:
>         get_zspage_mapping+0x0/0x24
>         zs_free+0x88/0x114
>         zram_free_page+0x64/0xcc
>         zram_slot_free_notify+0x90/0x108
>         swap_entry_free+0x278/0x294
>         free_swap_and_cache+0x38/0x11c
>         unmap_single_vma+0x480/0x5c8
>         unmap_vmas+0x44/0x60
>         exit_mmap+0x50/0x110
>         mmput+0x58/0xe0
>         do_exit+0x320/0x8dc
>         do_group_exit+0x44/0xa8
>         get_signal+0x538/0x580
>         do_signal+0x98/0x4b8
>         do_notify_resume+0x14/0x5c
>    
>    This patch keeps the lock bit in migration path and update value
>    atomically.
>    
>    Signed-off-by: Junil Lee <junil0814.lee@lge.com>
>    Signed-off-by: Minchan Kim <minchan@kernel.org>
>    Acked-by: Vlastimil Babka <vbabka@suse.cz>
>    Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
>    Cc: <stable@vger.kernel.org> [4.1+]
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a9c56fd066f9b5d222e0813b732908dabd721867
>Author: Herbert Xu <herbert@gondor.apana.org.au>
>Date:   Tue Jan 19 21:23:57 2016 +0800
>
>    crypto: algif_skcipher - sendmsg SG marking is off by one
>    
>    [ Upstream commit 202736d99b7f29279db9da61587f11a08a04a9c6 ]
>    
>    We mark the end of the SG list in sendmsg and sendpage and unmark
>    it on the next send call.  Unfortunately the unmarking in sendmsg
>    is off-by-one, leading to an SG list that is too short.
>    
>    Fixes: 0f477b655a52 ("crypto: algif - Mark sgl end at the end of data")
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5446a444ae9e1976a77cb8faeab8198e44168daa
>Author: Nicholas Bellinger <nab@linux-iscsi.org>
>Date:   Tue Jan 19 16:15:27 2016 -0800
>
>    iscsi-target: Fix potential dead-lock during node acl delete
>    
>    [ Upstream commit 26a99c19f810b2593410899a5b304b21b47428a6 ]
>    
>    This patch is a iscsi-target specific bug-fix for a dead-lock
>    that can occur during explicit struct se_node_acl->acl_group
>    se_session deletion via configfs rmdir(2), when iscsi-target
>    time2retain timer is still active.
>    
>    It changes iscsi-target to obtain se_portal_group->session_lock
>    internally using spin_in_locked() to check for the specific
>    se_node_acl configfs shutdown rmdir(2) case.
>    
>    Note this patch is intended for stable, and the subsequent
>    v4.5-rc patch converts target_core_tpg.c to use proper
>    se_sess->sess_kref reference counting for both se_node_acl
>    deletion + se_node_acl->queue_depth se_session restart.
>    
>    Reported-by:: Sagi Grimberg <sagig@mellanox.com>
>    Cc: Christoph Hellwig <hch@lst.de>
>    Cc: Hannes Reinecke <hare@suse.de>
>    Cc: Andy Grover <agrover@redhat.com>
>    Cc: Mike Christie <michaelc@cs.wisc.edu>
>    Cc: stable@vger.kernel.org # 3.10+
>    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e004a097257612853c63b3f47726fe04981e94c2
>Author: Filipe Manana <fdmanana@suse.com>
>Date:   Fri Jan 15 11:05:12 2016 +0000
>
>    Btrfs: fix deadlock running delayed iputs at transaction commit time
>    
>    [ Upstream commit c2d6cb1636d235257086f939a8194ef0bf93af6e ]
>    
>    While running a stress test I ran into a deadlock when running the delayed
>    iputs at transaction time, which produced the following report and trace:
>    
>    [  886.399989] =============================================
>    [  886.400871] [ INFO: possible recursive locking detected ]
>    [  886.401663] 4.4.0-rc6-btrfs-next-18+ #1 Not tainted
>    [  886.402384] ---------------------------------------------
>    [  886.403182] fio/8277 is trying to acquire lock:
>    [  886.403568]  (&fs_info->delayed_iput_sem){++++..}, at: [<ffffffffa0538823>] btrfs_run_delayed_iputs+0x36/0xbf [btrfs]
>    [  886.403568]
>    [  886.403568] but task is already holding lock:
>    [  886.403568]  (&fs_info->delayed_iput_sem){++++..}, at: [<ffffffffa0538823>] btrfs_run_delayed_iputs+0x36/0xbf [btrfs]
>    [  886.403568]
>    [  886.403568] other info that might help us debug this:
>    [  886.403568]  Possible unsafe locking scenario:
>    [  886.403568]
>    [  886.403568]        CPU0
>    [  886.403568]        ----
>    [  886.403568]   lock(&fs_info->delayed_iput_sem);
>    [  886.403568]   lock(&fs_info->delayed_iput_sem);
>    [  886.403568]
>    [  886.403568]  *** DEADLOCK ***
>    [  886.403568]
>    [  886.403568]  May be due to missing lock nesting notation
>    [  886.403568]
>    [  886.403568] 3 locks held by fio/8277:
>    [  886.403568]  #0:  (sb_writers#11){.+.+.+}, at: [<ffffffff81174c4c>] __sb_start_write+0x5f/0xb0
>    [  886.403568]  #1:  (&sb->s_type->i_mutex_key#15){+.+.+.}, at: [<ffffffffa054620d>] btrfs_file_write_iter+0x73/0x408 [btrfs]
>    [  886.403568]  #2:  (&fs_info->delayed_iput_sem){++++..}, at: [<ffffffffa0538823>] btrfs_run_delayed_iputs+0x36/0xbf [btrfs]
>    [  886.403568]
>    [  886.403568] stack backtrace:
>    [  886.403568] CPU: 6 PID: 8277 Comm: fio Not tainted 4.4.0-rc6-btrfs-next-18+ #1
>    [  886.403568] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS by qemu-project.org 04/01/2014
>    [  886.403568]  0000000000000000 ffff88009f80f770 ffffffff8125d4fd ffffffff82af1fc0
>    [  886.403568]  ffff88009f80f830 ffffffff8108e5f9 0000000200000000 ffff88009fd92290
>    [  886.403568]  0000000000000000 ffffffff82af1fc0 ffffffff829cfb01 00042b216d008804
>    [  886.403568] Call Trace:
>    [  886.403568]  [<ffffffff8125d4fd>] dump_stack+0x4e/0x79
>    [  886.403568]  [<ffffffff8108e5f9>] __lock_acquire+0xd42/0xf0b
>    [  886.403568]  [<ffffffff810c22db>] ? __module_address+0xdf/0x108
>    [  886.403568]  [<ffffffff8108eb77>] lock_acquire+0x10d/0x194
>    [  886.403568]  [<ffffffff8108eb77>] ? lock_acquire+0x10d/0x194
>    [  886.403568]  [<ffffffffa0538823>] ? btrfs_run_delayed_iputs+0x36/0xbf [btrfs]
>    [  886.489542]  [<ffffffff8148556b>] down_read+0x3e/0x4d
>    [  886.489542]  [<ffffffffa0538823>] ? btrfs_run_delayed_iputs+0x36/0xbf [btrfs]
>    [  886.489542]  [<ffffffffa0538823>] btrfs_run_delayed_iputs+0x36/0xbf [btrfs]
>    [  886.489542]  [<ffffffffa0533953>] btrfs_commit_transaction+0x8f5/0x96e [btrfs]
>    [  886.489542]  [<ffffffffa0521d7a>] flush_space+0x435/0x44a [btrfs]
>    [  886.489542]  [<ffffffffa052218b>] ? reserve_metadata_bytes+0x26a/0x384 [btrfs]
>    [  886.489542]  [<ffffffffa05221ae>] reserve_metadata_bytes+0x28d/0x384 [btrfs]
>    [  886.489542]  [<ffffffffa052256c>] ? btrfs_block_rsv_refill+0x58/0x96 [btrfs]
>    [  886.489542]  [<ffffffffa0522584>] btrfs_block_rsv_refill+0x70/0x96 [btrfs]
>    [  886.489542]  [<ffffffffa053d747>] btrfs_evict_inode+0x394/0x55a [btrfs]
>    [  886.489542]  [<ffffffff81188e31>] evict+0xa7/0x15c
>    [  886.489542]  [<ffffffff81189878>] iput+0x1d3/0x266
>    [  886.489542]  [<ffffffffa053887c>] btrfs_run_delayed_iputs+0x8f/0xbf [btrfs]
>    [  886.489542]  [<ffffffffa0533953>] btrfs_commit_transaction+0x8f5/0x96e [btrfs]
>    [  886.489542]  [<ffffffff81085096>] ? signal_pending_state+0x31/0x31
>    [  886.489542]  [<ffffffffa0521191>] btrfs_alloc_data_chunk_ondemand+0x1d7/0x288 [btrfs]
>    [  886.489542]  [<ffffffffa0521282>] btrfs_check_data_free_space+0x40/0x59 [btrfs]
>    [  886.489542]  [<ffffffffa05228f5>] btrfs_delalloc_reserve_space+0x1e/0x4e [btrfs]
>    [  886.489542]  [<ffffffffa053620a>] btrfs_direct_IO+0x10c/0x27e [btrfs]
>    [  886.489542]  [<ffffffff8111d9a1>] generic_file_direct_write+0xb3/0x128
>    [  886.489542]  [<ffffffffa05463c3>] btrfs_file_write_iter+0x229/0x408 [btrfs]
>    [  886.489542]  [<ffffffff8108ae38>] ? __lock_is_held+0x38/0x50
>    [  886.489542]  [<ffffffff8117279e>] __vfs_write+0x7c/0xa5
>    [  886.489542]  [<ffffffff81172cda>] vfs_write+0xa0/0xe4
>    [  886.489542]  [<ffffffff811734cc>] SyS_write+0x50/0x7e
>    [  886.489542]  [<ffffffff814872d7>] entry_SYSCALL_64_fastpath+0x12/0x6f
>    [ 1081.852335] INFO: task fio:8244 blocked for more than 120 seconds.
>    [ 1081.854348]       Not tainted 4.4.0-rc6-btrfs-next-18+ #1
>    [ 1081.857560] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>    [ 1081.863227] fio        D ffff880213f9bb28     0  8244   8240 0x00000000
>    [ 1081.868719]  ffff880213f9bb28 00ffffff810fc6b0 ffffffff0000000a ffff88023ed55240
>    [ 1081.872499]  ffff880206b5d400 ffff880213f9c000 ffff88020a4d5318 ffff880206b5d400
>    [ 1081.876834]  ffffffff00000001 ffff880206b5d400 ffff880213f9bb40 ffffffff81482ba4
>    [ 1081.880782] Call Trace:
>    [ 1081.881793]  [<ffffffff81482ba4>] schedule+0x7f/0x97
>    [ 1081.883340]  [<ffffffff81485eb5>] rwsem_down_write_failed+0x2d5/0x325
>    [ 1081.895525]  [<ffffffff8108d48d>] ? trace_hardirqs_on_caller+0x16/0x1ab
>    [ 1081.897419]  [<ffffffff81269723>] call_rwsem_down_write_failed+0x13/0x20
>    [ 1081.899251]  [<ffffffff81269723>] ? call_rwsem_down_write_failed+0x13/0x20
>    [ 1081.901063]  [<ffffffff81089fae>] ? __down_write_nested.isra.0+0x1f/0x21
>    [ 1081.902365]  [<ffffffff814855bd>] down_write+0x43/0x57
>    [ 1081.903846]  [<ffffffffa05211b0>] ? btrfs_alloc_data_chunk_ondemand+0x1f6/0x288 [btrfs]
>    [ 1081.906078]  [<ffffffffa05211b0>] btrfs_alloc_data_chunk_ondemand+0x1f6/0x288 [btrfs]
>    [ 1081.908846]  [<ffffffff8108d461>] ? mark_held_locks+0x56/0x6c
>    [ 1081.910409]  [<ffffffffa0521282>] btrfs_check_data_free_space+0x40/0x59 [btrfs]
>    [ 1081.912482]  [<ffffffffa05228f5>] btrfs_delalloc_reserve_space+0x1e/0x4e [btrfs]
>    [ 1081.914597]  [<ffffffffa053620a>] btrfs_direct_IO+0x10c/0x27e [btrfs]
>    [ 1081.919037]  [<ffffffff8111d9a1>] generic_file_direct_write+0xb3/0x128
>    [ 1081.920754]  [<ffffffffa05463c3>] btrfs_file_write_iter+0x229/0x408 [btrfs]
>    [ 1081.922496]  [<ffffffff8108ae38>] ? __lock_is_held+0x38/0x50
>    [ 1081.923922]  [<ffffffff8117279e>] __vfs_write+0x7c/0xa5
>    [ 1081.925275]  [<ffffffff81172cda>] vfs_write+0xa0/0xe4
>    [ 1081.926584]  [<ffffffff811734cc>] SyS_write+0x50/0x7e
>    [ 1081.927968]  [<ffffffff814872d7>] entry_SYSCALL_64_fastpath+0x12/0x6f
>    [ 1081.985293] INFO: lockdep is turned off.
>    [ 1081.986132] INFO: task fio:8249 blocked for more than 120 seconds.
>    [ 1081.987434]       Not tainted 4.4.0-rc6-btrfs-next-18+ #1
>    [ 1081.988534] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>    [ 1081.990147] fio        D ffff880218febbb8     0  8249   8240 0x00000000
>    [ 1081.991626]  ffff880218febbb8 00ffffff81486b8e ffff88020000000b ffff88023ed75240
>    [ 1081.993258]  ffff8802120a9a00 ffff880218fec000 ffff88020a4d5318 ffff8802120a9a00
>    [ 1081.994850]  ffffffff00000001 ffff8802120a9a00 ffff880218febbd0 ffffffff81482ba4
>    [ 1081.996485] Call Trace:
>    [ 1081.997037]  [<ffffffff81482ba4>] schedule+0x7f/0x97
>    [ 1081.998017]  [<ffffffff81485eb5>] rwsem_down_write_failed+0x2d5/0x325
>    [ 1081.999241]  [<ffffffff810852a5>] ? finish_wait+0x6d/0x76
>    [ 1082.000306]  [<ffffffff81269723>] call_rwsem_down_write_failed+0x13/0x20
>    [ 1082.001533]  [<ffffffff81269723>] ? call_rwsem_down_write_failed+0x13/0x20
>    [ 1082.002776]  [<ffffffff81089fae>] ? __down_write_nested.isra.0+0x1f/0x21
>    [ 1082.003995]  [<ffffffff814855bd>] down_write+0x43/0x57
>    [ 1082.005000]  [<ffffffffa05211b0>] ? btrfs_alloc_data_chunk_ondemand+0x1f6/0x288 [btrfs]
>    [ 1082.007403]  [<ffffffffa05211b0>] btrfs_alloc_data_chunk_ondemand+0x1f6/0x288 [btrfs]
>    [ 1082.008988]  [<ffffffffa0545064>] btrfs_fallocate+0x7c1/0xc2f [btrfs]
>    [ 1082.010193]  [<ffffffff8108a1ba>] ? percpu_down_read+0x4e/0x77
>    [ 1082.011280]  [<ffffffff81174c4c>] ? __sb_start_write+0x5f/0xb0
>    [ 1082.012265]  [<ffffffff81174c4c>] ? __sb_start_write+0x5f/0xb0
>    [ 1082.013021]  [<ffffffff811712e4>] vfs_fallocate+0x170/0x1ff
>    [ 1082.013738]  [<ffffffff81181ebb>] ioctl_preallocate+0x89/0x9b
>    [ 1082.014778]  [<ffffffff811822d7>] do_vfs_ioctl+0x40a/0x4ea
>    [ 1082.015778]  [<ffffffff81176ea7>] ? SYSC_newfstat+0x25/0x2e
>    [ 1082.016806]  [<ffffffff8118b4de>] ? __fget_light+0x4d/0x71
>    [ 1082.017789]  [<ffffffff8118240e>] SyS_ioctl+0x57/0x79
>    [ 1082.018706]  [<ffffffff814872d7>] entry_SYSCALL_64_fastpath+0x12/0x6f
>    
>    This happens because we can recursively acquire the semaphore
>    fs_info->delayed_iput_sem when attempting to allocate space to satisfy
>    a file write request as shown in the first trace above - when committing
>    a transaction we acquire (down_read) the semaphore before running the
>    delayed iputs, and when running a delayed iput() we can end up calling
>    an inode's eviction handler, which in turn commits another transaction
>    and attempts to acquire (down_read) again the semaphore to run more
>    delayed iput operations.
>    This results in a deadlock because if a task acquires multiple times a
>    semaphore it should invoke down_read_nested() with a different lockdep
>    class for each level of recursion.
>    
>    Fix this by simplifying the implementation and use a mutex instead that
>    is acquired by the cleaner kthread before it runs the delayed iputs
>    instead of always acquiring a semaphore before delayed references are
>    run from anywhere.
>    
>    Fixes: d7c151717a1e (btrfs: Fix NO_SPACE bug caused by delayed-iput)
>    Cc: stable@vger.kernel.org   # 4.1+
>    Signed-off-by: Filipe Manana <fdmanana@suse.com>
>    Signed-off-by: Chris Mason <clm@fb.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f3eaec38506470d74a642b9aa518ed1fd6849b57
>Author: David Sterba <dsterba@suse.cz>
>Date:   Thu Nov 19 14:15:51 2015 +0100
>
>    btrfs: put delayed item hook into inode
>    
>    [ Upstream commit 8089fe62c6603860f6796ca80519b92391292f21 ]
>    
>    Inodes for delayed iput allocate a trivial helper structure, let's place
>    the list hook directly into the inode and save a kmalloc (killing a
>    __GFP_NOFAIL as a bonus) at the cost of increasing size of btrfs_inode.
>    
>    The inode can be put into the delayed_iputs list more than once and we
>    have to keep the count. This means we can't use the list_splice to
>    process a bunch of inodes because we'd lost track of the count if the
>    inode is put into the delayed iputs again while it's processed.
>    
>    Signed-off-by: David Sterba <dsterba@suse.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c98b306e392edc0898a1dd715761998222c19676
>Author: Josh Boyer <jwboyer@fedoraproject.org>
>Date:   Wed Dec 9 21:12:52 2015 -0500
>
>    ideapad-laptop: Add Lenovo ideapad Y700-17ISK to no_hw_rfkill dmi list
>    
>    [ Upstream commit edde316acb5f07c04abf09a92f59db5d2efd14e2 ]
>    
>    One of the newest ideapad models also lacks a physical hw rfkill switch,
>    and trying to read the hw rfkill switch through the ideapad module
>    causes it to always reported blocking breaking wifi.
>    
>    Fix it by adding this model to the DMI list.
>    
>    BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1286293
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
>    Signed-off-by: Darren Hart <dvhart@linux.intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 34d7d523ecaa8c7a6857f97fd251e95e628aa17e
>Author: Vinit Agnihotri <vinit.abhay.agnihotri@intel.com>
>Date:   Mon Jan 11 12:57:25 2016 -0500
>
>    IB/qib: Support creating qps with GFP_NOIO flag
>    
>    [ Upstream commit fbbeb8632bf0b46ab44cfcedc4654cd7831b7161 ]
>    
>    The current code is problematic when the QP creation and ipoib is used to
>    support NFS and NFS desires to do IO for paging purposes. In that case, the
>    GFP_KERNEL allocation in qib_qp.c causes a deadlock in tight memory
>    situations.
>    
>    This fix adds support to create queue pair with GFP_NOIO flag for connected
>    mode only to cleanly fail the create queue pair in those situations.
>    
>    Cc: <stable@vger.kernel.org> # 3.16+
>    Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
>    Signed-off-by: Vinit Agnihotri <vinit.abhay.agnihotri@intel.com>
>    Signed-off-by: Doug Ledford <dledford@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit dfaff0ef0343ba85ba3bac69a6547701425c0242
>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
>    
>    [ Upstream commit 09dc9cd6528f5b52bcbd3292a6312e762c85260f ]
>    
>    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.
>    
>    Cc: <stable@vger.kernel.org>
>    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: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5d545a70cca8594f6120a9e3d70187920e62ce77
>Author: Jean Delvare <jdelvare@suse.de>
>Date:   Mon Jan 18 17:06:05 2016 +0100
>
>    crypto: crc32c - Fix crc32c soft dependency
>    
>    [ Upstream commit fd7f6727102a1ccf6b4c1dfcc631f9b546526b26 ]
>    
>    I don't think it makes sense for a module to have a soft dependency
>    on itself. This seems quite cyclic by nature and I can't see what
>    purpose it could serve.
>    
>    OTOH libcrc32c calls crypto_alloc_shash("crc32c", 0, 0) so it pretty
>    much assumes that some incarnation of the "crc32c" hash algorithm has
>    been loaded. Therefore it makes sense to have the soft dependency
>    there (as crc-t10dif does.)
>    
>    Cc: stable@vger.kernel.org
>    Cc: Tim Chen <tim.c.chen@linux.intel.com>
>    Cc: "David S. Miller" <davem@davemloft.net>
>    Signed-off-by: Jean Delvare <jdelvare@suse.de>
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4126014e7cd0d5e667953610139b20388910cbbd
>Author: Dave Chinner <dchinner@redhat.com>
>Date:   Tue Jan 19 08:28:10 2016 +1100
>
>    xfs: log mount failures don't wait for buffers to be released
>    
>    [ Upstream commit 85bec5460ad8e05e0a8d70fb0f6750eb719ad092 ]
>    
>    Recently I've been seeing xfs/051 fail on 1k block size filesystems.
>    Trying to trace the events during the test lead to the problem going
>    away, indicating that it was a race condition that lead to this
>    ASSERT failure:
>    
>    XFS: Assertion failed: atomic_read(&pag->pag_ref) == 0, file: fs/xfs/xfs_mount.c, line: 156
>    .....
>    [<ffffffff814e1257>] xfs_free_perag+0x87/0xb0
>    [<ffffffff814e21b9>] xfs_mountfs+0x4d9/0x900
>    [<ffffffff814e5dff>] xfs_fs_fill_super+0x3bf/0x4d0
>    [<ffffffff811d8800>] mount_bdev+0x180/0x1b0
>    [<ffffffff814e3ff5>] xfs_fs_mount+0x15/0x20
>    [<ffffffff811d90a8>] mount_fs+0x38/0x170
>    [<ffffffff811f4347>] vfs_kern_mount+0x67/0x120
>    [<ffffffff811f7018>] do_mount+0x218/0xd60
>    [<ffffffff811f7e5b>] SyS_mount+0x8b/0xd0
>    
>    When I finally caught it with tracing enabled, I saw that AG 2 had
>    an elevated reference count and a buffer was responsible for it. I
>    tracked down the specific buffer, and found that it was missing the
>    final reference count release that would put it back on the LRU and
>    hence be found by xfs_wait_buftarg() calls in the log mount failure
>    handling.
>    
>    The last four traces for the buffer before the assert were (trimmed
>    for relevance)
>    
>    kworker/0:1-5259   xfs_buf_iodone:        hold 2  lock 0 flags ASYNC
>    kworker/0:1-5259   xfs_buf_ioerror:       hold 2  lock 0 error -5
>    mount-7163	   xfs_buf_lock_done:     hold 2  lock 0 flags ASYNC
>    mount-7163	   xfs_buf_unlock:        hold 2  lock 1 flags ASYNC
>    
>    This is an async write that is completing, so there's nobody waiting
>    for it directly.  Hence we call xfs_buf_relse() once all the
>    processing is complete. That does:
>    
>    static inline void xfs_buf_relse(xfs_buf_t *bp)
>    {
>    	xfs_buf_unlock(bp);
>    	xfs_buf_rele(bp);
>    }
>    
>    Now, it's clear that mount is waiting on the buffer lock, and that
>    it has been released by xfs_buf_relse() and gained by mount. This is
>    expected, because at this point the mount process is in
>    xfs_buf_delwri_submit() waiting for all the IO it submitted to
>    complete.
>    
>    The mount process, however, is waiting on the lock for the buffer
>    because it is in xfs_buf_delwri_submit(). This waits for IO
>    completion, but it doesn't wait for the buffer reference owned by
>    the IO to go away. The mount process collects all the completions,
>    fails the log recovery, and the higher level code then calls
>    xfs_wait_buftarg() to free all the remaining buffers in the
>    filesystem.
>    
>    The issue is that on unlocking the buffer, the scheduler has decided
>    that the mount process has higher priority than the the kworker
>    thread that is running the IO completion, and so immediately
>    switched contexts to the mount process from the semaphore unlock
>    code, hence preventing the kworker thread from finishing the IO
>    completion and releasing the IO reference to the buffer.
>    
>    Hence by the time that xfs_wait_buftarg() is run, the buffer still
>    has an active reference and so isn't on the LRU list that the
>    function walks to free the remaining buffers. Hence we miss that
>    buffer and continue onwards to tear down the mount structures,
>    at which time we get find a stray reference count on the perag
>    structure. On a non-debug kernel, this will be ignored and the
>    structure torn down and freed. Hence when the kworker thread is then
>    rescheduled and the buffer released and freed, it will access a
>    freed perag structure.
>    
>    The problem here is that when the log mount fails, we still need to
>    quiesce the log to ensure that the IO workqueues have returned to
>    idle before we run xfs_wait_buftarg(). By synchronising the
>    workqueues, we ensure that all IO completions are fully processed,
>    not just to the point where buffers have been unlocked. This ensures
>    we don't end up in the situation above.
>    
>    cc: <stable@vger.kernel.org> # 3.18
>    Signed-off-by: Dave Chinner <dchinner@redhat.com>
>    Reviewed-by: Brian Foster <bfoster@redhat.com>
>    Signed-off-by: Dave Chinner <david@fromorbit.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 34d751ee6985e545e5de6d2c626e33001ea5fc5b
>Author: Arnd Bergmann <arnd@arndb.de>
>Date:   Mon Jan 18 10:45:00 2016 +0100
>
>    ARM: debug-ll: fix BCM63xx entry for multiplatform
>    
>    [ Upstream commit 6c54809977de3c9e2ef9e9934a2c6625f7e161e7 ]
>    
>    During my randconfig build testing, I found that a kernel with
>    DEBUG_AT91_UART and ARCH_BCM_63XX fails to build:
>    
>    arch/arm/include/debug/at91.S:18:0: error: "CONFIG_DEBUG_UART_VIRT" redefined [-Werror]
>    
>    It turns out that the DEBUG_UART_BCM63XX option is enabled whenever
>    the ARCH_BCM_63XX is, and that breaks multiplatform kernels because
>    we then end up using the UART address from BCM63XX rather than the
>    one we actually configured (if any).
>    
>    This changes the BCM63XX options to only have one Kconfig option,
>    and only enable that if the user explicitly turns it on.
>    
>    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>    Fixes: b51312bebfa4 ("ARM: BCM63XX: add low-level UART debug support")
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 40ced0bb2cd8bd17c4f1061176c2ca1db71ec667
>Author: Songjun Wu <songjun.wu@atmel.com>
>Date:   Mon Jan 18 11:14:44 2016 +0100
>
>    dmaengine: at_xdmac: fix resume for cyclic transfers
>    
>    [ Upstream commit 611dcadb01c89d1d3521450c05a4ded332e5a32d ]
>    
>    When having cyclic transfers, the channel was paused when performing
>    suspend but was not correctly resumed.
>    
>    Signed-off-by: Songjun Wu <songjun.wu@atmel.com>
>    Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
>    Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel
>    eXtended DMA Controller driver")
>    Cc: <stable@vger.kernel.org> # 4.1 and later
>    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3a1e81ad84e4d880b00ecf7ad8d03b9b772ddfa7
>Author: Herbert Xu <herbert@gondor.apana.org.au>
>Date:   Fri Jan 15 22:01:08 2016 +0800
>
>    crypto: algif_hash - Fix race condition in hash_check_key
>    
>    [ Upstream commit ad46d7e33219218605ea619e32553daf4f346b9f ]
>    
>    We need to lock the child socket in hash_check_key as otherwise
>    two simultaneous calls can cause the parent socket to be freed.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8515819fff8fce56be067af985016b6356d1fe5e
>Author: Herbert Xu <herbert@gondor.apana.org.au>
>Date:   Wed Jan 13 15:03:32 2016 +0800
>
>    crypto: af_alg - Forbid bind(2) when nokey child sockets are present
>    
>    [ Upstream commit a6a48c565f6f112c6983e2a02b1602189ed6e26e ]
>    
>    This patch forbids the calling of bind(2) when there are child
>    sockets created by accept(2) in existence, even if they are created
>    on the nokey path.
>    
>    This is needed as those child sockets have references to the tfm
>    object which bind(2) will destroy.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 279792e1f4f66d719fe9ff7c720dd600d9880fbf
>Author: Herbert Xu <herbert@gondor.apana.org.au>
>Date:   Wed Jan 13 15:00:36 2016 +0800
>
>    crypto: algif_hash - Remove custom release parent function
>    
>    [ Upstream commit f1d84af1835846a5a2b827382c5848faf2bb0e75 ]
>    
>    This patch removes the custom release parent function as the
>    generic af_alg_release_parent now works for nokey sockets too.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 99214a2ff7f6faef389659e93dafdf41ae86a72b
>Author: Herbert Xu <herbert@gondor.apana.org.au>
>Date:   Wed Jan 13 14:59:03 2016 +0800
>
>    crypto: af_alg - Allow af_af_alg_release_parent to be called on nokey path
>    
>    [ Upstream commit 6a935170a980024dd29199e9dbb5c4da4767a1b9 ]
>    
>    This patch allows af_alg_release_parent to be called even for
>    nokey sockets.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e1ed9a4b4380fc33c558a0c1bd7cbf527e891151
>Author: Herbert Xu <herbert@gondor.apana.org.au>
>Date:   Fri Jan 8 21:31:04 2016 +0800
>
>    crypto: algif_hash - Require setkey before accept(2)
>    
>    [ Upstream commit 6de62f15b581f920ade22d758f4c338311c2f0d4 ]
>    
>    Hash implementations that require a key may crash if you use
>    them without setting a key.  This patch adds the necessary checks
>    so that if you do attempt to use them without a key that we return
>    -ENOKEY instead of proceeding.
>    
>    This patch also adds a compatibility path to support old applications
>    that do acept(2) before setkey.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c409087e6db988257adffb614616764116c7337e
>Author: Herbert Xu <herbert@gondor.apana.org.au>
>Date:   Fri Jan 8 21:28:26 2016 +0800
>
>    crypto: hash - Add crypto_ahash_has_setkey
>    
>    [ Upstream commit a5596d6332787fd383b3b5427b41f94254430827 ]
>    
>    This patch adds a way for ahash users to determine whether a key
>    is required by a crypto_ahash transform.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 92d76b5b2c3a29e14bc01a5e96d075afd4c6644f
>Author: Herbert Xu <herbert@gondor.apana.org.au>
>Date:   Mon Jan 4 13:35:18 2016 +0900
>
>    crypto: af_alg - Add nokey compatibility path
>    
>    [ Upstream commit 37766586c965d63758ad542325a96d5384f4a8c9 ]
>    
>    This patch adds a compatibility path to support old applications
>    that do acept(2) before setkey.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit fa988b35c2e40f38e57388a1a3f48de056e81dd3
>Author: Herbert Xu <herbert@gondor.apana.org.au>
>Date:   Wed Dec 30 20:24:17 2015 +0800
>
>    crypto: af_alg - Fix socket double-free when accept fails
>    
>    [ Upstream commit a383292c86663bbc31ac62cc0c04fc77504636a6 ]
>    
>    When we fail an accept(2) call we will end up freeing the socket
>    twice, once due to the direct sk_free call and once again through
>    newsock.
>    
>    This patch fixes this by removing the sk_free call.
>    
>    Cc: stable@vger.kernel.org
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0571ba52a19e18a1c20469454231eef681cb1310
>Author: Herbert Xu <herbert@gondor.apana.org.au>
>Date:   Wed Dec 30 11:47:53 2015 +0800
>
>    crypto: af_alg - Disallow bind/setkey/... after accept(2)
>    
>    [ Upstream commit c840ac6af3f8713a71b4d2363419145760bd6044 ]
>    
>    Each af_alg parent socket obtained by socket(2) corresponds to a
>    tfm object once bind(2) has succeeded.  An accept(2) call on that
>    parent socket creates a context which then uses the tfm object.
>    
>    Therefore as long as any child sockets created by accept(2) exist
>    the parent socket must not be modified or freed.
>    
>    This patch guarantees this by using locks and a reference count
>    on the parent socket.  Any attempt to modify the parent socket will
>    fail with EBUSY.
>    
>    Cc: stable@vger.kernel.org
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit bc24ac15b0746172a8f603171352aa54abcf7c78
>Author: Tejun Heo <tj@kernel.org>
>Date:   Fri Jan 15 16:58:24 2016 -0800
>
>    printk: do cond_resched() between lines while outputting to consoles
>    
>    [ Upstream commit 8d91f8b15361dfb438ab6eb3b319e2ded43458ff ]
>    
>    @console_may_schedule tracks whether console_sem was acquired through
>    lock or trylock.  If the former, we're inside a sleepable context and
>    console_conditional_schedule() performs cond_resched().  This allows
>    console drivers which use console_lock for synchronization to yield
>    while performing time-consuming operations such as scrolling.
>    
>    However, the actual console outputting is performed while holding
>    irq-safe logbuf_lock, so console_unlock() clears @console_may_schedule
>    before starting outputting lines.  Also, only a few drivers call
>    console_conditional_schedule() to begin with.  This means that when a
>    lot of lines need to be output by console_unlock(), for example on a
>    console registration, the task doing console_unlock() may not yield for
>    a long time on a non-preemptible kernel.
>    
>    If this happens with a slow console devices, for example a serial
>    console, the outputting task may occupy the cpu for a very long time.
>    Long enough to trigger softlockup and/or RCU stall warnings, which in
>    turn pile more messages, sometimes enough to trigger the next cycle of
>    warnings incapacitating the system.
>    
>    Fix it by making console_unlock() insert cond_resched() between lines if
>    @console_may_schedule.
>    
>    Signed-off-by: Tejun Heo <tj@kernel.org>
>    Reported-by: Calvin Owens <calvinowens@fb.com>
>    Acked-by: Jan Kara <jack@suse.com>
>    Cc: Dave Jones <davej@codemonkey.org.uk>
>    Cc: Kyle McMartin <kyle@kernel.org>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0e19e24c3fe0abde8e2c5f4543616a251ccea6bf
>Author: Vitaly Kuznetsov <vkuznets@redhat.com>
>Date:   Fri Nov 20 15:57:24 2015 -0800
>
>    kernel/panic.c: turn off locks debug before releasing console lock
>    
>    [ Upstream commit 7625b3a0007decf2b135cb47ca67abc78a7b1bc1 ]
>    
>    Commit 08d78658f393 ("panic: release stale console lock to always get the
>    logbuf printed out") introduced an unwanted bad unlock balance report when
>    panic() is called directly and not from OOPS (e.g.  from out_of_memory()).
>    The difference is that in case of OOPS we disable locks debug in
>    oops_enter() and on direct panic call nobody does that.
>    
>    Fixes: 08d78658f393 ("panic: release stale console lock to always get the logbuf printed out")
>    Reported-by: kernel test robot <ying.huang@linux.intel.com>
>    Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>    Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
>    Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
>    Cc: Jiri Kosina <jkosina@suse.cz>
>    Cc: Baoquan He <bhe@redhat.com>
>    Cc: Prarit Bhargava <prarit@redhat.com>
>    Cc: Xie XiuQi <xiexiuqi@huawei.com>
>    Cc: Seth Jennings <sjenning@redhat.com>
>    Cc: "K. Y. Srinivasan" <kys@microsoft.com>
>    Cc: Jan Kara <jack@suse.cz>
>    Cc: Petr Mladek <pmladek@suse.cz>
>    Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 94ecf566322c74e13509e834605e71b332d2469f
>Author: Vitaly Kuznetsov <vkuznets@redhat.com>
>Date:   Fri Nov 6 16:32:58 2015 -0800
>
>    panic: release stale console lock to always get the logbuf printed out
>    
>    [ Upstream commit 08d78658f393fefaa2e6507ea052c6f8ef4002a2 ]
>    
>    In some cases we may end up killing the CPU holding the console lock
>    while still having valuable data in logbuf. E.g. I'm observing the
>    following:
>    
>    - A crash is happening on one CPU and console_unlock() is being called on
>      some other.
>    
>    - console_unlock() tries to print out the buffer before releasing the lock
>      and on slow console it takes time.
>    
>    - in the meanwhile crashing CPU does lots of printk()-s with valuable data
>      (which go to the logbuf) and sends IPIs to all other CPUs.
>    
>    - console_unlock() finishes printing previous chunk and enables interrupts
>      before trying to print out the rest, the CPU catches the IPI and never
>      releases console lock.
>    
>    This is not the only possible case: in VT/fb subsystems we have many other
>    console_lock()/console_unlock() users.  Non-masked interrupts (or
>    receiving NMI in case of extreme slowness) will have the same result.
>    Getting the whole console buffer printed out on crash should be top
>    priority.
>    
>    [akpm@linux-foundation.org: tweak comment text]
>    Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>    Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
>    Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
>    Cc: Jiri Kosina <jkosina@suse.cz>
>    Cc: Baoquan He <bhe@redhat.com>
>    Cc: Prarit Bhargava <prarit@redhat.com>
>    Cc: Xie XiuQi <xiexiuqi@huawei.com>
>    Cc: Seth Jennings <sjenning@redhat.com>
>    Cc: "K. Y. Srinivasan" <kys@microsoft.com>
>    Cc: Jan Kara <jack@suse.cz>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2c641f5b0c8e87d43235ce39890bcc4d0c7cd2fb
>Author: Martijn Coenen <maco@google.com>
>Date:   Fri Jan 15 16:57:49 2016 -0800
>
>    memcg: only free spare array when readers are done
>    
>    [ Upstream commit 6611d8d76132f86faa501de9451a89bf23fb2371 ]
>    
>    A spare array holding mem cgroup threshold events is kept around to make
>    sure we can always safely deregister an event and have an array to store
>    the new set of events in.
>    
>    In the scenario where we're going from 1 to 0 registered events, the
>    pointer to the primary array containing 1 event is copied to the spare
>    slot, and then the spare slot is freed because no events are left.
>    However, it is freed before calling synchronize_rcu(), which means
>    readers may still be accessing threshold->primary after it is freed.
>    
>    Fixed by only freeing after synchronize_rcu().
>    
>    Signed-off-by: Martijn Coenen <maco@google.com>
>    Cc: Johannes Weiner <hannes@cmpxchg.org>
>    Acked-by: Michal Hocko <mhocko@suse.com>
>    Cc: Vladimir Davydov <vdavydov@virtuozzo.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4ae0f4a619e2071dc184e0792d90ace3fd18c280
>Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
>Date:   Fri Jan 15 16:54:03 2016 -0800
>
>    mm: soft-offline: check return value in second __get_any_page() call
>    
>    [ Upstream commit d96b339f453997f2f08c52da3f41423be48c978f ]
>    
>    I saw the following BUG_ON triggered in a testcase where a process calls
>    madvise(MADV_SOFT_OFFLINE) on thps, along with a background process that
>    calls migratepages command repeatedly (doing ping-pong among different
>    NUMA nodes) for the first process:
>    
>       Soft offlining page 0x60000 at 0x700000600000
>       __get_any_page: 0x60000 free buddy page
>       page:ffffea0001800000 count:0 mapcount:-127 mapping:          (null) index:0x1
>       flags: 0x1fffc0000000000()
>       page dumped because: VM_BUG_ON_PAGE(atomic_read(&page->_count) == 0)
>       ------------[ cut here ]------------
>       kernel BUG at /src/linux-dev/include/linux/mm.h:342!
>       invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
>       Modules linked in: cfg80211 rfkill crc32c_intel serio_raw virtio_balloon i2c_piix4 virtio_blk virtio_net ata_generic pata_acpi
>       CPU: 3 PID: 3035 Comm: test_alloc_gene Tainted: G           O    4.4.0-rc8-v4.4-rc8-160107-1501-00000-rc8+ #74
>       Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
>       task: ffff88007c63d5c0 ti: ffff88007c210000 task.ti: ffff88007c210000
>       RIP: 0010:[<ffffffff8118998c>]  [<ffffffff8118998c>] put_page+0x5c/0x60
>       RSP: 0018:ffff88007c213e00  EFLAGS: 00010246
>       Call Trace:
>         put_hwpoison_page+0x4e/0x80
>         soft_offline_page+0x501/0x520
>         SyS_madvise+0x6bc/0x6f0
>         entry_SYSCALL_64_fastpath+0x12/0x6a
>       Code: 8b fc ff ff 5b 5d c3 48 89 df e8 b0 fa ff ff 48 89 df 31 f6 e8 c6 7d ff ff 5b 5d c3 48 c7 c6 08 54 a2 81 48 89 df e8 a4 c5 01 00 <0f> 0b 66 90 66 66 66 66 90 55 48 89 e5 41 55 41 54 53 48 8b 47
>       RIP  [<ffffffff8118998c>] put_page+0x5c/0x60
>        RSP <ffff88007c213e00>
>    
>    The root cause resides in get_any_page() which retries to get a refcount
>    of the page to be soft-offlined.  This function calls
>    put_hwpoison_page(), expecting that the target page is putback to LRU
>    list.  But it can be also freed to buddy.  So the second check need to
>    care about such case.
>    
>    Fixes: af8fae7c0886 ("mm/memory-failure.c: clean up soft_offline_page()")
>    Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
>    Cc: Sasha Levin <sasha.levin@oracle.com>
>    Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>    Cc: Vlastimil Babka <vbabka@suse.cz>
>    Cc: Jerome Marchand <jmarchan@redhat.com>
>    Cc: Andrea Arcangeli <aarcange@redhat.com>
>    Cc: Hugh Dickins <hughd@google.com>
>    Cc: Dave Hansen <dave.hansen@intel.com>
>    Cc: Mel Gorman <mgorman@suse.de>
>    Cc: Rik van Riel <riel@redhat.com>
>    Cc: Steve Capper <steve.capper@linaro.org>
>    Cc: Johannes Weiner <hannes@cmpxchg.org>
>    Cc: Michal Hocko <mhocko@suse.cz>
>    Cc: Christoph Lameter <cl@linux.com>
>    Cc: David Rientjes <rientjes@google.com>
>    Cc: <stable@vger.kernel.org>	[3.9+]
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7332411bbb9f327e65467013ef10d1d0f4999fcb
>Author: Kyeongdon Kim <kyeongdon.kim@lge.com>
>Date:   Thu Jan 14 15:22:29 2016 -0800
>
>    zram: try vmalloc() after kmalloc()
>    
>    [ Upstream commit d913897abace843bba20249f3190167f7895e9c3 ]
>    
>    When we're using LZ4 multi compression streams for zram swap, we found
>    out page allocation failure message in system running test.  That was
>    not only once, but a few(2 - 5 times per test).  Also, some failure
>    cases were continually occurring to try allocation order 3.
>    
>    In order to make parallel compression private data, we should call
>    kzalloc() with order 2/3 in runtime(lzo/lz4).  But if there is no order
>    2/3 size memory to allocate in that time, page allocation fails.  This
>    patch makes to use vmalloc() as fallback of kmalloc(), this prevents
>    page alloc failure warning.
>    
>    After using this, we never found warning message in running test, also
>    It could reduce process startup latency about 60-120ms in each case.
>    
>    For reference a call trace :
>    
>        Binder_1: page allocation failure: order:3, mode:0x10c0d0
>        CPU: 0 PID: 424 Comm: Binder_1 Tainted: GW 3.10.49-perf-g991d02b-dirty #20
>        Call trace:
>          dump_backtrace+0x0/0x270
>          show_stack+0x10/0x1c
>          dump_stack+0x1c/0x28
>          warn_alloc_failed+0xfc/0x11c
>          __alloc_pages_nodemask+0x724/0x7f0
>          __get_free_pages+0x14/0x5c
>          kmalloc_order_trace+0x38/0xd8
>          zcomp_lz4_create+0x2c/0x38
>          zcomp_strm_alloc+0x34/0x78
>          zcomp_strm_multi_find+0x124/0x1ec
>          zcomp_strm_find+0xc/0x18
>          zram_bvec_rw+0x2fc/0x780
>          zram_make_request+0x25c/0x2d4
>          generic_make_request+0x80/0xbc
>          submit_bio+0xa4/0x15c
>          __swap_writepage+0x218/0x230
>          swap_writepage+0x3c/0x4c
>          shrink_page_list+0x51c/0x8d0
>          shrink_inactive_list+0x3f8/0x60c
>          shrink_lruvec+0x33c/0x4cc
>          shrink_zone+0x3c/0x100
>          try_to_free_pages+0x2b8/0x54c
>          __alloc_pages_nodemask+0x514/0x7f0
>          __get_free_pages+0x14/0x5c
>          proc_info_read+0x50/0xe4
>          vfs_read+0xa0/0x12c
>          SyS_read+0x44/0x74
>        DMA: 3397*4kB (MC) 26*8kB (RC) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB
>             0*512kB 0*1024kB 0*2048kB 0*4096kB = 13796kB
>    
>    [minchan@kernel.org: change vmalloc gfp and adding comment about gfp]
>    [sergey.senozhatsky@gmail.com: tweak comments and styles]
>    Signed-off-by: Kyeongdon Kim <kyeongdon.kim@lge.com>
>    Signed-off-by: Minchan Kim <minchan@kernel.org>
>    Acked-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
>    Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 664ecf4f243bac17065cd9878790d40a592e2f3d
>Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
>Date:   Thu Jan 14 15:22:26 2016 -0800
>
>    zram/zcomp: use GFP_NOIO to allocate streams
>    
>    [ Upstream commit 3d5fe03a3ea013060ebba2a811aeb0f23f56aefa ]
>    
>    We can end up allocating a new compression stream with GFP_KERNEL from
>    within the IO path, which may result is nested (recursive) IO
>    operations.  That can introduce problems if the IO path in question is a
>    reclaimer, holding some locks that will deadlock nested IOs.
>    
>    Allocate streams and working memory using GFP_NOIO flag, forbidding
>    recursive IO and FS operations.
>    
>    An example:
>    
>      inconsistent {IN-RECLAIM_FS-W} -> {RECLAIM_FS-ON-W} usage.
>      git/20158 [HC0[0]:SC0[0]:HE1:SE1] takes:
>       (jbd2_handle){+.+.?.}, at:  start_this_handle+0x4ca/0x555
>      {IN-RECLAIM_FS-W} state was registered at:
>         __lock_acquire+0x8da/0x117b
>         lock_acquire+0x10c/0x1a7
>         start_this_handle+0x52d/0x555
>         jbd2__journal_start+0xb4/0x237
>         __ext4_journal_start_sb+0x108/0x17e
>         ext4_dirty_inode+0x32/0x61
>         __mark_inode_dirty+0x16b/0x60c
>         iput+0x11e/0x274
>         __dentry_kill+0x148/0x1b8
>         shrink_dentry_list+0x274/0x44a
>         prune_dcache_sb+0x4a/0x55
>         super_cache_scan+0xfc/0x176
>         shrink_slab.part.14.constprop.25+0x2a2/0x4d3
>         shrink_zone+0x74/0x140
>         kswapd+0x6b7/0x930
>         kthread+0x107/0x10f
>         ret_from_fork+0x3f/0x70
>      irq event stamp: 138297
>      hardirqs last  enabled at (138297):  debug_check_no_locks_freed+0x113/0x12f
>      hardirqs last disabled at (138296):  debug_check_no_locks_freed+0x33/0x12f
>      softirqs last  enabled at (137818):  __do_softirq+0x2d3/0x3e9
>      softirqs last disabled at (137813):  irq_exit+0x41/0x95
>    
>                   other info that might help us debug this:
>       Possible unsafe locking scenario:
>             CPU0
>             ----
>        lock(jbd2_handle);
>        <Interrupt>
>          lock(jbd2_handle);
>    
>                    *** DEADLOCK ***
>      5 locks held by git/20158:
>       #0:  (sb_writers#7){.+.+.+}, at: [<ffffffff81155411>] mnt_want_write+0x24/0x4b
>       #1:  (&type->i_mutex_dir_key#2/1){+.+.+.}, at: [<ffffffff81145087>] lock_rename+0xd9/0xe3
>       #2:  (&sb->s_type->i_mutex_key#11){+.+.+.}, at: [<ffffffff8114f8e2>] lock_two_nondirectories+0x3f/0x6b
>       #3:  (&sb->s_type->i_mutex_key#11/4){+.+.+.}, at: [<ffffffff8114f909>] lock_two_nondirectories+0x66/0x6b
>       #4:  (jbd2_handle){+.+.?.}, at: [<ffffffff811e31db>] start_this_handle+0x4ca/0x555
>    
>                   stack backtrace:
>      CPU: 2 PID: 20158 Comm: git Not tainted 4.1.0-rc7-next-20150615-dbg-00016-g8bdf555-dirty #211
>      Call Trace:
>        dump_stack+0x4c/0x6e
>        mark_lock+0x384/0x56d
>        mark_held_locks+0x5f/0x76
>        lockdep_trace_alloc+0xb2/0xb5
>        kmem_cache_alloc_trace+0x32/0x1e2
>        zcomp_strm_alloc+0x25/0x73 [zram]
>        zcomp_strm_multi_find+0xe7/0x173 [zram]
>        zcomp_strm_find+0xc/0xe [zram]
>        zram_bvec_rw+0x2ca/0x7e0 [zram]
>        zram_make_request+0x1fa/0x301 [zram]
>        generic_make_request+0x9c/0xdb
>        submit_bio+0xf7/0x120
>        ext4_io_submit+0x2e/0x43
>        ext4_bio_write_page+0x1b7/0x300
>        mpage_submit_page+0x60/0x77
>        mpage_map_and_submit_buffers+0x10f/0x21d
>        ext4_writepages+0xc8c/0xe1b
>        do_writepages+0x23/0x2c
>        __filemap_fdatawrite_range+0x84/0x8b
>        filemap_flush+0x1c/0x1e
>        ext4_alloc_da_blocks+0xb8/0x117
>        ext4_rename+0x132/0x6dc
>        ? mark_held_locks+0x5f/0x76
>        ext4_rename2+0x29/0x2b
>        vfs_rename+0x540/0x636
>        SyS_renameat2+0x359/0x44d
>        SyS_rename+0x1e/0x20
>        entry_SYSCALL_64_fastpath+0x12/0x6f
>    
>    [minchan@kernel.org: add stable mark]
>    Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
>    Acked-by: Minchan Kim <minchan@kernel.org>
>    Cc: Kyeongdon Kim <kyeongdon.kim@lge.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 39e51d967413e64c40eae6201430b1ffdb90ba08
>Author: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
>Date:   Mon Dec 7 12:25:02 2015 +0530
>
>    perf kvm record/report: 'unprocessable sample' error while recording/reporting guest data
>    
>    [ Upstream commit 3caeaa562733c4836e61086ec07666635006a787 ]
>    
>    While recording guest samples in host using perf kvm record, it will
>    populate unprocessable sample error, though samples will be recorded
>    properly. While generating report using perf kvm report, no samples will
>    be processed and same error will populate. We have seen this behaviour
>    with upstream perf(4.4-rc3) on x86 and ppc64 hardware.
>    
>    Reason behind this failure is, when it tries to fetch machine from
>    rb_tree of machines, it fails. As a part of tracing a bug, we figured
>    out that this code was incorrectly refactored in commit 54245fdc3576
>    ("perf session: Remove wrappers to machines__find").
>    
>    This patch will change the functionality such that if it can't fetch
>    machine in first trial, it will create one node of machine and add that to
>    rb_tree. So next time when it tries to fetch same machine from rb_tree,
>    it won't fail. Actually it was the case before refactoring of code in
>    aforementioned commit.
>    
>    This patch is generated from acme perf/core branch.
>    
>    Below I've mention an example that demonstrate the behaviour before and
>    after applying patch.
>    
>    Before applying patch:
>    [Note: One needs to run guest before recording data in host]
>    
>      ravi@ravi-bangoria:~$ ./perf kvm record -a
>      Warning:
>      5903 unprocessable samples recorded.
>      Do you have a KVM guest running and not using 'perf kvm'?
>      [ perf record: Captured and wrote 1.409 MB perf.data.guest (285 samples) ]
>    
>      ravi@ravi-bangoria:~$ ./perf kvm report --stdio
>      Warning:
>      5903 unprocessable samples recorded.
>      Do you have a KVM guest running and not using 'perf kvm'?
>      # To display the perf.data header info, please use --header/--header-only options.
>      #
>      # Total Lost Samples: 0
>      #
>      # Samples: 285  of event 'cycles'
>      # Event count (approx.): 88715406
>      #
>      # Overhead  Command  Shared Object  Symbol
>      # ........  .......  .............  ......
>      #
>    
>      # (For a higher level overview, try: perf report --sort comm,dso)
>      #
>    
>    After applying patch:
>    
>      ravi@ravi-bangoria:~$ ./perf kvm record -a
>      [ perf record: Captured and wrote 1.188 MB perf.data.guest (17 samples) ]
>    
>      ravi@ravi-bangoria:~$ ./perf kvm report --stdio
>      # To display the perf.data header info, please use --header/--header-only options.
>      #
>      # Total Lost Samples: 0
>      #
>      # Samples: 17  of event 'cycles'
>      # Event count (approx.): 700746
>      #
>      # Overhead  Command  Shared Object     Symbol
>      # ........  .......  ................  ......................
>      #
>          34.19%  :5758    [unknown]         [g] 0xffffffff818682ab
>          22.79%  :5758    [unknown]         [g] 0xffffffff812dc7f8
>          22.79%  :5758    [unknown]         [g] 0xffffffff818650d0
>          14.83%  :5758    [unknown]         [g] 0xffffffff8161a1b6
>           2.49%  :5758    [unknown]         [g] 0xffffffff818692bf
>           0.48%  :5758    [unknown]         [g] 0xffffffff81869253
>           0.05%  :5758    [unknown]         [g] 0xffffffff81869250
>    
>    Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
>    Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
>    Cc: stable@vger.kernel.org # v3.19+
>    Fixes: 54245fdc3576 ("perf session: Remove wrappers to machines__find")
>    Link: http://lkml.kernel.org/r/1449471302-11283-1-git-send-email-ravi.bangoria@linux.vnet.ibm.com
>    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8467278d965a3c2c2f2e95c8eb723f47b872ad5d
>Author: xuejiufei <xuejiufei@huawei.com>
>Date:   Thu Jan 14 15:17:38 2016 -0800
>
>    ocfs2/dlm: ignore cleaning the migration mle that is inuse
>    
>    [ Upstream commit bef5502de074b6f6fa647b94b73155d675694420 ]
>    
>    We have found that migration source will trigger a BUG that the refcount
>    of mle is already zero before put when the target is down during
>    migration.  The situation is as follows:
>    
>    dlm_migrate_lockres
>      dlm_add_migration_mle
>      dlm_mark_lockres_migrating
>      dlm_get_mle_inuse
>      <<<<<< Now the refcount of the mle is 2.
>      dlm_send_one_lockres and wait for the target to become the
>      new master.
>      <<<<<< o2hb detect the target down and clean the migration
>      mle. Now the refcount is 1.
>    
>    dlm_migrate_lockres woken, and put the mle twice when found the target
>    goes down which trigger the BUG with the following message:
>    
>      "ERROR: bad mle: ".
>    
>    Signed-off-by: Jiufei Xue <xuejiufei@huawei.com>
>    Reviewed-by: Joseph Qi <joseph.qi@huawei.com>
>    Cc: Mark Fasheh <mfasheh@suse.de>
>    Cc: Joel Becker <jlbec@evilplan.org>
>    Cc: Junxiao Bi <junxiao.bi@oracle.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c91d339da50d0f1e1f61556fa6ef3374d6810c80
>Author: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
>Date:   Thu Jan 14 15:16:53 2016 -0800
>
>    scripts/bloat-o-meter: fix python3 syntax error
>    
>    [ Upstream commit 72214a24a7677d4c7501eecc9517ed681b5f2db2 ]
>    
>    In Python3+ print is a function so the old syntax is not correct
>    anymore:
>    
>      $ ./scripts/bloat-o-meter vmlinux.o vmlinux.o.old
>        File "./scripts/bloat-o-meter", line 61
>          print "add/remove: %s/%s grow/shrink: %s/%s up/down: %s/%s (%s)" % \
>                                                                         ^
>      SyntaxError: invalid syntax
>    
>    Fix by calling print as a function.
>    
>    Tested on python 2.7.11, 3.5.1
>    
>    Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 68cc9774de3e0ad8de67d6fbbdaf4a808cbc62a9
>Author: Laura Abbott <labbott@fedoraproject.org>
>Date:   Thu Jan 14 15:16:50 2016 -0800
>
>    dma-debug: switch check from _text to _stext
>    
>    [ Upstream commit ea535e418c01837d07b6c94e817540f50bfdadb0 ]
>    
>    In include/asm-generic/sections.h:
>    
>      /*
>       * Usage guidelines:
>       * _text, _data: architecture specific, don't use them in
>       * arch-independent code
>       * [_stext, _etext]: contains .text.* sections, may also contain
>       * .rodata.*
>       *                   and/or .init.* sections
>    
>    _text is not guaranteed across architectures.  Architectures such as ARM
>    may reuse parts which are not actually text and erroneously trigger a bug.
>    Switch to using _stext which is guaranteed to contain text sections.
>    
>    Came out of https://lkml.kernel.org/g/<567B1176.4000106@redhat.com>
>    
>    Signed-off-by: Laura Abbott <labbott@fedoraproject.org>
>    Reviewed-by: Kees Cook <keescook@chromium.org>
>    Cc: Russell King <linux@arm.linux.org.uk>
>    Cc: Arnd Bergmann <arnd@arndb.de>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a5254ac06b9aaf6ef99bb260fe713f6a64371353
>Author: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
>Date:   Thu Jan 14 15:16:47 2016 -0800
>
>    m32r: fix m32104ut_defconfig build fail
>    
>    [ Upstream commit 601f1db653217f205ffa5fb33514b4e1711e56d1 ]
>    
>    The build of m32104ut_defconfig for m32r arch was failing for long long
>    time with the error:
>    
>      ERROR: "memory_start" [fs/udf/udf.ko] undefined!
>      ERROR: "memory_end" [fs/udf/udf.ko] undefined!
>      ERROR: "memory_end" [drivers/scsi/sg.ko] undefined!
>      ERROR: "memory_start" [drivers/scsi/sg.ko] undefined!
>      ERROR: "memory_end" [drivers/i2c/i2c-dev.ko] undefined!
>      ERROR: "memory_start" [drivers/i2c/i2c-dev.ko] undefined!
>    
>    As done in other architectures export the symbols to fix the error.
>    
>    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
>    Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c5882812d2e1ab7db5bc71a1bca90b3a2d89dedd
>Author: Vasily Averin <vvs@virtuozzo.com>
>Date:   Thu Jan 14 13:41:14 2016 +0300
>
>    cifs_dbg() outputs an uninitialized buffer in cifs_readdir()
>    
>    [ Upstream commit 01b9b0b28626db4a47d7f48744d70abca9914ef1 ]
>    
>    In some cases tmp_bug can be not filled in cifs_filldir and stay uninitialized,
>    therefore its printk with "%s" modifier can leak content of kernelspace memory.
>    If old content of this buffer does not contain '\0' access bejond end of
>    allocated object can crash the host.
>    
>    Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
>    Signed-off-by: Steve French <sfrench@localhost.localdomain>
>    CC: Stable <stable@vger.kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 99b79b15df4ed1a6293cff487b46efc86bd20ae5
>Author: Rabin Vincent <rabin.vincent@axis.com>
>Date:   Wed Dec 23 07:32:41 2015 +0100
>
>    cifs: fix race between call_async() and reconnect()
>    
>    [ Upstream commit 820962dc700598ffe8cd21b967e30e7520c34748 ]
>    
>    cifs_call_async() queues the MID to the pending list and calls
>    smb_send_rqst().  If smb_send_rqst() performs a partial send, it sets
>    the tcpStatus to CifsNeedReconnect and returns an error code to
>    cifs_call_async().  In this case, cifs_call_async() removes the MID
>    from the list and returns to the caller.
>    
>    However, cifs_call_async() releases the server mutex _before_ removing
>    the MID.  This means that a cifs_reconnect() can race with this function
>    and manage to remove the MID from the list and delete the entry before
>    cifs_call_async() calls cifs_delete_mid().  This leads to various
>    crashes due to the use after free in cifs_delete_mid().
>    
>    Task1				Task2
>    
>    cifs_call_async():
>     - rc = -EAGAIN
>     - mutex_unlock(srv_mutex)
>    
>    				cifs_reconnect():
>    				 - mutex_lock(srv_mutex)
>    				 - mutex_unlock(srv_mutex)
>    				 - list_delete(mid)
>    				 - mid->callback()
>    				 	cifs_writev_callback():
>    				 		- mutex_lock(srv_mutex)
>    						- delete(mid)
>    				 		- mutex_unlock(srv_mutex)
>    
>     - cifs_delete_mid(mid) <---- use after free
>    
>    Fix this by removing the MID in cifs_call_async() before releasing the
>    srv_mutex.  Also hold the srv_mutex in cifs_reconnect() until the MIDs
>    are moved out of the pending list.
>    
>    Signed-off-by: Rabin Vincent <rabin.vincent@axis.com>
>    Acked-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
>    CC: Stable <stable@vger.kernel.org>
>    Signed-off-by: Steve French <sfrench@localhost.localdomain>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ca7342a8a39704670c4079aacbd78e360beaf223
>Author: Jamie Bainbridge <jamie.bainbridge@gmail.com>
>Date:   Sat Nov 7 22:13:49 2015 +1000
>
>    cifs: Ratelimit kernel log messages
>    
>    [ Upstream commit ec7147a99e33a9e4abad6fc6e1b40d15df045d53 ]
>    
>    Under some conditions, CIFS can repeatedly call the cifs_dbg() logging
>    wrapper. If done rapidly enough, the console framebuffer can softlockup
>    or "rcu_sched self-detected stall". Apply the built-in log ratelimiters
>    to prevent such hangs.
>    
>    Signed-off-by: Jamie Bainbridge <jamie.bainbridge@gmail.com>
>    Signed-off-by: Steve French <smfrench@gmail.com>
>    CC: Stable <stable@vger.kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5301c0647782e71150361a3854ccf3e004b79bb9
>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
>    
>    [ Upstream commit 525fd5a94e1be0776fa652df5c687697db508c91 ]
>    
>    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>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2a048a248fad2e7d49a3a5c8b9259f403182b5ac
>Author: Carlo Caione <carlo@endlessm.com>
>Date:   Wed Jan 13 09:36:55 2016 +0100
>
>    mmc: core: Enable tuning according to the actual timing
>    
>    [ Upstream commit e10c321977091f163eceedec0650e0ef4b3cf4bb ]
>    
>    While in sdhci_execute_tuning() the choice whether or not to enable the
>    tuning is done on the actual timing, in the mmc_sdio_init_uhs_card() the
>    check is done on the capability of the card.
>    
>    This difference is causing some issues with some SDIO cards in DDR50
>    mode where the CDM19 is wrongly issued.
>    
>    With this patch we modify the check in both
>    mmc_(sd|sdio)_init_uhs_card() functions to take the proper decision
>    only according to the actual timing specification.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Carlo Caione <carlo@endlessm.com>
>    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6e1e9bd06060eedf56db7aa53909b52944fc3d06
>Author: Weijun Yang <york.yang@csr.com>
>Date:   Sun Oct 4 12:04:11 2015 +0000
>
>    mmc: core: enable CMD19 tuning for DDR50 mode
>    
>    [ Upstream commit 4324f6de6d2eb9b232410eb0d67bfafdde8ba711 ]
>    
>    As SD Specifications Part1 Physical Layer Specification Version
>    3.01 says, CMD19 tuning is available for unlocked cards in transfer
>    state of 1.8V signaling mode. The small difference between v3.00
>    and 3.01 spec means that CMD19 tuning is also available for DDR50
>    mode.
>    
>    Signed-off-by: Weijun Yang <york.yang@csr.com>
>    Signed-off-by: Barry Song <Baohua.Song@csr.com>
>    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8a55af069755c320f9f69c29d6bba9856ba8a74a
>Author: Linus Walleij <linus.walleij@linaro.org>
>Date:   Mon Jan 4 02:21:55 2016 +0100
>
>    mmc: mmci: fix an ages old detection error
>    
>    [ Upstream commit 0bcb7efdff63564e80fe84dd36a9fbdfbf6697a4 ]
>    
>    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.
>    
>    Cc: stable@vger.kernel.org
>    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: Sasha Levin <sasha.levin@oracle.com>
>
>commit 66eba3dabc93f3404e3d011cd19a2eb45b87990f
>Author: Mans Rullgard <mans@mansr.com>
>Date:   Mon Jan 11 13:04:29 2016 +0000
>
>    dmaengine: dw: fix cyclic transfer callbacks
>    
>    [ Upstream commit 2895b2cad6e7a95104cf396e5330054453382ae1 ]
>    
>    Cyclic transfer callbacks rely on block completion interrupts which were
>    disabled in commit ff7b05f29fd4 ("dmaengine/dw_dmac: Don't handle block
>    interrupts").  This re-enables block interrupts so the cyclic callbacks
>    can work.  Other transfer types are not affected as they set the INT_EN
>    bit only on the last block.
>    
>    Fixes: ff7b05f29fd4 ("dmaengine/dw_dmac: Don't handle block interrupts")
>    Signed-off-by: Mans Rullgard <mans@mansr.com>
>    Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
>    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 13aedd784b84cb7d8a3bb835941d80e99f5c796e
>Author: Mans Rullgard <mans@mansr.com>
>Date:   Mon Jan 11 13:04:28 2016 +0000
>
>    dmaengine: dw: fix cyclic transfer setup
>    
>    [ Upstream commit df3bb8a0e619d501cd13334c3e0586edcdcbc716 ]
>    
>    Commit 61e183f83069 ("dmaengine/dw_dmac: Reconfigure interrupt and
>    chan_cfg register on resume") moved some channel initialisation to
>    a new function which must be called before starting a transfer.
>    
>    This updates dw_dma_cyclic_start() to use dwc_dostart() like the other
>    modes, thus ensuring dwc_initialize() gets called and removing some code
>    duplication.
>    
>    Fixes: 61e183f83069 ("dmaengine/dw_dmac: Reconfigure interrupt and chan_cfg register on resume")
>    Signed-off-by: Mans Rullgard <mans@mansr.com>
>    Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
>    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 064ee90886630403af052302f922a07499595515
>Author: Greg Kurz <gkurz@linux.vnet.ibm.com>
>Date:   Wed Jan 13 18:28:17 2016 +0100
>
>    KVM: PPC: Fix ONE_REG AltiVec support
>    
>    [ Upstream commit b4d7f161feb3015d6306e1d35b565c888ff70c9d ]
>    
>    The get and set operations got exchanged by mistake when moving the
>    code from book3s.c to powerpc.c.
>    
>    Fixes: 3840edc8033ad5b86deee309c1c321ca54257452
>    Cc: stable@vger.kernel.org # 3.18+
>    Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
>    Signed-off-by: Paul Mackerras <paulus@samba.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 12060a1c7cd09460128f8580c1862de807294c3a
>Author: Chris Wilson <chris@chris-wilson.co.uk>
>Date:   Fri Nov 27 13:28:55 2015 +0000
>
>    drm/i915: Restore inhibiting the load of the default context
>    
>    [ Upstream commit 06ef83a705a98da63797a5a570220b6ca36febd4 ]
>    
>    Following a GPU reset, we may leave the context in a poorly defined
>    state, and reloading from that context will leave the GPU flummoxed. For
>    secondary contexts, this will lead to that context being banned - but
>    currently it is also causing the default context to become banned,
>    leading to turmoil in the shared state.
>    
>    This is a regression from
>    
>    commit 6702cf16e0ba8b0129f5aa1b6609d4e9c70bc13b [v4.1]
>    Author: Ben Widawsky <benjamin.widawsky@intel.com>
>    Date:   Mon Mar 16 16:00:58 2015 +0000
>    
>        drm/i915: Initialize all contexts
>    
>    which quietly introduced the removal of the MI_RESTORE_INHIBIT on the
>    default context.
>    
>    v2: Mark the global default context as uninitialized on GPU reset so
>    that the context-local workarounds are reloaded upon re-enabling.
>    
>    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>    Cc: Michel Thierry <michel.thierry@intel.com>
>    Cc: Mika Kuoppala <mika.kuoppala@intel.com>
>    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>    Link: http://patchwork.freedesktop.org/patch/msgid/1448630935-27377-1-git-send-email-chris@chris-wilson.co.uk
>    Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
>    Cc: stable@vger.kernel.org
>    [danvet: This seems to fix a gpu hand on after the first resume,
>    resulting in any future suspend operation failing with -EIO because
>    the gpu seems to be in a funky state. Somehow this patch fixes that.]
>    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>    (cherry picked from commit 42f1cae8c079bcceb3cff079fddc3ff8852c788f)
>    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 35a317f44dbf18460282a9c4d0d74480f5c3f7b2
>Author: Helge Deller <deller@gmx.de>
>Date:   Sun Jan 10 09:30:42 2016 +0100
>
>    parisc: Fix __ARCH_SI_PREAMBLE_SIZE
>    
>    [ Upstream commit e60fc5aa608eb38b47ba4ee058f306f739eb70a0 ]
>    
>    On a 64bit kernel build the compiler aligns the _sifields union in the
>    struct siginfo_t on a 64bit address. The __ARCH_SI_PREAMBLE_SIZE define
>    compensates for this alignment and thus fixes the wait testcase of the
>    strace package.
>    
>    The symptoms of a wrong __ARCH_SI_PREAMBLE_SIZE value is that
>    _sigchld.si_stime variable is missed to be copied and thus after a
>    copy_siginfo() will have uninitialized values.
>    
>    Signed-off-by: Helge Deller <deller@gmx.de>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c1a7154c7e5d81bba4b027d42ec1f16113992415
>Author: Minchan Kim <minchan@kernel.org>
>Date:   Mon Dec 28 08:35:13 2015 +0900
>
>    virtio_balloon: fix race between migration and ballooning
>    
>    [ Upstream commit 21ea9fb69e7c4b1b1559c3e410943d3ff248ffcb ]
>    
>    In balloon_page_dequeue, pages_lock should cover the loop
>    (ie, list_for_each_entry_safe). Otherwise, the cursor page could
>    be isolated by compaction and then list_del by isolation could
>    poison the page->lru.{prev,next} so the loop finally could
>    access wrong address like this. This patch fixes the bug.
>    
>    general protection fault: 0000 [#1] SMP
>    Dumping ftrace buffer:
>       (ftrace buffer empty)
>    Modules linked in:
>    CPU: 2 PID: 82 Comm: vballoon Not tainted 4.4.0-rc5-mm1-access_bit+ #1906
>    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>    task: ffff8800a7ff0000 ti: ffff8800a7fec000 task.ti: ffff8800a7fec000
>    RIP: 0010:[<ffffffff8115e754>]  [<ffffffff8115e754>] balloon_page_dequeue+0x54/0x130
>    RSP: 0018:ffff8800a7fefdc0  EFLAGS: 00010246
>    RAX: ffff88013fff9a70 RBX: ffffea000056fe00 RCX: 0000000000002b7d
>    RDX: ffff88013fff9a70 RSI: ffffea000056fe00 RDI: ffff88013fff9a68
>    RBP: ffff8800a7fefde8 R08: ffffea000056fda0 R09: 0000000000000000
>    R10: ffff8800a7fefd90 R11: 0000000000000001 R12: dead0000000000e0
>    R13: ffffea000056fe20 R14: ffff880138809070 R15: ffff880138809060
>    FS:  0000000000000000(0000) GS:ffff88013fc40000(0000) knlGS:0000000000000000
>    CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>    CR2: 00007f229c10e000 CR3: 00000000b8b53000 CR4: 00000000000006a0
>    Stack:
>     0000000000000100 ffff880138809088 ffff880138809000 ffff880138809060
>     0000000000000046 ffff8800a7fefe28 ffffffff812c86d3 ffff880138809020
>     ffff880138809000 fffffffffff91900 0000000000000100 ffff880138809060
>    Call Trace:
>     [<ffffffff812c86d3>] leak_balloon+0x93/0x1a0
>     [<ffffffff812c8bc7>] balloon+0x217/0x2a0
>     [<ffffffff8143739e>] ? __schedule+0x31e/0x8b0
>     [<ffffffff81078160>] ? abort_exclusive_wait+0xb0/0xb0
>     [<ffffffff812c89b0>] ? update_balloon_stats+0xf0/0xf0
>     [<ffffffff8105b6e9>] kthread+0xc9/0xe0
>     [<ffffffff8105b620>] ? kthread_park+0x60/0x60
>     [<ffffffff8143b4af>] ret_from_fork+0x3f/0x70
>     [<ffffffff8105b620>] ? kthread_park+0x60/0x60
>    Code: 8d 60 e0 0f 84 af 00 00 00 48 8b 43 20 a8 01 75 3b 48 89 d8 f0 0f ba 28 00 72 10 48 8b 03 f6 c4 08 75 2f 48 89 df e8 8c 83 f9 ff <49> 8b 44 24 20 4d 8d 6c 24 20 48 83 e8 20 4d 39 f5 74 7a 4c 89
>    RIP  [<ffffffff8115e754>] balloon_page_dequeue+0x54/0x130
>     RSP <ffff8800a7fefdc0>
>    ---[ end trace 43cf28060d708d5f ]---
>    Kernel panic - not syncing: Fatal exception
>    Dumping ftrace buffer:
>       (ftrace buffer empty)
>    Kernel Offset: disabled
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Minchan Kim <minchan@kernel.org>
>    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>    Acked-by: Rafael Aquini <aquini@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3bbe9868ba5654df63f9e10766620f813e92fdf8
>Author: Minchan Kim <minchan@kernel.org>
>Date:   Mon Dec 28 08:35:12 2015 +0900
>
>    virtio_balloon: fix race by fill and leak
>    
>    [ Upstream commit f68b992bbb474641881932c61c92dcfa6f5b3689 ]
>    
>    During my compaction-related stuff, I encountered a bug
>    with ballooning.
>    
>    With repeated inflating and deflating cycle, guest memory(
>    ie, cat /proc/meminfo | grep MemTotal) is decreased and
>    couldn't be recovered.
>    
>    The reason is balloon_lock doesn't cover release_pages_balloon
>    so struct virtio_balloon fields could be overwritten by race
>    of fill_balloon(e,g, vb->*pfns could be critical).
>    
>    This patch fixes it in my test.
>    
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Minchan Kim <minchan@kernel.org>
>    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 7daaedba8fa87ade25763e15e5218c66558634c3
>Author: Denis V. Lunev <den@openvz.org>
>Date:   Thu Aug 20 00:49:48 2015 +0300
>
>    virtio_ballon: change stub of release_pages_by_pfn
>    
>    [ Upstream commit b4d34037329f46ed818d3b0a6e1e23b9c8721f79 ]
>    
>    and rename it to release_pages_balloon. The function originally takes
>    arrays of pfns and now it takes pointer to struct virtio_ballon.
>    This change is necessary to conditionally call adjust_managed_page_count
>    in the next patch.
>    
>    Signed-off-by: Denis V. Lunev <den@openvz.org>
>    CC: Michael S. Tsirkin <mst@redhat.com>
>    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1fc9a4dd398062e9fa4937f446bedd3305312d1d
>Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>Date:   Mon Jan 11 17:35:38 2016 -0800
>
>    Input: elantech - mark protocols v2 and v3 as semi-mt
>    
>    [ Upstream commit 6544a1df11c48c8413071aac3316792e4678fbfb ]
>    
>    When using a protocol v2 or v3 hardware, elantech uses the function
>    elantech_report_semi_mt_data() to report data. This devices are rather
>    creepy because if num_finger is 3, (x2,y2) is (0,0). Yes, only one valid
>    touch is reported.
>    
>    Anyway, userspace (libinput) is now confused by these (0,0) touches,
>    and detect them as palm, and rejects them.
>    
>    Commit 3c0213d17a09 ("Input: elantech - fix semi-mt protocol for v3 HW")
>    was sufficient enough for xf86-input-synaptics and libinput before it has
>    palm rejection. Now we need to actually tell libinput that this device is
>    a semi-mt one and it should not rely on the actual values of the 2 touches.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 27853751e20c1d4c3d060210d38cc0b63ac0c991
>Author: Roman Volkov <rvolkov@v1ros.org>
>Date:   Fri Jan 1 16:24:41 2016 +0300
>
>    clocksource/drivers/vt8500: Increase the minimum delta
>    
>    [ Upstream commit f9eccf24615672896dc13251410c3f2f33a14f95 ]
>    
>    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: stable@vger.kernel.org
>    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: Sasha Levin <sasha.levin@oracle.com>
>
>commit e52b0623ee970dfa58d4af089329e193e59be918
>Author: Dave Chinner <dchinner@redhat.com>
>Date:   Tue Jan 12 07:04:01 2016 +1100
>
>    xfs: handle dquot buffer readahead in log recovery correctly
>    
>    [ Upstream commit 7d6a13f023567d573ac362502bb702eda716e654 ]
>    
>    When we do dquot readahead in log recovery, we do not use a verifier
>    as the underlying buffer may not have dquots in it. e.g. the
>    allocation operation hasn't yet been replayed. Hence we do not want
>    to fail recovery because we detect an operation to be replayed has
>    not been run yet. This problem was addressed for inodes in commit
>    d891400 ("xfs: inode buffers may not be valid during recovery
>    readahead") but the problem was not recognised to exist for dquots
>    and their buffers as the dquot readahead did not have a verifier.
>    
>    The result of not using a verifier is that when the buffer is then
>    next read to replay a dquot modification, the dquot buffer verifier
>    will only be attached to the buffer if *readahead is not complete*.
>    Hence we can read the buffer, replay the dquot changes and then add
>    it to the delwri submission list without it having a verifier
>    attached to it. This then generates warnings in xfs_buf_ioapply(),
>    which catches and warns about this case.
>    
>    Fix this and make it handle the same readahead verifier error cases
>    as for inode buffers by adding a new readahead verifier that has a
>    write operation as well as a read operation that marks the buffer as
>    not done if any corruption is detected.  Also make sure we don't run
>    readahead if the dquot buffer has been marked as cancelled by
>    recovery.
>    
>    This will result in readahead either succeeding and the buffer
>    having a valid write verifier, or readahead failing and the buffer
>    state requiring the subsequent read to resubmit the IO with the new
>    verifier.  In either case, this will result in the buffer always
>    ending up with a valid write verifier on it.
>    
>    Note: we also need to fix the inode buffer readahead error handling
>    to mark the buffer with EIO. Brian noticed the code I copied from
>    there wrong during review, so fix it at the same time. Add comments
>    linking the two functions that handle readahead verifier errors
>    together so we don't forget this behavioural link in future.
>    
>    cc: <stable@vger.kernel.org> # 3.12 - current
>    Signed-off-by: Dave Chinner <dchinner@redhat.com>
>    Reviewed-by: Brian Foster <bfoster@redhat.com>
>    Signed-off-by: Dave Chinner <david@fromorbit.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 848235ac48d900d7c5e9c6cfb190d290cdb87a62
>Author: Dave Chinner <dchinner@redhat.com>
>Date:   Tue Jan 12 07:03:44 2016 +1100
>
>    xfs: inode recovery readahead can race with inode buffer creation
>    
>    [ Upstream commit b79f4a1c68bb99152d0785ee4ea3ab4396cdacc6 ]
>    
>    When we do inode readahead in log recovery, we do can do the
>    readahead before we've replayed the icreate transaction that stamps
>    the buffer with inode cores. The inode readahead verifier catches
>    this and marks the buffer as !done to indicate that it doesn't yet
>    contain valid inodes.
>    
>    In adding buffer error notification  (i.e. setting b_error = -EIO at
>    the same time as as we clear the done flag) to such a readahead
>    verifier failure, we can then get subsequent inode recovery failing
>    with this error:
>    
>    XFS (dm-0): metadata I/O error: block 0xa00060 ("xlog_recover_do..(read#2)") error 5 numblks 32
>    
>    This occurs when readahead completion races with icreate item replay
>    such as:
>    
>    	inode readahead
>    		find buffer
>    		lock buffer
>    		submit RA io
>    	....
>    	icreate recovery
>    	    xfs_trans_get_buffer
>    		find buffer
>    		lock buffer
>    		<blocks on RA completion>
>    	.....
>    	<ra completion>
>    		fails verifier
>    		clear XBF_DONE
>    		set bp->b_error = -EIO
>    		release and unlock buffer
>    	<icreate gains lock>
>    	icreate initialises buffer
>    	marks buffer as done
>    	adds buffer to delayed write queue
>    	releases buffer
>    
>    At this point, we have an initialised inode buffer that is up to
>    date but has an -EIO state registered against it. When we finally
>    get to recovering an inode in that buffer:
>    
>    	inode item recovery
>    	    xfs_trans_read_buffer
>    		find buffer
>    		lock buffer
>    		sees XBF_DONE is set, returns buffer
>    	    sees bp->b_error is set
>    		fail log recovery!
>    
>    Essentially, we need xfs_trans_get_buf_map() to clear the error status of
>    the buffer when doing a lookup. This function returns uninitialised
>    buffers, so the buffer returned can not be in an error state and
>    none of the code that uses this function expects b_error to be set
>    on return. Indeed, there is an ASSERT(!bp->b_error); in the
>    transaction case in xfs_trans_get_buf_map() that would have caught
>    this if log recovery used transactions....
>    
>    This patch firstly changes the inode readahead failure to set -EIO
>    on the buffer, and secondly changes xfs_buf_get_map() to never
>    return a buffer with an error state set so this first change doesn't
>    cause unexpected log recovery failures.
>    
>    cc: <stable@vger.kernel.org> # 3.12 - current
>    Signed-off-by: Dave Chinner <dchinner@redhat.com>
>    Reviewed-by: Brian Foster <bfoster@redhat.com>
>    Signed-off-by: Dave Chinner <david@fromorbit.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2826e0944f3c7a673da95fd226c8a752254c3e6a
>Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>Date:   Fri Jan 1 13:39:22 2016 +0100
>
>    s390: fix normalization bug in exception table sorting
>    
>    [ Upstream commit bcb7825a77f41c7dd91da6f7ac10b928156a322e ]
>    
>    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>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
>    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ccafc9df447a3de7b5b88d246404d97f70f80d6f
>Author: Ben Skeggs <bskeggs@redhat.com>
>Date:   Fri Jan 8 08:56:51 2016 +1000
>
>    drm/nouveau/kms: take mode_config mutex in connector hotplug path
>    
>    [ Upstream commit 0a882cadbc63fd2da3994af7115b4ada2fcbd638 ]
>    
>    fdo#93634
>    
>    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 498b346868790663ef443951bb06a30a57b64b32
>Author: Vegard Nossum <vegard.nossum@oracle.com>
>Date:   Fri Dec 18 21:28:53 2015 +0100
>
>    uml: flush stdout before forking
>    
>    [ Upstream commit 0754fb298f2f2719f0393491d010d46cfb25d043 ]
>    
>    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.
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
>    Signed-off-by: Richard Weinberger <richard@nod.at>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4e623240d3054ca29fbb294d15a24b2ed971a413
>Author: Vegard Nossum <vegard.nossum@oracle.com>
>Date:   Wed Dec 16 21:59:56 2015 +0100
>
>    uml: fix hostfs mknod()
>    
>    [ Upstream commit 9f2dfda2f2f1c6181c3732c16b85c59ab2d195e0 ]
>    
>    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>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Richard Weinberger <richard@nod.at>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 27f8627c3a656409f8594e3d976d03ab445d7fcc
>Author: Mikulas Patocka <mpatocka@redhat.com>
>Date:   Fri Jan 8 19:07:55 2016 -0500
>
>    dm snapshot: fix hung bios when copy error occurs
>    
>    [ Upstream commit 385277bfb57faac44e92497104ba542cdd82d5fe ]
>    
>    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>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9d8246cd71ec50f8aa57c1ea74d8aff314908043
>Author: Mike Christie <mchristi@redhat.com>
>Date:   Thu Jan 7 16:34:05 2016 -0600
>
>    scsi: add Synology to 1024 sector blacklist
>    
>    [ Upstream commit 9055082fb100cc66e20c048251d05159f5f2cfba ]
>    
>    Another iscsi target that cannot handle large IOs, but does not tell us
>    a limit.
>    
>    The Synology iSCSI targets report:
>    
>    Block limits VPD page (SBC):
>      Write same no zero (WSNZ): 0
>      Maximum compare and write length: 0 blocks
>      Optimal transfer length granularity: 0 blocks
>      Maximum transfer length: 0 blocks
>      Optimal transfer length: 0 blocks
>      Maximum prefetch length: 0 blocks
>      Maximum unmap LBA count: 0
>      Maximum unmap block descriptor count: 0
>      Optimal unmap granularity: 0
>      Unmap granularity alignment valid: 0
>      Unmap granularity alignment: 0
>      Maximum write same length: 0x0 blocks
>    
>    and the size of the command it can handle seems to depend on how much
>    memory it can allocate at the time. This results in IO errors when
>    handling large IOs. This patch just has us use the old 1024 default
>    sectors for this target by adding it to the scsi blacklist. We do not
>    have good contacs with this vendors, so I have not been able to try and
>    fix on their side.
>    
>    I have posted this a long while back, but it was not merged. This
>    version just fixes it up for merge/patch failures in the original
>    version.
>    
>    Reported-by: Ancoron Luciferis <ancoron.luciferis@googlemail.com>
>    Reported-by: Michael Meyers <steltek@tcnnet.com>
>    Signed-off-by: Mike Christie <mchristi@redhat.com>
>    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
>    Cc: <stable@vger.kernel.org> # 4.1+
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2e21928b854d0201e5af8413daaa8dfe1b32690d
>Author: Jeff Layton <jeff.layton@primarydata.com>
>Date:   Thu Jan 7 16:38:10 2016 -0500
>
>    locks: fix unlock when fcntl_setlk races with a close
>    
>    [ Upstream commit 7f3697e24dc3820b10f445a4a7d914fc356012d1 ]
>    
>    Dmitry reported that he was able to reproduce the WARN_ON_ONCE that
>    fires in locks_free_lock_context when the flc_posix list isn't empty.
>    
>    The problem turns out to be that we're basically rebuilding the
>    file_lock from scratch in fcntl_setlk when we discover that the setlk
>    has raced with a close. If the l_whence field is SEEK_CUR or SEEK_END,
>    then we may end up with fl_start and fl_end values that differ from
>    when the lock was initially set, if the file position or length of the
>    file has changed in the interim.
>    
>    Fix this by just reusing the same lock request structure, and simply
>    override fl_type value with F_UNLCK as appropriate. That ensures that
>    we really are unlocking the lock that was initially set.
>    
>    While we're there, make sure that we do pop a WARN_ON_ONCE if the
>    removal ever fails. Also return -EBADF in this event, since that's
>    what we would have returned if the close had happened earlier.
>    
>    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
>    Cc: <stable@vger.kernel.org>
>    Fixes: c293621bbf67 (stale POSIX lock handling)
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
>    Acked-by: "J. Bruce Fields" <bfields@fieldses.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d9d42b679e3653759b107ff99daf8da9c21aaec7
>Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
>Date:   Tue Jan 5 15:25:43 2016 +0200
>
>    iwlwifi: pcie: properly configure the debug buffer size for 8000
>    
>    [ Upstream commit 62d7476d958ce06d7a10b02bdb30006870286fe2 ]
>    
>    8000 device family has a new debug engine that needs to be
>    configured differently than 7000's.
>    The debug engine's DMA works in chunks of memory and the
>    size of the buffer really means the start of the last
>    chunk. Since one chunk is 256-byte long, we should
>    configure the device to write to buffer_size - 256.
>    This fixes a situation were the device would write to
>    memory it is not allowed to access.
>    
>    CC: <stable@vger.kernel.org> [4.1+]
>    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 01999150f50e945ee85914c37a1337784c1993c8
>Author: Sasha Levin <sasha.levin@oracle.com>
>Date:   Mon Feb 1 15:02:44 2016 -0500
>
>    iwlwifi: update and fix 7265 series PCI IDs
>    
>    [ Upstream commit 006bda75d81fd27a583a3b310e9444fea2aa6ef2 ]
>    
>    Update and fix some 7265 PCI IDs entries.
>    
>    CC: <stable@vger.kernel.org> [3.13+]
>    Signed-off-by: Oren Givon <oren.givon@intel.com>
>    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1ecdadef5db6404bb57c9f369c0f026e1e9ac638
>Author: David Sterba <dsterba@suse.com>
>Date:   Mon Nov 30 17:27:06 2015 +0100
>
>    btrfs: handle invalid num_stripes in sys_array
>    
>    [ Upstream commit f5cdedd73fa71b74dcc42f2a11a5735d89ce7c4f ]
>    
>    We can handle the special case of num_stripes == 0 directly inside
>    btrfs_read_sys_array. The BUG_ON in btrfs_chunk_item_size is there to
>    catch other unhandled cases where we fail to validate external data.
>    
>    A crafted or corrupted image crashes at mount time:
>    
>    BTRFS: device fsid 9006933e-2a9a-44f0-917f-514252aeec2c devid 1 transid 7 /dev/loop0
>    BTRFS info (device loop0): disk space caching is enabled
>    BUG: failure at fs/btrfs/ctree.h:337/btrfs_chunk_item_size()!
>    Kernel panic - not syncing: BUG!
>    CPU: 0 PID: 313 Comm: mount Not tainted 4.2.5-00657-ge047887-dirty #25
>    Stack:
>     637af890 60062489 602aeb2e 604192ba
>     60387961 00000011 637af8a0 6038a835
>     637af9c0 6038776b 634ef32b 00000000
>    Call Trace:
>     [<6001c86d>] show_stack+0xfe/0x15b
>     [<6038a835>] dump_stack+0x2a/0x2c
>     [<6038776b>] panic+0x13e/0x2b3
>     [<6020f099>] btrfs_read_sys_array+0x25d/0x2ff
>     [<601cfbbe>] open_ctree+0x192d/0x27af
>     [<6019c2c1>] btrfs_mount+0x8f5/0xb9a
>     [<600bc9a7>] mount_fs+0x11/0xf3
>     [<600d5167>] vfs_kern_mount+0x75/0x11a
>     [<6019bcb0>] btrfs_mount+0x2e4/0xb9a
>     [<600bc9a7>] mount_fs+0x11/0xf3
>     [<600d5167>] vfs_kern_mount+0x75/0x11a
>     [<600d710b>] do_mount+0xa35/0xbc9
>     [<600d7557>] SyS_mount+0x95/0xc8
>     [<6001e884>] handle_syscall+0x6b/0x8e
>    
>    Reported-by: Jiri Slaby <jslaby@suse.com>
>    Reported-by: Vegard Nossum <vegard.nossum@oracle.com>
>    CC: stable@vger.kernel.org	# 3.19+
>    Signed-off-by: David Sterba <dsterba@suse.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 16870da043de536d1e4b866b594c60f0475f6739
>Author: Grygorii Strashko <grygorii.strashko@ti.com>
>Date:   Thu Dec 10 21:18:20 2015 +0200
>
>    PCI: host: Mark PCIe/PCI (MSI) IRQ cascade handlers as IRQF_NO_THREAD
>    
>    [ Upstream commit 8ff0ef996ca00028519c70e8d51d32bd37eb51dc ]
>    
>    On -RT and if kernel is booting with "threadirqs" cmd line parameter,
>    PCIe/PCI (MSI) IRQ cascade handlers (like dra7xx_pcie_msi_irq_handler())
>    will be forced threaded and, as result, will generate warnings like this:
>    
>      WARNING: CPU: 1 PID: 82 at kernel/irq/handle.c:150 handle_irq_event_percpu+0x14c/0x174()
>      irq 460 handler irq_default_primary_handler+0x0/0x14 enabled interrupts
>      Backtrace:
>       (warn_slowpath_common) from (warn_slowpath_fmt+0x38/0x40)
>       (warn_slowpath_fmt) from (handle_irq_event_percpu+0x14c/0x174)
>       (handle_irq_event_percpu) from (handle_irq_event+0x84/0xb8)
>       (handle_irq_event) from (handle_simple_irq+0x90/0x118)
>       (handle_simple_irq) from (generic_handle_irq+0x30/0x44)
>       (generic_handle_irq) from (dra7xx_pcie_msi_irq_handler+0x7c/0x8c)
>       (dra7xx_pcie_msi_irq_handler) from (irq_forced_thread_fn+0x28/0x5c)
>       (irq_forced_thread_fn) from (irq_thread+0x128/0x204)
>    
>    This happens because all of them invoke generic_handle_irq() from the
>    requested handler.  generic_handle_irq() grabs raw_locks and thus needs to
>    run in raw-IRQ context.
>    
>    This issue was originally reproduced on TI dra7-evem, but, as was
>    identified during discussion [1], other hosts can also suffer from this
>    issue.  Fix all them at once by marking PCIe/PCI (MSI) IRQ cascade handlers
>    IRQF_NO_THREAD explicitly.
>    
>    [1] http://lkml.kernel.org/r/1448027966-21610-1-git-send-email-grygorii.strashko@ti.com
>    
>    [bhelgaas: add stable tag, fix typos]
>    Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>    Acked-by: Lucas Stach <l.stach@pengutronix.de> (for imx6)
>    CC: stable@vger.kernel.org
>    CC: Kishon Vijay Abraham I <kishon@ti.com>
>    CC: Jingoo Han <jingoohan1@gmail.com>
>    CC: Kukjin Kim <kgene@kernel.org>
>    CC: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>    CC: Richard Zhu <Richard.Zhu@freescale.com>
>    CC: Thierry Reding <thierry.reding@gmail.com>
>    CC: Stephen Warren <swarren@wwwdotorg.org>
>    CC: Alexandre Courbot <gnurou@gmail.com>
>    CC: Simon Horman <horms@verge.net.au>
>    CC: Pratyush Anand <pratyush.anand@gmail.com>
>    CC: Michal Simek <michal.simek@xilinx.com>
>    CC: "SÃ¶ren Brinkmann" <soren.brinkmann@xilinx.com>
>    CC: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 24ab3b8e796248bfbdb8a80469b9811b5df39caa
>Author: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
>Date:   Wed Dec 23 16:51:57 2015 +0100
>
>    PCI: Fix minimum allocation address overwrite
>    
>    [ Upstream commit 3460baa620685c20f5ee19afb6d99d26150c382c ]
>    
>    Commit 36e097a8a297 ("PCI: Split out bridge window override of minimum
>    allocation address") claimed to do no functional changes but unfortunately
>    did: The "min" variable is altered.  At least the AVM A1 PCMCIA adapter was
>    no longer detected, breaking ISDN operation.
>    
>    Use a local copy of "min" to restore the previous behaviour.
>    
>    [bhelgaas: avoid gcc "?:" extension for portability and readability]
>    Fixes: 36e097a8a297 ("PCI: Split out bridge window override of minimum allocation address")
>    Signed-off-by: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
>    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>    CC: stable@vger.kernel.org      # v3.14+
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 67d0df37bf4235bc3aa1866571e74437cba33199
>Author: Mykola Lysenko <Mykola.Lysenko@amd.com>
>Date:   Fri Dec 25 16:14:48 2015 +0800
>
>    drm/dp/mst: fix in RAD element access
>    
>    [ Upstream commit 7a11a334aa6af4c65c6a0d81b60c97fc18673532 ]
>    
>    This is needed to receive correct port
>    number from RAD, so MSTB could be found
>    
>    Acked-by: Dave Airlie <airlied@gmail.com>
>    Signed-off-by: Mykola Lysenko <Mykola.Lysenko@amd.com>
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8605e8573eae0457d6d3a1826ba3253e56c3d644
>Author: Mykola Lysenko <Mykola.Lysenko@amd.com>
>Date:   Fri Dec 25 16:14:47 2015 +0800
>
>    drm/dp/mst: fix in MSTB RAD initialization
>    
>    [ Upstream commit 75af4c8c4c0f60d7ad135419805798f144e9baf9 ]
>    
>    This fix is needed to support more then two
>    branch displays, so RAD address consist at
>    least of 2 elements
>    
>    Acked-by: Dave Airlie <airlied@gmail.com>
>    Signed-off-by: Mykola Lysenko <Mykola.Lysenko@amd.com>
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1d1e2c4f98c1673ae2c99ab6f133d2a1d3fa0b9e
>Author: Mykola Lysenko <Mykola.Lysenko@amd.com>
>Date:   Fri Dec 18 17:14:43 2015 -0500
>
>    drm/dp/mst: always send reply for UP request
>    
>    [ Upstream commit 1f16ee7fa13649f4e55aa48ad31c3eb0722a62d3 ]
>    
>    We should always send reply for UP request in order
>    to make downstream device clean-up resources appropriately.
>    
>    Issue was that reply for UP request was sent only once.
>    
>    Acked-by: Dave Airlie <airlied@gmail.com>
>    Signed-off-by: Mykola Lysenko <Mykola.Lysenko@amd.com>
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e76bda944f6f601dd7bf2a26b34803a30d4503e3
>Author: Mykola Lysenko <Mykola.Lysenko@amd.com>
>Date:   Fri Dec 18 17:14:42 2015 -0500
>
>    drm/dp/mst: process broadcast messages correctly
>    
>    [ Upstream commit bd9343208704fcc70a5b919f228a7d26ae472727 ]
>    
>    In case broadcast message received in UP request,
>    RAD cannot be used to identify message originator.
>    Message should be parsed, originator should be found
>    by GUID from parsed message.
>    
>    Also reply with broadcast in case broadcast message
>    received (for now it is always broadcast)
>    
>    Acked-by: Dave Airlie <airlied@gmail.com>
>    Signed-off-by: Mykola Lysenko <Mykola.Lysenko@amd.com>
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 516a102b0add0610805d0062670b18b1b44ccdda
>Author: Andrew Gabbasov <andrew_gabbasov@mentor.com>
>Date:   Thu Dec 24 10:25:33 2015 -0600
>
>    udf: Check output buffer length when converting name to CS0
>    
>    [ Upstream commit bb00c898ad1ce40c4bb422a8207ae562e9aea7ae ]
>    
>    If a name contains at least some characters with Unicode values
>    exceeding single byte, the CS0 output should have 2 bytes per character.
>    And if other input characters have single byte Unicode values, then
>    the single input byte is converted to 2 output bytes, and the length
>    of output becomes larger than the length of input. And if the input
>    name is long enough, the output length may exceed the allocated buffer
>    length.
>    
>    All this means that conversion from UTF8 or NLS to CS0 requires
>    checking of output length in order to stop when it exceeds the given
>    output buffer size.
>    
>    [JK: Make code return -ENAMETOOLONG instead of silently truncating the
>    name]
>    
>    CC: stable@vger.kernel.org
>    Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
>    Signed-off-by: Jan Kara <jack@suse.cz>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d6341753c418d3699948290d8c0b9d9dc78bd209
>Author: Andrew Gabbasov <andrew_gabbasov@mentor.com>
>Date:   Thu Dec 24 10:25:32 2015 -0600
>
>    udf: Prevent buffer overrun with multi-byte characters
>    
>    [ Upstream commit ad402b265ecf6fa22d04043b41444cdfcdf4f52d ]
>    
>    udf_CS0toUTF8 function stops the conversion when the output buffer
>    length reaches UDF_NAME_LEN-2, which is correct maximum name length,
>    but, when checking, it leaves the space for a single byte only,
>    while multi-bytes output characters can take more space, causing
>    buffer overflow.
>    
>    Similar error exists in udf_CS0toNLS function, that restricts
>    the output length to UDF_NAME_LEN, while actual maximum allowed
>    length is UDF_NAME_LEN-2.
>    
>    In these cases the output can override not only the current buffer
>    length field, causing corruption of the name buffer itself, but also
>    following allocation structures, causing kernel crash.
>    
>    Adjust the output length checks in both functions to prevent buffer
>    overruns in case of multi-bytes UTF8 or NLS characters.
>    
>    CC: stable@vger.kernel.org
>    Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
>    Signed-off-by: Jan Kara <jack@suse.cz>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit eaf7c91b334172cc4ec2871940baee3cc0ebeede
>Author: AurÃ©lien Francillon <aurelien@francillon.net>
>Date:   Sat Jan 2 20:39:54 2016 -0800
>
>    Input: i8042 - add Fujitsu Lifebook U745 to the nomux list
>    
>    [ Upstream commit dd0d0d4de582a6a61c032332c91f4f4cb2bab569 ]
>    
>    Without i8042.nomux=1 the Elantech touch pad is not working at all on
>    a Fujitsu Lifebook U745. This patch does not seem necessary for all
>    U745 (maybe because of different BIOS versions?). However, it was
>    verified that the patch does not break those (see opensuse bug 883192:
>    https://bugzilla.opensuse.org/show_bug.cgi?id=883192).
>    
>    Signed-off-by: AurÃ©lien Francillon <aurelien@francillon.net>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 34ed7459a09569f4b2dd8a549f420fac8c3619e0
>Author: Uri Mashiach <uri.mashiach@compulab.co.il>
>Date:   Thu Dec 24 16:05:00 2015 +0200
>
>    wlcore/wl12xx: spi: fix NULL pointer dereference (Oops)
>    
>    [ Upstream commit e47301b06d5a65678690f04c2248fd181db1e59a ]
>    
>    Fix the below Oops when trying to modprobe wlcore_spi.
>    The oops occurs because the wl1271_power_{off,on}()
>    function doesn't check the power() function pointer.
>    
>    [   23.401447] Unable to handle kernel NULL pointer dereference at
>    virtual address 00000000
>    [   23.409954] pgd = c0004000
>    [   23.412922] [00000000] *pgd=00000000
>    [   23.416693] Internal error: Oops: 80000007 [#1] SMP ARM
>    [   23.422168] Modules linked in: wl12xx wlcore mac80211 cfg80211
>    musb_dsps musb_hdrc usbcore usb_common snd_soc_simple_card evdev joydev
>    omap_rng wlcore_spi snd_soc_tlv320aic23_i2c rng_core snd_soc_tlv320aic23
>    c_can_platform c_can can_dev snd_soc_davinci_mcasp snd_soc_edma
>    snd_soc_omap omap_wdt musb_am335x cpufreq_dt thermal_sys hwmon
>    [   23.453253] CPU: 0 PID: 36 Comm: kworker/0:2 Not tainted
>    4.2.0-00002-g951efee-dirty #233
>    [   23.461720] Hardware name: Generic AM33XX (Flattened Device Tree)
>    [   23.468123] Workqueue: events request_firmware_work_func
>    [   23.473690] task: de32efc0 ti: de4ee000 task.ti: de4ee000
>    [   23.479341] PC is at 0x0
>    [   23.482112] LR is at wl12xx_set_power_on+0x28/0x124 [wlcore]
>    [   23.488074] pc : [<00000000>]    lr : [<bf2581f0>]    psr: 60000013
>    [   23.488074] sp : de4efe50  ip : 00000002  fp : 00000000
>    [   23.500162] r10: de7cdd00  r9 : dc848800  r8 : bf27af00
>    [   23.505663] r7 : bf27a1a8  r6 : dcbd8a80  r5 : dce0e2e0  r4 :
>    dce0d2e0
>    [   23.512536] r3 : 00000000  r2 : 00000000  r1 : 00000001  r0 :
>    dc848810
>    [   23.519412] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
>    Segment kernel
>    [   23.527109] Control: 10c5387d  Table: 9cb78019  DAC: 00000015
>    [   23.533160] Process kworker/0:2 (pid: 36, stack limit = 0xde4ee218)
>    [   23.539760] Stack: (0xde4efe50 to 0xde4f0000)
>    
>    [...]
>    
>    [   23.665030] [<bf2581f0>] (wl12xx_set_power_on [wlcore]) from
>    [<bf25f7ac>] (wlcore_nvs_cb+0x118/0xa4c [wlcore])
>    [   23.675604] [<bf25f7ac>] (wlcore_nvs_cb [wlcore]) from [<c04387ec>]
>    (request_firmware_work_func+0x30/0x58)
>    [   23.685784] [<c04387ec>] (request_firmware_work_func) from
>    [<c0058e2c>] (process_one_work+0x1b4/0x4b4)
>    [   23.695591] [<c0058e2c>] (process_one_work) from [<c0059168>]
>    (worker_thread+0x3c/0x4a4)
>    [   23.704124] [<c0059168>] (worker_thread) from [<c005ee68>]
>    (kthread+0xd4/0xf0)
>    [   23.711747] [<c005ee68>] (kthread) from [<c000f598>]
>    (ret_from_fork+0x14/0x3c)
>    [   23.719357] Code: bad PC value
>    [   23.722760] ---[ end trace 981be8510db9b3a9 ]---
>    
>    Prevent oops by validationg power() pointer value before
>    calling the function.
>    
>    Signed-off-by: Uri Mashiach <uri.mashiach@compulab.co.il>
>    Cc: stable@vger.kernel.org
>    Acked-by: Igor Grinberg <grinberg@compulab.co.il>
>    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ebd138117e5be089d0e10fea7cb308e8345ed643
>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
>    
>    [ Upstream commit 627ccd20b4ad3ba836472468208e2ac4dfadbf03 ]
>    
>    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>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Jens Axboe <axboe@fb.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ad148665b58dcd0a4336188ce4a2194d7f353c5f
>Author: Stefan Bader <stefan.bader@canonical.com>
>Date:   Sun Nov 29 18:44:49 2015 -0800
>
>    bcache: prevent crash on changing writeback_running
>    
>    [ Upstream commit 8d16ce540c94c9d366eb36fc91b7154d92d6397b ]
>    
>    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>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Jens Axboe <axboe@fb.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit d5402134c27d66e83295ae2961772b89bc6a50bc
>Author: Gabriel de Perthuis <g2p.code@gmail.com>
>Date:   Sun Nov 29 18:40:23 2015 -0800
>
>    bcache: allows use of register in udev to avoid "device_busy" error.
>    
>    [ Upstream commit d7076f21629f8f329bca4a44dc408d94670f49e2 ]
>    
>    Allows to use register, not register_quiet in udev to avoid "device_busy" error.
>    The initial patch proposed at https://lkml.org/lkml/2013/8/26/549 by Gabriel de Perthuis
>    <g2p.code@gmail.com> does not unlock the mutex and hangs the kernel.
>    
>    See http://thread.gmane.org/gmane.linux.kernel.bcache.devel/2594 for the discussion.
>    
>    Cc: Denis Bychkov <manover@gmail.com>
>    Cc: Kent Overstreet <kent.overstreet@gmail.com>
>    Cc: Eric Wheeler <bcache@linux.ewheeler.net>
>    Cc: Gabriel de Perthuis <g2p.code@gmail.com>
>    Cc: stable@vger.kernel.org
>    
>    Signed-off-by: Jens Axboe <axboe@fb.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 322d0128f1e4af6b5b3532e0848fae633fd5a992
>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
>    
>    [ Upstream commit 2ecf0cdb2b437402110ab57546e02abfa68a716b ]
>    
>    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>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Jens Axboe <axboe@fb.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 888841b4a1fc60d064919dde3da80102f8dbe53c
>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()
>    
>    [ Upstream commit 4d4d8573a8451acc9f01cbea24b7e55f04a252fe ]
>    
>    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>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Jens Axboe <axboe@fb.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 14dca8988999b6ccf4126cf6a3455e5822777a8f
>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
>    
>    [ Upstream commit fecaee6f20ee122ad75402c53d8278f9bb142ddc ]
>    
>    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>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Jens Axboe <axboe@fb.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 08656518aa2812e8650b8036201bd9e5463f22a8
>Author: Kent Overstreet <kmo@daterainc.com>
>Date:   Sun Nov 29 17:18:33 2015 -0800
>
>    bcache: Add a cond_resched() call to gc
>    
>    [ Upstream commit c5f1e5adf956e3ba82d204c7c141a75da9fa449a ]
>    
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Tested-by: Eric Wheeler <bcache@linux.ewheeler.net>
>    Cc: Kent Overstreet <kmo@daterainc.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Jens Axboe <axboe@fb.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c505638900d191ae10d1f8afdc8d09ca8c2de0d4
>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
>    
>    [ Upstream commit 2ef9ccbfcb90cf84bdba320a571b18b05c41101b ]
>    
>    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>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Jens Axboe <axboe@fb.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e96bbdf82d1943c73af99d1a4e2ea9d140144983
>Author: Larry Finger <Larry.Finger@lwfinger.net>
>Date:   Mon Dec 21 17:05:08 2015 -0600
>
>    rtlwifi: rtl_pci: Fix kernel panic
>    
>    [ Upstream commit f99551a2d39dc26ea03dc6761be11ac913eb2d57 ]
>    
>    In commit 38506ecefab9 (rtlwifi: rtl_pci: Start modification for new
>    drivers), a bug was introduced that causes a NULL pointer dereference.
>    As this bug only affects the infrequently used RTL8192EE and only under
>    low-memory conditions, it has taken a long time for the bug to show up.
>    
>    The bug was reported on the linux-wireless mailing list and also at
>    https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/ as
>    bug #1527603 (kernel crashes due to rtl8192ee driver on ubuntu 15.10).
>    
>    Fixes: 38506ecefab9 ("rtlwifi: rtl_pci: Start modification for new drivers")
>    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>    Cc: Stable <stable@vger.kernel.org>
>    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 8572f2fa313c47750609178b20caf0598fd1042a
>Author: Trond Myklebust <trond.myklebust@primarydata.com>
>Date:   Tue Dec 29 18:55:19 2015 -0500
>
>    NFS: Fix attribute cache revalidation
>    
>    [ Upstream commit ade14a7df796d4e86bd9d181193c883a57b13db0 ]
>    
>    If a NFSv4 client uses the cache_consistency_bitmask in order to
>    request only information about the change attribute, timestamps and
>    size, then it has not revalidated all attributes, and hence the
>    attribute timeout timestamp should not be updated.
>    
>    Reported-by: Donald Buczek <buczek@molgen.mpg.de>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 226864aff728a7253570e8dd3073ee6dc588d1de
>Author: Trond Myklebust <trond.myklebust@primarydata.com>
>Date:   Sun Jul 5 11:12:07 2015 -0400
>
>    NFS: Remove the "NFS_CAP_CHANGE_ATTR" capability
>    
>    [ Upstream commit cd812599796f500b042f5464b6665755eca21137 ]
>    
>    Setting the change attribute has been mandatory for all NFS versions, since
>    commit 3a1556e8662c ("NFSv2/v3: Simulate the change attribute"). We should
>    therefore not have anything be conditional on it being set/unset.
>    
>    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit de944618d562173faaf27a853acb37ee85825682
>Author: Larry Finger <Larry.Finger@lwfinger.net>
>Date:   Mon Dec 14 16:34:38 2015 -0600
>
>    rtlwifi: rtl8192cu: Add missing parameter setup
>    
>    [ Upstream commit b68d0ae7e58624c33f2eddab471fee55db27dbf9 ]
>    
>    This driver fails to copy the module parameter for software encryption
>    to the locations used by the main code.
>    
>    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>    Cc: Stable <stable@vger.kernel.org>
>    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 0375ae541a81271fba5adf2b05adff1945cf3251
>Author: Larry Finger <Larry.Finger@lwfinger.net>
>Date:   Mon Dec 14 16:34:37 2015 -0600
>
>    rtlwifi: rtl8192ce: Fix handling of module parameters
>    
>    [ Upstream commit b24f19f16b9e43f54218c07609b783ea8625406a ]
>    
>    The module parameter for software encryption was never transferred to
>    the location used by the driver.
>    
>    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>    Cc: Stable <stable@vger.kernel.org>
>    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 214e5cc67f9f5636b3272410f9ad0c151dafa0ac
>Author: Larry Finger <Larry.Finger@lwfinger.net>
>Date:   Mon Dec 14 16:34:36 2015 -0600
>
>    rtlwifi: rtl8192se: Fix module parameter initialization
>    
>    [ Upstream commit 7503efbd82c15c4070adffff1344e5169d3634b4 ]
>    
>    Two of the module parameter descriptions show incorrect default values.
>    In addition the value for software encryption is not transferred to
>    the locations used by the driver.
>    
>    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>    Cc: Stable <stable@vger.kernel.org>
>    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1a37aece44090c945a9b764e413b901863d32e86
>Author: Larry Finger <Larry.Finger@lwfinger.net>
>Date:   Mon Dec 14 16:34:35 2015 -0600
>
>    rtlwifi: rtl8192de: Fix incorrect module parameter descriptions
>    
>    [ Upstream commit d4d60b4caaa5926e1b243070770968f05656107a ]
>    
>    Two of the module parameters are listed with incorrect default values.
>    
>    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>    Cc: Stable <stable@vger.kernel.org>
>    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 07493d2c6685b2e0a243f5dfda8cabbf581994d8
>Author: Larry Finger <Larry.Finger@lwfinger.net>
>Date:   Mon Dec 14 16:34:34 2015 -0600
>
>    rtlwifi: rtl8188ee: Fix module parameter initialization
>    
>    [ Upstream commit 06f34572c6110e2e2d5e653a957f1d74db9e3f2b ]
>    
>    In this driver, parameters disable_watchdog and sw_crypto are never
>    copied into the locations used in the main code. While modifying the
>    parameter handling, the copying of parameter msi_support is moved to
>    be with the rest.
>    
>    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>    Cc: Stable <stable@vger.kernel.org>
>    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 35de29368026457b742115a340cead9bfea9b0bd
>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
>    
>    [ Upstream commit 1b9f23727abb92c5e58f139e7d180befcaa06fe0 ]
>    
>    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
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit bdfc34b6cffea584f49ed9356924674e3e40b7e6
>Author: Chen Yu <yu.c.chen@intel.com>
>Date:   Fri Oct 30 16:32:10 2015 +0800
>
>    Thermal: do thermal zone update after a cooling device registered
>    
>    [ Upstream commit 4511f7166a2deb5f7a578cf87fd2fe1ae83527e3 ]
>    
>    When a new cooling device is registered, we need to update the
>    thermal zone to set the new registered cooling device to a proper
>    state.
>    
>    This fixes a problem that the system is cool, while the fan devices
>    are left running on full speed after boot, if fan device is registered
>    after thermal zone device.
>    
>    Here is the history of why current patch looks like this:
>    https://patchwork.kernel.org/patch/7273041/
>    
>    CC: <stable@vger.kernel.org> #3.18+
>    Reference:https://bugzilla.kernel.org/show_bug.cgi?id=92431
>    Tested-by: Manuel Krause <manuelkrause@netscape.net>
>    Tested-by: szegad <szegadlo@poczta.onet.pl>
>    Tested-by: prash <prash.n.rao@gmail.com>
>    Tested-by: amish <ammdispose-arch@yahoo.com>
>    Reviewed-by: Javi Merino <javi.merino@arm.com>
>    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
>    Signed-off-by: Chen Yu <yu.c.chen@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ab4827691501adf64fc580f7a8cadca0332b84b7
>Author: Zhang Rui <rui.zhang@intel.com>
>Date:   Fri Oct 30 16:31:58 2015 +0800
>
>    Thermal: handle thermal zone device properly during system sleep
>    
>    [ Upstream commit ff140fea847e1c2002a220571ab106c2456ed252 ]
>    
>    Current thermal code does not handle system sleep well because
>    1. the cooling device cooling state may be changed during suspend
>    2. the previous temperature reading becomes invalid after resumed because
>       it is got before system sleep
>    3. updating thermal zone device during suspending/resuming
>       is wrong because some devices may have already been suspended
>       or may have not been resumed.
>    
>    Thus, the proper way to do this is to cancel all thermal zone
>    device update requirements during suspend/resume, and after all
>    the devices have been resumed, reset and update every registered
>    thermal zone devices.
>    
>    This also fixes a regression introduced by:
>    Commit 19593a1fb1f6 ("ACPI / fan: convert to platform driver")
>    Because, with above commit applied, all the fan devices are attached
>    to the acpi_general_pm_domain, and they are turned on by the pm_domain
>    automatically after resume, without the awareness of thermal core.
>    
>    CC: <stable@vger.kernel.org> #3.18+
>    Reference: https://bugzilla.kernel.org/show_bug.cgi?id=78201
>    Reference: https://bugzilla.kernel.org/show_bug.cgi?id=91411
>    Tested-by: Manuel Krause <manuelkrause@netscape.net>
>    Tested-by: szegad <szegadlo@poczta.onet.pl>
>    Tested-by: prash <prash.n.rao@gmail.com>
>    Tested-by: amish <ammdispose-arch@yahoo.com>
>    Tested-by: Matthias <morpheusxyz123@yahoo.de>
>    Reviewed-by: Javi Merino <javi.merino@arm.com>
>    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
>    Signed-off-by: Chen Yu <yu.c.chen@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 247d403072cc86564439a919a4f9c48f46d138cd
>Author: Zhang Rui <rui.zhang@intel.com>
>Date:   Fri Oct 30 16:31:47 2015 +0800
>
>    Thermal: initialize thermal zone device correctly
>    
>    [ Upstream commit bb431ba26c5cd0a17c941ca6c3a195a3a6d5d461 ]
>    
>    After thermal zone device registered, as we have not read any
>    temperature before, thus tz->temperature should not be 0,
>    which actually means 0C, and thermal trend is not available.
>    In this case, we need specially handling for the first
>    thermal_zone_device_update().
>    
>    Both thermal core framework and step_wise governor is
>    enhanced to handle this. And since the step_wise governor
>    is the only one that uses trends, so it's the only thermal
>    governor that needs to be updated.
>    
>    CC: <stable@vger.kernel.org> #3.18+
>    Tested-by: Manuel Krause <manuelkrause@netscape.net>
>    Tested-by: szegad <szegadlo@poczta.onet.pl>
>    Tested-by: prash <prash.n.rao@gmail.com>
>    Tested-by: amish <ammdispose-arch@yahoo.com>
>    Tested-by: Matthias <morpheusxyz123@yahoo.de>
>    Reviewed-by: Javi Merino <javi.merino@arm.com>
>    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
>    Signed-off-by: Chen Yu <yu.c.chen@intel.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 40b7566cb9872529f0b95bd913e16022e1107731
>Author: Andrew Elble <aweits@rit.edu>
>Date:   Wed Dec 2 09:20:57 2015 -0500
>
>    nfs: Fix race in __update_open_stateid()
>    
>    [ Upstream commit 361cad3c89070aeb37560860ea8bfc092d545adc ]
>    
>    We've seen this in a packet capture - I've intermixed what I
>    think was going on. The fix here is to grab the so_lock sooner.
>    
>    1964379 -> #1 open (for write) reply seqid=1
>    1964393 -> #2 open (for read) reply seqid=2
>    
>      __nfs4_close(), state->n_wronly--
>      nfs4_state_set_mode_locked(), changes state->state = [R]
>      state->flags is [RW]
>      state->state is [R], state->n_wronly == 0, state->n_rdonly == 1
>    
>    1964398 -> #3 open (for write) call -> because close is already running
>    1964399 -> downgrade (to read) call seqid=2 (close of #1)
>    1964402 -> #3 open (for write) reply seqid=3
>    
>     __update_open_stateid()
>       nfs_set_open_stateid_locked(), changes state->flags
>       state->flags is [RW]
>       state->state is [R], state->n_wronly == 0, state->n_rdonly == 1
>       new sequence number is exposed now via nfs4_stateid_copy()
>    
>       next step would be update_open_stateflags(), pending so_lock
>    
>    1964403 -> downgrade reply seqid=2, fails with OLD_STATEID (close of #1)
>    
>       nfs4_close_prepare() gets so_lock and recalcs flags -> send close
>    
>    1964405 -> downgrade (to read) call seqid=3 (close of #1 retry)
>    
>       __update_open_stateid() gets so_lock
>     * update_open_stateflags() updates state->n_wronly.
>       nfs4_state_set_mode_locked() updates state->state
>    
>       state->flags is [RW]
>       state->state is [RW], state->n_wronly == 1, state->n_rdonly == 1
>    
>     * should have suppressed the preceding nfs4_close_prepare() from
>       sending open_downgrade
>    
>    1964406 -> write call
>    1964408 -> downgrade (to read) reply seqid=4 (close of #1 retry)
>    
>       nfs_clear_open_stateid_locked()
>       state->flags is [R]
>       state->state is [RW], state->n_wronly == 1, state->n_rdonly == 1
>    
>    1964409 -> write reply (fails, openmode)
>    
>    Signed-off-by: Andrew Elble <aweits@rit.edu>
>    Cc: stable@vger,kernel.org
>    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 33c7c20d62a7916522628fbb45bb65cbc0b9f899
>Author: Chen-Yu Tsai <wens@csie.org>
>Date:   Tue Dec 22 02:27:35 2015 -0200
>
>    [media] rc: sunxi-cir: Initialize the spinlock properly
>    
>    [ Upstream commit 768acf46e1320d6c41ed1b7c4952bab41c1cde79 ]
>    
>    The driver allocates the spinlock but fails to initialize it correctly.
>    The kernel reports a BUG indicating bad spinlock magic when spinlock
>    debugging is enabled.
>    
>    Call spin_lock_init() on it to initialize it correctly.
>    
>    Fixes: b4e3e59fb59c ("[media] rc: add sunxi-ir driver")
>    
>    Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>    Acked-by: Hans de Goede <hdegoede@redhat.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 4476dc677064d27c1fb6ff28a47eeac384e8ba64
>Author: Vegard Nossum <vegard.nossum@oracle.com>
>Date:   Fri Dec 11 15:54:16 2015 +0100
>
>    udf: limit the maximum number of indirect extents in a row
>    
>    [ Upstream commit b0918d9f476a8434b055e362b83fa4fd1d462c3f ]
>    
>    udf_next_aext() just follows extent pointers while extents are marked as
>    indirect. This can loop forever for corrupted filesystem. Limit number
>    the of indirect extents we are willing to follow in a row.
>    
>    [JK: Updated changelog, limit, style]
>    
>    Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
>    Cc: stable@vger.kernel.org
>    Cc: Jan Kara <jack@suse.com>
>    Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
>    Cc: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Jan Kara <jack@suse.cz>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a2da01ce927dd98cb8f1a8f2d2343d2f5827b988
>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()
>    
>    [ Upstream commit 5c671c410c8704800f4f1673b6f572137e7e6ddd ]
>    
>    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>
>    Cc: stable@vger.kernel.org # v3.11+
>    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit b0aed82cdc3204ef04bfb05cab8a7892ed8bd9db
>Author: Adrian Hunter <adrian.hunter@intel.com>
>Date:   Thu Nov 26 14:00:48 2015 +0200
>
>    mmc: sdhci: Fix DMA descriptor with zero data length
>    
>    [ Upstream commit 347ea32dc118326c4f2636928239a29d192cc9b8 ]
>    
>    SDHCI has built-in DMA called ADMA2.  ADMA2 uses a descriptor
>    table to define DMA scatter-gather.  Each desciptor can specify
>    a data length up to 65536 bytes, however the length field is
>    only 16-bits so zero means 65536.  Consequently, putting zero
>    when the size is zero must not be allowed.  This patch fixes
>    one case where zero data length could be set inadvertently.
>    
>    The problem happens because unaligned data gets split and the
>    code did not consider that the remaining aligned portion might
>    be zero length.  That case really only happens for SDIO because
>    SD and eMMC cards transfer blocks that are invariably sector-
>    aligned.  For SDIO, access to function registers is done by
>    data transfer (CMD53) when the register is bigger than 1 byte.
>    Generally registers are 4 bytes but 2-byte registers are possible.
>    So DMA of 4 bytes or less can happen.  When 32-bit DMA is used,
>    the data alignment must be 4, so 4-byte transfers won't casue a
>    problem, but a 2-byte transfer could.  However with the introduction
>    of 64-bit DMA, the data alignment for 64-bit DMA was made 8 bytes,
>    so all 4-byte transfers not on 8-byte boundaries get "split" into
>    a 4-byte chunk and a 0-byte chunk, thereby hitting the bug.
>    
>    In fact, a closer look at the SDHCI specs indicates that only the
>    descriptor table requires 8-byte alignment for 64-bit DMA.  That
>    will be dealt with in a separate patch, but the potential for a
>    2-byte access remains, so this fix is needed anyway.
>    
>    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
>    Cc: stable@vger.kernel.org # v3.19+
>    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e6cbcb008a279d7794fba01799ecfb6be391484f
>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
>    
>    [ Upstream commit d9bfbb95ed598a09cf336adb0f190ee0ff802f0d ]
>    
>    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>
>    Cc: stable@vger.kernel.org # v3.13+
>    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 86062e985300bc13fc5d29c862e34047bcb65c7e
>Author: Alex Deucher <alexander.deucher@amd.com>
>Date:   Thu Dec 17 12:52:17 2015 -0500
>
>    drm/radeon: clean up fujitsu quirks
>    
>    [ Upstream commit 0eb1c3d4084eeb6fb3a703f88d6ce1521f8fcdd1 ]
>    
>    Combine the two quirks.
>    
>    bug:
>    https://bugzilla.kernel.org/show_bug.cgi?id=109481
>    
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 47062c9c6cf99ef7fa09a2458a26bb95edb02759
>Author: Felix Kuehling <Felix.Kuehling@amd.com>
>Date:   Mon Nov 23 17:39:11 2015 -0500
>
>    drm/radeon: Fix off-by-one errors in radeon_vm_bo_set_addr
>    
>    [ Upstream commit 42ef344c0994cc453477afdc7a8eadc578ed0257 ]
>    
>    eoffset is sometimes treated as the last address inside the address
>    range, and sometimes as the first address outside the range. This
>    was resulting in errors when a test filled up the entire address
>    space. Make it consistent to always be the last address within the
>    range. Also fixed related errors when checking the VA limit and in
>    radeon_vm_fence_pts.
>    
>    Signed-off-by: Felix.Kuehling <Felix.Kuehling@amd.com>
>    Reviewed-by: Christian KÃ¶nig <christian.koenig@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit dc25a0a0d2bc9296d0d66cbe7a17f698122d3c41
>Author: Mathieu Poirier <mathieu.poirier@linaro.org>
>Date:   Thu Dec 17 08:47:02 2015 -0700
>
>    coresight: checking for NULL string in coresight_name_match()
>    
>    [ Upstream commit fadf3a44e974b030e7145218ad1ab25e3ef91738 ]
>    
>    Connection child names associated to ports can sometimes be NULL,
>    which is the case when booting a system on QEMU or when the Coresight
>    power domain isn't switched on.
>    
>    This patch is adding a check to make sure a NULL string isn't fed
>    to strcmp(), something that avoid crashing the system.
>    
>    Cc: <stable@vger.kernel.org> # v3.18+
>    Reported-by: Tyler Baker <tyler.baker@linaro.org>
>    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 5de8e1eed3221cb8737c2617c4567b70833795e6
>Author: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>Date:   Fri Dec 18 10:35:54 2015 +0000
>
>    arm64: kernel: enforce pmuserenr_el0 initialization and restore
>    
>    [ Upstream commit d2d39a3b91628ef5abdf58e83905b173e63d5ecf ]
>    
>    commit 60792ad349f3c6dc5735aafefe5dc9121c79e320 upstream.
>    
>    The pmuserenr_el0 register value is architecturally UNKNOWN on reset.
>    Current kernel code resets that register value iff the core pmu device is
>    correctly probed in the kernel. On platforms with missing DT pmu nodes (or
>    disabled perf events in the kernel), the pmu is not probed, therefore the
>    pmuserenr_el0 register is not reset in the kernel, which means that its
>    value retains the reset value that is architecturally UNKNOWN (system
>    may run with eg pmuserenr_el0 == 0x1, which means that PMU counters access
>    is available at EL0, which must be disallowed).
>    
>    This patch adds code that resets pmuserenr_el0 on cold boot and restores
>    it on core resume from shutdown, so that the pmuserenr_el0 setup is
>    always enforced in the kernel.
>    
>    Cc: Mark Rutland <mark.rutland@arm.com>
>    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>    Signed-off-by: Will Deacon <will.deacon@arm.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1d4c425164b922424b3f86f93f3f0b7f85293fa7
>Author: Will Deacon <will.deacon@arm.com>
>Date:   Thu Aug 20 11:47:13 2015 +0100
>
>    arm64: mdscr_el1: avoid exposing DCC to userspace
>    
>    [ Upstream commit d8d23fa0f27f3b2942a7bbc7378c7735324ed519 ]
>    
>    We don't want to expose the DCC to userspace, particularly as there is
>    a kernel console driver for it.
>    
>    This patch resets mdscr_el1 to disable userspace access to the DCC
>    registers on the cold boot path.
>    
>    Signed-off-by: Will Deacon <will.deacon@arm.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit e70aade221a271f91e2d71901b2d602df2faee15
>Author: Thomas Gleixner <tglx@linutronix.de>
>Date:   Sat Dec 19 20:07:38 2015 +0000
>
>    futex: Drop refcount if requeue_pi() acquired the rtmutex
>    
>    [ Upstream commit fb75a4282d0d9a3c7c44d940582c2d226cf3acfb ]
>    
>    If the proxy lock in the requeue loop acquires the rtmutex for a
>    waiter then it acquired also refcount on the pi_state related to the
>    futex, but the waiter side does not drop the reference count.
>    
>    Add the missing free_pi_state() call.
>    
>    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Darren Hart <darren@dvhart.com>
>    Cc: Davidlohr Bueso <dave@stgolabs.net>
>    Cc: Bhuvanesh_Surachari@mentor.com
>    Cc: Andy Lowe <Andy_Lowe@mentor.com>
>    Link: http://lkml.kernel.org/r/20151219200607.178132067@linutronix.de
>    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 51697d5f76e114f27ec08958ea1970fc55db0438
>Author: Slava Grigorev <slava.grigorev@amd.com>
>Date:   Thu Dec 17 11:09:58 2015 -0500
>
>    drm/radeon: Fix "slow" audio over DP on DCE8+
>    
>    [ Upstream commit ac4a9350abddc51ccb897abf0d9f3fd592b97e0b ]
>    
>    DP audio is derived from the dfs clock.
>    
>    Signed-off-by: Slava Grigorev <slava.grigorev@amd.com>
>    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 9e612a000cf889cfa624d984ccef770fdce43cf6
>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
>    
>    [ Upstream commit 18d03e8c25f173f4107a40d0b8c24defb6ed69f3 ]
>    
>    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>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit bf0a6a9a3d53615aee7a3e04c12f88fdd3fc1d4c
>Author: Will Deacon <will.deacon@arm.com>
>Date:   Tue Dec 15 16:08:12 2015 +0000
>
>    iommu/io-pgtable-arm: Ensure we free the final level on teardown
>    
>    [ Upstream commit 12c2ab09571e8aae3a87da2a4a452632a5fac1e5 ]
>    
>    When tearing down page tables, we return early for the final level
>    since we know that we won't have any table pointers to follow.
>    Unfortunately, this also means that we forget to free the final level,
>    so we end up leaking memory.
>    
>    Fix the issue by always freeing the current level, but just don't bother
>    to iterate over the ptes if we're at the final level.
>    
>    Cc: <stable@vger.kernel.org>
>    Reported-by: Zhang Bo <zhangbo_a@xiaomi.com>
>    Signed-off-by: Will Deacon <will.deacon@arm.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 94fde0abd09b14f0e50efe87edb36ec0d1e88510
>Author: Borislav Petkov <bp@suse.de>
>Date:   Fri Nov 27 10:38:38 2015 +0100
>
>    EDAC: Robustify workqueues destruction
>    
>    [ Upstream commit fcd5c4dd8201595d4c598c9cca5e54760277d687 ]
>    
>    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>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit eddf977af760a73a9072299e5a41bdb3de4c3930
>Author: Borislav Petkov <bp@suse.de>
>Date:   Tue Dec 1 15:52:36 2015 +0100
>
>    EDAC, mc_sysfs: Fix freeing bus' name
>    
>    [ Upstream commit 12e26969b32c79018165d52caff3762135614aa1 ]
>    
>    I get the splat below when modprobing/rmmoding EDAC drivers. It happens
>    because bus->name is invalid after bus_unregister() has run. The Code: section
>    below corresponds to:
>    
>      .loc 1 1108 0
>      movq    672(%rbx), %rax # mci_1(D)->bus, mci_1(D)->bus
>      .loc 1 1109 0
>      popq    %rbx    #
>    
>      .loc 1 1108 0
>      movq    (%rax), %rdi    # _7->name,
>      jmp     kfree   #
>    
>    and %rax has some funky stuff 2030203020312030 which looks a lot like
>    something walked over it.
>    
>    Fix that by saving the name ptr before doing stuff to string it points to.
>    
>      general protection fault: 0000 [#1] SMP
>      Modules linked in: ...
>      CPU: 4 PID: 10318 Comm: modprobe Tainted: G          I EN  3.12.51-11-default+ #48
>      Hardware name: HP ProLiant DL380 G7, BIOS P67 05/05/2011
>      task: ffff880311320280 ti: ffff88030da3e000 task.ti: ffff88030da3e000
>      RIP: 0010:[<ffffffffa019da92>]  [<ffffffffa019da92>] edac_unregister_sysfs+0x22/0x30 [edac_core]
>      RSP: 0018:ffff88030da3fe28  EFLAGS: 00010292
>      RAX: 2030203020312030 RBX: ffff880311b4e000 RCX: 000000000000095c
>      RDX: 0000000000000001 RSI: ffff880327bb9600 RDI: 0000000000000286
>      RBP: ffff880311b4e750 R08: 0000000000000000 R09: ffffffff81296110
>      R10: 0000000000000400 R11: 0000000000000000 R12: ffff88030ba1ac68
>      R13: 0000000000000001 R14: 00000000011b02f0 R15: 0000000000000000
>      FS:  00007fc9bf8f5700(0000) GS:ffff8801a7c40000(0000) knlGS:0000000000000000
>      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>      CR2: 0000000000403c90 CR3: 000000019ebdf000 CR4: 00000000000007e0
>      Stack:
>      Call Trace:
>        i7core_unregister_mci.isra.9
>        i7core_remove
>        pci_device_remove
>        __device_release_driver
>        driver_detach
>        bus_remove_driver
>        pci_unregister_driver
>        i7core_exit
>        SyS_delete_module
>        system_call_fastpath
>        0x7fc9bf426536
>      Code: 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 53 48 89 fb e8 52 2a 1f e1 48 8b bb a0 02 00 00 e8 46 59 1f e1 48 8b 83 a0 02 00 00 5b <48> 8b 38 e9 26 9a fe e0 66 0f 1f 44 00 00 66 66 66 66 90 48 8b
>      RIP  [<ffffffffa019da92>] edac_unregister_sysfs+0x22/0x30 [edac_core]
>       RSP <ffff88030da3fe28>
>    
>    Signed-off-by: Borislav Petkov <bp@suse.de>
>    Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
>    Cc: <stable@vger.kernel.org> # v3.6..
>    Fixes: 7a623c039075 ("edac: rewrite the sysfs code to use struct device")
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 1cbc3b7717e8a0c13ea5009b4157dfdf8f90b0b3
>Author: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
>Date:   Mon Nov 16 18:44:11 2015 +0300
>
>    ovl: check dentry positiveness in ovl_cleanup_whiteouts()
>    
>    [ Upstream commit 84889d49335627bc770b32787c1ef9ebad1da232 ]
>    
>    This patch fixes kernel crash at removing directory which contains
>    whiteouts from lower layers.
>    
>    Cache of directory content passed as "list" contains entries from all
>    layers, including whiteouts from lower layers. So, lookup in upper dir
>    (moved into work at this stage) will return negative entry. Plus this
>    cache is filled long before and we can race with external removal.
>    
>    Example:
>     mkdir -p lower0/dir lower1/dir upper work overlay
>     touch lower0/dir/a lower0/dir/b
>     mknod lower1/dir/a c 0 0
>     mount -t overlay none overlay -o lowerdir=lower1:lower0,upperdir=upper,workdir=work
>     rm -fr overlay/dir
>    
>    Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
>    Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
>    Cc: <stable@vger.kernel.org> # 3.18+
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c8e1bebf86dff9277e21e9a2769724ca05f40c02
>Author: Miklos Szeredi <miklos@szeredi.hu>
>Date:   Fri Dec 11 16:30:49 2015 +0100
>
>    ovl: setattr: check permissions before copy-up
>    
>    [ Upstream commit cf9a6784f7c1b5ee2b9159a1246e327c331c5697 ]
>    
>    Without this copy-up of a file can be forced, even without actually being
>    allowed to do anything on the file.
>    
>    [Arnd Bergmann] include <linux/pagemap.h> for PAGE_CACHE_SIZE (used by
>    MAX_LFS_FILESIZE definition).
>    
>    Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3d51d36e7148182e76fc36d66c494d192c410fdd
>Author: Uri Mashiach <uri.mashiach@compulab.co.il>
>Date:   Thu Dec 10 15:12:56 2015 +0200
>
>    wlcore/wl12xx: spi: fix oops on firmware load
>    
>    [ Upstream commit 9b2761cb72dc41e1948c8a5512b4efd384eda130 ]
>    
>    The maximum chunks used by the function is
>    (SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE + 1).
>    The original commands array had space for
>    (SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE) commands.
>    When the last chunk is used (len > 4 * WSPI_MAX_CHUNK_SIZE), the last
>    command is stored outside the bounds of the commands array.
>    
>    Oops 5 (page fault) is generated during current wl1271 firmware load
>    attempt:
>    
>    root@debian-armhf:~# ifconfig wlan0 up
>    [  294.312399] Unable to handle kernel paging request at virtual address
>    00203fc4
>    [  294.320173] pgd = de528000
>    [  294.323028] [00203fc4] *pgd=00000000
>    [  294.326916] Internal error: Oops: 5 [#1] SMP ARM
>    [  294.331789] Modules linked in: bnep rfcomm bluetooth ipv6 arc4 wl12xx
>    wlcore mac80211 musb_dsps cfg80211 musb_hdrc usbcore usb_common
>    wlcore_spi omap_rng rng_core musb_am335x omap_wdt cpufreq_dt thermal_sys
>    hwmon
>    [  294.351838] CPU: 0 PID: 1827 Comm: ifconfig Not tainted
>    4.2.0-00002-g3e9ad27-dirty #78
>    [  294.360154] Hardware name: Generic AM33XX (Flattened Device Tree)
>    [  294.366557] task: dc9d6d40 ti: de550000 task.ti: de550000
>    [  294.372236] PC is at __spi_validate+0xa8/0x2ac
>    [  294.376902] LR is at __spi_sync+0x78/0x210
>    [  294.381200] pc : [<c049c760>]    lr : [<c049ebe0>]    psr: 60000013
>    [  294.381200] sp : de551998  ip : de5519d8  fp : 00200000
>    [  294.393242] r10: de551c8c  r9 : de5519d8  r8 : de3a9000
>    [  294.398730] r7 : de3a9258  r6 : de3a9400  r5 : de551a48  r4 :
>    00203fbc
>    [  294.405577] r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 :
>    de3a9000
>    [  294.412420] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
>    Segment user
>    [  294.419918] Control: 10c5387d  Table: 9e528019  DAC: 00000015
>    [  294.425954] Process ifconfig (pid: 1827, stack limit = 0xde550218)
>    [  294.432437] Stack: (0xde551998 to 0xde552000)
>    
>    ...
>    
>    [  294.883613] [<c049c760>] (__spi_validate) from [<c049ebe0>]
>    (__spi_sync+0x78/0x210)
>    [  294.891670] [<c049ebe0>] (__spi_sync) from [<bf036598>]
>    (wl12xx_spi_raw_write+0xfc/0x148 [wlcore_spi])
>    [  294.901661] [<bf036598>] (wl12xx_spi_raw_write [wlcore_spi]) from
>    [<bf21c694>] (wlcore_boot_upload_firmware+0x1ec/0x458 [wlcore])
>    [  294.914038] [<bf21c694>] (wlcore_boot_upload_firmware [wlcore]) from
>    [<bf24532c>] (wl12xx_boot+0xc10/0xfac [wl12xx])
>    [  294.925161] [<bf24532c>] (wl12xx_boot [wl12xx]) from [<bf20d5cc>]
>    (wl1271_op_add_interface+0x5b0/0x910 [wlcore])
>    [  294.936364] [<bf20d5cc>] (wl1271_op_add_interface [wlcore]) from
>    [<bf15c4ac>] (ieee80211_do_open+0x44c/0xf7c [mac80211])
>    [  294.947963] [<bf15c4ac>] (ieee80211_do_open [mac80211]) from
>    [<c0537978>] (__dev_open+0xa8/0x110)
>    [  294.957307] [<c0537978>] (__dev_open) from [<c0537bf8>]
>    (__dev_change_flags+0x88/0x148)
>    [  294.965713] [<c0537bf8>] (__dev_change_flags) from [<c0537cd0>]
>    (dev_change_flags+0x18/0x48)
>    [  294.974576] [<c0537cd0>] (dev_change_flags) from [<c05a55a0>]
>    (devinet_ioctl+0x6b4/0x7d0)
>    [  294.983191] [<c05a55a0>] (devinet_ioctl) from [<c0517040>]
>    (sock_ioctl+0x1e4/0x2bc)
>    [  294.991244] [<c0517040>] (sock_ioctl) from [<c017d378>]
>    (do_vfs_ioctl+0x420/0x6b0)
>    [  294.999208] [<c017d378>] (do_vfs_ioctl) from [<c017d674>]
>    (SyS_ioctl+0x6c/0x7c)
>    [  295.006880] [<c017d674>] (SyS_ioctl) from [<c000f4c0>]
>    (ret_fast_syscall+0x0/0x54)
>    [  295.014835] Code: e1550004 e2444034 0a00007d e5953018 (e5942008)
>    [  295.021544] ---[ end trace 66ed188198f4e24e ]---
>    
>    Signed-off-by: Uri Mashiach <uri.mashiach@compulab.co.il>
>    Acked-by: Igor Grinberg <grinberg@compulab.co.il>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 76e8046ae4f3c7abd9e4f8ab69000609e554eb77
>Author: Peter Wu <peter@lekensteyn.nl>
>Date:   Mon Dec 7 01:07:31 2015 +0100
>
>    rtlwifi: fix memory leak for USB device
>    
>    [ Upstream commit 17bc55864f81dd730d05f09b1641312a7990d636 ]
>    
>    Free skb for received frames with a wrong checksum. This can happen
>    pretty rapidly, exhausting all memory.
>    
>    This fixes a memleak (detected with kmemleak). Originally found while
>    using monitor mode, but it also appears during managed mode (once the
>    link is up).
>    
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Peter Wu <peter@lekensteyn.nl>
>    ACKed-by: Larry Finger <Larry.Finger@lwfinger.net>
>    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 01e6b1f4cc792b0c932b3b37f273012af0ae50a1
>Author: Ville SyrjÃ¤lÃ¤ <ville.syrjala@linux.intel.com>
>Date:   Thu Dec 3 23:14:09 2015 +0200
>
>    drm: Don't overwrite UNVERFIED mode status to OK
>    
>    [ Upstream commit be8719a610003297c28b140f1ebd4445aef1d613 ]
>    
>    The way the mode probing works is this:
>    1. All modes currently on the mode list are marked as UNVERIFIED
>    2. New modes are on the probed_modes list (they start with
>       status OK)
>    3. Modes are moved from the probed_modes list to the actual
>       mode list. If a mode already on the mode list is deemed
>       to match one of the probed modes, the duplicate is dropped
>       and the mode status updated to OK. After this the
>       probed_modes list will be empty.
>    4. All modes on the mode list are verified to not violate any
>       constraints. Any that do are marked as such.
>    5. Any mode left with a non-OK status is pruned from the list,
>       with an appropriate debug message.
>    
>    What all this means is that any mode on the original list that
>    didn't have a duplicate on the probed_modes list, should be left
>    with status UNVERFIED (or previously could have been left with
>    some other status, but never OK).
>    
>    I broke that in
>    commit 05acaec334fc ("drm: Reorganize probed mode validation")
>    by always assigning something to the mode->status during the validation
>    step. So any mode from the old list that still passed the validation
>    would be left on the list with status OK in the end.
>    
>    Fix this by not doing the basic mode validation unless the mode
>    already has status OK (meaning it came from the probed_modes list,
>    or at least a duplicate of it was on that list). This way we will
>    correctly prune away any mode from the old mode list that didn't
>    appear on the probed_modes list.
>    
>    Cc: stable@vger.kernel.org
>    Cc: Adam Jackson <ajax@redhat.com>
>    Fixes: 05acaec334fc ("drm: Reorganize probed mode validation")
>    Signed-off-by: Ville SyrjÃ¤lÃ¤ <ville.syrjala@linux.intel.com>
>    Link: http://patchwork.freedesktop.org/patch/msgid/1449177255-9515-2-git-send-email-ville.syrjala@linux.intel.com
>    Testcase: igt/kms_force_connector_basic/prune-stale-modes
>    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93332
>    [danvet: Also applying to drm-misc to avoid too much conflict hell -
>    there's a big pile of patches from Ville on top of this one.]
>    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>    
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 138792935ec5f83d0e18b18e692be7341fa42a4a
>Author: Dmitry Tunin <hanipouspilot@gmail.com>
>Date:   Sat Dec 5 14:09:36 2015 +0300
>
>    Bluetooth: Add support of Toshiba Broadcom based devices
>    
>    [ Upstream commit 1623d0bf847d3b38d8cf24367b3689ba0e3fe2aa ]
>    
>    BugLink: https://bugs.launchpad.net/bugs/1522949
>    
>        T: Bus=03 Lev=02 Prnt=02 Port=05 Cnt=02 Dev#= 4 Spd=12 MxCh= 0
>        D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
>        P: Vendor=0930 ProdID=0225 Rev=01.12
>        S: Manufacturer=Broadcom Corp
>        S: Product=BCM43142A0
>        S: SerialNumber=4CBB58034671
>        C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
>        I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
>        I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
>        I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
>        I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
>    
>    Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
>    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit ba122961c9ef892d5b94d68fbb91d59e3d6ec38a
>Author: Miklos Szeredi <miklos@szeredi.hu>
>Date:   Wed Dec 9 16:11:59 2015 +0100
>
>    ovl: root: copy attr
>    
>    [ Upstream commit ed06e069775ad9236087594a1c1667367e983fb5 ]
>    
>    We copy i_uid and i_gid of underlying inode into overlayfs inode.  Except
>    for the root inode.
>    
>    Fix this omission.
>    
>    Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit a94ff8213e3bd0918424f3208450955638f98197
>Author: Thomas Huth <thuth@redhat.com>
>Date:   Fri Nov 20 09:11:45 2015 +0100
>
>    KVM: PPC: Fix emulation of H_SET_DABR/X on POWER8
>    
>    [ Upstream commit 760a7364f27d974d100118d88190e574626e18a6 ]
>    
>    In the old DABR register, the BT (Breakpoint Translation) bit
>    is bit number 61. In the new DAWRX register, the WT (Watchpoint
>    Translation) bit is bit number 59. So to move the DABR-BT bit
>    into the position of the DAWRX-WT bit, it has to be shifted by
>    two, not only by one. This fixes hardware watchpoints in gdb of
>    older guests that only use the H_SET_DABR/X interface instead
>    of the new H_SET_MODE interface.
>    
>    Cc: stable@vger.kernel.org # v3.14+
>    Signed-off-by: Thomas Huth <thuth@redhat.com>
>    Reviewed-by: Laurent Vivier <lvivier@redhat.com>
>    Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
>    Signed-off-by: Paul Mackerras <paulus@samba.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 51975a203210d3a94a7711651b1045ed0e3514ed
>Author: David Gibson <david@gibson.dropbear.id.au>
>Date:   Mon Nov 30 12:30:30 2015 +1100
>
>    time: Avoid signed overflow in timekeeping_get_ns()
>    
>    [ Upstream commit 35a4933a895927990772ae96fdcfd2f806929ee2 ]
>    
>    1e75fa8 "time: Condense timekeeper.xtime into xtime_sec" replaced a call to
>    clocksource_cyc2ns() from timekeeping_get_ns() with an open-coded version
>    of the same logic to avoid keeping a semi-redundant struct timespec
>    in struct timekeeper.
>    
>    However, the commit also introduced a subtle semantic change - where
>    clocksource_cyc2ns() uses purely unsigned math, the new version introduces
>    a signed temporary, meaning that if (delta * tk->mult) has a 63-bit
>    overflow the following shift will still give a negative result.  The
>    choice of 'maxsec' in __clocksource_updatefreq_scale() means this will
>    generally happen if there's a ~10 minute pause in examining the
>    clocksource.
>    
>    This can be triggered on a powerpc KVM guest by stopping it from qemu for
>    a bit over 10 minutes.  After resuming time has jumped backwards several
>    minutes causing numerous problems (jiffies does not advance, msleep()s can
>    be extended by minutes..).  It doesn't happen on x86 KVM guests, because
>    the guest TSC is effectively frozen while the guest is stopped, which is
>    not the case for the powerpc timebase.
>    
>    Obviously an unsigned (64 bit) overflow will only take twice as long as a
>    signed, 63-bit overflow.  I don't know the time code well enough to know
>    if that will still cause incorrect calculations, or if a 64-bit overflow
>    is avoided elsewhere.
>    
>    Still, an incorrect forwards clock adjustment will cause less trouble than
>    time going backwards.  So, this patch removes the potential for
>    intermediate signed overflow.
>    
>    Cc: stable@vger.kernel.org  (3.7+)
>    Suggested-by: Laurent Vivier <lvivier@redhat.com>
>    Tested-by: Laurent Vivier <lvivier@redhat.com>
>    Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>    Signed-off-by: John Stultz <john.stultz@linaro.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 549913712496e0534b1ee23dcaa24721e0edd6f4
>Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>Date:   Fri Dec 4 14:29:02 2015 +0100
>
>    ARM: mvebu: remove duplicated regulator definition in Armada 388 GP
>    
>    [ Upstream commit 079ae0c121fd23287f4ad2be9e9f8a13f63cae73 ]
>    
>    The Armada 388 GP Device Tree file describes two times a regulator
>    named 'reg_usb2_1_vbus', with the exact same description. This has
>    been wrong since Armada 388 GP support was introduced.
>    
>    Fixes: 928413bd859c0 ("ARM: mvebu: Add Armada 388 General Purpose Development Board support")
>    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>    Cc: <stable@vger.kernel.org> # v4.0+
>    Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f04d333fc68c2dc2441e2ef2ca12e2fc4793a587
>Author: Alex Deucher <alexander.deucher@amd.com>
>Date:   Tue Nov 24 14:32:44 2015 -0500
>
>    drm/radeon: call hpd_irq_event on resume
>    
>    [ Upstream commit dbb17a21c131eca94eb31136eee9a7fe5aff00d9 ]
>    
>    Need to call this on resume if displays changes during
>    suspend in order to properly be notified of changes.
>    
>    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>    Cc: stable@vger.kernel.org
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit f0193949e113c8bf87ed8d6143bcf5823dd78db0
>Author: Steven Rostedt <rostedt@goodmis.org>
>Date:   Mon Nov 16 17:25:16 2015 -0500
>
>    tools lib traceevent: Fix output of %llu for 64 bit values read on 32 bit machines
>    
>    [ Upstream commit 32abc2ede536aae52978d6c0a8944eb1df14f460 ]
>    
>    When a long value is read on 32 bit machines for 64 bit output, the
>    parsing needs to change "%lu" into "%llu", as the value is read
>    natively.
>    
>    Unfortunately, if "%llu" is already there, the code will add another "l"
>    to it and fail to parse it properly.
>    
>    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
>    Acked-by: Namhyung Kim <namhyung@kernel.org>
>    Cc: stable@vger.kernel.org
>    Link: http://lkml.kernel.org/r/20151116172516.4b79b109@gandalf.local.home
>    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 6649b1104932f3213f7e5aca7aefbdff7fbfae6b
>Author: Malcolm Priestley <tvboxspy@gmail.com>
>Date:   Mon Aug 31 06:13:45 2015 -0300
>
>    [media] media: dvb-core: Don't force CAN_INVERSION_AUTO in oneshot mode
>    
>    [ Upstream commit c9d57de6103e343f2d4e04ea8d9e417e10a24da7 ]
>    
>    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>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit bf114c8b221d078ba4a5530732ea17b32367f216
>Author: Antonio Ospite <ao2@ao2.it>
>Date:   Fri Oct 2 17:33:13 2015 -0300
>
>    [media] gspca: ov534/topro: prevent a division by 0
>    
>    [ Upstream commit dcc7fdbec53a960588f2c40232db2c6466c09917 ]
>    
>    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>
>    Cc: stable@vger.kernel.org
>    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: Sasha Levin <sasha.levin@oracle.com>
>
>commit b377c2be9c4cd3a8c422627d9964f257e6d0ed53
>Author: Sasha Levin <sasha.levin@oracle.com>
>Date:   Mon Feb 1 11:27:06 2016 -0500
>
>    [media] vb2: fix a regression in poll() behavior for output,streams
>    
>    [ Upstream commit 4623e5967448444a4ea1e77beb58898c4af48693 ]
>    
>    In the 3.17 kernel the poll() behavior changed for output streams:
>    as long as not all buffers were queued up poll() would return that
>    userspace can write. This is fine for the write() call, but when
>    using stream I/O this changed the behavior since the expectation
>    was that it would wait for buffers to become available for dequeuing.
>    
>    This patch only enables the check whether you can queue buffers
>    for file I/O only, and skips it for stream I/O.
>    
>    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
>    Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>    Cc: <stable@vger.kernel.org>      # for v3.17 and up
>    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
>    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 3c0a63d74b4a12a0a98cd85b195031d8d4b109a6
>Author: Vito Caputo <vito.caputo@coreos.com>
>Date:   Sat Oct 24 07:19:46 2015 -0500
>
>    ovl: use a minimal buffer in ovl_copy_xattr
>    
>    [ Upstream commit e4ad29fa0d224d05e08b2858e65f112fd8edd4fe ]
>    
>    Rather than always allocating the high-order XATTR_SIZE_MAX buffer
>    which is costly and prone to failure, only allocate what is needed and
>    realloc if necessary.
>    
>    Fixes https://github.com/coreos/bugs/issues/489
>    
>    Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit c000201d0b514b2324bfdaccb8bf8f63eafec6e8
>Author: Miklos Szeredi <miklos@szeredi.hu>
>Date:   Tue Nov 10 17:08:41 2015 +0100
>
>    ovl: allow zero size xattr
>    
>    [ Upstream commit 97daf8b97ad6f913a34c82515be64dc9ac08d63e ]
>    
>    When ovl_copy_xattr() encountered a zero size xattr no more xattrs were
>    copied and the function returned success.  This is clearly not the desired
>    behavior.
>    
>    Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
>    Cc: <stable@vger.kernel.org>
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>
>commit 2d5f6b0413359df065fd02d695c08bbc7d998bbd
>Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>Date:   Sun Jan 31 11:23:48 2016 -0800
>
>    Linux 4.1.17
>
>commit d17367a77457f556e7614f2e80db5d5a902e1268
>Author: libin <huawei.libin@huawei.com>
>Date:   Tue Nov 3 08:58:47 2015 +0800
>
>    recordmcount: Fix endianness handling bug for nop_mcount
>    
>    commit c84da8b9ad3761eef43811181c7e896e9834b26b upstream.
>    
>    In nop_mcount, shdr->sh_offset and welp->r_offset should handle
>    endianness properly, otherwise it will trigger Segmentation fault
>    if the recordmcount main and file.o have different endianness.
>    
>    Link: http://lkml.kernel.org/r/563806C7.7070606@huawei.com
>    
>    Signed-off-by: Li Bin <huawei.libin@huawei.com>
>    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 1f6d936d33f4b5875ca3aed0e8084e0fb56d4e0d
>Author: Yang Shi <yang.shi@linaro.org>
>Date:   Wed Nov 18 10:48:55 2015 -0800
>
>    arm64: restore bogomips information in /proc/cpuinfo
>    
>    commit 92e788b749862ebe9920360513a718e5dd4da7a9 upstream.
>    
>    As previously reported, some userspace applications depend on bogomips
>    showed by /proc/cpuinfo. Although there is much less legacy impact on
>    aarch64 than arm, it does break libvirt.
>    
>    This patch reverts commit 326b16db9f69 ("arm64: delay: don't bother
>    reporting bogomips in /proc/cpuinfo"), but with some tweak due to
>    context change and without the pr_info().
>    
>    Fixes: 326b16db9f69 ("arm64: delay: don't bother reporting bogomips in /proc/cpuinfo")
>    Signed-off-by: Yang Shi <yang.shi@linaro.org>
>    Acked-by: Will Deacon <will.deacon@arm.com>
>    Cc: <stable@vger.kernel.org> # 3.12+
>    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 705164dbe08ff960bce54eb2edad20f8def2b247
>Author: Guenter Roeck <linux@roeck-us.net>
>Date:   Sat Nov 28 08:52:04 2015 -0800
>
>    mn10300: Select CONFIG_HAVE_UID16 to fix build failure
>    
>    commit c86576ea114a9a881cf7328dc7181052070ca311 upstream.
>    
>    mn10300 builds fail with
>    
>    fs/stat.c: In function 'cp_old_stat':
>    fs/stat.c:163:2: error: 'old_uid_t' undeclared
>    
>    ipc/util.c: In function 'ipc64_perm_to_ipc_perm':
>    ipc/util.c:540:2: error: 'old_uid_t' undeclared
>    
>    Select CONFIG_HAVE_UID16 and remove local definition of CONFIG_UID16
>    to fix the problem.
>    
>    Fixes: fbc416ff8618 ("arm64: fix building without CONFIG_UID16")
>    Cc: Arnd Bergmann <arnd@arndb.de>
>    Acked-by: Arnd Bergmann <arnd@arndb.de>
>    Acked-by: Acked-by: David Howells <dhowells@redhat.com>
>    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 57b7d61c2d89e3e0665b9cdcc8fb73b08d10f0c2
>Author: Al Viro <viro@zeniv.linux.org.uk>
>Date:   Tue Dec 8 12:22:47 2015 -0500
>
>    fix the regression from "direct-io: Fix negative return from dio read beyond eof"
>    
>    commit 2d4594acbf6d8f75a27f3578476b6a27d8b13ebb upstream.
>    
>    Sure, it's better to bail out of past-the-eof read and return 0 than return
>    a bogus negative value on such.  Only we'd better make sure we are bailing out
>    with 0 and not -ENOMEM...
>    
>    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 8885e7f3d76a9d42eb4fd97a3cfc5a8ac7f6f2ff
>Author: Jan Kara <jack@suse.cz>
>Date:   Mon Nov 30 10:15:42 2015 -0700
>
>    direct-io: Fix negative return from dio read beyond eof
>    
>    commit 74cedf9b6c603f2278a05bc91b140b32b434d0b5 upstream.
>    
>    Assume a filesystem with 4KB blocks. When a file has size 1000 bytes and
>    we issue direct IO read at offset 1024, blockdev_direct_IO() reads the
>    tail of the last block and the logic for handling short DIO reads in
>    dio_complete() results in a return value -24 (1000 - 1024) which
>    obviously confuses userspace.
>    
>    Fix the problem by bailing out early once we sample i_size and can
>    reliably check that direct IO read starts beyond i_size.
>    
>    Reported-by: Avi Kivity <avi@scylladb.com>
>    Fixes: 9fe55eea7e4b444bafc42fa0000cc2d1d2847275
>    CC: Steven Whitehouse <swhiteho@redhat.com>
>    Signed-off-by: Jan Kara <jack@suse.cz>
>    Signed-off-by: Jens Axboe <axboe@fb.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit b824d64b153a9683aed6730e9f093a7102c36799
>Author: Salva PeirÃ³ <speirofr@gmail.com>
>Date:   Wed Oct 7 07:09:26 2015 -0300
>
>    media/vivid-osd: fix info leak in ioctl
>    
>    commit eda98796aff0d9bf41094b06811f5def3b4c333c upstream.
>    
>    The vivid_fb_ioctl() code fails to initialize the 16 _reserved bytes of
>    struct fb_vblank after the ->hcount member. Add an explicit
>    memset(0) before filling the structure to avoid the info leak.
>    
>    Signed-off-by: Salva PeirÃ³ <speirofr@gmail.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 3f0cf7dcf712ef29ca47cd2f0b20292aab6e1d59
>Author: Al Viro <viro@ZenIV.linux.org.uk>
>Date:   Tue Dec 1 19:52:12 2015 +0000
>
>    staging: lustre: echo_copy.._lsm() dereferences userland pointers directly
>    
>    commit 9225c0b7b976dd9ceac2b80727a60d8fcb906a62 upstream.
>    
>    missing get_user()
>    
>    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit b50a2b556d1e487c2430e13042a98325adca0be5
>Author: Richard Purdie <richard.purdie@linuxfoundation.org>
>Date:   Fri Sep 18 16:31:33 2015 -0700
>
>    HID: core: Avoid uninitialized buffer access
>    
>    commit 79b568b9d0c7c5d81932f4486d50b38efdd6da6d upstream.
>    
>    hid_connect adds various strings to the buffer but they're all
>    conditional. You can find circumstances where nothing would be written
>    to it but the kernel will still print the supposedly empty buffer with
>    printk. This leads to corruption on the console/in the logs.
>    
>    Ensure buf is initialized to an empty string.
>    
>    Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>    [dvhart: Initialize string to "" rather than assign buf[0] = NULL;]
>    Cc: Jiri Kosina <jikos@kernel.org>
>    Cc: linux-input@vger.kernel.org
>    Signed-off-by: Darren Hart <dvhart@linux.intel.com>
>    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit c777e9ab2a44c802ca1453b820f9e3ff5dbe11a4
>Author: Mikulas Patocka <mpatocka@redhat.com>
>Date:   Mon Nov 30 14:47:46 2015 -0500
>
>    parisc iommu: fix panic due to trying to allocate too large region
>    
>    commit e46e31a3696ae2d66f32c207df3969613726e636 upstream.
>    
>    When using the Promise TX2+ SATA controller on PA-RISC, the system often
>    crashes with kernel panic, for example just writing data with the dd
>    utility will make it crash.
>    
>    Kernel panic - not syncing: drivers/parisc/sba_iommu.c: I/O MMU @ 000000000000a000 is out of mapping resources
>    
>    CPU: 0 PID: 18442 Comm: mkspadfs Not tainted 4.4.0-rc2 #2
>    Backtrace:
>     [<000000004021497c>] show_stack+0x14/0x20
>     [<0000000040410bf0>] dump_stack+0x88/0x100
>     [<000000004023978c>] panic+0x124/0x360
>     [<0000000040452c18>] sba_alloc_range+0x698/0x6a0
>     [<0000000040453150>] sba_map_sg+0x260/0x5b8
>     [<000000000c18dbb4>] ata_qc_issue+0x264/0x4a8 [libata]
>     [<000000000c19535c>] ata_scsi_translate+0xe4/0x220 [libata]
>     [<000000000c19a93c>] ata_scsi_queuecmd+0xbc/0x320 [libata]
>     [<0000000040499bbc>] scsi_dispatch_cmd+0xfc/0x130
>     [<000000004049da34>] scsi_request_fn+0x6e4/0x970
>     [<00000000403e95a8>] __blk_run_queue+0x40/0x60
>     [<00000000403e9d8c>] blk_run_queue+0x3c/0x68
>     [<000000004049a534>] scsi_run_queue+0x2a4/0x360
>     [<000000004049be68>] scsi_end_request+0x1a8/0x238
>     [<000000004049de84>] scsi_io_completion+0xfc/0x688
>     [<0000000040493c74>] scsi_finish_command+0x17c/0x1d0
>    
>    The cause of the crash is not exhaustion of the IOMMU space, there is
>    plenty of free pages. The function sba_alloc_range is called with size
>    0x11000, thus the pages_needed variable is 0x11. The function
>    sba_search_bitmap is called with bits_wanted 0x11 and boundary size is
>    0x10 (because dma_get_seg_boundary(dev) returns 0xffff).
>    
>    The function sba_search_bitmap attempts to allocate 17 pages that must not
>    cross 16-page boundary - it can't satisfy this requirement
>    (iommu_is_span_boundary always returns true) and fails even if there are
>    many free entries in the IOMMU space.
>    
>    How did it happen that we try to allocate 17 pages that don't cross
>    16-page boundary? The cause is in the function iommu_coalesce_chunks. This
>    function tries to coalesce adjacent entries in the scatterlist. The
>    function does several checks if it may coalesce one entry with the next,
>    one of those checks is this:
>    
>    	if (startsg->length + dma_len > max_seg_size)
>    		break;
>    
>    When it finishes coalescing adjacent entries, it allocates the mapping:
>    
>    sg_dma_len(contig_sg) = dma_len;
>    dma_len = ALIGN(dma_len + dma_offset, IOVP_SIZE);
>    sg_dma_address(contig_sg) =
>    	PIDE_FLAG
>    	| (iommu_alloc_range(ioc, dev, dma_len) << IOVP_SHIFT)
>    	| dma_offset;
>    
>    It is possible that (startsg->length + dma_len > max_seg_size) is false
>    (we are just near the 0x10000 max_seg_size boundary), so the funcion
>    decides to coalesce this entry with the next entry. When the coalescing
>    succeeds, the function performs
>    	dma_len = ALIGN(dma_len + dma_offset, IOVP_SIZE);
>    And now, because of non-zero dma_offset, dma_len is greater than 0x10000.
>    iommu_alloc_range (a pointer to sba_alloc_range) is called and it attempts
>    to allocate 17 pages for a device that must not cross 16-page boundary.
>    
>    To fix the bug, we must make sure that dma_len after addition of
>    dma_offset and alignment doesn't cross the segment boundary. I.e. change
>    	if (startsg->length + dma_len > max_seg_size)
>    		break;
>    to
>    	if (ALIGN(dma_len + dma_offset + startsg->length, IOVP_SIZE) > max_seg_size)
>    		break;
>    
>    This patch makes this change (it precalculates max_seg_boundary at the
>    beginning of the function iommu_coalesce_chunks). I also added a check
>    that the mapping length doesn't exceed dma_get_seg_boundary(dev) (it is
>    not needed for Promise TX2+ SATA, but it may be needed for other devices
>    that have dma_get_seg_boundary lower than dma_get_max_seg_size).
>    
>    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
>    Signed-off-by: Helge Deller <deller@gmx.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit e479822e1e3a518250cb7c9be51ed8f857dfab86
>Author: David Woodhouse <David.Woodhouse@intel.com>
>Date:   Thu Oct 15 09:28:06 2015 +0100
>
>    iommu/vt-d: Fix ATSR handling for Root-Complex integrated endpoints
>    
>    commit d14053b3c714178525f22660e6aaf41263d00056 upstream.
>    
>    The VT-d specification says that "Software must enable ATS on endpoint
>    devices behind a Root Port only if the Root Port is reported as
>    supporting ATS transactions."
>    
>    We walk up the tree to find a Root Port, but for integrated devices we
>    don't find one â we get to the host bridge. In that case we *should*
>    allow ATS. Currently we don't, which means that we are incorrectly
>    failing to use ATS for the integrated graphics. Fix that.
>    
>    We should never break out of this loop "naturally" with bus==NULL,
>    since we'll always find bridge==NULL in that case (and now return 1).
>    
>    So remove the check for (!bridge) after the loop, since it can never
>    happen. If it did, it would be worthy of a BUG_ON(!bridge). But since
>    it'll oops anyway in that case, that'll do just as well.
>    
>    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit f21731a54a666aec2242849207f6369dc976079c
>Author: Will Deacon <will.deacon@arm.com>
>Date:   Thu Dec 10 16:05:36 2015 +0000
>
>    arm64: mm: ensure that the zero page is visible to the page table walker
>    
>    commit 32d6397805d00573ce1fa55f408ce2bca15b0ad3 upstream.
>    
>    In paging_init, we allocate the zero page, memset it to zero and then
>    point TTBR0 to it in order to avoid speculative fetches through the
>    identity mapping.
>    
>    In order to guarantee that the freshly zeroed page is indeed visible to
>    the page table walker, we need to execute a dsb instruction prior to
>    writing the TTBR.
>    
>    Signed-off-by: Will Deacon <will.deacon@arm.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 3e804c36399e7b39b39eff847a44f3933f48ac52
>Author: John Blackwood <john.blackwood@ccur.com>
>Date:   Mon Dec 7 11:50:34 2015 +0000
>
>    arm64: Clear out any singlestep state on a ptrace detach operation
>    
>    commit 5db4fd8c52810bd9740c1240ebf89223b171aa70 upstream.
>    
>    Make sure to clear out any ptrace singlestep state when a ptrace(2)
>    PTRACE_DETACH call is made on arm64 systems.
>    
>    Otherwise, the previously ptraced task will die off with a SIGTRAP
>    signal if the debugger just previously singlestepped the ptraced task.
>    
>    Signed-off-by: John Blackwood <john.blackwood@ccur.com>
>    [will: added comment to justify why this is in the arch code]
>    Signed-off-by: Will Deacon <will.deacon@arm.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 426bfb6a778411df0245373aa0979ce11d8fff85
>Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>Date:   Thu Dec 3 09:25:22 2015 +0100
>
>    ARM/arm64: KVM: correct PTE uncachedness check
>    
>    commit 0de58f852875a0f0dcfb120bb8433e4e73c7803b upstream.
>    
>    Commit e6fab5442345 ("ARM/arm64: KVM: test properly for a PTE's
>    uncachedness") modified the logic to test whether a HYP or stage-2
>    mapping needs flushing, from [incorrectly] interpreting the page table
>    attributes to [incorrectly] checking whether the PFN that backs the
>    mapping is covered by host system RAM. The PFN number is part of the
>    output of the translation, not the input, so we have to use pte_pfn()
>    on the contents of the PTE, not __phys_to_pfn() on the HYP virtual
>    address or stage-2 intermediate physical address.
>    
>    Fixes: e6fab5442345 ("ARM/arm64: KVM: test properly for a PTE's uncachedness")
>    Tested-by: Pavel Fedin <p.fedin@samsung.com>
>    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 3f0b20e1a2d8e9eadbe8ca81dfc7e3d324b813da
>Author: Arnd Bergmann <arnd@arndb.de>
>Date:   Fri Nov 20 12:12:21 2015 +0100
>
>    arm64: fix building without CONFIG_UID16
>    
>    commit fbc416ff86183e2203cdf975e2881d7c164b0271 upstream.
>    
>    As reported by Michal Simek, building an ARM64 kernel with CONFIG_UID16
>    disabled currently fails because the system call table still needs to
>    reference the individual function entry points that are provided by
>    kernel/sys_ni.c in this case, and the declarations are hidden inside
>    of #ifdef CONFIG_UID16:
>    
>    arch/arm64/include/asm/unistd32.h:57:8: error: 'sys_lchown16' undeclared here (not in a function)
>     __SYSCALL(__NR_lchown, sys_lchown16)
>    
>    I believe this problem only exists on ARM64, because older architectures
>    tend to not need declarations when their system call table is built
>    in assembly code, while newer architectures tend to not need UID16
>    support. ARM64 only uses these system calls for compatibility with
>    32-bit ARM binaries.
>    
>    This changes the CONFIG_UID16 check into CONFIG_HAVE_UID16, which is
>    set unconditionally on ARM64 with CONFIG_COMPAT, so we see the
>    declarations whenever we need them, but otherwise the behavior is
>    unchanged.
>    
>    Fixes: af1839eb4bd4 ("Kconfig: clean up the long arch list for the UID16 config option")
>    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>    Acked-by: Will Deacon <will.deacon@arm.com>
>    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit f94cf332a8061d7cec4940d29f58b6f5a1e3f765
>Author: Marc Zyngier <marc.zyngier@arm.com>
>Date:   Mon Nov 16 10:28:17 2015 +0000
>
>    arm64: KVM: Fix AArch32 to AArch64 register mapping
>    
>    commit c0f0963464c24e034b858441205455bf2a5d93ad upstream.
>    
>    When running a 32bit guest under a 64bit hypervisor, the ARMv8
>    architecture defines a mapping of the 32bit registers in the 64bit
>    space. This includes banked registers that are being demultiplexed
>    over the 64bit ones.
>    
>    On exceptions caused by an operation involving a 32bit register, the
>    HW exposes the register number in the ESR_EL2 register. It was so
>    far understood that SW had to distinguish between AArch32 and AArch64
>    accesses (based on the current AArch32 mode and register number).
>    
>    It turns out that I misinterpreted the ARM ARM, and the clue is in
>    D1.20.1: "For some exceptions, the exception syndrome given in the
>    ESR_ELx identifies one or more register numbers from the issued
>    instruction that generated the exception. Where the exception is
>    taken from an Exception level using AArch32 these register numbers
>    give the AArch64 view of the register."
>    
>    Which means that the HW is already giving us the translated version,
>    and that we shouldn't try to interpret it at all (for example, doing
>    an MMIO operation from the IRQ mode using the LR register leads to
>    very unexpected behaviours).
>    
>    The fix is thus not to perform a call to vcpu_reg32() at all from
>    vcpu_reg(), and use whatever register number is supplied directly.
>    The only case we need to find out about the mapping is when we
>    actively generate a register access, which only occurs when injecting
>    a fault in a guest.
>    
>    Reviewed-by: Robin Murphy <robin.murphy@arm.com>
>    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>    Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 959cad3a68a7b47370f092fd76be3ea411127515
>Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>Date:   Tue Nov 10 15:11:20 2015 +0100
>
>    ARM/arm64: KVM: test properly for a PTE's uncachedness
>    
>    commit e6fab54423450d699a09ec2b899473a541f61971 upstream.
>    
>    The open coded tests for checking whether a PTE maps a page as
>    uncached use a flawed '(pte_val(xxx) & CONST) != CONST' pattern,
>    which is not guaranteed to work since the type of a mapping is
>    not a set of mutually exclusive bits
>    
>    For HYP mappings, the type is an index into the MAIR table (i.e, the
>    index itself does not contain any information whatsoever about the
>    type of the mapping), and for stage-2 mappings it is a bit field where
>    normal memory and device types are defined as follows:
>    
>        #define MT_S2_NORMAL            0xf
>        #define MT_S2_DEVICE_nGnRE      0x1
>    
>    I.e., masking *and* comparing with the latter matches on the former,
>    and we have been getting lucky merely because the S2 device mappings
>    also have the PTE_UXN bit set, or we would misidentify memory mappings
>    as device mappings.
>    
>    Since the unmap_range() code path (which contains one instance of the
>    flawed test) is used both for HYP mappings and stage-2 mappings, and
>    considering the difference between the two, it is non-trivial to fix
>    this by rewriting the tests in place, as it would involve passing
>    down the type of mapping through all the functions.
>    
>    However, since HYP mappings and stage-2 mappings both deal with host
>    physical addresses, we can simply check whether the mapping is backed
>    by memory that is managed by the host kernel, and only perform the
>    D-cache maintenance if this is the case.
>    
>    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>    Tested-by: Pavel Fedin <p.fedin@samsung.com>
>    Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
>    Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 75f1fde24b56a5838c22f6eea2a16593a1b80fb4
>Author: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>Date:   Tue Nov 17 11:50:51 2015 +0000
>
>    arm64: kernel: pause/unpause function graph tracer in cpu_suspend()
>    
>    commit de818bd4522c40ea02a81b387d2fa86f989c9623 upstream.
>    
>    The function graph tracer adds instrumentation that is required to trace
>    both entry and exit of a function. In particular the function graph
>    tracer updates the "return address" of a function in order to insert
>    a trace callback on function exit.
>    
>    Kernel power management functions like cpu_suspend() are called
>    upon power down entry with functions called "finishers" that are in turn
>    called to trigger the power down sequence but they may not return to the
>    kernel through the normal return path.
>    
>    When the core resumes from low-power it returns to the cpu_suspend()
>    function through the cpu_resume path, which leaves the trace stack frame
>    set-up by the function tracer in an incosistent state upon return to the
>    kernel when tracing is enabled.
>    
>    This patch fixes the issue by pausing/resuming the function graph
>    tracer on the thread executing cpu_suspend() (ie the function call that
>    subsequently triggers the "suspend finishers"), so that the function graph
>    tracer state is kept consistent across functions that enter power down
>    states and never return by effectively disabling graph tracer while they
>    are executing.
>    
>    Fixes: 819e50e25d0c ("arm64: Add ftrace support")
>    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>    Reported-by: Catalin Marinas <catalin.marinas@arm.com>
>    Reported-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
>    Suggested-by: Steven Rostedt <rostedt@goodmis.org>
>    Acked-by: Steven Rostedt <rostedt@goodmis.org>
>    Cc: Will Deacon <will.deacon@arm.com>
>    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit f22c64cd0745e9b6bc1c68d82affe9dd2151625a
>Author: Zi Shen Lim <zlim.lnx@gmail.com>
>Date:   Wed Nov 4 20:43:59 2015 -0800
>
>    arm64: bpf: fix mod-by-zero case
>    
>    commit 14e589ff4aa3f28a5424e92b6495ecb8950080f7 upstream.
>    
>    Turns out in the case of modulo by zero in a BPF program:
>    	A = A % X;  (X == 0)
>    the expected behavior is to terminate with return value 0.
>    
>    The bug in JIT is exposed by a new test case [1].
>    
>    [1] https://lkml.org/lkml/2015/11/4/499
>    
>    Signed-off-by: Zi Shen Lim <zlim.lnx@gmail.com>
>    Reported-by: Yang Shi <yang.shi@linaro.org>
>    Reported-by: Xi Wang <xi.wang@gmail.com>
>    CC: Alexei Starovoitov <ast@plumgrid.com>
>    Fixes: e54bcde3d69d ("arm64: eBPF JIT compiler")
>    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 40c5dde6eb7e1d23ab8f4152d28bd71b5e30f8f6
>Author: Zi Shen Lim <zlim.lnx@gmail.com>
>Date:   Tue Nov 3 22:56:44 2015 -0800
>
>    arm64: bpf: fix div-by-zero case
>    
>    commit 251599e1d6906621f49218d7b474ddd159e58f3b upstream.
>    
>    In the case of division by zero in a BPF program:
>    	A = A / X;  (X == 0)
>    the expected behavior is to terminate with return value 0.
>    
>    This is confirmed by the test case introduced in commit 86bf1721b226
>    ("test_bpf: add tests checking that JIT/interpreter sets A and X to 0.").
>    
>    Reported-by: Yang Shi <yang.shi@linaro.org>
>    Tested-by: Yang Shi <yang.shi@linaro.org>
>    CC: Xi Wang <xi.wang@gmail.com>
>    CC: Alexei Starovoitov <ast@plumgrid.com>
>    CC: linux-arm-kernel@lists.infradead.org
>    CC: linux-kernel@vger.kernel.org
>    Fixes: e54bcde3d69d ("arm64: eBPF JIT compiler")
>    Signed-off-by: Zi Shen Lim <zlim.lnx@gmail.com>
>    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 8831ded35abdb2ff1eaaa10c3e756a8d45a9d171
>Author: Li Bin <huawei.libin@huawei.com>
>Date:   Fri Oct 30 16:31:04 2015 +0800
>
>    recordmcount: arm64: Replace the ignored mcount call into nop
>    
>    commit 2ee8a74f2a5da913637f75a19a0da0e7a08c0f86 upstream.
>    
>    By now, the recordmcount only records the function that in
>    following sections:
>    .text/.ref.text/.sched.text/.spinlock.text/.irqentry.text/
>    .kprobes.text/.text.unlikely
>    
>    For the function that not in these sections, the call mcount
>    will be in place and not be replaced when kernel boot up. And
>    it will bring performance overhead, such as do_mem_abort (in
>    .exception.text section). This patch make the call mcount to
>    nop for this case in recordmcount.
>    
>    Link: http://lkml.kernel.org/r/1446019445-14421-1-git-send-email-huawei.libin@huawei.com
>    Link: http://lkml.kernel.org/r/1446193864-24593-4-git-send-email-huawei.libin@huawei.com
>    
>    Cc: <lkp@intel.com>
>    Cc: <catalin.marinas@arm.com>
>    Cc: <takahiro.akashi@linaro.org>
>    Acked-by: Will Deacon <will.deacon@arm.com>
>    Signed-off-by: Li Bin <huawei.libin@huawei.com>
>    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit a33b8ff3d6cb996ae964dc04a99c536f31fc463f
>Author: Ulrich Weigand <ulrich.weigand@de.ibm.com>
>Date:   Tue Jan 12 23:14:23 2016 +1100
>
>    powerpc/module: Handle R_PPC64_ENTRY relocations
>    
>    commit a61674bdfc7c2bf909c4010699607b62b69b7bec upstream.
>    
>    GCC 6 will include changes to generated code with -mcmodel=large,
>    which is used to build kernel modules on powerpc64le.  This was
>    necessary because the large model is supposed to allow arbitrary
>    sizes and locations of the code and data sections, but the ELFv2
>    global entry point prolog still made the unconditional assumption
>    that the TOC associated with any particular function can be found
>    within 2 GB of the function entry point:
>    
>    func:
>    	addis r2,r12,(.TOC.-func)@ha
>    	addi  r2,r2,(.TOC.-func)@l
>    	.localentry func, .-func
>    
>    To remove this assumption, GCC will now generate instead this global
>    entry point prolog sequence when using -mcmodel=large:
>    
>    	.quad .TOC.-func
>    func:
>    	.reloc ., R_PPC64_ENTRY
>    	ld    r2, -8(r12)
>    	add   r2, r2, r12
>    	.localentry func, .-func
>    
>    The new .reloc triggers an optimization in the linker that will
>    replace this new prolog with the original code (see above) if the
>    linker determines that the distance between .TOC. and func is in
>    range after all.
>    
>    Since this new relocation is now present in module object files,
>    the kernel module loader is required to handle them too.  This
>    patch adds support for the new relocation and implements the
>    same optimization done by the GNU linker.
>    
>    Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
>    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 1e2c53f19cefa0689798e4a37ecb73f2c8a7d7c7
>Author: Ulrich Weigand <ulrich.weigand@de.ibm.com>
>Date:   Tue Jan 12 23:14:22 2016 +1100
>
>    scripts/recordmcount.pl: support data in text section on powerpc
>    
>    commit 2e50c4bef77511b42cc226865d6bc568fa7f8769 upstream.
>    
>    If a text section starts out with a data blob before the first
>    function start label, disassembly parsing doing in recordmcount.pl
>    gets confused on powerpc, leading to creation of corrupted module
>    objects.
>    
>    This was not a problem so far since the compiler would never create
>    such text sections.  However, this has changed with a recent change
>    in GCC 6 to support distances of > 2GB between a function and its
>    assoicated TOC in the ELFv2 ABI, exposing this problem.
>    
>    There is already code in recordmcount.pl to handle such data blobs
>    on the sparc64 platform.  This patch uses the same method to handle
>    those on powerpc as well.
>    
>    Acked-by: Steven Rostedt <rostedt@goodmis.org>
>    Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
>    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 4126ac7cdcefc74d2e14f975f43615f09d263c2c
>Author: Boqun Feng <boqun.feng@gmail.com>
>Date:   Mon Nov 2 09:30:32 2015 +0800
>
>    powerpc: Make {cmp}xchg* and their atomic_ versions fully ordered
>    
>    commit 81d7a3294de7e9828310bbf986a67246b13fa01e upstream.
>    
>    According to memory-barriers.txt, xchg*, cmpxchg* and their atomic_
>    versions all need to be fully ordered, however they are now just
>    RELEASE+ACQUIRE, which are not fully ordered.
>    
>    So also replace PPC_RELEASE_BARRIER and PPC_ACQUIRE_BARRIER with
>    PPC_ATOMIC_ENTRY_BARRIER and PPC_ATOMIC_EXIT_BARRIER in
>    __{cmp,}xchg_{u32,u64} respectively to guarantee fully ordered semantics
>    of atomic{,64}_{cmp,}xchg() and {cmp,}xchg(), as a complement of commit
>    b97021f85517 ("powerpc: Fix atomic_xxx_return barrier semantics")
>    
>    This patch depends on patch "powerpc: Make value-returning atomics fully
>    ordered" for PPC_ATOMIC_ENTRY_BARRIER definition.
>    
>    Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
>    Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit af69fe1f70afcd8cf5aa71320e012ca2abedbabe
>Author: Boqun Feng <boqun.feng@gmail.com>
>Date:   Mon Nov 2 09:30:31 2015 +0800
>
>    powerpc: Make value-returning atomics fully ordered
>    
>    commit 49e9cf3f0c04bf76ffa59242254110309554861d upstream.
>    
>    According to memory-barriers.txt:
>    
>    > Any atomic operation that modifies some state in memory and returns
>    > information about the state (old or new) implies an SMP-conditional
>    > general memory barrier (smp_mb()) on each side of the actual
>    > operation ...
>    
>    Which mean these operations should be fully ordered. However on PPC,
>    PPC_ATOMIC_ENTRY_BARRIER is the barrier before the actual operation,
>    which is currently "lwsync" if SMP=y. The leading "lwsync" can not
>    guarantee fully ordered atomics, according to Paul Mckenney:
>    
>    https://lkml.org/lkml/2015/10/14/970
>    
>    To fix this, we define PPC_ATOMIC_ENTRY_BARRIER as "sync" to guarantee
>    the fully-ordered semantics.
>    
>    This also makes futex atomics fully ordered, which can avoid possible
>    memory ordering problems if userspace code relies on futex system call
>    for fully ordered semantics.
>    
>    Fixes: b97021f85517 ("powerpc: Fix atomic_xxx_return barrier semantics")
>    Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
>    Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 1e14dd5a386443f9dd4237f7da4df3669d903f0d
>Author: Stewart Smith <stewart@linux.vnet.ibm.com>
>Date:   Fri Dec 11 12:08:23 2015 +1100
>
>    powerpc/powernv: pr_warn_once on unsupported OPAL_MSG type
>    
>    commit 98da62b716a3b24ab8e77453c9a8a954124c18cd upstream.
>    
>    When running on newer OPAL firmware that supports sending extra
>    OPAL_MSG types, we would print a warning on *every* message received.
>    
>    This could be a problem for kernels that don't support OPAL_MSG_OCC
>    on machines that are running real close to thermal limits and the
>    OCC is throttling the chip. For a kernel that is paying attention to
>    the message queue, we could get these notifications quite often.
>    
>    Conceivably, future message types could also come fairly often,
>    and printing that we didn't understand them 10,000 times provides
>    no further information than printing them once.
>    
>    Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
>    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit a54d3a4234121d8a9749331f7b10e6ff02f886ba
>Author: Michael Neuling <mikey@neuling.org>
>Date:   Thu Nov 19 15:44:45 2015 +1100
>
>    powerpc/tm: Check for already reclaimed tasks
>    
>    commit 7f821fc9c77a9b01fe7b1d6e72717b33d8d64142 upstream.
>    
>    Currently we can hit a scenario where we'll tm_reclaim() twice.  This
>    results in a TM bad thing exception because the second reclaim occurs
>    when not in suspend mode.
>    
>    The scenario in which this can happen is the following.  We attempt to
>    deliver a signal to userspace.  To do this we need obtain the stack
>    pointer to write the signal context.  To get this stack pointer we
>    must tm_reclaim() in case we need to use the checkpointed stack
>    pointer (see get_tm_stackpointer()).  Normally we'd then return
>    directly to userspace to deliver the signal without going through
>    __switch_to().
>    
>    Unfortunatley, if at this point we get an error (such as a bad
>    userspace stack pointer), we need to exit the process.  The exit will
>    result in a __switch_to().  __switch_to() will attempt to save the
>    process state which results in another tm_reclaim().  This
>    tm_reclaim() now causes a TM Bad Thing exception as this state has
>    already been saved and the processor is no longer in TM suspend mode.
>    Whee!
>    
>    This patch checks the state of the MSR to ensure we are TM suspended
>    before we attempt the tm_reclaim().  If we've already saved the state
>    away, we should no longer be in TM suspend mode.  This has the
>    additional advantage of checking for a potential TM Bad Thing
>    exception.
>    
>    Found using syscall fuzzer.
>    
>    Fixes: fb09692e71f1 ("powerpc: Add reclaim and recheckpoint functions for context switching transactional memory processes")
>    Signed-off-by: Michael Neuling <mikey@neuling.org>
>    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 567a215dd1586dae787f21b8f3e484018763a710
>Author: Michael Neuling <mikey@neuling.org>
>Date:   Thu Nov 19 15:44:44 2015 +1100
>
>    powerpc/tm: Block signal return setting invalid MSR state
>    
>    commit d2b9d2a5ad5ef04ff978c9923d19730cb05efd55 upstream.
>    
>    Currently we allow both the MSR T and S bits to be set by userspace on
>    a signal return.  Unfortunately this is a reserved configuration and
>    will cause a TM Bad Thing exception if attempted (via rfid).
>    
>    This patch checks for this case in both the 32 and 64 bit signals
>    code.  If both T and S are set, we mark the context as invalid.
>    
>    Found using a syscall fuzzer.
>    
>    Fixes: 2b0a576d15e0 ("powerpc: Add new transactional memory state to the signal context")
>    Signed-off-by: Michael Neuling <mikey@neuling.org>
>    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit eeca98948d8c4922e6deb16bfc9ee0bd9902dbb0
>Author: Dan Streetman <dan.streetman@canonical.com>
>Date:   Thu Oct 29 09:51:16 2015 -0400
>
>    xfrm: dst_entries_init() per-net dst_ops
>    
>    [ Upstream commit a8a572a6b5f2a79280d6e302cb3c1cb1fbaeb3e8 ]
>    
>    Remove the dst_entries_init/destroy calls for xfrm4 and xfrm6 dst_ops
>    templates; their dst_entries counters will never be used.  Move the
>    xfrm dst_ops initialization from the common xfrm/xfrm_policy.c to
>    xfrm4/xfrm4_policy.c and xfrm6/xfrm6_policy.c, and call dst_entries_init
>    and dst_entries_destroy for each net namespace.
>    
>    The ipv4 and ipv6 xfrms each create dst_ops template, and perform
>    dst_entries_init on the templates.  The template values are copied to each
>    net namespace's xfrm.xfrm*_dst_ops.  The problem there is the dst_ops
>    pcpuc_entries field is a percpu counter and cannot be used correctly by
>    simply copying it to another object.
>    
>    The result of this is a very subtle bug; changes to the dst entries
>    counter from one net namespace may sometimes get applied to a different
>    net namespace dst entries counter.  This is because of how the percpu
>    counter works; it has a main count field as well as a pointer to the
>    percpu variables.  Each net namespace maintains its own main count
>    variable, but all point to one set of percpu variables.  When any net
>    namespace happens to change one of the percpu variables to outside its
>    small batch range, its count is moved to the net namespace's main count
>    variable.  So with multiple net namespaces operating concurrently, the
>    dst_ops entries counter can stray from the actual value that it should
>    be; if counts are consistently moved from one net namespace to another
>    (which my testing showed is likely), then one net namespace winds up
>    with a negative dst_ops count while another winds up with a continually
>    increasing count, eventually reaching its gc_thresh limit, which causes
>    all new traffic on the net namespace to fail with -ENOBUFS.
>    
>    Signed-off-by: Dan Streetman <dan.streetman@canonical.com>
>    Signed-off-by: Dan Streetman <ddstreet@ieee.org>
>    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 139bd872dc6868296a992a2b8142b4daba964d3f
>Author: Joe Jin <joe.jin@oracle.com>
>Date:   Mon Oct 19 13:37:17 2015 +0800
>
>    xen-netfront: update num_queues to real created
>    
>    [ Upstream commit ca88ea1247dfee094e2467a3578eaec9bdf0833a ]
>    
>    Sometimes xennet_create_queues() may failed to created all requested
>    queues, we need to update num_queues to real created to avoid NULL
>    pointer dereference.
>    
>    Signed-off-by: Joe Jin <joe.jin@oracle.com>
>    Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>    Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>    Cc: Wei Liu <wei.liu2@citrix.com>
>    Cc: Ian Campbell <ian.campbell@citrix.com>
>    Cc: David S. Miller <davem@davemloft.net>
>    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit a1edfa789d1a7f111dffb142bacbc6f2aa9d2e29
>Author: Wei Liu <wei.liu2@citrix.com>
>Date:   Thu Sep 10 11:18:58 2015 +0100
>
>    xen-netfront: respect user provided max_queues
>    
>    [ Upstream commit 32a844056fd43dda647e1c3c6b9983bdfa04d17d ]
>    
>    Originally that parameter was always reset to num_online_cpus during
>    module initialisation, which renders it useless.
>    
>    The fix is to only set max_queues to num_online_cpus when user has not
>    provided a value.
>    
>    Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>    Cc: David Vrabel <david.vrabel@citrix.com>
>    Reviewed-by: David Vrabel <david.vrabel@citrix.com>
>    Tested-by: David Vrabel <david.vrabel@citrix.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 21edf40b5ccbdf48720758fe525f3cbc19c8a202
>Author: Wei Liu <wei.liu2@citrix.com>
>Date:   Thu Sep 10 11:18:57 2015 +0100
>
>    xen-netback: respect user provided max_queues
>    
>    [ Upstream commit 4c82ac3c37363e8c4ded6a5fe1ec5fa756b34df3 ]
>    
>    Originally that parameter was always reset to num_online_cpus during
>    module initialisation, which renders it useless.
>    
>    The fix is to only set max_queues to num_online_cpus when user has not
>    provided a value.
>    
>    Reported-by: Johnny Strom <johnny.strom@linuxsolutions.fi>
>    Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>    Reviewed-by: David Vrabel <david.vrabel@citrix.com>
>    Acked-by: Ian Campbell <ian.campbell@citrix.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 534e9016cd88ccd577b226b7172e5cd079f5fb02
>Author: Karl Heiss <kheiss@gmail.com>
>Date:   Thu Sep 24 12:15:07 2015 -0400
>
>    sctp: Prevent soft lockup when sctp_accept() is called during a timeout event
>    
>    [ Upstream commit 635682a14427d241bab7bbdeebb48a7d7b91638e ]
>    
>    A case can occur when sctp_accept() is called by the user during
>    a heartbeat timeout event after the 4-way handshake.  Since
>    sctp_assoc_migrate() changes both assoc->base.sk and assoc->ep, the
>    bh_sock_lock in sctp_generate_heartbeat_event() will be taken with
>    the listening socket but released with the new association socket.
>    The result is a deadlock on any future attempts to take the listening
>    socket lock.
>    
>    Note that this race can occur with other SCTP timeouts that take
>    the bh_lock_sock() in the event sctp_accept() is called.
>    
>     BUG: soft lockup - CPU#9 stuck for 67s! [swapper:0]
>     ...
>     RIP: 0010:[<ffffffff8152d48e>]  [<ffffffff8152d48e>] _spin_lock+0x1e/0x30
>     RSP: 0018:ffff880028323b20  EFLAGS: 00000206
>     RAX: 0000000000000002 RBX: ffff880028323b20 RCX: 0000000000000000
>     RDX: 0000000000000000 RSI: ffff880028323be0 RDI: ffff8804632c4b48
>     RBP: ffffffff8100bb93 R08: 0000000000000000 R09: 0000000000000000
>     R10: ffff880610662280 R11: 0000000000000100 R12: ffff880028323aa0
>     R13: ffff8804383c3880 R14: ffff880028323a90 R15: ffffffff81534225
>     FS:  0000000000000000(0000) GS:ffff880028320000(0000) knlGS:0000000000000000
>     CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
>     CR2: 00000000006df528 CR3: 0000000001a85000 CR4: 00000000000006e0
>     DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>     DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>     Process swapper (pid: 0, threadinfo ffff880616b70000, task ffff880616b6cab0)
>     Stack:
>     ffff880028323c40 ffffffffa01c2582 ffff880614cfb020 0000000000000000
>     <d> 0100000000000000 00000014383a6c44 ffff8804383c3880 ffff880614e93c00
>     <d> ffff880614e93c00 0000000000000000 ffff8804632c4b00 ffff8804383c38b8
>     Call Trace:
>     <IRQ>
>     [<ffffffffa01c2582>] ? sctp_rcv+0x492/0xa10 [sctp]
>     [<ffffffff8148c559>] ? nf_iterate+0x69/0xb0
>     [<ffffffff814974a0>] ? ip_local_deliver_finish+0x0/0x2d0
>     [<ffffffff8148c716>] ? nf_hook_slow+0x76/0x120
>     [<ffffffff814974a0>] ? ip_local_deliver_finish+0x0/0x2d0
>     [<ffffffff8149757d>] ? ip_local_deliver_finish+0xdd/0x2d0
>     [<ffffffff81497808>] ? ip_local_deliver+0x98/0xa0
>     [<ffffffff81496ccd>] ? ip_rcv_finish+0x12d/0x440
>     [<ffffffff81497255>] ? ip_rcv+0x275/0x350
>     [<ffffffff8145cfeb>] ? __netif_receive_skb+0x4ab/0x750
>     ...
>    
>    With lockdep debugging:
>    
>     =====================================
>     [ BUG: bad unlock balance detected! ]
>     -------------------------------------
>     CslRx/12087 is trying to release lock (slock-AF_INET) at:
>     [<ffffffffa01bcae0>] sctp_generate_timeout_event+0x40/0xe0 [sctp]
>     but there are no more locks to release!
>    
>     other info that might help us debug this:
>     2 locks held by CslRx/12087:
>     #0:  (&asoc->timers[i]){+.-...}, at: [<ffffffff8108ce1f>] run_timer_softirq+0x16f/0x3e0
>     #1:  (slock-AF_INET){+.-...}, at: [<ffffffffa01bcac3>] sctp_generate_timeout_event+0x23/0xe0 [sctp]
>    
>    Ensure the socket taken is also the same one that is released by
>    saving a copy of the socket before entering the timeout event
>    critical section.
>    
>    Signed-off-by: Karl Heiss <kheiss@gmail.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 490c963c1eb9a7f5f74446f4b9738c9fb1b8e325
>Author: Ido Schimmel <idosch@mellanox.com>
>Date:   Mon Jan 18 17:30:22 2016 +0200
>
>    team: Replace rcu_read_lock with a mutex in team_vlan_rx_kill_vid
>    
>    [ Upstream commit 60a6531bfe49555581ccd65f66a350cc5693fcde ]
>    
>    We can't be within an RCU read-side critical section when deleting
>    VLANs, as underlying drivers might sleep during the hardware operation.
>    Therefore, replace the RCU critical section with a mutex. This is
>    consistent with team_vlan_rx_add_vid.
>    
>    Fixes: 3d249d4ca7d0 ("net: introduce ethernet teaming device")
>    Acked-by: Jiri Pirko <jiri@mellanox.com>
>    Signed-off-by: Ido Schimmel <idosch@mellanox.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 95785b105fa2f784ad7b6be0238338b648ed892a
>Author: Sven Eckelmann <sven@narfation.org>
>Date:   Tue Jan 5 12:06:20 2016 +0100
>
>    batman-adv: Drop immediate orig_node free function
>    
>    [ Upstream commit 42eff6a617e23b691f8e4467f4687ed7245a92db ]
>    
>    It is not allowed to free the memory of an object which is part of a list
>    which is protected by rcu-read-side-critical sections without making sure
>    that no other context is accessing the object anymore. This usually happens
>    by removing the references to this object and then waiting until the rcu
>    grace period is over and no one (allowedly) accesses it anymore.
>    
>    But the _now functions ignore this completely. They free the object
>    directly even when a different context still tries to access it. This has
>    to be avoided and thus these functions must be removed and all functions
>    have to use batadv_orig_node_free_ref.
>    
>    Fixes: 72822225bd41 ("batman-adv: Fix rcu_barrier() miss due to double call_rcu() in TT code")
>    Signed-off-by: Sven Eckelmann <sven@narfation.org>
>    Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
>    Signed-off-by: Antonio Quartulli <a@unstable.cc>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit ae3eb44e0e8b4e0fe4ab51e0a91d76517abc1e30
>Author: Sven Eckelmann <sven@narfation.org>
>Date:   Tue Jan 5 12:06:25 2016 +0100
>
>    batman-adv: Drop immediate batadv_hard_iface free function
>    
>    [ Upstream commit b4d922cfc9c08318eeb77d53b7633740e6b0efb0 ]
>    
>    It is not allowed to free the memory of an object which is part of a list
>    which is protected by rcu-read-side-critical sections without making sure
>    that no other context is accessing the object anymore. This usually happens
>    by removing the references to this object and then waiting until the rcu
>    grace period is over and no one (allowedly) accesses it anymore.
>    
>    But the _now functions ignore this completely. They free the object
>    directly even when a different context still tries to access it. This has
>    to be avoided and thus these functions must be removed and all functions
>    have to use batadv_hardif_free_ref.
>    
>    Fixes: 89652331c00f ("batman-adv: split tq information in neigh_node struct")
>    Signed-off-by: Sven Eckelmann <sven@narfation.org>
>    Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
>    Signed-off-by: Antonio Quartulli <a@unstable.cc>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 924224c6e44a393a2a41385d699230384ea23df5
>Author: Sven Eckelmann <sven@narfation.org>
>Date:   Tue Jan 5 12:06:24 2016 +0100
>
>    batman-adv: Drop immediate neigh_ifinfo free function
>    
>    [ Upstream commit ae3e1e36e3cb6c686a7a2725af20ca86aa46d62a ]
>    
>    It is not allowed to free the memory of an object which is part of a list
>    which is protected by rcu-read-side-critical sections without making sure
>    that no other context is accessing the object anymore. This usually happens
>    by removing the references to this object and then waiting until the rcu
>    grace period is over and no one (allowedly) accesses it anymore.
>    
>    But the _now functions ignore this completely. They free the object
>    directly even when a different context still tries to access it. This has
>    to be avoided and thus these functions must be removed and all functions
>    have to use batadv_neigh_ifinfo_free_ref.
>    
>    Fixes: 89652331c00f ("batman-adv: split tq information in neigh_node struct")
>    Signed-off-by: Sven Eckelmann <sven@narfation.org>
>    Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
>    Signed-off-by: Antonio Quartulli <a@unstable.cc>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 620493a90c78ce1bd150d48ca6f624ad964e0c8d
>Author: Sven Eckelmann <sven@narfation.org>
>Date:   Tue Jan 5 12:06:22 2016 +0100
>
>    batman-adv: Drop immediate batadv_neigh_node free function
>    
>    [ Upstream commit 2baa753c276f27f8e844637561ad597867aa6fb6 ]
>    
>    It is not allowed to free the memory of an object which is part of a list
>    which is protected by rcu-read-side-critical sections without making sure
>    that no other context is accessing the object anymore. This usually happens
>    by removing the references to this object and then waiting until the rcu
>    grace period is over and no one (allowedly) accesses it anymore.
>    
>    But the _now functions ignore this completely. They free the object
>    directly even when a different context still tries to access it. This has
>    to be avoided and thus these functions must be removed and all functions
>    have to use batadv_neigh_node_free_ref.
>    
>    Fixes: 89652331c00f ("batman-adv: split tq information in neigh_node struct")
>    Signed-off-by: Sven Eckelmann <sven@narfation.org>
>    Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
>    Signed-off-by: Antonio Quartulli <a@unstable.cc>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 9d188c6b672c7d205f43da74b534d2114371edc5
>Author: Sven Eckelmann <sven@narfation.org>
>Date:   Tue Jan 5 12:06:21 2016 +0100
>
>    batman-adv: Drop immediate batadv_orig_ifinfo free function
>    
>    [ Upstream commit deed96605f5695cb945e0b3d79429581857a2b9d ]
>    
>    It is not allowed to free the memory of an object which is part of a list
>    which is protected by rcu-read-side-critical sections without making sure
>    that no other context is accessing the object anymore. This usually happens
>    by removing the references to this object and then waiting until the rcu
>    grace period is over and no one (allowedly) accesses it anymore.
>    
>    But the _now functions ignore this completely. They free the object
>    directly even when a different context still tries to access it. This has
>    to be avoided and thus these functions must be removed and all functions
>    have to use batadv_orig_ifinfo_free_ref.
>    
>    Fixes: 7351a4822d42 ("batman-adv: split out router from orig_node")
>    Signed-off-by: Sven Eckelmann <sven@narfation.org>
>    Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
>    Signed-off-by: Antonio Quartulli <a@unstable.cc>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 34c5bf7c7bf4e285274e28a36b08cbf3da5bd3e3
>Author: Sven Eckelmann <sven@narfation.org>
>Date:   Tue Jan 5 12:06:19 2016 +0100
>
>    batman-adv: Avoid recursive call_rcu for batadv_nc_node
>    
>    [ Upstream commit 44e8e7e91d6c7c7ab19688750f7257292640d1a0 ]
>    
>    The batadv_nc_node_free_ref function uses call_rcu to delay the free of the
>    batadv_nc_node object until no (already started) rcu_read_lock is enabled
>    anymore. This makes sure that no context is still trying to access the
>    object which should be removed. But batadv_nc_node also contains a
>    reference to orig_node which must be removed.
>    
>    The reference drop of orig_node was done in the call_rcu function
>    batadv_nc_node_free_rcu but should actually be done in the
>    batadv_nc_node_release function to avoid nested call_rcus. This is
>    important because rcu_barrier (e.g. batadv_softif_free or batadv_exit) will
>    not detect the inner call_rcu as relevant for its execution. Otherwise this
>    barrier will most likely be inserted in the queue before the callback of
>    the first call_rcu was executed. The caller of rcu_barrier will therefore
>    continue to run before the inner call_rcu callback finished.
>    
>    Fixes: d56b1705e28c ("batman-adv: network coding - detect coding nodes and remove these after timeout")
>    Signed-off-by: Sven Eckelmann <sven@narfation.org>
>    Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
>    Signed-off-by: Antonio Quartulli <a@unstable.cc>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 016cb1d02db9840a62c0e2a465ffd6617eacffc7
>Author: Sven Eckelmann <sven@narfation.org>
>Date:   Thu Jan 14 15:28:19 2016 +0100
>
>    batman-adv: Avoid recursive call_rcu for batadv_bla_claim
>    
>    [ Upstream commit 63b399272294e7a939cde41792dca38c549f0484 ]
>    
>    The batadv_claim_free_ref function uses call_rcu to delay the free of the
>    batadv_bla_claim object until no (already started) rcu_read_lock is enabled
>    anymore. This makes sure that no context is still trying to access the
>    object which should be removed. But batadv_bla_claim also contains a
>    reference to backbone_gw which must be removed.
>    
>    The reference drop of backbone_gw was done in the call_rcu function
>    batadv_claim_free_rcu but should actually be done in the
>    batadv_claim_release function to avoid nested call_rcus. This is important
>    because rcu_barrier (e.g. batadv_softif_free or batadv_exit) will not
>    detect the inner call_rcu as relevant for its execution. Otherwise this
>    barrier will most likely be inserted in the queue before the callback of
>    the first call_rcu was executed. The caller of rcu_barrier will therefore
>    continue to run before the inner call_rcu callback finished.
>    
>    Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code")
>    Signed-off-by: Sven Eckelmann <sven@narfation.org>
>    Acked-by: Simon Wunderlich <sw@simonwunderlich.de>
>    Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
>    Signed-off-by: Antonio Quartulli <a@unstable.cc>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit a50a93cc99286dc444c7e5ccc7dfb9d58c2d346d
>Author: Ben Hutchings <ben@decadent.org.uk>
>Date:   Sun Nov 1 16:22:53 2015 +0000
>
>    ppp, slip: Validate VJ compression slot parameters completely
>    
>    [ Upstream commit 4ab42d78e37a294ac7bc56901d563c642e03c4ae ]
>    
>    Currently slhc_init() treats out-of-range values of rslots and tslots
>    as equivalent to 0, except that if tslots is too large it will
>    dereference a null pointer (CVE-2015-7799).
>    
>    Add a range-check at the top of the function and make it return an
>    ERR_PTR() on error instead of NULL.  Change the callers accordingly.
>    
>    Compile-tested only.
>    
>    Reported-by: éæ°¸å <guoyonggang@360.cn>
>    References: http://article.gmane.org/gmane.comp.security.oss.general/17908
>    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 5984398539a2c47834caf1b00dc9f58b7bb2e67a
>Author: Ben Hutchings <ben@decadent.org.uk>
>Date:   Sun Nov 1 16:21:24 2015 +0000
>
>    isdn_ppp: Add checks for allocation failure in isdn_ppp_open()
>    
>    [ Upstream commit 0baa57d8dc32db78369d8b5176ef56c5e2e18ab3 ]
>    
>    Compile-tested only.
>    
>    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 9ba3d77689a5d07aa5020dbf38d10ce8f641aa16
>Author: Raanan Avargil <raanan.avargil@intel.com>
>Date:   Thu Oct 1 04:48:53 2015 -0700
>
>    tcp/dccp: fix old style declarations
>    
>    [ Upstream commit 8695a144da9e500a5a60fa34c06694346ec1048f ]
>    
>    Iâm using the compilation flag -Werror=old-style-declaration, which
>    requires that the âinlineâ word would come at the beginning of the code
>    line.
>    
>    $ make drivers/net/ethernet/intel/e1000e/e1000e.ko
>    ...
>    include/net/inet_timewait_sock.h:116:1: error: âinlineâ is not at
>    beginning of declaration [-Werror=old-style-declaration]
>    static void inline inet_twsk_schedule(struct inet_timewait_sock *tw, int
>    timeo)
>    
>    include/net/inet_timewait_sock.h:121:1: error: âinlineâ is not at
>    beginning of declaration [-Werror=old-style-declaration]
>    static void inline inet_twsk_reschedule(struct inet_timewait_sock *tw,
>    int timeo)
>    
>    Fixes: ed2e92394589 ("tcp/dccp: fix timewait races in timer handling")
>    Signed-off-by: Raanan Avargil <raanan.avargil@intel.com>
>    Signed-off-by: Eric Dumazet <edumazet@google.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 479b539a310152b10c1747ac8c5354ed7bc25181
>Author: Eric Dumazet <edumazet@google.com>
>Date:   Sat Sep 19 09:08:34 2015 -0700
>
>    tcp/dccp: fix timewait races in timer handling
>    
>    [ Upstream commit ed2e923945892a8372ab70d2f61d364b0b6d9054 ]
>    
>    When creating a timewait socket, we need to arm the timer before
>    allowing other cpus to find it. The signal allowing cpus to find
>    the socket is setting tw_refcnt to non zero value.
>    
>    As we set tw_refcnt in __inet_twsk_hashdance(), we therefore need to
>    call inet_twsk_schedule() first.
>    
>    This also means we need to remove tw_refcnt changes from
>    inet_twsk_schedule() and let the caller handle it.
>    
>    Note that because we use mod_timer_pinned(), we have the guarantee
>    the timer wont expire before we set tw_refcnt as we run in BH context.
>    
>    To make things more readable I introduced inet_twsk_reschedule() helper.
>    
>    When rearming the timer, we can use mod_timer_pending() to make sure
>    we do not rearm a canceled timer.
>    
>    Note: This bug can possibly trigger if packets of a flow can hit
>    multiple cpus. This does not normally happen, unless flow steering
>    is broken somehow. This explains this bug was spotted ~5 months after
>    its introduction.
>    
>    A similar fix is needed for SYN_RECV sockets in reqsk_queue_hash_req(),
>    but will be provided in a separate patch for proper tracking.
>    
>    Fixes: 789f558cfb36 ("tcp/dccp: get rid of central timewait timer")
>    Signed-off-by: Eric Dumazet <edumazet@google.com>
>    Reported-by: Ying Cai <ycai@google.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 332fb8799ed1c701339e9b4dad3efbed245b4cf8
>Author: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
>Date:   Fri Jan 15 19:03:54 2016 +0100
>
>    bridge: fix lockdep addr_list_lock false positive splat
>    
>    [ Upstream commit c6894dec8ea9ae05747124dce98b3b5c2e69b168 ]
>    
>    After promisc mode management was introduced a bridge device could do
>    dev_set_promiscuity from its ndo_change_rx_flags() callback which in
>    turn can be called after the bridge's addr_list_lock has been taken
>    (e.g. by dev_uc_add). This causes a false positive lockdep splat because
>    the port interfaces' addr_list_lock is taken when br_manage_promisc()
>    runs after the bridge's addr list lock was already taken.
>    To remove the false positive introduce a custom bridge addr_list_lock
>    class and set it on bridge init.
>    A simple way to reproduce this is with the following:
>    $ brctl addbr br0
>    $ ip l add l br0 br0.100 type vlan id 100
>    $ ip l set br0 up
>    $ ip l set br0.100 up
>    $ echo 1 > /sys/class/net/br0/bridge/vlan_filtering
>    $ brctl addif br0 eth0
>    Splat:
>    [   43.684325] =============================================
>    [   43.684485] [ INFO: possible recursive locking detected ]
>    [   43.684636] 4.4.0-rc8+ #54 Not tainted
>    [   43.684755] ---------------------------------------------
>    [   43.684906] brctl/1187 is trying to acquire lock:
>    [   43.685047]  (_xmit_ETHER){+.....}, at: [<ffffffff8150169e>] dev_set_rx_mode+0x1e/0x40
>    [   43.685460]  but task is already holding lock:
>    [   43.685618]  (_xmit_ETHER){+.....}, at: [<ffffffff815072a7>] dev_uc_add+0x27/0x80
>    [   43.686015]  other info that might help us debug this:
>    [   43.686316]  Possible unsafe locking scenario:
>    
>    [   43.686743]        CPU0
>    [   43.686967]        ----
>    [   43.687197]   lock(_xmit_ETHER);
>    [   43.687544]   lock(_xmit_ETHER);
>    [   43.687886] *** DEADLOCK ***
>    
>    [   43.688438]  May be due to missing lock nesting notation
>    
>    [   43.688882] 2 locks held by brctl/1187:
>    [   43.689134]  #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff81510317>] rtnl_lock+0x17/0x20
>    [   43.689852]  #1:  (_xmit_ETHER){+.....}, at: [<ffffffff815072a7>] dev_uc_add+0x27/0x80
>    [   43.690575] stack backtrace:
>    [   43.690970] CPU: 0 PID: 1187 Comm: brctl Not tainted 4.4.0-rc8+ #54
>    [   43.691270] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.8.1-20150318_183358- 04/01/2014
>    [   43.691770]  ffffffff826a25c0 ffff8800369fb8e0 ffffffff81360ceb ffffffff826a25c0
>    [   43.692425]  ffff8800369fb9b8 ffffffff810d0466 ffff8800369fb968 ffffffff81537139
>    [   43.693071]  ffff88003a08c880 0000000000000000 00000000ffffffff 0000000002080020
>    [   43.693709] Call Trace:
>    [   43.693931]  [<ffffffff81360ceb>] dump_stack+0x4b/0x70
>    [   43.694199]  [<ffffffff810d0466>] __lock_acquire+0x1e46/0x1e90
>    [   43.694483]  [<ffffffff81537139>] ? netlink_broadcast_filtered+0x139/0x3e0
>    [   43.694789]  [<ffffffff8153b5da>] ? nlmsg_notify+0x5a/0xc0
>    [   43.695064]  [<ffffffff810d10f5>] lock_acquire+0xe5/0x1f0
>    [   43.695340]  [<ffffffff8150169e>] ? dev_set_rx_mode+0x1e/0x40
>    [   43.695623]  [<ffffffff815edea5>] _raw_spin_lock_bh+0x45/0x80
>    [   43.695901]  [<ffffffff8150169e>] ? dev_set_rx_mode+0x1e/0x40
>    [   43.696180]  [<ffffffff8150169e>] dev_set_rx_mode+0x1e/0x40
>    [   43.696460]  [<ffffffff8150189c>] dev_set_promiscuity+0x3c/0x50
>    [   43.696750]  [<ffffffffa0586845>] br_port_set_promisc+0x25/0x50 [bridge]
>    [   43.697052]  [<ffffffffa05869aa>] br_manage_promisc+0x8a/0xe0 [bridge]
>    [   43.697348]  [<ffffffffa05826ee>] br_dev_change_rx_flags+0x1e/0x20 [bridge]
>    [   43.697655]  [<ffffffff81501532>] __dev_set_promiscuity+0x132/0x1f0
>    [   43.697943]  [<ffffffff81501672>] __dev_set_rx_mode+0x82/0x90
>    [   43.698223]  [<ffffffff815072de>] dev_uc_add+0x5e/0x80
>    [   43.698498]  [<ffffffffa05b3c62>] vlan_device_event+0x542/0x650 [8021q]
>    [   43.698798]  [<ffffffff8109886d>] notifier_call_chain+0x5d/0x80
>    [   43.699083]  [<ffffffff810988b6>] raw_notifier_call_chain+0x16/0x20
>    [   43.699374]  [<ffffffff814f456e>] call_netdevice_notifiers_info+0x6e/0x80
>    [   43.699678]  [<ffffffff814f4596>] call_netdevice_notifiers+0x16/0x20
>    [   43.699973]  [<ffffffffa05872be>] br_add_if+0x47e/0x4c0 [bridge]
>    [   43.700259]  [<ffffffffa058801e>] add_del_if+0x6e/0x80 [bridge]
>    [   43.700548]  [<ffffffffa0588b5f>] br_dev_ioctl+0xaf/0xc0 [bridge]
>    [   43.700836]  [<ffffffff8151a7ac>] dev_ifsioc+0x30c/0x3c0
>    [   43.701106]  [<ffffffff8151aac9>] dev_ioctl+0xf9/0x6f0
>    [   43.701379]  [<ffffffff81254345>] ? mntput_no_expire+0x5/0x450
>    [   43.701665]  [<ffffffff812543ee>] ? mntput_no_expire+0xae/0x450
>    [   43.701947]  [<ffffffff814d7b02>] sock_do_ioctl+0x42/0x50
>    [   43.702219]  [<ffffffff814d8175>] sock_ioctl+0x1e5/0x290
>    [   43.702500]  [<ffffffff81242d0b>] do_vfs_ioctl+0x2cb/0x5c0
>    [   43.702771]  [<ffffffff81243079>] SyS_ioctl+0x79/0x90
>    [   43.703033]  [<ffffffff815eebb6>] entry_SYSCALL_64_fastpath+0x16/0x7a
>    
>    CC: Vlad Yasevich <vyasevic@redhat.com>
>    CC: Stephen Hemminger <stephen@networkplumber.org>
>    CC: Bridge list <bridge@lists.linux-foundation.org>
>    CC: Andy Gospodarek <gospo@cumulusnetworks.com>
>    CC: Roopa Prabhu <roopa@cumulusnetworks.com>
>    Fixes: 2796d0c648c9 ("bridge: Automatically manage port promiscuous mode.")
>    Reported-by: Andy Gospodarek <gospo@cumulusnetworks.com>
>    Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 2980502b9f6d3e15a4dd6695d4cfff8ec3213209
>Author: Eric Dumazet <edumazet@google.com>
>Date:   Fri Jan 15 04:56:56 2016 -0800
>
>    ipv6: update skb->csum when CE mark is propagated
>    
>    [ Upstream commit 34ae6a1aa0540f0f781dd265366036355fdc8930 ]
>    
>    When a tunnel decapsulates the outer header, it has to comply
>    with RFC 6080 and eventually propagate CE mark into inner header.
>    
>    It turns out IP6_ECN_set_ce() does not correctly update skb->csum
>    for CHECKSUM_COMPLETE packets, triggering infamous "hw csum failure"
>    messages and stack traces.
>    
>    Signed-off-by: Eric Dumazet <edumazet@google.com>
>    Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit dc1cfcc266978d0213d7d4f9f813bafd4e9f709a
>Author: Rabin Vincent <rabin@rab.in>
>Date:   Tue Jan 12 20:17:08 2016 +0100
>
>    net: bpf: reject invalid shifts
>    
>    [ Upstream commit 229394e8e62a4191d592842cf67e80c62a492937 ]
>    
>    On ARM64, a BUG() is triggered in the eBPF JIT if a filter with a
>    constant shift that can't be encoded in the immediate field of the
>    UBFM/SBFM instructions is passed to the JIT.  Since these shifts
>    amounts, which are negative or >= regsize, are invalid, reject them in
>    the eBPF verifier and the classic BPF filter checker, for all
>    architectures.
>    
>    Signed-off-by: Rabin Vincent <rabin@rab.in>
>    Acked-by: Alexei Starovoitov <ast@kernel.org>
>    Acked-by: Daniel Borkmann <daniel@iogearbox.net>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 2a1e5e4ab662a159e7e5dfd229597c4752d29b3c
>Author: Eric Dumazet <edumazet@google.com>
>Date:   Tue Jan 12 08:58:00 2016 -0800
>
>    phonet: properly unshare skbs in phonet_rcv()
>    
>    [ Upstream commit 7aaed57c5c2890634cfadf725173c7c68ea4cb4f ]
>    
>    Ivaylo Dimitrov reported a regression caused by commit 7866a621043f
>    ("dev: add per net_device packet type chains").
>    
>    skb->dev becomes NULL and we crash in __netif_receive_skb_core().
>    
>    Before above commit, different kind of bugs or corruptions could happen
>    without major crash.
>    
>    But the root cause is that phonet_rcv() can queue skb without checking
>    if skb is shared or not.
>    
>    Many thanks to Ivaylo Dimitrov for his help, diagnosis and tests.
>    
>    Reported-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
>    Tested-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
>    Signed-off-by: Eric Dumazet <edumazet@google.com>
>    Cc: Remi Denis-Courmont <courmisch@gmail.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 7d9fb947be67ec2e0811a2ab6dd0582ad1bae4db
>Author: Karl Heiss <kheiss@gmail.com>
>Date:   Mon Jan 11 08:28:43 2016 -0500
>
>    bonding: Prevent IPv6 link local address on enslaved devices
>    
>    [ Upstream commit 03d84a5f83a67e692af00a3d3901e7820e3e84d5 ]
>    
>    Commit 1f718f0f4f97 ("bonding: populate neighbour's private on enslave")
>    undoes the fix provided by commit c2edacf80e15 ("bonding / ipv6: no addrconf
>    for slaves separately from master") by effectively setting the slave flag
>    after the slave has been opened.  If the slave comes up quickly enough, it
>    will go through the IPv6 addrconf before the slave flag has been set and
>    will get a link local IPv6 address.
>    
>    In order to ensure that addrconf knows to ignore the slave devices on state
>    change, set IFF_SLAVE before dev_open() during bonding enslavement.
>    
>    Fixes: 1f718f0f4f97 ("bonding: populate neighbour's private on enslave")
>    Signed-off-by: Karl Heiss <kheiss@gmail.com>
>    Signed-off-by: Jay Vosburgh <jay.vosburgh@canonical.com>
>    Reviewed-by: Jarod Wilson <jarod@redhat.com>
>    Signed-off-by: Andy Gospodarek <gospo@cumulusnetworks.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit abefd1b4087b9b5e83e7b4e7689f8b8e3cb2899c
>Author: Konstantin Khlebnikov <koct9i@gmail.com>
>Date:   Fri Jan 8 15:21:46 2016 +0300
>
>    net: preserve IP control block during GSO segmentation
>    
>    [ Upstream commit 9207f9d45b0ad071baa128e846d7e7ed85016df3 ]
>    
>    Skb_gso_segment() uses skb control block during segmentation.
>    This patch adds 32-bytes room for previous control block which
>    will be copied into all resulting segments.
>    
>    This patch fixes kernel crash during fragmenting forwarded packets.
>    Fragmentation requires valid IP CB in skb for clearing ip options.
>    Also patch removes custom save/restore in ovs code, now it's redundant.
>    
>    Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com>
>    Link: http://lkml.kernel.org/r/CALYGNiP-0MZ-FExV2HutTvE9U-QQtkKSoE--KN=JQE5STYsjAA@mail.gmail.com
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 4bb526bce19d6e4c8cc862ce304b8c072ef43366
>Author: Michal KubeÄek <mkubecek@suse.cz>
>Date:   Mon Jan 11 07:50:30 2016 +0100
>
>    udp: disallow UFO for sockets with SO_NO_CHECK option
>    
>    [ Upstream commit 40ba330227ad00b8c0cdf2f425736ff9549cc423 ]
>    
>    Commit acf8dd0a9d0b ("udp: only allow UFO for packets from SOCK_DGRAM
>    sockets") disallows UFO for packets sent from raw sockets. We need to do
>    the same also for SOCK_DGRAM sockets with SO_NO_CHECK options, even if
>    for a bit different reason: while such socket would override the
>    CHECKSUM_PARTIAL set by ip_ufo_append_data(), gso_size is still set and
>    bad offloading flags warning is triggered in __skb_gso_segment().
>    
>    In the IPv6 case, SO_NO_CHECK option is ignored but we need to disallow
>    UFO for packets sent by sockets with UDP_NO_CHECK6_TX option.
>    
>    Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
>    Tested-by: Shannon Nelson <shannon.nelson@intel.com>
>    Acked-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 e7bbeacbafc18a7781036c6111ffd9fe9eaa6ec0
>Author: Neal Cardwell <ncardwell@google.com>
>Date:   Mon Jan 11 13:42:43 2016 -0500
>
>    tcp_yeah: don't set ssthresh below 2
>    
>    [ Upstream commit 83d15e70c4d8909d722c0d64747d8fb42e38a48f ]
>    
>    For tcp_yeah, use an ssthresh floor of 2, the same floor used by Reno
>    and CUBIC, per RFC 5681 (equation 4).
>    
>    tcp_yeah_ssthresh() was sometimes returning a 0 or negative ssthresh
>    value if the intended reduction is as big or bigger than the current
>    cwnd. Congestion control modules should never return a zero or
>    negative ssthresh. A zero ssthresh generally results in a zero cwnd,
>    causing the connection to stall. A negative ssthresh value will be
>    interpreted as a u32 and will set a target cwnd for PRR near 4
>    billion.
>    
>    Oleksandr Natalenko reported that a system using tcp_yeah with ECN
>    could see a warning about a prior_cwnd of 0 in
>    tcp_cwnd_reduction(). Testing verified that this was due to
>    tcp_yeah_ssthresh() misbehaving in this way.
>    
>    Reported-by: Oleksandr Natalenko <oleksandr@natalenko.name>
>    Signed-off-by: Neal Cardwell <ncardwell@google.com>
>    Signed-off-by: Yuchung Cheng <ycheng@google.com>
>    Signed-off-by: Eric Dumazet <edumazet@google.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit add92082e2d14367b27b0e18b0deeaedd7c1f938
>Author: Eric Dumazet <edumazet@google.com>
>Date:   Fri Jan 8 09:35:51 2016 -0800
>
>    ipv6: tcp: add rcu locking in tcp_v6_send_synack()
>    
>    [ Upstream commit 3e4006f0b86a5ae5eb0e8215f9a9e1db24506977 ]
>    
>    When first SYNACK is sent, we already hold rcu_read_lock(), but this
>    is not true if a SYNACK is retransmitted, as a timer (soft) interrupt
>    does not hold rcu_read_lock()
>    
>    Fixes: 45f6fad84cc30 ("ipv6: add complete rcu protection around np->opt")
>    Reported-by: Dave Jones <davej@codemonkey.org.uk>
>    Signed-off-by: Eric Dumazet <edumazet@google.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit bcea43fb3164cdcdc42c710ca0cb90aa9c6a5530
>Author: Sasha Levin <sasha.levin@oracle.com>
>Date:   Thu Jan 7 14:52:43 2016 -0500
>
>    net: sctp: prevent writes to cookie_hmac_alg from accessing invalid memory
>    
>    [ Upstream commit 320f1a4a175e7cd5d3f006f92b4d4d3e2cbb7bb5 ]
>    
>    proc_dostring() needs an initialized destination string, while the one
>    provided in proc_sctp_do_hmac_alg() contains stack garbage.
>    
>    Thus, writing to cookie_hmac_alg would strlen() that garbage and end up
>    accessing invalid memory.
>    
>    Fixes: 3c68198e7 ("sctp: Make hmac algorithm selection for cookie generation dynamic")
>    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit a33704eb60850ac837ef83ecc380f5f6b2aa2906
>Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>Date:   Thu Jan 7 11:26:53 2016 +0100
>
>    vxlan: fix test which detect duplicate vxlan iface
>    
>    [ Upstream commit 07b9b37c227cb8d88d478b4a9c5634fee514ede1 ]
>    
>    When a vxlan interface is created, the driver checks that there is not
>    another vxlan interface with the same properties. To do this, it checks
>    the existing vxlan udp socket. Since commit 1c51a9159dde, the creation of
>    the vxlan socket is done only when the interface is set up, thus it breaks
>    that test.
>    
>    Example:
>    $ ip l a vxlan10 type vxlan id 10 group 239.0.0.10 dev eth0 dstport 0
>    $ ip l a vxlan11 type vxlan id 10 group 239.0.0.10 dev eth0 dstport 0
>    $ ip -br l | grep vxlan
>    vxlan10          DOWN           f2:55:1c:6a:fb:00 <BROADCAST,MULTICAST>
>    vxlan11          DOWN           7a:cb:b9:38:59:0d <BROADCAST,MULTICAST>
>    
>    Instead of checking sockets, let's loop over the vxlan iface list.
>    
>    Fixes: 1c51a9159dde ("vxlan: fix race caused by dropping rtnl_unlock")
>    Reported-by: Thomas Faivre <thomas.faivre@6wind.com>
>    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 8f5cd6eea8115c6a4153268508369b81f84e9dce
>Author: Francesco Ruggeri <fruggeri@aristanetworks.com>
>Date:   Wed Jan 6 00:18:48 2016 -0800
>
>    net: possible use after free in dst_release
>    
>    [ Upstream commit 07a5d38453599052aff0877b16bb9c1585f08609 ]
>    
>    dst_release should not access dst->flags after decrementing
>    __refcnt to 0. The dst_entry may be in dst_busy_list and
>    dst_gc_task may dst_destroy it before dst_release gets a chance
>    to access dst->flags.
>    
>    Fixes: d69bbf88c8d0 ("net: fix a race in dst_release()")
>    Fixes: 27b75c95f10d ("net: avoid RCU for NOCACHE dst")
>    Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
>    Acked-by: Eric Dumazet <edumazet@google.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 02a1fef61d06bb0417b60f1233320e141266860c
>Author: John Fastabend <john.fastabend@gmail.com>
>Date:   Tue Jan 5 09:11:36 2016 -0800
>
>    net: sched: fix missing free per cpu on qstats
>    
>    [ Upstream commit 73c20a8b7245273125cfe92c4b46e6fdb568a801 ]
>    
>    When a qdisc is using per cpu stats (currently just the ingress
>    qdisc) only the bstats are being freed. This also free's the qstats.
>    
>    Fixes: b0ab6f92752b9f9d8 ("net: sched: enable per cpu qstats")
>    Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>    Acked-by: Eric Dumazet <edumazet@google.com>
>    Acked-by: Daniel Borkmann <daniel@iogearbox.net>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 5596242a6263ece70ee14f3b6861f02b8dc82d11
>Author: Rabin Vincent <rabin@rab.in>
>Date:   Tue Jan 5 16:23:07 2016 +0100
>
>    net: filter: make JITs zero A for SKF_AD_ALU_XOR_X
>    
>    [ Upstream commit 55795ef5469290f89f04e12e662ded604909e462 ]
>    
>    The SKF_AD_ALU_XOR_X ancillary is not like the other ancillary data
>    instructions since it XORs A with X while all the others replace A with
>    some loaded value.  All the BPF JITs fail to clear A if this is used as
>    the first instruction in a filter.  This was found using american fuzzy
>    lop.
>    
>    Add a helper to determine if A needs to be cleared given the first
>    instruction in a filter, and use this in the JITs.  Except for ARM, the
>    rest have only been compile-tested.
>    
>    Fixes: 3480593131e0 ("net: filter: get rid of BPF_S_* enum")
>    Signed-off-by: Rabin Vincent <rabin@rab.in>
>    Acked-by: Daniel Borkmann <daniel@iogearbox.net>
>    Acked-by: Alexei Starovoitov <ast@kernel.org>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit a6b1d24893805bb4f2e7c7bc6f86a98ec37065ee
>Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
>Date:   Tue Jan 5 10:46:00 2016 +0100
>
>    bridge: Only call /sbin/bridge-stp for the initial network namespace
>    
>    [ Upstream commit ff62198553e43cdffa9d539f6165d3e83f8a42bc ]
>    
>    [I stole this patch from Eric Biederman. He wrote:]
>    
>    > There is no defined mechanism to pass network namespace information
>    > into /sbin/bridge-stp therefore don't even try to invoke it except
>    > for bridge devices in the initial network namespace.
>    >
>    > It is possible for unprivileged users to cause /sbin/bridge-stp to be
>    > invoked for any network device name which if /sbin/bridge-stp does not
>    > guard against unreasonable arguments or being invoked twice on the
>    > same network device could cause problems.
>    
>    [Hannes: changed patch using netns_eq]
>    
>    Cc: Eric W. Biederman <ebiederm@xmission.com>
>    Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
>    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 dc6b0ec667f67d4768e72c1b7f1bbc14ea52379c
>Author: willy tarreau <w@1wt.eu>
>Date:   Sun Jan 10 07:54:56 2016 +0100
>
>    unix: properly account for FDs passed over unix sockets
>    
>    [ Upstream commit 712f4aad406bb1ed67f3f98d04c044191f0ff593 ]
>    
>    It is possible for a process to allocate and accumulate far more FDs than
>    the process' limit by sending them over a unix socket then closing them
>    to keep the process' fd count low.
>    
>    This change addresses this problem by keeping track of the number of FDs
>    in flight per user and preventing non-privileged processes from having
>    more FDs in flight than their configured FD limit.
>    
>    Reported-by: socketpair@gmail.com
>    Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
>    Mitigates: CVE-2013-4312 (Linux 2.0+)
>    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
>    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
>    Signed-off-by: Willy Tarreau <w@1wt.eu>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit f45f0213b831305572436cdd2f7f0709fcbe2887
>Author: Florian Westphal <fw@strlen.de>
>Date:   Thu Dec 31 14:26:33 2015 +0100
>
>    connector: bump skb->users before callback invocation
>    
>    [ Upstream commit 55285bf09427c5abf43ee1d54e892f352092b1f1 ]
>    
>    Dmitry reports memleak with syskaller program.
>    Problem is that connector bumps skb usecount but might not invoke callback.
>    
>    So move skb_get to where we invoke the callback.
>    
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Signed-off-by: Florian Westphal <fw@strlen.de>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit c000d76ec0d8bbadb7972b374bcf7ffe34deb592
>Author: Xin Long <lucien.xin@gmail.com>
>Date:   Tue Dec 29 17:49:25 2015 +0800
>
>    sctp: sctp should release assoc when sctp_make_abort_user return NULL in sctp_close
>    
>    [ Upstream commit 068d8bd338e855286aea54e70d1c101569284b21 ]
>    
>    In sctp_close, sctp_make_abort_user may return NULL because of memory
>    allocation failure. If this happens, it will bypass any state change
>    and never free the assoc. The assoc has no chance to be freed and it
>    will be kept in memory with the state it had even after the socket is
>    closed by sctp_close().
>    
>    So if sctp_make_abort_user fails to allocate memory, we should abort
>    the asoc via sctp_primitive_ABORT as well. Just like the annotation in
>    sctp_sf_cookie_wait_prm_abort and sctp_sf_do_9_1_prm_abort said,
>    "Even if we can't send the ABORT due to low memory delete the TCB.
>    This is a departure from our typical NOMEM handling".
>    
>    But then the chunk is NULL (low memory) and the SCTP_CMD_REPLY cmd would
>    dereference the chunk pointer, and system crash. So we should add
>    SCTP_CMD_REPLY cmd only when the chunk is not NULL, just like other
>    places where it adds SCTP_CMD_REPLY cmd.
>    
>    Signed-off-by: Xin Long <lucien.xin@gmail.com>
>    Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 45d52b0b1f9f5c8717e9212ee6e4964dc8ed095c
>Author: BjÃ¸rn Mork <bjorn@mork.no>
>Date:   Wed Dec 23 13:42:43 2015 +0100
>
>    net: cdc_ncm: avoid changing RX/TX buffers on MTU changes
>    
>    [ Upstream commit 1dfddff5fcd869fcab0c52fafae099dfa435a935 ]
>    
>    NCM buffer sizes are negotiated with the device independently of
>    the network device MTU.  The RX buffers are allocated by the
>    usbnet framework based on the rx_urb_size value set by cdc_ncm. A
>    single RX buffer can hold a number of MTU sized packets.
>    
>    The default usbnet change_mtu ndo only modifies rx_urb_size if it
>    is equal to hard_mtu.  And the cdc_ncm driver will set rx_urb_size
>    and hard_mtu independently of each other, based on dwNtbInMaxSize
>    and dwNtbOutMaxSize respectively. It was therefore assumed that
>    usbnet_change_mtu() would never touch rx_urb_size.  This failed to
>    consider the case where dwNtbInMaxSize and dwNtbOutMaxSize happens
>    to be equal.
>    
>    Fix by implementing an NCM specific change_mtu ndo, modifying the
>    netdev MTU without touching the buffer size settings.
>    
>    Signed-off-by: BjÃ¸rn Mork <bjorn@mork.no>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 6866b52c56db189f8471a13f951221c45c0089c7
>Author: WANG Cong <xiyou.wangcong@gmail.com>
>Date:   Mon Dec 21 10:55:45 2015 -0800
>
>    addrconf: always initialize sysctl table data
>    
>    [ Upstream commit 5449a5ca9bc27dd51a462de7ca0b1cd861cd2bd0 ]
>    
>    When sysctl performs restrict writes, it allows to write from
>    a middle position of a sysctl file, which requires us to initialize
>    the table data before calling proc_dostring() for the write case.
>    
>    Fixes: 3d1bec99320d ("ipv6: introduce secret_stable to ipv6_devconf")
>    Reported-by: Sasha Levin <sasha.levin@oracle.com>
>    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
>    Tested-by: Sasha Levin <sasha.levin@oracle.com>
>    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 8a39e24931d119c0418721923281d2b496275ad3
>Author: Andrey Ryabinin <aryabinin@virtuozzo.com>
>Date:   Mon Dec 21 12:54:45 2015 +0300
>
>    ipv6/addrlabel: fix ip6addrlbl_get()
>    
>    [ Upstream commit e459dfeeb64008b2d23bdf600f03b3605dbb8152 ]
>    
>    ip6addrlbl_get() has never worked. If ip6addrlbl_hold() succeeded,
>    ip6addrlbl_get() will exit with '-ESRCH'. If ip6addrlbl_hold() failed,
>    ip6addrlbl_get() will use about to be free ip6addrlbl_entry pointer.
>    
>    Fix this by inverting ip6addrlbl_hold() check.
>    
>    Fixes: 2a8cc6c89039 ("[IPV6] ADDRCONF: Support RFC3484 configurable address selection policy table.")
>    Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
>    Reviewed-by: Cong Wang <cwang@twopensource.com>
>    Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 57d0c018b46ef5293da715af12c8adc32aa99847
>Author: Vijay Pandurangan <vijayp@vijayp.ca>
>Date:   Fri Dec 18 14:34:59 2015 -0500
>
>    veth: donât modify ip_summed; doing so treats packets with bad checksums as good.
>    
>    [ Upstream commit ce8c839b74e3017996fad4e1b7ba2e2625ede82f ]
>    
>    Packets that arrive from real hardware devices have ip_summed ==
>    CHECKSUM_UNNECESSARY if the hardware verified the checksums, or
>    CHECKSUM_NONE if the packet is bad or it was unable to verify it. The
>    current version of veth will replace CHECKSUM_NONE with
>    CHECKSUM_UNNECESSARY, which causes corrupt packets routed from hardware to
>    a veth device to be delivered to the application. This caused applications
>    at Twitter to receive corrupt data when network hardware was corrupting
>    packets.
>    
>    We believe this was added as an optimization to skip computing and
>    verifying checksums for communication between containers. However, locally
>    generated packets have ip_summed == CHECKSUM_PARTIAL, so the code as
>    written does nothing for them. As far as we can tell, after removing this
>    code, these packets are transmitted from one stack to another unmodified
>    (tcpdump shows invalid checksums on both sides, as expected), and they are
>    delivered correctly to applications. We didnât test every possible network
>    configuration, but we tried a few common ones such as bridging containers,
>    using NAT between the host and a container, and routing from hardware
>    devices to containers. We have effectively deployed this in production at
>    Twitter (by disabling RX checksum offloading on veth devices).
>    
>    This code dates back to the first version of the driver, commit
>    <e314dbdc1c0dc6a548ecf> ("[NET]: Virtual ethernet device driver"), so I
>    suspect this bug occurred mostly because the driver API has evolved
>    significantly since then. Commit <0b7967503dc97864f283a> ("net/veth: Fix
>    packet checksumming") (in December 2010) fixed this for packets that get
>    created locally and sent to hardware devices, by not changing
>    CHECKSUM_PARTIAL. However, the same issue still occurs for packets coming
>    in from hardware devices.
>    
>    Co-authored-by: Evan Jones <ej@evanjones.ca>
>    Signed-off-by: Evan Jones <ej@evanjones.ca>
>    Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>    Cc: Phil Sutter <phil@nwl.cc>
>    Cc: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>    Cc: netdev@vger.kernel.org
>    Cc: linux-kernel@vger.kernel.org
>    Signed-off-by: Vijay Pandurangan <vijayp@vijayp.ca>
>    Acked-by: Cong Wang <cwang@twopensource.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 3fabd53542c866e28e13a2cff43904d7a66308e0
>Author: Oliver Neukum <oneukum@suse.com>
>Date:   Thu Dec 3 15:03:34 2015 +0100
>
>    xhci: refuse loading if nousb is used
>    
>    commit 1eaf35e4dd592c59041bc1ed3248c46326da1f5f upstream.
>    
>    The module should fail to load.
>    
>    Signed-off-by: Oliver Neukum <oneukum@suse.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 3f5e25aa380d0ed5a38a824049ed520dabb149a9
>Author: Oliver Freyermuth <o.freyermuth@googlemail.com>
>Date:   Mon Dec 28 18:37:38 2015 +0100
>
>    USB: cp210x: add ID for ELV Marble Sound Board 1
>    
>    commit f7d7f59ab124748156ea551edf789994f05da342 upstream.
>    
>    Add the USB device ID for ELV Marble Sound Board 1.
>    
>    Signed-off-by: Oliver Freyermuth <o.freyermuth@googlemail.com>
>    Signed-off-by: Johan Hovold <johan@kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 887c3cc2557b3548eabcce9e03dce470303f29e9
>Author: Dan Carpenter <dan.carpenter@oracle.com>
>Date:   Wed Dec 16 14:06:37 2015 +0300
>
>    USB: ipaq.c: fix a timeout loop
>    
>    commit abdc9a3b4bac97add99e1d77dc6d28623afe682b upstream.
>    
>    The code expects the loop to end with "retries" set to zero but, because
>    it is a post-op, it will end set to -1.  I have fixed this by moving the
>    decrement inside the loop.
>    
>    Fixes: 014aa2a3c32e ('USB: ipaq: minor ipaq_open() cleanup.')
>    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit a7e83b16c8d83a75c58989e845c664ecaa6e0aa6
>Author: Alan Stern <stern@rowland.harvard.edu>
>Date:   Wed Dec 16 13:32:38 2015 -0500
>
>    USB: fix invalid memory access in hub_activate()
>    
>    commit e50293ef9775c5f1cf3fcc093037dd6a8c5684ea upstream.
>    
>    Commit 8520f38099cc ("USB: change hub initialization sleeps to
>    delayed_work") changed the hub_activate() routine to make part of it
>    run in a workqueue.  However, the commit failed to take a reference to
>    the usb_hub structure or to lock the hub interface while doing so.  As
>    a result, if a hub is plugged in and quickly unplugged before the work
>    routine can run, the routine will try to access memory that has been
>    deallocated.  Or, if the hub is unplugged while the routine is
>    running, the memory may be deallocated while it is in active use.
>    
>    This patch fixes the problem by taking a reference to the usb_hub at
>    the start of hub_activate() and releasing it at the end (when the work
>    is finished), and by locking the hub interface while the work routine
>    is running.  It also adds a check at the start of the routine to see
>    if the hub has already been disconnected, in which nothing should be
>    done.
>    
>    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
>    Reported-by: Alexandru Cornea <alexandru.cornea@intel.com>
>    Tested-by: Alexandru Cornea <alexandru.cornea@intel.com>
>    Fixes: 8520f38099cc ("USB: change hub initialization sleeps to delayed_work")
>    CC: <stable@vger.kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 5241134a79fa2fc2d45b66b2651c8467818482db
>Author: Antti Palosaari <crope@iki.fi>
>Date:   Mon Oct 26 18:58:14 2015 -0200
>
>    airspy: increase USB control message buffer size
>    
>    commit aa0850e1d56623845b46350ffd971afa9241886d upstream.
>    
>    Driver requested device firmware version string during probe using
>    only 24 byte long buffer. That buffer is too small for newer firmware
>    versions, which causes device firmware hang - device stops responding
>    to any commands after that. Increase buffer size to 128 which should
>    be enough for any current and future version strings.
>    
>    Link: https://github.com/airspy/host/issues/27
>    
>    Reported-by: Benjamin Vernoux <bvernoux@gmail.com>
>    Signed-off-by: Antti Palosaari <crope@iki.fi>
>    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit abcbfda367d4eb2b17dc9c5b036c99431ed3ea3c
>Author: Chunfeng Yun <chunfeng.yun@mediatek.com>
>Date:   Fri Dec 4 15:53:43 2015 +0200
>
>    usb: xhci: fix config fail of FS hub behind a HS hub with MTT
>    
>    commit 096b110a3dd3c868e4610937c80d2e3f3357c1a9 upstream.
>    
>    if a full speed hub connects to a high speed hub which
>    supports MTT, the MTT field of its slot context will be set
>    to 1 when xHCI driver setups an xHCI virtual device in
>    xhci_setup_addressable_virt_dev(); once usb core fetch its
>    hub descriptor, and need to update the xHC's internal data
>    structures for the device, the HUB field of its slot context
>    will be set to 1 too, meanwhile MTT is also set before,
>    this will cause configure endpoint command fail, so in the
>    case, we should clear MTT to 0 for full speed hub according
>    to section 6.2.2
>    
>    Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
>    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 1f6a2cc39913518756d8b4dad4a10493d208f4c2
>Author: Vinod Koul <vinod.koul@intel.com>
>Date:   Thu Jan 7 21:48:14 2016 +0530
>
>    ASoC: compress: Fix compress device direction check
>    
>    commit a1068045883ed4a18363a4ebad0c3d55e473b716 upstream.
>    
>    The detection of direction for compress was only taking into account codec
>    capabilities and not CPU ones. Fix this by checking the CPU side capabilities
>    as well
>    
>    Tested-by: Ashish Panwar <ashish.panwar@intel.com>
>    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
>    Signed-off-by: Mark Brown <broonie@kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 20091f9139bc0a17544a45b51fd3a7780552682f
>Author: Nikesh Oswal <Nikesh.Oswal@cirrus.com>
>Date:   Wed Dec 23 14:18:05 2015 +0000
>
>    ASoC: arizona: Fix bclk for sample rates that are multiple of 4kHz
>    
>    commit e73694d871867cae8471d2350ce89acb38bc2b63 upstream.
>    
>    For a sample rate of 12kHz the bclk was taken from the 44.1kHz table as
>    we test for a multiple of 8kHz. This patch fixes this issue by testing
>    for multiples of 4kHz instead.
>    
>    Signed-off-by: Nikesh Oswal <Nikesh.Oswal@cirrus.com>
>    Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
>    Signed-off-by: Mark Brown <broonie@kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 6ac84206a212c8d86277680ef6e9066020fc54f7
>Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
>Date:   Fri Dec 11 13:06:24 2015 +0200
>
>    ASoC: davinci-mcasp: Fix XDATA check in mcasp_start_tx
>    
>    commit e2a0c9fa80227be5ee017b5476638829dd41cb39 upstream.
>    
>    The condition for checking for XDAT being cleared was not correct.
>    
>    Fixes: 36bcecd0a73eb ("ASoC: davinci-mcasp: Correct TX start sequence")
>    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
>    Signed-off-by: Mark Brown <broonie@kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 1fce19176555fdad16a9933965f36e514514d092
>Author: Mans Rullgard <mans@mansr.com>
>Date:   Fri Dec 11 11:27:08 2015 +0000
>
>    ASoC: wm8974: set cache type for regmap
>    
>    commit 1ea5998afe903384ddc16391d4c023cd4c867bea upstream.
>    
>    Attempting to use this codec driver triggers a BUG() in regcache_sync()
>    since no cache type is set.  The register map of this device is fairly
>    small and has few holes so a flat cache is suitable.
>    
>    Signed-off-by: Mans Rullgard <mans@mansr.com>
>    Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
>    Signed-off-by: Mark Brown <broonie@kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 5a1109e05e0907b324db88b8e376fb5174facd2c
>Author: John Keeping <john@metanate.com>
>Date:   Wed Dec 9 11:38:13 2015 +0000
>
>    ASoC: es8328: Fix deemphasis values
>    
>    commit 84ebac4d04d25ac5c1b1dc3ae621fd465eb38f4e upstream.
>    
>    This is using completely the wrong mask and value when updating the
>    register.  Since the correct values are already defined in the header,
>    switch to using a table with explicit constants rather than shifting the
>    array index.
>    
>    Signed-off-by: John Keeping <john@metanate.com>
>    Signed-off-by: Mark Brown <broonie@kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 64fa05313b0aa4802e0d5be0331eb6cd68baf7a0
>Author: Sachin Pandhare <sachinpandhare@gmail.com>
>Date:   Tue Nov 10 23:38:02 2015 +0530
>
>    ASoC: wm8962: correct addresses for HPF_C_0/1
>    
>    commit e9f96bc53c1b959859599cb30ce6fd4fbb4448c2 upstream.
>    
>    From datasheet:
>    R17408 (4400h) HPF_C_1
>    R17409 (4401h) HPF_C_0
>    17048 -> 17408 (0x4400)
>    17049 -> 17409 (0x4401)
>    
>    Signed-off-by: Sachin Pandhare <sachinpandhare@gmail.com>
>    Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
>    Signed-off-by: Mark Brown <broonie@kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 1c98861e646744157dc97cf24d2d584774521452
>Author: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>Date:   Thu Nov 5 23:53:03 2015 +0000
>
>    ASoC: rsnd: fixup SCU_SYS_INT_EN1 address
>    
>    commit 021c5d9469960b8c68aa1d1825f7bfd8d61e157d upstream.
>    
>    cfcefe0126 ("ASoC: rsnd: add recovery support for under/over flow
>    error on SRC") added SCU_SYS_INT_EN1 address, but it should be
>    0x1d4, not 0x1c4. This patch fixup it.
>    
>    Fixes: cfcefe0126 ("ASoC: rsnd: add recovery support for under/over flow error on SRC")
>    Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>    Signed-off-by: Mark Brown <broonie@kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit b309c8bf5a4a524b30f9e4013828eed9dbea1e5c
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Thu Jan 21 17:19:31 2016 +0100
>
>    ALSA: timer: Handle disconnection more safely
>    
>    commit 230323dac060123c340cf75997971145a42661ee upstream.
>    
>    Currently ALSA timer device doesn't take the disconnection into
>    account very well; it merely unlinks the timer device at disconnection
>    callback but does nothing else.  Because of this, when an application
>    accessing the timer device is disconnected, it may release the
>    resource before actually closed.  In most cases, it results in a
>    warning message indicating a leftover timer instance like:
>       ALSA: timer xxxx is busy?
>    But basically this is an open race.
>    
>    This patch tries to address it.  The strategy is like other ALSA
>    devices: namely,
>    - Manage card's refcount at each open/close
>    - Wake up the pending tasks at disconnection
>    - Check the shutdown flag appropriately at each possible call
>    
>    Note that this patch has one ugly hack to handle the wakeup of pending
>    tasks.  It'd be cleaner to introduce a new disconnect op to
>    snd_timer_instance ops.  But since it would lead to internal ABI
>    breakage and it eventually increase my own work when backporting to
>    stable kernels, I took a different path to implement locally in
>    timer.c.  A cleanup patch will follow at next for 4.5 kernel.
>    
>    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109431
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 2b332719b8f033d77070a4b58e41105b658dc2eb
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Wed Jan 20 17:19:02 2016 +0100
>
>    ALSA: hda - Flush the pending probe work at remove
>    
>    commit 991f86d7ae4e1f8c15806e62f97af519e3cdd860 upstream.
>    
>    As HD-audio driver does deferred probe internally via workqueue, the
>    driver might go into the mixed state doing both probe and remove when
>    the module gets unloaded during the probe work.  This eventually
>    triggers an Oops, unsurprisingly.
>    
>    For avoiding this race, we just need to flush the pending probe work
>    explicitly before actually starting the resource release.
>    
>    Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=960710
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit a63fabd4ac6c29f01fa630e43c1597e8e6680a97
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Mon Jan 18 09:17:30 2016 +0100
>
>    ALSA: hda - Fix bass pin fixup for ASUS N550JX
>    
>    commit db8948e653e12b218058bb6696f4a33fa7845f64 upstream.
>    
>    ASUS N550JX (PCI SSID 1043:13df) requires the same fixup for a bass
>    speaker output pin as other N550 models.
>    
>    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=110001
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit efcf073d7fa1aa1fb2a8d3f3db373e1a5ecbc60a
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Mon Jan 18 14:12:40 2016 +0100
>
>    ALSA: control: Avoid kernel warnings from tlv ioctl with numid 0
>    
>    commit c0bcdbdff3ff73a54161fca3cb8b6cdbd0bb8762 upstream.
>    
>    When a TLV ioctl with numid zero is handled, the driver may spew a
>    kernel warning with a stack trace at each call.  The check was
>    intended obviously only for a kernel driver, but not for a user
>    interaction.  Let's fix it.
>    
>    This was spotted by syzkaller fuzzer.
>    
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 965b1203f399676ac4989a0876336e212a71085b
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Mon Jan 18 13:52:47 2016 +0100
>
>    ALSA: hrtimer: Fix stall by hrtimer_cancel()
>    
>    commit 2ba1fe7a06d3624f9a7586d672b55f08f7c670f3 upstream.
>    
>    hrtimer_cancel() waits for the completion from the callback, thus it
>    must not be called inside the callback itself.  This was already a
>    problem in the past with ALSA hrtimer driver, and the early commit
>    [fcfdebe70759: ALSA: hrtimer - Fix lock-up] tried to address it.
>    
>    However, the previous fix is still insufficient: it may still cause a
>    lockup when the ALSA timer instance reprograms itself in its callback.
>    Then it invokes the start function even in snd_timer_interrupt() that
>    is called in hrtimer callback itself, results in a CPU stall.  This is
>    no hypothetical problem but actually triggered by syzkaller fuzzer.
>    
>    This patch tries to fix the issue again.  Now we call
>    hrtimer_try_to_cancel() at both start and stop functions so that it
>    won't fall into a deadlock, yet giving some chance to cancel the queue
>    if the functions have been called outside the callback.  The proper
>    hrtimer_cancel() is called in anyway at closing, so this should be
>    enough.
>    
>    Reported-and-tested-by: Dmitry Vyukov <dvyukov@google.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 281bedb8728f02a9b8bd5f5e342883e6d255abdc
>Author: Nicolas Boichat <drinkcat@chromium.org>
>Date:   Mon Jan 18 21:35:00 2016 +0800
>
>    ALSA: pcm: Fix snd_pcm_hw_params struct copy in compat mode
>    
>    commit 43c54b8c7cfe22f868a751ba8a59abf1724160b1 upstream.
>    
>    This reverts one hunk of
>    commit ef44a1ec6eee ("ALSA: sound/core: use memdup_user()"), which
>    replaced a number of kmalloc followed by memcpy with memdup calls.
>    
>    In this case, we are copying from a struct snd_pcm_hw_params32 to
>    a struct snd_pcm_hw_params, but the latter is 4 bytes longer than
>    the 32-bit version, so we need to separate kmalloc and copy calls.
>    
>    This actually leads to an out-of-bounds memory access later on
>    in sound/soc/soc-pcm.c:soc_pcm_hw_params() (detected using KASan).
>    
>    Fixes: ef44a1ec6eee ('ALSA: sound/core: use memdup_user()')
>    Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit d1a55757fefff39a7b71305a78c2722d3b9b6529
>Author: Nicolas Boichat <drinkcat@chromium.org>
>Date:   Mon Jan 18 21:35:01 2016 +0800
>
>    ALSA: seq: Fix snd_seq_call_port_info_ioctl in compat mode
>    
>    commit 9586495dc3011a80602329094e746dbce16cb1f1 upstream.
>    
>    This reverts one hunk of
>    commit ef44a1ec6eee ("ALSA: sound/core: use memdup_user()"), which
>    replaced a number of kmalloc followed by memcpy with memdup calls.
>    
>    In this case, we are copying from a struct snd_seq_port_info32 to a
>    struct snd_seq_port_info, but the latter is 4 bytes longer than the
>    32-bit version, so we need to separate kmalloc and copy calls.
>    
>    Fixes: ef44a1ec6eee ('ALSA: sound/core: use memdup_user()')
>    Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit dc5697eb3297920e20b53fdf4c40891e1ed0eafd
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Wed Jan 13 21:35:06 2016 +0100
>
>    ALSA: timer: Fix double unlink of active_list
>    
>    commit ee8413b01045c74340aa13ad5bdf905de32be736 upstream.
>    
>    ALSA timer instance object has a couple of linked lists and they are
>    unlinked unconditionally at snd_timer_stop().  Meanwhile
>    snd_timer_interrupt() unlinks it, but it calls list_del() which leaves
>    the element list itself unchanged.  This ends up with unlinking twice,
>    and it was caught by syzkaller fuzzer.
>    
>    The fix is to use list_del_init() variant properly there, too.
>    
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Tested-by: Dmitry Vyukov <dvyukov@google.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit ac905ca58370789645e813d8abfa5871c93e9e36
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Wed Jan 13 17:48:01 2016 +0100
>
>    ALSA: timer: Fix race among timer ioctls
>    
>    commit af368027a49a751d6ff4ee9e3f9961f35bb4fede upstream.
>    
>    ALSA timer ioctls have an open race and this may lead to a
>    use-after-free of timer instance object.  A simplistic fix is to make
>    each ioctl exclusive.  We have already tread_sem for controlling the
>    tread, and extend this as a global mutex to be applied to each ioctl.
>    
>    The downside is, of course, the worse concurrency.  But these ioctls
>    aren't to be parallel accessible, in anyway, so it should be fine to
>    serialize there.
>    
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Tested-by: Dmitry Vyukov <dvyukov@google.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 042b42c579b94d2e5b53fe208d16dc8fb5dc0b10
>Author: Hui Wang <hui.wang@canonical.com>
>Date:   Wed Jan 13 11:51:38 2016 +0800
>
>    ALSA: hda - fix the headset mic detection problem for a Dell laptop
>    
>    commit 0a1f90a982e85f4921bed606a6b41a24f4de2ae1 upstream.
>    
>    The machine uses codec alc255, and the pin configuration value for
>    pin 0x14 on this machine is 0x90171130 which is not in the pin quirk
>    table yet.
>    
>    BugLink: https://bugs.launchpad.net/bugs/1533461
>    Signed-off-by: Hui Wang <hui.wang@canonical.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 466c99bd815a1ae189d883b509b067c9a74a30f9
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Thu Jan 14 16:30:58 2016 +0100
>
>    ALSA: timer: Harden slave timer list handling
>    
>    commit b5a663aa426f4884c71cd8580adae73f33570f0d upstream.
>    
>    A slave timer instance might be still accessible in a racy way while
>    operating the master instance as it lacks of locking.  Since the
>    master operation is mostly protected with timer->lock, we should cope
>    with it while changing the slave instance, too.  Also, some linked
>    lists (active_list and ack_list) of slave instances aren't unlinked
>    immediately at stopping or closing, and this may lead to unexpected
>    accesses.
>    
>    This patch tries to address these issues.  It adds spin lock of
>    timer->lock (either from master or slave, which is equivalent) in a
>    few places.  For avoiding a deadlock, we ensure that the global
>    slave_active_lock is always locked at first before each timer lock.
>    
>    Also, ack and active_list of slave instances are properly unlinked at
>    snd_timer_stop() and snd_timer_close().
>    
>    Last but not least, remove the superfluous call of _snd_timer_stop()
>    at removing slave links.  This is a noop, and calling it may confuse
>    readers wrt locking.  Further cleanup will follow in a later patch.
>    
>    Actually we've got reports of use-after-free by syzkaller fuzzer, and
>    this hopefully fixes these issues.
>    
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 27b496cc9e8c4cea094806ae1f54059696afabae
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Wed Jan 13 07:20:13 2016 +0100
>
>    ALSA: usb-audio: Fix mixer ctl regression of Native Instrument devices
>    
>    commit c4a359a0049f2e17b012b31e801e96566f6391e5 upstream.
>    
>    The commit [da6d276957ea: ALSA: usb-audio: Add resume support for
>    Native Instruments controls] brought a regression where the Native
>    Instrument audio devices don't get the correct value at update due to
>    the missing shift at writing.  This patch addresses it.
>    
>    Fixes: da6d276957ea ('ALSA: usb-audio: Add resume support for Native Instruments controls')
>    Reported-and-tested-by: Owen Williams <owilliams@mixxx.org>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 6aee1f8440bfd61d8939989197576e1577a01eb9
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Tue Jan 12 21:06:39 2016 +0100
>
>    ALSA: hda - Fix white noise on Dell Latitude E5550
>    
>    commit 98070576c4f77509459c83cd2358617ef0769a38 upstream.
>    
>    Dell Latitude E5550 (1028:062c) has a white noise problem like other
>    Latitude E models, and it gets fixed by the very same quirk as well.
>    
>    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=110591
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 49c9eb3db86407868a664ade6da041fabeb457f8
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Tue Jan 12 15:36:27 2016 +0100
>
>    ALSA: seq: Fix race at timer setup and close
>    
>    commit 3567eb6af614dac436c4b16a8d426f9faed639b3 upstream.
>    
>    ALSA sequencer code has an open race between the timer setup ioctl and
>    the close of the client.  This was triggered by syzkaller fuzzer, and
>    a use-after-free was caught there as a result.
>    
>    This patch papers over it by adding a proper queue->timer_mutex lock
>    around the timer-related calls in the relevant code path.
>    
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Tested-by: Dmitry Vyukov <dvyukov@google.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 9a6003a362acb814fea7422209be344b822b047a
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Tue Jan 12 12:38:02 2016 +0100
>
>    ALSA: seq: Fix missing NULL check at remove_events ioctl
>    
>    commit 030e2c78d3a91dd0d27fef37e91950dde333eba1 upstream.
>    
>    snd_seq_ioctl_remove_events() calls snd_seq_fifo_clear()
>    unconditionally even if there is no FIFO assigned, and this leads to
>    an Oops due to NULL dereference.  The fix is just to add a proper NULL
>    check.
>    
>    Reported-by: Dmitry Vyukov <dvyukov@google.com>
>    Tested-by: Dmitry Vyukov <dvyukov@google.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit aa13585b6672c9d6dc9e0f01de03ef3f8c5622b6
>Author: Jurgen Kramer <gtmkramer@xs4all.nl>
>Date:   Mon Jan 11 08:16:58 2016 +0100
>
>    ALSA: usb: Add native DSD support for Oppo HA-1
>    
>    commit a4eae3a506ea4a7d4474cd74e20b423fa8053d91 upstream.
>    
>    This patch adds native DSD support for the Oppo HA-1. It uses a XMOS chipset
>    but they use their own vendor ID.
>    
>    Signed-off-by: Jurgen Kramer <gtmkramer@xs4all.nl>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 37191bd8b4dd9fa695806687235206ddc30d4761
>Author: Mario Kleiner <mario.kleiner.de@gmail.com>
>Date:   Tue Dec 22 00:45:43 2015 +0100
>
>    ALSA: hda/realtek - Fix silent headphone output on MacPro 4,1 (v2)
>    
>    commit 9f660a1c43890c2cdd1f423fd73654e7ca08fe56 upstream.
>    
>    Without this patch, internal speaker and line-out work,
>    but front headphone output jack stays silent on the
>    Mac Pro 4,1.
>    
>    This code path also gets executed on the MacPro 5,1 due
>    to identical codec SSID, but i don't know if it has any
>    positive or adverse effects there or not.
>    
>    (v2) Implement feedback from Takashi Iwai: Reuse
>         alc889_fixup_mbp_vref and just add a new nid
>         0x19 for the MacPro 4,1.
>    
>    Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit b40f630cfe4d099deca538523542783b79471fc8
>Author: Xiong Zhang <xiong.y.zhang@intel.com>
>Date:   Fri Dec 18 13:29:18 2015 +0800
>
>    ALSA: hda - Set SKL+ hda controller power at freeze() and thaw()
>    
>    commit 3e6db33aaf1d42a30339f831ec4850570d6cc7a3 upstream.
>    
>    It takes three minutes to enter into hibernation on some OEM SKL
>    machines and we see many codec spurious response after thaw() opertion.
>    This is because HDA is still in D0 state after freeze() call and
>    pci_pm_freeze/pci_pm_freeze_noirq() don't set D3 hot in pci_bus driver.
>    It seems bios still access HDA when system enter into freeze state,
>    HDA will receive codec response interrupt immediately after thaw() call.
>    Because of this unexpected interrupt, HDA enter into a abnormal
>    state and slow down the system enter into hibernation.
>    
>    In this patch, we put HDA into D3 hot state in azx_freeze_noirq() and
>    put HDA into D0 state in azx_thaw_noirq().
>    
>    V2: Only apply this fix to SKL+
>        Fix compile error when CONFIG_PM_SLEEP isn't defined
>    
>    [Yet another fix for CONFIG_PM_SLEEP ifdef and the additional comment
>     by tiwai]
>    
>    Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 73a5fdacba1f8cf702e93e66ea9753fa85afc2fc
>Author: Anssi Hannula <anssi.hannula@iki.fi>
>Date:   Sun Dec 13 20:49:59 2015 +0200
>
>    ALSA: usb-audio: Add sample rate inquiry quirk for AudioQuest DragonFly
>    
>    commit 12a6116e66695a728bcb9616416c508ce9c051a1 upstream.
>    
>    Avoid getting sample rate on AudioQuest DragonFly as it is unsupported
>    and causes noisy "cannot get freq at ep 0x1" messages when playback
>    starts.
>    
>    Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 271126c7cbb6c0dabb5eb9dd25e224b53a48f715
>Author: Anssi Hannula <anssi.hannula@iki.fi>
>Date:   Sun Dec 13 20:49:58 2015 +0200
>
>    ALSA: usb-audio: Add a more accurate volume quirk for AudioQuest DragonFly
>    
>    commit 42e3121d90f42e57f6dbd6083dff2f57b3ec7daa upstream.
>    
>    AudioQuest DragonFly DAC reports a volume control range of 0..50
>    (0x0000..0x0032) which in USB Audio means a range of 0 .. 0.2dB, which
>    is obviously incorrect and would cause software using the dB information
>    in e.g. volume sliders to have a massive volume difference in 100..102%
>    range.
>    
>    Commit 2d1cb7f658fb ("ALSA: usb-audio: add dB range mapping for some
>    devices") added a dB range mapping for it with range 0..50 dB.
>    
>    However, the actual volume mapping seems to be neither linear volume nor
>    linear dB scale, but instead quite close to the cubic mapping e.g.
>    alsamixer uses, with a range of approx. -53...0 dB.
>    
>    Replace the previous quirk with a custom dB mapping based on some basic
>    output measurements, using a 10-item range TLV (which will still fit in
>    alsa-lib MAX_TLV_RANGE_SIZE).
>    
>    Tested on AudioQuest DragonFly HW v1.2. The quirk is only applied if the
>    range is 0..50, so if this gets fixed/changed in later HW revisions it
>    will no longer be applied.
>    
>    v2: incorporated Takashi Iwai's suggestion for the quirk application
>    method
>    
>    Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 228a0e09d53a3c9048050f976e90c96ea28a666e
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Tue Dec 15 14:59:58 2015 +0100
>
>    ALSA: hda - Set codec to D3 at reboot/shutdown on Thinkpads
>    
>    commit 70a0976b0c0d90f4246d7e63359d796ec82b87d6 upstream.
>    
>    Lenovo Thinkpads with Realtek codecs may still have some loud
>    crackling noises at reboot/shutdown even though a few previous fixes
>    have been applied.  It's because the previous fix (disabling the
>    default shutup callback) takes effect only at transition of the codec
>    power state.  Meanwhile, at reboot or shutdown, we don't take down the
>    codec power as default, thus it triggers the same problem unless the
>    codec is powered down casually by runtime PM.
>    
>    This patch tries to address the issue.  It gives two things:
>    - implement the separate reboot_notify hook to struct alc_spec, and
>      call it optionally if defined.
>    - turn off the codec to D3 for Thinkpad models via this new callback
>    
>    Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=958439
>    Reported-and-tested-by: Benjamin Poirier <bpoirier@suse.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit be7c9844eea1a34939f808af288b2e59c1510fff
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Thu Dec 10 23:30:43 2015 +0100
>
>    ALSA: hda - Apply click noise workaround for Thinkpads generically
>    
>    commit 157f0b7f6c0cc0bc88647390006e959e267a0143 upstream.
>    
>    It seems that a workaround for Thinkpad T440s crackling noise can be
>    applied generically to all Thinkpad models: namely, disabling the
>    default alc269 shutup callback.  This patch moves it to the existing
>    alc_fixup_tpt440_dock() while also replacing the rest code with
>    another existing alc_fixup_disable_aamix().  It resulted in a good
>    code reduction.
>    
>    Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=958439
>    Reported-and-tested-by: Benjamin Poirier <bpoirier@suse.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit dff55bf1b247c612600ba0855f792bf8c3833952
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Thu Dec 10 12:20:20 2015 +0100
>
>    ALSA: hda - Add a fixup for Thinkpad X1 Carbon 2nd
>    
>    commit b6903c0ed9f0bcbbe88f67f7ed43d1721cbc6235 upstream.
>    
>    Apply the same fixup for Thinkpad with dock to Thinkpad X1 Carbon 2nd,
>    too.  This reduces the annoying loud cracking noise problem, as well
>    as the support of missing docking port.
>    
>    Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=958439
>    Reported-and-tested-by: Benjamin Poirier <bpoirier@suse.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit bc4d35b2c8c7c39b6d69cda22eac15b1d850b71a
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Wed Dec 9 15:17:43 2015 +0100
>
>    ALSA: hda - Fix noise problems on Thinkpad T440s
>    
>    commit 9a811230481243f384b8036c6a558bfdbd961f78 upstream.
>    
>    Lenovo Thinkpad T440s suffers from constant background noises, and it
>    seems to be a generic hardware issue on this model:
>      https://forums.lenovo.com/t5/ThinkPad-T400-T500-and-newer-T/T440s-speaker-noise/td-p/1339883
>    
>    As the noise comes from the analog loopback path, disabling the path
>    is the easy workaround.
>    
>    Also, the machine gives significant cracking noises at PM suspend.  A
>    workaround found by trial-and-error is to disable the shutup callback
>    currently used for ALC269-variant.
>    
>    This patch addresses these noise issues by introducing a new fixup
>    chain.  Although the same workaround might be applicable to other
>    Thinkpad models, it's applied only to T440s (17aa:220c) in this patch,
>    so far, just to be safe (you chicken!).  As a compromise, a new model
>    option string "tp440" is provided now, though, so that owners of other
>    Thinkpad models can test it more easily.
>    
>    Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=958504
>    Reported-and-tested-by: Tim Hardeck <thardeck@suse.de>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit c5e609dc5cab66a6db129d11e5d33be7371624b7
>Author: David Henningsson <david.henningsson@canonical.com>
>Date:   Mon Dec 7 11:29:31 2015 +0100
>
>    ALSA: hda - Add inverted dmic for Packard Bell DOTS
>    
>    commit 02f6ff90400d055f08b0ba0b5f0707630b6faed7 upstream.
>    
>    On the internal mic of the Packard Bell DOTS, one channel
>    has an inverted signal. Add a quirk to fix this up.
>    
>    BugLink: https://bugs.launchpad.net/bugs/1523232
>    Signed-off-by: David Henningsson <david.henningsson@canonical.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit af95ff49d83b6ccb628bc5b7b1caa994fd2a27c9
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Fri Dec 4 16:44:24 2015 +0100
>
>    ALSA: rme96: Fix unexpected volume reset after rate changes
>    
>    commit a74a821624c0c75388a193337babd17a8c02c740 upstream.
>    
>    rme96 driver needs to reset DAC depending on the sample rate, and this
>    results in resetting to the max volume suddenly.  It's because of the
>    missing call of snd_rme96_apply_dac_volume().
>    
>    However, calling this function right after the DAC reset still may not
>    work, and we need some delay before this call.  Since the DAC reset
>    and the procedure after that are performed in the spinlock, we delay
>    the DAC volume restore at the end after the spinlock.
>    
>    Reported-and-tested-by: Sylvain LABOISNE <maeda1@free.fr>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 9bc3da2497b3b21e686175ce2a5bbb15182534fd
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Tue Nov 24 20:02:12 2015 +0100
>
>    ALSA: hda - Fix noise on Gigabyte Z170X mobo
>    
>    commit 0c25ad80408e95e0a4fbaf0056950206e95f726f upstream.
>    
>    Gigabyte Z710X mobo with ALC1150 codec gets significant noises from
>    the analog loopback routes even if their inputs are all muted.
>    Simply kill the aamix for fixing it.
>    
>    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=108301
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 842dd2467a244af77c59b6830a0656fe1d82c8cf
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Thu Nov 19 16:39:50 2015 +0100
>
>    ALSA: hda - Add fixup for Acer Aspire One Cloudbook 14
>    
>    commit b9c2fa52135d49a931c56ed2bfc17d61f771b412 upstream.
>    
>    For making the speakers on Acer Aspire One Cloudbook 14 to work, we
>    need the as same quirk as for another Chromebook.  This patch adds the
>    corresponding fixup entry.
>    
>    Reported-by: Patrick <epictetus@gmail.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 5c7e814c1b3a350ebccde2303fbb4be933315d89
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Mon Nov 9 14:46:35 2015 +0100
>
>    ALSA: hda - Apply HP headphone fixups more generically
>    
>    commit 196543d54574f50e3fd04df4e3048181e006a9da upstream.
>    
>    It turned out that many HP laptops suffer from the same problem as
>    fixed in commit [c932b98c1e47: ALSA: hda - Apply pin fixup for HP
>    ProBook 6550b].  But, it's tiresome to list up all such PCI SSIDs, as
>    there are really lots of HP machines.
>    
>    Instead, we do a bit more clever, try to check the supposedly dock and
>    built-in headphone pins, and apply the fixup when both seem valid.
>    This rule can be applied generically to all models using the same
>    quirk, so we'll fix all in a shot.
>    
>    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=107491
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit c397bc975aa4b205a99b0c651af931537be871e5
>Author: Takashi Sakamoto <o-takashi@sakamocchi.jp>
>Date:   Sun Oct 18 13:46:47 2015 +0900
>
>    ALSA: fireworks/bebob/oxfw/dice: enable to make as built-in
>    
>    commit df4833886f91eea0d20e6e97066adab308625ef8 upstream.
>    
>    When committed to upstream, these four modules had wrong entries for
>    Makefile. This forces them to be loadable modules even if they're set
>    as built-in.
>    
>    This commit fixes this bug.
>    
>    Fixes: b5b04336015e('ALSA: fireworks: Add skelton for Fireworks based devices')
>    Fixes: fd6f4b0dc167('ALSA: bebob: Add skelton for BeBoB based devices')
>    Fixes: 1a4e39c2e5ca('ALSA: oxfw: Move to its own directory')
>    Fixes: 14ff6a094815('ALSA: dice: Move file to its own directory')
>    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 055fb07950beed4e3ee6e0a1d3b50ed84bb29fa5
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Wed Nov 4 22:39:16 2015 +0100
>
>    ALSA: hda - Apply pin fixup for HP ProBook 6550b
>    
>    commit c932b98c1e47312822d911c1bb76e81ef50e389c upstream.
>    
>    HP ProBook 6550b needs the same pin fixup applied to other HP B-series
>    laptops with docks for making its headphone and dock headphone jacks
>    working properly.  We just need to add the codec SSID to the list.
>    
>    Bugzilla: https://bugzilla.kernel.org/attachment.cgi?id=191971
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 29923678a8ef26de4fb186fd0c3b9c817c4b4738
>Author: Alexandra Yates <alexandra.yates@linux.intel.com>
>Date:   Wed Nov 4 15:56:09 2015 -0800
>
>    ALSA: hda - Add Intel Lewisburg device IDs Audio
>    
>    commit 5cf92c8b3dc5da59e05dc81bdc069cedf6f38313 upstream.
>    
>    Adding Intel codename Lewisburg platform device IDs for audio.
>    
>    [rearranged the position by tiwai]
>    
>    Signed-off-by: Alexandra Yates <alexandra.yates@linux.intel.com>
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit e702f5856baa2d68c225662d57c572ea178351b5
>Author: Takashi Iwai <tiwai@suse.de>
>Date:   Tue Oct 27 14:21:51 2015 +0100
>
>    ALSA: hda - Disable 64bit address for Creative HDA controllers
>    
>    commit cadd16ea33a938d49aee99edd4758cc76048b399 upstream.
>    
>    We've had many reports that some Creative sound cards with CA0132
>    don't work well.  Some reported that it starts working after reloading
>    the module, while some reported it starts working when a 32bit kernel
>    is used.  All these facts seem implying that the chip fails to
>    communicate when the buffer is located in 64bit address.
>    
>    This patch addresses these issues by just adding AZX_DCAPS_NO_64BIT
>    flag to the corresponding PCI entries.  I casually had a chance to
>    test an SB Recon3D board, and indeed this seems helping.
>    
>    Although this hasn't been tested on all Creative devices, it's safer
>    to assume that this restriction applies to the rest of them, too.  So
>    the flag is applied to all Creative entries.
>    
>    Signed-off-by: Takashi Iwai <tiwai@suse.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 69bed67bc32fd47774539eaddb9f33420df556fe
>Author: Jan Stancek <jstancek@redhat.com>
>Date:   Tue Dec 8 13:57:51 2015 -0500
>
>    ipmi: move timer init to before irq is setup
>    
>    commit 27f972d3e00b50639deb4cc1392afaeb08d3cecc upstream.
>    
>    We encountered a panic on boot in ipmi_si on a dell per320 due to an
>    uninitialized timer as follows.
>    
>    static int smi_start_processing(void       *send_info,
>                                    ipmi_smi_t intf)
>    {
>            /* Try to claim any interrupts. */
>            if (new_smi->irq_setup)
>                    new_smi->irq_setup(new_smi);
>    
>     --> IRQ arrives here and irq handler tries to modify uninitialized timer
>    
>        which triggers BUG_ON(!timer->function) in __mod_timer().
>    
>     Call Trace:
>       <IRQ>
>       [<ffffffffa0532617>] start_new_msg+0x47/0x80 [ipmi_si]
>       [<ffffffffa053269e>] start_check_enables+0x4e/0x60 [ipmi_si]
>       [<ffffffffa0532bd8>] smi_event_handler+0x1e8/0x640 [ipmi_si]
>       [<ffffffff810f5584>] ? __rcu_process_callbacks+0x54/0x350
>       [<ffffffffa053327c>] si_irq_handler+0x3c/0x60 [ipmi_si]
>       [<ffffffff810efaf0>] handle_IRQ_event+0x60/0x170
>       [<ffffffff810f245e>] handle_edge_irq+0xde/0x180
>       [<ffffffff8100fc59>] handle_irq+0x49/0xa0
>       [<ffffffff8154643c>] do_IRQ+0x6c/0xf0
>       [<ffffffff8100ba53>] ret_from_intr+0x0/0x11
>    
>            /* Set up the timer that drives the interface. */
>            setup_timer(&new_smi->si_timer, smi_timeout, (long)new_smi);
>    
>    The following patch fixes the problem.
>    
>    To: Openipmi-developer@lists.sourceforge.net
>    To: Corey Minyard <minyard@acm.org>
>    CC: linux-kernel@vger.kernel.org
>    
>    Signed-off-by: Jan Stancek <jstancek@redhat.com>
>    Signed-off-by: Tony Camuso <tcamuso@redhat.com>
>    Signed-off-by: Corey Minyard <cminyard@mvista.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 8dfca273353b9131dfd82c2720ccd78f89fd44ae
>Author: Corey Minyard <cminyard@mvista.com>
>Date:   Sat Sep 5 17:44:13 2015 -0500
>
>    ipmi: Start the timer and thread on internal msgs
>    
>    commit 0cfec916e86d881e209de4b4ae9959a6271e6660 upstream.
>    
>    The timer and thread were not being started for internal messages,
>    so in interrupt mode if something hung the timer would never go
>    off and clean things up.  Factor out the internal message sending
>    and start the timer for those messages, too.
>    
>    Signed-off-by: Corey Minyard <cminyard@mvista.com>
>    Tested-by: Gouji, Masayuki <gouji.masayuki@jp.fujitsu.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit c1a631b482a7b3cc5a78daa8f5babf28e67d4dc6
>Author: Andy Lutomirski <luto@kernel.org>
>Date:   Tue Jan 12 12:47:40 2016 -0800
>
>    x86/mm: Improve switch_mm() barrier comments
>    
>    commit 4eaffdd5a5fe6ff9f95e1ab4de1ac904d5e0fa8b upstream.
>    
>    My previous comments were still a bit confusing and there was a
>    typo. Fix it up.
>    
>    Reported-by: Peter Zijlstra <peterz@infradead.org>
>    Signed-off-by: Andy Lutomirski <luto@kernel.org>
>    Cc: Andy Lutomirski <luto@amacapital.net>
>    Cc: Borislav Petkov <bp@alien8.de>
>    Cc: Brian Gerst <brgerst@gmail.com>
>    Cc: Dave Hansen <dave.hansen@linux.intel.com>
>    Cc: Denys Vlasenko <dvlasenk@redhat.com>
>    Cc: H. Peter Anvin <hpa@zytor.com>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Rik van Riel <riel@redhat.com>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Fixes: 71b3c126e611 ("x86/mm: Add barriers and document switch_mm()-vs-flush synchronization")
>    Link: http://lkml.kernel.org/r/0a0b43cdcdd241c5faaaecfbcc91a155ddedc9a1.1452631609.git.luto@kernel.org
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit ae535caf02c7e2e7feec62f4e07ac1f48ad5b336
>Author: Andy Lutomirski <luto@kernel.org>
>Date:   Wed Jan 6 12:21:01 2016 -0800
>
>    x86/mm: Add barriers and document switch_mm()-vs-flush synchronization
>    
>    commit 71b3c126e61177eb693423f2e18a1914205b165e upstream.
>    
>    When switch_mm() activates a new PGD, it also sets a bit that
>    tells other CPUs that the PGD is in use so that TLB flush IPIs
>    will be sent.  In order for that to work correctly, the bit
>    needs to be visible prior to loading the PGD and therefore
>    starting to fill the local TLB.
>    
>    Document all the barriers that make this work correctly and add
>    a couple that were missing.
>    
>    Signed-off-by: Andy Lutomirski <luto@kernel.org>
>    Cc: Andrew Morton <akpm@linux-foundation.org>
>    Cc: Andy Lutomirski <luto@amacapital.net>
>    Cc: Borislav Petkov <bp@alien8.de>
>    Cc: Brian Gerst <brgerst@gmail.com>
>    Cc: Dave Hansen <dave.hansen@linux.intel.com>
>    Cc: Denys Vlasenko <dvlasenk@redhat.com>
>    Cc: H. Peter Anvin <hpa@zytor.com>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Rik van Riel <riel@redhat.com>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Cc: linux-mm@kvack.org
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 4b6c3a55305de01d24d994d16ff7dc3dfaee2715
>Author: H.J. Lu <hjl.tools@gmail.com>
>Date:   Mon Jan 4 10:17:09 2016 -0800
>
>    x86/boot: Double BOOT_HEAP_SIZE to 64KB
>    
>    commit 8c31902cffc4d716450be549c66a67a8a3dd479c upstream.
>    
>    When decompressing kernel image during x86 bootup, malloc memory
>    for ELF program headers may run out of heap space, which leads
>    to system halt.  This patch doubles BOOT_HEAP_SIZE to 64KB.
>    
>    Tested with 32-bit kernel which failed to boot without this patch.
>    
>    Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
>    Acked-by: H. Peter Anvin <hpa@zytor.com>
>    Cc: Andy Lutomirski <luto@amacapital.net>
>    Cc: Borislav Petkov <bp@alien8.de>
>    Cc: Brian Gerst <brgerst@gmail.com>
>    Cc: Denys Vlasenko <dvlasenk@redhat.com>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Cc: linux-kernel@vger.kernel.org
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit eec2baa864792fc7d6b396b1934c83dad759905d
>Author: Mario Kleiner <mario.kleiner.de@gmail.com>
>Date:   Fri Dec 18 20:24:06 2015 +0100
>
>    x86/reboot/quirks: Add iMac10,1 to pci_reboot_dmi_table[]
>    
>    commit 2f0c0b2d96b1205efb14347009748d786c2d9ba5 upstream.
>    
>    Without the reboot=pci method, the iMac 10,1 simply
>    hangs after printing "Restarting system" at the point
>    when it should reboot. This fixes it.
>    
>    Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
>    Cc: Andy Lutomirski <luto@amacapital.net>
>    Cc: Borislav Petkov <bp@alien8.de>
>    Cc: Brian Gerst <brgerst@gmail.com>
>    Cc: Dave Jones <davej@codemonkey.org.uk>
>    Cc: Denys Vlasenko <dvlasenk@redhat.com>
>    Cc: H. Peter Anvin <hpa@zytor.com>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Link: http://lkml.kernel.org/r/1450466646-26663-1-git-send-email-mario.kleiner.de@gmail.com
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 17f33d468f4dfbfd5e4c8782f5e26a0863167a66
>Author: Paolo Bonzini <pbonzini@redhat.com>
>Date:   Thu Nov 12 16:42:18 2015 +0100
>
>    KVM: x86: correctly print #AC in traces
>    
>    commit aba2f06c070f604e388cf77b1dcc7f4cf4577eb0 upstream.
>    
>    Poor #AC was so unimportant until a few days ago that we were
>    not even tracing its name correctly.  But now it's all over
>    the place.
>    
>    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 8a3185c54d650a86dafc8d8bcafa124b50944315
>Author: Paolo Bonzini <pbonzini@redhat.com>
>Date:   Thu Nov 12 14:49:17 2015 +0100
>
>    KVM: x86: expose MSR_TSC_AUX to userspace
>    
>    commit 9dbe6cf941a6fe82933aef565e4095fb10f65023 upstream.
>    
>    If we do not do this, it is not properly saved and restored across
>    migration.  Windows notices due to its self-protection mechanisms,
>    and is very upset about it (blue screen of death).
>    
>    Cc: Radim Krcmar <rkrcmar@redhat.com>
>    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit e052d6eeedf13ad69db1686b0b49fb9192519d9e
>Author: Paul Mackerras <paulus@ozlabs.org>
>Date:   Thu Nov 12 16:43:02 2015 +1100
>
>    KVM: PPC: Book3S HV: Prohibit setting illegal transaction state in MSR
>    
>    commit c20875a3e638e4a03e099b343ec798edd1af5cc6 upstream.
>    
>    Currently it is possible for userspace (e.g. QEMU) to set a value
>    for the MSR for a guest VCPU which has both of the TS bits set,
>    which is an illegal combination.  The result of this is that when
>    we execute a hrfid (hypervisor return from interrupt doubleword)
>    instruction to enter the guest, the CPU will take a TM Bad Thing
>    type of program interrupt (vector 0x700).
>    
>    Now, if PR KVM is configured in the kernel along with HV KVM, we
>    actually handle this without crashing the host or giving hypervisor
>    privilege to the guest; instead what happens is that we deliver a
>    program interrupt to the guest, with SRR0 reflecting the address
>    of the hrfid instruction and SRR1 containing the MSR value at that
>    point.  If PR KVM is not configured in the kernel, then we try to
>    run the host's program interrupt handler with the MMU set to the
>    guest context, which almost certainly causes a host crash.
>    
>    This closes the hole by making kvmppc_set_msr_hv() check for the
>    illegal combination and force the TS field to a safe value (00,
>    meaning non-transactional).
>    
>    Signed-off-by: Paul Mackerras <paulus@samba.org>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 19eaffefc4b03d92e0adfd1870b10b9539916106
>Author: Paolo Bonzini <pbonzini@redhat.com>
>Date:   Tue Nov 10 09:14:39 2015 +0100
>
>    KVM: svm: unconditionally intercept #DB
>    
>    commit cbdb967af3d54993f5814f1cee0ed311a055377d upstream.
>    
>    This is needed to avoid the possibility that the guest triggers
>    an infinite stream of #DB exceptions (CVE-2015-8104).
>    
>    VMX is not affected: because it does not save DR6 in the VMCS,
>    it already intercepts #DB unconditionally.
>    
>    Reported-by: Jan Beulich <jbeulich@suse.com>
>    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit 03e572f3dda7f5790930df631a3f013f4100558b
>Author: Radim KrÄmÃ¡Å <rkrcmar@redhat.com>
>Date:   Mon Nov 2 22:20:00 2015 +0100
>
>    KVM: VMX: fix SMEP and SMAP without EPT
>    
>    commit 656ec4a4928a3db7d16e5cb9bce351a478cfd3d5 upstream.
>    
>    The comment in code had it mostly right, but we enable paging for
>    emulated real mode regardless of EPT.
>    
>    Without EPT (which implies emulated real mode), secondary VCPUs won't
>    start unless we disable SM[AE]P when the guest doesn't use paging.
>    
>    Signed-off-by: Radim KrÄmÃ¡Å <rkrcmar@redhat.com>
>    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit c12a3752a390994ad5e3b987f123ffe24143ad48
>Author: Ouyang Zhaowei (Charles) <ouyangzhaowei@huawei.com>
>Date:   Wed May 6 09:47:04 2015 +0800
>
>    x86/xen: don't reset vcpu_info on a cancelled suspend
>    
>    commit 6a1f513776b78c994045287073e55bae44ed9f8c upstream.
>    
>    On a cancelled suspend the vcpu_info location does not change (it's
>    still in the per-cpu area registered by xen_vcpu_setup()).  So do not
>    call xen_hvm_init_shared_info() which would make the kernel think its
>    back in the shared info.  With the wrong vcpu_info, events cannot be
>    received and the domain will hang after a cancelled suspend.
>    
>    Signed-off-by: Charles Ouyang <ouyangzhaowei@huawei.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 702d87e2ff77d75c8ba8783510b71c68eef644f3
>Author: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>Date:   Tue Nov 10 15:10:33 2015 -0500
>
>    xen/gntdev: Grant maps should not be subject to NUMA balancing
>    
>    commit 9c17d96500f78d7ecdb71ca6942830158bc75a2b upstream.
>    
>    Doing so will cause the grant to be unmapped and then, during
>    fault handling, the fault to be mistakenly treated as NUMA hint
>    fault.
>    
>    In addition, even if those maps could partcipate in NUMA
>    balancing, it wouldn't provide any benefit since we are unable
>    to determine physical page's node (even if/when VNUMA is
>    implemented).
>    
>    Marking grant maps' VMAs as VM_IO will exclude them from being
>    part of NUMA balancing.
>    
>    Signed-off-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 3ab6a090acfb20dfa49979d21c0a110019ad381f
>Author: Dmitry V. Levin <ldv@altlinux.org>
>Date:   Tue Dec 1 00:54:36 2015 +0300
>
>    x86/signal: Fix restart_syscall number for x32 tasks
>    
>    commit 22eab1108781eff09961ae7001704f7bd8fb1dce upstream.
>    
>    When restarting a syscall with regs->ax == -ERESTART_RESTARTBLOCK,
>    regs->ax is assigned to a restart_syscall number.  For x32 tasks, this
>    syscall number must have __X32_SYSCALL_BIT set, otherwise it will be
>    an x86_64 syscall number instead of a valid x32 syscall number. This
>    issue has been there since the introduction of x32.
>    
>    Reported-by: strace/tests/restart_syscall.test
>    Reported-and-tested-by: Elvira Khabirova <lineprinter0@gmail.com>
>    Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
>    Cc: Elvira Khabirova <lineprinter0@gmail.com>
>    Link: http://lkml.kernel.org/r/20151130215436.GA25996@altlinux.org
>    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>commit c24eedeca7b86abc1719f1705de671cee8853b8d
>Author: Dave Hansen <dave.hansen@linux.intel.com>
>Date:   Mon Nov 30 16:31:13 2015 -0800
>
>    x86/mpx: Fix instruction decoder condition
>    
>    commit 8e8efe0379bd93e8219ca0fc6fa80b5dd85b09cb upstream.
>    
>    MPX decodes instructions in order to tell which bounds register
>    was violated.  Part of this decoding involves looking at the "REX
>    prefix" which is a special instrucion prefix used to retrofit
>    support for new registers in to old instructions.
>    
>    The X86_REX_*() macros are defined to return actual bit values:
>    
>    	#define X86_REX_R(rex) ((rex) & 4)
>    
>    *not* boolean values.  However, the MPX code was checking for
>    them like they were booleans.  This might have led to us
>    mis-decoding the "REX prefix" and giving false information out to
>    userspace about bounds violations.  X86_REX_B() actually is bit 1,
>    so this is really only broken for the X86_REX_X() case.
>    
>    Fix the conditionals up to tolerate the non-boolean values.
>    
>    Fixes: fcc7ffd67991 "x86, mpx: Decode MPX instruction to get bound violation information"
>    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
>    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
>    Cc: x86@kernel.org
>    Cc: Dave Hansen <dave@sr71.net>
>    Link: http://lkml.kernel.org/r/20151201003113.D800C1E0@viggo.jf.intel.com
>    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Actions: View

Attachments on bug 41058: 8079