commit 2e9f201da63e83205973e093bd58c3ede6c8d862
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Thu Sep 29 11:29:36 2016 +0200

    Linux 3.12.64

commit f0cbef458ac3d7575397295568507a9b45d5a858
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Sat Sep 17 12:57:24 2016 -0700

    openrisc: fix the fix of copy_from_user()
    
    commit 8e4b72054f554967827e18be1de0e8122e6efc04 upstream.
    
    Since commit acb2505d0119 ("openrisc: fix copy_from_user()"),
    copy_from_user() returns the number of bytes requested, not the
    number of bytes not copied.
    
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Fixes: acb2505d0119 ("openrisc: fix copy_from_user()")
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit fa1709570d8087a4c0e330be876e242ba6b8a7e3
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Sat Sep 17 07:52:49 2016 -0700

    avr32: fix 'undefined reference to `___copy_from_user'
    
    commit 65c0044ca8d7c7bbccae37f0ff2972f0210e9f41 upstream.
    
    avr32 builds fail with:
    
    arch/avr32/kernel/built-in.o: In function `arch_ptrace':
    (.text+0x650): undefined reference to `___copy_from_user'
    arch/avr32/kernel/built-in.o:(___ksymtab+___copy_from_user+0x0): undefined
    reference to `___copy_from_user'
    kernel/built-in.o: In function `proc_doulongvec_ms_jiffies_minmax':
    (.text+0x5dd8): undefined reference to `___copy_from_user'
    kernel/built-in.o: In function `proc_dointvec_minmax_sysadmin':
    sysctl.c:(.text+0x6174): undefined reference to `___copy_from_user'
    kernel/built-in.o: In function `ptrace_has_cap':
    ptrace.c:(.text+0x69c0): undefined reference to `___copy_from_user'
    kernel/built-in.o:ptrace.c:(.text+0x6b90): more undefined references to
    `___copy_from_user' follow
    
    Fixes: 8630c32275ba ("avr32: fix copy_from_user()")
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Acked-by: Havard Skinnemoen <hskinnemoen@gmail.com>
    Acked-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit c9a55e4ae3dbbc72eb6d7f9faf91e914b5f7f90f
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Thu Aug 18 21:31:41 2016 -0400

    ia64: copy_from_user() should zero the destination on access_ok() failure
    
    commit a5e541f796f17228793694d64b507f5f57db4cd7 upstream.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit cf0d095b6a8bbb53ce5d9940d0868bcf5b8ca00d
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sun Aug 21 19:16:26 2016 -0400

    ppc32: fix copy_from_user()
    
    commit 224264657b8b228f949b42346e09ed8c90136a8e upstream.
    
    should clear on access_ok() failures.  Also remove the useless
    range truncation logics.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 0ed3b0d5028684292100726687b725d541e5a34e
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Mon Aug 22 00:23:07 2016 -0400

    sparc32: fix copy_from_user()
    
    commit 917400cecb4b52b5cde5417348322bb9c8272fa6 upstream.
    
    Acked-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit b8d635cfa41503774d0655d2ad09b12e444167bd
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sat Aug 20 16:33:10 2016 -0400

    mn10300: copy_from_user() should zero on access_ok() failure...
    
    commit ae7cc577ec2a4a6151c9e928fd1f595d953ecef1 upstream.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 0ab16ba1cdfed30d4b96f723fad6aa1342fa6513
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sat Aug 20 17:05:21 2016 -0400

    openrisc: fix copy_from_user()
    
    commit acb2505d0119033a80c85ac8d02dccae41271667 upstream.
    
    ... that should zero on faults.  Also remove the <censored> helpful
    logics wrt range truncation copied from ppc32.  Where it had ever
    been needed only in case of copy_from_user() *and* had not been merged
    into the mainline until a month after the need had disappeared.
    A decade before openrisc went into mainline, I might add...
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 503b87d3d3f77158e2879b4221f3cc38cef6faf6
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sat Aug 20 19:03:37 2016 -0400

    parisc: fix copy_from_user()
    
    commit aace880feea38875fbc919761b77e5732a3659ef upstream.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit dedf843d4ba72e5a1e0a1c05e173c80a0281625a
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Thu Aug 18 22:08:20 2016 -0400

    metag: copy_from_user() should zero the destination on access_ok() failure
    
    commit 8ae95ed4ae5fc7c3391ed668b2014c9e2079533b upstream.
    
    Acked-by: James Hogan <james.hogan@imgtec.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 1bca0d9f93a0578062fe9b98e04320966582de53
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Wed Aug 17 16:02:32 2016 -0400

    alpha: fix copy_from_user()
    
    commit 2561d309dfd1555e781484af757ed0115035ddb3 upstream.
    
    it should clear the destination even when access_ok() fails.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 6153b7f59b8461742da1fd17533bca4d46fe8b0a
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Wed Aug 17 16:36:37 2016 -0400

    asm-generic: make copy_from_user() zero the destination properly
    
    commit 2545e5da080b4839dd859e3b09343a884f6ab0e3 upstream.
    
    ... in all cases, including the failing access_ok()
    
    Note that some architectures using asm-generic/uaccess.h have
    __copy_from_user() not zeroing the tail on failure halfway
    through.  This variant works either way.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit d41370b5c3b2e69b65ec76b217e39f602193f26c
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sat Aug 20 16:18:53 2016 -0400

    mips: copy_from_user() must zero the destination on access_ok() failure
    
    commit e69d700535ac43a18032b3c399c69bf4639e89a2 upstream.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a85bf48e05efd12abccc475f987204caef459be4
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Thu Aug 18 21:16:49 2016 -0400

    hexagon: fix strncpy_from_user() error return
    
    commit f35c1e0671728d1c9abc405d05ef548b5fcb2fc4 upstream.
    
    It's -EFAULT, not -1 (and contrary to the comment in there,
    __strnlen_user() can return 0 - on faults).
    
    Acked-by: Richard Kuo <rkuo@codeaurora.org>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 49e361884efedb0786751217b0da7f78c263265e
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sun Aug 21 23:39:47 2016 -0400

    sh: fix copy_from_user()
    
    commit 6e050503a150b2126620c1a1e9b3a368fcd51eac upstream.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 20f17babfafe6641a200b49b572e61464c475a99
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sun Aug 21 22:30:44 2016 -0400

    score: fix copy_from_user() and friends
    
    commit b615e3c74621e06cd97f86373ca90d43d6d998aa upstream.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit d7a9ffa0e56b2d5dd24fb9949c4d045111515aa5
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Fri Sep 9 19:16:58 2016 -0400

    blackfin: fix copy_from_user()
    
    commit 8f035983dd826d7e04f67b28acf8e2f08c347e41 upstream.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit f78d413ad9adc66888da0660bce02a6c455e3edd
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Thu Aug 18 19:34:00 2016 -0400

    cris: buggered copy_from_user/copy_to_user/clear_user
    
    commit eb47e0293baaa3044022059f1fa9ff474bfe35cb upstream.
    
    * copy_from_user() on access_ok() failure ought to zero the destination
    * none of those primitives should skip the access_ok() check in case of
    small constant size.
    
    Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit ba2540d8680b26475e48bbf527eea6d70fcc1ad2
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Thu Aug 18 20:54:02 2016 -0400

    frv: fix clear_user()
    
    commit 3b8767a8f00cc6538ba6b1cf0f88502e2fd2eb90 upstream.
    
    It should check access_ok().  Otherwise a bunch of places turn into
    trivially exploitable rootholes.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 1334047d29ad3e40fee3bb6bdb75e1707739ad01
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Wed Aug 17 23:19:01 2016 -0400

    asm-generic: make get_user() clear the destination on errors
    
    commit 9ad18b75c2f6e4a78ce204e79f37781f8815c0fa upstream.
    
    both for access_ok() failures and for faults halfway through
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 27f32d12e690e61a9b356f84e54f496a2cb64f6e
Author: Vineet Gupta <Vineet.Gupta1@synopsys.com>
Date:   Fri Aug 19 12:10:02 2016 -0700

    ARC: uaccess: get_user to zero out dest in cause of fault
    
    commit 05d9d0b96e53c52a113fd783c0c97c830c8dc7af upstream.
    
    Al reported potential issue with ARC get_user() as it wasn't clearing
    out destination pointer in case of fault due to bad address etc.
    
    Verified using following
    
    | {
    |       u32 bogus1 = 0xdeadbeef;
    |       u64 bogus2 = 0xdead;
    |       int rc1, rc2;
    |
    |       pr_info("Orig values %x %llx\n", bogus1, bogus2);
    |       rc1 = get_user(bogus1, (u32 __user *)0x40000000);
    |       rc2 = get_user(bogus2, (u64 __user *)0x50000000);
    |       pr_info("access %d %d, new values %x %llx\n",
    |               rc1, rc2, bogus1, bogus2);
    | }
    
    | [ARCLinux]# insmod /mnt/kernel-module/qtn.ko
    | Orig values deadbeef dead
    | access -14 -14, new values 0 0
    
    Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: linux-snps-arc@lists.infradead.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 1cdd2edb8f7ec2fa7f87154bfe5499021fac7bcb
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sun Aug 21 22:00:54 2016 -0400

    s390: get_user() should zero on failure
    
    commit fd2d2b191fe75825c4c7a6f12f3fef35aaed7dd7 upstream.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 9931f8fe5e1b606ea031df159044b4be0983f078
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sun Aug 21 22:13:39 2016 -0400

    score: fix __get_user/get_user
    
    commit c2f18fa4cbb3ad92e033a24efa27583978ce9600 upstream.
    
    * should zero on any failure
    * __get_user() should use __copy_from_user(), not copy_from_user()
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit b5687db2c83a4a83a910fc255583cf4be6669a93
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sun Aug 21 23:33:47 2016 -0400

    sh64: failing __get_user() should zero
    
    commit c6852389228df9fb3067f94f3b651de2a7921b36 upstream.
    
    It could be done in exception-handling bits in __get_user_b() et.al.,
    but the surgery involved would take more knowledge of sh64 details
    than I have or _want_ to have.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 92fe4f77cb343044fcefff6a3ddac59c20d7afe1
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Fri Sep 9 19:20:13 2016 -0400

    m32r: fix __get_user()
    
    commit c90a3bc5061d57e7931a9b7ad14784e1a0ed497d upstream.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 9309c7dd3bfc356a4385dd8bc0c310880773e9b6
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sat Aug 20 16:32:02 2016 -0400

    mn10300: failing __get_user() and get_user() should zero
    
    commit 43403eabf558d2800b429cd886e996fd555aa542 upstream.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit d42924ab1ec523c0671f5560d51750996be31d3a
Author: Al Viro <viro@ZenIV.linux.org.uk>
Date:   Thu Sep 15 02:35:29 2016 +0100

    fix minor infoleak in get_user_ex()
    
    commit 1c109fabbd51863475cd12ac206bdd249aee35af upstream.
    
    get_user_ex(x, ptr) should zero x on failure.  It's not a lot of a leak
    (at most we are leaking uninitialized 64bit value off the kernel stack,
    and in a fairly constrained situation, at that), but the fix is trivial,
    so...
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    [ This sat in different branch from the uaccess fixes since mid-August ]
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 2338cc7a51dfe7e2f8d3fe7911dc7a5f8e4b6c99
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Fri Sep 9 19:22:34 2016 -0400

    microblaze: fix copy_from_user()
    
    commit d0cf385160c12abd109746cad1f13e3b3e8b50b8 upstream.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 93f38d00f990ab67306e5cfafa0c0c28e80ff81d
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Fri Sep 9 19:28:23 2016 -0400

    avr32: fix copy_from_user()
    
    commit 8630c32275bac2de6ffb8aea9d9b11663e7ad28e upstream.
    
    really ugly, but apparently avr32 compilers turns access_ok() into
    something so bad that they want it in assembler.  Left that way,
    zeroing added in inline wrapper.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 2c3d357188859f8ee773aefb40551c3b402b8599
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Fri Sep 9 19:23:33 2016 -0400

    microblaze: fix __get_user()
    
    commit e98b9e37ae04562d52c96f46b3cf4c2e80222dc1 upstream.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 8d6f6eb1a459ec5ca3750a3f49d7f6130de6df13
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Thu Sep 1 14:25:43 2016 +0100

    crypto: cryptd - initialize child shash_desc on import
    
    commit 0bd2223594a4dcddc1e34b15774a3a4776f7749e upstream.
    
    When calling .import() on a cryptd ahash_request, the structure members
    that describe the child transform in the shash_desc need to be initialized
    like they are when calling .init()
    
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit e5eb7be2db286ec3fdaf5cf5451e653d6a6d95b8
Author: Will Deacon <will.deacon@arm.com>
Date:   Mon Sep 5 11:56:05 2016 +0100

    arm64: spinlocks: implement smp_mb__before_spinlock() as smp_mb()
    
    commit 872c63fbf9e153146b07f0cece4da0d70b283eeb upstream.
    
    smp_mb__before_spinlock() is intended to upgrade a spin_lock() operation
    to a full barrier, such that prior stores are ordered with respect to
    loads and stores occuring inside the critical section.
    
    Unfortunately, the core code defines the barrier as smp_wmb(), which
    is insufficient to provide the required ordering guarantees when used in
    conjunction with our load-acquire-based spinlock implementation.
    
    This patch overrides the arm64 definition of smp_mb__before_spinlock()
    to map to a full smp_mb().
    
    Cc: Peter Zijlstra <peterz@infradead.org>
    Reported-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit f23a0f229e0f46d823234a8e6b761445ef08a2a3
Author: Sebastian Reichel <sre@kernel.org>
Date:   Fri Jun 24 03:59:33 2016 +0200

    ARM: OMAP3: hwmod data: Add sysc information for DSI
    
    commit b46211d6dcfb81a8af66b8684a42d629183670d4 upstream.
    
    Add missing sysconfig/sysstatus information
    to OMAP3 hwmod. The information has been
    checked against OMAP34xx and OMAP36xx TRM.
    
    Without this change DSI block is not reset
    during boot, which is required for working
    Nokia N950 display.
    
    Signed-off-by: Sebastian Reichel <sre@kernel.org>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit ece4b3b57a90b381ccbdb8722ed28dd9fc52fbe0
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Fri Sep 16 10:24:26 2016 -0400

    USB: change bInterval default to 10 ms
    
    commit 08c5cd37480f59ea39682f4585d92269be6b1424 upstream.
    
    Some full-speed mceusb infrared transceivers contain invalid endpoint
    descriptors for their interrupt endpoints, with bInterval set to 0.
    In the past they have worked out okay with the mceusb driver, because
    the driver sets the bInterval field in the descriptor to 1,
    overwriting whatever value may have been there before.  However, this
    approach was never sanctioned by the USB core, and in fact it does not
    work with xHCI controllers, because they use the bInterval value that
    was present when the configuration was installed.
    
    Currently usbcore uses 32 ms as the default interval if the value in
    the endpoint descriptor is invalid.  It turns out that these IR
    transceivers don't work properly unless the interval is set to 10 ms
    or below.  To work around this mceusb problem, this patch changes the
    endpoint-descriptor parsing routine, making the default interval value
    be 10 ms rather than 32 ms.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Tested-by: Wade Berrier <wberrier@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 902d1e9ecd4161ace2c10eb0e7e3a5bba95a9000
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Mon Aug 29 18:00:38 2016 +0900

    usb: renesas_usbhs: fix clearing the {BRDY,BEMP}STS condition
    
    commit 519d8bd4b5d3d82c413eac5bb42b106bb4b9ec15 upstream.
    
    The previous driver is possible to stop the transfer wrongly.
    For example:
     1) An interrupt happens, but not BRDY interruption.
     2) Read INTSTS0. And than state->intsts0 is not set to BRDY.
     3) BRDY is set to 1 here.
     4) Read BRDYSTS.
     5) Clear the BRDYSTS. And then. the BRDY is cleared wrongly.
    
    Remarks:
     - The INTSTS0.BRDY is read only.
      - If any bits of BRDYSTS are set to 1, the BRDY is set to 1.
      - If BRDYSTS is 0, the BRDY is set to 0.
    
    So, this patch adds condition to avoid such situation. (And about
    NRDYSTS, this is not used for now. But, avoiding any side effects,
    this patch doesn't touch it.)
    
    Fixes: d5c6a1e024dd ("usb: renesas_usbhs: fixup interrupt status clear method")
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 399c48c62021f9ce838eb7f7cf9aa2aec8a876fc
Author: Daniele Palmas <dnlplm@gmail.com>
Date:   Fri Sep 2 10:37:56 2016 +0200

    USB: serial: simple: add support for another Infineon flashloader
    
    commit f190fd92458da3e869b4e2c6289e2c617490ae53 upstream.
    
    This patch adds support for Infineon flashloader 0x8087/0x0801.
    
    The flashloader is used in Telit LE940B modem family with Telit
    flashing application.
    
    Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 2f8c95d916594d62694807666fae72335e302fae
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Thu Sep 1 11:44:35 2016 +0200

    iio: accel: kxsd9: Fix scaling bug
    
    commit 307fe9dd11ae44d4f8881ee449a7cbac36e1f5de upstream.
    
    All the scaling of the KXSD9 involves multiplication with a
    fraction number < 1.
    
    However the scaling value returned from IIO_INFO_SCALE was
    unpredictable as only the micros of the value was assigned, and
    not the integer part, resulting in scaling like this:
    
    $cat in_accel_scale
    -1057462640.011978
    
    Fix this by assigning zero to the integer part.
    
    Tested-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 523e1dd7c34ecd807bd7fef25f8ef0c46c3245a9
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Tue Aug 16 15:33:28 2016 +0200

    iio: accel: kxsd9: Fix raw read return
    
    commit 7ac61a062f3147dc23e3f12b9dfe7c4dd35f9cb8 upstream.
    
    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.
    
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit da1fef7414b439fac08169b4f0c7554ba3c668aa
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Thu Sep 8 16:25:49 2016 +0100

    kvm-arm: Unmap shadow pagetables properly
    
    commit 293f293637b55db4f9f522a5a72514e98a541076 upstream.
    
    On arm/arm64, we depend on the kvm_unmap_hva* callbacks (via
    mmu_notifiers::invalidate_*) to unmap the stage2 pagetables when
    the userspace buffer gets unmapped. However, when the Hypervisor
    process exits without explicit unmap of the guest buffers, the only
    notifier we get is kvm_arch_flush_shadow_all() (via mmu_notifier::release
    ) which does nothing on arm. Later this causes us to access pages that
    were already released [via exit_mmap() -> unmap_vmas()] when we actually
    get to unmap the stage2 pagetable [via kvm_arch_destroy_vm() ->
    kvm_free_stage2_pgd()]. This triggers crashes with CONFIG_DEBUG_PAGEALLOC,
    which unmaps any free'd pages from the linear map.
    
     [  757.644120] Unable to handle kernel paging request at virtual address
      ffff800661e00000
     [  757.652046] pgd = ffff20000b1a2000
     [  757.655471] [ffff800661e00000] *pgd=00000047fffe3003, *pud=00000047fcd8c003,
      *pmd=00000047fcc7c003, *pte=00e8004661e00712
     [  757.666492] Internal error: Oops: 96000147 [#3] PREEMPT SMP
     [  757.672041] Modules linked in:
     [  757.675100] CPU: 7 PID: 3630 Comm: qemu-system-aar Tainted: G      D
     4.8.0-rc1 #3
     [  757.683240] Hardware name: AppliedMicro X-Gene Mustang Board/X-Gene Mustang Board,
      BIOS 3.06.15 Aug 19 2016
     [  757.692938] task: ffff80069cdd3580 task.stack: ffff8006adb7c000
     [  757.698840] PC is at __flush_dcache_area+0x1c/0x40
     [  757.703613] LR is at kvm_flush_dcache_pmd+0x60/0x70
     [  757.708469] pc : [<ffff20000809dbdc>] lr : [<ffff2000080b4a70>] pstate: 20000145
     ...
     [  758.357249] [<ffff20000809dbdc>] __flush_dcache_area+0x1c/0x40
     [  758.363059] [<ffff2000080b6748>] unmap_stage2_range+0x458/0x5f0
     [  758.368954] [<ffff2000080b708c>] kvm_free_stage2_pgd+0x34/0x60
     [  758.374761] [<ffff2000080b2280>] kvm_arch_destroy_vm+0x20/0x68
     [  758.380570] [<ffff2000080aa330>] kvm_put_kvm+0x210/0x358
     [  758.385860] [<ffff2000080aa524>] kvm_vm_release+0x2c/0x40
     [  758.391239] [<ffff2000082ad234>] __fput+0x114/0x2e8
     [  758.396096] [<ffff2000082ad46c>] ____fput+0xc/0x18
     [  758.400869] [<ffff200008104658>] task_work_run+0x108/0x138
     [  758.406332] [<ffff2000080dc8ec>] do_exit+0x48c/0x10e8
     [  758.411363] [<ffff2000080dd5fc>] do_group_exit+0x6c/0x130
     [  758.416739] [<ffff2000080ed924>] get_signal+0x284/0xa18
     [  758.421943] [<ffff20000808a098>] do_signal+0x158/0x860
     [  758.427060] [<ffff20000808aad4>] do_notify_resume+0x6c/0x88
     [  758.432608] [<ffff200008083624>] work_pending+0x10/0x14
     [  758.437812] Code: 9ac32042 8b010001 d1000443 8a230000 (d50b7e20)
    
    This patch fixes the issue by moving the kvm_free_stage2_pgd() to
    kvm_arch_flush_shadow_all().
    
    Tested-by: Itaru Kitayama <itaru.kitayama@riken.jp>
    Reported-by: Itaru Kitayama <itaru.kitayama@riken.jp>
    Reported-by: James Morse <james.morse@arm.com>
    Cc: Marc Zyngier <marc.zyngier@arm.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Christoffer Dall <christoffer.dall@linaro.org>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 0e0aebc5bd6b7705dbb511facb65dbbebd4e79b8
Author: Steven Rostedt <rostedt@goodmis.org>
Date:   Wed May 25 13:47:26 2016 -0400

    x86/paravirt: Do not trace _paravirt_ident_*() functions
    
    commit 15301a570754c7af60335d094dd2d1808b0641a5 upstream.
    
    Ł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>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit bc45be8519f7dd6a0aa98c95e37a0b3a74c62423
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
    
    commit 299f6230bc6d0ccd5f95bb0fb865d80a9c7d5ccc upstream.
    
    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>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 55377ee2f5c04bc79c22cec747daf687540eb35f
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
    
    commit 98b0f80c2396224bbbed81792b526e6c72ba9efa upstream.
    
    On error, the callers expect us to return without bumping
    nn->cb_users[].
    
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 78d6a2c928a0cbf0d38f42dc366adf66ca141cbe
Author: Paul Mackerras <paulus@ozlabs.org>
Date:   Fri Sep 2 21:47:59 2016 +1000

    powerpc/mm: Don't alias user region to other regions below PAGE_OFFSET
    
    commit f077aaf0754bcba0fffdbd925bc12f09cd1e38aa upstream.
    
    In commit c60ac5693c47 ("powerpc: Update kernel VSID range", 2013-03-13)
    we lost a check on the region number (the top four bits of the effective
    address) for addresses below PAGE_OFFSET.  That commit replaced a check
    that the top 18 bits were all zero with a check that bits 46 - 59 were
    zero (performed for all addresses, not just user addresses).
    
    This means that userspace can access an address like 0x1000_0xxx_xxxx_xxxx
    and we will insert a valid SLB entry for it.  The VSID used will be the
    same as if the top 4 bits were 0, but the page size will be some random
    value obtained by indexing beyond the end of the mm_ctx_high_slices_psize
    array in the paca.  If that page size is the same as would be used for
    region 0, then userspace just has an alias of the region 0 space.  If the
    page size is different, then no HPTE will be found for the access, and
    the process will get a SIGSEGV (since hash_page_mm() will refuse to create
    a HPTE for the bogus address).
    
    The access beyond the end of the mm_ctx_high_slices_psize can be at most
    5.5MB past the array, and so will be in RAM somewhere.  Since the access
    is a load performed in real mode, it won't fault or crash the kernel.
    At most this bug could perhaps leak a little bit of information about
    blocks of 32 bytes of memory located at offsets of i * 512kB past the
    paca->mm_ctx_high_slices_psize array, for 1 <= i <= 11.
    
    Fixes: c60ac5693c47 ("powerpc: Update kernel VSID range")
    Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
    Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 68151411d795b08418cbaf52bb984fac94b914f6
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
    
    commit b53e7d000d9e6e9fd2c6eb6b82d2783c67fd599e upstream.
    
    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.
    
    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: Jiri Slaby <jslaby@suse.cz>

commit 25da72e985a27baced282d6f805cc951354b9e49
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Fri Jul 8 11:38:28 2016 +0200

    x86/mm/pat, /dev/mem: Remove superfluous error message
    
    commit 39380b80d72723282f0ea1d1bbf2294eae45013e upstream.
    
    Currently it's possible for broken (or malicious) userspace to flood a
    kernel log indefinitely with messages a-la
    
            Program dmidecode tried to access /dev/mem between f0000->100000
    
    because range_is_allowed() is case of CONFIG_STRICT_DEVMEM being turned on
    dumps this information each and every time devmem_is_allowed() fails.
    
    Reportedly userspace that is able to trigger contignuous flow of these
    messages exists.
    
    It would be possible to rate limit this message, but that'd have a
    questionable value; the administrator wouldn't get information about all
    the failing accessess, so then the information would be both superfluous
    and incomplete at the same time :)
    
    Returning EPERM (which is what is actually happening) is enough indication
    for userspace what has happened; no need to log this particular error as
    some sort of special condition.
    
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    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: Kees Cook <keescook@chromium.org>
    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>
    Link: http://lkml.kernel.org/r/alpine.LNX.2.00.1607081137020.24757@cbobk.fhfr.pm
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit b9fe5ee13b710dbe49eb34f63066096d5de29254
Author: Michal Kubecek <mkubecek@suse.cz>
Date:   Fri Jun 3 17:56:50 2016 +0200

    ipvs: count pre-established TCP states as active
    
    commit be2cef49904b34dd5f75d96bbc8cd8341bab1bc0 upstream.
    
    Some users observed that "least connection" distribution algorithm doesn't
    handle well bursts of TCP connections from reconnecting clients after
    a node or network failure.
    
    This is because the algorithm counts active connection as worth 256
    inactive ones where for TCP, "active" only means TCP connections in
    ESTABLISHED state. In case of a connection burst, new connections are
    handled before previous ones have finished the three way handshaking so
    that all are still counted as "inactive", i.e. cheap ones. The become
    "active" quickly but at that time, all of them are already assigned to one
    real server (or few), resulting in highly unbalanced distribution.
    
    Address this by counting the "pre-established" states as "active".
    
    Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
    Acked-by: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: Simon Horman <horms@verge.net.au>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit af29d5b57acef4c573c8361a509908115b9ced68
Author: Michal Kubecek <mkubecek@suse.cz>
Date:   Mon May 9 11:01:04 2016 +0200

    net: disable fragment reassembly if high_thresh is set to zero
    
    commit 30759219f562cfaaebe7b9c1d1c0e6b5445c69b0 upstream.
    
    Before commit 6d7b857d541e ("net: use lib/percpu_counter API for
    fragmentation mem accounting"), setting high threshold to 0 prevented
    fragment reassembly as first fragment would be always evicted before
    second could be added to the queue. While inefficient, some users
    apparently relied on it.
    
    Since the commit mentioned above, a percpu counter is used for
    reassembly memory accounting and high batch size avoids taking slow path
    in most common scenarios. As a result, a whole full sized packet can be
    reassembled without the percpu counter's main counter changing its
    value so that even with high_thresh set to 0, fragmented packets can be
    still reassembled and processed.
    
    Add explicit checks preventing reassembly if high threshold is zero.
    
    [mk] backport to 3.12
    
    Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit dea85278d68898838020b9f9edfa159f0a2b7eea
Author: Emrah Demir <ed@abdsec.com>
Date:   Fri Apr 8 22:16:11 2016 +0300

    mISDN: Fixing missing validation in base_sock_bind()
    
    commit b821646826e22f0491708768fccce58eef3f5704 upstream.
    
    Add validation code into mISDN/socket.c
    
    Signed-off-by: Emrah Demir <ed@abdsec.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Oliver Neukum <oliver@neukum.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a770479ab807755a935bb6424ece051de4e5db57
Author: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Date:   Sun Mar 13 00:19:07 2016 +0100

    mISDN: Support DR6 indication in mISDNipac driver
    
    commit 1e1589ad8b5cb5b8a6781ba5850cf710ada0e919 upstream.
    
    According to figure 39 in PEB3086 data sheet, version 1.4 this indication
    replaces DR when layer 1 transition source state is F6.
    
    This fixes mISDN layer 1 getting stuck in F6 state in TE mode on
    Dialogic Diva 2.02 card (and possibly others) when NT deactivates it.
    
    Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
    Acked-by: Karsten Keil <keil@b1-systems.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Oliver Neukum <oliver@neukum.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 9df73f85035830c3cb3f7c55985c9b44f9796cbf
Author: Jean-Gabriel Gill-Couture <jeangab@jeangab.fr.nf>
Date:   Mon Jul 11 17:41:26 2016 +0200

    HID: add usb device id for Apple Magic Keyboard
    
    commit b5d9427549be859dd42c5a6c635bc09d1d07b00b upstream.
    
    USB device
            Vendor 05ac (Apple)
            Device 0267 (Magic Keyboard)
    
    This keyboard supports both Bluetooth and USB connections, this patch
    only covers USB.
    
    Thanks to Maxime Poulin <maxpoulin64@gmail.com>
    
    Signed-off-by: Jean-Gabriel Gill-Couture <jeangab@jeangab.fr.nf>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Cc: Oliver Neukum <oliver@neukum.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 5680d5b72ddcaf80ba452179c0bdac01f90b2da9
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Tue Aug 2 10:31:43 2016 -0700

    Input: ili210x - fix permissions on "calibrate" attribute
    
    commit b27c0d0c3bf3073e8ae19875eb1d3755c5e8c072 upstream.
    
    "calibrate" attribute does not provide "show" methods and thus we should
    not mark it as readable.
    
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Cc: Oliver Neukum <oliver@neukum.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 7d3ca0691f5ab3ec86c95fd96625dbdb990f916e
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date:   Mon Mar 14 09:07:14 2016 +0900

    hwrng: exynos - Disable runtime PM on probe failure
    
    commit 48a61e1e2af8020f11a2b8f8dc878144477623c6 upstream.
    
    Add proper error path (for disabling runtime PM) when registering of
    hwrng fails.
    
    Fixes: b329669ea0b5 ("hwrng: exynos - Add support for Exynos random number generator")
    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 5fd55fb3dd4e854aa89d744774ea77c4468b4272
Author: Sai Gurrappadi <sgurrappadi@nvidia.com>
Date:   Fri Apr 29 14:44:37 2016 -0700

    cpufreq: Fix GOV_LIMITS handling for the userspace governor
    
    commit e43e94c1eda76dabd686ddf6f7825f54d747b310 upstream.
    
    Currently, the userspace governor only updates frequency on GOV_LIMITS
    if policy->cur falls outside policy->{min/max}. However, it is also
    necessary to update current frequency on GOV_LIMITS to match the user
    requested value if it can be achieved within the new policy->{max/min}.
    
    This was previously the behaviour in the governor until commit d1922f0
    ("cpufreq: Simplify userspace governor") which incorrectly assumed that
    policy->cur == user requested frequency via scaling_setspeed. This won't
    be true if the user requested frequency falls outside policy->{min/max}.
    Ex: a temporary thermal cap throttled the user requested frequency.
    
    Fix this by storing the user requested frequency in a seperate variable.
    The governor will then try to achieve this request on every GOV_LIMITS
    change.
    
    Fixes: d1922f02562f (cpufreq: Simplify userspace governor)
    Signed-off-by: Sai Gurrappadi <sgurrappadi@nvidia.com>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit b0c04f74642bc9c8179a294ef33ee12a5748c919
Author: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Date:   Fri Aug 12 17:20:07 2016 -0500

    scsi: fix upper bounds check of sense key in scsi_sense_key_string()
    
    commit a87eeb900dbb9f8202f96604d56e47e67c936b9d upstream.
    
    Commit 655ee63cf371 ("scsi constants: command, sense key + additional
    sense string") added a "Completed" sense string with key 0xF to
    snstext[], but failed to updated the upper bounds check of the sense key
    in scsi_sense_key_string().
    
    Fixes: 655ee63cf371 ("[SCSI] scsi constants: command, sense key + additional sense strings")
    Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
    Reviewed-by: Bart Van Assche <bart.vanassche@sandisk.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit bca643b27d59c303f431714b763404b7f531b181
Author: Vegard Nossum <vegard.nossum@oracle.com>
Date:   Mon Aug 29 00:33:51 2016 +0200

    ALSA: timer: fix NULL pointer dereference on memory allocation failure
    
    commit 8ddc05638ee42b18ba4fe99b5fb647fa3ad20456 upstream.
    
    I hit this with syzkaller:
    
        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: 0 PID: 1327 Comm: a.out Not tainted 4.8.0-rc2+ #190
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
        task: ffff88011278d600 task.stack: ffff8801120c0000
        RIP: 0010:[<ffffffff82c8ba07>]  [<ffffffff82c8ba07>] snd_hrtimer_start+0x77/0x100
        RSP: 0018:ffff8801120c7a60  EFLAGS: 00010006
        RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000007
        RDX: 0000000000000009 RSI: 1ffff10023483091 RDI: 0000000000000048
        RBP: ffff8801120c7a78 R08: ffff88011a5cf768 R09: ffff88011a5ba790
        R10: 0000000000000002 R11: ffffed00234b9ef1 R12: ffff880114843980
        R13: ffffffff84213c00 R14: ffff880114843ab0 R15: 0000000000000286
        FS:  00007f72958f3700(0000) GS:ffff88011aa00000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 0000000000603001 CR3: 00000001126ab000 CR4: 00000000000006f0
        Stack:
         ffff880114843980 ffff880111eb2dc0 ffff880114843a34 ffff8801120c7ad0
         ffffffff82c81ab1 0000000000000000 ffffffff842138e0 0000000100000000
         ffff880111eb2dd0 ffff880111eb2dc0 0000000000000001 ffff880111eb2dc0
        Call Trace:
         [<ffffffff82c81ab1>] snd_timer_start1+0x331/0x670
         [<ffffffff82c85bfd>] snd_timer_start+0x5d/0xa0
         [<ffffffff82c8795e>] snd_timer_user_ioctl+0x88e/0x2830
         [<ffffffff8159f3a0>] ? __follow_pte.isra.49+0x430/0x430
         [<ffffffff82c870d0>] ? snd_timer_pause+0x80/0x80
         [<ffffffff815a26fa>] ? do_wp_page+0x3aa/0x1c90
         [<ffffffff8132762f>] ? put_prev_entity+0x108f/0x21a0
         [<ffffffff82c870d0>] ? snd_timer_pause+0x80/0x80
         [<ffffffff816b0733>] do_vfs_ioctl+0x193/0x1050
         [<ffffffff813510af>] ? cpuacct_account_field+0x12f/0x1a0
         [<ffffffff816b05a0>] ? ioctl_preallocate+0x200/0x200
         [<ffffffff81002f2f>] ? syscall_trace_enter+0x3cf/0xdb0
         [<ffffffff815045ba>] ? __context_tracking_exit.part.4+0x9a/0x1e0
         [<ffffffff81002b60>] ? exit_to_usermode_loop+0x190/0x190
         [<ffffffff82001a97>] ? check_preemption_disabled+0x37/0x1e0
         [<ffffffff81d93889>] ? security_file_ioctl+0x89/0xb0
         [<ffffffff816b167f>] SyS_ioctl+0x8f/0xc0
         [<ffffffff816b15f0>] ? do_vfs_ioctl+0x1050/0x1050
         [<ffffffff81005524>] do_syscall_64+0x1c4/0x4e0
         [<ffffffff83c32b2a>] entry_SYSCALL64_slow_path+0x25/0x25
        Code: c7 c7 c4 b9 c8 82 48 89 d9 4c 89 ee e8 63 88 7f fe e8 7e 46 7b fe 48 8d 7b 48 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 04 84 c0 7e 65 80 7b 48 00 74 0e e8 52 46
        RIP  [<ffffffff82c8ba07>] snd_hrtimer_start+0x77/0x100
         RSP <ffff8801120c7a60>
        ---[ end trace 5955b08db7f2b029 ]---
    
    This can happen if snd_hrtimer_open() fails to allocate memory and
    returns an error, which is currently not checked by snd_timer_open():
    
        ioctl(SNDRV_TIMER_IOCTL_SELECT)
         - snd_timer_user_tselect()
            - snd_timer_close()
               - snd_hrtimer_close()
                  - (struct snd_timer *) t->private_data = NULL
            - snd_timer_open()
               - snd_hrtimer_open()
                  - kzalloc() fails; t->private_data is still NULL
    
        ioctl(SNDRV_TIMER_IOCTL_START)
         - snd_timer_user_start()
            - snd_timer_start()
               - snd_timer_start1()
                  - snd_hrtimer_start()
                    - t->private_data == NULL // boom
    
    [js] no put_device in 3.12 yet
    
    Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit f3b1afe3c30fe99c982b2dec9adcad6450cd58ec
Author: Vegard Nossum <vegard.nossum@oracle.com>
Date:   Mon Aug 29 00:33:50 2016 +0200

    ALSA: timer: fix division by zero after SNDRV_TIMER_IOCTL_CONTINUE
    
    commit 6b760bb2c63a9e322c0e4a0b5daf335ad93d5a33 upstream.
    
    I got this:
    
        divide error: 0000 [#1] PREEMPT SMP KASAN
        CPU: 1 PID: 1327 Comm: a.out Not tainted 4.8.0-rc2+ #189
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
        task: ffff8801120a9580 task.stack: ffff8801120b0000
        RIP: 0010:[<ffffffff82c8bd9a>]  [<ffffffff82c8bd9a>] snd_hrtimer_callback+0x1da/0x3f0
        RSP: 0018:ffff88011aa87da8  EFLAGS: 00010006
        RAX: 0000000000004f76 RBX: ffff880112655e88 RCX: 0000000000000000
        RDX: 0000000000000000 RSI: ffff880112655ea0 RDI: 0000000000000001
        RBP: ffff88011aa87e00 R08: ffff88013fff905c R09: ffff88013fff9048
        R10: ffff88013fff9050 R11: 00000001050a7b8c R12: ffff880114778a00
        R13: ffff880114778ab4 R14: ffff880114778b30 R15: 0000000000000000
        FS:  00007f071647c700(0000) GS:ffff88011aa80000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 0000000000603001 CR3: 0000000112021000 CR4: 00000000000006e0
        Stack:
         0000000000000000 ffff880114778ab8 ffff880112655ea0 0000000000004f76
         ffff880112655ec8 ffff880112655e80 ffff880112655e88 ffff88011aa98fc0
         00000000b97ccf2b dffffc0000000000 ffff88011aa98fc0 ffff88011aa87ef0
        Call Trace:
         <IRQ>
         [<ffffffff813abce7>] __hrtimer_run_queues+0x347/0xa00
         [<ffffffff82c8bbc0>] ? snd_hrtimer_close+0x130/0x130
         [<ffffffff813ab9a0>] ? retrigger_next_event+0x1b0/0x1b0
         [<ffffffff813ae1a6>] ? hrtimer_interrupt+0x136/0x4b0
         [<ffffffff813ae220>] hrtimer_interrupt+0x1b0/0x4b0
         [<ffffffff8120f91e>] local_apic_timer_interrupt+0x6e/0xf0
         [<ffffffff81227ad3>] ? kvm_guest_apic_eoi_write+0x13/0xc0
         [<ffffffff83c35086>] smp_apic_timer_interrupt+0x76/0xa0
         [<ffffffff83c3416c>] apic_timer_interrupt+0x8c/0xa0
         <EOI>
         [<ffffffff83c3239c>] ? _raw_spin_unlock_irqrestore+0x2c/0x60
         [<ffffffff82c8185d>] snd_timer_start1+0xdd/0x670
         [<ffffffff82c87015>] snd_timer_continue+0x45/0x80
         [<ffffffff82c88100>] snd_timer_user_ioctl+0x1030/0x2830
         [<ffffffff8159f3a0>] ? __follow_pte.isra.49+0x430/0x430
         [<ffffffff82c870d0>] ? snd_timer_pause+0x80/0x80
         [<ffffffff815a26fa>] ? do_wp_page+0x3aa/0x1c90
         [<ffffffff815aa4f8>] ? handle_mm_fault+0xbc8/0x27f0
         [<ffffffff815a9930>] ? __pmd_alloc+0x370/0x370
         [<ffffffff82c870d0>] ? snd_timer_pause+0x80/0x80
         [<ffffffff816b0733>] do_vfs_ioctl+0x193/0x1050
         [<ffffffff816b05a0>] ? ioctl_preallocate+0x200/0x200
         [<ffffffff81002f2f>] ? syscall_trace_enter+0x3cf/0xdb0
         [<ffffffff815045ba>] ? __context_tracking_exit.part.4+0x9a/0x1e0
         [<ffffffff81002b60>] ? exit_to_usermode_loop+0x190/0x190
         [<ffffffff82001a97>] ? check_preemption_disabled+0x37/0x1e0
         [<ffffffff81d93889>] ? security_file_ioctl+0x89/0xb0
         [<ffffffff816b167f>] SyS_ioctl+0x8f/0xc0
         [<ffffffff816b15f0>] ? do_vfs_ioctl+0x1050/0x1050
         [<ffffffff81005524>] do_syscall_64+0x1c4/0x4e0
         [<ffffffff83c32b2a>] entry_SYSCALL64_slow_path+0x25/0x25
        Code: e8 fc 42 7b fe 8b 0d 06 8a 50 03 49 0f af cf 48 85 c9 0f 88 7c 01 00 00 48 89 4d a8 e8 e0 42 7b fe 48 8b 45 c0 48 8b 4d a8 48 99 <48> f7 f9 49 01 c7 e8 cb 42 7b fe 48 8b 55 d0 48 b8 00 00 00 00
        RIP  [<ffffffff82c8bd9a>] snd_hrtimer_callback+0x1da/0x3f0
         RSP <ffff88011aa87da8>
        ---[ end trace 6aa380f756a21074 ]---
    
    The problem happens when you call ioctl(SNDRV_TIMER_IOCTL_CONTINUE) on a
    completely new/unused timer -- it will have ->sticks == 0, which causes a
    divide by 0 in snd_hrtimer_callback().
    
    Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit d244fbcc5ea46592d4f409c0418e8fe0be3d81ca
Author: Vegard Nossum <vegard.nossum@oracle.com>
Date:   Sun Aug 28 10:13:07 2016 +0200

    ALSA: timer: fix NULL pointer dereference in read()/ioctl() race
    
    commit 11749e086b2766cccf6217a527ef5c5604ba069c upstream.
    
    I got this with syzkaller:
    
        ==================================================================
        BUG: KASAN: null-ptr-deref on address 0000000000000020
        Read of size 32 by task syz-executor/22519
        CPU: 1 PID: 22519 Comm: syz-executor Not tainted 4.8.0-rc2+ #169
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2
        014
         0000000000000001 ffff880111a17a00 ffffffff81f9f141 ffff880111a17a90
         ffff880111a17c50 ffff880114584a58 ffff880114584a10 ffff880111a17a80
         ffffffff8161fe3f ffff880100000000 ffff880118d74a48 ffff880118d74a68
        Call Trace:
         [<ffffffff81f9f141>] dump_stack+0x83/0xb2
         [<ffffffff8161fe3f>] kasan_report_error+0x41f/0x4c0
         [<ffffffff8161ff74>] kasan_report+0x34/0x40
         [<ffffffff82c84b54>] ? snd_timer_user_read+0x554/0x790
         [<ffffffff8161e79e>] check_memory_region+0x13e/0x1a0
         [<ffffffff8161e9c1>] kasan_check_read+0x11/0x20
         [<ffffffff82c84b54>] snd_timer_user_read+0x554/0x790
         [<ffffffff82c84600>] ? snd_timer_user_info_compat.isra.5+0x2b0/0x2b0
         [<ffffffff817d0831>] ? proc_fault_inject_write+0x1c1/0x250
         [<ffffffff817d0670>] ? next_tgid+0x2a0/0x2a0
         [<ffffffff8127c278>] ? do_group_exit+0x108/0x330
         [<ffffffff8174653a>] ? fsnotify+0x72a/0xca0
         [<ffffffff81674dfe>] __vfs_read+0x10e/0x550
         [<ffffffff82c84600>] ? snd_timer_user_info_compat.isra.5+0x2b0/0x2b0
         [<ffffffff81674cf0>] ? do_sendfile+0xc50/0xc50
         [<ffffffff81745e10>] ? __fsnotify_update_child_dentry_flags+0x60/0x60
         [<ffffffff8143fec6>] ? kcov_ioctl+0x56/0x190
         [<ffffffff81e5ada2>] ? common_file_perm+0x2e2/0x380
         [<ffffffff81746b0e>] ? __fsnotify_parent+0x5e/0x2b0
         [<ffffffff81d93536>] ? security_file_permission+0x86/0x1e0
         [<ffffffff816728f5>] ? rw_verify_area+0xe5/0x2b0
         [<ffffffff81675355>] vfs_read+0x115/0x330
         [<ffffffff81676371>] SyS_read+0xd1/0x1a0
         [<ffffffff816762a0>] ? vfs_write+0x4b0/0x4b0
         [<ffffffff82001c2c>] ? __this_cpu_preempt_check+0x1c/0x20
         [<ffffffff8150455a>] ? __context_tracking_exit.part.4+0x3a/0x1e0
         [<ffffffff816762a0>] ? vfs_write+0x4b0/0x4b0
         [<ffffffff81005524>] do_syscall_64+0x1c4/0x4e0
         [<ffffffff810052fc>] ? syscall_return_slowpath+0x16c/0x1d0
         [<ffffffff83c3276a>] entry_SYSCALL64_slow_path+0x25/0x25
        ==================================================================
    
    There are a couple of problems that I can see:
    
     - ioctl(SNDRV_TIMER_IOCTL_SELECT), which potentially sets
       tu->queue/tu->tqueue to NULL on memory allocation failure, so read()
       would get a NULL pointer dereference like the above splat
    
     - the same ioctl() can free tu->queue/to->tqueue which means read()
       could potentially see (and dereference) the freed pointer
    
    We can fix both by taking the ioctl_lock mutex when dereferencing
    ->queue/->tqueue, since that's always held over all the ioctl() code.
    
    Just looking at the code I find it likely that there are more problems
    here such as tu->qhead pointing outside the buffer if the size is
    changed concurrently using SNDRV_TIMER_IOCTL_PARAMS.
    
    [js] unlock in fail paths
    
    Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 72fe6c43d30f622810e72b436bf25ae0a342b4c9
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Aug 30 14:45:46 2016 +0200

    ALSA: rawmidi: Fix possible deadlock with virmidi registration
    
    commit 816f318b2364262a51024096da7ca3b84e78e3b5 upstream.
    
    When a seq-virmidi driver is initialized, it registers a rawmidi
    instance with its callback to create an associated seq kernel client.
    Currently it's done throughly in rawmidi's register_mutex context.
    Recently it was found that this may lead to a deadlock another rawmidi
    device that is being attached with the sequencer is accessed, as both
    open with the same register_mutex.  This was actually triggered by
    syzkaller, as Dmitry Vyukov reported:
    
    ======================================================
     [ INFO: possible circular locking dependency detected ]
     4.8.0-rc1+ #11 Not tainted
     -------------------------------------------------------
     syz-executor/7154 is trying to acquire lock:
      (register_mutex#5){+.+.+.}, at: [<ffffffff84fd6d4b>] snd_rawmidi_kernel_open+0x4b/0x260 sound/core/rawmidi.c:341
    
     but task is already holding lock:
      (&grp->list_mutex){++++.+}, at: [<ffffffff850138bb>] check_and_subscribe_port+0x5b/0x5c0 sound/core/seq/seq_ports.c:495
    
     which lock already depends on the new lock.
    
     the existing dependency chain (in reverse order) is:
    
     -> #1 (&grp->list_mutex){++++.+}:
        [<ffffffff8147a3a8>] lock_acquire+0x208/0x430 kernel/locking/lockdep.c:3746
        [<ffffffff863f6199>] down_read+0x49/0xc0 kernel/locking/rwsem.c:22
        [<     inline     >] deliver_to_subscribers sound/core/seq/seq_clientmgr.c:681
        [<ffffffff85005c5e>] snd_seq_deliver_event+0x35e/0x890 sound/core/seq/seq_clientmgr.c:822
        [<ffffffff85006e96>] > snd_seq_kernel_client_dispatch+0x126/0x170 sound/core/seq/seq_clientmgr.c:2418
        [<ffffffff85012c52>] snd_seq_system_broadcast+0xb2/0xf0 sound/core/seq/seq_system.c:101
        [<ffffffff84fff70a>] snd_seq_create_kernel_client+0x24a/0x330 sound/core/seq/seq_clientmgr.c:2297
        [<     inline     >] snd_virmidi_dev_attach_seq sound/core/seq/seq_virmidi.c:383
        [<ffffffff8502d29f>] snd_virmidi_dev_register+0x29f/0x750 sound/core/seq/seq_virmidi.c:450
        [<ffffffff84fd208c>] snd_rawmidi_dev_register+0x30c/0xd40 sound/core/rawmidi.c:1645
        [<ffffffff84f816d3>] __snd_device_register.part.0+0x63/0xc0 sound/core/device.c:164
        [<     inline     >] __snd_device_register sound/core/device.c:162
        [<ffffffff84f8235d>] snd_device_register_all+0xad/0x110 sound/core/device.c:212
        [<ffffffff84f7546f>] snd_card_register+0xef/0x6c0 sound/core/init.c:749
        [<ffffffff85040b7f>] snd_virmidi_probe+0x3ef/0x590 sound/drivers/virmidi.c:123
        [<ffffffff833ebf7b>] platform_drv_probe+0x8b/0x170 drivers/base/platform.c:564
        ......
    
     -> #0 (register_mutex#5){+.+.+.}:
        [<     inline     >] check_prev_add kernel/locking/lockdep.c:1829
        [<     inline     >] check_prevs_add kernel/locking/lockdep.c:1939
        [<     inline     >] validate_chain kernel/locking/lockdep.c:2266
        [<ffffffff814791f4>] __lock_acquire+0x4d44/0x4d80 kernel/locking/lockdep.c:3335
        [<ffffffff8147a3a8>] lock_acquire+0x208/0x430 kernel/locking/lockdep.c:3746
        [<     inline     >] __mutex_lock_common kernel/locking/mutex.c:521
        [<ffffffff863f0ef1>] mutex_lock_nested+0xb1/0xa20 kernel/locking/mutex.c:621
        [<ffffffff84fd6d4b>] snd_rawmidi_kernel_open+0x4b/0x260 sound/core/rawmidi.c:341
        [<ffffffff8502e7c7>] midisynth_subscribe+0xf7/0x350 sound/core/seq/seq_midi.c:188
        [<     inline     >] subscribe_port sound/core/seq/seq_ports.c:427
        [<ffffffff85013cc7>] check_and_subscribe_port+0x467/0x5c0 sound/core/seq/seq_ports.c:510
        [<ffffffff85015da9>] snd_seq_port_connect+0x2c9/0x500 sound/core/seq/seq_ports.c:579
        [<ffffffff850079b8>] snd_seq_ioctl_subscribe_port+0x1d8/0x2b0 sound/core/seq/seq_clientmgr.c:1480
        [<ffffffff84ffe9e4>] snd_seq_do_ioctl+0x184/0x1e0 sound/core/seq/seq_clientmgr.c:2225
        [<ffffffff84ffeae8>] snd_seq_kernel_client_ctl+0xa8/0x110 sound/core/seq/seq_clientmgr.c:2440
        [<ffffffff85027664>] snd_seq_oss_midi_open+0x3b4/0x610 sound/core/seq/oss/seq_oss_midi.c:375
        [<ffffffff85023d67>] snd_seq_oss_synth_setup_midi+0x107/0x4c0 sound/core/seq/oss/seq_oss_synth.c:281
        [<ffffffff8501b0a8>] snd_seq_oss_open+0x748/0x8d0 sound/core/seq/oss/seq_oss_init.c:274
        [<ffffffff85019d8a>] odev_open+0x6a/0x90 sound/core/seq/oss/seq_oss.c:138
        [<ffffffff84f7040f>] soundcore_open+0x30f/0x640 sound/sound_core.c:639
        ......
    
     other info that might help us debug this:
    
     Possible unsafe locking scenario:
    
            CPU0                    CPU1
            ----                    ----
       lock(&grp->list_mutex);
                                    lock(register_mutex#5);
                                    lock(&grp->list_mutex);
       lock(register_mutex#5);
    
     *** DEADLOCK ***
    ======================================================
    
    The fix is to simply move the registration parts in
    snd_rawmidi_dev_register() to the outside of the register_mutex lock.
    The lock is needed only to manage the linked list, and it's not
    necessarily to cover the whole initialization process.
    
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 434ada5f2400baced39d2b603612ec680d8d1495
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
    
    commit 2e63ad4bd5dd583871e6602f9d398b9322d358d9 upstream.
    
    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
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 67e71ed6b5b11b6741c2a4593ed10071fd24ebff
Author: Vincent Stehlé <vincent.stehle@intel.com>
Date:   Fri Aug 12 15:26:30 2016 +0200

    ubifs: Fix assertion in layout_in_gaps()
    
    commit c0082e985fdf77b02fc9e0dac3b58504dcf11b7a upstream.
    
    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")
    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: Jiri Slaby <jslaby@suse.cz>

commit 4a47090ab9b6aef293efb11472112df2cf44323f
Author: John Stultz <john.stultz@linaro.org>
Date:   Tue Aug 23 16:08:22 2016 -0700

    timekeeping: Cap array access in timekeeping_debug
    
    commit a4f8f6667f099036c88f231dcad4cf233652c824 upstream.
    
    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: 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: Jiri Slaby <jslaby@suse.cz>

commit 09fc5004852c8ec3ae470dfc1f63384e9dd93788
Author: Dave Chinner <dchinner@redhat.com>
Date:   Fri Aug 26 16:01:30 2016 +1000

    xfs: fix superblock inprogress check
    
    commit f3d7ebdeb2c297bd26272384e955033493ca291c upstream.
    
    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.
    
    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: Jiri Slaby <jslaby@suse.cz>

commit 94a517e819e083124149fa990e15cb77f3de3293
Author: Rob Clark <robdclark@gmail.com>
Date:   Mon Aug 22 15:15:23 2016 -0400

    drm/msm: fix use of copy_from_user() while holding spinlock
    
    commit 89f82cbb0d5c0ab768c8d02914188aa2211cd2e3 upstream.
    
    Use instead __copy_from_user_inatomic() and fallback to slow-path where
    we drop and re-aquire the lock in case of fault.
    
    Reported-by: Vaishali Thakkar <vaishali.thakkar@oracle.com>
    Signed-off-by: Rob Clark <robdclark@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 623c18b3f2540cef9111ad3465f4bda98bb91eec
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sat Aug 20 12:22:11 2016 +0200

    drm: Reject page_flip for !DRIVER_MODESET
    
    commit 6f00975c619064a18c23fd3aced325ae165a73b9 upstream.
    
    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>
    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: Jiri Slaby <jslaby@suse.cz>

commit bbca3af46c6a529be17d8ceb5cfdc2a600810a45
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
    
    commit 13f479b9df4e2bbf2d16e7e1b02f3f55f70e2455 upstream.
    
    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>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 44d6b34c6acb9c22304ec8a95b45ffa0bccbef24
Author: Dave Jones <davej@codemonkey.org.uk>
Date:   Fri Sep 2 14:39:50 2016 -0400

    ipv6: release dst in ping_v6_sendmsg
    
    [ Upstream commit 03c2778a938aaba0893f6d6cdc29511d91a79848 ]
    
    Neither the failure or success paths of ping_v6_sendmsg release
    the dst it acquires.  This leads to a flood of warnings from
    "net/core/dst.c:288 dst_release" on older kernels that
    don't have 8bf4ada2e21378816b28205427ee6b0e1ca4c5f1 backported.
    
    That patch optimistically hoped this had been fixed post 3.10, but
    it seems at least one case wasn't, where I've seen this triggered
    a lot from machines doing unprivileged icmp sockets.
    
    Cc: Martin Lau <kafai@fb.com>
    Signed-off-by: Dave Jones <davej@codemonkey.org.uk>
    Acked-by: Martin KaFai Lau <kafai@fb.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 11cea763c4c2c51933f16e6d761afa19ab71e74c
Author: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Date:   Fri Jul 17 14:01:11 2015 +0300

    net: ratelimit warnings about dst entry refcount underflow or overflow
    
    commit 8bf4ada2e21378816b28205427ee6b0e1ca4c5f1 upstream.
    
    Kernel generates a lot of warnings when dst entry reference counter
    overflows and becomes negative. That bug was seen several times at
    machines with outdated 3.10.y kernels. Most like it's already fixed
    in upstream. Anyway that flood completely kills machine and makes
    further debugging impossible.
    
    Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 19e352cad241ecb7c5b2b3436c9ce64002d6ff26
Author: Mahesh Bandewar <maheshb@google.com>
Date:   Thu Sep 1 22:18:34 2016 -0700

    bonding: Fix bonding crash
    
    [ Upstream commit 24b27fc4cdf9e10c5e79e5923b6b7c2c5c95096c ]
    
    Following few steps will crash kernel -
    
      (a) Create bonding master
          > modprobe bonding miimon=50
      (b) Create macvlan bridge on eth2
          > ip link add link eth2 dev mvl0 address aa:0:0:0:0:01 \
               type macvlan
      (c) Now try adding eth2 into the bond
          > echo +eth2 > /sys/class/net/bond0/bonding/slaves
          <crash>
    
    Bonding does lots of things before checking if the device enslaved is
    busy or not.
    
    In this case when the notifier call-chain sends notifications, the
    bond_netdev_event() assumes that the rx_handler /rx_handler_data is
    registered while the bond_enslave() hasn't progressed far enough to
    register rx_handler for the new slave.
    
    This patch adds a rx_handler check that can be performed right at the
    beginning of the enslave code to avoid getting into this situation.
    
    Signed-off-by: Mahesh Bandewar <maheshb@google.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 35bb29a7ec45852afd168fa7e2b97c4a67e9e6c7
Author: Soheil Hassas Yeganeh <soheil@google.com>
Date:   Tue Aug 23 18:22:33 2016 -0400

    tun: fix transmit timestamp support
    
    [ Upstream commit 7b996243fab46092fb3a29c773c54be8152366e4 ]
    
    Instead of using sock_tx_timestamp, use skb_tx_timestamp to record
    software transmit timestamp of a packet.
    
    sock_tx_timestamp resets and overrides the tx_flags of the skb.
    The function is intended to be called from within the protocol
    layer when creating the skb, not from a device driver. This is
    inconsistent with other drivers and will cause issues for TCP.
    
    In TCP, we intend to sample the timestamps for the last byte
    for each sendmsg/sendpage. For that reason, tcp_sendmsg calls
    tcp_tx_timestamp only with the last skb that it generates.
    For example, if a 128KB message is split into two 64KB packets
    we want to sample the SND timestamp of the last packet. The current
    code in the tun driver, however, will result in sampling the SND
    timestamp for both packets.
    
    Also, when the last packet is split into smaller packets for
    retranmission (see tcp_fragment), the tun driver will record
    timestamps for all of the retransmitted packets and not only the
    last packet.
    
    Fixes: eda297729171 (tun: Support software transmit time stamping.)
    Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
    Signed-off-by: Francis Yan <francisyyan@google.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 8ed803221d9a2a56b3a05d81250382629957178f
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Aug 22 11:31:10 2016 -0700

    tcp: properly scale window in tcp_v[46]_reqsk_send_ack()
    
    [ Upstream commit 20a2b49fc538540819a0c552877086548cff8d8d ]
    
    When sending an ack in SYN_RECV state, we must scale the offered
    window if wscale option was negotiated and accepted.
    
    Tested:
     Following packetdrill test demonstrates the issue :
    
    0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
    +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
    
    +0 bind(3, ..., ...) = 0
    +0 listen(3, 1) = 0
    
    // Establish a connection.
    +0 < S 0:0(0) win 20000 <mss 1000,sackOK,wscale 7, nop, TS val 100 ecr 0>
    +0 > S. 0:0(0) ack 1 win 28960 <mss 1460,sackOK, TS val 100 ecr 100, nop, wscale 7>
    
    +0 < . 1:11(10) ack 1 win 156 <nop,nop,TS val 99 ecr 100>
    // check that window is properly scaled !
    +0 > . 1:1(0) ack 1 win 226 <nop,nop,TS val 200 ecr 100>
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Yuchung Cheng <ycheng@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Acked-by: Yuchung Cheng <ycheng@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 522a16c9b6f120dd4fdfdfdf925a64128923e1a6
Author: Paul Blakey <paulb@mellanox.com>
Date:   Thu Aug 18 21:09:05 2016 +0300

    net/mlx5: Added missing check of msg length in verifying its signature
    
    [ Upstream commit 2c0f8ce1b584a4d7b8ff53140d21dfed99834940 ]
    
    Set and verify signature calculates the signature for each of the
    mailbox nodes, even for those that are unused (from cache). Added
    a missing length check to set and verify only those which are used.
    
    While here, also moved the setting of msg's nodes token to where we
    already go over them. This saves a pass because checksum is disabled,
    and the only useful thing remaining that set signature does is setting
    the token.
    
    Fixes: e126ba97dba9 ('mlx5: Add driver for Mellanox Connect-IB
    adapters')
    Signed-off-by: Paul Blakey <paulb@mellanox.com>
    
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 1f25ea564d810767b4ce3302530156dd5ddaa0f4
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Aug 17 05:56:26 2016 -0700

    tcp: fix use after free in tcp_xmit_retransmit_queue()
    
    [ Upstream commit bb1fceca22492109be12640d49f5ea5a544c6bb4 ]
    
    When tcp_sendmsg() allocates a fresh and empty skb, it puts it at the
    tail of the write queue using tcp_add_write_queue_tail()
    
    Then it attempts to copy user data into this fresh skb.
    
    If the copy fails, we undo the work and remove the fresh skb.
    
    Unfortunately, this undo lacks the change done to tp->highest_sack and
    we can leave a dangling pointer (to a freed skb)
    
    Later, tcp_xmit_retransmit_queue() can dereference this pointer and
    access freed memory. For regular kernels where memory is not unmapped,
    this might cause SACK bugs because tcp_highest_sack_seq() is buggy,
    returning garbage instead of tp->snd_nxt, but with various debug
    features like CONFIG_DEBUG_PAGEALLOC, this can crash the kernel.
    
    This bug was found by Marco Grassi thanks to syzkaller.
    
    Fixes: 6859d49475d4 ("[TCP]: Abstract tp->highest_sack accessing & point to next skb")
    Reported-by: Marco Grassi <marco.gra@gmail.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
    Cc: Yuchung Cheng <ycheng@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Reviewed-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit c0a606255170ba4b14a171966a1e74c04214097e
Author: Vegard Nossum <vegard.nossum@oracle.com>
Date:   Fri Aug 12 10:29:13 2016 +0200

    net/irda: handle iriap_register_lsap() allocation failure
    
    [ Upstream commit 5ba092efc7ddff040777ae7162f1d195f513571b ]
    
    If iriap_register_lsap() fails to allocate memory, self->lsap is
    set to NULL. However, none of the callers handle the failure and
    irlmp_connect_request() will happily dereference it:
    
        iriap_register_lsap: Unable to allocated LSAP!
        ================================================================================
        UBSAN: Undefined behaviour in net/irda/irlmp.c:378:2
        member access within null pointer of type 'struct lsap_cb'
        CPU: 1 PID: 15403 Comm: trinity-c0 Not tainted 4.8.0-rc1+ #81
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org
        04/01/2014
         0000000000000000 ffff88010c7e78a8 ffffffff82344f40 0000000041b58ab3
         ffffffff84f98000 ffffffff82344e94 ffff88010c7e78d0 ffff88010c7e7880
         ffff88010630ad00 ffffffff84a5fae0 ffffffff84d3f5c0 000000000000017a
        Call Trace:
         [<ffffffff82344f40>] dump_stack+0xac/0xfc
         [<ffffffff8242f5a8>] ubsan_epilogue+0xd/0x8a
         [<ffffffff824302bf>] __ubsan_handle_type_mismatch+0x157/0x411
         [<ffffffff83b7bdbc>] irlmp_connect_request+0x7ac/0x970
         [<ffffffff83b77cc0>] iriap_connect_request+0xa0/0x160
         [<ffffffff83b77f48>] state_s_disconnect+0x88/0xd0
         [<ffffffff83b78904>] iriap_do_client_event+0x94/0x120
         [<ffffffff83b77710>] iriap_getvaluebyclass_request+0x3e0/0x6d0
         [<ffffffff83ba6ebb>] irda_find_lsap_sel+0x1eb/0x630
         [<ffffffff83ba90c8>] irda_connect+0x828/0x12d0
         [<ffffffff833c0dfb>] SYSC_connect+0x22b/0x340
         [<ffffffff833c7e09>] SyS_connect+0x9/0x10
         [<ffffffff81007bd3>] do_syscall_64+0x1b3/0x4b0
         [<ffffffff845f946a>] entry_SYSCALL64_slow_path+0x25/0x25
        ================================================================================
    
    The bug seems to have been around since forever.
    
    There's more problems with missing error checks in iriap_init() (and
    indeed all of irda_init()), but that's a bigger problem that needs
    very careful review and testing. This patch will fix the most serious
    bug (as it's easily reached from unprivileged userspace).
    
    I have tested my patch with a reproducer.
    
    Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 781bd0bd9f139917a518f6414b88114b3eff7243
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Aug 8 08:45:33 2016 +0200

    Revert "wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel"
    
    commit 4d0bd46a4d55383f7b925e6cf7865a77e0f0e020 upstream.
    
    This reverts commit 3d5fdff46c4b2b9534fa2f9fc78e90a48e0ff724.
    
    Ben Hutchings pointed out that the commit isn't safe since it assumes
    that the structure used by the driver is iw_point, when in fact there's
    no way to know about that.
    
    Fortunately, the only driver in the tree that ever runs this code path
    is the wilc1000 staging driver, so it doesn't really matter.
    
    Clearly I should have investigated this better before applying, sorry.
    
    Reported-by: Ben Hutchings <ben@decadent.org.uk>
    Fixes: 3d5fdff46c4b ("wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit e3cdcb05f75add28bc19bdcf853e0e487ade34b1
Author: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Date:   Sun Mar 13 17:29:06 2016 -0400

    ext4: use __GFP_NOFAIL in ext4_free_blocks()
    
    commit adb7ef600cc9d9d15ecc934cc26af5c1379777df upstream.
    
    This might be unexpected but pages allocated for sbi->s_buddy_cache are
    charged to current memory cgroup. So, GFP_NOFS allocation could fail if
    current task has been killed by OOM or if current memory cgroup has no
    free memory left. Block allocator cannot handle such failures here yet.
    
    Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit cb554cf8a55e5381d398cb85567f808d92ce6251
Author: Tejun Heo <tj@kernel.org>
Date:   Wed Nov 4 12:15:33 2015 -0500

    timers: Use proper base migration in add_timer_on()
    
    commit 22b886dd1018093920c4250dee2a9a3cb7cff7b8 upstream.
    
    Regardless of the previous CPU a timer was on, add_timer_on()
    currently simply sets timer->flags to the new CPU.  As the caller must
    be seeing the timer as idle, this is locally fine, but the timer
    leaving the old base while unlocked can lead to race conditions as
    follows.
    
    Let's say timer was on cpu 0.
    
      cpu 0                                 cpu 1
      -----------------------------------------------------------------------------
      del_timer(timer) succeeds
                                            del_timer(timer)
                                              lock_timer_base(timer) locks cpu_0_base
      add_timer_on(timer, 1)
        spin_lock(&cpu_1_base->lock)
        timer->flags set to cpu_1_base
        operates on @timer                    operates on @timer
    
    This triggered with mod_delayed_work_on() which contains
    "if (del_timer()) add_timer_on()" sequence eventually leading to the
    following oops.
    
      BUG: unable to handle kernel NULL pointer dereference at           (null)
      IP: [<ffffffff810ca6e9>] detach_if_pending+0x69/0x1a0
      ...
      Workqueue: wqthrash wqthrash_workfunc [wqthrash]
      task: ffff8800172ca680 ti: ffff8800172d0000 task.ti: ffff8800172d0000
      RIP: 0010:[<ffffffff810ca6e9>]  [<ffffffff810ca6e9>] detach_if_pending+0x69/0x1a0
      ...
      Call Trace:
       [<ffffffff810cb0b4>] del_timer+0x44/0x60
       [<ffffffff8106e836>] try_to_grab_pending+0xb6/0x160
       [<ffffffff8106e913>] mod_delayed_work_on+0x33/0x80
       [<ffffffffa0000081>] wqthrash_workfunc+0x61/0x90 [wqthrash]
       [<ffffffff8106dba8>] process_one_work+0x1e8/0x650
       [<ffffffff8106e05e>] worker_thread+0x4e/0x450
       [<ffffffff810746af>] kthread+0xef/0x110
       [<ffffffff8185980f>] ret_from_fork+0x3f/0x70
    
    Fix it by updating add_timer_on() to perform proper migration as
    __mod_timer() does.
    
    Mike: apply tglx backport
    
    Reported-and-tested-by: Jeff Layton <jlayton@poochiereds.net>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: Chris Worley <chris.worley@primarydata.com>
    Cc: bfields@fieldses.org
    Cc: Michael Skralivetsky <michael.skralivetsky@primarydata.com>
    Cc: Trond Myklebust <trond.myklebust@primarydata.com>
    Cc: Shaohua Li <shli@fb.com>
    Cc: Jeff Layton <jlayton@poochiereds.net>
    Cc: kernel-team@fb.com
    Cc: stable@vger.kernel.org
    Link: http://lkml.kernel.org/r/20151029103113.2f893924@tlielax.poochiereds.net
    Link: http://lkml.kernel.org/r/20151104171533.GI5749@mtj.duckdns.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Mike Galbraith <mgalbraith@suse.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 8964b0e40d19743da5d43638fa8679d9d5da7c5d
Author: Daeho Jeong <daeho.jeong@samsung.com>
Date:   Sun Jul 3 17:51:39 2016 -0400

    ext4: avoid modifying checksum fields directly during checksum verification
    
    commit b47820edd1634dc1208f9212b7ecfb4230610a23 upstream.
    
    We temporally change checksum fields in buffers of some types of
    metadata into '0' for verifying the checksum values. By doing this
    without locking the buffer, some metadata's checksums, which are
    being committed or written back to the storage, could be damaged.
    In our test, several metadata blocks were found with damaged metadata
    checksum value during recovery process. When we only verify the
    checksum value, we have to avoid modifying checksum fields directly.
    
    Signed-off-by: Daeho Jeong <daeho.jeong@samsung.com>
    Signed-off-by: Youngjin Gil <youngjin.gil@samsung.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 98d91ddd338eea3a4eed37f4f2498ce5a3cc1102
Author: Willy Tarreau <w@1wt.eu>
Date:   Sat Aug 27 11:31:35 2016 +0200

    fix d_walk()/non-delayed __d_free() race
    
    I checked Jari's explanation below and found that v3.14.77 and v3.12.62
    are missing the same fix as 3.10. In fact Al's original commit 3d56c25
    ("fix d_walk()/non-delayed __d_free() race") used to mention to check
    this __d_materialise_dentry() function in the Cc: stable line, but this
    got lost during the backports.
    
    Normally all of our 3 kernels need to apply the following patch that
    Ben correctly put in 3.16 and 3.2. I'm fixing the backport in 3.10.103
    right now.
    
    On Mon, Aug 22, 2016 at 04:56:57PM +0300, Jari Ruusu wrote:
    > This patch for 3.10 branch appears to be missing one important
    >
    > +       dentry->d_flags |= DCACHE_RCUACCESS;
    >
    > in fs/dcache.c __d_materialise_dentry() function. When Ben Hutchings
    > backported Al Viro's original fix to stable branches that he maintains,
    > he added that one additional line to both 3.2 and 3.16 branches. Please
    > consider including that additional one line fix for 3.10 stable branch
    > also.
    >
    >
    > Ben Hutchings said this on his 3.2.82-rc1 patch:
    > [bwh: Backported to 3.2:
    >  - Adjust context
    >  - Also set the flag in __d_materialise_dentry())]
    >
    > http://marc.info/?l=linux-kernel&m=147117565612275&w=2
    >
    >
    > Ben Hutchings said this on his 3.16.37-rc1 patch:
    > [bwh: Backported to 3.16:
    >  - Adjust context
    >  - Also set the flag in __d_materialise_dentry())]
    >
    > http://marc.info/?l=linux-kernel&m=147117433412006&w=2
    >
    >
    > Also mentioned by Sasha Levin on 3.18 and 4.1 commits:
    > Cc: stable@vger.kernel.org # v3.2+ (and watch out for __d_materialise_dentry())
    >
    > http://marc.info/?l=linux-stable-commits&m=146648034410827&w=2
    > http://marc.info/?l=linux-stable-commits&m=146647471009771&w=2
    
    
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 6ec8ba03f408beac5bad1e9ec06c8a90b373f3ac
Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date:   Mon Apr 25 17:54:28 2016 +0200

    s390/sclp_ctl: fix potential information leak with /dev/sclp
    
    commit 532c34b5fbf1687df63b3fcd5b2846312ac943c6 upstream.
    
    The sclp_ctl_ioctl_sccb function uses two copy_from_user calls to
    retrieve the sclp request from user space. The first copy_from_user
    fetches the length of the request which is stored in the first two
    bytes of the request. The second copy_from_user gets the complete
    sclp request, but this copies the length field a second time.
    A malicious user may have changed the length in the meantime.
    
    Reported-by: Pengfei Wang <wpengfeinudt@gmail.com>
    Reviewed-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Juerg Haefliger <juerg.haefliger@hpe.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 672a020d4a85288c58e73727d8a6561d83f60dad
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
    
    commit 829fa70dddadf9dd041d62b82cd7cea63943899d upstream.
    
    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.
    
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 2794a7141faccd80f81938b7af781e83b7ff136b
Author: Alexander Shiyan <shc_work@mail.ru>
Date:   Tue Feb 25 23:41:14 2014 -0300

    stb6100: fix buffer length check in stb6100_write_reg_range()
    
    commit 7e6bd12fb77b0067df13fb3ba3fadbdff2945396 upstream.
    
    We are checking sizeof() the wrong variable!
    
    Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
    Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
    Cc: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit f1e02250a6d3d79ffbfec6b7340ed5ee6c8e78f7
Author: Tomer Barletz <barletz@gmail.com>
Date:   Sun Aug 2 02:08:57 2015 -0700

    ALSA: oxygen: Fix logical-not-parentheses warning
    
    commit 8ec7cfce3762299ae289c384e281b2f4010ae231 upstream.
    
    This fixes the following warning, that is seen with gcc 5.1:
    warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses].
    
    Signed-off-by: Tomer Barletz <barletz@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Cc: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a02b9364200829b15937dc274325c317c36ebc73
Author: James C Boyd <jcboyd.dev@gmail.com>
Date:   Wed May 27 17:09:06 2015 -0500

    HID: hid-input: Add parentheses to quell gcc warning
    
    commit 09a5c34e8d6b05663ec4c3d22b1fbd9fec89aaf9 upstream.
    
    GCC reports a -Wlogical-not-parentheses warning here; therefore
    add parentheses to shut it up and to express our intent more.
    
    Signed-off-by: James C Boyd <jcboyd.dev@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Cc: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit dde3f0d00580fd24c6a51fce124762084a62efc9
Author: Tim Gardner <tim.gardner@canonical.com>
Date:   Fri Oct 30 12:22:58 2015 -0600

    be2iscsi: Fix bogus WARN_ON length check
    
    commit dd29dae00d39186890a5eaa2fe4ad8768bfd41a9 upstream.
    
    drivers/scsi/be2iscsi/be_main.c: In function 'be_sgl_create_contiguous':
    drivers/scsi/be2iscsi/be_main.c:3187:18: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
      WARN_ON(!length > 0);
    
    gcc version 5.2.1
    
    Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
    Cc: Jayamohan Kallickal <jayamohan.kallickal@avagotech.com>
    Cc: Minh Tran <minh.tran@avagotech.com>
    Cc: John Soni Jose <sony.john-n@avagotech.com>
    Cc: "James E.J. Bottomley" <JBottomley@odin.com>
    Reported-by: Joel Stanley <joel@jms.id.au>
    Reviewed-by: Manoj Kumar <manoj@linux.vnet.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Cc: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 02910968895e0f7b5ef81146407c57a5a8b1ca62
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Sep 9 13:32:42 2016 +0200

    Revert "can: fix handling of unmodifiable configuration options fix"
    
    This reverts commit ded1c127d6dc1a1827f3ff657a4cb7edd646092e which was
    bce271f255dae8335dc4d2ee2c4531e09cc67f5a upstream.
    
    It was applied incorrectly, and isn't needed for 3.12-stable.
    
    Reported-by: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org

commit dc7d223a5de64dc78396a98c2f034ba12dc160e1
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu May 5 16:23:04 2016 +0300

    ACPI / sysfs: fix error code in get_status()
    
    commit f18ebc211e259d4f591e39e74b2aa2de226c9a1d upstream.
    
    The problem with ornamental, do-nothing gotos is that they lead to
    "forgot to set the error code" bugs.  We should be returning -EINVAL
    here but we don't.  It leads to an uninitalized variable in
    counter_show():
    
        drivers/acpi/sysfs.c:603 counter_show()
        error: uninitialized symbol 'status'.
    
    Fixes: 1c8fce27e275 (ACPI: introduce drivers/acpi/sysfs.c)
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 1186d77797e84479057ba69cae221e5e2b06bf04
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
    
    commit 80e162ee9b31d77d851b10f8c5299132be1e120f upstream.
    
    `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>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit f3a6e82686efcce3c2b3eca44f9d2cb34821bfab
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
    
    commit 3b7c7e52efda0d4640060de747768360ba70a7c0 upstream.
    
    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>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 8eb8f07bf70fcbbce1ac985ca32bbee15b3d4f53
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
    
    commit 5a5a1d614287a647b36dff3f40c2b0ceabbc83ec upstream.
    
    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>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 047f96ef719b4e2a0c475775c3489338ed0b9060
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Mon Aug 22 16:58:53 2016 -0400

    USB: fix typo in wMaxPacketSize validation
    
    commit 6c73358c83ce870c0cf32413e5cadb3b9a39c606 upstream.
    
    The maximum value allowed for wMaxPacketSize of a high-speed interrupt
    endpoint is 1024 bytes, not 1023.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Fixes: aed9d65ac327 ("USB: validate wMaxPacketValue entries in endpoint descriptors")
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit addf8b9697f9efb97dd8f599fcf17a3e128cfd5f
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Jul 15 14:09:13 2016 +0300

    crypto: nx - off by one bug in nx_of_update_msc()
    
    commit e514cc0a492a3f39ef71b31590a7ef67537ee04b upstream.
    
    The props->ap[] array is defined like this:
    
            struct alg_props ap[NX_MAX_FC][NX_MAX_MODE][3];
    
    So we can see that if msc->fc and msc->mode are == to NX_MAX_FC or
    NX_MAX_MODE then we're off by one.
    
    Fixes: ae0222b7289d ('powerpc/crypto: nx driver code supporting nx encryption')
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 1bc74ff3eeb249ab98674bb31e92abee566bb3d5
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
    
    commit 47af45d684b5f3ae000ad448db02ce4f13f73273 upstream.
    
    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>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit e5d9fc669fe391ba7bd187873051fec42d7fc7df
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
    
    commit 4097461897df91041382ff6fcd2bfa7ee6b2448c upstream.
    
    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>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f3dfb86ff9b018a667edb90cfc46bd98e3c678e
Author: Vegard Nossum <vegard.nossum@oracle.com>
Date:   Thu Aug 25 15:17:11 2016 -0700

    fs/seq_file: fix out-of-bounds read
    
    commit 088bf2ff5d12e2e32ee52a4024fec26e582f44d3 upstream.
    
    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>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a2bde3ce91848beb790bfa454c062fcc8187061c
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Tue Aug 16 09:58:25 2016 +0200

    gpio: Fix OF build problem on UM
    
    commit 2527ecc9195e9c66252af24c4689e8a67cd4ccb9 upstream.
    
    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: 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: Jiri Slaby <jslaby@suse.cz>

commit 5f4b5f601e7679d14bbeaa406664af6e04e67501
Author: Yinghai Lu <yinghai@kernel.org>
Date:   Fri Aug 5 23:37:34 2016 -0700

    megaraid_sas: Fix probing cards without io port
    
    commit e7f851684efb3377e9c93aca7fae6e76212e5680 upstream.
    
    Found one megaraid_sas HBA probe fails,
    
    [  187.235190] scsi host2: Avago SAS based MegaRAID driver
    [  191.112365] megaraid_sas 0000:89:00.0: BAR 0: can't reserve [io  0x0000-0x00ff]
    [  191.120548] megaraid_sas 0000:89:00.0: IO memory region busy!
    
    and the card has resource like,
    [  125.097714] pci 0000:89:00.0: [1000:005d] type 00 class 0x010400
    [  125.104446] pci 0000:89:00.0: reg 0x10: [io  0x0000-0x00ff]
    [  125.110686] pci 0000:89:00.0: reg 0x14: [mem 0xce400000-0xce40ffff 64bit]
    [  125.118286] pci 0000:89:00.0: reg 0x1c: [mem 0xce300000-0xce3fffff 64bit]
    [  125.125891] pci 0000:89:00.0: reg 0x30: [mem 0xce200000-0xce2fffff pref]
    
    that does not io port resource allocated from BIOS, and kernel can not
    assign one as io port shortage.
    
    The driver is only looking for MEM, and should not fail.
    
    It turns out megasas_init_fw() etc are using bar index as mask.  index 1
    is used as mask 1, so that pci_request_selected_regions() is trying to
    request BAR0 instead of BAR1.
    
    Fix all related reference.
    
    Fixes: b6d5d8808b4c ("megaraid_sas: Use lowest memory bar for SR-IOV VF support")
    Signed-off-by: Yinghai Lu <yinghai@kernel.org>
    Acked-by: Kashyap Desai <kashyap.desai@broadcom.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 35cb28d791be7651ad364219420a276d15866add
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
    
    commit add125054b8727103631dce116361668436ef6a7 upstream.
    
    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>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit bcc85e09fc60d2e99053eae3fd0515c343189375
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
    
    commit fa00c437eef8dc2e7b25f8cd868cfa405fcc2bb3 upstream.
    
    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)'
    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: Jiri Slaby <jslaby@suse.cz>

commit 597df07653db851fa2332b433b794c21ff652b5b
Author: Felix Fietkau <nbd@nbd.name>
Date:   Tue Aug 2 11:13:41 2016 +0200

    mac80211: fix purging multicast PS buffer queue
    
    commit 6b07d9ca9b5363dda959b9582a3fc9c0b89ef3b5 upstream.
    
    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.
    
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit fc62dbc6971b6b57d3574886edaa4fa9f96e5fbd
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
    
    commit 9ba333dc55cbb9523553df973adb3024d223e905 upstream.
    
    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>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 5b02d69d5a58ee0c66334b927821eec38d946378
Author: Emmanouil Maroudas <emmanouil.maroudas@gmail.com>
Date:   Sat Apr 23 18:33:00 2016 +0300

    EDAC: Increment correct counter in edac_inc_ue_error()
    
    commit 993f88f1cc7f0879047ff353e824e5cc8f10adfc upstream.
    
    Fix typo in edac_inc_ue_error() to increment ue_noinfo_count instead of
    ce_noinfo_count.
    
    Signed-off-by: Emmanouil Maroudas <emmanouil.maroudas@gmail.com>
    Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    Cc: linux-edac <linux-edac@vger.kernel.org>
    Fixes: 4275be635597 ("edac: Change internal representation to work with layers")
    Link: http://lkml.kernel.org/r/1461425580-5898-1-git-send-email-emmanouil.maroudas@gmail.com
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit bed2ccd27484d16555021b7ca8ca2b96b8816eb5
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Mon Jan 25 15:30:44 2016 +0200

    xhci: Make sure xhci handles USB_SPEED_SUPER_PLUS devices.
    
    commit 0caf6b33452112e5a1186c8c964e90310e49e6bd upstream.
    
    In most cases the devices with the speed set to USB_SPEED_SUPER_PLUS
    are handled like regular SuperSpeed devices.
    
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 46cfcf58d4f3166e1678db1e2655e127dad6b099
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
    
    commit 6977495c06f7f47636a076ee5a0ca571279d9697 upstream.
    
    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>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 057cb57556906287c48cb68dbb26e4d9c915987b
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
    
    commit ae34d12cc1e212ffcd92e069030e54dae69c832f upstream.
    
    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>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 3f9336dfafbe82480e9d4256cece26f2d975f80c
Author: Daniele Palmas <dnlplm@gmail.com>
Date:   Tue Aug 2 11:29:25 2016 +0200

    USB: serial: option: add support for Telit LE920A4
    
    commit 01d7956b58e644ea0d2e8d9340c5727a8fc39d70 upstream.
    
    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>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 6cb7b8165cdb9e89e7750bc78d627f3651d4c39f
Author: Lubomir Rintel <lkundrak@v3.sk>
Date:   Sun Jul 24 13:53:30 2016 +0200

    USB: serial: option: add D-Link DWM-156/A3
    
    commit cf1b18030de29e4e5b0a57695ae5db4a89da0ff7 upstream.
    
    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>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 4f5e6d558d6bdb5d0206e8f7cbf737d07ca61d38
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
    
    commit 647024a7df36014bbc4479d92d88e6b77c0afcf6 upstream.
    
    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>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a0e3daf77a3cc07d93b0fd6257dbf51a6e3016bf
Author: Jim Lin <jilin@nvidia.com>
Date:   Tue Aug 16 10:18:05 2016 +0300

    usb: xhci: Fix panic if disconnect
    
    commit 88716a93766b8f095cdef37a8e8f2c93aa233b21 upstream.
    
    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>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a78180286845bd78351d36eac6a8ea8b231026d5
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Mon Aug 1 15:25:56 2016 -0400

    USB: validate wMaxPacketValue entries in endpoint descriptors
    
    commit aed9d65ac3278d4febd8665bd7db59ef53e825fe upstream.
    
    Erroneous or malicious endpoint descriptors may have non-zero bits in
    reserved positions, or out-of-bounds values.  This patch helps prevent
    these from causing problems by bounds-checking the wMaxPacketValue
    entries in endpoint descriptors and capping the values at the maximum
    allowed.
    
    This issue was first discovered and tests were conducted by Jake Lamberson
    <jake.lamberson1@gmail.com>, an intern working for Rosie Hall.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: roswest <roswest@cisco.com>
    Tested-by: roswest <roswest@cisco.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 8488473e2db3f291a2d706f0dfc0848cbbb6901e
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Thu Dec 10 09:59:25 2015 +0200

    usb: define USB_SPEED_SUPER_PLUS speed for SuperSpeedPlus USB3.1 devices
    
    commit 8a1b2725a60d3267135c15e80984b4406054f650 upstream.
    
    Add a new USB_SPEED_SUPER_PLUS device speed, and make sure usb core can
    handle the new speed.
    In most cases the behaviour is the same as with USB_SPEED_SUPER SuperSpeed
    devices. In a few places we add a "Plus" string to inform the user of the
    new speed.
    
    [js] backport to 3.12: no use_new_scheme yet
    
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 0cf05a9d7030cd96e90401b83fe8f6658eddd684
Author: Felipe Balbi <felipe.balbi@linux.intel.com>
Date:   Fri Jul 29 03:17:58 2016 +0300

    usb: dwc3: gadget: increment request->actual once
    
    commit c7de573471832dff7d31f0c13b0f143d6f017799 upstream.
    
    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.
    
    Reported-by: Brian E Rogers <brian.e.rogers@intel.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 49fa4f820dafe9c552a62a2f13001972396ff5fb
Author: Simon Horman <simon.horman@netronome.com>
Date:   Fri Dec 11 11:30:12 2015 +0900

    PCI: Limit config space size for Netronome NFP4000
    
    commit c2e771b02792d222cbcd9617fe71482a64f52647 upstream.
    
    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: Jiri Slaby <jslaby@suse.cz>

commit b15280aa98e3faeb780a03ecbee8f77ac3e96080
Author: Simon Horman <simon.horman@netronome.com>
Date:   Fri Dec 11 11:30:11 2015 +0900

    PCI: Add Netronome NFP4000 PF device ID
    
    commit 69874ec233871a62e1bc8c89e643993af93a8630 upstream.
    
    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: Jiri Slaby <jslaby@suse.cz>

commit c78c104a9bfb09d6096e8119b0f8a70d18221db2
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
    
    commit 9f33a2ae59f24452c1076749deb615bccd435ca9 upstream.
    
    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: Jiri Slaby <jslaby@suse.cz>

commit db5ba5779b1f8145576a2b59e6c71697a65286ac
Author: Jason S. McMullan <jason.mcmullan@netronome.com>
Date:   Wed Sep 30 15:35:06 2015 +0900

    PCI: Add Netronome vendor and device IDs
    
    commit a755e169031dac9ebaed03302c4921687c271d62 upstream.
    
    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: Jiri Slaby <jslaby@suse.cz>

commit 20ca8b06b61273bfc9c4137e9b678777bea04910
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
    
    commit c20aecf6963d1273d8f6d61c042b4845441ca592 upstream.
    
    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: Jiri Slaby <jslaby@suse.cz>

commit 7af0891d048a9a5f960571869935d20666ff4fc9
Author: Helge Deller <deller@gmx.de>
Date:   Sat Aug 20 11:51:38 2016 +0200

    parisc: Fix order of EREFUSED define in errno.h
    
    commit 3eb53b20d7bd1374598cfb1feaa081fcac0e76cd upstream.
    
    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>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 29fe597d4b04182ebcf448b0b90cde7ff8f9d2f5
Author: James Hogan <james.hogan@imgtec.com>
Date:   Mon Jul 25 16:59:52 2016 +0100

    arm64: Define AT_VECTOR_SIZE_ARCH for ARCH_DLINFO
    
    commit 3146bc64d12377a74dbda12b96ea32da3774ae07 upstream.
    
    AT_VECTOR_SIZE_ARCH should be defined with the maximum number of
    NEW_AUX_ENT entries that ARCH_DLINFO can contain, but it wasn't defined
    for arm64 at all even though ARCH_DLINFO will contain one NEW_AUX_ENT
    for the VDSO address.
    
    This shouldn't be a problem as AT_VECTOR_SIZE_BASE includes space for
    AT_BASE_PLATFORM which arm64 doesn't use, but lets define it now and add
    the comment above ARCH_DLINFO as found in several other architectures to
    remind future modifiers of ARCH_DLINFO to keep AT_VECTOR_SIZE_ARCH up to
    date.
    
    Fixes: f668cd1673aa ("arm64: ELF definitions")
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: linux-arm-kernel@lists.infradead.org
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 08180d21d4dc457bd6ed494c1363e942f518534c
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Fri Aug 5 15:37:39 2016 +0200

    x86/mm: Disable preemption during CR3 read+write
    
    commit 5cf0791da5c162ebc14b01eb01631cfa7ed4fa6e upstream.
    
    There's a subtle preemption race on UP kernels:
    
    Usually current->mm (and therefore mm->pgd) stays the same during the
    lifetime of a task so it does not matter if a task gets preempted during
    the read and write of the CR3.
    
    But then, there is this scenario on x86-UP:
    
    TaskA is in do_exit() and exit_mm() sets current->mm = NULL followed by:
    
     -> mmput()
     -> exit_mmap()
     -> tlb_finish_mmu()
     -> tlb_flush_mmu()
     -> tlb_flush_mmu_tlbonly()
     -> tlb_flush()
     -> flush_tlb_mm_range()
     -> __flush_tlb_up()
     -> __flush_tlb()
     ->  __native_flush_tlb()
    
    At this point current->mm is NULL but current->active_mm still points to
    the "old" mm.
    
    Let's preempt taskA _after_ native_read_cr3() by taskB. TaskB has its
    own mm so CR3 has changed.
    
    Now preempt back to taskA. TaskA has no ->mm set so it borrows taskB's
    mm and so CR3 remains unchanged. Once taskA gets active it continues
    where it was interrupted and that means it writes its old CR3 value
    back. Everything is fine because userland won't need its memory
    anymore.
    
    Now the fun part:
    
    Let's preempt taskA one more time and get back to taskB. This
    time switch_mm() won't do a thing because oldmm (->active_mm)
    is the same as mm (as per context_switch()). So we remain
    with a bad CR3 / PGD and return to userland.
    
    The next thing that happens is handle_mm_fault() with an address for
    the execution of its code in userland. handle_mm_fault() realizes that
    it has a PTE with proper rights so it returns doing nothing. But the
    CPU looks at the wrong PGD and insists that something is wrong and
    faults again. And again. And one more time…
    
    This pagefault circle continues until the scheduler gets tired of it and
    puts another task on the CPU. It gets little difficult if the task is a
    RT task with a high priority. The system will either freeze or it gets
    fixed by the software watchdog thread which usually runs at RT-max prio.
    But waiting for the watchdog will increase the latency of the RT task
    which is no good.
    
    Fix this by disabling preemption across the critical code section.
    
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Rik van Riel <riel@redhat.com>
    Acked-by: Andy Lutomirski <luto@kernel.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Borislav Petkov <bp@suse.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: Mel Gorman <mgorman@suse.de>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: linux-mm@kvack.org
    Link: http://lkml.kernel.org/r/1470404259-26290-1-git-send-email-bigeasy@linutronix.de
    [ Prettified the changelog. ]
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a528a0fa6d67ebe60bfc762c72b316d28ed21dea
Author: James Hogan <james.hogan@imgtec.com>
Date:   Thu Sep 15 22:51:27 2016 +0100

    MIPS: KVM: Check for pfn noslot case
    
    commit ba913e4f72fc9cfd03dad968dfb110eb49211d80 upstream.
    
    When mapping a page into the guest we error check using is_error_pfn(),
    however this doesn't detect a value of KVM_PFN_NOSLOT, indicating an
    error HVA for the page. This can only happen on MIPS right now due to
    unusual memslot management (e.g. being moved / removed / resized), or
    with an Enhanced Virtual Memory (EVA) configuration where the default
    KVM_HVA_ERR_* and kvm_is_error_hva() definitions are unsuitable (fixed
    in a later patch). This case will be treated as a pfn of zero, mapping
    the first page of physical memory into the guest.
    
    It would appear the MIPS KVM port wasn't updated prior to being merged
    (in v3.10) to take commit 81c52c56e2b4 ("KVM: do not treat noslot pfn as
    a error pfn") into account (merged v3.8), which converted a bunch of
    is_error_pfn() calls to is_error_noslot_pfn(). Switch to using
    is_error_noslot_pfn() instead to catch this case properly.
    
    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: Paolo Bonzini <pbonzini@redhat.com>
    [james.hogan@imgtec.com: Backport to v3.16.y]
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>