commit dd8b674caeef9381345a6369fba29d425ff433f3
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Jul 21 08:12:37 2017 +0200

    Linux 3.18.62

commit da89aa5b8c67b130181e56b3382506a319818091
Author: Pavankumar Kondeti <pkondeti@codeaurora.org>
Date:   Fri Dec 9 21:50:17 2016 +0530

    tracing: Use SOFTIRQ_OFFSET for softirq dectection for more accurate results
    
    commit c59f29cb144a6a0dfac16ede9dc8eafc02dc56ca upstream.
    
    The 's' flag is supposed to indicate that a softirq is running. This
    can be detected by testing the preempt_count with SOFTIRQ_OFFSET.
    
    The current code tests the preempt_count with SOFTIRQ_MASK, which
    would be true even when softirqs are disabled but not serving a
    softirq.
    
    Link: http://lkml.kernel.org/r/1481300417-3564-1-git-send-email-pkondeti@codeaurora.org
    
    Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9abcd35a85b1658ed30fcdc706db2f49ada66b65
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Jul 10 10:21:40 2017 +0300

    PM / QoS: return -EINVAL for bogus strings
    
    commit 2ca30331c156ca9e97643ad05dd8930b8fe78b01 upstream.
    
    In the current code, if the user accidentally writes a bogus command to
    this sysfs file, then we set the latency tolerance to an uninitialized
    variable.
    
    Fixes: 2d984ad132a8 (PM / QoS: Introcuce latency tolerance device PM QoS type)
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8f70f49650b428378320c12dee41122d9f9e258e
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue Apr 25 14:00:49 2017 +0200

    sched/topology: Fix overlapping sched_group_mask
    
    commit 73bb059f9b8a00c5e1bf2f7ca83138c05d05e600 upstream.
    
    The point of sched_group_mask is to select those CPUs from
    sched_group_cpus that can actually arrive at this balance domain.
    
    The current code gets it wrong, as can be readily demonstrated with a
    topology like:
    
      node   0   1   2   3
        0:  10  20  30  20
        1:  20  10  20  30
        2:  30  20  10  20
        3:  20  30  20  10
    
    Where (for example) domain 1 on CPU1 ends up with a mask that includes
    CPU0:
    
      [] CPU1 attaching sched-domain:
      []  domain 0: span 0-2 level NUMA
      []   groups: 1 (mask: 1), 2, 0
      []   domain 1: span 0-3 level NUMA
      []    groups: 0-2 (mask: 0-2) (cpu_capacity: 3072), 0,2-3 (cpu_capacity: 3072)
    
    This causes sched_balance_cpu() to compute the wrong CPU and
    consequently should_we_balance() will terminate early resulting in
    missed load-balance opportunities.
    
    The fixed topology looks like:
    
      [] CPU1 attaching sched-domain:
      []  domain 0: span 0-2 level NUMA
      []   groups: 1 (mask: 1), 2, 0
      []   domain 1: span 0-3 level NUMA
      []    groups: 0-2 (mask: 1) (cpu_capacity: 3072), 0,2-3 (cpu_capacity: 3072)
    
    (note: this relies on OVERLAP domains to always have children, this is
     true because the regular topology domains are still here -- this is
     before degenerate trimming)
    
    Debugged-by: Lauro Ramos Venancio <lvenanci@redhat.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Mike Galbraith <efault@gmx.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: linux-kernel@vger.kernel.org
    Fixes: e3589f6c81e4 ("sched: Allow for overlapping sched_domain spans")
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 49c159f59d5328cc86900fbb175356e1cb0be7f2
Author: Lauro Ramos Venancio <lvenanci@redhat.com>
Date:   Thu Apr 20 16:51:40 2017 -0300

    sched/topology: Optimize build_group_mask()
    
    commit f32d782e31bf079f600dcec126ed117b0577e85c upstream.
    
    The group mask is always used in intersection with the group CPUs. So,
    when building the group mask, we don't have to care about CPUs that are
    not part of the group.
    
    Signed-off-by: Lauro Ramos Venancio <lvenanci@redhat.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Mike Galbraith <efault@gmx.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: lwang@redhat.com
    Cc: riel@redhat.com
    Link: http://lkml.kernel.org/r/1492717903-5195-2-git-send-email-lvenanci@redhat.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be032fd50ba1fccc2ae62ec4770d18660543f6f5
Author: Horia Geantă <horia.geanta@nxp.com>
Date:   Fri Jul 7 16:57:06 2017 +0300

    crypto: caam - fix signals handling
    
    commit 7459e1d25ffefa2b1be799477fcc1f6c62f6cec7 upstream.
    
    Driver does not properly handle the case when signals interrupt
    wait_for_completion_interruptible():
    -it does not check for return value
    -completion structure is allocated on stack; in case a signal interrupts
    the sleep, it will go out of scope, causing the worker thread
    (caam_jr_dequeue) to fail when it accesses it
    
    wait_for_completion_interruptible() is replaced with uninterruptable
    wait_for_completion().
    We choose to block all signals while waiting for I/O (device executing
    the split key generation job descriptor) since the alternative - in
    order to have a deterministic device state - would be to flush the job
    ring (aborting *all* in-progress jobs).
    
    Fixes: 045e36780f115 ("crypto: caam - ahash hmac support")
    Fixes: 4c1ec1f930154 ("crypto: caam - refactor key_gen, sg")
    Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 17ab2212a52caa1233fc74f07e08a4f6464435bf
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Tue Jul 4 12:21:12 2017 +0800

    crypto: sha1-ssse3 - Disable avx2
    
    commit b82ce24426a4071da9529d726057e4e642948667 upstream.
    
    It has been reported that sha1-avx2 can cause page faults by reading
    beyond the end of the input.  This patch disables it until it can be
    fixed.
    
    Fixes: 7c1da8d0d046 ("crypto: sha - SHA1 transform x86_64 AVX2")
    Reported-by: Jan Stancek <jstancek@redhat.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 792282845a49fc92e2b137576ca196a4b4bc5279
Author: Gilad Ben-Yossef <gilad@benyossef.com>
Date:   Wed Jun 28 10:22:03 2017 +0300

    crypto: atmel - only treat EBUSY as transient if backlog
    
    commit 1606043f214f912a52195293614935811a6e3e53 upstream.
    
    The Atmel SHA driver was treating -EBUSY as indication of queueing
    to backlog without checking that backlog is enabled for the request.
    
    Fix it by checking request flags.
    
    Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f608a8c3e9e067eca27a3d703f75a594bd84bc2f
Author: Martin Hicks <mort@bork.org>
Date:   Tue May 2 09:38:35 2017 -0400

    crypto: talitos - Extend max key length for SHA384/512-HMAC and AEAD
    
    commit 03d2c5114c95797c0aa7d9f463348b171a274fd4 upstream.
    
    An updated patch that also handles the additional key length requirements
    for the AEAD algorithms.
    
    The max keysize is not 96.  For SHA384/512 it's 128, and for the AEAD
    algorithms it's longer still.  Extend the max keysize for the
    AEAD size for AES256 + HMAC(SHA512).
    
    Fixes: 357fb60502ede ("crypto: talitos - add sha224, sha384 and sha512 to existing AEAD algorithms")
    Signed-off-by: Martin Hicks <mort@bork.org>
    Acked-by: Horia Geantă <horia.geanta@nxp.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 07b65f64a30b412012578ec57c8e7ec401b528ca
Author: Helge Deller <deller@gmx.de>
Date:   Fri Jul 14 14:49:38 2017 -0700

    mm: fix overflow check in expand_upwards()
    
    commit 37511fb5c91db93d8bd6e3f52f86e5a7ff7cfcdf upstream.
    
    Jörn Engel noticed that the expand_upwards() function might not return
    -ENOMEM in case the requested address is (unsigned long)-PAGE_SIZE and
    if the architecture didn't defined TASK_SIZE as multiple of PAGE_SIZE.
    
    Affected architectures are arm, frv, m68k, blackfin, h8300 and xtensa
    which all define TASK_SIZE as 0xffffffff, but since none of those have
    an upwards-growing stack we currently have no actual issue.
    
    Nevertheless let's fix this just in case any of the architectures with
    an upward-growing stack (currently parisc, metag and partly ia64) define
    TASK_SIZE similar.
    
    Link: http://lkml.kernel.org/r/20170702192452.GA11868@p100.box
    Fixes: bd726c90b6b8 ("Allow stack to grow up to address space limit")
    Signed-off-by: Helge Deller <deller@gmx.de>
    Reported-by: Jörn Engel <joern@purestorage.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 91f57354c85ae0ba0d6f17b2dc410d4240f5a8c3
Author: Adam Borowski <kilobyte@angband.pl>
Date:   Sat Jun 3 09:35:06 2017 +0200

    vt: fix unchecked __put_user() in tioclinux ioctls
    
    commit 6987dc8a70976561d22450b5858fc9767788cc1c upstream.
    
    Only read access is checked before this call.
    
    Actually, at the moment this is not an issue, as every in-tree arch does
    the same manual checks for VERIFY_READ vs VERIFY_WRITE, relying on the MMU
    to tell them apart, but this wasn't the case in the past and may happen
    again on some odd arch in the future.
    
    If anyone cares about 3.7 and earlier, this is a security hole (untested)
    on real 80386 CPUs.
    
    Signed-off-by: Adam Borowski <kilobyte@angband.pl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 915d918369390e5746794ca0d38a40ba05745b4a
Author: Kees Cook <keescook@chromium.org>
Date:   Fri Jul 7 11:57:29 2017 -0700

    exec: Limit arg stack to at most 75% of _STK_LIM
    
    commit da029c11e6b12f321f36dac8771e833b65cec962 upstream.
    
    To avoid pathological stack usage or the need to special-case setuid
    execs, just limit all arg stack usage to at most 75% of _STK_LIM (6MB).
    
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9034de1dc17fc062b42f30b762e18cd94eb68fa4
Author: Cyril Bur <cyrilbur@gmail.com>
Date:   Mon Jul 10 15:52:21 2017 -0700

    checkpatch: silence perl 5.26.0 unescaped left brace warnings
    
    commit 8d81ae05d0176da1c54aeaed697fa34be5c5575e upstream.
    
    As of perl 5, version 26, subversion 0 (v5.26.0) some new warnings have
    occurred when running checkpatch.
    
    Unescaped left brace in regex is deprecated here (and will be fatal in
    Perl 5.30), passed through in regex; marked by <-- HERE in m/^(.\s*){
    <-- HERE \s*/ at scripts/checkpatch.pl line 3544.
    
    Unescaped left brace in regex is deprecated here (and will be fatal in
    Perl 5.30), passed through in regex; marked by <-- HERE in m/^(.\s*){
    <-- HERE \s*/ at scripts/checkpatch.pl line 3885.
    
    Unescaped left brace in regex is deprecated here (and will be fatal in
    Perl 5.30), passed through in regex; marked by <-- HERE in
    m/^(\+.*(?:do|\))){ <-- HERE / at scripts/checkpatch.pl line 4374.
    
    It seems perfectly reasonable to do as the warning suggests and simply
    escape the left brace in these three locations.
    
    Link: http://lkml.kernel.org/r/20170607060135.17384-1-cyrilbur@gmail.com
    Signed-off-by: Cyril Bur <cyrilbur@gmail.com>
    Acked-by: Joe Perches <joe@perches.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 44c1a9e2f9b3e4db7c5779add97b56a32da33ad7
Author: Sahitya Tummala <stummala@codeaurora.org>
Date:   Mon Jul 10 15:50:00 2017 -0700

    fs/dcache.c: fix spin lockup issue on nlru->lock
    
    commit b17c070fb624cf10162cf92ea5e1ec25cd8ac176 upstream.
    
    __list_lru_walk_one() acquires nlru spin lock (nlru->lock) for longer
    duration if there are more number of items in the lru list.  As per the
    current code, it can hold the spin lock for upto maximum UINT_MAX
    entries at a time.  So if there are more number of items in the lru
    list, then "BUG: spinlock lockup suspected" is observed in the below
    path:
    
      spin_bug+0x90
      do_raw_spin_lock+0xfc
      _raw_spin_lock+0x28
      list_lru_add+0x28
      dput+0x1c8
      path_put+0x20
      terminate_walk+0x3c
      path_lookupat+0x100
      filename_lookup+0x6c
      user_path_at_empty+0x54
      SyS_faccessat+0xd0
      el0_svc_naked+0x24
    
    This nlru->lock is acquired by another CPU in this path -
    
      d_lru_shrink_move+0x34
      dentry_lru_isolate_shrink+0x48
      __list_lru_walk_one.isra.10+0x94
      list_lru_walk_node+0x40
      shrink_dcache_sb+0x60
      do_remount_sb+0xbc
      do_emergency_remount+0xb0
      process_one_work+0x228
      worker_thread+0x2e0
      kthread+0xf4
      ret_from_fork+0x10
    
    Fix this lockup by reducing the number of entries to be shrinked from
    the lru list to 1024 at once.  Also, add cond_resched() before
    processing the lru list again.
    
    Link: http://marc.info/?t=149722864900001&r=1&w=2
    Link: http://lkml.kernel.org/r/1498707575-2472-1-git-send-email-stummala@codeaurora.org
    Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
    Suggested-by: Jan Kara <jack@suse.cz>
    Suggested-by: Vladimir Davydov <vdavydov.dev@gmail.com>
    Acked-by: Vladimir Davydov <vdavydov.dev@gmail.com>
    Cc: Alexander Polakov <apolyakov@beget.ru>
    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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8766889caa01ba67969ff9987682834c8625fea6
Author: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
Date:   Thu Jul 6 15:35:31 2017 -0700

    kernel/extable.c: mark core_kernel_text notrace
    
    commit c0d80ddab89916273cb97114889d3f337bc370ae upstream.
    
    core_kernel_text is used by MIPS in its function graph trace processing,
    so having this method traced leads to an infinite set of recursive calls
    such as:
    
      Call Trace:
         ftrace_return_to_handler+0x50/0x128
         core_kernel_text+0x10/0x1b8
         prepare_ftrace_return+0x6c/0x114
         ftrace_graph_caller+0x20/0x44
         return_to_handler+0x10/0x30
         return_to_handler+0x0/0x30
         return_to_handler+0x0/0x30
         ftrace_ops_no_ops+0x114/0x1bc
         core_kernel_text+0x10/0x1b8
         core_kernel_text+0x10/0x1b8
         core_kernel_text+0x10/0x1b8
         ftrace_ops_no_ops+0x114/0x1bc
         core_kernel_text+0x10/0x1b8
         prepare_ftrace_return+0x6c/0x114
         ftrace_graph_caller+0x20/0x44
         (...)
    
    Mark the function notrace to avoid it being traced.
    
    Link: http://lkml.kernel.org/r/1498028607-6765-1-git-send-email-marcin.nowakowski@imgtec.com
    Signed-off-by: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
    Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Meyer <thomas@m3y3r.de>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3eb7672cbf8bdd917971479d40b0b4bdf1f1ad9a
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Thu May 25 12:58:33 2017 +0000

    tools/lib/lockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing lock_chain/: Depth
    
    commit 98dcea0cfd04e083ac74137ceb9a632604740e2d upstream.
    
    liblockdep has been broken since commit 75dd602a5198 ("lockdep: Fix
    lock_chain::base size"), as that adds a check that MAX_LOCK_DEPTH is
    within the range of lock_chain::depth and in liblockdep it is much
    too large.
    
    That should have resulted in a compiler error, but didn't because:
    
    - the check uses ARRAY_SIZE(), which isn't yet defined in liblockdep
      so is assumed to be an (undeclared) function
    - putting a function call inside a BUILD_BUG_ON() expression quietly
      turns it into some nonsense involving a variable-length array
    
    It did produce a compiler warning, but I didn't notice because
    liblockdep already produces too many warnings if -Wall is enabled
    (which I'll fix shortly).
    
    Even before that commit, which reduced lock_chain::depth from 8 bits
    to 6, MAX_LOCK_DEPTH was too large.
    
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: a.p.zijlstra@chello.nl
    Link: http://lkml.kernel.org/r/20170525130005.5947-3-alexander.levin@verizon.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit de7a2dcb0e3ae398e9689859e40662dcd6724040
Author: Helge Deller <deller@gmx.de>
Date:   Mon May 29 17:14:16 2017 +0200

    parisc/mm: Ensure IRQs are off in switch_mm()
    
    commit 649aa24254e85bf6bd7807dd372d083707852b1f upstream.
    
    This is because of commit f98db6013c55 ("sched/core: Add switch_mm_irqs_off()
    and use it in the scheduler") in which switch_mm_irqs_off() is called by the
    scheduler, vs switch_mm() which is used by use_mm().
    
    This patch lets the parisc code mirror the x86 and powerpc code, ie. it
    disables interrupts in switch_mm(), and optimises the scheduler case by
    defining switch_mm_irqs_off().
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c6006ec76a7c741ce91f59cc06ed07ecf618daef
Author: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Date:   Mon Jul 3 10:38:05 2017 +0200

    parisc: DMA API: return error instead of BUG_ON for dma ops on non dma devs
    
    commit 33f9e02495d15a061f0c94ef46f5103a2d0c20f3 upstream.
    
    Enabling parport pc driver on a B2600 (and probably other 64bit PARISC
    systems) produced following BUG:
    
    CPU: 0 PID: 1 Comm: swapper Not tainted 4.12.0-rc5-30198-g1132d5e #156
    task: 000000009e050000 task.stack: 000000009e04c000
    
         YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
    PSW: 00001000000001101111111100001111 Not tainted
    r00-03  000000ff0806ff0f 000000009e04c990 0000000040871b78 000000009e04cac0
    r04-07  0000000040c14de0 ffffffffffffffff 000000009e07f098 000000009d82d200
    r08-11  000000009d82d210 0000000000000378 0000000000000000 0000000040c345e0
    r12-15  0000000000000005 0000000040c345e0 0000000000000000 0000000040c9d5e0
    r16-19  0000000040c345e0 00000000f00001c4 00000000f00001bc 0000000000000061
    r20-23  000000009e04ce28 0000000000000010 0000000000000010 0000000040b89e40
    r24-27  0000000000000003 0000000000ffffff 000000009d82d210 0000000040c14de0
    r28-31  0000000000000000 000000009e04ca90 000000009e04cb40 0000000000000000
    sr00-03  0000000000000000 0000000000000000 0000000000000000 0000000000000000
    sr04-07  0000000000000000 0000000000000000 0000000000000000 0000000000000000
    
    IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000404aece0 00000000404aece4
     IIR: 03ffe01f    ISR: 0000000010340000  IOR: 000001781304cac8
     CPU:        0   CR30: 000000009e04c000 CR31: 00000000e2976de2
     ORIG_R28: 0000000000000200
     IAOQ[0]: sba_dma_supported+0x80/0xd0
     IAOQ[1]: sba_dma_supported+0x84/0xd0
     RP(r2): parport_pc_probe_port+0x178/0x1200
    
    Cause is a call to dma_coerce_mask_and_coherenet in parport_pc_probe_port,
    which PARISC DMA API doesn't handle very nicely. This commit gives back
    DMA_ERROR_CODE for DMA API calls, if device isn't capable of DMA
    transaction.
    
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2566eeeda9891bfc3585826e5b68629a704c64da
Author: Eric Biggers <ebiggers@google.com>
Date:   Mon Jun 12 23:18:30 2017 -0700

    parisc: use compat_sys_keyctl()
    
    commit b0f94efd5aa8daa8a07d7601714c2573266cd4c9 upstream.
    
    Architectures with a compat syscall table must put compat_sys_keyctl()
    in it, not sys_keyctl().  The parisc architecture was not doing this;
    fix it.
    
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Acked-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd01854e969acfb1671bff680fa169a850c10845
Author: Helge Deller <deller@gmx.de>
Date:   Sun Jul 2 22:00:41 2017 +0200

    parisc: Report SIGSEGV instead of SIGBUS when running out of stack
    
    commit 247462316f85a9e0479445c1a4223950b68ffac1 upstream.
    
    When a process runs out of stack the parisc kernel wrongly faults with SIGBUS
    instead of the expected SIGSEGV signal.
    
    This example shows how the kernel faults:
    do_page_fault() command='a.out' type=15 address=0xfaac2000 in libc-2.24.so[f8308000+16c000]
    trap #15: Data TLB miss fault, vm_start = 0xfa2c2000, vm_end = 0xfaac2000
    
    The vma->vm_end value is the first address which does not belong to the vma, so
    adjust the check to include vma->vm_end to the range for which to send the
    SIGSEGV signal.
    
    This patch unbreaks building the debian libsigsegv package.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 655dff165880e4222589b52ab55a6411f04be272
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Fri Jun 30 10:58:28 2017 +0100

    irqchip/gic-v3: Fix out-of-bound access in gic_set_affinity
    
    commit 866d7c1b0a3c70387646c4e455e727a58c5d465a upstream.
    
    The GICv3 driver doesn't check if the target CPU for gic_set_affinity
    is valid before going ahead and making the changes. This triggers the
    following splat with KASAN:
    
    [  141.189434] BUG: KASAN: global-out-of-bounds in gic_set_affinity+0x8c/0x140
    [  141.189704] Read of size 8 at addr ffff200009741d20 by task swapper/1/0
    [  141.189958]
    [  141.190158] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.12.0-rc7
    [  141.190458] Hardware name: Foundation-v8A (DT)
    [  141.190658] Call trace:
    [  141.190908] [<ffff200008089d70>] dump_backtrace+0x0/0x328
    [  141.191224] [<ffff20000808a1b4>] show_stack+0x14/0x20
    [  141.191507] [<ffff200008504c3c>] dump_stack+0xa4/0xc8
    [  141.191858] [<ffff20000826c19c>] print_address_description+0x13c/0x250
    [  141.192219] [<ffff20000826c5c8>] kasan_report+0x210/0x300
    [  141.192547] [<ffff20000826ad54>] __asan_load8+0x84/0x98
    [  141.192874] [<ffff20000854eeec>] gic_set_affinity+0x8c/0x140
    [  141.193158] [<ffff200008148b14>] irq_do_set_affinity+0x54/0xb8
    [  141.193473] [<ffff200008148d2c>] irq_set_affinity_locked+0x64/0xf0
    [  141.193828] [<ffff200008148e00>] __irq_set_affinity+0x48/0x78
    [  141.194158] [<ffff200008bc48a4>] arm_perf_starting_cpu+0x104/0x150
    [  141.194513] [<ffff2000080d73bc>] cpuhp_invoke_callback+0x17c/0x1f8
    [  141.194783] [<ffff2000080d94ec>] notify_cpu_starting+0x8c/0xb8
    [  141.195130] [<ffff2000080911ec>] secondary_start_kernel+0x15c/0x200
    [  141.195390] [<0000000080db81b4>] 0x80db81b4
    [  141.195603]
    [  141.195685] The buggy address belongs to the variable:
    [  141.196012]  __cpu_logical_map+0x200/0x220
    [  141.196176]
    [  141.196315] Memory state around the buggy address:
    [  141.196586]  ffff200009741c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [  141.196913]  ffff200009741c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [  141.197158] >ffff200009741d00: 00 00 00 00 fa fa fa fa 00 00 00 00 00 00 00 00
    [  141.197487]                                ^
    [  141.197758]  ffff200009741d80: 00 00 00 00 00 00 00 00 fa fa fa fa 00 00 00 00
    [  141.198060]  ffff200009741e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [  141.198358] ==================================================================
    [  141.198609] Disabling lock debugging due to kernel taint
    [  141.198961] CPU1: Booted secondary processor [410fd051]
    
    This patch adds the check to make sure the cpu is valid.
    
    Fixes: commit 021f653791ad17e03f98 ("irqchip: gic-v3: Initial support for GICv3")
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8f859a8a86ccd31d590ef4b5e04dc81496475d8b
Author: Srinivas Dasari <dasaris@qti.qualcomm.com>
Date:   Fri Jul 7 01:43:39 2017 +0300

    cfg80211: Check if PMKID attribute is of expected size
    
    commit 9361df14d1cbf966409d5d6f48bb334384fbe138 upstream.
    
    nla policy checks for only maximum length of the attribute data
    when the attribute type is NLA_BINARY. If userspace sends less
    data than specified, the wireless drivers may access illegal
    memory. When type is NLA_UNSPEC, nla policy check ensures that
    userspace sends minimum specified length number of bytes.
    
    Remove type assignment to NLA_BINARY from nla_policy of
    NL80211_ATTR_PMKID to make this NLA_UNSPEC and to make sure minimum
    WLAN_PMKID_LEN bytes are received from userspace with
    NL80211_ATTR_PMKID.
    
    Fixes: 67fbb16be69d ("nl80211: PMKSA caching support")
    Signed-off-by: Srinivas Dasari <dasaris@qti.qualcomm.com>
    Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e9e04fa55ae6540720af2dba5a955666014260a1
Author: Srinivas Dasari <dasaris@qti.qualcomm.com>
Date:   Fri Jul 7 01:43:42 2017 +0300

    cfg80211: Validate frequencies nested in NL80211_ATTR_SCAN_FREQUENCIES
    
    commit d7f13f7450369281a5d0ea463cc69890a15923ae upstream.
    
    validate_scan_freqs() retrieves frequencies from attributes
    nested in the attribute NL80211_ATTR_SCAN_FREQUENCIES with
    nla_get_u32(), which reads 4 bytes from each attribute
    without validating the size of data received. Attributes
    nested in NL80211_ATTR_SCAN_FREQUENCIES don't have an nla policy.
    
    Validate size of each attribute before parsing to avoid potential buffer
    overread.
    
    Fixes: 2a519311926 ("cfg80211/nl80211: scanning (and mac80211 update to use it)")
    Signed-off-by: Srinivas Dasari <dasaris@qti.qualcomm.com>
    Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 55520ec2ca6a85ab1e2a51210f414cf0f9f5fe7a
Author: Srinivas Dasari <dasaris@qti.qualcomm.com>
Date:   Fri Jul 7 01:43:41 2017 +0300

    cfg80211: Define nla_policy for NL80211_ATTR_LOCAL_MESH_POWER_MODE
    
    commit 8feb69c7bd89513be80eb19198d48f154b254021 upstream.
    
    Buffer overread may happen as nl80211_set_station() reads 4 bytes
    from the attribute NL80211_ATTR_LOCAL_MESH_POWER_MODE without
    validating the size of data received when userspace sends less
    than 4 bytes of data with NL80211_ATTR_LOCAL_MESH_POWER_MODE.
    Define nla_policy for NL80211_ATTR_LOCAL_MESH_POWER_MODE to avoid
    the buffer overread.
    
    Fixes: 3b1c5a5307f ("{cfg,nl}80211: mesh power mode primitives and userspace access")
    Signed-off-by: Srinivas Dasari <dasaris@qti.qualcomm.com>
    Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ae10cf5c80b897b3a46ef1bdf77a52dd84bd336d
Author: Arend van Spriel <arend.vanspriel@broadcom.com>
Date:   Fri Jul 7 21:09:06 2017 +0100

    brcmfmac: fix possible buffer overflow in brcmf_cfg80211_mgmt_tx()
    
    commit 8f44c9a41386729fea410e688959ddaa9d51be7c upstream.
    
    The lower level nl80211 code in cfg80211 ensures that "len" is between
    25 and NL80211_ATTR_FRAME (2304).  We subtract DOT11_MGMT_HDR_LEN (24) from
    "len" so thats's max of 2280.  However, the action_frame->data[] buffer is
    only BRCMF_FIL_ACTION_FRAME_SIZE (1800) bytes long so this memcpy() can
    overflow.
    
            memcpy(action_frame->data, &buf[DOT11_MGMT_HDR_LEN],
                   le16_to_cpu(action_frame->len));
    
    Fixes: 18e2f61db3b70 ("brcmfmac: P2P action frame tx.")
    Reported-by: "freenerguo(郭大兴)" <freenerguo@tencent.com>
    Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 430bf4d3b44ef970f607698ee18e5b6f26da046e
Author: Sabrina Dubroca <sd@queasysnail.net>
Date:   Thu Jun 29 16:56:54 2017 +0200

    ipv6: dad: don't remove dynamic addresses if link is down
    
    commit ec8add2a4c9df723c94a863b8fcd6d93c472deed upstream.
    
    Currently, when the link for $DEV is down, this command succeeds but the
    address is removed immediately by DAD (1):
    
        ip addr add 1111::12/64 dev $DEV valid_lft 3600 preferred_lft 1800
    
    In the same situation, this will succeed and not remove the address (2):
    
        ip addr add 1111::12/64 dev $DEV
        ip addr change 1111::12/64 dev $DEV valid_lft 3600 preferred_lft 1800
    
    The comment in addrconf_dad_begin() when !IF_READY makes it look like
    this is the intended behavior, but doesn't explain why:
    
         * If the device is not ready:
         * - keep it tentative if it is a permanent address.
         * - otherwise, kill it.
    
    We clearly cannot prevent userspace from doing (2), but we can make (1)
    work consistently with (2).
    
    addrconf_dad_stop() is only called in two cases: if DAD failed, or to
    skip DAD when the link is down. In that second case, the fix is to avoid
    deleting the address, like we already do for permanent addresses.
    
    Fixes: 3c21edbd1137 ("[IPV6]: Defer IPv6 device initialization until the link becomes ready.")
    Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 57c094c29cfb48d795e232487bcaebe41c3c768e
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jun 27 07:02:20 2017 -0700

    net: prevent sign extension in dev_get_stats()
    
    commit 6f64ec74515925cced6df4571638b5a099a49aae upstream.
    
    Similar to the fix provided by Dominik Heidler in commit
    9b3dc0a17d73 ("l2tp: cast l2tp traffic counter to unsigned")
    we need to take care of 32bit kernels in dev_get_stats().
    
    When using atomic_long_read(), we add a 'long' to u64 and
    might misinterpret high order bit, unless we cast to unsigned.
    
    Fixes: caf586e5f23ce ("net: add a core netdev->rx_dropped counter")
    Fixes: 015f0688f57ca ("net: net: add a core netdev->tx_dropped counter")
    Fixes: 6e7333d315a76 ("net: add rx_nohandler stat counter")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Jarod Wilson <jarod@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 24b8df0b45849cd270d9f7efd552bb4281016d11
Author: WANG Cong <xiyou.wangcong@gmail.com>
Date:   Sat Jun 24 23:50:30 2017 -0700

    tcp: reset sk_rx_dst in tcp_disconnect()
    
    commit d747a7a51b00984127a88113cdbbc26f91e9d815 upstream.
    
    We have to reset the sk->sk_rx_dst when we disconnect a TCP
    connection, because otherwise when we re-connect it this
    dst reference is simply overridden in tcp_finish_connect().
    
    This fixes a dst leak which leads to a loopback dev refcnt
    leak. It is a long-standing bug, Kevin reported a very similar
    (if not same) bug before. Thanks to Andrei for providing such
    a reliable reproducer which greatly narrows down the problem.
    
    Fixes: 41063e9dd119 ("ipv4: Early TCP socket demux.")
    Reported-by: Andrei Vagin <avagin@gmail.com>
    Reported-by: Kevin Xu <kaiwen.xu@hulu.com>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e88fa5f09b1f98c3e907937415d0038ba9af3044
Author: WANG Cong <xiyou.wangcong@gmail.com>
Date:   Wed Jun 21 14:34:58 2017 -0700

    ipv6: avoid unregistering inet6_dev for loopback
    
    commit 60abc0be96e00ca71bac083215ac91ad2e575096 upstream.
    
    The per netns loopback_dev->ip6_ptr is unregistered and set to
    NULL when its mtu is set to smaller than IPV6_MIN_MTU, this
    leads to that we could set rt->rt6i_idev NULL after a
    rt6_uncached_list_flush_dev() and then crash after another
    call.
    
    In this case we should just bring its inet6_dev down, rather
    than unregistering it, at least prior to commit 176c39af29bc
    ("netns: fix addrconf_ifdown kernel panic") we always
    override the case for loopback.
    
    Thanks a lot to Andrey for finding a reliable reproducer.
    
    Fixes: 176c39af29bc ("netns: fix addrconf_ifdown kernel panic")
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Cc: Andrey Konovalov <andreyknvl@google.com>
    Cc: Daniel Lezcano <dlezcano@fr.ibm.com>
    Cc: David Ahern <dsahern@gmail.com>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Acked-by: David Ahern <dsahern@gmail.com>
    Tested-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>