--- /dev/null
+From 24458b64cf444b0c2550c7b16d3cbe6c745a91d9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 4 Jun 2020 20:42:06 +0800
+Subject: ARM: imx5: add missing put_device() call in imx_suspend_alloc_ocram()
+
+From: yu kuai <yukuai3@huawei.com>
+
+[ Upstream commit 586745f1598ccf71b0a5a6df2222dee0a865954e ]
+
+if of_find_device_by_node() succeed, imx_suspend_alloc_ocram() doesn't
+have a corresponding put_device(). Thus add a jump target to fix the
+exception handling for this function implementation.
+
+Fixes: 1579c7b9fe01 ("ARM: imx53: Set DDR pins to high impedance when in suspend to RAM.")
+Signed-off-by: yu kuai <yukuai3@huawei.com>
+Signed-off-by: Shawn Guo <shawnguo@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/mach-imx/pm-imx5.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/arch/arm/mach-imx/pm-imx5.c b/arch/arm/mach-imx/pm-imx5.c
+index 868781fd460c7..14c630c899c5d 100644
+--- a/arch/arm/mach-imx/pm-imx5.c
++++ b/arch/arm/mach-imx/pm-imx5.c
+@@ -301,14 +301,14 @@ static int __init imx_suspend_alloc_ocram(
+ if (!ocram_pool) {
+ pr_warn("%s: ocram pool unavailable!\n", __func__);
+ ret = -ENODEV;
+- goto put_node;
++ goto put_device;
+ }
+
+ ocram_base = gen_pool_alloc(ocram_pool, size);
+ if (!ocram_base) {
+ pr_warn("%s: unable to alloc ocram!\n", __func__);
+ ret = -ENOMEM;
+- goto put_node;
++ goto put_device;
+ }
+
+ phys = gen_pool_virt_to_phys(ocram_pool, ocram_base);
+@@ -318,6 +318,8 @@ static int __init imx_suspend_alloc_ocram(
+ if (virt_out)
+ *virt_out = virt;
+
++put_device:
++ put_device(&pdev->dev);
+ put_node:
+ of_node_put(node);
+
+--
+2.25.1
+
--- /dev/null
+From b5aeb4311123a82326a3dc614b50fccf09eb1463 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 5 Jun 2020 09:41:49 +0800
+Subject: ata/libata: Fix usage of page address by page_address in
+ ata_scsi_mode_select_xlat function
+
+From: Ye Bin <yebin10@huawei.com>
+
+[ Upstream commit f650ef61e040bcb175dd8762164b00a5d627f20e ]
+
+BUG: KASAN: use-after-free in ata_scsi_mode_select_xlat+0x10bd/0x10f0
+drivers/ata/libata-scsi.c:4045
+Read of size 1 at addr ffff88803b8cd003 by task syz-executor.6/12621
+
+CPU: 1 PID: 12621 Comm: syz-executor.6 Not tainted 4.19.95 #1
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
+1.10.2-1ubuntu1 04/01/2014
+Call Trace:
+__dump_stack lib/dump_stack.c:77 [inline]
+dump_stack+0xac/0xee lib/dump_stack.c:118
+print_address_description+0x60/0x223 mm/kasan/report.c:253
+kasan_report_error mm/kasan/report.c:351 [inline]
+kasan_report mm/kasan/report.c:409 [inline]
+kasan_report.cold+0xae/0x2d8 mm/kasan/report.c:393
+ata_scsi_mode_select_xlat+0x10bd/0x10f0 drivers/ata/libata-scsi.c:4045
+ata_scsi_translate+0x2da/0x680 drivers/ata/libata-scsi.c:2035
+__ata_scsi_queuecmd drivers/ata/libata-scsi.c:4360 [inline]
+ata_scsi_queuecmd+0x2e4/0x790 drivers/ata/libata-scsi.c:4409
+scsi_dispatch_cmd+0x2ee/0x6c0 drivers/scsi/scsi_lib.c:1867
+scsi_queue_rq+0xfd7/0x1990 drivers/scsi/scsi_lib.c:2170
+blk_mq_dispatch_rq_list+0x1e1/0x19a0 block/blk-mq.c:1186
+blk_mq_do_dispatch_sched+0x147/0x3d0 block/blk-mq-sched.c:108
+blk_mq_sched_dispatch_requests+0x427/0x680 block/blk-mq-sched.c:204
+__blk_mq_run_hw_queue+0xbc/0x200 block/blk-mq.c:1308
+__blk_mq_delay_run_hw_queue+0x3c0/0x460 block/blk-mq.c:1376
+blk_mq_run_hw_queue+0x152/0x310 block/blk-mq.c:1413
+blk_mq_sched_insert_request+0x337/0x6c0 block/blk-mq-sched.c:397
+blk_execute_rq_nowait+0x124/0x320 block/blk-exec.c:64
+blk_execute_rq+0xc5/0x112 block/blk-exec.c:101
+sg_scsi_ioctl+0x3b0/0x6a0 block/scsi_ioctl.c:507
+sg_ioctl+0xd37/0x23f0 drivers/scsi/sg.c:1106
+vfs_ioctl fs/ioctl.c:46 [inline]
+file_ioctl fs/ioctl.c:501 [inline]
+do_vfs_ioctl+0xae6/0x1030 fs/ioctl.c:688
+ksys_ioctl+0x76/0xa0 fs/ioctl.c:705
+__do_sys_ioctl fs/ioctl.c:712 [inline]
+__se_sys_ioctl fs/ioctl.c:710 [inline]
+__x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:710
+do_syscall_64+0xa0/0x2e0 arch/x86/entry/common.c:293
+entry_SYSCALL_64_after_hwframe+0x44/0xa9
+RIP: 0033:0x45c479
+Code: ad b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89
+f7 48
+89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
+ff 0f
+83 7b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
+RSP: 002b:00007fb0e9602c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
+RAX: ffffffffffffffda RBX: 00007fb0e96036d4 RCX: 000000000045c479
+RDX: 0000000020000040 RSI: 0000000000000001 RDI: 0000000000000003
+RBP: 000000000076bfc0 R08: 0000000000000000 R09: 0000000000000000
+R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
+R13: 000000000000046d R14: 00000000004c6e1a R15: 000000000076bfcc
+
+Allocated by task 12577:
+set_track mm/kasan/kasan.c:460 [inline]
+kasan_kmalloc mm/kasan/kasan.c:553 [inline]
+kasan_kmalloc+0xbf/0xe0 mm/kasan/kasan.c:531
+__kmalloc+0xf3/0x1e0 mm/slub.c:3749
+kmalloc include/linux/slab.h:520 [inline]
+load_elf_phdrs+0x118/0x1b0 fs/binfmt_elf.c:441
+load_elf_binary+0x2de/0x4610 fs/binfmt_elf.c:737
+search_binary_handler fs/exec.c:1654 [inline]
+search_binary_handler+0x15c/0x4e0 fs/exec.c:1632
+exec_binprm fs/exec.c:1696 [inline]
+__do_execve_file.isra.0+0xf52/0x1a90 fs/exec.c:1820
+do_execveat_common fs/exec.c:1866 [inline]
+do_execve fs/exec.c:1883 [inline]
+__do_sys_execve fs/exec.c:1964 [inline]
+__se_sys_execve fs/exec.c:1959 [inline]
+__x64_sys_execve+0x8a/0xb0 fs/exec.c:1959
+do_syscall_64+0xa0/0x2e0 arch/x86/entry/common.c:293
+entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+Freed by task 12577:
+set_track mm/kasan/kasan.c:460 [inline]
+__kasan_slab_free+0x129/0x170 mm/kasan/kasan.c:521
+slab_free_hook mm/slub.c:1370 [inline]
+slab_free_freelist_hook mm/slub.c:1397 [inline]
+slab_free mm/slub.c:2952 [inline]
+kfree+0x8b/0x1a0 mm/slub.c:3904
+load_elf_binary+0x1be7/0x4610 fs/binfmt_elf.c:1118
+search_binary_handler fs/exec.c:1654 [inline]
+search_binary_handler+0x15c/0x4e0 fs/exec.c:1632
+exec_binprm fs/exec.c:1696 [inline]
+__do_execve_file.isra.0+0xf52/0x1a90 fs/exec.c:1820
+do_execveat_common fs/exec.c:1866 [inline]
+do_execve fs/exec.c:1883 [inline]
+__do_sys_execve fs/exec.c:1964 [inline]
+__se_sys_execve fs/exec.c:1959 [inline]
+__x64_sys_execve+0x8a/0xb0 fs/exec.c:1959
+do_syscall_64+0xa0/0x2e0 arch/x86/entry/common.c:293
+entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+The buggy address belongs to the object at ffff88803b8ccf00
+which belongs to the cache kmalloc-512 of size 512
+The buggy address is located 259 bytes inside of
+512-byte region [ffff88803b8ccf00, ffff88803b8cd100)
+The buggy address belongs to the page:
+page:ffffea0000ee3300 count:1 mapcount:0 mapping:ffff88806cc03080
+index:0xffff88803b8cc780 compound_mapcount: 0
+flags: 0x100000000008100(slab|head)
+raw: 0100000000008100 ffffea0001104080 0000000200000002 ffff88806cc03080
+raw: ffff88803b8cc780 00000000800c000b 00000001ffffffff 0000000000000000
+page dumped because: kasan: bad access detected
+
+Memory state around the buggy address:
+ffff88803b8ccf00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
+ffff88803b8ccf80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
+>ffff88803b8cd000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
+^
+ffff88803b8cd080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
+ffff88803b8cd100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
+
+You can refer to "https://www.lkml.org/lkml/2019/1/17/474" reproduce
+this error.
+
+The exception code is "bd_len = p[3];", "p" value is ffff88803b8cd000
+which belongs to the cache kmalloc-512 of size 512. The "page_address(sg_page(scsi_sglist(scmd)))"
+maybe from sg_scsi_ioctl function "buffer" which allocated by kzalloc, so "buffer"
+may not page aligned.
+This also looks completely buggy on highmem systems and really needs to use a
+kmap_atomic. --Christoph Hellwig
+To address above bugs, Paolo Bonzini advise to simpler to just make a char array
+of size CACHE_MPAGE_LEN+8+8+4-2(or just 64 to make it easy), use sg_copy_to_buffer
+to copy from the sglist into the buffer, and workthere.
+
+Signed-off-by: Ye Bin <yebin10@huawei.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/ata/libata-scsi.c | 9 ++++++---
+ 1 file changed, 6 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
+index c4f2b563c9f03..f4b38adb9d8a7 100644
+--- a/drivers/ata/libata-scsi.c
++++ b/drivers/ata/libata-scsi.c
+@@ -3967,12 +3967,13 @@ static unsigned int ata_scsi_mode_select_xlat(struct ata_queued_cmd *qc)
+ {
+ struct scsi_cmnd *scmd = qc->scsicmd;
+ const u8 *cdb = scmd->cmnd;
+- const u8 *p;
+ u8 pg, spg;
+ unsigned six_byte, pg_len, hdr_len, bd_len;
+ int len;
+ u16 fp = (u16)-1;
+ u8 bp = 0xff;
++ u8 buffer[64];
++ const u8 *p = buffer;
+
+ VPRINTK("ENTER\n");
+
+@@ -4006,12 +4007,14 @@ static unsigned int ata_scsi_mode_select_xlat(struct ata_queued_cmd *qc)
+ if (!scsi_sg_count(scmd) || scsi_sglist(scmd)->length < len)
+ goto invalid_param_len;
+
+- p = page_address(sg_page(scsi_sglist(scmd)));
+-
+ /* Move past header and block descriptors. */
+ if (len < hdr_len)
+ goto invalid_param_len;
+
++ if (!sg_copy_to_buffer(scsi_sglist(scmd), scsi_sg_count(scmd),
++ buffer, sizeof(buffer)))
++ goto invalid_param_len;
++
+ if (six_byte)
+ bd_len = p[3];
+ else
+--
+2.25.1
+
--- /dev/null
+From a82ef486d5bdceb5000fae01dd43d92858f03150 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 5 Jun 2020 16:58:36 +0200
+Subject: blktrace: break out of blktrace setup on concurrent calls
+
+From: Luis Chamberlain <mcgrof@kernel.org>
+
+[ Upstream commit 1b0b283648163dae2a214ca28ed5a99f62a77319 ]
+
+We use one blktrace per request_queue, that means one per the entire
+disk. So we cannot run one blktrace on say /dev/vda and then /dev/vda1,
+or just two calls on /dev/vda.
+
+We check for concurrent setup only at the very end of the blktrace setup though.
+
+If we try to run two concurrent blktraces on the same block device the
+second one will fail, and the first one seems to go on. However when
+one tries to kill the first one one will see things like this:
+
+The kernel will show these:
+
+```
+debugfs: File 'dropped' in directory 'nvme1n1' already present!
+debugfs: File 'msg' in directory 'nvme1n1' already present!
+debugfs: File 'trace0' in directory 'nvme1n1' already present!
+``
+
+And userspace just sees this error message for the second call:
+
+```
+blktrace /dev/nvme1n1
+BLKTRACESETUP(2) /dev/nvme1n1 failed: 5/Input/output error
+```
+
+The first userspace process #1 will also claim that the files
+were taken underneath their nose as well. The files are taken
+away form the first process given that when the second blktrace
+fails, it will follow up with a BLKTRACESTOP and BLKTRACETEARDOWN.
+This means that even if go-happy process #1 is waiting for blktrace
+data, we *have* been asked to take teardown the blktrace.
+
+This can easily be reproduced with break-blktrace [0] run_0005.sh test.
+
+Just break out early if we know we're already going to fail, this will
+prevent trying to create the files all over again, which we know still
+exist.
+
+[0] https://github.com/mcgrof/break-blktrace
+
+Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
+Signed-off-by: Jan Kara <jack@suse.cz>
+Reviewed-by: Bart Van Assche <bvanassche@acm.org>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/trace/blktrace.c | 13 +++++++++++++
+ 1 file changed, 13 insertions(+)
+
+diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
+index 6d3b432a748a6..88eb9261c7b5c 100644
+--- a/kernel/trace/blktrace.c
++++ b/kernel/trace/blktrace.c
+@@ -15,6 +15,9 @@
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
++
++#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
++
+ #include <linux/kernel.h>
+ #include <linux/blkdev.h>
+ #include <linux/blktrace_api.h>
+@@ -481,6 +484,16 @@ int do_blk_trace_setup(struct request_queue *q, char *name, dev_t dev,
+ */
+ strreplace(buts->name, '/', '_');
+
++ /*
++ * bdev can be NULL, as with scsi-generic, this is a helpful as
++ * we can be.
++ */
++ if (q->blk_trace) {
++ pr_warn("Concurrent blktraces are not allowed on %s\n",
++ buts->name);
++ return -EBUSY;
++ }
++
+ bt = kzalloc(sizeof(*bt), GFP_KERNEL);
+ if (!bt)
+ return -ENOMEM;
+--
+2.25.1
+
--- /dev/null
+From a9b4a6ee6182fcc8d425adf40b200beae8236139 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 28 May 2020 13:38:04 -0500
+Subject: efi/esrt: Fix reference count leak in esre_create_sysfs_entry.
+
+From: Qiushi Wu <wu000273@umn.edu>
+
+[ Upstream commit 4ddf4739be6e375116c375f0a68bf3893ffcee21 ]
+
+kobject_init_and_add() takes reference even when it fails.
+If this function returns an error, kobject_put() must be called to
+properly clean up the memory associated with the object. Previous
+commit "b8eb718348b8" fixed a similar problem.
+
+Fixes: 0bb549052d33 ("efi: Add esrt support")
+Signed-off-by: Qiushi Wu <wu000273@umn.edu>
+Link: https://lore.kernel.org/r/20200528183804.4497-1-wu000273@umn.edu
+Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/firmware/efi/esrt.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/firmware/efi/esrt.c b/drivers/firmware/efi/esrt.c
+index 241dd7c63d2c8..481b2f0a190b0 100644
+--- a/drivers/firmware/efi/esrt.c
++++ b/drivers/firmware/efi/esrt.c
+@@ -180,7 +180,7 @@ static int esre_create_sysfs_entry(void *esre, int entry_num)
+ rc = kobject_init_and_add(&entry->kobj, &esre1_ktype, NULL,
+ "entry%d", entry_num);
+ if (rc) {
+- kfree(entry);
++ kobject_put(&entry->kobj);
+ return rc;
+ }
+ }
+--
+2.25.1
+
--- /dev/null
+From 3bdfdd47a6cc61a7fad85b34f4e603df8f918c41 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 14 Jun 2020 23:43:40 +0900
+Subject: kbuild: improve cc-option to clean up all temporary files
+
+From: Masahiro Yamada <masahiroy@kernel.org>
+
+[ Upstream commit f2f02ebd8f3833626642688b2d2c6a7b3c141fa9 ]
+
+When cc-option and friends evaluate compiler flags, the temporary file
+$$TMP is created as an output object, and automatically cleaned up.
+The actual file path of $$TMP is .<pid>.tmp, here <pid> is the process
+ID of $(shell ...) invoked from cc-option. (Please note $$$$ is the
+escape sequence of $$).
+
+Such garbage files are cleaned up in most cases, but some compiler flags
+create additional output files.
+
+For example, -gsplit-dwarf creates a .dwo file.
+
+When CONFIG_DEBUG_INFO_SPLIT=y, you will see a bunch of .<pid>.dwo files
+left in the top of build directories. You may not notice them unless you
+do 'ls -a', but the garbage files will increase every time you run 'make'.
+
+This commit changes the temporary object path to .tmp_<pid>/tmp, and
+removes .tmp_<pid> directory when exiting. Separate build artifacts such
+as *.dwo will be cleaned up all together because their file paths are
+usually determined based on the base name of the object.
+
+Another example is -ftest-coverage, which outputs the coverage data into
+<base-name-of-object>.gcno
+
+Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ scripts/Kbuild.include | 11 ++++++-----
+ 1 file changed, 6 insertions(+), 5 deletions(-)
+
+diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
+index 558dea61db114..1920b9e2d2514 100644
+--- a/scripts/Kbuild.include
++++ b/scripts/Kbuild.include
+@@ -82,20 +82,21 @@ cc-cross-prefix = \
+ fi)))
+
+ # output directory for tests below
+-TMPOUT := $(if $(KBUILD_EXTMOD),$(firstword $(KBUILD_EXTMOD))/)
++TMPOUT = $(if $(KBUILD_EXTMOD),$(firstword $(KBUILD_EXTMOD))/).tmp_$$$$
+
+ # try-run
+ # Usage: option = $(call try-run, $(CC)...-o "$$TMP",option-ok,otherwise)
+ # Exit code chooses option. "$$TMP" is can be used as temporary file and
+ # is automatically cleaned up.
+ try-run = $(shell set -e; \
+- TMP="$(TMPOUT).$$$$.tmp"; \
+- TMPO="$(TMPOUT).$$$$.o"; \
++ TMP=$(TMPOUT)/tmp; \
++ TMPO=$(TMPOUT)/tmp.o; \
++ mkdir -p $(TMPOUT); \
++ trap "rm -rf $(TMPOUT)" EXIT; \
+ if ($(1)) >/dev/null 2>&1; \
+ then echo "$(2)"; \
+ else echo "$(3)"; \
+- fi; \
+- rm -f "$$TMP" "$$TMPO")
++ fi)
+
+ # as-option
+ # Usage: cflags-y += $(call as-option,-Wa$(comma)-isa=foo,)
+--
+2.25.1
+
--- /dev/null
+From 377c412032d44b2b8c4d1f5eb943c0d0ac008f08 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 15 Jun 2020 11:50:29 -0400
+Subject: net: alx: fix race condition in alx_remove
+
+From: Zekun Shen <bruceshenzk@gmail.com>
+
+[ Upstream commit e89df5c4322c1bf495f62d74745895b5fd2a4393 ]
+
+There is a race condition exist during termination. The path is
+alx_stop and then alx_remove. An alx_schedule_link_check could be called
+before alx_stop by interrupt handler and invoke alx_link_check later.
+Alx_stop frees the napis, and alx_remove cancels any pending works.
+If any of the work is scheduled before termination and invoked before
+alx_remove, a null-ptr-deref occurs because both expect alx->napis[i].
+
+This patch fix the race condition by moving cancel_work_sync functions
+before alx_free_napis inside alx_stop. Because interrupt handler can call
+alx_schedule_link_check again, alx_free_irq is moved before
+cancel_work_sync calls too.
+
+Signed-off-by: Zekun Shen <bruceshenzk@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/atheros/alx/main.c | 9 +++++----
+ 1 file changed, 5 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/net/ethernet/atheros/alx/main.c b/drivers/net/ethernet/atheros/alx/main.c
+index c0f84b73574d8..2a5bb1012385e 100644
+--- a/drivers/net/ethernet/atheros/alx/main.c
++++ b/drivers/net/ethernet/atheros/alx/main.c
+@@ -1056,8 +1056,12 @@ static int __alx_open(struct alx_priv *alx, bool resume)
+
+ static void __alx_stop(struct alx_priv *alx)
+ {
+- alx_halt(alx);
+ alx_free_irq(alx);
++
++ cancel_work_sync(&alx->link_check_wk);
++ cancel_work_sync(&alx->reset_wk);
++
++ alx_halt(alx);
+ alx_free_rings(alx);
+ }
+
+@@ -1659,9 +1663,6 @@ static void alx_remove(struct pci_dev *pdev)
+ struct alx_priv *alx = pci_get_drvdata(pdev);
+ struct alx_hw *hw = &alx->hw;
+
+- cancel_work_sync(&alx->link_check_wk);
+- cancel_work_sync(&alx->reset_wk);
+-
+ /* restore permanent mac address */
+ alx_set_macaddr(hw, hw->perm_addr);
+
+--
+2.25.1
+
--- /dev/null
+From 76f1cf591d279492646ae1b10d54e4b490bc9167 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 23 Jun 2020 16:51:33 +0300
+Subject: net: qed: fix excessive QM ILT lines consumption
+
+From: Alexander Lobakin <alobakin@marvell.com>
+
+[ Upstream commit d434d02f7e7c24c721365fd594ed781acb18e0da ]
+
+This is likely a copy'n'paste mistake. The amount of ILT lines to
+reserve for a single VF was being multiplied by the total VFs count.
+This led to a huge redundancy in reservation and potential lines
+drainouts.
+
+Fixes: 1408cc1fa48c ("qed: Introduce VFs")
+Signed-off-by: Alexander Lobakin <alobakin@marvell.com>
+Signed-off-by: Igor Russkikh <irusskikh@marvell.com>
+Signed-off-by: Michal Kalderon <michal.kalderon@marvell.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/qlogic/qed/qed_cxt.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/qlogic/qed/qed_cxt.c b/drivers/net/ethernet/qlogic/qed/qed_cxt.c
+index f1956c4d02a01..d026da36e47e6 100644
+--- a/drivers/net/ethernet/qlogic/qed/qed_cxt.c
++++ b/drivers/net/ethernet/qlogic/qed/qed_cxt.c
+@@ -339,7 +339,7 @@ static void qed_cxt_qm_iids(struct qed_hwfn *p_hwfn,
+ vf_tids += segs[NUM_TASK_PF_SEGMENTS].count;
+ }
+
+- iids->vf_cids += vf_cids * p_mngr->vf_count;
++ iids->vf_cids = vf_cids;
+ iids->tids += vf_tids * p_mngr->vf_count;
+
+ DP_VERBOSE(p_hwfn, QED_MSG_ILT,
+--
+2.25.1
+
--- /dev/null
+From 68b92e1333c98d90a8b9144708c1784c6a337188 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 23 Jun 2020 16:51:29 +0300
+Subject: net: qed: fix left elements count calculation
+
+From: Alexander Lobakin <alobakin@marvell.com>
+
+[ Upstream commit 97dd1abd026ae4e6a82fa68645928404ad483409 ]
+
+qed_chain_get_element_left{,_u32} returned 0 when the difference
+between producer and consumer page count was equal to the total
+page count.
+Fix this by conditional expanding of producer value (vs
+unconditional). This allowed to eliminate normalizaton against
+total page count, which was the cause of this bug.
+
+Misc: replace open-coded constants with common defines.
+
+Fixes: a91eb52abb50 ("qed: Revisit chain implementation")
+Signed-off-by: Alexander Lobakin <alobakin@marvell.com>
+Signed-off-by: Igor Russkikh <irusskikh@marvell.com>
+Signed-off-by: Michal Kalderon <michal.kalderon@marvell.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/linux/qed/qed_chain.h | 26 ++++++++++++++++----------
+ 1 file changed, 16 insertions(+), 10 deletions(-)
+
+diff --git a/include/linux/qed/qed_chain.h b/include/linux/qed/qed_chain.h
+index 72d88cf3ca25b..5a215da57b55a 100644
+--- a/include/linux/qed/qed_chain.h
++++ b/include/linux/qed/qed_chain.h
+@@ -155,28 +155,34 @@ static inline u32 qed_chain_get_cons_idx_u32(struct qed_chain *p_chain)
+
+ static inline u16 qed_chain_get_elem_left(struct qed_chain *p_chain)
+ {
++ u16 elem_per_page = p_chain->elem_per_page;
++ u32 prod = p_chain->u.chain16.prod_idx;
++ u32 cons = p_chain->u.chain16.cons_idx;
+ u16 used;
+
+- used = (u16) (((u32)0x10000 +
+- (u32)p_chain->u.chain16.prod_idx) -
+- (u32)p_chain->u.chain16.cons_idx);
++ if (prod < cons)
++ prod += (u32)U16_MAX + 1;
++
++ used = (u16)(prod - cons);
+ if (p_chain->mode == QED_CHAIN_MODE_NEXT_PTR)
+- used -= p_chain->u.chain16.prod_idx / p_chain->elem_per_page -
+- p_chain->u.chain16.cons_idx / p_chain->elem_per_page;
++ used -= prod / elem_per_page - cons / elem_per_page;
+
+ return (u16)(p_chain->capacity - used);
+ }
+
+ static inline u32 qed_chain_get_elem_left_u32(struct qed_chain *p_chain)
+ {
++ u16 elem_per_page = p_chain->elem_per_page;
++ u64 prod = p_chain->u.chain32.prod_idx;
++ u64 cons = p_chain->u.chain32.cons_idx;
+ u32 used;
+
+- used = (u32) (((u64)0x100000000ULL +
+- (u64)p_chain->u.chain32.prod_idx) -
+- (u64)p_chain->u.chain32.cons_idx);
++ if (prod < cons)
++ prod += (u64)U32_MAX + 1;
++
++ used = (u32)(prod - cons);
+ if (p_chain->mode == QED_CHAIN_MODE_NEXT_PTR)
+- used -= p_chain->u.chain32.prod_idx / p_chain->elem_per_page -
+- p_chain->u.chain32.cons_idx / p_chain->elem_per_page;
++ used -= (u32)(prod / elem_per_page - cons / elem_per_page);
+
+ return p_chain->capacity - used;
+ }
+--
+2.25.1
+
--- /dev/null
+From 5058bdb75ba472871ffd489e97e0f7745aa30e72 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 23 Jun 2020 16:51:32 +0300
+Subject: net: qed: fix NVMe login fails over VFs
+
+From: Alexander Lobakin <alobakin@marvell.com>
+
+[ Upstream commit ccd7c7ce167a21dbf2b698ffcf00f11d96d44f9b ]
+
+25ms sleep cycles in waiting for PF response are excessive and may lead
+to different timeout failures.
+
+Start to wait with short udelays, and in most cases polling will end
+here. If the time was not sufficient, switch to msleeps.
+usleep_range() may go far beyond 100us depending on platform and tick
+configuration, hence atomic udelays for consistency.
+
+Also add explicit DMA barriers since 'done' always comes from a shared
+request-response DMA pool, and note that in the comment nearby.
+
+Fixes: 1408cc1fa48c ("qed: Introduce VFs")
+Signed-off-by: Alexander Lobakin <alobakin@marvell.com>
+Signed-off-by: Igor Russkikh <irusskikh@marvell.com>
+Signed-off-by: Michal Kalderon <michal.kalderon@marvell.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/qlogic/qed/qed_vf.c | 23 ++++++++++++++++++-----
+ 1 file changed, 18 insertions(+), 5 deletions(-)
+
+diff --git a/drivers/net/ethernet/qlogic/qed/qed_vf.c b/drivers/net/ethernet/qlogic/qed/qed_vf.c
+index cf34908ec8e1f..170243d3276b9 100644
+--- a/drivers/net/ethernet/qlogic/qed/qed_vf.c
++++ b/drivers/net/ethernet/qlogic/qed/qed_vf.c
+@@ -57,12 +57,17 @@ static void qed_vf_pf_req_end(struct qed_hwfn *p_hwfn, int req_status)
+ mutex_unlock(&(p_hwfn->vf_iov_info->mutex));
+ }
+
++#define QED_VF_CHANNEL_USLEEP_ITERATIONS 90
++#define QED_VF_CHANNEL_USLEEP_DELAY 100
++#define QED_VF_CHANNEL_MSLEEP_ITERATIONS 10
++#define QED_VF_CHANNEL_MSLEEP_DELAY 25
++
+ static int qed_send_msg2pf(struct qed_hwfn *p_hwfn, u8 *done, u32 resp_size)
+ {
+ union vfpf_tlvs *p_req = p_hwfn->vf_iov_info->vf2pf_request;
+ struct ustorm_trigger_vf_zone trigger;
+ struct ustorm_vf_zone *zone_data;
+- int rc = 0, time = 100;
++ int iter, rc = 0;
+
+ zone_data = (struct ustorm_vf_zone *)PXP_VF_BAR0_START_USDM_ZONE_B;
+
+@@ -102,11 +107,19 @@ static int qed_send_msg2pf(struct qed_hwfn *p_hwfn, u8 *done, u32 resp_size)
+ REG_WR(p_hwfn, (uintptr_t)&zone_data->trigger, *((u32 *)&trigger));
+
+ /* When PF would be done with the response, it would write back to the
+- * `done' address. Poll until then.
++ * `done' address from a coherent DMA zone. Poll until then.
+ */
+- while ((!*done) && time) {
+- msleep(25);
+- time--;
++
++ iter = QED_VF_CHANNEL_USLEEP_ITERATIONS;
++ while (!*done && iter--) {
++ udelay(QED_VF_CHANNEL_USLEEP_DELAY);
++ dma_rmb();
++ }
++
++ iter = QED_VF_CHANNEL_MSLEEP_ITERATIONS;
++ while (!*done && iter--) {
++ msleep(QED_VF_CHANNEL_MSLEEP_DELAY);
++ dma_rmb();
+ }
+
+ if (!*done) {
+--
+2.25.1
+
--- /dev/null
+From 75be6624ea2b6f8f28c9dada4a8a7acb170f168a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 10 Jun 2020 21:51:11 +0100
+Subject: netfilter: ipset: fix unaligned atomic access
+
+From: Russell King <rmk+kernel@armlinux.org.uk>
+
+[ Upstream commit 715028460082d07a7ec6fcd87b14b46784346a72 ]
+
+When using ip_set with counters and comment, traffic causes the kernel
+to panic on 32-bit ARM:
+
+Alignment trap: not handling instruction e1b82f9f at [<bf01b0dc>]
+Unhandled fault: alignment exception (0x221) at 0xea08133c
+PC is at ip_set_match_extensions+0xe0/0x224 [ip_set]
+
+The problem occurs when we try to update the 64-bit counters - the
+faulting address above is not 64-bit aligned. The problem occurs
+due to the way elements are allocated, for example:
+
+ set->dsize = ip_set_elem_len(set, tb, 0, 0);
+ map = ip_set_alloc(sizeof(*map) + elements * set->dsize);
+
+If the element has a requirement for a member to be 64-bit aligned,
+and set->dsize is not a multiple of 8, but is a multiple of four,
+then every odd numbered elements will be misaligned - and hitting
+an atomic64_add() on that element will cause the kernel to panic.
+
+ip_set_elem_len() must return a size that is rounded to the maximum
+alignment of any extension field stored in the element. This change
+ensures that is the case.
+
+Fixes: 95ad1f4a9358 ("netfilter: ipset: Fix extension alignment")
+Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
+Acked-by: Jozsef Kadlecsik <kadlec@netfilter.org>
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/netfilter/ipset/ip_set_core.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/net/netfilter/ipset/ip_set_core.c b/net/netfilter/ipset/ip_set_core.c
+index f64660e9ff879..511496278262c 100644
+--- a/net/netfilter/ipset/ip_set_core.c
++++ b/net/netfilter/ipset/ip_set_core.c
+@@ -379,6 +379,8 @@ ip_set_elem_len(struct ip_set *set, struct nlattr *tb[], size_t len,
+ for (id = 0; id < IPSET_EXT_ID_MAX; id++) {
+ if (!add_extension(id, cadt_flags, tb))
+ continue;
++ if (align < ip_set_extensions[id].align)
++ align = ip_set_extensions[id].align;
+ len = ALIGN(len, ip_set_extensions[id].align);
+ set->offset[id] = len;
+ set->extensions |= ip_set_extensions[id].type;
+--
+2.25.1
+
--- /dev/null
+From c19dbf12547e10e4dab925491cb123f9b6a4f681 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 12 Jun 2020 14:38:24 +0800
+Subject: RDMA/mad: Fix possible memory leak in ib_mad_post_receive_mads()
+
+From: Fan Guo <guofan5@huawei.com>
+
+[ Upstream commit a17f4bed811c60712d8131883cdba11a105d0161 ]
+
+If ib_dma_mapping_error() returns non-zero value,
+ib_mad_post_receive_mads() will jump out of loops and return -ENOMEM
+without freeing mad_priv. Fix this memory-leak problem by freeing mad_priv
+in this case.
+
+Fixes: 2c34e68f4261 ("IB/mad: Check and handle potential DMA mapping errors")
+Link: https://lore.kernel.org/r/20200612063824.180611-1-guofan5@huawei.com
+Signed-off-by: Fan Guo <guofan5@huawei.com>
+Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/infiniband/core/mad.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/infiniband/core/mad.c b/drivers/infiniband/core/mad.c
+index a1f059a9c7519..f03e10517accd 100644
+--- a/drivers/infiniband/core/mad.c
++++ b/drivers/infiniband/core/mad.c
+@@ -2885,6 +2885,7 @@ static int ib_mad_post_receive_mads(struct ib_mad_qp_info *qp_info,
+ DMA_FROM_DEVICE);
+ if (unlikely(ib_dma_mapping_error(qp_info->port_priv->device,
+ sg_list.addr))) {
++ kfree(mad_priv);
+ ret = -ENOMEM;
+ break;
+ }
+--
+2.25.1
+
--- /dev/null
+From e0490cf821baf685be8e9cdb75898a1c3b072d4c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 9 Mar 2020 16:44:50 +0100
+Subject: s390/ptrace: fix setting syscall number
+
+From: Sven Schnelle <svens@linux.ibm.com>
+
+[ Upstream commit 873e5a763d604c32988c4a78913a8dab3862d2f9 ]
+
+When strace wants to update the syscall number, it sets GPR2
+to the desired number and updates the GPR via PTRACE_SETREGSET.
+It doesn't update regs->int_code which would cause the old syscall
+executed on syscall restart. As we cannot change the ptrace ABI and
+don't have a field for the interruption code, check whether the tracee
+is in a syscall and the last instruction was svc. In that case assume
+that the tracer wants to update the syscall number and copy the GPR2
+value to regs->int_code.
+
+Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
+Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/s390/kernel/ptrace.c | 31 ++++++++++++++++++++++++++++++-
+ 1 file changed, 30 insertions(+), 1 deletion(-)
+
+diff --git a/arch/s390/kernel/ptrace.c b/arch/s390/kernel/ptrace.c
+index fc2974b929c37..ee757d6f585e6 100644
+--- a/arch/s390/kernel/ptrace.c
++++ b/arch/s390/kernel/ptrace.c
+@@ -308,6 +308,25 @@ static inline void __poke_user_per(struct task_struct *child,
+ child->thread.per_user.end = data;
+ }
+
++static void fixup_int_code(struct task_struct *child, addr_t data)
++{
++ struct pt_regs *regs = task_pt_regs(child);
++ int ilc = regs->int_code >> 16;
++ u16 insn;
++
++ if (ilc > 6)
++ return;
++
++ if (ptrace_access_vm(child, regs->psw.addr - (regs->int_code >> 16),
++ &insn, sizeof(insn), FOLL_FORCE) != sizeof(insn))
++ return;
++
++ /* double check that tracee stopped on svc instruction */
++ if ((insn >> 8) != 0xa)
++ return;
++
++ regs->int_code = 0x20000 | (data & 0xffff);
++}
+ /*
+ * Write a word to the user area of a process at location addr. This
+ * operation does have an additional problem compared to peek_user.
+@@ -319,7 +338,9 @@ static int __poke_user(struct task_struct *child, addr_t addr, addr_t data)
+ struct user *dummy = NULL;
+ addr_t offset;
+
++
+ if (addr < (addr_t) &dummy->regs.acrs) {
++ struct pt_regs *regs = task_pt_regs(child);
+ /*
+ * psw and gprs are stored on the stack
+ */
+@@ -337,7 +358,11 @@ static int __poke_user(struct task_struct *child, addr_t addr, addr_t data)
+ /* Invalid addressing mode bits */
+ return -EINVAL;
+ }
+- *(addr_t *)((addr_t) &task_pt_regs(child)->psw + addr) = data;
++
++ if (test_pt_regs_flag(regs, PIF_SYSCALL) &&
++ addr == offsetof(struct user, regs.gprs[2]))
++ fixup_int_code(child, data);
++ *(addr_t *)((addr_t) ®s->psw + addr) = data;
+
+ } else if (addr < (addr_t) (&dummy->regs.orig_gpr2)) {
+ /*
+@@ -703,6 +728,10 @@ static int __poke_user_compat(struct task_struct *child,
+ regs->psw.mask = (regs->psw.mask & ~PSW_MASK_BA) |
+ (__u64)(tmp & PSW32_ADDR_AMODE);
+ } else {
++
++ if (test_pt_regs_flag(regs, PIF_SYSCALL) &&
++ addr == offsetof(struct compat_user, regs.gprs[2]))
++ fixup_int_code(child, data);
+ /* gpr 0-15 */
+ *(__u32*)((addr_t) ®s->psw + addr*2 + 4) = tmp;
+ }
+--
+2.25.1
+
--- /dev/null
+From b7bf6d47694b32f078b5128a997cff41e06861bb Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 19 Nov 2018 16:32:01 +0100
+Subject: sched/core: Fix PI boosting between RT and DEADLINE tasks
+
+From: Juri Lelli <juri.lelli@redhat.com>
+
+[ Upstream commit 740797ce3a124b7dd22b7fb832d87bc8fba1cf6f ]
+
+syzbot reported the following warning:
+
+ WARNING: CPU: 1 PID: 6351 at kernel/sched/deadline.c:628
+ enqueue_task_dl+0x22da/0x38a0 kernel/sched/deadline.c:1504
+
+At deadline.c:628 we have:
+
+ 623 static inline void setup_new_dl_entity(struct sched_dl_entity *dl_se)
+ 624 {
+ 625 struct dl_rq *dl_rq = dl_rq_of_se(dl_se);
+ 626 struct rq *rq = rq_of_dl_rq(dl_rq);
+ 627
+ 628 WARN_ON(dl_se->dl_boosted);
+ 629 WARN_ON(dl_time_before(rq_clock(rq), dl_se->deadline));
+ [...]
+ }
+
+Which means that setup_new_dl_entity() has been called on a task
+currently boosted. This shouldn't happen though, as setup_new_dl_entity()
+is only called when the 'dynamic' deadline of the new entity
+is in the past w.r.t. rq_clock and boosted tasks shouldn't verify this
+condition.
+
+Digging through the PI code I noticed that what above might in fact happen
+if an RT tasks blocks on an rt_mutex hold by a DEADLINE task. In the
+first branch of boosting conditions we check only if a pi_task 'dynamic'
+deadline is earlier than mutex holder's and in this case we set mutex
+holder to be dl_boosted. However, since RT 'dynamic' deadlines are only
+initialized if such tasks get boosted at some point (or if they become
+DEADLINE of course), in general RT 'dynamic' deadlines are usually equal
+to 0 and this verifies the aforementioned condition.
+
+Fix it by checking that the potential donor task is actually (even if
+temporary because in turn boosted) running at DEADLINE priority before
+using its 'dynamic' deadline value.
+
+Fixes: 2d3d891d3344 ("sched/deadline: Add SCHED_DEADLINE inheritance logic")
+Reported-by: syzbot+119ba87189432ead09b4@syzkaller.appspotmail.com
+Signed-off-by: Juri Lelli <juri.lelli@redhat.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Reviewed-by: Daniel Bristot de Oliveira <bristot@redhat.com>
+Tested-by: Daniel Wagner <dwagner@suse.de>
+Link: https://lkml.kernel.org/r/20181119153201.GB2119@localhost.localdomain
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/sched/core.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/kernel/sched/core.c b/kernel/sched/core.c
+index 82cec9a666e7b..870d802c46f90 100644
+--- a/kernel/sched/core.c
++++ b/kernel/sched/core.c
+@@ -3697,7 +3697,8 @@ void rt_mutex_setprio(struct task_struct *p, int prio)
+ if (dl_prio(prio)) {
+ struct task_struct *pi_task = rt_mutex_get_top_task(p);
+ if (!dl_prio(p->normal_prio) ||
+- (pi_task && dl_entity_preempt(&pi_task->dl, &p->dl))) {
++ (pi_task && dl_prio(pi_task->prio) &&
++ dl_entity_preempt(&pi_task->dl, &p->dl))) {
+ p->dl.dl_boosted = 1;
+ queue_flag |= ENQUEUE_REPLENISH;
+ } else
+--
+2.25.1
+
xhci-poll-for-u0-after-disabling-usb2-lpm.patch
cifs-smb3-fix-data-inconsistent-when-punch-hole.patch
cifs-smb3-fix-data-inconsistent-when-zero-file-range.patch
+efi-esrt-fix-reference-count-leak-in-esre_create_sys.patch
+rdma-mad-fix-possible-memory-leak-in-ib_mad_post_rec.patch
+net-qed-fix-left-elements-count-calculation.patch
+net-qed-fix-nvme-login-fails-over-vfs.patch
+net-qed-fix-excessive-qm-ilt-lines-consumption.patch
+arm-imx5-add-missing-put_device-call-in-imx_suspend_.patch
+usb-gadget-udc-potential-oops-in-error-handling-code.patch
+netfilter-ipset-fix-unaligned-atomic-access.patch
+sched-core-fix-pi-boosting-between-rt-and-deadline-t.patch
+ata-libata-fix-usage-of-page-address-by-page_address.patch
+net-alx-fix-race-condition-in-alx_remove.patch
+s390-ptrace-fix-setting-syscall-number.patch
+kbuild-improve-cc-option-to-clean-up-all-temporary-f.patch
+blktrace-break-out-of-blktrace-setup-on-concurrent-c.patch
--- /dev/null
+From 888cfdcca44bab6cbb52f82949b2841a6f43e04a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 15 Jun 2020 14:27:19 +0300
+Subject: usb: gadget: udc: Potential Oops in error handling code
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+[ Upstream commit e55f3c37cb8d31c7e301f46396b2ac6a19eb3a7c ]
+
+If this is in "transceiver" mode the the ->qwork isn't required and is
+a NULL pointer. This can lead to a NULL dereference when we call
+destroy_workqueue(udc->qwork).
+
+Fixes: 3517c31a8ece ("usb: gadget: mv_udc: use devm_xxx for probe")
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Signed-off-by: Felipe Balbi <balbi@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/usb/gadget/udc/mv_udc_core.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/usb/gadget/udc/mv_udc_core.c b/drivers/usb/gadget/udc/mv_udc_core.c
+index ce73b3552269f..8700db903382d 100644
+--- a/drivers/usb/gadget/udc/mv_udc_core.c
++++ b/drivers/usb/gadget/udc/mv_udc_core.c
+@@ -2317,7 +2317,8 @@ static int mv_udc_probe(struct platform_device *pdev)
+ return 0;
+
+ err_create_workqueue:
+- destroy_workqueue(udc->qwork);
++ if (udc->qwork)
++ destroy_workqueue(udc->qwork);
+ err_destroy_dma:
+ dma_pool_destroy(udc->dtd_pool);
+ err_free_dma:
+--
+2.25.1
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
