commit a5ad06fc4b7b22f6df0c21b7052a82e039305a14
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Apr 2 17:20:41 2020 +0200

    Linux 4.9.218

commit 6d5fd9db8c42cdc8eeaea90885e88554ab151e55
Author: disconnect3d <dominik.b.czarnota@gmail.com>
Date:   Mon Mar 9 11:48:53 2020 +0100

    perf map: Fix off by one in strncpy() size argument
    
    commit db2c549407d4a76563c579e4768f7d6d32afefba upstream.
    
    This patch fixes an off-by-one error in strncpy size argument in
    tools/perf/util/map.c. The issue is that in:
    
            strncmp(filename, "/system/lib/", 11)
    
    the passed string literal: "/system/lib/" has 12 bytes (without the NULL
    byte) and the passed size argument is 11. As a result, the logic won't
    match the ending "/" byte and will pass filepaths that are stored in
    other directories e.g. "/system/libmalicious/bin" or just
    "/system/libmalicious".
    
    This functionality seems to be present only on Android. I assume the
    /system/ directory is only writable by the root user, so I don't think
    this bug has much (or any) security impact.
    
    Fixes: eca818369996 ("perf tools: Add automatic remapping of Android libraries")
    Signed-off-by: disconnect3d <dominik.b.czarnota@gmail.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Changbin Du <changbin.du@intel.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: John Keeping <john@metanate.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Michael Lentine <mlentine@google.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Song Liu <songliubraving@fb.com>
    Cc: Stephane Eranian <eranian@google.com>
    Link: http://lore.kernel.org/lkml/20200309104855.3775-1-dominik.b.czarnota@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd08eda55929b96917f55df6d6dfcc3450587a78
Author: Ilie Halip <ilie.halip@gmail.com>
Date:   Thu Mar 19 23:45:28 2020 +0200

    arm64: alternative: fix build with clang integrated assembler
    
    commit 6f5459da2b8736720afdbd67c4bd2d1edba7d0e3 upstream.
    
    Building an arm64 defconfig with clang's integrated assembler, this error
    occurs:
        <instantiation>:2:2: error: unrecognized instruction mnemonic
         _ASM_EXTABLE 9999b, 9f
         ^
        arch/arm64/mm/cache.S:50:1: note: while in macro instantiation
        user_alt 9f, "dc cvau, x4", "dc civac, x4", 0
        ^
    
    While GNU as seems fine with case-sensitive macro instantiations, clang
    doesn't, so use the actual macro name (_asm_extable) as in the rest of
    the file.
    
    Also checked that the generated assembly matches the GCC output.
    
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Tested-by: Nick Desaulniers <ndesaulniers@google.com>
    Fixes: 290622efc76e ("arm64: fix "dc cvau" cache operation on errata-affected core")
    Link: https://github.com/ClangBuiltLinux/linux/issues/924
    Signed-off-by: Ilie Halip <ilie.halip@gmail.com>
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b1d5cd9c79c412f8bc845a6d64d12107c200480
Author: Marek Vasut <marex@denx.de>
Date:   Wed Mar 25 15:25:47 2020 +0100

    net: ks8851-ml: Fix IO operations, again
    
    commit 8262e6f9b1034ede34548a04dec4c302d92c9497 upstream.
    
    This patch reverts 58292104832f ("net: ks8851-ml: Fix 16-bit IO operation")
    and edacb098ea9c ("net: ks8851-ml: Fix 16-bit data access"), because it
    turns out these were only necessary due to buggy hardware. This patch adds
    a check for such a buggy hardware to prevent any such mistakes again.
    
    While working further on the KS8851 driver, it came to light that the
    KS8851-16MLL is capable of switching bus endianness by a hardware strap,
    EESK pin. If this strap is incorrect, the IO accesses require such endian
    swapping as is being reverted by this patch. Such swapping also impacts
    the performance significantly.
    
    Hence, in addition to removing it, detect that the hardware is broken,
    report to user, and fail to bind with such hardware.
    
    Fixes: 58292104832f ("net: ks8851-ml: Fix 16-bit IO operation")
    Fixes: edacb098ea9c ("net: ks8851-ml: Fix 16-bit data access")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Lukas Wunner <lukas@wunner.de>
    Cc: Petr Stetiar <ynezz@true.cz>
    Cc: YueHaibing <yuehaibing@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ce7656ea221c87333702134ee55e2a9018803249
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Mar 20 10:48:13 2020 +0100

    bpf: Explicitly memset the bpf_attr structure
    
    commit 8096f229421f7b22433775e928d506f0342e5907 upstream.
    
    For the bpf syscall, we are relying on the compiler to properly zero out
    the bpf_attr union that we copy userspace data into. Unfortunately that
    doesn't always work properly, padding and other oddities might not be
    correctly zeroed, and in some tests odd things have been found when the
    stack is pre-initialized to other values.
    
    Fix this by explicitly memsetting the structure to 0 before using it.
    
    Reported-by: Maciej Żenczykowski <maze@google.com>
    Reported-by: John Stultz <john.stultz@linaro.org>
    Reported-by: Alexander Potapenko <glider@google.com>
    Reported-by: Alistair Delva <adelva@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Yonghong Song <yhs@fb.com>
    Link: https://android-review.googlesource.com/c/kernel/common/+/1235490
    Link: https://lore.kernel.org/bpf/20200320094813.GA421650@kroah.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c47de1c09553fac2e5697573a1b0df843ae4ff8b
Author: Eric Biggers <ebiggers@google.com>
Date:   Sat Mar 21 20:43:05 2020 -0700

    vt: vt_ioctl: fix use-after-free in vt_in_use()
    
    commit 7cf64b18b0b96e751178b8d0505d8466ff5a448f upstream.
    
    vt_in_use() dereferences console_driver->ttys[i] without proper locking.
    This is broken because the tty can be closed and freed concurrently.
    
    We could fix this by using 'READ_ONCE(console_driver->ttys[i]) != NULL'
    and skipping the check of tty_struct::count.  But, looking at
    console_driver->ttys[i] isn't really appropriate anyway because even if
    it is NULL the tty can still be in the process of being closed.
    
    Instead, fix it by making vt_in_use() require console_lock() and check
    whether the vt is allocated and has port refcount > 1.  This works since
    following the patch "vt: vt_ioctl: fix VT_DISALLOCATE freeing in-use
    virtual console" the port refcount is incremented while the vt is open.
    
    Reproducer (very unreliable, but it worked for me after a few minutes):
    
            #include <fcntl.h>
            #include <linux/vt.h>
    
            int main()
            {
                    int fd, nproc;
                    struct vt_stat state;
                    char ttyname[16];
    
                    fd = open("/dev/tty10", O_RDONLY);
                    for (nproc = 1; nproc < 8; nproc *= 2)
                            fork();
                    for (;;) {
                            sprintf(ttyname, "/dev/tty%d", rand() % 8);
                            close(open(ttyname, O_RDONLY));
                            ioctl(fd, VT_GETSTATE, &state);
                    }
            }
    
    KASAN report:
    
            BUG: KASAN: use-after-free in vt_in_use drivers/tty/vt/vt_ioctl.c:48 [inline]
            BUG: KASAN: use-after-free in vt_ioctl+0x1ad3/0x1d70 drivers/tty/vt/vt_ioctl.c:657
            Read of size 4 at addr ffff888065722468 by task syz-vt2/132
    
            CPU: 0 PID: 132 Comm: syz-vt2 Not tainted 5.6.0-rc5-00130-g089b6d3654916 #13
            Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20191223_100556-anatol 04/01/2014
            Call Trace:
             [...]
             vt_in_use drivers/tty/vt/vt_ioctl.c:48 [inline]
             vt_ioctl+0x1ad3/0x1d70 drivers/tty/vt/vt_ioctl.c:657
             tty_ioctl+0x9db/0x11b0 drivers/tty/tty_io.c:2660
             [...]
    
            Allocated by task 136:
             [...]
             kzalloc include/linux/slab.h:669 [inline]
             alloc_tty_struct+0x96/0x8a0 drivers/tty/tty_io.c:2982
             tty_init_dev+0x23/0x350 drivers/tty/tty_io.c:1334
             tty_open_by_driver drivers/tty/tty_io.c:1987 [inline]
             tty_open+0x3ca/0xb30 drivers/tty/tty_io.c:2035
             [...]
    
            Freed by task 41:
             [...]
             kfree+0xbf/0x200 mm/slab.c:3757
             free_tty_struct+0x8d/0xb0 drivers/tty/tty_io.c:177
             release_one_tty+0x22d/0x2f0 drivers/tty/tty_io.c:1468
             process_one_work+0x7f1/0x14b0 kernel/workqueue.c:2264
             worker_thread+0x8b/0xc80 kernel/workqueue.c:2410
             [...]
    
    Fixes: 4001d7b7fc27 ("vt: push down the tty lock so we can see what is left to tackle")
    Cc: <stable@vger.kernel.org> # v3.4+
    Acked-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Link: https://lore.kernel.org/r/20200322034305.210082-3-ebiggers@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea9df3c8cc1cae78d32ad25caa64d83435a564b2
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Mon Nov 14 17:29:48 2016 +0100

    locking/atomic, kref: Add kref_read()
    
    commit 2c935bc57221cc2edc787c72ea0e2d30cdcd3d5e upstream.
    
    Since we need to change the implementation, stop exposing internals.
    
    Provide kref_read() to read the current reference count; typically
    used for debug messages.
    
    Kills two anti-patterns:
    
            atomic_read(&kref->refcount)
            kref->refcount.counter
    
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    [only add kref_read() to kref.h for stable backports - gregkh]
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6bc9bf78618edf42b31cb7551fb0c83af340c54f
Author: Eric Biggers <ebiggers@google.com>
Date:   Sat Mar 21 20:43:04 2020 -0700

    vt: vt_ioctl: fix VT_DISALLOCATE freeing in-use virtual console
    
    commit ca4463bf8438b403596edd0ec961ca0d4fbe0220 upstream.
    
    The VT_DISALLOCATE ioctl can free a virtual console while tty_release()
    is still running, causing a use-after-free in con_shutdown().  This
    occurs because VT_DISALLOCATE considers a virtual console's
    'struct vc_data' to be unused as soon as the corresponding tty's
    refcount hits 0.  But actually it may be still being closed.
    
    Fix this by making vc_data be reference-counted via the embedded
    'struct tty_port'.  A newly allocated virtual console has refcount 1.
    Opening it for the first time increments the refcount to 2.  Closing it
    for the last time decrements the refcount (in tty_operations::cleanup()
    so that it happens late enough), as does VT_DISALLOCATE.
    
    Reproducer:
            #include <fcntl.h>
            #include <linux/vt.h>
            #include <sys/ioctl.h>
            #include <unistd.h>
    
            int main()
            {
                    if (fork()) {
                            for (;;)
                                    close(open("/dev/tty5", O_RDWR));
                    } else {
                            int fd = open("/dev/tty10", O_RDWR);
    
                            for (;;)
                                    ioctl(fd, VT_DISALLOCATE, 5);
                    }
            }
    
    KASAN report:
            BUG: KASAN: use-after-free in con_shutdown+0x76/0x80 drivers/tty/vt/vt.c:3278
            Write of size 8 at addr ffff88806a4ec108 by task syz_vt/129
    
            CPU: 0 PID: 129 Comm: syz_vt Not tainted 5.6.0-rc2 #11
            Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20191223_100556-anatol 04/01/2014
            Call Trace:
             [...]
             con_shutdown+0x76/0x80 drivers/tty/vt/vt.c:3278
             release_tty+0xa8/0x410 drivers/tty/tty_io.c:1514
             tty_release_struct+0x34/0x50 drivers/tty/tty_io.c:1629
             tty_release+0x984/0xed0 drivers/tty/tty_io.c:1789
             [...]
    
            Allocated by task 129:
             [...]
             kzalloc include/linux/slab.h:669 [inline]
             vc_allocate drivers/tty/vt/vt.c:1085 [inline]
             vc_allocate+0x1ac/0x680 drivers/tty/vt/vt.c:1066
             con_install+0x4d/0x3f0 drivers/tty/vt/vt.c:3229
             tty_driver_install_tty drivers/tty/tty_io.c:1228 [inline]
             tty_init_dev+0x94/0x350 drivers/tty/tty_io.c:1341
             tty_open_by_driver drivers/tty/tty_io.c:1987 [inline]
             tty_open+0x3ca/0xb30 drivers/tty/tty_io.c:2035
             [...]
    
            Freed by task 130:
             [...]
             kfree+0xbf/0x1e0 mm/slab.c:3757
             vt_disallocate drivers/tty/vt/vt_ioctl.c:300 [inline]
             vt_ioctl+0x16dc/0x1e30 drivers/tty/vt/vt_ioctl.c:818
             tty_ioctl+0x9db/0x11b0 drivers/tty/tty_io.c:2660
             [...]
    
    Fixes: 4001d7b7fc27 ("vt: push down the tty lock so we can see what is left to tackle")
    Cc: <stable@vger.kernel.org> # v3.4+
    Reported-by: syzbot+522643ab5729b0421998@syzkaller.appspotmail.com
    Acked-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Link: https://lore.kernel.org/r/20200322034305.210082-2-ebiggers@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 35d6480159daf993ba19df3b7f5e925776918fcc
Author: Eric Biggers <ebiggers@google.com>
Date:   Mon Feb 24 00:03:26 2020 -0800

    vt: vt_ioctl: remove unnecessary console allocation checks
    
    commit 1aa6e058dd6cd04471b1f21298270014daf48ac9 upstream.
    
    The vc_cons_allocated() checks in vt_ioctl() and vt_compat_ioctl() are
    unnecessary because they can only be reached by calling ioctl() on an
    open tty, which implies the corresponding virtual console is allocated.
    
    And even if the virtual console *could* be freed concurrently, then
    these checks would be broken since they aren't done under console_lock,
    and the vc_data is dereferenced before them anyway.
    
    So, remove these unneeded checks to avoid confusion.
    
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Link: https://lore.kernel.org/r/20200224080326.295046-1-ebiggers@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e1c84e1109566b3dbff34ad8cbbdbb0d472712c
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Wed Feb 19 08:39:48 2020 +0100

    vt: switch vt_dont_switch to bool
    
    commit f400991bf872debffb01c46da882dc97d7e3248e upstream.
    
    vt_dont_switch is pure boolean, no need for whole char.
    
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Link: https://lore.kernel.org/r/20200219073951.16151-6-jslaby@suse.cz
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8c3bc92d11c51461eadc43ca8ac9912c82cab320
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Wed Feb 19 08:39:44 2020 +0100

    vt: ioctl, switch VT_IS_IN_USE and VT_BUSY to inlines
    
    commit e587e8f17433ddb26954f0edf5b2f95c42155ae9 upstream.
    
    These two were macros. Switch them to static inlines, so that it's more
    understandable what they are doing.
    
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Link: https://lore.kernel.org/r/20200219073951.16151-2-jslaby@suse.cz
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fc3d6dd88e21c84550aa807d4cb1182bd161f383
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Wed Feb 19 08:39:43 2020 +0100

    vt: selection, introduce vc_is_sel
    
    commit dce05aa6eec977f1472abed95ccd71276b9a3864 upstream.
    
    Avoid global variables (namely sel_cons) by introducing vc_is_sel. It
    checks whether the parameter is the current selection console. This will
    help putting sel_cons to a struct later.
    
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Link: https://lore.kernel.org/r/20200219073951.16151-1-jslaby@suse.cz
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2839f7afb8cc9f949070bd5b510d3de37c8084a7
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Sun Mar 29 22:50:06 2020 +0200

    mac80211: fix authentication with iwlwifi/mvm
    
    commit be8c827f50a0bcd56361b31ada11dc0a3c2fd240 upstream.
    
    The original patch didn't copy the ieee80211_is_data() condition
    because on most drivers the management frames don't go through
    this path. However, they do on iwlwifi/mvm, so we do need to keep
    the condition here.
    
    Cc: stable@vger.kernel.org
    Fixes: ce2e1ca70307 ("mac80211: Check port authorization in the ieee80211_tx_dequeue() case")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Woody Suwalski <terraluna977@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 76685e1c142c65f66e9aa776c8f25137e4145c3e
Author: Jouni Malinen <jouni@codeaurora.org>
Date:   Thu Mar 26 15:51:34 2020 +0100

    mac80211: Check port authorization in the ieee80211_tx_dequeue() case
    
    commit ce2e1ca703071723ca2dd94d492a5ab6d15050da upstream.
    
    mac80211 used to check port authorization in the Data frame enqueue case
    when going through start_xmit(). However, that authorization status may
    change while the frame is waiting in a queue. Add a similar check in the
    dequeue case to avoid sending previously accepted frames after
    authorization change. This provides additional protection against
    potential leaking of frames after a station has been disconnected and
    the keys for it are being removed.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
    Link: https://lore.kernel.org/r/20200326155133.ced84317ea29.I34d4c47cd8cc8a4042b38a76f16a601fbcbfd9b3@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8f08a2bb2199a4511bea29e9a130b449f8c1a581
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Jan 3 17:35:11 2020 +0100

    media: xirlink_cit: add missing descriptor sanity checks
    
    commit a246b4d547708f33ff4d4b9a7a5dbac741dc89d8 upstream.
    
    Make sure to check that we have two alternate settings and at least one
    endpoint before accessing the second altsetting structure and
    dereferencing the endpoint arrays.
    
    This specifically avoids dereferencing NULL-pointers or corrupting
    memory when a device does not have the expected descriptors.
    
    Note that the sanity check in cit_get_packet_size() is not redundant as
    the driver is mixing looking up altsettings by index and by number,
    which may not coincide.
    
    Fixes: 659fefa0eb17 ("V4L/DVB: gspca_xirlink_cit: Add support for camera with a bcd version of 0.01")
    Fixes: 59f8b0bf3c12 ("V4L/DVB: gspca_xirlink_cit: support bandwidth changing for devices with 1 alt setting")
    Cc: stable <stable@vger.kernel.org>     # 2.6.37
    Cc: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be6fdd999bcc66cbfde80efbdc16cfd8a3290e38
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Jan 3 17:35:10 2020 +0100

    media: stv06xx: add missing descriptor sanity checks
    
    commit 485b06aadb933190f4bc44e006076bc27a23f205 upstream.
    
    Make sure to check that we have two alternate settings and at least one
    endpoint before accessing the second altsetting structure and
    dereferencing the endpoint arrays.
    
    This specifically avoids dereferencing NULL-pointers or corrupting
    memory when a device does not have the expected descriptors.
    
    Note that the sanity checks in stv06xx_start() and pb0100_start() are
    not redundant as the driver is mixing looking up altsettings by index
    and by number, which may not coincide.
    
    Fixes: 8668d504d72c ("V4L/DVB (12082): gspca_stv06xx: Add support for st6422 bridge and sensor")
    Fixes: c0b33bdc5b8d ("[media] gspca-stv06xx: support bandwidth changing")
    Cc: stable <stable@vger.kernel.org>     # 2.6.31
    Cc: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a1ba8819766af43459c5aaead44dbd3b0a3fc957
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Jan 3 17:35:12 2020 +0100

    media: dib0700: fix rc endpoint lookup
    
    commit f52981019ad8d6718de79b425a574c6bddf81f7c upstream.
    
    Make sure to use the current alternate setting when verifying the
    interface descriptors to avoid submitting an URB to an invalid endpoint.
    
    Failing to do so could cause the driver to misbehave or trigger a WARN()
    in usb_submit_urb() that kernels with panic_on_warn set would choke on.
    
    Fixes: c4018fa2e4c0 ("[media] dib0700: fix RC support on Hauppauge Nova-TD")
    Cc: stable <stable@vger.kernel.org>     # 3.16
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 03e73c3ef017580482d8e4de2db2bac9505facca
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Jan 3 17:35:09 2020 +0100

    media: ov519: add missing endpoint sanity checks
    
    commit 998912346c0da53a6dbb71fab3a138586b596b30 upstream.
    
    Make sure to check that we have at least one endpoint before accessing
    the endpoint array to avoid dereferencing a NULL-pointer on stream
    start.
    
    Note that these sanity checks are not redundant as the driver is mixing
    looking up altsettings by index and by number, which need not coincide.
    
    Fixes: 1876bb923c98 ("V4L/DVB (12079): gspca_ov519: add support for the ov511 bridge")
    Fixes: b282d87332f5 ("V4L/DVB (12080): gspca_ov519: Fix ov518+ with OV7620AE (Trust spacecam 320)")
    Cc: stable <stable@vger.kernel.org>     # 2.6.31
    Cc: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 696119fa9f1822ff93d58b3ca9f8f339b29d058b
Author: Eric Biggers <ebiggers@google.com>
Date:   Sat Mar 7 18:38:49 2020 -0800

    libfs: fix infoleak in simple_attr_read()
    
    commit a65cab7d7f05c2061a3e2490257d3086ff3202c6 upstream.
    
    Reading from a debugfs file at a nonzero position, without first reading
    at position 0, leaks uninitialized memory to userspace.
    
    It's a bit tricky to do this, since lseek() and pread() aren't allowed
    on these files, and write() doesn't update the position on them.  But
    writing to them with splice() *does* update the position:
    
            #define _GNU_SOURCE 1
            #include <fcntl.h>
            #include <stdio.h>
            #include <unistd.h>
            int main()
            {
                    int pipes[2], fd, n, i;
                    char buf[32];
    
                    pipe(pipes);
                    write(pipes[1], "0", 1);
                    fd = open("/sys/kernel/debug/fault_around_bytes", O_RDWR);
                    splice(pipes[0], NULL, fd, NULL, 1, 0);
                    n = read(fd, buf, sizeof(buf));
                    for (i = 0; i < n; i++)
                            printf("%02x", buf[i]);
                    printf("\n");
            }
    
    Output:
            5a5a5a5a5a5a5a5a5a5a5a5a5a5a5a5a5a5a5a5a5a5a5a30
    
    Fix the infoleak by making simple_attr_read() always fill
    simple_attr::get_buf if it hasn't been filled yet.
    
    Reported-by: syzbot+fcab69d1ada3e8d6f06b@syzkaller.appspotmail.com
    Reported-by: Alexander Potapenko <glider@google.com>
    Fixes: acaefc25d21f ("[PATCH] libfs: add simple attribute files")
    Cc: stable@vger.kernel.org
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Acked-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20200308023849.988264-1-ebiggers@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 482aa95582f95770b1226314e06aef0da404f0dc
Author: Qiujun Huang <hqjagain@gmail.com>
Date:   Thu Mar 26 21:18:50 2020 +0800

    staging: wlan-ng: fix use-after-free Read in hfa384x_usbin_callback
    
    commit 1165dd73e811a07d947aee218510571f516081f6 upstream.
    
    We can't handle the case length > WLAN_DATA_MAXLEN.
    Because the size of rxfrm->data is WLAN_DATA_MAXLEN(2312), and we can't
    read more than that.
    
    Thanks-to: Hillf Danton <hdanton@sina.com>
    Reported-and-tested-by: syzbot+7d42d68643a35f71ac8a@syzkaller.appspotmail.com
    Signed-off-by: Qiujun Huang <hqjagain@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200326131850.17711-1-hqjagain@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eae4e4b9709b1295f74f7d6cf1ab6b1f12ca0e17
Author: Qiujun Huang <hqjagain@gmail.com>
Date:   Wed Mar 25 15:06:46 2020 +0800

    staging: wlan-ng: fix ODEBUG bug in prism2sta_disconnect_usb
    
    commit a1f165a6b738f0c9d744bad4af7a53909278f5fc upstream.
    
    We should cancel hw->usb_work before kfree(hw).
    
    Reported-by: syzbot+6d2e7f6fa90e27be9d62@syzkaller.appspotmail.com
    Signed-off-by: Qiujun Huang <hqjagain@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/1585120006-30042-1-git-send-email-hqjagain@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b9ab9fd623c442b994bafde5bf6c573b12fee01
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Sat Mar 21 13:00:11 2020 -0500

    staging: rtl8188eu: Add ASUS USB-N10 Nano B1 to device table
    
    commit 38ef48f7d4b7342f145a1b4f96023bde99aeb245 upstream.
    
    The ASUS USB-N10 Nano B1 has been reported as a new RTL8188EU device.
    Add it to the device tables.
    
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Reported-by: kovi <zraetn@gmail.com>
    Cc: Stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200321180011.26153-1-Larry.Finger@lwfinger.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2236571434af6a54d6824a01d6accb1df4995b65
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Jan 13 18:18:18 2020 +0100

    media: usbtv: fix control-message timeouts
    
    commit 536f561d871c5781bc33d26d415685211b94032e upstream.
    
    The driver was issuing synchronous uninterruptible control requests
    without using a timeout. This could lead to the driver hanging on
    various user requests due to a malfunctioning (or malicious) device
    until the device is physically disconnected.
    
    The USB upper limit of five seconds per request should be more than
    enough.
    
    Fixes: f3d27f34fdd7 ("[media] usbtv: Add driver for Fushicai USBTV007 video frame grabber")
    Fixes: c53a846c48f2 ("[media] usbtv: add video controls")
    Cc: stable <stable@vger.kernel.org>     # 3.11
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Acked-by: Lubomir Rintel <lkundrak@v3.sk>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d36a039d703b71c9836a8c602fd48e915b9c5c10
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Jan 3 17:35:08 2020 +0100

    media: flexcop-usb: fix endpoint sanity check
    
    commit bca243b1ce0e46be26f7c63b5591dfbb41f558e5 upstream.
    
    commit 1b976fc6d684 ("media: b2c2-flexcop-usb: add sanity checking") added
    an endpoint sanity check to address a NULL-pointer dereference on probe.
    Unfortunately the check was done on the current altsetting which was later
    changed.
    
    Fix this by moving the sanity check to after the altsetting is changed.
    
    Fixes: 1b976fc6d684 ("media: b2c2-flexcop-usb: add sanity checking")
    Cc: Oliver Neukum <oneukum@suse.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit edc87d9f7f76f88fe27b007f605f10df838ee413
Author: Mans Rullgard <mans@mansr.com>
Date:   Mon Mar 16 16:11:35 2020 -0500

    usb: musb: fix crash with highmen PIO and usbmon
    
    commit 52974d94a206ce428d9d9b6eaa208238024be82a upstream.
    
    When handling a PIO bulk transfer with highmem buffer, a temporary
    mapping is assigned to urb->transfer_buffer.  After the transfer is
    complete, an invalid address is left behind in this pointer.  This is
    not ordinarily a problem since nothing touches that buffer before the
    urb is released.  However, when usbmon is active, usbmon_urb_complete()
    calls (indirectly) mon_bin_get_data() which does access the transfer
    buffer if it is set.  To prevent an invalid memory access here, reset
    urb->transfer_buffer to NULL when finished (musb_host_rx()), or do not
    set it at all (musb_host_tx()).
    
    Fixes: 8e8a55165469 ("usb: musb: host: Handle highmem in PIO mode")
    Signed-off-by: Mans Rullgard <mans@mansr.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Bin Liu <b-liu@ti.com>
    Link: https://lore.kernel.org/r/20200316211136.2274-8-b-liu@ti.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a2f1111f2728a057d7524575f6d6945f4218cccd
Author: Qiujun Huang <hqjagain@gmail.com>
Date:   Wed Mar 25 15:52:37 2020 +0800

    USB: serial: io_edgeport: fix slab-out-of-bounds read in edge_interrupt_callback
    
    commit 57aa9f294b09463492f604feaa5cc719beaace32 upstream.
    
    Fix slab-out-of-bounds read in the interrupt-URB completion handler.
    
    The boundary condition should be (length - 1) as we access
    data[position + 1].
    
    Reported-and-tested-by: syzbot+37ba33391ad5f3935bbd@syzkaller.appspotmail.com
    Signed-off-by: Qiujun Huang <hqjagain@gmail.com>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4826a0bef66e71ecdf78c9748375932f5c2073cc
Author: Matthias Reichl <hias@horus.com>
Date:   Fri Mar 27 16:03:50 2020 +0100

    USB: cdc-acm: restore capability check order
    
    commit 62d65bdd9d05158aa2547f8ef72375535f3bc6e3 upstream.
    
    commit b401f8c4f492c ("USB: cdc-acm: fix rounding error in TIOCSSERIAL")
    introduced a regression by changing the order of capability and close
    settings change checks. When running with CAP_SYS_ADMIN setting the
    close settings to the values already set resulted in -EOPNOTSUPP.
    
    Fix this by changing the check order back to how it was before.
    
    Fixes: b401f8c4f492c ("USB: cdc-acm: fix rounding error in TIOCSSERIAL")
    Cc: Anthony Mallet <anthony.mallet@laas.fr>
    Cc: stable <stable@vger.kernel.org>
    Cc: Oliver Neukum <oneukum@suse.com>
    Signed-off-by: Matthias Reichl <hias@horus.com>
    Link: https://lore.kernel.org/r/20200327150350.3657-1-hias@horus.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ce6edbf07ac0ee4036638d6bc0ba841c37ef3047
Author: Pawel Dembicki <paweldembicki@gmail.com>
Date:   Wed Mar 25 06:44:19 2020 +0100

    USB: serial: option: add Wistron Neweb D19Q1
    
    commit dfee7e2f478346b12ea651d5c28b069f6a4af563 upstream.
    
    This modem is embedded on dlink dwr-960 router.
    The oem configuration states:
    
    T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0
    D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
    P: Vendor=1435 ProdID=d191 Rev=ff.ff
    S: Manufacturer=Android
    S: Product=Android
    S: SerialNumber=0123456789ABCDEF
    C:* #Ifs= 6 Cfg#= 1 Atr=80 MxPwr=500mA
    I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
    E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
    E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
    E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
    E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
    E: Ad=88(I) Atr=03(Int.) MxPS= 8 Ivl=32ms
    E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
    E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=125us
    
    Tested on openwrt distribution
    
    Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 251acc898910ac685649d5a17fbf435a72630ae6
Author: Pawel Dembicki <paweldembicki@gmail.com>
Date:   Wed Mar 25 06:44:18 2020 +0100

    USB: serial: option: add BroadMobi BM806U
    
    commit 6cb2669cb97fc4fdf526127159ac59caae052247 upstream.
    
    BroadMobi BM806U is an Qualcomm MDM9225 based 3G/4G modem.
    Tested hardware BM806U is mounted on D-Link DWR-921-C3 router.
    
    T:  Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  2 Spd=480  MxCh= 0
    D:  Ver= 2.01 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=2020 ProdID=2033 Rev= 2.28
    S:  Manufacturer=Mobile Connect
    S:  Product=Mobile Connect
    S:  SerialNumber=f842866cfd5a
    C:* #Ifs= 5 Cfg#= 1 Atr=80 MxPwr=500mA
    I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
    E:  Ad=89(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Co-developed-by: Cezary Jackiewicz <cezary@eko.one.pl>
    Signed-off-by: Cezary Jackiewicz <cezary@eko.one.pl>
    Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ae1050f4726c65b930d5070ceca0df822014a3f6
Author: Pawel Dembicki <paweldembicki@gmail.com>
Date:   Wed Mar 25 06:44:17 2020 +0100

    USB: serial: option: add support for ASKEY WWHC050
    
    commit 007d20dca2376a751b1dad03442f118438b7e65e upstream.
    
    ASKEY WWHC050 is a mcie LTE modem.
    The oem configuration states:
    
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480  MxCh= 0
    D:  Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1690 ProdID=7588 Rev=ff.ff
    S:  Manufacturer=Android
    S:  Product=Android
    S:  SerialNumber=813f0eef6e6e
    C:* #Ifs= 6 Cfg#= 1 Atr=80 MxPwr=500mA
    I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=86(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
    E:  Ad=88(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
    E:  Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=125us
    
    Tested on openwrt distribution.
    
    Co-developed-by: Cezary Jackiewicz <cezary@eko.one.pl>
    Signed-off-by: Cezary Jackiewicz <cezary@eko.one.pl>
    Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aae6b58ce74d6b20c6f9f1b88a55da370bed57e1
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Sat Mar 7 03:32:58 2020 +0900

    tools: Let O= makes handle a relative path with -C option
    
    [ Upstream commit be40920fbf1003c38ccdc02b571e01a75d890c82 ]
    
    When I tried to compile tools/perf from the top directory with the -C
    option, the O= option didn't work correctly if I passed a relative path:
    
      $ make O=BUILD -C tools/perf/
      make: Entering directory '/home/mhiramat/ksrc/linux/tools/perf'
        BUILD:   Doing 'make -j8' parallel build
      ../scripts/Makefile.include:4: *** O=/home/mhiramat/ksrc/linux/tools/perf/BUILD does not exist.  Stop.
      make: *** [Makefile:70: all] Error 2
      make: Leaving directory '/home/mhiramat/ksrc/linux/tools/perf'
    
    The O= directory existence check failed because the check script ran in
    the build target directory instead of the directory where I ran the make
    command.
    
    To fix that, once change directory to $(PWD) and check O= directory,
    since the PWD is set to where the make command runs.
    
    Fixes: c883122acc0d ("perf tools: Let O= makes handle relative paths")
    Reported-by: Randy Dunlap <rdunlap@infradead.org>
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Masahiro Yamada <masahiroy@kernel.org>
    Cc: Michal Marek <michal.lkml@markovi.net>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Sasha Levin <sashal@kernel.org>
    Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Cc: stable@vger.kernel.org
    Link: http://lore.kernel.org/lkml/158351957799.3363.15269768530697526765.stgit@devnote2
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fbd5896b898c4ce924a4117511b97fde595139ed
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Mar 6 11:50:51 2020 -0800

    Input: raydium_i2c_ts - fix error codes in raydium_i2c_boot_trigger()
    
    [ Upstream commit 32cf3a610c35cb21e3157f4bbf29d89960e30a36 ]
    
    These functions are supposed to return negative error codes but instead
    it returns true on failure and false on success.  The error codes are
    eventually propagated back to user space.
    
    Fixes: 48a2b783483b ("Input: add Raydium I2C touchscreen driver")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/20200303101306.4potflz7na2nn3od@kili.mountain
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9ff4173c764847b3427dc2f68a0a90c64464893b
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Mon Aug 6 15:20:19 2018 -0700

    Input: raydium_i2c_ts - use true and false for boolean values
    
    [ Upstream commit 6cad4e269e25dddd7260a53e9d9d90ba3a3cc35a ]
    
    Return statements in functions returning bool should use true or false
    instead of an integer value.
    
    This code was detected with the help of Coccinelle.
    
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 758156577e0a60d5849b0751f3d5c21c2662bd49
Author: Torsten Hilbrich <torsten.hilbrich@secunet.com>
Date:   Wed Mar 11 11:19:06 2020 +0100

    vti6: Fix memory leak of skb if input policy check fails
    
    commit 2a9de3af21aa8c31cd68b0b39330d69f8c1e59df upstream.
    
    The vti6_rcv function performs some tests on the retrieved tunnel
    including checking the IP protocol, the XFRM input policy, the
    source and destination address.
    
    In all but one places the skb is released in the error case. When
    the input policy check fails the network packet is leaked.
    
    Using the same goto-label discard in this case to fix this problem.
    
    Fixes: ed1efb2aefbb ("ipv6: Add support for IPsec virtual tunnel interfaces")
    Signed-off-by: Torsten Hilbrich <torsten.hilbrich@secunet.com>
    Reviewed-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 282fd1fb2ff8f2f1b722903d8af844ef346424c1
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Mar 23 14:27:16 2020 +0100

    netfilter: nft_fwd_netdev: validate family and chain type
    
    commit 76a109fac206e158eb3c967af98c178cff738e6a upstream.
    
    Make sure the forward action is only used from ingress.
    
    Fixes: 39e6dea28adc ("netfilter: nf_tables: add forward expression to the netdev family")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 86e98ce7de083649e330d518e98a80b9e39b5d43
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Mon Mar 23 15:32:39 2020 +0800

    xfrm: policy: Fix doulbe free in xfrm_policy_timer
    
    commit 4c59406ed00379c8663f8663d82b2537467ce9d7 upstream.
    
    After xfrm_add_policy add a policy, its ref is 2, then
    
                                 xfrm_policy_timer
                                   read_lock
                                   xp->walk.dead is 0
                                   ....
                                   mod_timer()
    xfrm_policy_kill
      policy->walk.dead = 1
      ....
      del_timer(&policy->timer)
        xfrm_pol_put //ref is 1
      xfrm_pol_put  //ref is 0
        xfrm_policy_destroy
          call_rcu
                                     xfrm_pol_hold //ref is 1
                                   read_unlock
                                   xfrm_pol_put //ref is 0
                                     xfrm_policy_destroy
                                      call_rcu
    
    xfrm_policy_destroy is called twice, which may leads to
    double free.
    
    Call Trace:
    RIP: 0010:refcount_warn_saturate+0x161/0x210
    ...
     xfrm_policy_timer+0x522/0x600
     call_timer_fn+0x1b3/0x5e0
     ? __xfrm_decode_session+0x2990/0x2990
     ? msleep+0xb0/0xb0
     ? _raw_spin_unlock_irq+0x24/0x40
     ? __xfrm_decode_session+0x2990/0x2990
     ? __xfrm_decode_session+0x2990/0x2990
     run_timer_softirq+0x5c5/0x10e0
    
    Fix this by use write_lock_bh in xfrm_policy_kill.
    
    Fixes: ea2dea9dacc2 ("xfrm: remove policy lock when accessing policy->walk.dead")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Acked-by: Timo Teräs <timo.teras@iki.fi>
    Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c2e254ef344cc9cb07cf21ff0a377e632e1e825a
Author: Xin Long <lucien.xin@gmail.com>
Date:   Sun Feb 9 21:16:38 2020 +0800

    xfrm: add the missing verify_sec_ctx_len check in xfrm_add_acquire
    
    commit a1a7e3a36e01ca6e67014f8cf673cb8e47be5550 upstream.
    
    Without doing verify_sec_ctx_len() check in xfrm_add_acquire(), it may be
    out-of-bounds to access uctx->ctx_str with uctx->ctx_len, as noticed by
    syz:
    
      BUG: KASAN: slab-out-of-bounds in selinux_xfrm_alloc_user+0x237/0x430
      Read of size 768 at addr ffff8880123be9b4 by task syz-executor.1/11650
    
      Call Trace:
       dump_stack+0xe8/0x16e
       print_address_description.cold.3+0x9/0x23b
       kasan_report.cold.4+0x64/0x95
       memcpy+0x1f/0x50
       selinux_xfrm_alloc_user+0x237/0x430
       security_xfrm_policy_alloc+0x5c/0xb0
       xfrm_policy_construct+0x2b1/0x650
       xfrm_add_acquire+0x21d/0xa10
       xfrm_user_rcv_msg+0x431/0x6f0
       netlink_rcv_skb+0x15a/0x410
       xfrm_netlink_rcv+0x6d/0x90
       netlink_unicast+0x50e/0x6a0
       netlink_sendmsg+0x8ae/0xd40
       sock_sendmsg+0x133/0x170
       ___sys_sendmsg+0x834/0x9a0
       __sys_sendmsg+0x100/0x1e0
       do_syscall_64+0xe5/0x660
       entry_SYSCALL_64_after_hwframe+0x6a/0xdf
    
    So fix it by adding the missing verify_sec_ctx_len check there.
    
    Fixes: 980ebd25794f ("[IPSEC]: Sync series - acquire insert")
    Reported-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fa40d12e2f5026399996ca8f367b99c3fa468605
Author: Xin Long <lucien.xin@gmail.com>
Date:   Sun Feb 9 21:15:29 2020 +0800

    xfrm: fix uctx len check in verify_sec_ctx_len
    
    commit 171d449a028573b2f0acdc7f31ecbb045391b320 upstream.
    
    It's not sufficient to do 'uctx->len != (sizeof(struct xfrm_user_sec_ctx) +
    uctx->ctx_len)' check only, as uctx->len may be greater than nla_len(rt),
    in which case it will cause slab-out-of-bounds when accessing uctx->ctx_str
    later.
    
    This patch is to fix it by return -EINVAL when uctx->len > nla_len(rt).
    
    Fixes: df71837d5024 ("[LSM-IPSec]: Security association restriction.")
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0807f59465b3c3424eebf2488c8cc7b45161e2a5
Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date:   Tue Feb 4 17:00:27 2020 +0100

    vti[6]: fix packet tx through bpf_redirect() in XinY cases
    
    commit f1ed10264ed6b66b9cd5e8461cffce69be482356 upstream.
    
    I forgot the 4in6/6in4 cases in my previous patch. Let's fix them.
    
    Fixes: 95224166a903 ("vti[6]: fix packet tx through bpf_redirect()")
    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cc24d74e50d21050fa9e8dcee2ef6460dca0d798
Author: Edward Cree <ecree@solarflare.com>
Date:   Fri Mar 13 20:33:07 2020 +0000

    genirq: Fix reference leaks on irq affinity notifiers
    
    commit df81dfcfd6991d547653d46c051bac195cd182c1 upstream.
    
    The handling of notify->work did not properly maintain notify->kref in two
     cases:
    1) where the work was already scheduled, another irq_set_affinity_locked()
       would get the ref and (no-op-ly) schedule the work.  Thus when
       irq_affinity_notify() ran, it would drop the original ref but not the
       additional one.
    2) when cancelling the (old) work in irq_set_affinity_notifier(), if there
       was outstanding work a ref had been got for it but was never put.
    Fix both by checking the return values of the work handling functions
     (schedule_work() for (1) and cancel_work_sync() for (2)) and put the
     extra ref if the return value indicates preexisting work.
    
    Fixes: cd7eab44e994 ("genirq: Add IRQ affinity notifiers")
    Fixes: 59c39840f5ab ("genirq: Prevent use-after-free and work list corruption")
    Signed-off-by: Edward Cree <ecree@solarflare.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Ben Hutchings <ben@decadent.org.uk>
    Link: https://lkml.kernel.org/r/24f5983f-2ab5-e83a-44ee-a45b5f9300f5@solarflare.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e52d8aff25010f4744022fca72d104ae7f074e19
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Mar 26 15:51:35 2020 +0100

    mac80211: mark station unauthorized before key removal
    
    commit b16798f5b907733966fd1a558fca823b3c67e4a1 upstream.
    
    If a station is still marked as authorized, mark it as no longer
    so before removing its keys. This allows frames transmitted to it
    to be rejected, providing additional protection against leaking
    plain text data during the disconnection flow.
    
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20200326155133.ccb4fb0bb356.If48f0f0504efdcf16b8921f48c6d3bb2cb763c99@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 95b526e711aef9df03990f0c7afbbbf30f88a1d9
Author: Martin K. Petersen <martin.petersen@oracle.com>
Date:   Tue Mar 24 11:16:15 2020 -0400

    scsi: sd: Fix optimal I/O size for devices that change reported values
    
    commit ea697a8bf5a4161e59806fab14f6e4a46dc7dcb0 upstream.
    
    Some USB bridge devices will return a default set of characteristics during
    initialization. And then, once an attached drive has spun up, substitute
    the actual parameters reported by the drive. According to the SCSI spec,
    the device should return a UNIT ATTENTION in case any reported parameters
    change. But in this case the change is made silently after a small window
    where default values are reported.
    
    Commit a83da8a4509d ("scsi: sd: Optimal I/O size should be a multiple of
    physical block size") validated the reported optimal I/O size against the
    physical block size to overcome problems with devices reporting nonsensical
    transfer sizes. However, this validation did not account for the fact that
    aforementioned devices will return default values during a brief window
    during spin-up. The subsequent change in reported characteristics would
    invalidate the checking that had previously been performed.
    
    Unset a previously configured optimal I/O size should the sanity checking
    fail on subsequent revalidate attempts.
    
    Link: https://lore.kernel.org/r/33fb522e-4f61-1b76-914f-c9e6a3553c9b@gmail.com
    Cc: Bryan Gurney <bgurney@redhat.com>
    Cc: <stable@vger.kernel.org>
    Reported-by: Bernhard Sulzer <micraft.b@gmail.com>
    Tested-by: Bernhard Sulzer <micraft.b@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8e8ab8554aa4988db5e1028fbd02c51af676a7f2
Author: Dirk Mueller <dmueller@suse.com>
Date:   Tue Jan 14 18:53:41 2020 +0100

    scripts/dtc: Remove redundant YYLOC global declaration
    
    commit e33a814e772cdc36436c8c188d8c42d019fda639 upstream.
    
    gcc 10 will default to -fno-common, which causes this error at link
    time:
    
      (.text+0x0): multiple definition of `yylloc'; dtc-lexer.lex.o (symbol from plugin):(.text+0x0): first defined here
    
    This is because both dtc-lexer as well as dtc-parser define the same
    global symbol yyloc. Before with -fcommon those were merged into one
    defintion. The proper solution would be to to mark this as "extern",
    however that leads to:
    
      dtc-lexer.l:26:16: error: redundant redeclaration of 'yylloc' [-Werror=redundant-decls]
       26 | extern YYLTYPE yylloc;
          |                ^~~~~~
    In file included from dtc-lexer.l:24:
    dtc-parser.tab.h:127:16: note: previous declaration of 'yylloc' was here
      127 | extern YYLTYPE yylloc;
          |                ^~~~~~
    cc1: all warnings being treated as errors
    
    which means the declaration is completely redundant and can just be
    dropped.
    
    Signed-off-by: Dirk Mueller <dmueller@suse.com>
    Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
    [robh: cherry-pick from upstream]
    Cc: stable@vger.kernel.org
    Signed-off-by: Rob Herring <robh@kernel.org>
    [nc: Also apply to dtc-lexer.lex.c_shipped due to a lack of
         e039139be8c2, where dtc-lexer.l started being used]
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 791b3ea23b9a3e33c53e2431c617d0348bcfda99
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Fri Feb 28 00:42:01 2020 +0900

    perf probe: Do not depend on dwfl_module_addrsym()
    
    commit 1efde2754275dbd9d11c6e0132a4f09facf297ab upstream.
    
    Do not depend on dwfl_module_addrsym() because it can fail on user-space
    shared libraries.
    
    Actually, same bug was fixed by commit 664fee3dc379 ("perf probe: Do not
    use dwfl_module_addrsym if dwarf_diename finds symbol name"), but commit
    07d369857808 ("perf probe: Fix wrong address verification) reverted to
    get actual symbol address from symtab.
    
    This fixes it again by getting symbol address from DIE, and only if the
    DIE has only address range, it uses dwfl_module_addrsym().
    
    Fixes: 07d369857808 ("perf probe: Fix wrong address verification)
    Reported-by: Alexandre Ghiti <alex@ghiti.fr>
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Tested-by: Alexandre Ghiti <alex@ghiti.fr>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Sasha Levin <sashal@kernel.org>
    Link: http://lore.kernel.org/lkml/158281812176.476.14164573830975116234.stgit@devnote2
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ff9fb22ad1077b451fc830963e48d5ac27edf14
Author: Roger Quadros <rogerq@ti.com>
Date:   Mon Mar 16 12:27:31 2020 +0200

    ARM: dts: omap5: Add bus_dma_limit for L3 bus
    
    commit dfa7ea303f56a3a8b1ed3b91ef35af2da67ca4ee upstream.
    
    The L3 interconnect's memory map is from 0x0 to
    0xffffffff. Out of this, System memory (SDRAM) can be
    accessed from 0x80000000 to 0xffffffff (2GB)
    
    OMAP5 does support 4GB of SDRAM but upper 2GB can only be
    accessed by the MPU subsystem.
    
    Add the dma-ranges property to reflect the physical address limit
    of the L3 bus.
    
    Cc: stable@kernel.org
    Signed-off-by: Roger Quadros <rogerq@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 35e50a4f92a62476f27b6e809f1391e8a398c9b0
Author: Roger Quadros <rogerq@ti.com>
Date:   Fri Mar 13 11:47:17 2020 +0200

    ARM: dts: dra7: Add bus_dma_limit for L3 bus
    
    commit cfb5d65f25959f724081bae8445a0241db606af6 upstream.
    
    The L3 interconnect's memory map is from 0x0 to
    0xffffffff. Out of this, System memory (SDRAM) can be
    accessed from 0x80000000 to 0xffffffff (2GB)
    
    DRA7 does support 4GB of SDRAM but upper 2GB can only be
    accessed by the MPU subsystem.
    
    Add the dma-ranges property to reflect the physical address limit
    of the L3 bus.
    
    Issues ere observed only with SATA on DRA7-EVM with 4GB RAM
    and CONFIG_ARM_LPAE enabled. This is because the controller
    supports 64-bit DMA and its driver sets the dma_mask to 64-bit
    thus resulting in DMA accesses beyond L3 limit of 2G.
    
    Setting the correct bus_dma_limit fixes the issue.
    
    Signed-off-by: Roger Quadros <rogerq@ti.com>
    Cc: stable@kernel.org
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 01d5bf949e49a8fd38c186e7725bb9f54c0b3e15
Author: Chuhong Yuan <hslester96@gmail.com>
Date:   Mon Nov 4 23:00:48 2019 +0800

    i2c: hix5hd2: add missed clk_disable_unprepare in remove
    
    commit e1b9f99ff8c40bba6e59de9ad4a659447b1e4112 upstream.
    
    The driver forgets to disable and unprepare clk when remove.
    Add a call to clk_disable_unprepare to fix it.
    
    Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f5432ef98d71f18d714251efc9885891989c0e6
Author: Dominik Czarnota <dominik.b.czarnota@gmail.com>
Date:   Mon Mar 9 16:22:50 2020 +0100

    sxgbe: Fix off by one in samsung driver strncpy size arg
    
    [ Upstream commit f3cc008bf6d59b8d93b4190e01d3e557b0040e15 ]
    
    This patch fixes an off-by-one error in strncpy size argument in
    drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c. The issue is that in:
    
            strncmp(opt, "eee_timer:", 6)
    
    the passed string literal: "eee_timer:" has 10 bytes (without the NULL
    byte) and the passed size argument is 6. As a result, the logic will
    also accept other, malformed strings, e.g. "eee_tiXXX:".
    
    This bug doesn't seem to have any security impact since its present in
    module's cmdline parsing code.
    
    Signed-off-by: Dominik Czarnota <dominik.b.czarnota@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a8351c8a9eb24c664290098fc97df6573c1a6468
Author: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Date:   Thu Mar 5 15:04:09 2020 +0100

    mac80211: Do not send mesh HWMP PREQ if HWMP is disabled
    
    [ Upstream commit ba32679cac50c38fdf488296f96b1f3175532b8e ]
    
    When trying to transmit to an unknown destination, the mesh code would
    unconditionally transmit a HWMP PREQ even if HWMP is not the current
    path selection algorithm.
    
    Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
    Link: https://lore.kernel.org/r/20200305140409.12204-1-cavallar@lri.fr
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9509c9134b4becfce017c6ad0f03633cfa31dcb1
Author: Wen Xiong <wenxiong@linux.vnet.ibm.com>
Date:   Fri Mar 6 09:57:28 2020 -0600

    scsi: ipr: Fix softlockup when rescanning devices in petitboot
    
    [ Upstream commit 394b61711f3ce33f75bf70a3e22938464a13b3ee ]
    
    When trying to rescan disks in petitboot shell, we hit the following
    softlockup stacktrace:
    
    Kernel panic - not syncing: System is deadlocked on memory
    [  241.223394] CPU: 32 PID: 693 Comm: sh Not tainted 5.4.16-openpower1 #1
    [  241.223406] Call Trace:
    [  241.223415] [c0000003f07c3180] [c000000000493fc4] dump_stack+0xa4/0xd8 (unreliable)
    [  241.223432] [c0000003f07c31c0] [c00000000007d4ac] panic+0x148/0x3cc
    [  241.223446] [c0000003f07c3260] [c000000000114b10] out_of_memory+0x468/0x4c4
    [  241.223461] [c0000003f07c3300] [c0000000001472b0] __alloc_pages_slowpath+0x594/0x6d8
    [  241.223476] [c0000003f07c3420] [c00000000014757c] __alloc_pages_nodemask+0x188/0x1a4
    [  241.223492] [c0000003f07c34a0] [c000000000153e10] alloc_pages_current+0xcc/0xd8
    [  241.223508] [c0000003f07c34e0] [c0000000001577ac] alloc_slab_page+0x30/0x98
    [  241.223524] [c0000003f07c3520] [c0000000001597fc] new_slab+0x138/0x40c
    [  241.223538] [c0000003f07c35f0] [c00000000015b204] ___slab_alloc+0x1e4/0x404
    [  241.223552] [c0000003f07c36c0] [c00000000015b450] __slab_alloc+0x2c/0x48
    [  241.223566] [c0000003f07c36f0] [c00000000015b754] kmem_cache_alloc_node+0x9c/0x1b4
    [  241.223582] [c0000003f07c3760] [c000000000218c48] blk_alloc_queue_node+0x34/0x270
    [  241.223599] [c0000003f07c37b0] [c000000000226574] blk_mq_init_queue+0x2c/0x78
    [  241.223615] [c0000003f07c37e0] [c0000000002ff710] scsi_mq_alloc_queue+0x28/0x70
    [  241.223631] [c0000003f07c3810] [c0000000003005b8] scsi_alloc_sdev+0x184/0x264
    [  241.223647] [c0000003f07c38a0] [c000000000300ba0] scsi_probe_and_add_lun+0x288/0xa3c
    [  241.223663] [c0000003f07c3a00] [c000000000301768] __scsi_scan_target+0xcc/0x478
    [  241.223679] [c0000003f07c3b20] [c000000000301c64] scsi_scan_channel.part.9+0x74/0x7c
    [  241.223696] [c0000003f07c3b70] [c000000000301df4] scsi_scan_host_selected+0xe0/0x158
    [  241.223712] [c0000003f07c3bd0] [c000000000303f04] store_scan+0x104/0x114
    [  241.223727] [c0000003f07c3cb0] [c0000000002d5ac4] dev_attr_store+0x30/0x4c
    [  241.223741] [c0000003f07c3cd0] [c0000000001dbc34] sysfs_kf_write+0x64/0x78
    [  241.223756] [c0000003f07c3cf0] [c0000000001da858] kernfs_fop_write+0x170/0x1b8
    [  241.223773] [c0000003f07c3d40] [c0000000001621fc] __vfs_write+0x34/0x60
    [  241.223787] [c0000003f07c3d60] [c000000000163c2c] vfs_write+0xa8/0xcc
    [  241.223802] [c0000003f07c3db0] [c000000000163df4] ksys_write+0x70/0xbc
    [  241.223816] [c0000003f07c3e20] [c00000000000b40c] system_call+0x5c/0x68
    
    As a part of the scan process Linux will allocate and configure a
    scsi_device for each target to be scanned. If the device is not present,
    then the scsi_device is torn down. As a part of scsi_device teardown a
    workqueue item will be scheduled and the lockups we see are because there
    are 250k workqueue items to be processed.  Accoding to the specification of
    SIS-64 sas controller, max_channel should be decreased on SIS-64 adapters
    to 4.
    
    The patch fixes softlockup issue.
    
    Thanks for Oliver Halloran's help with debugging and explanation!
    
    Link: https://lore.kernel.org/r/1583510248-23672-1-git-send-email-wenxiong@linux.vnet.ibm.com
    Signed-off-by: Wen Xiong <wenxiong@linux.vnet.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4fe8dc061a0cbdd10ba19fc889fe42a0fa9429b9
Author: Madalin Bucur <madalin.bucur@nxp.com>
Date:   Wed Mar 4 18:04:25 2020 +0200

    dt-bindings: net: FMan erratum A050385
    
    [ Upstream commit 26d5bb9e4c4b541c475751e015072eb2cbf70d15 ]
    
    FMAN DMA read or writes under heavy traffic load may cause FMAN
    internal resource leak; thus stopping further packet processing.
    
    The FMAN internal queue can overflow when FMAN splits single
    read or write transactions into multiple smaller transactions
    such that more than 17 AXI transactions are in flight from FMAN
    to interconnect. When the FMAN internal queue overflows, it can
    stall further packet processing. The issue can occur with any one
    of the following three conditions:
    
      1. FMAN AXI transaction crosses 4K address boundary (Errata
         A010022)
      2. FMAN DMA address for an AXI transaction is not 16 byte
         aligned, i.e. the last 4 bits of an address are non-zero
      3. Scatter Gather (SG) frames have more than one SG buffer in
         the SG list and any one of the buffers, except the last
         buffer in the SG list has data size that is not a multiple
         of 16 bytes, i.e., other than 16, 32, 48, 64, etc.
    
    With any one of the above three conditions present, there is
    likelihood of stalled FMAN packet processing, especially under
    stress with multiple ports injecting line-rate traffic.
    
    To avoid situations that stall FMAN packet processing, all of the
    above three conditions must be avoided; therefore, configure the
    system with the following rules:
    
      1. Frame buffers must not span a 4KB address boundary, unless
         the frame start address is 256 byte aligned
      2. All FMAN DMA start addresses (for example, BMAN buffer
         address, FD[address] + FD[offset]) are 16B aligned
      3. SG table and buffer addresses are 16B aligned and the size
         of SG buffers are multiple of 16 bytes, except for the last
         SG buffer that can be of any size.
    
    Additional workaround notes:
    - Address alignment of 64 bytes is recommended for maximally
    efficient system bus transactions (although 16 byte alignment is
    sufficient to avoid the stall condition)
    - To support frame sizes that are larger than 4K bytes, there are
    two options:
      1. Large single buffer frames that span a 4KB page boundary can
         be converted into SG frames to avoid transaction splits at
         the 4KB boundary,
      2. Align the large single buffer to 256B address boundaries,
         ensure that the frame address plus offset is 256B aligned.
    - If software generated SG frames have buffers that are unaligned
    and with random non-multiple of 16 byte lengths, before
    transmitting such frames via FMAN, frames will need to be copied
    into a new single buffer or multiple buffer SG frame that is
    compliant with the three rules listed above.
    
    Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 85e8b90e4e8a815279317be7244971055e5775c7
Author: Mike Gilbert <floppym@gentoo.org>
Date:   Wed Feb 26 14:33:59 2020 -0500

    cpupower: avoid multiple definition with gcc -fno-common
    
    [ Upstream commit 2de7fb60a4740135e03cf55c1982e393ccb87b6b ]
    
    Building cpupower with -fno-common in CFLAGS results in errors due to
    multiple definitions of the 'cpu_count' and 'start_time' variables.
    
    ./utils/idle_monitor/snb_idle.o:./utils/idle_monitor/cpupower-monitor.h:28:
    multiple definition of `cpu_count';
    ./utils/idle_monitor/nhm_idle.o:./utils/idle_monitor/cpupower-monitor.h:28:
    first defined here
    ...
    ./utils/idle_monitor/cpuidle_sysfs.o:./utils/idle_monitor/cpuidle_sysfs.c:22:
    multiple definition of `start_time';
    ./utils/idle_monitor/amd_fam14h_idle.o:./utils/idle_monitor/amd_fam14h_idle.c:85:
    first defined here
    
    The -fno-common option will be enabled by default in GCC 10.
    
    Bug: https://bugs.gentoo.org/707462
    Signed-off-by: Mike Gilbert <floppym@gentoo.org>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 14c137ce30cd40caff4fb7efe0a651590b64d695
Author: Sabrina Dubroca <sd@queasysnail.net>
Date:   Tue Oct 9 17:48:15 2018 +0200

    net: ipv4: don't let PMTU updates increase route MTU
    
    [ Upstream commit 28d35bcdd3925e7293408cdb8aa5f2aac5f0d6e3 ]
    
    When an MTU update with PMTU smaller than net.ipv4.route.min_pmtu is
    received, we must clamp its value. However, we can receive a PMTU
    exception with PMTU < old_mtu < ip_rt_min_pmtu, which would lead to an
    increase in PMTU.
    
    To fix this, take the smallest of the old MTU and ip_rt_min_pmtu.
    
    Before this patch, in case of an update, the exception's MTU would
    always change. Now, an exception can have only its lock flag updated,
    but not the MTU, so we need to add a check on locking to the following
    "is this exception getting updated, or close to expiring?" test.
    
    Fixes: d52e5a7e7ca4 ("ipv4: lock mtu in fnhe when received PMTU < net.ipv4.route.min_pmtu")
    Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
    Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6be2735f9e50f140206f0c69a4188ce194a49fec
Author: Sean Christopherson <sean.j.christopherson@intel.com>
Date:   Thu Aug 23 13:56:46 2018 -0700

    KVM: VMX: Do not allow reexecute_instruction() when skipping MMIO instr
    
    [ Upstream commit c4409905cd6eb42cfd06126e9226b0150e05a715 ]
    
    Re-execution after an emulation decode failure is only intended to
    handle a case where two or vCPUs race to write a shadowed page, i.e.
    we should never re-execute an instruction as part of MMIO emulation.
    As handle_ept_misconfig() is only used for MMIO emulation, it should
    pass EMULTYPE_NO_REEXECUTE when using the emulator to skip an instr
    in the fast-MMIO case where VM_EXIT_INSTRUCTION_LEN is invalid.
    
    And because the cr2 value passed to x86_emulate_instruction() is only
    destined for use when retrying or reexecuting, we can simply call
    emulate_instruction().
    
    Fixes: d391f1207067 ("x86/kvm/vmx: do not use vm-exit instruction length
                          for fast MMIO when running nested")
    Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
    Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 03e7234b3e95a5e0851de2b890d291c4634a7e4b
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Fri Mar 13 06:50:33 2020 +0000

    hsr: set .netnsok flag
    
    [ Upstream commit 09e91dbea0aa32be02d8877bd50490813de56b9a ]
    
    The hsr module has been supporting the list and status command.
    (HSR_C_GET_NODE_LIST and HSR_C_GET_NODE_STATUS)
    These commands send node information to the user-space via generic netlink.
    But, in the non-init_net namespace, these commands are not allowed
    because .netnsok flag is false.
    So, there is no way to get node information in the non-init_net namespace.
    
    Fixes: f421436a591d ("net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c669c9376d7e5e24d3067fcc5352a45864acb112
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Fri Mar 13 06:50:24 2020 +0000

    hsr: add restart routine into hsr_get_node_list()
    
    [ Upstream commit ca19c70f5225771c05bcdcb832b4eb84d7271c5e ]
    
    The hsr_get_node_list() is to send node addresses to the userspace.
    If there are so many nodes, it could fail because of buffer size.
    In order to avoid this failure, the restart routine is added.
    
    Fixes: f421436a591d ("net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9bc97bc67f01b2b729aae0efb070fb0edd38c2dc
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Fri Mar 13 06:50:14 2020 +0000

    hsr: use rcu_read_lock() in hsr_get_node_{list/status}()
    
    [ Upstream commit 173756b86803655d70af7732079b3aa935e6ab68 ]
    
    hsr_get_node_{list/status}() are not under rtnl_lock() because
    they are callback functions of generic netlink.
    But they use __dev_get_by_index() without rtnl_lock().
    So, it would use unsafe data.
    In order to fix it, rcu_read_lock() and dev_get_by_index_rcu()
    are used instead of __dev_get_by_index().
    
    Fixes: f421436a591d ("net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dabbf0e824fac8e98ca942e0962c7764924edeaa
Author: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Date:   Mon Mar 16 22:56:36 2020 +0800

    net: mvneta: Fix the case where the last poll did not process all rx
    
    [ Upstream commit 065fd83e1be2e1ba0d446a257fd86a3cc7bddb51 ]
    
    For the case where the last mvneta_poll did not process all
    RX packets, we need to xor the pp->cause_rx_tx or port->cause_rx_tx
    before claculating the rx_queue.
    
    Fixes: 2dcf75e2793c ("net: mvneta: Associate RX queues with each CPU")
    Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cc42f986e5de1c6cfde505648a47f436ff7010a2
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Wed Mar 18 13:28:09 2020 +0000

    vxlan: check return value of gro_cells_init()
    
    [ Upstream commit 384d91c267e621e0926062cfb3f20cb72dc16928 ]
    
    gro_cells_init() returns error if memory allocation is failed.
    But the vxlan module doesn't check the return value of gro_cells_init().
    
    Fixes: 58ce31cca1ff ("vxlan: GRO support at tunnel layer")`
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a1c9b23142ac8d6577613f6e41297ae24e7d313c
Author: Oliver Hartkopp <socketcan@hartkopp.net>
Date:   Sat Mar 21 14:08:29 2020 +0100

    slcan: not call free_netdev before rtnl_unlock in slcan_open
    
    [ Upstream commit 2091a3d42b4f339eaeed11228e0cbe9d4f92f558 ]
    
    As the description before netdev_run_todo, we cannot call free_netdev
    before rtnl_unlock, fix it by reorder the code.
    
    This patch is a 1:1 copy of upstream slip.c commit f596c87005f7
    ("slip: not call free_netdev before rtnl_unlock in slip_open").
    
    Reported-by: yangerkun <yangerkun@huawei.com>
    Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 93b84b9cc4324a9c863ce9f7ee411ff933161a6b
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Mar 20 16:21:17 2020 +0300

    NFC: fdp: Fix a signedness bug in fdp_nci_send_patch()
    
    [ Upstream commit 0dcdf9f64028ec3b75db6b691560f8286f3898bf ]
    
    The nci_conn_max_data_pkt_payload_size() function sometimes returns
    -EPROTO so "max_size" needs to be signed for the error handling to
    work.  We can make "payload_size" an int as well.
    
    Fixes: a06347c04c13 ("NFC: Add Intel Fields Peak NFC solution driver")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c4453d2833671e3a9f6bd52f0f581056c3736386
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date:   Wed Mar 11 22:42:28 2020 -0700

    net_sched: keep alloc_hash updated after hash allocation
    
    [ Upstream commit 0d1c3530e1bd38382edef72591b78e877e0edcd3 ]
    
    In commit 599be01ee567 ("net_sched: fix an OOB access in cls_tcindex")
    I moved cp->hash calculation before the first
    tcindex_alloc_perfect_hash(), but cp->alloc_hash is left untouched.
    This difference could lead to another out of bound access.
    
    cp->alloc_hash should always be the size allocated, we should
    update it after this tcindex_alloc_perfect_hash().
    
    Reported-and-tested-by: syzbot+dcc34d54d68ef7d2d53d@syzkaller.appspotmail.com
    Reported-and-tested-by: syzbot+c72da7b9ed57cde6fca2@syzkaller.appspotmail.com
    Fixes: 599be01ee567 ("net_sched: fix an OOB access in cls_tcindex")
    Cc: Jamal Hadi Salim <jhs@mojatatu.com>
    Cc: Jiri Pirko <jiri@resnulli.us>
    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 97a8e7afaee8fc4f08662cf8e4f495b87874aa91
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date:   Fri Mar 13 22:29:54 2020 -0700

    net_sched: cls_route: remove the right filter from hashtable
    
    [ Upstream commit ef299cc3fa1a9e1288665a9fdc8bff55629fd359 ]
    
    route4_change() allocates a new filter and copies values from
    the old one. After the new filter is inserted into the hash
    table, the old filter should be removed and freed, as the final
    step of the update.
    
    However, the current code mistakenly removes the new one. This
    looks apparently wrong to me, and it causes double "free" and
    use-after-free too, as reported by syzbot.
    
    Reported-and-tested-by: syzbot+f9b32aaacd60305d9687@syzkaller.appspotmail.com
    Reported-and-tested-by: syzbot+2f8c233f131943d6056d@syzkaller.appspotmail.com
    Reported-and-tested-by: syzbot+9c2df9fd5e9445b74e01@syzkaller.appspotmail.com
    Fixes: 1109c00547fc ("net: sched: RCU cls_route")
    Cc: Jamal Hadi Salim <jhs@mojatatu.com>
    Cc: Jiri Pirko <jiri@resnulli.us>
    Cc: John Fastabend <john.fastabend@gmail.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 5e845dc62f383b656c0da16d65e4d4d0b1024d34
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Sun Mar 22 13:58:50 2020 -0700

    net: dsa: Fix duplicate frames flooded by learning
    
    [ Upstream commit 0e62f543bed03a64495bd2651d4fe1aa4bcb7fe5 ]
    
    When both the switch and the bridge are learning about new addresses,
    switch ports attached to the bridge would see duplicate ARP frames
    because both entities would attempt to send them.
    
    Fixes: 5037d532b83d ("net: dsa: add Broadcom tag RX/TX handler")
    Reported-by: Maxime Bizon <mbizon@freebox.fr>
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 52d58912962eaf8d184ab785b7e4245f9223c2b6
Author: Willem de Bruijn <willemb@google.com>
Date:   Sun Mar 22 13:51:13 2020 -0400

    macsec: restrict to ethernet devices
    
    [ Upstream commit b06d072ccc4b1acd0147b17914b7ad1caa1818bb ]
    
    Only attach macsec to ethernet devices.
    
    Syzbot was able to trigger a KMSAN warning in macsec_handle_frame
    by attaching to a phonet device.
    
    Macvlan has a similar check in macvlan_port_create.
    
    v1->v2
      - fix commit message typo
    
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a6362a9f2039dc47efe1f14b05be7645a1332099
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Sat Mar 21 06:46:50 2020 +0000

    hsr: fix general protection fault in hsr_addr_is_self()
    
    [ Upstream commit 3a303cfdd28d5f930a307c82e8a9d996394d5ebd ]
    
    The port->hsr is used in the hsr_handle_frame(), which is a
    callback of rx_handler.
    hsr master and slaves are initialized in hsr_add_port().
    This function initializes several pointers, which includes port->hsr after
    registering rx_handler.
    So, in the rx_handler routine, un-initialized pointer would be used.
    In order to fix this, pointers should be initialized before
    registering rx_handler.
    
    Test commands:
        ip netns del left
        ip netns del right
        modprobe -rv veth
        modprobe -rv hsr
        killall ping
        modprobe hsr
        ip netns add left
        ip netns add right
        ip link add veth0 type veth peer name veth1
        ip link add veth2 type veth peer name veth3
        ip link add veth4 type veth peer name veth5
        ip link set veth1 netns left
        ip link set veth3 netns right
        ip link set veth4 netns left
        ip link set veth5 netns right
        ip link set veth0 up
        ip link set veth2 up
        ip link set veth0 address fc:00:00:00:00:01
        ip link set veth2 address fc:00:00:00:00:02
        ip netns exec left ip link set veth1 up
        ip netns exec left ip link set veth4 up
        ip netns exec right ip link set veth3 up
        ip netns exec right ip link set veth5 up
        ip link add hsr0 type hsr slave1 veth0 slave2 veth2
        ip a a 192.168.100.1/24 dev hsr0
        ip link set hsr0 up
        ip netns exec left ip link add hsr1 type hsr slave1 veth1 slave2 veth4
        ip netns exec left ip a a 192.168.100.2/24 dev hsr1
        ip netns exec left ip link set hsr1 up
        ip netns exec left ip n a 192.168.100.1 dev hsr1 lladdr \
                fc:00:00:00:00:01 nud permanent
        ip netns exec left ip n r 192.168.100.1 dev hsr1 lladdr \
                fc:00:00:00:00:01 nud permanent
        for i in {1..100}
        do
            ip netns exec left ping 192.168.100.1 &
        done
        ip netns exec left hping3 192.168.100.1 -2 --flood &
        ip netns exec right ip link add hsr2 type hsr slave1 veth3 slave2 veth5
        ip netns exec right ip a a 192.168.100.3/24 dev hsr2
        ip netns exec right ip link set hsr2 up
        ip netns exec right ip n a 192.168.100.1 dev hsr2 lladdr \
                fc:00:00:00:00:02 nud permanent
        ip netns exec right ip n r 192.168.100.1 dev hsr2 lladdr \
                fc:00:00:00:00:02 nud permanent
        for i in {1..100}
        do
            ip netns exec right ping 192.168.100.1 &
        done
        ip netns exec right hping3 192.168.100.1 -2 --flood &
        while :
        do
            ip link add hsr0 type hsr slave1 veth0 slave2 veth2
            ip a a 192.168.100.1/24 dev hsr0
            ip link set hsr0 up
            ip link del hsr0
        done
    
    Splat looks like:
    [  120.954938][    C0] general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1]I
    [  120.957761][    C0] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
    [  120.959064][    C0] CPU: 0 PID: 1511 Comm: hping3 Not tainted 5.6.0-rc5+ #460
    [  120.960054][    C0] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
    [  120.962261][    C0] RIP: 0010:hsr_addr_is_self+0x65/0x2a0 [hsr]
    [  120.963149][    C0] Code: 44 24 18 70 73 2f c0 48 c1 eb 03 48 8d 04 13 c7 00 f1 f1 f1 f1 c7 40 04 00 f2 f2 f2 4
    [  120.966277][    C0] RSP: 0018:ffff8880d9c09af0 EFLAGS: 00010206
    [  120.967293][    C0] RAX: 0000000000000006 RBX: 1ffff1101b38135f RCX: 0000000000000000
    [  120.968516][    C0] RDX: dffffc0000000000 RSI: ffff8880d17cb208 RDI: 0000000000000000
    [  120.969718][    C0] RBP: 0000000000000030 R08: ffffed101b3c0e3c R09: 0000000000000001
    [  120.972203][    C0] R10: 0000000000000001 R11: ffffed101b3c0e3b R12: 0000000000000000
    [  120.973379][    C0] R13: ffff8880aaf80100 R14: ffff8880aaf800f2 R15: ffff8880aaf80040
    [  120.974410][    C0] FS:  00007f58e693f740(0000) GS:ffff8880d9c00000(0000) knlGS:0000000000000000
    [  120.979794][    C0] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  120.980773][    C0] CR2: 00007ffcb8b38f29 CR3: 00000000afe8e001 CR4: 00000000000606f0
    [  120.981945][    C0] Call Trace:
    [  120.982411][    C0]  <IRQ>
    [  120.982848][    C0]  ? hsr_add_node+0x8c0/0x8c0 [hsr]
    [  120.983522][    C0]  ? rcu_read_lock_held+0x90/0xa0
    [  120.984159][    C0]  ? rcu_read_lock_sched_held+0xc0/0xc0
    [  120.984944][    C0]  hsr_handle_frame+0x1db/0x4e0 [hsr]
    [  120.985597][    C0]  ? hsr_nl_nodedown+0x2b0/0x2b0 [hsr]
    [  120.986289][    C0]  __netif_receive_skb_core+0x6bf/0x3170
    [  120.992513][    C0]  ? check_chain_key+0x236/0x5d0
    [  120.993223][    C0]  ? do_xdp_generic+0x1460/0x1460
    [  120.993875][    C0]  ? register_lock_class+0x14d0/0x14d0
    [  120.994609][    C0]  ? __netif_receive_skb_one_core+0x8d/0x160
    [  120.995377][    C0]  __netif_receive_skb_one_core+0x8d/0x160
    [  120.996204][    C0]  ? __netif_receive_skb_core+0x3170/0x3170
    [ ... ]
    
    Reported-by: syzbot+fcf5dd39282ceb27108d@syzkaller.appspotmail.com
    Fixes: c5a759117210 ("net/hsr: Use list_head (and rcu) instead of array for slave devices.")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 594b060252bbc6965c9dbb7c7db636c58815a3ab
Author: Lyude Paul <lyude@redhat.com>
Date:   Wed Nov 28 16:00:05 2018 -0500

    Revert "drm/dp_mst: Skip validating ports during destruction, just ref"
    
    commit 9765635b30756eb74e05e260ac812659c296cd28 upstream.
    
    This reverts commit:
    
    c54c7374ff44 ("drm/dp_mst: Skip validating ports during destruction, just ref")
    
    ugh.
    
    In drm_dp_destroy_connector_work(), we have a pretty good chance of
    freeing the actual struct drm_dp_mst_port. However, after destroying
    things we send a hotplug through (*mgr->cbs->hotplug)(mgr) which is
    where the problems start.
    
    For i915, this calls all the way down to the fbcon probing helpers,
    which start trying to access the port in a modeset.
    
    [   45.062001] ==================================================================
    [   45.062112] BUG: KASAN: use-after-free in ex_handler_refcount+0x146/0x180
    [   45.062196] Write of size 4 at addr ffff8882b4b70968 by task kworker/3:1/53
    
    [   45.062325] CPU: 3 PID: 53 Comm: kworker/3:1 Kdump: loaded Tainted: G           O      4.20.0-rc4Lyude-Test+ #3
    [   45.062442] Hardware name: LENOVO 20BWS1KY00/20BWS1KY00, BIOS JBET71WW (1.35 ) 09/14/2018
    [   45.062554] Workqueue: events drm_dp_destroy_connector_work [drm_kms_helper]
    [   45.062641] Call Trace:
    [   45.062685]  dump_stack+0xbd/0x15a
    [   45.062735]  ? dump_stack_print_info.cold.0+0x1b/0x1b
    [   45.062801]  ? printk+0x9f/0xc5
    [   45.062847]  ? kmsg_dump_rewind_nolock+0xe4/0xe4
    [   45.062909]  ? ex_handler_refcount+0x146/0x180
    [   45.062970]  print_address_description+0x71/0x239
    [   45.063036]  ? ex_handler_refcount+0x146/0x180
    [   45.063095]  kasan_report.cold.5+0x242/0x30b
    [   45.063155]  __asan_report_store4_noabort+0x1c/0x20
    [   45.063313]  ex_handler_refcount+0x146/0x180
    [   45.063371]  ? ex_handler_clear_fs+0xb0/0xb0
    [   45.063428]  fixup_exception+0x98/0xd7
    [   45.063484]  ? raw_notifier_call_chain+0x20/0x20
    [   45.063548]  do_trap+0x6d/0x210
    [   45.063605]  ? _GLOBAL__sub_I_65535_1_drm_dp_aux_unregister_devnode+0x2f/0x1c6 [drm_kms_helper]
    [   45.063732]  do_error_trap+0xc0/0x170
    [   45.063802]  ? _GLOBAL__sub_I_65535_1_drm_dp_aux_unregister_devnode+0x2f/0x1c6 [drm_kms_helper]
    [   45.063929]  do_invalid_op+0x3b/0x50
    [   45.063997]  ? _GLOBAL__sub_I_65535_1_drm_dp_aux_unregister_devnode+0x2f/0x1c6 [drm_kms_helper]
    [   45.064103]  invalid_op+0x14/0x20
    [   45.064162] RIP: 0010:_GLOBAL__sub_I_65535_1_drm_dp_aux_unregister_devnode+0x2f/0x1c6 [drm_kms_helper]
    [   45.064274] Code: 00 48 c7 c7 80 fe 53 a0 48 89 e5 e8 5b 6f 26 e1 5d c3 48 8d 0e 0f 0b 48 8d 0b 0f 0b 48 8d 0f 0f 0b 48 8d 0f 0f 0b 49 8d 4d 00 <0f> 0b 49 8d 0e 0f 0b 48 8d 08 0f 0b 49 8d 4d 00 0f 0b 48 8d 0b 0f
    [   45.064569] RSP: 0018:ffff8882b789ee10 EFLAGS: 00010282
    [   45.064637] RAX: ffff8882af47ae70 RBX: ffff8882af47aa60 RCX: ffff8882b4b70968
    [   45.064723] RDX: ffff8882af47ae70 RSI: 0000000000000008 RDI: ffff8882b788bdb8
    [   45.064808] RBP: ffff8882b789ee28 R08: ffffed1056f13db4 R09: ffffed1056f13db3
    [   45.064894] R10: ffffed1056f13db3 R11: ffff8882b789ed9f R12: ffff8882af47ad28
    [   45.064980] R13: ffff8882b4b70968 R14: ffff8882acd86728 R15: ffff8882b4b75dc8
    [   45.065084]  drm_dp_mst_reset_vcpi_slots+0x12/0x80 [drm_kms_helper]
    [   45.065225]  intel_mst_disable_dp+0xda/0x180 [i915]
    [   45.065361]  intel_encoders_disable.isra.107+0x197/0x310 [i915]
    [   45.065498]  haswell_crtc_disable+0xbe/0x400 [i915]
    [   45.065622]  ? i9xx_disable_plane+0x1c0/0x3e0 [i915]
    [   45.065750]  intel_atomic_commit_tail+0x74e/0x3e60 [i915]
    [   45.065884]  ? intel_pre_plane_update+0xbc0/0xbc0 [i915]
    [   45.065968]  ? drm_atomic_helper_swap_state+0x88b/0x1d90 [drm_kms_helper]
    [   45.066054]  ? kasan_check_write+0x14/0x20
    [   45.066165]  ? i915_gem_track_fb+0x13a/0x330 [i915]
    [   45.066277]  ? i915_sw_fence_complete+0xe9/0x140 [i915]
    [   45.066406]  ? __i915_sw_fence_complete+0xc50/0xc50 [i915]
    [   45.066540]  intel_atomic_commit+0x72e/0xef0 [i915]
    [   45.066635]  ? drm_dev_dbg+0x200/0x200 [drm]
    [   45.066764]  ? intel_atomic_commit_tail+0x3e60/0x3e60 [i915]
    [   45.066898]  ? intel_atomic_commit_tail+0x3e60/0x3e60 [i915]
    [   45.067001]  drm_atomic_commit+0xc4/0xf0 [drm]
    [   45.067074]  restore_fbdev_mode_atomic+0x562/0x780 [drm_kms_helper]
    [   45.067166]  ? drm_fb_helper_debug_leave+0x690/0x690 [drm_kms_helper]
    [   45.067249]  ? kasan_check_read+0x11/0x20
    [   45.067324]  restore_fbdev_mode+0x127/0x4b0 [drm_kms_helper]
    [   45.067364]  ? kasan_check_read+0x11/0x20
    [   45.067406]  drm_fb_helper_restore_fbdev_mode_unlocked+0x164/0x200 [drm_kms_helper]
    [   45.067462]  ? drm_fb_helper_hotplug_event+0x30/0x30 [drm_kms_helper]
    [   45.067508]  ? kasan_check_write+0x14/0x20
    [   45.070360]  ? mutex_unlock+0x22/0x40
    [   45.073748]  drm_fb_helper_set_par+0xb2/0xf0 [drm_kms_helper]
    [   45.075846]  drm_fb_helper_hotplug_event.part.33+0x1cd/0x290 [drm_kms_helper]
    [   45.078088]  drm_fb_helper_hotplug_event+0x1c/0x30 [drm_kms_helper]
    [   45.082614]  intel_fbdev_output_poll_changed+0x9f/0x140 [i915]
    [   45.087069]  drm_kms_helper_hotplug_event+0x67/0x90 [drm_kms_helper]
    [   45.089319]  intel_dp_mst_hotplug+0x37/0x50 [i915]
    [   45.091496]  drm_dp_destroy_connector_work+0x510/0x6f0 [drm_kms_helper]
    [   45.093675]  ? drm_dp_update_payload_part1+0x1220/0x1220 [drm_kms_helper]
    [   45.095851]  ? kasan_check_write+0x14/0x20
    [   45.098473]  ? kasan_check_read+0x11/0x20
    [   45.101155]  ? strscpy+0x17c/0x530
    [   45.103808]  ? __switch_to_asm+0x34/0x70
    [   45.106456]  ? syscall_return_via_sysret+0xf/0x7f
    [   45.109711]  ? read_word_at_a_time+0x20/0x20
    [   45.113138]  ? __switch_to_asm+0x40/0x70
    [   45.116529]  ? __switch_to_asm+0x34/0x70
    [   45.119891]  ? __switch_to_asm+0x40/0x70
    [   45.123224]  ? __switch_to_asm+0x34/0x70
    [   45.126540]  ? __switch_to_asm+0x34/0x70
    [   45.129824]  process_one_work+0x88d/0x15d0
    [   45.133172]  ? pool_mayday_timeout+0x850/0x850
    [   45.136459]  ? pci_mmcfg_check_reserved+0x110/0x128
    [   45.139739]  ? wake_q_add+0xb0/0xb0
    [   45.143010]  ? check_preempt_wakeup+0x652/0x1050
    [   45.146304]  ? worker_enter_idle+0x29e/0x740
    [   45.149589]  ? __schedule+0x1ec0/0x1ec0
    [   45.152937]  ? kasan_check_read+0x11/0x20
    [   45.156179]  ? _raw_spin_lock_irq+0xa3/0x130
    [   45.159382]  ? _raw_read_unlock_irqrestore+0x30/0x30
    [   45.162542]  ? kasan_check_write+0x14/0x20
    [   45.165657]  worker_thread+0x1a5/0x1470
    [   45.168725]  ? set_load_weight+0x2e0/0x2e0
    [   45.171755]  ? process_one_work+0x15d0/0x15d0
    [   45.174806]  ? __switch_to_asm+0x34/0x70
    [   45.177645]  ? __switch_to_asm+0x40/0x70
    [   45.180323]  ? __switch_to_asm+0x34/0x70
    [   45.182936]  ? __switch_to_asm+0x40/0x70
    [   45.185539]  ? __switch_to_asm+0x34/0x70
    [   45.188100]  ? __switch_to_asm+0x40/0x70
    [   45.190628]  ? __schedule+0x7d4/0x1ec0
    [   45.193143]  ? save_stack+0xa9/0xd0
    [   45.195632]  ? kasan_check_write+0x10/0x20
    [   45.198162]  ? kasan_kmalloc+0xc4/0xe0
    [   45.200609]  ? kmem_cache_alloc_trace+0xdd/0x190
    [   45.203046]  ? kthread+0x9f/0x3b0
    [   45.205470]  ? ret_from_fork+0x35/0x40
    [   45.207876]  ? unwind_next_frame+0x43/0x50
    [   45.210273]  ? __save_stack_trace+0x82/0x100
    [   45.212658]  ? deactivate_slab.isra.67+0x3d4/0x580
    [   45.215026]  ? default_wake_function+0x35/0x50
    [   45.217399]  ? kasan_check_read+0x11/0x20
    [   45.219825]  ? _raw_spin_lock_irqsave+0xae/0x140
    [   45.222174]  ? __lock_text_start+0x8/0x8
    [   45.224521]  ? replenish_dl_entity.cold.62+0x4f/0x4f
    [   45.226868]  ? __kthread_parkme+0x87/0xf0
    [   45.229200]  kthread+0x2f7/0x3b0
    [   45.231557]  ? process_one_work+0x15d0/0x15d0
    [   45.233923]  ? kthread_park+0x120/0x120
    [   45.236249]  ret_from_fork+0x35/0x40
    
    [   45.240875] Allocated by task 242:
    [   45.243136]  save_stack+0x43/0xd0
    [   45.245385]  kasan_kmalloc+0xc4/0xe0
    [   45.247597]  kmem_cache_alloc_trace+0xdd/0x190
    [   45.249793]  drm_dp_add_port+0x1e0/0x2170 [drm_kms_helper]
    [   45.252000]  drm_dp_send_link_address+0x4a7/0x740 [drm_kms_helper]
    [   45.254389]  drm_dp_check_and_send_link_address+0x1a7/0x210 [drm_kms_helper]
    [   45.256803]  drm_dp_mst_link_probe_work+0x6f/0xb0 [drm_kms_helper]
    [   45.259200]  process_one_work+0x88d/0x15d0
    [   45.261597]  worker_thread+0x1a5/0x1470
    [   45.264038]  kthread+0x2f7/0x3b0
    [   45.266371]  ret_from_fork+0x35/0x40
    
    [   45.270937] Freed by task 53:
    [   45.273170]  save_stack+0x43/0xd0
    [   45.275382]  __kasan_slab_free+0x139/0x190
    [   45.277604]  kasan_slab_free+0xe/0x10
    [   45.279826]  kfree+0x99/0x1b0
    [   45.282044]  drm_dp_free_mst_port+0x4a/0x60 [drm_kms_helper]
    [   45.284330]  drm_dp_destroy_connector_work+0x43e/0x6f0 [drm_kms_helper]
    [   45.286660]  process_one_work+0x88d/0x15d0
    [   45.288934]  worker_thread+0x1a5/0x1470
    [   45.291231]  kthread+0x2f7/0x3b0
    [   45.293547]  ret_from_fork+0x35/0x40
    
    [   45.298206] The buggy address belongs to the object at ffff8882b4b70968
                    which belongs to the cache kmalloc-2k of size 2048
    [   45.303047] The buggy address is located 0 bytes inside of
                    2048-byte region [ffff8882b4b70968, ffff8882b4b71168)
    [   45.308010] The buggy address belongs to the page:
    [   45.310477] page:ffffea000ad2dc00 count:1 mapcount:0 mapping:ffff8882c080cf40 index:0x0 compound_mapcount: 0
    [   45.313051] flags: 0x8000000000010200(slab|head)
    [   45.315635] raw: 8000000000010200 ffffea000aac2808 ffffea000abe8608 ffff8882c080cf40
    [   45.318300] raw: 0000000000000000 00000000000d000d 00000001ffffffff 0000000000000000
    [   45.320966] page dumped because: kasan: bad access detected
    
    [   45.326312] Memory state around the buggy address:
    [   45.329085]  ffff8882b4b70800: fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [   45.331845]  ffff8882b4b70880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [   45.334584] >ffff8882b4b70900: fc fc fc fc fc fc fc fc fc fc fc fc fc fb fb fb
    [   45.337302]                                                           ^
    [   45.340061]  ffff8882b4b70980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [   45.342910]  ffff8882b4b70a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [   45.345748] ==================================================================
    
    So, this definitely isn't a fix that we want. This being said; there's
    no real easy fix for this problem because of some of the catch-22's of
    the MST helpers current design. For starters; we always need to validate
    a port with drm_dp_get_validated_port_ref(), but validation relies on
    the lifetime of the port in the actual topology. So once the port is
    gone, it can't be validated again.
    
    If we were to try to make the payload helpers not use port validation,
    then we'd cause another problem: if the port isn't validated, it could
    be freed and we'd just start causing more KASAN issues. There are
    already hacks that attempt to workaround this in
    drm_dp_mst_destroy_connector_work() by re-initializing the kref so that
    it can be used again and it's memory can be freed once the VCPI helpers
    finish removing the port's respective payloads. But none of these really
    do anything helpful since the port still can't be validated since it's
    gone from the topology. Also, that workaround is immensely confusing to
    read through.
    
    What really needs to be done in order to fix this is to teach DRM how to
    track the lifetime of the structs for MST ports and branch devices
    separately from their lifetime in the actual topology. Simply put; this
    means having two different krefs-one that removes the port/branch device
    from the topology, and one that finally calls kfree(). This would let us
    simplify things, since we'd now be able to keep ports around without
    having to keep them in the topology at the same time, which is exactly
    what we need in order to teach our VCPI helpers to only validate ports
    when it's actually necessary without running the risk of trying to use
    unallocated memory.
    
    Such a fix is on it's way, but for now let's play it safe and just
    revert this. If this bug has been around for well over a year, we can
    wait a little while to get an actual proper fix here.
    
    Signed-off-by: Lyude Paul <lyude@redhat.com>
    Fixes: c54c7374ff44 ("drm/dp_mst: Skip validating ports during destruction, just ref")
    Cc: Daniel Vetter <daniel@ffwll.ch>
    Cc: Sean Paul <sean@poorly.run>
    Cc: Jerry Zuo <Jerry.Zuo@amd.com>
    Cc: Harry Wentland <Harry.Wentland@amd.com>
    Cc: stable@vger.kernel.org # v4.6+
    Acked-by: Sean Paul <sean@poorly.run>
    Link: https://patchwork.freedesktop.org/patch/msgid/20181128210005.24434-1-lyude@redhat.com
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e68b6894f48bd6c10618360700c4a3655dc6934
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Mar 12 12:01:51 2020 +0100

    staging: greybus: loopback_test: fix potential path truncations
    
    commit ae62cf5eb2792d9a818c2d93728ed92119357017 upstream.
    
    Newer GCC warns about possible truncations of two generated path names as
    we're concatenating the configurable sysfs and debugfs path prefixes
    with a filename and placing the results in buffers of the same size as
    the maximum length of the prefixes.
    
            snprintf(d->name, MAX_STR_LEN, "gb_loopback%u", dev_id);
    
            snprintf(d->sysfs_entry, MAX_SYSFS_PATH, "%s%s/",
                     t->sysfs_prefix, d->name);
    
            snprintf(d->debugfs_entry, MAX_SYSFS_PATH, "%sraw_latency_%s",
                     t->debugfs_prefix, d->name);
    
    Fix this by separating the maximum path length from the maximum prefix
    length and reducing the latter enough to fit the generated strings.
    
    Note that we also need to reduce the device-name buffer size as GCC
    isn't smart enough to figure out that we ever only used MAX_STR_LEN
    bytes of it.
    
    Fixes: 6b0658f68786 ("greybus: tools: Add tools directory to greybus repo and add loopback")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20200312110151.22028-4-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d444ed69b47126c440a7a7bda0f1de2737a5644a
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Mar 12 12:01:50 2020 +0100

    staging: greybus: loopback_test: fix potential path truncation
    
    commit f16023834863932f95dfad13fac3fc47f77d2f29 upstream.
    
    Newer GCC warns about a possible truncation of a generated sysfs path
    name as we're concatenating a directory path with a file name and
    placing the result in a buffer that is half the size of the maximum
    length of the directory path (which is user controlled).
    
    loopback_test.c: In function 'open_poll_files':
    loopback_test.c:651:31: warning: '%s' directive output may be truncated writing up to 511 bytes into a region of size 255 [-Wformat-truncation=]
      651 |   snprintf(buf, sizeof(buf), "%s%s", dev->sysfs_entry, "iteration_count");
          |                               ^~
    loopback_test.c:651:3: note: 'snprintf' output between 16 and 527 bytes into a destination of size 255
      651 |   snprintf(buf, sizeof(buf), "%s%s", dev->sysfs_entry, "iteration_count");
          |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    Fix this by making sure the buffer is large enough the concatenated
    strings.
    
    Fixes: 6b0658f68786 ("greybus: tools: Add tools directory to greybus repo and add loopback")
    Fixes: 9250c0ee2626 ("greybus: Loopback_test: use poll instead of inotify")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20200312110151.22028-3-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 35989bb9eddedf7dda8dbadefc7dc95ccb552f4a
Author: Cristian Marussi <cristian.marussi@arm.com>
Date:   Wed Mar 11 17:12:44 2020 +0000

    arm64: smp: fix smp_send_stop() behaviour
    
    commit d0bab0c39e32d39a8c5cddca72e5b4a3059fe050 upstream.
    
    On a system with only one CPU online, when another one CPU panics while
    starting-up, smp_send_stop() will fail to send any STOP message to the
    other already online core, resulting in a system still responsive and
    alive at the end of the panic procedure.
    
    [  186.700083] CPU3: shutdown
    [  187.075462] CPU2: shutdown
    [  187.162869] CPU1: shutdown
    [  188.689998] ------------[ cut here ]------------
    [  188.691645] kernel BUG at arch/arm64/kernel/cpufeature.c:886!
    [  188.692079] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
    [  188.692444] Modules linked in:
    [  188.693031] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.6.0-rc4-00001-g338d25c35a98 #104
    [  188.693175] Hardware name: Foundation-v8A (DT)
    [  188.693492] pstate: 200001c5 (nzCv dAIF -PAN -UAO)
    [  188.694183] pc : has_cpuid_feature+0xf0/0x348
    [  188.694311] lr : verify_local_elf_hwcaps+0x84/0xe8
    [  188.694410] sp : ffff800011b1bf60
    [  188.694536] x29: ffff800011b1bf60 x28: 0000000000000000
    [  188.694707] x27: 0000000000000000 x26: 0000000000000000
    [  188.694801] x25: 0000000000000000 x24: ffff80001189a25c
    [  188.694905] x23: 0000000000000000 x22: 0000000000000000
    [  188.694996] x21: ffff8000114aa018 x20: ffff800011156a38
    [  188.695089] x19: ffff800010c944a0 x18: 0000000000000004
    [  188.695187] x17: 0000000000000000 x16: 0000000000000000
    [  188.695280] x15: 0000249dbde5431e x14: 0262cbe497efa1fa
    [  188.695371] x13: 0000000000000002 x12: 0000000000002592
    [  188.695472] x11: 0000000000000080 x10: 00400032b5503510
    [  188.695572] x9 : 0000000000000000 x8 : ffff800010c80204
    [  188.695659] x7 : 00000000410fd0f0 x6 : 0000000000000001
    [  188.695750] x5 : 00000000410fd0f0 x4 : 0000000000000000
    [  188.695836] x3 : 0000000000000000 x2 : ffff8000100939d8
    [  188.695919] x1 : 0000000000180420 x0 : 0000000000180480
    [  188.696253] Call trace:
    [  188.696410]  has_cpuid_feature+0xf0/0x348
    [  188.696504]  verify_local_elf_hwcaps+0x84/0xe8
    [  188.696591]  check_local_cpu_capabilities+0x44/0x128
    [  188.696666]  secondary_start_kernel+0xf4/0x188
    [  188.697150] Code: 52805001 72a00301 6b01001f 54000ec0 (d4210000)
    [  188.698639] ---[ end trace 3f12ca47652f7b72 ]---
    [  188.699160] Kernel panic - not syncing: Attempted to kill the idle task!
    [  188.699546] Kernel Offset: disabled
    [  188.699828] CPU features: 0x00004,20c02008
    [  188.700012] Memory Limit: none
    [  188.700538] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---
    
    [root@arch ~]# echo Helo
    Helo
    [root@arch ~]# cat /proc/cpuinfo | grep proce
    processor       : 0
    
    Make smp_send_stop() account also for the online status of the calling CPU
    while evaluating how many CPUs are effectively online: this way, the right
    number of STOPs is sent, so enforcing a proper freeze of the system at the
    end of panic even under the above conditions.
    
    Fixes: 08e875c16a16c ("arm64: SMP support")
    Reported-by: Dave Martin <Dave.Martin@arm.com>
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit caf411112fcec537634fad1221b3b877a2147285
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Wed Mar 11 14:13:28 2020 +0800

    ALSA: hda/realtek: Fix pop noise on ALC225
    
    commit 3b36b13d5e69d6f51ff1c55d1b404a74646c9757 upstream.
    
    Commit 317d9313925c ("ALSA: hda/realtek - Set default power save node to
    0") makes the ALC225 have pop noise on S3 resume and cold boot.
    
    So partially revert this commit for ALC225 to fix the regression.
    
    Fixes: 317d9313925c ("ALSA: hda/realtek - Set default power save node to 0")
    BugLink: https://bugs.launchpad.net/bugs/1866357
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Link: https://lore.kernel.org/r/20200311061328.17614-1-kai.heng.feng@canonical.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 95c5383499d656599edeb0d391592a99c5736d80
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sun Mar 8 19:07:17 2020 +0100

    futex: Unbreak futex hashing
    
    commit 8d67743653dce5a0e7aa500fcccb237cde7ad88e upstream.
    
    The recent futex inode life time fix changed the ordering of the futex key
    union struct members, but forgot to adjust the hash function accordingly,
    
    As a result the hashing omits the leading 64bit and even hashes beyond the
    futex key causing a bad hash distribution which led to a ~100% performance
    regression.
    
    Hand in the futex key pointer instead of a random struct member and make
    the size calculation based of the struct offset.
    
    Fixes: 8019ad13ef7f ("futex: Fix inode life-time issue")
    Reported-by: Rong Chen <rong.a.chen@intel.com>
    Decoded-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Rong Chen <rong.a.chen@intel.com>
    Link: https://lkml.kernel.org/r/87h7yy90ve.fsf@nanos.tec.linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb099f3bb477a0ee2d0669a753f7ffcdf8884c2d
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Wed Mar 4 11:28:31 2020 +0100

    futex: Fix inode life-time issue
    
    commit 8019ad13ef7f64be44d4f892af9c840179009254 upstream.
    
    As reported by Jann, ihold() does not in fact guarantee inode
    persistence. And instead of making it so, replace the usage of inode
    pointers with a per boot, machine wide, unique inode identifier.
    
    This sequence number is global, but shared (file backed) futexes are
    rare enough that this should not become a performance issue.
    
    Reported-by: Jann Horn <jannh@google.com>
    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3251c97f66407c57089c2002228fe25316ad4c57
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Wed Mar 11 12:41:21 2020 -0700

    kbuild: Disable -Wpointer-to-enum-cast
    
    commit 82f2bc2fcc0160d6f82dd1ac64518ae0a4dd183f upstream.
    
    Clang's -Wpointer-to-int-cast deviates from GCC in that it warns when
    casting to enums. The kernel does this in certain places, such as device
    tree matches to set the version of the device being used, which allows
    the kernel to avoid using a gigantic union.
    
    https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L428
    https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L402
    https://elixir.bootlin.com/linux/v5.5.8/source/include/linux/mod_devicetable.h#L264
    
    To avoid a ton of false positive warnings, disable this particular part
    of the warning, which has been split off into a separate diagnostic so
    that the entire warning does not need to be turned off for clang. It
    will be visible under W=1 in case people want to go about fixing these
    easily and enabling the warning treewide.
    
    Cc: stable@vger.kernel.org
    Link: https://github.com/ClangBuiltLinux/linux/issues/887
    Link: https://github.com/llvm/llvm-project/commit/2a41b31fcdfcb67ab7038fc2ffb606fd50b83a84
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8e22289c9f58b2126f923e0f4e3cb23db9b8f872
Author: Anthony Mallet <anthony.mallet@laas.fr>
Date:   Thu Mar 12 14:31:01 2020 +0100

    USB: cdc-acm: fix rounding error in TIOCSSERIAL
    
    [ Upstream commit b401f8c4f492cbf74f3f59c9141e5be3071071bb ]
    
    By default, tty_port_init() initializes those parameters to a multiple
    of HZ. For instance in line 69 of tty_port.c:
       port->close_delay = (50 * HZ) / 100;
    https://github.com/torvalds/linux/blob/master/drivers/tty/tty_port.c#L69
    
    With e.g. CONFIG_HZ = 250 (as this is the case for Ubuntu 18.04
    linux-image-4.15.0-37-generic), the default setting for close_delay is
    thus 125.
    
    When ioctl(fd, TIOCGSERIAL, &s) is executed, the setting returned in
    user space is '12' (125/10). When ioctl(fd, TIOCSSERIAL, &s) is then
    executed with the same setting '12', the value is interpreted as '120'
    which is different from the current setting and a EPERM error may be
    raised by set_serial_info() if !CAP_SYS_ADMIN.
    https://github.com/torvalds/linux/blob/master/drivers/usb/class/cdc-acm.c#L919
    
    Fixes: ba2d8ce9db0a6 ("cdc-acm: implement TIOCSSERIAL to avoid blocking close(2)")
    Signed-off-by: Anthony Mallet <anthony.mallet@laas.fr>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200312133101.7096-2-anthony.mallet@laas.fr
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7d09cc7bbe80c2f4208daa5e306572ca944af0e3
Author: Anthony Mallet <anthony.mallet@laas.fr>
Date:   Thu Mar 12 14:31:00 2020 +0100

    USB: cdc-acm: fix close_delay and closing_wait units in TIOCSSERIAL
    
    [ Upstream commit 633e2b2ded739a34bd0fb1d8b5b871f7e489ea29 ]
    
    close_delay and closing_wait are specified in hundredth of a second but stored
    internally in jiffies. Use the jiffies_to_msecs() and msecs_to_jiffies()
    functions to convert from each other.
    
    Signed-off-by: Anthony Mallet <anthony.mallet@laas.fr>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200312133101.7096-1-anthony.mallet@laas.fr
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8c59bdceffbc8f7485ac4e68a1eb3d618154fc35
Author: Joerg Roedel <jroedel@suse.de>
Date:   Sat Mar 21 18:22:41 2020 -0700

    x86/mm: split vmalloc_sync_all()
    
    commit 763802b53a427ed3cbd419dbba255c414fdd9e7c upstream.
    
    Commit 3f8fd02b1bf1 ("mm/vmalloc: Sync unmappings in
    __purge_vmap_area_lazy()") introduced a call to vmalloc_sync_all() in
    the vunmap() code-path.  While this change was necessary to maintain
    correctness on x86-32-pae kernels, it also adds additional cycles for
    architectures that don't need it.
    
    Specifically on x86-64 with CONFIG_VMAP_STACK=y some people reported
    severe performance regressions in micro-benchmarks because it now also
    calls the x86-64 implementation of vmalloc_sync_all() on vunmap().  But
    the vmalloc_sync_all() implementation on x86-64 is only needed for newly
    created mappings.
    
    To avoid the unnecessary work on x86-64 and to gain the performance
    back, split up vmalloc_sync_all() into two functions:
    
            * vmalloc_sync_mappings(), and
            * vmalloc_sync_unmappings()
    
    Most call-sites to vmalloc_sync_all() only care about new mappings being
    synchronized.  The only exception is the new call-site added in the
    above mentioned commit.
    
    Shile Zhang directed us to a report of an 80% regression in reaim
    throughput.
    
    Fixes: 3f8fd02b1bf1 ("mm/vmalloc: Sync unmappings in __purge_vmap_area_lazy()")
    Reported-by: kernel test robot <oliver.sang@intel.com>
    Reported-by: Shile Zhang <shile.zhang@linux.alibaba.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Tested-by: Borislav Petkov <bp@suse.de>
    Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>        [GHES]
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: <stable@vger.kernel.org>
    Link: http://lkml.kernel.org/r/20191009124418.8286-1-joro@8bytes.org
    Link: https://lists.01.org/hyperkitty/list/lkp@lists.01.org/thread/4D3JPPHBNOSPFK2KEPC6KGKS6J25AIDB/
    Link: http://lkml.kernel.org/r/20191113095530.228959-1-shile.zhang@linux.alibaba.com
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a8a2622689c4478f59900fbe6b4e6f6ce1521033
Author: Vlastimil Babka <vbabka@suse.cz>
Date:   Sat Mar 21 18:22:37 2020 -0700

    mm, slub: prevent kmalloc_node crashes and memory leaks
    
    commit 0715e6c516f106ed553828a671d30ad9a3431536 upstream.
    
    Sachin reports [1] a crash in SLUB __slab_alloc():
    
      BUG: Kernel NULL pointer dereference on read at 0x000073b0
      Faulting instruction address: 0xc0000000003d55f4
      Oops: Kernel access of bad area, sig: 11 [#1]
      LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
      Modules linked in:
      CPU: 19 PID: 1 Comm: systemd Not tainted 5.6.0-rc2-next-20200218-autotest #1
      NIP:  c0000000003d55f4 LR: c0000000003d5b94 CTR: 0000000000000000
      REGS: c0000008b37836d0 TRAP: 0300   Not tainted  (5.6.0-rc2-next-20200218-autotest)
      MSR:  8000000000009033 <SF,EE,ME,IR,DR,RI,LE>  CR: 24004844  XER: 00000000
      CFAR: c00000000000dec4 DAR: 00000000000073b0 DSISR: 40000000 IRQMASK: 1
      GPR00: c0000000003d5b94 c0000008b3783960 c00000000155d400 c0000008b301f500
      GPR04: 0000000000000dc0 0000000000000002 c0000000003443d8 c0000008bb398620
      GPR08: 00000008ba2f0000 0000000000000001 0000000000000000 0000000000000000
      GPR12: 0000000024004844 c00000001ec52a00 0000000000000000 0000000000000000
      GPR16: c0000008a1b20048 c000000001595898 c000000001750c18 0000000000000002
      GPR20: c000000001750c28 c000000001624470 0000000fffffffe0 5deadbeef0000122
      GPR24: 0000000000000001 0000000000000dc0 0000000000000002 c0000000003443d8
      GPR28: c0000008b301f500 c0000008bb398620 0000000000000000 c00c000002287180
      NIP ___slab_alloc+0x1f4/0x760
      LR __slab_alloc+0x34/0x60
      Call Trace:
        ___slab_alloc+0x334/0x760 (unreliable)
        __slab_alloc+0x34/0x60
        __kmalloc_node+0x110/0x490
        kvmalloc_node+0x58/0x110
        mem_cgroup_css_online+0x108/0x270
        online_css+0x48/0xd0
        cgroup_apply_control_enable+0x2ec/0x4d0
        cgroup_mkdir+0x228/0x5f0
        kernfs_iop_mkdir+0x90/0xf0
        vfs_mkdir+0x110/0x230
        do_mkdirat+0xb0/0x1a0
        system_call+0x5c/0x68
    
    This is a PowerPC platform with following NUMA topology:
    
      available: 2 nodes (0-1)
      node 0 cpus:
      node 0 size: 0 MB
      node 0 free: 0 MB
      node 1 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
      node 1 size: 35247 MB
      node 1 free: 30907 MB
      node distances:
      node   0   1
        0:  10  40
        1:  40  10
    
      possible numa nodes: 0-31
    
    This only happens with a mmotm patch "mm/memcontrol.c: allocate
    shrinker_map on appropriate NUMA node" [2] which effectively calls
    kmalloc_node for each possible node.  SLUB however only allocates
    kmem_cache_node on online N_NORMAL_MEMORY nodes, and relies on
    node_to_mem_node to return such valid node for other nodes since commit
    a561ce00b09e ("slub: fall back to node_to_mem_node() node if allocating
    on memoryless node").  This is however not true in this configuration
    where the _node_numa_mem_ array is not initialized for nodes 0 and 2-31,
    thus it contains zeroes and get_partial() ends up accessing
    non-allocated kmem_cache_node.
    
    A related issue was reported by Bharata (originally by Ramachandran) [3]
    where a similar PowerPC configuration, but with mainline kernel without
    patch [2] ends up allocating large amounts of pages by kmalloc-1k
    kmalloc-512.  This seems to have the same underlying issue with
    node_to_mem_node() not behaving as expected, and might probably also
    lead to an infinite loop with CONFIG_SLUB_CPU_PARTIAL [4].
    
    This patch should fix both issues by not relying on node_to_mem_node()
    anymore and instead simply falling back to NUMA_NO_NODE, when
    kmalloc_node(node) is attempted for a node that's not online, or has no
    usable memory.  The "usable memory" condition is also changed from
    node_present_pages() to N_NORMAL_MEMORY node state, as that is exactly
    the condition that SLUB uses to allocate kmem_cache_node structures.
    The check in get_partial() is removed completely, as the checks in
    ___slab_alloc() are now sufficient to prevent get_partial() being
    reached with an invalid node.
    
    [1] https://lore.kernel.org/linux-next/3381CD91-AB3D-4773-BA04-E7A072A63968@linux.vnet.ibm.com/
    [2] https://lore.kernel.org/linux-mm/fff0e636-4c36-ed10-281c-8cdb0687c839@virtuozzo.com/
    [3] https://lore.kernel.org/linux-mm/20200317092624.GB22538@in.ibm.com/
    [4] https://lore.kernel.org/linux-mm/088b5996-faae-8a56-ef9c-5b567125ae54@suse.cz/
    
    Fixes: a561ce00b09e ("slub: fall back to node_to_mem_node() node if allocating on memoryless node")
    Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
    Reported-by: PUVICHAKRAVARTHY RAMACHANDRAN <puvichakravarthy@in.ibm.com>
    Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Tested-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
    Tested-by: Bharata B Rao <bharata@linux.ibm.com>
    Reviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    Cc: Mel Gorman <mgorman@techsingularity.net>
    Cc: Michael Ellerman <mpe@ellerman.id.au>
    Cc: Michal Hocko <mhocko@kernel.org>
    Cc: Christopher Lameter <cl@linux.com>
    Cc: linuxppc-dev@lists.ozlabs.org
    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Cc: Pekka Enberg <penberg@kernel.org>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Kirill Tkhai <ktkhai@virtuozzo.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Nathan Lynch <nathanl@linux.ibm.com>
    Cc: <stable@vger.kernel.org>
    Link: http://lkml.kernel.org/r/20200320115533.9604-1-vbabka@suse.cz
    Debugged-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e663542445b828bc2c5daf8978d8d5c42678fc15
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue Mar 17 11:04:09 2020 -0700

    mm: slub: be more careful about the double cmpxchg of freelist
    
    commit 5076190daded2197f62fe92cf69674488be44175 upstream.
    
    This is just a cleanup addition to Jann's fix to properly update the
    transaction ID for the slub slowpath in commit fd4d9c7d0c71 ("mm: slub:
    add missing TID bump..").
    
    The transaction ID is what protects us against any concurrent accesses,
    but we should really also make sure to make the 'freelist' comparison
    itself always use the same freelist value that we then used as the new
    next free pointer.
    
    Jann points out that if we do all of this carefully, we could skip the
    transaction ID update for all the paths that only remove entries from
    the lists, and only update the TID when adding entries (to avoid the ABA
    issue with cmpxchg and list handling re-adding a previously seen value).
    
    But this patch just does the "make sure to cmpxchg the same value we
    used" rather than then try to be clever.
    
    Acked-by: Jann Horn <jannh@google.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62628b8660262c1138e76232ba5a967b6815b7e9
Author: Chunguang Xu <brookxu@tencent.com>
Date:   Sat Mar 21 18:22:10 2020 -0700

    memcg: fix NULL pointer dereference in __mem_cgroup_usage_unregister_event
    
    commit 7d36665a5886c27ca4c4d0afd3ecc50b400f3587 upstream.
    
    An eventfd monitors multiple memory thresholds of the cgroup, closes them,
    the kernel deletes all events related to this eventfd.  Before all events
    are deleted, another eventfd monitors the memory threshold of this cgroup,
    leading to a crash:
    
      BUG: kernel NULL pointer dereference, address: 0000000000000004
      #PF: supervisor write access in kernel mode
      #PF: error_code(0x0002) - not-present page
      PGD 800000033058e067 P4D 800000033058e067 PUD 3355ce067 PMD 0
      Oops: 0002 [#1] SMP PTI
      CPU: 2 PID: 14012 Comm: kworker/2:6 Kdump: loaded Not tainted 5.6.0-rc4 #3
      Hardware name: LENOVO 20AWS01K00/20AWS01K00, BIOS GLET70WW (2.24 ) 05/21/2014
      Workqueue: events memcg_event_remove
      RIP: 0010:__mem_cgroup_usage_unregister_event+0xb3/0x190
      RSP: 0018:ffffb47e01c4fe18 EFLAGS: 00010202
      RAX: 0000000000000001 RBX: ffff8bb223a8a000 RCX: 0000000000000001
      RDX: 0000000000000001 RSI: ffff8bb22fb83540 RDI: 0000000000000001
      RBP: ffffb47e01c4fe48 R08: 0000000000000000 R09: 0000000000000010
      R10: 000000000000000c R11: 071c71c71c71c71c R12: ffff8bb226aba880
      R13: ffff8bb223a8a480 R14: 0000000000000000 R15: 0000000000000000
      FS:  0000000000000000(0000) GS:ffff8bb242680000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000004 CR3: 000000032c29c003 CR4: 00000000001606e0
      Call Trace:
        memcg_event_remove+0x32/0x90
        process_one_work+0x172/0x380
        worker_thread+0x49/0x3f0
        kthread+0xf8/0x130
        ret_from_fork+0x35/0x40
      CR2: 0000000000000004
    
    We can reproduce this problem in the following ways:
    
    1. We create a new cgroup subdirectory and a new eventfd, and then we
       monitor multiple memory thresholds of the cgroup through this eventfd.
    
    2.  closing this eventfd, and __mem_cgroup_usage_unregister_event ()
       will be called multiple times to delete all events related to this
       eventfd.
    
    The first time __mem_cgroup_usage_unregister_event() is called, the
    kernel will clear all items related to this eventfd in thresholds->
    primary.
    
    Since there is currently only one eventfd, thresholds-> primary becomes
    empty, so the kernel will set thresholds-> primary and hresholds-> spare
    to NULL.  If at this time, the user creates a new eventfd and monitor
    the memory threshold of this cgroup, kernel will re-initialize
    thresholds-> primary.
    
    Then when __mem_cgroup_usage_unregister_event () is called for the
    second time, because thresholds-> primary is not empty, the system will
    access thresholds-> spare, but thresholds-> spare is NULL, which will
    trigger a crash.
    
    In general, the longer it takes to delete all events related to this
    eventfd, the easier it is to trigger this problem.
    
    The solution is to check whether the thresholds associated with the
    eventfd has been cleared when deleting the event.  If so, we do nothing.
    
    [akpm@linux-foundation.org: fix comment, per Kirill]
    Fixes: 907860ed381a ("cgroups: make cftype.unregister_event() void-returning")
    Signed-off-by: Chunguang Xu <brookxu@tencent.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: http://lkml.kernel.org/r/077a6f67-aefa-4591-efec-f2f3af2b0b02@gmail.com
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4866ed92e47fff38e9438433472a6a2b919991e1
Author: Corentin Labbe <clabbe@baylibre.com>
Date:   Wed Mar 18 15:26:49 2020 +0000

    rtc: max8907: add missing select REGMAP_IRQ
    
    commit 5d892919fdd0cefd361697472d4e1b174a594991 upstream.
    
    I have hit the following build error:
    
      armv7a-hardfloat-linux-gnueabi-ld: drivers/rtc/rtc-max8907.o: in function `max8907_rtc_probe':
      rtc-max8907.c:(.text+0x400): undefined reference to `regmap_irq_get_virq'
    
    max8907 should select REGMAP_IRQ
    
    Fixes: 94c01ab6d7544 ("rtc: add MAX8907 RTC driver")
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1e99829d8cd574011ffd5447fc820ed18d5d5ac9
Author: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Date:   Tue Mar 17 08:22:14 2020 +0200

    intel_th: Fix user-visible error codes
    
    commit ce666be89a8a09c5924ff08fc32e119f974bdab6 upstream.
    
    There are a few places in the driver that end up returning ENOTSUPP to
    the user, replace those with EINVAL.
    
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Fixes: ba82664c134ef ("intel_th: Add Memory Storage Unit driver")
    Cc: stable@vger.kernel.org # v4.4+
    Link: https://lore.kernel.org/r/20200317062215.15598-6-alexander.shishkin@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 05f7f08e034706df30329daf7a53b4da7ee614f2
Author: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date:   Fri Mar 6 01:30:47 2020 +0100

    staging/speakup: fix get_word non-space look-ahead
    
    commit 9d32c0cde4e2d1343dfb88a67b2ec6397705b32b upstream.
    
    get_char was erroneously given the address of the pointer to the text
    instead of the address of the text, thus leading to random crashes when
    the user requests speaking a word while the current position is on a space
    character and say_word_ctl is not enabled.
    
    Reported-on: https://github.com/bytefire/speakup/issues/1
    Reported-by: Kirk Reiser <kirk@reisers.ca>
    Reported-by: Janina Sajka <janina@rednote.net>
    Reported-by: Alexandr Epaneshnikov <aarnaarn2@gmail.com>
    Reported-by: Gregory Nowak <greg@gregn.net>
    Reported-by: deedra waters <deedra@the-brannons.com>
    Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
    Tested-by: Alexandr Epaneshnikov <aarnaarn2@gmail.com>
    Tested-by: Gregory Nowak <greg@gregn.net>
    Tested-by: Michael Taboada <michael@michaels.world>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200306003047.thijtmqrnayd3dmw@function
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7be6822e7f052e5fb428c4b9f0b5c9bd6abf132c
Author: Michael Straube <straube.linux@gmail.com>
Date:   Thu Mar 12 10:36:52 2020 +0100

    staging: rtl8188eu: Add device id for MERCUSYS MW150US v2
    
    commit bb5786b9286c253557a0115bc8d21879e61b7b94 upstream.
    
    This device was added to the stand-alone driver on github.
    Add it to the staging driver as well.
    
    Link: https://github.com/lwfinger/rtl8188eu/commit/2141f244c3e7
    Signed-off-by: Michael Straube <straube.linux@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200312093652.13918-1-straube.linux@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bddeb421b755a6d7f182f246b280766738a9e42b
Author: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date:   Sun Mar 15 17:44:25 2020 +0100

    mmc: sdhci-of-at91: fix cd-gpios for SAMA5D2
    
    commit 53dd0a7cd65edc83b0c243d1c08377c8b876b2ee upstream.
    
    SAMA5D2x doesn't drive CMD line if GPIO is used as CD line (at least
    SAMA5D27 doesn't). Fix this by forcing card-detect in the module
    if module-controlled CD is not used.
    
    Fixed commit addresses the problem only for non-removable cards. This
    amends it to also cover gpio-cd case.
    
    Cc: stable@vger.kernel.org
    Fixes: 7a1e3f143176 ("mmc: sdhci-of-at91: force card detect value for non removable devices")
    Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Link: https://lore.kernel.org/r/8d10950d9940468577daef4772b82a071b204716.1584290561.git.mirq-linux@rere.qmqm.pl
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc823df170e7d3a11bafcc4731eb3f60623df797
Author: Stephan Gerhold <stephan@gerhold.net>
Date:   Fri Feb 14 12:03:24 2020 +0100

    iio: magnetometer: ak8974: Fix negative raw values in sysfs
    
    commit b500c086e4110829a308c23e83a7cdc65b26228a upstream.
    
    At the moment, reading from in_magn_*_raw in sysfs tends to return
    large values around 65000, even though the output of ak8974 is actually
    limited to ±32768. This happens because the value is never converted
    to the signed 16-bit integer variant.
    
    Add an explicit cast to s16 to fix this.
    
    Fixes: 7c94a8b2ee8c ("iio: magn: add a driver for AK8974")
    Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
    Reviewed-by: Linus Waleij <linus.walleij@linaro.org>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 51d3d6778adf1e50a3a25fab44fc6bfd4e1459a1
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Mar 12 16:57:30 2020 +0100

    ALSA: pcm: oss: Remove WARNING from snd_pcm_plug_alloc() checks
    
    commit 5461e0530c222129dfc941058be114b5cbc00837 upstream.
    
    The return value checks in snd_pcm_plug_alloc() are covered with
    snd_BUG_ON() macro that may trigger a kernel WARNING depending on the
    kconfig.  But since the error condition can be triggered by a weird
    user space parameter passed to OSS layer, we shouldn't give the kernel
    stack trace just for that.  As it's a normal error condition, let's
    remove snd_BUG_ON() macro usage there.
    
    Reported-by: syzbot+2a59ee7a9831b264f45e@syzkaller.appspotmail.com
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200312155730.7520-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e2edae1f9ffc04d13ae9319ebb2252efbe3c485c
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Mar 9 09:21:48 2020 +0100

    ALSA: pcm: oss: Avoid plugin buffer overflow
    
    commit f2ecf903ef06eb1bbbfa969db9889643d487e73a upstream.
    
    Each OSS PCM plugins allocate its internal buffer per pre-calculation
    of the max buffer size through the chain of plugins (calling
    src_frames and dst_frames callbacks).  This works for most plugins,
    but the rate plugin might behave incorrectly.  The calculation in the
    rate plugin involves with the fractional position, i.e. it may vary
    depending on the input position.  Since the buffer size
    pre-calculation is always done with the offset zero, it may return a
    shorter size than it might be; this may result in the out-of-bound
    access as spotted by fuzzer.
    
    This patch addresses those possible buffer overflow accesses by simply
    setting the upper limit per the given buffer size for each plugin
    before src_frames() and after dst_frames() calls.
    
    Reported-by: syzbot+e1fe9f44fb8ecf4fb5dd@syzkaller.appspotmail.com
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/000000000000b25ea005a02bcf21@google.com
    Link: https://lore.kernel.org/r/20200309082148.19855-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3356e53c860bf85282a213684629ff25c709c925
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Mar 16 10:05:06 2020 +0100

    ALSA: seq: oss: Fix running status after receiving sysex
    
    commit 6c3171ef76a0bad892050f6959a7eac02fb16df7 upstream.
    
    This is a similar bug like the previous case for virmidi: the invalid
    running status is kept after receiving a sysex message.
    
    Again the fix is to clear the running status after handling the sysex.
    
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/3b4a4e0f232b7afbaf0a843f63d0e538e3029bfd.camel@domdv.de
    Link: https://lore.kernel.org/r/20200316090506.23966-3-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1783ff0390230d71a0580f5c21cc3da197b43d0e
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Mar 16 10:05:05 2020 +0100

    ALSA: seq: virmidi: Fix running status after receiving sysex
    
    commit 4384f167ce5fa7241b61bb0984d651bc528ddebe upstream.
    
    The virmidi driver handles sysex event exceptionally in a short-cut
    snd_seq_dump_var_event() call, but this missed the reset of the
    running status.  As a result, it may lead to an incomplete command
    right after the sysex when an event with the same running status was
    queued.
    
    Fix it by clearing the running status properly via alling
    snd_midi_event_reset_decode() for that code path.
    
    Reported-by: Andreas Steinmetz <ast@domdv.de>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/3b4a4e0f232b7afbaf0a843f63d0e538e3029bfd.camel@domdv.de
    Link: https://lore.kernel.org/r/20200316090506.23966-2-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d53b9e03b4eaaede319b411958dc0232d91050a
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Mar 9 10:59:22 2020 +0100

    ALSA: line6: Fix endless MIDI read loop
    
    commit d683469b3c93d7e2afd39e6e1970f24700eb7a68 upstream.
    
    The MIDI input event parser of the LINE6 driver may enter into an
    endless loop when the unexpected data sequence is given, as it tries
    to continue the secondary bytes without termination.  Also, when the
    input data is too short, the parser returns a negative error, while
    the caller doesn't handle it properly.  This would lead to the
    unexpected behavior as well.
    
    This patch addresses those issues by checking the return value
    correctly and handling the one-byte event in the parser properly.
    
    The bug was reported by syzkaller.
    
    Reported-by: syzbot+cce32521ee0a824c21f7@syzkaller.appspotmail.com
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/000000000000033087059f8f8fa3@google.com
    Link: https://lore.kernel.org/r/20200309095922.30269-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a07410ba4df94499083e87d52a98491d465991cc
Author: Scott Chen <scott@labau.com.tw>
Date:   Wed Mar 11 14:14:23 2020 +0800

    USB: serial: pl2303: add device-id for HP LD381
    
    commit cecc113c1af0dd41ccf265c1fdb84dbd05e63423 upstream.
    
    Add a device id for HP LD381 Display
    LD381:   03f0:0f7f
    
    Signed-off-by: Scott Chen <scott@labau.com.tw>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad88d8db0ba50aaa973f28607880af310cab429f
Author: Ran Wang <ran.wang_1@nxp.com>
Date:   Fri Mar 6 17:23:28 2020 +0800

    usb: host: xhci-plat: add a shutdown
    
    commit b433e340e7565110b0ce9ca4b3e26f4b97a1decf upstream.
    
    When loading new kernel via kexec, we need to shutdown host controller to
    avoid any un-expected memory accessing during new kernel boot.
    
    Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
    Cc: stable <stable@vger.kernel.org>
    Tested-by: Stephen Boyd <swboyd@chromium.org>
    Reviewed-by: Peter Chen <peter.chen@nxp.com>
    Link: https://lore.kernel.org/r/20200306092328.41253-1-ran.wang_1@nxp.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c0bd356f21690f9203019512f37d3eee8845029b
Author: Daniele Palmas <dnlplm@gmail.com>
Date:   Wed Mar 4 11:43:10 2020 +0100

    USB: serial: option: add ME910G1 ECM composition 0x110b
    
    commit 8e852a7953be2a6ee371449f7257fe15ace6a1fc upstream.
    
    Add ME910G1 ECM composition 0x110b: tty, tty, tty, ecm
    
    Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
    Link: https://lore.kernel.org/r/20200304104310.2938-1-dnlplm@gmail.com
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 517c81ceb477d0198b25815e417ba7b9a7a3f4c1
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Fri Mar 13 13:07:08 2020 +0100

    usb: quirks: add NO_LPM quirk for RTL8153 based ethernet adapters
    
    commit 75d7676ead19b1fbb5e0ee934c9ccddcb666b68c upstream.
    
    We have been receiving bug reports that ethernet connections over
    RTL8153 based ethernet adapters stops working after a while with
    errors like these showing up in dmesg when the ethernet stops working:
    
    [12696.189484] r8152 6-1:1.0 enp10s0u1: Tx timeout
    [12702.333456] r8152 6-1:1.0 enp10s0u1: Tx timeout
    [12707.965422] r8152 6-1:1.0 enp10s0u1: Tx timeout
    
    This has been reported on Dell WD15 docks, Belkin USB-C Express Dock 3.1
    docks and with generic USB to ethernet dongles using the RTL8153
    chipsets. Some users have tried adding usbcore.quirks=0bda:8153:k to
    the kernel commandline and all users who have tried this report that
    this fixes this.
    
    Also note that we already have an existing NO_LPM quirk for the RTL8153
    used in the Microsoft Surface Dock (where it uses a different usb-id).
    
    This commit adds a NO_LPM quirk for the generic Realtek RTL8153
    0bda:8153 usb-id, fixing the Tx timeout errors on these devices.
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=198931
    Cc: stable@vger.kernel.org
    Cc: russianneuromancer@ya.ru
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20200313120708.100339-1-hdegoede@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 55f186fbfcda5838d41989f12aa0e10732af9d96
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Wed Feb 5 19:26:33 2020 +0800

    USB: Disable LPM on WD19's Realtek Hub
    
    commit b63e48fb50e1ca71db301ca9082befa6f16c55c4 upstream.
    
    Realtek Hub (0bda:0x0487) used in Dell Dock WD19 sometimes drops off the
    bus when bringing underlying ports from U3 to U0.
    
    Disabling LPM on the hub during setting link state is not enough, so
    let's disable LPM completely for this hub.
    
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200205112633.25995-3-kai.heng.feng@canonical.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 95489cba64a81220390141405ff0d5cf013e6f82
Author: Daniel Axtens <dja@axtens.net>
Date:   Tue Feb 25 10:44:27 2020 -0800

    altera-stapl: altera_get_note: prevent write beyond end of 'key'
    
    [ Upstream commit 3745488e9d599916a0b40d45d3f30e3d4720288e ]
    
    altera_get_note is called from altera_init, where key is kzalloc(33).
    
    When the allocation functions are annotated to allow the compiler to see
    the sizes of objects, and with FORTIFY_SOURCE, we see:
    
    In file included from drivers/misc/altera-stapl/altera.c:14:0:
    In function ‘strlcpy’,
        inlined from ‘altera_init’ at drivers/misc/altera-stapl/altera.c:2189:5:
    include/linux/string.h:378:4: error: call to ‘__write_overflow’ declared with attribute error: detected write beyond size of object passed as 1st parameter
        __write_overflow();
        ^~~~~~~~~~~~~~~~~~
    
    That refers to this code in altera_get_note:
    
        if (key != NULL)
                strlcpy(key, &p[note_strings +
                                get_unaligned_be32(
                                &p[note_table + (8 * i)])],
                        length);
    
    The error triggers because the length of 'key' is 33, but the copy
    uses length supplied as the 'length' parameter, which is always
    256. Split the size parameter into key_len and val_len, and use the
    appropriate length depending on what is being copied.
    
    Detected by compiler error, only compile-tested.
    
    Cc: "Igor M. Liplianin" <liplianin@netup.ru>
    Signed-off-by: Daniel Axtens <dja@axtens.net>
    Link: https://lore.kernel.org/r/20200120074344.504-2-dja@axtens.net
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/202002251042.D898E67AC@keescook
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 108ebbc04e891b1ca7197db732421ececb6a32d2
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date:   Thu Feb 20 13:30:12 2020 +0100

    drm/exynos: dsi: fix workaround for the legacy clock name
    
    [ Upstream commit c0fd99d659ba5582e09625c7a985d63fc2ca74b5 ]
    
    Writing to the built-in strings arrays doesn't work if driver is loaded
    as kernel module. This is also considered as a bad pattern. Fix this by
    adding a call to clk_get() with legacy clock name. This fixes following
    kernel oops if driver is loaded as module:
    
    Unable to handle kernel paging request at virtual address bf047978
     pgd = (ptrval)
     [bf047978] *pgd=59344811, *pte=5903c6df, *ppte=5903c65f
     Internal error: Oops: 80f [#1] SMP ARM
     Modules linked in: mc exynosdrm(+) analogix_dp rtc_s3c exynos_ppmu i2c_gpio
     CPU: 1 PID: 212 Comm: systemd-udevd Not tainted 5.6.0-rc2-next-20200219 #326
     videodev: Linux video capture interface: v2.00
     Hardware name: Samsung Exynos (Flattened Device Tree)
     PC is at exynos_dsi_probe+0x1f0/0x384 [exynosdrm]
     LR is at exynos_dsi_probe+0x1dc/0x384 [exynosdrm]
     ...
     Process systemd-udevd (pid: 212, stack limit = 0x(ptrval))
     ...
     [<bf03cf14>] (exynos_dsi_probe [exynosdrm]) from [<c09b1ca0>] (platform_drv_probe+0x6c/0xa4)
     [<c09b1ca0>] (platform_drv_probe) from [<c09afcb8>] (really_probe+0x210/0x350)
     [<c09afcb8>] (really_probe) from [<c09aff74>] (driver_probe_device+0x60/0x1a0)
     [<c09aff74>] (driver_probe_device) from [<c09b0254>] (device_driver_attach+0x58/0x60)
     [<c09b0254>] (device_driver_attach) from [<c09b02dc>] (__driver_attach+0x80/0xbc)
     [<c09b02dc>] (__driver_attach) from [<c09ade00>] (bus_for_each_dev+0x68/0xb4)
     [<c09ade00>] (bus_for_each_dev) from [<c09aefd8>] (bus_add_driver+0x130/0x1e8)
     [<c09aefd8>] (bus_add_driver) from [<c09b0d64>] (driver_register+0x78/0x110)
     [<c09b0d64>] (driver_register) from [<bf038558>] (exynos_drm_init+0xe8/0x11c [exynosdrm])
     [<bf038558>] (exynos_drm_init [exynosdrm]) from [<c0302fa8>] (do_one_initcall+0x50/0x220)
     [<c0302fa8>] (do_one_initcall) from [<c03dd02c>] (do_init_module+0x60/0x210)
     [<c03dd02c>] (do_init_module) from [<c03dbf44>] (load_module+0x1c0c/0x2310)
     [<c03dbf44>] (load_module) from [<c03dc85c>] (sys_finit_module+0xac/0xbc)
     [<c03dc85c>] (sys_finit_module) from [<c0301000>] (ret_fast_syscall+0x0/0x54)
     Exception stack(0xd979bfa8 to 0xd979bff0)
     ...
     ---[ end trace db16efe05faab470 ]---
    
    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
    Signed-off-by: Inki Dae <inki.dae@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit db5cffa22a5f7826957d7531250ddb548ad361e9
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date:   Thu Feb 27 08:06:37 2020 +0100

    drm/exynos: dsi: propagate error value and silence meaningless warning
    
    [ Upstream commit 0a9d1e3f3f038785ebc72d53f1c409d07f6b4ff5 ]
    
    Properly propagate error value from devm_regulator_bulk_get() and don't
    confuse user with meaningless warning about failure in getting regulators
    in case of deferred probe.
    
    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Inki Dae <inki.dae@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3dd8860bd399d16aa45720f178ce4fcd4ce21e90
Author: Thommy Jakobsson <thommyj@gmail.com>
Date:   Mon Feb 24 17:26:43 2020 +0100

    spi/zynqmp: remove entry that causes a cs glitch
    
    [ Upstream commit 5dd8304981ecffa77bb72b1c57c4be5dfe6cfae9 ]
    
    In the public interface for chipselect, there is always an entry
    commented as "Dummy generic FIFO entry" pushed down to the fifo right
    after the activate/deactivate command. The dummy entry is 0x0,
    irregardless if the intention was to activate or deactive the cs. This
    causes the cs line to glitch rather than beeing activated in the case
    when there was an activate command.
    
    This has been observed on oscilloscope, and have caused problems for at
    least one specific flash device type connected to the qspi port. After
    the change the glitch is gone and cs goes active when intended.
    
    The reason why this worked before (except for the glitch) was because
    when sending the actual data, the CS bits are once again set. Since
    most flashes uses mode 0, there is always a half clk period anyway for
    cs to clk active setup time. If someone would rely on timing from a
    chip_select call to a transfer_one, it would fail though.
    
    It is unknown why the dummy entry was there in the first place, git log
    seems to be of no help in this case. The reference manual gives no
    indication of the necessity of this. In fact the lower 8 bits are a
    setup (or hold in case of deactivate) time expressed in cycles. So this
    should not be needed to fulfill any setup/hold timings.
    
    Signed-off-by: Thommy Jakobsson <thommyj@gmail.com>
    Reviewed-by: Naga Sureshkumar Relli <naga.sureshkumar.relli@xilinx.com>
    Link: https://lore.kernel.org/r/20200224162643.29102-1-thommyj@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 99f0be68c1c4961c26638a6cc2636d6253e0fad9
Author: Kishon Vijay Abraham I <kishon@ti.com>
Date:   Tue Jan 28 12:11:47 2020 +0530

    ARM: dts: dra7: Add "dma-ranges" property to PCIe RC DT nodes
    
    [ Upstream commit 27f13774654ea6bd0b6fc9b97cce8d19e5735661 ]
    
    'dma-ranges' in a PCI bridge node does correctly set dma masks for PCI
    devices not described in the DT. Certain DRA7 platforms (e.g., DRA76)
    has RAM above 32-bit boundary (accessible with LPAE config) though the
    PCIe bridge will be able to access only 32-bits. Add 'dma-ranges'
    property in PCIe RC DT nodes to indicate the host bridge can access
    only 32 bits.
    
    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 30942cd983ab46ff0229a03050006a5133389064
Author: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Date:   Thu Feb 20 17:01:32 2020 +0530

    powerpc: Include .BTF section
    
    [ Upstream commit cb0cc635c7a9fa8a3a0f75d4d896721819c63add ]
    
    Selecting CONFIG_DEBUG_INFO_BTF results in the below warning from ld:
      ld: warning: orphan section `.BTF' from `.btf.vmlinux.bin.o' being placed in section `.BTF'
    
    Include .BTF section in vmlinux explicitly to fix the same.
    
    Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20200220113132.857132-1-naveen.n.rao@linux.vnet.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e0f5fa76696a990695e110deee83aa3f3efa0ab3
Author: Yuji Sasaki <sasakiy@chromium.org>
Date:   Fri Feb 14 13:13:40 2020 +0530

    spi: qup: call spi_qup_pm_resume_runtime before suspending
    
    [ Upstream commit 136b5cd2e2f97581ae560cff0db2a3b5369112da ]
    
    spi_qup_suspend() will cause synchronous external abort when
    runtime suspend is enabled and applied, as it tries to
    access SPI controller register while clock is already disabled
    in spi_qup_pm_suspend_runtime().
    
    Signed-off-by: Yuji sasaki <sasakiy@chromium.org>
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Link: https://lore.kernel.org/r/20200214074340.2286170-1-vkoul@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>