commit a9518c1aec5b6a8e1a04bbd54e6ba9725ef0db4c Author: Greg Kroah-Hartman Date: Thu Oct 1 13:18:26 2020 +0200 Linux 5.4.69 Tested-by: Jon Hunter Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Link: https://lore.kernel.org/r/20200929110010.467764689@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 9fb8e10b0519dd535fb2f3b320e30d56d070cafe Author: Jiri Slaby Date: Thu Oct 31 10:59:46 2019 +0100 ata: sata_mv, avoid trigerrable BUG_ON commit e9f691d899188679746eeb96e6cb520459eda9b4 upstream. There are several reports that the BUG_ON on unsupported command in mv_qc_prep can be triggered under some circumstances: https://bugzilla.suse.com/show_bug.cgi?id=1110252 https://serverfault.com/questions/888897/raid-problems-after-power-outage https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1652185 https://bugs.centos.org/view.php?id=14998 Let sata_mv handle the failure gracefully: warn about that incl. the failed command number and return an AC_ERR_INVALID error. We can do that now thanks to the previous patch. Remove also the long-standing FIXME. [v2] use %.2x as commands are defined as hexa. Signed-off-by: Jiri Slaby Cc: Jens Axboe Cc: linux-ide@vger.kernel.org Cc: Sergei Shtylyov Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit e11c83520cd04b813cd1748ee2a8f2c620e5f7e3 Author: Jiri Slaby Date: Thu Oct 31 10:59:45 2019 +0100 ata: make qc_prep return ata_completion_errors commit 95364f36701e62dd50eee91e1303187fd1a9f567 upstream. In case a driver wants to return an error from qc_prep, return enum ata_completion_errors. sata_mv is one of those drivers -- see the next patch. Other drivers return the newly defined AC_ERR_OK. [v2] use enum ata_completion_errors and AC_ERR_OK. Signed-off-by: Jiri Slaby Cc: Jens Axboe Cc: linux-ide@vger.kernel.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit b6e503c0a0ffd67de01fb5b3f01883c740745460 Author: Jiri Slaby Date: Thu Oct 31 10:59:44 2019 +0100 ata: define AC_ERR_OK commit 25937580a5065d6fbd92d9c8ebd47145ad80052e upstream. Since we will return enum ata_completion_errors from qc_prep in the next patch, let's define AC_ERR_OK to mark the OK status. Signed-off-by: Jiri Slaby Cc: Jens Axboe Cc: linux-ide@vger.kernel.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit b4a9fdf062e8b38b6cb4aa3a61035762a472833b Author: Muchun Song Date: Thu Aug 6 01:20:46 2020 +0800 kprobes: Fix compiler warning for !CONFIG_KPROBES_ON_FTRACE commit 10de795a5addd1962406796a6e13ba6cc0fc6bee upstream. Fix compiler warning(as show below) for !CONFIG_KPROBES_ON_FTRACE. kernel/kprobes.c: In function 'kill_kprobe': kernel/kprobes.c:1116:33: warning: statement with no effect [-Wunused-value] 1116 | #define disarm_kprobe_ftrace(p) (-ENODEV) | ^ kernel/kprobes.c:2154:3: note: in expansion of macro 'disarm_kprobe_ftrace' 2154 | disarm_kprobe_ftrace(p); Link: https://lore.kernel.org/r/20200805142136.0331f7ea@canb.auug.org.au Link: https://lkml.kernel.org/r/20200805172046.19066-1-songmuchun@bytedance.com Reported-by: Stephen Rothwell Fixes: 0cb2f1372baa ("kprobes: Fix NULL pointer dereference at kprobe_ftrace_handler") Acked-by: Masami Hiramatsu Acked-by: John Fastabend Signed-off-by: Muchun Song Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 3d9f39d274eaee792b9d3d637fb0f935a79d482d Author: Mike Snitzer Date: Mon Sep 14 13:04:19 2020 -0400 dm: fix bio splitting and its bio completion order for regular IO commit ee1dfad5325ff1cfb2239e564cd411b3bfe8667a upstream. dm_queue_split() is removed because __split_and_process_bio() _must_ handle splitting bios to ensure proper bio submission and completion ordering as a bio is split. Otherwise, multiple recursive calls to ->submit_bio will cause multiple split bios to be allocated from the same ->bio_split mempool at the same time. This would result in deadlock in low memory conditions because no progress could be made (only one bio is available in ->bio_split mempool). This fix has been verified to still fix the loss of performance, due to excess splitting, that commit 120c9257f5f1 provided. Fixes: 120c9257f5f1 ("Revert "dm: always call blk_queue_split() in dm_process_bio()"") Cc: stable@vger.kernel.org # 5.0+, requires custom backport due to 5.9 changes Reported-by: Ming Lei Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit c9bfb7b4d944c9b2294426efc0d30a7c9bb4c2b1 Author: Marc Zyngier Date: Tue Sep 15 11:42:17 2020 +0100 KVM: arm64: Assume write fault on S1PTW permission fault on instruction fetch commit c4ad98e4b72cb5be30ea282fce935248f2300e62 upstream. KVM currently assumes that an instruction abort can never be a write. This is in general true, except when the abort is triggered by a S1PTW on instruction fetch that tries to update the S1 page tables (to set AF, for example). This can happen if the page tables have been paged out and brought back in without seeing a direct write to them (they are thus marked read only), and the fault handling code will make the PT executable(!) instead of writable. The guest gets stuck forever. In these conditions, the permission fault must be considered as a write so that the Stage-1 update can take place. This is essentially the I-side equivalent of the problem fixed by 60e21a0ef54c ("arm64: KVM: Take S1 walks into account when determining S2 write faults"). Update kvm_is_write_fault() to return true on IABT+S1PTW, and introduce kvm_vcpu_trap_is_exec_fault() that only return true when no faulting on a S1 fault. Additionally, kvm_vcpu_dabt_iss1tw() is renamed to kvm_vcpu_abt_iss1tw(), as the above makes it plain that it isn't specific to data abort. Signed-off-by: Marc Zyngier Reviewed-by: Will Deacon Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200915104218.1284701-2-maz@kernel.org Signed-off-by: Greg Kroah-Hartman commit 5dcb66f970a8eb799e9802c357ff4ef242d3f7d2 Author: Christian Borntraeger Date: Mon Sep 21 12:48:36 2020 +0200 s390/zcrypt: Fix ZCRYPT_PERDEV_REQCNT ioctl commit f7e80983f0cf470bb82036e73bff4d5a7daf8fc2 upstream. reqcnt is an u32 pointer but we do copy sizeof(reqcnt) which is the size of the pointer. This means we only copy 8 byte. Let us copy the full monty. Signed-off-by: Christian Borntraeger Cc: Harald Freudenberger Cc: stable@vger.kernel.org Fixes: af4a72276d49 ("s390/zcrypt: Support up to 256 crypto adapters.") Reviewed-by: Harald Freudenberger Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 4f5260ee0ce30773ec62799b71a0cf75d7ed9b92 Author: Vasily Gorbik Date: Fri Sep 25 21:19:10 2020 -0700 mm/gup: fix gup_fast with dynamic page table folding commit d3f7b1bb204099f2f7306318896223e8599bb6a2 upstream. Currently to make sure that every page table entry is read just once gup_fast walks perform READ_ONCE and pass pXd value down to the next gup_pXd_range function by value e.g.: static int gup_pud_range(p4d_t p4d, unsigned long addr, unsigned long end, unsigned int flags, struct page **pages, int *nr) ... pudp = pud_offset(&p4d, addr); This function passes a reference on that local value copy to pXd_offset, and might get the very same pointer in return. This happens when the level is folded (on most arches), and that pointer should not be iterated. On s390 due to the fact that each task might have different 5,4 or 3-level address translation and hence different levels folded the logic is more complex and non-iteratable pointer to a local copy leads to severe problems. Here is an example of what happens with gup_fast on s390, for a task with 3-level paging, crossing a 2 GB pud boundary: // addr = 0x1007ffff000, end = 0x10080001000 static int gup_pud_range(p4d_t p4d, unsigned long addr, unsigned long end, unsigned int flags, struct page **pages, int *nr) { unsigned long next; pud_t *pudp; // pud_offset returns &p4d itself (a pointer to a value on stack) pudp = pud_offset(&p4d, addr); do { // on second iteratation reading "random" stack value pud_t pud = READ_ONCE(*pudp); // next = 0x10080000000, due to PUD_SIZE/MASK != PGDIR_SIZE/MASK on s390 next = pud_addr_end(addr, end); ... } while (pudp++, addr = next, addr != end); // pudp++ iterating over stack return 1; } This happens since s390 moved to common gup code with commit d1874a0c2805 ("s390/mm: make the pxd_offset functions more robust") and commit 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_fast code"). s390 tried to mimic static level folding by changing pXd_offset primitives to always calculate top level page table offset in pgd_offset and just return the value passed when pXd_offset has to act as folded. What is crucial for gup_fast and what has been overlooked is that PxD_SIZE/MASK and thus pXd_addr_end should also change correspondingly. And the latter is not possible with dynamic folding. To fix the issue in addition to pXd values pass original pXdp pointers down to gup_pXd_range functions. And introduce pXd_offset_lockless helpers, which take an additional pXd entry value parameter. This has already been discussed in https://lkml.kernel.org/r/20190418100218.0a4afd51@mschwideX1 Fixes: 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_fast code") Signed-off-by: Vasily Gorbik Signed-off-by: Andrew Morton Reviewed-by: Gerald Schaefer Reviewed-by: Alexander Gordeev Reviewed-by: Jason Gunthorpe Reviewed-by: Mike Rapoport Reviewed-by: John Hubbard Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Dave Hansen Cc: Russell King Cc: Catalin Marinas Cc: Will Deacon Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Jeff Dike Cc: Richard Weinberger Cc: Dave Hansen Cc: Andy Lutomirski Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Arnd Bergmann Cc: Andrey Ryabinin Cc: Heiko Carstens Cc: Christian Borntraeger Cc: Claudio Imbrenda Cc: [5.2+] Link: https://lkml.kernel.org/r/patch.git-943f1e5dcff2.your-ad-here.call-01599856292-ext-8676@work.hours Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 20a5e4272b654876e6601ab53a4aec8c592b0816 Author: Gao Xiang Date: Fri Sep 25 21:19:01 2020 -0700 mm, THP, swap: fix allocating cluster for swapfile by mistake commit 41663430588c737dd735bad5a0d1ba325dcabd59 upstream. SWP_FS is used to make swap_{read,write}page() go through the filesystem, and it's only used for swap files over NFS. So, !SWP_FS means non NFS for now, it could be either file backed or device backed. Something similar goes with legacy SWP_FILE. So in order to achieve the goal of the original patch, SWP_BLKDEV should be used instead. FS corruption can be observed with SSD device + XFS + fragmented swapfile due to CONFIG_THP_SWAP=y. I reproduced the issue with the following details: Environment: QEMU + upstream kernel + buildroot + NVMe (2 GB) Kernel config: CONFIG_BLK_DEV_NVME=y CONFIG_THP_SWAP=y Some reproducible steps: mkfs.xfs -f /dev/nvme0n1 mkdir /tmp/mnt mount /dev/nvme0n1 /tmp/mnt bs="32k" sz="1024m" # doesn't matter too much, I also tried 16m xfs_io -f -c "pwrite -R -b $bs 0 $sz" -c "fdatasync" /tmp/mnt/sw xfs_io -f -c "pwrite -R -b $bs 0 $sz" -c "fdatasync" /tmp/mnt/sw xfs_io -f -c "pwrite -R -b $bs 0 $sz" -c "fdatasync" /tmp/mnt/sw xfs_io -f -c "pwrite -F -S 0 -b $bs 0 $sz" -c "fdatasync" /tmp/mnt/sw xfs_io -f -c "pwrite -R -b $bs 0 $sz" -c "fsync" /tmp/mnt/sw mkswap /tmp/mnt/sw swapon /tmp/mnt/sw stress --vm 2 --vm-bytes 600M # doesn't matter too much as well Symptoms: - FS corruption (e.g. checksum failure) - memory corruption at: 0xd2808010 - segfault Fixes: f0eea189e8e9 ("mm, THP, swap: Don't allocate huge cluster for file backed swap device") Fixes: 38d8b4e6bdc8 ("mm, THP, swap: delay splitting THP during swap out") Signed-off-by: Gao Xiang Signed-off-by: Andrew Morton Reviewed-by: "Huang, Ying" Reviewed-by: Yang Shi Acked-by: Rafael Aquini Cc: Matthew Wilcox Cc: Carlos Maiolino Cc: Eric Sandeen Cc: Dave Chinner Cc: Link: https://lkml.kernel.org/r/20200820045323.7809-1-hsiangkao@redhat.com Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 198d9f7e905c26bec6534914e1b0b86645ddc1bf Author: Charan Teja Reddy Date: Fri Sep 18 16:02:31 2020 +0530 dmabuf: fix NULL pointer dereference in dma_buf_release() commit 19a508bd1ad8e444de86873bf2f2b2ab8edd6552 upstream. NULL pointer dereference is observed while exporting the dmabuf but failed to allocate the 'struct file' which results into the dropping of the allocated dentry corresponding to this file in the dmabuf fs, which is ending up in dma_buf_release() and accessing the uninitialzed dentry->d_fsdata. Call stack on 5.4 is below: dma_buf_release+0x2c/0x254 drivers/dma-buf/dma-buf.c:88 __dentry_kill+0x294/0x31c fs/dcache.c:584 dentry_kill fs/dcache.c:673 [inline] dput+0x250/0x380 fs/dcache.c:859 path_put+0x24/0x40 fs/namei.c:485 alloc_file_pseudo+0x1a4/0x200 fs/file_table.c:235 dma_buf_getfile drivers/dma-buf/dma-buf.c:473 [inline] dma_buf_export+0x25c/0x3ec drivers/dma-buf/dma-buf.c:585 Fix this by checking for the valid pointer in the dentry->d_fsdata. Fixes: 4ab59c3c638c ("dma-buf: Move dma_buf_release() from fops to dentry_ops") Cc: [5.7+] Signed-off-by: Charan Teja Reddy Reviewed-by: Christian König Link: https://patchwork.freedesktop.org/patch/391319/ Signed-off-by: Christian König Signed-off-by: Greg Kroah-Hartman commit aded5dee7fb2b54612d48505644a1af467ca57a3 Author: Johannes Thumshirn Date: Mon Sep 21 16:57:14 2020 +0900 btrfs: fix overflow when copying corrupt csums for a message commit 35be8851d172c6e3db836c0f28c19087b10c9e00 upstream. Syzkaller reported a buffer overflow in btree_readpage_end_io_hook() when loop mounting a crafted image: detected buffer overflow in memcpy ------------[ cut here ]------------ kernel BUG at lib/string.c:1129! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 26 Comm: kworker/u4:2 Not tainted 5.9.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: btrfs-endio-meta btrfs_work_helper RIP: 0010:fortify_panic+0xf/0x20 lib/string.c:1129 RSP: 0018:ffffc90000e27980 EFLAGS: 00010286 RAX: 0000000000000022 RBX: ffff8880a80dca64 RCX: 0000000000000000 RDX: ffff8880a90860c0 RSI: ffffffff815dba07 RDI: fffff520001c4f22 RBP: ffff8880a80dca00 R08: 0000000000000022 R09: ffff8880ae7318e7 R10: 0000000000000000 R11: 0000000000077578 R12: 00000000ffffff6e R13: 0000000000000008 R14: ffffc90000e27a40 R15: 1ffff920001c4f3c FS: 0000000000000000(0000) GS:ffff8880ae700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000557335f440d0 CR3: 000000009647d000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: memcpy include/linux/string.h:405 [inline] btree_readpage_end_io_hook.cold+0x206/0x221 fs/btrfs/disk-io.c:642 end_bio_extent_readpage+0x4de/0x10c0 fs/btrfs/extent_io.c:2854 bio_endio+0x3cf/0x7f0 block/bio.c:1449 end_workqueue_fn+0x114/0x170 fs/btrfs/disk-io.c:1695 btrfs_work_helper+0x221/0xe20 fs/btrfs/async-thread.c:318 process_one_work+0x94c/0x1670 kernel/workqueue.c:2269 worker_thread+0x64c/0x1120 kernel/workqueue.c:2415 kthread+0x3b5/0x4a0 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 Modules linked in: ---[ end trace b68924293169feef ]--- RIP: 0010:fortify_panic+0xf/0x20 lib/string.c:1129 RSP: 0018:ffffc90000e27980 EFLAGS: 00010286 RAX: 0000000000000022 RBX: ffff8880a80dca64 RCX: 0000000000000000 RDX: ffff8880a90860c0 RSI: ffffffff815dba07 RDI: fffff520001c4f22 RBP: ffff8880a80dca00 R08: 0000000000000022 R09: ffff8880ae7318e7 R10: 0000000000000000 R11: 0000000000077578 R12: 00000000ffffff6e R13: 0000000000000008 R14: ffffc90000e27a40 R15: 1ffff920001c4f3c FS: 0000000000000000(0000) GS:ffff8880ae700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f95b7c4d008 CR3: 000000009647d000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 The overflow happens, because in btree_readpage_end_io_hook() we assume that we have found a 4 byte checksum instead of the real possible 32 bytes we have for the checksums. With the fix applied: [ 35.726623] BTRFS: device fsid 815caf9a-dc43-4d2a-ac54-764b8333d765 devid 1 transid 5 /dev/loop0 scanned by syz-repro (215) [ 35.738994] BTRFS info (device loop0): disk space caching is enabled [ 35.738998] BTRFS info (device loop0): has skinny extents [ 35.743337] BTRFS warning (device loop0): loop0 checksum verify failed on 1052672 wanted 0xf9c035fc8d239a54 found 0x67a25c14b7eabcf9 level 0 [ 35.743420] BTRFS error (device loop0): failed to read chunk root [ 35.745899] BTRFS error (device loop0): open_ctree failed Reported-by: syzbot+e864a35d361e1d4e29a5@syzkaller.appspotmail.com Fixes: d5178578bcd4 ("btrfs: directly call into crypto framework for checksumming") CC: stable@vger.kernel.org # 5.4+ Signed-off-by: Johannes Thumshirn Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit c4ab0a8370932db7d9d85fd8fea059449027307e Author: Masami Hiramatsu Date: Thu Sep 10 17:55:05 2020 +0900 kprobes: tracing/kprobes: Fix to kill kprobes on initmem after boot commit 82d083ab60c3693201c6f5c7a5f23a6ed422098d upstream. Since kprobe_event= cmdline option allows user to put kprobes on the functions in initmem, kprobe has to make such probes gone after boot. Currently the probes on the init functions in modules will be handled by module callback, but the kernel init text isn't handled. Without this, kprobes may access non-exist text area to disable or remove it. Link: https://lkml.kernel.org/r/159972810544.428528.1839307531600646955.stgit@devnote2 Fixes: 970988e19eb0 ("tracing/kprobe: Add kprobe_event= boot parameter") Cc: Jonathan Corbet Cc: Shuah Khan Cc: Randy Dunlap Cc: Ingo Molnar Cc: stable@vger.kernel.org Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 3995f7a60feceba6c8f762f4aff3184f90a1291d Author: Masami Hiramatsu Date: Tue Sep 1 00:12:07 2020 +0900 kprobes: Fix to check probe enabled before disarm_kprobe_ftrace() commit 3031313eb3d549b7ad6f9fbcc52ba04412e3eb9e upstream. Commit 0cb2f1372baa ("kprobes: Fix NULL pointer dereference at kprobe_ftrace_handler") fixed one bug but not completely fixed yet. If we run a kprobe_module.tc of ftracetest, kernel showed a warning as below. # ./ftracetest test.d/kprobe/kprobe_module.tc === Ftrace unit tests === [1] Kprobe dynamic event - probing module ... [ 22.400215] ------------[ cut here ]------------ [ 22.400962] Failed to disarm kprobe-ftrace at trace_printk_irq_work+0x0/0x7e [trace_printk] (-2) [ 22.402139] WARNING: CPU: 7 PID: 200 at kernel/kprobes.c:1091 __disarm_kprobe_ftrace.isra.0+0x7e/0xa0 [ 22.403358] Modules linked in: trace_printk(-) [ 22.404028] CPU: 7 PID: 200 Comm: rmmod Not tainted 5.9.0-rc2+ #66 [ 22.404870] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/2014 [ 22.406139] RIP: 0010:__disarm_kprobe_ftrace.isra.0+0x7e/0xa0 [ 22.406947] Code: 30 8b 03 eb c9 80 3d e5 09 1f 01 00 75 dc 49 8b 34 24 89 c2 48 c7 c7 a0 c2 05 82 89 45 e4 c6 05 cc 09 1f 01 01 e8 a9 c7 f0 ff <0f> 0b 8b 45 e4 eb b9 89 c6 48 c7 c7 70 c2 05 82 89 45 e4 e8 91 c7 [ 22.409544] RSP: 0018:ffffc90000237df0 EFLAGS: 00010286 [ 22.410385] RAX: 0000000000000000 RBX: ffffffff83066024 RCX: 0000000000000000 [ 22.411434] RDX: 0000000000000001 RSI: ffffffff810de8d3 RDI: ffffffff810de8d3 [ 22.412687] RBP: ffffc90000237e10 R08: 0000000000000001 R09: 0000000000000001 [ 22.413762] R10: 0000000000000000 R11: 0000000000000001 R12: ffff88807c478640 [ 22.414852] R13: ffffffff8235ebc0 R14: ffffffffa00060c0 R15: 0000000000000000 [ 22.415941] FS: 00000000019d48c0(0000) GS:ffff88807d7c0000(0000) knlGS:0000000000000000 [ 22.417264] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 22.418176] CR2: 00000000005bb7e3 CR3: 0000000078f7a000 CR4: 00000000000006a0 [ 22.419309] Call Trace: [ 22.419990] kill_kprobe+0x94/0x160 [ 22.420652] kprobes_module_callback+0x64/0x230 [ 22.421470] notifier_call_chain+0x4f/0x70 [ 22.422184] blocking_notifier_call_chain+0x49/0x70 [ 22.422979] __x64_sys_delete_module+0x1ac/0x240 [ 22.423733] do_syscall_64+0x38/0x50 [ 22.424366] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 22.425176] RIP: 0033:0x4bb81d [ 22.425741] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 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 73 01 c3 48 c7 c1 e0 ff ff ff f7 d8 64 89 01 48 [ 22.428726] RSP: 002b:00007ffc70fef008 EFLAGS: 00000246 ORIG_RAX: 00000000000000b0 [ 22.430169] RAX: ffffffffffffffda RBX: 00000000019d48a0 RCX: 00000000004bb81d [ 22.431375] RDX: 0000000000000000 RSI: 0000000000000880 RDI: 00007ffc70fef028 [ 22.432543] RBP: 0000000000000880 R08: 00000000ffffffff R09: 00007ffc70fef320 [ 22.433692] R10: 0000000000656300 R11: 0000000000000246 R12: 00007ffc70fef028 [ 22.434635] R13: 0000000000000000 R14: 0000000000000002 R15: 0000000000000000 [ 22.435682] irq event stamp: 1169 [ 22.436240] hardirqs last enabled at (1179): [] console_unlock+0x422/0x580 [ 22.437466] hardirqs last disabled at (1188): [] console_unlock+0x7b/0x580 [ 22.438608] softirqs last enabled at (866): [] __do_softirq+0x38e/0x490 [ 22.439637] softirqs last disabled at (859): [] asm_call_on_stack+0x12/0x20 [ 22.440690] ---[ end trace 1e7ce7e1e4567276 ]--- [ 22.472832] trace_kprobe: This probe might be able to register after target module is loaded. Continue. This is because the kill_kprobe() calls disarm_kprobe_ftrace() even if the given probe is not enabled. In that case, ftrace_set_filter_ip() fails because the given probe point is not registered to ftrace. Fix to check the given (going) probe is enabled before invoking disarm_kprobe_ftrace(). Link: https://lkml.kernel.org/r/159888672694.1411785.5987998076694782591.stgit@devnote2 Fixes: 0cb2f1372baa ("kprobes: Fix NULL pointer dereference at kprobe_ftrace_handler") Cc: Ingo Molnar Cc: "Naveen N . Rao" Cc: Anil S Keshavamurthy Cc: David Miller Cc: Muchun Song Cc: Chengming Zhou Cc: stable@vger.kernel.org Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 31efa3b5b592521ddbc58f19500e909d7c13e068 Author: Jan Höppner Date: Mon Sep 14 13:56:47 2020 +0200 s390/dasd: Fix zero write for FBA devices commit 709192d531e5b0a91f20aa14abfe2fc27ddd47af upstream. A discard request that writes zeros using the global kernel internal ZERO_PAGE will fail for machines with more than 2GB of memory due to the location of the ZERO_PAGE. Fix this by using a driver owned global zero page allocated with GFP_DMA flag set. Fixes: 28b841b3a7cb ("s390/dasd: Add discard support for FBA devices") Signed-off-by: Jan Höppner Reviewed-by: Stefan Haberland Cc: # 4.14+ Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit e92c490f104993cea35e5f5d5108ac12df1850ac Author: Tom Rix Date: Mon Sep 7 06:58:45 2020 -0700 tracing: fix double free commit 46bbe5c671e06f070428b9be142cc4ee5cedebac upstream. clang static analyzer reports this problem trace_events_hist.c:3824:3: warning: Attempt to free released memory kfree(hist_data->attrs->var_defs.name[i]); In parse_var_defs() if there is a problem allocating var_defs.expr, the earlier var_defs.name is freed. This free is duplicated by free_var_defs() which frees the rest of the list. Because free_var_defs() has to run anyway, remove the second free fom parse_var_defs(). Link: https://lkml.kernel.org/r/20200907135845.15804-1-trix@redhat.com Cc: stable@vger.kernel.org Fixes: 30350d65ac56 ("tracing: Add variable support to hist triggers") Reviewed-by: Tom Zanussi Signed-off-by: Tom Rix Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit f05f667f8764f9ec834ca3e412ed7f5a20dea3bf Author: Nick Desaulniers Date: Fri Sep 25 21:19:18 2020 -0700 lib/string.c: implement stpcpy commit 1e1b6d63d6340764e00356873e5794225a2a03ea upstream. LLVM implemented a recent "libcall optimization" that lowers calls to `sprintf(dest, "%s", str)` where the return value is used to `stpcpy(dest, str) - dest`. This generally avoids the machinery involved in parsing format strings. `stpcpy` is just like `strcpy` except it returns the pointer to the new tail of `dest`. This optimization was introduced into clang-12. Implement this so that we don't observe linkage failures due to missing symbol definitions for `stpcpy`. Similar to last year's fire drill with: commit 5f074f3e192f ("lib/string.c: implement a basic bcmp") The kernel is somewhere between a "freestanding" environment (no full libc) and "hosted" environment (many symbols from libc exist with the same type, function signature, and semantics). As Peter Anvin notes, there's not really a great way to inform the compiler that you're targeting a freestanding environment but would like to opt-in to some libcall optimizations (see pr/47280 below), rather than opt-out. Arvind notes, -fno-builtin-* behaves slightly differently between GCC and Clang, and Clang is missing many __builtin_* definitions, which I consider a bug in Clang and am working on fixing. Masahiro summarizes the subtle distinction between compilers justly: To prevent transformation from foo() into bar(), there are two ways in Clang to do that; -fno-builtin-foo, and -fno-builtin-bar. There is only one in GCC; -fno-buitin-foo. (Any difference in that behavior in Clang is likely a bug from a missing __builtin_* definition.) Masahiro also notes: We want to disable optimization from foo() to bar(), but we may still benefit from the optimization from foo() into something else. If GCC implements the same transform, we would run into a problem because it is not -fno-builtin-bar, but -fno-builtin-foo that disables that optimization. In this regard, -fno-builtin-foo would be more future-proof than -fno-built-bar, but -fno-builtin-foo is still potentially overkill. We may want to prevent calls from foo() being optimized into calls to bar(), but we still may want other optimization on calls to foo(). It seems that compilers today don't quite provide the fine grain control over which libcall optimizations pseudo-freestanding environments would prefer. Finally, Kees notes that this interface is unsafe, so we should not encourage its use. As such, I've removed the declaration from any header, but it still needs to be exported to avoid linkage errors in modules. Reported-by: Sami Tolvanen Suggested-by: Andy Lavr Suggested-by: Arvind Sankar Suggested-by: Joe Perches Suggested-by: Kees Cook Suggested-by: Masahiro Yamada Suggested-by: Rasmus Villemoes Signed-off-by: Nick Desaulniers Signed-off-by: Andrew Morton Tested-by: Nathan Chancellor Cc: Link: https://lkml.kernel.org/r/20200914161643.938408-1-ndesaulniers@google.com Link: https://bugs.llvm.org/show_bug.cgi?id=47162 Link: https://bugs.llvm.org/show_bug.cgi?id=47280 Link: https://github.com/ClangBuiltLinux/linux/issues/1126 Link: https://man7.org/linux/man-pages/man3/stpcpy.3.html Link: https://pubs.opengroup.org/onlinepubs/9699919799/functions/stpcpy.html Link: https://reviews.llvm.org/D85963 Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 26a6452b27ec8376a69944be7b1363a9f9dbda2a Author: Kai-Heng Feng Date: Mon Sep 14 15:02:29 2020 +0800 ALSA: hda/realtek: Enable front panel headset LED on Lenovo ThinkStation P520 commit f73bbf639b32acb6b409e188fdde5644b301978f upstream. On Lenovo P520, the front panel headset LED isn't lit up right now. Realtek states that the LED needs to be enabled by ALC233's GPIO2, so let's do it accordingly to light the LED up. Signed-off-by: Kai-Heng Feng Acked-by: Hui Wang Cc: Link: https://lore.kernel.org/r/20200914070231.13192-1-kai.heng.feng@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2a2ae4831ff74323ea0e2138ca688d8ef2735278 Author: Hui Wang Date: Mon Sep 14 14:51:18 2020 +0800 ALSA: hda/realtek - Couldn't detect Mic if booting with headset plugged commit 3f74249057827c5f6676c41c18f6be12ce1469ce upstream. We found a Mic detection issue on many Lenovo laptops, those laptops belong to differnt models and they have different audio design like internal mic connects to the codec or PCH, they all have this problem, the problem is if plugging a headset before powerup/reboot the machine, after booting up, the headphone could be detected but Mic couldn't. If we plug out and plug in the headset, both headphone and Mic could be detected then. Through debugging we found the codec on those laptops are same, it is alc257, and if we don't disable the 3k pulldown in alc256_shutup(), the issue will be fixed. So far there is no pop noise or power consumption regression on those laptops after this change. Cc: Kailang Yang Cc: Signed-off-by: Hui Wang Link: https://lore.kernel.org/r/20200914065118.19238-1-hui.wang@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 86f6af05ffa0f4bf0c06d4090de9bfcb789a8463 Author: Joakim Tjernlund Date: Thu Sep 10 10:53:28 2020 +0200 ALSA: usb-audio: Add delay quirk for H570e USB headsets commit 315c7ad7a701baba28c628c4c5426b3d9617ceed upstream. Needs the same delay as H650e Signed-off-by: Joakim Tjernlund Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200910085328.19188-1-joakim.tjernlund@infinera.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4cb7f229823cd95607381cdda7bef2254310bc98 Author: James Smart Date: Fri Sep 11 13:01:47 2020 -0700 scsi: lpfc: Fix initial FLOGI failure due to BBSCN not supported commit 7f04839ec4483563f38062b4dd90253e45447198 upstream. Initial FLOGIs are failing with the following message: lpfc 0000:13:00.1: 1:(0):0820 FLOGI Failed (x300). BBCredit Not Supported In a prior patch, the READ_SPARAM command was re-ordered to post after CONFIG_LINK as the driver is expected to update the driver's copy of the service parameters for the FLOGI payload. If the bb-credit recovery feature is enabled, this is fine. But on adapters were bb-credit recovery isn't enabled, it would cause the FLOGI to fail. Fix by restoring the original command order (READ_SPARAM before CONFIG_LINK), and after issuing CONFIG_LINK, detect bb-credit recovery support and reissuing READ_SPARAM to obtain the updated service parameters (effectively adding in the fix command order). [mkp: corrected SHA] Link: https://lore.kernel.org/r/20200911200147.110826-1-james.smart@broadcom.com Fixes: 835214f5d5f5 ("scsi: lpfc: Fix broken Credit Recovery after driver load") CC: # v5.7+ Co-developed-by: Dick Kennedy Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 6890a6f5665fef67860c7c27e661f0ce7d38a061 Author: Thomas Gleixner Date: Wed Sep 23 17:46:20 2020 +0200 x86/ioapic: Unbreak check_timer() commit 86a82ae0b5095ea24c55898a3f025791e7958b21 upstream. Several people reported in the kernel bugzilla that between v4.12 and v4.13 the magic which works around broken hardware and BIOSes to find the proper timer interrupt delivery mode stopped working for some older affected platforms which need to fall back to ExtINT delivery mode. The reason is that the core code changed to keep track of the masked and disabled state of an interrupt line more accurately to avoid the expensive hardware operations. That broke an assumption in i8259_make_irq() which invokes disable_irq_nosync(); irq_set_chip_and_handler(); enable_irq(); Up to v4.12 this worked because enable_irq() unconditionally unmasked the interrupt line, but after the state tracking improvements this is not longer the case because the IO/APIC uses lazy disabling. So the line state is unmasked which means that enable_irq() does not call into the new irq chip to unmask it. In principle this is a shortcoming of the core code, but it's more than unclear whether the core code should try to reset state. At least this cannot be done unconditionally as that would break other existing use cases where the chip type is changed, e.g. when changing the trigger type, but the callers expect the state to be preserved. As the way how check_timer() is switching the delivery modes is truly unique, the obvious fix is to simply unmask the i8259 manually after changing the mode to ExtINT delivery and switching the irq chip to the legacy PIC. Note, that the fixes tag is not really precise, but identifies the commit which broke the assumptions in the IO/APIC and i8259 code and that's the kernel version to which this needs to be backported. Fixes: bf22ff45bed6 ("genirq: Avoid unnecessary low level irq function calls") Reported-by: p_c_chan@hotmail.com Reported-by: ecm4@mail.com Reported-by: perdigao1@yahoo.com Reported-by: matzes@users.sourceforge.net Reported-by: rvelascog@gmail.com Signed-off-by: Thomas Gleixner Tested-by: p_c_chan@hotmail.com Tested-by: matzes@users.sourceforge.net Cc: stable@vger.kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=197769 Signed-off-by: Greg Kroah-Hartman commit 361a4b17e88dd58a7ba977ed2e4db55506f98067 Author: Mikulas Patocka Date: Fri Sep 25 21:19:24 2020 -0700 arch/x86/lib/usercopy_64.c: fix __copy_user_flushcache() cache writeback commit a1cd6c2ae47ee10ff21e62475685d5b399e2ed4a upstream. If we copy less than 8 bytes and if the destination crosses a cache line, __copy_user_flushcache would invalidate only the first cache line. This patch makes it invalidate the second cache line as well. Fixes: 0aed55af88345b ("x86, uaccess: introduce copy_from_iter_flushcache for pmem / cache-bypass operations") Signed-off-by: Mikulas Patocka Signed-off-by: Andrew Morton Reviewed-by: Dan Williams Cc: Jan Kara Cc: Jeff Moyer Cc: Ingo Molnar Cc: Christoph Hellwig Cc: Toshi Kani Cc: "H. Peter Anvin" Cc: Al Viro Cc: Thomas Gleixner Cc: Matthew Wilcox Cc: Ross Zwisler Cc: Ingo Molnar Cc: Link: https://lkml.kernel.org/r/alpine.LRH.2.02.2009161451140.21915@file01.intranet.prod.int.rdu2.redhat.com Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit fe932d4c9ea2d921ea9e844999832b4cae09a081 Author: Minchan Kim Date: Mon Sep 14 23:32:15 2020 -0700 mm: validate pmd after splitting [ Upstream commit ce2684254bd4818ca3995c0d021fb62c4cf10a19 ] syzbot reported the following KASAN splat: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] CPU: 1 PID: 6826 Comm: syz-executor142 Not tainted 5.9.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__lock_acquire+0x84/0x2ae0 kernel/locking/lockdep.c:4296 Code: ff df 8a 04 30 84 c0 0f 85 e3 16 00 00 83 3d 56 58 35 08 00 0f 84 0e 17 00 00 83 3d 25 c7 f5 07 00 74 2c 4c 89 e8 48 c1 e8 03 <80> 3c 30 00 74 12 4c 89 ef e8 3e d1 5a 00 48 be 00 00 00 00 00 fc RSP: 0018:ffffc90004b9f850 EFLAGS: 00010006 Call Trace: lock_acquire+0x140/0x6f0 kernel/locking/lockdep.c:5006 __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline] _raw_spin_lock+0x2a/0x40 kernel/locking/spinlock.c:151 spin_lock include/linux/spinlock.h:354 [inline] madvise_cold_or_pageout_pte_range+0x52f/0x25c0 mm/madvise.c:389 walk_pmd_range mm/pagewalk.c:89 [inline] walk_pud_range mm/pagewalk.c:160 [inline] walk_p4d_range mm/pagewalk.c:193 [inline] walk_pgd_range mm/pagewalk.c:229 [inline] __walk_page_range+0xe7b/0x1da0 mm/pagewalk.c:331 walk_page_range+0x2c3/0x5c0 mm/pagewalk.c:427 madvise_pageout_page_range mm/madvise.c:521 [inline] madvise_pageout mm/madvise.c:557 [inline] madvise_vma mm/madvise.c:946 [inline] do_madvise+0x12d0/0x2090 mm/madvise.c:1145 __do_sys_madvise mm/madvise.c:1171 [inline] __se_sys_madvise mm/madvise.c:1169 [inline] __x64_sys_madvise+0x76/0x80 mm/madvise.c:1169 do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The backing vma was shmem. In case of split page of file-backed THP, madvise zaps the pmd instead of remapping of sub-pages. So we need to check pmd validity after split. Reported-by: syzbot+ecf80462cb7d5d552bc7@syzkaller.appspotmail.com Fixes: 1a4e58cce84e ("mm: introduce MADV_PAGEOUT") Signed-off-by: Minchan Kim Acked-by: Kirill A. Shutemov Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 5d4431c9de063fc23bf0857820e1a8e1798d5e28 Author: Tom Lendacky Date: Thu Sep 24 13:41:57 2020 -0500 KVM: SVM: Add a dedicated INVD intercept routine [ Upstream commit 4bb05f30483fd21ea5413eaf1182768f251cf625 ] The INVD instruction intercept performs emulation. Emulation can't be done on an SEV guest because the guest memory is encrypted. Provide a dedicated intercept routine for the INVD intercept. And since the instruction is emulated as a NOP, just skip it instead. Fixes: 1654efcbc431 ("KVM: SVM: Add KVM_SEV_INIT command") Signed-off-by: Tom Lendacky Message-Id: Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 16788dc19fa186d68e6d3bdb46433636d12dfb84 Author: Sean Christopherson Date: Wed Sep 23 14:53:52 2020 -0700 KVM: x86: Reset MMU context if guest toggles CR4.SMAP or CR4.PKE [ Upstream commit 8d214c481611b29458a57913bd786f0ac06f0605 ] Reset the MMU context during kvm_set_cr4() if SMAP or PKE is toggled. Recent commits to (correctly) not reload PDPTRs when SMAP/PKE are toggled inadvertantly skipped the MMU context reset due to the mask of bits that triggers PDPTR loads also being used to trigger MMU context resets. Fixes: 427890aff855 ("kvm: x86: Toggling CR4.SMAP does not load PDPTEs in PAE mode") Fixes: cb957adb4ea4 ("kvm: x86: Toggling CR4.PKE does not load PDPTEs in PAE mode") Cc: Jim Mattson Cc: Peter Shier Cc: Oliver Upton Signed-off-by: Sean Christopherson Message-Id: <20200923215352.17756-1-sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 87f7a4910e57cde3a223fe1bf5296699cce64445 Author: Icenowy Zheng Date: Wed Sep 23 08:51:42 2020 +0800 regulator: axp20x: fix LDO2/4 description [ Upstream commit fbb5a79d2fe7b01c6424fbbc04368373b1672d61 ] Currently we wrongly set the mask of value of LDO2/4 both to the mask of LDO2, and the LDO4 voltage configuration is left untouched. This leads to conflict when LDO2/4 are both in use. Fix this issue by setting different vsel_mask to both regulators. Fixes: db4a555f7c4c ("regulator: axp20x: use defines for masks") Signed-off-by: Icenowy Zheng Link: https://lore.kernel.org/r/20200923005142.147135-1-icenowy@aosc.io Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5c58104841fe073bbf8a80b4079f58e04005f27d Author: Wei Li Date: Wed Sep 23 14:53:12 2020 +0800 MIPS: Add the missing 'CPU_1074K' into __get_cpu_type() [ Upstream commit e393fbe6fa27af23f78df6e16a8fd2963578a8c4 ] Commit 442e14a2c55e ("MIPS: Add 1074K CPU support explicitly.") split 1074K from the 74K as an unique CPU type, while it missed to add the 'CPU_1074K' in __get_cpu_type(). So let's add it back. Fixes: 442e14a2c55e ("MIPS: Add 1074K CPU support explicitly.") Signed-off-by: Wei Li Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 283a3234550c34d0ac459be04a7cc3dfafc277b9 Author: Dmitry Baryshkov Date: Thu Sep 17 18:34:05 2020 +0300 regmap: fix page selection for noinc writes [ Upstream commit 05669b63170771d554854c0e465b76dc98fc7c84 ] Non-incrementing writes can fail if register + length crosses page border. However for non-incrementing writes we should not check for page border crossing. Fix this by passing additional flag to _regmap_raw_write and passing length to _regmap_select_page basing on the flag. Signed-off-by: Dmitry Baryshkov Fixes: cdf6b11daa77 ("regmap: Add regmap_noinc_write API") Link: https://lore.kernel.org/r/20200917153405.3139200-2-dmitry.baryshkov@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 47fef0ebc1502fde0ab649aa913956dd61984325 Author: Dmitry Baryshkov Date: Thu Sep 17 18:34:04 2020 +0300 regmap: fix page selection for noinc reads [ Upstream commit 4003324856311faebb46cbd56a1616bd3f3b67c2 ] Non-incrementing reads can fail if register + length crosses page border. However for non-incrementing reads we should not check for page border crossing. Fix this by passing additional flag to _regmap_raw_read and passing length to _regmap_select_page basing on the flag. Signed-off-by: Dmitry Baryshkov Fixes: 74fe7b551f33 ("regmap: Add regmap_noinc_read API") Link: https://lore.kernel.org/r/20200917153405.3139200-1-dmitry.baryshkov@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a8cebb4a59318db6509796d9dce319750cd60967 Author: Tom Rix Date: Sun Sep 13 09:52:30 2020 -0700 ALSA: asihpi: fix iounmap in error handler [ Upstream commit 472eb39103e885f302fd8fd6eff104fcf5503f1b ] clang static analysis flags this problem hpioctl.c:513:7: warning: Branch condition evaluates to a garbage value if (pci.ap_mem_base[idx]) { ^~~~~~~~~~~~~~~~~~~~ If there is a failure in the middle of the memory space loop, only some of the memory spaces need to be cleaned up. At the error handler, idx holds the number of successful memory spaces mapped. So rework the handler loop to use the old idx. There is a second problem, the memory space loop conditionally iomaps()/sets the mem_base so it is necessay to initize pci. Fixes: 719f82d3987a ("ALSA: Add support of AudioScience ASI boards") Signed-off-by: Tom Rix Link: https://lore.kernel.org/r/20200913165230.17166-1-trix@redhat.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 83b9a250d77496d940bf6acf29b3a19d9f81ba06 Author: Necip Fazil Yildiran Date: Wed Sep 9 12:54:53 2020 +0300 lib80211: fix unmet direct dependendices config warning when !CRYPTO [ Upstream commit b959ba9f468b1c581f40e92661ad58b093abaa03 ] When LIB80211_CRYPT_CCMP is enabled and CRYPTO is disabled, it results in unmet direct dependencies config warning. The reason is that LIB80211_CRYPT_CCMP selects CRYPTO_AES and CRYPTO_CCM, which are subordinate to CRYPTO. This is reproducible with CRYPTO disabled and R8188EU enabled, where R8188EU selects LIB80211_CRYPT_CCMP but does not select or depend on CRYPTO. Honor the kconfig menu hierarchy to remove kconfig dependency warnings. Fixes: a11e2f85481c ("lib80211: use crypto API ccm(aes) transform for CCMP processing") Signed-off-by: Necip Fazil Yildiran Link: https://lore.kernel.org/r/20200909095452.3080-1-fazilyildiran@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 43cdb648e1da7b195eba564c5af5a2c320f77dce Author: Yonghong Song Date: Tue Sep 15 17:44:01 2020 -0700 bpf: Fix a rcu warning for bpffs map pretty-print [ Upstream commit ce880cb825fcc22d4e39046a6c3a3a7f6603883d ] Running selftest ./btf_btf -p the kernel had the following warning: [ 51.528185] WARNING: CPU: 3 PID: 1756 at kernel/bpf/hashtab.c:717 htab_map_get_next_key+0x2eb/0x300 [ 51.529217] Modules linked in: [ 51.529583] CPU: 3 PID: 1756 Comm: test_btf Not tainted 5.9.0-rc1+ #878 [ 51.530346] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-1.el7.centos 04/01/2014 [ 51.531410] RIP: 0010:htab_map_get_next_key+0x2eb/0x300 ... [ 51.542826] Call Trace: [ 51.543119] map_seq_next+0x53/0x80 [ 51.543528] seq_read+0x263/0x400 [ 51.543932] vfs_read+0xad/0x1c0 [ 51.544311] ksys_read+0x5f/0xe0 [ 51.544689] do_syscall_64+0x33/0x40 [ 51.545116] entry_SYSCALL_64_after_hwframe+0x44/0xa9 The related source code in kernel/bpf/hashtab.c: 709 static int htab_map_get_next_key(struct bpf_map *map, void *key, void *next_key) 710 { 711 struct bpf_htab *htab = container_of(map, struct bpf_htab, map); 712 struct hlist_nulls_head *head; 713 struct htab_elem *l, *next_l; 714 u32 hash, key_size; 715 int i = 0; 716 717 WARN_ON_ONCE(!rcu_read_lock_held()); In kernel/bpf/inode.c, bpffs map pretty print calls map->ops->map_get_next_key() without holding a rcu_read_lock(), hence causing the above warning. To fix the issue, just surrounding map->ops->map_get_next_key() with rcu read lock. Fixes: a26ca7c982cb ("bpf: btf: Add pretty print support to the basic arraymap") Reported-by: Alexei Starovoitov Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Cc: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20200916004401.146277-1-yhs@fb.com Signed-off-by: Sasha Levin commit d9fadccbf25e855cd40976c1f95e80628745a5f4 Author: Linus Lüssing Date: Tue Sep 15 09:54:10 2020 +0200 batman-adv: mcast: fix duplicate mcast packets from BLA backbone to mesh [ Upstream commit 2369e827046920ef0599e6a36b975ac5c0a359c2 ] Scenario: * Multicast frame send from BLA backbone gateways (multiple nodes with their bat0 bridged together, with BLA enabled) sharing the same LAN to nodes in the mesh Issue: * Nodes receive the frame multiple times on bat0 from the mesh, once from each foreign BLA backbone gateway which shares the same LAN with another For multicast frames via batman-adv broadcast packets coming from the same BLA backbone but from different backbone gateways duplicates are currently detected via a CRC history of previously received packets. However this CRC so far was not performed for multicast frames received via batman-adv unicast packets. Fixing this by appyling the same check for such packets, too. Room for improvements in the future: Ideally we would introduce the possibility to not only claim a client, but a complete originator, too. This would allow us to only send a multicast-in-unicast packet from a BLA backbone gateway claiming the node and by that avoid potential redundant transmissions in the first place. Fixes: 279e89b2281a ("batman-adv: add broadcast duplicate check") Signed-off-by: Linus Lüssing Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Sasha Levin commit 5d8774492819f65d72604221a8422c4b92533d74 Author: Linus Lüssing Date: Tue Sep 15 09:54:09 2020 +0200 batman-adv: mcast: fix duplicate mcast packets in BLA backbone from mesh [ Upstream commit 74c09b7275126da1b642b90c9cdc3ae8b729ad4b ] Scenario: * Multicast frame send from mesh to a BLA backbone (multiple nodes with their bat0 bridged together, with BLA enabled) Issue: * BLA backbone nodes receive the frame multiple times on bat0, once from mesh->bat0 and once from each backbone_gw from LAN For unicast, a node will send only to the best backbone gateway according to the TQ. However for multicast we currently cannot determine if multiple destination nodes share the same backbone if they don't share the same backbone with us. So we need to keep sending the unicasts to all backbone gateways and let the backbone gateways decide which one will forward the frame. We can use the CLAIM mechanism to make this decision. One catch: The batman-adv gateway feature for DHCP packets potentially sends multicast packets in the same batman-adv unicast header as the multicast optimizations code. And we are not allowed to drop those even if we did not claim the source address of the sender, as for such packets there is only this one multicast-in-unicast packet. How can we distinguish the two cases? The gateway feature uses a batman-adv unicast 4 address header. While the multicast-to-unicasts feature uses a simple, 3 address batman-adv unicast header. So let's use this to distinguish. Fixes: fe2da6ff27c7 ("batman-adv: check incoming packet type for bla") Signed-off-by: Linus Lüssing Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Sasha Levin commit 24e5e941d804a2f6641e7d629f6b5a795403a213 Author: Linus Lüssing Date: Tue Sep 15 09:54:08 2020 +0200 batman-adv: mcast: fix duplicate mcast packets in BLA backbone from LAN [ Upstream commit 3236d215ad38a3f5372e65cd1e0a52cf93d3c6a2 ] Scenario: * Multicast frame send from a BLA backbone (multiple nodes with their bat0 bridged together, with BLA enabled) Issue: * BLA backbone nodes receive the frame multiple times on bat0 For multicast frames received via batman-adv broadcast packets the originator of the broadcast packet is checked before decapsulating and forwarding the frame to bat0 (batadv_bla_is_backbone_gw()-> batadv_recv_bcast_packet()). If it came from a node which shares the same BLA backbone with us then it is not forwarded to bat0 to avoid a loop. When sending a multicast frame in a non-4-address batman-adv unicast packet we are currently missing this check - and cannot do so because the batman-adv unicast packet has no originator address field. However, we can simply fix this on the sender side by only sending the multicast frame via unicasts to interested nodes which do not share the same BLA backbone with us. This also nicely avoids some unnecessary transmissions on mesh side. Note that no infinite loop was observed, probably because of dropping via batadv_interface_tx()->batadv_bla_tx(). However the duplicates still utterly confuse switches/bridges, ICMPv6 duplicate address detection and neighbor discovery and therefore leads to long delays before being able to establish TCP connections, for instance. And it also leads to the Linux bridge printing messages like: "br-lan: received packet on eth1 with own address as source address ..." Fixes: 2d3f6ccc4ea5 ("batman-adv: Modified forwarding behaviour for multicast packets") Signed-off-by: Linus Lüssing Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Sasha Levin commit b0632590cbec1b55a94186d1b3e294811595d027 Author: Necip Fazil Yildiran Date: Mon Sep 14 18:01:21 2020 +0300 nvme-tcp: fix kconfig dependency warning when !CRYPTO [ Upstream commit af5ad17854f96a6d3c9775e776bd01ab262672a1 ] When NVME_TCP is enabled and CRYPTO is disabled, it results in the following Kbuild warning: WARNING: unmet direct dependencies detected for CRYPTO_CRC32C Depends on [n]: CRYPTO [=n] Selected by [y]: - NVME_TCP [=y] && INET [=y] && BLK_DEV_NVME [=y] The reason is that NVME_TCP selects CRYPTO_CRC32C without depending on or selecting CRYPTO while CRYPTO_CRC32C is subordinate to CRYPTO. Honor the kconfig menu hierarchy to remove kconfig dependency warnings. Fixes: 79fd751d61aa ("nvme: tcp: selects CRYPTO_CRC32C for nvme-tcp") Signed-off-by: Necip Fazil Yildiran Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 8c6ba1878a9256b5b3f8e6acf83add5ed3f621c2 Author: Sven Eckelmann Date: Mon Sep 14 13:58:16 2020 +0200 batman-adv: Add missing include for in_interrupt() [ Upstream commit 4bba9dab86b6ac15ca560ef1f2b5aa4529cbf784 ] The fix for receiving (internally generated) bla packets outside the interrupt context introduced the usage of in_interrupt(). But this functionality is only defined in linux/preempt.h which was not included with the same patch. Fixes: 279e89b2281a ("batman-adv: bla: use netif_rx_ni when not in interrupt context") Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Sasha Levin commit 248c25e7725ac1fa6edb2daa8bcd09455c82e927 Author: Martin Cerveny Date: Sun Sep 6 18:21:39 2020 +0200 drm/sun4i: sun8i-csc: Secondary CSC register correction [ Upstream commit cab4c03b4ba54c8d9378298cacb8bc0fd74ceece ] "Allwinner V3s" has secondary video layer (VI). Decoded video is displayed in wrong colors until secondary CSC registers are programmed correctly. Fixes: 883029390550 ("drm/sun4i: Add DE2 CSC library") Signed-off-by: Martin Cerveny Reviewed-by: Jernej Skrabec Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20200906162140.5584-2-m.cerveny@computer.org Signed-off-by: Sasha Levin commit 12bea822dbe6e37d2e0c04910f91b56a59c0d5f0 Author: Dmitry Bogdanov Date: Wed Sep 9 20:43:10 2020 +0300 net: qed: RDMA personality shouldn't fail VF load [ Upstream commit ce1cf9e5025f4e2d2198728391f1847b3e168bc6 ] Fix the assert during VF driver installation when the personality is iWARP Fixes: 1fe614d10f45 ("qed: Relax VF firmware requirements") Signed-off-by: Igor Russkikh Signed-off-by: Michal Kalderon Signed-off-by: Dmitry Bogdanov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7e74a6d6f99cfa9c5dd317d913b9cf5a61644a86 Author: Dmitry Bogdanov Date: Wed Sep 9 20:43:09 2020 +0300 net: qede: Disable aRFS for NPAR and 100G [ Upstream commit 0367f05885b9f21d062447bd2ba1302ba3cc7392 ] In some configurations ARFS cannot be used, so disable it if device is not capable. Fixes: e4917d46a653 ("qede: Add aRFS support") Signed-off-by: Manish Chopra Signed-off-by: Igor Russkikh Signed-off-by: Michal Kalderon Signed-off-by: Dmitry Bogdanov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 82dfe9c32dea40fd1b823fbec515b27834327c9e Author: Dmitry Bogdanov Date: Wed Sep 9 20:43:08 2020 +0300 net: qed: Disable aRFS for NPAR and 100G [ Upstream commit 2d2fe8433796603091ac8ea235b9165ac5a85f9a ] In CMT and NPAR the PF is unknown when the GFS block processes the packet. Therefore cannot use searcher as it has a per PF database, and thus ARFS must be disabled. Fixes: d51e4af5c209 ("qed: aRFS infrastructure support") Signed-off-by: Manish Chopra Signed-off-by: Igor Russkikh Signed-off-by: Michal Kalderon Signed-off-by: Dmitry Bogdanov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f301585195a0b4258b2685250d06316a6d35d072 Author: Marek Szyprowski Date: Wed Jul 1 09:39:49 2020 +0200 drm/vc4/vc4_hdmi: fill ASoC card owner [ Upstream commit ec653df2a0cbc306a4bfcb0e3484d318fa779002 ] card->owner is a required property and since commit 81033c6b584b ("ALSA: core: Warn on empty module") a warning is issued if it is empty. Fix lack of it. This fixes following warning observed on RaspberryPi 3B board with ARM 32bit kernel and multi_v7_defconfig: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 210 at sound/core/init.c:207 snd_card_new+0x378/0x398 [snd] Modules linked in: vc4(+) snd_soc_core ac97_bus snd_pcm_dmaengine bluetooth snd_pcm snd_timer crc32_arm_ce raspberrypi_hwmon snd soundcore ecdh_generic ecc bcm2835_thermal phy_generic CPU: 1 PID: 210 Comm: systemd-udevd Not tainted 5.8.0-rc1-00027-g81033c6b584b #1087 Hardware name: BCM2835 [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0xd4/0xe8) [] (dump_stack) from [] (__warn+0xdc/0xf4) [] (__warn) from [] (warn_slowpath_fmt+0xb0/0xb8) [] (warn_slowpath_fmt) from [] (snd_card_new+0x378/0x398 [snd]) [] (snd_card_new [snd]) from [] (snd_soc_bind_card+0x280/0x99c [snd_soc_core]) [] (snd_soc_bind_card [snd_soc_core]) from [] (devm_snd_soc_register_card+0x34/0x6c [snd_soc_core]) [] (devm_snd_soc_register_card [snd_soc_core]) from [] (vc4_hdmi_bind+0x43c/0x5f4 [vc4]) [] (vc4_hdmi_bind [vc4]) from [] (component_bind_all+0xec/0x24c) [] (component_bind_all) from [] (vc4_drm_bind+0xd4/0x174 [vc4]) [] (vc4_drm_bind [vc4]) from [] (try_to_bring_up_master+0x160/0x1b0) [] (try_to_bring_up_master) from [] (component_master_add_with_match+0xd0/0x104) [] (component_master_add_with_match) from [] (vc4_platform_drm_probe+0x9c/0xbc [vc4]) [] (vc4_platform_drm_probe [vc4]) from [] (platform_drv_probe+0x6c/0xa4) [] (platform_drv_probe) from [] (really_probe+0x210/0x350) [] (really_probe) from [] (driver_probe_device+0x5c/0xb4) [] (driver_probe_device) from [] (device_driver_attach+0x58/0x60) [] (device_driver_attach) from [] (__driver_attach+0x80/0xbc) [] (__driver_attach) from [] (bus_for_each_dev+0x68/0xb4) [] (bus_for_each_dev) from [] (bus_add_driver+0x130/0x1e8) [] (bus_add_driver) from [] (driver_register+0x78/0x110) [] (driver_register) from [] (do_one_initcall+0x50/0x220) [] (do_one_initcall) from [] (do_init_module+0x60/0x210) [] (do_init_module) from [] (load_module+0x1e34/0x2338) [] (load_module) from [] (sys_finit_module+0xac/0xbc) [] (sys_finit_module) from [] (ret_fast_syscall+0x0/0x54) Exception stack(0xeded9fa8 to 0xeded9ff0) ... ---[ end trace 6414689569c2bc08 ]--- Fixes: bb7d78568814 ("drm/vc4: Add HDMI audio support") Suggested-by: Takashi Iwai Signed-off-by: Marek Szyprowski Tested-by: Stefan Wahren Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20200701073949.28941-1-m.szyprowski@samsung.com Signed-off-by: Sasha Levin commit 5e77009e33a16f8c5987f6ced2fc322c7b89fd60 Author: Daniel Borkmann Date: Tue Sep 8 00:04:10 2020 +0200 bpf: Fix clobbering of r2 in bpf_gen_ld_abs [ Upstream commit e6a18d36118bea3bf497c9df4d9988b6df120689 ] Bryce reported that he saw the following with: 0: r6 = r1 1: r1 = 12 2: r0 = *(u16 *)skb[r1] The xlated sequence was incorrectly clobbering r2 with pointer value of r6 ... 0: (bf) r6 = r1 1: (b7) r1 = 12 2: (bf) r1 = r6 3: (bf) r2 = r1 4: (85) call bpf_skb_load_helper_16_no_cache#7692160 ... and hence call to the load helper never succeeded given the offset was too high. Fix it by reordering the load of r6 to r1. Other than that the insn has similar calling convention than BPF helpers, that is, r0 - r5 are scratch regs, so nothing else affected after the insn. Fixes: e0cea7ce988c ("bpf: implement ld_abs/ld_ind in native bpf") Reported-by: Bryce Kahle Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/cace836e4d07bb63b1a53e49c5dfb238a040c298.1599512096.git.daniel@iogearbox.net Signed-off-by: Sasha Levin commit 2e1a95f450d86eaef050b3eb6f5088ca468a9dc2 Author: Eric Dumazet Date: Tue Sep 8 03:40:25 2020 -0700 mac802154: tx: fix use-after-free [ Upstream commit 0ff4628f4c6c1ab87eef9f16b25355cadc426d64 ] syzbot reported a bug in ieee802154_tx() [1] A similar issue in ieee802154_xmit_worker() is also fixed in this patch. [1] BUG: KASAN: use-after-free in ieee802154_tx+0x3d2/0x480 net/mac802154/tx.c:88 Read of size 4 at addr ffff8880251a8c70 by task syz-executor.3/928 CPU: 0 PID: 928 Comm: syz-executor.3 Not tainted 5.9.0-rc3-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+0x198/0x1fd lib/dump_stack.c:118 print_address_description.constprop.0.cold+0xae/0x497 mm/kasan/report.c:383 __kasan_report mm/kasan/report.c:513 [inline] kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530 ieee802154_tx+0x3d2/0x480 net/mac802154/tx.c:88 ieee802154_subif_start_xmit+0xbe/0xe4 net/mac802154/tx.c:130 __netdev_start_xmit include/linux/netdevice.h:4634 [inline] netdev_start_xmit include/linux/netdevice.h:4648 [inline] dev_direct_xmit+0x4e9/0x6e0 net/core/dev.c:4203 packet_snd net/packet/af_packet.c:2989 [inline] packet_sendmsg+0x2413/0x5290 net/packet/af_packet.c:3014 sock_sendmsg_nosec net/socket.c:651 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:671 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2353 ___sys_sendmsg+0xf3/0x170 net/socket.c:2407 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2440 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x45d5b9 Code: 5d b4 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 2b b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007fc98e749c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000002ccc0 RCX: 000000000045d5b9 RDX: 0000000000000000 RSI: 0000000020007780 RDI: 000000000000000b RBP: 000000000118d020 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000118cfec R13: 00007fff690c720f R14: 00007fc98e74a9c0 R15: 000000000118cfec Allocated by task 928: kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48 kasan_set_track mm/kasan/common.c:56 [inline] __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:461 slab_post_alloc_hook mm/slab.h:518 [inline] slab_alloc_node mm/slab.c:3254 [inline] kmem_cache_alloc_node+0x136/0x3e0 mm/slab.c:3574 __alloc_skb+0x71/0x550 net/core/skbuff.c:198 alloc_skb include/linux/skbuff.h:1094 [inline] alloc_skb_with_frags+0x92/0x570 net/core/skbuff.c:5771 sock_alloc_send_pskb+0x72a/0x880 net/core/sock.c:2348 packet_alloc_skb net/packet/af_packet.c:2837 [inline] packet_snd net/packet/af_packet.c:2932 [inline] packet_sendmsg+0x19fb/0x5290 net/packet/af_packet.c:3014 sock_sendmsg_nosec net/socket.c:651 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:671 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2353 ___sys_sendmsg+0xf3/0x170 net/socket.c:2407 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2440 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Freed by task 928: kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48 kasan_set_track+0x1c/0x30 mm/kasan/common.c:56 kasan_set_free_info+0x1b/0x30 mm/kasan/generic.c:355 __kasan_slab_free+0xd8/0x120 mm/kasan/common.c:422 __cache_free mm/slab.c:3418 [inline] kmem_cache_free.part.0+0x74/0x1e0 mm/slab.c:3693 kfree_skbmem+0xef/0x1b0 net/core/skbuff.c:622 __kfree_skb net/core/skbuff.c:679 [inline] consume_skb net/core/skbuff.c:838 [inline] consume_skb+0xcf/0x160 net/core/skbuff.c:832 __dev_kfree_skb_any+0x9c/0xc0 net/core/dev.c:3107 fakelb_hw_xmit+0x20e/0x2a0 drivers/net/ieee802154/fakelb.c:81 drv_xmit_async net/mac802154/driver-ops.h:16 [inline] ieee802154_tx+0x282/0x480 net/mac802154/tx.c:81 ieee802154_subif_start_xmit+0xbe/0xe4 net/mac802154/tx.c:130 __netdev_start_xmit include/linux/netdevice.h:4634 [inline] netdev_start_xmit include/linux/netdevice.h:4648 [inline] dev_direct_xmit+0x4e9/0x6e0 net/core/dev.c:4203 packet_snd net/packet/af_packet.c:2989 [inline] packet_sendmsg+0x2413/0x5290 net/packet/af_packet.c:3014 sock_sendmsg_nosec net/socket.c:651 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:671 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2353 ___sys_sendmsg+0xf3/0x170 net/socket.c:2407 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2440 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The buggy address belongs to the object at ffff8880251a8c00 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 112 bytes inside of 224-byte region [ffff8880251a8c00, ffff8880251a8ce0) The buggy address belongs to the page: page:0000000062b6a4f1 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x251a8 flags: 0xfffe0000000200(slab) raw: 00fffe0000000200 ffffea0000435c88 ffffea00028b6c08 ffff8880a9055d00 raw: 0000000000000000 ffff8880251a80c0 000000010000000c 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880251a8b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880251a8b80: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc >ffff8880251a8c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880251a8c80: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ffff8880251a8d00: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb Fixes: 409c3b0c5f03 ("mac802154: tx: move stats tx increment") Signed-off-by: Eric Dumazet Reported-by: syzbot Cc: Alexander Aring Cc: Stefan Schmidt Cc: linux-wpan@vger.kernel.org Link: https://lore.kernel.org/r/20200908104025.4009085-1-edumazet@google.com Signed-off-by: Stefan Schmidt Signed-off-by: Sasha Levin commit eb5f810e06da3fc202b2fc57658ad711229c0e66 Author: Eelco Chaudron Date: Tue Sep 1 16:56:02 2020 +0200 netfilter: conntrack: nf_conncount_init is failing with IPv6 disabled [ Upstream commit 526e81b990e53e31ba40ba304a2285ffd098721f ] The openvswitch module fails initialization when used in a kernel without IPv6 enabled. nf_conncount_init() fails because the ct code unconditionally tries to initialize the netns IPv6 related bit, regardless of the build option. The change below ignores the IPv6 part if not enabled. Note that the corresponding _put() function already has this IPv6 configuration check. Fixes: 11efd5cb04a1 ("openvswitch: Support conntrack zone limit") Signed-off-by: Eelco Chaudron Reviewed-by: Simon Horman Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit b6112ff05f5f4f28b7b0e7cef02e5e3b0639e893 Author: Linus Lüssing Date: Fri Sep 4 20:28:00 2020 +0200 batman-adv: mcast/TT: fix wrongly dropped or rerouted packets [ Upstream commit 7dda5b3384121181c4e79f6eaeac2b94c0622c8d ] The unicast packet rerouting code makes several assumptions. For instance it assumes that there is always exactly one destination in the TT. This breaks for multicast frames in a unicast packets in several ways: For one thing if there is actually no TT entry and the destination node was selected due to the multicast tvlv flags it announced. Then an intermediate node will wrongly drop the packet. For another thing if there is a TT entry but the TTVN of this entry is newer than the originally addressed destination node: Then the intermediate node will wrongly redirect the packet, leading to duplicated multicast packets at a multicast listener and missing packets at other multicast listeners or multicast routers. Fixing this by not applying the unicast packet rerouting to batman-adv unicast packets with a multicast payload. We are not able to detect a roaming multicast listener at the moment and will just continue to send the multicast frame to both the new and old destination for a while in case of such a roaming multicast listener. Fixes: a73105b8d4c7 ("batman-adv: improved client announcement mechanism") Signed-off-by: Linus Lüssing Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Sasha Levin commit 5b0a13a03b8b3a258c3dd5c0e3d730b00bb44c8d Author: Jing Xiangfeng Date: Fri Sep 4 10:51:03 2020 +0800 atm: eni: fix the missed pci_disable_device() for eni_init_one() [ Upstream commit c2b947879ca320ac5505c6c29a731ff17da5e805 ] eni_init_one() misses to call pci_disable_device() in an error path. Jump to err_disable to fix it. Fixes: ede58ef28e10 ("atm: remove deprecated use of pci api") Signed-off-by: Jing Xiangfeng Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e0117ad11b3e59d7d955d1173430a1910625915b Author: Linus Lüssing Date: Thu Aug 27 17:34:48 2020 +0200 batman-adv: bla: fix type misuse for backbone_gw hash indexing [ Upstream commit 097930e85f90f252c44dc0d084598265dd44ca48 ] It seems that due to a copy & paste error the void pointer in batadv_choose_backbone_gw() is cast to the wrong type. Fixing this by using "struct batadv_bla_backbone_gw" instead of "struct batadv_bla_claim" which better matches the caller's side. For now it seems that we were lucky because the two structs both have their orig/vid and addr/vid in the beginning. However I stumbled over this issue when I was trying to add some debug variables in front of "orig" in batadv_backbone_gw, which caused hash lookups to fail. Fixes: 07568d0369f9 ("batman-adv: don't rely on positions in struct for hashing") Signed-off-by: Linus Lüssing Signed-off-by: Sven Eckelmann Signed-off-by: Sasha Levin commit a63798d534892d01c0aa20afa5d5893fa822a3d7 Author: Maximilian Luz Date: Tue Aug 25 17:38:29 2020 +0200 mwifiex: Increase AES key storage size to 256 bits [ Upstream commit 4afc850e2e9e781976fb2c7852ce7bac374af938 ] Following commit e18696786548 ("mwifiex: Prevent memory corruption handling keys") the mwifiex driver fails to authenticate with certain networks, specifically networks with 256 bit keys, and repeatedly asks for the password. The kernel log repeats the following lines (id and bssid redacted): mwifiex_pcie 0000:01:00.0: info: trying to associate to '' bssid mwifiex_pcie 0000:01:00.0: info: associated to bssid successfully mwifiex_pcie 0000:01:00.0: crypto keys added mwifiex_pcie 0000:01:00.0: info: successfully disconnected from : reason code 3 Tracking down this problem lead to the overflow check introduced by the aforementioned commit into mwifiex_ret_802_11_key_material_v2(). This check fails on networks with 256 bit keys due to the current storage size for AES keys in struct mwifiex_aes_param being only 128 bit. To fix this issue, increase the storage size for AES keys to 256 bit. Fixes: e18696786548 ("mwifiex: Prevent memory corruption handling keys") Signed-off-by: Maximilian Luz Reported-by: Kaloyan Nikolov Tested-by: Kaloyan Nikolov Reviewed-by: Dan Carpenter Reviewed-by: Brian Norris Tested-by: Brian Norris Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200825153829.38043-1-luzmaximilian@gmail.com Signed-off-by: Sasha Levin commit f43500892470820d190e044364094d93b20d0c4e Author: Tianjia Zhang Date: Sun Aug 2 19:15:41 2020 +0800 clocksource/drivers/h8300_timer8: Fix wrong return value in h8300_8timer_init() [ Upstream commit 400d033f5a599120089b5f0c54d14d198499af5a ] In the init function, if the call to of_iomap() fails, the return value is ENXIO instead of -ENXIO. Change to the right negative errno. Fixes: 691f8f878290f ("clocksource/drivers/h8300_timer8: Convert init function to return error") Cc: Daniel Lezcano Signed-off-by: Tianjia Zhang Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20200802111541.5429-1-tianjia.zhang@linux.alibaba.com Signed-off-by: Sasha Levin commit f77f4586bdd73d0d3b981969182a2aa98c4db0a6 Author: Tom Rix Date: Sun Aug 2 07:23:39 2020 -0700 ieee802154/adf7242: check status of adf7242_read_reg [ Upstream commit e3914ed6cf44bfe1f169e26241f8314556fd1ac1 ] Clang static analysis reports this error adf7242.c:887:6: warning: Assigned value is garbage or undefined len = len_u8; ^ ~~~~~~ len_u8 is set in adf7242_read_reg(lp, 0, &len_u8); When this call fails, len_u8 is not set. So check the return code. Fixes: 7302b9d90117 ("ieee802154/adf7242: Driver for ADF7242 MAC IEEE802154") Signed-off-by: Tom Rix Acked-by: Michael Hennerich Link: https://lore.kernel.org/r/20200802142339.21091-1-trix@redhat.com Signed-off-by: Stefan Schmidt Signed-off-by: Sasha Levin commit 22936fa7a295d824ead32278f13eb848a50494dd Author: Liu Jian Date: Mon Jul 20 22:33:15 2020 +0800 ieee802154: fix one possible memleak in ca8210_dev_com_init [ Upstream commit 88f46b3fe2ac41c381770ebad9f2ee49346b57a2 ] We should call destroy_workqueue to destroy mlme_workqueue in error branch. Fixes: ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver") Signed-off-by: Liu Jian Link: https://lore.kernel.org/r/20200720143315.40523-1-liujian56@huawei.com Signed-off-by: Stefan Schmidt Signed-off-by: Sasha Levin commit d85044145fdd791ea391fb0b09c9c036a7b02146 Author: Josh Poimboeuf Date: Thu Sep 10 10:24:57 2020 -0500 objtool: Fix noreturn detection for ignored functions [ Upstream commit db6c6a0df840e3f52c84cc302cc1a08ba11a4416 ] When a function is annotated with STACK_FRAME_NON_STANDARD, objtool doesn't validate its code paths. It also skips sibling call detection within the function. But sibling call detection is actually needed for the case where the ignored function doesn't have any return instructions. Otherwise objtool naively marks the function as implicit static noreturn, which affects the reachability of its callers, resulting in "unreachable instruction" warnings. Fix it by just enabling sibling call detection for ignored functions. The 'insn->ignore' check in add_jump_destinations() is no longer needed after e6da9567959e ("objtool: Don't use ignore flag for fake jumps"). Fixes the following warning: arch/x86/kvm/vmx/vmx.o: warning: objtool: vmx_handle_exit_irqoff()+0x142: unreachable instruction which triggers on an allmodconfig with CONFIG_GCOV_KERNEL unset. Reported-by: Linus Torvalds Signed-off-by: Josh Poimboeuf Signed-off-by: Borislav Petkov Acked-by: Linus Torvalds Link: https://lkml.kernel.org/r/5b1e2536cdbaa5246b60d7791b76130a74082c62.1599751464.git.jpoimboe@redhat.com Signed-off-by: Sasha Levin commit a53d9b3ae9c8db08326ef1db4c22ef22c27de8ad Author: Hans de Goede Date: Wed Sep 9 12:32:33 2020 +0200 i2c: core: Call i2c_acpi_install_space_handler() before i2c_acpi_register_devices() [ Upstream commit 21653a4181ff292480599dad996a2b759ccf050f ] Some ACPI i2c-devices _STA method (which is used to detect if the device is present) use autodetection code which probes which device is present over i2c. This requires the I2C ACPI OpRegion handler to be registered before we enumerate i2c-clients under the i2c-adapter. This fixes the i2c touchpad on the Lenovo ThinkBook 14-IIL and ThinkBook 15 IIL not getting an i2c-client instantiated and thus not working. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1842039 Signed-off-by: Hans de Goede Reviewed-by: Mika Westerberg Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 65f452b7a2c119bcc80cdf2a75d4e135c73b7de9 Author: Michel Dänzer Date: Fri Sep 4 12:43:04 2020 +0200 drm/amdgpu/dc: Require primary plane to be enabled whenever the CRTC is [ Upstream commit 2f228aab21bbc74e90e267a721215ec8be51daf7 ] Don't check drm_crtc_state::active for this either, per its documentation in include/drm/drm_crtc.h: * Hence drivers must not consult @active in their various * &drm_mode_config_funcs.atomic_check callback to reject an atomic * commit. atomic_remove_fb disables the CRTC as needed for disabling the primary plane. This prevents at least the following problems if the primary plane gets disabled (e.g. due to destroying the FB assigned to the primary plane, as happens e.g. with mutter in Wayland mode): * The legacy cursor ioctl returned EINVAL for a non-0 cursor FB ID (which enables the cursor plane). * If the cursor plane was enabled, changing the legacy DPMS property value from off to on returned EINVAL. v2: * Minor changes to code comment and commit log, per review feedback. GitLab: https://gitlab.gnome.org/GNOME/mutter/-/issues/1108 GitLab: https://gitlab.gnome.org/GNOME/mutter/-/issues/1165 GitLab: https://gitlab.gnome.org/GNOME/mutter/-/issues/1344 Suggested-by: Daniel Vetter Acked-by: Daniel Vetter Reviewed-by: Nicholas Kazlauskas Signed-off-by: Michel Dänzer Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 8c48b7617b7c486a4c3fcaf7be249a6c899113fb Author: Jun Lei Date: Thu Sep 3 16:17:46 2020 -0400 drm/amd/display: update nv1x stutter latencies [ Upstream commit c4790a8894232f39c25c7c546c06efe074e63384 ] [why] Recent characterization shows increased stutter latencies on some SKUs, leading to underflow. [how] Update SOC params to account for this worst case latency. Signed-off-by: Jun Lei Acked-by: Aurabindo Pillai Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c48363d19fcbbcfbef23e3daff3fd33df70c4a29 Author: Dennis Li Date: Wed Sep 2 17:11:09 2020 +0800 drm/amdkfd: fix a memory leak issue [ Upstream commit 087d764159996ae378b08c0fdd557537adfd6899 ] In the resume stage of GPU recovery, start_cpsch will call pm_init which set pm->allocated as false, cause the next pm_release_ib has no chance to release ib memory. Add pm_release_ib in stop_cpsch which will be called in the suspend stage of GPU recovery. Reviewed-by: Felix Kuehling Signed-off-by: Dennis Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b11f2d6b80f4515893db949c0b12e4655f7fba9d Author: Borislav Petkov Date: Fri Sep 11 18:17:30 2020 +0200 EDAC/ghes: Check whether the driver is on the safe list correctly [ Upstream commit 251c54ea26fa6029b01a76161a37a12fde5124e4 ] With CONFIG_DEBUG_TEST_DRIVER_REMOVE=y, a system would try to probe, unregister and probe again a driver. When ghes_edac is attempted to be loaded on a system which is not on the safe platforms list, ghes_edac_register() would return early. The unregister counterpart ghes_edac_unregister() would still attempt to unregister and exit early at the refcount test, leading to the refcount underflow below. In order to not do *anything* on the unregister path too, reuse the force_load parameter and check it on that path too, before fumbling with the refcount. ghes_edac: ghes_edac_register: entry ghes_edac: ghes_edac_register: return -ENODEV ------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 10 PID: 1 at lib/refcount.c:28 refcount_warn_saturate+0xb9/0x100 Modules linked in: CPU: 10 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc4+ #12 Hardware name: GIGABYTE MZ01-CE1-00/MZ01-CE1-00, BIOS F02 08/29/2018 RIP: 0010:refcount_warn_saturate+0xb9/0x100 Code: 82 e8 fb 8f 4d 00 90 0f 0b 90 90 c3 80 3d 55 4c f5 00 00 75 88 c6 05 4c 4c f5 00 01 90 48 c7 c7 d0 8a 10 82 e8 d8 8f 4d 00 90 <0f> 0b 90 90 c3 80 3d 30 4c f5 00 00 0f 85 61 ff ff ff c6 05 23 4c RSP: 0018:ffffc90000037d58 EFLAGS: 00010292 RAX: 0000000000000026 RBX: ffff88840b8da000 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffffffff8216b24f RDI: 00000000ffffffff RBP: ffff88840c662e00 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000046 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88840ee80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000800002211000 CR4: 00000000003506e0 Call Trace: ghes_edac_unregister ghes_remove platform_drv_remove really_probe driver_probe_device device_driver_attach __driver_attach ? device_driver_attach ? device_driver_attach bus_for_each_dev bus_add_driver driver_register ? bert_init ghes_init do_one_initcall ? rcu_read_lock_sched_held kernel_init_freeable ? rest_init kernel_init ret_from_fork ... ghes_edac: ghes_edac_unregister: FALSE, refcount: -1073741824 Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20200911164950.GB19320@zn.tnic Signed-off-by: Sasha Levin commit c7be1f4d4e608564a5466903cea21fecf914fd96 Author: Sven Schnelle Date: Thu Sep 10 12:24:53 2020 +0200 lockdep: fix order in trace_hardirqs_off_caller() [ Upstream commit 73ac74c7d489756d2313219a108809921dbfaea1 ] Switch order so that locking state is consistent even if the IRQ tracer calls into lockdep again. Acked-by: Peter Zijlstra Signed-off-by: Sven Schnelle Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 43d750a0994ca8edb9f7695c779901592339482c Author: Ilya Leoshkevich Date: Wed Sep 9 14:27:25 2020 +0200 s390/init: add missing __init annotations [ Upstream commit fcb2b70cdb194157678fb1a75f9ff499aeba3d2a ] Add __init to reserve_memory_end, reserve_oldmem and remove_oldmem. Sometimes these functions are not inlined, and then the build complains about section mismatch. Signed-off-by: Ilya Leoshkevich Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit fdd60315b9312d04d3178326aeadc2c8a1eca918 Author: Eddie James Date: Wed Sep 9 15:30:57 2020 -0500 i2c: aspeed: Mask IRQ status to relevant bits [ Upstream commit 1a1d6db23ddacde0b15ea589e9103373e05af8de ] Mask the IRQ status to only the bits that the driver checks. This prevents excessive driver warnings when operating in slave mode when additional bits are set that the driver doesn't handle. Signed-off-by: Eddie James Reviewed-by: Tao Ren Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 66d987b80dc34236777318000ca94c3b963f8aca Author: Palmer Dabbelt Date: Mon Aug 24 17:21:22 2020 -0700 RISC-V: Take text_mutex in ftrace_init_nop() [ Upstream commit 66d18dbda8469a944dfec6c49d26d5946efba218 ] Without this we get lockdep failures. They're spurious failures as SMP isn't up when ftrace_init_nop() is called. As far as I can tell the easiest fix is to just take the lock, which also seems like the safest fix. Signed-off-by: Palmer Dabbelt Acked-by: Guo Ren Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 487e3a1bc9ab3558f761c9d604dc90662d6d32d9 Author: Hans de Goede Date: Tue Sep 1 10:06:23 2020 +0200 ASoC: Intel: bytcr_rt5640: Add quirk for MPMAN Converter9 2-in-1 [ Upstream commit 6a0137101f47301fff2da6ba4b9048383d569909 ] The MPMAN Converter9 2-in-1 almost fully works with out default settings. The only problem is that it has only 1 speaker so any sounds only playing on the right channel get lost. Add a quirk for this model using the default settings + MONO_SPEAKER. Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200901080623.4987-1-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4a07fbecfa554febfc11509877165b0cdc8494ef Author: Sylwester Nawrocki Date: Thu Aug 27 19:33:57 2020 +0200 ASoC: wm8994: Ensure the device is resumed in wm89xx_mic_detect functions [ Upstream commit f5a2cda4f1db89776b64c4f0f2c2ac609527ac70 ] When the wm8958_mic_detect, wm8994_mic_detect functions get called from the machine driver, e.g. from the card's late_probe() callback, the CODEC device may be PM runtime suspended and any regmap writes have no effect. Add PM runtime calls to these functions to ensure the device registers are updated as expected. This suppresses an error during boot "wm8994-codec: ASoC: error at snd_soc_component_update_bits on wm8994-codec" caused by the regmap access error due to the cache_only flag being set. Signed-off-by: Sylwester Nawrocki Acked-by: Krzysztof Kozlowski Acked-by: Charles Keepax Link: https://lore.kernel.org/r/20200827173357.31891-2-s.nawrocki@samsung.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7cdb35fc858f4cf741084bc0d2716aad5b97665e Author: Sylwester Nawrocki Date: Thu Aug 27 19:33:56 2020 +0200 ASoC: wm8994: Skip setting of the WM8994_MICBIAS register for WM1811 [ Upstream commit 811c5494436789e7149487c06e0602b507ce274b ] The WM8994_MICBIAS register is not available in the WM1811 CODEC so skip initialization of that register for that device. This suppresses an error during boot: "wm8994-codec: ASoC: error at snd_soc_component_update_bits on wm8994-codec" Signed-off-by: Sylwester Nawrocki Acked-by: Krzysztof Kozlowski Acked-by: Charles Keepax Link: https://lore.kernel.org/r/20200827173357.31891-1-s.nawrocki@samsung.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 927a024487dc0218024667fc93db66defa481a7a Author: Kuninori Morimoto Date: Tue Aug 25 08:39:24 2020 +0900 ASoC: pcm3168a: ignore 0 Hz settings [ Upstream commit 7ad26d6671db758c959d7e1d100b138a38483612 ] Some sound card try to set 0 Hz as reset, but it is impossible. This patch ignores it to avoid error return. Signed-off-by: Kuninori Morimoto Link: https://lore.kernel.org/r/87a6yjy5sy.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8ebf2b77d7e5687d49fd9a1505d7fe30009a8433 Author: Amol Grover Date: Mon Apr 6 16:29:50 2020 +0530 device_cgroup: Fix RCU list debugging warning [ Upstream commit bc62d68e2a0a69fcdcf28aca8edb01abf306b698 ] exceptions may be traversed using list_for_each_entry_rcu() outside of an RCU read side critical section BUT under the protection of decgroup_mutex. Hence add the corresponding lockdep expression to fix the following false-positive warning: [ 2.304417] ============================= [ 2.304418] WARNING: suspicious RCU usage [ 2.304420] 5.5.4-stable #17 Tainted: G E [ 2.304422] ----------------------------- [ 2.304424] security/device_cgroup.c:355 RCU-list traversed in non-reader section!! Signed-off-by: Amol Grover Signed-off-by: James Morris Signed-off-by: Sasha Levin commit 5b84cd71c1da50fb99cd81d526563ed2e3a93c1b Author: Anthony Iliopoulos Date: Tue Jul 14 13:11:59 2020 +0200 nvme: explicitly update mpath disk capacity on revalidation [ Upstream commit 05b29021fba5e725dd385151ef00b6340229b500 ] Commit 3b4b19721ec652 ("nvme: fix possible deadlock when I/O is blocked") reverted multipath head disk revalidation due to deadlocks caused by holding the bd_mutex during revalidate. Updating the multipath disk blockdev size is still required though for userspace to be able to observe any resizing while the device is mounted. Directly update the bdev inode size to avoid unnecessarily holding the bdev->bd_mutex. Fixes: 3b4b19721ec652 ("nvme: fix possible deadlock when I/O is blocked") Signed-off-by: Anthony Iliopoulos Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 765f47c425aa07edc6de4398b923260c6c35cc97 Author: Tonghao Zhang Date: Sat Apr 25 11:39:48 2020 +0800 net: openvswitch: use div_u64() for 64-by-32 divisions [ Upstream commit 659d4587fe7233bfdff303744b20d6f41ad04362 ] Compile the kernel for arm 32 platform, the build warning found. To fix that, should use div_u64() for divisions. | net/openvswitch/meter.c:396: undefined reference to `__udivdi3' [add more commit msg, change reported tag, and use div_u64 instead of do_div by Tonghao] Fixes: e57358873bb5d6ca ("net: openvswitch: use u64 for meter bucket") Reported-by: kbuild test robot Signed-off-by: Tonghao Zhang Tested-by: Tonghao Zhang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit caa44b67f4d38eaf26663e620563ef0b3a1f9c3f Author: Takashi Iwai Date: Mon Jul 27 18:44:43 2020 +0200 ALSA: hda: Workaround for spurious wakeups on some Intel platforms [ Upstream commit a6630529aecb5a3e84370c376ed658e892e6261e ] We've received a regression report on Intel HD-audio controller that wakes up immediately after S3 suspend. The bisection leads to the commit c4c8dd6ef807 ("ALSA: hda: Skip controller resume if not needed"). This commit replaces the system-suspend to use pm_runtime_force_suspend() instead of the direct call of __azx_runtime_suspend(). However, by some really mysterious reason, pm_runtime_force_suspend() causes a spurious wakeup (although it calls the same __azx_runtime_suspend() internally). As an ugly workaround for now, revert the behavior to call __azx_runtime_suspend() and __azx_runtime_resume() for those old Intel platforms that may exhibit such a problem, while keeping the new standard pm_runtime_force_suspend() and pm_runtime_force_resume() pair for the remaining chips. Fixes: c4c8dd6ef807 ("ALSA: hda: Skip controller resume if not needed") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208649 Cc: Link: https://lore.kernel.org/r/20200727164443.4233-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 862dd508c6f273ddb24e3c5ec492e2cf92d09523 Author: Takashi Iwai Date: Wed Apr 22 22:37:44 2020 +0200 ALSA: hda: Always use jackpoll helper for jack update after resume [ Upstream commit 8d6762af302d69f76fa788a277a56a9d9cd275d5 ] HD-audio codec driver applies a tricky procedure to forcibly perform the runtime resume by mimicking the usage count even if the device has been runtime-suspended beforehand. This was needed to assure to trigger the jack detection update after the system resume. And recently we also applied the similar logic to the HD-audio controller side. However this seems leading to some inconsistency, and eventually PCI controller gets screwed up. This patch is an attempt to fix and clean up those behavior: instead of the tricky runtime resume procedure, the existing jackpoll work is scheduled when such a forced codec resume is required. The jackpoll work will power up the codec, and this alone should suffice for the jack status update in usual cases. If the extra polling is requested (by checking codec->jackpoll_interval), the manual update is invoked after that, and the codec is powered down again. Also, we filter the spurious wake up of the codec from the controller runtime resume by checking codec->relaxed_resume flag. If this flag is set, basically we don't need to wake up explicitly, but it's supposed to be done via the audio component notifier. Fixes: c4c8dd6ef807 ("ALSA: hda: Skip controller resume if not needed") Link: https://lore.kernel.org/r/20200422203744.26299-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 1f160738d9a845c46830769f090ae34b8ffd8a41 Author: Jin Yao Date: Thu Apr 30 08:36:18 2020 +0800 perf parse-events: Use strcmp() to compare the PMU name [ Upstream commit 8510895bafdbf7c4dd24c22946d925691135c2b2 ] A big uncore event group is split into multiple small groups which only include the uncore events from the same PMU. This has been supported in the commit 3cdc5c2cb924a ("perf parse-events: Handle uncore event aliases in small groups properly"). If the event's PMU name starts to repeat, it must be a new event. That can be used to distinguish the leader from other members. But now it only compares the pointer of pmu_name (leader->pmu_name == evsel->pmu_name). If we use "perf stat -M LLC_MISSES.PCIE_WRITE -a" on cascadelakex, the event list is: evsel->name evsel->pmu_name --------------------------------------------------------------- unc_iio_data_req_of_cpu.mem_write.part0 uncore_iio_4 (as leader) unc_iio_data_req_of_cpu.mem_write.part0 uncore_iio_2 unc_iio_data_req_of_cpu.mem_write.part0 uncore_iio_0 unc_iio_data_req_of_cpu.mem_write.part0 uncore_iio_5 unc_iio_data_req_of_cpu.mem_write.part0 uncore_iio_3 unc_iio_data_req_of_cpu.mem_write.part0 uncore_iio_1 unc_iio_data_req_of_cpu.mem_write.part1 uncore_iio_4 ...... For the event "unc_iio_data_req_of_cpu.mem_write.part1" with "uncore_iio_4", it should be the event from PMU "uncore_iio_4". It's not a new leader for this PMU. But if we use "(leader->pmu_name == evsel->pmu_name)", the check would be failed and the event is stored to leaders[] as a new PMU leader. So this patch uses strcmp to compare the PMU name between events. Fixes: d4953f7ef1a2 ("perf parse-events: Fix 3 use after frees found with clang ASAN") Signed-off-by: Jin Yao Acked-by: Jiri Olsa Cc: Alexander Shishkin Cc: Andi Kleen Cc: Jin Yao Cc: Kan Liang Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20200430003618.17002-1-yao.jin@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 4d8d6f71b60fdc3c9fb76446a2dede6c06851518 Author: Walter Lozano Date: Wed Jul 15 23:54:52 2020 -0300 opp: Increase parsed_static_opps in _of_add_opp_table_v1() [ Upstream commit 6544abc520f0fff701e9da382110dc29676c683a ] Currently, when using _of_add_opp_table_v2 parsed_static_opps is increased and this value is used in _opp_remove_all_static() to check if there are static opp entries that need to be freed. Unfortunately this does not happen when using _of_add_opp_table_v1(), which leads to warnings. This patch increases parsed_static_opps in _of_add_opp_table_v1() in a similar way as in _of_add_opp_table_v2(). Fixes: 03758d60265c ("opp: Replace list_kref with a local counter") Cc: v5.6+ # v5.6+ Signed-off-by: Walter Lozano [ Viresh: Do the operation with lock held and set the value to 1 instead of incrementing it ] Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 87e6e1957cf0da966378b61264dc64d680020a9a Author: Arnd Bergmann Date: Mon Dec 16 14:18:42 2019 +0100 mt76: fix LED link time failure [ Upstream commit d68f4e43a46ff1f772ff73085f96d44eb4163e9d ] The mt76_led_cleanup() function is called unconditionally, which leads to a link error when CONFIG_LEDS is a loadable module or disabled but mt76 is built-in: drivers/net/wireless/mediatek/mt76/mac80211.o: In function `mt76_unregister_device': mac80211.c:(.text+0x2ac): undefined reference to `led_classdev_unregister' Use the same trick that is guarding the registration, using an IS_ENABLED() check for the CONFIG_MT76_LEDS symbol that indicates whether LEDs can be used or not. Fixes: 36f7e2b2bb1d ("mt76: do not use devm API for led classdev") Signed-off-by: Arnd Bergmann Acked-by: Felix Fietkau Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit ca1704f177dc5f34b8f89552422c1c566fa7c2f3 Author: Hou Tao Date: Mon Feb 10 21:26:34 2020 +0800 ubi: fastmap: Free unused fastmap anchor peb during detach [ Upstream commit c16f39d14a7e0ec59881fbdb22ae494907534384 ] When CONFIG_MTD_UBI_FASTMAP is enabled, fm_anchor will be assigned a free PEB during ubi_wl_init() or ubi_update_fastmap(). However if fastmap is not used or disabled on the MTD device, ubi_wl_entry related with the PEB will not be freed during detach. So Fix it by freeing the unused fastmap anchor during detach. Fixes: f9c34bb52997 ("ubi: Fix producing anchor PEBs") Reported-by: syzbot+f317896aae32eb281a58@syzkaller.appspotmail.com Reviewed-by: Sascha Hauer Signed-off-by: Hou Tao Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 74924e407bf74667b07430f785a104371be097af Author: Quinn Tran Date: Tue Nov 5 07:06:50 2019 -0800 scsi: qla2xxx: Retry PLOGI on FC-NVMe PRLI failure [ Upstream commit 983f127603fac650fa34ee69db363e4615eaf9e7 ] Current code will send PRLI with FC-NVMe bit set for the targets which support only FCP. This may result into issue with targets which do not understand NVMe and will go into a strange state. This patch would restart the login process by going back to PLOGI state. The PLOGI state will force the target to respond to correct PRLI request. Fixes: c76ae845ea836 ("scsi: qla2xxx: Add error handling for PLOGI ELS passthrough") Cc: stable@vger.kernel.org # 5.4 Link: https://lore.kernel.org/r/20191105150657.8092-2-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 e1ad5cf63e402c37a4e18d84921bc5d4e37230e4 Author: Thomas Richter Date: Wed Jul 29 15:53:14 2020 +0200 perf tests: Fix test 68 zstd compression for s390 [ Upstream commit 463538a383a27337cb83ae195e432a839a52d639 ] Commit 5aa98879efe7 ("s390/cpum_sf: prohibit callchain data collection") prohibits call graph sampling for hardware events on s390. The information recorded is out of context and does not match. On s390 this commit now breaks test case 68 Zstd perf.data compression/decompression. Therefore omit call graph sampling on s390 in this test. Output before: [root@t35lp46 perf]# ./perf test -Fv 68 68: Zstd perf.data compression/decompression : --- start --- Collecting compressed record file: Error: cycles: PMU Hardware doesn't support sampling/overflow-interrupts. Try 'perf stat' ---- end ---- Zstd perf.data compression/decompression: FAILED! [root@t35lp46 perf]# Output after: [root@t35lp46 perf]# ./perf test -Fv 68 68: Zstd perf.data compression/decompression : --- start --- Collecting compressed record file: 500+0 records in 500+0 records out 256000 bytes (256 kB, 250 KiB) copied, 0.00615638 s, 41.6 MB/s [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.004 MB /tmp/perf.data.X3M, compressed (original 0.002 MB, ratio is 3.609) ] Checking compressed events stats: # compressed : Zstd, level = 1, ratio = 4 COMPRESSED events: 1 2ELIFREPh---- end ---- Zstd perf.data compression/decompression: Ok [root@t35lp46 perf]# Signed-off-by: Thomas Richter Reviewed-by: Sumanth Korikkar Cc: Heiko Carstens Cc: Sven Schnelle Cc: Vasily Gorbik Link: http://lore.kernel.org/lkml/20200729135314.91281-1-tmricht@linux.ibm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 85c417050fc7fef65b9bce690f2d8a6d0aefdd2c Author: Qu Wenruo Date: Fri Jul 17 15:12:05 2020 +0800 btrfs: qgroup: fix data leak caused by race between writeback and truncate [ Upstream commit fa91e4aa1716004ea8096d5185ec0451e206aea0 ] [BUG] When running tests like generic/013 on test device with btrfs quota enabled, it can normally lead to data leak, detected at unmount time: BTRFS warning (device dm-3): qgroup 0/5 has unreleased space, type 0 rsv 4096 ------------[ cut here ]------------ WARNING: CPU: 11 PID: 16386 at fs/btrfs/disk-io.c:4142 close_ctree+0x1dc/0x323 [btrfs] RIP: 0010:close_ctree+0x1dc/0x323 [btrfs] Call Trace: btrfs_put_super+0x15/0x17 [btrfs] generic_shutdown_super+0x72/0x110 kill_anon_super+0x18/0x30 btrfs_kill_super+0x17/0x30 [btrfs] deactivate_locked_super+0x3b/0xa0 deactivate_super+0x40/0x50 cleanup_mnt+0x135/0x190 __cleanup_mnt+0x12/0x20 task_work_run+0x64/0xb0 __prepare_exit_to_usermode+0x1bc/0x1c0 __syscall_return_slowpath+0x47/0x230 do_syscall_64+0x64/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 ---[ end trace caf08beafeca2392 ]--- BTRFS error (device dm-3): qgroup reserved space leaked [CAUSE] In the offending case, the offending operations are: 2/6: writev f2X[269 1 0 0 0 0] [1006997,67,288] 0 2/7: truncate f2X[269 1 0 0 48 1026293] 18388 0 The following sequence of events could happen after the writev(): CPU1 (writeback) | CPU2 (truncate) ----------------------------------------------------------------- btrfs_writepages() | |- extent_write_cache_pages() | |- Got page for 1003520 | | 1003520 is Dirty, no writeback | | So (!clear_page_dirty_for_io()) | | gets called for it | |- Now page 1003520 is Clean. | | | btrfs_setattr() | | |- btrfs_setsize() | | |- truncate_setsize() | | New i_size is 18388 |- __extent_writepage() | | |- page_offset() > i_size | |- btrfs_invalidatepage() | |- Page is clean, so no qgroup | callback executed This means, the qgroup reserved data space is not properly released in btrfs_invalidatepage() as the page is Clean. [FIX] Instead of checking the dirty bit of a page, call btrfs_qgroup_free_data() unconditionally in btrfs_invalidatepage(). As qgroup rsv are completely bound to the QGROUP_RESERVED bit of io_tree, not bound to page status, thus we won't cause double freeing anyway. Fixes: 0b34c261e235 ("btrfs: qgroup: Prevent qgroup->reserved from going subzero") CC: stable@vger.kernel.org # 4.14+ Reviewed-by: Josef Bacik Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit af60d80598b3c18abf250dfd0d4039be3846b4b9 Author: Zeng Tao Date: Wed Jul 15 15:34:41 2020 +0800 vfio/pci: fix racy on error and request eventfd ctx [ Upstream commit b872d0640840018669032b20b6375a478ed1f923 ] The vfio_pci_release call will free and clear the error and request eventfd ctx while these ctx could be in use at the same time in the function like vfio_pci_request, and it's expected to protect them under the vdev->igate mutex, which is missing in vfio_pci_release. This issue is introduced since commit 1518ac272e78 ("vfio/pci: fix memory leaks of eventfd ctx"),and since commit 5c5866c593bb ("vfio/pci: Clear error and request eventfd ctx after releasing"), it's very easily to trigger the kernel panic like this: [ 9513.904346] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 [ 9513.913091] Mem abort info: [ 9513.915871] ESR = 0x96000006 [ 9513.918912] EC = 0x25: DABT (current EL), IL = 32 bits [ 9513.924198] SET = 0, FnV = 0 [ 9513.927238] EA = 0, S1PTW = 0 [ 9513.930364] Data abort info: [ 9513.933231] ISV = 0, ISS = 0x00000006 [ 9513.937048] CM = 0, WnR = 0 [ 9513.940003] user pgtable: 4k pages, 48-bit VAs, pgdp=0000007ec7d12000 [ 9513.946414] [0000000000000008] pgd=0000007ec7d13003, p4d=0000007ec7d13003, pud=0000007ec728c003, pmd=0000000000000000 [ 9513.956975] Internal error: Oops: 96000006 [#1] PREEMPT SMP [ 9513.962521] Modules linked in: vfio_pci vfio_virqfd vfio_iommu_type1 vfio hclge hns3 hnae3 [last unloaded: vfio_pci] [ 9513.972998] CPU: 4 PID: 1327 Comm: bash Tainted: G W 5.8.0-rc4+ #3 [ 9513.980443] Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V3.B270.01 05/08/2020 [ 9513.989274] pstate: 80400089 (Nzcv daIf +PAN -UAO BTYPE=--) [ 9513.994827] pc : _raw_spin_lock_irqsave+0x48/0x88 [ 9513.999515] lr : eventfd_signal+0x6c/0x1b0 [ 9514.003591] sp : ffff800038a0b960 [ 9514.006889] x29: ffff800038a0b960 x28: ffff007ef7f4da10 [ 9514.012175] x27: ffff207eefbbfc80 x26: ffffbb7903457000 [ 9514.017462] x25: ffffbb7912191000 x24: ffff007ef7f4d400 [ 9514.022747] x23: ffff20be6e0e4c00 x22: 0000000000000008 [ 9514.028033] x21: 0000000000000000 x20: 0000000000000000 [ 9514.033321] x19: 0000000000000008 x18: 0000000000000000 [ 9514.038606] x17: 0000000000000000 x16: ffffbb7910029328 [ 9514.043893] x15: 0000000000000000 x14: 0000000000000001 [ 9514.049179] x13: 0000000000000000 x12: 0000000000000002 [ 9514.054466] x11: 0000000000000000 x10: 0000000000000a00 [ 9514.059752] x9 : ffff800038a0b840 x8 : ffff007ef7f4de60 [ 9514.065038] x7 : ffff007fffc96690 x6 : fffffe01faffb748 [ 9514.070324] x5 : 0000000000000000 x4 : 0000000000000000 [ 9514.075609] x3 : 0000000000000000 x2 : 0000000000000001 [ 9514.080895] x1 : ffff007ef7f4d400 x0 : 0000000000000000 [ 9514.086181] Call trace: [ 9514.088618] _raw_spin_lock_irqsave+0x48/0x88 [ 9514.092954] eventfd_signal+0x6c/0x1b0 [ 9514.096691] vfio_pci_request+0x84/0xd0 [vfio_pci] [ 9514.101464] vfio_del_group_dev+0x150/0x290 [vfio] [ 9514.106234] vfio_pci_remove+0x30/0x128 [vfio_pci] [ 9514.111007] pci_device_remove+0x48/0x108 [ 9514.115001] device_release_driver_internal+0x100/0x1b8 [ 9514.120200] device_release_driver+0x28/0x38 [ 9514.124452] pci_stop_bus_device+0x68/0xa8 [ 9514.128528] pci_stop_and_remove_bus_device+0x20/0x38 [ 9514.133557] pci_iov_remove_virtfn+0xb4/0x128 [ 9514.137893] sriov_disable+0x3c/0x108 [ 9514.141538] pci_disable_sriov+0x28/0x38 [ 9514.145445] hns3_pci_sriov_configure+0x48/0xb8 [hns3] [ 9514.150558] sriov_numvfs_store+0x110/0x198 [ 9514.154724] dev_attr_store+0x44/0x60 [ 9514.158373] sysfs_kf_write+0x5c/0x78 [ 9514.162018] kernfs_fop_write+0x104/0x210 [ 9514.166010] __vfs_write+0x48/0x90 [ 9514.169395] vfs_write+0xbc/0x1c0 [ 9514.172694] ksys_write+0x74/0x100 [ 9514.176079] __arm64_sys_write+0x24/0x30 [ 9514.179987] el0_svc_common.constprop.4+0x110/0x200 [ 9514.184842] do_el0_svc+0x34/0x98 [ 9514.188144] el0_svc+0x14/0x40 [ 9514.191185] el0_sync_handler+0xb0/0x2d0 [ 9514.195088] el0_sync+0x140/0x180 [ 9514.198389] Code: b9001020 d2800000 52800022 f9800271 (885ffe61) [ 9514.204455] ---[ end trace 648de00c8406465f ]--- [ 9514.212308] note: bash[1327] exited with preempt_count 1 Cc: Qian Cai Cc: Alex Williamson Fixes: 1518ac272e78 ("vfio/pci: fix memory leaks of eventfd ctx") Signed-off-by: Zeng Tao Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit eb7833e0ee0118100fbcbffb84a449eec5baf039 Author: Andy Lutomirski Date: Fri Jun 26 10:21:15 2020 -0700 selftests/x86/syscall_nt: Clear weird flags after each test [ Upstream commit a61fa2799ef9bf6c4f54cf7295036577cececc72 ] Clear the weird flags before logging to improve strace output -- logging results while, say, TF is set does no one any favors. Signed-off-by: Andy Lutomirski Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/907bfa5a42d4475b8245e18b67a04b13ca51ffdb.1593191971.git.luto@kernel.org Signed-off-by: Sasha Levin commit 7292e6e9d82c345f31c3286c59c0d8db9117c8e2 Author: Javed Hasan Date: Fri Jun 26 02:49:59 2020 -0700 scsi: libfc: Skip additional kref updating work event [ Upstream commit 823a65409c8990f64c5693af98ce0e7819975cba ] When an rport event (RPORT_EV_READY) is updated without work being queued, avoid taking an additional reference. This issue was leading to memory leak. Trace from KMEMLEAK tool: unreferenced object 0xffff8888259e8780 (size 512): comm "kworker/2:1", jiffies 4433237386 (age 113021.971s) hex dump (first 32 bytes): 58 0a ec cf 83 88 ff ff 00 00 00 00 00 00 00 00 01 00 00 00 08 00 00 00 13 7d f0 1e 0e 00 00 10 backtrace: [<000000006b25760f>] fc_rport_recv_req+0x3c6/0x18f0 [libfc] [<00000000f208d994>] fc_lport_recv_els_req+0x120/0x8a0 [libfc] [<00000000a9c437b8>] fc_lport_recv+0xb9/0x130 [libfc] [<00000000a9c437b8>] fc_lport_recv+0xb9/0x130 [libfc] [<00000000ad5be37b>] qedf_ll2_process_skb+0x73d/0xad0 [qedf] [<00000000e0eb6893>] process_one_work+0x382/0x6c0 [<000000002dfd9e21>] worker_thread+0x57/0x5c0 [<00000000b648204f>] kthread+0x1a0/0x1c0 [<0000000072f5ab20>] ret_from_fork+0x35/0x40 [<000000001d5c05d8>] 0xffffffffffffffff Below is the log sequence which leads to memory leak. Here we get the RPORT_EV_READY and RPORT_EV_STOP back to back, which lead to overwrite the event RPORT_EV_READY by event RPORT_EV_STOP. Because of this, kref_count gets incremented by 1. kernel: host0: rport fffce5: Received PLOGI request kernel: host0: rport fffce5: Received PLOGI in INIT state kernel: host0: rport fffce5: Port is Ready kernel: host0: rport fffce5: Received PRLI request while in state Ready kernel: host0: rport fffce5: PRLI rspp type 8 active 1 passive 0 kernel: host0: rport fffce5: Received LOGO request while in state Ready kernel: host0: rport fffce5: Delete port kernel: host0: rport fffce5: Received PLOGI request kernel: host0: rport fffce5: Received PLOGI in state Delete - send busy kernel: host0: rport fffce5: work event 3 kernel: host0: rport fffce5: lld callback ev 3 kernel: host0: rport fffce5: work delete Link: https://lore.kernel.org/r/20200626094959.32151-1-jhasan@marvell.com Reviewed-by: Girish Basrur Reviewed-by: Saurav Kashyap Reviewed-by: Shyam Sundar Signed-off-by: Javed Hasan Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 1e15d5237c1e8518e83dc4972aada432d252a63c Author: Javed Hasan Date: Mon Jun 22 03:12:11 2020 -0700 scsi: libfc: Handling of extra kref [ Upstream commit 71f2bf85e90d938d4a9ef9dd9bfa8d9b0b6a03f7 ] Handling of extra kref which is done by lookup table in case rdata is already present in list. This issue was leading to memory leak. Trace from KMEMLEAK tool: unreferenced object 0xffff8888259e8780 (size 512): comm "kworker/2:1", pid 182614, jiffies 4433237386 (age 113021.971s) hex dump (first 32 bytes): 58 0a ec cf 83 88 ff ff 00 00 00 00 00 00 00 00 01 00 00 00 08 00 00 00 13 7d f0 1e 0e 00 00 10 backtrace: [<000000006b25760f>] fc_rport_recv_req+0x3c6/0x18f0 [libfc] [<00000000f208d994>] fc_lport_recv_els_req+0x120/0x8a0 [libfc] [<00000000a9c437b8>] fc_lport_recv+0xb9/0x130 [libfc] [<00000000ad5be37b>] qedf_ll2_process_skb+0x73d/0xad0 [qedf] [<00000000e0eb6893>] process_one_work+0x382/0x6c0 [<000000002dfd9e21>] worker_thread+0x57/0x5c0 [<00000000b648204f>] kthread+0x1a0/0x1c0 [<0000000072f5ab20>] ret_from_fork+0x35/0x40 [<000000001d5c05d8>] 0xffffffffffffffff Below is the log sequence which leads to memory leak. Here we get the nested "Received PLOGI request" for same port and this request leads to call the fc_rport_create() twice for the same rport. kernel: host1: rport fffce5: Received PLOGI request kernel: host1: rport fffce5: Received PLOGI in INIT state kernel: host1: rport fffce5: Port is Ready kernel: host1: rport fffce5: Received PRLI request while in state Ready kernel: host1: rport fffce5: PRLI rspp type 8 active 1 passive 0 kernel: host1: rport fffce5: Received LOGO request while in state Ready kernel: host1: rport fffce5: Delete port kernel: host1: rport fffce5: Received PLOGI request kernel: host1: rport fffce5: Received PLOGI in state Delete - send busy Link: https://lore.kernel.org/r/20200622101212.3922-2-jhasan@marvell.com Reviewed-by: Girish Basrur Reviewed-by: Saurav Kashyap Reviewed-by: Shyam Sundar Signed-off-by: Javed Hasan Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 2ad1397c88158150bc0572ffad4a190e1a37f394 Author: Markus Theil Date: Wed Jun 17 10:26:36 2020 +0200 mac80211: skip mpath lookup also for control port tx [ Upstream commit 5af7fef39d7952c0f5551afa7b821ee7b6c9dd3d ] When using 802.1X over mesh networks, at first an ordinary mesh peering is established, then the 802.1X EAPOL dialog happens, afterwards an authenticated mesh peering exchange (AMPE) happens, finally the peering is complete and we can set the STA authorized flag. As 802.1X is an intermediate step here and key material is not yet exchanged for stations we have to skip mesh path lookup for these EAPOL frames. Otherwise the already configure mesh group encryption key would be used to send a mesh path request which no one can decipher, because we didn't already establish key material on both peers, like with SAE and directly using AMPE. Signed-off-by: Markus Theil Link: https://lore.kernel.org/r/20200617082637.22670-2-markus.theil@tu-ilmenau.de [remove pointless braces, remove unnecessary local variable, the list can only process one such frame (or its fragments)] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 8bfd43a5180f697345116212bc1ba98da0efc315 Author: Sagi Grimberg Date: Wed Jun 24 01:53:08 2020 -0700 nvme: fix possible deadlock when I/O is blocked [ Upstream commit 3b4b19721ec652ad2c4fe51dfbe5124212b5f581 ] Revert fab7772bfbcf ("nvme-multipath: revalidate nvme_ns_head gendisk in nvme_validate_ns") When adding a new namespace to the head disk (via nvme_mpath_set_live) we will see partition scan which triggers I/O on the mpath device node. This process will usually be triggered from the scan_work which holds the scan_lock. If I/O blocks (if we got ana change currently have only available paths but none are accessible) this can deadlock on the head disk bd_mutex as both partition scan I/O takes it, and head disk revalidation takes it to check for resize (also triggered from scan_work on a different path). See trace [1]. The mpath disk revalidation was originally added to detect online disk size change, but this is no longer needed since commit cb224c3af4df ("nvme: Convert to use set_capacity_revalidate_and_notify") which already updates resize info without unnecessarily revalidating the disk (the mpath disk doesn't even implement .revalidate_disk fop). [1]: -- kernel: INFO: task kworker/u65:9:494 blocked for more than 241 seconds. kernel: Tainted: G OE 5.3.5-050305-generic #201910071830 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kernel: kworker/u65:9 D 0 494 2 0x80004000 kernel: Workqueue: nvme-wq nvme_scan_work [nvme_core] kernel: Call Trace: kernel: __schedule+0x2b9/0x6c0 kernel: schedule+0x42/0xb0 kernel: schedule_preempt_disabled+0xe/0x10 kernel: __mutex_lock.isra.0+0x182/0x4f0 kernel: __mutex_lock_slowpath+0x13/0x20 kernel: mutex_lock+0x2e/0x40 kernel: revalidate_disk+0x63/0xa0 kernel: __nvme_revalidate_disk+0xfe/0x110 [nvme_core] kernel: nvme_revalidate_disk+0xa4/0x160 [nvme_core] kernel: ? evict+0x14c/0x1b0 kernel: revalidate_disk+0x2b/0xa0 kernel: nvme_validate_ns+0x49/0x940 [nvme_core] kernel: ? blk_mq_free_request+0xd2/0x100 kernel: ? __nvme_submit_sync_cmd+0xbe/0x1e0 [nvme_core] kernel: nvme_scan_work+0x24f/0x380 [nvme_core] kernel: process_one_work+0x1db/0x380 kernel: worker_thread+0x249/0x400 kernel: kthread+0x104/0x140 kernel: ? process_one_work+0x380/0x380 kernel: ? kthread_park+0x80/0x80 kernel: ret_from_fork+0x1f/0x40 ... kernel: INFO: task kworker/u65:1:2630 blocked for more than 241 seconds. kernel: Tainted: G OE 5.3.5-050305-generic #201910071830 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kernel: kworker/u65:1 D 0 2630 2 0x80004000 kernel: Workqueue: nvme-wq nvme_scan_work [nvme_core] kernel: Call Trace: kernel: __schedule+0x2b9/0x6c0 kernel: schedule+0x42/0xb0 kernel: io_schedule+0x16/0x40 kernel: do_read_cache_page+0x438/0x830 kernel: ? __switch_to_asm+0x34/0x70 kernel: ? file_fdatawait_range+0x30/0x30 kernel: read_cache_page+0x12/0x20 kernel: read_dev_sector+0x27/0xc0 kernel: read_lba+0xc1/0x220 kernel: ? kmem_cache_alloc_trace+0x19c/0x230 kernel: efi_partition+0x1e6/0x708 kernel: ? vsnprintf+0x39e/0x4e0 kernel: ? snprintf+0x49/0x60 kernel: check_partition+0x154/0x244 kernel: rescan_partitions+0xae/0x280 kernel: __blkdev_get+0x40f/0x560 kernel: blkdev_get+0x3d/0x140 kernel: __device_add_disk+0x388/0x480 kernel: device_add_disk+0x13/0x20 kernel: nvme_mpath_set_live+0x119/0x140 [nvme_core] kernel: nvme_update_ns_ana_state+0x5c/0x60 [nvme_core] kernel: nvme_set_ns_ana_state+0x1e/0x30 [nvme_core] kernel: nvme_parse_ana_log+0xa1/0x180 [nvme_core] kernel: ? nvme_update_ns_ana_state+0x60/0x60 [nvme_core] kernel: nvme_mpath_add_disk+0x47/0x90 [nvme_core] kernel: nvme_validate_ns+0x396/0x940 [nvme_core] kernel: ? blk_mq_free_request+0xd2/0x100 kernel: nvme_scan_work+0x24f/0x380 [nvme_core] kernel: process_one_work+0x1db/0x380 kernel: worker_thread+0x249/0x400 kernel: kthread+0x104/0x140 kernel: ? process_one_work+0x380/0x380 kernel: ? kthread_park+0x80/0x80 kernel: ret_from_fork+0x1f/0x40 -- Fixes: fab7772bfbcf ("nvme-multipath: revalidate nvme_ns_head gendisk in nvme_validate_ns") Signed-off-by: Anton Eidelman Signed-off-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 8b85da354c7497796cdb59315ef4bc4ea777833b Author: Zhang Xiaoxu Date: Mon Jun 22 05:30:19 2020 -0400 cifs: Fix double add page to memcg when cifs_readpages [ Upstream commit 95a3d8f3af9b0d63b43f221b630beaab9739d13a ] When xfstests generic/451, there is an BUG at mm/memcontrol.c: page:ffffea000560f2c0 refcount:2 mapcount:0 mapping:000000008544e0ea index:0xf mapping->aops:cifs_addr_ops dentry name:"tst-aio-dio-cycle-write.451" flags: 0x2fffff80000001(locked) raw: 002fffff80000001 ffffc90002023c50 ffffea0005280088 ffff88815cda0210 raw: 000000000000000f 0000000000000000 00000002ffffffff ffff88817287d000 page dumped because: VM_BUG_ON_PAGE(page->mem_cgroup) page->mem_cgroup:ffff88817287d000 ------------[ cut here ]------------ kernel BUG at mm/memcontrol.c:2659! invalid opcode: 0000 [#1] SMP CPU: 2 PID: 2038 Comm: xfs_io Not tainted 5.8.0-rc1 #44 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_ 073836-buildvm-ppc64le-16.ppc.4 RIP: 0010:commit_charge+0x35/0x50 Code: 0d 48 83 05 54 b2 02 05 01 48 89 77 38 c3 48 c7 c6 78 4a ea ba 48 83 05 38 b2 02 05 01 e8 63 0d9 RSP: 0018:ffffc90002023a50 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff88817287d000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88817ac97ea0 RDI: ffff88817ac97ea0 RBP: ffffea000560f2c0 R08: 0000000000000203 R09: 0000000000000005 R10: 0000000000000030 R11: ffffc900020237a8 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000001 R15: ffff88815a1272c0 FS: 00007f5071ab0800(0000) GS:ffff88817ac80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055efcd5ca000 CR3: 000000015d312000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: mem_cgroup_charge+0x166/0x4f0 __add_to_page_cache_locked+0x4a9/0x710 add_to_page_cache_locked+0x15/0x20 cifs_readpages+0x217/0x1270 read_pages+0x29a/0x670 page_cache_readahead_unbounded+0x24f/0x390 __do_page_cache_readahead+0x3f/0x60 ondemand_readahead+0x1f1/0x470 page_cache_async_readahead+0x14c/0x170 generic_file_buffered_read+0x5df/0x1100 generic_file_read_iter+0x10c/0x1d0 cifs_strict_readv+0x139/0x170 new_sync_read+0x164/0x250 __vfs_read+0x39/0x60 vfs_read+0xb5/0x1e0 ksys_pread64+0x85/0xf0 __x64_sys_pread64+0x22/0x30 do_syscall_64+0x69/0x150 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f5071fcb1af Code: Bad RIP value. RSP: 002b:00007ffde2cdb8e0 EFLAGS: 00000293 ORIG_RAX: 0000000000000011 RAX: ffffffffffffffda RBX: 00007ffde2cdb990 RCX: 00007f5071fcb1af RDX: 0000000000001000 RSI: 000055efcd5ca000 RDI: 0000000000000003 RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000001000 R11: 0000000000000293 R12: 0000000000000001 R13: 000000000009f000 R14: 0000000000000000 R15: 0000000000001000 Modules linked in: ---[ end trace 725fa14a3e1af65c ]--- Since commit 3fea5a499d57 ("mm: memcontrol: convert page cache to a new mem_cgroup_charge() API") not cancel the page charge, the pages maybe double add to pagecache: thread1 | thread2 cifs_readpages readpages_get_pages add_to_page_cache_locked(head,index=n)=0 | readpages_get_pages | add_to_page_cache_locked(head,index=n+1)=0 add_to_page_cache_locked(head, index=n+1)=-EEXIST then, will next loop with list head page's index=n+1 and the page->mapping not NULL readpages_get_pages add_to_page_cache_locked(head, index=n+1) commit_charge VM_BUG_ON_PAGE So, we should not do the next loop when any page add to page cache failed. Reported-by: Hulk Robot Signed-off-by: Zhang Xiaoxu Signed-off-by: Steve French Acked-by: Ronnie Sahlberg Signed-off-by: Sasha Levin commit 3bb9b0ad76e56204fc6498b99b7f5676b0aa44fe Author: Alex Williamson Date: Tue Jun 16 15:26:36 2020 -0600 vfio/pci: Clear error and request eventfd ctx after releasing [ Upstream commit 5c5866c593bbd444d0339ede6a8fb5f14ff66d72 ] The next use of the device will generate an underflow from the stale reference. Cc: Qian Cai Fixes: 1518ac272e78 ("vfio/pci: fix memory leaks of eventfd ctx") Reported-by: Daniel Wagner Reviewed-by: Cornelia Huck Tested-by: Daniel Wagner Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 781a4bf652b80766d5e5a4445f3383c5548a48e1 Author: Chuck Lever Date: Tue May 12 17:14:00 2020 -0400 NFS: nfs_xdr_status should record the procedure name [ Upstream commit 5be5945864ea143fda628e8179c8474457af1f43 ] When sunrpc trace points are not enabled, the recorded task ID information alone is not helpful. Signed-off-by: Chuck Lever Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit bc65336acddc2696b25721d52b17c5e4ccb78106 Author: Thomas Gleixner Date: Wed Mar 4 12:49:18 2020 +0100 x86/speculation/mds: Mark mds_user_clear_cpu_buffers() __always_inline [ Upstream commit a7ef9ba986b5fae9d80f8a7b31db0423687efe4e ] Prevent the compiler from uninlining and creating traceable/probable functions as this is invoked _after_ context tracking switched to CONTEXT_USER and rcu idle. Signed-off-by: Thomas Gleixner Reviewed-by: Alexandre Chartre Acked-by: Peter Zijlstra Link: https://lkml.kernel.org/r/20200505134340.902709267@linutronix.de Signed-off-by: Sasha Levin commit c63613b93479bc23810c5efc2ddcd15c70a29fd3 Author: Boris Brezillon Date: Wed Apr 29 09:53:47 2020 -0700 mtd: parser: cmdline: Support MTD names containing one or more colons [ Upstream commit eb13fa0227417e84aecc3bd9c029d376e33474d3 ] Looks like some drivers define MTD names with a colon in it, thus making mtdpart= parsing impossible. Let's fix the parser to gracefully handle that case: the last ':' in a partition definition sequence is considered instead of the first one. Signed-off-by: Boris Brezillon Signed-off-by: Ron Minnich Tested-by: Ron Minnich Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit f7b07311ff0f4bd9f1863022b9434fa1bfdbca34 Author: Madhuparna Bhowmik Date: Thu Jun 4 16:51:21 2020 -0700 rapidio: avoid data race between file operation callbacks and mport_cdev_add(). [ Upstream commit e1c3cdb26ab881b77486dc50370356a349077c74 ] Fields of md(mport_dev) are set after cdev_device_add(). However, the file operation callbacks can be called after cdev_device_add() and therefore accesses to fields of md in the callbacks can race with the rest of the mport_cdev_add() function. One such example is INIT_LIST_HEAD(&md->portwrites) in mport_cdev_add(), the list is initialised after cdev_device_add(). This can race with list_add_tail(&pw_filter->md_node,&md->portwrites) in rio_mport_add_pw_filter() which is called by unlocked_ioctl. To avoid such data races use cdev_device_add() after initializing md. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Madhuparna Bhowmik Signed-off-by: Andrew Morton Acked-by: Alexandre Bounine Cc: Matt Porter Cc: Dan Carpenter Cc: Mike Marshall Cc: Thomas Gleixner Cc: Ira Weiny Cc: Allison Randal Cc: Pavel Andrianov Link: http://lkml.kernel.org/r/20200426112950.1803-1-madhuparnabhowmik10@gmail.com Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 92514a7bb941d208b716faa9afd78279b497a619 Author: Johannes Weiner Date: Wed Jun 3 16:01:28 2020 -0700 mm: memcontrol: fix stat-corrupting race in charge moving [ Upstream commit abb242f57196dbaa108271575353a0453f6834ef ] The move_lock is a per-memcg lock, but the VM accounting code that needs to acquire it comes from the page and follows page->mem_cgroup under RCU protection. That means that the page becomes unlocked not when we drop the move_lock, but when we update page->mem_cgroup. And that assignment doesn't imply any memory ordering. If that pointer write gets reordered against the reads of the page state - page_mapped, PageDirty etc. the state may change while we rely on it being stable and we can end up corrupting the counters. Place an SMP memory barrier to make sure we're done with all page state by the time the new page->mem_cgroup becomes visible. Also replace the open-coded move_lock with a lock_page_memcg() to make it more obvious what we're serializing against. Signed-off-by: Johannes Weiner Signed-off-by: Andrew Morton Reviewed-by: Joonsoo Kim Reviewed-by: Shakeel Butt Cc: Alex Shi Cc: Hugh Dickins Cc: "Kirill A. Shutemov" Cc: Michal Hocko Cc: Roman Gushchin Cc: Balbir Singh Link: http://lkml.kernel.org/r/20200508183105.225460-3-hannes@cmpxchg.org Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit a9e87c5beeb98e9f8830b61b73adb0276115aa2a Author: Qian Cai Date: Mon Jun 1 21:48:40 2020 -0700 mm/swap_state: fix a data race in swapin_nr_pages [ Upstream commit d6c1f098f2a7ba62627c9bc17cda28f534ef9e4a ] "prev_offset" is a static variable in swapin_nr_pages() that can be accessed concurrently with only mmap_sem held in read mode as noticed by KCSAN, BUG: KCSAN: data-race in swap_cluster_readahead / swap_cluster_readahead write to 0xffffffff92763830 of 8 bytes by task 14795 on cpu 17: swap_cluster_readahead+0x2a6/0x5e0 swapin_readahead+0x92/0x8dc do_swap_page+0x49b/0xf20 __handle_mm_fault+0xcfb/0xd70 handle_mm_fault+0xfc/0x2f0 do_page_fault+0x263/0x715 page_fault+0x34/0x40 1 lock held by (dnf)/14795: #0: ffff897bd2e98858 (&mm->mmap_sem#2){++++}-{3:3}, at: do_page_fault+0x143/0x715 do_user_addr_fault at arch/x86/mm/fault.c:1405 (inlined by) do_page_fault at arch/x86/mm/fault.c:1535 irq event stamp: 83493 count_memcg_event_mm+0x1a6/0x270 count_memcg_event_mm+0x119/0x270 __do_softirq+0x365/0x589 irq_exit+0xa2/0xc0 read to 0xffffffff92763830 of 8 bytes by task 1 on cpu 22: swap_cluster_readahead+0xfd/0x5e0 swapin_readahead+0x92/0x8dc do_swap_page+0x49b/0xf20 __handle_mm_fault+0xcfb/0xd70 handle_mm_fault+0xfc/0x2f0 do_page_fault+0x263/0x715 page_fault+0x34/0x40 1 lock held by systemd/1: #0: ffff897c38f14858 (&mm->mmap_sem#2){++++}-{3:3}, at: do_page_fault+0x143/0x715 irq event stamp: 43530289 count_memcg_event_mm+0x1a6/0x270 count_memcg_event_mm+0x119/0x270 __do_softirq+0x365/0x589 irq_exit+0xa2/0xc0 Signed-off-by: Qian Cai Signed-off-by: Andrew Morton Cc: Marco Elver Cc: Hugh Dickins Link: http://lkml.kernel.org/r/20200402213748.2237-1-cai@lca.pw Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 3e4ca8bf580919d73be087c480d11c38ca8139c4 Author: Jeff Layton Date: Fri Mar 20 16:45:45 2020 -0400 ceph: fix potential race in ceph_check_caps [ Upstream commit dc3da0461cc4b76f2d0c5b12247fcb3b520edbbf ] Nothing ensures that session will still be valid by the time we dereference the pointer. Take and put a reference. In principle, we should always be able to get a reference here, but throw a warning if that's ever not the case. Signed-off-by: Jeff Layton Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit dac34dd4efc6c971dd4fbf8f617cb67ba133572c Author: Dinghao Liu Date: Thu May 21 10:47:09 2020 +0800 PCI: tegra: Fix runtime PM imbalance on error [ Upstream commit fcee90cdf6f3a3a371add04d41528d5ba9c3b411 ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Also, call pm_runtime_disable() when pm_runtime_get_sync() returns an error code. Link: https://lore.kernel.org/r/20200521024709.2368-1-dinghao.liu@zju.edu.cn Signed-off-by: Dinghao Liu Signed-off-by: Lorenzo Pieralisi Acked-by: Thierry Reding Signed-off-by: Sasha Levin commit 5cddba546a0061b8f1011c79efb227e38885c5e3 Author: Dinghao Liu Date: Fri May 22 18:40:06 2020 +0800 mtd: rawnand: omap_elm: Fix runtime PM imbalance on error [ Upstream commit 37f7212148cf1d796135cdf8d0c7fee13067674b ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Signed-off-by: Dinghao Liu Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20200522104008.28340-1-dinghao.liu@zju.edu.cn Signed-off-by: Sasha Levin commit 63f600d87b05b69c4ac963898263c5e092f0e76c Author: Dinghao Liu Date: Fri May 22 17:51:39 2020 +0800 mtd: rawnand: gpmi: Fix runtime PM imbalance on error [ Upstream commit 550e68ea36a6671a96576c0531685ce6e6c0d19d ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Signed-off-by: Dinghao Liu Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20200522095139.19653-1-dinghao.liu@zju.edu.cn Signed-off-by: Sasha Levin commit ec705f9ffbbaeead254cfa0b7fd034cf2ddbea0f Author: Dinghao Liu Date: Wed May 20 20:46:47 2020 +0800 wlcore: fix runtime pm imbalance in wlcore_regdomain_config [ Upstream commit 282a04bf1d8029eb98585cb5db3fd70fe8bc91f7 ] pm_runtime_get_sync() increments the runtime PM usage counter even the call returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Signed-off-by: Dinghao Liu Acked-by: Tony Lindgren Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200520124649.10848-1-dinghao.liu@zju.edu.cn Signed-off-by: Sasha Levin commit a0f8499fba8d8138b344bad8cd483729b30a61f2 Author: Dinghao Liu Date: Wed May 20 20:42:38 2020 +0800 wlcore: fix runtime pm imbalance in wl1271_tx_work [ Upstream commit 9604617e998b49f7695fea1479ed82421ef8c9f0 ] There are two error handling paths in this functon. When wlcore_tx_work_locked() returns an error code, we should decrease the runtime PM usage counter the same way as the error handling path beginning from pm_runtime_get_sync(). Signed-off-by: Dinghao Liu Acked-by: Tony Lindgren Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200520124241.9931-1-dinghao.liu@zju.edu.cn Signed-off-by: Sasha Levin commit 7555bb003417e550404269c22b03c5cc27e12f6f Author: Dinghao Liu Date: Fri May 29 09:22:28 2020 +0800 ASoC: img-i2s-out: Fix runtime PM imbalance on error [ Upstream commit 65bd91dd6957390c42a0491b9622cf31a2cdb140 ] pm_runtime_get_sync() increments the runtime PM usage counter even the call returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Signed-off-by: Dinghao Liu Link: https://lore.kernel.org/r/20200529012230.5863-1-dinghao.liu@zju.edu.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 13e1951aa3b8a428d6fdc69b7e01c9804d26f6fc Author: Dinghao Liu Date: Thu May 21 11:13:49 2020 +0800 PCI: tegra194: Fix runtime PM imbalance on error [ Upstream commit 1c1dbb2c02623db18a50c61b175f19aead800b4e ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Link: https://lore.kernel.org/r/20200521031355.7022-1-dinghao.liu@zju.edu.cn Signed-off-by: Dinghao Liu Signed-off-by: Lorenzo Pieralisi Acked-by: Thierry Reding Acked-by: Vidya Sagar Signed-off-by: Sasha Levin commit 7415f52e2e9593cdc5baeeca6788725b56bcba05 Author: Adrian Hunter Date: Tue May 12 15:19:16 2020 +0300 perf kcore_copy: Fix module map when there are no modules loaded [ Upstream commit 61f82e3fb697a8e85f22fdec786528af73dc36d1 ] In the absence of any modules, no "modules" map is created, but there are other executable pages to map, due to eBPF JIT, kprobe or ftrace. Map them by recognizing that the first "module" symbol is not necessarily from a module, and adjust the map accordingly. Signed-off-by: Adrian Hunter Cc: Alexander Shishkin Cc: Borislav Petkov Cc: H. Peter Anvin Cc: Jiri Olsa Cc: Leo Yan Cc: Mark Rutland Cc: Masami Hiramatsu Cc: Mathieu Poirier Cc: Peter Zijlstra Cc: Steven Rostedt (VMware) Cc: x86@kernel.org Link: http://lore.kernel.org/lkml/20200512121922.8997-10-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit ff793fe02ca89d737217b2c20cd042382b7007c8 Author: Ian Rogers Date: Thu May 7 22:36:24 2020 -0700 perf metricgroup: Free metric_events on error [ Upstream commit a159e2fe89b4d1f9fb54b0ae418b961e239bf617 ] Avoid a simple memory leak. Signed-off-by: Ian Rogers Cc: Alexander Shishkin Cc: Alexei Starovoitov Cc: Andi Kleen Cc: Andrii Nakryiko Cc: Cong Wang Cc: Daniel Borkmann Cc: Jin Yao Cc: Jiri Olsa Cc: John Fastabend Cc: John Garry Cc: Kajol Jain Cc: Kan Liang Cc: Kim Phillips Cc: Mark Rutland Cc: Martin KaFai Lau Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Song Liu Cc: Stephane Eranian Cc: Vince Weaver Cc: Yonghong Song Cc: bpf@vger.kernel.org Cc: kp singh Cc: netdev@vger.kernel.org Link: http://lore.kernel.org/lkml/20200508053629.210324-10-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 2076ee4ae51253e2294955881b02517edb3c94bd Author: Xie XiuQi Date: Thu May 21 21:32:17 2020 +0800 perf util: Fix memory leak of prefix_if_not_in [ Upstream commit 07e9a6f538cbeecaf5c55b6f2991416f873cdcbd ] Need to free "str" before return when asprintf() failed to avoid memory leak. Signed-off-by: Xie XiuQi Cc: Alexander Shishkin Cc: Hongbo Yao Cc: Jiri Olsa Cc: Li Bin Cc: Mark Rutland Cc: Namhyung Kim Link: http://lore.kernel.org/lkml/20200521133218.30150-4-liwei391@huawei.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit b10dd4b3c1040972f6274a88df8cea045848046e Author: Jiri Olsa Date: Mon May 18 15:14:45 2020 +0200 perf stat: Fix duration_time value for higher intervals [ Upstream commit ea9eb1f456a08c18feb485894185f7a4e31cc8a4 ] Joakim reported wrong duration_time value for interval bigger than 4000 [1]. The problem is in the interval value we pass to update_stats function, which is typed as 'unsigned int' and overflows when we get over 2^32 (happens between intervals 4000 and 5000). Retyping the passed value to unsigned long long. [1] https://www.spinics.net/lists/linux-perf-users/msg11777.html Fixes: b90f1333ef08 ("perf stat: Update walltime_nsecs_stats in interval mode") Reported-by: Joakim Zhang Signed-off-by: Jiri Olsa Cc: Alexander Shishkin Cc: Andi Kleen Cc: Michael Petlan Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20200518131445.3745083-1-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit eddcc70de8da9f1e9442ae6ad285dec61e1a0a6c Author: Ian Rogers Date: Thu Mar 5 23:11:10 2020 -0800 perf trace: Fix the selection for architectures to generate the errno name tables [ Upstream commit 7597ce89b3ed239f7a3408b930d2a6c7a4c938a1 ] Make the architecture test directory agree with the code comment. Committer notes: This was split from a larger patch. The code was assuming the developer always worked from tools/perf/, so make sure we do the test -d having $toolsdir/perf/arch/$arch, to match the intent expressed in the comment, just above that loop. Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Alexios Zavras Cc: Andi Kleen Cc: Greg Kroah-Hartman Cc: Igor Lubashev Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Mathieu Poirier Cc: Namhyung Kim Cc: Nick Desaulniers Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Wei Li Link: http://lore.kernel.org/lkml/20200306071110.130202-4-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit feaaa88ffce784cfc044162a7ed144fa4e392d72 Author: Ian Rogers Date: Tue May 12 16:59:18 2020 -0700 perf evsel: Fix 2 memory leaks [ Upstream commit 3efc899d9afb3d03604f191a0be9669eabbfc4aa ] If allocated, perf_pkg_mask and metric_events need freeing. Signed-off-by: Ian Rogers Reviewed-by: Andi Kleen Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Stephane Eranian Link: http://lore.kernel.org/lkml/20200512235918.10732-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit ad9940e377fd6471766ad9f9883368ce14a5ad7a Author: Paul Mackerras Date: Thu May 28 10:56:42 2020 +1000 KVM: PPC: Book3S HV: Close race with page faults around memslot flushes [ Upstream commit 11362b1befeadaae4d159a8cddcdaf6b8afe08f9 ] There is a potential race condition between hypervisor page faults and flushing a memslot. It is possible for a page fault to read the memslot before a memslot is updated and then write a PTE to the partition-scoped page tables after kvmppc_radix_flush_memslot has completed. (Note that this race has never been explicitly observed.) To close this race, it is sufficient to increment the MMU sequence number while the kvm->mmu_lock is held. That will cause mmu_notifier_retry() to return true, and the page fault will then return to the guest without inserting a PTE. Signed-off-by: Paul Mackerras Signed-off-by: Sasha Levin commit f9c47a0cc513bd16106b48ef0ed697b5235b2dec Author: Qian Cai Date: Mon May 11 00:34:50 2020 -0400 vfio/pci: fix memory leaks of eventfd ctx [ Upstream commit 1518ac272e789cae8c555d69951b032a275b7602 ] Finished a qemu-kvm (-device vfio-pci,host=0001:01:00.0) triggers a few memory leaks after a while because vfio_pci_set_ctx_trigger_single() calls eventfd_ctx_fdget() without the matching eventfd_ctx_put() later. Fix it by calling eventfd_ctx_put() for those memory in vfio_pci_release() before vfio_device_release(). unreferenced object 0xebff008981cc2b00 (size 128): comm "qemu-kvm", pid 4043, jiffies 4294994816 (age 9796.310s) hex dump (first 32 bytes): 01 00 00 00 6b 6b 6b 6b 00 00 00 00 ad 4e ad de ....kkkk.....N.. ff ff ff ff 6b 6b 6b 6b ff ff ff ff ff ff ff ff ....kkkk........ backtrace: [<00000000917e8f8d>] slab_post_alloc_hook+0x74/0x9c [<00000000df0f2aa2>] kmem_cache_alloc_trace+0x2b4/0x3d4 [<000000005fcec025>] do_eventfd+0x54/0x1ac [<0000000082791a69>] __arm64_sys_eventfd2+0x34/0x44 [<00000000b819758c>] do_el0_svc+0x128/0x1dc [<00000000b244e810>] el0_sync_handler+0xd0/0x268 [<00000000d495ef94>] el0_sync+0x164/0x180 unreferenced object 0x29ff008981cc4180 (size 128): comm "qemu-kvm", pid 4043, jiffies 4294994818 (age 9796.290s) hex dump (first 32 bytes): 01 00 00 00 6b 6b 6b 6b 00 00 00 00 ad 4e ad de ....kkkk.....N.. ff ff ff ff 6b 6b 6b 6b ff ff ff ff ff ff ff ff ....kkkk........ backtrace: [<00000000917e8f8d>] slab_post_alloc_hook+0x74/0x9c [<00000000df0f2aa2>] kmem_cache_alloc_trace+0x2b4/0x3d4 [<000000005fcec025>] do_eventfd+0x54/0x1ac [<0000000082791a69>] __arm64_sys_eventfd2+0x34/0x44 [<00000000b819758c>] do_el0_svc+0x128/0x1dc [<00000000b244e810>] el0_sync_handler+0xd0/0x268 [<00000000d495ef94>] el0_sync+0x164/0x180 Signed-off-by: Qian Cai Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit bb6e9827da759c84a763899f03e88621bdcf5ebc Author: Dinghao Liu Date: Fri May 22 16:08:38 2020 +0800 gpio: rcar: Fix runtime PM imbalance on error [ Upstream commit 6f8cd246411575703d9312888b70705c396b53a9 ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Signed-off-by: Dinghao Liu Link: https://lore.kernel.org/r/20200522080839.32612-1-dinghao.liu@zju.edu.cn Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 1aa9de56d7626342343fa2d93a6923a6142c737e Author: Omar Sandoval Date: Thu Apr 16 14:46:13 2020 -0700 btrfs: fix double __endio_write_update_ordered in direct I/O [ Upstream commit c36cac28cb94e58f7e21ff43bdc6064346dab32c ] In btrfs_submit_direct(), if we fail to allocate the btrfs_dio_private, we complete the ordered extent range. However, we don't mark that the range doesn't need to be cleaned up from btrfs_direct_IO() until later. Therefore, if we fail to allocate the btrfs_dio_private, we complete the ordered extent range twice. We could fix this by updating unsubmitted_oe_range earlier, but it's cleaner to reorganize the code so that creating the btrfs_dio_private and submitting the bios are separate, and once the btrfs_dio_private is created, cleanup always happens through the btrfs_dio_private. The logic around unsubmitted_oe_range_end and unsubmitted_oe_range_start is really subtle. We have the following: 1. btrfs_direct_IO sets those two to the same value. 2. When we call __blockdev_direct_IO unless btrfs_get_blocks_direct->btrfs_get_blocks_direct_write is called to modify unsubmitted_oe_range_start so that start < end. Cleanup won't happen. 3. We come into btrfs_submit_direct - if it dip allocation fails we'd return with oe_range_end now modified so cleanup will happen. 4. If we manage to allocate the dip we reset the unsubmitted range members to be equal so that cleanup happens from btrfs_endio_direct_write. This 4-step logic is not really obvious, especially given it's scattered across 3 functions. Fixes: f28a49287817 ("Btrfs: fix leaking of ordered extents after direct IO write error") Reviewed-by: Johannes Thumshirn Reviewed-by: Nikolay Borisov Signed-off-by: Omar Sandoval [ add range start/end logic explanation from Nikolay ] Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit b3b21823d68e7e4b43201953cc500b02ab027034 Author: David Sterba Date: Tue Feb 25 15:05:53 2020 +0100 btrfs: don't force read-only after error in drop snapshot [ Upstream commit 7c09c03091ac562ddca2b393e5d65c1d37da79f1 ] Deleting a subvolume on a full filesystem leads to ENOSPC followed by a forced read-only. This is not a transaction abort and the filesystem is otherwise ok, so the error should be just propagated to the callers. This is caused by unnecessary call to btrfs_handle_fs_error for all errors, except EAGAIN. This does not make sense as the standard transaction abort mechanism is in btrfs_drop_snapshot so all relevant failures are handled. Originally in commit cb1b69f4508a ("Btrfs: forced readonly when btrfs_drop_snapshot() fails") there was no return value at all, so the btrfs_std_error made some sense but once the error handling and propagation has been implemented we don't need it anymore. Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 859748f8cd8c13ab4a1a02e7b165f0b431ef7b97 Author: Yu Chen Date: Thu May 21 16:46:43 2020 +0800 usb: dwc3: Increase timeout for CmdAct cleared by device controller [ Upstream commit 1c0e69ae1b9f9004fd72978612ae3463791edc56 ] If the SS PHY is in P3, there is no pipe_clk, HW may use suspend_clk for function, as suspend_clk is slow so EP command need more time to complete, e.g, imx8M suspend_clk is 32K, set ep configuration will take about 380us per below trace time stamp(44.286278 - 44.285897 = 0.000381): configfs_acm.sh-822 [000] d..1 44.285896: dwc3_writel: addr 000000006d59aae1 value 00000401 configfs_acm.sh-822 [000] d..1 44.285897: dwc3_readl: addr 000000006d59aae1 value 00000401 ... ... configfs_acm.sh-822 [000] d..1 44.286278: dwc3_readl: addr 000000006d59aae1 value 00000001 configfs_acm.sh-822 [000] d..1 44.286279: dwc3_gadget_ep_cmd: ep0out: cmd 'Set Endpoint Configuration' [401] params 00001000 00000500 00000000 --> status: Successful This was originally found on Hisilicon Kirin Soc that need more time for the device controller to clear the CmdAct of DEPCMD. Signed-off-by: Yu Chen Signed-off-by: John Stultz Signed-off-by: Li Jun Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 5c7f727e8ad67cd36ecf1802387cd0936edf32e4 Author: Shreyas Joshi Date: Fri May 22 16:53:06 2020 +1000 printk: handle blank console arguments passed in. [ Upstream commit 48021f98130880dd74286459a1ef48b5e9bc374f ] If uboot passes a blank string to console_setup then it results in a trashed memory. Ultimately, the kernel crashes during freeing up the memory. This fix checks if there is a blank parameter being passed to console_setup from uboot. In case it detects that the console parameter is blank then it doesn't setup the serial device and it gracefully exits. Link: https://lore.kernel.org/r/20200522065306.83-1-shreyas.joshi@biamp.com Signed-off-by: Shreyas Joshi Acked-by: Sergey Senozhatsky [pmladek@suse.com: Better format the commit message and code, remove unnecessary brackets.] Signed-off-by: Petr Mladek Signed-off-by: Sasha Levin commit 482466b67d87ccd4b9a1d9569d5086d68a7fee7d Author: Dinghao Liu Date: Wed May 20 18:47:48 2020 +0800 drm/nouveau/dispnv50: fix runtime pm imbalance on error [ Upstream commit dc455f4c888365595c0a13da445e092422d55b8d ] pm_runtime_get_sync() increments the runtime PM usage counter even the call returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Signed-off-by: Dinghao Liu Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit bd39447bad06e9623ce75f3edb3c96f9b00862b1 Author: Dinghao Liu Date: Wed May 20 18:25:49 2020 +0800 drm/nouveau: fix runtime pm imbalance on error [ Upstream commit d7372dfb3f7f1602b87e0663e8b8646da23ebca7 ] pm_runtime_get_sync() increments the runtime PM usage counter even the call returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Signed-off-by: Dinghao Liu Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit f6331bfcccc890b5c46bfe0a21debbf5c7ff2c21 Author: Dinghao Liu Date: Wed May 20 18:14:53 2020 +0800 drm/nouveau/debugfs: fix runtime pm imbalance on error [ Upstream commit 00583fbe8031f69bba8b0a9a861efb75fb7131af ] pm_runtime_get_sync() increments the runtime PM usage counter even the call returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Signed-off-by: Dinghao Liu Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit 2477158bfd3e7ef4976e4a2e29964564199d7185 Author: Alexander Duyck Date: Fri Apr 17 09:35:31 2020 -0700 e1000: Do not perform reset in reset_task if we are already down [ Upstream commit 49ee3c2ab5234757bfb56a0b3a3cb422f427e3a3 ] We are seeing a deadlock in e1000 down when NAPI is being disabled. Looking over the kernel function trace of the system it appears that the interface is being closed and then a reset is hitting which deadlocks the interface as the NAPI interface is already disabled. To prevent this from happening I am disabling the reset task when __E1000_DOWN is already set. In addition code has been added so that we set the __E1000_DOWN while holding the __E1000_RESET flag in e1000_close in order to guarantee that the reset task will not run after we have started the close call. Signed-off-by: Alexander Duyck Tested-by: Maxim Zhukov Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 62962e08b9c33adec71340bf1eb3429702e20457 Author: Philip Yang Date: Thu May 21 09:56:58 2020 -0400 drm/amdkfd: fix restore worker race condition [ Upstream commit f7646585a30ed8ef5ab300d4dc3b0c1d6afbe71d ] In free memory of gpu path, remove bo from validate_list to make sure restore worker don't access the BO any more, then unregister bo MMU interval notifier. Otherwise, the restore worker will crash in the middle of validating BO user pages if MMU interval notifer is gone. Signed-off-by: Philip Yang Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 180e60f154a3b45e0c11b7ed9f1fa0edc9e345ce Author: Anshuman Khandual Date: Tue May 19 15:10:39 2020 +0530 arm64/cpufeature: Drop TraceFilt feature exposure from ID_DFR0 register [ Upstream commit 1ed1b90a0594c8c9d31e8bb8be25a2b37717dc9e ] ID_DFR0 based TraceFilt feature should not be exposed to guests. Hence lets drop it. Cc: Catalin Marinas Cc: Will Deacon Cc: Marc Zyngier Cc: Mark Rutland Cc: James Morse Cc: Suzuki K Poulose Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Suggested-by: Mark Rutland Signed-off-by: Anshuman Khandual Reviewed-by: Suzuki K Poulose Link: https://lore.kernel.org/r/1589881254-10082-3-git-send-email-anshuman.khandual@arm.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 196d14cea6a3031a8d25a3ed5db3d93b95656f40 Author: Wei Yongjun Date: Tue Apr 28 14:18:55 2020 +0000 scsi: cxlflash: Fix error return code in cxlflash_probe() [ Upstream commit d0b1e4a638d670a09f42017a3e567dc846931ba8 ] Fix to return negative error code -ENOMEM from create_afu error handling case instead of 0, as done elsewhere in this function. Link: https://lore.kernel.org/r/20200428141855.88704-1-weiyongjun1@huawei.com Acked-by: Matthew R. Ochs Signed-off-by: Wei Yongjun Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit af02933d59bd1621a48d8b0b331cca9e530ba14b Author: James Morse Date: Fri May 1 17:45:43 2020 +0100 arm64: acpi: Make apei_claim_sea() synchronise with APEI's irq work [ Upstream commit 8fcc4ae6faf8b455eeef00bc9ae70744e3b0f462 ] APEI is unable to do all of its error handling work in nmi-context, so it defers non-fatal work onto the irq_work queue. arch_irq_work_raise() sends an IPI to the calling cpu, but this is not guaranteed to be taken before returning to user-space. Unless the exception interrupted a context with irqs-masked, irq_work_run() can run immediately. Otherwise return -EINPROGRESS to indicate ghes_notify_sea() found some work to do, but it hasn't finished yet. With this apei_claim_sea() returning '0' means this external-abort was also notification of a firmware-first RAS error, and that APEI has processed the CPER records. Signed-off-by: James Morse Tested-by: Tyler Baicar Acked-by: Catalin Marinas Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 502bd98a8e279a7645d580724a45132b6039aa1b Author: Suzuki K Poulose Date: Mon May 18 12:02:40 2020 -0600 coresight: etm4x: Fix use-after-free of per-cpu etm drvdata [ Upstream commit 3f4943d422c5febbb3c764670011a00eb2a86238 ] etm probe could be deferred due to the dependency in the trace path chain and may be retried. We need to clear the per-cpu etmdrvdata entry for the etm in case of a failure to avoid use-after-free cases as reported below: KASAN use-after-free bug in etm4_cpu_pm_notify(): [ 8.574566] coresight etm0: CPU0: ETM v4.2 initialized [ 8.581920] BUG: KASAN: use-after-free in etm4_cpu_pm_notify+0x580/0x2024 [ 8.581925] Read of size 8 at addr ffffff813304f8c8 by task swapper/3/0 [ 8.581927] [ 8.581934] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G S W 5.4.28 #314 [ 8.587775] coresight etm1: CPU1: ETM v4.2 initialized [ 8.594195] Call trace: [ 8.594205] dump_backtrace+0x0/0x188 [ 8.594209] show_stack+0x20/0x2c [ 8.594216] dump_stack+0xdc/0x144 [ 8.594227] print_address_description+0x3c/0x494 [ 8.594232] __kasan_report+0x144/0x168 [ 8.601598] coresight etm2: CPU2: ETM v4.2 initialized [ 8.602563] kasan_report+0x10/0x18 [ 8.602568] check_memory_region+0x1a4/0x1b4 [ 8.602572] __kasan_check_read+0x18/0x24 [ 8.602577] etm4_cpu_pm_notify+0x580/0x2024 [ 8.665945] notifier_call_chain+0x5c/0x90 [ 8.670166] __atomic_notifier_call_chain+0x90/0xf8 [ 8.675182] cpu_pm_notify+0x40/0x6c [ 8.678858] cpu_pm_enter+0x38/0x80 [ 8.682451] psci_enter_idle_state+0x34/0x70 [ 8.686844] cpuidle_enter_state+0xb8/0x20c [ 8.691143] cpuidle_enter+0x38/0x4c [ 8.694820] call_cpuidle+0x3c/0x68 [ 8.698408] do_idle+0x1a0/0x280 [ 8.701729] cpu_startup_entry+0x24/0x28 [ 8.705768] secondary_start_kernel+0x15c/0x170 [ 8.710423] [ 8.711972] Allocated by task 242: [ 8.715473] __kasan_kmalloc+0xf0/0x1ac [ 8.719426] kasan_slab_alloc+0x14/0x1c [ 8.723375] __kmalloc_track_caller+0x23c/0x388 [ 8.728040] devm_kmalloc+0x38/0x94 [ 8.731632] etm4_probe+0x48/0x3c8 [ 8.735140] amba_probe+0xbc/0x158 [ 8.738645] really_probe+0x144/0x408 [ 8.742412] driver_probe_device+0x70/0x140 [ 8.746716] __device_attach_driver+0x9c/0x110 [ 8.751287] bus_for_each_drv+0x90/0xd8 [ 8.755236] __device_attach+0xb4/0x164 [ 8.759188] device_initial_probe+0x20/0x2c [ 8.763490] bus_probe_device+0x34/0x94 [ 8.767436] device_add+0x34c/0x3e0 [ 8.771029] amba_device_try_add+0x68/0x440 [ 8.775332] amba_deferred_retry_func+0x48/0xc8 [ 8.779997] process_one_work+0x344/0x648 [ 8.784127] worker_thread+0x2ac/0x47c [ 8.787987] kthread+0x128/0x138 [ 8.791313] ret_from_fork+0x10/0x18 [ 8.794993] [ 8.796532] Freed by task 242: [ 8.799684] __kasan_slab_free+0x15c/0x22c [ 8.803897] kasan_slab_free+0x10/0x1c [ 8.807761] kfree+0x25c/0x4bc [ 8.810913] release_nodes+0x240/0x2b0 [ 8.814767] devres_release_all+0x3c/0x54 [ 8.818887] really_probe+0x178/0x408 [ 8.822661] driver_probe_device+0x70/0x140 [ 8.826963] __device_attach_driver+0x9c/0x110 [ 8.831539] bus_for_each_drv+0x90/0xd8 [ 8.835487] __device_attach+0xb4/0x164 [ 8.839431] device_initial_probe+0x20/0x2c [ 8.843732] bus_probe_device+0x34/0x94 [ 8.847678] device_add+0x34c/0x3e0 [ 8.851274] amba_device_try_add+0x68/0x440 [ 8.855576] amba_deferred_retry_func+0x48/0xc8 [ 8.860240] process_one_work+0x344/0x648 [ 8.864366] worker_thread+0x2ac/0x47c [ 8.868228] kthread+0x128/0x138 [ 8.871557] ret_from_fork+0x10/0x18 [ 8.875231] [ 8.876782] The buggy address belongs to the object at ffffff813304f800 [ 8.876782] which belongs to the cache kmalloc-1k of size 1024 [ 8.889632] The buggy address is located 200 bytes inside of [ 8.889632] 1024-byte region [ffffff813304f800, ffffff813304fc00) [ 8.901761] The buggy address belongs to the page: [ 8.906695] page:ffffffff04ac1200 refcount:1 mapcount:0 mapping:ffffff8146c03800 index:0x0 compound_mapcount: 0 [ 8.917047] flags: 0x4000000000010200(slab|head) [ 8.921799] raw: 4000000000010200 dead000000000100 dead000000000122 ffffff8146c03800 [ 8.929753] raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 [ 8.937703] page dumped because: kasan: bad access detected [ 8.943433] [ 8.944974] Memory state around the buggy address: [ 8.949903] ffffff813304f780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 8.957320] ffffff813304f800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 8.964742] >ffffff813304f880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 8.972157] ^ [ 8.977886] ffffff813304f900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 8.985298] ffffff813304f980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 8.992713] ================================================================== Fixes: f188b5e76aae ("coresight: etm4x: Save/restore state across CPU low power states") Reported-by: Sai Prakash Ranjan Tested-by: Sai Prakash Ranjan Cc: Mathieu Poirier Cc: Mike Leach Signed-off-by: Suzuki K Poulose Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200518180242.7916-22-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c3fa2949c2727f202cb9cca4966198b6378ef38f Author: Colin Ian King Date: Fri May 15 17:54:53 2020 +0100 USB: EHCI: ehci-mv: fix less than zero comparison of an unsigned int [ Upstream commit a7f40c233a6b0540d28743267560df9cfb571ca9 ] The comparison of hcd->irq to less than zero for an error check will never be true because hcd->irq is an unsigned int. Fix this by assigning the int retval to the return of platform_get_irq and checking this for the -ve error condition and assigning hcd->irq to retval. Addresses-Coverity: ("Unsigned compared against 0") Fixes: c856b4b0fdb5 ("USB: EHCI: ehci-mv: fix error handling in mv_ehci_probe()") Signed-off-by: Colin Ian King Link: https://lore.kernel.org/r/20200515165453.104028-1-colin.king@canonical.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 89e6cf1c0ab5590ff134d89ac6c9b892d818d097 Author: Miklos Szeredi Date: Tue May 19 14:50:38 2020 +0200 fuse: update attr_version counter on fuse_notify_inval_inode() [ Upstream commit 5ddd9ced9aef6cfa76af27d384c17c9e2d610ce8 ] A GETATTR request can race with FUSE_NOTIFY_INVAL_INODE, resulting in the attribute cache being updated with stale information after the invalidation. Fix this by bumping the attribute version in fuse_reverse_inval_inode(). Reported-by: Krzysztof Rusek Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit e431e923c8a6d65ff40f764f43edf7e2c3798316 Author: Miklos Szeredi Date: Tue May 19 14:50:37 2020 +0200 fuse: don't check refcount after stealing page [ Upstream commit 32f98877c57bee6bc27f443a96f49678a2cd6a50 ] page_count() is unstable. Unless there has been an RCU grace period between when the page was removed from the page cache and now, a speculative reference may exist from the page cache. Reported-by: Matthew Wilcox Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 55c3e7fac92eb82c72b2713a565be09ac235a8a5 Author: Chuck Lever Date: Fri Mar 20 17:32:41 2020 -0400 svcrdma: Fix backchannel return code [ Upstream commit ea740bd5f58e2912e74f401fd01a9d6aa985ca05 ] Way back when I was writing the RPC/RDMA server-side backchannel code, I misread the TCP backchannel reply handler logic. When svc_tcp_recvfrom() successfully receives a backchannel reply, it does not return -EAGAIN. It sets XPT_DATA and returns zero. Update svc_rdma_recvfrom() to return zero. Here, XPT_DATA doesn't need to be set again: it is set whenever a new message is received, behind a spin lock in a single threaded context. Also, if handling the cb reply is not successful, the message is simply dropped. There's no special message framing to deal with as there is in the TCP case. Now that the handle_bc_reply() return value is ignored, I've removed the dprintk call sites in the error exit of handle_bc_reply() in favor of trace points in other areas that already report the error cases. Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 7c972122cab5173ec8eb4379e2f50cf0bfa0e8b1 Author: Nicholas Piggin Date: Fri May 8 14:34:07 2020 +1000 powerpc/traps: Make unrecoverable NMIs die instead of panic [ Upstream commit 265d6e588d87194c2fe2d6c240247f0264e0c19b ] System Reset and Machine Check interrupts that are not recoverable due to being nested or interrupting when RI=0 currently panic. This is not necessary, and can often just kill the current context and recover. Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Reviewed-by: Christophe Leroy Link: https://lore.kernel.org/r/20200508043408.886394-16-npiggin@gmail.com Signed-off-by: Sasha Levin commit 004cb15b1e4cdca29cdf4c473ba6e2004e59f3b4 Author: Tang Bin Date: Tue May 5 18:29:06 2020 +0800 ipmi:bt-bmc: Fix error handling and status check [ Upstream commit 49826937e7c7917140515aaf10c17bedcc4acaad ] If the function platform_get_irq() failed, the negative value returned will not be detected here. So fix error handling in bt_bmc_config_irq(). And in the function bt_bmc_probe(), when get irq failed, it will print error message. So use platform_get_irq_optional() to simplify code. Finally in the function bt_bmc_remove() should make the right status check if get irq failed. Signed-off-by: Shengju Zhang Signed-off-by: Tang Bin Message-Id: <20200505102906.17196-1-tangbin@cmss.chinamobile.com> [Also set bt_bmc->irq to a negative value if devm_request_irq() fails.] Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin commit 09197d39cab312728ed09cc10f5e854c3adefcb0 Author: Christophe JAILLET Date: Sat May 16 12:57:36 2020 +0200 drm/exynos: dsi: Remove bridge node reference in error handling path in probe function [ Upstream commit 547a7348633b1f9923551f94ac3157a613d2c9f2 ] 'exynos_dsi_parse_dt()' takes a reference to 'dsi->in_bridge_node'. This must be released in the error handling path. In order to do that, add an error handling path and move the 'exynos_dsi_parse_dt()' call from the beginning to the end of the probe function to ease the error handling path. This function only sets some variables which are used only in the 'transfer' function. The call chain is: .transfer --> exynos_dsi_host_transfer --> exynos_dsi_init --> exynos_dsi_enable_clock (use burst_clk_rate and esc_clk_rate) --> exynos_dsi_set_pll (use pll_clk_rate) While at it, also handle cases where 'component_add()' fails. This patch is similar to commit 70505c2ef94b ("drm/exynos: dsi: Remove bridge node reference in removal") which fixed the issue in the remove function. Signed-off-by: Christophe JAILLET Signed-off-by: Inki Dae Signed-off-by: Sasha Levin commit 7ce7dd0a6f1db28cffdd94985a6a25ca638f68a9 Author: Takashi Iwai Date: Sat May 16 08:25:56 2020 +0200 ALSA: hda: Fix potential race in unsol event handler [ Upstream commit c637fa151259c0f74665fde7cba5b7eac1417ae5 ] The unsol event handling code has a loop retrieving the read/write indices and the arrays without locking while the append to the array may happen concurrently. This may lead to some inconsistency. Although there hasn't been any proof of this bad results, it's still safer to protect the racy accesses. This patch adds the spinlock protection around the unsol handling loop for addressing it. Here we take bus->reg_lock as the writer side snd_hdac_bus_queue_event() is also protected by that lock. Link: https://lore.kernel.org/r/20200516062556.30951-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 942a6ff2146a9d65ba3c13822143827c6ad31d59 Author: Jonathan Bakker Date: Fri May 8 18:34:33 2020 -0700 tty: serial: samsung: Correct clock selection logic [ Upstream commit 7d31676a8d91dd18e08853efd1cb26961a38c6a6 ] Some variants of the samsung tty driver can pick which clock to use for their baud rate generation. In the DT conversion, a default clock was selected to be used if a specific one wasn't assigned and then a comparison of which clock rate worked better was done. Unfortunately, the comparison was implemented in such a way that only the default clock was ever actually compared. Fix this by iterating through all possible clocks, except when a specific clock has already been picked via clk_sel (which is only possible via board files). Signed-off-by: Jonathan Bakker Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/BN6PR04MB06604E63833EA41837EBF77BA3A30@BN6PR04MB0660.namprd04.prod.outlook.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 202ae05859eaac9c84cbbcb3bb73fbb46ddd0829 Author: Tuong Lien Date: Wed May 13 19:33:17 2020 +0700 tipc: fix memory leak in service subscripting [ Upstream commit 0771d7df819284d46cf5cfb57698621b503ec17f ] Upon receipt of a service subscription request from user via a topology connection, one 'sub' object will be allocated in kernel, so it will be able to send an event of the service if any to the user correspondingly then. Also, in case of any failure, the connection will be shutdown and all the pertaining 'sub' objects will be freed. However, there is a race condition as follows resulting in memory leak: receive-work connection send-work | | | sub-1 |<------//-------| | sub-2 |<------//-------| | | |<---------------| evt for sub-x sub-3 |<------//-------| | : : : : : : | /--------| | | | * peer closed | | | | | | | |<-------X-------| evt for sub-y | | |<===============| sub-n |<------/ X shutdown | -> orphan | | That is, the 'receive-work' may get the last subscription request while the 'send-work' is shutting down the connection due to peer close. We had a 'lock' on the connection, so the two actions cannot be carried out simultaneously. If the last subscription is allocated e.g. 'sub-n', before the 'send-work' closes the connection, there will be no issue at all, the 'sub' objects will be freed. In contrast the last subscription will become orphan since the connection was closed, and we released all references. This commit fixes the issue by simply adding one test if the connection remains in 'connected' state right after we obtain the connection lock, then a subscription object can be created as usual, otherwise we ignore it. Acked-by: Ying Xue Acked-by: Jon Maloy Reported-by: Thang Ngo Signed-off-by: Tuong Lien Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 97cf50cc4e5c655c5dd98707a14cd96ff8c64537 Author: Paolo Bonzini Date: Mon Apr 27 11:55:59 2020 -0400 KVM: x86: handle wrap around 32-bit address space [ Upstream commit fede8076aab4c2280c673492f8f7a2e87712e8b4 ] KVM is not handling the case where EIP wraps around the 32-bit address space (that is, outside long mode). This is needed both in vmx.c and in emulate.c. SVM with NRIPS is okay, but it can still print an error to dmesg due to integer overflow. Reported-by: Nick Peterson Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit c7a403d16fd7f2b78895af3929411d938c245514 Author: Tang Bin Date: Fri May 8 19:43:05 2020 +0800 USB: EHCI: ehci-mv: fix error handling in mv_ehci_probe() [ Upstream commit c856b4b0fdb5044bca4c0acf9a66f3b5cc01a37a ] If the function platform_get_irq() failed, the negative value returned will not be detected here. So fix error handling in mv_ehci_probe(). And when get irq failed, the function platform_get_irq() logs an error message, so remove redundant message here. Signed-off-by: Zhang Shengju Signed-off-by: Tang Bin Link: https://lore.kernel.org/r/20200508114305.15740-1-tangbin@cmss.chinamobile.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3515b56cc0b730cd0f3cfc592d4a87f3885aede1 Author: Sonny Sasaka Date: Wed May 6 12:55:03 2020 -0700 Bluetooth: Handle Inquiry Cancel error after Inquiry Complete [ Upstream commit adf1d6926444029396861413aba8a0f2a805742a ] After sending Inquiry Cancel command to the controller, it is possible that Inquiry Complete event comes before Inquiry Cancel command complete event. In this case the Inquiry Cancel command will have status of Command Disallowed since there is no Inquiry session to be cancelled. This case should not be treated as error, otherwise we can reach an inconsistent state. Example of a btmon trace when this happened: < HCI Command: Inquiry Cancel (0x01|0x0002) plen 0 > HCI Event: Inquiry Complete (0x01) plen 1 Status: Success (0x00) > HCI Event: Command Complete (0x0e) plen 4 Inquiry Cancel (0x01|0x0002) ncmd 1 Status: Command Disallowed (0x0c) Signed-off-by: Sonny Sasaka Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit b5a49bb741e9a7e279574c9e1e869ad758a06e69 Author: Jonathan Bakker Date: Sat Apr 25 10:36:33 2020 -0700 phy: samsung: s5pv210-usb2: Add delay after reset [ Upstream commit 05942b8c36c7eb5d3fc5e375d4b0d0c49562e85d ] The USB phy takes some time to reset, so make sure we give it to it. The delay length was taken from the 4x12 phy driver. This manifested in issues with the DWC2 driver since commit fe369e1826b3 ("usb: dwc2: Make dwc2_readl/writel functions endianness-agnostic.") where the endianness check would read the DWC ID as 0 due to the phy still resetting, resulting in the wrong endian mode being chosen. Signed-off-by: Jonathan Bakker Link: https://lore.kernel.org/r/BN6PR04MB06605D52502816E500683553A3D10@BN6PR04MB0660.namprd04.prod.outlook.com Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Sasha Levin commit e3d47125a42ce0f67fdb0bcc104aa6e7a040028b Author: Jonathan Bakker Date: Mon May 4 15:12:58 2020 -0700 power: supply: max17040: Correct voltage reading [ Upstream commit 0383024f811aa469df258039807810fc3793a105 ] According to the datasheet available at (1), the bottom four bits are always zero and the actual voltage is 1.25x this value in mV. Since the kernel API specifies that voltages should be in uV, it should report 1250x the shifted value. 1) https://datasheets.maximintegrated.com/en/ds/MAX17040-MAX17041.pdf Signed-off-by: Jonathan Bakker Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 44a3faa00887122295e5b48044bdd53b292db400 Author: Thierry Reding Date: Fri Dec 13 14:44:17 2019 +0100 i2c: tegra: Restore pinmux on system resume [ Upstream commit 44c99904cf61f945d02ac9976ab10dd5ccaea393 ] Depending on the board design, the I2C controllers found on Tegra SoCs may require pinmuxing in order to function. This is done as part of the driver's runtime suspend/resume operations. However, the PM core does not allow devices to go into runtime suspend during system sleep to avoid potential races with the suspend/resume of their parents. As a result of this, when Tegra SoCs resume from system suspend, their I2C controllers may have lost the pinmux state in hardware, whereas the pinctrl subsystem is not aware of this. To fix this, make sure that if the I2C controller is not runtime suspended, the runtime suspend code is still executed in order to disable the module clock (which we don't need to be enabled during sleep) and set the pinmux to the idle state. Conversely, make sure that the I2C controller is properly resumed when waking up from sleep so that pinmux settings are properly restored. This fixes a bug seen with DDC transactions to an HDMI monitor timing out when resuming from system suspend. Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 00519f4da8dadfed9f61814192a19016e3e4ab50 Author: Waiman Long Date: Thu May 7 18:36:06 2020 -0700 mm/slub: fix incorrect interpretation of s->offset [ Upstream commit cbfc35a48609ceac978791e3ab9dde0c01f8cb20 ] In a couple of places in the slub memory allocator, the code uses "s->offset" as a check to see if the free pointer is put right after the object. That check is no longer true with commit 3202fa62fb43 ("slub: relocate freelist pointer to middle of object"). As a result, echoing "1" into the validate sysfs file, e.g. of dentry, may cause a bunch of "Freepointer corrupt" error reports like the following to appear with the system in panic afterwards. ============================================================================= BUG dentry(666:pmcd.service) (Tainted: G B): Freepointer corrupt ----------------------------------------------------------------------------- To fix it, use the check "s->offset == s->inuse" in the new helper function freeptr_outside_object() instead. Also add another helper function get_info_end() to return the end of info block (inuse + free pointer if not overlapping with object). Fixes: 3202fa62fb43 ("slub: relocate freelist pointer to middle of object") Signed-off-by: Waiman Long Signed-off-by: Andrew Morton Reviewed-by: Matthew Wilcox (Oracle) Reviewed-by: Kees Cook Acked-by: Rafael Aquini Cc: Christoph Lameter Cc: Vitaly Nikolenko Cc: Silvio Cesare Cc: Pekka Enberg Cc: David Rientjes Cc: Joonsoo Kim Cc: Markus Elfring Cc: Changbin Du Link: http://lkml.kernel.org/r/20200429135328.26976-1-longman@redhat.com Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 0eb69a66083ea46da0d3ec3f03784c2893920c74 Author: Ian Rogers Date: Fri Mar 20 11:23:47 2020 -0700 perf mem2node: Avoid double free related to realloc [ Upstream commit 266150c94c69429cf6d18e130237224a047f5061 ] Realloc of size zero is a free not an error, avoid this causing a double free. Caught by clang's address sanitizer: ==2634==ERROR: AddressSanitizer: attempting double-free on 0x6020000015f0 in thread T0: #0 0x5649659297fd in free llvm/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:123:3 #1 0x5649659e9251 in __zfree tools/lib/zalloc.c:13:2 #2 0x564965c0f92c in mem2node__exit tools/perf/util/mem2node.c:114:2 #3 0x564965a08b4c in perf_c2c__report tools/perf/builtin-c2c.c:2867:2 #4 0x564965a0616a in cmd_c2c tools/perf/builtin-c2c.c:2989:10 #5 0x564965944348 in run_builtin tools/perf/perf.c:312:11 #6 0x564965943235 in handle_internal_command tools/perf/perf.c:364:8 #7 0x5649659440c4 in run_argv tools/perf/perf.c:408:2 #8 0x564965942e41 in main tools/perf/perf.c:538:3 0x6020000015f0 is located 0 bytes inside of 1-byte region [0x6020000015f0,0x6020000015f1) freed by thread T0 here: #0 0x564965929da3 in realloc third_party/llvm/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3 #1 0x564965c0f55e in mem2node__init tools/perf/util/mem2node.c:97:16 #2 0x564965a08956 in perf_c2c__report tools/perf/builtin-c2c.c:2803:8 #3 0x564965a0616a in cmd_c2c tools/perf/builtin-c2c.c:2989:10 #4 0x564965944348 in run_builtin tools/perf/perf.c:312:11 #5 0x564965943235 in handle_internal_command tools/perf/perf.c:364:8 #6 0x5649659440c4 in run_argv tools/perf/perf.c:408:2 #7 0x564965942e41 in main tools/perf/perf.c:538:3 previously allocated by thread T0 here: #0 0x564965929c42 in calloc third_party/llvm/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:154:3 #1 0x5649659e9220 in zalloc tools/lib/zalloc.c:8:9 #2 0x564965c0f32d in mem2node__init tools/perf/util/mem2node.c:61:12 #3 0x564965a08956 in perf_c2c__report tools/perf/builtin-c2c.c:2803:8 #4 0x564965a0616a in cmd_c2c tools/perf/builtin-c2c.c:2989:10 #5 0x564965944348 in run_builtin tools/perf/perf.c:312:11 #6 0x564965943235 in handle_internal_command tools/perf/perf.c:364:8 #7 0x5649659440c4 in run_argv tools/perf/perf.c:408:2 #8 0x564965942e41 in main tools/perf/perf.c:538:3 v2: add a WARN_ON_ONCE when the free condition arises. Signed-off-by: Ian Rogers Acked-by: Jiri Olsa Cc: Alexander Shishkin Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Stephane Eranian Cc: clang-built-linux@googlegroups.com Link: http://lore.kernel.org/lkml/20200320182347.87675-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit bd60439f495007a9689f34d6cffc49b6225223e1 Author: Stanimir Varbanov Date: Fri Apr 3 15:10:13 2020 +0200 media: venus: vdec: Init registered list unconditionally [ Upstream commit bc3d870e414b42d72cd386aa20a4fc3612e4feb7 ] Presently the list initialization is done only in dynamic-resolution-change state, which leads to list corruptions and use-after-free. Init list_head unconditionally in vdec_stop_capture called by vb2 stop_streaming without takeing into account current codec state. Signed-off-by: Stanimir Varbanov Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit fa7c336dd1c8676143f6d72492479868ce4d84a8 Author: Cong Wang Date: Fri May 1 11:11:09 2020 -0700 atm: fix a memory leak of vcc->user_back [ Upstream commit 8d9f73c0ad2f20e9fed5380de0a3097825859d03 ] In lec_arp_clear_vccs() only entry->vcc is freed, but vcc could be installed on entry->recv_vcc too in lec_vcc_added(). This fixes the following memory leak: unreferenced object 0xffff8880d9266b90 (size 16): comm "atm2", pid 425, jiffies 4294907980 (age 23.488s) hex dump (first 16 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 6b 6b 6b a5 ............kkk. backtrace: [<(____ptrval____)>] kmem_cache_alloc_trace+0x10e/0x151 [<(____ptrval____)>] lane_ioctl+0x4b3/0x569 [<(____ptrval____)>] do_vcc_ioctl+0x1ea/0x236 [<(____ptrval____)>] svc_ioctl+0x17d/0x198 [<(____ptrval____)>] sock_do_ioctl+0x47/0x12f [<(____ptrval____)>] sock_ioctl+0x2f9/0x322 [<(____ptrval____)>] vfs_ioctl+0x1e/0x2b [<(____ptrval____)>] ksys_ioctl+0x61/0x80 [<(____ptrval____)>] __x64_sys_ioctl+0x16/0x19 [<(____ptrval____)>] do_syscall_64+0x57/0x65 [<(____ptrval____)>] entry_SYSCALL_64_after_hwframe+0x49/0xb3 Cc: Gengming Liu Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9325e9e5abf6eb4f5136f642ad7d5fa4a7a8572d Author: Aya Levin Date: Mon May 4 11:27:46 2020 +0300 devlink: Fix reporter's recovery condition [ Upstream commit bea0c5c942d3b4e9fb6ed45f6a7de74c6b112437 ] Devlink health core conditions the reporter's recovery with the expiration of the grace period. This is not relevant for the first recovery. Explicitly demand that the grace period will only apply to recoveries other than the first. Fixes: c8e1da0bf923 ("devlink: Add health report functionality") Signed-off-by: Aya Levin Reviewed-by: Moshe Shemesh Reviewed-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4ac87b6af491e6f5739e3bf8e4f539ffce1e8f0d Author: Krzysztof Kozlowski Date: Fri May 1 15:35:34 2020 +0200 dt-bindings: sound: wm8994: Correct required supplies based on actual implementaion [ Upstream commit 8c149b7d75e53be47648742f40fc90d9fc6fa63a ] The required supplies in bindings were actually not matching implementation making the bindings incorrect and misleading. The Linux kernel driver requires all supplies to be present. Also for wlf,wm8994 uses just DBVDD-supply instead of DBVDDn-supply (n: <1,3>). Reported-by: Jonathan Bakker Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20200501133534.6706-1-krzk@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8ff65ea6c77c76dc1b11c1b31e7a5ab435705303 Author: Wei Yongjun Date: Mon Apr 27 10:43:22 2020 +0000 dpaa2-eth: fix error return code in setup_dpni() [ Upstream commit 97fff7c8de1e54e5326dfeb66085796864bceb64 ] Fix to return negative error code -ENOMEM from the error handling case instead of 0, as done elsewhere in this function. Signed-off-by: Wei Yongjun Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 527378a0dfd73b1122fc9d1bf75ec6dd734282a6 Author: Paul Turner Date: Fri Apr 10 15:52:07 2020 -0700 sched/fair: Eliminate bandwidth race between throttling and distribution [ Upstream commit e98fa02c4f2ea4991dae422ac7e34d102d2f0599 ] There is a race window in which an entity begins throttling before quota is added to the pool, but does not finish throttling until after we have finished with distribute_cfs_runtime(). This entity is not observed by distribute_cfs_runtime() because it was not on the throttled list at the time that distribution was running. This race manifests as rare period-length statlls for such entities. Rather than heavy-weight the synchronization with the progress of distribution, we can fix this by aborting throttling if bandwidth has become available. Otherwise, we immediately add the entity to the throttled list so that it can be observed by a subsequent distribution. Additionally, we can remove the case of adding the throttled entity to the head of the throttled list, and simply always add to the tail. Thanks to 26a8b12747c97, distribute_cfs_runtime() no longer holds onto its own pool of runtime. This means that if we do hit the !assign and distribute_running case, we know that distribution is about to end. Signed-off-by: Paul Turner Signed-off-by: Ben Segall Signed-off-by: Josh Don Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Phil Auld Link: https://lkml.kernel.org/r/20200410225208.109717-2-joshdon@google.com Signed-off-by: Sasha Levin commit 8e32fed034ed133385a26ade4765b8514a441b39 Author: Will Deacon Date: Tue Apr 21 15:29:21 2020 +0100 arm64: cpufeature: Relax checks for AArch32 support at EL[0-2] [ Upstream commit 98448cdfe7060dd5491bfbd3f7214ffe1395d58e ] We don't need to be quite as strict about mismatched AArch32 support, which is good because the friendly hardware folks have been busy mismatching this to their hearts' content. * We don't care about EL2 or EL3 (there are silly comments concerning the latter, so remove those) * EL1 support is gated by the ARM64_HAS_32BIT_EL1 capability and handled gracefully when a mismatch occurs * EL0 support is gated by the ARM64_HAS_32BIT_EL0 capability and handled gracefully when a mismatch occurs Relax the AArch32 checks to FTR_NONSTRICT. Tested-by: Sai Prakash Ranjan Reviewed-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20200421142922.18950-8-will@kernel.org Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 294e26f89163addc5d4f1f291579edfd7bafcd06 Author: Wei Yongjun Date: Mon Apr 27 12:24:15 2020 +0000 sparc64: vcc: Fix error return code in vcc_probe() [ Upstream commit ff62255a2a5c1228a28f2bb063646f948115a309 ] Fix to return negative error code -ENOMEM from the error handling case instead of 0, as done elsewhere in this function. Signed-off-by: Wei Yongjun Link: https://lore.kernel.org/r/20200427122415.47416-1-weiyongjun1@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f1723949cf811950e9af48080d03579a7b51d3d1 Author: Ivan Safonov Date: Thu Apr 23 22:14:04 2020 +0300 staging:r8188eu: avoid skb_clone for amsdu to msdu conversion [ Upstream commit 628cbd971a927abe6388d44320e351c337b331e4 ] skb clones use same data buffer, so tail of one skb is corrupted by beginning of next skb. Signed-off-by: Ivan Safonov Link: https://lore.kernel.org/r/20200423191404.12028-1-insafonov@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b6cee18cba12acaf1ac11f7072a58e616463e887 Author: Christophe JAILLET Date: Sun Apr 12 11:40:39 2020 +0200 scsi: aacraid: Fix error handling paths in aac_probe_one() [ Upstream commit f7854c382240c1686900b2f098b36430c6f5047e ] If 'scsi_host_alloc()' or 'kcalloc()' fail, 'error' is known to be 0. Set it explicitly to -ENOMEM before branching to the error handling path. While at it, remove 2 useless assignments to 'error'. These values are overwridden a few lines later. Link: https://lore.kernel.org/r/20200412094039.8822-1-christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit cd6f892ba542891ee71a1ba073aca5102ed64e09 Author: Tonghao Zhang Date: Fri Apr 24 08:08:06 2020 +0800 net: openvswitch: use u64 for meter bucket [ Upstream commit e57358873bb5d6caa882b9684f59140912b37dde ] When setting the meter rate to 4+Gbps, there is an overflow, the meters don't work as expected. Cc: Pravin B Shelar Cc: Andy Zhou Signed-off-by: Tonghao Zhang Acked-by: Pravin B Shelar Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 545c261f22b41186cbc0c7ad33fe91b03eac2c1c Author: Zenghui Yu Date: Tue Apr 14 11:03:48 2020 +0800 KVM: arm64: vgic-its: Fix memory leak on the error path of vgic_add_lpi() [ Upstream commit 57bdb436ce869a45881d8aa4bc5dac8e072dd2b6 ] If we're going to fail out the vgic_add_lpi(), let's make sure the allocated vgic_irq memory is also freed. Though it seems that both cases are unlikely to fail. Signed-off-by: Zenghui Yu Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20200414030349.625-3-yuzenghui@huawei.com Signed-off-by: Sasha Levin commit beb8e02541970a05367492e6b8eb0a8150cc87d2 Author: Zenghui Yu Date: Tue Apr 14 11:03:47 2020 +0800 KVM: arm64: vgic-v3: Retire all pending LPIs on vcpu destroy [ Upstream commit 969ce8b5260d8ec01e6f1949d2927a86419663ce ] It's likely that the vcpu fails to handle all virtual interrupts if userspace decides to destroy it, leaving the pending ones stay in the ap_list. If the un-handled one is a LPI, its vgic_irq structure will be eventually leaked because of an extra refcount increment in vgic_queue_irq_unlock(). This was detected by kmemleak on almost every guest destroy, the backtrace is as follows: unreferenced object 0xffff80725aed5500 (size 128): comm "CPU 5/KVM", pid 40711, jiffies 4298024754 (age 166366.512s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 01 a9 73 6d 80 ff ff ...........sm... c8 61 ee a9 00 20 ff ff 28 1e 55 81 6c 80 ff ff .a... ..(.U.l... backtrace: [<000000004bcaa122>] kmem_cache_alloc_trace+0x2dc/0x418 [<0000000069c7dabb>] vgic_add_lpi+0x88/0x418 [<00000000bfefd5c5>] vgic_its_cmd_handle_mapi+0x4dc/0x588 [<00000000cf993975>] vgic_its_process_commands.part.5+0x484/0x1198 [<000000004bd3f8e3>] vgic_its_process_commands+0x50/0x80 [<00000000b9a65b2b>] vgic_mmio_write_its_cwriter+0xac/0x108 [<0000000009641ebb>] dispatch_mmio_write+0xd0/0x188 [<000000008f79d288>] __kvm_io_bus_write+0x134/0x240 [<00000000882f39ac>] kvm_io_bus_write+0xe0/0x150 [<0000000078197602>] io_mem_abort+0x484/0x7b8 [<0000000060954e3c>] kvm_handle_guest_abort+0x4cc/0xa58 [<00000000e0d0cd65>] handle_exit+0x24c/0x770 [<00000000b44a7fad>] kvm_arch_vcpu_ioctl_run+0x460/0x1988 [<0000000025fb897c>] kvm_vcpu_ioctl+0x4f8/0xee0 [<000000003271e317>] do_vfs_ioctl+0x160/0xcd8 [<00000000e7f39607>] ksys_ioctl+0x98/0xd8 Fix it by retiring all pending LPIs in the ap_list on the destroy path. p.s. I can also reproduce it on a normal guest shutdown. It is because userspace still send LPIs to vcpu (through KVM_SIGNAL_MSI ioctl) while the guest is being shutdown and unable to handle it. A little strange though and haven't dig further... Reviewed-by: James Morse Signed-off-by: Zenghui Yu [maz: moved the distributor deallocation down to avoid an UAF splat] Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20200414030349.625-2-yuzenghui@huawei.com Signed-off-by: Sasha Levin commit 4998dc5ff868289806f8cebab8279148ef9463d1 Author: Madhuparna Bhowmik Date: Fri Apr 17 21:04:51 2020 +0530 drivers: char: tlclk.c: Avoid data race between init and interrupt handler [ Upstream commit 44b8fb6eaa7c3fb770bf1e37619cdb3902cca1fc ] After registering character device the file operation callbacks can be called. The open callback registers interrupt handler. Therefore interrupt handler can execute in parallel with rest of the init function. To avoid such data race initialize telclk_interrupt variable and struct alarm_events before registering character device. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Madhuparna Bhowmik Link: https://lore.kernel.org/r/20200417153451.1551-1-madhuparnabhowmik10@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a48b609c8dfd1d177474c8b69c9a2e74ef2f4d62 Author: Douglas Anderson Date: Tue Mar 24 14:48:27 2020 -0700 bdev: Reduce time holding bd_mutex in sync in blkdev_close() [ Upstream commit b849dd84b6ccfe32622988b79b7b073861fcf9f7 ] While trying to "dd" to the block device for a USB stick, I encountered a hung task warning (blocked for > 120 seconds). I managed to come up with an easy way to reproduce this on my system (where /dev/sdb is the block device for my USB stick) with: while true; do dd if=/dev/zero of=/dev/sdb bs=4M; done With my reproduction here are the relevant bits from the hung task detector: INFO: task udevd:294 blocked for more than 122 seconds. ... udevd D 0 294 1 0x00400008 Call trace: ... mutex_lock_nested+0x40/0x50 __blkdev_get+0x7c/0x3d4 blkdev_get+0x118/0x138 blkdev_open+0x94/0xa8 do_dentry_open+0x268/0x3a0 vfs_open+0x34/0x40 path_openat+0x39c/0xdf4 do_filp_open+0x90/0x10c do_sys_open+0x150/0x3c8 ... ... Showing all locks held in the system: ... 1 lock held by dd/2798: #0: ffffff814ac1a3b8 (&bdev->bd_mutex){+.+.}, at: __blkdev_put+0x50/0x204 ... dd D 0 2798 2764 0x00400208 Call trace: ... schedule+0x8c/0xbc io_schedule+0x1c/0x40 wait_on_page_bit_common+0x238/0x338 __lock_page+0x5c/0x68 write_cache_pages+0x194/0x500 generic_writepages+0x64/0xa4 blkdev_writepages+0x24/0x30 do_writepages+0x48/0xa8 __filemap_fdatawrite_range+0xac/0xd8 filemap_write_and_wait+0x30/0x84 __blkdev_put+0x88/0x204 blkdev_put+0xc4/0xe4 blkdev_close+0x28/0x38 __fput+0xe0/0x238 ____fput+0x1c/0x28 task_work_run+0xb0/0xe4 do_notify_resume+0xfc0/0x14bc work_pending+0x8/0x14 The problem appears related to the fact that my USB disk is terribly slow and that I have a lot of RAM in my system to cache things. Specifically my writes seem to be happening at ~15 MB/s and I've got ~4 GB of RAM in my system that can be used for buffering. To write 4 GB of buffer to disk thus takes ~4000 MB / ~15 MB/s = ~267 seconds. The 267 second number is a problem because in __blkdev_put() we call sync_blockdev() while holding the bd_mutex. Any other callers who want the bd_mutex will be blocked for the whole time. The problem is made worse because I believe blkdev_put() specifically tells other tasks (namely udev) to go try to access the device at right around the same time we're going to hold the mutex for a long time. Putting some traces around this (after disabling the hung task detector), I could confirm: dd: 437.608600: __blkdev_put() right before sync_blockdev() for sdb udevd: 437.623901: blkdev_open() right before blkdev_get() for sdb dd: 661.468451: __blkdev_put() right after sync_blockdev() for sdb udevd: 663.820426: blkdev_open() right after blkdev_get() for sdb A simple fix for this is to realize that sync_blockdev() works fine if you're not holding the mutex. Also, it's not the end of the world if you sync a little early (though it can have performance impacts). Thus we can make a guess that we're going to need to do the sync and then do it without holding the mutex. We still do one last sync with the mutex but it should be much, much faster. With this, my hung task warnings for my test case are gone. Signed-off-by: Douglas Anderson Reviewed-by: Guenter Roeck Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c8317e9fc412644c2e3de1de92e7b190f0c2c37e Author: Stephane Eranian Date: Tue Apr 14 09:15:50 2020 -0700 perf stat: Force error in fallback on :k events [ Upstream commit bec49a9e05db3dbdca696fa07c62c52638fb6371 ] When it is not possible for a non-privilege perf command to monitor at the kernel level (:k), the fallback code forces a :u. That works if the event was previously monitoring both levels. But if the event was already constrained to kernel only, then it does not make sense to restrict it to user only. Given the code works by exclusion, a kernel only event would have: attr->exclude_user = 1 The fallback code would add: attr->exclude_kernel = 1 In the end the end would not monitor in either the user level or kernel level. In other words, it would count nothing. An event programmed to monitor kernel only cannot be switched to user only without seriously warning the user. This patch forces an error in this case to make it clear the request cannot really be satisfied. Behavior with paranoid 1: $ sudo bash -c "echo 1 > /proc/sys/kernel/perf_event_paranoid" $ perf stat -e cycles:k sleep 1 Performance counter stats for 'sleep 1': 1,520,413 cycles:k 1.002361664 seconds time elapsed 0.002480000 seconds user 0.000000000 seconds sys Old behavior with paranoid 2: $ sudo bash -c "echo 2 > /proc/sys/kernel/perf_event_paranoid" $ perf stat -e cycles:k sleep 1 Performance counter stats for 'sleep 1': 0 cycles:ku 1.002358127 seconds time elapsed 0.002384000 seconds user 0.000000000 seconds sys New behavior with paranoid 2: $ sudo bash -c "echo 2 > /proc/sys/kernel/perf_event_paranoid" $ perf stat -e cycles:k sleep 1 Error: You may not have permission to collect stats. Consider tweaking /proc/sys/kernel/perf_event_paranoid, which controls use of the performance events system by unprivileged users (without CAP_PERFMON or CAP_SYS_ADMIN). The current value is 2: -1: Allow use of (almost) all events by all users Ignore mlock limit after perf_event_mlock_kb without CAP_IPC_LOCK >= 0: Disallow ftrace function tracepoint by users without CAP_PERFMON or CAP_SYS_ADMIN Disallow raw tracepoint access by users without CAP_SYS_PERFMON or CAP_SYS_ADMIN >= 1: Disallow CPU event access by users without CAP_PERFMON or CAP_SYS_ADMIN >= 2: Disallow kernel profiling by users without CAP_PERFMON or CAP_SYS_ADMIN To make this setting permanent, edit /etc/sysctl.conf too, e.g.: kernel.perf_event_paranoid = -1 v2 of this patch addresses the review feedback from jolsa@redhat.com. Signed-off-by: Stephane Eranian Reviewed-by: Ian Rogers Acked-by: Jiri Olsa Tested-by: Arnaldo Carvalho de Melo Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20200414161550.225588-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 4f4e2978952508d9f25f765b4bfe12ba2dde5c68 Author: Steve Rutherford Date: Thu Apr 16 12:11:52 2020 -0700 KVM: Remove CREATE_IRQCHIP/SET_PIT2 race [ Upstream commit 7289fdb5dcdbc5155b5531529c44105868a762f2 ] Fixes a NULL pointer dereference, caused by the PIT firing an interrupt before the interrupt table has been initialized. SET_PIT2 can race with the creation of the IRQchip. In particular, if SET_PIT2 is called with a low PIT timer period (after the creation of the IOAPIC, but before the instantiation of the irq routes), the PIT can fire an interrupt at an uninitialized table. Signed-off-by: Steve Rutherford Signed-off-by: Jon Cargille Reviewed-by: Jim Mattson Message-Id: <20200416191152.259434-1-jcargill@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit e4e024e89ccaca6686beca82a898b80ead131030 Author: Josef Bacik Date: Fri Apr 10 11:42:48 2020 -0400 btrfs: fix setting last_trans for reloc roots [ Upstream commit aec7db3b13a07d515c15ada752a7287a44a79ea0 ] I made a mistake with my previous fix, I assumed that we didn't need to mess with the reloc roots once we were out of the part of relocation where we are actually moving the extents. The subtle thing that I missed is that btrfs_init_reloc_root() also updates the last_trans for the reloc root when we do btrfs_record_root_in_trans() for the corresponding fs_root. I've added a comment to make sure future me doesn't make this mistake again. This showed up as a WARN_ON() in btrfs_copy_root() because our last_trans didn't == the current transid. This could happen if we snapshotted a fs root with a reloc root after we set rc->create_reloc_tree = 0, but before we actually merge the reloc root. Worth mentioning that the regression produced the following warning when running snapshot creation and balance in parallel: BTRFS info (device sdc): relocating block group 30408704 flags metadata|dup ------------[ cut here ]------------ WARNING: CPU: 0 PID: 12823 at fs/btrfs/ctree.c:191 btrfs_copy_root+0x26f/0x430 [btrfs] CPU: 0 PID: 12823 Comm: btrfs Tainted: G W 5.6.0-rc7-btrfs-next-58 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 RIP: 0010:btrfs_copy_root+0x26f/0x430 [btrfs] RSP: 0018:ffffb96e044279b8 EFLAGS: 00010202 RAX: 0000000000000009 RBX: ffff9da70bf61000 RCX: ffffb96e04427a48 RDX: ffff9da733a770c8 RSI: ffff9da70bf61000 RDI: ffff9da694163818 RBP: ffff9da733a770c8 R08: fffffffffffffff8 R09: 0000000000000002 R10: ffffb96e044279a0 R11: 0000000000000000 R12: ffff9da694163818 R13: fffffffffffffff8 R14: ffff9da6d2512000 R15: ffff9da714cdac00 FS: 00007fdeacf328c0(0000) GS:ffff9da735e00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055a2a5b8a118 CR3: 00000001eed78002 CR4: 00000000003606f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? create_reloc_root+0x49/0x2b0 [btrfs] ? kmem_cache_alloc_trace+0xe5/0x200 create_reloc_root+0x8b/0x2b0 [btrfs] btrfs_reloc_post_snapshot+0x96/0x5b0 [btrfs] create_pending_snapshot+0x610/0x1010 [btrfs] create_pending_snapshots+0xa8/0xd0 [btrfs] btrfs_commit_transaction+0x4c7/0xc50 [btrfs] ? btrfs_mksubvol+0x3cd/0x560 [btrfs] btrfs_mksubvol+0x455/0x560 [btrfs] __btrfs_ioctl_snap_create+0x15f/0x190 [btrfs] btrfs_ioctl_snap_create_v2+0xa4/0xf0 [btrfs] ? mem_cgroup_commit_charge+0x6e/0x540 btrfs_ioctl+0x12d8/0x3760 [btrfs] ? do_raw_spin_unlock+0x49/0xc0 ? _raw_spin_unlock+0x29/0x40 ? __handle_mm_fault+0x11b3/0x14b0 ? ksys_ioctl+0x92/0xb0 ksys_ioctl+0x92/0xb0 ? trace_hardirqs_off_thunk+0x1a/0x1c __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x5c/0x280 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7fdeabd3bdd7 Fixes: 2abc726ab4b8 ("btrfs: do not init a reloc root if we aren't relocating") Reviewed-by: Filipe Manana Signed-off-by: Josef Bacik Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 26d261f32f43253e0fcd781cdee4d1eda79f672c Author: Raviteja Narayanam Date: Thu Apr 9 11:56:02 2020 +0530 serial: uartps: Wait for tx_empty in console setup [ Upstream commit 42e11948ddf68b9f799cad8c0ddeab0a39da33e8 ] On some platforms, the log is corrupted while console is being registered. It is observed that when set_termios is called, there are still some bytes in the FIFO to be transmitted. So, wait for tx_empty inside cdns_uart_console_setup before calling set_termios. Signed-off-by: Raviteja Narayanam Reviewed-by: Shubhrajyoti Datta Link: https://lore.kernel.org/r/1586413563-29125-2-git-send-email-raviteja.narayanam@xilinx.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ab1d9bad60975630dfc4cb4ca63892417cf82747 Author: Nilesh Javali Date: Tue Apr 7 23:43:32 2020 -0700 scsi: qedi: Fix termination timeouts in session logout [ Upstream commit b9b97e6903032ec56e6dcbe137a9819b74a17fea ] The destroy connection ramrod timed out during session logout. Fix the wait delay for graceful vs abortive termination as per the FW requirements. Link: https://lore.kernel.org/r/20200408064332.19377-7-mrangankar@marvell.com Reviewed-by: Lee Duncan Signed-off-by: Nilesh Javali Signed-off-by: Manish Rangankar Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 61192ac4a1f2350daf0f222d29d1bbef6680ab57 Author: Takashi Iwai Date: Mon Apr 13 10:20:33 2020 +0200 ALSA: hda: Skip controller resume if not needed [ Upstream commit c4c8dd6ef807663e42a5f04ea77cd62029eb99fa ] The HD-audio controller does system-suspend and resume operations by directly calling its helpers __azx_runtime_suspend() and __azx_runtime_resume(). However, in general, we don't have to resume always the device fully at the system resume; typically, if a device has been runtime-suspended, we can leave it to runtime resume. Usually for achieving this, the driver would call pm_runtime_force_suspend() and pm_runtime_force_resume() pairs in the system suspend and resume ops. Unfortunately, this doesn't work for the resume path in our case. For handling the jack detection at the system resume, a child codec device may need the (literally) forcibly resume even if it's been runtime-suspended, and for that, the controller device must be also resumed even if it's been suspended. This patch is an attempt to improve the situation. It replaces the direct __azx_runtime_suspend()/_resume() calls with with pm_runtime_force_suspend() and pm_runtime_force_resume() with a slight trick as we've done for the codec side. More exactly: - azx_has_pm_runtime() check is dropped from azx_runtime_suspend() and azx_runtime_resume(), so that it can be properly executed from the system-suspend/resume path - The WAKEEN handling depends on the card's power state now; it's set and cleared only for the runtime-suspend - azx_resume() checks whether any codec may need the forcible resume beforehand. If the forcible resume is required, it does temporary PM refcount up/down for actually triggering the runtime resume. - A new helper function, hda_codec_need_resume(), is introduced for checking whether the codec needs a forcible runtime-resume, and the existing code is rewritten with that. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207043 Link: https://lore.kernel.org/r/20200413082034.25166-6-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 51396da044255fac6309cdcfae4d679ca87829e6 Author: Jaewon Kim Date: Fri Apr 10 14:32:48 2020 -0700 mm/mmap.c: initialize align_offset explicitly for vm_unmapped_area [ Upstream commit 09ef5283fd96ac424ef0e569626f359bf9ab86c9 ] On passing requirement to vm_unmapped_area, arch_get_unmapped_area and arch_get_unmapped_area_topdown did not set align_offset. Internally on both unmapped_area and unmapped_area_topdown, if info->align_mask is 0, then info->align_offset was meaningless. But commit df529cabb7a2 ("mm: mmap: add trace point of vm_unmapped_area") always prints info->align_offset even though it is uninitialized. Fix this uninitialized value issue by setting it to 0 explicitly. Before: vm_unmapped_area: addr=0x755b155000 err=0 total_vm=0x15aaf0 flags=0x1 len=0x109000 lo=0x8000 hi=0x75eed48000 mask=0x0 ofs=0x4022 After: vm_unmapped_area: addr=0x74a4ca1000 err=0 total_vm=0x168ab1 flags=0x1 len=0x9000 lo=0x8000 hi=0x753d94b000 mask=0x0 ofs=0x0 Signed-off-by: Jaewon Kim Signed-off-by: Andrew Morton Reviewed-by: Andrew Morton Cc: Matthew Wilcox (Oracle) Cc: Michel Lespinasse Cc: Borislav Petkov Link: http://lkml.kernel.org/r/20200409094035.19457-1-jaewon31.kim@samsung.com Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit cb1dfad688ef9aa7140933a5fe7ffe49b2ee5c48 Author: Jack Zhang Date: Thu Apr 2 15:10:24 2020 +0800 drm/amdgpu/sriov add amdgpu_amdkfd_pre_reset in gpu reset [ Upstream commit 04bef61e5da18c2b301c629a209ccdba4d4c6fbb ] kfd_pre_reset will free mem_objs allocated by kfd_gtt_sa_allocate Without this change, sriov tdr code path will never free those allocated memories and get memory leak. v2:add a bugfix for kiq ring test fail Signed-off-by: Jack Zhang Reviewed-by: Monk Liu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 644148cd15378b89123e9cdc9d1840cf6135f7ea Author: Sebastian Andrzej Siewior Date: Sat Mar 28 00:29:59 2020 +0100 workqueue: Remove the warning in wq_worker_sleeping() [ Upstream commit 62849a9612924a655c67cf6962920544aa5c20db ] The kernel test robot triggered a warning with the following race: task-ctx A interrupt-ctx B worker -> process_one_work() -> work_item() -> schedule(); -> sched_submit_work() -> wq_worker_sleeping() -> ->sleeping = 1 atomic_dec_and_test(nr_running) __schedule(); *interrupt* async_page_fault() -> local_irq_enable(); -> schedule(); -> sched_submit_work() -> wq_worker_sleeping() -> if (WARN_ON(->sleeping)) return -> __schedule() -> sched_update_worker() -> wq_worker_running() -> atomic_inc(nr_running); -> ->sleeping = 0; -> sched_update_worker() -> wq_worker_running() if (!->sleeping) return In this context the warning is pointless everything is fine. An interrupt before wq_worker_sleeping() will perform the ->sleeping assignment (0 -> 1 > 0) twice. An interrupt after wq_worker_sleeping() will trigger the warning and nr_running will be decremented (by A) and incremented once (only by B, A will skip it). This is the case until the ->sleeping is zeroed again in wq_worker_running(). Remove the WARN statement because this condition may happen. Document that preemption around wq_worker_sleeping() needs to be disabled to protect ->sleeping and not just as an optimisation. Fixes: 6d25be5782e48 ("sched/core, workqueues: Distangle worker accounting from rq lock") Reported-by: kernel test robot Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Cc: Tejun Heo Link: https://lkml.kernel.org/r/20200327074308.GY11705@shao2-debian Signed-off-by: Sasha Levin commit 74c28abcb301d12b4361dfee9e4a5f78cb8ac72f Author: Israel Rukshin Date: Tue Apr 7 11:02:28 2020 +0000 nvmet-rdma: fix double free of rdma queue [ Upstream commit 21f9024355e58772ec5d7fc3534aa5e29d72a8b6 ] In case rdma accept fails at nvmet_rdma_queue_connect(), release work is scheduled. Later on, a new RDMA CM event may arrive since we didn't destroy the cm-id and call nvmet_rdma_queue_connect_fail(), which schedule another release work. This will cause calling nvmet_rdma_free_queue twice. To fix this we implicitly destroy the cm_id with non-zero ret code, which guarantees that new rdma_cm events will not arrive afterwards. Also add a qp pointer to nvmet_rdma_queue structure, so we can use it when the cm_id pointer is NULL or was destroyed. Signed-off-by: Israel Rukshin Suggested-by: Sagi Grimberg Reviewed-by: Max Gurtovoy Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 5e3c0dae5f96fb0e1080ed439354bec91ed1d66c Author: Trond Myklebust Date: Sat Apr 4 19:52:21 2020 -0400 SUNRPC: Don't start a timer on an already queued rpc task [ Upstream commit 1fab7dc477241c12f977955aa6baea7938b6f08d ] Move the test for whether a task is already queued to prevent corruption of the timer list in __rpc_sleep_on_priority_timeout(). Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 19b9ff11464ecd2606c65c24905c99a70c0a2ba6 Author: Qian Cai Date: Wed Apr 1 21:10:12 2020 -0700 mm/vmscan.c: fix data races using kswapd_classzone_idx [ Upstream commit 5644e1fbbfe15ad06785502bbfe5751223e5841d ] pgdat->kswapd_classzone_idx could be accessed concurrently in wakeup_kswapd(). Plain writes and reads without any lock protection result in data races. Fix them by adding a pair of READ|WRITE_ONCE() as well as saving a branch (compilers might well optimize the original code in an unintentional way anyway). While at it, also take care of pgdat->kswapd_order and non-kswapd threads in allow_direct_reclaim(). The data races were reported by KCSAN, BUG: KCSAN: data-race in wakeup_kswapd / wakeup_kswapd write to 0xffff9f427ffff2dc of 4 bytes by task 7454 on cpu 13: wakeup_kswapd+0xf1/0x400 wakeup_kswapd at mm/vmscan.c:3967 wake_all_kswapds+0x59/0xc0 wake_all_kswapds at mm/page_alloc.c:4241 __alloc_pages_slowpath+0xdcc/0x1290 __alloc_pages_slowpath at mm/page_alloc.c:4512 __alloc_pages_nodemask+0x3bb/0x450 alloc_pages_vma+0x8a/0x2c0 do_anonymous_page+0x16e/0x6f0 __handle_mm_fault+0xcd5/0xd40 handle_mm_fault+0xfc/0x2f0 do_page_fault+0x263/0x6f9 page_fault+0x34/0x40 1 lock held by mtest01/7454: #0: ffff9f425afe8808 (&mm->mmap_sem#2){++++}, at: do_page_fault+0x143/0x6f9 do_user_addr_fault at arch/x86/mm/fault.c:1405 (inlined by) do_page_fault at arch/x86/mm/fault.c:1539 irq event stamp: 6944085 count_memcg_event_mm+0x1a6/0x270 count_memcg_event_mm+0x119/0x270 __do_softirq+0x34c/0x57c irq_exit+0xa2/0xc0 read to 0xffff9f427ffff2dc of 4 bytes by task 7472 on cpu 38: wakeup_kswapd+0xc8/0x400 wake_all_kswapds+0x59/0xc0 __alloc_pages_slowpath+0xdcc/0x1290 __alloc_pages_nodemask+0x3bb/0x450 alloc_pages_vma+0x8a/0x2c0 do_anonymous_page+0x16e/0x6f0 __handle_mm_fault+0xcd5/0xd40 handle_mm_fault+0xfc/0x2f0 do_page_fault+0x263/0x6f9 page_fault+0x34/0x40 1 lock held by mtest01/7472: #0: ffff9f425a9ac148 (&mm->mmap_sem#2){++++}, at: do_page_fault+0x143/0x6f9 irq event stamp: 6793561 count_memcg_event_mm+0x1a6/0x270 count_memcg_event_mm+0x119/0x270 __do_softirq+0x34c/0x57c irq_exit+0xa2/0xc0 BUG: KCSAN: data-race in kswapd / wakeup_kswapd write to 0xffff90973ffff2dc of 4 bytes by task 820 on cpu 6: kswapd+0x27c/0x8d0 kthread+0x1e0/0x200 ret_from_fork+0x27/0x50 read to 0xffff90973ffff2dc of 4 bytes by task 6299 on cpu 0: wakeup_kswapd+0xf3/0x450 wake_all_kswapds+0x59/0xc0 __alloc_pages_slowpath+0xdcc/0x1290 __alloc_pages_nodemask+0x3bb/0x450 alloc_pages_vma+0x8a/0x2c0 do_anonymous_page+0x170/0x700 __handle_mm_fault+0xc9f/0xd00 handle_mm_fault+0xfc/0x2f0 do_page_fault+0x263/0x6f9 page_fault+0x34/0x40 Signed-off-by: Qian Cai Signed-off-by: Andrew Morton Reviewed-by: Andrew Morton Cc: Marco Elver Cc: Matthew Wilcox Link: http://lkml.kernel.org/r/1582749472-5171-1-git-send-email-cai@lca.pw Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit b569d92b1d031b9b202ea61e7ad68007a0c2b47b Author: Qian Cai Date: Wed Apr 1 21:06:13 2020 -0700 mm/swapfile: fix data races in try_to_unuse() [ Upstream commit 218209487c3da2f6d861b236c11226b6eca7b7b7 ] si->inuse_pages could be accessed concurrently as noticed by KCSAN, write to 0xffff98b00ebd04dc of 4 bytes by task 82262 on cpu 92: swap_range_free+0xbe/0x230 swap_range_free at mm/swapfile.c:719 swapcache_free_entries+0x1be/0x250 free_swap_slot+0x1c8/0x220 __swap_entry_free.constprop.19+0xa3/0xb0 free_swap_and_cache+0x53/0xa0 unmap_page_range+0x7e0/0x1ce0 unmap_single_vma+0xcd/0x170 unmap_vmas+0x18b/0x220 exit_mmap+0xee/0x220 mmput+0xe7/0x240 do_exit+0x598/0xfd0 do_group_exit+0x8b/0x180 get_signal+0x293/0x13d0 do_signal+0x37/0x5d0 prepare_exit_to_usermode+0x1b7/0x2c0 ret_from_intr+0x32/0x42 read to 0xffff98b00ebd04dc of 4 bytes by task 82499 on cpu 46: try_to_unuse+0x86b/0xc80 try_to_unuse at mm/swapfile.c:2185 __x64_sys_swapoff+0x372/0xd40 do_syscall_64+0x91/0xb05 entry_SYSCALL_64_after_hwframe+0x49/0xbe The plain reads in try_to_unuse() are outside si->lock critical section which result in data races that could be dangerous to be used in a loop. Fix them by adding READ_ONCE(). Signed-off-by: Qian Cai Signed-off-by: Andrew Morton Reviewed-by: Andrew Morton Cc: Marco Elver Cc: Hugh Dickins Link: http://lkml.kernel.org/r/1582578903-29294-1-git-send-email-cai@lca.pw Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 6eed4b3392c666d17e5412c203ddc0f917da4db0 Author: Xianting Tian Date: Wed Apr 1 21:04:47 2020 -0700 mm/filemap.c: clear page error before actual read [ Upstream commit faffdfa04fa11ccf048cebdde73db41ede0679e0 ] Mount failure issue happens under the scenario: Application forked dozens of threads to mount the same number of cramfs images separately in docker, but several mounts failed with high probability. Mount failed due to the checking result of the page(read from the superblock of loop dev) is not uptodate after wait_on_page_locked(page) returned in function cramfs_read: wait_on_page_locked(page); if (!PageUptodate(page)) { ... } The reason of the checking result of the page not uptodate: systemd-udevd read the loopX dev before mount, because the status of loopX is Lo_unbound at this time, so loop_make_request directly trigger the calling of io_end handler end_buffer_async_read, which called SetPageError(page). So It caused the page can't be set to uptodate in function end_buffer_async_read: if(page_uptodate && !PageError(page)) { SetPageUptodate(page); } Then mount operation is performed, it used the same page which is just accessed by systemd-udevd above, Because this page is not uptodate, it will launch a actual read via submit_bh, then wait on this page by calling wait_on_page_locked(page). When the I/O of the page done, io_end handler end_buffer_async_read is called, because no one cleared the page error(during the whole read path of mount), which is caused by systemd-udevd reading, so this page is still in "PageError" status, which can't be set to uptodate in function end_buffer_async_read, then caused mount failure. But sometimes mount succeed even through systemd-udeved read loopX dev just before, The reason is systemd-udevd launched other loopX read just between step 3.1 and 3.2, the steps as below: 1, loopX dev default status is Lo_unbound; 2, systemd-udved read loopX dev (page is set to PageError); 3, mount operation 1) set loopX status to Lo_bound; ==>systemd-udevd read loopX dev<== 2) read loopX dev(page has no error) 3) mount succeed As the loopX dev status is set to Lo_bound after step 3.1, so the other loopX dev read by systemd-udevd will go through the whole I/O stack, part of the call trace as below: SYS_read vfs_read do_sync_read blkdev_aio_read generic_file_aio_read do_generic_file_read: ClearPageError(page); mapping->a_ops->readpage(filp, page); here, mapping->a_ops->readpage() is blkdev_readpage. In latest kernel, some function name changed, the call trace as below: blkdev_read_iter generic_file_read_iter generic_file_buffered_read: /* * A previous I/O error may have been due to temporary * failures, eg. mutipath errors. * Pg_error will be set again if readpage fails. */ ClearPageError(page); /* Start the actual read. The read will unlock the page*/ error=mapping->a_ops->readpage(flip, page); We can see ClearPageError(page) is called before the actual read, then the read in step 3.2 succeed. This patch is to add the calling of ClearPageError just before the actual read of read path of cramfs mount. Without the patch, the call trace as below when performing cramfs mount: do_mount cramfs_read cramfs_blkdev_read read_cache_page do_read_cache_page: filler(data, page); or mapping->a_ops->readpage(data, page); With the patch, the call trace as below when performing mount: do_mount cramfs_read cramfs_blkdev_read read_cache_page: do_read_cache_page: ClearPageError(page); <== new add filler(data, page); or mapping->a_ops->readpage(data, page); With the patch, mount operation trigger the calling of ClearPageError(page) before the actual read, the page has no error if no additional page error happen when I/O done. Signed-off-by: Xianting Tian Signed-off-by: Andrew Morton Reviewed-by: Matthew Wilcox (Oracle) Cc: Jan Kara Cc: Link: http://lkml.kernel.org/r/1583318844-22971-1-git-send-email-xianting_tian@126.com Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 336df1dcf92d095b1a50c1b60d642d3a7d1ed0d0 Author: Nathan Chancellor Date: Wed Apr 1 21:04:34 2020 -0700 mm/kmemleak.c: use address-of operator on section symbols [ Upstream commit b0d14fc43d39203ae025f20ef4d5d25d9ccf4be1 ] Clang warns: mm/kmemleak.c:1955:28: warning: array comparison always evaluates to a constant [-Wtautological-compare] if (__start_ro_after_init < _sdata || __end_ro_after_init > _edata) ^ mm/kmemleak.c:1955:60: warning: array comparison always evaluates to a constant [-Wtautological-compare] if (__start_ro_after_init < _sdata || __end_ro_after_init > _edata) These are not true arrays, they are linker defined symbols, which are just addresses. Using the address of operator silences the warning and does not change the resulting assembly with either clang/ld.lld or gcc/ld (tested with diff + objdump -Dr). Suggested-by: Nick Desaulniers Signed-off-by: Nathan Chancellor Signed-off-by: Andrew Morton Acked-by: Catalin Marinas Link: https://github.com/ClangBuiltLinux/linux/issues/895 Link: http://lkml.kernel.org/r/20200220051551.44000-1-natechancellor@gmail.com Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 685a1e317a64cee610e8763e3a16cb4192e94c49 Author: Anju T Sudhakar Date: Fri Mar 13 11:22:37 2020 +0530 powerpc/perf: Implement a global lock to avoid races between trace, core and thread imc events. [ Upstream commit a36e8ba60b991d563677227f172db69e030797e6 ] IMC(In-memory Collection Counters) does performance monitoring in two different modes, i.e accumulation mode(core-imc and thread-imc events), and trace mode(trace-imc events). A cpu thread can either be in accumulation-mode or trace-mode at a time and this is done via the LDBAR register in POWER architecture. The current design does not address the races between thread-imc and trace-imc events. Patch implements a global id and lock to avoid the races between core, trace and thread imc events. With this global id-lock implementation, the system can either run core, thread or trace imc events at a time. i.e. to run any core-imc events, thread/trace imc events should not be enabled/monitored. Signed-off-by: Anju T Sudhakar Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200313055238.8656-1-anju@linux.vnet.ibm.com Signed-off-by: Sasha Levin commit 7cafcc37c57e2a100e61778808624953daba561d Author: James Zhu Date: Tue Feb 18 17:44:39 2020 -0500 drm/amdgpu/vcn2.0: stall DPG when WPTR/RPTR reset [ Upstream commit ef563ff403404ef2f234abe79bdd9f04ab6481c9 ] Add vcn dpg harware synchronization to fix race condition issue between vcn driver and hardware. Signed-off-by: James Zhu Reviewed-by: Leo Liu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 24c56b6fe0ba0e745f62a4c5b1037195012147cd Author: Trond Myklebust Date: Wed Apr 1 13:04:49 2020 -0400 NFS: Fix races nfs_page_group_destroy() vs nfs_destroy_unlinked_subrequests() [ Upstream commit 08ca8b21f760c0ed5034a5c122092eec22ccf8f4 ] When a subrequest is being detached from the subgroup, we want to ensure that it is not holding the group lock, or in the process of waiting for the group lock. Fixes: 5b2b5187fa85 ("NFS: Fix nfs_page_group_destroy() and nfs_lock_and_join_requests() race cases") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 4667358dab9cc07da044d5bc087065545b1000df Author: Stuart Hayes Date: Wed Feb 19 15:31:13 2020 +0100 PCI: pciehp: Fix MSI interrupt race [ Upstream commit 8edf5332c39340b9583cf9cba659eb7ec71f75b5 ] Without this commit, a PCIe hotplug port can stop generating interrupts on hotplug events, so device adds and removals will not be seen: The pciehp interrupt handler pciehp_isr() reads the Slot Status register and then writes back to it to clear the bits that caused the interrupt. If a different interrupt event bit gets set between the read and the write, pciehp_isr() returns without having cleared all of the interrupt event bits. If this happens when the MSI isn't masked (which by default it isn't in handle_edge_irq(), and which it will never be when MSI per-vector masking is not supported), we won't get any more hotplug interrupts from that device. That is expected behavior, according to the PCIe Base Spec r5.0, section 6.7.3.4, "Software Notification of Hot-Plug Events". Because the Presence Detect Changed and Data Link Layer State Changed event bits can both get set at nearly the same time when a device is added or removed, this is more likely to happen than it might seem. The issue was found (and can be reproduced rather easily) by connecting and disconnecting an NVMe storage device on at least one system model where the NVMe devices were being connected to an AMD PCIe port (PCI device 0x1022/0x1483). Fix the issue by modifying pciehp_isr() to loop back and re-read the Slot Status register immediately after writing to it, until it sees that all of the event status bits have been cleared. [lukas: drop loop count limitation, write "events" instead of "status", don't loop back in INTx and poll modes, tweak code comment & commit msg] Link: https://lore.kernel.org/r/78b4ced5072bfe6e369d20e8b47c279b8c7af12e.1582121613.git.lukas@wunner.de Tested-by: Stuart Hayes Signed-off-by: Stuart Hayes Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Reviewed-by: Joerg Roedel Signed-off-by: Sasha Levin commit ca767cf0152d18fc299cde85b18d1f46ac21e1ba Author: Andreas Steinmetz Date: Tue Mar 31 14:25:54 2020 +0200 ALSA: usb-audio: Fix case when USB MIDI interface has more than one extra endpoint descriptor [ Upstream commit 5c6cd7021a05a02fcf37f360592d7c18d4d807fb ] The Miditech MIDIFACE 16x16 (USB ID 1290:1749) has more than one extra endpoint descriptor. The first extra descriptor is: 0x06 0x30 0x00 0x00 0x00 0x00 As the code in snd_usbmidi_get_ms_info() looks only at the first extra descriptor to find USB_DT_CS_ENDPOINT the device as such is recognized but there is neither input nor output configured. The patch iterates through the extra descriptors to find the proper one. With this patch the device is correctly configured. Signed-off-by: Andreas Steinmetz Link: https://lore.kernel.org/r/1c3b431a86f69e1d60745b6110cdb93c299f120b.camel@domdv.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit af574e78e7e463be359bf014f53738afac47b582 Author: Liu Song Date: Thu Jan 16 23:36:07 2020 +0800 ubifs: Fix out-of-bounds memory access caused by abnormal value of node_len [ Upstream commit acc5af3efa303d5f36cc8c0f61716161f6ca1384 ] In “ubifs_check_node”, when the value of "node_len" is abnormal, the code will goto label of "out_len" for execution. Then, in the following "ubifs_dump_node", if inode type is "UBIFS_DATA_NODE", in "print_hex_dump", an out-of-bounds access may occur due to the wrong "ch->len". Therefore, when the value of "node_len" is abnormal, data length should to be adjusted to a reasonable safe range. At this time, structured data is not credible, so dump the corrupted data directly for analysis. Signed-off-by: Liu Song Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 49bc26b7653f8275945e4a2c22efe50fa4faddcd Author: Zhihao Cheng Date: Tue Mar 3 17:40:23 2020 +0800 ubifs: ubifs_add_orphan: Fix a memory leak bug [ Upstream commit 927cc5cec35f01fe4f8af0ba80830a90b0533983 ] Memory leak occurs when files with extended attributes are added to orphan list. Signed-off-by: Zhihao Cheng Fixes: 988bec41318f3fa897e2f8 ("ubifs: orphan: Handle xattrs like files") Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 17bc3bff02a75f35e009f714ce3db2cb08cc3a34 Author: Zhihao Cheng Date: Tue Mar 3 17:40:22 2020 +0800 ubifs: ubifs_jnl_write_inode: Fix a memory leak bug [ Upstream commit 81423c78551654953d746250f1721300b470be0e ] When inodes with extended attributes are evicted, xent is not freed in one exit branch. Signed-off-by: Zhihao Cheng Fixes: 9ca2d732644484488db3112 ("ubifs: Limit number of xattrs per inode") Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 535943c46dfcf32018d94da0b8c9ba470a9a8e71 Author: Mikel Rychliski Date: Wed Mar 18 22:16:23 2020 -0400 PCI: Use ioremap(), not phys_to_virt() for platform ROM [ Upstream commit 72e0ef0e5f067fd991f702f0b2635d911d0cf208 ] On some EFI systems, the video BIOS is provided by the EFI firmware. The boot stub code stores the physical address of the ROM image in pdev->rom. Currently we attempt to access this pointer using phys_to_virt(), which doesn't work with CONFIG_HIGHMEM. On these systems, attempting to load the radeon module on a x86_32 kernel can result in the following: BUG: unable to handle page fault for address: 3e8ed03c #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page *pde = 00000000 Oops: 0000 [#1] PREEMPT SMP CPU: 0 PID: 317 Comm: systemd-udevd Not tainted 5.6.0-rc3-next-20200228 #2 Hardware name: Apple Computer, Inc. MacPro1,1/Mac-F4208DC8, BIOS MP11.88Z.005C.B08.0707021221 07/02/07 EIP: radeon_get_bios+0x5ed/0xe50 [radeon] Code: 00 00 84 c0 0f 85 12 fd ff ff c7 87 64 01 00 00 00 00 00 00 8b 47 08 8b 55 b0 e8 1e 83 e1 d6 85 c0 74 1a 8b 55 c0 85 d2 74 13 <80> 38 55 75 0e 80 78 01 aa 0f 84 a4 03 00 00 8d 74 26 00 68 dc 06 EAX: 3e8ed03c EBX: 00000000 ECX: 3e8ed03c EDX: 00010000 ESI: 00040000 EDI: eec04000 EBP: eef3fc60 ESP: eef3fbe0 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010206 CR0: 80050033 CR2: 3e8ed03c CR3: 2ec77000 CR4: 000006d0 Call Trace: r520_init+0x26/0x240 [radeon] radeon_device_init+0x533/0xa50 [radeon] radeon_driver_load_kms+0x80/0x220 [radeon] drm_dev_register+0xa7/0x180 [drm] radeon_pci_probe+0x10f/0x1a0 [radeon] pci_device_probe+0xd4/0x140 Fix the issue by updating all drivers which can access a platform provided ROM. Instead of calling the helper function pci_platform_rom() which uses phys_to_virt(), call ioremap() directly on the pdev->rom. radeon_read_platform_bios() previously directly accessed an __iomem pointer. Avoid this by calling memcpy_fromio() instead of kmemdup(). pci_platform_rom() now has no remaining callers, so remove it. Link: https://lore.kernel.org/r/20200319021623.5426-1-mikel@mikelr.com Signed-off-by: Mikel Rychliski Signed-off-by: Bjorn Helgaas Acked-by: Alex Deucher Signed-off-by: Sasha Levin commit aa325ff72c80741673661b255b868b4c8cb2db66 Author: Qian Cai Date: Wed Mar 25 10:31:42 2020 -0400 netfilter: nf_tables: silence a RCU-list warning in nft_table_lookup() [ Upstream commit 0a6a9515fe390976cd762c52d8d4f446d7a14285 ] It is safe to traverse &net->nft.tables with &net->nft.commit_mutex held using list_for_each_entry_rcu(). Silence the PROVE_RCU_LIST false positive, WARNING: suspicious RCU usage net/netfilter/nf_tables_api.c:523 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by iptables/1384: #0: ffffffff9745c4a8 (&net->nft.commit_mutex){+.+.}, at: nf_tables_valid_genid+0x25/0x60 [nf_tables] Call Trace: dump_stack+0xa1/0xea lockdep_rcu_suspicious+0x103/0x10d nft_table_lookup.part.0+0x116/0x120 [nf_tables] nf_tables_newtable+0x12c/0x7d0 [nf_tables] nfnetlink_rcv_batch+0x559/0x1190 [nfnetlink] nfnetlink_rcv+0x1da/0x210 [nfnetlink] netlink_unicast+0x306/0x460 netlink_sendmsg+0x44b/0x770 ____sys_sendmsg+0x46b/0x4a0 ___sys_sendmsg+0x138/0x1a0 __sys_sendmsg+0xb6/0x130 __x64_sys_sendmsg+0x48/0x50 do_syscall_64+0x69/0xf4 entry_SYSCALL_64_after_hwframe+0x49/0xb3 Signed-off-by: Qian Cai Acked-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit cf2d7883e84ce250aa55c5c1a91100b103579a75 Author: Chuck Lever Date: Tue Mar 24 16:53:59 2020 -0400 svcrdma: Fix leak of transport addresses [ Upstream commit 1a33d8a284b1e85e03b8c7b1ea8fb985fccd1d71 ] Kernel memory leak detected: unreferenced object 0xffff888849cdf480 (size 8): comm "kworker/u8:3", pid 2086, jiffies 4297898756 (age 4269.856s) hex dump (first 8 bytes): 30 00 cd 49 88 88 ff ff 0..I.... backtrace: [<00000000acfc370b>] __kmalloc_track_caller+0x137/0x183 [<00000000a2724354>] kstrdup+0x2b/0x43 [<0000000082964f84>] xprt_rdma_format_addresses+0x114/0x17d [rpcrdma] [<00000000dfa6ed00>] xprt_setup_rdma_bc+0xc0/0x10c [rpcrdma] [<0000000073051a83>] xprt_create_transport+0x3f/0x1a0 [sunrpc] [<0000000053531a8e>] rpc_create+0x118/0x1cd [sunrpc] [<000000003a51b5f8>] setup_callback_client+0x1a5/0x27d [nfsd] [<000000001bd410af>] nfsd4_process_cb_update.isra.7+0x16c/0x1ac [nfsd] [<000000007f4bbd56>] nfsd4_run_cb_work+0x4c/0xbd [nfsd] [<0000000055c5586b>] process_one_work+0x1b2/0x2fe [<00000000b1e3e8ef>] worker_thread+0x1a6/0x25a [<000000005205fb78>] kthread+0xf6/0xfb [<000000006d2dc057>] ret_from_fork+0x3a/0x50 Introduce a call to xprt_rdma_free_addresses() similar to the way that the TCP backchannel releases a transport's peer address strings. Fixes: 5d252f90a800 ("svcrdma: Add class for RDMA backwards direction transport") Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 5f8174bfb9fffa5c5239cb25dbbafb0152d3810b Author: Christophe JAILLET Date: Fri Mar 27 17:15:39 2020 +0100 SUNRPC: Fix a potential buffer overflow in 'svc_print_xprts()' [ Upstream commit b25b60d7bfb02a74bc3c2d998e09aab159df8059 ] 'maxlen' is the total size of the destination buffer. There is only one caller and this value is 256. When we compute the size already used and what we would like to add in the buffer, the trailling NULL character is not taken into account. However, this trailling character will be added by the 'strcat' once we have checked that we have enough place. So, there is a off-by-one issue and 1 byte of the stack could be erroneously overwridden. Take into account the trailling NULL, when checking if there is enough place in the destination buffer. While at it, also replace a 'sprintf' by a safer 'snprintf', check for output truncation and avoid a superfluous 'strlen'. Fixes: dc9a16e49dbba ("svc: Add /proc/sys/sunrpc/transport files") Signed-off-by: Christophe JAILLET [ cel: very minor fix to documenting comment Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 4f7b6eef7921cf85a9261ffde57ac856aeed5f34 Author: Don Brace Date: Fri Mar 20 13:26:18 2020 -0500 scsi: hpsa: correct race condition in offload enabled [ Upstream commit 3e16e83a62edac7617bfd8dbb4e55d04ff6adbe1 ] Correct race condition where ioaccel is re-enabled before the raid_map is updated. For RAID_1, RAID_1ADM, and RAID 5/6 there is a BUG_ON called which is bad. - Change event thread to disable ioaccel only. Send all requests down the RAID path instead. - Have rescan thread handle offload_enable. - Since there is only one rescan allowed at a time, turning offload_enabled on/off should not be racy. Each handler queues up a rescan if one is already in progress. - For timing diagram, offload_enabled is initially off due to a change (transformation: splitmirror/remirror), ... otbe = offload_to_be_enabled oe = offload_enabled Time Event Rescan Completion Request Worker Worker Thread Thread ---- ------ ------ ---------- ------- T0 | | + UA | T1 | + rescan started | 0x3f | T2 + Event | | 0x0e | T3 + Ack msg | | | T4 | + if (!dev[i]->oe && | | T5 | | dev[i]->otbe) | | T6 | | get_raid_map | | T7 + otbe = 1 | | | T8 | | | | T9 | + oe = otbe | | T10 | | | + ioaccel request T11 * BUG_ON T0 - I/O completion with UA 0x3f 0x0e sets rescan flag. T1 - rescan worker thread starts a rescan. T2 - event comes in T3 - event thread starts and issues "Acknowledge" message ... T6 - rescan thread has bypassed code to reload new raid map. ... T7 - event thread runs and sets offload_to_be_enabled ... T9 - rescan thread turns on offload_enabled. T10- request comes in and goes down ioaccel path. T11- BUG_ON. - After the patch is applied, ioaccel_enabled can only be re-enabled in the re-scan thread. Link: https://lore.kernel.org/r/158472877894.14200.7077843399036368335.stgit@brunhilda Reviewed-by: Scott Teel Reviewed-by: Matt Perricone Reviewed-by: Scott Benesh Signed-off-by: Don Brace Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 6e3b662d86a5e981c74bf88b8f4cdc3305040dfc Author: Sergey Gorenko Date: Wed Mar 25 15:12:10 2020 +0000 IB/iser: Always check sig MR before putting it to the free pool [ Upstream commit 26e28deb813eed908cf31a6052870b6493ec0e86 ] libiscsi calls the check_protection transport handler only if SCSI-Respose is received. So, the handler is never called if iSCSI task is completed for some other reason like a timeout or error handling. And this behavior looks correct. But the iSER does not handle this case properly because it puts a non-checked signature MR to the free pool. Then the error occurs at reusing the MR because it is not allowed to invalidate a signature MR without checking. This commit adds an extra check to iser_unreg_mem_fastreg(), which is a part of the task cleanup flow. Now the signature MR is checked there if it is needed. Link: https://lore.kernel.org/r/20200325151210.1548-1-sergeygo@mellanox.com Signed-off-by: Sergey Gorenko Reviewed-by: Max Gurtovoy Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit d5e7198bcf7e7fe2726420e05df226838fa48dfc Author: Zhu Yanjun Date: Mon Mar 23 13:28:00 2020 +0200 RDMA/rxe: Set sys_image_guid to be aligned with HW IB devices [ Upstream commit d0ca2c35dd15a3d989955caec02beea02f735ee6 ] The RXE driver doesn't set sys_image_guid and user space applications see zeros. This causes to pyverbs tests to fail with the following traceback, because the IBTA spec requires to have valid sys_image_guid. Traceback (most recent call last): File "./tests/test_device.py", line 51, in test_query_device self.verify_device_attr(attr) File "./tests/test_device.py", line 74, in verify_device_attr assert attr.sys_image_guid != 0 In order to fix it, set sys_image_guid to be equal to node_guid. Before: 5: rxe0: ... node_guid 5054:00ff:feaa:5363 sys_image_guid 0000:0000:0000:0000 After: 5: rxe0: ... node_guid 5054:00ff:feaa:5363 sys_image_guid 5054:00ff:feaa:5363 Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://lore.kernel.org/r/20200323112800.1444784-1-leon@kernel.org Signed-off-by: Zhu Yanjun Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit f812e43e727ff69de9e14d5ad4a18029e2bf8fc7 Author: Darrick J. Wong Date: Tue Mar 24 23:03:24 2020 -0700 xfs: prohibit fs freezing when using empty transactions [ Upstream commit 27fb5a72f50aa770dd38b0478c07acacef97e3e7 ] I noticed that fsfreeze can take a very long time to freeze an XFS if there happens to be a GETFSMAP caller running in the background. I also happened to notice the following in dmesg: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 43492 at fs/xfs/xfs_super.c:853 xfs_quiesce_attr+0x83/0x90 [xfs] Modules linked in: xfs libcrc32c ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 ip_set_hash_ip ip_set_hash_net xt_tcpudp xt_set ip_set_hash_mac ip_set nfnetlink ip6table_filter ip6_tables bfq iptable_filter sch_fq_codel ip_tables x_tables nfsv4 af_packet [last unloaded: xfs] CPU: 2 PID: 43492 Comm: xfs_io Not tainted 5.6.0-rc4-djw #rc4 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.2-1ubuntu1 04/01/2014 RIP: 0010:xfs_quiesce_attr+0x83/0x90 [xfs] Code: 7c 07 00 00 85 c0 75 22 48 89 df 5b e9 96 c1 00 00 48 c7 c6 b0 2d 38 a0 48 89 df e8 57 64 ff ff 8b 83 7c 07 00 00 85 c0 74 de <0f> 0b 48 89 df 5b e9 72 c1 00 00 66 90 0f 1f 44 00 00 41 55 41 54 RSP: 0018:ffffc900030f3e28 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffff88802ac54000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff81e4a6f0 RDI: 00000000ffffffff RBP: ffff88807859f070 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000010 R12: 0000000000000000 R13: ffff88807859f388 R14: ffff88807859f4b8 R15: ffff88807859f5e8 FS: 00007fad1c6c0fc0(0000) GS:ffff88807e000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f0c7d237000 CR3: 0000000077f01003 CR4: 00000000001606a0 Call Trace: xfs_fs_freeze+0x25/0x40 [xfs] freeze_super+0xc8/0x180 do_vfs_ioctl+0x70b/0x750 ? __fget_files+0x135/0x210 ksys_ioctl+0x3a/0xb0 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x50/0x1a0 entry_SYSCALL_64_after_hwframe+0x49/0xbe These two things appear to be related. The assertion trips when another thread initiates a fsmap request (which uses an empty transaction) after the freezer waited for m_active_trans to hit zero but before the the freezer executes the WARN_ON just prior to calling xfs_log_quiesce. The lengthy delays in freezing happen because the freezer calls xfs_wait_buftarg to clean out the buffer lru list. Meanwhile, the GETFSMAP caller is continuing to grab and release buffers, which means that it can take a very long time for the buffer lru list to empty out. We fix both of these races by calling sb_start_write to obtain freeze protection while using empty transactions for GETFSMAP and for metadata scrubbing. The other two users occur during mount, during which time we cannot fs freeze. Signed-off-by: Darrick J. Wong Reviewed-by: Dave Chinner Signed-off-by: Sasha Levin commit 1ed8ad92378726b4f8e93abfa41086b08c0d8984 Author: Raveendran Somu Date: Wed Mar 25 03:20:25 2020 -0500 brcmfmac: Fix double freeing in the fmac usb data path [ Upstream commit 78179869dc3f5c0059bbf5d931a2717f1ad97ecd ] When the brcmf_fws_process_skb() fails to get hanger slot for queuing the skb, it tries to free the skb. But the caller brcmf_netdev_start_xmit() of that funciton frees the packet on error return value. This causes the double freeing and which caused the kernel crash. Signed-off-by: Raveendran Somu Signed-off-by: Chi-hsien Lin Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1585124429-97371-3-git-send-email-chi-hsien.lin@cypress.com Signed-off-by: Sasha Levin commit 9aca5e655a29f8ae0f762043e397422f5d8360cf Author: Israel Rukshin Date: Tue Mar 24 17:29:43 2020 +0200 nvme: Fix controller creation races with teardown flow [ Upstream commit ce1518139e6976cf19c133b555083354fdb629b8 ] Calling nvme_sysfs_delete() when the controller is in the middle of creation may cause several bugs. If the controller is in NEW state we remove delete_controller file and don't delete the controller. The user will not be able to use nvme disconnect command on that controller again, although the controller may be active. Other bugs may happen if the controller is in the middle of create_ctrl callback and nvme_do_delete_ctrl() starts. For example, freeing I/O tagset at nvme_do_delete_ctrl() before it was allocated at create_ctrl callback. To fix all those races don't allow the user to delete the controller before it was fully created. Signed-off-by: Israel Rukshin Reviewed-by: Max Gurtovoy Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 509730002abcfc4d15aea021ddceb0f6fe250b82 Author: Israel Rukshin Date: Tue Mar 24 17:29:41 2020 +0200 nvme: Fix ctrl use-after-free during sysfs deletion [ Upstream commit b780d7415aacec855e2f2370cbf98f918b224903 ] In case nvme_sysfs_delete() is called by the user before taking the ctrl reference count, the ctrl may be freed during the creation and cause the bug. Take the reference as soon as the controller is externally visible, which is done by cdev_device_add() in nvme_init_ctrl(). Also take the reference count at the core layer instead of taking it on each transport separately. Signed-off-by: Israel Rukshin Reviewed-by: Max Gurtovoy Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit eef1e9e876e9d25d44a9172fa78b8e4aec53d30c Author: John Meneghini Date: Thu Feb 20 10:05:38 2020 +0900 nvme-multipath: do not reset on unknown status [ Upstream commit 764e9332098c0e60251386a507fe46ac91276120 ] The nvme multipath error handling defaults to controller reset if the error is unknown. There are, however, no existing nvme status codes that indicate a reset should be used, and resetting causes unnecessary disruption to the rest of IO. Change nvme's error handling to first check if failover should happen. If not, let the normal error handling take over rather than reset the controller. Based-on-a-patch-by: Christoph Hellwig Reviewed-by: Hannes Reinecke Signed-off-by: John Meneghini Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit a48cf1c921a7072324b5ce245ccddffec4c970dd Author: Bernd Edlinger Date: Fri Mar 20 21:27:55 2020 +0100 perf: Use new infrastructure to fix deadlocks in execve [ Upstream commit 6914303824bb572278568330d72fc1f8f9814e67 ] This changes perf_event_set_clock to use the new exec_update_mutex instead of cred_guard_mutex. This should be safe, as the credentials are only used for reading. Signed-off-by: Bernd Edlinger Signed-off-by: Eric W. Biederman Signed-off-by: Sasha Levin commit ba7eb0e48e765a3325e651ed362b27980d8a3c3d Author: Bernd Edlinger Date: Fri Mar 20 21:27:41 2020 +0100 proc: io_accounting: Use new infrastructure to fix deadlocks in execve [ Upstream commit 76518d3798855242817e8a8ed76b2d72f4415624 ] This changes do_io_accounting to use the new exec_update_mutex instead of cred_guard_mutex. This fixes possible deadlocks when the trace is accessing /proc/$pid/io for instance. This should be safe, as the credentials are only used for reading. Signed-off-by: Bernd Edlinger Signed-off-by: Eric W. Biederman Signed-off-by: Sasha Levin commit 4301db49e5569fbb729769bfaf9b21b858330543 Author: Bernd Edlinger Date: Fri Mar 20 21:27:24 2020 +0100 proc: Use new infrastructure to fix deadlocks in execve [ Upstream commit 2db9dbf71bf98d02a0bf33e798e5bfd2a9944696 ] This changes lock_trace to use the new exec_update_mutex instead of cred_guard_mutex. This fixes possible deadlocks when the trace is accessing /proc/$pid/stack for instance. This should be safe, as the credentials are only used for reading, and task->mm is updated on execve under the new exec_update_mutex. Signed-off-by: Bernd Edlinger Signed-off-by: Eric W. Biederman Signed-off-by: Sasha Levin commit 0cd97836869e9792cd66a2223b978f0148b46a12 Author: Bernd Edlinger Date: Fri Mar 20 21:27:05 2020 +0100 kernel/kcmp.c: Use new infrastructure to fix deadlocks in execve [ Upstream commit 454e3126cb842388e22df6b3ac3da44062c00765 ] This changes kcmp_epoll_target to use the new exec_update_mutex instead of cred_guard_mutex. This should be safe, as the credentials are only used for reading, and furthermore ->mm and ->sighand are updated on execve, but only under the new exec_update_mutex. Signed-off-by: Bernd Edlinger Signed-off-by: Eric W. Biederman Signed-off-by: Sasha Levin commit 2f7a0de4e5da7223902d48a30833bc67ef45a02b Author: Bernd Edlinger Date: Fri Mar 20 21:26:19 2020 +0100 selftests/ptrace: add test cases for dead-locks [ Upstream commit 2de4e82318c7f9d34f4b08599a612cd4cd10bf0b ] This adds test cases for ptrace deadlocks. Additionally fixes a compile problem in get_syscall_info.c, observed with gcc-4.8.4: get_syscall_info.c: In function 'get_syscall_info': get_syscall_info.c:93:3: error: 'for' loop initial declarations are only allowed in C99 mode for (unsigned int i = 0; i < ARRAY_SIZE(args); ++i) { ^ get_syscall_info.c:93:3: note: use option -std=c99 or -std=gnu99 to compile your code Signed-off-by: Bernd Edlinger Reviewed-by: Kees Cook Signed-off-by: Eric W. Biederman Signed-off-by: Sasha Levin commit d8d15a4c445a5d0d13d76729b4ee7639a1deeaa9 Author: Bernd Edlinger Date: Fri Mar 20 21:26:04 2020 +0100 exec: Fix a deadlock in strace [ Upstream commit 3e74fabd39710ee29fa25618d2c2b40cfa7d76c7 ] This fixes a deadlock in the tracer when tracing a multi-threaded application that calls execve while more than one thread are running. I observed that when running strace on the gcc test suite, it always blocks after a while, when expect calls execve, because other threads have to be terminated. They send ptrace events, but the strace is no longer able to respond, since it is blocked in vm_access. The deadlock is always happening when strace needs to access the tracees process mmap, while another thread in the tracee starts to execve a child process, but that cannot continue until the PTRACE_EVENT_EXIT is handled and the WIFEXITED event is received: strace D 0 30614 30584 0x00000000 Call Trace: __schedule+0x3ce/0x6e0 schedule+0x5c/0xd0 schedule_preempt_disabled+0x15/0x20 __mutex_lock.isra.13+0x1ec/0x520 __mutex_lock_killable_slowpath+0x13/0x20 mutex_lock_killable+0x28/0x30 mm_access+0x27/0xa0 process_vm_rw_core.isra.3+0xff/0x550 process_vm_rw+0xdd/0xf0 __x64_sys_process_vm_readv+0x31/0x40 do_syscall_64+0x64/0x220 entry_SYSCALL_64_after_hwframe+0x44/0xa9 expect D 0 31933 30876 0x80004003 Call Trace: __schedule+0x3ce/0x6e0 schedule+0x5c/0xd0 flush_old_exec+0xc4/0x770 load_elf_binary+0x35a/0x16c0 search_binary_handler+0x97/0x1d0 __do_execve_file.isra.40+0x5d4/0x8a0 __x64_sys_execve+0x49/0x60 do_syscall_64+0x64/0x220 entry_SYSCALL_64_after_hwframe+0x44/0xa9 This changes mm_access to use the new exec_update_mutex instead of cred_guard_mutex. This patch is based on the following patch by Eric W. Biederman: "[PATCH 0/5] Infrastructure to allow fixing exec deadlocks" Link: https://lore.kernel.org/lkml/87v9ne5y4y.fsf_-_@x220.int.ebiederm.org/ Signed-off-by: Bernd Edlinger Reviewed-by: Kees Cook Signed-off-by: Eric W. Biederman Signed-off-by: Sasha Levin commit b796d94921ce2adffcb30d25381bcb88a9d77f60 Author: Eric W. Biederman Date: Wed Mar 25 10:03:36 2020 -0500 exec: Add exec_update_mutex to replace cred_guard_mutex [ Upstream commit eea9673250db4e854e9998ef9da6d4584857f0ea ] The cred_guard_mutex is problematic as it is held over possibly indefinite waits for userspace. The possible indefinite waits for userspace that I have identified are: The cred_guard_mutex is held in PTRACE_EVENT_EXIT waiting for the tracer. The cred_guard_mutex is held over "put_user(0, tsk->clear_child_tid)" in exit_mm(). The cred_guard_mutex is held over "get_user(futex_offset, ...") in exit_robust_list. The cred_guard_mutex held over copy_strings. The functions get_user and put_user can trigger a page fault which can potentially wait indefinitely in the case of userfaultfd or if userspace implements part of the page fault path. In any of those cases the userspace process that the kernel is waiting for might make a different system call that winds up taking the cred_guard_mutex and result in deadlock. Holding a mutex over any of those possibly indefinite waits for userspace does not appear necessary. Add exec_update_mutex that will just cover updating the process during exec where the permissions and the objects pointed to by the task struct may be out of sync. The plan is to switch the users of cred_guard_mutex to exec_update_mutex one by one. This lets us move forward while still being careful and not introducing any regressions. Link: https://lore.kernel.org/lkml/20160921152946.GA24210@dhcp22.suse.cz/ Link: https://lore.kernel.org/lkml/AM6PR03MB5170B06F3A2B75EFB98D071AE4E60@AM6PR03MB5170.eurprd03.prod.outlook.com/ Link: https://lore.kernel.org/linux-fsdevel/20161102181806.GB1112@redhat.com/ Link: https://lore.kernel.org/lkml/20160923095031.GA14923@redhat.com/ Link: https://lore.kernel.org/lkml/20170213141452.GA30203@redhat.com/ Ref: 45c1a159b85b ("Add PTRACE_O_TRACEVFORKDONE and PTRACE_O_TRACEEXIT facilities.") Ref: 456f17cd1a28 ("[PATCH] user-vm-unlock-2.5.31-A2") Reviewed-by: Kirill Tkhai Signed-off-by: "Eric W. Biederman" Signed-off-by: Bernd Edlinger Signed-off-by: Eric W. Biederman Signed-off-by: Sasha Levin commit 32d9453c208ce13ec585aa91634b05bb0e67f770 Author: Gabriel Ravier Date: Thu Mar 12 15:50:21 2020 +0100 tools: gpio-hammer: Avoid potential overflow in main [ Upstream commit d1ee7e1f5c9191afb69ce46cc7752e4257340a31 ] If '-o' was used more than 64 times in a single invocation of gpio-hammer, this could lead to an overflow of the 'lines' array. This commit fixes this by avoiding the overflow and giving a proper diagnostic back to the user Signed-off-by: Gabriel Ravier Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 3b63e4b7045b8a2b5a44b05cd25a86ee459b0d0a Author: Pratik Rajesh Sampat Date: Mon Mar 16 19:27:43 2020 +0530 cpufreq: powernv: Fix frame-size-overflow in powernv_cpufreq_work_fn [ Upstream commit d95fe371ecd28901f11256c610b988ed44e36ee2 ] The patch avoids allocating cpufreq_policy on stack hence fixing frame size overflow in 'powernv_cpufreq_work_fn' Fixes: 227942809b52 ("cpufreq: powernv: Restore cpu frequency to policy->cur on unthrottling") Signed-off-by: Pratik Rajesh Sampat Reviewed-by: Daniel Axtens Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200316135743.57735-1-psampat@linux.ibm.com Signed-off-by: Sasha Levin commit 1ad72297146dd59bca829243841da606e6f28727 Author: Andre Przywara Date: Tue Mar 24 13:23:36 2020 +0000 net: axienet: Propagate failure of DMA descriptor setup [ Upstream commit ee44d0b78839b21591501424fd3cb3648cc803b5 ] When we fail allocating the DMA buffers in axienet_dma_bd_init(), we report this error, but carry on with initialisation nevertheless. This leads to a kernel panic when the driver later wants to send a packet, as it uses uninitialised data structures. Make the axienet_device_reset() routine return an error value, as it contains the DMA buffer initialisation. Make sure we propagate the error up the chain and eventually fail the driver initialisation, to avoid relying on non-initialised buffers. Signed-off-by: Andre Przywara Reviewed-by: Radhey Shyam Pandey Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 468f2bc2bb5b1f43e0ac2f23825c46a082496a97 Author: Andre Przywara Date: Tue Mar 24 13:23:35 2020 +0000 net: axienet: Convert DMA error handler to a work queue [ Upstream commit 24201a64770afe2e17050b2ab9e8c0e24e9c23b2 ] The DMA error handler routine is currently a tasklet, scheduled to run after the DMA error IRQ was handled. However it needs to take the MDIO mutex, which is not allowed to do in a tasklet. A kernel (with debug options) complains consequently: [ 614.050361] net eth0: DMA Tx error 0x174019 [ 614.064002] net eth0: Current BD is at: 0x8f84aa0ce [ 614.080195] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:935 [ 614.109484] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 40, name: kworker/u4:4 [ 614.135428] 3 locks held by kworker/u4:4/40: [ 614.149075] #0: ffff000879863328 ((wq_completion)rpciod){....}, at: process_one_work+0x1f0/0x6a8 [ 614.177528] #1: ffff80001251bdf8 ((work_completion)(&task->u.tk_work)){....}, at: process_one_work+0x1f0/0x6a8 [ 614.209033] #2: ffff0008784e0110 (sk_lock-AF_INET-RPC){....}, at: tcp_sendmsg+0x24/0x58 [ 614.235429] CPU: 0 PID: 40 Comm: kworker/u4:4 Not tainted 5.6.0-rc3-00926-g4a165a9d5921 #26 [ 614.260854] Hardware name: ARM Test FPGA (DT) [ 614.274734] Workqueue: rpciod rpc_async_schedule [ 614.289022] Call trace: [ 614.296871] dump_backtrace+0x0/0x1a0 [ 614.308311] show_stack+0x14/0x20 [ 614.318751] dump_stack+0xbc/0x100 [ 614.329403] ___might_sleep+0xf0/0x140 [ 614.341018] __might_sleep+0x4c/0x80 [ 614.352201] __mutex_lock+0x5c/0x8a8 [ 614.363348] mutex_lock_nested+0x1c/0x28 [ 614.375654] axienet_dma_err_handler+0x38/0x388 [ 614.389999] tasklet_action_common.isra.15+0x160/0x1a8 [ 614.405894] tasklet_action+0x24/0x30 [ 614.417297] efi_header_end+0xe0/0x494 [ 614.429020] irq_exit+0xd0/0xd8 [ 614.439047] __handle_domain_irq+0x60/0xb0 [ 614.451877] gic_handle_irq+0xdc/0x2d0 [ 614.463486] el1_irq+0xcc/0x180 [ 614.473451] __tcp_transmit_skb+0x41c/0xb58 [ 614.486513] tcp_write_xmit+0x224/0x10a0 [ 614.498792] __tcp_push_pending_frames+0x38/0xc8 [ 614.513126] tcp_rcv_established+0x41c/0x820 [ 614.526301] tcp_v4_do_rcv+0x8c/0x218 [ 614.537784] __release_sock+0x5c/0x108 [ 614.549466] release_sock+0x34/0xa0 [ 614.560318] tcp_sendmsg+0x40/0x58 [ 614.571053] inet_sendmsg+0x40/0x68 [ 614.582061] sock_sendmsg+0x18/0x30 [ 614.593074] xs_sendpages+0x218/0x328 [ 614.604506] xs_tcp_send_request+0xa0/0x1b8 [ 614.617461] xprt_transmit+0xc8/0x4f0 [ 614.628943] call_transmit+0x8c/0xa0 [ 614.640028] __rpc_execute+0xbc/0x6f8 [ 614.651380] rpc_async_schedule+0x28/0x48 [ 614.663846] process_one_work+0x298/0x6a8 [ 614.676299] worker_thread+0x40/0x490 [ 614.687687] kthread+0x134/0x138 [ 614.697804] ret_from_fork+0x10/0x18 [ 614.717319] xilinx_axienet 7fe00000.ethernet eth0: Link is Down [ 615.748343] xilinx_axienet 7fe00000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off Since tasklets are not really popular anymore anyway, lets convert this over to a work queue, which can sleep and thus can take the MDIO mutex. Signed-off-by: Andre Przywara Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 79f60d5bd0dd264b52bcfd2e604643edff13c776 Author: Christophe JAILLET Date: Tue Mar 24 08:03:19 2020 +0100 perf cpumap: Fix snprintf overflow check [ Upstream commit d74b181a028bb5a468f0c609553eff6a8fdf4887 ] 'snprintf' returns the number of characters which would be generated for the given input. If the returned value is *greater than* or equal to the buffer size, it means that the output has been truncated. Fix the overflow test accordingly. Fixes: 7780c25bae59f ("perf tools: Allow ability to map cpus to nodes easily") Fixes: 92a7e1278005b ("perf cpumap: Add cpu__max_present_cpu()") Signed-off-by: Christophe JAILLET Suggested-by: David Laight Cc: Alexander Shishkin Cc: Don Zickus Cc: He Zhe Cc: Jan Stancek Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: kernel-janitors@vger.kernel.org Link: http://lore.kernel.org/lkml/20200324070319.10901-1-christophe.jaillet@wanadoo.fr Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 47e276e1c40ebbda39143a7ac87254d5078cb9a9 Author: Vignesh Raghavendra Date: Thu Mar 19 16:33:39 2020 +0530 serial: 8250: 8250_omap: Terminate DMA before pushing data on RX timeout [ Upstream commit 7cf4df30a98175033e9849f7f16c46e96ba47f41 ] Terminate and flush DMA internal buffers, before pushing RX data to higher layer. Otherwise, this will lead to data corruption, as driver would end up pushing stale buffer data to higher layer while actual data is still stuck inside DMA hardware and has yet not arrived at the memory. While at that, replace deprecated dmaengine_terminate_all() with dmaengine_terminate_async(). Signed-off-by: Vignesh Raghavendra Link: https://lore.kernel.org/r/20200319110344.21348-2-vigneshr@ti.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 09a2cf6771059fbc49f26bc26b1d582e04a75ea6 Author: Peter Ujfalusi Date: Fri Mar 20 14:52:00 2020 +0200 serial: 8250_omap: Fix sleeping function called from invalid context during probe [ Upstream commit 4ce35a3617c0ac758c61122b2218b6c8c9ac9398 ] When booting j721e the following bug is printed: [ 1.154821] BUG: sleeping function called from invalid context at kernel/sched/completion.c:99 [ 1.154827] in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 12, name: kworker/0:1 [ 1.154832] 3 locks held by kworker/0:1/12: [ 1.154836] #0: ffff000840030728 ((wq_completion)events){+.+.}, at: process_one_work+0x1d4/0x6e8 [ 1.154852] #1: ffff80001214fdd8 (deferred_probe_work){+.+.}, at: process_one_work+0x1d4/0x6e8 [ 1.154860] #2: ffff00084060b170 (&dev->mutex){....}, at: __device_attach+0x38/0x138 [ 1.154872] irq event stamp: 63096 [ 1.154881] hardirqs last enabled at (63095): [] _raw_spin_unlock_irqrestore+0x70/0x78 [ 1.154887] hardirqs last disabled at (63096): [] _raw_spin_lock_irqsave+0x28/0x80 [ 1.154893] softirqs last enabled at (62254): [] _stext+0x488/0x564 [ 1.154899] softirqs last disabled at (62247): [] irq_exit+0x114/0x140 [ 1.154906] CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.6.0-rc6-next-20200318-00094-g45e4089b0bd3 #221 [ 1.154911] Hardware name: Texas Instruments K3 J721E SoC (DT) [ 1.154917] Workqueue: events deferred_probe_work_func [ 1.154923] Call trace: [ 1.154928] dump_backtrace+0x0/0x190 [ 1.154933] show_stack+0x14/0x20 [ 1.154940] dump_stack+0xe0/0x148 [ 1.154946] ___might_sleep+0x150/0x1f0 [ 1.154952] __might_sleep+0x4c/0x80 [ 1.154957] wait_for_completion_timeout+0x40/0x140 [ 1.154964] ti_sci_set_device_state+0xa0/0x158 [ 1.154969] ti_sci_cmd_get_device_exclusive+0x14/0x20 [ 1.154977] ti_sci_dev_start+0x34/0x50 [ 1.154984] genpd_runtime_resume+0x78/0x1f8 [ 1.154991] __rpm_callback+0x3c/0x140 [ 1.154996] rpm_callback+0x20/0x80 [ 1.155001] rpm_resume+0x568/0x758 [ 1.155007] __pm_runtime_resume+0x44/0xb0 [ 1.155013] omap8250_probe+0x2b4/0x508 [ 1.155019] platform_drv_probe+0x50/0xa0 [ 1.155023] really_probe+0xd4/0x318 [ 1.155028] driver_probe_device+0x54/0xe8 [ 1.155033] __device_attach_driver+0x80/0xb8 [ 1.155039] bus_for_each_drv+0x74/0xc0 [ 1.155044] __device_attach+0xdc/0x138 [ 1.155049] device_initial_probe+0x10/0x18 [ 1.155053] bus_probe_device+0x98/0xa0 [ 1.155058] deferred_probe_work_func+0x74/0xb0 [ 1.155063] process_one_work+0x280/0x6e8 [ 1.155068] worker_thread+0x48/0x430 [ 1.155073] kthread+0x108/0x138 [ 1.155079] ret_from_fork+0x10/0x18 To fix the bug we need to first call pm_runtime_enable() prior to any pm_runtime calls. Reported-by: Tomi Valkeinen Signed-off-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20200320125200.6772-1-peter.ujfalusi@ti.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 93ec0b575aca57e663e0ba881e65aa06df2b1a2d Author: Vignesh Raghavendra Date: Thu Mar 19 16:02:29 2020 +0530 serial: 8250_port: Don't service RX FIFO if throttled [ Upstream commit f19c3f6c8109b8bab000afd35580929958e087a9 ] When port's throttle callback is called, it should stop pushing any more data into TTY buffer to avoid buffer overflow. This means driver has to stop HW from receiving more data and assert the HW flow control. For UARTs with auto HW flow control (such as 8250_omap) manual assertion of flow control line is not possible and only way is to allow RX FIFO to fill up, thus trigger auto HW flow control logic. Therefore make sure that 8250 generic IRQ handler does not drain data when port is stopped (i.e UART_LSR_DR is unset in read_status_mask). Not servicing, RX FIFO would trigger auto HW flow control when FIFO occupancy reaches preset threshold, thus halting RX. Since, error conditions in UART_LSR register are cleared just by reading the register, data has to be drained in case there are FIFO errors, else error information will lost. Signed-off-by: Vignesh Raghavendra Link: https://lore.kernel.org/r/20200319103230.16867-2-vigneshr@ti.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0557e5f8d69ca1080cf5727c43c58851e2a644ca Author: Heiner Kallweit Date: Sun Mar 22 19:03:56 2020 +0100 r8169: improve RTL8168b FIFO overflow workaround [ Upstream commit 6b02e407cbf8d421477ebb7792cd6380affcd313 ] So far only the reset bit it set, but the handler executing the reset is not scheduled. Therefore nothing will happen until some other action schedules the handler. Improve this by ensuring that the handler is scheduled. Signed-off-by: Heiner Kallweit Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5dc170aee1d10c9ec53b00f23c986ded9af62739 Author: Josef Bacik Date: Wed Mar 4 11:18:26 2020 -0500 btrfs: free the reloc_control in a consistent way [ Upstream commit 1a0afa0ecfc4dbc8d7583d03cafd3f68f781df0c ] If we have an error while processing the reloc roots we could leak roots that were added to rc->reloc_roots before we hit the error. We could have also not removed the reloc tree mapping from our rb_tree, so clean up any remaining nodes in the reloc root rb_tree. Signed-off-by: Josef Bacik Reviewed-by: David Sterba [ use rbtree_postorder_for_each_entry_safe ] Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit c88596d593abaaa889c127fdd9fcc46f8178785f Author: Josef Bacik Date: Wed Mar 4 11:18:24 2020 -0500 btrfs: do not init a reloc root if we aren't relocating [ Upstream commit 2abc726ab4b83db774e315c660ab8da21477092f ] We previously were checking if the root had a dead root before accessing root->reloc_root in order to avoid a use-after-free type bug. However this scenario happens after we've unset the reloc control, so we would have been saved if we'd simply checked for fs_info->reloc_control. At this point during relocation we no longer need to be creating new reloc roots, so simply move this check above the reloc_root checks to avoid any future races and confusion. Reviewed-by: Qu Wenruo Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 98c921e6be068a0759567eea5dbaaeabb0cdaee4 Author: Ian Rogers Date: Sat Mar 14 10:03:56 2020 -0700 perf parse-events: Fix 3 use after frees found with clang ASAN [ Upstream commit d4953f7ef1a2e87ef732823af35361404d13fea8 ] Reproducible with a clang asan build and then running perf test in particular 'Parse event definition strings'. Signed-off-by: Ian Rogers Acked-by: Jiri Olsa Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Andi Kleen Cc: Leo Yan Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Stephane Eranian Cc: clang-built-linux@googlegroups.com Link: http://lore.kernel.org/lkml/20200314170356.62914-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 048892dfab4d51813f7cf23064c66f3d245dbfe5 Author: He Zhe Date: Fri Mar 20 15:06:07 2020 +0800 KVM: LAPIC: Mark hrtimer for period or oneshot mode to expire in hard interrupt context [ Upstream commit edec6e015a02003c2af0ce82c54ea016b5a9e3f0 ] apic->lapic_timer.timer was initialized with HRTIMER_MODE_ABS_HARD but started later with HRTIMER_MODE_ABS, which may cause the following warning in PREEMPT_RT kernel. WARNING: CPU: 1 PID: 2957 at kernel/time/hrtimer.c:1129 hrtimer_start_range_ns+0x348/0x3f0 CPU: 1 PID: 2957 Comm: qemu-system-x86 Not tainted 5.4.23-rt11 #1 Hardware name: Supermicro SYS-E300-9A-8C/A2SDi-8C-HLN4F, BIOS 1.1a 09/18/2018 RIP: 0010:hrtimer_start_range_ns+0x348/0x3f0 Code: 4d b8 0f 94 c1 0f b6 c9 e8 35 f1 ff ff 4c 8b 45 b0 e9 3b fd ff ff e8 d7 3f fa ff 48 98 4c 03 34 c5 a0 26 bf 93 e9 a1 fd ff ff <0f> 0b e9 fd fc ff ff 65 8b 05 fa b7 90 6d 89 c0 48 0f a3 05 60 91 RSP: 0018:ffffbc60026ffaf8 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffff9d81657d4110 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000006cc7987bcf RDI: ffff9d81657d4110 RBP: ffffbc60026ffb58 R08: 0000000000000001 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000000 R12: 0000006cc7987bcf R13: 0000000000000000 R14: 0000006cc7987bcf R15: ffffbc60026d6a00 FS: 00007f401daed700(0000) GS:ffff9d81ffa40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000ffffffff CR3: 0000000fa7574000 CR4: 00000000003426e0 Call Trace: ? kvm_release_pfn_clean+0x22/0x60 [kvm] start_sw_timer+0x85/0x230 [kvm] ? vmx_vmexit+0x1b/0x30 [kvm_intel] kvm_lapic_switch_to_sw_timer+0x72/0x80 [kvm] vmx_pre_block+0x1cb/0x260 [kvm_intel] ? vmx_vmexit+0xf/0x30 [kvm_intel] ? vmx_vmexit+0x1b/0x30 [kvm_intel] ? vmx_vmexit+0xf/0x30 [kvm_intel] ? vmx_vmexit+0x1b/0x30 [kvm_intel] ? vmx_vmexit+0xf/0x30 [kvm_intel] ? vmx_vmexit+0x1b/0x30 [kvm_intel] ? vmx_vmexit+0xf/0x30 [kvm_intel] ? vmx_vmexit+0xf/0x30 [kvm_intel] ? vmx_vmexit+0x1b/0x30 [kvm_intel] ? vmx_vmexit+0xf/0x30 [kvm_intel] ? vmx_vmexit+0x1b/0x30 [kvm_intel] ? vmx_vmexit+0xf/0x30 [kvm_intel] ? vmx_vmexit+0x1b/0x30 [kvm_intel] ? vmx_vmexit+0xf/0x30 [kvm_intel] ? vmx_vmexit+0x1b/0x30 [kvm_intel] ? vmx_vmexit+0xf/0x30 [kvm_intel] ? vmx_sync_pir_to_irr+0x9e/0x100 [kvm_intel] ? kvm_apic_has_interrupt+0x46/0x80 [kvm] kvm_arch_vcpu_ioctl_run+0x85b/0x1fa0 [kvm] ? _raw_spin_unlock_irqrestore+0x18/0x50 ? _copy_to_user+0x2c/0x30 kvm_vcpu_ioctl+0x235/0x660 [kvm] ? rt_spin_unlock+0x2c/0x50 do_vfs_ioctl+0x3e4/0x650 ? __fget+0x7a/0xa0 ksys_ioctl+0x67/0x90 __x64_sys_ioctl+0x1a/0x20 do_syscall_64+0x4d/0x120 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f4027cc54a7 Code: 00 00 90 48 8b 05 e9 59 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d b9 59 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007f401dae9858 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00005558bd029690 RCX: 00007f4027cc54a7 RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 000000000000000d RBP: 00007f4028b72000 R08: 00005558bc829ad0 R09: 00000000ffffffff R10: 00005558bcf90ca0 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 00005558bce1c840 --[ end trace 0000000000000002 ]-- Signed-off-by: He Zhe Message-Id: <1584687967-332859-1-git-send-email-zhe.he@windriver.com> Reviewed-by: Wanpeng Li Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 157ff88660c8d8c9e100961605d9ed59643baaad Author: Niklas Söderlund Date: Tue Mar 10 12:47:09 2020 +0100 thermal: rcar_thermal: Handle probe error gracefully [ Upstream commit 39056e8a989ef52486e063e34b4822b341e47b0e ] If the common register memory resource is not available the driver needs to fail gracefully to disable PM. Instead of returning the error directly store it in ret and use the already existing error path. Signed-off-by: Niklas Söderlund Reviewed-by: Geert Uytterhoeven Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20200310114709.1483860-1-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Sasha Levin commit e978d00a3d164610cc0f8ba9a68c8da2a53601b8 Author: Nathan Chancellor Date: Wed Feb 19 22:10:12 2020 -0700 tracing: Use address-of operator on section symbols [ Upstream commit bf2cbe044da275021b2de5917240411a19e5c50d ] Clang warns: ../kernel/trace/trace.c:9335:33: warning: array comparison always evaluates to true [-Wtautological-compare] if (__stop___trace_bprintk_fmt != __start___trace_bprintk_fmt) ^ 1 warning generated. These are not true arrays, they are linker defined symbols, which are just addresses. Using the address of operator silences the warning and does not change the runtime result of the check (tested with some print statements compiled in with clang + ld.lld and gcc + ld.bfd in QEMU). Link: http://lkml.kernel.org/r/20200220051011.26113-1-natechancellor@gmail.com Link: https://github.com/ClangBuiltLinux/linux/issues/893 Suggested-by: Nick Desaulniers Signed-off-by: Nathan Chancellor Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit cb9841c5119c9592ad0bc287a27358e98bf86987 Author: Jordan Crouse Date: Fri Feb 14 11:36:44 2020 -0700 drm/msm/a5xx: Always set an OPP supported hardware value [ Upstream commit 0478b4fc5f37f4d494245fe7bcce3f531cf380e9 ] If the opp table specifies opp-supported-hw as a property but the driver has not set a supported hardware value the OPP subsystem will reject all the table entries. Set a "default" value that will match the default table entries but not conflict with any possible real bin values. Also fix a small memory leak and free the buffer allocated by nvmem_cell_read(). Signed-off-by: Jordan Crouse Reviewed-by: Eric Anholt Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 8db4810dd5ccc084286518b7a486b56b049db9a4 Author: Pavel Machek Date: Mon Mar 9 11:14:10 2020 +0100 drm/msm: fix leaks if initialization fails [ Upstream commit 66be340f827554cb1c8a1ed7dea97920b4085af2 ] We should free resources in unlikely case of allocation failure. Signed-off-by: Pavel Machek Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 5d09e3edf5d9b93b72f664aa2c54949558ee383d Author: Gustavo Romero Date: Fri Feb 21 11:29:50 2020 -0500 KVM: PPC: Book3S HV: Treat TM-related invalid form instructions on P9 like the valid ones [ Upstream commit 1dff3064c764b5a51c367b949b341d2e38972bec ] On P9 DD2.2 due to a CPU defect some TM instructions need to be emulated by KVM. This is handled at first by the hardware raising a softpatch interrupt when certain TM instructions that need KVM assistance are executed in the guest. Althought some TM instructions per Power ISA are invalid forms they can raise a softpatch interrupt too. For instance, 'tresume.' instruction as defined in the ISA must have bit 31 set (1), but an instruction that matches 'tresume.' PO and XO opcode fields but has bit 31 not set (0), like 0x7cfe9ddc, also raises a softpatch interrupt. Similarly for 'treclaim.' and 'trechkpt.' instructions with bit 31 = 0, i.e. 0x7c00075c and 0x7c0007dc, respectively. Hence, if a code like the following is executed in the guest it will raise a softpatch interrupt just like a 'tresume.' when the TM facility is enabled ('tabort. 0' in the example is used only to enable the TM facility): int main() { asm("tabort. 0; .long 0x7cfe9ddc;"); } Currently in such a case KVM throws a complete trace like: [345523.705984] WARNING: CPU: 24 PID: 64413 at arch/powerpc/kvm/book3s_hv_tm.c:211 kvmhv_p9_tm_emulation+0x68/0x620 [kvm_hv] [345523.705985] Modules linked in: kvm_hv(E) xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp ip6table_mangle ip6table_nat iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter bridge stp llc sch_fq_codel ipmi_powernv at24 vmx_crypto ipmi_devintf ipmi_msghandler ibmpowernv uio_pdrv_genirq kvm opal_prd uio leds_powernv ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx libcrc32c xor raid6_pq raid1 raid0 multipath linear tg3 crct10dif_vpmsum crc32c_vpmsum ipr [last unloaded: kvm_hv] [345523.706030] CPU: 24 PID: 64413 Comm: CPU 0/KVM Tainted: G W E 5.5.0+ #1 [345523.706031] NIP: c0080000072cb9c0 LR: c0080000072b5e80 CTR: c0080000085c7850 [345523.706034] REGS: c000000399467680 TRAP: 0700 Tainted: G W E (5.5.0+) [345523.706034] MSR: 900000010282b033 CR: 24022428 XER: 00000000 [345523.706042] CFAR: c0080000072b5e7c IRQMASK: 0 GPR00: c0080000072b5e80 c000000399467910 c0080000072db500 c000000375ccc720 GPR04: c000000375ccc720 00000003fbec0000 0000a10395dda5a6 0000000000000000 GPR08: 000000007cfe9ddc 7cfe9ddc000005dc 7cfe9ddc7c0005dc c0080000072cd530 GPR12: c0080000085c7850 c0000003fffeb800 0000000000000001 00007dfb737f0000 GPR16: c0002001edcca558 0000000000000000 0000000000000000 0000000000000001 GPR20: c000000001b21258 c0002001edcca558 0000000000000018 0000000000000000 GPR24: 0000000001000000 ffffffffffffffff 0000000000000001 0000000000001500 GPR28: c0002001edcc4278 c00000037dd80000 800000050280f033 c000000375ccc720 [345523.706062] NIP [c0080000072cb9c0] kvmhv_p9_tm_emulation+0x68/0x620 [kvm_hv] [345523.706065] LR [c0080000072b5e80] kvmppc_handle_exit_hv.isra.53+0x3e8/0x798 [kvm_hv] [345523.706066] Call Trace: [345523.706069] [c000000399467910] [c000000399467940] 0xc000000399467940 (unreliable) [345523.706071] [c000000399467950] [c000000399467980] 0xc000000399467980 [345523.706075] [c0000003994679f0] [c0080000072bd1c4] kvmhv_run_single_vcpu+0xa1c/0xb80 [kvm_hv] [345523.706079] [c000000399467ac0] [c0080000072bd8e0] kvmppc_vcpu_run_hv+0x5b8/0xb00 [kvm_hv] [345523.706087] [c000000399467b90] [c0080000085c93cc] kvmppc_vcpu_run+0x34/0x48 [kvm] [345523.706095] [c000000399467bb0] [c0080000085c582c] kvm_arch_vcpu_ioctl_run+0x244/0x420 [kvm] [345523.706101] [c000000399467c40] [c0080000085b7498] kvm_vcpu_ioctl+0x3d0/0x7b0 [kvm] [345523.706105] [c000000399467db0] [c0000000004adf9c] ksys_ioctl+0x13c/0x170 [345523.706107] [c000000399467e00] [c0000000004adff8] sys_ioctl+0x28/0x80 [345523.706111] [c000000399467e20] [c00000000000b278] system_call+0x5c/0x68 [345523.706112] Instruction dump: [345523.706114] 419e0390 7f8a4840 409d0048 6d497c00 2f89075d 419e021c 6d497c00 2f8907dd [345523.706119] 419e01c0 6d497c00 2f8905dd 419e00a4 <0fe00000> 38210040 38600000 ebc1fff0 and then treats the executed instruction as a 'nop'. However the POWER9 User's Manual, in section "4.6.10 Book II Invalid Forms", informs that for TM instructions bit 31 is in fact ignored, thus for the TM-related invalid forms ignoring bit 31 and handling them like the valid forms is an acceptable way to handle them. POWER8 behaves the same way too. This commit changes the handling of the cases here described by treating the TM-related invalid forms that can generate a softpatch interrupt just like their valid forms (w/ bit 31 = 1) instead of as a 'nop' and by gently reporting any other unrecognized case to the host and treating it as illegal instruction instead of throwing a trace and treating it as a 'nop'. Signed-off-by: Gustavo Romero Reviewed-by: Segher Boessenkool Acked-By: Michael Neuling Reviewed-by: Leonardo Bras Signed-off-by: Paul Mackerras Signed-off-by: Sasha Levin commit 63b7647dd0e179d23dcf514dc4c09a5abf6112a0 Author: Alexander Shishkin Date: Tue Mar 17 08:22:10 2020 +0200 intel_th: Disallow multi mode on devices where it's broken [ Upstream commit 397c7729665a3b07a7b4ce7215173df8e9112809 ] Some versions of Intel TH have an issue that prevents the multi mode of MSU from working correctly, resulting in no trace data and potentially stuck MSU pipeline. Disable multi mode on such devices. Signed-off-by: Alexander Shishkin Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20200317062215.15598-2-alexander.shishkin@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c3e39fa0aa108a201a3a05499705bc4356803bab Author: Jason Gunthorpe Date: Tue Mar 10 11:25:33 2020 +0200 RDMA/cm: Remove a race freeing timewait_info [ Upstream commit bede86a39d9dc3387ac00dcb8e1ac221676b2f25 ] When creating a cm_id during REQ the id immediately becomes visible to the other MAD handlers, and shortly after the state is moved to IB_CM_REQ_RCVD This allows cm_rej_handler() to run concurrently and free the work: CPU 0 CPU1 cm_req_handler() ib_create_cm_id() cm_match_req() id_priv->state = IB_CM_REQ_RCVD cm_rej_handler() cm_acquire_id() spin_lock(&id_priv->lock) switch (id_priv->state) case IB_CM_REQ_RCVD: cm_reset_to_idle() kfree(id_priv->timewait_info); goto destroy destroy: kfree(id_priv->timewait_info); id_priv->timewait_info = NULL Causing a double free or worse. Do not free the timewait_info without also holding the id_priv->lock. Simplify this entire flow by making the free unconditional during cm_destroy_id() and removing the confusing special case error unwind during creation of the timewait_info. This also fixes a leak of the timewait if cm_destroy_id() is called in IB_CM_ESTABLISHED with an XRC TGT QP. The state machine will be left in ESTABLISHED while it needed to transition through IB_CM_TIMEWAIT to release the timewait pointer. Also fix a leak of the timewait_info if the caller mis-uses the API and does ib_send_cm_reqs(). Fixes: a977049dacde ("[PATCH] IB: Add the kernel CM implementation") Link: https://lore.kernel.org/r/20200310092545.251365-4-leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 0300cda5009a72da2ee5c6a6bda07739481b0f2f Author: Trond Myklebust Date: Sun Mar 1 18:21:38 2020 -0500 nfsd: Don't add locks to closed or closing open stateids [ Upstream commit a451b12311aa8c96c6f6e01c783a86995dc3ec6b ] In NFSv4, the lock stateids are tied to the lockowner, and the open stateid, so that the action of closing the file also results in either an automatic loss of the locks, or an error of the form NFS4ERR_LOCKS_HELD. In practice this means we must not add new locks to the open stateid after the close process has been invoked. In fact doing so, can result in the following panic: kernel BUG at lib/list_debug.c:51! invalid opcode: 0000 [#1] SMP NOPTI CPU: 2 PID: 1085 Comm: nfsd Not tainted 5.6.0-rc3+ #2 Hardware name: VMware, Inc. VMware7,1/440BX Desktop Reference Platform, BIOS VMW71.00V.14410784.B64.1908150010 08/15/2019 RIP: 0010:__list_del_entry_valid.cold+0x31/0x55 Code: 1a 3d 9b e8 74 10 c2 ff 0f 0b 48 c7 c7 f0 1a 3d 9b e8 66 10 c2 ff 0f 0b 48 89 f2 48 89 fe 48 c7 c7 b0 1a 3d 9b e8 52 10 c2 ff <0f> 0b 48 89 fe 4c 89 c2 48 c7 c7 78 1a 3d 9b e8 3e 10 c2 ff 0f 0b RSP: 0018:ffffb296c1d47d90 EFLAGS: 00010246 RAX: 0000000000000054 RBX: ffff8ba032456ec8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff8ba039e99cc8 RDI: ffff8ba039e99cc8 RBP: ffff8ba032456e60 R08: 0000000000000781 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000001 R12: ffff8ba009a4abe0 R13: ffff8ba032456e8c R14: 0000000000000000 R15: ffff8ba00adb01d8 FS: 0000000000000000(0000) GS:ffff8ba039e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb213f0b008 CR3: 00000001347de006 CR4: 00000000003606e0 Call Trace: release_lock_stateid+0x2b/0x80 [nfsd] nfsd4_free_stateid+0x1e9/0x210 [nfsd] nfsd4_proc_compound+0x414/0x700 [nfsd] ? nfs4svc_decode_compoundargs+0x407/0x4c0 [nfsd] nfsd_dispatch+0xc1/0x200 [nfsd] svc_process_common+0x476/0x6f0 [sunrpc] ? svc_sock_secure_port+0x12/0x30 [sunrpc] ? svc_recv+0x313/0x9c0 [sunrpc] ? nfsd_svc+0x2d0/0x2d0 [nfsd] svc_process+0xd4/0x110 [sunrpc] nfsd+0xe3/0x140 [nfsd] kthread+0xf9/0x130 ? nfsd_destroy+0x50/0x50 [nfsd] ? kthread_park+0x90/0x90 ret_from_fork+0x1f/0x40 The fix is to ensure that lock creation tests for whether or not the open stateid is unhashed, and to fail if that is the case. Fixes: 659aefb68eca ("nfsd: Ensure we don't recognise lock stateids after freeing them") Signed-off-by: Trond Myklebust Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit cdb785710edd3a4d6897df9e933b0cf8289dd50e Author: Alexandre Belloni Date: Fri Mar 6 08:34:01 2020 +0100 rtc: ds1374: fix possible race condition [ Upstream commit c11af8131a4e7ba1960faed731ee7e84c2c13c94 ] The RTC IRQ is requested before the struct rtc_device is allocated, this may lead to a NULL pointer dereference in the IRQ handler. To fix this issue, allocating the rtc_device struct before requesting the RTC IRQ using devm_rtc_allocate_device, and use rtc_register_device to register the RTC device. Link: https://lore.kernel.org/r/20200306073404.56921-1-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 45c1212d91f7e2b8ec6c3760e97eb971a2aa646f Author: Alexandre Belloni Date: Fri Mar 6 02:01:44 2020 +0100 rtc: sa1100: fix possible race condition [ Upstream commit f2997775b111c6d660c32a18d5d44d37cb7361b1 ] Both RTC IRQs are requested before the struct rtc_device is allocated, this may lead to a NULL pointer dereference in the IRQ handler. To fix this issue, allocating the rtc_device struct before requesting the IRQs using devm_rtc_allocate_device, and use rtc_register_device to register the RTC device. Link: https://lore.kernel.org/r/20200306010146.39762-1-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 22de4a5d57919a5a48ea2bcf59cf950a6129a21a Author: Stefan Berger Date: Thu Mar 12 11:53:31 2020 -0400 tpm: ibmvtpm: Wait for buffer to be set before proceeding [ Upstream commit d8d74ea3c00214aee1e1826ca18e77944812b9b4 ] Synchronize with the results from the CRQs before continuing with the initialization. This avoids trying to send TPM commands while the rtce buffer has not been allocated, yet. This patch fixes an existing race condition that may occurr if the hypervisor does not quickly respond to the VTPM_GET_RTCE_BUFFER_SIZE request sent during initialization and therefore the ibmvtpm->rtce_buf has not been allocated at the time the first TPM command is sent. Fixes: 132f76294744 ("drivers/char/tpm: Add new device driver to support IBM vTPM") Signed-off-by: Stefan Berger Acked-by: Nayna Jain Tested-by: Nayna Jain Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit be4ff3a49c5d9a07b8de0ba78bf35c168cb5c3d5 Author: Dmitry Monakhov Date: Tue Mar 10 15:01:56 2020 +0000 ext4: mark block bitmap corrupted when found instead of BUGON [ Upstream commit eb5760863fc28feab28b567ddcda7e667e638da0 ] We already has similar code in ext4_mb_complex_scan_group(), but ext4_mb_simple_scan_group() still affected. Other reports: https://www.spinics.net/lists/linux-ext4/msg60231.html Reviewed-by: Andreas Dilger Signed-off-by: Dmitry Monakhov Link: https://lore.kernel.org/r/20200310150156.641-1-dmonakhov@gmail.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 152875a0f0949631f66d91692b3ae17995ad6e48 Author: Darrick J. Wong Date: Wed Mar 11 10:37:57 2020 -0700 xfs: mark dir corrupt when lookup-by-hash fails [ Upstream commit 2e107cf869eecc770e3f630060bb4e5f547d0fd8 ] In xchk_dir_actor, we attempt to validate the directory hash structures by performing a directory entry lookup by (hashed) name. If the lookup returns ENOENT, that means that the hash information is corrupt. The _process_error functions don't catch this, so we have to add that explicitly. Signed-off-by: Darrick J. Wong Reviewed-by: Dave Chinner Signed-off-by: Sasha Levin commit cb72c9f84219e594ca5ebccdde6712571875ad1d Author: Darrick J. Wong Date: Wed Mar 11 10:37:55 2020 -0700 xfs: don't ever return a stale pointer from __xfs_dir3_free_read [ Upstream commit 1cb5deb5bc095c070c09a4540c45f9c9ba24be43 ] If we decide that a directory free block is corrupt, we must take care not to leak a buffer pointer to the caller. After xfs_trans_brelse returns, the buffer can be freed or reused, which means that we have to set *bpp back to NULL. Callers are supposed to notice the nonzero return value and not use the buffer pointer, but we should code more defensively, even if all current callers handle this situation correctly. Fixes: de14c5f541e7 ("xfs: verify free block header fields") Signed-off-by: Darrick J. Wong Reviewed-by: Dave Chinner Signed-off-by: Sasha Levin commit b1f5989a23c1d06f834a051fbeea4cfc65c58668 Author: Palmer Dabbelt Date: Fri Mar 6 20:26:38 2020 -0800 tty: sifive: Finish transmission before changing the clock [ Upstream commit 4cbd7814bbd595061fcb6d6355d63f04179161cd ] SiFive's UART has a software controller clock divider that produces the final baud rate clock. Whenever the clock that drives the UART is changed this divider must be updated accordingly, and given that these two events are controlled by software they cannot be done atomically. During the period between updating the UART's driving clock and internal divider the UART will transmit a different baud rate than what the user has configured, which will probably result in a corrupted transmission stream. The SiFive UART has a FIFO, but due to an issue with the programming interface there is no way to directly determine when the UART has finished transmitting. We're essentially restricted to dead reckoning in order to figure that out: we can use the FIFO's TX busy register to figure out when the last frame has begun transmission and just delay for a long enough that the last frame is guaranteed to get out. As far as the actual implementation goes: I've modified the existing existing clock notifier function to drain both the FIFO and the shift register in on PRE_RATE_CHANGE. As far as I know there is no hardware flow control in this UART, so there's no good way to ask the other end to stop transmission while we can't receive (inserting software flow control messages seems like a bad idea here). Signed-off-by: Palmer Dabbelt Tested-by: Yash Shah Link: https://lore.kernel.org/r/20200307042637.83728-1-palmer@dabbelt.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit abbe59ca91f3e201f574c5d5519d41811e39fbae Author: Colin Ian King Date: Mon Feb 10 15:26:46 2020 +0100 media: tda10071: fix unsigned sign extension overflow [ Upstream commit a7463e2dc698075132de9905b89f495df888bb79 ] The shifting of buf[3] by 24 bits to the left will be promoted to a 32 bit signed int and then sign-extended to an unsigned long. In the unlikely event that the the top bit of buf[3] is set then all then all the upper bits end up as also being set because of the sign-extension and this affect the ev->post_bit_error sum. Fix this by using the temporary u32 variable bit_error to avoid the sign-extension promotion. This also removes the need to do the computation twice. Addresses-Coverity: ("Unintended sign extension") Fixes: 267897a4708f ("[media] tda10071: implement DVBv5 statistics") Signed-off-by: Colin Ian King Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit b432ea85ab8472763870dd0f2c186130dd36d68c Author: Howard Chung Date: Thu Mar 12 12:35:27 2020 +0800 Bluetooth: L2CAP: handle l2cap config request during open state [ Upstream commit 96298f640104e4cd9a913a6e50b0b981829b94ff ] According to Core Spec Version 5.2 | Vol 3, Part A 6.1.5, the incoming L2CAP_ConfigReq should be handled during OPEN state. The section below shows the btmon trace when running L2CAP/COS/CFD/BV-12-C before and after this change. === Before === ... > ACL Data RX: Handle 256 flags 0x02 dlen 12 #22 L2CAP: Connection Request (0x02) ident 2 len 4 PSM: 1 (0x0001) Source CID: 65 < ACL Data TX: Handle 256 flags 0x00 dlen 16 #23 L2CAP: Connection Response (0x03) ident 2 len 8 Destination CID: 64 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 256 flags 0x00 dlen 12 #24 L2CAP: Configure Request (0x04) ident 2 len 4 Destination CID: 65 Flags: 0x0000 > HCI Event: Number of Completed Packets (0x13) plen 5 #25 Num handles: 1 Handle: 256 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 #26 Num handles: 1 Handle: 256 Count: 1 > ACL Data RX: Handle 256 flags 0x02 dlen 16 #27 L2CAP: Configure Request (0x04) ident 3 len 8 Destination CID: 64 Flags: 0x0000 Option: Unknown (0x10) [hint] 01 00 .. < ACL Data TX: Handle 256 flags 0x00 dlen 18 #28 L2CAP: Configure Response (0x05) ident 3 len 10 Source CID: 65 Flags: 0x0000 Result: Success (0x0000) Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 672 > HCI Event: Number of Completed Packets (0x13) plen 5 #29 Num handles: 1 Handle: 256 Count: 1 > ACL Data RX: Handle 256 flags 0x02 dlen 14 #30 L2CAP: Configure Response (0x05) ident 2 len 6 Source CID: 64 Flags: 0x0000 Result: Success (0x0000) > ACL Data RX: Handle 256 flags 0x02 dlen 20 #31 L2CAP: Configure Request (0x04) ident 3 len 12 Destination CID: 64 Flags: 0x0000 Option: Unknown (0x10) [hint] 01 00 91 02 11 11 ...... < ACL Data TX: Handle 256 flags 0x00 dlen 14 #32 L2CAP: Command Reject (0x01) ident 3 len 6 Reason: Invalid CID in request (0x0002) Destination CID: 64 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 #33 Num handles: 1 Handle: 256 Count: 1 ... === After === ... > ACL Data RX: Handle 256 flags 0x02 dlen 12 #22 L2CAP: Connection Request (0x02) ident 2 len 4 PSM: 1 (0x0001) Source CID: 65 < ACL Data TX: Handle 256 flags 0x00 dlen 16 #23 L2CAP: Connection Response (0x03) ident 2 len 8 Destination CID: 64 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 256 flags 0x00 dlen 12 #24 L2CAP: Configure Request (0x04) ident 2 len 4 Destination CID: 65 Flags: 0x0000 > HCI Event: Number of Completed Packets (0x13) plen 5 #25 Num handles: 1 Handle: 256 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 #26 Num handles: 1 Handle: 256 Count: 1 > ACL Data RX: Handle 256 flags 0x02 dlen 16 #27 L2CAP: Configure Request (0x04) ident 3 len 8 Destination CID: 64 Flags: 0x0000 Option: Unknown (0x10) [hint] 01 00 .. < ACL Data TX: Handle 256 flags 0x00 dlen 18 #28 L2CAP: Configure Response (0x05) ident 3 len 10 Source CID: 65 Flags: 0x0000 Result: Success (0x0000) Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 672 > HCI Event: Number of Completed Packets (0x13) plen 5 #29 Num handles: 1 Handle: 256 Count: 1 > ACL Data RX: Handle 256 flags 0x02 dlen 14 #30 L2CAP: Configure Response (0x05) ident 2 len 6 Source CID: 64 Flags: 0x0000 Result: Success (0x0000) > ACL Data RX: Handle 256 flags 0x02 dlen 20 #31 L2CAP: Configure Request (0x04) ident 3 len 12 Destination CID: 64 Flags: 0x0000 Option: Unknown (0x10) [hint] 01 00 91 02 11 11 ..... < ACL Data TX: Handle 256 flags 0x00 dlen 18 #32 L2CAP: Configure Response (0x05) ident 3 len 10 Source CID: 65 Flags: 0x0000 Result: Success (0x0000) Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 672 < ACL Data TX: Handle 256 flags 0x00 dlen 12 #33 L2CAP: Configure Request (0x04) ident 3 len 4 Destination CID: 65 Flags: 0x0000 > HCI Event: Number of Completed Packets (0x13) plen 5 #34 Num handles: 1 Handle: 256 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 #35 Num handles: 1 Handle: 256 Count: 1 ... Signed-off-by: Howard Chung Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit ae3dffdbe42b0ec3891252866958372928fd6e13 Author: Sagar Biradar Date: Wed Feb 12 16:29:31 2020 -0800 scsi: aacraid: Disabling TM path and only processing IOP reset [ Upstream commit bef18d308a2215eff8c3411a23d7f34604ce56c3 ] Fixes the occasional adapter panic when sg_reset is issued with -d, -t, -b and -H flags. Removal of command type HBA_IU_TYPE_SCSI_TM_REQ in aac_hba_send since iu_type, request_id and fib_flags are not populated. Device and target reset handlers are made to send TMF commands only when reset_state is 0. Link: https://lore.kernel.org/r/1581553771-25796-1-git-send-email-Sagar.Biradar@microchip.com Reviewed-by: Sagar Biradar Signed-off-by: Sagar Biradar Signed-off-by: Balsundar P Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 62602774e5aab919e172e462fdbfb1b6648394ed Author: Wen Gong Date: Fri Feb 14 11:42:18 2020 +0800 ath10k: use kzalloc to read for ath10k_sdio_hif_diag_read [ Upstream commit 402f2992b4d62760cce7c689ff216ea3bf4d6e8a ] When use command to read values, it crashed. command: dd if=/sys/kernel/debug/ieee80211/phy0/ath10k/mem_value count=1 bs=4 skip=$((0x100233)) It will call to ath10k_sdio_hif_diag_read with address = 0x4008cc and buf_len = 4. Then system crash: [ 1786.013258] Unable to handle kernel paging request at virtual address ffffffc00bd45000 [ 1786.013273] Mem abort info: [ 1786.013281] ESR = 0x96000045 [ 1786.013291] Exception class = DABT (current EL), IL = 32 bits [ 1786.013299] SET = 0, FnV = 0 [ 1786.013307] EA = 0, S1PTW = 0 [ 1786.013314] Data abort info: [ 1786.013322] ISV = 0, ISS = 0x00000045 [ 1786.013330] CM = 0, WnR = 1 [ 1786.013342] swapper pgtable: 4k pages, 39-bit VAs, pgdp = 000000008542a60e [ 1786.013350] [ffffffc00bd45000] pgd=0000000000000000, pud=0000000000000000 [ 1786.013368] Internal error: Oops: 96000045 [#1] PREEMPT SMP [ 1786.013609] Process swapper/0 (pid: 0, stack limit = 0x0000000084b153c6) [ 1786.013623] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.86 #137 [ 1786.013631] Hardware name: MediaTek krane sku176 board (DT) [ 1786.013643] pstate: 80000085 (Nzcv daIf -PAN -UAO) [ 1786.013662] pc : __memcpy+0x94/0x180 [ 1786.013678] lr : swiotlb_tbl_unmap_single+0x84/0x150 [ 1786.013686] sp : ffffff8008003c60 [ 1786.013694] x29: ffffff8008003c90 x28: ffffffae96411f80 [ 1786.013708] x27: ffffffae960d2018 x26: ffffff8019a4b9a8 [ 1786.013721] x25: 0000000000000000 x24: 0000000000000001 [ 1786.013734] x23: ffffffae96567000 x22: 00000000000051d4 [ 1786.013747] x21: 0000000000000000 x20: 00000000fe6e9000 [ 1786.013760] x19: 0000000000000004 x18: 0000000000000020 [ 1786.013773] x17: 0000000000000001 x16: 0000000000000000 [ 1786.013787] x15: 00000000ffffffff x14: 00000000000044c0 [ 1786.013800] x13: 0000000000365ba4 x12: 0000000000000000 [ 1786.013813] x11: 0000000000000001 x10: 00000037be6e9000 [ 1786.013826] x9 : ffffffc940000000 x8 : 000000000bd45000 [ 1786.013839] x7 : 0000000000000000 x6 : ffffffc00bd45000 [ 1786.013852] x5 : 0000000000000000 x4 : 0000000000000000 [ 1786.013865] x3 : 0000000000000c00 x2 : 0000000000000004 [ 1786.013878] x1 : fffffff7be6e9004 x0 : ffffffc00bd45000 [ 1786.013891] Call trace: [ 1786.013903] __memcpy+0x94/0x180 [ 1786.013914] unmap_single+0x6c/0x84 [ 1786.013925] swiotlb_unmap_sg_attrs+0x54/0x80 [ 1786.013938] __swiotlb_unmap_sg_attrs+0x8c/0xa4 [ 1786.013952] msdc_unprepare_data+0x6c/0x84 [ 1786.013963] msdc_request_done+0x58/0x84 [ 1786.013974] msdc_data_xfer_done+0x1a0/0x1c8 [ 1786.013985] msdc_irq+0x12c/0x17c [ 1786.013996] __handle_irq_event_percpu+0xe4/0x250 [ 1786.014006] handle_irq_event_percpu+0x28/0x68 [ 1786.014015] handle_irq_event+0x48/0x78 [ 1786.014026] handle_fasteoi_irq+0xd0/0x1a0 [ 1786.014039] __handle_domain_irq+0x84/0xc4 [ 1786.014050] gic_handle_irq+0x124/0x1a4 [ 1786.014059] el1_irq+0xb0/0x128 [ 1786.014072] cpuidle_enter_state+0x298/0x328 [ 1786.014082] cpuidle_enter+0x30/0x40 [ 1786.014094] do_idle+0x190/0x268 [ 1786.014104] cpu_startup_entry+0x24/0x28 [ 1786.014116] rest_init+0xd4/0xe0 [ 1786.014126] start_kernel+0x30c/0x38c [ 1786.014139] Code: f8408423 f80084c3 36100062 b8404423 (b80044c3) [ 1786.014150] ---[ end trace 3b02ddb698ea69ee ]--- [ 1786.015415] Kernel panic - not syncing: Fatal exception in interrupt [ 1786.015433] SMP: stopping secondary CPUs [ 1786.015447] Kernel Offset: 0x2e8d200000 from 0xffffff8008000000 [ 1786.015458] CPU features: 0x0,2188200c [ 1786.015466] Memory Limit: none For sdio chip, it need the memory which is kmalloc, if it is vmalloc from ath10k_mem_value_read, then it have a memory error. kzalloc of ath10k_sdio_hif_diag_read32 is the correct type, so add kzalloc in ath10k_sdio_hif_diag_read to replace the buffer which is vmalloc from ath10k_mem_value_read. This patch only effect sdio chip. Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00029. Signed-off-by: Wen Gong Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit f6acb4ae6b6cb88048ced8da7e3db418e77112ed Author: Leo Yan Date: Wed Feb 19 10:18:09 2020 +0800 perf cs-etm: Correct synthesizing instruction samples [ Upstream commit c9f5baa136777b2c982f6f7a90c9da69a88be148 ] When 'etm->instructions_sample_period' is less than 'tidq->period_instructions', the function cs_etm__sample() cannot handle this case properly with its logic. Let's see below flow as an example: - If we set itrace option '--itrace=i4', then function cs_etm__sample() has variables with initialized values: tidq->period_instructions = 0 etm->instructions_sample_period = 4 - When the first packet is coming: packet->instr_count = 10; the number of instructions executed in this packet is 10, thus update period_instructions as below: tidq->period_instructions = 0 + 10 = 10 instrs_over = 10 - 4 = 6 offset = 10 - 6 - 1 = 3 tidq->period_instructions = instrs_over = 6 - When the second packet is coming: packet->instr_count = 10; in the second pass, assume 10 instructions in the trace sample again: tidq->period_instructions = 6 + 10 = 16 instrs_over = 16 - 4 = 12 offset = 10 - 12 - 1 = -3 -> the negative value tidq->period_instructions = instrs_over = 12 So after handle these two packets, there have below issues: The first issue is that cs_etm__instr_addr() returns the address within the current trace sample of the instruction related to offset, so the offset is supposed to be always unsigned value. But in fact, function cs_etm__sample() might calculate a negative offset value (in handling the second packet, the offset is -3) and pass to cs_etm__instr_addr() with u64 type with a big positive integer. The second issue is it only synthesizes 2 samples for sample period = 4. In theory, every packet has 10 instructions so the two packets have total 20 instructions, 20 instructions should generate 5 samples (4 x 5 = 20). This is because cs_etm__sample() only calls once cs_etm__synth_instruction_sample() to generate instruction sample per range packet. This patch fixes the logic in function cs_etm__sample(); the basic idea for handling coming packet is: - To synthesize the first instruction sample, it combines the left instructions from the previous packet and the head of the new packet; then generate continuous samples with sample period; - At the tail of the new packet, if it has the rest instructions, these instructions will be left for the sequential sample. Suggested-by: Mike Leach Signed-off-by: Leo Yan Reviewed-by: Mathieu Poirier Reviewed-by: Mike Leach Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Robert Walker Cc: Suzuki Poulouse Cc: coresight ml Cc: linux-arm-kernel@lists.infradead.org Link: http://lore.kernel.org/lkml/20200219021811.20067-4-leo.yan@linaro.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit f7ba2eeb0c6f790b645364bf960763897b7faff6 Author: Leo Yan Date: Wed Feb 19 10:18:07 2020 +0800 perf cs-etm: Swap packets for instruction samples [ Upstream commit d01751563caf0dec7be36f81de77cc0197b77e59 ] If use option '--itrace=iNNN' with Arm CoreSight trace data, perf tool fails inject instruction samples; the root cause is the packets are only swapped for branch samples and last branches but not for instruction samples, so the new coming packets cannot be properly handled for only synthesizing instruction samples. To fix this issue, this patch refactors the code with a new function cs_etm__packet_swap() which is used to swap packets and adds the condition for instruction samples. Signed-off-by: Leo Yan Reviewed-by: Mathieu Poirier Reviewed-by: Mike Leach Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Robert Walker Cc: Suzuki Poulouse Cc: coresight ml Cc: linux-arm-kernel@lists.infradead.org Link: http://lore.kernel.org/lkml/20200219021811.20067-2-leo.yan@linaro.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit fc1d08a2023d921413a0bb28b5cc166be0796f26 Author: afzal mohammed Date: Wed Mar 4 06:20:48 2020 +0530 s390/irq: replace setup_irq() by request_irq() [ Upstream commit 8719b6d29d2851fa84c4074bb2e5adc022911ab8 ] request_irq() is preferred over setup_irq(). Invocations of setup_irq() occur after memory allocators are ready. Per tglx[1], setup_irq() existed in olden days when allocators were not ready by the time early interrupts were initialized. Hence replace setup_irq() by request_irq(). [1] https://lkml.kernel.org/r/alpine.DEB.2.20.1710191609480.1971@nanos Signed-off-by: afzal mohammed Message-Id: <20200304005049.5291-1-afzal.mohd.ma@gmail.com> [heiko.carstens@de.ibm.com: replace pr_err with panic] Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 37b972bf80704f5dc4016801ccd50ce93389b1c1 Author: Zeng Tao Date: Wed Mar 4 11:54:52 2020 +0800 cpu-topology: Fix the potential data corruption [ Upstream commit 4a33691c4cea9eb0a7c66e87248be4637e14b180 ] Currently there are only 10 bytes to store the cpu-topology 'name' information. Only 10 bytes copied into cluster/thread/core names. If the cluster ID exceeds 2-digit number, it will result in the data corruption, and ending up in a dead loop in the parsing routines. The same applies to the thread names with more that 3-digit number. This issue was found using the boundary tests under virtualised environment like QEMU. Let us increase the buffer to fix such potential issues. Reviewed-by: Sudeep Holla Signed-off-by: Zeng Tao Link: https://lore.kernel.org/r/1583294092-5929-1-git-send-email-prime.zeng@hisilicon.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2d4e6ce22c58654438240d99fdcaa4827c99ee8b Author: Anson Huang Date: Wed Feb 19 15:59:46 2020 +0800 clk: imx: Fix division by zero warning on pfdv2 [ Upstream commit 28b2f82e0383e27476be8a5e13d2aea07ebeb275 ] Fix below division by zero warning: [ 3.176443] Division by zero in kernel. [ 3.181809] CPU: 0 PID: 88 Comm: kworker/0:2 Not tainted 5.3.0-rc2-next-20190730-63758-ge08da51-dirty #124 [ 3.191817] Hardware name: Freescale i.MX7ULP (Device Tree) [ 3.197821] Workqueue: events dbs_work_handler [ 3.202849] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 3.211058] [] (show_stack) from [] (dump_stack+0xd8/0x110) [ 3.218820] [] (dump_stack) from [] (Ldiv0_64+0x8/0x18) [ 3.226263] [] (Ldiv0_64) from [] (clk_pfdv2_set_rate+0x54/0xac) [ 3.234487] [] (clk_pfdv2_set_rate) from [] (clk_change_rate+0x1a4/0x698) [ 3.243468] [] (clk_change_rate) from [] (clk_change_rate+0x280/0x698) [ 3.252180] [] (clk_change_rate) from [] (clk_core_set_rate_nolock+0x1a0/0x278) [ 3.261679] [] (clk_core_set_rate_nolock) from [] (clk_set_rate+0x30/0x64) [ 3.270743] [] (clk_set_rate) from [] (imx7ulp_set_target+0x184/0x2a4) [ 3.279501] [] (imx7ulp_set_target) from [] (__cpufreq_driver_target+0x188/0x514) [ 3.289196] [] (__cpufreq_driver_target) from [] (od_dbs_update+0x130/0x15c) [ 3.298438] [] (od_dbs_update) from [] (dbs_work_handler+0x2c/0x5c) [ 3.306914] [] (dbs_work_handler) from [] (process_one_work+0x2ac/0x704) [ 3.315826] [] (process_one_work) from [] (worker_thread+0x2c/0x574) [ 3.324404] [] (worker_thread) from [] (kthread+0x134/0x148) [ 3.332278] [] (kthread) from [] (ret_from_fork+0x14/0x20) [ 3.339858] Exception stack(0xe82d5fb0 to 0xe82d5ff8) [ 3.345314] 5fa0: 00000000 00000000 00000000 00000000 [ 3.353926] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 3.362519] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 Signed-off-by: Anson Huang Signed-off-by: Peng Fan Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 6fc325a4d35dc79cd6c002b57c49fedcefb5b5fb Author: Rodrigo Siqueira Date: Mon Feb 24 10:13:37 2020 -0500 drm/amd/display: Stop if retimer is not available [ Upstream commit a0e40018dcc3f59a10ca21d58f8ea8ceb1b035ac ] Raven provides retimer feature support that requires i2c interaction in order to make it work well, all settings required for this configuration are loaded from the Atom bios which include the i2c address. If the retimer feature is not available, we should abort the attempt to set this feature, otherwise, it makes the following line return I2C_CHANNEL_OPERATION_NO_RESPONSE: i2c_success = i2c_write(pipe_ctx, slave_address, buffer, sizeof(buffer)); ... if (!i2c_success) ASSERT(i2c_success); This ends up causing problems with hotplugging HDMI displays on Raven, and causes retimer settings to warn like so: WARNING: CPU: 1 PID: 429 at drivers/gpu/drm/amd/amdgpu/../dal/dc/core/dc_link.c:1998 write_i2c_retimer_setting+0xc2/0x3c0 [amdgpu] Modules linked in: edac_mce_amd ccp kvm irqbypass binfmt_misc crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel amdgpu(+) snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi aesni_intel snd_seq amd_iommu_v2 gpu_sched aes_x86_64 crypto_simd cryptd glue_helper snd_seq_device ttm drm_kms_helper snd_timer eeepc_wmi wmi_bmof asus_wmi sparse_keymap drm mxm_wmi snd k10temp fb_sys_fops syscopyarea sysfillrect sysimgblt soundcore joydev input_leds mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 igb i2c_algo_bit hid_generic usbhid i2c_piix4 dca ahci hid libahci video wmi gpio_amdpt gpio_generic CPU: 1 PID: 429 Comm: systemd-udevd Tainted: G W 5.2.0-rc1sept162019+ #1 Hardware name: System manufacturer System Product Name/ROG STRIX B450-F GAMING, BIOS 2605 08/06/2019 RIP: 0010:write_i2c_retimer_setting+0xc2/0x3c0 [amdgpu] Code: ff 0f b6 4d ce 44 0f b6 45 cf 44 0f b6 c8 45 89 cf 44 89 e2 48 c7 c6 f0 34 bc c0 bf 04 00 00 00 e8 63 b0 90 ff 45 84 ff 75 02 <0f> 0b 42 0f b6 04 73 8d 50 f6 80 fa 02 77 8c 3c 0a 0f 85 c8 00 00 RSP: 0018:ffffa99d02726fd0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa99d02727035 RCX: 0000000000000006 RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff976acc857440 RBP: ffffa99d02727018 R08: 0000000000000002 R09: 000000000002a600 R10: ffffe90610193680 R11: 00000000000005e3 R12: 000000000000005d R13: ffff976ac4b201b8 R14: 0000000000000001 R15: 0000000000000000 FS: 00007f14f99e1680(0000) GS:ffff976acc840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fdf212843b8 CR3: 0000000408906000 CR4: 00000000003406e0 Call Trace: core_link_enable_stream+0x626/0x680 [amdgpu] dce110_apply_ctx_to_hw+0x414/0x4e0 [amdgpu] dc_commit_state+0x331/0x5e0 [amdgpu] ? drm_calc_timestamping_constants+0xf9/0x150 [drm] amdgpu_dm_atomic_commit_tail+0x395/0x1e00 [amdgpu] ? dm_plane_helper_prepare_fb+0x20c/0x280 [amdgpu] commit_tail+0x42/0x70 [drm_kms_helper] drm_atomic_helper_commit+0x10c/0x120 [drm_kms_helper] amdgpu_dm_atomic_commit+0x95/0xa0 [amdgpu] drm_atomic_commit+0x4a/0x50 [drm] restore_fbdev_mode_atomic+0x1c0/0x1e0 [drm_kms_helper] restore_fbdev_mode+0x4c/0x160 [drm_kms_helper] ? _cond_resched+0x19/0x40 drm_fb_helper_restore_fbdev_mode_unlocked+0x4e/0xa0 [drm_kms_helper] drm_fb_helper_set_par+0x2d/0x50 [drm_kms_helper] fbcon_init+0x471/0x630 visual_init+0xd5/0x130 do_bind_con_driver+0x20a/0x430 do_take_over_console+0x7d/0x1b0 do_fbcon_takeover+0x5c/0xb0 fbcon_event_notify+0x6cd/0x8a0 notifier_call_chain+0x4c/0x70 blocking_notifier_call_chain+0x43/0x60 fb_notifier_call_chain+0x1b/0x20 register_framebuffer+0x254/0x360 __drm_fb_helper_initial_config_and_unlock+0x2c5/0x510 [drm_kms_helper] drm_fb_helper_initial_config+0x35/0x40 [drm_kms_helper] amdgpu_fbdev_init+0xcd/0x100 [amdgpu] amdgpu_device_init+0x1156/0x1930 [amdgpu] amdgpu_driver_load_kms+0x8d/0x2e0 [amdgpu] drm_dev_register+0x12b/0x1c0 [drm] amdgpu_pci_probe+0xd3/0x160 [amdgpu] local_pci_probe+0x47/0xa0 pci_device_probe+0x142/0x1b0 really_probe+0xf5/0x3d0 driver_probe_device+0x11b/0x130 device_driver_attach+0x58/0x60 __driver_attach+0xa3/0x140 ? device_driver_attach+0x60/0x60 ? device_driver_attach+0x60/0x60 bus_for_each_dev+0x74/0xb0 ? kmem_cache_alloc_trace+0x1a3/0x1c0 driver_attach+0x1e/0x20 bus_add_driver+0x147/0x220 ? 0xffffffffc0cb9000 driver_register+0x60/0x100 ? 0xffffffffc0cb9000 __pci_register_driver+0x5a/0x60 amdgpu_init+0x74/0x83 [amdgpu] do_one_initcall+0x4a/0x1fa ? _cond_resched+0x19/0x40 ? kmem_cache_alloc_trace+0x3f/0x1c0 ? __vunmap+0x1cc/0x200 do_init_module+0x5f/0x227 load_module+0x2330/0x2b40 __do_sys_finit_module+0xfc/0x120 ? __do_sys_finit_module+0xfc/0x120 __x64_sys_finit_module+0x1a/0x20 do_syscall_64+0x5a/0x130 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f14f9500839 Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 73 01 c3 48 8b 0d 1f f6 2c 00 f7 d8 64 89 01 48 RSP: 002b:00007fff9bc4f5a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 000055afb5abce30 RCX: 00007f14f9500839 RDX: 0000000000000000 RSI: 000055afb5ace0f0 RDI: 0000000000000017 RBP: 000055afb5ace0f0 R08: 0000000000000000 R09: 000000000000000a R10: 0000000000000017 R11: 0000000000000246 R12: 0000000000000000 R13: 000055afb5aad800 R14: 0000000000020000 R15: 0000000000000000 ---[ end trace c286e96563966f08 ]--- This commit reworks the way that we handle i2c write for retimer in the way that we abort this configuration if the feature is not available in the device. For debug sake, we kept a simple log message in case the retimer is not available. Signed-off-by: Rodrigo Siqueira Reviewed-by: Hersen Wu Acked-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 10a144b77f64348dead15848833d3ecfe5425bde Author: Tony Lindgren Date: Wed Mar 4 14:54:30 2020 -0800 ARM: OMAP2+: Handle errors for cpu_pm [ Upstream commit 55be2f50336f67800513b46c5ba6270e4ed0e784 ] We need to check for errors when calling cpu_pm_enter() and cpu_cluster_pm_enter(). And we need to bail out on errors as otherwise we can enter a deeper idle state when not desired. I'm not aware of the lack of error handling causing issues yet, but we need this at least for blocking deeper idle states when a GPIO instance has pending interrupts. Cc: Dave Gerlach Cc: Grygorii Strashko Cc: Keerthy Cc: Ladislav Michl Cc: Russell King Cc: Tero Kristo Signed-off-by: Tony Lindgren Link: https://lore.kernel.org/r/20200304225433.37336-2-tony@atomide.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit d1a749c01d03330d269f02b69d79d37919adc7d5 Author: John Clements Date: Thu Mar 5 17:48:56 2020 +0800 drm/amdgpu: increase atombios cmd timeout [ Upstream commit 1b3460a8b19688ad3033b75237d40fa580a5a953 ] mitigates race condition on BACO reset between GPU bootcode and driver reload Reviewed-by: Hawking Zhang Signed-off-by: John Clements Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3a220956aaaf1b46902d7238a8bdb27f28e138e8 Author: Kirill A. Shutemov Date: Thu Mar 5 22:28:32 2020 -0800 mm: avoid data corruption on CoW fault into PFN-mapped VMA [ Upstream commit c3e5ea6ee574ae5e845a40ac8198de1fb63bb3ab ] Jeff Moyer has reported that one of xfstests triggers a warning when run on DAX-enabled filesystem: WARNING: CPU: 76 PID: 51024 at mm/memory.c:2317 wp_page_copy+0xc40/0xd50 ... wp_page_copy+0x98c/0xd50 (unreliable) do_wp_page+0xd8/0xad0 __handle_mm_fault+0x748/0x1b90 handle_mm_fault+0x120/0x1f0 __do_page_fault+0x240/0xd70 do_page_fault+0x38/0xd0 handle_page_fault+0x10/0x30 The warning happens on failed __copy_from_user_inatomic() which tries to copy data into a CoW page. This happens because of race between MADV_DONTNEED and CoW page fault: CPU0 CPU1 handle_mm_fault() do_wp_page() wp_page_copy() do_wp_page() madvise(MADV_DONTNEED) zap_page_range() zap_pte_range() ptep_get_and_clear_full() __copy_from_user_inatomic() sees empty PTE and fails WARN_ON_ONCE(1) clear_page() The solution is to re-try __copy_from_user_inatomic() under PTL after checking that PTE is matches the orig_pte. The second copy attempt can still fail, like due to non-readable PTE, but there's nothing reasonable we can do about, except clearing the CoW page. Reported-by: Jeff Moyer Signed-off-by: Andrew Morton Signed-off-by: Kirill A. Shutemov Tested-by: Jeff Moyer Cc: Cc: Justin He Cc: Dan Williams Link: http://lkml.kernel.org/r/20200218154151.13349-1-kirill.shutemov@linux.intel.com Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 2da77d2d0d893c1732c0830dd5df0b51f8767882 Author: John Garry Date: Thu Mar 5 19:08:01 2020 +0800 perf jevents: Fix leak of mapfile memory [ Upstream commit 3f5777fbaf04c58d940526a22a2e0c813c837936 ] The memory for global pointer is never freed during normal program execution, so let's do that in the main function exit as a good programming practice. A stray blank line is also removed. Reported-by: Jiri Olsa Signed-off-by: John Garry Cc: Alexander Shishkin Cc: Andi Kleen Cc: James Clark Cc: Joakim Zhang Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Will Deacon Cc: linuxarm@huawei.com Link: http://lore.kernel.org/lkml/1583406486-154841-2-git-send-email-john.garry@huawei.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 26005b604cef9bce5a7b3dbd31298d389e01f46b Author: Qiujun Huang Date: Mon Feb 24 23:02:46 2020 +0800 ext4: fix a data race at inode->i_disksize [ Upstream commit dce8e237100f60c28cc66effb526ba65a01d8cb3 ] KCSAN find inode->i_disksize could be accessed concurrently. BUG: KCSAN: data-race in ext4_mark_iloc_dirty / ext4_write_end write (marked) to 0xffff8b8932f40090 of 8 bytes by task 66792 on cpu 0: ext4_write_end+0x53f/0x5b0 ext4_da_write_end+0x237/0x510 generic_perform_write+0x1c4/0x2a0 ext4_buffered_write_iter+0x13a/0x210 ext4_file_write_iter+0xe2/0x9b0 new_sync_write+0x29c/0x3a0 __vfs_write+0x92/0xa0 vfs_write+0xfc/0x2a0 ksys_write+0xe8/0x140 __x64_sys_write+0x4c/0x60 do_syscall_64+0x8a/0x2a0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 read to 0xffff8b8932f40090 of 8 bytes by task 14414 on cpu 1: ext4_mark_iloc_dirty+0x716/0x1190 ext4_mark_inode_dirty+0xc9/0x360 ext4_convert_unwritten_extents+0x1bc/0x2a0 ext4_convert_unwritten_io_end_vec+0xc5/0x150 ext4_put_io_end+0x82/0x130 ext4_writepages+0xae7/0x16f0 do_writepages+0x64/0x120 __writeback_single_inode+0x7d/0x650 writeback_sb_inodes+0x3a4/0x860 __writeback_inodes_wb+0xc4/0x150 wb_writeback+0x43f/0x510 wb_workfn+0x3b2/0x8a0 process_one_work+0x39b/0x7e0 worker_thread+0x88/0x650 kthread+0x1d4/0x1f0 ret_from_fork+0x35/0x40 The plain read is outside of inode->i_data_sem critical section which results in a data race. Fix it by adding READ_ONCE(). Signed-off-by: Qiujun Huang Link: https://lore.kernel.org/r/1582556566-3909-1-git-send-email-hqjagain@gmail.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit d0c298030382a743d53e61d757374d8c9b8889fe Author: Wenjing Liu Date: Tue Feb 18 17:11:50 2020 -0500 drm/amd/display: fix image corruption with ODM 2:1 DSC 2 slice [ Upstream commit df8e34ac27e8a0d8dce364628226c5619693c3fd ] [why] When combining two or more pipes in DSC mode, there will always be more than 1 slice per line. In this case, as per DSC rules, the sink device is expecting that the ICH is reset at the end of each slice line (i.e. ICH_RESET_AT_END_OF_LINE must be configured based on the number of slices at the output of ODM). It is recommended that software set ICH_RESET_AT_END_OF_LINE = 0xF for each DSC in the ODM combine. However the current code only set ICH_RESET_AT_END_OF_LINE = 0xF when number of slice per DSC engine is greater than 1 instead of number of slice per output after ODM combine. [how] Add is_odm in dsc config. Set ICH_RESET_AT_END_OF_LINE = 0xF if either is_odm or number of slice per DSC engine is greater than 1. Signed-off-by: Wenjing Liu Reviewed-by: Nikola Cornij Acked-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f2118308295d565cd576af1253196d7c48998d4a Author: Alexey Kardashevskiy Date: Mon Dec 23 17:03:51 2019 +1100 powerpc/book3s64: Fix error handling in mm_iommu_do_alloc() [ Upstream commit c4b78169e3667413184c9a20e11b5832288a109f ] The last jump to free_exit in mm_iommu_do_alloc() happens after page pointers in struct mm_iommu_table_group_mem_t were already converted to physical addresses. Thus calling put_page() on these physical addresses will likely crash. This moves the loop which calculates the pageshift and converts page struct pointers to physical addresses later after the point when we cannot fail; thus eliminating the need to convert pointers back. Fixes: eb9d7a62c386 ("powerpc/mm_iommu: Fix potential deadlock") Reported-by: Jan Kara Signed-off-by: Alexey Kardashevskiy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191223060351.26359-1-aik@ozlabs.ru Signed-off-by: Sasha Levin commit efc95f2ef743506638648a091887c0a8a8f1079b Author: Wen Yang Date: Mon Jan 20 18:05:23 2020 +0800 timekeeping: Prevent 32bit truncation in scale64_check_overflow() [ Upstream commit 4cbbc3a0eeed675449b1a4d080008927121f3da3 ] While unlikely the divisor in scale64_check_overflow() could be >= 32bit in scale64_check_overflow(). do_div() truncates the divisor to 32bit at least on 32bit platforms. Use div64_u64() instead to avoid the truncation to 32-bit. [ tglx: Massaged changelog ] Signed-off-by: Wen Yang Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/20200120100523.45656-1-wenyang@linux.alibaba.com Signed-off-by: Sasha Levin commit 202e2ff9de4026e71fed251c40804ba262c797f3 Author: Alain Michaud Date: Tue Mar 3 15:55:34 2020 +0000 Bluetooth: guard against controllers sending zero'd events [ Upstream commit 08bb4da90150e2a225f35e0f642cdc463958d696 ] Some controllers have been observed to send zero'd events under some conditions. This change guards against this condition as well as adding a trace to facilitate diagnosability of this condition. Signed-off-by: Alain Michaud Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit a941594034301a9d31e5fe7913150222dcf12af0 Author: Takashi Iwai Date: Thu Feb 6 16:45:27 2020 +0100 media: go7007: Fix URB type for interrupt handling [ Upstream commit a3ea410cac41b19a5490aad7fe6d9a9a772e646e ] Josef reported that his old-and-good Plextor ConvertX M402U video converter spews lots of WARNINGs on the recent kernels, and it turned out that the device uses a bulk endpoint for interrupt handling just like 2250 board. For fixing it, generalize the check with the proper verification of the endpoint instead of hard-coded board type check. Fixes: 7e5219d18e93 ("[media] go7007: Fix 2250 urb type") Reported-and-tested-by: Josef Möllers BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1162583 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206427 Signed-off-by: Takashi Iwai Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 657e50f8cdbfb0e39aff0609a5fee4c1ed2b6f37 Author: Jaska Uimonen Date: Fri Feb 28 17:18:48 2020 -0600 ASoC: SOF: ipc: check ipc return value before data copy [ Upstream commit 1919b42ca4ad75a2397081164661af3ce5a7b8f4 ] In tx_wait_done the ipc payload is copied before the DSP transaction error code is checked. This might lead to corrupted data in kernel side even though the error would be handled later. It is also pointless to copy the data in case of error. So change the order of error check and copy. Signed-off-by: Pierre-Louis Bossart Signed-off-by: Jaska Uimonen Link: https://lore.kernel.org/r/20200228231850.9226-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 29c25e69492b9c3f2a930265c88dab5ea73eb3d8 Author: John Garry Date: Fri Jan 17 02:48:34 2020 +0800 bus: hisi_lpc: Fixup IO ports addresses to avoid use-after-free in host removal [ Upstream commit a6dd255bdd7d00bbdbf78ba00bde9fc64f86c3a7 ] Some released ACPI FW for Huawei boards describes incorrect the port IO address range for child devices, in that it tells us the IO port max range is 0x3fff for each child device, which is not correct. The address range should be [e4:e8) or similar. With this incorrect upper range, the child device IO port resources overlap. As such, the kernel thinks that the LPC host serial device is a child of the IPMI device: root@(none)$ more /proc/ioports [...] 00ffc0e3-00ffffff : hisi-lpc-ipmi.0.auto 00ffc0e3-00ffc0e3 : ipmi_si 00ffc0e4-00ffc0e4 : ipmi_si 00ffc0e5-00ffc0e5 : ipmi_si 00ffc2f7-00ffffff : serial8250.1.auto 00ffc2f7-00ffc2fe : serial root@(none)$ They should both be siblings. Note that these are logical PIO addresses, which have a direct mapping from the FW IO port ranges. This shows up as a real issue when we enable CONFIG_KASAN and CONFIG_DEBUG_TEST_DRIVER_REMOVE - we see use-after-free warnings in the host removal path: ================================================================== BUG: KASAN: use-after-free in release_resource+0x38/0xc8 Read of size 8 at addr ffff0026accdbc38 by task swapper/0/1 CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.5.0-rc6-00001-g68e186e77b5c-dirty #1593 Hardware name: Huawei Taishan 2180 /D03, BIOS Hisilicon D03 IT20 Nemo 2.0 RC0 03/30/2018 Call trace: dump_backtrace+0x0/0x290 show_stack+0x14/0x20 dump_stack+0xf0/0x14c print_address_description.isra.9+0x6c/0x3b8 __kasan_report+0x12c/0x23c kasan_report+0xc/0x18 __asan_load8+0x94/0xb8 release_resource+0x38/0xc8 platform_device_del.part.10+0x80/0xe0 platform_device_unregister+0x20/0x38 hisi_lpc_acpi_remove_subdev+0x10/0x20 device_for_each_child+0xc8/0x128 hisi_lpc_acpi_remove+0x4c/0xa8 hisi_lpc_remove+0xbc/0xc0 platform_drv_remove+0x3c/0x68 really_probe+0x174/0x548 driver_probe_device+0x7c/0x148 device_driver_attach+0x94/0xa0 __driver_attach+0xa4/0x110 bus_for_each_dev+0xe8/0x158 driver_attach+0x30/0x40 bus_add_driver+0x234/0x2f0 driver_register+0xbc/0x1d0 __platform_driver_register+0x7c/0x88 hisi_lpc_driver_init+0x18/0x20 do_one_initcall+0xb4/0x258 kernel_init_freeable+0x248/0x2c0 kernel_init+0x10/0x118 ret_from_fork+0x10/0x1c ... The issue here is that the kernel created an incorrect parent-child resource dependency between two devices, and references the false parent node when deleting the second child device, when it had been deleted already. Fix up the child device resources from FW to create proper IO port resource relationships for broken FW. With this, the IO port layout looks more healthy: root@(none)$ more /proc/ioports [...] 00ffc0e3-00ffc0e7 : hisi-lpc-ipmi.0.auto 00ffc0e3-00ffc0e3 : ipmi_si 00ffc0e4-00ffc0e4 : ipmi_si 00ffc0e5-00ffc0e5 : ipmi_si 00ffc2f7-00ffc2ff : serial8250.1.auto 00ffc2f7-00ffc2fe : serial Signed-off-by: John Garry Signed-off-by: Wei Xu Signed-off-by: Sasha Levin commit 3193035ec136a314646b3cbd1415c205e378ea53 Author: Qian Cai Date: Tue Feb 25 11:27:04 2020 -0500 random: fix data races at timer_rand_state [ Upstream commit e00d996a4317aff5351c4338dd97d390225412c2 ] Fields in "struct timer_rand_state" could be accessed concurrently. Lockless plain reads and writes result in data races. Fix them by adding pairs of READ|WRITE_ONCE(). The data races were reported by KCSAN, BUG: KCSAN: data-race in add_timer_randomness / add_timer_randomness write to 0xffff9f320a0a01d0 of 8 bytes by interrupt on cpu 22: add_timer_randomness+0x100/0x190 add_timer_randomness at drivers/char/random.c:1152 add_disk_randomness+0x85/0x280 scsi_end_request+0x43a/0x4a0 scsi_io_completion+0xb7/0x7e0 scsi_finish_command+0x1ed/0x2a0 scsi_softirq_done+0x1c9/0x1d0 blk_done_softirq+0x181/0x1d0 __do_softirq+0xd9/0x57c irq_exit+0xa2/0xc0 do_IRQ+0x8b/0x190 ret_from_intr+0x0/0x42 cpuidle_enter_state+0x15e/0x980 cpuidle_enter+0x69/0xc0 call_cpuidle+0x23/0x40 do_idle+0x248/0x280 cpu_startup_entry+0x1d/0x1f start_secondary+0x1b2/0x230 secondary_startup_64+0xb6/0xc0 no locks held by swapper/22/0. irq event stamp: 32871382 _raw_spin_unlock_irqrestore+0x53/0x60 _raw_spin_lock_irqsave+0x21/0x60 _local_bh_enable+0x21/0x30 irq_exit+0xa2/0xc0 read to 0xffff9f320a0a01d0 of 8 bytes by interrupt on cpu 2: add_timer_randomness+0xe8/0x190 add_disk_randomness+0x85/0x280 scsi_end_request+0x43a/0x4a0 scsi_io_completion+0xb7/0x7e0 scsi_finish_command+0x1ed/0x2a0 scsi_softirq_done+0x1c9/0x1d0 blk_done_softirq+0x181/0x1d0 __do_softirq+0xd9/0x57c irq_exit+0xa2/0xc0 do_IRQ+0x8b/0x190 ret_from_intr+0x0/0x42 cpuidle_enter_state+0x15e/0x980 cpuidle_enter+0x69/0xc0 call_cpuidle+0x23/0x40 do_idle+0x248/0x280 cpu_startup_entry+0x1d/0x1f start_secondary+0x1b2/0x230 secondary_startup_64+0xb6/0xc0 no locks held by swapper/2/0. irq event stamp: 37846304 _raw_spin_unlock_irqrestore+0x53/0x60 _raw_spin_lock_irqsave+0x21/0x60 _local_bh_enable+0x21/0x30 irq_exit+0xa2/0xc0 Reported by Kernel Concurrency Sanitizer on: Hardware name: HP ProLiant BL660c Gen9, BIOS I38 10/17/2018 Link: https://lore.kernel.org/r/1582648024-13111-1-git-send-email-cai@lca.pw Signed-off-by: Qian Cai Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 1edfaecc30a9bd1169fbc39f13031f1905f319a9 Author: James Morse Date: Fri Feb 21 16:35:08 2020 +0000 firmware: arm_sdei: Use cpus_read_lock() to avoid races with cpuhp [ Upstream commit 54f529a6806c9710947a4f2cdc15d6ea54121ccd ] SDEI has private events that need registering and enabling on each CPU. CPUs can come and go while we are trying to do this. SDEI tries to avoid these problems by setting the reregister flag before the register call, so any CPUs that come online register the event too. Sticking plaster like this doesn't work, as if the register call fails, a CPU that subsequently comes online will register the event before reregister is cleared. Take cpus_read_lock() around the register and enable calls. We don't want surprise CPUs to do the wrong thing if they race with these calls failing. Signed-off-by: James Morse Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 21e2f6bf0863008c02401bcd59453c5d0c4251eb Author: Jiri Pirko Date: Wed Feb 26 09:21:57 2020 +0100 iavf: use tc_cls_can_offload_and_chain0() instead of chain check [ Upstream commit bb0858d8bc828ebc3eaa90be02a0f32bca3c2351 ] Looks like the iavf code actually experienced a race condition, when a developer took code before the check for chain 0 was put to helper. So use tc_cls_can_offload_and_chain0() helper instead of direct check and move the check to _cb() so this is similar to i40e code. Signed-off-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0d5984ba936bb6e205d4c3a6bc7907d0526d437a Author: Laurent Pinchart Date: Wed Feb 26 13:24:41 2020 +0200 drm/omap: dss: Cleanup DSS ports on initialisation failure [ Upstream commit 2a0a3ae17d36fa86dcf7c8e8d7b7f056ebd6c064 ] When the DSS initialises its output DPI and SDI ports, failures don't clean up previous successfully initialised ports. This can lead to resource leak or memory corruption. Fix it. Reported-by: Hans Verkuil Signed-off-by: Laurent Pinchart Reviewed-by: Tomi Valkeinen Acked-by: Sam Ravnborg Tested-by: Sebastian Reichel Reviewed-by: Sebastian Reichel Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20200226112514.12455-22-laurent.pinchart@ideasonboard.com Signed-off-by: Sasha Levin commit b4bca7b2a6e2fe564af7d80742026b614367c62c Author: Aric Cyr Date: Thu Jan 30 14:46:53 2020 -0500 drm/amd/display: dal_ddc_i2c_payloads_create can fail causing panic [ Upstream commit 6a6c4a4d459ecacc9013c45dcbf2bc9747fdbdbd ] [Why] Since the i2c payload allocation can fail need to check return codes [How] Clean up i2c payload allocations and check for errors Signed-off-by: Aric Cyr Reviewed-by: Joshua Aberback Acked-by: Rodrigo Siqueira Acked-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3e6f9c20bd32bedceb28a6fa6fa01dc5350f4841 Author: Pierre-Louis Bossart Date: Tue Jan 14 18:08:41 2020 -0600 soundwire: bus: disable pm_runtime in sdw_slave_delete [ Upstream commit dff70572e9a3a1a01d9dbc2279faa784d95f41b6 ] Before removing the slave device, disable pm_runtime to prevent any race condition with the resume being executed after the bus and slave devices are removed. Since this pm_runtime_disable() is handled in common routines, implementations of Slave drivers do not need to call it in their .remove() routine. Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200115000844.14695-8-pierre-louis.bossart@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit c4b62a7e52ee6b00bc52fe8beeb512f3eca6b144 Author: Dmitry Osipenko Date: Sun Feb 9 19:33:41 2020 +0300 dmaengine: tegra-apb: Prevent race conditions on channel's freeing [ Upstream commit 8e84172e372bdca20c305d92d51d33640d2da431 ] It's incorrect to check the channel's "busy" state without taking a lock. That shouldn't cause any real troubles, nevertheless it's always better not to have any race conditions in the code. Signed-off-by: Dmitry Osipenko Acked-by: Jon Hunter Link: https://lore.kernel.org/r/20200209163356.6439-5-digetx@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit cdf63c29af1e7eb1f53820c1b8adca8adc663537 Author: Amelie Delaunay Date: Wed Jan 29 16:36:28 2020 +0100 dmaengine: stm32-dma: use vchan_terminate_vdesc() in .terminate_all [ Upstream commit d80cbef35bf89b763f06e03bb4ff8f933bf012c5 ] To avoid race with vchan_complete, use the race free way to terminate running transfer. Move vdesc->node list_del in stm32_dma_start_transfer instead of in stm32_mdma_chan_complete to avoid another race in vchan_dma_desc_free_list. Signed-off-by: Amelie Delaunay Link: https://lore.kernel.org/r/20200129153628.29329-9-amelie.delaunay@st.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit f60007c9e91402d936e300913eed62fa7fc2e54b Author: Thomas Gleixner Date: Mon Feb 24 15:01:39 2020 +0100 bpf: Remove recursion prevention from rcu free callback [ Upstream commit 8a37963c7ac9ecb7f86f8ebda020e3f8d6d7b8a0 ] If an element is freed via RCU then recursion into BPF instrumentation functions is not a concern. The element is already detached from the map and the RCU callback does not hold any locks on which a kprobe, perf event or tracepoint attached BPF program could deadlock. Signed-off-by: Thomas Gleixner Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200224145643.259118710@linutronix.de Signed-off-by: Sasha Levin commit e8b95c29cdef28b80d8ef15d807792d06ffd7eb3 Author: Dave Hansen Date: Wed Jan 22 08:53:46 2020 -0800 x86/pkeys: Add check for pkey "overflow" [ Upstream commit 16171bffc829272d5e6014bad48f680cb50943d9 ] Alex Shi reported the pkey macros above arch_set_user_pkey_access() to be unused. They are unused, and even refer to a nonexistent CONFIG option. But, they might have served a good use, which was to ensure that the code does not try to set values that would not fit in the PKRU register. As it stands, a too-large 'pkey' value would be likely to silently overflow the u32 new_pkru_bits. Add a check to look for overflows. Also add a comment to remind any future developer to closely examine the types used to store pkey values if arch_max_pkey() ever changes. This boots and passes the x86 pkey selftests. Reported-by: Alex Shi Signed-off-by: Dave Hansen Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20200122165346.AD4DA150@viggo.jf.intel.com Signed-off-by: Sasha Levin commit 321c5b279313da6f332da8b2ca135200852fa045 Author: Dan Carpenter Date: Tue Feb 11 08:35:46 2020 +0100 media: staging/imx: Missing assignment in imx_media_capture_device_register() [ Upstream commit ef0ed05dcef8a74178a8b480cce23a377b1de2b8 ] There was supposed to be a "ret = " assignment here, otherwise the error handling on the next line won't work. Fixes: 64b5a49df486 ("[media] media: imx: Add Capture Device Interface") Signed-off-by: Dan Carpenter Reviewed-by: Steve Longerbeam Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 5132f9f3d3e2dff61a42043f00c93e7bf7b959f2 Author: Amelie Delaunay Date: Mon Jan 27 09:53:34 2020 +0100 dmaengine: stm32-mdma: use vchan_terminate_vdesc() in .terminate_all [ Upstream commit dfc708812a2acfc0ca56f56233b3c3e7b0d4ffe7 ] To avoid race with vchan_complete, use the race free way to terminate running transfer. Move vdesc->node list_del in stm32_mdma_start_transfer instead of in stm32_mdma_xfer_end to avoid another race in vchan_dma_desc_free_list. Signed-off-by: Amelie Delaunay Link: https://lore.kernel.org/r/20200127085334.13163-7-amelie.delaunay@st.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 484de771d637c9c9fc2abb7b87919449f3e124d0 Author: wanpeng li Date: Mon Feb 17 18:37:43 2020 +0800 KVM: nVMX: Hold KVM's srcu lock when syncing vmcs12->shadow [ Upstream commit c9dfd3fb08352d439f0399b6fabe697681d2638c ] For the duration of mapping eVMCS, it derefences ->memslots without holding ->srcu or ->slots_lock when accessing hv assist page. This patch fixes it by moving nested_sync_vmcs12_to_shadow to prepare_guest_switch, where the SRCU is already taken. It can be reproduced by running kvm's evmcs_test selftest. ============================= warning: suspicious rcu usage 5.6.0-rc1+ #53 tainted: g w ioe ----------------------------- ./include/linux/kvm_host.h:623 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by evmcs_test/8507: #0: ffff9ddd156d00d0 (&vcpu->mutex){+.+.}, at: kvm_vcpu_ioctl+0x85/0x680 [kvm] stack backtrace: cpu: 6 pid: 8507 comm: evmcs_test tainted: g w ioe 5.6.0-rc1+ #53 hardware name: dell inc. optiplex 7040/0jctf8, bios 1.4.9 09/12/2016 call trace: dump_stack+0x68/0x9b kvm_read_guest_cached+0x11d/0x150 [kvm] kvm_hv_get_assist_page+0x33/0x40 [kvm] nested_enlightened_vmentry+0x2c/0x60 [kvm_intel] nested_vmx_handle_enlightened_vmptrld.part.52+0x32/0x1c0 [kvm_intel] nested_sync_vmcs12_to_shadow+0x439/0x680 [kvm_intel] vmx_vcpu_run+0x67a/0xe60 [kvm_intel] vcpu_enter_guest+0x35e/0x1bc0 [kvm] kvm_arch_vcpu_ioctl_run+0x40b/0x670 [kvm] kvm_vcpu_ioctl+0x370/0x680 [kvm] ksys_ioctl+0x235/0x850 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x77/0x780 entry_syscall_64_after_hwframe+0x49/0xbe Signed-off-by: Wanpeng Li Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit d1da396447096c919a1d80e2426f2ed019014915 Author: Paolo Bonzini Date: Thu Feb 13 18:24:48 2020 +0100 KVM: x86: fix incorrect comparison in trace event [ Upstream commit 147f1a1fe5d7e6b01b8df4d0cbd6f9eaf6b6c73b ] The "u" field in the event has three states, -1/0/1. Using u8 however means that comparison with -1 will always fail, so change to signed char. Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit a4d17715a85299f880d986003589b054abefd95c Author: Bart Van Assche Date: Mon Feb 17 12:57:14 2020 -0800 RDMA/rxe: Fix configuration of atomic queue pair attributes [ Upstream commit fb3063d31995cc4cf1d47a406bb61d6fb1b1d58d ] From the comment above the definition of the roundup_pow_of_two() macro: The result is undefined when n == 0. Hence only pass positive values to roundup_pow_of_two(). This patch fixes the following UBSAN complaint: UBSAN: Undefined behaviour in ./include/linux/log2.h:57:13 shift exponent 64 is too large for 64-bit type 'long unsigned int' Call Trace: dump_stack+0xa5/0xe6 ubsan_epilogue+0x9/0x26 __ubsan_handle_shift_out_of_bounds.cold+0x4c/0xf9 rxe_qp_from_attr.cold+0x37/0x5d [rdma_rxe] rxe_modify_qp+0x59/0x70 [rdma_rxe] _ib_modify_qp+0x5aa/0x7c0 [ib_core] ib_modify_qp+0x3b/0x50 [ib_core] cma_modify_qp_rtr+0x234/0x260 [rdma_cm] __rdma_accept+0x1a7/0x650 [rdma_cm] nvmet_rdma_cm_handler+0x1286/0x14cd [nvmet_rdma] cma_cm_event_handler+0x6b/0x330 [rdma_cm] cma_ib_req_handler+0xe60/0x22d0 [rdma_cm] cm_process_work+0x30/0x140 [ib_cm] cm_req_handler+0x11f4/0x1cd0 [ib_cm] cm_work_handler+0xb8/0x344e [ib_cm] process_one_work+0x569/0xb60 worker_thread+0x7a/0x5d0 kthread+0x1e6/0x210 ret_from_fork+0x24/0x30 Link: https://lore.kernel.org/r/20200217205714.26937-1-bvanassche@acm.org Fixes: 8700e3e7c485 ("Soft RoCE driver") Signed-off-by: Bart Van Assche Reviewed-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 45901923749f4fc3a34e6d7fbdc7e779662e2569 Author: Thomas Richter Date: Mon Feb 17 11:21:11 2020 +0100 perf test: Fix test trace+probe_vfs_getname.sh on s390 [ Upstream commit 2bbc83537614517730e9f2811195004b712de207 ] This test places a kprobe to function getname_flags() in the kernel which has the following prototype: struct filename *getname_flags(const char __user *filename, int flags, int *empty) The 'filename' argument points to a filename located in user space memory. Looking at commit 88903c464321c ("tracing/probe: Add ustring type for user-space string") the kprobe should indicate that user space memory is accessed. Output before: [root@m35lp76 perf]# ./perf test 66 67 66: Use vfs_getname probe to get syscall args filenames : FAILED! 67: Check open filename arg using perf trace + vfs_getname: FAILED! [root@m35lp76 perf]# Output after: [root@m35lp76 perf]# ./perf test 66 67 66: Use vfs_getname probe to get syscall args filenames : Ok 67: Check open filename arg using perf trace + vfs_getname: Ok [root@m35lp76 perf]# Comments from Masami Hiramatsu: This bug doesn't happen on x86 or other archs on which user address space and kernel address space is the same. On some arches (ppc64 in this case?) user address space is partially or completely the same as kernel address space. (Yes, they switch the world when running into the kernel) In this case, we need to use different data access functions for each space. That is why I introduced the "ustring" type for kprobe events. As far as I can see, Thomas's patch is sane. Thomas, could you show us your result on your test environment? Comments from Thomas Richter: Test results for s/390 included above. Signed-off-by: Thomas Richter Acked-by: Masami Hiramatsu Tested-by: Arnaldo Carvalho de Melo Cc: Heiko Carstens Cc: Sumanth Korikkar Cc: Vasily Gorbik Link: http://lore.kernel.org/lkml/20200217102111.61137-1-tmricht@linux.ibm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit e2d439c2000d0236fdb3218545e3144ad3463076 Author: Takashi Iwai Date: Fri Feb 14 15:49:28 2020 +0100 ALSA: usb-audio: Don't create a mixer element with bogus volume range [ Upstream commit e9a0ef0b5ddcbc0d56c65aefc0f18d16e6f71207 ] Some USB-audio descriptors provide a bogus volume range (e.g. volume min and max are identical), which confuses user-space. This patch makes the driver skipping such a control element. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206221 Link: https://lore.kernel.org/r/20200214144928.23628-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 78344a4dc43ed1976bf11e418163c1d44d40954c Author: Felix Fietkau Date: Mon Jan 20 12:08:30 2020 +0100 mt76: fix handling full tx queues in mt76_dma_tx_queue_skb_raw [ Upstream commit 93eaec7625f13cffb593b471405b017c7e64d4ee ] Fixes a theoretical issue where it could potentially overwrite an existing descriptor entry (and leaking its skb) Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 9b42bfb06d3722faac9c6091495aa3f6568e4ed5 Author: Felix Fietkau Date: Sat Dec 14 00:15:26 2019 +0100 mt76: clear skb pointers from rx aggregation reorder buffer during cleanup [ Upstream commit 9379df2fd9234e3b67a23101c2370c99f6af6d77 ] During the cleanup of the aggregation session, a rx handler (or release timer) on another CPU might still hold a pointer to the reorder buffer and could attempt to release some packets. Clearing pointers during cleanup avoids a theoretical use-after-free bug here. Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 1841613e97e7796e1ad96e03ed8e895c039c11cf Author: Ayush Sawal Date: Wed Feb 5 10:48:42 2020 +0530 crypto: chelsio - This fixes the kernel panic which occurs during a libkcapi test [ Upstream commit 9195189e00a7db55e7d448cee973cae87c5a3c71 ] The libkcapi test which causes kernel panic is aead asynchronous vmsplice multiple test. ./bin/kcapi -v -d 4 -x 10 -c "ccm(aes)" -q 4edb58e8d5eb6bc711c43a6f3693daebde2e5524f1b55297abb29f003236e43d -t a7877c99 -n 674742abd0f5ba -k 2861fd0253705d7875c95ba8a53171b4 -a fb7bc304a3909e66e2e0c5ef952712dd884ce3e7324171369f2c5db1adc48c7d This patch avoids dma_mapping of a zero length sg which causes the panic, by using sg_nents_for_len which maps only upto a specific length Signed-off-by: Ayush Sawal Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 671e6c9c6b7bd5ddee621ae7afa3e04dbb612ba6 Author: Dinh Nguyen Date: Tue Jan 14 10:07:25 2020 -0600 clk: stratix10: use do_div() for 64-bit calculation [ Upstream commit cc26ed7be46c5f5fa45f3df8161ed7ca3c4d318c ] do_div() macro to perform u64 division and guards against overflow if the result is too large for the unsigned long return type. Signed-off-by: Dinh Nguyen Link: https://lkml.kernel.org/r/20200114160726.19771-1-dinguyen@kernel.org Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit ef6eb812132156239cf2bfdd6f756edd779fdcaf Author: Waiman Long Date: Thu Feb 6 10:24:03 2020 -0500 locking/lockdep: Decrement IRQ context counters when removing lock chain [ Upstream commit b3b9c187dc2544923a601733a85352b9ddaba9b3 ] There are currently three counters to track the IRQ context of a lock chain - nr_hardirq_chains, nr_softirq_chains and nr_process_chains. They are incremented when a new lock chain is added, but they are not decremented when a lock chain is removed. That causes some of the statistic counts reported by /proc/lockdep_stats to be incorrect. IRQ Fix that by decrementing the right counter when a lock chain is removed. Since inc_chains() no longer accesses hardirq_context and softirq_context directly, it is moved out from the CONFIG_TRACE_IRQFLAGS conditional compilation block. Fixes: a0b0fd53e1e6 ("locking/lockdep: Free lock classes that are no longer in use") Signed-off-by: Waiman Long Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://lkml.kernel.org/r/20200206152408.24165-2-longman@redhat.com Signed-off-by: Sasha Levin commit 8e88cdd3223a8b4109d9b46aec8b58146acf9ab5 Author: Wen Yang Date: Mon Apr 8 10:58:32 2019 +0800 drm/omap: fix possible object reference leak [ Upstream commit 47340e46f34a3b1d80e40b43ae3d7a8da34a3541 ] The call to of_find_matching_node returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:212:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function. drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:237:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function. Signed-off-by: Wen Yang Reviewed-by: Laurent Pinchart Reviewed-by: Mukesh Ojha Cc: Tomi Valkeinen Cc: David Airlie Cc: Daniel Vetter Cc: Sebastian Reichel Cc: Laurent Pinchart Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Cc: Markus Elfring Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/1554692313-28882-2-git-send-email-wen.yang99@zte.com.cn Signed-off-by: Sasha Levin commit 41b71eff27771831772f80ac3bc7cbe7369d0bc3 Author: James Smart Date: Mon Jan 27 16:23:07 2020 -0800 scsi: lpfc: Fix coverity errors in fmdi attribute handling [ Upstream commit 4cb9e1ddaa145be9ed67b6a7de98ca705a43f998 ] Coverity reported a memory corruption error for the fdmi attributes routines: CID 15768 [Memory Corruption] Out-of-bounds access on FDMI Sloppy coding of the fmdi structures. In both the lpfc_fdmi_attr_def and lpfc_fdmi_reg_port_list structures, a field was placed at the start of payload that may have variable content. The field was given an arbitrary type (uint32_t). The code then uses the field name to derive an address, which it used in things such as memset and memcpy. The memset sizes or memcpy lengths were larger than the arbitrary type, thus coverity reported an error. Fix by replacing the arbitrary fields with the real field structures describing the payload. Link: https://lore.kernel.org/r/20200128002312.16346-8-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 e0ddd176a302245dc2f2da1f4bb0c21dae9fc03f Author: James Smart Date: Mon Jan 27 16:23:05 2020 -0800 scsi: lpfc: Fix release of hwq to clear the eq relationship [ Upstream commit 821bc882accaaaf1bbecf5c0ecef659443e3e8cb ] When performing reset testing, the eq's list for related hwqs was getting corrupted. In cases where there is not a 1:1 eq to hwq, the eq is shared. The eq maintains a list of hwqs utilizing it in case of cpu offlining and polling. During the reset, the hwqs are being torn down so they can be recreated. The recreation was getting confused by seeing a non-null eq assignment on the eq and the eq list became corrupt. Correct by clearing the hdwq eq assignment when the hwq is cleaned up. Link: https://lore.kernel.org/r/20200128002312.16346-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 4935732e8821de2d50fba59276816f8cd4332bb9 Author: James Smart Date: Mon Jan 27 16:23:01 2020 -0800 scsi: lpfc: Fix RQ buffer leakage when no IOCBs available [ Upstream commit 39c4f1a965a9244c3ba60695e8ff8da065ec6ac4 ] The driver is occasionally seeing the following SLI Port error, requiring reset and reinit: Port Status Event: ... error 1=0x52004a01, error 2=0x218 The failure means an RQ timeout. That is, the adapter had received asynchronous receive frames, ran out of buffer slots to place the frames, and the driver did not replenish the buffer slots before a timeout occurred. The driver should not be so slow in replenishing buffers that a timeout can occur. When the driver received all the frames of a sequence, it allocates an IOCB to put the frames in. In a situation where there was no IOCB available for the frame of a sequence, the RQ buffer corresponding to the first frame of the sequence was not returned to the FW. Eventually, with enough traffic encountering the situation, the timeout occurred. Fix by releasing the buffer back to firmware whenever there is no IOCB for the first frame. [mkp: typo] Link: https://lore.kernel.org/r/20200128002312.16346-2-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 f72a51eab2de06d2983ce1ddc4ff03df45546476 Author: Vasily Averin Date: Sat Feb 1 10:47:47 2020 +0300 selinux: sel_avc_get_stat_idx should increase position index [ Upstream commit 8d269a8e2a8f0bca89022f4ec98de460acb90365 ] If seq_file .next function does not change position index, read after some lseek can generate unexpected output. $ dd if=/sys/fs/selinux/avc/cache_stats # usual output lookups hits misses allocations reclaims frees 817223 810034 7189 7189 6992 7037 1934894 1926896 7998 7998 7632 7683 1322812 1317176 5636 5636 5456 5507 1560571 1551548 9023 9023 9056 9115 0+1 records in 0+1 records out 189 bytes copied, 5,1564e-05 s, 3,7 MB/s $# read after lseek to midle of last line $ dd if=/sys/fs/selinux/avc/cache_stats bs=180 skip=1 dd: /sys/fs/selinux/avc/cache_stats: cannot skip to specified offset 056 9115 <<<< end of last line 1560571 1551548 9023 9023 9056 9115 <<< whole last line once again 0+1 records in 0+1 records out 45 bytes copied, 8,7221e-05 s, 516 kB/s $# read after lseek beyond end of of file $ dd if=/sys/fs/selinux/avc/cache_stats bs=1000 skip=1 dd: /sys/fs/selinux/avc/cache_stats: cannot skip to specified offset 1560571 1551548 9023 9023 9056 9115 <<<< generates whole last line 0+1 records in 0+1 records out 36 bytes copied, 9,0934e-05 s, 396 kB/s https://bugzilla.kernel.org/show_bug.cgi?id=206283 Signed-off-by: Vasily Averin Acked-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Sasha Levin commit d96fcfd58c2157570d5e31d11e9224222c9d8976 Author: Steve Grubb Date: Fri Jan 24 17:29:16 2020 -0500 audit: CONFIG_CHANGE don't log internal bookkeeping as an event [ Upstream commit 70b3eeed49e8190d97139806f6fbaf8964306cdb ] Common Criteria calls out for any action that modifies the audit trail to be recorded. That usually is interpreted to mean insertion or removal of rules. It is not required to log modification of the inode information since the watch is still in effect. Additionally, if the rule is a never rule and the underlying file is one they do not want events for, they get an event for this bookkeeping update against their wishes. Since no device/inode info is logged at insertion and no device/inode information is logged on update, there is nothing meaningful being communicated to the admin by the CONFIG_CHANGE updated_rules event. One can assume that the rule was not "modified" because it is still watching the intended target. If the device or inode cannot be resolved, then audit_panic is called which is sufficient. The correct resolution is to drop logging config_update events since the watch is still in effect but just on another unknown inode. Signed-off-by: Steve Grubb Signed-off-by: Paul Moore Signed-off-by: Sasha Levin commit 26eae6def7809b8bb0e0dca33eac253d8ef7c385 Author: Tony Cheng Date: Tue Jan 28 16:00:22 2020 +0800 drm/amd/display: fix workaround for incorrect double buffer register for DLG ADL and TTU [ Upstream commit 85e148fb963d27152a14e6d399a47aed9bc99c15 ] [Why] these registers should have been double buffered. SW workaround we will have SW program the more aggressive (lower) values whenever we are upating this register, so we will not have underflow at expense of less optimzal request pattern. [How] there is a driver bug where we don't check for 0, which is uninitialzed HW default. since 0 is smaller than any value we need to program, driver end up with not programming these registers Signed-off-by: Tony Cheng Reviewed-by: Yongqiang Sun Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 1f483c3ef0507ad11f985a1dd7df137240f73334 Author: Trond Myklebust Date: Tue Jan 14 12:00:21 2020 -0500 nfsd: Fix a perf warning [ Upstream commit a9ceb060b3cf37987b6162223575eaf4f4e0fc36 ] perf does not know how to deal with a __builtin_bswap32() call, and complains. All other functions just store the xid etc in host endian form, so let's do that in the tracepoint for nfsd_file_acquire too. Signed-off-by: Trond Myklebust Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit 980040c7ae697bbb15735fe6dad6d63dd459a135 Author: Qian Cai Date: Tue Feb 4 13:40:29 2020 -0500 skbuff: fix a data race in skb_queue_len() [ Upstream commit 86b18aaa2b5b5bb48e609cd591b3d2d0fdbe0442 ] sk_buff.qlen can be accessed concurrently as noticed by KCSAN, BUG: KCSAN: data-race in __skb_try_recv_from_queue / unix_dgram_sendmsg read to 0xffff8a1b1d8a81c0 of 4 bytes by task 5371 on cpu 96: unix_dgram_sendmsg+0x9a9/0xb70 include/linux/skbuff.h:1821 net/unix/af_unix.c:1761 ____sys_sendmsg+0x33e/0x370 ___sys_sendmsg+0xa6/0xf0 __sys_sendmsg+0x69/0xf0 __x64_sys_sendmsg+0x51/0x70 do_syscall_64+0x91/0xb47 entry_SYSCALL_64_after_hwframe+0x49/0xbe write to 0xffff8a1b1d8a81c0 of 4 bytes by task 1 on cpu 99: __skb_try_recv_from_queue+0x327/0x410 include/linux/skbuff.h:2029 __skb_try_recv_datagram+0xbe/0x220 unix_dgram_recvmsg+0xee/0x850 ____sys_recvmsg+0x1fb/0x210 ___sys_recvmsg+0xa2/0xf0 __sys_recvmsg+0x66/0xf0 __x64_sys_recvmsg+0x51/0x70 do_syscall_64+0x91/0xb47 entry_SYSCALL_64_after_hwframe+0x49/0xbe Since only the read is operating as lockless, it could introduce a logic bug in unix_recvq_full() due to the load tearing. Fix it by adding a lockless variant of skb_queue_len() and unix_recvq_full() where READ_ONCE() is on the read while WRITE_ONCE() is on the write similar to the commit d7d16a89350a ("net: add skb_queue_empty_lockless()"). Signed-off-by: Qian Cai Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2b22cead04785733054fe089a2224248feac102e Author: Mohan Kumar Date: Thu Feb 6 15:40:53 2020 +0530 ALSA: hda: Clear RIRB status before reading WP [ Upstream commit 6d011d5057ff88ee556c000ac6fe0be23bdfcd72 ] RIRB interrupt status getting cleared after the write pointer is read causes a race condition, where last response(s) into RIRB may remain unserviced by IRQ, eventually causing azx_rirb_get_response to fall back to polling mode. Clearing the RIRB interrupt status ahead of write pointer access ensures that this condition is avoided. Signed-off-by: Mohan Kumar Signed-off-by: Viswanath L Link: https://lore.kernel.org/r/1580983853-351-1-git-send-email-viswanathl@nvidia.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit a13d21ed852667f9a2a2dfe49454c4ce9ffa7289 Author: Zhuang Yanying Date: Sat Oct 12 11:37:31 2019 +0800 KVM: fix overflow of zero page refcount with ksm running [ Upstream commit 7df003c85218b5f5b10a7f6418208f31e813f38f ] We are testing Virtual Machine with KSM on v5.4-rc2 kernel, and found the zero_page refcount overflow. The cause of refcount overflow is increased in try_async_pf (get_user_page) without being decreased in mmu_set_spte() while handling ept violation. In kvm_release_pfn_clean(), only unreserved page will call put_page. However, zero page is reserved. So, as well as creating and destroy vm, the refcount of zero page will continue to increase until it overflows. step1: echo 10000 > /sys/kernel/pages_to_scan/pages_to_scan echo 1 > /sys/kernel/pages_to_scan/run echo 1 > /sys/kernel/pages_to_scan/use_zero_pages step2: just create several normal qemu kvm vms. And destroy it after 10s. Repeat this action all the time. After a long period of time, all domains hang because of the refcount of zero page overflow. Qemu print error log as follow: … error: kvm run failed Bad address EAX=00006cdc EBX=00000008 ECX=80202001 EDX=078bfbfd ESI=ffffffff EDI=00000000 EBP=00000008 ESP=00006cc4 EIP=000efd75 EFL=00010002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] CS =0008 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA] SS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] DS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] FS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] GS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy GDT= 000f7070 00000037 IDT= 000f70ae 00000000 CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 EFER=0000000000000000 Code=00 01 00 00 00 e9 e8 00 00 00 c7 05 4c 55 0f 00 01 00 00 00 <8b> 35 00 00 01 00 8b 3d 04 00 01 00 b8 d8 d3 00 00 c1 e0 08 0c ea a3 00 00 01 00 c7 05 04 … Meanwhile, a kernel warning is departed. [40914.836375] WARNING: CPU: 3 PID: 82067 at ./include/linux/mm.h:987 try_get_page+0x1f/0x30 [40914.836412] CPU: 3 PID: 82067 Comm: CPU 0/KVM Kdump: loaded Tainted: G OE 5.2.0-rc2 #5 [40914.836415] RIP: 0010:try_get_page+0x1f/0x30 [40914.836417] Code: 40 00 c3 0f 1f 84 00 00 00 00 00 48 8b 47 08 a8 01 75 11 8b 47 34 85 c0 7e 10 f0 ff 47 34 b8 01 00 00 00 c3 48 8d 78 ff eb e9 <0f> 0b 31 c0 c3 66 90 66 2e 0f 1f 84 00 0 0 00 00 00 48 8b 47 08 a8 [40914.836418] RSP: 0018:ffffb4144e523988 EFLAGS: 00010286 [40914.836419] RAX: 0000000080000000 RBX: 0000000000000326 RCX: 0000000000000000 [40914.836420] RDX: 0000000000000000 RSI: 00004ffdeba10000 RDI: ffffdf07093f6440 [40914.836421] RBP: ffffdf07093f6440 R08: 800000424fd91225 R09: 0000000000000000 [40914.836421] R10: ffff9eb41bfeebb8 R11: 0000000000000000 R12: ffffdf06bbd1e8a8 [40914.836422] R13: 0000000000000080 R14: 800000424fd91225 R15: ffffdf07093f6440 [40914.836423] FS: 00007fb60ffff700(0000) GS:ffff9eb4802c0000(0000) knlGS:0000000000000000 [40914.836425] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [40914.836426] CR2: 0000000000000000 CR3: 0000002f220e6002 CR4: 00000000003626e0 [40914.836427] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [40914.836427] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [40914.836428] Call Trace: [40914.836433] follow_page_pte+0x302/0x47b [40914.836437] __get_user_pages+0xf1/0x7d0 [40914.836441] ? irq_work_queue+0x9/0x70 [40914.836443] get_user_pages_unlocked+0x13f/0x1e0 [40914.836469] __gfn_to_pfn_memslot+0x10e/0x400 [kvm] [40914.836486] try_async_pf+0x87/0x240 [kvm] [40914.836503] tdp_page_fault+0x139/0x270 [kvm] [40914.836523] kvm_mmu_page_fault+0x76/0x5e0 [kvm] [40914.836588] vcpu_enter_guest+0xb45/0x1570 [kvm] [40914.836632] kvm_arch_vcpu_ioctl_run+0x35d/0x580 [kvm] [40914.836645] kvm_vcpu_ioctl+0x26e/0x5d0 [kvm] [40914.836650] do_vfs_ioctl+0xa9/0x620 [40914.836653] ksys_ioctl+0x60/0x90 [40914.836654] __x64_sys_ioctl+0x16/0x20 [40914.836658] do_syscall_64+0x5b/0x180 [40914.836664] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [40914.836666] RIP: 0033:0x7fb61cb6bfc7 Signed-off-by: LinFeng Signed-off-by: Zhuang Yanying Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 54d9839877f2da80ac118a241e23b168c1bd3a3f Author: Hillf Danton Date: Wed Feb 5 10:31:59 2020 +0800 Bluetooth: prefetch channel before killing sock [ Upstream commit 2a154903cec20fb64ff4d7d617ca53c16f8fd53a ] Prefetch channel before killing sock in order to fix UAF like BUG: KASAN: use-after-free in l2cap_sock_release+0x24c/0x290 net/bluetooth/l2cap_sock.c:1212 Read of size 8 at addr ffff8880944904a0 by task syz-fuzzer/9751 Reported-by: syzbot+c3c5bdea7863886115dc@syzkaller.appspotmail.com Fixes: 6c08fc896b60 ("Bluetooth: Fix refcount use-after-free issue") Cc: Manish Mandlik Signed-off-by: Hillf Danton Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 4c67f0b1eabb8d274baa93a41f110e10f6470b5c Author: Steven Price Date: Mon Feb 3 17:35:58 2020 -0800 mm: pagewalk: fix termination condition in walk_pte_range() [ Upstream commit c02a98753e0a36ba65a05818626fa6adeb4e7c97 ] If walk_pte_range() is called with a 'end' argument that is beyond the last page of memory (e.g. ~0UL) then the comparison between 'addr' and 'end' will always fail and the loop will be infinite. Instead change the comparison to >= while accounting for overflow. Link: http://lkml.kernel.org/r/20191218162402.45610-15-steven.price@arm.com Signed-off-by: Steven Price Cc: Albert Ou Cc: Alexandre Ghiti Cc: Andy Lutomirski Cc: Ard Biesheuvel Cc: Arnd Bergmann Cc: Benjamin Herrenschmidt Cc: Borislav Petkov Cc: Catalin Marinas Cc: Christian Borntraeger Cc: Dave Hansen Cc: David S. Miller Cc: Heiko Carstens Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: James Hogan Cc: James Morse Cc: Jerome Glisse Cc: "Liang, Kan" Cc: Mark Rutland Cc: Michael Ellerman Cc: Paul Burton Cc: Paul Mackerras Cc: Paul Walmsley Cc: Peter Zijlstra Cc: Ralf Baechle Cc: Russell King Cc: Thomas Gleixner Cc: Vasily Gorbik Cc: Vineet Gupta Cc: Will Deacon Cc: Zong Li Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit dac81f1ddce556b132c18c02246302538c0c801f Author: Vasily Averin Date: Thu Jan 30 22:13:39 2020 -0800 mm/swapfile.c: swap_next should increase position index [ Upstream commit 10c8d69f314d557d94d74ec492575ae6a4f1eb1c ] If seq_file .next fuction does not change position index, read after some lseek can generate unexpected output. In Aug 2018 NeilBrown noticed commit 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code and interface") "Some ->next functions do not increment *pos when they return NULL... Note that such ->next functions are buggy and should be fixed. A simple demonstration is dd if=/proc/swaps bs=1000 skip=1 Choose any block size larger than the size of /proc/swaps. This will always show the whole last line of /proc/swaps" Described problem is still actual. If you make lseek into middle of last output line following read will output end of last line and whole last line once again. $ dd if=/proc/swaps bs=1 # usual output Filename Type Size Used Priority /dev/dm-0 partition 4194812 97536 -2 104+0 records in 104+0 records out 104 bytes copied $ dd if=/proc/swaps bs=40 skip=1 # last line was generated twice dd: /proc/swaps: cannot skip to specified offset v/dm-0 partition 4194812 97536 -2 /dev/dm-0 partition 4194812 97536 -2 3+1 records in 3+1 records out 131 bytes copied https://bugzilla.kernel.org/show_bug.cgi?id=206283 Link: http://lkml.kernel.org/r/bd8cfd7b-ac95-9b91-f9e7-e8438bd5047d@virtuozzo.com Signed-off-by: Vasily Averin Reviewed-by: Andrew Morton Cc: Jann Horn Cc: Alexander Viro Cc: Kees Cook Cc: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 8f54d39da5f4c5a8dd1a542a172a47783033291d Author: Manish Mandlik Date: Tue Jan 28 10:54:14 2020 -0800 Bluetooth: Fix refcount use-after-free issue [ Upstream commit 6c08fc896b60893c5d673764b0668015d76df462 ] There is no lock preventing both l2cap_sock_release() and chan->ops->close() from running at the same time. If we consider Thread A running l2cap_chan_timeout() and Thread B running l2cap_sock_release(), expected behavior is: A::l2cap_chan_timeout()->l2cap_chan_close()->l2cap_sock_teardown_cb() A::l2cap_chan_timeout()->l2cap_sock_close_cb()->l2cap_sock_kill() B::l2cap_sock_release()->sock_orphan() B::l2cap_sock_release()->l2cap_sock_kill() where, sock_orphan() clears "sk->sk_socket" and l2cap_sock_teardown_cb() marks socket as SOCK_ZAPPED. In l2cap_sock_kill(), there is an "if-statement" that checks if both sock_orphan() and sock_teardown() has been run i.e. sk->sk_socket is NULL and socket is marked as SOCK_ZAPPED. Socket is killed if the condition is satisfied. In the race condition, following occurs: A::l2cap_chan_timeout()->l2cap_chan_close()->l2cap_sock_teardown_cb() B::l2cap_sock_release()->sock_orphan() B::l2cap_sock_release()->l2cap_sock_kill() A::l2cap_chan_timeout()->l2cap_sock_close_cb()->l2cap_sock_kill() In this scenario, "if-statement" is true in both B::l2cap_sock_kill() and A::l2cap_sock_kill() and we hit "refcount: underflow; use-after-free" bug. Similar condition occurs at other places where teardown/sock_kill is happening: l2cap_disconnect_rsp()->l2cap_chan_del()->l2cap_sock_teardown_cb() l2cap_disconnect_rsp()->l2cap_sock_close_cb()->l2cap_sock_kill() l2cap_conn_del()->l2cap_chan_del()->l2cap_sock_teardown_cb() l2cap_conn_del()->l2cap_sock_close_cb()->l2cap_sock_kill() l2cap_disconnect_req()->l2cap_chan_del()->l2cap_sock_teardown_cb() l2cap_disconnect_req()->l2cap_sock_close_cb()->l2cap_sock_kill() l2cap_sock_cleanup_listen()->l2cap_chan_close()->l2cap_sock_teardown_cb() l2cap_sock_cleanup_listen()->l2cap_sock_kill() Protect teardown/sock_kill and orphan/sock_kill by adding hold_lock on l2cap channel to ensure that the socket is killed only after marked as zapped and orphan. Signed-off-by: Manish Mandlik Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 60d539ff1cd844a2bc6a42fd41d4aa4a7da82b90 Author: Doug Smythies Date: Mon Jan 27 19:59:56 2020 -0800 tools/power/x86/intel_pstate_tracer: changes for python 3 compatibility [ Upstream commit e749e09db30c38f1a275945814b0109e530a07b0 ] Some syntax needs to be more rigorous for python 3. Backwards compatibility tested with python 2.7 Signed-off-by: Doug Smythies Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit f15dd13158ad74ff01c816b648f04c3600e6220e Author: Sven Schnelle Date: Tue Jan 28 09:30:29 2020 +0100 selftests/ftrace: fix glob selftest [ Upstream commit af4ddd607dff7aabd466a4a878e01b9f592a75ab ] test.d/ftrace/func-filter-glob.tc is failing on s390 because it has ARCH_INLINE_SPIN_LOCK and friends set to 'y'. So the usual __raw_spin_lock symbol isn't in the ftrace function list. Change '*aw*lock' to '*spin*lock' which would hopefully match some of the locking functions on all platforms. Reviewed-by: Steven Rostedt (VMware) Signed-off-by: Sven Schnelle Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 379deeac55dafdc9e43c5f9c95e8c04f6ce0a168 Author: Jeff Layton Date: Thu Dec 5 08:41:25 2019 -0500 ceph: ensure we have a new cap before continuing in fill_inode [ Upstream commit 9a6bed4fe0c8bf57785cbc4db9f86086cb9b193d ] If the caller passes in a NULL cap_reservation, and we can't allocate one then ensure that we fail gracefully. Signed-off-by: Jeff Layton Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 5a5fa887629173bf884cfde5c5b9b60ca1bf8674 Author: Mert Dirik Date: Thu Jan 16 14:11:25 2020 +0300 ar5523: Add USB ID of SMCWUSBT-G2 wireless adapter [ Upstream commit 5b362498a79631f283578b64bf6f4d15ed4cc19a ] Add the required USB ID for running SMCWUSBT-G2 wireless adapter (SMC "EZ Connect g"). This device uses ar5523 chipset and requires firmware to be loaded. Even though pid of the device is 4507, this patch adds it as 4506 so that AR5523_DEVICE_UG macro can set the AR5523_FLAG_PRE_FIRMWARE flag for pid 4507. Signed-off-by: Mert Dirik Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 47634c0fc94c398c0d37c36be171aa0e3e6c5207 Author: Vincent Whitchurch Date: Mon Dec 16 11:48:28 2019 +0100 ARM: 8948/1: Prevent OOB access in stacktrace [ Upstream commit 40ff1ddb5570284e039e0ff14d7a859a73dc3673 ] The stacktrace code can read beyond the stack size, when it attempts to read pt_regs from exception frames. This can happen on normal, non-corrupt stacks. Since the unwind information in the extable is not correct for function prologues, the unwinding code can return data from the stack which is not actually the caller function address, and if in_entry_text() happens to succeed on this value, we can end up reading data from outside the task's stack when attempting to read pt_regs, since there is no bounds check. Example: [<8010e729>] (unwind_backtrace) from [<8010a9c9>] (show_stack+0x11/0x14) [<8010a9c9>] (show_stack) from [<8057d8d7>] (dump_stack+0x87/0xac) [<8057d8d7>] (dump_stack) from [<8012271d>] (tasklet_action_common.constprop.4+0xa5/0xa8) [<8012271d>] (tasklet_action_common.constprop.4) from [<80102333>] (__do_softirq+0x11b/0x31c) [<80102333>] (__do_softirq) from [<80122485>] (irq_exit+0xad/0xd8) [<80122485>] (irq_exit) from [<8015f3d7>] (__handle_domain_irq+0x47/0x84) [<8015f3d7>] (__handle_domain_irq) from [<8036a523>] (gic_handle_irq+0x43/0x78) [<8036a523>] (gic_handle_irq) from [<80101a49>] (__irq_svc+0x69/0xb4) Exception stack(0xeb491f58 to 0xeb491fa0) 1f40: 7eb14794 00000000 1f60: ffffffff 008dd32c 008dd324 ffffffff 008dd314 0000002a 801011e4 eb490000 1f80: 0000002a 7eb1478c 50c5387d eb491fa8 80101001 8023d09c 40080033 ffffffff [<80101a49>] (__irq_svc) from [<8023d09c>] (do_pipe2+0x0/0xac) [<8023d09c>] (do_pipe2) from [] (0xffffffff) Exception stack(0xeb491fc8 to 0xeb492010) 1fc0: 008dd314 0000002a 00511ad8 008de4c8 7eb14790 7eb1478c 1fe0: 00511e34 7eb14774 004c8557 76f44098 60080030 7eb14794 00000000 00000000 2000: 00000001 00000000 ea846c00 ea847cc0 In this example, the stack limit is 0xeb492000, but 16 bytes outside the stack have been read. Fix it by adding bounds checks. Signed-off-by: Vincent Whitchurch Signed-off-by: Russell King Signed-off-by: Sasha Levin commit 5093d01f0809e1236d2a4351b1c2533b7234e3f8 Author: Josef Bacik Date: Wed Sep 24 16:14:12 2014 -0400 tracing: Set kernel_stack's caller size properly [ Upstream commit cbc3b92ce037f5e7536f6db157d185cd8b8f615c ] I noticed when trying to use the trace-cmd python interface that reading the raw buffer wasn't working for kernel_stack events. This is because it uses a stubbed version of __dynamic_array that doesn't do the __data_loc trick and encode the length of the array into the field. Instead it just shows up as a size of 0. So change this to __array and set the len to FTRACE_STACK_ENTRIES since this is what we actually do in practice and matches how user_stack_trace works. Link: http://lkml.kernel.org/r/1411589652-1318-1-git-send-email-jbacik@fb.com Signed-off-by: Josef Bacik [ Pulled from the archeological digging of my INBOX ] Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 0c81861ae9036f7343b0f8a4640dedd923af4f9b Author: Maxim Mikityanskiy Date: Fri Jan 24 19:15:35 2020 +0200 Bluetooth: btrtl: Use kvmalloc for FW allocations [ Upstream commit 268d3636dfb22254324774de1f8875174b3be064 ] Currently, kmemdup is applied to the firmware data, and it invokes kmalloc under the hood. The firmware size and patch_length are big (more than PAGE_SIZE), and on some low-end systems (like ASUS E202SA) kmalloc may fail to allocate a contiguous chunk under high memory usage and fragmentation: Bluetooth: hci0: RTL: examining hci_ver=06 hci_rev=000a lmp_ver=06 lmp_subver=8821 Bluetooth: hci0: RTL: rom_version status=0 version=1 Bluetooth: hci0: RTL: loading rtl_bt/rtl8821a_fw.bin kworker/u9:2: page allocation failure: order:4, mode:0x40cc0(GFP_KERNEL|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0 As firmware load happens on each resume, Bluetooth will stop working after several iterations, when the kernel fails to allocate an order-4 page. This patch replaces kmemdup with kvmalloc+memcpy. It's not required to have a contiguous chunk here, because it's not mapped to the device directly. Signed-off-by: Maxim Mikityanskiy Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 821bf0bf652c8d9de30c7307211e67775ec24ec0 Author: Oliver O'Halloran Date: Wed Oct 16 12:25:36 2019 +1100 powerpc/eeh: Only dump stack once if an MMIO loop is detected [ Upstream commit 4e0942c0302b5ad76b228b1a7b8c09f658a1d58a ] Many drivers don't check for errors when they get a 0xFFs response from an MMIO load. As a result after an EEH event occurs a driver can get stuck in a polling loop unless it some kind of internal timeout logic. Currently EEH tries to detect and report stuck drivers by dumping a stack trace after eeh_dev_check_failure() is called EEH_MAX_FAILS times on an already frozen PE. The value of EEH_MAX_FAILS was chosen so that a dump would occur every few seconds if the driver was spinning in a loop. This results in a lot of spurious stack traces in the kernel log. Fix this by limiting it to printing one stack trace for each PE freeze. If the driver is truely stuck the kernel's hung task detector is better suited to reporting the probelm anyway. Signed-off-by: Oliver O'Halloran Reviewed-by: Sam Bobroff Tested-by: Sam Bobroff Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191016012536.22588-1-oohall@gmail.com Signed-off-by: Sasha Levin commit fed639f7e1d5e562f58a1d2de87490e43831e519 Author: Trond Myklebust Date: Mon Jan 6 13:20:47 2020 -0500 nfsd: Fix a soft lockup race in nfsd_file_mark_find_or_create() [ Upstream commit 90d2f1da832fd23290ef0c0d964d97501e5e8553 ] If nfsd_file_mark_find_or_create() keeps winning the race for the nfsd_file_fsnotify_group->mark_mutex against nfsd_file_mark_put() then it can soft lock up, since fsnotify_add_inode_mark() ends up always finding an existing entry. Signed-off-by: Trond Myklebust Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit 4f726a2afb99f1ba2d8af4251c0b44562511cf7a Author: Thomas Richter Date: Thu Dec 19 14:56:13 2019 +0100 s390/cpum_sf: Use kzalloc and minor changes [ Upstream commit 32dab6828c42f087439d3e2617dc7283546bd8f7 ] Use kzalloc() to allocate auxiliary buffer structure initialized with all zeroes to avoid random value in trace output. Avoid double access to SBD hardware flags. Signed-off-by: Thomas Richter Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 26966e89ca14ba279eb44c6f12c3f4545a653fa6 Author: Matthias Fend Date: Wed Jan 15 11:22:49 2020 +0100 dmaengine: zynqmp_dma: fix burst length configuration [ Upstream commit cc88525ebffc757e00cc5a5d61da6271646c7f5f ] Since the dma engine expects the burst length register content as power of 2 value, the burst length needs to be converted first. Additionally add a burst length range check to avoid corrupting unrelated register bits. Signed-off-by: Matthias Fend Link: https://lore.kernel.org/r/20200115102249.24398-1-matthias.fend@wolfvision.net Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit d64f6dfdf4ab2d8c1c67718d5a8d6e735ef49f12 Author: Qu Wenruo Date: Tue Dec 17 18:58:20 2019 +0800 btrfs: tree-checker: Check leaf chunk item size [ Upstream commit f6d2a5c263afca84646cf3300dc13061bedbd99e ] Inspired by btrfs-progs github issue #208, where chunk item in chunk tree has invalid num_stripes (0). Although that can already be caught by current btrfs_check_chunk_valid(), that function doesn't really check item size as it needs to handle chunk item in super block sys_chunk_array(). This patch will add two extra checks for chunk items in chunk tree: - Basic chunk item size If the item is smaller than btrfs_chunk (which already contains one stripe), exit right now as reading num_stripes may even go beyond eb boundary. - Item size check against num_stripes If item size doesn't match with calculated chunk size, then either the item size or the num_stripes is corrupted. Error out anyway. Reviewed-by: Josef Bacik Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 2bbe85d911feb8faeeab92b81967ffd3431d430e Author: Dmitry Osipenko Date: Tue Jan 14 04:34:37 2020 +0300 i2c: tegra: Prevent interrupt triggering after transfer timeout [ Upstream commit b5d5605ca3cebb9b16c4f251635ef171ad18b80d ] Potentially it is possible that interrupt may fire after transfer timeout. That may not end up well for the next transfer because interrupt handling may race with hardware resetting. This is very unlikely to happen in practice, but anyway let's prevent the potential problem by enabling interrupt only at the moments when it is actually necessary to get some interrupt event. Tested-by: Thierry Reding Signed-off-by: Dmitry Osipenko Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 1e4a6a0e03bcf1d042d5f522ea51ce9a40d57070 Author: David Francis Date: Fri Aug 16 13:43:46 2019 -0400 drm/amd/display: Initialize DSC PPS variables to 0 [ Upstream commit b6adc57cff616da18ff8cff028d2ddf585c97334 ] For DSC MST, sometimes monitors would break out in full-screen static. The issue traced back to the PPS generation code, where these variables were being used uninitialized and were picking up garbage. memset to 0 to avoid this Reviewed-by: Nicholas Kazlauskas Signed-off-by: David Francis Signed-off-by: Mikita Lipski Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 65f2f192526fde7e254d5c8e83f318240a032843 Author: Bart Van Assche Date: Tue Dec 24 14:02:46 2019 -0800 scsi: ufs: Fix a race condition in the tracing code [ Upstream commit eacf36f5bebde5089dddb3d5bfcbeab530b01f8a ] Starting execution of a command before tracing a command may cause the completion handler to free data while it is being traced. Fix this race by tracing a command before it is submitted. Cc: Bean Huo Cc: Can Guo Cc: Avri Altman Cc: Stanley Chu Cc: Tomas Winkler Link: https://lore.kernel.org/r/20191224220248.30138-5-bvanassche@acm.org Reviewed-by: Alim Akhtar Signed-off-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 1ac994f80be2af7729e4e1b8270eeb1560f09f2a Author: Bart Van Assche Date: Tue Dec 24 14:02:44 2019 -0800 scsi: ufs: Make ufshcd_add_command_trace() easier to read [ Upstream commit e4d2add7fd5bc64ee3e388eabe6b9e081cb42e11 ] Since the lrbp->cmd expression occurs multiple times, introduce a new local variable to hold that pointer. This patch does not change any functionality. Cc: Bean Huo Cc: Can Guo Cc: Avri Altman Cc: Stanley Chu Cc: Tomas Winkler Link: https://lore.kernel.org/r/20191224220248.30138-3-bvanassche@acm.org Reviewed-by: Stanley Chu Reviewed-by: Can Guo Reviewed-by: Alim Akhtar Signed-off-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 3d05b30722325922314000e30ff48264b1b49c42 Author: Rafael J. Wysocki Date: Fri Dec 27 11:04:21 2019 +0100 ACPI: EC: Reference count query handlers under lock [ Upstream commit 3df663a147fe077a6ee8444ec626738946e65547 ] There is a race condition in acpi_ec_get_query_handler() theoretically allowing query handlers to go away before refernce counting them. In order to avoid it, call kref_get() on query handlers under ec->mutex. Also simplify the code a bit while at it. Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 95ceefc6f0ce47a68fcc01517d530b019d503b43 Author: Kevin Kou Date: Thu Dec 26 12:29:17 2019 +0000 sctp: move trace_sctp_probe_path into sctp_outq_sack [ Upstream commit f643ee295c1c63bc117fb052d4da681354d6f732 ] The original patch bringed in the "SCTP ACK tracking trace event" feature was committed at Dec.20, 2017, it replaced jprobe usage with trace events, and bringed in two trace events, one is TRACE_EVENT(sctp_probe), another one is TRACE_EVENT(sctp_probe_path). The original patch intended to trigger the trace_sctp_probe_path in TRACE_EVENT(sctp_probe) as below code, +TRACE_EVENT(sctp_probe, + + TP_PROTO(const struct sctp_endpoint *ep, + const struct sctp_association *asoc, + struct sctp_chunk *chunk), + + TP_ARGS(ep, asoc, chunk), + + TP_STRUCT__entry( + __field(__u64, asoc) + __field(__u32, mark) + __field(__u16, bind_port) + __field(__u16, peer_port) + __field(__u32, pathmtu) + __field(__u32, rwnd) + __field(__u16, unack_data) + ), + + TP_fast_assign( + struct sk_buff *skb = chunk->skb; + + __entry->asoc = (unsigned long)asoc; + __entry->mark = skb->mark; + __entry->bind_port = ep->base.bind_addr.port; + __entry->peer_port = asoc->peer.port; + __entry->pathmtu = asoc->pathmtu; + __entry->rwnd = asoc->peer.rwnd; + __entry->unack_data = asoc->unack_data; + + if (trace_sctp_probe_path_enabled()) { + struct sctp_transport *sp; + + list_for_each_entry(sp, &asoc->peer.transport_addr_list, + transports) { + trace_sctp_probe_path(sp, asoc); + } + } + ), But I found it did not work when I did testing, and trace_sctp_probe_path had no output, I finally found that there is trace buffer lock operation(trace_event_buffer_reserve) in include/trace/trace_events.h: static notrace void \ trace_event_raw_event_##call(void *__data, proto) \ { \ struct trace_event_file *trace_file = __data; \ struct trace_event_data_offsets_##call __maybe_unused __data_offsets;\ struct trace_event_buffer fbuffer; \ struct trace_event_raw_##call *entry; \ int __data_size; \ \ if (trace_trigger_soft_disabled(trace_file)) \ return; \ \ __data_size = trace_event_get_offsets_##call(&__data_offsets, args); \ \ entry = trace_event_buffer_reserve(&fbuffer, trace_file, \ sizeof(*entry) + __data_size); \ \ if (!entry) \ return; \ \ tstruct \ \ { assign; } \ \ trace_event_buffer_commit(&fbuffer); \ } The reason caused no output of trace_sctp_probe_path is that trace_sctp_probe_path written in TP_fast_assign part of TRACE_EVENT(sctp_probe), and it will be placed( { assign; } ) after the trace_event_buffer_reserve() when compiler expands Macro, entry = trace_event_buffer_reserve(&fbuffer, trace_file, \ sizeof(*entry) + __data_size); \ \ if (!entry) \ return; \ \ tstruct \ \ { assign; } \ so trace_sctp_probe_path finally can not acquire trace_event_buffer and return no output, that is to say the nest of tracepoint entry function is not allowed. The function call flow is: trace_sctp_probe() -> trace_event_raw_event_sctp_probe() -> lock buffer -> trace_sctp_probe_path() -> trace_event_raw_event_sctp_probe_path() --nested -> buffer has been locked and return no output. This patch is to remove trace_sctp_probe_path from the TP_fast_assign part of TRACE_EVENT(sctp_probe) to avoid the nest of entry function, and trigger sctp_probe_path_trace in sctp_outq_sack. After this patch, you can enable both events individually, # cd /sys/kernel/debug/tracing # echo 1 > events/sctp/sctp_probe/enable # echo 1 > events/sctp/sctp_probe_path/enable Or, you can enable all the events under sctp. # echo 1 > events/sctp/enable Signed-off-by: Kevin Kou Acked-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a9e53499f4de56277f76ae2d362248a0632a5bc2 Author: James Smart Date: Wed Dec 18 15:57:59 2019 -0800 scsi: lpfc: Fix incomplete NVME discovery when target [ Upstream commit be0709e449ac9d9753a5c17e5b770d6e5e930e4a ] NVMe device re-discovery does not complete. Dev_loss_tmo messages seen on initiator after recovery from a link disturbance. The failing case is the following: When the driver (as a NVME target) receives a PLOGI, the driver initiates an "unreg rpi" mailbox command. While the mailbox command is in progress, the driver requests that an ACC be sent to the initiator. The target's ACC is received by the initiator and the initiator then transmits a PLOGI. The driver receives the PLOGI prior to receiving the completion for the PLOGI response WQE that sent the ACC. (Different delivery sources from the hw so the race is very possible). Given the PLOGI is prior to the ACC completion (signifying PLOGI exchange complete), the driver LS_RJT's the PRLI. The "unreg rpi" mailbox then completes. Since PRLI has been received, the driver transmits a PLOGI to restart discovery, which the initiator then ACC's. If the driver processes the (re)PLOGI ACC prior to the completing the handling for the earlier ACC it sent the intiators original PLOGI, there is no state change for completion of the (re)PLOGI. The ndlp remains in "PLOGI Sent" and the initiator continues sending PRLI's which are rejected by the target until timeout or retry is reached. Fix by: When in target mode, defer sending an ACC for the received PLOGI until unreg RPI completes. Link: https://lore.kernel.org/r/20191218235808.31922-2-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 64d2887486d142ae218c4fee09caccccd1bd9eb8 Author: Quinn Tran Date: Tue Dec 17 14:06:15 2019 -0800 scsi: qla2xxx: Fix stuck session in GNL [ Upstream commit e1217dc3edce62895595cf484af33b9e0379b7f3 ] Fix race condition between GNL completion processing and GNL request. Late submission of GNL request was not seen by the GNL completion thread. This patch will re-submit the GNL request for late submission fcport. Link: https://lore.kernel.org/r/20191217220617.28084-13-hmadhani@marvell.com Signed-off-by: Quinn Tran Signed-off-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 9f7d28075ae4a3679e821051e0a69f431ca3afff Author: Viresh Kumar Date: Mon Nov 11 16:35:03 2019 +0530 opp: Replace list_kref with a local counter [ Upstream commit 03758d60265c773e1d06d436b99ee338f2ac55d6 ] A kref or refcount isn't the right tool to be used here for counting number of devices that are sharing the static OPPs created for the OPP table. For example, we are reinitializing the kref again, after it reaches a value of 0 and frees the resources, if the static OPPs get added for the same OPP table structure (as the OPP table structure was never freed). That is messy and very unclear. This patch makes parsed_static_opps an unsigned integer and uses it to count the number of users of the static OPPs. The increment and decrement to parsed_static_opps is done under opp_table->lock now to make sure no races are possible if the OPP table is getting added and removed in parallel (which doesn't happen in practice, but can in theory). Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 8c324ef0b46664be9443e12e63f65cc8b27a8d56 Author: Nikhil Devshatwar Date: Tue Nov 12 15:53:33 2019 +0100 media: ti-vpe: cal: Restrict DMA to avoid memory corruption [ Upstream commit 6e72eab2e7b7a157d554b8f9faed7676047be7c1 ] When setting DMA for video capture from CSI channel, if the DMA size is not given, it ends up writing as much data as sent by the camera. This may lead to overwriting the buffers causing memory corruption. Observed green lines on the default framebuffer. Restrict the DMA to maximum height as specified in the S_FMT ioctl. Signed-off-by: Nikhil Devshatwar Signed-off-by: Benoit Parrot Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 4a4c78cf0cf756280b1ce81b907008a356a17d5a Author: Andrey Grodzovsky Date: Mon Nov 25 15:51:29 2019 -0500 drm/scheduler: Avoid accessing freed bad job. [ Upstream commit 135517d3565b48f4def3b1b82008bc17eb5d1c90 ] Problem: Due to a race between drm_sched_cleanup_jobs in sched thread and drm_sched_job_timedout in timeout work there is a possiblity that bad job was already freed while still being accessed from the timeout thread. Fix: Instead of just peeking at the bad job in the mirror list remove it from the list under lock and then put it back later when we are garanteed no race with main sched thread is possible which is after the thread is parked. v2: Lock around processing ring_mirror_list in drm_sched_cleanup_jobs. v3: Rebase on top of drm-misc-next. v2 is not needed anymore as drm_sched_get_cleanup_job already has a lock there. v4: Fix comments to relfect latest code in drm-misc. Signed-off-by: Andrey Grodzovsky Reviewed-by: Christian König Reviewed-by: Emily Deng Tested-by: Emily Deng Signed-off-by: Christian König Link: https://patchwork.freedesktop.org/patch/342356 Signed-off-by: Sasha Levin commit 06a90303633ffcd18bece6e41bb4a7787b9f34c2 Author: Marco Elver Date: Thu Nov 14 19:03:00 2019 +0100 seqlock: Require WRITE_ONCE surrounding raw_seqcount_barrier [ Upstream commit bf07132f96d426bcbf2098227fb680915cf44498 ] This patch proposes to require marked atomic accesses surrounding raw_write_seqcount_barrier. We reason that otherwise there is no way to guarantee propagation nor atomicity of writes before/after the barrier [1]. For example, consider the compiler tears stores either before or after the barrier; in this case, readers may observe a partial value, and because readers are unaware that writes are going on (writes are not in a seq-writer critical section), will complete the seq-reader critical section while having observed some partial state. [1] https://lwn.net/Articles/793253/ This came up when designing and implementing KCSAN, because KCSAN would flag these accesses as data-races. After careful analysis, our reasoning as above led us to conclude that the best thing to do is to propose an amendment to the raw_seqcount_barrier usage. Signed-off-by: Marco Elver Acked-by: Paul E. McKenney Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit a9d4bca63493623412e3d0b5e605c4a7d022ffc5 Author: Stephan Gerhold Date: Wed Nov 6 17:58:35 2019 +0100 drm/mcde: Handle pending vblank while disabling display [ Upstream commit 97de863673f07f424dd0666aefb4b6ecaba10171 ] Disabling the display using MCDE currently results in a warning together with a delay caused by some timeouts: mcde a0350000.mcde: MCDE display is disabled ------------[ cut here ]------------ WARNING: CPU: 0 PID: 20 at drivers/gpu/drm/drm_atomic_helper.c:2258 drm_atomic_helper_commit_hw_done+0xe0/0xe4 Hardware name: ST-Ericsson Ux5x0 platform (Device Tree Support) Workqueue: events drm_mode_rmfb_work_fn [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0x84/0x98) [] (dump_stack) from [] (__warn+0xb8/0xd4) [] (__warn) from [] (warn_slowpath_fmt+0x64/0xc4) [] (warn_slowpath_fmt) from [] (drm_atomic_helper_commit_hw_done+0xe0/0xe4) [] (drm_atomic_helper_commit_hw_done) from [] (drm_atomic_helper_commit_tail_rpm+0x44/0x6c) [] (drm_atomic_helper_commit_tail_rpm) from [] (commit_tail+0x50/0x10c) [] (commit_tail) from [] (drm_atomic_helper_commit+0xbc/0x128) [] (drm_atomic_helper_commit) from [] (drm_framebuffer_remove+0x390/0x428) [] (drm_framebuffer_remove) from [] (drm_mode_rmfb_work_fn+0x38/0x48) [] (drm_mode_rmfb_work_fn) from [] (process_one_work+0x1f0/0x43c) [] (process_one_work) from [] (worker_thread+0x254/0x55c) [] (worker_thread) from [] (kthread+0x124/0x150) [] (kthread) from [] (ret_from_fork+0x14/0x2c) Exception stack(0xeb14dfb0 to 0xeb14dff8) dfa0: 00000000 00000000 00000000 00000000 dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 ---[ end trace 314909bcd4c7d50c ]--- [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:32:crtc-0] flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:34:DSI-1] flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:31:plane-0] flip_done timed out The reason for this is that there is a vblank event pending, but we never handle it after disabling the vblank interrupts. Check if there is an vblank event pending when disabling the display, and clear it by sending a fake vblank event in that case. Signed-off-by: Stephan Gerhold Tested-by: Linus Walleij Reviewed-by: Linus Walleij Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20191106165835.2863-8-stephan@gerhold.net Signed-off-by: Sasha Levin commit c89925822f8219fb0416483536b4d9b3401d03e9 Author: Vasily Averin Date: Thu Jan 23 10:12:06 2020 +0300 ipv6_route_seq_next should increase position index [ Upstream commit 4fc427e0515811250647d44de38d87d7b0e0790f ] if seq_file .next fuction does not change position index, read after some lseek can generate unexpected output. https://bugzilla.kernel.org/show_bug.cgi?id=206283 Signed-off-by: Vasily Averin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 046e79cca228344999e16139ead9aae97960606e Author: Vasily Averin Date: Thu Jan 23 10:11:35 2020 +0300 rt_cpu_seq_next should increase position index [ Upstream commit a3ea86739f1bc7e121d921842f0f4a8ab1af94d9 ] if seq_file .next fuction does not change position index, read after some lseek can generate unexpected output. https://bugzilla.kernel.org/show_bug.cgi?id=206283 Signed-off-by: Vasily Averin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2ba309f086b822d89a7d8528d1516e5eebf49791 Author: Vasily Averin Date: Thu Jan 23 10:11:28 2020 +0300 neigh_stat_seq_next() should increase position index [ Upstream commit 1e3f9f073c47bee7c23e77316b07bc12338c5bba ] if seq_file .next fuction does not change position index, read after some lseek can generate unexpected output. https://bugzilla.kernel.org/show_bug.cgi?id=206283 Signed-off-by: Vasily Averin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f508c5d99343555e9c1abbc4c10ae412da539a4c Author: Vasily Averin Date: Thu Jan 23 10:11:20 2020 +0300 vcc_seq_next should increase position index [ Upstream commit 8bf7092021f283944f0c5f4c364853201c45c611 ] if seq_file .next fuction does not change position index, read after some lseek can generate unexpected output. https://bugzilla.kernel.org/show_bug.cgi?id=206283 Signed-off-by: Vasily Averin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8c926e159aface3567b2ded6024b1b14c0f27f18 Author: Tuong Lien Date: Wed Jan 8 09:18:15 2020 +0700 tipc: fix link overflow issue at socket shutdown [ Upstream commit 49afb806cb650dd1f06f191994f3aa657d264009 ] When a socket is suddenly shutdown or released, it will reject all the unreceived messages in its receive queue. This applies to a connected socket too, whereas there is only one 'FIN' message required to be sent back to its peer in this case. In case there are many messages in the queue and/or some connections with such messages are shutdown at the same time, the link layer will easily get overflowed at the 'TIPC_SYSTEM_IMPORTANCE' backlog level because of the message rejections. As a result, the link will be taken down. Moreover, immediately when the link is re-established, the socket layer can continue to reject the messages and the same issue happens... The commit refactors the '__tipc_shutdown()' function to only send one 'FIN' in the situation mentioned above. For the connectionless case, it is unavoidable but usually there is no rejections for such socket messages because they are 'dest-droppable' by default. In addition, the new code makes the other socket states clear (e.g.'TIPC_LISTEN') and treats as a separate case to avoid misbehaving. Acked-by: Ying Xue Acked-by: Jon Maloy Signed-off-by: Tuong Lien Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f99f4372f544fed7eb8b0ad6078ceee3a9a2e419 Author: Kai Vehmanen Date: Wed Jan 8 20:08:56 2020 +0200 ALSA: hda: enable regmap internal locking [ Upstream commit 8e85def5723eccea30ebf22645673692ab8cb3e2 ] This reverts commit 42ec336f1f9d ("ALSA: hda: Disable regmap internal locking"). Without regmap locking, there is a race between snd_hda_codec_amp_init() and PM callbacks issuing regcache_sync(). This was caught by following kernel warning trace: <4> [358.080081] WARNING: CPU: 2 PID: 4157 at drivers/base/regmap/regcache.c:498 regcache_cache_only+0xf5/0x130 [...] <4> [358.080148] Call Trace: <4> [358.080158] snd_hda_codec_amp_init+0x4e/0x100 [snd_hda_codec] <4> [358.080169] snd_hda_codec_amp_init_stereo+0x40/0x80 [snd_hda_codec] Suggested-by: Takashi Iwai BugLink: https://gitlab.freedesktop.org/drm/intel/issues/592 Signed-off-by: Kai Vehmanen Link: https://lore.kernel.org/r/20200108180856.5194-1-kai.vehmanen@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit b56212ddca0fd90c683d1bab88ac5ac01678de46 Author: Darrick J. Wong Date: Wed Dec 11 13:19:07 2019 -0800 xfs: fix log reservation overflows when allocating large rt extents [ Upstream commit b1de6fc7520fe12949c070af0e8c0e4044cd3420 ] Omar Sandoval reported that a 4G fallocate on the realtime device causes filesystem shutdowns due to a log reservation overflow that happens when we log the rtbitmap updates. Factor rtbitmap/rtsummary updates into the the tr_write and tr_itruncate log reservation calculation. "The following reproducer results in a transaction log overrun warning for me: mkfs.xfs -f -r rtdev=/dev/vdc -d rtinherit=1 -m reflink=0 /dev/vdb mount -o rtdev=/dev/vdc /dev/vdb /mnt fallocate -l 4G /mnt/foo Reported-by: Omar Sandoval Tested-by: Omar Sandoval Signed-off-by: Darrick J. Wong Reviewed-by: Brian Foster Signed-off-by: Sasha Levin commit 16d40ce11521758b0f2d2260ab84fb97a97fc932 Author: Steven Rostedt (VMware) Date: Mon Dec 9 10:33:30 2019 -0500 module: Remove accidental change of module_enable_x() [ Upstream commit af74262337faa65d5ac2944553437d3f5fb29123 ] When pulling in Divya Indi's patch, I made a minor fix to remove unneeded braces. I commited my fix up via "git commit -a --amend". Unfortunately, I didn't realize I had some changes I was testing in the module code, and those changes were applied to Divya's patch as well. This reverts the accidental updates to the module code. Cc: Jessica Yu Cc: Divya Indi Reported-by: Peter Zijlstra Fixes: e585e6469d6f ("tracing: Verify if trace array exists before destroying it.") Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 566b1bb7d393ae7ddf03c9ea6e665755493bd5cf Author: Miaohe Lin Date: Thu Nov 28 14:38:48 2019 +0800 KVM: arm/arm64: vgic: Fix potential double free dist->spis in __kvm_vgic_destroy() [ Upstream commit 0bda9498dd45280e334bfe88b815ebf519602cc3 ] In kvm_vgic_dist_init() called from kvm_vgic_map_resources(), if dist->vgic_model is invalid, dist->spis will be freed without set dist->spis = NULL. And in vgicv2 resources clean up path, __kvm_vgic_destroy() will be called to free allocated resources. And dist->spis will be freed again in clean up chain because we forget to set dist->spis = NULL in kvm_vgic_dist_init() failed path. So double free would happen. Signed-off-by: Miaohe Lin Signed-off-by: Marc Zyngier Reviewed-by: Eric Auger Link: https://lore.kernel.org/r/1574923128-19956-1-git-send-email-linmiaohe@huawei.com Signed-off-by: Sasha Levin commit c306458a2bd0f5e8f2da1aba809039662cf963e8 Author: Joe Perches Date: Wed Dec 4 16:50:53 2019 -0800 kernel/sys.c: avoid copying possible padding bytes in copy_to_user [ Upstream commit 5e1aada08cd19ea652b2d32a250501d09b02ff2e ] Initialization is not guaranteed to zero padding bytes so use an explicit memset instead to avoid leaking any kernel content in any possible padding bytes. Link: http://lkml.kernel.org/r/dfa331c00881d61c8ee51577a082d8bebd61805c.camel@perches.com Signed-off-by: Joe Perches Cc: Dan Carpenter Cc: Julia Lawall Cc: Thomas Gleixner Cc: Kees Cook Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit e95e4ba3efd80a54cea46def1d78825510502b36 Author: Xiaoming Ni Date: Wed Dec 4 16:50:39 2019 -0800 kernel/notifier.c: intercept duplicate registrations to avoid infinite loops [ Upstream commit 1a50cb80f219c44adb6265f5071b81fc3c1deced ] Registering the same notifier to a hook repeatedly can cause the hook list to form a ring or lose other members of the list. case1: An infinite loop in notifier_chain_register() can cause soft lockup atomic_notifier_chain_register(&test_notifier_list, &test1); atomic_notifier_chain_register(&test_notifier_list, &test1); atomic_notifier_chain_register(&test_notifier_list, &test2); case2: An infinite loop in notifier_chain_register() can cause soft lockup atomic_notifier_chain_register(&test_notifier_list, &test1); atomic_notifier_chain_register(&test_notifier_list, &test1); atomic_notifier_call_chain(&test_notifier_list, 0, NULL); case3: lose other hook test2 atomic_notifier_chain_register(&test_notifier_list, &test1); atomic_notifier_chain_register(&test_notifier_list, &test2); atomic_notifier_chain_register(&test_notifier_list, &test1); case4: Unregister returns 0, but the hook is still in the linked list, and it is not really registered. If you call notifier_call_chain after ko is unloaded, it will trigger oops. If the system is configured with softlockup_panic and the same hook is repeatedly registered on the panic_notifier_list, it will cause a loop panic. Add a check in notifier_chain_register(), intercepting duplicate registrations to avoid infinite loops Link: http://lkml.kernel.org/r/1568861888-34045-2-git-send-email-nixiaoming@huawei.com Signed-off-by: Xiaoming Ni Reviewed-by: Vasily Averin Reviewed-by: Andrew Morton Cc: Alexey Dobriyan Cc: Anna Schumaker Cc: Arjan van de Ven Cc: J. Bruce Fields Cc: Chuck Lever Cc: David S. Miller Cc: Jeff Layton Cc: Andy Lutomirski Cc: Ingo Molnar Cc: Nadia Derbey Cc: "Paul E. McKenney" Cc: Sam Protsenko Cc: Alan Stern Cc: Thomas Gleixner Cc: Trond Myklebust Cc: Viresh Kumar Cc: Xiaoming Ni Cc: YueHaibing Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 425582bd448cf113e72d1ab17d0a009008038dac Author: Stanislav Fomichev Date: Wed Dec 4 11:09:55 2019 -0800 selftests/bpf: De-flake test_tcpbpf [ Upstream commit ef8c84effce3c7a0b8196fcda8f430c815ab511c ] It looks like BPF program that handles BPF_SOCK_OPS_STATE_CB state can race with the bpf_map_lookup_elem("global_map"); I sometimes see the failures in this test and re-running helps. Since we know that we expect the callback to be called 3 times (one time for listener socket, two times for both ends of the connection), let's export this number and add simple retry logic around that. Also, let's make EXPECT_EQ() not return on failure, but continue evaluating all conditions; that should make potential debugging easier. With this fix in place I don't observe the flakiness anymore. Signed-off-by: Stanislav Fomichev Signed-off-by: Alexei Starovoitov Cc: Lawrence Brakmo Link: https://lore.kernel.org/bpf/20191204190955.170934-1-sdf@google.com Signed-off-by: Sasha Levin commit 3283bd6d19cdc38ae553367a68578741cc01e0e4 Author: Mark Rutland Date: Mon Dec 2 16:11:07 2019 +0000 arm64: insn: consistently handle exit text [ Upstream commit ca2ef4ffabbef25644e02a98b0f48869f8be0375 ] A kernel built with KASAN && FTRACE_WITH_REGS && !MODULES, produces a boot-time splat in the bowels of ftrace: | [ 0.000000] ftrace: allocating 32281 entries in 127 pages | [ 0.000000] ------------[ cut here ]------------ | [ 0.000000] WARNING: CPU: 0 PID: 0 at kernel/trace/ftrace.c:2019 ftrace_bug+0x27c/0x328 | [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.4.0-rc3-00008-g7f08ae53a7e3 #13 | [ 0.000000] Hardware name: linux,dummy-virt (DT) | [ 0.000000] pstate: 60000085 (nZCv daIf -PAN -UAO) | [ 0.000000] pc : ftrace_bug+0x27c/0x328 | [ 0.000000] lr : ftrace_init+0x640/0x6cc | [ 0.000000] sp : ffffa000120e7e00 | [ 0.000000] x29: ffffa000120e7e00 x28: ffff00006ac01b10 | [ 0.000000] x27: ffff00006ac898c0 x26: dfffa00000000000 | [ 0.000000] x25: ffffa000120ef290 x24: ffffa0001216df40 | [ 0.000000] x23: 000000000000018d x22: ffffa0001244c700 | [ 0.000000] x21: ffffa00011bf393c x20: ffff00006ac898c0 | [ 0.000000] x19: 00000000ffffffff x18: 0000000000001584 | [ 0.000000] x17: 0000000000001540 x16: 0000000000000007 | [ 0.000000] x15: 0000000000000000 x14: ffffa00010432770 | [ 0.000000] x13: ffff940002483519 x12: 1ffff40002483518 | [ 0.000000] x11: 1ffff40002483518 x10: ffff940002483518 | [ 0.000000] x9 : dfffa00000000000 x8 : 0000000000000001 | [ 0.000000] x7 : ffff940002483519 x6 : ffffa0001241a8c0 | [ 0.000000] x5 : ffff940002483519 x4 : ffff940002483519 | [ 0.000000] x3 : ffffa00011780870 x2 : 0000000000000001 | [ 0.000000] x1 : 1fffe0000d591318 x0 : 0000000000000000 | [ 0.000000] Call trace: | [ 0.000000] ftrace_bug+0x27c/0x328 | [ 0.000000] ftrace_init+0x640/0x6cc | [ 0.000000] start_kernel+0x27c/0x654 | [ 0.000000] random: get_random_bytes called from print_oops_end_marker+0x30/0x60 with crng_init=0 | [ 0.000000] ---[ end trace 0000000000000000 ]--- | [ 0.000000] ftrace faulted on writing | [ 0.000000] [] _GLOBAL__sub_D_65535_0___tracepoint_initcall_level+0x4/0x28 | [ 0.000000] Initializing ftrace call sites | [ 0.000000] ftrace record flags: 0 | [ 0.000000] (0) | [ 0.000000] expected tramp: ffffa000100b3344 This is due to an unfortunate combination of several factors. Building with KASAN results in the compiler generating anonymous functions to register/unregister global variables against the shadow memory. These functions are placed in .text.startup/.text.exit, and given mangled names like _GLOBAL__sub_{I,D}_65535_0_$OTHER_SYMBOL. The kernel linker script places these in .init.text and .exit.text respectively, which are both discarded at runtime as part of initmem. Building with FTRACE_WITH_REGS uses -fpatchable-function-entry=2, which also instruments KASAN's anonymous functions. When these are discarded with the rest of initmem, ftrace removes dangling references to these call sites. Building without MODULES implicitly disables STRICT_MODULE_RWX, and causes arm64's patch_map() function to treat any !core_kernel_text() symbol as something that can be modified in-place. As core_kernel_text() is only true for .text and .init.text, with the latter depending on system_state < SYSTEM_RUNNING, we'll treat .exit.text as something that can be patched in-place. However, .exit.text is mapped read-only. Hence in this configuration the ftrace init code blows up while trying to patch one of the functions generated by KASAN. We could try to filter out the call sites in .exit.text rather than initializing them, but this would be inconsistent with how we handle .init.text, and requires hooking into core bits of ftrace. The behaviour of patch_map() is also inconsistent today, so instead let's clean that up and have it consistently handle .exit.text. This patch teaches patch_map() to handle .exit.text at init time, preventing the boot-time splat above. The flow of patch_map() is reworked to make the logic clearer and minimize redundant conditionality. Fixes: 3b23e4991fb66f6d ("arm64: implement ftrace with regs") Signed-off-by: Mark Rutland Cc: Amit Daniel Kachhap Cc: Ard Biesheuvel Cc: Torsten Duwe Cc: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit c8662aa75a4269e4219fe1b2d933fa053e8e62f5 Author: Monk Liu Date: Tue Nov 26 19:42:25 2019 +0800 drm/amdgpu: fix calltrace during kmd unload(v3) [ Upstream commit 82a829dc8c2bb03cc9b7e5beb1c5479aa3ba7831 ] issue: kernel would report a warning from a double unpin during the driver unloading on the CSB bo why: we unpin it during hw_fini, and there will be another unpin in sw_fini on CSB bo. fix: actually we don't need to pin/unpin it during hw_init/fini since it is created with kernel pinned, we only need to fullfill the CSB again during hw_init to prevent CSB/VRAM lost after S3 v2: get_csb in init_rlc so hw_init() will make CSIB content back even after reset or s3 v3: use bo_create_kernel instead of bo_create_reserved for CSB otherwise the bo_free_kernel() on CSB is not aligned and would lead to its internal reserve pending there forever take care of gfx7/8 as well Signed-off-by: Monk Liu Reviewed-by: Hawking Zhang Reviewed-by: Xiaojie Yuan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 6a74132beed217240e7865e2faeda9192e7d5ee2 Author: Omar Sandoval Date: Tue Nov 26 16:58:07 2019 -0800 xfs: fix realtime file data space leak [ Upstream commit 0c4da70c83d41a8461fdf50a3f7b292ecb04e378 ] Realtime files in XFS allocate extents in rextsize units. However, the written/unwritten state of those extents is still tracked in blocksize units. Therefore, a realtime file can be split up into written and unwritten extents that are not necessarily aligned to the realtime extent size. __xfs_bunmapi() has some logic to handle these various corner cases. Consider how it handles the following case: 1. The last extent is unwritten. 2. The last extent is smaller than the realtime extent size. 3. startblock of the last extent is not aligned to the realtime extent size, but startblock + blockcount is. In this case, __xfs_bunmapi() calls xfs_bmap_add_extent_unwritten_real() to set the second-to-last extent to unwritten. This should merge the last and second-to-last extents, so __xfs_bunmapi() moves on to the second-to-last extent. However, if the size of the last and second-to-last extents combined is greater than MAXEXTLEN, xfs_bmap_add_extent_unwritten_real() does not merge the two extents. When that happens, __xfs_bunmapi() skips past the last extent without unmapping it, thus leaking the space. Fix it by only unwriting the minimum amount needed to align the last extent to the realtime extent size, which is guaranteed to merge with the last extent. Signed-off-by: Omar Sandoval Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin commit a04223019c2219e9a55377bee587f45c18c40dad Author: Vasily Gorbik Date: Fri Nov 22 13:12:57 2019 +0100 s390: avoid misusing CALL_ON_STACK for task stack setup [ Upstream commit 7bcaad1f9fac889f5fcd1a383acf7e00d006da41 ] CALL_ON_STACK is intended to be used for temporary stack switching with potential return to the caller. When CALL_ON_STACK is misused to switch from nodat stack to task stack back_chain information would later lead stack unwinder from task stack into (per cpu) nodat stack which is reused for other purposes. This would yield confusing unwinding result or errors. To avoid that introduce CALL_ON_STACK_NORETURN to be used instead. It makes sure that back_chain is zeroed and unwinder finishes gracefully ending up at task pt_regs. Reviewed-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit a1a6f8a14cb09657b26dd31f73cc310af8d548fc Author: Max Filippov Date: Fri Nov 29 14:54:06 2019 -0800 xtensa: fix system_call interaction with ptrace [ Upstream commit 02ce94c229251555ac726ecfebe3458ef5905fa9 ] Don't overwrite return value if system call was cancelled at entry by ptrace. Return status code from do_syscall_trace_enter so that pt_regs::syscall doesn't need to be changed to skip syscall. Signed-off-by: Max Filippov Signed-off-by: Sasha Levin commit f9f47ef869eb2e6111221d8e642aa1538b5a3c55 Author: Tzung-Bi Shih Date: Fri Nov 22 15:31:12 2019 +0800 ASoC: max98090: remove msleep in PLL unlocked workaround [ Upstream commit acb874a7c049ec49d8fc66c893170fb42c01bdf7 ] It was observed Baytrail-based chromebooks could cause continuous PLL unlocked when using playback stream and capture stream simultaneously. Specifically, starting a capture stream after started a playback stream. As a result, the audio data could corrupt or turn completely silent. As the datasheet suggested, the maximum PLL lock time should be 7 msec. The workaround resets the codec softly by toggling SHDN off and on if PLL failed to lock for 10 msec. Notably, there is no suggested hold time for SHDN off. On Baytrail-based chromebooks, it would easily happen continuous PLL unlocked if there is a 10 msec delay between SHDN off and on. Removes the msleep(). Signed-off-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20191122073114.219945-2-tzungbi@google.com Reviewed-by: Pierre-Louis Bossart Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 273589e82cb160aae345065d49863d9331f68640 Author: Jaegeuk Kim Date: Fri Nov 22 12:02:06 2019 -0800 f2fs: stop GC when the victim becomes fully valid [ Upstream commit 803e74be04b32f7785742dcabfc62116718fbb06 ] We must stop GC, once the segment becomes fully valid. Otherwise, it can produce another dirty segments by moving valid blocks in the segment partially. Ramon hit no free segment panic sometimes and saw this case happens when validating reliable file pinning feature. Signed-off-by: Ramon Pantin Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 84b15c4e155099a657c9d839f37e2f6c738075d2 Author: Pavel Shilovsky Date: Tue Oct 29 16:51:19 2019 -0700 CIFS: Properly process SMB3 lease breaks [ Upstream commit 9bd4540836684013aaad6070a65d6fcdd9006625 ] Currenly we doesn't assume that a server may break a lease from RWH to RW which causes us setting a wrong lease state on a file and thus mistakenly flushing data and byte-range locks and purging cached data on the client. This leads to performance degradation because subsequent IOs go directly to the server. Fix this by propagating new lease state and epoch values to the oplock break handler through cifsFileInfo structure and removing the use of cifsInodeInfo flags for that. It allows to avoid some races of several lease/oplock breaks using those flags in parallel. Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 2005c32ec99ee2490e8131b3953f3f212009ffea Author: Markus Elfring Date: Tue Nov 5 22:26:53 2019 +0100 CIFS: Use common error handling code in smb2_ioctl_query_info() [ Upstream commit 2b1116bbe898aefdf584838448c6869f69851e0f ] Move the same error code assignments so that such exception handling can be better reused at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 3ce5297c0b40a01e8f1e2c4bf6bc2944ec21439f Author: Chuck Lever Date: Wed Nov 20 16:25:52 2019 -0500 SUNRPC: Capture completion of all RPC tasks [ Upstream commit a264abad51d8ecb7954a2f6d9f1885b38daffc74 ] RPC tasks on the backchannel never invoke xprt_complete_rqst(), so there is no way to report their tk_status at completion. Also, any RPC task that exits via rpc_exit_task() before it is replied to will also disappear without a trace. Introduce a trace point that is symmetrical with rpc_task_begin that captures the termination status of each RPC task. Sample trace output for callback requests initiated on the server: kworker/u8:12-448 [003] 127.025240: rpc_task_end: task:50@3 flags=ASYNC|DYNAMIC|SOFT|SOFTCONN|SENT runstate=RUNNING|ACTIVE status=0 action=rpc_exit_task kworker/u8:12-448 [002] 127.567310: rpc_task_end: task:51@3 flags=ASYNC|DYNAMIC|SOFT|SOFTCONN|SENT runstate=RUNNING|ACTIVE status=0 action=rpc_exit_task kworker/u8:12-448 [001] 130.506817: rpc_task_end: task:52@3 flags=ASYNC|DYNAMIC|SOFT|SOFTCONN|SENT runstate=RUNNING|ACTIVE status=0 action=rpc_exit_task Odd, though, that I never see trace_rpc_task_complete, either in the forward or backchannel. Should it be removed? Signed-off-by: Chuck Lever Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 80f7667422447a146f55b26e7b453354cccdc642 Author: Kusanagi Kouichi Date: Thu Nov 21 19:20:21 2019 +0900 debugfs: Fix !DEBUG_FS debugfs_create_automount [ Upstream commit 4250b047039d324e0ff65267c8beb5bad5052a86 ] If DEBUG_FS=n, compile fails with the following error: kernel/trace/trace.c: In function 'tracing_init_dentry': kernel/trace/trace.c:8658:9: error: passing argument 3 of 'debugfs_create_automount' from incompatible pointer type [-Werror=incompatible-pointer-types] 8658 | trace_automount, NULL); | ^~~~~~~~~~~~~~~ | | | struct vfsmount * (*)(struct dentry *, void *) In file included from kernel/trace/trace.c:24: ./include/linux/debugfs.h:206:25: note: expected 'struct vfsmount * (*)(void *)' but argument is of type 'struct vfsmount * (*)(struct dentry *, void *)' 206 | struct vfsmount *(*f)(void *), | ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~ Signed-off-by: Kusanagi Kouichi Link: https://lore.kernel.org/r/20191121102021787.MLMY.25002.ppp.dion.ne.jp@dmta0003.auone-net.jp Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 14bbbfbafef1840df6ef5464a8b1db1307491aed Author: Felix Fietkau Date: Mon Oct 7 12:32:14 2019 +0200 mt76: add missing locking around ampdu action [ Upstream commit 1a817fa73c3b27a593aadf0029de24db1bbc1a3e ] This is needed primarily to avoid races in dealing with rx aggregation related data structures Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 5eee23bc19a8c4f98f1eefd1cab87c7aceb751d4 Author: Felix Fietkau Date: Sun Sep 29 22:04:37 2019 +0200 mt76: do not use devm API for led classdev [ Upstream commit 36f7e2b2bb1de86f0072cd49ca93d82b9e8fd894 ] With the devm API, the unregister happens after the device cleanup is done, after which the struct mt76_dev which contains the led_cdev has already been freed. This leads to a use-after-free bug that can crash the system. Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 773dc29227193a50310bdfdf471f256777febf97 Author: peter chang Date: Thu Nov 14 15:39:06 2019 +0530 scsi: pm80xx: Cleanup command when a reset times out [ Upstream commit 51c1c5f6ed64c2b65a8cf89dac136273d25ca540 ] Added the fix so the if driver properly sent the abort it tries to remove it from the firmware's list of outstanding commands regardless of the abort status. This means that the task gets freed 'now' rather than possibly getting freed later when the scsi layer thinks it's leaked but still valid. Link: https://lore.kernel.org/r/20191114100910.6153-10-deepak.ukey@microchip.com Acked-by: Jack Wang Signed-off-by: peter chang Signed-off-by: Deepak Ukey Signed-off-by: Viswas G Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 714dbaf2f8143134603c0b8e6ac435ae3d1fa66c Author: Bob Peterson Date: Tue Nov 19 11:40:46 2019 -0500 gfs2: clean up iopen glock mess in gfs2_create_inode [ Upstream commit 2c47c1be51fbded1f7baa2ceaed90f97932f79be ] Before this patch, gfs2_create_inode had a use-after-free for the iopen glock in some error paths because it did this: gfs2_glock_put(io_gl); fail_gunlock2: if (io_gl) clear_bit(GLF_INODE_CREATING, &io_gl->gl_flags); In some cases, the io_gl was used for create and only had one reference, so the glock might be freed before the clear_bit(). This patch tries to straighten it out by only jumping to the error paths where iopen is properly set, and moving the gfs2_glock_put after the clear_bit. Signed-off-by: Bob Peterson Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit a21260928bd30bab09c7406b72e79415b2f34fcc Author: Bradley Bolen Date: Sat Nov 16 20:00:45 2019 -0500 mmc: core: Fix size overflow for mmc partitions [ Upstream commit f3d7c2292d104519195fdb11192daec13229c219 ] With large eMMC cards, it is possible to create general purpose partitions that are bigger than 4GB. The size member of the mmc_part struct is only an unsigned int which overflows for gp partitions larger than 4GB. Change this to a u64 to handle the overflow. Signed-off-by: Bradley Bolen Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit cbd2ee90d3c1d32ccd9ba37a6b87ecd2f309627e Author: Sascha Hauer Date: Tue Nov 5 09:12:51 2019 +0100 ubi: Fix producing anchor PEBs [ Upstream commit f9c34bb529975fe9f85b870a80c53a83a3c5a182 ] When a new fastmap is about to be written UBI must make sure it has a free block for a fastmap anchor available. For this ubi_update_fastmap() calls ubi_ensure_anchor_pebs(). This stopped working with 2e8f08deabbc ("ubi: Fix races around ubi_refill_pools()"), with this commit the wear leveling code is blocked and can no longer produce free PEBs. UBI then more often than not falls back to write the new fastmap anchor to the same block it was already on which means the same erase block gets erased during each fastmap write and wears out quite fast. As the locking prevents us from producing the anchor PEB when we actually need it, this patch changes the strategy for creating the anchor PEB. We no longer create it on demand right before we want to write a fastmap, but instead we create an anchor PEB right after we have written a fastmap. This gives us enough time to produce a new anchor PEB before it is needed. To make sure we have an anchor PEB for the very first fastmap write we call ubi_ensure_anchor_pebs() during initialisation as well. Fixes: 2e8f08deabbc ("ubi: Fix races around ubi_refill_pools()") Signed-off-by: Sascha Hauer Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 40afadc0577122239550efb5d22b7291efa7b088 Author: Christophe JAILLET Date: Mon Sep 23 21:07:46 2019 +0200 RDMA/iw_cgxb4: Fix an error handling path in 'c4iw_connect()' [ Upstream commit 9067f2f0b41d7e817fc8c5259bab1f17512b0147 ] We should jump to fail3 in order to undo the 'xa_insert_irq()' call. Link: https://lore.kernel.org/r/20190923190746.10964-1-christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit be45bce4ad8e90e80b45c65749bc5252a6e38d0d Author: Brian Foster Date: Fri Nov 15 21:15:08 2019 -0800 xfs: fix attr leaf header freemap.size underflow [ Upstream commit 2a2b5932db67586bacc560cc065d62faece5b996 ] The leaf format xattr addition helper xfs_attr3_leaf_add_work() adjusts the block freemap in a couple places. The first update drops the size of the freemap that the caller had already selected to place the xattr name/value data. Before the function returns, it also checks whether the entries array has encroached on a freemap range by virtue of the new entry addition. This is necessary because the entries array grows from the start of the block (but end of the block header) towards the end of the block while the name/value data grows from the end of the block in the opposite direction. If the associated freemap is already empty, however, size is zero and the subtraction underflows the field and causes corruption. This is reproduced rarely by generic/070. The observed behavior is that a smaller sized freemap is aligned to the end of the entries list, several subsequent xattr additions land in larger freemaps and the entries list expands into the smaller freemap until it is fully consumed and then underflows. Note that it is not otherwise a corruption for the entries array to consume an empty freemap because the nameval list (i.e. the firstused pointer in the xattr header) starts beyond the end of the corrupted freemap. Update the freemap size modification to account for the fact that the freemap entry can be empty and thus stale. Signed-off-by: Brian Foster Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin commit 424388f0c53417d06e0a4fa60e2b1987f1afc699 Author: Al Viro Date: Thu Oct 31 01:43:31 2019 -0400 fix dget_parent() fastpath race [ Upstream commit e84009336711d2bba885fc9cea66348ddfce3758 ] We are overoptimistic about taking the fast path there; seeing the same value in ->d_parent after having grabbed a reference to that parent does *not* mean that it has remained our parent all along. That wouldn't be a big deal (in the end it is our parent and we have grabbed the reference we are about to return), but... the situation with barriers is messed up. We might have hit the following sequence: d is a dentry of /tmp/a/b CPU1: CPU2: parent = d->d_parent (i.e. dentry of /tmp/a) rename /tmp/a/b to /tmp/b rmdir /tmp/a, making its dentry negative grab reference to parent, end up with cached parent->d_inode (NULL) mkdir /tmp/a, rename /tmp/b to /tmp/a/b recheck d->d_parent, which is back to original decide that everything's fine and return the reference we'd got. The trouble is, caller (on CPU1) will observe dget_parent() returning an apparently negative dentry. It actually is positive, but CPU1 has stale ->d_inode cached. Use d->d_seq to see if it has been moved instead of rechecking ->d_parent. NOTE: we are *NOT* going to retry on any kind of ->d_seq mismatch; we just go into the slow path in such case. We don't wait for ->d_seq to become even either - again, if we are racing with renames, we can bloody well go to slow path anyway. Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 797f6c19abce4f843ce0d62d9b3c9e865a86405e Author: Nicholas Johnson Date: Wed Nov 13 15:25:28 2019 +0000 PCI: Avoid double hpmemsize MMIO window assignment [ Upstream commit c13704f5685deb7d6eb21e293233e0901ed77377 ] Previously, the kernel sometimes assigned more MMIO or MMIO_PREF space than desired. For example, if the user requested 128M of space with "pci=realloc,hpmemsize=128M", we sometimes assigned 256M: pci 0000:06:01.0: BAR 14: assigned [mem 0x90100000-0xa00fffff] = 256M pci 0000:06:04.0: BAR 14: assigned [mem 0xa0200000-0xb01fffff] = 256M With this patch applied: pci 0000:06:01.0: BAR 14: assigned [mem 0x90100000-0x980fffff] = 128M pci 0000:06:04.0: BAR 14: assigned [mem 0x98200000-0xa01fffff] = 128M This happened when in the first pass, the MMIO_PREF succeeded but the MMIO failed. In the next pass, because MMIO_PREF was already assigned, the attempt to assign MMIO_PREF returned an error code instead of success (nothing more to do, already allocated). Hence, the size which was actually allocated, but thought to have failed, was placed in the MMIO window. The bug resulted in the MMIO_PREF being added to the MMIO window, which meant doubling if MMIO_PREF size = MMIO size. With a large MMIO_PREF, the MMIO window would likely fail to be assigned altogether due to lack of 32-bit address space. Change find_free_bus_resource() to do the following: - Return first unassigned resource of the correct type. - If there is none, return first assigned resource of the correct type. - If none of the above, return NULL. Returning an assigned resource of the correct type allows the caller to distinguish between already assigned and no resource of the correct type. Add checks in pbus_size_io() and pbus_size_mem() to return success if resource returned from find_free_bus_resource() is already allocated. This avoids pbus_size_io() and pbus_size_mem() returning error code to __pci_bus_size_bridges() when a resource has been successfully assigned in a previous pass. This fixes the existing behaviour where space for a resource could be reserved multiple times in different parent bridge windows. Link: https://lore.kernel.org/lkml/20190531171216.20532-2-logang@deltatee.com/T/#u Link: https://bugzilla.kernel.org/show_bug.cgi?id=203243 Link: https://lore.kernel.org/r/PS2P216MB075563AA6AD242AA666EDC6A80760@PS2P216MB0755.KORP216.PROD.OUTLOOK.COM Reported-by: Kit Chow Reported-by: Nicholas Johnson Signed-off-by: Nicholas Johnson Signed-off-by: Bjorn Helgaas Reviewed-by: Mika Westerberg Reviewed-by: Logan Gunthorpe Signed-off-by: Sasha Levin commit 3161ea6733825629372a49eda0b6e48fcffd776f Author: Pan Bian Date: Wed Nov 6 14:44:11 2019 +0800 RDMA/i40iw: Fix potential use after free [ Upstream commit da046d5f895fca18d63b15ac8faebd5bf784e23a ] Release variable dst after logging dst->error to avoid possible use after free. Link: https://lore.kernel.org/r/1573022651-37171-1-git-send-email-bianpan2016@163.com Signed-off-by: Pan Bian Reviewed-by: Jason Gunthorpe Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit f3ebf81ee6346c8230d5dda80ff112611fd78982 Author: Pan Bian Date: Wed Nov 6 14:23:54 2019 +0800 RDMA/qedr: Fix potential use after free [ Upstream commit 960657b732e1ce21b07be5ab48a7ad3913d72ba4 ] Move the release operation after error log to avoid possible use after free. Link: https://lore.kernel.org/r/1573021434-18768-1-git-send-email-bianpan2016@163.com Signed-off-by: Pan Bian Acked-by: Michal Kalderon  Reviewed-by: Jason Gunthorpe Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 04f4f09502f1cac4c5aa440f5a5a33b72838ab51 Author: Lianbo Jiang Date: Fri Nov 8 17:00:25 2019 +0800 x86/kdump: Always reserve the low 1M when the crashkernel option is specified [ Upstream commit 6f599d84231fd27e42f4ca2a786a6641e8cddf00 ] On x86, purgatory() copies the first 640K of memory to a backup region because the kernel needs those first 640K for the real mode trampoline during boot, among others. However, when SME is enabled, the kernel cannot properly copy the old memory to the backup area but reads only its encrypted contents. The result is that the crash tool gets invalid pointers when parsing vmcore: crash> kmem -s|grep -i invalid kmem: dma-kmalloc-512: slab:ffffd77680001c00 invalid freepointer:a6086ac099f0c5a4 kmem: dma-kmalloc-512: slab:ffffd77680001c00 invalid freepointer:a6086ac099f0c5a4 crash> So reserve the remaining low 1M memory when the crashkernel option is specified (after reserving real mode memory) so that allocated memory does not fall into the low 1M area and thus the copying of the contents of the first 640k to a backup region in purgatory() can be avoided altogether. This way, it does not need to be included in crash dumps or used for anything except the trampolines that must live in the low 1M. [ bp: Heavily rewrite commit message, flip check logic in crash_reserve_low_1M().] Signed-off-by: Lianbo Jiang Signed-off-by: Borislav Petkov Cc: bhe@redhat.com Cc: Dave Young Cc: d.hatayama@fujitsu.com Cc: dhowells@redhat.com Cc: ebiederm@xmission.com Cc: horms@verge.net.au Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Jürgen Gross Cc: kexec@lists.infradead.org Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Tom Lendacky Cc: vgoyal@redhat.com Cc: x86-ml Link: https://lkml.kernel.org/r/20191108090027.11082-2-lijiang@redhat.com Link: https://bugzilla.kernel.org/show_bug.cgi?id=204793 Signed-off-by: Sasha Levin commit 21c82e8d42016a23c7ec92f0f9013678ae8d07ba Author: Satendra Singh Thakur Date: Sat Nov 9 17:05:23 2019 +0530 dmaengine: mediatek: hsdma_probe: fixed a memory leak when devm_request_irq fails [ Upstream commit 1ff95243257fad07290dcbc5f7a6ad79d6e703e2 ] When devm_request_irq fails, currently, the function dma_async_device_unregister gets called. This doesn't free the resources allocated by of_dma_controller_register. Therefore, we have called of_dma_controller_free for this purpose. Signed-off-by: Satendra Singh Thakur Link: https://lore.kernel.org/r/20191109113523.6067-1-sst2005@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit fd3572bd5bc1c18512a44d4e73ea39af957dc658 Author: Guoju Fang Date: Wed Nov 13 16:03:16 2019 +0800 bcache: fix a lost wake-up problem caused by mca_cannibalize_lock [ Upstream commit 34cf78bf34d48dddddfeeadb44f9841d7864997a ] This patch fix a lost wake-up problem caused by the race between mca_cannibalize_lock and bch_cannibalize_unlock. Consider two processes, A and B. Process A is executing mca_cannibalize_lock, while process B takes c->btree_cache_alloc_lock and is executing bch_cannibalize_unlock. The problem happens that after process A executes cmpxchg and will execute prepare_to_wait. In this timeslice process B executes wake_up, but after that process A executes prepare_to_wait and set the state to TASK_INTERRUPTIBLE. Then process A goes to sleep but no one will wake up it. This problem may cause bcache device to dead. Signed-off-by: Guoju Fang Signed-off-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 9f81aa5d44932c7c183b873ae0192bf0df232ffc Author: Divya Indi Date: Wed Aug 14 10:55:25 2019 -0700 tracing: Adding NULL checks for trace_array descriptor pointer [ Upstream commit 953ae45a0c25e09428d4a03d7654f97ab8a36647 ] As part of commit f45d1225adb0 ("tracing: Kernel access to Ftrace instances") we exported certain functions. Here, we are adding some additional NULL checks to ensure safe usage by users of these APIs. Link: http://lkml.kernel.org/r/1565805327-579-4-git-send-email-divya.indi@oracle.com Signed-off-by: Divya Indi Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 8e0d54aa40057cb16848d87af2da094feea3de57 Author: Divya Indi Date: Wed Aug 14 10:55:24 2019 -0700 tracing: Verify if trace array exists before destroying it. [ Upstream commit e585e6469d6f476b82aa148dc44aaf7ae269a4e2 ] A trace array can be destroyed from userspace or kernel. Verify if the trace array exists before proceeding to destroy/remove it. Link: http://lkml.kernel.org/r/1565805327-579-3-git-send-email-divya.indi@oracle.com Reviewed-by: Aruna Ramakrishna Signed-off-by: Divya Indi [ Removed unneeded braces ] Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 6405d5c5c5b8313777f20d7e537702ab78b85fc8 Author: Ivan Lazeev Date: Wed Oct 16 21:28:14 2019 +0300 tpm_crb: fix fTPM on AMD Zen+ CPUs [ Upstream commit 3ef193822b25e9ee629974f66dc1ff65167f770c ] Bug link: https://bugzilla.kernel.org/show_bug.cgi?id=195657 cmd/rsp buffers are expected to be in the same ACPI region. For Zen+ CPUs BIOS's might report two different regions, some of them also report region sizes inconsistent with values from TPM registers. Memory configuration on ASRock x470 ITX: db0a0000-dc59efff : Reserved dc57e000-dc57efff : MSFT0101:00 dc582000-dc582fff : MSFT0101:00 Work around the issue by storing ACPI regions declared for the device in a fixed array and adding an array for pointers to corresponding possibly allocated resources in crb_map_io function. This data was previously held for a single resource in struct crb_priv (iobase field) and local variable io_res in crb_map_io function. ACPI resources array is used to find index of corresponding region for each buffer and make the buffer size consistent with region's length. Array of pointers to allocated resources is used to map the region at most once. Signed-off-by: Ivan Lazeev Tested-by: Jerry Snitselaar Tested-by: Jarkko Sakkinen Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit b3a1fb675eb89cebb0c63d41b83f760bead83ab9 Author: Alex Deucher Date: Fri Nov 8 11:15:17 2019 -0500 drm/amdgpu/powerplay/smu7: fix AVFS handling with custom powerplay table [ Upstream commit 901245624c7812b6c95d67177bae850e783b5212 ] When a custom powerplay table is provided, we need to update the OD VDDC flag to avoid AVFS being enabled when it shouldn't be. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205393 Reviewed-by: Evan Quan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 022a2a0728cb9f1dadba23b3c73f81ea89511dbb Author: Lee Jones Date: Mon Oct 21 10:16:34 2019 +0100 mfd: mfd-core: Protect against NULL call-back function pointer [ Upstream commit b195e101580db390f50b0d587b7f66f241d2bc88 ] If a child device calls mfd_cell_{en,dis}able() without an appropriate call-back being set, we are likely to encounter a panic. Avoid this by adding suitable checking. Signed-off-by: Lee Jones Reviewed-by: Daniel Thompson Reviewed-by: Mark Brown Signed-off-by: Sasha Levin commit deb34c91ebd4cb5b59dfb746796e9b45d0fa4c99 Author: Hou Tao Date: Tue Oct 8 10:36:37 2019 +0800 mtd: cfi_cmdset_0002: don't free cfi->cfiq in error path of cfi_amdstd_setup() [ Upstream commit 03976af89e3bd9489d542582a325892e6a8cacc0 ] Else there may be a double-free problem, because cfi->cfiq will be freed by mtd_do_chip_probe() if both the two invocations of check_cmd_set() return failure. Signed-off-by: Hou Tao Reviewed-by: Richard Weinberger Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin commit bcd4bbf995350fc11b23b4ffcafcea67c11ab3fb Author: Usha Ketineni Date: Wed Nov 6 02:05:31 2019 -0800 ice: Fix to change Rx/Tx ring descriptor size via ethtool with DCBx [ Upstream commit c0a3665f71a2f086800abea4d9d14d28269089d6 ] This patch fixes the call trace caused by the kernel when the Rx/Tx descriptor size change request is initiated via ethtool when DCB is configured. ice_set_ringparam() should use vsi->num_txq instead of vsi->alloc_txq as it represents the queues that are enabled in the driver when DCB is enabled/disabled. Otherwise, queue index being used can go out of range. For example, when vsi->alloc_txq has 104 queues and with 3 TCS enabled via DCB, each TC gets 34 queues, vsi->num_txq will be 102 and only 102 queues will be enabled. Signed-off-by: Usha Ketineni Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 3642887a4031a5809d73cb6bf1032a50afb5f05e Author: Alex Deucher Date: Thu Nov 7 09:50:18 2019 -0500 drm/amdgpu/powerplay: fix AVFS handling with custom powerplay table [ Upstream commit 53dbc27ad5a93932ff1892a8e4ef266827d74a0f ] When a custom powerplay table is provided, we need to update the OD VDDC flag to avoid AVFS being enabled when it shouldn't be. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205393 Reviewed-by: Evan Quan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c5505813d01fb142d8f89e77290346ed6021272e Author: Stephen Kitt Date: Sat Oct 19 16:06:34 2019 +0200 clk/ti/adpll: allocate room for terminating null [ Upstream commit 7f6ac72946b88b89ee44c1c527aa8591ac5ffcbe ] The buffer allocated in ti_adpll_clk_get_name doesn't account for the terminating null. This patch switches to devm_kasprintf to avoid overflowing. Signed-off-by: Stephen Kitt Link: https://lkml.kernel.org/r/20191019140634.15596-1-steve@sk2.org Acked-by: Tony Lindgren Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 5eb67d3843edc1de5105445a0d1aa1033b17f16d Author: Jaegeuk Kim Date: Fri Nov 1 09:34:21 2019 -0700 f2fs: avoid kernel panic on corruption test [ Upstream commit bc005a4d5347da68e690f78d365d8927c87dc85a ] xfstests/generic/475 complains kernel warn/panic while testing corrupted disk. Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 5657f17bcd9c6284605d987958b03a0bdec1e5c1 Author: Andreas Gruenbacher Date: Thu Nov 7 07:28:18 2019 -0800 iomap: Fix overflow in iomap_page_mkwrite [ Upstream commit add66fcbd3fbe5aa0dd4dddfa23e119c12989a27 ] On architectures where loff_t is wider than pgoff_t, the expression ((page->index + 1) << PAGE_SHIFT) can overflow. Rewrite to use the page offset, which we already compute here anyway. Signed-off-by: Andreas Gruenbacher Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin commit 4c7d4dd210a12438e33ec1ec9b5c062d2f04a216 Author: Dan Williams Date: Wed Nov 6 17:43:37 2019 -0800 dax: Fix alloc_dax_region() compile warning [ Upstream commit 460370ab20b6cc174256e46e192adf01e730faf6 ] PFN flags are (unsigned long long), fix the alloc_dax_region() calling convention to fix warnings of the form: >> include/linux/pfn_t.h:18:17: warning: large integer implicitly truncated to unsigned type [-Woverflow] #define PFN_DEV (1ULL << (BITS_PER_LONG_LONG - 3)) Reported-by: kbuild test robot Signed-off-by: Dan Williams Acked-by: Thomas Gleixner Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 6670a2a397d4482a11388f5e93c8481b8a5ad89b Author: Eric Dumazet Date: Wed Nov 6 10:04:11 2019 -0800 net: silence data-races on sk_backlog.tail [ Upstream commit 9ed498c6280a2f2b51d02df96df53037272ede49 ] sk->sk_backlog.tail might be read without holding the socket spinlock, we need to add proper READ_ONCE()/WRITE_ONCE() to silence the warnings. KCSAN reported : BUG: KCSAN: data-race in tcp_add_backlog / tcp_recvmsg write to 0xffff8881265109f8 of 8 bytes by interrupt on cpu 1: __sk_add_backlog include/net/sock.h:907 [inline] sk_add_backlog include/net/sock.h:938 [inline] tcp_add_backlog+0x476/0xce0 net/ipv4/tcp_ipv4.c:1759 tcp_v4_rcv+0x1a70/0x1bd0 net/ipv4/tcp_ipv4.c:1947 ip_protocol_deliver_rcu+0x4d/0x420 net/ipv4/ip_input.c:204 ip_local_deliver_finish+0x110/0x140 net/ipv4/ip_input.c:231 NF_HOOK include/linux/netfilter.h:305 [inline] NF_HOOK include/linux/netfilter.h:299 [inline] ip_local_deliver+0x133/0x210 net/ipv4/ip_input.c:252 dst_input include/net/dst.h:442 [inline] ip_rcv_finish+0x121/0x160 net/ipv4/ip_input.c:413 NF_HOOK include/linux/netfilter.h:305 [inline] NF_HOOK include/linux/netfilter.h:299 [inline] ip_rcv+0x18f/0x1a0 net/ipv4/ip_input.c:523 __netif_receive_skb_one_core+0xa7/0xe0 net/core/dev.c:4929 __netif_receive_skb+0x37/0xf0 net/core/dev.c:5043 netif_receive_skb_internal+0x59/0x190 net/core/dev.c:5133 napi_skb_finish net/core/dev.c:5596 [inline] napi_gro_receive+0x28f/0x330 net/core/dev.c:5629 receive_buf+0x284/0x30b0 drivers/net/virtio_net.c:1061 virtnet_receive drivers/net/virtio_net.c:1323 [inline] virtnet_poll+0x436/0x7d0 drivers/net/virtio_net.c:1428 napi_poll net/core/dev.c:6311 [inline] net_rx_action+0x3ae/0xa90 net/core/dev.c:6379 __do_softirq+0x115/0x33f kernel/softirq.c:292 invoke_softirq kernel/softirq.c:373 [inline] irq_exit+0xbb/0xe0 kernel/softirq.c:413 exiting_irq arch/x86/include/asm/apic.h:536 [inline] do_IRQ+0xa6/0x180 arch/x86/kernel/irq.c:263 ret_from_intr+0x0/0x19 native_safe_halt+0xe/0x10 arch/x86/kernel/paravirt.c:71 arch_cpu_idle+0x1f/0x30 arch/x86/kernel/process.c:571 default_idle_call+0x1e/0x40 kernel/sched/idle.c:94 cpuidle_idle_call kernel/sched/idle.c:154 [inline] do_idle+0x1af/0x280 kernel/sched/idle.c:263 cpu_startup_entry+0x1b/0x20 kernel/sched/idle.c:355 start_secondary+0x208/0x260 arch/x86/kernel/smpboot.c:264 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241 read to 0xffff8881265109f8 of 8 bytes by task 8057 on cpu 0: tcp_recvmsg+0x46e/0x1b40 net/ipv4/tcp.c:2050 inet_recvmsg+0xbb/0x250 net/ipv4/af_inet.c:838 sock_recvmsg_nosec net/socket.c:871 [inline] sock_recvmsg net/socket.c:889 [inline] sock_recvmsg+0x92/0xb0 net/socket.c:885 sock_read_iter+0x15f/0x1e0 net/socket.c:967 call_read_iter include/linux/fs.h:1889 [inline] new_sync_read+0x389/0x4f0 fs/read_write.c:414 __vfs_read+0xb1/0xc0 fs/read_write.c:427 vfs_read fs/read_write.c:461 [inline] vfs_read+0x143/0x2c0 fs/read_write.c:446 ksys_read+0xd5/0x1b0 fs/read_write.c:587 __do_sys_read fs/read_write.c:597 [inline] __se_sys_read fs/read_write.c:595 [inline] __x64_sys_read+0x4c/0x60 fs/read_write.c:595 do_syscall_64+0xcc/0x370 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 8057 Comm: syz-fuzzer Not tainted 5.4.0-rc6+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 75a1c456944f964667749ec78d9d08e42619b975 Author: Michael Ellerman Date: Wed Nov 6 13:30:25 2019 +1100 powerpc/64s: Always disable branch profiling for prom_init.o [ Upstream commit 6266a4dadb1d0976490fdf5af4f7941e36f64e80 ] Otherwise the build fails because prom_init is calling symbols it's not allowed to, eg: Error: External symbol 'ftrace_likely_update' referenced from prom_init.c make[3]: *** [arch/powerpc/kernel/Makefile:197: arch/powerpc/kernel/prom_init_check] Error 1 Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191106051129.7626-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit f5abdca0c2ef9d8a01241dae76feeb5276eab9b6 Author: James Smart Date: Mon Nov 4 16:57:00 2019 -0800 scsi: lpfc: Fix kernel crash at lpfc_nvme_info_show during remote port bounce [ Upstream commit 6c1e803eac846f886cd35131e6516fc51a8414b9 ] When reading sysfs nvme_info file while a remote port leaves and comes back, a NULL pointer is encountered. The issue is due to ndlp list corruption as the the nvme_info_show does not use the same lock as the rest of the code. Correct by removing the rcu_xxx_lock calls and replace by the host_lock and phba->hbaLock spinlocks that are used by the rest of the driver. Given we're called from sysfs, we are safe to use _irq rather than _irqsave. Link: https://lore.kernel.org/r/20191105005708.7399-4-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 1a4c4df217281783d9427e3f0acd4b9a8b3de07c Author: Pan Bian Date: Mon Nov 4 23:26:22 2019 +0800 scsi: fnic: fix use after free [ Upstream commit ec990306f77fd4c58c3b27cc3b3c53032d6e6670 ] The memory chunk io_req is released by mempool_free. Accessing io_req->start_time will result in a use after free bug. The variable start_time is a backup of the timestamp. So, use start_time here to avoid use after free. Link: https://lore.kernel.org/r/1572881182-37664-1-git-send-email-bianpan2016@163.com Signed-off-by: Pan Bian Reviewed-by: Satish Kharat Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 4241376371ad23be4cbbbb2f1627b1ddcf42f2b2 Author: Dmitry Osipenko Date: Tue Nov 5 00:56:03 2019 +0300 PM / devfreq: tegra30: Fix integer overflow on CPU's freq max out [ Upstream commit 53b4b2aeee26f42cde5ff2a16dd0d8590c51a55a ] There is another kHz-conversion bug in the code, resulting in integer overflow. Although, this time the resulting value is 4294966296 and it's close to ULONG_MAX, which is okay in this case. Reviewed-by: Chanwoo Choi Tested-by: Peter Geis Signed-off-by: Dmitry Osipenko Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin commit d550b07e1a3f6b5780f1f0be0e782ef35e9a62b6 Author: Mike Snitzer Date: Tue Nov 5 10:43:44 2019 -0500 dm table: do not allow request-based DM to stack on partitions [ Upstream commit 6ba01df72b4b63a26b4977790f58d8f775d2992c ] Partitioned request-based devices cannot be used as underlying devices for request-based DM because no partition offsets are added to each incoming request. As such, until now, stacking on partitioned devices would _always_ result in data corruption (e.g. wiping the partition table, writing to other partitions, etc). Fix this by disallowing request-based stacking on partitions. While at it, since all .request_fn support has been removed from block core, remove legacy dm-table code that differentiated between blk-mq and .request_fn request-based. Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit e645b649c418733d91a9f70f34ee7eae0988c502 Author: Oleh Kravchenko Date: Wed Oct 16 10:24:30 2019 +0300 leds: mlxreg: Fix possible buffer overflow [ Upstream commit 7c6082b903ac28dc3f383fba57c6f9e7e2594178 ] Error was detected by PVS-Studio: V512 A call of the 'sprintf' function will lead to overflow of the buffer 'led_data->led_cdev_name'. Acked-by: Jacek Anaszewski Acked-by: Pavel Machek Signed-off-by: Oleh Kravchenko Signed-off-by: Pavel Machek Signed-off-by: Sasha Levin commit 36f11775da759b27bfe674049d5e109e04694caf Author: Dave Chinner Date: Tue Oct 29 13:04:32 2019 -0700 xfs: properly serialise fallocate against AIO+DIO [ Upstream commit 249bd9087a5264d2b8a974081870e2e27671b4dc ] AIO+DIO can extend the file size on IO completion, and it holds no inode locks while the IO is in flight. Therefore, a race condition exists in file size updates if we do something like this: aio-thread fallocate-thread lock inode submit IO beyond inode->i_size unlock inode ..... lock inode break layouts if (off + len > inode->i_size) new_size = off + len ..... inode_dio_wait() ..... completes inode->i_size updated inode_dio_done() .... if (new_size) xfs_vn_setattr(inode, new_size) Yup, that attempt to extend the file size in the fallocate code turns into a truncate - it removes the whatever the aio write allocated and put to disk, and reduced the inode size back down to where the fallocate operation ends. Fundamentally, xfs_file_fallocate() not compatible with racing AIO+DIO completions, so we need to move the inode_dio_wait() call up to where the lock the inode and break the layouts. Secondly, storing the inode size and then using it unchecked without holding the ILOCK is not safe; we can only do such a thing if we've locked out and drained all IO and other modification operations, which we don't do initially in xfs_file_fallocate. It should be noted that some of the fallocate operations are compound operations - they are made up of multiple manipulations that may zero data, and so we may need to flush and invalidate the file multiple times during an operation. However, we only need to lock out IO and other space manipulation operations once, as that lockout is maintained until the entire fallocate operation has been completed. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Reviewed-by: Brian Foster Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin commit 50afba5c129c5b41cc82e76331b843b0e2fd7643 Author: Nicholas Kazlauskas Date: Fri Oct 11 12:26:10 2019 -0400 drm/amd/display: Free gamma after calculating legacy transfer function [ Upstream commit 0e3a7c2ec93b15f43a2653e52e9608484391aeaf ] [Why] We're leaking memory by not freeing the gamma used to calculate the transfer function for legacy gamma. [How] Release the gamma after we're done with it. Signed-off-by: Nicholas Kazlauskas Reviewed-by: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 252e8b514a98a28b85825be249c140e2c2a1a516 Author: Sakari Ailus Date: Mon Sep 23 11:25:42 2019 -0300 media: smiapp: Fix error handling at NVM reading [ Upstream commit a5b1d5413534607b05fb34470ff62bf395f5c8d0 ] If NVM reading failed, the device was left powered on. Fix that. Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit e0731a6503b007085b1d4433ed8e9a3c3c60e97c Author: Pierre-Louis Bossart Date: Tue Oct 22 18:54:44 2019 -0500 soundwire: intel/cadence: fix startup sequence [ Upstream commit 49ea07d33d9a32c17e18b322e789507280ceb2a3 ] Multiple changes squashed in single patch to avoid tick-tock effect and avoid breaking compilation/bisect 1. Per the hardware documentation, all changes to MCP_CONFIG, MCP_CONTROL, MCP_CMDCTRL and MCP_PHYCTRL need to be validated with a self-clearing write to MCP_CONFIG_UPDATE. Add a helper and do the update when the CONFIG is changed. 2. Move interrupt enable after interrupt handler registration 3. Add a new helper to start the hardware bus reset with maximum duration to make sure the Slave(s) correctly detect the reset pattern and to ensure electrical conflicts can be resolved. 4. flush command FIFOs Better error handling will be provided after interrupt disable is provided in follow-up patches. Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20191022235448.17586-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit d9adb4deef1606392f5761c337a11450d66c8880 Author: Russell King Date: Wed Oct 23 16:46:59 2019 +0100 ASoC: kirkwood: fix IRQ error handling [ Upstream commit 175fc928198236037174e5c5c066fe3c4691903e ] Propagate the error code from request_irq(), rather than returning -EBUSY. Signed-off-by: Russell King Link: https://lore.kernel.org/r/E1iNIqh-0000tW-EZ@rmk-PC.armlinux.org.uk Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8b4e9c1bb05a064c456b7937c542e5391c7d6460 Author: Kangjie Lu Date: Thu Oct 17 23:29:53 2019 -0500 gma/gma500: fix a memory disclosure bug due to uninitialized bytes [ Upstream commit 57a25a5f754ce27da2cfa6f413cfd366f878db76 ] `best_clock` is an object that may be sent out. Object `clock` contains uninitialized bytes that are copied to `best_clock`, which leads to memory disclosure and information leak. Signed-off-by: Kangjie Lu Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20191018042953.31099-1-kjlu@umn.edu Signed-off-by: Sasha Levin commit 8c355ed61996a3a4da91fc612bec1b9bad16853e Author: Dave Chinner Date: Thu Oct 17 13:40:33 2019 -0700 xfs: fix inode fork extent count overflow [ Upstream commit 3f8a4f1d876d3e3e49e50b0396eaffcc4ba71b08 ] [commit message is verbose for discussion purposes - will trim it down later. Some questions about implementation details at the end.] Zorro Lang recently ran a new test to stress single inode extent counts now that they are no longer limited by memory allocation. The test was simply: # xfs_io -f -c "falloc 0 40t" /mnt/scratch/big-file # ~/src/xfstests-dev/punch-alternating /mnt/scratch/big-file This test uncovered a problem where the hole punching operation appeared to finish with no error, but apparently only created 268M extents instead of the 10 billion it was supposed to. Further, trying to punch out extents that should have been present resulted in success, but no change in the extent count. It looked like a silent failure. While running the test and observing the behaviour in real time, I observed the extent coutn growing at ~2M extents/minute, and saw this after about an hour: # xfs_io -f -c "stat" /mnt/scratch/big-file |grep next ; \ > sleep 60 ; \ > xfs_io -f -c "stat" /mnt/scratch/big-file |grep next fsxattr.nextents = 127657993 fsxattr.nextents = 129683339 # And a few minutes later this: # xfs_io -f -c "stat" /mnt/scratch/big-file |grep next fsxattr.nextents = 4177861124 # Ah, what? Where did that 4 billion extra extents suddenly come from? Stop the workload, unmount, mount: # xfs_io -f -c "stat" /mnt/scratch/big-file |grep next fsxattr.nextents = 166044375 # And it's back at the expected number. i.e. the extent count is correct on disk, but it's screwed up in memory. I loaded up the extent list, and immediately: # xfs_io -f -c "stat" /mnt/scratch/big-file |grep next fsxattr.nextents = 4192576215 # It's bad again. So, where does that number come from? xfs_fill_fsxattr(): if (ip->i_df.if_flags & XFS_IFEXTENTS) fa->fsx_nextents = xfs_iext_count(&ip->i_df); else fa->fsx_nextents = ip->i_d.di_nextents; And that's the behaviour I just saw in a nutshell. The on disk count is correct, but once the tree is loaded into memory, it goes whacky. Clearly there's something wrong with xfs_iext_count(): inline xfs_extnum_t xfs_iext_count(struct xfs_ifork *ifp) { return ifp->if_bytes / sizeof(struct xfs_iext_rec); } Simple enough, but 134M extents is 2**27, and that's right about where things went wrong. A struct xfs_iext_rec is 16 bytes in size, which means 2**27 * 2**4 = 2**31 and we're right on target for an integer overflow. And, sure enough: struct xfs_ifork { int if_bytes; /* bytes in if_u1 */ .... Once we get 2**27 extents in a file, we overflow if_bytes and the in-core extent count goes wrong. And when we reach 2**28 extents, if_bytes wraps back to zero and things really start to go wrong there. This is where the silent failure comes from - only the first 2**28 extents can be looked up directly due to the overflow, all the extents above this index wrap back to somewhere in the first 2**28 extents. Hence with a regular pattern, trying to punch a hole in the range that didn't have holes mapped to a hole in the first 2**28 extents and so "succeeded" without changing anything. Hence "silent failure"... Fix this by converting if_bytes to a int64_t and converting all the index variables and size calculations to use int64_t types to avoid overflows in future. Signed integers are still used to enable easy detection of extent count underflows. This enables scalability of extent counts to the limits of the on-disk format - MAXEXTNUM (2**31) extents. Current testing is at over 500M extents and still going: fsxattr.nextents = 517310478 Reported-by: Zorro Lang Signed-off-by: Dave Chinner Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin commit ff099d7c845def4b9824ad17072d46b73209f8cb Author: Fuqian Huang Date: Fri Sep 27 20:15:44 2019 +0800 m68k: q40: Fix info-leak in rtc_ioctl [ Upstream commit 7cf78b6b12fd5550545e4b73b35dca18bd46b44c ] When the option is RTC_PLL_GET, pll will be copied to userland via copy_to_user. pll is initialized using mach_get_rtc_pll indirect call and mach_get_rtc_pll is only assigned with function q40_get_rtc_pll in arch/m68k/q40/config.c. In function q40_get_rtc_pll, the field pll_ctrl is not initialized. This will leak uninitialized stack content to userland. Fix this by zeroing the uninitialized field. Signed-off-by: Fuqian Huang Link: https://lore.kernel.org/r/20190927121544.7650-1-huangfq.daxian@gmail.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit bbe4f5e44a75f3468afe77fb2f288f00ece3d17a Author: Balsundar P Date: Tue Oct 15 11:51:58 2019 +0530 scsi: aacraid: fix illegal IO beyond last LBA [ Upstream commit c86fbe484c10b2cd1e770770db2d6b2c88801c1d ] The driver fails to handle data when read or written beyond device reported LBA, which triggers kernel panic Link: https://lore.kernel.org/r/1571120524-6037-2-git-send-email-balsundar.p@microsemi.com Signed-off-by: Balsundar P Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 2c25b951117857d43fdac01fe7bd3894514e6ecf Author: Jia He Date: Fri Oct 11 22:09:39 2019 +0800 mm: fix double page fault on arm64 if PTE_AF is cleared [ Upstream commit 83d116c53058d505ddef051e90ab27f57015b025 ] When we tested pmdk unit test [1] vmmalloc_fork TEST3 on arm64 guest, there will be a double page fault in __copy_from_user_inatomic of cow_user_page. To reproduce the bug, the cmd is as follows after you deployed everything: make -C src/test/vmmalloc_fork/ TEST_TIME=60m check Below call trace is from arm64 do_page_fault for debugging purpose: [ 110.016195] Call trace: [ 110.016826] do_page_fault+0x5a4/0x690 [ 110.017812] do_mem_abort+0x50/0xb0 [ 110.018726] el1_da+0x20/0xc4 [ 110.019492] __arch_copy_from_user+0x180/0x280 [ 110.020646] do_wp_page+0xb0/0x860 [ 110.021517] __handle_mm_fault+0x994/0x1338 [ 110.022606] handle_mm_fault+0xe8/0x180 [ 110.023584] do_page_fault+0x240/0x690 [ 110.024535] do_mem_abort+0x50/0xb0 [ 110.025423] el0_da+0x20/0x24 The pte info before __copy_from_user_inatomic is (PTE_AF is cleared): [ffff9b007000] pgd=000000023d4f8003, pud=000000023da9b003, pmd=000000023d4b3003, pte=360000298607bd3 As told by Catalin: "On arm64 without hardware Access Flag, copying from user will fail because the pte is old and cannot be marked young. So we always end up with zeroed page after fork() + CoW for pfn mappings. we don't always have a hardware-managed access flag on arm64." This patch fixes it by calling pte_mkyoung. Also, the parameter is changed because vmf should be passed to cow_user_page() Add a WARN_ON_ONCE when __copy_from_user_inatomic() returns error in case there can be some obscure use-case (by Kirill). [1] https://github.com/pmem/pmdk/tree/master/src/test/vmmalloc_fork Signed-off-by: Jia He Reported-by: Yibo Cai Reviewed-by: Catalin Marinas Acked-by: Kirill A. Shutemov Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit bdb830d101e7e23a2b09e1c52eb291a86ddfb87e Author: Pierre Crégut Date: Wed Sep 11 09:27:36 2019 +0200 PCI/IOV: Serialize sysfs sriov_numvfs reads vs writes [ Upstream commit 35ff867b76576e32f34c698ccd11343f7d616204 ] When sriov_numvfs is being updated, we call the driver->sriov_configure() function, which may enable VFs and call probe functions, which may make new devices visible. This all happens before before sriov_numvfs_store() updates sriov->num_VFs, so previously, concurrent sysfs reads of sriov_numvfs returned stale values. Serialize the sysfs read vs the write so the read returns the correct num_VFs value. [bhelgaas: hold device_lock instead of checking mutex_is_locked()] Link: https://bugzilla.kernel.org/show_bug.cgi?id=202991 Link: https://lore.kernel.org/r/20190911072736.32091-1-pierre.cregut@orange.com Signed-off-by: Pierre Crégut Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit a34a9a4c31e2a7928706a54f55491320e86854b3 Author: Miaoqing Pan Date: Wed Oct 9 16:18:09 2019 +0800 ath10k: fix memory leak for tpc_stats_final [ Upstream commit 486a8849843455298d49e694cca9968336ce2327 ] The memory of ar->debug.tpc_stats_final is reallocated every debugfs reading, it should be freed in ath10k_debug_destroy() for the last allocation. Tested HW: QCA9984 Tested FW: 10.4-3.9.0.2-00035 Signed-off-by: Miaoqing Pan Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit b8ef4aaf6e326662c2c0614882d519c17c974a12 Author: Miaoqing Pan Date: Wed Oct 9 16:18:08 2019 +0800 ath10k: fix array out-of-bounds access [ Upstream commit c5329b2d5b8b4e41be14d31ee8505b4f5607bf9b ] If firmware reports rate_max > WMI_TPC_RATE_MAX(WMI_TPC_FINAL_RATE_MAX) or num_tx_chain > WMI_TPC_TX_N_CHAIN, it will cause array out-of-bounds access, so print a warning and reset to avoid memory corruption. Tested HW: QCA9984 Tested FW: 10.4-3.9.0.2-00035 Signed-off-by: Miaoqing Pan Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit abc15be19f4cb3da457b75dbf40ad8b6161cb13d Author: Quinn Tran Date: Thu Sep 12 11:09:13 2019 -0700 scsi: qla2xxx: Add error handling for PLOGI ELS passthrough [ Upstream commit c76ae845ea836d6128982dcbd41ac35c81e2de63 ] Add error handling logic to ELS Passthrough relating to NVME devices. Current code does not parse error code to take proper recovery action, instead it re-logins with the same login parameters that encountered the error. Ex: nport handle collision. Link: https://lore.kernel.org/r/20190912180918.6436-10-hmadhani@marvell.com Signed-off-by: Quinn Tran Signed-off-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit ac559369050fde4bce7a624c6951ab394e0b8ffd Author: Chris Wilson Date: Fri Oct 4 11:11:40 2019 +0100 dma-fence: Serialise signal enabling (dma_fence_enable_sw_signaling) [ Upstream commit 9c98f021e4e717ffd9948fa65340ea3ef12b7935 ] Make dma_fence_enable_sw_signaling() behave like its dma_fence_add_callback() and dma_fence_default_wait() counterparts and perform the test to enable signaling under the fence->lock, along with the action to do so. This ensure that should an implementation be trying to flush the cb_list (by signaling) on retirement before freeing the fence, it can do so in a race-free manner. See also 0fc89b6802ba ("dma-fence: Simply wrap dma_fence_signal_locked with dma_fence_signal"). v2: Refactor all 3 enable_signaling paths to use a common function. v3: Don't argue, just keep the tracepoint in the existing spot. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Reviewed-by: Tvrtko Ursulin Link: https://patchwork.freedesktop.org/patch/msgid/20191004101140.32713-1-chris@chris-wilson.co.uk Signed-off-by: Sasha Levin commit 3e7bf63360841fc8178d83f996b8aa935b8ffb2a Author: Jay Cornwall Date: Wed Sep 25 17:05:01 2019 -0500 drm/amdkfd: Fix race in gfx10 context restore handler [ Upstream commit c18cc2bb9e064d3a613d8276f2cab3984926a779 ] Missing synchronization with VGPR restore leads to intermittent VGPR trashing in the user shader. Signed-off-by: Jay Cornwall Reviewed-by: Yong Zhao Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c08ecda2cf31abd761f67ca34ff9da667d158308 Author: Wesley Chalmers Date: Mon Sep 16 15:42:38 2019 -0500 drm/amd/display: Do not double-buffer DTO adjustments [ Upstream commit 6bd0a112ec129615d23aa5d8d3dd0be0243989aa ] [WHY] When changing DPP global ref clock, DTO adjustments must take effect immediately, or else underflow may occur. It appears the original decision to double-buffer DTO adjustments was made to prevent underflows that occur when raising DPP ref clock (which is not double-buffered), but that same decision causes similar issues when lowering DPP global ref clock. The better solution is to order the adjustments according to whether clocks are being raised or lowered. Signed-off-by: Wesley Chalmers Reviewed-by: Dmytro Laktyushkin Acked-by: Anthony Koo Acked-by: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 1333ce263ad9616140c4fddf3dd0f985d9c9d2b5 Author: zhengbin Date: Sun Aug 18 22:51:30 2019 -0300 media: mc-device.c: fix memleak in media_device_register_entity [ Upstream commit 713f871b30a66dc4daff4d17b760c9916aaaf2e1 ] In media_device_register_entity, if media_graph_walk_init fails, need to free the previously memory. Reported-by: Hulk Robot Signed-off-by: zhengbin Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit b7316f505fe5213a6fa6eaa5e03404b8e75ced26 Author: Jonathan Lebon Date: Thu Sep 12 09:30:07 2019 -0400 selinux: allow labeling before policy is loaded [ Upstream commit 3e3e24b42043eceb97ed834102c2d094dfd7aaa6 ] Currently, the SELinux LSM prevents one from setting the `security.selinux` xattr on an inode without a policy first being loaded. However, this restriction is problematic: it makes it impossible to have newly created files with the correct label before actually loading the policy. This is relevant in distributions like Fedora, where the policy is loaded by systemd shortly after pivoting out of the initrd. In such instances, all files created prior to pivoting will be unlabeled. One then has to relabel them after pivoting, an operation which inherently races with other processes trying to access those same files. Going further, there are use cases for creating the entire root filesystem on first boot from the initrd (e.g. Container Linux supports this today[1], and we'd like to support it in Fedora CoreOS as well[2]). One can imagine doing this in two ways: at the block device level (e.g. laying down a disk image), or at the filesystem level. In the former, labeling can simply be part of the image. But even in the latter scenario, one still really wants to be able to set the right labels when populating the new filesystem. This patch enables this by changing behaviour in the following two ways: 1. allow `setxattr` if we're not initialized 2. don't try to set the in-core inode SID if we're not initialized; instead leave it as `LABEL_INVALID` so that revalidation may be attempted at a later time Note the first hunk of this patch is mostly the same as a previously discussed one[3], though it was part of a larger series which wasn't accepted. [1] https://coreos.com/os/docs/latest/root-filesystem-placement.html [2] https://github.com/coreos/fedora-coreos-tracker/issues/94 [3] https://www.spinics.net/lists/linux-initramfs/msg04593.html Co-developed-by: Victor Kamensky Signed-off-by: Victor Kamensky Signed-off-by: Jonathan Lebon Signed-off-by: Paul Moore Signed-off-by: Sasha Levin commit e14f1f8f1bfec3bc721ef533dd13ef616bd2d0cb Author: Sreekanth Reddy Date: Fri Sep 13 09:04:41 2019 -0400 scsi: mpt3sas: Free diag buffer without any status check [ Upstream commit 764f472ba4a7a0c18107ebfbe1a9f1f5f5a1e411 ] Memory leak can happen when diag buffer is released but not unregistered (where buffer is deallocated) by the user. During module unload time driver is not deallocating the buffer if the buffer is in released state. Deallocate the diag buffer during module unload time without any diag buffer status checks. Link: https://lore.kernel.org/r/1568379890-18347-5-git-send-email-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 6b8fbd9b2db056d888dc4f34f61c824faea659b3 Author: James Smart Date: Sat Sep 21 20:58:47 2019 -0700 scsi: lpfc: Fix pt2pt discovery on SLI3 HBAs [ Upstream commit 359e10f087dbb7b9c9f3035a8cc4391af45bd651 ] After exchanging PLOGI on an SLI-3 adapter, the PRLI exchange failed. Link trace showed the port was assigned a non-zero n_port_id, but didn't use the address on the PRLI. The assigned address is set on the port by the CONFIG_LINK mailbox command. The driver responded to the PRLI before the mailbox command completed. Thus the PRLI response used the old n_port_id. Defer the PRLI response until CONFIG_LINK completes. Link: https://lore.kernel.org/r/20190922035906.10977-2-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 03c4d42e3c14cca45ce64c85cd1eee0227048b85 Author: Iurii Zaikin Date: Mon Sep 23 02:02:47 2019 -0700 kernel/sysctl-test: Add null pointer test for sysctl.c:proc_dointvec() [ Upstream commit 2cb80dbbbaba4f2f86f686c34cb79ea5cbfb0edb ] KUnit tests for initialized data behavior of proc_dointvec that is explicitly checked in the code. Includes basic parsing tests including int min/max overflow. Signed-off-by: Iurii Zaikin Signed-off-by: Brendan Higgins Reviewed-by: Greg Kroah-Hartman Reviewed-by: Logan Gunthorpe Acked-by: Luis Chamberlain Reviewed-by: Stephen Boyd Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin