commit 5e2cfee1b25c94aa357fca06f30d3be073c36d16 Author: Greg Kroah-Hartman Date: Tue Dec 17 20:08:41 2019 +0100 Linux 5.3.17 commit aadb4f25f7d4c364a9ca7ed521d4859b0b54412f Author: Robert Richter Date: Thu Nov 21 21:36:57 2019 +0000 EDAC/ghes: Do not warn when incrementing refcount on 0 [ Upstream commit 16214bd9e43a31683a7073664b000029bba00354 ] The following warning from the refcount framework is seen during ghes initialization: EDAC MC0: Giving out device to module ghes_edac.c controller ghes_edac: DEV ghes (INTERRUPT) ------------[ cut here ]------------ refcount_t: increment on 0; use-after-free. WARNING: CPU: 36 PID: 1 at lib/refcount.c:156 refcount_inc_checked [...] Call trace: refcount_inc_checked ghes_edac_register ghes_probe ... It warns if the refcount is incremented from zero. This warning is reasonable as a kernel object is typically created with a refcount of one and freed once the refcount is zero. Afterwards the object would be "used-after-free". For GHES, the refcount is initialized with zero, and that is why this message is seen when initializing the first instance. However, whenever the refcount is zero, the device will be allocated and registered. Since the ghes_reg_mutex protects the refcount and serializes allocation and freeing of ghes devices, a use-after-free cannot happen here. Instead of using refcount_inc() for the first instance, use refcount_set(). This can be used here because the refcount is zero at this point and can not change due to its protection by the mutex. Fixes: 23f61b9fc5cc ("EDAC/ghes: Fix locking and memory barrier issues") Reported-by: John Garry Signed-off-by: Robert Richter Signed-off-by: Borislav Petkov Tested-by: John Garry Cc: Cc: James Morse Cc: Cc: linux-edac Cc: Mauro Carvalho Chehab Cc: Cc: Tony Luck Cc: Link: https://lkml.kernel.org/r/20191121213628.21244-1-rrichter@marvell.com Signed-off-by: Sasha Levin commit 9d2710fe8bf0b62996f4c8e0edd0ade0d3a34127 Author: Andreas Gruenbacher Date: Mon Dec 9 20:11:14 2019 +0100 block: fix "check bi_size overflow before merge" [ Upstream commit cc90bc68422318eb8e75b15cd74bc8d538a7df29 ] This partially reverts commit e3a5d8e386c3fb973fa75f2403622a8f3640ec06. Commit e3a5d8e386c3 ("check bi_size overflow before merge") adds a bio_full check to __bio_try_merge_page. This will cause __bio_try_merge_page to fail when the last bi_io_vec has been reached. Instead, what we want here is only the bi_size overflow check. Fixes: e3a5d8e386c3 ("block: check bi_size overflow before merge") Cc: stable@vger.kernel.org # v5.4+ Reviewed-by: Ming Lei Signed-off-by: Andreas Gruenbacher Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit d0400f5906e95d743d2e5dc84d5876e833fde856 Author: Andre Przywara Date: Tue Nov 5 11:06:51 2019 +0000 arm64: dts: allwinner: a64: Re-add PMU node [ Upstream commit 6b832a148717f1718f57805a9a4aa7f092582d15 ] As it was found recently, the Performance Monitoring Unit (PMU) on the Allwinner A64 SoC was not generating (the right) interrupts. With the SPI numbers from the manual the kernel did not receive any overflow interrupts, so perf was not happy at all. It turns out that the numbers were just off by 4, so the PMU interrupts are from 148 to 151, not from 152 to 155 as the manual describes. This was found by playing around with U-Boot, which typically does not use interrupts, so the GIC is fully available for experimentation: With *every* PPI and SPI enabled, an overflowing PMU cycle counter was found to set a bit in one of the GICD_ISPENDR registers, with careful counting this was determined to be number 148. Tested with perf record and perf top on a Pine64-LTS. Also tested with tasksetting to every core to confirm the assignment between IRQs and cores. This somewhat "revert-fixes" commit ed3e9406bcbc ("arm64: dts: allwinner: a64: Drop PMU node"). Fixes: 34a97fcc71c2 ("arm64: dts: allwinner: a64: Add PMU node") Fixes: ed3e9406bcbc ("arm64: dts: allwinner: a64: Drop PMU node") Signed-off-by: Andre Przywara Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit 5a93c71a8cf55b64454d370d0a2fd3229b6527bc Author: Eric Dumazet Date: Sat Dec 7 11:34:45 2019 -0800 net_sched: validate TCA_KIND attribute in tc_chain_tmplt_add() [ Upstream commit 2dd5616ecdcebdf5a8d007af64e040d4e9214efe ] Use the new tcf_proto_check_kind() helper to make sure user provided value is well formed. BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:606 [inline] BUG: KMSAN: uninit-value in string+0x4be/0x600 lib/vsprintf.c:668 CPU: 0 PID: 12358 Comm: syz-executor.1 Not tainted 5.4.0-rc8-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x220 lib/dump_stack.c:118 kmsan_report+0x128/0x220 mm/kmsan/kmsan_report.c:108 __msan_warning+0x64/0xc0 mm/kmsan/kmsan_instr.c:245 string_nocheck lib/vsprintf.c:606 [inline] string+0x4be/0x600 lib/vsprintf.c:668 vsnprintf+0x218f/0x3210 lib/vsprintf.c:2510 __request_module+0x2b1/0x11c0 kernel/kmod.c:143 tcf_proto_lookup_ops+0x171/0x700 net/sched/cls_api.c:139 tc_chain_tmplt_add net/sched/cls_api.c:2730 [inline] tc_ctl_chain+0x1904/0x38a0 net/sched/cls_api.c:2850 rtnetlink_rcv_msg+0x115a/0x1580 net/core/rtnetlink.c:5224 netlink_rcv_skb+0x431/0x620 net/netlink/af_netlink.c:2477 rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:5242 netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline] netlink_unicast+0xf3e/0x1020 net/netlink/af_netlink.c:1328 netlink_sendmsg+0x110f/0x1330 net/netlink/af_netlink.c:1917 sock_sendmsg_nosec net/socket.c:637 [inline] sock_sendmsg net/socket.c:657 [inline] ___sys_sendmsg+0x14ff/0x1590 net/socket.c:2311 __sys_sendmsg net/socket.c:2356 [inline] __do_sys_sendmsg net/socket.c:2365 [inline] __se_sys_sendmsg+0x305/0x460 net/socket.c:2363 __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2363 do_syscall_64+0xb6/0x160 arch/x86/entry/common.c:291 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x45a649 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:00007f0790795c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 000000000045a649 RDX: 0000000000000000 RSI: 0000000020000300 RDI: 0000000000000006 RBP: 000000000075bfc8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f07907966d4 R13: 00000000004c8db5 R14: 00000000004df630 R15: 00000000ffffffff Uninit was created at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:149 [inline] kmsan_internal_poison_shadow+0x5c/0x110 mm/kmsan/kmsan.c:132 kmsan_slab_alloc+0x97/0x100 mm/kmsan/kmsan_hooks.c:86 slab_alloc_node mm/slub.c:2773 [inline] __kmalloc_node_track_caller+0xe27/0x11a0 mm/slub.c:4381 __kmalloc_reserve net/core/skbuff.c:141 [inline] __alloc_skb+0x306/0xa10 net/core/skbuff.c:209 alloc_skb include/linux/skbuff.h:1049 [inline] netlink_alloc_large_skb net/netlink/af_netlink.c:1174 [inline] netlink_sendmsg+0x783/0x1330 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:637 [inline] sock_sendmsg net/socket.c:657 [inline] ___sys_sendmsg+0x14ff/0x1590 net/socket.c:2311 __sys_sendmsg net/socket.c:2356 [inline] __do_sys_sendmsg net/socket.c:2365 [inline] __se_sys_sendmsg+0x305/0x460 net/socket.c:2363 __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2363 do_syscall_64+0xb6/0x160 arch/x86/entry/common.c:291 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: 6f96c3c6904c ("net_sched: fix backward compatibility for TCA_KIND") Signed-off-by: Eric Dumazet Reported-by: syzbot Acked-by: Cong Wang Cc: Marcelo Ricardo Leitner Cc: Jamal Hadi Salim Cc: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit af075ec9c1670e9f43c2b3163873780996243493 Author: Chuck Lever Date: Fri Nov 15 08:39:07 2019 -0500 SUNRPC: Fix another issue with MIC buffer space [ Upstream commit e8d70b321ecc9b23d09b8df63e38a2f73160c209 ] xdr_shrink_pagelen() BUG's when @len is larger than buf->page_len. This can happen when xdr_buf_read_mic() is given an xdr_buf with a small page array (like, only a few bytes). Instead, just cap the number of bytes that xdr_shrink_pagelen() will move. Fixes: 5f1bc39979d ("SUNRPC: Fix buffer handling of GSS MIC ... ") Signed-off-by: Chuck Lever Reviewed-by: Benjamin Coddington Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 11c3ef9073a06f849e4ed87db6995107157ae0ed Author: Roman Bolshakov Date: Mon Nov 25 19:56:54 2019 +0300 scsi: qla2xxx: Change discovery state before PLOGI [ Upstream commit 58e39a2ce4be08162c0368030cdc405f7fd849aa ] When a port sends PLOGI, discovery state should be changed to login pending, otherwise RELOGIN_NEEDED bit is set in qla24xx_handle_plogi_done_event(). RELOGIN_NEEDED triggers another PLOGI, and it never goes out of the loop until login timer expires. Fixes: 8777e4314d397 ("scsi: qla2xxx: Migrate NVME N2N handling into state machine") Fixes: 8b5292bcfcacf ("scsi: qla2xxx: Fix Relogin to prevent modifying scan_state flag") Cc: Quinn Tran Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20191125165702.1013-6-r.bolshakov@yadro.com Acked-by: Himanshu Madhani Reviewed-by: Hannes Reinecke Tested-by: Hannes Reinecke Signed-off-by: Roman Bolshakov Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 51952b3c0340bd101c9076fde1cd276e26510ebd Author: Guoqing Jiang Date: Wed Nov 27 17:57:50 2019 +0100 raid5: need to set STRIPE_HANDLE for batch head [ Upstream commit a7ede3d16808b8f3915c8572d783530a82b2f027 ] With commit 6ce220dd2f8ea71d6afc29b9a7524c12e39f374a ("raid5: don't set STRIPE_HANDLE to stripe which is in batch list"), we don't want to set STRIPE_HANDLE flag for sh which is already in batch list. However, the stripe which is the head of batch list should set this flag, otherwise panic could happen inside init_stripe at BUG_ON(sh->batch_head), it is reproducible with raid5 on top of nvdimm devices per Xiao oberserved. Thanks for Xiao's effort to verify the change. Fixes: 6ce220dd2f8ea ("raid5: don't set STRIPE_HANDLE to stripe which is in batch list") Reported-by: Xiao Ni Tested-by: Xiao Ni Signed-off-by: Guoqing Jiang Signed-off-by: Song Liu Signed-off-by: Sasha Levin commit 9b025e3f91e1f132700394bfcc8a6962f941cf55 Author: Tejun Heo Date: Fri Sep 20 13:39:57 2019 -0700 workqueue: Fix missing kfree(rescuer) in destroy_workqueue() commit 8efe1223d73c218ce7e8b2e0e9aadb974b582d7f upstream. Signed-off-by: Tejun Heo Reported-by: Qian Cai Fixes: def98c84b6cd ("workqueue: Fix spurious sanity check failures in destroy_workqueue()") Cc: Nobuhiro Iwamatsu Signed-off-by: Greg Kroah-Hartman commit e484f55479c49b871d882a2da84ac0abcfa6d1ad Author: Ming Lei Date: Mon Nov 4 16:26:53 2019 +0800 blk-mq: make sure that line break can be printed commit d2c9be89f8ebe7ebcc97676ac40f8dec1cf9b43a upstream. 8962842ca5ab ("blk-mq: avoid sysfs buffer overflow with too many CPU cores") avoids sysfs buffer overflow, and reserves one character for line break. However, the last snprintf() doesn't get correct 'size' parameter passed in, so fixed it. Fixes: 8962842ca5ab ("blk-mq: avoid sysfs buffer overflow with too many CPU cores") Signed-off-by: Ming Lei Signed-off-by: Jens Axboe Cc: Nobuhiro Iwamatsu Signed-off-by: Greg Kroah-Hartman commit e880a8445950c53e52891fef0df2ece918a2fba8 Author: yangerkun Date: Thu Sep 19 14:35:08 2019 +0800 ext4: fix a bug in ext4_wait_for_tail_page_commit commit 565333a1554d704789e74205989305c811fd9c7a upstream. No need to wait for any commit once the page is fully truncated. Besides, it may confuse e.g. concurrent ext4_writepage() with the page still be dirty (will be cleared by truncate_pagecache() in ext4_setattr()) but buffers has been freed; and then trigger a bug show as below: [ 26.057508] ------------[ cut here ]------------ [ 26.058531] kernel BUG at fs/ext4/inode.c:2134! ... [ 26.088130] Call trace: [ 26.088695] ext4_writepage+0x914/0xb28 [ 26.089541] writeout.isra.4+0x1b4/0x2b8 [ 26.090409] move_to_new_page+0x3b0/0x568 [ 26.091338] __unmap_and_move+0x648/0x988 [ 26.092241] unmap_and_move+0x48c/0xbb8 [ 26.093096] migrate_pages+0x220/0xb28 [ 26.093945] kernel_mbind+0x828/0xa18 [ 26.094791] __arm64_sys_mbind+0xc8/0x138 [ 26.095716] el0_svc_common+0x190/0x490 [ 26.096571] el0_svc_handler+0x60/0xd0 [ 26.097423] el0_svc+0x8/0xc Run the procedure (generate by syzkaller) parallel with ext3. void main() { int fd, fd1, ret; void *addr; size_t length = 4096; int flags; off_t offset = 0; char *str = "12345"; fd = open("a", O_RDWR | O_CREAT); assert(fd >= 0); /* Truncate to 4k */ ret = ftruncate(fd, length); assert(ret == 0); /* Journal data mode */ flags = 0xc00f; ret = ioctl(fd, _IOW('f', 2, long), &flags); assert(ret == 0); /* Truncate to 0 */ fd1 = open("a", O_TRUNC | O_NOATIME); assert(fd1 >= 0); addr = mmap(NULL, length, PROT_WRITE | PROT_READ, MAP_SHARED, fd, offset); assert(addr != (void *)-1); memcpy(addr, str, 5); mbind(addr, length, 0, 0, 0, MPOL_MF_MOVE); } And the bug will be triggered once we seen the below order. reproduce1 reproduce2 ... | ... truncate to 4k | change to journal data mode | | memcpy(set page dirty) truncate to 0: | ext4_setattr: | ... | ext4_wait_for_tail_page_commit | | mbind(trigger bug) truncate_pagecache(clean dirty)| ... ... | mbind will call ext4_writepage() since the page still be dirty, and then report the bug since the buffers has been free. Fix it by return directly once offset equals to 0 which means the page has been fully truncated. Reported-by: Hulk Robot Signed-off-by: yangerkun Link: https://lore.kernel.org/r/20190919063508.1045-1-yangerkun@huawei.com Reviewed-by: Jan Kara Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit acdd98046288d9113aad152dc8d1341dd602afc7 Author: Darrick J. Wong Date: Tue Oct 15 08:44:32 2019 -0700 splice: only read in as much information as there is pipe buffer space commit 3253d9d093376d62b4a56e609f15d2ec5085ac73 upstream. Andreas Grünbacher reports that on the two filesystems that support iomap directio, it's possible for splice() to return -EAGAIN (instead of a short splice) if the pipe being written to has less space available in its pipe buffers than the length supplied by the calling process. Months ago we fixed splice_direct_to_actor to clamp the length of the read request to the size of the splice pipe. Do the same to do_splice. Fixes: 17614445576b6 ("splice: don't read more than available pipe space") Reported-by: syzbot+3c01db6025f26530cf8d@syzkaller.appspotmail.com Reported-by: Andreas Grünbacher Reviewed-by: Andreas Grünbacher Signed-off-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman commit ec968952480d2c4168440b6a0b3aada66afe273a Author: Alexandre Belloni Date: Mon Oct 21 01:13:20 2019 +0200 rtc: disable uie before setting time and enable after commit 7e7c005b4b1f1f169bcc4b2c3a40085ecc663df2 upstream. When setting the time in the future with the uie timer enabled, rtc_timer_do_work will loop for a while because the expiration of the uie timer was way before the current RTC time and a new timer will be enqueued until the current rtc time is reached. If the uie timer is enabled, disable it before setting the time and enable it after expiring current timers (which may actually be an alarm). This is the safest thing to do to ensure the uie timer is still synchronized with the RTC, especially in the UIE emulation case. Reported-by: syzbot+08116743f8ad6f9a6de7@syzkaller.appspotmail.com Fixes: 6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events") Link: https://lore.kernel.org/r/20191020231320.8191-1-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 3b353b2b9d8a092982866422020b1c47e285cd83 Author: Chen Jun Date: Sat Nov 30 17:58:11 2019 -0800 mm/shmem.c: cast the type of unmap_start to u64 commit aa71ecd8d86500da6081a72da6b0b524007e0627 upstream. In 64bit system. sb->s_maxbytes of shmem filesystem is MAX_LFS_FILESIZE, which equal LLONG_MAX. If offset > LLONG_MAX - PAGE_SIZE, offset + len < LLONG_MAX in shmem_fallocate, which will pass the checking in vfs_fallocate. /* Check for wrap through zero too */ if (((offset + len) > inode->i_sb->s_maxbytes) || ((offset + len) < 0)) return -EFBIG; loff_t unmap_start = round_up(offset, PAGE_SIZE) in shmem_fallocate causes a overflow. Syzkaller reports a overflow problem in mm/shmem: UBSAN: Undefined behaviour in mm/shmem.c:2014:10 signed integer overflow: '9223372036854775807 + 1' cannot be represented in type 'long long int' CPU: 0 PID:17076 Comm: syz-executor0 Not tainted 4.1.46+ #1 Hardware name: linux, dummy-virt (DT) Call trace: dump_backtrace+0x0/0x2c8 arch/arm64/kernel/traps.c:100 show_stack+0x20/0x30 arch/arm64/kernel/traps.c:238 __dump_stack lib/dump_stack.c:15 [inline] ubsan_epilogue+0x18/0x70 lib/ubsan.c:164 handle_overflow+0x158/0x1b0 lib/ubsan.c:195 shmem_fallocate+0x6d0/0x820 mm/shmem.c:2104 vfs_fallocate+0x238/0x428 fs/open.c:312 SYSC_fallocate fs/open.c:335 [inline] SyS_fallocate+0x54/0xc8 fs/open.c:239 The highest bit of unmap_start will be appended with sign bit 1 (overflow) when calculate shmem_falloc.start: shmem_falloc.start = unmap_start >> PAGE_SHIFT. Fix it by casting the type of unmap_start to u64, when right shifted. This bug is found in LTS Linux 4.1. It also seems to exist in mainline. Link: http://lkml.kernel.org/r/1573867464-5107-1-git-send-email-chenjun102@huawei.com Signed-off-by: Chen Jun Reviewed-by: Andrew Morton Cc: Hugh Dickins Cc: Qian Cai Cc: Kefeng Wang Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 58aa93a2353d0bd95d3be630b25b34b903a9f7cd Author: Gerald Schaefer Date: Tue Nov 19 12:30:53 2019 +0100 s390/kaslr: store KASLR offset for early dumps commit a9f2f6865d784477e1c7b59269d3a384abafd9ca upstream. The KASLR offset is added to vmcoreinfo in arch_crash_save_vmcoreinfo(), so that it can be found by crash when processing kernel dumps. However, arch_crash_save_vmcoreinfo() is called during a subsys_initcall, so if the kernel crashes before that, we have no vmcoreinfo and no KASLR offset. Fix this by storing the KASLR offset in the lowcore, where the vmcore_info pointer will be stored, and where it can be found by crash. In order to make it distinguishable from a real vmcore_info pointer, mark it as uneven (KASLR offset itself is aligned to THREAD_SIZE). When arch_crash_save_vmcoreinfo() stores the real vmcore_info pointer in the lowcore, it overwrites the KASLR offset. At that point, the KASLR offset is not yet added to vmcoreinfo, so we also need to move the mem_assign_absolute() behind the vmcoreinfo_append_str(). Fixes: b2d24b97b2a9 ("s390/kernel: add support for kernel address space layout randomization (KASLR)") Cc: # v5.2+ Signed-off-by: Gerald Schaefer Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 8a477efd5cd027a2fe2420014aa2822f2e1b1acc Author: Heiko Carstens Date: Mon Nov 18 13:09:52 2019 +0100 s390/smp,vdso: fix ASCE handling commit a2308c11ecbc3471ebb7435ee8075815b1502ef0 upstream. When a secondary CPU is brought up it must initialize its control registers. CPU A which triggers that a secondary CPU B is brought up stores its control register contents into the lowcore of new CPU B, which then loads these values on startup. This is problematic in various ways: the control register which contains the home space ASCE will correctly contain the kernel ASCE; however control registers for primary and secondary ASCEs are initialized with whatever values were present in CPU A. Typically: - the primary ASCE will contain the user process ASCE of the process that triggered onlining of CPU B. - the secondary ASCE will contain the percpu VDSO ASCE of CPU A. Due to lazy ASCE handling we may also end up with other combinations. When then CPU B switches to a different process (!= idle) it will fixup the primary ASCE. However the problem is that the (wrong) ASCE from CPU A was loaded into control register 1: as soon as an ASCE is attached (aka loaded) a CPU is free to generate TLB entries using that address space. Even though it is very unlikey that CPU B will actually generate such entries, this could result in TLB entries of the address space of the process that ran on CPU A. These entries shouldn't exist at all and could cause problems later on. Furthermore the secondary ASCE of CPU B will not be updated correctly. This means that processes may see wrong results or even crash if they access VDSO data on CPU B. The correct VDSO ASCE will eventually be loaded on return to user space as soon as the kernel executed a call to strnlen_user or an atomic futex operation on CPU B. Fix both issues by intializing the to be loaded control register contents with the correct ASCEs and also enforce (re-)loading of the ASCEs upon first context switch and return to user space. Fixes: 0aaba41b58bc ("s390: remove all code using the access register mode") Cc: stable@vger.kernel.org # v4.15+ Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 496c44d56744db7e58e985f27d511a0045d31552 Author: Will Deacon Date: Mon Nov 4 15:58:15 2019 +0000 firmware: qcom: scm: Ensure 'a0' status code is treated as signed commit ff34f3cce278a0982a7b66b1afaed6295141b1fc upstream. The 'a0' member of 'struct arm_smccc_res' is declared as 'unsigned long', however the Qualcomm SCM firmware interface driver expects to receive negative error codes via this field, so ensure that it's cast to 'long' before comparing to see if it is less than 0. Cc: Reviewed-by: Bjorn Andersson Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit ea46b9e9aa340496aec70ff401b4e922df54f244 Author: Theodore Ts'o Date: Mon Nov 11 22:18:13 2019 -0500 ext4: work around deleting a file with i_nlink == 0 safely commit c7df4a1ecb8579838ec8c56b2bb6a6716e974f37 upstream. If the file system is corrupted such that a file's i_links_count is too small, then it's possible that when unlinking that file, i_nlink will already be zero. Previously we were working around this kind of corruption by forcing i_nlink to one; but we were doing this before trying to delete the directory entry --- and if the file system is corrupted enough that ext4_delete_entry() fails, then we exit with i_nlink elevated, and this causes the orphan inode list handling to be FUBAR'ed, such that when we unmount the file system, the orphan inode list can get corrupted. A better way to fix this is to simply skip trying to call drop_nlink() if i_nlink is already zero, thus moving the check to the place where it makes the most sense. https://bugzilla.kernel.org/show_bug.cgi?id=205433 Link: https://lore.kernel.org/r/20191112032903.8828-1-tytso@mit.edu Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Reviewed-by: Andreas Dilger Signed-off-by: Greg Kroah-Hartman commit b18b05545e2c084bc6c86db36267311f2e518d3c Author: Roman Gushchin Date: Wed Dec 4 16:49:46 2019 -0800 mm: memcg/slab: wait for !root kmem_cache refcnt killing on root kmem_cache destruction commit a264df74df38855096393447f1b8f386069a94b9 upstream. Christian reported a warning like the following obtained during running some KVM-related tests on s390: WARNING: CPU: 8 PID: 208 at lib/percpu-refcount.c:108 percpu_ref_exit+0x50/0x58 Modules linked in: kvm(-) xt_CHECKSUM xt_MASQUERADE bonding xt_tcpudp ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ip6table_na> CPU: 8 PID: 208 Comm: kworker/8:1 Not tainted 5.2.0+ #66 Hardware name: IBM 2964 NC9 712 (LPAR) Workqueue: events sysfs_slab_remove_workfn Krnl PSW : 0704e00180000000 0000001529746850 (percpu_ref_exit+0x50/0x58) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 00000000ffff8808 0000001529746740 000003f4e30e8e18 0036008100000000 0000001f00000000 0035008100000000 0000001fb3573ab8 0000000000000000 0000001fbdb6de00 0000000000000000 0000001529f01328 0000001fb3573b00 0000001fbb27e000 0000001fbdb69300 000003e009263d00 000003e009263cd0 Krnl Code: 0000001529746842: f0a0000407fe srp 4(11,%r0),2046,0 0000001529746848: 47000700 bc 0,1792 #000000152974684c: a7f40001 brc 15,152974684e >0000001529746850: a7f4fff2 brc 15,1529746834 0000001529746854: 0707 bcr 0,%r7 0000001529746856: 0707 bcr 0,%r7 0000001529746858: eb8ff0580024 stmg %r8,%r15,88(%r15) 000000152974685e: a738ffff lhi %r3,-1 Call Trace: ([<000003e009263d00>] 0x3e009263d00) [<00000015293252ea>] slab_kmem_cache_release+0x3a/0x70 [<0000001529b04882>] kobject_put+0xaa/0xe8 [<000000152918cf28>] process_one_work+0x1e8/0x428 [<000000152918d1b0>] worker_thread+0x48/0x460 [<00000015291942c6>] kthread+0x126/0x160 [<0000001529b22344>] ret_from_fork+0x28/0x30 [<0000001529b2234c>] kernel_thread_starter+0x0/0x10 Last Breaking-Event-Address: [<000000152974684c>] percpu_ref_exit+0x4c/0x58 ---[ end trace b035e7da5788eb09 ]--- The problem occurs because kmem_cache_destroy() is called immediately after deleting of a memcg, so it races with the memcg kmem_cache deactivation. flush_memcg_workqueue() at the beginning of kmem_cache_destroy() is supposed to guarantee that all deactivation processes are finished, but failed to do so. It waits for an rcu grace period, after which all children kmem_caches should be deactivated. During the deactivation percpu_ref_kill() is called for non root kmem_cache refcounters, but it requires yet another rcu grace period to finish the transition to the atomic (dead) state. So in a rare case when not all children kmem_caches are destroyed at the moment when the root kmem_cache is about to be gone, we need to wait another rcu grace period before destroying the root kmem_cache. This issue can be triggered only with dynamically created kmem_caches which are used with memcg accounting. In this case per-memcg child kmem_caches are created. They are deactivated from the cgroup removing path. If the destruction of the root kmem_cache is racing with the removal of the cgroup (both are quite complicated multi-stage processes), the described issue can occur. The only known way to trigger it in the real life, is to unload some kernel module which creates a dedicated kmem_cache, used from different memory cgroups with GFP_ACCOUNT flag. If the unloading happens immediately after calling rmdir on the corresponding cgroup, there is some chance to trigger the issue. Link: http://lkml.kernel.org/r/20191129025011.3076017-1-guro@fb.com Fixes: f0a3a24b532d ("mm: memcg/slab: rework non-root kmem_cache lifecycle management") Signed-off-by: Roman Gushchin Reported-by: Christian Borntraeger Tested-by: Christian Borntraeger Reviewed-by: Shakeel Butt Acked-by: Michal Hocko Cc: Johannes Weiner Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d593e48c52699ae6658cdc01990092466954f4cf Author: Daniel Schultz Date: Tue Sep 17 10:12:53 2019 +0200 mfd: rk808: Fix RK818 ID template commit 37ef8c2c15bdc1322b160e38986c187de2b877b2 upstream. The Rockchip PMIC driver can automatically detect connected component versions by reading the ID_MSB and ID_LSB registers. The probe function will always fail with RK818 PMICs because the ID_MSK is 0xFFF0 and the RK818 template ID is 0x8181. This patch changes this value to 0x8180. Fixes: 9d6105e19f61 ("mfd: rk808: Fix up the chip id get failed") Cc: stable@vger.kernel.org Cc: Elaine Zhang Cc: Joseph Chen Signed-off-by: Daniel Schultz Signed-off-by: Heiko Stuebner Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 0393233a2c20a7d90781819a1e6cd522d11062b2 Author: Nicolas Geoffray Date: Sat Nov 30 17:53:28 2019 -0800 mm, memfd: fix COW issue on MAP_PRIVATE and F_SEAL_FUTURE_WRITE mappings commit 05d351102dbe4e103d6bdac18b1122cd3cd04925 upstream. F_SEAL_FUTURE_WRITE has unexpected behavior when used with MAP_PRIVATE: A private mapping created after the memfd file that gets sealed with F_SEAL_FUTURE_WRITE loses the copy-on-write at fork behavior, meaning children and parent share the same memory, even though the mapping is private. The reason for this is due to the code below: static int shmem_mmap(struct file *file, struct vm_area_struct *vma) { struct shmem_inode_info *info = SHMEM_I(file_inode(file)); if (info->seals & F_SEAL_FUTURE_WRITE) { /* * New PROT_WRITE and MAP_SHARED mmaps are not allowed when * "future write" seal active. */ if ((vma->vm_flags & VM_SHARED) && (vma->vm_flags & VM_WRITE)) return -EPERM; /* * Since the F_SEAL_FUTURE_WRITE seals allow for a MAP_SHARED * read-only mapping, take care to not allow mprotect to revert * protections. */ vma->vm_flags &= ~(VM_MAYWRITE); } ... } And for the mm to know if a mapping is copy-on-write: static inline bool is_cow_mapping(vm_flags_t flags) { return (flags & (VM_SHARED | VM_MAYWRITE)) == VM_MAYWRITE; } The patch fixes the issue by making the mprotect revert protection happen only for shared mappings. For private mappings, using mprotect will have no effect on the seal behavior. The F_SEAL_FUTURE_WRITE feature was introduced in v5.1 so v5.3.x stable kernels would need a backport. [akpm@linux-foundation.org: reflow comment, per Christoph] Link: http://lkml.kernel.org/r/20191107195355.80608-1-joel@joelfernandes.org Fixes: ab3948f58ff84 ("mm/memfd: add an F_SEAL_FUTURE_WRITE seal to memfd") Signed-off-by: Nicolas Geoffray Signed-off-by: Joel Fernandes (Google) Cc: Hugh Dickins Cc: Shuah Khan Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e8672e0f87adbed588f077c03108b2de1bbf0124 Author: Vincenzo Frascino Date: Mon Dec 2 07:57:29 2019 +0000 powerpc: Fix vDSO clock_getres() [ Upstream commit 552263456215ada7ee8700ce022d12b0cffe4802 ] clock_getres in the vDSO library has to preserve the same behaviour of posix_get_hrtimer_res(). In particular, posix_get_hrtimer_res() does: sec = 0; ns = hrtimer_resolution; and hrtimer_resolution depends on the enablement of the high resolution timers that can happen either at compile or at run time. Fix the powerpc vdso implementation of clock_getres keeping a copy of hrtimer_resolution in vdso data and using that directly. Fixes: a7f290dad32e ("[PATCH] powerpc: Merge vdso's and add vdso support to 32 bits kernel") Cc: stable@vger.kernel.org Signed-off-by: Vincenzo Frascino Reviewed-by: Christophe Leroy Acked-by: Shuah Khan [chleroy: changed CLOCK_REALTIME_RES to CLOCK_HRTIMER_RES] Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/a55eca3a5e85233838c2349783bcb5164dae1d09.1575273217.git.christophe.leroy@c-s.fr Signed-off-by: Sasha Levin commit 54cf310773484a6ae5d3b02bb36947ec33bed20a Author: Nathan Chancellor Date: Mon Nov 18 21:57:11 2019 -0700 powerpc: Avoid clang warnings around setjmp and longjmp [ Upstream commit c9029ef9c95765e7b63c4d9aa780674447db1ec0 ] Commit aea447141c7e ("powerpc: Disable -Wbuiltin-requires-header when setjmp is used") disabled -Wbuiltin-requires-header because of a warning about the setjmp and longjmp declarations. r367387 in clang added another diagnostic around this, complaining that there is no jmp_buf declaration. In file included from ../arch/powerpc/xmon/xmon.c:47: ../arch/powerpc/include/asm/setjmp.h:10:13: error: declaration of built-in function 'setjmp' requires the declaration of the 'jmp_buf' type, commonly provided in the header . [-Werror,-Wincomplete-setjmp-declaration] extern long setjmp(long *); ^ ../arch/powerpc/include/asm/setjmp.h:11:13: error: declaration of built-in function 'longjmp' requires the declaration of the 'jmp_buf' type, commonly provided in the header . [-Werror,-Wincomplete-setjmp-declaration] extern void longjmp(long *, long); ^ 2 errors generated. We are not using the standard library's longjmp/setjmp implementations for obvious reasons; make this clear to clang by using -ffreestanding on these files. Cc: stable@vger.kernel.org # 4.14+ Suggested-by: Segher Boessenkool Reviewed-by: Nick Desaulniers Signed-off-by: Nathan Chancellor Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191119045712.39633-3-natechancellor@gmail.com Signed-off-by: Sasha Levin commit cd0e6f740ee6f90e2c87cca8d63aaa21b0b93a28 Author: H. Nikolaus Schaller Date: Thu Nov 7 11:30:39 2019 +0100 omap: pdata-quirks: remove openpandora quirks for mmc3 and wl1251 [ Upstream commit 2398c41d64321e62af54424fd399964f3d48cdc2 ] With a wl1251 child node of mmc3 in the device tree decoded in omap_hsmmc.c to handle special wl1251 initialization, we do no longer need to instantiate the mmc3 through pdata quirks. We also can remove the wlan regulator and reset/interrupt definitions and do them through device tree. Fixes: 81eef6ca9201 ("mmc: omap_hsmmc: Use dma_request_chan() for requesting DMA channel") Signed-off-by: H. Nikolaus Schaller Cc: # v4.7+ Acked-by: Tony Lindgren Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit d01b5f373c2b51f20ebbdfaf0c273c7861b5395a Author: H. Nikolaus Schaller Date: Thu Nov 7 11:30:38 2019 +0100 omap: pdata-quirks: revert pandora specific gpiod additions [ Upstream commit 4e8fad98171babe019db51c15055ec74697e9525 ] This partly reverts the commit efdfeb079cc3 ("regulator: fixed: Convert to use GPIO descriptor only"). We must remove this from mainline first, so that the following patch to remove the openpandora quirks for mmc3 and wl1251 cleanly applies to stable v4.9, v4.14, v4.19 where the above mentioned patch is not yet present. Since the code affected is removed (no pandora gpios in pdata-quirks and more), there will be no matching revert-of-the-revert. Signed-off-by: H. Nikolaus Schaller Acked-by: Tony Lindgren Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 4e09a87e9916dc8717fa236f8b11684de55e961b Author: Andrea Merello Date: Mon Dec 2 15:13:36 2019 +0100 iio: ad7949: fix channels mixups [ Upstream commit 3b71f6b59508b1c9befcb43de434866aafc76520 ] Each time we need to read a sample (from the sysfs interface, since the driver supports only it) the driver writes the configuration register with the proper settings needed to perform the said read, then it runs another xfer to actually read the resulting value. Most notably the configuration register is updated to set the ADC internal MUX depending by which channel the read targets. Unfortunately this seems not enough to ensure correct operation because the ADC works in a pipelined-like fashion and the new configuration isn't applied in time. The ADC alternates two phases: acquisition and conversion. During the acquisition phase the ADC samples the analog signal in an internal capacitor; in the conversion phase the ADC performs the actual analog to digital conversion of the stored voltage. Note that of course the MUX needs to be set to the proper channel when the acquisition phase is performed. Once the conversion phase has been completed, the device automatically switches back to a new acquisition; on the other hand the device switches from acquisition to conversion on the rising edge of SPI cs signal (that is when the xfer finishes). Only after both two phases have been completed (with the proper settings already written in the configuration register since the beginning) it is possible to read the outcome from SPI bus. With the current driver implementation, we end up in the following situation: _______ 1st xfer ____________ 2nd xfer ___________________ SPI cs.. \_________/ \_________/ SPI rd.. idle |(val N-2)+ idle | val N-1 + idle ... SPI wr.. idle | cfg N + idle | (X) + idle ... ------------------------ + -------------------- + ------------------ AD .. acq N-1 + cnv N-1 | acq N + cnv N | acq N+1 As shown in the diagram above, the value we read in the Nth read belongs to configuration setting N-1. In case the configuration is not changed (config[N] == config[N-1]), then we still get correct data, but in case the configuration changes (i.e. switching the MUX on another channel), we get wrong data (data from the previously selected channel). This patch fixes this by performing one more "dummy" transfer in order to ending up in reading the data when it's really ready, as per the following timing diagram. _______ 1st xfer ____________ 2nd xfer ___________ 3rd xfer ___ SPI cs.. \_________/ \_________/ \_________/ SPI rd.. idle |(val N-2)+ idle |(val N-1)+ idle | val N + .. SPI wr.. idle | cfg N + idle | (X) + idle | (X) + .. ------------------------ + -------------------- + ------------------- + -- AD .. acq N-1 + cnv N-1 | acq N + cnv N | acq N+1 | .. NOTE: in the latter case (cfg changes), the acquisition phase for the value to be read begins after the 1st xfer, that is after the read request has been issued on sysfs. On the other hand, if the cfg doesn't change, then we can refer to the fist diagram assuming N == (N - 1); the acquisition phase _begins_ before the 1st xfer (potentially a lot of time before the read has been issued via sysfs, but it _ends_ after the 1st xfer, that is _after_ the read has started. This should guarantee a reasonably fresh data, which value represents the voltage that the sampled signal has after the read start or maybe just around it. Signed-off-by: Andrea Merello Reviewed-by: Charles-Antoine Couret Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit faabf040373a9391256bb48bee6f797ed9d1f6c6 Author: Andrea Merello Date: Thu Sep 12 16:43:07 2019 +0200 iio: ad7949: kill pointless "readback"-handling code [ Upstream commit c270bbf7bb9ddc4e2a51b3c56557c377c9ac79bc ] The device could be configured to spit out also the configuration word while reading the AD result value (in the same SPI xfer) - this is called "readback" in the device datasheet. The driver checks if readback is enabled and it eventually adjusts the SPI xfer length and it applies proper shifts to still get the data, discarding the configuration word. The readback option is actually never enabled (the driver disables it), so the said checks do not serve for any purpose. Since enabling the readback option seems not to provide any advantage (the driver entirely sets the configuration word without relying on any default value), just kill the said, unused, code. Signed-off-by: Andrea Merello Reviewed-by: Alexandru Ardelean Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 4b5540af0124278cb0d86488d627d80426c3f4a5 Author: Lorenzo Bianconi Date: Sun Oct 27 19:02:30 2019 +0100 iio: imu: st_lsm6dsx: fix ODR check in st_lsm6dsx_write_raw [ Upstream commit fc3f6ad7f5dc6c899fbda0255865737bac88c2e0 ] Since st_lsm6dsx i2c master controller relies on accel device as trigger and slave devices can run at different ODRs we must select an accel_odr >= slave_odr. Report real accel ODR in st_lsm6dsx_check_odr() in order to properly set sensor frequency in st_lsm6dsx_write_raw and avoid to report unsupported frequency Fixes: 6ffb55e5009ff ("iio: imu: st_lsm6dsx: introduce ST_LSM6DSX_ID_EXT sensor ids") Signed-off-by: Lorenzo Bianconi Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 02bd14b66ec2375ba262531b13f1c1a5708dbeaa Author: Lorenzo Bianconi Date: Mon Jul 29 21:22:28 2019 +0200 iio: imu: st_lsm6dsx: move odr_table in st_lsm6dsx_sensor_settings [ Upstream commit 40dd7343897760c4b617faa78d213e25652de9a6 ] Move sensor odr table in st_lsm6dsx_sensor_settings in order to support sensors with different odr maps. This is a preliminary patch to add support for LSM9DS1 sensor to st_lsm6dsx driver Tested-by: Martin Kepplinger Signed-off-by: Lorenzo Bianconi Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit fb5a9dc2fa439eac370e297dda7f42751c843ee3 Author: Bart Van Assche Date: Thu Aug 8 20:02:05 2019 -0700 scsi: qla2xxx: Introduce the function qla2xxx_init_sp() [ Upstream commit bdb61b9b944d1e5b7cee5a9fe21014363c55b811 ] This patch does not change any functionality but makes the next patch easier to read. Cc: Himanshu Madhani Signed-off-by: Bart Van Assche Tested-by: Himanshu Madhani Reviewed-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 10fd34ac79b234d9bd4459c9b9c1f9d5a67f7bde Author: Quinn Tran Date: Tue Nov 5 07:06:54 2019 -0800 scsi: qla2xxx: Fix double scsi_done for abort path [ Upstream commit f45bca8c5052e8c59bab64ee90c44441678b9a52 ] Current code assumes abort will remove the original command from the active list where scsi_done will not be called. Instead, the eh_abort thread will do the scsi_done. That is not the case. Instead, we have a double scsi_done calls triggering use after free. Abort will tell FW to release the command from FW possesion. The original command will return to ULP with error in its normal fashion via scsi_done. eh_abort path would wait for the original command completion before returning. eh_abort path will not perform the scsi_done call. Fixes: 219d27d7147e0 ("scsi: qla2xxx: Fix race conditions in the code for aborting SCSI commands") Cc: stable@vger.kernel.org # 5.2 Link: https://lore.kernel.org/r/20191105150657.8092-6-hmadhani@marvell.com Reviewed-by: Ewan D. Milne Signed-off-by: Quinn Tran Signed-off-by: Arun Easi Signed-off-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 95000d33752d22d46838a462afaaa3107a5dfab2 Author: Bart Van Assche Date: Thu Aug 8 20:02:06 2019 -0700 scsi: qla2xxx: Fix a race condition between aborting and completing a SCSI command [ Upstream commit 85cffefa09e448906a6f0bc20f422d75a18675bd ] Instead of allocating a struct srb dynamically from inside .queuecommand(), set qla2xxx_driver_template.cmd_size such that struct scsi_cmnd and struct srb are contiguous. Do not call QLA_QPAIR_MARK_BUSY() / QLA_QPAIR_MARK_NOT_BUSY() for SRBs associated with SCSI commands. That is safe because scsi_remove_host() is called before queue pairs are deleted and scsi_remove_host() waits for all outstanding SCSI commands to finish. Cc: Himanshu Madhani Signed-off-by: Bart Van Assche Tested-by: Himanshu Madhani Reviewed-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit b4edc7157b94dba1c2b0d867cfcdf38b5d1cd199 Author: Martin K. Petersen Date: Mon Nov 18 23:55:45 2019 -0500 Revert "scsi: qla2xxx: Fix memory leak when sending I/O fails" [ Upstream commit 5a993e507ee65a28eca6690ee11868555c4ca46b ] This reverts commit 2f856d4e8c23f5ad5221f8da4a2f22d090627f19. This patch was found to introduce a double free regression. The issue it originally attempted to address was fixed in patch f45bca8c5052 ("scsi: qla2xxx: Fix double scsi_done for abort path"). Link: https://lore.kernel.org/r/4BDE2B95-835F-43BE-A32C-2629D7E03E0A@marvell.com Requested-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 4abf4c49ec5b366b2978e0f4cb0ae61b75e408b0 Author: Bart Van Assche Date: Tue Nov 5 20:42:26 2019 -0800 scsi: qla2xxx: Fix a dma_pool_free() call [ Upstream commit 162b805e38327135168cb0938bd37b131b481cb0 ] This patch fixes the following kernel warning: DMA-API: qla2xxx 0000:00:0a.0: device driver frees DMA memory with different size [device address=0x00000000c7b60000] [map size=4088 bytes] [unmap size=512 bytes] WARNING: CPU: 3 PID: 1122 at kernel/dma/debug.c:1021 check_unmap+0x4d0/0xbd0 CPU: 3 PID: 1122 Comm: rmmod Tainted: G O 5.4.0-rc1-dbg+ #1 RIP: 0010:check_unmap+0x4d0/0xbd0 Call Trace: debug_dma_free_coherent+0x123/0x173 dma_free_attrs+0x76/0xe0 qla2x00_mem_free+0x329/0xc40 [qla2xxx_scst] qla2x00_free_device+0x170/0x1c0 [qla2xxx_scst] qla2x00_remove_one+0x4f0/0x6d0 [qla2xxx_scst] pci_device_remove+0xd5/0x1f0 device_release_driver_internal+0x159/0x280 driver_detach+0x8b/0xf2 bus_remove_driver+0x9a/0x15a driver_unregister+0x51/0x70 pci_unregister_driver+0x2d/0x130 qla2x00_module_exit+0x1c/0xbc [qla2xxx_scst] __x64_sys_delete_module+0x22a/0x300 do_syscall_64+0x6f/0x2e0 entry_SYSCALL_64_after_hwframe+0x49/0xbe Fixes: 3f006ac342c0 ("scsi: qla2xxx: Secure flash update support for ISP28XX") # v5.2-rc1~130^2~270. Cc: Michael Hernandez Cc: Himanshu Madhani Link: https://lore.kernel.org/r/20191106044226.5207-3-bvanassche@acm.org Reviewed-by: Martin Wilck Acked-by: Himanshu Madhani Signed-off-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 4a1cc2f71bc57cf8dee6f58e7d2355a43aabb312 Author: Quinn Tran Date: Tue Nov 5 07:06:52 2019 -0800 scsi: qla2xxx: Fix SRB leak on switch command timeout [ Upstream commit af2a0c51b1205327f55a7e82e530403ae1d42cbb ] when GPSC/GPDB switch command fails, driver just returns without doing a proper cleanup. This patch fixes this memory leak by calling sp->free() in the error path. Link: https://lore.kernel.org/r/20191105150657.8092-4-hmadhani@marvell.com Reviewed-by: Ewan D. Milne Signed-off-by: Quinn Tran Signed-off-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f110f9ee5bc479861aff8236b1356dc0b8ad1561 Author: Quinn Tran Date: Fri Aug 30 15:24:01 2019 -0700 scsi: qla2xxx: Fix stale session [ Upstream commit 2037ce49d30a0d07348df406ef78f6664f4bc899 ] On fast cable pull, where driver is unable to detect device has disappeared and came back based on switch info, qla2xxx would not re-login while remote port has already invalidated the session. This causes IO timeout. This patch would relogin to remote device for RSCN affected port. Signed-off-by: Quinn Tran Signed-off-by: Himanshu Madhani Reviewed-by: Ewan D. Milne Link: https://lore.kernel.org/r/20190830222402.23688-6-hmadhani@marvell.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 292e8c2eaf07c0ef502713688f8155916f2dd5cd Author: Quinn Tran Date: Fri Aug 30 15:24:00 2019 -0700 scsi: qla2xxx: Fix stuck login session [ Upstream commit ce0ba496dccfc15d3a8866b845864585b5d316ff ] Login session was stucked on cable pull. When FW is in the middle PRLI PENDING + driver is in Initiator mode, driver fails to check back with FW to see if the PRLI has completed. This patch would re-check with FW again to make sure PRLI would complete before pushing forward with relogin. Signed-off-by: Quinn Tran Signed-off-by: Himanshu Madhani Reviewed-by: Ewan D. Milne Link: https://lore.kernel.org/r/20190830222402.23688-5-hmadhani@marvell.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 1df80889c9db960252e3bfddbae76320f4a0eafb Author: Himanshu Madhani Date: Fri Aug 30 15:23:59 2019 -0700 scsi: qla2xxx: Fix driver reload for ISP82xx [ Upstream commit 32a13df21668b92f70f0673387f29251e0f285ec ] HINT_MBX_INT_PENDING is not guaranteed to be cleared by firmware. Remove check that prevent driver load with ISP82XX. Signed-off-by: Quinn Tran Signed-off-by: Himanshu Madhani Reviewed-by: Ewan D. Milne Link: https://lore.kernel.org/r/20190830222402.23688-4-hmadhani@marvell.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e6409dd3fac84639e74aed4e8c497c56ea619d0d Author: Quinn Tran Date: Fri Aug 30 15:23:58 2019 -0700 scsi: qla2xxx: Fix flash read for Qlogic ISPs [ Upstream commit cb92cb1657c438efe7c88c9759f40c0a9d46c353 ] Use adapter specific callback to read flash instead of ISP adapter specific. Signed-off-by: Quinn Tran Signed-off-by: Himanshu Madhani Reviewed-by: Ewan D. Milne Link: https://lore.kernel.org/r/20190830222402.23688-3-hmadhani@marvell.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 0ba4f7bd112c4a1b39e3a69620e1f18bdc31562e Author: Himanshu Madhani Date: Fri Aug 30 15:23:57 2019 -0700 scsi: qla2xxx: Fix message indicating vectors used by driver [ Upstream commit da48b82425b8bf999fb9f7c220e967c4d661b5f8 ] This patch updates log message which indicates number of vectors used by the driver instead of displaying failure to get maximum requested vectors. Driver will always request maximum vectors during initialization. In the event driver is not able to get maximum requested vectors, it will adjust the allocated vectors. This is normal and does not imply failure in driver. Signed-off-by: Himanshu Madhani Reviewed-by: Ewan D. Milne Reviewed-by: Lee Duncan Link: https://lore.kernel.org/r/20190830222402.23688-2-hmadhani@marvell.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit c7f6acfc80f033f233f3e0b9ca5f6e435d8d0c5a Author: Martin Wilck Date: Wed Aug 14 13:28:27 2019 +0000 scsi: qla2xxx: qla2x00_alloc_fw_dump: set ha->eft [ Upstream commit edbd56472a636ab396f5ee6783e8438fa725a6ee ] In qla2x00_alloc_fw_dump(), an existing EFT buffer (e.g. from previous invocation of qla2x00_alloc_offload_mem()) is freed. The buffer is then re-allocated, but without setting the eft and eft_dma fields to the new values. Fixes: a28d9e4ef997 ("scsi: qla2xxx: Add support for multiple fwdump templates/segments") Cc: Joe Carnuccio Cc: Quinn Tran Cc: Himanshu Madhani Cc: Bart Van Assche Signed-off-by: Martin Wilck Tested-by: Himanshu Madhani Reviewed-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit d4e12ee06db1ef66c97c6fd17ada38895c4282ca Author: Bart Van Assche Date: Thu Aug 8 20:02:10 2019 -0700 scsi: qla2xxx: Make sure that aborted commands are freed [ Upstream commit 0dcec41acb85da33841c2ab56dbf337ed00a3914 ] The LIO core requires that the target driver callback functions .queue_data_in() and .queue_status() call target_put_sess_cmd() or transport_generic_free_cmd(). These calls may happen synchronously or asynchronously. Make sure that one of these LIO functions is called in case a command has been aborted. This patch avoids that the code for removing a session hangs due to commands that do not make progress. Cc: Himanshu Madhani Fixes: 694833ee00c4 ("scsi: tcm_qla2xxx: Do not allow aborted cmd to advance.") # v4.13. Fixes: a07100e00ac4 ("qla2xxx: Fix TMR ABORT interaction issue between qla2xxx and TCM") # v4.5. Signed-off-by: Bart Van Assche Tested-by: Himanshu Madhani Reviewed-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 974552b2045a20a6e67765cc16937970b81dbccf Author: Bart Van Assche Date: Thu Aug 8 20:02:00 2019 -0700 scsi: qla2xxx: Check secondary image if reading the primary image fails [ Upstream commit 0597fe601a3a7d103c35b922046251906e0349b3 ] This patch fixes several Coverity complaints about reading data that has not been initialized. Cc: Himanshu Madhani Signed-off-by: Bart Van Assche Tested-by: Himanshu Madhani Reviewed-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 9161282efe6752a90b22a7f5f6e6c9c5e5b5e974 Author: Bart Van Assche Date: Thu Aug 8 20:01:52 2019 -0700 scsi: qla2xxx: Always check the qla2x00_wait_for_hba_online() return value [ Upstream commit e6803efae5acd109fad9f2f07dab674563441a53 ] This patch fixes several Coverity complaints about not always checking the qla2x00_wait_for_hba_online() return value. Cc: Himanshu Madhani Signed-off-by: Bart Van Assche Tested-by: Himanshu Madhani Reviewed-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 2461ad0fb97558e77563581ab94eb95cbf213932 Author: Bart Van Assche Date: Thu Aug 8 20:01:48 2019 -0700 scsi: qla2xxx: Fix qla24xx_process_bidir_cmd() [ Upstream commit c29282c65d1cf54daeea63be46243d7f69d72f4d ] Set the r??_data_len variables before using these instead of after. This patch fixes the following Coverity complaint: const: At condition req_data_len != rsp_data_len, the value of req_data_len must be equal to 0. const: At condition req_data_len != rsp_data_len, the value of rsp_data_len must be equal to 0. dead_error_condition: The condition req_data_len != rsp_data_len cannot be true. Cc: Himanshu Madhani Fixes: a9b6f722f62d ("[SCSI] qla2xxx: Implementation of bidirectional.") # v3.7. Signed-off-by: Bart Van Assche Tested-by: Himanshu Madhani Reviewed-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit ea09bb4a3b5ef4acd94afcedec1afe902a061d91 Author: Bart Van Assche Date: Thu Aug 8 20:01:40 2019 -0700 scsi: qla2xxx: Fix session lookup in qlt_abort_work() [ Upstream commit ac452b8e79320c9e90c78edf32ba2d42431e4daf ] Pass the correct session ID to find_sess_by_s_id() instead of passing an uninitialized variable. Cc: Himanshu Madhani Fixes: 2d70c103fd2a ("[SCSI] qla2xxx: Add LLD target-mode infrastructure for >= 24xx series") # v3.5. Signed-off-by: Bart Van Assche Tested-by: Himanshu Madhani Reviewed-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 64549a2ecb8222fbd7f5a23bbcb9ffaf10f51767 Author: Bart Van Assche Date: Thu Aug 8 20:01:23 2019 -0700 scsi: qla2xxx: Really fix qla2xxx_eh_abort() [ Upstream commit 8dd9593cc07ad7d999bef81b06789ef873a94881 ] I'm not sure how this happened but the patch that was intended to fix abort handling was incomplete. This patch fixes that patch as follows: - If aborting the SCSI command failed, wait until the SCSI command completes. - Return SUCCESS instead of FAILED if an abort attempt races with SCSI command completion. - Since qla2xxx_eh_abort() increments the sp reference count by calling sp_get(), decrement the sp reference count before returning. Cc: Himanshu Madhani Fixes: 219d27d7147e ("scsi: qla2xxx: Fix race conditions in the code for aborting SCSI commands") Signed-off-by: Bart Van Assche Tested-by: Himanshu Madhani Reviewed-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 97ba2bec3aa329a62de3f51b95c08f70e6208aee Author: Bart Van Assche Date: Thu Aug 8 20:01:22 2019 -0700 scsi: qla2xxx: Make qla2x00_abort_srb() again decrease the sp reference count [ Upstream commit d2d2b5a5741d317bed1fa38211f1f3b142d8cf7a ] Since qla2x00_abort_srb() starts with increasing the reference count of @sp, decrease that same reference count before returning. Cc: Himanshu Madhani Fixes: 219d27d7147e ("scsi: qla2xxx: Fix race conditions in the code for aborting SCSI commands") # v5.2. Signed-off-by: Bart Van Assche Tested-by: Himanshu Madhani Reviewed-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e64665e1d55fbca9bf82809f5e7349160ffcc9e2 Author: Quinn Tran Date: Fri Jul 26 09:07:38 2019 -0700 scsi: qla2xxx: Fix hang in fcport delete path [ Upstream commit f00b3428a801758243693e046b34226e92bc56b3 ] A hang was observed in the fcport delete path when the device was responding slow and an issue-lip path (results in session termination) was taken. Fix this by issuing logo requests unconditionally. PID: 19491 TASK: ffff8e23e67bb150 CPU: 0 COMMAND: "kworker/0:0" #0 [ffff8e2370297bf8] __schedule at ffffffffb4f7dbb0 #1 [ffff8e2370297c88] schedule at ffffffffb4f7e199 #2 [ffff8e2370297c98] schedule_timeout at ffffffffb4f7ba68 #3 [ffff8e2370297d40] msleep at ffffffffb48ad9ff #4 [ffff8e2370297d58] qlt_free_session_done at ffffffffc0c32052 [qla2xxx] #5 [ffff8e2370297e20] process_one_work at ffffffffb48bcfdf #6 [ffff8e2370297e68] worker_thread at ffffffffb48bdca6 #7 [ffff8e2370297ec8] kthread at ffffffffb48c4f81 Signed-off-by: Quinn Tran Signed-off-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a9ca74e0fbb55851de2549a75a9e635ca2c35ff6 Author: Arun Easi Date: Fri Jul 26 09:07:36 2019 -0700 scsi: qla2xxx: Fix NVMe port discovery after a short device port loss [ Upstream commit 9e744591ef1b8df27c25c68dac858dada8688f77 ] The following sequence of event leads to NVME port disappearing: - device port shut - nvme_fc_unregister_remoteport - device port online - remote port delete completes - relogin is scheduled - "post gidpn" message appears due to rscn generation # mismatch In short, if a device comes back online sooner than an unregister completion, a mismatch in rscn generation number occurs, which is not handled correctly during device relogin. Fix this by starting with a redo of GNL. When ql2xextended_error_logging is enabled, the re-plugged device's discovery stops with the following messages printed: --8<-- qla2xxx [0000:41:00.0]-480d:3: Relogin scheduled. qla2xxx [0000:41:00.0]-4800:3: DPC handler sleeping. qla2xxx [0000:41:00.0]-2902:3: qla24xx_handle_relogin_event 21:00:00:24:ff:17:9e:91 DS 0 LS 7 P 0 del 2 cnfl (null) rscn 1|2 login 1|2 fl 1 qla2xxx [0000:41:00.0]-28e9:3: qla24xx_handle_relogin_event 1666 21:00:00:24:ff:17:9e:91 post gidpn qla2xxx [0000:41:00.0]-480e:3: Relogin end. --8<-- Signed-off-by: Arun Easi Signed-off-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 0ae32925b04960e40f0dbc1ce3246b8c3ca7c7b3 Author: Quinn Tran Date: Fri Jul 26 09:07:27 2019 -0700 scsi: qla2xxx: Fix different size DMA Alloc/Unmap [ Upstream commit d376dbda187317d06d3a2d495b43a7983e4a3250 ] [ 17.177276] qla2xxx 0000:05:00.0: DMA-API: device driver frees DMA memory with different size [device address=0x00000006198b0000] [map size=32784 bytes] [unmap size=8208 bytes] [ 17.177390] RIP: 0010:check_unmap+0x7a2/0x1750 [ 17.177425] Call Trace: [ 17.177438] debug_dma_free_coherent+0x1b5/0x2d5 [ 17.177470] dma_free_attrs+0x7f/0x140 [ 17.177489] qla24xx_sp_unmap+0x1e2/0x610 [qla2xxx] [ 17.177509] qla24xx_async_gnnft_done+0x9c6/0x17d0 [qla2xxx] [ 17.177535] qla2x00_do_work+0x514/0x2200 [qla2xxx] Fixes: b5f3bc39a0e8 ("scsi: qla2xxx: Fix inconsistent DMA mem alloc/free") Signed-off-by: Quinn Tran Signed-off-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 02cef303f06abf9be359b1df589166c763aa01b6 Author: Himanshu Madhani Date: Fri Jul 26 09:07:26 2019 -0700 scsi: qla2xxx: Fix DMA unmap leak [ Upstream commit 5d328de64d89400dcf9911125844d8adc0db697f ] With debug kernel we see following wanings indicating memory leak. [28809.523959] WARNING: CPU: 3 PID: 6790 at lib/dma-debug.c:978 dma_debug_device_change+0x166/0x1d0 [28809.523964] pci 0000:0c:00.6: DMA-API: device driver has pending DMA allocations while released from device [count=5] [28809.523964] One of leaked entries details: [device address=0x00000002aefe4000] [size=8208 bytes] [mapped with DMA_BIDIRECTIONAL] [mapped as coherent] Fix this by unmapping DMA memory. Signed-off-by: Quinn Tran Signed-off-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 13f9f56890059ed917de6aa18cfa7c1b66c4d07d Author: Quinn Tran Date: Fri Jul 26 09:07:33 2019 -0700 scsi: qla2xxx: Fix premature timer expiration [ Upstream commit 3a4b6cc7332130ac5cbf3b505d8cddf0aa2ea745 ] For any qla2xxx async command, the SRB buffer is used to send it. In setting up the SRB buffer, the timer for this command is started before all memory allocation has finished. Under low memory pressure, memory alloc can go to sleep and not wake up before the timer expires. Once timer has expired, the timer thread will access uninitialize fields resulting into NULL pointer crash. This patch fixes this crash by moving the start of timer after everything is setup. backtrace shows following PID: 3720 TASK: ffff996928401040 CPU: 0 COMMAND: "qla2xxx_1_dpc" 0 [ffff99652751b698] __schedule at ffffffff965676c7 1 [ffff99652751b728] schedule at ffffffff96567bc9 2 [ffff99652751b738] schedule_timeout at ffffffff965655e8 3 [ffff99652751b7e0] io_schedule_timeout at ffffffff9656726d 4 [ffff99652751b810] congestion_wait at ffffffff95fd8d12 5 [ffff99652751b870] isolate_migratepages_range at ffffffff95fddaf3 6 [ffff99652751b930] compact_zone at ffffffff95fdde96 7 [ffff99652751b980] compact_zone_order at ffffffff95fde0bc 8 [ffff99652751ba20] try_to_compact_pages at ffffffff95fde481 9 [ffff99652751ba80] __alloc_pages_direct_compact at ffffffff9655cc31 10 [ffff99652751bae0] __alloc_pages_slowpath at ffffffff9655d101 11 [ffff99652751bbd0] __alloc_pages_nodemask at ffffffff95fc0e95 12 [ffff99652751bc80] dma_generic_alloc_coherent at ffffffff95e3217f 13 [ffff99652751bcc8] x86_swiotlb_alloc_coherent at ffffffff95e6b7a1 14 [ffff99652751bcf8] qla2x00_rft_id at ffffffffc055b5e0 [qla2xxx] 15 [ffff99652751bd50] qla2x00_loop_resync at ffffffffc0533e71 [qla2xxx] 16 [ffff99652751be68] qla2x00_do_dpc at ffffffffc05210ca [qla2xxx] PID: 0 TASK: ffffffff96a18480 CPU: 0 COMMAND: "swapper/0" 0 [ffff99652fc03ae0] machine_kexec at ffffffff95e63674 1 [ffff99652fc03b40] __crash_kexec at ffffffff95f1ce12 2 [ffff99652fc03c10] crash_kexec at ffffffff95f1cf00 3 [ffff99652fc03c28] oops_end at ffffffff9656c758 4 [ffff99652fc03c50] no_context at ffffffff9655aa7e 5 [ffff99652fc03ca0] __bad_area_nosemaphore at ffffffff9655ab15 6 [ffff99652fc03cf0] bad_area_nosemaphore at ffffffff9655ac86 7 [ffff99652fc03d00] __do_page_fault at ffffffff9656f6b0 8 [ffff99652fc03d70] do_page_fault at ffffffff9656f915 9 [ffff99652fc03da0] page_fault at ffffffff9656b758 [exception RIP: unknown or invalid address] RIP: 0000000000000000 RSP: ffff99652fc03e50 RFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff99652b79a600 RCX: ffff99652b79a760 RDX: ffff99652b79a600 RSI: ffffffffc0525ad0 RDI: ffff99652b79a600 RBP: ffff99652fc03e60 R8: ffffffff96a18a18 R9: ffffffff96ee3c00 R10: 0000000000000002 R11: ffff99652fc03de8 R12: ffff99652b79a760 R13: 0000000000000100 R14: ffffffffc0525ad0 R15: ffff99652b79a600 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 10 [ffff99652fc03e50] qla2x00_sp_timeout at ffffffffc0525af8 [qla2xxx] 11 [ffff99652fc03e68] call_timer_fn at ffffffff95ea7f58 12 [ffff99652fc03ea0] run_timer_softirq at ffffffff95eaa3bd 13 [ffff99652fc03f18] __do_softirq at ffffffff95ea0f05 14 [ffff99652fc03f88] call_softirq at ffffffff9657832c 15 [ffff99652fc03fa0] do_softirq at ffffffff95e2e675 16 [ffff99652fc03fc0] irq_exit at ffffffff95ea1285 17 [ffff99652fc03fd8] smp_apic_timer_interrupt at ffffffff965796c8 18 [ffff99652fc03ff0] apic_timer_interrupt at ffffffff96575df2 Signed-off-by: Quinn Tran Signed-off-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 457173c8b43ecd3ac48c8ace8d4437a50f7ad77b Author: Quinn Tran Date: Tue Nov 5 07:06:51 2019 -0800 scsi: qla2xxx: Do command completion on abort timeout [ Upstream commit 71c80b75ce8f08c0978ce9a9816b81b5c3ce5e12 ] On switch, fabric and mgt command timeout, driver send Abort to tell FW to return the original command. If abort is timeout, then return both Abort and original command for cleanup. Fixes: 219d27d7147e0 ("scsi: qla2xxx: Fix race conditions in the code for aborting SCSI commands") Cc: stable@vger.kernel.org # 5.2 Link: https://lore.kernel.org/r/20191105150657.8092-3-hmadhani@marvell.com Reviewed-by: Ewan D. Milne Signed-off-by: Quinn Tran Signed-off-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit d863b40cc143e348ac5aa6489d3292eaa9073c01 Author: Quinn Tran Date: Fri Jul 26 09:07:28 2019 -0700 scsi: qla2xxx: Fix abort timeout race condition. [ Upstream commit 0c6df59061b23c7a951836d23977be34e896d3da ] If an abort times out, the Abort IOCB completion and Abort timer can race against each other. This patch provides unique error code for timer path to allow proper cleanup. [mkp: typo] Signed-off-by: Quinn Tran Signed-off-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 300ad69446e3383e546dde8035af12f87bd8feef Author: James Smart Date: Fri Oct 18 14:18:21 2019 -0700 scsi: lpfc: Fix bad ndlp ptr in xri aborted handling [ Upstream commit 324e1c402069e8d277d2a2b18ce40bde1265b96a ] In cases where I/O may be aborted, such as driver unload or link bounces, the system will crash based on a bad ndlp pointer. Example: RIP: 0010:lpfc_sli4_abts_err_handler+0x15/0x140 [lpfc] ... lpfc_sli4_io_xri_aborted+0x20d/0x270 [lpfc] lpfc_sli4_sp_handle_abort_xri_wcqe.isra.54+0x84/0x170 [lpfc] lpfc_sli4_fp_handle_cqe+0xc2/0x480 [lpfc] __lpfc_sli4_process_cq+0xc6/0x230 [lpfc] __lpfc_sli4_hba_process_cq+0x29/0xc0 [lpfc] process_one_work+0x14c/0x390 Crash was caused by a bad ndlp address passed to I/O indicated by the XRI aborted CQE. The address was not NULL so the routine deferenced the ndlp ptr. The bad ndlp also caused the lpfc_sli4_io_xri_aborted to call an erroneous io handler. Root cause for the bad ndlp was an lpfc_ncmd that was aborted, put on the abort_io list, completed, taken off the abort_io list, sent to lpfc_release_nvme_buf where it was put back on the abort_io list because the lpfc_ncmd->flags setting LPFC_SBUF_XBUSY was not cleared on the final completion. Rework the exchange busy handling to ensure the flags are properly set for both scsi and nvme. Fixes: c490850a0947 ("scsi: lpfc: Adapt partitioned XRI lists to efficient sharing") Cc: # v5.1+ Link: https://lore.kernel.org/r/20191018211832.7917-6-jsmart2021@gmail.com Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 3f162625c49739c2f3c5e26e64d59f487c47b492 Author: Jeff Mahoney Date: Thu Oct 24 10:31:27 2019 -0400 reiserfs: fix extended attributes on the root directory commit 60e4cf67a582d64f07713eda5fcc8ccdaf7833e6 upstream. Since commit d0a5b995a308 (vfs: Add IOP_XATTR inode operations flag) extended attributes haven't worked on the root directory in reiserfs. This is due to reiserfs conditionally setting the sb->s_xattrs handler array depending on whether it located or create the internal privroot directory. It necessarily does this after the root inode is already read in. The IOP_XATTR flag is set during inode initialization, so it never gets set on the root directory. This commit unconditionally assigns sb->s_xattrs and clears IOP_XATTR on internal inodes. The old return values due to the conditional assignment are handled via open_xa_root, which now returns EOPNOTSUPP as the VFS would have done. Link: https://lore.kernel.org/r/20191024143127.17509-1-jeffm@suse.com CC: stable@vger.kernel.org Fixes: d0a5b995a308 ("vfs: Add IOP_XATTR inode operations flag") Signed-off-by: Jeff Mahoney Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 4ea8b55f7b4a40c92afbd025dfc4332768d869fa Author: Jan Kara Date: Tue Nov 5 17:44:12 2019 +0100 ext4: Fix credit estimate for final inode freeing commit 65db869c754e7c271691dd5feabf884347e694f5 upstream. Estimate for the number of credits needed for final freeing of inode in ext4_evict_inode() was to small. We may modify 4 blocks (inode & sb for orphan deletion, bitmap & group descriptor for inode freeing) and not just 3. [ Fixed minor whitespace nit. -- TYT ] Fixes: e50e5129f384 ("ext4: xattr-in-inode support") CC: stable@vger.kernel.org Signed-off-by: Jan Kara Link: https://lore.kernel.org/r/20191105164437.32602-6-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 0739013bf4decc714eb2d8424068c8b60f012f08 Author: Dmitry Monakhov Date: Thu Oct 31 10:39:19 2019 +0000 quota: fix livelock in dquot_writeback_dquots commit 6ff33d99fc5c96797103b48b7b0902c296f09c05 upstream. Write only quotas which are dirty at entry. XFSTEST: https://github.com/dmonakhov/xfstests/commit/b10ad23566a5bf75832a6f500e1236084083cddc Link: https://lore.kernel.org/r/20191031103920.3919-1-dmonakhov@openvz.org CC: stable@vger.kernel.org Signed-off-by: Konstantin Khlebnikov Signed-off-by: Dmitry Monakhov Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit f6538c6cf0f5d86503e6a8b7f26211f72431ec5a Author: Christian Brauner Date: Fri Sep 20 10:30:06 2019 +0200 seccomp: avoid overflow in implicit constant conversion commit 223e660bc7638d126a0e4fbace4f33f2895788c4 upstream. USER_NOTIF_MAGIC is assigned to int variables in this test so set it to INT_MAX to avoid warnings: seccomp_bpf.c: In function ‘user_notification_continue’: seccomp_bpf.c:3088:26: warning: overflow in implicit constant conversion [-Woverflow] #define USER_NOTIF_MAGIC 116983961184613L ^ seccomp_bpf.c:3572:15: note: in expansion of macro ‘USER_NOTIF_MAGIC’ resp.error = USER_NOTIF_MAGIC; ^~~~~~~~~~~~~~~~ Fixes: 6a21cc50f0c7 ("seccomp: add a return code to trap to userspace") Signed-off-by: Christian Brauner Reviewed-by: Tyler Hicks Cc: Andy Lutomirski Cc: Will Drewry Cc: Shuah Khan Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: Martin KaFai Lau Cc: Song Liu Cc: Yonghong Song Cc: Tycho Andersen Cc: stable@vger.kernel.org Cc: linux-kselftest@vger.kernel.org Cc: netdev@vger.kernel.org Cc: bpf@vger.kernel.org Reviewed-by: Tycho Andersen Link: https://lore.kernel.org/r/20190920083007.11475-3-christian.brauner@ubuntu.com Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman commit e1a9edb33fc50c6304f58c57494ea347d1253f1b Author: Chengguang Xu Date: Tue Nov 5 12:51:00 2019 +0800 ext2: check err when partial != NULL commit e705f4b8aa27a59f8933e8f384e9752f052c469c upstream. Check err when partial == NULL is meaningless because partial == NULL means getting branch successfully without error. CC: stable@vger.kernel.org Link: https://lore.kernel.org/r/20191105045100.7104-1-cgxu519@mykernel.net Signed-off-by: Chengguang Xu Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 39cc95ae4ffa354d1268ede4ee62761a6663e16d Author: Dmitry Monakhov Date: Thu Oct 31 10:39:20 2019 +0000 quota: Check that quota is not dirty before release commit df4bb5d128e2c44848aeb36b7ceceba3ac85080d upstream. There is a race window where quota was redirted once we drop dq_list_lock inside dqput(), but before we grab dquot->dq_lock inside dquot_release() TASK1 TASK2 (chowner) ->dqput() we_slept: spin_lock(&dq_list_lock) if (dquot_dirty(dquot)) { spin_unlock(&dq_list_lock); dquot->dq_sb->dq_op->write_dquot(dquot); goto we_slept if (test_bit(DQ_ACTIVE_B, &dquot->dq_flags)) { spin_unlock(&dq_list_lock); dquot->dq_sb->dq_op->release_dquot(dquot); dqget() mark_dquot_dirty() dqput() goto we_slept; } So dquot dirty quota will be released by TASK1, but on next we_sleept loop we detect this and call ->write_dquot() for it. XFSTEST: https://github.com/dmonakhov/xfstests/commit/440a80d4cbb39e9234df4d7240aee1d551c36107 Link: https://lore.kernel.org/r/20191031103920.3919-2-dmonakhov@openvz.org CC: stable@vger.kernel.org Signed-off-by: Dmitry Monakhov Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 1261d39df3077154478b219da00cfcba8dd42396 Author: Ville Syrjälä Date: Thu Sep 19 16:28:53 2019 +0300 video/hdmi: Fix AVI bar unpack commit 6039f37dd6b76641198e290f26b31c475248f567 upstream. The bar values are little endian, not big endian. The pack function did it right but the unpack got it wrong. Fix it. Cc: stable@vger.kernel.org Cc: linux-media@vger.kernel.org Cc: Martin Bugge Cc: Hans Verkuil Cc: Thierry Reding Cc: Mauro Carvalho Chehab Fixes: 2c676f378edb ("[media] hdmi: added unpack and logging functions for InfoFrames") Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20190919132853.30954-1-ville.syrjala@linux.intel.com Reviewed-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit 77622a16ebf0034f72a70fe07bd7f8d935ffec47 Author: Cédric Le Goater Date: Tue Dec 3 17:36:42 2019 +0100 powerpc/xive: Skip ioremap() of ESB pages for LSI interrupts commit b67a95f2abff0c34e5667c15ab8900de73d8d087 upstream. The PCI INTx interrupts and other LSI interrupts are handled differently under a sPAPR platform. When the interrupt source characteristics are queried, the hypervisor returns an H_INT_ESB flag to inform the OS that it should be using the H_INT_ESB hcall for interrupt management and not loads and stores on the interrupt ESB pages. A default -1 value is returned for the addresses of the ESB pages. The driver ignores this condition today and performs a bogus IO mapping. Recent changes and the DEBUG_VM configuration option make the bug visible with : kernel BUG at arch/powerpc/include/asm/book3s/64/pgtable.h:612! Oops: Exception in kernel mode, sig: 5 [#1] LE PAGE_SIZE=64K MMU=Radix MMU=Hash SMP NR_CPUS=1024 NUMA pSeries Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.4.0-0.rc6.git0.1.fc32.ppc64le #1 NIP: c000000000f63294 LR: c000000000f62e44 CTR: 0000000000000000 REGS: c0000000fa45f0d0 TRAP: 0700 Not tainted (5.4.0-0.rc6.git0.1.fc32.ppc64le) ... NIP ioremap_page_range+0x4c4/0x6e0 LR ioremap_page_range+0x74/0x6e0 Call Trace: ioremap_page_range+0x74/0x6e0 (unreliable) do_ioremap+0x8c/0x120 __ioremap_caller+0x128/0x140 ioremap+0x30/0x50 xive_spapr_populate_irq_data+0x170/0x260 xive_irq_domain_map+0x8c/0x170 irq_domain_associate+0xb4/0x2d0 irq_create_mapping+0x1e0/0x3b0 irq_create_fwspec_mapping+0x27c/0x3e0 irq_create_of_mapping+0x98/0xb0 of_irq_parse_and_map_pci+0x168/0x230 pcibios_setup_device+0x88/0x250 pcibios_setup_bus_devices+0x54/0x100 __of_scan_bus+0x160/0x310 pcibios_scan_phb+0x330/0x390 pcibios_init+0x8c/0x128 do_one_initcall+0x60/0x2c0 kernel_init_freeable+0x290/0x378 kernel_init+0x2c/0x148 ret_from_kernel_thread+0x5c/0x80 Fixes: bed81ee181dd ("powerpc/xive: introduce H_INT_ESB hcall") Cc: stable@vger.kernel.org # v4.14+ Signed-off-by: Cédric Le Goater Tested-by: Daniel Axtens Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191203163642.2428-1-clg@kaod.org Signed-off-by: Greg Kroah-Hartman commit c9367c0a7d2c34d4fe0173fdf513444f9777ab74 Author: Alastair D'Silva Date: Mon Nov 4 13:32:53 2019 +1100 powerpc: Allow flush_icache_range to work across ranges >4GB commit 29430fae82073d39b1b881a3cd507416a56a363f upstream. When calling flush_icache_range with a size >4GB, we were masking off the upper 32 bits, so we would incorrectly flush a range smaller than intended. This patch replaces the 32 bit shifts with 64 bit ones, so that the full size is accounted for. Signed-off-by: Alastair D'Silva Cc: stable@vger.kernel.org Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191104023305.9581-2-alastair@au1.ibm.com Signed-off-by: Greg Kroah-Hartman commit ba8dd5a468730c01f702783a08317a405d706c1b Author: Cédric Le Goater Date: Thu Oct 31 07:31:00 2019 +0100 powerpc/xive: Prevent page fault issues in the machine crash handler commit 1ca3dec2b2dff9d286ce6cd64108bda0e98f9710 upstream. When the machine crash handler is invoked, all interrupts are masked but interrupts which have not been started yet do not have an ESB page mapped in the Linux address space. This crashes the 'crash kexec' sequence on sPAPR guests. To fix, force the mapping of the ESB page when an interrupt is being mapped in the Linux IRQ number space. This is done by setting the initial state of the interrupt to OFF which is not necessarily the case on PowerNV. Fixes: 243e25112d06 ("powerpc/xive: Native exploitation of the XIVE interrupt controller") Cc: stable@vger.kernel.org # v4.12+ Signed-off-by: Cédric Le Goater Reviewed-by: Greg Kurz Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191031063100.3864-1-clg@kaod.org Signed-off-by: Greg Kroah-Hartman commit e05c9d352ea11acce01b18f1ef701dbbcc638f47 Author: Alastair D'Silva Date: Mon Nov 4 13:32:54 2019 +1100 powerpc: Allow 64bit VDSO __kernel_sync_dicache to work across ranges >4GB commit f9ec11165301982585e5e5f606739b5bae5331f3 upstream. When calling __kernel_sync_dicache with a size >4GB, we were masking off the upper 32 bits, so we would incorrectly flush a range smaller than intended. This patch replaces the 32 bit shifts with 64 bit ones, so that the full size is accounted for. Signed-off-by: Alastair D'Silva Cc: stable@vger.kernel.org Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191104023305.9581-3-alastair@au1.ibm.com Signed-off-by: Greg Kroah-Hartman commit 5fa3bd392ddb829421d8a3491c2b16b5ff8b07f8 Author: Yabin Cui Date: Mon Nov 4 11:12:50 2019 -0700 coresight: Serialize enabling/disabling a link device. commit edda32dabedb01f98b9d7b9a4492c13357834bbe upstream. When tracing etm data of multiple threads on multiple cpus through perf interface, some link devices are shared between paths of different cpus. It creates race conditions when different cpus wants to enable/disable the same link device at the same time. Example 1: Two cpus want to enable different ports of a coresight funnel, thus calling the funnel enable operation at the same time. But the funnel enable operation isn't reentrantable. Example 2: For an enabled coresight dynamic replicator with refcnt=1, one cpu wants to disable it, while another cpu wants to enable it. Ideally we still have an enabled replicator with refcnt=1 at the end. But in reality the result is uncertain. Since coresight devices claim themselves when enabled for self-hosted usage, the race conditions above usually make the link devices not usable after many cycles. To fix the race conditions, this patch uses spinlocks to serialize enabling/disabling link devices. Fixes: a06ae8609b3d ("coresight: add CoreSight core layer framework") Signed-off-by: Yabin Cui Signed-off-by: Mathieu Poirier Cc: stable # 5.3 Link: https://lore.kernel.org/r/20191104181251.26732-14-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman commit 0df9e964c9a5c7565e2803ad9876000195815b45 Author: Alexander Shishkin Date: Thu Nov 14 08:42:00 2019 +0200 stm class: Lose the protocol driver when dropping its reference commit 0a8f72fafb3f72a08df4ee491fcbeaafd6de85fd upstream. Commit c7fd62bc69d02 ("stm class: Introduce framing protocol drivers") forgot to tear down the link between an stm device and its protocol driver when policy is removed. This leads to an invalid pointer reference if one tries to write to an stm device after the policy has been removed and the protocol driver module unloaded, leading to the below splat: > BUG: unable to handle page fault for address: ffffffffc0737068 > #PF: supervisor read access in kernel mode > #PF: error_code(0x0000) - not-present page > PGD 3d780f067 P4D 3d780f067 PUD 3d7811067 PMD 492781067 PTE 0 > Oops: 0000 [#1] SMP NOPTI > CPU: 1 PID: 26122 Comm: cat Not tainted 5.4.0-rc5+ #1 > RIP: 0010:stm_output_free+0x40/0xc0 [stm_core] > Call Trace: > stm_char_release+0x3e/0x70 [stm_core] > __fput+0xc6/0x260 > ____fput+0xe/0x10 > task_work_run+0x9d/0xc0 > exit_to_usermode_loop+0x103/0x110 > do_syscall_64+0x19d/0x1e0 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fix this by tearing down the link from an stm device to its protocol driver when the policy involving that driver is removed. Signed-off-by: Alexander Shishkin Fixes: c7fd62bc69d02 ("stm class: Introduce framing protocol drivers") Reported-by: Ammy Yi Tested-by: Ammy Yi CC: stable@vger.kernel.org # v4.20+ Link: https://lore.kernel.org/r/20191114064201.43089-2-alexander.shishkin@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 450f540c12079264ea549409dbd7613f0988aabb Author: Arnd Bergmann Date: Fri Nov 8 21:34:30 2019 +0100 ppdev: fix PPGETTIME/PPSETTIME ioctls commit 998174042da229e2cf5841f574aba4a743e69650 upstream. Going through the uses of timeval in the user space API, I noticed two bugs in ppdev that were introduced in the y2038 conversion: * The range check was accidentally moved from ppsettime to ppgettime * On sparc64, the microseconds are in the other half of the 64-bit word. Fix both, and mark the fix for stable backports. Cc: stable@vger.kernel.org Fixes: 3b9ab374a1e6 ("ppdev: convert to y2038 safe") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20191108203435.112759-8-arnd@arndb.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 27598f27021bd630b46729808cb86aae8f1f0d92 Author: Bart Van Assche Date: Fri Oct 25 15:58:27 2019 -0700 RDMA/core: Fix ib_dma_max_seg_size() commit ecdfdfdbe4d4c74029f2b416b7ee6d0aeb56364a upstream. If dev->dma_device->params == NULL then the maximum DMA segment size is 64 KB. See also the dma_get_max_seg_size() implementation. This patch fixes the following kernel warning: DMA-API: infiniband rxe0: mapping sg segment longer than device claims to support [len=126976] [max=65536] WARNING: CPU: 4 PID: 4848 at kernel/dma/debug.c:1220 debug_dma_map_sg+0x3d9/0x450 RIP: 0010:debug_dma_map_sg+0x3d9/0x450 Call Trace: srp_queuecommand+0x626/0x18d0 [ib_srp] scsi_queue_rq+0xd02/0x13e0 [scsi_mod] __blk_mq_try_issue_directly+0x2b3/0x3f0 blk_mq_request_issue_directly+0xac/0xf0 blk_insert_cloned_request+0xdf/0x170 dm_mq_queue_rq+0x43d/0x830 [dm_mod] __blk_mq_try_issue_directly+0x2b3/0x3f0 blk_mq_request_issue_directly+0xac/0xf0 blk_mq_try_issue_list_directly+0xb8/0x170 blk_mq_sched_insert_requests+0x23c/0x3b0 blk_mq_flush_plug_list+0x529/0x730 blk_flush_plug_list+0x21f/0x260 blk_mq_make_request+0x56b/0xf20 generic_make_request+0x196/0x660 submit_bio+0xae/0x290 blkdev_direct_IO+0x822/0x900 generic_file_direct_write+0x110/0x200 __generic_file_write_iter+0x124/0x2a0 blkdev_write_iter+0x168/0x270 aio_write+0x1c4/0x310 io_submit_one+0x971/0x1390 __x64_sys_io_submit+0x12a/0x390 do_syscall_64+0x6f/0x2e0 entry_SYSCALL_64_after_hwframe+0x49/0xbe Link: https://lore.kernel.org/r/20191025225830.257535-2-bvanassche@acm.org Cc: Fixes: 0b5cb3300ae5 ("RDMA/srp: Increase max_segment_size") Signed-off-by: Bart Van Assche Reviewed-by: Jason Gunthorpe Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 32b9e6e1c5d36f6cc246a8220ffef2b30c5d5912 Author: Jarkko Nikula Date: Sat Nov 16 17:16:51 2019 +0200 ARM: dts: omap3-tao3530: Fix incorrect MMC card detection GPIO polarity commit 287897f9aaa2ad1c923d9875914f57c4dc9159c8 upstream. The MMC card detection GPIO polarity is active low on TAO3530, like in many other similar boards. Now the card is not detected and it is unable to mount rootfs from an SD card. Fix this by using the correct polarity. This incorrect polarity was defined already in the commit 30d95c6d7092 ("ARM: dts: omap3: Add Technexion TAO3530 SOM omap3-tao3530.dtsi") in v3.18 kernel and later changed to use defined GPIO constants in v4.4 kernel by the commit 3a637e008e54 ("ARM: dts: Use defined GPIO constants in flags cell for OMAP2+ boards"). While the latter commit did not introduce the issue I'm marking it with Fixes tag due the v4.4 kernels still being maintained. Fixes: 3a637e008e54 ("ARM: dts: Use defined GPIO constants in flags cell for OMAP2+ boards") Cc: linux-stable # 4.4+ Signed-off-by: Jarkko Nikula Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit 3a89bb354c23d25b19aa98010a713c467b9c00b4 Author: H. Nikolaus Schaller Date: Thu Nov 7 11:30:37 2019 +0100 mmc: host: omap_hsmmc: add code for special init of wl1251 to get rid of pandora_wl1251_init_card commit f6498b922e57aecbe3b7fa30a308d9d586c0c369 upstream. Pandora_wl1251_init_card was used to do special pdata based setup of the sdio mmc interface. This does no longer work with v4.7 and later. A fix requires a device tree based mmc3 setup. Therefore we move the special setup to omap_hsmmc.c instead of calling some pdata supplied init_card function. The new code checks for a DT child node compatible to wl1251 so it will not affect other MMC3 use cases. Generally, this code was and still is a hack and should be moved to mmc core to e.g. read such properties from optional DT child nodes. Fixes: 81eef6ca9201 ("mmc: omap_hsmmc: Use dma_request_chan() for requesting DMA channel") Signed-off-by: H. Nikolaus Schaller Cc: # v4.7+ [Ulf: Fixed up some checkpatch complaints] Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit e6177192e58af175f7c5f2574b6c3ce9f2537a52 Author: Krzysztof Kozlowski Date: Mon Aug 5 18:27:09 2019 +0200 pinctrl: samsung: Fix device node refcount leaks in S3C64xx wakeup controller init commit 7f028caadf6c37580d0f59c6c094ed09afc04062 upstream. In s3c64xx_eint_eint0_init() the for_each_child_of_node() loop is used with a break to find a matching child node. Although each iteration of for_each_child_of_node puts the previous node, but early exit from loop misses it. This leads to leak of device node. Cc: Fixes: 61dd72613177 ("pinctrl: Add pinctrl-s3c64xx driver") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit 803d65af07af00dcd4a7da3c2efb034a01de3a2c Author: Krzysztof Kozlowski Date: Mon Aug 5 18:27:10 2019 +0200 pinctrl: samsung: Fix device node refcount leaks in init code commit a322b3377f4bac32aa25fb1acb9e7afbbbbd0137 upstream. Several functions use for_each_child_of_node() loop with a break to find a matching child node. Although each iteration of for_each_child_of_node puts the previous node, but early exit from loop misses it. This leads to leak of device node. Cc: Fixes: 9a2c1c3b91aa ("pinctrl: samsung: Allow grouping multiple pinmux/pinconf nodes") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit a598e6c1cf8f274708da99f4076ee3325e073d43 Author: Krzysztof Kozlowski Date: Mon Aug 5 18:27:08 2019 +0200 pinctrl: samsung: Fix device node refcount leaks in S3C24xx wakeup controller init commit 6fbbcb050802d6ea109f387e961b1dbcc3a80c96 upstream. In s3c24xx_eint_init() the for_each_child_of_node() loop is used with a break to find a matching child node. Although each iteration of for_each_child_of_node puts the previous node, but early exit from loop misses it. This leads to leak of device node. Cc: Fixes: af99a7507469 ("pinctrl: Add pinctrl-s3c24xx driver") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit c3c7b4fe3ce7d82ca575bc14262d33fe17f115ea Author: Krzysztof Kozlowski Date: Mon Aug 5 18:27:07 2019 +0200 pinctrl: samsung: Fix device node refcount leaks in Exynos wakeup controller init commit 5c7f48dd14e892e3e920dd6bbbd52df79e1b3b41 upstream. In exynos_eint_wkup_init() the for_each_child_of_node() loop is used with a break to find a matching child node. Although each iteration of for_each_child_of_node puts the previous node, but early exit from loop misses it. This leads to leak of device node. Cc: Fixes: 43b169db1841 ("pinctrl: add exynos4210 specific extensions for samsung pinctrl driver") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit bead8ece444e8b6cd13bc942eeefbdc86902beac Author: Nishka Dasgupta Date: Sun Aug 4 21:32:00 2019 +0530 pinctrl: samsung: Add of_node_put() before return in error path commit 3d2557ab75d4c568c79eefa2e550e0d80348a6bd upstream. Each iteration of for_each_child_of_node puts the previous node, but in the case of a return from the middle of the loop, there is no put, thus causing a memory leak. Hence add an of_node_put before the return of exynos_eint_wkup_init() error path. Issue found with Coccinelle. Signed-off-by: Nishka Dasgupta Cc: Fixes: 14c255d35b25 ("pinctrl: exynos: Add irq_chip instance for Exynos7 wakeup interrupts") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit 296afe48c341825dbd5bb860f9e33d7364849313 Author: Gregory CLEMENT Date: Fri Nov 15 16:57:52 2019 +0100 pinctrl: armada-37xx: Fix irq mask access in armada_37xx_irq_set_type() commit 04fb02757ae5188031eb71b2f6f189edb1caf5dc upstream. As explained in the following commit a9a1a4833613 ("pinctrl: armada-37xx: Fix gpio interrupt setup") the armada_37xx_irq_set_type() function can be called before the initialization of the mask field. That means that we can't use this field in this function and need to workaround it using hwirq. Fixes: 30ac0d3b0702 ("pinctrl: armada-37xx: Add edge both type gpio irq support") Cc: stable@vger.kernel.org Reported-by: Russell King Signed-off-by: Gregory CLEMENT Link: https://lore.kernel.org/r/20191115155752.2562-1-gregory.clement@bootlin.com Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit eda70005159b82f55284cb4912bdd681d3a4261f Author: Chris Brandt Date: Mon Sep 30 09:58:04 2019 -0500 pinctrl: rza2: Fix gpio name typos commit 930d3a4907ae6cdb476db23fc7caa86e9de1e557 upstream. Fix apparent copy/paste errors that were overlooked in the original driver. "P0_4" -> "PF_4" "P0_3" -> "PG_3" Fixes: b59d0e782706 ("pinctrl: Add RZ/A2 pin and gpio controller") Cc: Signed-off-by: Chris Brandt Link: https://lore.kernel.org/r/20190930145804.30497-1-chris.brandt@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman commit 9791c37fb347d515fd8ed70aac33ee78bea6831f Author: Rafael J. Wysocki Date: Wed Dec 4 02:54:27 2019 +0100 ACPI: PM: Avoid attaching ACPI PM domain to certain devices commit b9ea0bae260f6aae546db224daa6ac1bd9d94b91 upstream. Certain ACPI-enumerated devices represented as platform devices in Linux, like fans, require special low-level power management handling implemented by their drivers that is not in agreement with the ACPI PM domain behavior. That leads to problems with managing ACPI fans during system-wide suspend and resume. For this reason, make acpi_dev_pm_attach() skip the affected devices by adding a list of device IDs to avoid to it and putting the IDs of the affected devices into that list. Fixes: e5cc8ef31267 (ACPI / PM: Provide ACPI PM callback routines for subsystems) Reported-by: Zhang Rui Tested-by: Todd Brandt Cc: 3.10+ # 3.10+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit d506c19d1d5147b8744d113579576c2ff5c8fba3 Author: Vamshi K Sthambamkadi Date: Thu Nov 28 15:58:29 2019 +0530 ACPI: bus: Fix NULL pointer check in acpi_bus_get_private_data() commit 627ead724eff33673597216f5020b72118827de4 upstream. kmemleak reported backtrace: [] kmem_cache_alloc_trace+0x128/0x260 [<6677f215>] i2c_acpi_install_space_handler+0x4b/0xe0 [<1180f4fc>] i2c_register_adapter+0x186/0x400 [<6083baf7>] i2c_add_adapter+0x4e/0x70 [] intel_gmbus_setup+0x1a2/0x2c0 [i915] [<84cb69ae>] i915_driver_probe+0x8d8/0x13a0 [i915] [<81911d4b>] i915_pci_probe+0x48/0x160 [i915] [<4b159af1>] pci_device_probe+0xdc/0x160 [] really_probe+0x1ee/0x450 [] driver_probe_device+0x142/0x1b0 [] device_driver_attach+0x49/0x50 [] __driver_attach+0xc9/0x150 [] bus_for_each_dev+0x56/0xa0 [<80089bba>] driver_attach+0x19/0x20 [] bus_add_driver+0x177/0x220 [<7b29d8c7>] driver_register+0x56/0xf0 In i2c_acpi_remove_space_handler(), a leak occurs whenever the "data" parameter is initialized to 0 before being passed to acpi_bus_get_private_data(). This is because the NULL pointer check in acpi_bus_get_private_data() (condition->if(!*data)) returns EINVAL and, in consequence, memory is never freed in i2c_acpi_remove_space_handler(). Fix the NULL pointer check in acpi_bus_get_private_data() to follow the analogous check in acpi_get_data_full(). Signed-off-by: Vamshi K Sthambamkadi [ rjw: Subject & changelog ] Cc: All applicable Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit a417b52e69d65b0a52ad18ee64c3e261c28b7f98 Author: Francesco Ruggeri Date: Tue Nov 19 21:47:27 2019 -0800 ACPI: OSL: only free map once in osl.c commit 833a426cc471b6088011b3d67f1dc4e147614647 upstream. acpi_os_map_cleanup checks map->refcount outside of acpi_ioremap_lock before freeing the map. This creates a race condition the can result in the map being freed more than once. A panic can be caused by running for ((i=0; i<10; i++)) do for ((j=0; j<100000; j++)) do cat /sys/firmware/acpi/tables/data/BERT >/dev/null done & done This patch makes sure that only the process that drops the reference to 0 does the freeing. Fixes: b7c1fadd6c2e ("ACPI: Do not use krefs under a mutex in osl.c") Signed-off-by: Francesco Ruggeri Reviewed-by: Dmitry Safonov <0x7f454c46@gmail.com> Cc: All applicable Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 3af31d779c83a5256b5f032b7e86314245403ee0 Author: Mika Westerberg Date: Wed Oct 30 18:05:45 2019 +0300 ACPI / hotplug / PCI: Allocate resources directly under the non-hotplug bridge commit 77adf9355304f8dcf09054280af5e23fc451ab3d upstream. Valerio and others reported that commit 84c8b58ed3ad ("ACPI / hotplug / PCI: Don't scan bridges managed by native hotplug") prevents some recent LG and HP laptops from booting with endless loop of: ACPI Error: No handler or method for GPE 08, disabling event (20190215/evgpe-835) ACPI Error: No handler or method for GPE 09, disabling event (20190215/evgpe-835) ACPI Error: No handler or method for GPE 0A, disabling event (20190215/evgpe-835) ... What seems to happen is that during boot, after the initial PCI enumeration when EC is enabled the platform triggers ACPI Notify() to one of the root ports. The root port itself looks like this: pci 0000:00:1b.0: PCI bridge to [bus 02-3a] pci 0000:00:1b.0: bridge window [mem 0xc4000000-0xda0fffff] pci 0000:00:1b.0: bridge window [mem 0x80000000-0xa1ffffff 64bit pref] The BIOS has configured the root port so that it does not have I/O bridge window. Now when the ACPI Notify() is triggered ACPI hotplug handler calls acpiphp_native_scan_bridge() for each non-hotplug bridge (as this system is using native PCIe hotplug) and pci_assign_unassigned_bridge_resources() to allocate resources. The device connected to the root port is a PCIe switch (Thunderbolt controller) with two hotplug downstream ports. Because of the hotplug ports __pci_bus_size_bridges() tries to add "additional I/O" of 256 bytes to each (DEFAULT_HOTPLUG_IO_SIZE). This gets further aligned to 4k as that's the minimum I/O window size so each hotplug port gets 4k I/O window and the same happens for the root port (which is also hotplug port). This means 3 * 4k = 12k I/O window. Because of this pci_assign_unassigned_bridge_resources() ends up opening a I/O bridge window for the root port at first available I/O address which seems to be in range 0x1000 - 0x3fff. Normally this range is used for ACPI stuff such as GPE bits (below is part of /proc/ioports): 1800-1803 : ACPI PM1a_EVT_BLK 1804-1805 : ACPI PM1a_CNT_BLK 1808-180b : ACPI PM_TMR 1810-1815 : ACPI CPU throttle 1850-1850 : ACPI PM2_CNT_BLK 1854-1857 : pnp 00:05 1860-187f : ACPI GPE0_BLK However, when the ACPI Notify() happened this range was not yet reserved for ACPI/PNP (that happens later) so PCI gets it. It then starts writing to this range and accidentally stomps over GPE bits among other things causing the endless stream of messages about missing GPE handler. This problem does not happen if "pci=hpiosize=0" is passed in the kernel command line. The reason is that then the kernel does not try to allocate the additional 256 bytes for each hotplug port. Fix this by allocating resources directly below the non-hotplug bridges where a new device may appear as a result of ACPI Notify(). This avoids the hotplug bridges and prevents opening the additional I/O window. Fixes: 84c8b58ed3ad ("ACPI / hotplug / PCI: Don't scan bridges managed by native hotplug") Link: https://bugzilla.kernel.org/show_bug.cgi?id=203617 Link: https://lore.kernel.org/r/20191030150545.19885-1-mika.westerberg@linux.intel.com Reported-by: Valerio Passini Signed-off-by: Mika Westerberg Signed-off-by: Bjorn Helgaas Reviewed-by: Rafael J. Wysocki Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 1ef5b387461c37cd038736cabccbac68dcfd1e8d Author: Hans de Goede Date: Thu Oct 24 23:57:23 2019 +0200 ACPI: LPSS: Add dmi quirk for skipping _DEP check for some device-links commit 6025e2fae3dde3c3d789d08f8ceacbdd9f90d471 upstream. The iGPU / GFX0 device's _PS0 method on the ASUS T200TA depends on the I2C1 controller (which is connected to the embedded controller). But unlike in the T100TA/T100CHI this dependency is not listed in the _DEP of the GFX0 device. This results in the dev_WARN_ONCE(..., "Transfer while suspended\n") call in i2c-designware-master.c triggering and the AML code not working as it should. This commit fixes this by adding a dmi based quirk mechanism for devices which miss a _DEP, and adding a quirk for the LNXVIDEO depending on the I2C1 device on the Asus T200TA. Fixes: 2d71ee0ce72f ("ACPI / LPSS: Add a device link from the GPU to the BYT I2C5 controller") Tested-by: Pierre-Louis Bossart Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Cc: 4.20+ # 4.20+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 6f1c9dda2a9f5276bf6d00c74499f40e5a24ae1d Author: Hans de Goede Date: Thu Oct 24 23:57:22 2019 +0200 ACPI: LPSS: Add LNXVIDEO -> BYT I2C1 to lpss_device_links commit b3b3519c04bdff91651d0a6deb79dbd4516b5d7b upstream. Various Asus Bay Trail devices (T100TA, T100CHI, T200TA) have an embedded controller connected to I2C1 and the iGPU (LNXVIDEO) _PS0/_PS3 methods access it, so we need to add a consumer link from LNXVIDEO to I2C1 on these devices to avoid suspend/resume ordering problems. Fixes: 2d71ee0ce72f ("ACPI / LPSS: Add a device link from the GPU to the BYT I2C5 controller") Tested-by: Pierre-Louis Bossart Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Cc: 4.20+ # 4.20+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 7574257af7ae484eb636ffaa83c8e234704fd4a8 Author: Hans de Goede Date: Thu Oct 24 23:57:21 2019 +0200 ACPI: LPSS: Add LNXVIDEO -> BYT I2C7 to lpss_device_links commit cc18735f208565343a9824adeca5305026598550 upstream. So far on Bay Trail (BYT) we only have been adding a device_link adding the iGPU (LNXVIDEO) device as consumer for the I2C controller for the PMIC for I2C5, but the PMIC only uses I2C5 on BYT CR (cost reduced) on regular BYT platforms I2C7 is used and we were not adding the device_link sometimes causing resume ordering issues. This commit adds LNXVIDEO -> BYT I2C7 to the lpss_device_links table, fixing this. Fixes: 2d71ee0ce72f ("ACPI / LPSS: Add a device link from the GPU to the BYT I2C5 controller") Tested-by: Pierre-Louis Bossart Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Cc: 4.20+ # 4.20+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit ac2d71a18299ff60bce38c6e80775f9118d6e1f4 Author: Andy Shevchenko Date: Tue Oct 1 17:27:21 2019 +0300 ACPI / utils: Move acpi_dev_get_first_match_dev() under CONFIG_ACPI commit a814dcc269830c9dbb8a83731cfc6fc5dd787f8d upstream. We have a stub defined for the acpi_dev_get_first_match_dev() in acpi.h for the case when CONFIG_ACPI=n. Moreover, acpi_dev_put(), counterpart function, is already placed under CONFIG_ACPI. Thus, move acpi_dev_get_first_match_dev() under CONFIG_ACPI as well. Fixes: 817b4d64da03 ("ACPI / utils: Introduce acpi_dev_get_first_match_dev() helper") Reported-by: kbuild test robot Signed-off-by: Andy Shevchenko Reviewed-by: Mika Westerberg Cc: 5.2+ # 5.2+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 1555114aad7cf4826301b30c499bc2002a90bb20 Author: Takashi Sakamoto Date: Tue Dec 10 00:03:04 2019 +0900 ALSA: oxfw: fix return value in error path of isochronous resources reservation commit 59a126aa3113fc23f03fedcafe3705f1de5aff50 upstream. Even if isochronous resources reservation fails, error code doesn't return in pcm.hw_params callback. Cc: #5.3+ Fixes: 4f380d007052 ("ALSA: oxfw: configure packet format in pcm.hw_params callback") Signed-off-by: Takashi Sakamoto Link: https://lore.kernel.org/r/20191209151655.GA8090@workstation Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9e6a98bd416b5b00b1d78d5141da5d036eb2c21d Author: Takashi Sakamoto Date: Tue Dec 10 00:05:41 2019 +0900 ALSA: fireface: fix return value in error path of isochronous resources reservation commit 480136343cbe89426d6c2ab74ffb4e3ee572c7ee upstream. Even if isochronous resources reservation fails, error code doesn't return in pcm.hw_params callback. Cc: #5.3+ Fixes: 55162d2bb0e8 ("ALSA: fireface: reserve/release isochronous resources in pcm.hw_params/hw_free callbacks") Signed-off-by: Takashi Sakamoto Link: https://lore.kernel.org/r/20191209151655.GA8090@workstation Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 0421df648655d682db9a43d67b97a2ff273d44a8 Author: John Hubbard Date: Wed Oct 30 22:21:59 2019 -0700 cpufreq: powernv: fix stack bloat and hard limit on number of CPUs commit db0d32d84031188443e25edbd50a71a6e7ac5d1d upstream. The following build warning occurred on powerpc 64-bit builds: drivers/cpufreq/powernv-cpufreq.c: In function 'init_chip_info': drivers/cpufreq/powernv-cpufreq.c:1070:1: warning: the frame size of 1040 bytes is larger than 1024 bytes [-Wframe-larger-than=] This is with a cross-compiler based on gcc 8.1.0, which I got from: https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/ The warning is due to putting 1024 bytes on the stack: unsigned int chip[256]; ...and it's also undesirable to have a hard limit on the number of CPUs here. Fix both problems by dynamically allocating based on num_possible_cpus, as recommended by Michael Ellerman. Fixes: 053819e0bf840 ("cpufreq: powernv: Handle throttling due to Pmax capping at chip level") Signed-off-by: John Hubbard Acked-by: Viresh Kumar Cc: 4.10+ # 4.10+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 02dbc453a17397ce6abc71f4dbaede92f4544b3f Author: Leonard Crestez Date: Tue Sep 24 10:52:23 2019 +0300 PM / devfreq: Lock devfreq in trans_stat_show commit 2abb0d5268ae7b5ddf82099b1f8d5aa8414637d4 upstream. There is no locking in this sysfs show function so stats printing can race with a devfreq_update_status called as part of freq switching or with initialization. Also add an assert in devfreq_update_status to make it clear that lock must be held by caller. Fixes: 39688ce6facd ("PM / devfreq: account suspend/resume for stats") Cc: stable@vger.kernel.org Signed-off-by: Leonard Crestez Reviewed-by: Matthias Kaehlcke Reviewed-by: Chanwoo Choi Signed-off-by: Chanwoo Choi Signed-off-by: Greg Kroah-Hartman commit ba70fbd22089d8161ab0ac8d0d3ec92cf4879508 Author: Alexander Shishkin Date: Wed Nov 20 15:08:06 2019 +0200 intel_th: pci: Add Tiger Lake CPU support commit 6e6c18bcb78c0dc0601ebe216bed12c844492d0c upstream. This adds support for the Trace Hub in Tiger Lake CPU. Signed-off-by: Alexander Shishkin Reviewed-by: Andy Shevchenko Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20191120130806.44028-4-alexander.shishkin@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 450ce60c0be53d86396fe2a8970b4834aedb2952 Author: Alexander Shishkin Date: Wed Nov 20 15:08:05 2019 +0200 intel_th: pci: Add Ice Lake CPU support commit 6a1743422a7c0fda26764a544136cac13e5ae486 upstream. This adds support for the Trace Hub in Ice Lake CPU. Signed-off-by: Alexander Shishkin Reviewed-by: Andy Shevchenko Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20191120130806.44028-3-alexander.shishkin@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 68c8574bec326d4fb5366fee7ec740f449ac7758 Author: Alexander Shishkin Date: Wed Nov 20 15:08:04 2019 +0200 intel_th: Fix a double put_device() in error path commit 512592779a337feb5905d8fcf9498dbf33672d4a upstream. Commit a753bfcfdb1f ("intel_th: Make the switch allocate its subdevices") factored out intel_th_subdevice_alloc() from intel_th_populate(), but got the error path wrong, resulting in two instances of a double put_device() on a freshly initialized, but not 'added' device. Fix this by only doing one put_device() in the error path. Signed-off-by: Alexander Shishkin Fixes: a753bfcfdb1f ("intel_th: Make the switch allocate its subdevices") Reported-by: Wen Yang Reviewed-by: Andy Shevchenko Cc: stable@vger.kernel.org # v4.14+ Link: https://lore.kernel.org/r/20191120130806.44028-2-alexander.shishkin@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 8772f964ad5654f915b0ad9f7ccf22784f87a033 Author: Madhavan Srinivasan Date: Mon Nov 18 09:14:52 2019 +0530 powerpc/perf: Disable trace_imc pmu commit 249fad734a25889a4f23ed014d43634af6798063 upstream. When a root user or a user with CAP_SYS_ADMIN privilege uses any trace_imc performance monitoring unit events, to monitor application or KVM threads, it may result in a checkstop (System crash). The cause is frequent switching of the "trace/accumulation" mode of the In-Memory Collection hardware (LDBAR). This patch disables the trace_imc PMU unit entirely to avoid triggering the checkstop. A future patch will reenable it at a later stage once a workaround has been developed. Fixes: 012ae244845f ("powerpc/perf: Trace imc PMU functions") Cc: stable@vger.kernel.org # v5.2+ Signed-off-by: Madhavan Srinivasan Tested-by: Hariharan T.S. [mpe: Add pr_info_once() so dmesg shows the PMU has been disabled] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191118034452.9939-1-maddy@linux.vnet.ibm.com Signed-off-by: Greg Kroah-Hartman commit 65130097f6a97c20efcb2263803622d4216c31ed Author: Gao Xiang Date: Sun Dec 1 16:01:09 2019 +0800 erofs: zero out when listxattr is called with no xattr commit 926d1650176448d7684b991fbe1a5b1a8289e97c upstream. As David reported [1], ENODATA returns when attempting to modify files by using EROFS as an overlayfs lower layer. The root cause is that listxattr could return unexpected -ENODATA by mistake for inodes without xattr. That breaks listxattr return value convention and it can cause copy up failure when used with overlayfs. Resolve by zeroing out if no xattr is found for listxattr. [1] https://lore.kernel.org/r/CAEvUa7nxnby+rxK-KRMA46=exeOMApkDMAV08AjMkkPnTPV4CQ@mail.gmail.com Link: https://lore.kernel.org/r/20191201084040.29275-1-hsiangkao@aol.com Fixes: cadf1ccf1b00 ("staging: erofs: add error handling for xattr submodule") Cc: # 4.19+ Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Signed-off-by: Greg Kroah-Hartman commit 6b2b568d985fc969f3dc6e422fc4194ff33bcf89 Author: Rafael J. Wysocki Date: Thu Oct 10 23:37:39 2019 +0200 cpuidle: teo: Fix "early hits" handling for disabled idle states commit 159e48560f51d9c2aa02d762a18cd24f7868ab27 upstream. The TEO governor uses idle duration "bins" defined in accordance with the CPU idle states table provided by the driver, so that each "bin" covers the idle duration range between the target residency of the idle state corresponding to it and the target residency of the closest deeper idle state. The governor collects statistics for each bin regardless of whether or not the idle state corresponding to it is currently enabled. In particular, the "early hits" metric measures the likelihood of a situation in which the idle duration measured after wakeup falls into to given bin, but the time till the next timer (sleep length) falls into a bin corresponding to one of the deeper idle states. It is used when the "hits" and "misses" metrics indicate that the state "matching" the sleep length should not be selected, so that the state with the maximum "early hits" value is selected instead of it. If the idle state corresponding to the given bin is disabled, it cannot be selected and if it turns out to be the one that should be selected, a shallower idle state needs to be used instead of it. Nevertheless, the metrics collected for the bin corresponding to it are still valid and need to be taken into account as though that state had not been disabled. As far as the "early hits" metric is concerned, teo_select() tries to take disabled states into account, but the state index corresponding to the maximum "early hits" value computed by it may be incorrect. Namely, it always uses the index of the previous maximum "early hits" state then, but there may be enabled idle states closer to the disabled one in question. In particular, if the current candidate state (whose index is the idx value) is closer to the disabled one and the "early hits" value of the disabled state is greater than the current maximum, the index of the current candidate state (idx) should replace the "maximum early hits state" index. Modify the code to handle that case correctly. Fixes: b26bf6ab716f ("cpuidle: New timer events oriented governor for tickless systems") Reported-by: Doug Smythies Signed-off-by: Rafael J. Wysocki Cc: 5.1+ # 5.1+ Signed-off-by: Greg Kroah-Hartman commit 91e505f2ea7457e6cbd03981f9622d425f5b1eaa Author: Rafael J. Wysocki Date: Thu Oct 10 23:36:15 2019 +0200 cpuidle: teo: Consider hits and misses metrics of disabled states commit e43dcf20215f0287ea113102617ca04daa76b70e upstream. The TEO governor uses idle duration "bins" defined in accordance with the CPU idle states table provided by the driver, so that each "bin" covers the idle duration range between the target residency of the idle state corresponding to it and the target residency of the closest deeper idle state. The governor collects statistics for each bin regardless of whether or not the idle state corresponding to it is currently enabled. In particular, the "hits" and "misses" metrics measure the likelihood of a situation in which both the time till the next timer (sleep length) and the idle duration measured after wakeup fall into the given bin. Namely, if the "hits" value is greater than the "misses" one, that situation is more likely than the one in which the sleep length falls into the given bin, but the idle duration measured after wakeup falls into a bin corresponding to one of the shallower idle states. If the idle state corresponding to the given bin is disabled, it cannot be selected and if it turns out to be the one that should be selected, a shallower idle state needs to be used instead of it. Nevertheless, the metrics collected for the bin corresponding to it are still valid and need to be taken into account as though that state had not been disabled. For this reason, make teo_select() always use the "hits" and "misses" values of the idle duration range that the sleep length falls into even if the specific idle state corresponding to it is disabled and if the "hits" values is greater than the "misses" one, select the closest enabled shallower idle state in that case. Fixes: b26bf6ab716f ("cpuidle: New timer events oriented governor for tickless systems") Signed-off-by: Rafael J. Wysocki Cc: 5.1+ # 5.1+ Signed-off-by: Greg Kroah-Hartman commit c3f7475fce8f284328f390c1be8b538337753d64 Author: Rafael J. Wysocki Date: Thu Oct 10 23:32:59 2019 +0200 cpuidle: teo: Rename local variable in teo_select() commit 4f690bb8ce4cc5d3fabe3a8e9c2401de1554cdc1 upstream. Rename a local variable in teo_select() in preparation for subsequent code modifications, no intentional impact. Signed-off-by: Rafael J. Wysocki Cc: 5.1+ # 5.1+ Signed-off-by: Greg Kroah-Hartman commit 37c3de955af1afa910e0f8ca492e174771c1efc7 Author: Rafael J. Wysocki Date: Thu Oct 10 23:32:17 2019 +0200 cpuidle: teo: Ignore disabled idle states that are too deep commit 069ce2ef1a6dd84cbd4d897b333e30f825e021f0 upstream. Prevent disabled CPU idle state with target residencies beyond the anticipated idle duration from being taken into account by the TEO governor. Fixes: b26bf6ab716f ("cpuidle: New timer events oriented governor for tickless systems") Signed-off-by: Rafael J. Wysocki Cc: 5.1+ # 5.1+ Signed-off-by: Greg Kroah-Hartman commit 3dc584f21890f1a48ec6156c64ba2013416845b6 Author: Zhenzhong Duan Date: Wed Oct 23 09:57:14 2019 +0800 cpuidle: Do not unset the driver if it is there already commit 918c1fe9fbbe46fcf56837ff21f0ef96424e8b29 upstream. Fix __cpuidle_set_driver() to check if any of the CPUs in the mask has a driver different from drv already and, if so, return -EBUSY before updating any cpuidle_drivers per-CPU pointers. Fixes: 82467a5a885d ("cpuidle: simplify multiple driver support") Cc: 3.11+ # 3.11+ Signed-off-by: Zhenzhong Duan [ rjw: Subject & changelog ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit bb9d374836867d9e68e40fa6be51c1291bf2e00a Author: Hans Verkuil Date: Mon Sep 16 02:47:41 2019 -0300 media: cec.h: CEC_OP_REC_FLAG_ values were swapped commit 806e0cdfee0b99efbb450f9f6e69deb7118602fc upstream. CEC_OP_REC_FLAG_NOT_USED is 0 and CEC_OP_REC_FLAG_USED is 1, not the other way around. Signed-off-by: Hans Verkuil Reported-by: Jiunn Chang Cc: # for v4.10 and up Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 158256b919c8587e871039ac111ed4ccef2b011d Author: Johan Hovold Date: Thu Oct 10 10:13:32 2019 -0300 media: radio: wl1273: fix interrupt masking on release commit 1091eb830627625dcf79958d99353c2391f41708 upstream. If a process is interrupted while accessing the radio device and the core lock is contended, release() could return early and fail to update the interrupt mask. Note that the return value of the v4l2 release file operation is ignored. Fixes: 87d1a50ce451 ("[media] V4L2: WL1273 FM Radio: TI WL1273 FM radio driver") Cc: stable # 2.6.38 Cc: Matti Aaltonen Signed-off-by: Johan Hovold Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 192e6b59fd44ace17f8ea9657fd4214bb97db58c Author: Johan Hovold Date: Thu Oct 10 10:13:31 2019 -0300 media: bdisp: fix memleak on release commit 11609a7e21f8cea42630350aa57662928fa4dc63 upstream. If a process is interrupted while accessing the video device and the device lock is contended, release() could return early and fail to free related resources. Note that the return value of the v4l2 release file operation is ignored. Fixes: 28ffeebbb7bd ("[media] bdisp: 2D blitter driver using v4l2 mem2mem framework") Cc: stable # 4.2 Signed-off-by: Johan Hovold Reviewed-by: Fabien Dessenne Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 06541e7582e114c50cbc779b293e4344aa7715cb Author: Ezequiel Garcia Date: Mon Oct 7 19:45:02 2019 +0200 media: hantro: Fix s_fmt for dynamic resolution changes commit ae02d49493b5d32bb3e035fdeb1655346f5e1ea5 upstream. Commit 953aaa1492c53 ("media: rockchip/vpu: Prepare things to support decoders") changed the conditions under S_FMT was allowed for OUTPUT CAPTURE buffers. However, and according to the mem-to-mem stateless decoder specification, in order to support dynamic resolution changes, S_FMT should be allowed even if OUTPUT buffers have been allocated. Relax decoder S_FMT restrictions on OUTPUT buffers, allowing a resolution modification, provided the pixel format stays the same. Tested on RK3288 platforms using ChromiumOS Video Decode/Encode Accelerator Unittests. [hverkuil: fix typo: In other -> In order] Fixes: 953aaa1492c53 ("media: rockchip/vpu: Prepare things to support decoders") Signed-off-by: Ezequiel Garcia Reviewed-by: Boris Brezillon Cc: # for v5.4 and up Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit c7fb59f55f1e1382d854b644c5e77d60844cc34a Author: Gerald Schaefer Date: Wed Sep 11 19:42:23 2019 +0200 s390/mm: properly clear _PAGE_NOEXEC bit when it is not supported commit ab874f22d35a8058d8fdee5f13eb69d8867efeae upstream. On older HW or under a hypervisor, w/o the instruction-execution- protection (IEP) facility, and also w/o EDAT-1, a translation-specification exception may be recognized when bit 55 of a pte is one (_PAGE_NOEXEC). The current code tries to prevent setting _PAGE_NOEXEC in such cases, by removing it within set_pte_at(). However, ptep_set_access_flags() will modify a pte directly, w/o using set_pte_at(). There is at least one scenario where this can result in an active pte with _PAGE_NOEXEC set, which would then lead to a panic due to a translation-specification exception (write to swapped out page): do_swap_page pte = mk_pte (with _PAGE_NOEXEC bit) set_pte_at (will remove _PAGE_NOEXEC bit in page table, but keep it in local variable pte) vmf->orig_pte = pte (pte still contains _PAGE_NOEXEC bit) do_wp_page wp_page_reuse entry = vmf->orig_pte (still with _PAGE_NOEXEC bit) ptep_set_access_flags (writes entry with _PAGE_NOEXEC bit) Fix this by clearing _PAGE_NOEXEC already in mk_pte_phys(), where the pgprot value is applied, so that no pte with _PAGE_NOEXEC will ever be visible, if it is not supported. The check in set_pte_at() can then also be removed. Cc: # 4.11+ Fixes: 57d7f939e7bd ("s390: add no-execute support") Signed-off-by: Gerald Schaefer Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit f026f2e3893957fb4c978a513f92dd502696a08a Author: Denis Efremov Date: Mon Sep 30 23:31:47 2019 +0300 ar5523: check NULL before memcpy() in ar5523_cmd() commit 315cee426f87658a6799815845788fde965ddaad upstream. memcpy() call with "idata == NULL && ilen == 0" results in undefined behavior in ar5523_cmd(). For example, NULL is passed in callchain "ar5523_stat_work() -> ar5523_cmd_write() -> ar5523_cmd()". This patch adds ilen check before memcpy() call in ar5523_cmd() to prevent an undefined behavior. Cc: Pontus Fuchs Cc: Kalle Valo Cc: "David S. Miller" Cc: David Laight Cc: stable@vger.kernel.org Signed-off-by: Denis Efremov Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit f94b7a436d64bb16568cdc70dc729042164cf17d Author: Denis Efremov Date: Tue Oct 1 15:08:23 2019 +0300 wil6210: check len before memcpy() calls commit 2c840676be8ffc624bf9bb4490d944fd13c02d71 upstream. memcpy() in wmi_set_ie() and wmi_update_ft_ies() is called with src == NULL and len == 0. This is an undefined behavior. Fix it by checking "ie_len > 0" before the memcpy() calls. As suggested by GCC documentation: "The pointers passed to memmove (and similar functions in ) must be non-null even when nbytes==0, so GCC can use that information to remove the check after the memmove call." [1] [1] https://gcc.gnu.org/gcc-4.9/porting_to.html Cc: Maya Erez Cc: Kalle Valo Cc: "David S. Miller" Cc: stable@vger.kernel.org Signed-off-by: Denis Efremov Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 9e473f472a38bd53f73ad1b12ebc179a15f4ab8f Author: Aleksa Sarai Date: Thu Oct 17 02:50:01 2019 +1100 cgroup: pids: use atomic64_t for pids->limit commit a713af394cf382a30dd28a1015cbe572f1b9ca75 upstream. Because pids->limit can be changed concurrently (but we don't want to take a lock because it would be needlessly expensive), use atomic64_ts instead. Fixes: commit 49b786ea146f ("cgroup: implement the PIDs subsystem") Cc: stable@vger.kernel.org # v4.3+ Signed-off-by: Aleksa Sarai Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit f23ca1a30d8f5e9f10b4887679ff3a38dc9f329d Author: Ming Lei Date: Sat Nov 2 16:02:15 2019 +0800 blk-mq: avoid sysfs buffer overflow with too many CPU cores commit 8962842ca5abdcf98e22ab3b2b45a103f0408b95 upstream. It is reported that sysfs buffer overflow can be triggered if the system has too many CPU cores(>841 on 4K PAGE_SIZE) when showing CPUs of hctx via /sys/block/$DEV/mq/$N/cpu_list. Use snprintf to avoid the potential buffer overflow. This version doesn't change the attribute format, and simply stops showing CPU numbers if the buffer is going to overflow. Cc: stable@vger.kernel.org Fixes: 676141e48af7("blk-mq: don't dump CPU -> hw queue map on driver load") Signed-off-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 8c91e70c0a4c64c338025c02f7904dbda7858033 Author: David Jeffery Date: Mon Sep 16 13:15:14 2019 -0400 md: improve handling of bio with REQ_PREFLUSH in md_flush_request() commit 775d78319f1ceb32be8eb3b1202ccdc60e9cb7f1 upstream. If pers->make_request fails in md_flush_request(), the bio is lost. To fix this, pass back a bool to indicate if the original make_request call should continue to handle the I/O and instead of assuming the flush logic will push it to completion. Convert md_flush_request to return a bool and no longer calls the raid driver's make_request function. If the return is true, then the md flush logic has or will complete the bio and the md make_request call is done. If false, then the md make_request function needs to keep processing like it is a normal bio. Let the original call to md_handle_request handle any need to retry sending the bio to the raid driver's make_request function should it be needed. Also mark md_flush_request and the make_request function pointer as __must_check to issue warnings should these critical return values be ignored. Fixes: 2bc13b83e629 ("md: batch flush requests.") Cc: stable@vger.kernel.org # # v4.19+ Cc: NeilBrown Signed-off-by: David Jeffery Reviewed-by: Xiao Ni Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit 89ce5f8081470f19afe1f21a64ced11e7dc25349 Author: Shengjiu Wang Date: Mon Nov 11 15:50:48 2019 +0800 ASoC: fsl_audmix: Add spin lock to protect tdms commit fe965096c9495ddcf78ec163348105e2baf8d185 upstream. Audmix support two substream, When two substream start to run, the trigger function may be called by two substream in same time, that the priv->tdms may be updated wrongly. The expected priv->tdms is 0x3, but sometimes the result is 0x2, or 0x1. Fixes: be1df61cf06e ("ASoC: fsl: Add Audio Mixer CPU DAI driver") Signed-off-by: Shengjiu Wang Acked-by: Nicolin Chen Reviewed-by: Daniel Baluta Link: https://lore.kernel.org/r/1e706afe53fdd1fbbbc79277c48a98f8416ba873.1573458378.git.shengjiu.wang@nxp.com Signed-off-by: Mark Brown Cc: Signed-off-by: Greg Kroah-Hartman commit cf20f0a42417e313e70fb93e332507adbc1ec25f Author: Pawel Harlozinski Date: Tue Nov 12 14:02:36 2019 +0100 ASoC: Jack: Fix NULL pointer dereference in snd_soc_jack_report commit 8f157d4ff039e03e2ed4cb602eeed2fd4687a58f upstream. Check for existance of jack before tracing. NULL pointer dereference has been reported by KASAN while unloading machine driver (snd_soc_cnl_rt274). Signed-off-by: Pawel Harlozinski Link: https://lore.kernel.org/r/20191112130237.10141-1-pawel.harlozinski@linux.intel.com Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ecc0bc0dbe3f9450f5ac9e92d69fd7027ea56742 Author: Jacob Rasmussen Date: Thu Nov 14 16:20:11 2019 -0700 ASoC: rt5645: Fixed typo for buddy jack support. commit fe23be2d85b05f561431d75acddec726ea807d2a upstream. Had a typo in e7cfd867fd98 that resulted in buddy jack support not being fixed. Fixes: e7cfd867fd98 ("ASoC: rt5645: Fixed buddy jack support.") Signed-off-by: Jacob Rasmussen Reviewed-by: Ross Zwisler Cc: CC: stable@vger.kernel.org Link: https://lore.kernel.org/r/20191114232011.165762-1-jacobraz@google.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit dd98992857453ec852d6a7c7a61181d5536dafe4 Author: Jacob Rasmussen Date: Mon Nov 11 11:59:57 2019 -0700 ASoC: rt5645: Fixed buddy jack support. commit e7cfd867fd9842f346688f28412eb83dec342900 upstream. The headphone jack on buddy was broken with the following commit: commit 6b5da66322c5 ("ASoC: rt5645: read jd1_1 status for jd detection"). This changes the jd_mode for buddy to 4 so buddy can read from the same register that was used in the working version of this driver without affecting any other devices that might use this, since no other device uses jd_mode = 4. To test this I plugged and uplugged the headphone jack, verifying audio works. Signed-off-by: Jacob Rasmussen Reviewed-by: Ross Zwisler Link: https://lore.kernel.org/r/20191111185957.217244-1-jacobraz@google.com Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 0da808f7cf7db5fdd5791d1d6cd71fb6b4370af2 Author: Tejun Heo Date: Wed Sep 25 06:59:15 2019 -0700 workqueue: Fix pwq ref leak in rescuer_thread() commit e66b39af00f426b3356b96433d620cb3367ba1ff upstream. 008847f66c3 ("workqueue: allow rescuer thread to do more work.") made the rescuer worker requeue the pwq immediately if there may be more work items which need rescuing instead of waiting for the next mayday timer expiration. Unfortunately, it doesn't check whether the pwq is already on the mayday list and unconditionally gets the ref and moves it onto the list. This doesn't corrupt the list but creates an additional reference to the pwq. It got queued twice but will only be removed once. This leak later can trigger pwq refcnt warning on workqueue destruction and prevent freeing of the workqueue. Signed-off-by: Tejun Heo Cc: "Williams, Gerald S" Cc: NeilBrown Cc: stable@vger.kernel.org # v3.19+ Signed-off-by: Greg Kroah-Hartman commit 646190c012895ba31347f1fd9fe8c0d3ae408973 Author: Tejun Heo Date: Wed Sep 18 18:43:40 2019 -0700 workqueue: Fix spurious sanity check failures in destroy_workqueue() commit def98c84b6cdf2eeea19ec5736e90e316df5206b upstream. Before actually destrying a workqueue, destroy_workqueue() checks whether it's actually idle. If it isn't, it prints out a bunch of warning messages and leaves the workqueue dangling. It unfortunately has a couple issues. * Mayday list queueing increments pwq's refcnts which gets detected as busy and fails the sanity checks. However, because mayday list queueing is asynchronous, this condition can happen without any actual work items left in the workqueue. * Sanity check failure leaves the sysfs interface behind too which can lead to init failure of newer instances of the workqueue. This patch fixes the above two by * If a workqueue has a rescuer, disable and kill the rescuer before sanity checks. Disabling and killing is guaranteed to flush the existing mayday list. * Remove sysfs interface before sanity checks. Signed-off-by: Tejun Heo Reported-by: Marcin Pawlowski Reported-by: "Williams, Gerald S" Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 47dffb966d954ec0ec66a50fa3050a0e80d6e2bf Author: Dmitry Fomichev Date: Wed Nov 6 14:34:35 2019 -0800 dm zoned: reduce overhead of backing device checks commit e7fad909b68aa37470d9f2d2731b5bec355ee5d6 upstream. Commit 75d66ffb48efb3 added backing device health checks and as a part of these checks, check_events() block ops template call is invoked in dm-zoned mapping path as well as in reclaim and flush path. Calling check_events() with ATA or SCSI backing devices introduces a blocking scsi_test_unit_ready() call being made in sd_check_events(). Even though the overhead of calling scsi_test_unit_ready() is small for ATA zoned devices, it is much larger for SCSI and it affects performance in a very negative way. Fix this performance regression by executing check_events() only in case of any I/O errors. The function dmz_bdev_is_dying() is modified to call only blk_queue_dying(), while calls to check_events() are made in a new helper function, dmz_check_bdev(). Reported-by: zhangxiaoxu Fixes: 75d66ffb48efb3 ("dm zoned: properly handle backing device failure") Cc: stable@vger.kernel.org Signed-off-by: Dmitry Fomichev Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 4932e81a0fc2753db988dba3eb866e24d2c710ea Author: Maged Mokhtar Date: Wed Oct 23 22:41:17 2019 +0200 dm writecache: handle REQ_FUA commit c1005322ff02110a4df7f0033368ea015062b583 upstream. Call writecache_flush() on REQ_FUA in writecache_map(). Cc: stable@vger.kernel.org # 4.18+ Signed-off-by: Maged Mokhtar Acked-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 20e07e99480e9c8227983b74f5d91c424314640a Author: Sumit Garg Date: Mon Oct 14 17:32:45 2019 +0530 hwrng: omap - Fix RNG wait loop timeout commit be867f987a4e1222114dd07a01838a17c26f3fff upstream. Existing RNG data read timeout is 200us but it doesn't cover EIP76 RNG data rate which takes approx. 700us to produce 16 bytes of output data as per testing results. So configure the timeout as 1000us to also take account of lack of udelay()'s reliability. Fixes: 383212425c92 ("hwrng: omap - Add device variant for SafeXcel IP-76 found in Armada 8K") Cc: Signed-off-by: Sumit Garg Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit e216ed638b04f044bfaa9a791001f2d295e533e0 Author: Amir Goldstein Date: Fri Dec 6 08:33:36 2019 +0200 ovl: relax WARN_ON() on rename to self commit 6889ee5a53b8d969aa542047f5ac8acdc0e79a91 upstream. In ovl_rename(), if new upper is hardlinked to old upper underneath overlayfs before upper dirs are locked, user will get an ESTALE error and a WARN_ON will be printed. Changes to underlying layers while overlayfs is mounted may result in unexpected behavior, but it shouldn't crash the kernel and it shouldn't trigger WARN_ON() either, so relax this WARN_ON(). Reported-by: syzbot+bb1836a212e69f8e201a@syzkaller.appspotmail.com Fixes: 804032fabb3b ("ovl: don't check rename to self") Cc: # v4.9+ Signed-off-by: Amir Goldstein Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 801a491252c419f262765efed108df8db36d04e2 Author: Amir Goldstein Date: Sun Nov 17 17:43:44 2019 +0200 ovl: fix corner case of non-unique st_dev;st_ino commit 9c6d8f13e9da10a26ad7f0a020ef86e8ef142835 upstream. On non-samefs overlay without xino, non pure upper inodes should use a pseudo_dev assigned to each unique lower fs and pure upper inodes use the real upper st_dev. It is fine for an overlay pure upper inode to use the same st_dev;st_ino values as the real upper inode, because the content of those two different filesystem objects is always the same. In this case, however: - two filesystems, A and B - upper layer is on A - lower layer 1 is also on A - lower layer 2 is on B Non pure upper overlay inode, whose origin is in layer 1 will have the same st_dev;st_ino values as the real lower inode. This may result with a false positive results of 'diff' between the real lower and copied up overlay inode. Fix this by using the upper st_dev;st_ino values in this case. This breaks the property of constant st_dev;st_ino across copy up of this case. This breakage will be fixed by a later patch. Fixes: 5148626b806a ("ovl: allocate anon bdev per unique lower fs") Cc: stable@vger.kernel.org # v4.17+ Signed-off-by: Amir Goldstein Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 3719288ce3a424eb4631279d0bc2d75009e75b25 Author: Amir Goldstein Date: Thu Nov 14 22:28:41 2019 +0200 ovl: fix lookup failure on multi lower squashfs commit 7e63c87fc2dcf3be9d3aab82d4a0ea085880bdca upstream. In the past, overlayfs required that lower fs have non null uuid in order to support nfs export and decode copy up origin file handles. Commit 9df085f3c9a2 ("ovl: relax requirement for non null uuid of lower fs") relaxed this requirement for nfs export support, as long as uuid (even if null) is unique among all lower fs. However, said commit unintentionally also relaxed the non null uuid requirement for decoding copy up origin file handles, regardless of the unique uuid requirement. Amend this mistake by disabling decoding of copy up origin file handle from lower fs with a conflicting uuid. We still encode copy up origin file handles from those fs, because file handles like those already exist in the wild and because they might provide useful information in the future. There is an unhandled corner case described by Miklos this way: - two filesystems, A and B, both have null uuid - upper layer is on A - lower layer 1 is also on A - lower layer 2 is on B In this case bad_uuid won't be set for B, because the check only involves the list of lower fs. Hence we'll try to decode a layer 2 origin on layer 1 and fail. We will deal with this corner case later. Reported-by: Colin Ian King Tested-by: Colin Ian King Link: https://lore.kernel.org/lkml/20191106234301.283006-1-colin.king@canonical.com/ Fixes: 9df085f3c9a2 ("ovl: relax requirement for non null uuid ...") Cc: stable@vger.kernel.org # v4.20+ Signed-off-by: Amir Goldstein Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 57a23be0caab81da82fb45a19eb2ee6019848e64 Author: Greg Kroah-Hartman Date: Fri Dec 6 16:26:00 2019 +0100 lib: raid6: fix awk build warnings commit 702600eef73033ddd4eafcefcbb6560f3e3a90f7 upstream. Newer versions of awk spit out these fun warnings: awk: ../lib/raid6/unroll.awk:16: warning: regexp escape sequence `\#' is not a known regexp operator As commit 700c1018b86d ("x86/insn: Fix awk regexp warnings") showed, it turns out that there are a number of awk strings that do not need to be escaped and newer versions of awk now warn about this. Fix the string up so that no warning is produced. The exact same kernel module gets created before and after this patch, showing that it wasn't needed. Link: https://lore.kernel.org/r/20191206152600.GA75093@kroah.com Signed-off-by: Greg Kroah-Hartman commit 5c04feed0d363b49af01dec8906379c37aafc9b8 Author: Larry Finger Date: Mon Nov 11 13:40:46 2019 -0600 rtlwifi: rtl8192de: Fix missing enable interrupt flag commit 330bb7117101099c687e9c7f13d48068670b9c62 upstream. In commit 38506ecefab9 ("rtlwifi: rtl_pci: Start modification for new drivers"), the flag that indicates that interrupts are enabled was never set. In addition, there are several places when enable/disable interrupts were commented out are restored. A sychronize_interrupts() call is removed. Fixes: 38506ecefab9 ("rtlwifi: rtl_pci: Start modification for new drivers") Cc: Stable # v3.18+ Signed-off-by: Larry Finger Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit ca6b0286dfcf34e520c86a78563805fc815a5f3b Author: Larry Finger Date: Mon Nov 11 13:40:45 2019 -0600 rtlwifi: rtl8192de: Fix missing callback that tests for hw release of buffer commit 3155db7613edea8fb943624062baf1e4f9cfbfd6 upstream. In commit 38506ecefab9 ("rtlwifi: rtl_pci: Start modification for new drivers"), a callback needed to check if the hardware has released a buffer indicating that a DMA operation is completed was not added. Fixes: 38506ecefab9 ("rtlwifi: rtl_pci: Start modification for new drivers") Cc: Stable # v3.18+ Signed-off-by: Larry Finger Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 8f82772312a78939fa8f05b17c4d8062acdf2b8c Author: Larry Finger Date: Mon Nov 11 13:40:44 2019 -0600 rtlwifi: rtl8192de: Fix missing code to retrieve RX buffer address commit 0e531cc575c4e9e3dd52ad287b49d3c2dc74c810 upstream. In commit 38506ecefab9 ("rtlwifi: rtl_pci: Start modification for new drivers"), a callback to get the RX buffer address was added to the PCI driver. Unfortunately, driver rtl8192de was not modified appropriately and the code runs into a WARN_ONCE() call. The use of an incorrect array is also fixed. Fixes: 38506ecefab9 ("rtlwifi: rtl_pci: Start modification for new drivers") Cc: Stable # 3.18+ Signed-off-by: Larry Finger Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit de5638d891c61bb57b6cba2bf9408b1f421258bd Author: Josef Bacik Date: Fri Nov 15 15:43:06 2019 -0500 btrfs: record all roots for rename exchange on a subvol commit 3e1740993e43116b3bc71b0aad1e6872f6ccf341 upstream. Testing with the new fsstress support for subvolumes uncovered a pretty bad problem with rename exchange on subvolumes. We're modifying two different subvolumes, but we only start the transaction on one of them, so the other one is not added to the dirty root list. This is caught by btrfs_cow_block() with a warning because the root has not been updated, however if we do not modify this root again we'll end up pointing at an invalid root because the root item is never updated. Fix this by making sure we add the destination root to the trans list, the same as we do with normal renames. This fixes the corruption. Fixes: cdd1fedf8261 ("btrfs: add support for RENAME_EXCHANGE and RENAME_WHITEOUT") CC: stable@vger.kernel.org # 4.9+ Reviewed-by: Filipe Manana Signed-off-by: Josef Bacik Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit fd04d18496465ce3b2d20723111bb77dc6e7c139 Author: Filipe Manana Date: Wed Oct 30 12:23:01 2019 +0000 Btrfs: send, skip backreference walking for extents with many references commit fd0ddbe2509568b00df364156f47561e9f469f15 upstream. Backreference walking, which is used by send to figure if it can issue clone operations instead of write operations, can be very slow and use too much memory when extents have many references. This change simply skips backreference walking when an extent has more than 64 references, in which case we fallback to a write operation instead of a clone operation. This limit is conservative and in practice I observed no signicant slowdown with up to 100 references and still low memory usage up to that limit. This is a temporary workaround until there are speedups in the backref walking code, and as such it does not attempt to add extra interfaces or knobs to tweak the threshold. Reported-by: Atemu Link: https://lore.kernel.org/linux-btrfs/CAE4GHgkvqVADtS4AzcQJxo0Q1jKQgKaW3JGp3SGdoinVo=C9eQ@mail.gmail.com/T/#me55dc0987f9cc2acaa54372ce0492c65782be3fa CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit eac0ae5314ba58334dd07f19702947a0ef7e4bde Author: Qu Wenruo Date: Thu Oct 24 09:38:29 2019 +0800 btrfs: Remove btrfs_bio::flags member commit 34b127aecd4fe8e6a3903e10f204a7b7ffddca22 upstream. The last user of btrfs_bio::flags was removed in commit 326e1dbb5736 ("block: remove management of bi_remaining when restoring original bi_end_io"), remove it. (Tagged for stable as the structure is heavily used and space savings are desirable.) CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 3d0704fc4a533126ac58395233547e19019f18fd Author: Tejun Heo Date: Thu Oct 3 07:27:13 2019 -0700 btrfs: Avoid getting stuck during cyclic writebacks commit f7bddf1e27d18fbc7d3e3056ba449cfbe4e20b0a upstream. During a cyclic writeback, extent_write_cache_pages() uses done_index to update the writeback_index after the current run is over. However, instead of current index + 1, it gets to to the current index itself. Unfortunately, this, combined with returning on EOF instead of looping back, can lead to the following pathlogical behavior. 1. There is a single file which has accumulated enough dirty pages to trigger balance_dirty_pages() and the writer appending to the file with a series of short writes. 2. balance_dirty_pages kicks in, wakes up background writeback and sleeps. 3. Writeback kicks in and the cursor is on the last page of the dirty file. Writeback is started or skipped if already in progress. As it's EOF, extent_write_cache_pages() returns and the cursor is set to done_index which is pointing to the last page. 4. Writeback is done. Nothing happens till balance_dirty_pages finishes, at which point we go back to #1. This can almost completely stall out writing back of the file and keep the system over dirty threshold for a long time which can mess up the whole system. We encountered this issue in production with a package handling application which can reliably reproduce the issue when running under tight memory limits. Reading the comment in the error handling section, this seems to be to avoid accidentally skipping a page in case the write attempt on the page doesn't succeed. However, this concern seems bogus. On each page, the code either: * Skips and moves onto the next page. * Fails issue and sets done_index to index + 1. * Successfully issues and continue to the next page if budget allows and not EOF. IOW, as long as it's not EOF and there's budget, the code never retries writing back the same page. Only when a page happens to be the last page of a particular run, we end up retrying the page, which can't possibly guarantee anything data integrity related. Besides, cyclic writes are only used for non-syncing writebacks meaning that there's no data integrity implication to begin with. Fix it by always setting done_index past the current page being processed. Note that this problem exists in other writepages too. CC: stable@vger.kernel.org # 4.19+ Signed-off-by: Tejun Heo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 6191944b4df8de25586aae02cf4ebecd81f87161 Author: Filipe Manana Date: Fri Oct 11 16:41:20 2019 +0100 Btrfs: fix negative subv_writers counter and data space leak after buffered write commit a0e248bb502d5165b3314ac3819e888fdcdf7d9f upstream. When doing a buffered write it's possible to leave the subv_writers counter of the root, used for synchronization between buffered nocow writers and snapshotting. This happens in an exceptional case like the following: 1) We fail to allocate data space for the write, since there's not enough available data space nor enough unallocated space for allocating a new data block group; 2) Because of that failure, we try to go to NOCOW mode, which succeeds and therefore we set the local variable 'only_release_metadata' to true and set the root's sub_writers counter to 1 through the call to btrfs_start_write_no_snapshotting() made by check_can_nocow(); 3) The call to btrfs_copy_from_user() returns zero, which is very unlikely to happen but not impossible; 4) No pages are copied because btrfs_copy_from_user() returned zero; 5) We call btrfs_end_write_no_snapshotting() which decrements the root's subv_writers counter to 0; 6) We don't set 'only_release_metadata' back to 'false' because we do it only if 'copied', the value returned by btrfs_copy_from_user(), is greater than zero; 7) On the next iteration of the while loop, which processes the same page range, we are now able to allocate data space for the write (we got enough data space released in the meanwhile); 8) After this if we fail at btrfs_delalloc_reserve_metadata(), because now there isn't enough free metadata space, or in some other place further below (prepare_pages(), lock_and_cleanup_extent_if_need(), btrfs_dirty_pages()), we break out of the while loop with 'only_release_metadata' having a value of 'true'; 9) Because 'only_release_metadata' is 'true' we end up decrementing the root's subv_writers counter to -1 (through a call to btrfs_end_write_no_snapshotting()), and we also end up not releasing the data space previously reserved through btrfs_check_data_free_space(). As a consequence the mechanism for synchronizing NOCOW buffered writes with snapshotting gets broken. Fix this by always setting 'only_release_metadata' to false at the start of each iteration. Fixes: 8257b2dc3c1a ("Btrfs: introduce btrfs_{start, end}_nocow_write() for each subvolume") Fixes: 7ee9e4405f26 ("Btrfs: check if we can nocow if we don't have data space") CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Josef Bacik Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 9d15a6722fa049c13f3f34e37feae37c84db76d5 Author: Filipe Manana Date: Wed Oct 9 17:43:59 2019 +0100 Btrfs: fix metadata space leak on fixup worker failure to set range as delalloc commit 536870071dbc4278264f59c9a2f5f447e584d139 upstream. In the fixup worker, if we fail to mark the range as delalloc in the io tree, we must release the previously reserved metadata, as well as update the outstanding extents counter for the inode, otherwise we leak metadata space. In pratice we can't return an error from btrfs_set_extent_delalloc(), which is just a wrapper around __set_extent_bit(), as for most errors __set_extent_bit() does a BUG_ON() (or panics which hits a BUG_ON() as well) and returning an -EEXIST error doesn't happen in this case since the exclusive bits parameter always has a value of 0 through this code path. Nevertheless, just fix the error handling in the fixup worker, in case one day __set_extent_bit() can return an error to this code path. Fixes: f3038ee3a3f101 ("btrfs: Handle btrfs_set_extent_delalloc failure in fixup worker") CC: stable@vger.kernel.org # 4.19+ Reviewed-by: Nikolay Borisov Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 4dd288cdab02062262fa12c639803df022c8e0df Author: Josef Bacik Date: Thu Sep 26 08:29:32 2019 -0400 btrfs: use refcount_inc_not_zero in kill_all_nodes commit baf320b9d531f1cfbf64c60dd155ff80a58b3796 upstream. We hit the following warning while running down a different problem [ 6197.175850] ------------[ cut here ]------------ [ 6197.185082] refcount_t: underflow; use-after-free. [ 6197.194704] WARNING: CPU: 47 PID: 966 at lib/refcount.c:190 refcount_sub_and_test_checked+0x53/0x60 [ 6197.521792] Call Trace: [ 6197.526687] __btrfs_release_delayed_node+0x76/0x1c0 [ 6197.536615] btrfs_kill_all_delayed_nodes+0xec/0x130 [ 6197.546532] ? __btrfs_btree_balance_dirty+0x60/0x60 [ 6197.556482] btrfs_clean_one_deleted_snapshot+0x71/0xd0 [ 6197.566910] cleaner_kthread+0xfa/0x120 [ 6197.574573] kthread+0x111/0x130 [ 6197.581022] ? kthread_create_on_node+0x60/0x60 [ 6197.590086] ret_from_fork+0x1f/0x30 [ 6197.597228] ---[ end trace 424bb7ae00509f56 ]--- This is because the free side drops the ref without the lock, and then takes the lock if our refcount is 0. So you can have nodes on the tree that have a refcount of 0. Fix this by zero'ing out that element in our temporary array so we don't try to kill it again. CC: stable@vger.kernel.org # 4.14+ Reviewed-by: Nikolay Borisov Signed-off-by: Josef Bacik Reviewed-by: David Sterba [ add comment ] Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 516e41558ee4bf0a70d7a81ab86fb0416dda8357 Author: Josef Bacik Date: Tue Sep 24 16:50:43 2019 -0400 btrfs: check page->mapping when loading free space cache commit 3797136b626ad4b6582223660c041efdea8f26b2 upstream. While testing 5.2 we ran into the following panic [52238.017028] BUG: kernel NULL pointer dereference, address: 0000000000000001 [52238.105608] RIP: 0010:drop_buffers+0x3d/0x150 [52238.304051] Call Trace: [52238.308958] try_to_free_buffers+0x15b/0x1b0 [52238.317503] shrink_page_list+0x1164/0x1780 [52238.325877] shrink_inactive_list+0x18f/0x3b0 [52238.334596] shrink_node_memcg+0x23e/0x7d0 [52238.342790] ? do_shrink_slab+0x4f/0x290 [52238.350648] shrink_node+0xce/0x4a0 [52238.357628] balance_pgdat+0x2c7/0x510 [52238.365135] kswapd+0x216/0x3e0 [52238.371425] ? wait_woken+0x80/0x80 [52238.378412] ? balance_pgdat+0x510/0x510 [52238.386265] kthread+0x111/0x130 [52238.392727] ? kthread_create_on_node+0x60/0x60 [52238.401782] ret_from_fork+0x1f/0x30 The page we were trying to drop had a page->private, but had no page->mapping and so called drop_buffers, assuming that we had a buffer_head on the page, and then panic'ed trying to deref 1, which is our page->private for data pages. This is happening because we're truncating the free space cache while we're trying to load the free space cache. This isn't supposed to happen, and I'll fix that in a followup patch. However we still shouldn't allow those sort of mistakes to result in messing with pages that do not belong to us. So add the page->mapping check to verify that we still own this page after dropping and re-acquiring the page lock. This page being unlocked as: btrfs_readpage extent_read_full_page __extent_read_full_page __do_readpage if (!nr) unlock_page <-- nr can be 0 only if submit_extent_page returns an error CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Filipe Manana Reviewed-by: Nikolay Borisov Signed-off-by: Josef Bacik [ add callchain ] Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 15117b1d3aa8403a4b880fec40daf3f4cb906df9 Author: Johannes Berg Date: Fri Jun 1 10:32:55 2018 +0200 iwlwifi: pcie: fix support for transmitting SKBs with fraglist commit 4f4925a7b23428d5719af5a2816586b2a0e6fd19 upstream. When the implementation of SKBs with fraglist was sent upstream, a merge-damage occurred and half the patch was not applied. This causes problems in high-throughput situations with AX200 devices, including low throughput and FW crashes. Introduce the part that was missing from the original patch. Fixes: 0044f1716c4d ("iwlwifi: pcie: support transmitting SKBs with fraglist") Cc: stable@vger.kernel.org # 4.20+ Signed-off-by: Johannes Berg [ This patch was created by me, but the original author of this code is Johannes, so his s-o-b is here and he's marked as the author of the patch. ] Signed-off-by: Luca Coelho Signed-off-by: Greg Kroah-Hartman commit 083316930d594890acd34cb1f386c431f24b0bc1 Author: Wen Yang Date: Tue Nov 26 22:04:52 2019 +0800 usb: typec: fix use after free in typec_register_port() commit 5c388abefda0d92355714010c0199055c57ab6c7 upstream. We can't use "port->sw" and/or "port->mux" after it has been freed. Fixes: 23481121c81d ("usb: typec: class: Don't use port parent for getting mux handles") Signed-off-by: Wen Yang Cc: stable Cc: linux-usb@vger.kernel.org Cc: linux-kernel@vger.kernel.org Acked-by: Heikki Krogerus  Link: https://lore.kernel.org/r/20191126140452.14048-1-wenyang@linux.alibaba.com Signed-off-by: Greg Kroah-Hartman commit 33e3c9187ddfb8f44f0758a9584c87f735bebaf5 Author: Yoshihiro Shimoda Date: Mon Oct 7 16:55:10 2019 +0900 phy: renesas: rcar-gen3-usb2: Fix sysfs interface of "role" commit 4bd5ead82d4b877ebe41daf95f28cda53205b039 upstream. Since the role_store() uses strncmp(), it's possible to refer out-of-memory if the sysfs data size is smaller than strlen("host"). This patch fixes it by using sysfs_streq() instead of strncmp(). Reported-by: Pavel Machek Fixes: 9bb86777fb71 ("phy: rcar-gen3-usb2: add sysfs for usb role swap") Cc: # v4.10+ Signed-off-by: Yoshihiro Shimoda Reviewed-by: Geert Uytterhoeven Acked-by: Pavel Machek Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Greg Kroah-Hartman commit eae68719695d059e02d7eef0485cf1d9248caa5a Author: Thinh Nguyen Date: Wed Nov 27 13:10:54 2019 -0800 usb: dwc3: ep0: Clear started flag on completion commit 2d7b78f59e020b07fc6338eefe286f54ee2d6773 upstream. Clear ep0's DWC3_EP_TRANSFER_STARTED flag if the END_TRANSFER command is completed. Otherwise, we can't start control transfer again after END_TRANSFER. Cc: stable@vger.kernel.org Signed-off-by: Thinh Nguyen Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit c59f882a4c0b042b019feedea285debb6085c5ae Author: Thinh Nguyen Date: Wed Nov 27 13:10:47 2019 -0800 usb: dwc3: gadget: Clear started flag for non-IOC commit d3abda5a98a18e524e17fd4085c9f4bd53e9ef53 upstream. Normally the END_TRANSFER command completion handler will clear the DWC3_EP_TRANSFER_STARTED flag. However, if the command was sent without interrupt on completion, then the flag will not be cleared. Make sure to clear the flag in this case. Cc: stable@vger.kernel.org Signed-off-by: Thinh Nguyen Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit bf23594f2c8863a1c255137242eb50ef9ba75f8d Author: Tejas Joglekar Date: Wed Nov 13 11:45:16 2019 +0530 usb: dwc3: gadget: Fix logical condition commit 8c7d4b7b3d43c54c0b8c1e4adb917a151c754196 upstream. This patch corrects the condition to kick the transfer without giving back the requests when either request has remaining data or when there are pending SGs. The && check was introduced during spliting up the dwc3_gadget_ep_cleanup_completed_requests() function. Fixes: f38e35dd84e2 ("usb: dwc3: gadget: split dwc3_gadget_ep_cleanup_completed_requests()") Cc: stable@vger.kernel.org Signed-off-by: Tejas Joglekar Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 8fc27548af3916ee4bf685d1ce47eb9bd677b02a Author: Heikki Krogerus Date: Thu Dec 12 12:37:13 2019 +0300 usb: dwc3: pci: add ID for the Intel Comet Lake -H variant commit 3c3caae4cd6e122472efcf64759ff6392fb6bce2 upstream. The original ID that was added for Comet Lake PCH was actually for the -LP (low power) variant even though the constant for it said CMLH. Changing that while at it. Signed-off-by: Heikki Krogerus Acked-by: Felipe Balbi Cc: stable Link: https://lore.kernel.org/r/20191212093713.60614-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 781060b82669ee2f1847a13ab834ac1d0e9b4793 Author: David Hildenbrand Date: Wed Dec 11 12:11:52 2019 +0100 virtio-balloon: fix managed page counts when migrating pages between zones commit 63341ab03706e11a31e3dd8ccc0fbc9beaf723f0 upstream. In case we have to migrate a ballon page to a newpage of another zone, the managed page count of both zones is wrong. Paired with memory offlining (which will adjust the managed page count), we can trigger kernel crashes and all kinds of different symptoms. One way to reproduce: 1. Start a QEMU guest with 4GB, no NUMA 2. Hotplug a 1GB DIMM and online the memory to ZONE_NORMAL 3. Inflate the balloon to 1GB 4. Unplug the DIMM (be quick, otherwise unmovable data ends up on it) 5. Observe /proc/zoneinfo Node 0, zone Normal pages free 16810 min 24848885473806 low 18471592959183339 high 36918337032892872 spanned 262144 present 262144 managed 18446744073709533486 6. Do anything that requires some memory (e.g., inflate the balloon some more). The OOM goes crazy and the system crashes [ 238.324946] Out of memory: Killed process 537 (login) total-vm:27584kB, anon-rss:860kB, file-rss:0kB, shmem-rss:00 [ 238.338585] systemd invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0 [ 238.339420] CPU: 0 PID: 1 Comm: systemd Tainted: G D W 5.4.0-next-20191204+ #75 [ 238.340139] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu4 [ 238.341121] Call Trace: [ 238.341337] dump_stack+0x8f/0xd0 [ 238.341630] dump_header+0x61/0x5ea [ 238.341942] oom_kill_process.cold+0xb/0x10 [ 238.342299] out_of_memory+0x24d/0x5a0 [ 238.342625] __alloc_pages_slowpath+0xd12/0x1020 [ 238.343024] __alloc_pages_nodemask+0x391/0x410 [ 238.343407] pagecache_get_page+0xc3/0x3a0 [ 238.343757] filemap_fault+0x804/0xc30 [ 238.344083] ? ext4_filemap_fault+0x28/0x42 [ 238.344444] ext4_filemap_fault+0x30/0x42 [ 238.344789] __do_fault+0x37/0x1a0 [ 238.345087] __handle_mm_fault+0x104d/0x1ab0 [ 238.345450] handle_mm_fault+0x169/0x360 [ 238.345790] do_user_addr_fault+0x20d/0x490 [ 238.346154] do_page_fault+0x31/0x210 [ 238.346468] async_page_fault+0x43/0x50 [ 238.346797] RIP: 0033:0x7f47eba4197e [ 238.347110] Code: Bad RIP value. [ 238.347387] RSP: 002b:00007ffd7c0c1890 EFLAGS: 00010293 [ 238.347834] RAX: 0000000000000002 RBX: 000055d196a20a20 RCX: 00007f47eba4197e [ 238.348437] RDX: 0000000000000033 RSI: 00007ffd7c0c18c0 RDI: 0000000000000004 [ 238.349047] RBP: 00007ffd7c0c1c20 R08: 0000000000000000 R09: 0000000000000033 [ 238.349660] R10: 00000000ffffffff R11: 0000000000000293 R12: 0000000000000001 [ 238.350261] R13: ffffffffffffffff R14: 0000000000000000 R15: 00007ffd7c0c18c0 [ 238.350878] Mem-Info: [ 238.351085] active_anon:3121 inactive_anon:51 isolated_anon:0 [ 238.351085] active_file:12 inactive_file:7 isolated_file:0 [ 238.351085] unevictable:0 dirty:0 writeback:0 unstable:0 [ 238.351085] slab_reclaimable:5565 slab_unreclaimable:10170 [ 238.351085] mapped:3 shmem:111 pagetables:155 bounce:0 [ 238.351085] free:720717 free_pcp:2 free_cma:0 [ 238.353757] Node 0 active_anon:12484kB inactive_anon:204kB active_file:48kB inactive_file:28kB unevictable:0kB iss [ 238.355979] Node 0 DMA free:11556kB min:36kB low:48kB high:60kB reserved_highatomic:0KB active_anon:152kB inactivB [ 238.358345] lowmem_reserve[]: 0 2955 2884 2884 2884 [ 238.358761] Node 0 DMA32 free:2677864kB min:7004kB low:10028kB high:13052kB reserved_highatomic:0KB active_anon:0B [ 238.361202] lowmem_reserve[]: 0 0 72057594037927865 72057594037927865 72057594037927865 [ 238.361888] Node 0 Normal free:193448kB min:99395541895224kB low:73886371836733356kB high:147673348131571488kB reB [ 238.364765] lowmem_reserve[]: 0 0 0 0 0 [ 238.365101] Node 0 DMA: 7*4kB (U) 5*8kB (UE) 6*16kB (UME) 2*32kB (UM) 1*64kB (U) 2*128kB (UE) 3*256kB (UME) 2*512B [ 238.366379] Node 0 DMA32: 0*4kB 1*8kB (U) 2*16kB (UM) 2*32kB (UM) 2*64kB (UM) 1*128kB (U) 1*256kB (U) 1*512kB (U)B [ 238.367654] Node 0 Normal: 1985*4kB (UME) 1321*8kB (UME) 844*16kB (UME) 524*32kB (UME) 300*64kB (UME) 138*128kB (B [ 238.369184] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB [ 238.369915] 130 total pagecache pages [ 238.370241] 0 pages in swap cache [ 238.370533] Swap cache stats: add 0, delete 0, find 0/0 [ 238.370981] Free swap = 0kB [ 238.371239] Total swap = 0kB [ 238.371488] 1048445 pages RAM [ 238.371756] 0 pages HighMem/MovableOnly [ 238.372090] 306992 pages reserved [ 238.372376] 0 pages cma reserved [ 238.372661] 0 pages hwpoisoned In another instance (older kernel), I was able to observe this (negative page count :/): [ 180.896971] Offlined Pages 32768 [ 182.667462] Offlined Pages 32768 [ 184.408117] Offlined Pages 32768 [ 186.026321] Offlined Pages 32768 [ 187.684861] Offlined Pages 32768 [ 189.227013] Offlined Pages 32768 [ 190.830303] Offlined Pages 32768 [ 190.833071] Built 1 zonelists, mobility grouping on. Total pages: -36920272750453009 In another instance (older kernel), I was no longer able to start any process: [root@vm ~]# [ 214.348068] Offlined Pages 32768 [ 215.973009] Offlined Pages 32768 cat /proc/meminfo -bash: fork: Cannot allocate memory [root@vm ~]# cat /proc/meminfo -bash: fork: Cannot allocate memory Fix it by properly adjusting the managed page count when migrating if the zone changed. The managed page count of the zones now looks after unplug of the DIMM (and after deflating the balloon) just like before inflating the balloon (and plugging+onlining the DIMM). We'll temporarily modify the totalram page count. If this ever becomes a problem, we can fine tune by providing helpers that don't touch the totalram pages (e.g., adjust_zone_managed_page_count()). Please note that fixing up the managed page count is only necessary when we adjusted the managed page count when inflating - only if we don't have VIRTIO_BALLOON_F_DEFLATE_ON_OOM. With that feature, the managed page count is not touched when inflating/deflating. Reported-by: Yumei Huang Fixes: 3dcc0571cd64 ("mm: correctly update zone->managed_pages") Cc: # v3.11+ Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: Jiang Liu Cc: Andrew Morton Cc: Igor Mammedov Cc: virtualization@lists.linux-foundation.org Signed-off-by: David Hildenbrand Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit 4fa2d82d157e241a875c2bcda8fe4e4ad839a0be Author: Taehee Yoo Date: Thu Nov 21 12:26:45 2019 +0000 virt_wifi: fix use-after-free in virt_wifi_newlink() commit bc71d8b580ba81b55b6e15b1c0320632515b4bac upstream. When virt_wifi interface is created, virt_wifi_newlink() is called and it calls register_netdevice(). if register_netdevice() fails, it internally would call ->priv_destructor(), which is virt_wifi_net_device_destructor() and it frees netdev. but virt_wifi_newlink() still use netdev. So, use-after-free would occur in virt_wifi_newlink(). Test commands: ip link add dummy0 type dummy modprobe bonding ip link add bonding_masters link dummy0 type virt_wifi Splat looks like: [ 202.220554] BUG: KASAN: use-after-free in virt_wifi_newlink+0x88b/0x9a0 [virt_wifi] [ 202.221659] Read of size 8 at addr ffff888061629cb8 by task ip/852 [ 202.222896] CPU: 1 PID: 852 Comm: ip Not tainted 5.4.0-rc5 #3 [ 202.223765] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 202.225073] Call Trace: [ 202.225532] dump_stack+0x7c/0xbb [ 202.226869] print_address_description.constprop.5+0x1be/0x360 [ 202.229362] __kasan_report+0x12a/0x16f [ 202.230714] kasan_report+0xe/0x20 [ 202.232595] virt_wifi_newlink+0x88b/0x9a0 [virt_wifi] [ 202.233370] __rtnl_newlink+0xb9f/0x11b0 [ 202.244909] rtnl_newlink+0x65/0x90 [ ... ] Cc: stable@vger.kernel.org Fixes: c7cdba31ed8b ("mac80211-next: rtnetlink wifi simulation device") Signed-off-by: Taehee Yoo Link: https://lore.kernel.org/r/20191121122645.9355-1-ap420073@gmail.com [trim stack dump a bit] Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit ec044f55b806e273c8d1710fdecacf2b03f726dc Author: Piotr Sroka Date: Tue Sep 24 06:54:31 2019 +0100 mtd: rawnand: Change calculating of position page containing BBM commit a3c4c2339f8948b0f578e938970303a7372e60c0 upstream. Change calculating of position page containing BBM If none of BBM flags are set then function nand_bbm_get_next_page reports EINVAL. It causes that BBM is not read at all during scanning factory bad blocks. The result is that the BBT table is build without checking factory BBM at all. For Micron flash memories none of these flags are set if page size is different than 2048 bytes. Address this regression by: - adding NAND_BBM_FIRSTPAGE chip flag without any condition. It solves issue only for Micron devices. - changing the nand_bbm_get_next_page_function. It will return 0 if no of BBM flag is set and page parameter is 0. After that modification way of discovering factory bad blocks will work similar as in kernel version 5.1. Cc: stable@vger.kernel.org Fixes: f90da7818b14 (mtd: rawnand: Support bad block markers in first, second or last page) Signed-off-by: Piotr Sroka Reviewed-by: Frieder Schrempf Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 8296e51d18c024e22eb4e1b0c9a9d0cf437f2631 Author: Miquel Raynal Date: Tue Oct 22 16:58:59 2019 +0200 mtd: spear_smi: Fix Write Burst mode commit 69c7f4618c16b4678f8a4949b6bb5ace259c0033 upstream. Any write with either dd or flashcp to a device driven by the spear_smi.c driver will pass through the spear_smi_cpy_toio() function. This function will get called for chunks of up to 256 bytes. If the amount of data is smaller, we may have a problem if the data length is not 4-byte aligned. In this situation, the kernel panics during the memcpy: # dd if=/dev/urandom bs=1001 count=1 of=/dev/mtd6 spear_smi_cpy_toio [620] dest c9070000, src c7be8800, len 256 spear_smi_cpy_toio [620] dest c9070100, src c7be8900, len 256 spear_smi_cpy_toio [620] dest c9070200, src c7be8a00, len 256 spear_smi_cpy_toio [620] dest c9070300, src c7be8b00, len 233 Unhandled fault: external abort on non-linefetch (0x808) at 0xc90703e8 [...] PC is at memcpy+0xcc/0x330 The above error occurs because the implementation of memcpy_toio() tries to optimize the number of I/O by writing 4 bytes at a time as much as possible, until there are less than 4 bytes left and then switches to word or byte writes. Unfortunately, the specification states about the Write Burst mode: "the next AHB Write request should point to the next incremented address and should have the same size (byte, half-word or word)" This means ARM architecture implementation of memcpy_toio() cannot reliably be used blindly here. Workaround this situation by update the write path to stick to byte access when the burst length is not multiple of 4. Fixes: f18dbbb1bfe0 ("mtd: ST SPEAr: Add SMI driver for serial NOR flash") Cc: Russell King Cc: Boris Brezillon Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Reviewed-by: Russell King Signed-off-by: Greg Kroah-Hartman commit c287e1ae87819034854cb0c8755f4ced8e451810 Author: Rafał Miłecki Date: Mon Nov 18 12:53:08 2019 +0100 brcmfmac: disable PCIe interrupts before bus reset commit 5d26a6a6150c486f51ea2aaab33af04db02f63b8 upstream. Keeping interrupts on could result in brcmfmac freeing some resources and then IRQ handlers trying to use them. That was obviously a straight path for crashing a kernel. Example: CPU0 CPU1 ---- ---- brcmf_pcie_reset brcmf_pcie_bus_console_read brcmf_detach ... brcmf_fweh_detach brcmf_proto_detach brcmf_pcie_isr_thread ... brcmf_proto_msgbuf_rx_trigger ... drvr->proto->pd brcmf_pcie_release_irq [ 363.789218] Unable to handle kernel NULL pointer dereference at virtual address 00000038 [ 363.797339] pgd = c0004000 [ 363.800050] [00000038] *pgd=00000000 [ 363.803635] Internal error: Oops: 17 [#1] SMP ARM (...) [ 364.029209] Backtrace: [ 364.031725] [] (brcmf_proto_msgbuf_rx_trigger [brcmfmac]) from [] (brcmf_pcie_isr_thread+0x228/0x274 [brcmfmac]) [ 364.043662] r7:00000001 r6:c8ca0000 r5:00010000 r4:c7b4f800 Fixes: 4684997d9eea ("brcmfmac: reset PCIe bus on a firmware crash") Cc: stable@vger.kernel.org # v5.2+ Signed-off-by: Rafał Miłecki Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit ccacb23b70a3901aea461885a8848a49d1b6bee6 Author: Meng Li Date: Thu Nov 21 12:30:46 2019 -0600 EDAC/altera: Use fast register IO for S10 IRQs commit 56d9e7bd3fa0f105b6670021d167744bc50ae4fe upstream. When an IRQ occurs, regmap_{read,write,...}() is invoked in atomic context. Regmap must indicate register IO is fast so that a spinlock is used instead of a mutex to avoid sleeping in atomic context: lock_acquire __mutex_lock mutex_lock_nested regmap_lock_mutex regmap_write a10_eccmgr_irq_unmask unmask_irq.part.0 irq_enable __irq_startup irq_startup __setup_irq request_threaded_irq devm_request_threaded_irq altr_sdram_probe Mark it so. [ bp: Massage. ] Fixes: 3dab6bd52687 ("EDAC, altera: Add support for Stratix10 SDRAM EDAC") Reported-by: Meng Li Signed-off-by: Meng Li Signed-off-by: Thor Thayer Signed-off-by: Borislav Petkov Cc: James Morse Cc: linux-edac Cc: Mauro Carvalho Chehab Cc: Robert Richter Cc: stable Cc: Tony Luck Link: https://lkml.kernel.org/r/1574361048-17572-2-git-send-email-thor.thayer@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit fc9f2ccc279af2ee56972fa766d98e0905027ded Author: Tadeusz Struk Date: Mon Oct 7 14:46:37 2019 -0700 tpm: add check after commands attribs tab allocation commit f1689114acc5e89a196fec6d732dae3e48edb6ad upstream. devm_kcalloc() can fail and return NULL so we need to check for that. Cc: stable@vger.kernel.org Fixes: 58472f5cd4f6f ("tpm: validate TPM 2.0 commands") Signed-off-by: Tadeusz Struk Reviewed-by: Jerry Snitselaar Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 0abe8cb6f92f4409442f1f6cd34d03e3895a76cc Author: Pete Zaitcev Date: Wed Dec 4 20:39:41 2019 -0600 usb: mon: Fix a deadlock in usbmon between mmap and read commit 19e6317d24c25ee737c65d1ffb7483bdda4bb54a upstream. The problem arises because our read() function grabs a lock of the circular buffer, finds something of interest, then invokes copy_to_user() straight from the buffer, which in turn takes mm->mmap_sem. In the same time, the callback mon_bin_vma_fault() is invoked under mm->mmap_sem. It attempts to take the fetch lock and deadlocks. This patch does away with protecting of our page list with any semaphores, and instead relies on the kernel not close the device while mmap is active in a process. In addition, we prohibit re-sizing of a buffer while mmap is active. This way, when (now unlocked) fault is processed, it works with the page that is intended to be mapped-in, and not some other random page. Note that this may have an ABI impact, but hopefully no legitimate program is this wrong. Signed-off-by: Pete Zaitcev Reported-by: syzbot+56f9673bb4cdcbeb0e92@syzkaller.appspotmail.com Reviewed-by: Alan Stern Fixes: 46eb14a6e158 ("USB: fix usbmon BUG trigger") Cc: Link: https://lore.kernel.org/r/20191204203941.3503452b@suzdal.zaitcev.lan Signed-off-by: Greg Kroah-Hartman commit df58b5b819b996283e2c7701914a3e8653ff3ed8 Author: Emiliano Ingrassia Date: Wed Nov 27 17:03:55 2019 +0100 usb: core: urb: fix URB structure initialization function commit 1cd17f7f0def31e3695501c4f86cd3faf8489840 upstream. Explicitly initialize URB structure urb_list field in usb_init_urb(). This field can be potentially accessed uninitialized and its initialization is coherent with the usage of list_del_init() in usb_hcd_unlink_urb_from_ep() and usb_giveback_urb_bh() and its explicit initialization in usb_hcd_submit_urb() error path. Signed-off-by: Emiliano Ingrassia Cc: stable Link: https://lore.kernel.org/r/20191127160355.GA27196@ingrassia.epigenesys.com Signed-off-by: Greg Kroah-Hartman commit 775fcf59d63e8fa6a302ac267ec043c545106a84 Author: Johan Hovold Date: Tue Dec 10 12:25:59 2019 +0100 USB: adutux: fix interface sanity check commit 3c11c4bed02b202e278c0f5c319ae435d7fb9815 upstream. Make sure to use the current alternate setting when verifying the interface descriptors to avoid binding to an invalid interface. 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: 03270634e242 ("USB: Add ADU support for Ontrak ADU devices") Cc: stable # 2.6.19 Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20191210112601.3561-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit fa448bf6c20b8d280f145ce7a7599587ce4e6415 Author: Wen Yang Date: Sun Nov 24 22:22:36 2019 +0800 usb: roles: fix a potential use after free commit 1848a543191ae32e558bb0a5974ae7c38ebd86fc upstream. Free the sw structure only after we are done using it. This patch just moves the put_device() down a bit to avoid the use after free. Fixes: 5c54fcac9a9d ("usb: roles: Take care of driver module reference counting") Signed-off-by: Wen Yang Reviewed-by: Heikki Krogerus Reviewed-by: Peter Chen Cc: stable Cc: Hans de Goede Cc: Chunfeng Yun Cc: Suzuki K Poulose Cc: linux-usb@vger.kernel.org Cc: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/r/20191124142236.25671-1-wenyang@linux.alibaba.com Signed-off-by: Greg Kroah-Hartman commit 9794b26a8d585fba47dd79ed972dd0588c87af9c Author: Johan Hovold Date: Tue Dec 10 12:26:01 2019 +0100 USB: serial: io_edgeport: fix epic endpoint lookup commit 7c5a2df3367a2c4984f1300261345817d95b71f8 upstream. Make sure to use the current alternate setting when looking up the endpoints on epic devices to avoid binding to an invalid interface. 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: 6e8cf7751f9f ("USB: add EPIC support to the io_edgeport driver") Cc: stable # 2.6.21 Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20191210112601.3561-5-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit a94dc7cf1eb5c456b7b772b29d421cd2646a57cc Author: Johan Hovold Date: Tue Dec 10 12:26:00 2019 +0100 USB: idmouse: fix interface sanity checks commit 59920635b89d74b9207ea803d5e91498d39e8b69 upstream. Make sure to use the current alternate setting when verifying the interface descriptors to avoid binding to an invalid interface. 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: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20191210112601.3561-4-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit d97bcfefc1d7f0431927bb903901d65cd149c2f0 Author: Johan Hovold Date: Tue Dec 10 12:25:58 2019 +0100 USB: atm: ueagle-atm: add missing endpoint check commit 09068c1ad53fb077bdac288869dec2435420bdc4 upstream. Make sure that the interrupt interface has an endpoint before trying to access its endpoint descriptors to avoid dereferencing a NULL pointer. The driver binds to the interrupt interface with interface number 0, but must not assume that this interface or its current alternate setting are the first entries in the corresponding configuration arrays. Fixes: b72458a80c75 ("[PATCH] USB: Eagle and ADI 930 usb adsl modem driver") Cc: stable # 2.6.16 Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20191210112601.3561-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 252ed340d49cfd1a85b8757396a3cebebc351929 Author: Mircea Caprioru Date: Mon Nov 18 10:38:57 2019 +0200 iio: adc: ad7124: Enable internal reference commit 11d7c8d3b1259c303fb52789febed58f0bc35ad1 upstream. When the internal reference was selected by a channel it was not enabled. This patch fixes that and enables it. Fixes: b3af341bbd96 ("iio: adc: Add ad7124 support") Signed-off-by: Mircea Caprioru Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 670b7e1be8a74140e7d645c61510e85fcf5d0d6a Author: Beniamin Bia Date: Mon Nov 4 18:26:34 2019 +0200 iio: adc: ad7606: fix reading unnecessary data from device commit 341826a065660d1b77d89e6335b6095cd654271c upstream. When a conversion result is being read from ADC, the driver reads the number of channels + 1 because it thinks that IIO_CHAN_SOFT_TIMESTAMP is also a physical channel. This patch fixes this issue. Fixes: 2985a5d88455 ("staging: iio: adc: ad7606: Move out of staging") Reported-by: Robert Wörle Signed-off-by: Beniamin Bia Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit f4fe532c3db9519fe68a65b430b9020c6ba40b85 Author: Jean-Baptiste Maneyrol Date: Tue Nov 26 17:19:12 2019 +0100 iio: imu: inv_mpu6050: fix temperature reporting using bad unit commit 53eaa9c27fdc01b4f4d885223e29f97393409e7e upstream. Temperature should be reported in milli-degrees, not degrees. Fix scale and offset values to use the correct unit. This is a fix for an issue that has been present for a long time. The fixes tag reflects the point at which the code last changed in a fashion that would make this fix patch no longer apply. Backports will be necessary to fix those elements that predate that patch. Fixes: 1615fe41a195 ("iio: imu: mpu6050: Fix FIFO layout for ICM20602") Cc: stable@vger.kernel.org Signed-off-by: Jean-Baptiste Maneyrol Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 324d96d014b3b60cd54c7dd1455f9df45ec49f74 Author: Chris Lesiak Date: Thu Nov 21 20:39:42 2019 +0000 iio: humidity: hdc100x: fix IIO_HUMIDITYRELATIVE channel reporting commit 342a6928bd5017edbdae376042d8ad6af3d3b943 upstream. The IIO_HUMIDITYRELATIVE channel was being incorrectly reported back as percent when it should have been milli percent. This is via an incorrect scale value being returned to userspace. Signed-off-by: Chris Lesiak Acked-by: Matt Ranostay Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 469ad78c87b27c2eb95224b16b136e2e83585404 Author: Nuno Sá Date: Mon Oct 28 17:33:48 2019 +0100 iio: adis16480: Fix scales factors commit 49549cb23a2926eba70bb634e361daea0f319794 upstream. This patch fixes the scales for the gyroscope, accelerometer and barometer. The pressure scale was just wrong. For the others, the scale factors were not taking into account that a 32bit word is being read from the device. Fixes: 7abad1063deb ("iio: adis16480: Fix scale factors") Fixes: 82e7a1b25017 ("iio: imu: adis16480: Add support for ADIS1649x family of devices") Signed-off-by: Nuno Sá Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 2ec0d8a41c0c26985d836bf2e56fbf8ab8416d40 Author: Nuno Sá Date: Mon Oct 28 17:33:49 2019 +0100 iio: adis16480: Add debugfs_reg_access entry commit 4c35b7a51e2f291471f7221d112c6a45c63e83bc upstream. The driver is defining debugfs entries by calling `adis16480_debugfs_init()`. However, those entries are attached to the iio_dev debugfs entry which won't exist if no debugfs_reg_access callback is provided. Fixes: 2f3abe6cbb6c ("iio:imu: Add support for the ADIS16480 and similar IMUs") Signed-off-by: Nuno Sá Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 6b2a08f142062ca15311f2d7180902609e42ad08 Author: H. Nikolaus Schaller Date: Thu Nov 7 11:30:36 2019 +0100 ARM: dts: pandora-common: define wl1251 as child node of mmc3 commit 4f9007d692017cef38baf2a9b82b7879d5b2407b upstream. Since v4.7 the dma initialization requires that there is a device tree property for "rx" and "tx" channels which is not provided by the pdata-quirks initialization. By conversion of the mmc3 setup to device tree this will finally allows to remove the OpenPandora wlan specific omap3 data-quirks. Fixes: 81eef6ca9201 ("mmc: omap_hsmmc: Use dma_request_chan() for requesting DMA channel") Signed-off-by: H. Nikolaus Schaller Cc: # v4.7+ Acked-by: Tony Lindgren Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 5a62c8694bb7dba2014d485d12beda71225b8769 Author: Georgi Djakov Date: Thu Dec 12 09:53:30 2019 +0200 interconnect: qcom: sdm845: Walk the list safely on node removal commit b29b8113bb41285eb7ed55ce0c65017b5c0240f7 upstream. As we will remove items off the list using list_del(), we need to use the safe version of list_for_each_entry(). Fixes: b5d2f741077a ("interconnect: qcom: Add sdm845 interconnect provider driver") Reported-by: Dmitry Osipenko Reviewed-by: Bjorn Andersson Signed-off-by: Georgi Djakov Cc: # v5.3+ Link: https://lore.kernel.org/r/20191212075332.16202-3-georgi.djakov@linaro.org Signed-off-by: Greg Kroah-Hartman commit 89159f7e47f2f140c32b0957e19219b23b1f7e15 Author: Mathias Nyman Date: Wed Dec 11 16:20:07 2019 +0200 xhci: make sure interrupts are restored to correct state commit bd82873f23c9a6ad834348f8b83f3b6a5bca2c65 upstream. spin_unlock_irqrestore() might be called with stale flags after reading port status, possibly restoring interrupts to a incorrect state. If a usb2 port just finished resuming while the port status is read the spin lock will be temporary released and re-acquired in a separate function. The flags parameter is passed as value instead of a pointer, not updating flags properly before the final spin_unlock_irqrestore() is called. Cc: # v3.12+ Fixes: 8b3d45705e54 ("usb: Fix xHCI host issues on remote wakeup.") Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20191211142007.8847-7-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit e03582344d00d7be9d24fbfeef8e4e74dce7401c Author: Mathias Nyman Date: Wed Dec 11 16:20:06 2019 +0200 xhci: handle some XHCI_TRUST_TX_LENGTH quirks cases as default behaviour. commit 7ff11162808cc2ec66353fc012c58bb449c892c3 upstream. xhci driver claims it needs XHCI_TRUST_TX_LENGTH quirk for both Broadcom/Cavium and a Renesas xHC controllers. The quirk was inteded for handling false "success" complete event for transfers that had data left untransferred. These transfers should complete with "short packet" events instead. In these two new cases the false "success" completion is reported after a "short packet" if the TD consists of several TRBs. xHCI specs 4.10.1.1.2 say remaining TRBs should report "short packet" as well after the first short packet in a TD, but this issue seems so common it doesn't make sense to add the quirk for all vendors. Turn these events into short packets automatically instead. This gets rid of the "The WARN Successful completion on short TX for slot 1 ep 1: needs XHCI_TRUST_TX_LENGTH quirk" warning in many cases. Cc: Reported-by: Eli Billauer Reported-by: Ard Biesheuvel Tested-by: Eli Billauer Tested-by: Ard Biesheuvel Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20191211142007.8847-6-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit c9382a9ac1db15cd9c507e34c16177be1f3d2376 Author: Kai-Heng Feng Date: Wed Dec 11 16:20:05 2019 +0200 xhci: Increase STS_HALT timeout in xhci_suspend() commit 7c67cf6658cec70d8a43229f2ce74ca1443dc95e upstream. I've recently observed failed xHCI suspend attempt on AMD Raven Ridge system: kernel: xhci_hcd 0000:04:00.4: WARN: xHC CMD_RUN timeout kernel: PM: suspend_common(): xhci_pci_suspend+0x0/0xd0 returns -110 kernel: PM: pci_pm_suspend(): hcd_pci_suspend+0x0/0x30 returns -110 kernel: PM: dpm_run_callback(): pci_pm_suspend+0x0/0x150 returns -110 kernel: PM: Device 0000:04:00.4 failed to suspend async: error -110 Similar to commit ac343366846a ("xhci: Increase STS_SAVE timeout in xhci_suspend()") we also need to increase the HALT timeout to make it be able to suspend again. Cc: # 5.2+ Fixes: f7fac17ca925 ("xhci: Convert xhci_handshake() to use readl_poll_timeout_atomic()") Signed-off-by: Kai-Heng Feng Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20191211142007.8847-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 34880efa320c44f74d0529bf417cc457fea725c8 Author: Mathias Nyman Date: Wed Dec 11 16:20:03 2019 +0200 xhci: fix USB3 device initiated resume race with roothub autosuspend commit 057d476fff778f1d3b9f861fdb5437ea1a3cfc99 upstream. A race in xhci USB3 remote wake handling may force device back to suspend after it initiated resume siganaling, causing a missed resume event or warm reset of device. When a USB3 link completes resume signaling and goes to enabled (UO) state a interrupt is issued and the interrupt handler will clear the bus_state->port_remote_wakeup resume flag, allowing bus suspend. If the USB3 roothub thread just finished reading port status before the interrupt, finding ports still in suspended (U3) state, but hasn't yet started suspending the hub, then the xhci interrupt handler will clear the flag that prevented roothub suspend and allow bus to suspend, forcing all port links back to suspended (U3) state. Example case: usb_runtime_suspend() # because all ports still show suspended U3 usb_suspend_both() hub_suspend(); # successful as hub->wakeup_bits not set yet ==> INTERRUPT xhci_irq() handle_port_status() clear bus_state->port_remote_wakeup usb_wakeup_notification() sets hub->wakeup_bits; kick_hub_wq() <== END INTERRUPT hcd_bus_suspend() xhci_bus_suspend() # success as port_remote_wakeup bits cleared Fix this by increasing roothub usage count during port resume to prevent roothub autosuspend, and by making sure bus_state->port_remote_wakeup flag is only cleared after resume completion is visible, i.e. after xhci roothub returned U0 or other non-U3 link state link on a get port status request. Issue rootcaused by Chiasheng Lee Cc: Cc: Lee, Hou-hsun Reported-by: Lee, Chiasheng Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20191211142007.8847-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 4f9f1a79f990eb13179268848874c8a834e43ab6 Author: Mika Westerberg Date: Wed Dec 11 16:20:02 2019 +0200 xhci: Fix memory leak in xhci_add_in_port() commit ce91f1a43b37463f517155bdfbd525eb43adbd1a upstream. When xHCI is part of Alpine or Titan Ridge Thunderbolt controller and the xHCI device is hot-removed as a result of unplugging a dock for example, the driver leaks memory it allocates for xhci->usb3_rhub.psi and xhci->usb2_rhub.psi in xhci_add_in_port() as reported by kmemleak: unreferenced object 0xffff922c24ef42f0 (size 16): comm "kworker/u16:2", pid 178, jiffies 4294711640 (age 956.620s) hex dump (first 16 bytes): 21 00 0c 00 12 00 dc 05 23 00 e0 01 00 00 00 00 !.......#....... backtrace: [<000000007ac80914>] xhci_mem_init+0xcf8/0xeb7 [<0000000001b6d775>] xhci_init+0x7c/0x160 [<00000000db443fe3>] xhci_gen_setup+0x214/0x340 [<00000000fdffd320>] xhci_pci_setup+0x48/0x110 [<00000000541e1e03>] usb_add_hcd.cold+0x265/0x747 [<00000000ca47a56b>] usb_hcd_pci_probe+0x219/0x3b4 [<0000000021043861>] xhci_pci_probe+0x24/0x1c0 [<00000000b9231f25>] local_pci_probe+0x3d/0x70 [<000000006385c9d7>] pci_device_probe+0xd0/0x150 [<0000000070241068>] really_probe+0xf5/0x3c0 [<0000000061f35c0a>] driver_probe_device+0x58/0x100 [<000000009da11198>] bus_for_each_drv+0x79/0xc0 [<000000009ce45f69>] __device_attach+0xda/0x160 [<00000000df201aaf>] pci_bus_add_device+0x46/0x70 [<0000000088a1bc48>] pci_bus_add_devices+0x27/0x60 [<00000000ad9ee708>] pci_bus_add_devices+0x52/0x60 unreferenced object 0xffff922c24ef3318 (size 8): comm "kworker/u16:2", pid 178, jiffies 4294711640 (age 956.620s) hex dump (first 8 bytes): 34 01 05 00 35 41 0a 00 4...5A.. backtrace: [<000000007ac80914>] xhci_mem_init+0xcf8/0xeb7 [<0000000001b6d775>] xhci_init+0x7c/0x160 [<00000000db443fe3>] xhci_gen_setup+0x214/0x340 [<00000000fdffd320>] xhci_pci_setup+0x48/0x110 [<00000000541e1e03>] usb_add_hcd.cold+0x265/0x747 [<00000000ca47a56b>] usb_hcd_pci_probe+0x219/0x3b4 [<0000000021043861>] xhci_pci_probe+0x24/0x1c0 [<00000000b9231f25>] local_pci_probe+0x3d/0x70 [<000000006385c9d7>] pci_device_probe+0xd0/0x150 [<0000000070241068>] really_probe+0xf5/0x3c0 [<0000000061f35c0a>] driver_probe_device+0x58/0x100 [<000000009da11198>] bus_for_each_drv+0x79/0xc0 [<000000009ce45f69>] __device_attach+0xda/0x160 [<00000000df201aaf>] pci_bus_add_device+0x46/0x70 [<0000000088a1bc48>] pci_bus_add_devices+0x27/0x60 [<00000000ad9ee708>] pci_bus_add_devices+0x52/0x60 Fix this by calling kfree() for the both psi objects in xhci_mem_cleanup(). Cc: # 4.4+ Fixes: 47189098f8be ("xhci: parse xhci protocol speed ID list for usb 3.1 usage") Signed-off-by: Mika Westerberg Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20191211142007.8847-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit d003c1ff598dd3f563f298a3513340faf8e1f514 Author: Henry Lin Date: Wed Dec 11 16:20:04 2019 +0200 usb: xhci: only set D3hot for pci device commit f2c710f7dca8457e88b4ac9de2060f011254f9dd upstream. Xhci driver cannot call pci_set_power_state() on non-pci xhci host controllers. For example, NVIDIA Tegra XHCI host controller which acts as platform device with XHCI_SPURIOUS_WAKEUP quirk set in some platform hits this issue during shutdown. Cc: Fixes: 638298dc66ea ("xhci: Fix spurious wakeups after S5 on Haswell") Signed-off-by: Henry Lin Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20191211142007.8847-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 2aaa26bab72b6cf4c63349e219125de7b601eea9 Author: Johan Hovold Date: Mon Dec 2 09:56:10 2019 +0100 staging: gigaset: add endpoint-type sanity check commit ed9ed5a89acba51b82bdff61144d4e4a4245ec8a upstream. Add missing endpoint-type sanity checks to probe. This specifically prevents a warning in USB core on URB submission when fuzzing USB descriptors. Signed-off-by: Johan Hovold Cc: stable Link: https://lore.kernel.org/r/20191202085610.12719-4-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 8843945d477a0decd51d8a0882ab03bfc97e7bc8 Author: Johan Hovold Date: Mon Dec 2 09:56:09 2019 +0100 staging: gigaset: fix illegal free on probe errors commit 84f60ca7b326ed8c08582417493982fe2573a9ad upstream. The driver failed to initialise its receive-buffer pointer, something which could lead to an illegal free on late probe errors. Fix this by making sure to clear all driver data at allocation. Fixes: 2032e2c2309d ("usb_gigaset: code cleanup") Cc: stable # 2.6.33 Cc: Tilman Schmidt Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20191202085610.12719-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 21bd5e89949598c28beba844c0cbdfbd27c00a92 Author: Johan Hovold Date: Mon Dec 2 09:56:08 2019 +0100 staging: gigaset: fix general protection fault on probe commit 53f35a39c3860baac1e5ca80bf052751cfb24a99 upstream. Fix a general protection fault when accessing the endpoint descriptors which could be triggered by a malicious device due to missing sanity checks on the number of endpoints. Reported-by: syzbot+35b1c403a14f5c89eba7@syzkaller.appspotmail.com Fixes: 07dc1f9f2f80 ("[PATCH] isdn4linux: Siemens Gigaset drivers - M105 USB DECT adapter") Cc: stable # 2.6.17 Cc: Hansjoerg Lipp Cc: Tilman Schmidt Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20191202085610.12719-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 010d2f0afa7a9421b98d3aabe815b478c5a2be14 Author: Marcelo Diop-Gonzalez Date: Tue Dec 3 10:39:21 2019 -0500 staging: vchiq: call unregister_chrdev_region() when driver registration fails commit d2cdb20507fe2079a146459f9718b45d78cbbe61 upstream. This undoes the previous call to alloc_chrdev_region() on failure, and is probably what was meant originally given the label name. Signed-off-by: Marcelo Diop-Gonzalez Cc: stable Fixes: 187ac53e590c ("staging: vchiq_arm: rework probe and init functions") Reviewed-by: Dan Carpenter Reviewed-by: Nicolas Saenz Julienne Link: https://lore.kernel.org/r/20191203153921.70540-1-marcgonzalez@google.com Signed-off-by: Greg Kroah-Hartman commit 8155eefdc11a079fbb4ab79e9ade98d8c3c6c6bc Author: Johan Hovold Date: Tue Dec 10 12:47:51 2019 +0100 staging: rtl8712: fix interface sanity check commit c724f776f048538ecfdf53a52b7a522309f5c504 upstream. Make sure to use the current alternate setting when verifying the interface descriptors to avoid binding to an invalid interface. 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: 2865d42c78a9 ("staging: r8712u: Add the new driver to the mainline kernel") Cc: stable # 2.6.37 Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20191210114751.5119-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit fe62c309af59f0e8cf473c8a0ed2caa60fee2799 Author: Johan Hovold Date: Tue Dec 10 12:47:50 2019 +0100 staging: rtl8188eu: fix interface sanity check commit 74ca34118a0e05793935d804ccffcedd6eb56596 upstream. Make sure to use the current alternate setting when verifying the interface descriptors to avoid binding to an invalid interface. 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: c2478d39076b ("staging: r8188eu: Add files for new driver - part 20") Cc: stable # 3.12 Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20191210114751.5119-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 409579300981183be71034b483d1f5eedbbaed2d Author: Todd Kjos Date: Fri Dec 13 12:25:31 2019 -0800 binder: fix incorrect calculation for num_valid commit 16981742717b04644a41052570fb502682a315d2 upstream. For BINDER_TYPE_PTR and BINDER_TYPE_FDA transactions, the num_valid local was calculated incorrectly causing the range check in binder_validate_ptr() to miss out-of-bounds offsets. Fixes: bde4a19fc04f ("binder: use userspace pointer as base of buffer space") Signed-off-by: Todd Kjos Cc: stable Link: https://lore.kernel.org/r/20191213202531.55010-1-tkjos@google.com Signed-off-by: Greg Kroah-Hartman commit b309d5aeaa8342d9b6bbcd94c256a1cc247f6fad Author: Nagarjuna Kristam Date: Mon Nov 4 14:54:30 2019 +0530 usb: host: xhci-tegra: Correct phy enable sequence commit 6351653febbb784d86fdf83afe41f7523a61b392 upstream. XUSB phy needs to be enabled before un-powergating the power partitions. However in the current sequence, it happens opposite. Correct the phy enable and powergating partition sequence to avoid any boot hangs. Signed-off-by: Nagarjuna Kristam Cc: stable Signed-off-by: Jui Chang Kuo Tested-by: Jon Hunter Acked-by: Thierry Reding Link: https://lore.kernel.org/r/1572859470-7823-1-git-send-email-nkristam@nvidia.com Signed-off-by: Greg Kroah-Hartman commit 05f3234419d380058f8418042d18ff44b10eeacd Author: Kai-Heng Feng Date: Wed Nov 6 14:27:10 2019 +0800 usb: Allow USB device to be warm reset in suspended state commit e76b3bf7654c3c94554c24ba15a3d105f4006c80 upstream. On Dell WD15 dock, sometimes USB ethernet cannot be detected after plugging cable to the ethernet port, the hub and roothub get runtime resumed and runtime suspended immediately: ... [ 433.315169] xhci_hcd 0000:3a:00.0: hcd_pci_runtime_resume: 0 [ 433.315204] usb usb4: usb auto-resume [ 433.315226] hub 4-0:1.0: hub_resume [ 433.315239] xhci_hcd 0000:3a:00.0: Get port status 4-1 read: 0x10202e2, return 0x10343 [ 433.315264] usb usb4-port1: status 0343 change 0001 [ 433.315279] xhci_hcd 0000:3a:00.0: clear port1 connect change, portsc: 0x10002e2 [ 433.315293] xhci_hcd 0000:3a:00.0: Get port status 4-2 read: 0x2a0, return 0x2a0 [ 433.317012] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling. [ 433.422282] xhci_hcd 0000:3a:00.0: Get port status 4-1 read: 0x10002e2, return 0x343 [ 433.422307] usb usb4-port1: do warm reset [ 433.422311] usb 4-1: device reset not allowed in state 8 [ 433.422339] hub 4-0:1.0: state 7 ports 2 chg 0002 evt 0000 [ 433.422346] xhci_hcd 0000:3a:00.0: Get port status 4-1 read: 0x10002e2, return 0x343 [ 433.422356] usb usb4-port1: do warm reset [ 433.422358] usb 4-1: device reset not allowed in state 8 [ 433.422428] xhci_hcd 0000:3a:00.0: set port remote wake mask, actual port 0 status = 0xf0002e2 [ 433.422455] xhci_hcd 0000:3a:00.0: set port remote wake mask, actual port 1 status = 0xe0002a0 [ 433.422465] hub 4-0:1.0: hub_suspend [ 433.422475] usb usb4: bus auto-suspend, wakeup 1 [ 433.426161] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling. [ 433.466209] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.510204] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.554051] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.598235] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.642154] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.686204] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.730205] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.774203] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.818207] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.862040] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.862053] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling. [ 433.862077] xhci_hcd 0000:3a:00.0: xhci_suspend: stopping port polling. [ 433.862096] xhci_hcd 0000:3a:00.0: // Setting command ring address to 0x8578fc001 [ 433.862312] xhci_hcd 0000:3a:00.0: hcd_pci_runtime_suspend: 0 [ 433.862445] xhci_hcd 0000:3a:00.0: PME# enabled [ 433.902376] xhci_hcd 0000:3a:00.0: restoring config space at offset 0xc (was 0x0, writing 0x20) [ 433.902395] xhci_hcd 0000:3a:00.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100403) [ 433.902490] xhci_hcd 0000:3a:00.0: PME# disabled [ 433.902504] xhci_hcd 0000:3a:00.0: enabling bus mastering [ 433.902547] xhci_hcd 0000:3a:00.0: // Setting command ring address to 0x8578fc001 [ 433.902649] pcieport 0000:00:1b.0: PME: Spurious native interrupt! [ 433.902839] xhci_hcd 0000:3a:00.0: Port change event, 4-1, id 3, portsc: 0xb0202e2 [ 433.902842] xhci_hcd 0000:3a:00.0: resume root hub [ 433.902845] xhci_hcd 0000:3a:00.0: handle_port_status: starting port polling. [ 433.902877] xhci_hcd 0000:3a:00.0: xhci_resume: starting port polling. [ 433.902889] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling. [ 433.902891] xhci_hcd 0000:3a:00.0: hcd_pci_runtime_resume: 0 [ 433.902919] usb usb4: usb wakeup-resume [ 433.902942] usb usb4: usb auto-resume [ 433.902966] hub 4-0:1.0: hub_resume ... As Mathias pointed out, the hub enters Cold Attach Status state and requires a warm reset. However usb_reset_device() bails out early when the device is in suspended state, as its callers port_event() and hub_event() don't always resume the device. Since there's nothing wrong to reset a suspended device, allow usb_reset_device() to do so to solve the issue. Signed-off-by: Kai-Heng Feng Acked-by: Alan Stern Cc: stable Link: https://lore.kernel.org/r/20191106062710.29880-1-kai.heng.feng@canonical.com Signed-off-by: Greg Kroah-Hartman commit ba4bd7beaacf8c922453a27a19f5644e64f1351c Author: Oliver Neukum Date: Thu Nov 14 12:27:58 2019 +0100 USB: documentation: flags on usb-storage versus UAS commit 65cc8bf99349f651a0a2cee69333525fe581f306 upstream. Document which flags work storage, UAS or both Signed-off-by: Oliver Neukum Cc: stable Link: https://lore.kernel.org/r/20191114112758.32747-4-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit 24ddc20833bb7b1081d2165de5a28baa55e4dec1 Author: Oliver Neukum Date: Thu Nov 14 12:27:57 2019 +0100 USB: uas: heed CAPACITY_HEURISTICS commit 335cbbd5762d5e5c67a8ddd6e6362c2aa42a328f upstream. There is no need to ignore this flag. We should be as close to storage in that regard as makes sense, so honor flags whose cost is tiny. Signed-off-by: Oliver Neukum Cc: stable Link: https://lore.kernel.org/r/20191114112758.32747-3-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit f2f71bfaa0d74e094df92f5e5d9942a6de2ce3ee Author: Oliver Neukum Date: Thu Nov 14 12:27:56 2019 +0100 USB: uas: honor flag to avoid CAPACITY16 commit bff000cae1eec750d62e265c4ba2db9af57b17e1 upstream. Copy the support over from usb-storage to get feature parity Signed-off-by: Oliver Neukum Cc: stable Link: https://lore.kernel.org/r/20191114112758.32747-2-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit b35cb9b5c3152f0fa8d92b03c1cb9e3473406045 Author: Arnd Bergmann Date: Wed Nov 6 10:06:54 2019 +0100 media: venus: remove invalid compat_ioctl32 handler commit 4adc0423de92cf850d1ef5c0e7cb28fd7a38219e upstream. v4l2_compat_ioctl32() is the function that calls into v4l2_file_operations->compat_ioctl32(), so setting that back to the same function leads to a trivial endless loop, followed by a kernel stack overrun. Remove the incorrect assignment. Cc: stable@vger.kernel.org Fixes: 7472c1c69138 ("[media] media: venus: vdec: add video decoder files") Fixes: aaaa93eda64b ("[media] media: venus: venc: add video encoder files") Signed-off-by: Arnd Bergmann Acked-by: Stanimir Varbanov Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit cedfebe22c7989778133e35a2a6c9bc008836648 Author: Arun Easi Date: Tue Nov 5 07:06:55 2019 -0800 scsi: qla2xxx: Fix memory leak when sending I/O fails commit 2f856d4e8c23f5ad5221f8da4a2f22d090627f19 upstream. On heavy loads, a memory leak of the srb_t structure is observed. This would make the qla2xxx_srbs cache gobble up memory. Fixes: 219d27d7147e0 ("scsi: qla2xxx: Fix race conditions in the code for aborting SCSI commands") Cc: stable@vger.kernel.org # 5.2 Link: https://lore.kernel.org/r/20191105150657.8092-7-hmadhani@marvell.com Reviewed-by: Ewan D. Milne Signed-off-by: Arun Easi Signed-off-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 3c95c10623185d58247d941a564523627d2df2d8 Author: Quinn Tran Date: Tue Nov 5 07:06:53 2019 -0800 scsi: qla2xxx: Fix driver unload hang commit dd322b7f3efc8cda085bb60eadc4aee6324eadd8 upstream. This patch fixes driver unload hang by removing msleep() Fixes: d74595278f4ab ("scsi: qla2xxx: Add multiple queue pair functionality.") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20191105150657.8092-5-hmadhani@marvell.com Reviewed-by: Ewan D. Milne Signed-off-by: Quinn Tran Signed-off-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 599495c1e703df9291476f79d85ea2bf96f9a65a Author: Steffen Maier Date: Fri Oct 25 18:12:53 2019 +0200 scsi: zfcp: trace channel log even for FCP command responses commit 100843f176109af94600e500da0428e21030ca7f upstream. While v2.6.26 commit b75db73159cc ("[SCSI] zfcp: Add qtcb dump to hba debug trace") is right that we don't want to flood the (payload) trace ring buffer, we don't trace successful FCP command responses by default. So we can include the channel log for problem determination with failed responses of any FSF request type. Fixes: b75db73159cc ("[SCSI] zfcp: Add qtcb dump to hba debug trace") Fixes: a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.") Cc: #2.6.38+ Link: https://lore.kernel.org/r/e37597b5c4ae123aaa85fd86c23a9f71e994e4a9.1572018132.git.bblock@linux.ibm.com Reviewed-by: Benjamin Block Signed-off-by: Steffen Maier Signed-off-by: Benjamin Block Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit af5348ee3201823e40094898808b39f6315a0d65 Author: Jian-Hong Pan Date: Thu Oct 31 17:34:09 2019 +0800 Revert "nvme: Add quirk for Kingston NVME SSD running FW E8FK11.T" commit 655e7aee1f0398602627a485f7dca6c29cc96cae upstream. Since e045fa29e893 ("PCI/MSI: Fix incorrect MSI-X masking on resume") is merged, we can revert the previous quirk now. This reverts commit 19ea025e1d28c629b369c3532a85b3df478cc5c6. Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204887 Fixes: 19ea025e1d28 ("nvme: Add quirk for Kingston NVME SSD running FW E8FK11.T") Link: https://lore.kernel.org/r/20191031093408.9322-1-jian-hong@endlessm.com Signed-off-by: Jian-Hong Pan Signed-off-by: Bjorn Helgaas Acked-by: Christoph Hellwig Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 5dbc67c98f9bd6945f1da01b201254751b8be6c6 Author: Gustavo A. R. Silva Date: Wed Nov 6 14:28:21 2019 -0600 usb: gadget: pch_udc: fix use after free commit 66d1b0c0580b7f1b1850ee4423f32ac42afa2e92 upstream. Remove pointer dereference after free. pci_pool_free doesn't care about contents of td. It's just a void* for it Addresses-Coverity-ID: 1091173 ("Use after free") Cc: stable@vger.kernel.org Acked-by: Michal Nazarewicz Signed-off-by: Gustavo A. R. Silva Link: https://lore.kernel.org/r/20191106202821.GA20347@embeddedor Signed-off-by: Greg Kroah-Hartman commit d8bb530114c2620dfc6ed2cc828c41502dda9879 Author: Wei Yongjun Date: Wed Oct 30 03:40:46 2019 +0000 usb: gadget: configfs: Fix missing spin_lock_init() commit 093edc2baad2c258b1f55d1ab9c63c2b5ae67e42 upstream. The driver allocates the spinlock but not initialize it. Use spin_lock_init() on it to initialize it correctly. This is detected by Coccinelle semantic patch. Fixes: 1a1c851bbd70 ("usb: gadget: configfs: fix concurrent issue between composite APIs") Signed-off-by: Wei Yongjun Cc: stable Reviewed-by: Peter Chen Link: https://lore.kernel.org/r/20191030034046.188808-1-weiyongjun1@huawei.com Signed-off-by: Greg Kroah-Hartman