commit 557ac4e2077364ff58c69fc524a8fc79c83870bf
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Feb 15 08:09:14 2019 +0100

    Linux 4.14.100

commit f142573d9cb63ccbcfc311ce5c997191b1df55e9
Author: Xiubo Li <xiubli@redhat.com>
Date:   Wed Feb 13 16:29:39 2019 +0000

    Revert "uio: use request_threaded_irq instead"
    
    commit 3d27c4de8d4fb2d4099ff324671792aa2578c6f9 upstream.
    
    Since mutex lock in irq hanler is useless currently, here will
    remove it together with it.
    
    This reverts commit 9421e45f5ff3d558cf8b75a8cc0824530caf3453.
    
    Reported-by: james.r.harris@intel.com
    CC: Ahsan Atta <ahsan.atta@intel.com>
    Signed-off-by: Xiubo Li <xiubli@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Tommi Rantala <tommi.t.rantala@nokia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5d07d245cb418064561c1a4e57313cf0a9132aa6
Author: Xiubo Li <xiubli@redhat.com>
Date:   Wed Feb 13 16:29:36 2019 +0000

    uio: fix possible circular locking dependency
    
    commit b34e9a15b37b8ddbf06a4da142b0c39c74211eb4 upstream.
    
    The call trace:
    XXX/1910 is trying to acquire lock:
     (&mm->mmap_sem){++++++}, at: [<ffffffff97008c87>] might_fault+0x57/0xb0
    
    but task is already holding lock:
     (&idev->info_lock){+.+...}, at: [<ffffffffc0638a06>] uio_write+0x46/0x130 [uio]
    
    which lock already depends on the new lock.
    
    the existing dependency chain (in reverse order) is:
    
    -> #1 (&idev->info_lock){+.+...}:
           [<ffffffff96f31fc9>] lock_acquire+0x99/0x1e0
           [<ffffffff975edad3>] mutex_lock_nested+0x93/0x410
           [<ffffffffc063873d>] uio_mmap+0x2d/0x170 [uio]
           [<ffffffff97016b58>] mmap_region+0x428/0x650
           [<ffffffff97017138>] do_mmap+0x3b8/0x4e0
           [<ffffffff96ffaba3>] vm_mmap_pgoff+0xd3/0x120
           [<ffffffff97015261>] SyS_mmap_pgoff+0x1f1/0x270
           [<ffffffff96e387c2>] SyS_mmap+0x22/0x30
           [<ffffffff975ff315>] system_call_fastpath+0x1c/0x21
    
    -> #0 (&mm->mmap_sem){++++++}:
           [<ffffffff96f30e9c>] __lock_acquire+0xdac/0x15f0
           [<ffffffff96f31fc9>] lock_acquire+0x99/0x1e0
           [<ffffffff97008cb4>] might_fault+0x84/0xb0
           [<ffffffffc0638a74>] uio_write+0xb4/0x130 [uio]
           [<ffffffff9706ffa3>] vfs_write+0xc3/0x1f0
           [<ffffffff97070e2a>] SyS_write+0x8a/0x100
           [<ffffffff975ff315>] system_call_fastpath+0x1c/0x21
    
    other info that might help us debug this:
     Possible unsafe locking scenario:
           CPU0                    CPU1
           ----                    ----
      lock(&idev->info_lock);
                                   lock(&mm->mmap_sem);
                                   lock(&idev->info_lock);
      lock(&mm->mmap_sem);
    
     *** DEADLOCK ***
    1 lock held by XXX/1910:
     #0:  (&idev->info_lock){+.+...}, at: [<ffffffffc0638a06>] uio_write+0x46/0x130 [uio]
    
    stack backtrace:
    CPU: 0 PID: 1910 Comm: XXX Kdump: loaded Not tainted #1
    Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017
    Call Trace:
     [<ffffffff975e9211>] dump_stack+0x19/0x1b
     [<ffffffff975e260a>] print_circular_bug+0x1f9/0x207
     [<ffffffff96f2f6a7>] check_prevs_add+0x957/0x960
     [<ffffffff96f30e9c>] __lock_acquire+0xdac/0x15f0
     [<ffffffff96f2fb19>] ? mark_held_locks+0xb9/0x140
     [<ffffffff96f31fc9>] lock_acquire+0x99/0x1e0
     [<ffffffff97008c87>] ? might_fault+0x57/0xb0
     [<ffffffff97008cb4>] might_fault+0x84/0xb0
     [<ffffffff97008c87>] ? might_fault+0x57/0xb0
     [<ffffffffc0638a74>] uio_write+0xb4/0x130 [uio]
     [<ffffffff9706ffa3>] vfs_write+0xc3/0x1f0
     [<ffffffff9709349c>] ? fget_light+0xfc/0x510
     [<ffffffff97070e2a>] SyS_write+0x8a/0x100
     [<ffffffff975ff315>] system_call_fastpath+0x1c/0x21
    
    Signed-off-by: Xiubo Li <xiubli@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Tommi Rantala <tommi.t.rantala@nokia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 28c618abeee3380a4ead50fe9863b692dd851e07
Author: Hailong Liu <liu.hailong6@zte.com.cn>
Date:   Wed Feb 13 16:29:36 2019 +0000

    uio: fix wrong return value from uio_mmap()
    
    commit e7de2590f18a272e63732b9d519250d1b522b2c4 upstream.
    
    uio_mmap has multiple fail paths to set return value to nonzero then
    goto out. However, it always returns *0* from the *out* at end, and
    this will mislead callers who check the return value of this function.
    
    Fixes: 57c5f4df0a5a0ee ("uio: fix crash after the device is unregistered")
    CC: Xiubo Li <xiubli@redhat.com>
    Signed-off-by: Hailong Liu <liu.hailong6@zte.com.cn>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Jiang Biao <jiang.biao2@zte.com.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Tommi Rantala <tommi.t.rantala@nokia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 13af019c87f2d90e663742cb1a819834048842ae
Author: Xiubo Li <xiubli@redhat.com>
Date:   Wed Feb 13 16:29:34 2019 +0000

    uio: fix crash after the device is unregistered
    
    commit 57c5f4df0a5a0ee83df799991251e2ee93a5e4e9 upstream.
    
    For the target_core_user use case, after the device is unregistered
    it maybe still opened in user space, then the kernel will crash, like:
    
    [  251.163692] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
    [  251.163820] IP: [<ffffffffc0736213>] show_name+0x23/0x40 [uio]
    [  251.163965] PGD 8000000062694067 PUD 62696067 PMD 0
    [  251.164097] Oops: 0000 [#1] SMP
    ...
    [  251.165605]  e1000 mptscsih mptbase drm_panel_orientation_quirks dm_mirror dm_region_hash dm_log dm_mod
    [  251.166014] CPU: 0 PID: 13380 Comm: tcmu-runner Kdump: loaded Not tainted 3.10.0-916.el7.test.x86_64 #1
    [  251.166381] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017
    [  251.166747] task: ffff971eb91db0c0 ti: ffff971e9e384000 task.ti: ffff971e9e384000
    [  251.167137] RIP: 0010:[<ffffffffc0736213>]  [<ffffffffc0736213>] show_name+0x23/0x40 [uio]
    [  251.167563] RSP: 0018:ffff971e9e387dc8  EFLAGS: 00010282
    [  251.167978] RAX: 0000000000000000 RBX: ffff971e9e3f8000 RCX: ffff971eb8368d98
    [  251.168408] RDX: ffff971e9e3f8000 RSI: ffffffffc0738084 RDI: ffff971e9e3f8000
    [  251.168856] RBP: ffff971e9e387dd0 R08: ffff971eb8bc0018 R09: 0000000000000000
    [  251.169296] R10: 0000000000001000 R11: ffffffffa09d444d R12: ffffffffa1076e80
    [  251.169750] R13: ffff971e9e387f18 R14: 0000000000000001 R15: ffff971e9cfb1c80
    [  251.170213] FS:  00007ff37d175880(0000) GS:ffff971ebb600000(0000) knlGS:0000000000000000
    [  251.170693] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  251.171248] CR2: 0000000000000008 CR3: 00000000001f6000 CR4: 00000000003607f0
    [  251.172071] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  251.172640] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [  251.173236] Call Trace:
    [  251.173789]  [<ffffffffa0c9b2d3>] dev_attr_show+0x23/0x60
    [  251.174356]  [<ffffffffa0f561b2>] ? mutex_lock+0x12/0x2f
    [  251.174892]  [<ffffffffa0ac6d9f>] sysfs_kf_seq_show+0xcf/0x1f0
    [  251.175433]  [<ffffffffa0ac54e6>] kernfs_seq_show+0x26/0x30
    [  251.175981]  [<ffffffffa0a63be0>] seq_read+0x110/0x3f0
    [  251.176609]  [<ffffffffa0ac5d45>] kernfs_fop_read+0xf5/0x160
    [  251.177158]  [<ffffffffa0a3d3af>] vfs_read+0x9f/0x170
    [  251.177707]  [<ffffffffa0a3e27f>] SyS_read+0x7f/0xf0
    [  251.178268]  [<ffffffffa0f648af>] system_call_fastpath+0x1c/0x21
    [  251.178823] Code: 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 53 48 89 d3 e8 7e 96 56 e0 48 8b 80 d8 02 00 00 48 89 df 48 c7 c6 84 80 73 c0 <48> 8b 50 08 31 c0 e8 e2 67 44 e0 5b 48 98 5d c3 0f 1f 00 66 2e
    [  251.180115] RIP  [<ffffffffc0736213>] show_name+0x23/0x40 [uio]
    [  251.180820]  RSP <ffff971e9e387dc8>
    [  251.181473] CR2: 0000000000000008
    
    CC: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
    CC: Mike Christie <mchristi@redhat.com>
    Reviewed-by: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
    Signed-off-by: Xiubo Li <xiubli@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Tommi Rantala <tommi.t.rantala@nokia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3f400c2c2e7043b64c65d9b8709a0b353e1f8384
Author: Xiubo Li <xiubli@redhat.com>
Date:   Wed Feb 13 16:29:33 2019 +0000

    uio: change to use the mutex lock instead of the spin lock
    
    commit 543af5861f41af0a5d2432f6fb5976af50f9cee5 upstream.
    
    We are hitting a regression with the following commit:
    
    commit a93e7b331568227500186a465fee3c2cb5dffd1f
    Author: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
    Date:   Mon May 14 13:32:23 2018 +1200
    
        uio: Prevent device destruction while fds are open
    
    The problem is the addition of spin_lock_irqsave in uio_write. This
    leads to hitting  uio_write -> copy_from_user -> _copy_from_user ->
    might_fault and the logs filling up with sleeping warnings.
    
    I also noticed some uio drivers allocate memory, sleep, grab mutexes
    from callouts like open() and release and uio is now doing
    spin_lock_irqsave while calling them.
    
    Reported-by: Mike Christie <mchristi@redhat.com>
    CC: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
    Reviewed-by: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
    Signed-off-by: Xiubo Li <xiubli@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Tommi Rantala <tommi.t.rantala@nokia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a68c55d15af981361ce324d90ee06e8276d330c
Author: Xiubo Li <xiubli@redhat.com>
Date:   Wed Feb 13 16:29:31 2019 +0000

    uio: use request_threaded_irq instead
    
    commit 9421e45f5ff3d558cf8b75a8cc0824530caf3453 upstream.
    
    Prepraing for changing to use mutex lock.
    
    Signed-off-by: Xiubo Li <xiubli@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Tommi Rantala <tommi.t.rantala@nokia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 085d735c858934e5d5bfaedb1fc98bd9135e6ff1
Author: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
Date:   Wed Feb 13 16:29:29 2019 +0000

    uio: Prevent device destruction while fds are open
    
    commit a93e7b331568227500186a465fee3c2cb5dffd1f upstream.
    
    Prevent destruction of a uio_device while user space apps hold open
    file descriptors to that device. Further, access to the 'info' member
    of the struct uio_device is protected by spinlock. This is to ensure
    stale pointers to data not under control of the UIO subsystem are not
    dereferenced.
    
    Signed-off-by: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
    Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [4.14 change __poll_t to unsigned int]
    Signed-off-by: Tommi Rantala <tommi.t.rantala@nokia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd4fe6339ccd9638da1304160abe60b84115dee5
Author: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
Date:   Wed Feb 13 16:29:24 2019 +0000

    uio: Reduce return paths from uio_write()
    
    commit 81daa406c2cc97d85eef9409400404efc2a3f756 upstream.
    
    Drive all return paths for uio_write() through a single block at the
    end of the function.
    
    Signed-off-by: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
    Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Tommi Rantala <tommi.t.rantala@nokia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 943f5f2a7d70f117a730dceb58131957f3c337c8
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Mon Oct 9 15:07:12 2017 +0200

    perf tests attr: Make hw events optional
    
    commit 692f5a22cd284bb8233a38e3ed86881d2d9c89d4 upstream.
    
    Otherwise we fail on virtual machines with no support for specific HW
    events.
    
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Cc: David Ahern <dsahern@gmail.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/20171009130712.14747-1-jolsa@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: "Rantala, Tommi T. (Nokia - FI/Espoo)" <tommi.t.rantala@nokia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3fbfbd393fbe0b064e39df81775538490e0625c4
Author: Jiri Olsa <jolsa@redhat.com>
Date:   Thu Sep 28 18:06:33 2017 +0200

    perf tests attr: Fix group stat tests
    
    commit f6a9820d572bd8384d982357cbad214b3a6c04bb upstream.
    
    We started to use group read whenever it's possible:
    
      82bf311e15d2 perf stat: Use group read for event groups
    
    That breaks some of attr tests, this change adds the new possible
    read_format value.
    
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
    Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
    Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Cc: Thomas-Mich Richter <tmricht@linux.vnet.ibm.com>
    LPU-Reference: 20170928160633.GA26973@krava
    Link: http://lkml.kernel.org/n/tip-1ko2zc4nph93d8lfwjyk9ivz@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: "Rantala, Tommi T. (Nokia - FI/Espoo)" <tommi.t.rantala@nokia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ffc2faad73247fe57fd64c4f315dbacb5cd34572
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Mon Jul 3 16:50:30 2017 +0200

    perf tests attr: Fix task term values
    
    commit 10836d9f9ac63d40ccfa756f871ce4ed51ae3b52 upstream.
    
    The perf_event_attr::task is 1 by default for first (tracking) event in
    the session. Setting task=1 as default and adding task=0 for cases that
    need it.
    
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Cc: David Ahern <dsahern@gmail.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Thomas-Mich Richter <tmricht@linux.vnet.ibm.com>
    Link: http://lkml.kernel.org/r/20170703145030.12903-16-jolsa@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: "Rantala, Tommi T. (Nokia - FI/Espoo)" <tommi.t.rantala@nokia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0ee47efddd0568853d8ad548e00d1681351d12ec
Author: Sven Eckelmann <sven@narfation.org>
Date:   Mon Dec 31 22:31:01 2018 +0100

    batman-adv: Force mac header to start of data on xmit
    
    commit 9114daa825fc3f335f9bea3313ce667090187280 upstream.
    
    The caller of ndo_start_xmit may not already have called
    skb_reset_mac_header. The returned value of skb_mac_header/eth_hdr
    therefore can be in the wrong position and even outside the current skbuff.
    This for example happens when the user binds to the device using a
    PF_PACKET-SOCK_RAW with enabled qdisc-bypass:
    
      int opt = 4;
      setsockopt(sock, SOL_PACKET, PACKET_QDISC_BYPASS, &opt, sizeof(opt));
    
    Since eth_hdr is used all over the codebase, the batadv_interface_tx
    function must always take care of resetting it.
    
    Fixes: c6c8fea29769 ("net: Add batman-adv meshing protocol")
    Reported-by: syzbot+9d7405c7faa390e60b4e@syzkaller.appspotmail.com
    Reported-by: syzbot+7d20bc3f1ddddc0f9079@syzkaller.appspotmail.com
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d66213863ade314c5f24c07aba74e31fd8b8c3b1
Author: Sven Eckelmann <sven@narfation.org>
Date:   Sun Dec 30 12:46:01 2018 +0100

    batman-adv: Avoid WARN on net_device without parent in netns
    
    commit 955d3411a17f590364238bd0d3329b61f20c1cd2 upstream.
    
    It is not allowed to use WARN* helpers on potential incorrect input from
    the user or transient problems because systems configured as panic_on_warn
    will reboot due to such a problem.
    
    A NULL return value of __dev_get_by_index can be caused by various problems
    which can either be related to the system configuration or problems
    (incorrectly returned network namespaces) in other (virtual) net_device
    drivers. batman-adv should not cause a (harmful) WARN in this situation and
    instead only report it via a simple message.
    
    Fixes: b7eddd0b3950 ("batman-adv: prevent using any virtual device created on batman-adv as hard-interface")
    Reported-by: syzbot+c764de0fcfadca9a8595@syzkaller.appspotmail.com
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc09fc5d8acd819a3e06f2894975a328e375e2f7
Author: Florian Westphal <fw@strlen.de>
Date:   Wed Jan 9 14:37:34 2019 +0100

    xfrm: refine validation of template and selector families
    
    commit 35e6103861a3a970de6c84688c6e7a1f65b164ca upstream.
    
    The check assumes that in transport mode, the first templates family
    must match the address family of the policy selector.
    
    Syzkaller managed to build a template using MODE_ROUTEOPTIMIZATION,
    with ipv4-in-ipv6 chain, leading to following splat:
    
    BUG: KASAN: stack-out-of-bounds in xfrm_state_find+0x1db/0x1854
    Read of size 4 at addr ffff888063e57aa0 by task a.out/2050
     xfrm_state_find+0x1db/0x1854
     xfrm_tmpl_resolve+0x100/0x1d0
     xfrm_resolve_and_create_bundle+0x108/0x1000 [..]
    
    Problem is that addresses point into flowi4 struct, but xfrm_state_find
    treats them as being ipv6 because it uses templ->encap_family is used
    (AF_INET6 in case of reproducer) rather than family (AF_INET).
    
    This patch inverts the logic: Enforce 'template family must match
    selector' EXCEPT for tunnel and BEET mode.
    
    In BEET and Tunnel mode, xfrm_tmpl_resolve_one will have remote/local
    address pointers changed to point at the addresses found in the template,
    rather than the flowi ones, so no oob read will occur.
    
    Reported-by: 3ntr0py1337@gmail.com
    Reported-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 264c83c2fe7b78b545b52b2bc7cc88855eac6c78
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Mon Jan 14 21:13:10 2019 +0100

    libceph: avoid KEEPALIVE_PENDING races in ceph_con_keepalive()
    
    commit 4aac9228d16458cedcfd90c7fb37211cf3653ac3 upstream.
    
    con_fault() can transition the connection into STANDBY right after
    ceph_con_keepalive() clears STANDBY in clear_standby():
    
        libceph user thread               ceph-msgr worker
    
    ceph_con_keepalive()
      mutex_lock(&con->mutex)
      clear_standby(con)
      mutex_unlock(&con->mutex)
                                    mutex_lock(&con->mutex)
                                    con_fault()
                                      ...
                                      if KEEPALIVE_PENDING isn't set
                                        set state to STANDBY
                                      ...
                                    mutex_unlock(&con->mutex)
      set KEEPALIVE_PENDING
      set WRITE_PENDING
    
    This triggers warnings in clear_standby() when either ceph_con_send()
    or ceph_con_keepalive() get to clearing STANDBY next time.
    
    I don't see a reason to condition queue_con() call on the previous
    value of KEEPALIVE_PENDING, so move the setting of KEEPALIVE_PENDING
    into the critical section -- unlike WRITE_PENDING, KEEPALIVE_PENDING
    could have been a non-atomic flag.
    
    Reported-by: syzbot+acdeb633f6211ccdf886@syzkaller.appspotmail.com
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Tested-by: Myungho Jung <mhjungk@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 850d47601371d800a4e8d46ac08a09c5c3aa3891
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Thu Jan 31 23:41:11 2019 -0500

    Revert "ext4: use ext4_write_inode() when fsyncing w/o a journal"
    
    commit 8fdd60f2ae3682caf2a7258626abc21eb4711892 upstream.
    
    This reverts commit ad211f3e94b314a910d4af03178a0b52a7d1ee0a.
    
    As Jan Kara pointed out, this change was unsafe since it means we lose
    the call to sync_mapping_buffers() in the nojournal case.  The
    original point of the commit was avoid taking the inode mutex (since
    it causes a lockdep warning in generic/113); but we need the mutex in
    order to call sync_mapping_buffers().
    
    The real fix to this problem was discussed here:
    
    https://lore.kernel.org/lkml/20181025150540.259281-4-bvanassche@acm.org
    
    The proposed patch was to fix a syzbot complaint, but the problem can
    also demonstrated via "kvm-xfstests -c nojournal generic/113".
    Multiple solutions were discused in the e-mail thread, but none have
    landed in the kernel as of this writing.  Anyway, commit
    ad211f3e94b314 is absolutely the wrong way to suppress the lockdep, so
    revert it.
    
    Fixes: ad211f3e94b314a910d4af03178a0b52a7d1ee0a ("ext4: use ext4_write_inode() when fsyncing w/o a journal")
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Reported: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e0f784bf571528011a7421021f72dbe4bfe10a7c
Author: Vladis Dronov <vdronov@redhat.com>
Date:   Tue Jan 29 11:58:35 2019 +0100

    HID: debug: fix the ring buffer implementation
    
    commit 13054abbaa4f1fd4e6f3b4b63439ec033b4c8035 upstream.
    
    Ring buffer implementation in hid_debug_event() and hid_debug_events_read()
    is strange allowing lost or corrupted data. After commit 717adfdaf147
    ("HID: debug: check length before copy_to_user()") it is possible to enter
    an infinite loop in hid_debug_events_read() by providing 0 as count, this
    locks up a system. Fix this by rewriting the ring buffer implementation
    with kfifo and simplify the code.
    
    This fixes CVE-2019-3819.
    
    v2: fix an execution logic and add a comment
    v3: use __set_current_state() instead of set_current_state()
    
    Backport to v4.14: 2 tree-wide patches 6396bb22151 ("treewide: kzalloc() ->
    kcalloc()") and a9a08845e9ac ("vfs: do bulk POLL* -> EPOLL* replacement")
    are missing in v4.14 so cherry-pick relevant pieces.
    
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=1669187
    Cc: stable@vger.kernel.org # v4.18+
    Fixes: cd667ce24796 ("HID: use debugfs for events/reports dumping")
    Fixes: 717adfdaf147 ("HID: debug: check length before copy_to_user()")
    Signed-off-by: Vladis Dronov <vdronov@redhat.com>
    Reviewed-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7fa5536f92fe647c2462c8a64a129706f1a8da63
Author: Thomas Hellstrom <thellstrom@vmware.com>
Date:   Thu Jan 31 10:55:37 2019 +0100

    drm/vmwgfx: Return error code from vmw_execbuf_copy_fence_user
    
    commit 728354c005c36eaf44b6e5552372b67e60d17f56 upstream.
    
    The function was unconditionally returning 0, and a caller would have to
    rely on the returned fence pointer being NULL to detect errors. However,
    the function vmw_execbuf_copy_fence_user() would expect a non-zero error
    code in that case and would BUG otherwise.
    
    So make sure we return a proper non-zero error code if the fence pointer
    returned is NULL.
    
    Cc: <stable@vger.kernel.org>
    Fixes: ae2a104058e2: ("vmwgfx: Implement fence objects")
    Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
    Reviewed-by: Deepak Rawat <drawat@vmware.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d69e310cbfcbbf5c7b409c477005355487aa79f4
Author: Thomas Hellstrom <thellstrom@vmware.com>
Date:   Mon Jan 28 10:31:33 2019 +0100

    drm/vmwgfx: Fix setting of dma masks
    
    commit 4cbfa1e6c09e98450aab3240e5119b0ab2c9795b upstream.
    
    Previously we set only the dma mask and not the coherent mask. Fix that.
    Also, for clarity, make sure both are initially set to 64 bits.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 0d00c488f3de: ("drm/vmwgfx: Fix the driver for large dma addresses")
    Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
    Reviewed-by: Deepak Rawat <drawat@vmware.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 90c7dfa37723f974c8a29155cc38e76ab8ea4a2d
Author: Tina Zhang <tina.zhang@intel.com>
Date:   Wed Jan 23 15:28:59 2019 +0800

    drm/modes: Prevent division by zero htotal
    
    commit a2fcd5c84f7a7825e028381b10182439067aa90d upstream.
    
    This patch prevents division by zero htotal.
    
    In a follow-up mail Tina writes:
    
    > > How did you manage to get here with htotal == 0? This needs backtraces (or if
    > > this is just about static checkers, a mention of that).
    > > -Daniel
    >
    > In GVT-g, we are trying to enable a virtual display w/o setting timings for a pipe
    > (a.k.a htotal=0), then we met the following kernel panic:
    >
    > [   32.832048] divide error: 0000 [#1] SMP PTI
    > [   32.833614] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.0-rc4-sriov+ #33
    > [   32.834438] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.10.1-0-g8891697-dirty-20180511_165818-tinazhang-linux-1 04/01/2014
    > [   32.835901] RIP: 0010:drm_mode_hsync+0x1e/0x40
    > [   32.836004] Code: 31 c0 c3 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 8b 87 d8 00 00 00 85 c0 75 22 8b 4f 68 85 c9 78 1b 69 47 58 e8 03 00 00 99 <f7> f9 b9 d3 4d 62 10 05 f4 01 00 00 f7 e1 89 d0 c1 e8 06 f3 c3 66
    > [   32.836004] RSP: 0000:ffffc900000ebb90 EFLAGS: 00010206
    > [   32.836004] RAX: 0000000000000000 RBX: ffff88001c67c8a0 RCX: 0000000000000000
    > [   32.836004] RDX: 0000000000000000 RSI: ffff88001c67c000 RDI: ffff88001c67c8a0
    > [   32.836004] RBP: ffff88001c7d03a0 R08: ffff88001c67c8a0 R09: ffff88001c7d0330
    > [   32.836004] R10: ffffffff822c3a98 R11: 0000000000000001 R12: ffff88001c67c000
    > [   32.836004] R13: ffff88001c7d0370 R14: ffffffff8207eb78 R15: ffff88001c67c800
    > [   32.836004] FS:  0000000000000000(0000) GS:ffff88001da00000(0000) knlGS:0000000000000000
    > [   32.836004] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    > [   32.836004] CR2: 0000000000000000 CR3: 000000000220a000 CR4: 00000000000006f0
    > [   32.836004] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    > [   32.836004] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    > [   32.836004] Call Trace:
    > [   32.836004]  intel_mode_from_pipe_config+0x72/0x90
    > [   32.836004]  intel_modeset_setup_hw_state+0x569/0xf90
    > [   32.836004]  intel_modeset_init+0x905/0x1db0
    > [   32.836004]  i915_driver_load+0xb8c/0x1120
    > [   32.836004]  i915_pci_probe+0x4d/0xb0
    > [   32.836004]  local_pci_probe+0x44/0xa0
    > [   32.836004]  ? pci_assign_irq+0x27/0x130
    > [   32.836004]  pci_device_probe+0x102/0x1c0
    > [   32.836004]  driver_probe_device+0x2b8/0x480
    > [   32.836004]  __driver_attach+0x109/0x110
    > [   32.836004]  ? driver_probe_device+0x480/0x480
    > [   32.836004]  bus_for_each_dev+0x67/0xc0
    > [   32.836004]  ? klist_add_tail+0x3b/0x70
    > [   32.836004]  bus_add_driver+0x1e8/0x260
    > [   32.836004]  driver_register+0x5b/0xe0
    > [   32.836004]  ? mipi_dsi_bus_init+0x11/0x11
    > [   32.836004]  do_one_initcall+0x4d/0x1eb
    > [   32.836004]  kernel_init_freeable+0x197/0x237
    > [   32.836004]  ? rest_init+0xd0/0xd0
    > [   32.836004]  kernel_init+0xa/0x110
    > [   32.836004]  ret_from_fork+0x35/0x40
    > [   32.836004] Modules linked in:
    > [   32.859183] ---[ end trace 525608b0ed0e8665 ]---
    > [   32.859722] RIP: 0010:drm_mode_hsync+0x1e/0x40
    > [   32.860287] Code: 31 c0 c3 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 8b 87 d8 00 00 00 85 c0 75 22 8b 4f 68 85 c9 78 1b 69 47 58 e8 03 00 00 99 <f7> f9 b9 d3 4d 62 10 05 f4 01 00 00 f7 e1 89 d0 c1 e8 06 f3 c3 66
    > [   32.862680] RSP: 0000:ffffc900000ebb90 EFLAGS: 00010206
    > [   32.863309] RAX: 0000000000000000 RBX: ffff88001c67c8a0 RCX: 0000000000000000
    > [   32.864182] RDX: 0000000000000000 RSI: ffff88001c67c000 RDI: ffff88001c67c8a0
    > [   32.865206] RBP: ffff88001c7d03a0 R08: ffff88001c67c8a0 R09: ffff88001c7d0330
    > [   32.866359] R10: ffffffff822c3a98 R11: 0000000000000001 R12: ffff88001c67c000
    > [   32.867213] R13: ffff88001c7d0370 R14: ffffffff8207eb78 R15: ffff88001c67c800
    > [   32.868075] FS:  0000000000000000(0000) GS:ffff88001da00000(0000) knlGS:0000000000000000
    > [   32.868983] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    > [   32.869659] CR2: 0000000000000000 CR3: 000000000220a000 CR4: 00000000000006f0
    > [   32.870599] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    > [   32.871598] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    > [   32.872549] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
    >
    > Since drm_mode_hsync() has the logic to check mode->htotal, I just extend it to cover the case htotal==0.
    
    Signed-off-by: Tina Zhang <tina.zhang@intel.com>
    Cc: Adam Jackson <ajax@redhat.com>
    Cc: Dave Airlie <airlied@redhat.com>
    Cc: Daniel Vetter <daniel@ffwll.ch>
    [danvet: Add additional explanations + cc: stable.]
    Cc: stable@vger.kernel.org
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/1548228539-3061-1-git-send-email-tina.zhang@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2243296f1144ddefb9f435c1f4f5e6042481dac7
Author: Felix Fietkau <nbd@nbd.name>
Date:   Tue Jan 29 11:10:57 2019 +0100

    mac80211: ensure that mgmt tx skbs have tailroom for encryption
    
    commit 9d0f50b80222dc273e67e4e14410fcfa4130a90c upstream.
    
    Some drivers use IEEE80211_KEY_FLAG_SW_MGMT_TX to indicate that management
    frames need to be software encrypted. Since normal data packets are still
    encrypted by the hardware, crypto_tx_tailroom_needed_cnt gets decremented
    after key upload to hw. This can lead to passing skbs to ccmp_encrypt_skb,
    which don't have the necessary tailroom for software encryption.
    
    Change the code to add tailroom for encrypted management packets, even if
    crypto_tx_tailroom_needed_cnt is 0.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39551af0e4e6562a859b96aed99a011f756038b7
Author: Marc Gonzalez <marc.w.gonzalez@free.fr>
Date:   Wed Jan 16 16:49:58 2019 +0100

    ARM: tango: Improve ARCH_MULTIPLATFORM compatibility
    
    commit d0f9f16788e15d9eb40f68b047732d49658c5a3a upstream.
    
    Calling platform-specific code unconditionally blows up when running
    an ARCH_MULTIPLATFORM kernel on a different platform. Don't do it.
    
    Reported-by: Paolo Pisati <p.pisati@gmail.com>
    Signed-off-by: Marc Gonzalez <marc.w.gonzalez@free.fr>
    Acked-by: Pavel Machek <pavel@ucw.cz>
    Cc: stable@vger.kernel.org # v4.8+
    Fixes: a30eceb7a59d ("ARM: tango: add Suspend-to-RAM support")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec61525653a2d6c6914b1070681bdfc23c3c5885
Author: Russell King <rmk+kernel@armlinux.org.uk>
Date:   Fri Jan 25 20:10:15 2019 +0000

    ARM: iop32x/n2100: fix PCI IRQ mapping
    
    commit db4090920ba2d61a5827a23e441447926a02ffee upstream.
    
    Booting 4.20 on a TheCUS N2100 results in a kernel oops while probing
    PCI, due to n2100_pci_map_irq() having been discarded during boot.
    
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Cc: stable@vger.kernel.org # 2.6.18+
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c2e0cb20f8fb5bd2dcc76d00c74c99223de8bd42
Author: Paul Burton <paul.burton@mips.com>
Date:   Mon Jan 28 23:16:22 2019 +0000

    MIPS: VDSO: Include $(ccflags-vdso) in o32,n32 .lds builds
    
    commit 67fc5dc8a541e8f458d7f08bf88ff55933bf9f9d upstream.
    
    When generating vdso-o32.lds & vdso-n32.lds for use with programs
    running as compat ABIs under 64b kernels, we previously haven't included
    the compiler flags that are supposedly common to all ABIs - ie. those in
    the ccflags-vdso variable.
    
    This is problematic in cases where we need to provide the -m%-float flag
    in order to ensure that we don't attempt to use a floating point ABI
    that's incompatible with the target CPU & ABI. For example a toolchain
    using current gcc trunk configured --with-fp-32=xx fails to build a
    64r6el_defconfig kernel with the following error:
    
      cc1: error: '-march=mips1' requires '-mfp32'
      make[2]: *** [arch/mips/vdso/Makefile:135: arch/mips/vdso/vdso-o32.lds] Error 1
    
    Include $(ccflags-vdso) for the compat VDSO .lds builds, just as it is
    included for the native VDSO .lds & when compiling objects for the
    compat VDSOs. This ensures we consistently provide the -msoft-float flag
    amongst others, avoiding the problem by ensuring we're agnostic to the
    toolchain defaults.
    
    Signed-off-by: Paul Burton <paul.burton@mips.com>
    Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
    Cc: linux-mips@vger.kernel.org
    Cc: Kevin Hilman <khilman@baylibre.com>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Cc: Maciej W . Rozycki <macro@linux-mips.org>
    Cc: stable@vger.kernel.org # v4.4+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c87691444b5f2bbf6bf2fd374000615e5ffc0372
Author: Aaro Koskinen <aaro.koskinen@iki.fi>
Date:   Sun Jan 27 23:28:33 2019 +0200

    MIPS: OCTEON: don't set octeon_dma_bar_type if PCI is disabled
    
    commit dcf300a69ac307053dfb35c2e33972e754a98bce upstream.
    
    Don't set octeon_dma_bar_type if PCI is disabled. This avoids creation
    of the MSI irqchip later on, and saves a bit of memory.
    
    Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Signed-off-by: Paul Burton <paul.burton@mips.com>
    Fixes: a214720cbf50 ("Disable MSI also when pcie-octeon.pcie_disable on")
    Cc: stable@vger.kernel.org # v3.3+
    Cc: linux-mips@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb5c1f624e6383e7a41f07b42dc6140b31baf495
Author: Vladimir Kondratiev <vladimir.kondratiev@linux.intel.com>
Date:   Wed Feb 6 13:46:17 2019 +0200

    mips: cm: reprime error cause
    
    commit 05dc6001af0630e200ad5ea08707187fe5537e6d upstream.
    
    Accordingly to the documentation
    ---cut---
    The GCR_ERROR_CAUSE.ERR_TYPE field and the GCR_ERROR_MULT.ERR_TYPE
    fields can be cleared by either a reset or by writing the current
    value of GCR_ERROR_CAUSE.ERR_TYPE to the
    GCR_ERROR_CAUSE.ERR_TYPE register.
    ---cut---
    Do exactly this. Original value of cm_error may be safely written back;
    it clears error cause and keeps other bits untouched.
    
    Fixes: 3885c2b463f6 ("MIPS: CM: Add support for reporting CM cache errors")
    Signed-off-by: Vladimir Kondratiev <vladimir.kondratiev@linux.intel.com>
    Signed-off-by: Paul Burton <paul.burton@mips.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: James Hogan <jhogan@kernel.org>
    Cc: linux-mips@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Cc: stable@vger.kernel.org # v4.3+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b49be10b2e624c4f50ae39239f112782addbcc4a
Author: Andreas Ziegler <andreas.ziegler@fau.de>
Date:   Thu Jan 17 14:30:23 2019 +0100

    tracing: uprobes: Fix typo in pr_fmt string
    
    commit ea6eb5e7d15e1838de335609994b4546e2abcaaf upstream.
    
    The subsystem-specific message prefix for uprobes was also
    "trace_kprobe: " instead of "trace_uprobe: " as described in
    the original commit message.
    
    Link: http://lkml.kernel.org/r/20190117133023.19292-1-andreas.ziegler@fau.de
    
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: stable@vger.kernel.org
    Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
    Fixes: 7257634135c24 ("tracing/probe: Show subsystem name in messages")
    Signed-off-by: Andreas Ziegler <andreas.ziegler@fau.de>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c87bdb9e8148c9955192d4ef4acdb889a557cd6d
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Jan 23 11:27:02 2019 +0100

    debugfs: fix debugfs_rename parameter checking
    
    commit d88c93f090f708c18195553b352b9f205e65418f upstream.
    
    debugfs_rename() needs to check that the dentries passed into it really
    are valid, as sometimes they are not (i.e. if the return value of
    another debugfs call is passed into this one.)  So fix this up by
    properly checking if the two parent directories are errors (they are
    allowed to be NULL), and if the dentry to rename is not NULL or an
    error.
    
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aef80fd68017793d14fddc3b4ef8e1c050b44faf
Author: Tomas Winkler <tomas.winkler@intel.com>
Date:   Thu Jan 24 14:45:03 2019 +0200

    samples: mei: use /dev/mei0 instead of /dev/mei
    
    commit c4a46acf1db3ce547d290c29e55b3476c78dd76c upstream.
    
    The device was moved from misc device to character devices
    to support multiple mei devices.
    
    Cc: <stable@vger.kernel.org> #v4.9+
    Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7e21768dfff37e71fed34f3f2cfcfadfd55b7d07
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Dec 3 17:52:19 2018 +0300

    misc: vexpress: Off by one in vexpress_syscfg_exec()
    
    commit f8a70d8b889f180e6860cb1f85fed43d37844c5a upstream.
    
    The > comparison should be >= to prevent reading beyond the end of the
    func->template[] array.
    
    (The func->template array is allocated in vexpress_syscfg_regmap_init()
    and it has func->num_templates elements.)
    
    Fixes: 974cc7b93441 ("mfd: vexpress: Define the device as MFD cells")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Sudeep Holla <sudeep.holla@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 284f7b1a09d73107ec4492dabd3a2b6db28122ee
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Wed Feb 6 17:51:47 2019 -0600

    signal: Better detection of synchronous signals
    
    commit 7146db3317c67b517258cb5e1b08af387da0618b upstream.
    
    Recently syzkaller was able to create unkillablle processes by
    creating a timer that is delivered as a thread local signal on SIGHUP,
    and receiving SIGHUP SA_NODEFERER.  Ultimately causing a loop failing
    to deliver SIGHUP but always trying.
    
    When the stack overflows delivery of SIGHUP fails and force_sigsegv is
    called.  Unfortunately because SIGSEGV is numerically higher than
    SIGHUP next_signal tries again to deliver a SIGHUP.
    
    From a quality of implementation standpoint attempting to deliver the
    timer SIGHUP signal is wrong.  We should attempt to deliver the
    synchronous SIGSEGV signal we just forced.
    
    We can make that happening in a fairly straight forward manner by
    instead of just looking at the signal number we also look at the
    si_code.  In particular for exceptions (aka synchronous signals) the
    si_code is always greater than 0.
    
    That still has the potential to pick up a number of asynchronous
    signals as in a few cases the same si_codes that are used
    for synchronous signals are also used for asynchronous signals,
    and SI_KERNEL is also included in the list of possible si_codes.
    
    Still the heuristic is much better and timer signals are definitely
    excluded.  Which is enough to prevent all known ways for someone
    sending a process signals fast enough to cause unexpected and
    arguably incorrect behavior.
    
    Cc: stable@vger.kernel.org
    Fixes: a27341cd5fcb ("Prioritize synchronous signals over 'normal' signals")
    Tested-by: Dmitry Vyukov <dvyukov@google.com>
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3edbf7432556ccc1cade629b567972bd96414c63
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Wed Feb 6 18:39:40 2019 -0600

    signal: Always notice exiting tasks
    
    commit 35634ffa1751b6efd8cf75010b509dcb0263e29b upstream.
    
    Recently syzkaller was able to create unkillablle processes by
    creating a timer that is delivered as a thread local signal on SIGHUP,
    and receiving SIGHUP SA_NODEFERER.  Ultimately causing a loop
    failing to deliver SIGHUP but always trying.
    
    Upon examination it turns out part of the problem is actually most of
    the solution.  Since 2.5 signal delivery has found all fatal signals,
    marked the signal group for death, and queued SIGKILL in every threads
    thread queue relying on signal->group_exit_code to preserve the
    information of which was the actual fatal signal.
    
    The conversion of all fatal signals to SIGKILL results in the
    synchronous signal heuristic in next_signal kicking in and preferring
    SIGHUP to SIGKILL.  Which is especially problematic as all
    fatal signals have already been transformed into SIGKILL.
    
    Instead of dequeueing signals and depending upon SIGKILL to
    be the first signal dequeued, first test if the signal group
    has already been marked for death.  This guarantees that
    nothing in the signal queue can prevent a process that needs
    to exit from exiting.
    
    Cc: stable@vger.kernel.org
    Tested-by: Dmitry Vyukov <dvyukov@google.com>
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Ref: ebf5ebe31d2c ("[PATCH] signal-fixes-2.5.59-A4")
    History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4c93500004f23cb198713c6bb35c946334e35821
Author: Matt Ranostay <matt.ranostay@konsulko.com>
Date:   Sun Dec 30 19:07:01 2018 -0800

    iio: chemical: atlas-ph-sensor: correct IIO_TEMP values to millicelsius
    
    commit 0808831dc62e90023ad14ff8da4804c7846e904b upstream.
    
    IIO_TEMP scale value for temperature was incorrect and not in millicelsius
    as required by the ABI documentation.
    
    Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>
    Fixes: 27dec00ecf2d (iio: chemical: add Atlas pH-SM sensor support)
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4337e2073104a051982ab08724c5116c8ce1d325
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sat Jan 5 19:36:18 2019 +0100

    iio: adc: axp288: Fix TS-pin handling
    
    commit 9bcf15f75cac3c6a00d8f8083a635de9c8537799 upstream.
    
    Prior to this commit there were 3 issues with our handling of the TS-pin:
    
    1) There are 2 ways how the firmware can disable monitoring of the TS-pin
    for designs which do not have a temperature-sensor for the battery:
    a) Clearing bit 0 of the AXP20X_ADC_EN1 register
    b) Setting bit 2 of the AXP288_ADC_TS_PIN_CTRL monitoring
    
    Prior to this commit we were unconditionally setting both bits to the
    value used on devices with a TS. This causes the temperature protection to
    kick in on devices without a TS, such as the Jumper ezbook v2, causing
    them to not charge under Linux.
    
    This commit fixes this by using regmap_update_bits when updating these 2
    registers, leaving the 2 mentioned bits alone.
    
    The next 2 problems are related to our handling of the current-source
    for the TS-pin. The current-source used for the battery temp-sensor (TS)
    is shared with the GPADC. For proper fuel-gauge and charger operation the
    TS current-source needs to be permanently on. But to read the GPADC we
    need to temporary switch the TS current-source to ondemand, so that the
    GPADC can use it, otherwise we will always read an all 0 value.
    
    2) Problem 2 is we were writing hardcoded values to the ADC TS pin-ctrl
    register, overwriting various other unrelated bits. Specifically we were
    overwriting the current-source setting for the TS and GPIO0 pins, forcing
    it to 80ųA independent of its original setting. On a Chuwi Vi10 tablet
    this was causing us to get a too high adc value (due to a too high
    current-source) resulting in the following errors being logged:
    
    ACPI Error: AE_ERROR, Returned by Handler for [UserDefinedRegion]
    ACPI Error: Method parse/execution failed \_SB.SXP1._TMP, AE_ERROR
    
    This commit fixes this by using regmap_update_bits to change only the
    relevant bits.
    
    3) After reading the GPADC channel we were unconditionally enabling the
    TS current-source even on devices where the TS-pin is not used and the
    current-source thus was off before axp288_adc_read_raw call.
    
    This commit fixes this by making axp288_adc_set_ts a nop on devices where
    the ADC is not enabled for the TS-pin.
    
    BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1610545
    Fixes: 3091141d7803 ("iio: adc: axp288: Fix the GPADC pin ...")
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ec492edfa17233b04a6525a731c4df82097ed32
Author: Martin Kepplinger <martin.kepplinger@ginzinger.com>
Date:   Tue Feb 5 16:52:51 2019 +0100

    mtd: rawnand: gpmi: fix MX28 bus master lockup problem
    
    commit d5d27fd9826b59979b184ec288e4812abac0e988 upstream.
    
    Disable BCH soft reset according to MX23 erratum #2847 ("BCH soft
    reset may cause bus master lock up") for MX28 too. It has the same
    problem.
    
    Observed problem: once per 100,000+ MX28 reboots NAND read failed on
    DMA timeout errors:
    [    1.770823] UBI: attaching mtd3 to ubi0
    [    2.768088] gpmi_nand: DMA timeout, last DMA :1
    [    3.958087] gpmi_nand: BCH timeout, last DMA :1
    [    4.156033] gpmi_nand: Error in ECC-based read: -110
    [    4.161136] UBI warning: ubi_io_read: error -110 while reading 64
    bytes from PEB 0:0, read only 0 bytes, retry
    [    4.171283] step 1 error
    [    4.173846] gpmi_nand: Chip: 0, Error -1
    
    Without BCH soft reset we successfully executed 1,000,000 MX28 reboots.
    
    I have a quote from NXP regarding this problem, from July 18th 2016:
    
    "As the i.MX23 and i.MX28 are of the same generation, they share many
    characteristics. Unfortunately, also the erratas may be shared.
    In case of the documented erratas and the workarounds, you can also
    apply the workaround solution of one device on the other one. This have
    been reported, but I’m afraid that there are not an estimated date for
    updating the Errata documents.
    Please accept our apologies for any inconveniences this may cause."
    
    Fixes: 6f2a6a52560a ("mtd: nand: gpmi: reset BCH earlier, too, to avoid NAND startup problems")
    Cc: stable@vger.kernel.org
    Signed-off-by: Manfred Schlaegl <manfred.schlaegl@ginzinger.com>
    Signed-off-by: Martin Kepplinger <martin.kepplinger@ginzinger.com>
    Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Reviewed-by: Fabio Estevam <festevam@gmail.com>
    Acked-by: Han Xu <han.xu@nxp.com>
    Signed-off-by: Boris Brezillon <bbrezillon@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>