commit 997fee5473ce59c9b1461f54dd2975c57b258a6e Author: Greg Kroah-Hartman Date: Tue Sep 10 10:35:27 2019 +0100 Linux 5.2.14 commit 0ccc5c227f888185576b804a074c39334fde821a Author: Jan Kaisrlik Date: Tue Aug 20 13:42:29 2019 +0200 Revert "mmc: core: do not retry CMD6 in __mmc_switch()" commit 8ad8e02c2fa70cfddc1ded53ba9001c9d444075d upstream. Turns out the commit 3a0681c7448b ("mmc: core: do not retry CMD6 in __mmc_switch()") breaks initialization of a Toshiba THGBMNG5 eMMC card, when using the meson-gx-mmc.c driver on a custom board based on Amlogic A113D. The CMD6 that switches the card into HS200 mode is then one that fails and according to the below printed messages from the log: [ 1.648951] mmc0: mmc_select_hs200 failed, error -84 [ 1.648988] mmc0: error -84 whilst initialising MMC card After some analyze, it turns out that adding a delay of ~5ms inside mmc_select_bus_width() but after mmc_compare_ext_csds() has been executed, also fixes the problem. Adding yet some more debug code, trying to figure out if potentially the card could be in a busy state, both by using CMD13 and ->card_busy() ops concluded that this was not the case. Therefore, let's simply revert the commit that dropped support for retrying of CMD6, as this also fixes the problem. Fixes: 3a0681c7448b ("mmc: core: do not retry CMD6 in __mmc_switch()") Cc: stable@vger.kernel.org Signed-off-by: Jan Kaisrlik Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 317a66e24b4608564c70eaa941a815b5ceadbcba Author: John S. Gruber Date: Mon Sep 2 00:00:54 2019 +0200 x86/boot: Preserve boot_params.secure_boot from sanitizing commit 29d9a0b50736768f042752070e5cdf4e4d4c00df upstream. Commit a90118c445cc ("x86/boot: Save fields explicitly, zero out everything else") now zeroes the secure boot setting information (enabled/disabled/...) passed by the boot loader or by the kernel's EFI handover mechanism. The problem manifests itself with signed kernels using the EFI handoff protocol with grub and the kernel loses the information whether secure boot is enabled in the firmware, i.e., the log message "Secure boot enabled" becomes "Secure boot could not be determined". efi_main() arch/x86/boot/compressed/eboot.c sets this field early but it is subsequently zeroed by the above referenced commit. Include boot_params.secure_boot in the preserve field list. [ bp: restructure commit message and massage. ] Fixes: a90118c445cc ("x86/boot: Save fields explicitly, zero out everything else") Signed-off-by: John S. Gruber Signed-off-by: Borislav Petkov Reviewed-by: John Hubbard Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Juergen Gross Cc: Mark Brown Cc: stable Cc: Thomas Gleixner Cc: x86-ml Link: https://lkml.kernel.org/r/CAPotdmSPExAuQcy9iAHqX3js_fc4mMLQOTr5RBGvizyCOPcTQQ@mail.gmail.com Signed-off-by: Greg Kroah-Hartman commit 1a7fd193e9d85d2a6b11f16e19bbaf28f75ff11b Author: Linus Torvalds Date: Sat Sep 7 14:25:54 2019 -0700 Revert "x86/apic: Include the LDR when clearing out APIC registers" [ Upstream commit 950b07c14e8c59444e2359f15fd70ed5112e11a0 ] This reverts commit 558682b5291937a70748d36fd9ba757fb25b99ae. Chris Wilson reports that it breaks his CPU hotplug test scripts. In particular, it breaks offlining and then re-onlining the boot CPU, which we treat specially (and the BIOS does too). The symptoms are that we can offline the CPU, but it then does not come back online again: smpboot: CPU 0 is now offline smpboot: Booting Node 0 Processor 0 APIC 0x0 smpboot: do_boot_cpu failed(-1) to wakeup CPU#0 Thomas says he knows why it's broken (my personal suspicion: our magic handling of the "cpu0_logical_apicid" thing), but for 5.3 the right fix is to just revert it, since we've never touched the LDR bits before, and it's not worth the risk to do anything else at this stage. [ Hotpluging of the boot CPU is special anyway, and should be off by default. See the "BOOTPARAM_HOTPLUG_CPU0" config option and the cpu0_hotplug kernel parameter. In general you should not do it, and it has various known limitations (hibernate and suspend require the boot CPU, for example). But it should work, even if the boot CPU is special and needs careful treatment - Linus ] Link: https://lore.kernel.org/lkml/156785100521.13300.14461504732265570003@skylake-alporthouse-com/ Reported-by: Chris Wilson Acked-by: Thomas Gleixner Cc: Bandan Das Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ae96cf9e1e3196eecde327a6efc9e30b70537741 Author: Luis Henriques Date: Fri Jul 19 15:32:19 2019 +0100 libceph: allow ceph_buffer_put() to receive a NULL ceph_buffer [ Upstream commit 5c498950f730aa17c5f8a2cdcb903524e4002ed2 ] Signed-off-by: Luis Henriques Reviewed-by: Jeff Layton Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 8d50b82ea79b57d53164d60d5bd6f44248b436f0 Author: Kirill A. Shutemov Date: Mon Aug 26 16:26:01 2019 +0300 x86/boot/compressed/64: Fix missing initialization in find_trampoline_placement() [ Upstream commit c96e8483cb2da6695c8b8d0896fe7ae272a07b54 ] Gustavo noticed that 'new' can be left uninitialized if 'bios_start' happens to be less or equal to 'entry->addr + entry->size'. Initialize the variable at the begin of the iteration to the current value of 'bios_start'. Fixes: 0a46fff2f910 ("x86/boot/compressed/64: Fix boot on machines with broken E820 table") Reported-by: "Gustavo A. R. Silva" Signed-off-by: Kirill A. Shutemov Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/20190826133326.7cxb4vbmiawffv2r@box Signed-off-by: Sasha Levin commit 852a051ef22bc8e6dd2d4bd5f3e90509c770beb6 Author: Andre Przywara Date: Fri Aug 23 11:34:16 2019 +0100 KVM: arm/arm64: VGIC: Properly initialise private IRQ affinity [ Upstream commit 2e16f3e926ed48373c98edea85c6ad0ef69425d1 ] At the moment we initialise the target *mask* of a virtual IRQ to the VCPU it belongs to, even though this mask is only defined for GICv2 and quickly runs out of bits for many GICv3 guests. This behaviour triggers an UBSAN complaint for more than 32 VCPUs: ------ [ 5659.462377] UBSAN: Undefined behaviour in virt/kvm/arm/vgic/vgic-init.c:223:21 [ 5659.471689] shift exponent 32 is too large for 32-bit type 'unsigned int' ------ Also for GICv3 guests the reporting of TARGET in the "vgic-state" debugfs dump is wrong, due to this very same problem. Because there is no requirement to create the VGIC device before the VCPUs (and QEMU actually does it the other way round), we can't safely initialise mpidr or targets in kvm_vgic_vcpu_init(). But since we touch every private IRQ for each VCPU anyway later (in vgic_init()), we can just move the initialisation of those fields into there, where we definitely know the VGIC type. On the way make sure we really have either a VGICv2 or a VGICv3 device, since the existing code is just checking for "VGICv3 or not", silently ignoring the uninitialised case. Signed-off-by: Andre Przywara Reported-by: Dave Martin Tested-by: Julien Grall Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit 44dfa46aaf7cf594ac89bc1a0c0e56c498b31269 Author: Linus Walleij Date: Tue Aug 20 10:05:27 2019 +0200 gpio: Fix irqchip initialization order [ Upstream commit 48057ed1840fde9239b1e000bea1a0a1f07c5e99 ] The new API for registering a gpio_irq_chip along with a gpio_chip has a different semantic ordering than the old API which added the irqchip explicitly after registering the gpio_chip. Move the calls to add the gpio_irq_chip *last* in the function, so that the different hooks setting up OF and ACPI and machine gpio_chips are called *before* we try to register the interrupts, preserving the elder semantic order. This cropped up in the PL061 driver which used to work fine with no special ACPI quirks, but started to misbehave using the new API. Fixes: e0d897289813 ("gpio: Implement tighter IRQ chip integration") Cc: Thierry Reding Cc: Grygorii Strashko Cc: Andy Shevchenko Reported-by: Wei Xu Tested-by: Wei Xu Reported-by: Andy Shevchenko Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20190820080527.11796-1-linus.walleij@linaro.org Signed-off-by: Sasha Levin commit 157ec0a3f834ba449a2fa1c1c9075862a614ed52 Author: Selvin Xavier Date: Thu Aug 22 03:02:50 2019 -0700 RDMA/bnxt_re: Fix stack-out-of-bounds in bnxt_qplib_rcfw_send_message [ Upstream commit d37b1e534071ab1983e7c85273234b132c77591a ] Driver copies FW commands to the HW queue as units of 16 bytes. Some of the command structures are not exact multiple of 16. So while copying the data from those structures, the stack out of bounds messages are reported by KASAN. The following error is reported. [ 1337.530155] ================================================================== [ 1337.530277] BUG: KASAN: stack-out-of-bounds in bnxt_qplib_rcfw_send_message+0x40a/0x850 [bnxt_re] [ 1337.530413] Read of size 16 at addr ffff888725477a48 by task rmmod/2785 [ 1337.530540] CPU: 5 PID: 2785 Comm: rmmod Tainted: G OE 5.2.0-rc6+ #75 [ 1337.530541] Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.0.4 08/28/2014 [ 1337.530542] Call Trace: [ 1337.530548] dump_stack+0x5b/0x90 [ 1337.530556] ? bnxt_qplib_rcfw_send_message+0x40a/0x850 [bnxt_re] [ 1337.530560] print_address_description+0x65/0x22e [ 1337.530568] ? bnxt_qplib_rcfw_send_message+0x40a/0x850 [bnxt_re] [ 1337.530575] ? bnxt_qplib_rcfw_send_message+0x40a/0x850 [bnxt_re] [ 1337.530577] __kasan_report.cold.3+0x37/0x77 [ 1337.530581] ? _raw_write_trylock+0x10/0xe0 [ 1337.530588] ? bnxt_qplib_rcfw_send_message+0x40a/0x850 [bnxt_re] [ 1337.530590] kasan_report+0xe/0x20 [ 1337.530592] memcpy+0x1f/0x50 [ 1337.530600] bnxt_qplib_rcfw_send_message+0x40a/0x850 [bnxt_re] [ 1337.530608] ? bnxt_qplib_creq_irq+0xa0/0xa0 [bnxt_re] [ 1337.530611] ? xas_create+0x3aa/0x5f0 [ 1337.530613] ? xas_start+0x77/0x110 [ 1337.530615] ? xas_clear_mark+0x34/0xd0 [ 1337.530623] bnxt_qplib_free_mrw+0x104/0x1a0 [bnxt_re] [ 1337.530631] ? bnxt_qplib_destroy_ah+0x110/0x110 [bnxt_re] [ 1337.530633] ? bit_wait_io_timeout+0xc0/0xc0 [ 1337.530641] bnxt_re_dealloc_mw+0x2c/0x60 [bnxt_re] [ 1337.530648] bnxt_re_destroy_fence_mr+0x77/0x1d0 [bnxt_re] [ 1337.530655] bnxt_re_dealloc_pd+0x25/0x60 [bnxt_re] [ 1337.530677] ib_dealloc_pd_user+0xbe/0xe0 [ib_core] [ 1337.530683] srpt_remove_one+0x5de/0x690 [ib_srpt] [ 1337.530689] ? __srpt_close_all_ch+0xc0/0xc0 [ib_srpt] [ 1337.530692] ? xa_load+0x87/0xe0 ... [ 1337.530840] do_syscall_64+0x6d/0x1f0 [ 1337.530843] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 1337.530845] RIP: 0033:0x7ff5b389035b [ 1337.530848] Code: 73 01 c3 48 8b 0d 2d 0b 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d fd 0a 2c 00 f7 d8 64 89 01 48 [ 1337.530849] RSP: 002b:00007fff83425c28 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 [ 1337.530852] RAX: ffffffffffffffda RBX: 00005596443e6750 RCX: 00007ff5b389035b [ 1337.530853] RDX: 000000000000000a RSI: 0000000000000800 RDI: 00005596443e67b8 [ 1337.530854] RBP: 0000000000000000 R08: 00007fff83424ba1 R09: 0000000000000000 [ 1337.530856] R10: 00007ff5b3902960 R11: 0000000000000206 R12: 00007fff83425e50 [ 1337.530857] R13: 00007fff8342673c R14: 00005596443e6260 R15: 00005596443e6750 [ 1337.530885] The buggy address belongs to the page: [ 1337.530962] page:ffffea001c951dc0 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 [ 1337.530964] flags: 0x57ffffc0000000() [ 1337.530967] raw: 0057ffffc0000000 0000000000000000 ffffffff1c950101 0000000000000000 [ 1337.530970] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 [ 1337.530970] page dumped because: kasan: bad access detected [ 1337.530996] Memory state around the buggy address: [ 1337.531072] ffff888725477900: 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 f2 f2 f2 [ 1337.531180] ffff888725477980: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 [ 1337.531288] >ffff888725477a00: 00 f2 f2 f2 f2 f2 f2 00 00 00 f2 00 00 00 00 00 [ 1337.531393] ^ [ 1337.531478] ffff888725477a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1337.531585] ffff888725477b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1337.531691] ================================================================== Fix this by passing the exact size of each FW command to bnxt_qplib_rcfw_send_message as req->cmd_size. Before sending the command to HW, modify the req->cmd_size to number of 16 byte units. Fixes: 1ac5a4047975 ("RDMA/bnxt_re: Add bnxt_re RoCE driver") Signed-off-by: Selvin Xavier Link: https://lore.kernel.org/r/1566468170-489-1-git-send-email-selvin.xavier@broadcom.com Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin commit cf9ec2e9056cb7407d72c68b8346bf5a30225122 Author: YueHaibing Date: Mon Aug 19 16:05:31 2019 +0100 afs: use correct afs_call_type in yfs_fs_store_opaque_acl2 [ Upstream commit 7533be858f5b9a036b9f91556a3ed70786abca8e ] It seems that 'yfs_RXYFSStoreOpaqueACL2' should be use in yfs_fs_store_opaque_acl2(). Fixes: f5e4546347bc ("afs: Implement YFS ACL setting") Signed-off-by: YueHaibing Signed-off-by: David Howells Signed-off-by: Sasha Levin commit 3f66858358891311582a179d3443cfcdde476e86 Author: Marc Dionne Date: Thu Aug 22 13:28:43 2019 +0100 afs: Fix possible oops in afs_lookup trace event [ Upstream commit c4c613ff08d92e72bf64a65ec35a2c3aa1cfcd06 ] The afs_lookup trace event can cause the following: [ 216.576777] BUG: kernel NULL pointer dereference, address: 000000000000023b [ 216.576803] #PF: supervisor read access in kernel mode [ 216.576813] #PF: error_code(0x0000) - not-present page ... [ 216.576913] RIP: 0010:trace_event_raw_event_afs_lookup+0x9e/0x1c0 [kafs] If the inode from afs_do_lookup() is an error other than ENOENT, or if it is ENOENT and afs_try_auto_mntpt() returns an error, the trace event will try to dereference the error pointer as a valid pointer. Use IS_ERR_OR_NULL to only pass a valid pointer for the trace, or NULL. Ideally the trace would include the error value, but for now just avoid the oops. Fixes: 80548b03991f ("afs: Add more tracepoints") Signed-off-by: Marc Dionne Signed-off-by: David Howells Signed-off-by: Sasha Levin commit c231241d83b960ec7b57f172921d223c28dce014 Author: David Howells Date: Thu Aug 22 13:28:43 2019 +0100 afs: Fix leak in afs_lookup_cell_rcu() [ Upstream commit a5fb8e6c02d6a518fb2b1a2b8c2471fa77b69436 ] Fix a leak on the cell refcount in afs_lookup_cell_rcu() due to non-clearance of the default error in the case a NULL cell name is passed and the workstation default cell is used. Also put a bit at the end to make sure we don't leak a cell ref if we're going to be returning an error. This leak results in an assertion like the following when the kafs module is unloaded: AFS: Assertion failed 2 == 1 is false 0x2 == 0x1 is false ------------[ cut here ]------------ kernel BUG at fs/afs/cell.c:770! ... RIP: 0010:afs_manage_cells+0x220/0x42f [kafs] ... process_one_work+0x4c2/0x82c ? pool_mayday_timeout+0x1e1/0x1e1 ? do_raw_spin_lock+0x134/0x175 worker_thread+0x336/0x4a6 ? rescuer_thread+0x4af/0x4af kthread+0x1de/0x1ee ? kthread_park+0xd4/0xd4 ret_from_fork+0x24/0x30 Fixes: 989782dcdc91 ("afs: Overhaul cell database management") Signed-off-by: David Howells Signed-off-by: Sasha Levin commit 7f134d569e1ab172d37de5c22e5bb000a036ac4c Author: Andrew Jones Date: Thu Aug 22 13:03:05 2019 +0200 KVM: arm/arm64: Only skip MMIO insn once [ Upstream commit 2113c5f62b7423e4a72b890bd479704aa85c81ba ] If after an MMIO exit to userspace a VCPU is immediately run with an immediate_exit request, such as when a signal is delivered or an MMIO emulation completion is needed, then the VCPU completes the MMIO emulation and immediately returns to userspace. As the exit_reason does not get changed from KVM_EXIT_MMIO in these cases we have to be careful not to complete the MMIO emulation again, when the VCPU is eventually run again, because the emulation does an instruction skip (and doing too many skips would be a waste of guest code :-) We need to use additional VCPU state to track if the emulation is complete. As luck would have it, we already have 'mmio_needed', which even appears to be used in this way by other architectures already. Fixes: 0d640732dbeb ("arm64: KVM: Skip MMIO insn after emulation") Acked-by: Mark Rutland Signed-off-by: Andrew Jones Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit 39c62cdaa2d41ea9007b80b6a4bf04a69d5ba32c Author: Luis Henriques Date: Fri Jul 19 15:32:22 2019 +0100 ceph: fix buffer free while holding i_ceph_lock in fill_inode() [ Upstream commit af8a85a41734f37b67ba8ce69d56b685bee4ac48 ] Calling ceph_buffer_put() in fill_inode() may result in freeing the i_xattrs.blob buffer while holding the i_ceph_lock. This can be fixed by postponing the call until later, when the lock is released. The following backtrace was triggered by fstests generic/070. BUG: sleeping function called from invalid context at mm/vmalloc.c:2283 in_atomic(): 1, irqs_disabled(): 0, pid: 3852, name: kworker/0:4 6 locks held by kworker/0:4/3852: #0: 000000004270f6bb ((wq_completion)ceph-msgr){+.+.}, at: process_one_work+0x1b8/0x5f0 #1: 00000000eb420803 ((work_completion)(&(&con->work)->work)){+.+.}, at: process_one_work+0x1b8/0x5f0 #2: 00000000be1c53a4 (&s->s_mutex){+.+.}, at: dispatch+0x288/0x1476 #3: 00000000559cb958 (&mdsc->snap_rwsem){++++}, at: dispatch+0x2eb/0x1476 #4: 000000000d5ebbae (&req->r_fill_mutex){+.+.}, at: dispatch+0x2fc/0x1476 #5: 00000000a83d0514 (&(&ci->i_ceph_lock)->rlock){+.+.}, at: fill_inode.isra.0+0xf8/0xf70 CPU: 0 PID: 3852 Comm: kworker/0:4 Not tainted 5.2.0+ #441 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58-prebuilt.qemu.org 04/01/2014 Workqueue: ceph-msgr ceph_con_workfn Call Trace: dump_stack+0x67/0x90 ___might_sleep.cold+0x9f/0xb1 vfree+0x4b/0x60 ceph_buffer_release+0x1b/0x60 fill_inode.isra.0+0xa9b/0xf70 ceph_fill_trace+0x13b/0xc70 ? dispatch+0x2eb/0x1476 dispatch+0x320/0x1476 ? __mutex_unlock_slowpath+0x4d/0x2a0 ceph_con_workfn+0xc97/0x2ec0 ? process_one_work+0x1b8/0x5f0 process_one_work+0x244/0x5f0 worker_thread+0x4d/0x3e0 kthread+0x105/0x140 ? process_one_work+0x5f0/0x5f0 ? kthread_park+0x90/0x90 ret_from_fork+0x3a/0x50 Signed-off-by: Luis Henriques Reviewed-by: Jeff Layton Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit c4e28be29a456fce5a96c1ce57642f78699948f0 Author: Luis Henriques Date: Fri Jul 19 15:32:21 2019 +0100 ceph: fix buffer free while holding i_ceph_lock in __ceph_build_xattrs_blob() [ Upstream commit 12fe3dda7ed89c95cc0ef7abc001ad1ad3e092f8 ] Calling ceph_buffer_put() in __ceph_build_xattrs_blob() may result in freeing the i_xattrs.blob buffer while holding the i_ceph_lock. This can be fixed by having this function returning the old blob buffer and have the callers of this function freeing it when the lock is released. The following backtrace was triggered by fstests generic/117. BUG: sleeping function called from invalid context at mm/vmalloc.c:2283 in_atomic(): 1, irqs_disabled(): 0, pid: 649, name: fsstress 4 locks held by fsstress/649: #0: 00000000a7478e7e (&type->s_umount_key#19){++++}, at: iterate_supers+0x77/0xf0 #1: 00000000f8de1423 (&(&ci->i_ceph_lock)->rlock){+.+.}, at: ceph_check_caps+0x7b/0xc60 #2: 00000000562f2b27 (&s->s_mutex){+.+.}, at: ceph_check_caps+0x3bd/0xc60 #3: 00000000f83ce16a (&mdsc->snap_rwsem){++++}, at: ceph_check_caps+0x3ed/0xc60 CPU: 1 PID: 649 Comm: fsstress Not tainted 5.2.0+ #439 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack+0x67/0x90 ___might_sleep.cold+0x9f/0xb1 vfree+0x4b/0x60 ceph_buffer_release+0x1b/0x60 __ceph_build_xattrs_blob+0x12b/0x170 __send_cap+0x302/0x540 ? __lock_acquire+0x23c/0x1e40 ? __mark_caps_flushing+0x15c/0x280 ? _raw_spin_unlock+0x24/0x30 ceph_check_caps+0x5f0/0xc60 ceph_flush_dirty_caps+0x7c/0x150 ? __ia32_sys_fdatasync+0x20/0x20 ceph_sync_fs+0x5a/0x130 iterate_supers+0x8f/0xf0 ksys_sync+0x4f/0xb0 __ia32_sys_sync+0xa/0x10 do_syscall_64+0x50/0x1c0 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7fc6409ab617 Signed-off-by: Luis Henriques Reviewed-by: Jeff Layton Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit f41cd559f1f3412db8e0acdede05ecf990ebfd8a Author: Luis Henriques Date: Fri Jul 19 15:32:20 2019 +0100 ceph: fix buffer free while holding i_ceph_lock in __ceph_setxattr() [ Upstream commit 86968ef21596515958d5f0a40233d02be78ecec0 ] Calling ceph_buffer_put() in __ceph_setxattr() may end up freeing the i_xattrs.prealloc_blob buffer while holding the i_ceph_lock. This can be fixed by postponing the call until later, when the lock is released. The following backtrace was triggered by fstests generic/117. BUG: sleeping function called from invalid context at mm/vmalloc.c:2283 in_atomic(): 1, irqs_disabled(): 0, pid: 650, name: fsstress 3 locks held by fsstress/650: #0: 00000000870a0fe8 (sb_writers#8){.+.+}, at: mnt_want_write+0x20/0x50 #1: 00000000ba0c4c74 (&type->i_mutex_dir_key#6){++++}, at: vfs_setxattr+0x55/0xa0 #2: 000000008dfbb3f2 (&(&ci->i_ceph_lock)->rlock){+.+.}, at: __ceph_setxattr+0x297/0x810 CPU: 1 PID: 650 Comm: fsstress Not tainted 5.2.0+ #437 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack+0x67/0x90 ___might_sleep.cold+0x9f/0xb1 vfree+0x4b/0x60 ceph_buffer_release+0x1b/0x60 __ceph_setxattr+0x2b4/0x810 __vfs_setxattr+0x66/0x80 __vfs_setxattr_noperm+0x59/0xf0 vfs_setxattr+0x81/0xa0 setxattr+0x115/0x230 ? filename_lookup+0xc9/0x140 ? rcu_read_lock_sched_held+0x74/0x80 ? rcu_sync_lockdep_assert+0x2e/0x60 ? __sb_start_write+0x142/0x1a0 ? mnt_want_write+0x20/0x50 path_setxattr+0xba/0xd0 __x64_sys_lsetxattr+0x24/0x30 do_syscall_64+0x50/0x1c0 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7ff23514359a Signed-off-by: Luis Henriques Reviewed-by: Jeff Layton Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 3ebab463e9f42a186389e490bc199476db2a14d5 Author: Nicolai Hähnle Date: Tue Aug 20 15:39:53 2019 +0200 drm/amdgpu: prevent memory leaks in AMDGPU_CS ioctl [ Upstream commit 1a701ea924815b0518733aa8d5d05c1f6fa87062 ] Error out if the AMDGPU_CS ioctl is called with multiple SYNCOBJ_OUT and/or TIMELINE_SIGNAL chunks, since otherwise the last chunk wins while the allocated array as well as the reference counts of sync objects are leaked. Signed-off-by: Nicolai Hähnle Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 23da8e9ef69bc9af8f542edcf2123441edb45071 Author: Vitaly Kuznetsov Date: Mon Jun 10 19:22:55 2019 +0200 selftests/kvm: make platform_info_test pass on AMD [ Upstream commit e4427372398c31f57450565de277f861a4db5b3b ] test_msr_platform_info_disabled() generates EXIT_SHUTDOWN but VMCB state is undefined after that so an attempt to launch this guest again from test_msr_platform_info_enabled() fails. Reorder the tests to make test pass. Signed-off-by: Vitaly Kuznetsov Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 666a41848d72bed82ef323d5139a651569fc0e27 Author: Paolo Bonzini Date: Tue Aug 20 17:35:52 2019 +0200 selftests: kvm: fix state save/load on processors without XSAVE [ Upstream commit 54577e5018a8c0cb79c9a0fa118a55c68715d398 ] state_test and smm_test are failing on older processors that do not have xcr0. This is because on those processor KVM does provide support for KVM_GET/SET_XSAVE (to avoid having to rely on the older KVM_GET/SET_FPU) but not for KVM_GET/SET_XCRS. Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit dd53d830bb30fe1164e49a8c4677144fbd10940c Author: Wenwen Wang Date: Sun Aug 18 13:54:46 2019 -0500 infiniband: hfi1: fix memory leaks [ Upstream commit 2323d7baab2b18d87d9bc267452e387aa9f0060a ] In fault_opcodes_write(), 'data' is allocated through kcalloc(). However, it is not deallocated in the following execution if an error occurs, leading to memory leaks. To fix this issue, introduce the 'free_data' label to free 'data' before returning the error. Signed-off-by: Wenwen Wang Reviewed-by: Leon Romanovsky Acked-by: Dennis Dalessandro Link: https://lore.kernel.org/r/1566154486-3713-1-git-send-email-wenwen@cs.uga.edu Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin commit bcb3211656fa24090a828cc2ee13cf8f3b95f08d Author: Wenwen Wang Date: Sun Aug 18 14:29:31 2019 -0500 infiniband: hfi1: fix a memory leak bug [ Upstream commit b08afa064c320e5d85cdc27228426b696c4c8dae ] In fault_opcodes_read(), 'data' is not deallocated if debugfs_file_get() fails, leading to a memory leak. To fix this bug, introduce the 'free_data' label to free 'data' before returning the error. Signed-off-by: Wenwen Wang Reviewed-by: Leon Romanovsky Acked-by: Dennis Dalessandro Link: https://lore.kernel.org/r/1566156571-4335-1-git-send-email-wenwen@cs.uga.edu Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin commit 1e93149659ccd7a427a73788b96b2e8d922688a0 Author: Wenwen Wang Date: Sun Aug 18 15:23:01 2019 -0500 IB/mlx4: Fix memory leaks [ Upstream commit 5c1baaa82cea2c815a5180ded402a7cd455d1810 ] In mlx4_ib_alloc_pv_bufs(), 'tun_qp->tx_ring' is allocated through kcalloc(). However, it is not always deallocated in the following execution if an error occurs, leading to memory leaks. To fix this issue, free 'tun_qp->tx_ring' whenever an error occurs. Signed-off-by: Wenwen Wang Acked-by: Leon Romanovsky Link: https://lore.kernel.org/r/1566159781-4642-1-git-send-email-wenwen@cs.uga.edu Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin commit fc38afc0434394e48d6170fd303e1dc99bb08989 Author: zhengbin Date: Mon Aug 19 12:27:39 2019 +0800 RDMA/cma: fix null-ptr-deref Read in cma_cleanup [ Upstream commit a7bfb93f0211b4a2f1ffeeb259ed6206bac30460 ] In cma_init, if cma_configfs_init fails, need to free the previously memory and return fail, otherwise will trigger null-ptr-deref Read in cma_cleanup. cma_cleanup cma_configfs_exit configfs_unregister_subsystem Fixes: 045959db65c6 ("IB/cma: Add configfs for rdma_cm") Reported-by: Hulk Robot Signed-off-by: zhengbin Reviewed-by: Parav Pandit Link: https://lore.kernel.org/r/1566188859-103051-1-git-send-email-zhengbin13@huawei.com Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin commit d61a256fece284909132d7e8eb6b7d385b864eac Author: Guilherme G. Piccoli Date: Wed Aug 14 11:26:10 2019 -0300 nvme: Fix cntlid validation when not using NVMEoF [ Upstream commit a89fcca8185633993018dc081d6b021d005e6d0b ] Commit 1b1031ca63b2 ("nvme: validate cntlid during controller initialisation") introduced a validation for controllers with duplicate cntlid that runs on nvme_init_subsystem(). The problem is that the validation relies on ctrl->cntlid, and this value is assigned (from id_ctrl value) after the call for nvme_init_subsystem() in nvme_init_identify() for non-fabrics scenario. That leads to ctrl->cntlid always being 0 in case we have a physical set of controllers in the same subsystem. This patch fixes that by loading the discovered cntlid id_ctrl value into ctrl->cntlid before the subsystem initialization, only for the non-fabrics case. The patch was tested with emulated nvme devices (qemu) having two controllers in a single subsystem. Without the patch, we couldn't make it work failing in the duplicate check; when running with the patch, we could see the subsystem holding both controllers. For the fabrics case we see ctrl->cntlid has a more intricate relation with the admin connect, so we didn't change that. Fixes: 1b1031ca63b2 ("nvme: validate cntlid during controller initialisation") Signed-off-by: Guilherme G. Piccoli Reviewed-by: Sagi Grimberg Signed-off-by: Sagi Grimberg Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit e1031b6c8100dba0da0d672f98db3a03139a3f93 Author: Anton Eidelman Date: Mon Aug 12 23:00:36 2019 +0300 nvme-multipath: fix possible I/O hang when paths are updated [ Upstream commit 504db087aaccdb32af61539916409f7dca31ceb5 ] nvme_state_set_live() making a path available triggers requeue_work in order to resubmit requests that ended up on requeue_list when no paths were available. This requeue_work may race with concurrent nvme_ns_head_make_request() that do not observe the live path yet. Such concurrent requests may by made by either: - New IO submission. - Requeue_work triggered by nvme_failover_req() or another ana_work. A race may cause requeue_work capture the state of requeue_list before more requests get onto the list. These requests will stay on the list forever unless requeue_work is triggered again. In order to prevent such race, nvme_state_set_live() should synchronize_srcu(&head->srcu) before triggering the requeue_work and prevent nvme_ns_head_make_request referencing an old snapshot of the path list. Reviewed-by: Christoph Hellwig Signed-off-by: Anton Eidelman Signed-off-by: Sagi Grimberg Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 6950d5b64a15407f10959f8a2e634ee65c576aea Author: Vitaly Kuznetsov Date: Mon Aug 19 16:44:09 2019 +0200 Tools: hv: kvp: eliminate 'may be used uninitialized' warning [ Upstream commit 89eb4d8d25722a0a0194cf7fa47ba602e32a6da7 ] When building hv_kvp_daemon GCC-8.3 complains: hv_kvp_daemon.c: In function ‘kvp_get_ip_info.constprop’: hv_kvp_daemon.c:812:30: warning: ‘ip_buffer’ may be used uninitialized in this function [-Wmaybe-uninitialized] struct hv_kvp_ipaddr_value *ip_buffer; this seems to be a false positive: we only use ip_buffer when op == KVP_OP_GET_IP_INFO and it is only unset when op == KVP_OP_ENUMERATE. Silence the warning by initializing ip_buffer to NULL. Signed-off-by: Vitaly Kuznetsov Signed-off-by: Sasha Levin commit 195b5aa923ecbd69ff8893166f18f37e024b896e Author: Dexuan Cui Date: Tue Aug 20 03:01:23 2019 +0000 Input: hyperv-keyboard: Use in-place iterator API in the channel callback [ Upstream commit d09bc83640d524b8467a660db7b1d15e6562a1de ] Simplify the ring buffer handling with the in-place API. Also avoid the dynamic allocation and the memory leak in the channel callback function. Signed-off-by: Dexuan Cui Acked-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 31b60e5c604c99766bd6f5692ed954eee585807b Author: James Smart Date: Thu Aug 15 19:36:49 2019 -0700 scsi: lpfc: Mitigate high memory pre-allocation by SCSI-MQ [ Upstream commit 77ffd3465ba837e9dc714e17b014e77b2eae765a ] When SCSI-MQ is enabled, the SCSI-MQ layers will do pre-allocation of MQ resources based on shost values set by the driver. In newer cases of the driver, which attempts to set nr_hw_queues to the cpu count, the multipliers become excessive, with a single shost having SCSI-MQ pre-allocation reaching into the multiple GBytes range. NPIV, which creates additional shosts, only multiply this overhead. On lower-memory systems, this can exhaust system memory very quickly, resulting in a system crash or failures in the driver or elsewhere due to low memory conditions. After testing several scenarios, the situation can be mitigated by limiting the value set in shost->nr_hw_queues to 4. Although the shost values were changed, the driver still had per-cpu hardware queues of its own that allowed parallelization per-cpu. Testing revealed that even with the smallish number for nr_hw_queues for SCSI-MQ, performance levels remained near maximum with the within-driver affiinitization. A module parameter was created to allow the value set for the nr_hw_queues to be tunable. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Reviewed-by: Ming Lei Reviewed-by: Ewan D. Milne Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit aa4bc3a352535c68a3625ad0d57d23748b4166a4 Author: Kirill A. Shutemov Date: Tue Aug 13 16:16:54 2019 +0300 x86/boot/compressed/64: Fix boot on machines with broken E820 table [ Upstream commit 0a46fff2f9108c2c44218380a43a736cf4612541 ] BIOS on Samsung 500C Chromebook reports very rudimentary E820 table that consists of 2 entries: BIOS-e820: [mem 0x0000000000000000-0x0000000000000fff] usable BIOS-e820: [mem 0x00000000fffff000-0x00000000ffffffff] reserved It breaks logic in find_trampoline_placement(): bios_start lands on the end of the first 4k page and trampoline start gets placed below 0. Detect underflow and don't touch bios_start for such cases. It makes kernel ignore E820 table on machines that doesn't have two usable pages below BIOS_START_MAX. Fixes: 1b3a62643660 ("x86/boot/compressed/64: Validate trampoline placement against E820") Signed-off-by: Kirill A. Shutemov Signed-off-by: Borislav Petkov Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Thomas Gleixner Cc: x86-ml Link: https://bugzilla.kernel.org/show_bug.cgi?id=203463 Link: https://lkml.kernel.org/r/20190813131654.24378-1-kirill.shutemov@linux.intel.com Signed-off-by: Sasha Levin commit 3091859b0b5e5f3c03d809dd7f1b915355b24076 Author: Benjamin Tissoires Date: Mon Aug 12 18:04:44 2019 +0200 HID: cp2112: prevent sleeping function called from invalid context [ Upstream commit 2d05dba2b25ecb0f8fc3a0b4eb2232da6454a47b ] When calling request_threaded_irq() with a CP2112, the function cp2112_gpio_irq_startup() is called in a IRQ context. Therefore we can not sleep, and we can not call cp2112_gpio_direction_input() there. Move the call to cp2112_gpio_direction_input() earlier to have a working driver. Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit e8fd4f47b22470e2c1f01f8defce0f4147a4d342 Author: Even Xu Date: Fri Aug 9 21:18:29 2019 +0800 HID: intel-ish-hid: ipc: add EHL device id [ Upstream commit b640be5bc8e4673dc8049cf74176ddedecea5597 ] EHL is a new platform using ishtp solution, add its device id to support list. Signed-off-by: Even Xu Acked-by: Srinivas Pandruvada Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit d58500c6fcb4485f3cee50eb09b308adc37fd0f4 Author: Andrea Righi Date: Mon Aug 12 20:43:02 2019 +0200 kprobes: Fix potential deadlock in kprobe_optimizer() [ Upstream commit f1c6ece23729257fb46562ff9224cf5f61b818da ] lockdep reports the following deadlock scenario: WARNING: possible circular locking dependency detected kworker/1:1/48 is trying to acquire lock: 000000008d7a62b2 (text_mutex){+.+.}, at: kprobe_optimizer+0x163/0x290 but task is already holding lock: 00000000850b5e2d (module_mutex){+.+.}, at: kprobe_optimizer+0x31/0x290 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (module_mutex){+.+.}: __mutex_lock+0xac/0x9f0 mutex_lock_nested+0x1b/0x20 set_all_modules_text_rw+0x22/0x90 ftrace_arch_code_modify_prepare+0x1c/0x20 ftrace_run_update_code+0xe/0x30 ftrace_startup_enable+0x2e/0x50 ftrace_startup+0xa7/0x100 register_ftrace_function+0x27/0x70 arm_kprobe+0xb3/0x130 enable_kprobe+0x83/0xa0 enable_trace_kprobe.part.0+0x2e/0x80 kprobe_register+0x6f/0xc0 perf_trace_event_init+0x16b/0x270 perf_kprobe_init+0xa7/0xe0 perf_kprobe_event_init+0x3e/0x70 perf_try_init_event+0x4a/0x140 perf_event_alloc+0x93a/0xde0 __do_sys_perf_event_open+0x19f/0xf30 __x64_sys_perf_event_open+0x20/0x30 do_syscall_64+0x65/0x1d0 entry_SYSCALL_64_after_hwframe+0x49/0xbe -> #0 (text_mutex){+.+.}: __lock_acquire+0xfcb/0x1b60 lock_acquire+0xca/0x1d0 __mutex_lock+0xac/0x9f0 mutex_lock_nested+0x1b/0x20 kprobe_optimizer+0x163/0x290 process_one_work+0x22b/0x560 worker_thread+0x50/0x3c0 kthread+0x112/0x150 ret_from_fork+0x3a/0x50 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(module_mutex); lock(text_mutex); lock(module_mutex); lock(text_mutex); *** DEADLOCK *** As a reproducer I've been using bcc's funccount.py (https://github.com/iovisor/bcc/blob/master/tools/funccount.py), for example: # ./funccount.py '*interrupt*' That immediately triggers the lockdep splat. Fix by acquiring text_mutex before module_mutex in kprobe_optimizer(). Signed-off-by: Andrea Righi Acked-by: Masami Hiramatsu Cc: Anil S Keshavamurthy Cc: David S. Miller Cc: Linus Torvalds Cc: Naveen N. Rao Cc: Peter Zijlstra Cc: Thomas Gleixner Fixes: d5b844a2cf50 ("ftrace/x86: Remove possible deadlock between register_kprobe() and ftrace_run_update_code()") Link: http://lkml.kernel.org/r/20190812184302.GA7010@xps-13 Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 9ad89d579c01cc6449d4fc503f00914caa4bcc7e Author: Sebastian Andrzej Siewior Date: Fri Aug 16 18:06:26 2019 +0200 sched/core: Schedule new worker even if PI-blocked [ Upstream commit b0fdc01354f45d43f082025636ef808968a27b36 ] If a task is PI-blocked (blocking on sleeping spinlock) then we don't want to schedule a new kworker if we schedule out due to lock contention because !RT does not do that as well. A spinning spinlock disables preemption and a worker does not schedule out on lock contention (but spin). On RT the RW-semaphore implementation uses an rtmutex so tsk_is_pi_blocked() will return true if a task blocks on it. In this case we will now start a new worker which may deadlock if one worker is waiting on progress from another worker. Since a RW-semaphore starts a new worker on !RT, we should do the same on RT. XFS is able to trigger this deadlock. Allow to schedule new worker if the current worker is PI-blocked. Signed-off-by: Sebastian Andrzej Siewior Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/20190816160626.12742-1-bigeasy@linutronix.de Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 086ddc5e71721ce385382e926b8112148c2ad58a Author: Tho Vu Date: Fri Aug 16 17:17:02 2019 +0200 ravb: Fix use-after-free ravb_tstamp_skb [ Upstream commit cfef46d692efd852a0da6803f920cc756eea2855 ] When a Tx timestamp is requested, a pointer to the skb is stored in the ravb_tstamp_skb struct. This was done without an skb_get. There exists the possibility that the skb could be freed by ravb_tx_free (when ravb_tx_free is called from ravb_start_xmit) before the timestamp was processed, leading to a use-after-free bug. Use skb_get when filling a ravb_tstamp_skb struct, and add appropriate frees/consumes when a ravb_tstamp_skb struct is freed. Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper") Signed-off-by: Tho Vu Signed-off-by: Kazuya Mizuguchi Signed-off-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 37f12b89544605b6a4683b58b22bbc2e630735fa Author: Wenwen Wang Date: Thu Aug 15 15:29:51 2019 -0500 wimax/i2400m: fix a memory leak bug [ Upstream commit 44ef3a03252844a8753479b0cea7f29e4a804bdc ] In i2400m_barker_db_init(), 'options_orig' is allocated through kstrdup() to hold the original command line options. Then, the options are parsed. However, if an error occurs during the parsing process, 'options_orig' is not deallocated, leading to a memory leak bug. To fix this issue, free 'options_orig' before returning the error. Signed-off-by: Wenwen Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 461f5b613b4d3d890eb83f6773d93298220d3a43 Author: Stephen Hemminger Date: Thu Aug 15 12:49:49 2019 -0700 net: cavium: fix driver name [ Upstream commit 3434341004a380f4e47c3a03d4320d43982162a0 ] The driver name gets exposed in sysfs under /sys/bus/pci/drivers so it should look like other devices. Change it to be common format (instead of "Cavium PTP"). This is a trivial fix that was observed by accident because Debian kernels were building this driver into kernel (bug). Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1915dd1826be7a7f538945b87b655629272fc9ef Author: Thomas Falcon Date: Wed Aug 14 14:57:05 2019 -0500 ibmvnic: Unmap DMA address of TX descriptor buffers after use [ Upstream commit 80f0fe0934cd3daa13a5e4d48a103f469115b160 ] There's no need to wait until a completion is received to unmap TX descriptor buffers that have been passed to the hypervisor. Instead unmap it when the hypervisor call has completed. This patch avoids the possibility that a buffer will not be unmapped because a TX completion is lost or mishandled. Reported-by: Abdul Haleem Tested-by: Devesh K. Singh Signed-off-by: Thomas Falcon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 895a07a5a03abb77a226cf6e311895ea22d9e62b Author: Wenwen Wang Date: Wed Aug 14 13:56:43 2019 -0500 net: kalmia: fix memory leaks [ Upstream commit f1472cb09f11ddb41d4be84f0650835cb65a9073 ] In kalmia_init_and_get_ethernet_addr(), 'usb_buf' is allocated through kmalloc(). In the following execution, if the 'status' returned by kalmia_send_init_packet() is not 0, 'usb_buf' is not deallocated, leading to memory leaks. To fix this issue, add the 'out' label to free 'usb_buf'. Signed-off-by: Wenwen Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 241a735f5f68c9d909d72ac062a18c64945e3f40 Author: Wenwen Wang Date: Wed Aug 14 13:03:38 2019 -0500 cx82310_eth: fix a memory leak bug [ Upstream commit 1eca92eef18719027d394bf1a2d276f43e7cf886 ] In cx82310_bind(), 'dev->partial_data' is allocated through kmalloc(). Then, the execution waits for the firmware to become ready. If the firmware is not ready in time, the execution is terminated. However, the allocated 'dev->partial_data' is not deallocated on this path, leading to a memory leak bug. To fix this issue, free 'dev->partial_data' before returning the error. Signed-off-by: Wenwen Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e8f8411a8deffc743abc7a322b4289acb78ac13d Author: Darrick J. Wong Date: Sun Aug 11 15:52:25 2019 -0700 vfs: fix page locking deadlocks when deduping files [ Upstream commit edc58dd0123b552453a74369bd0c8d890b497b4b ] When dedupe wants to use the page cache to compare parts of two files for dedupe, we must be very careful to handle locking correctly. The current code doesn't do this. It must lock and unlock the page only once if the two pages are the same, since the overlapping range check doesn't catch this when blocksize < pagesize. If the pages are distinct but from the same file, we must observe page locking order and lock them in order of increasing offset to avoid clashing with writeback locking. Fixes: 876bec6f9bbfcb3 ("vfs: refactor clone/dedupe_file_range common functions") Signed-off-by: Darrick J. Wong Reviewed-by: Bill O'Donnell Reviewed-by: Matthew Wilcox (Oracle) Signed-off-by: Sasha Levin commit a4234e27ed053eee92c83bd91cf10adb8bab2154 Author: Wenwen Wang Date: Wed Aug 14 11:23:13 2019 -0500 lan78xx: Fix memory leaks [ Upstream commit b9cbf8a64865b50fd0f4a3915fa00ac7365cdf8f ] In lan78xx_probe(), a new urb is allocated through usb_alloc_urb() and saved to 'dev->urb_intr'. However, in the following execution, if an error occurs, 'dev->urb_intr' is not deallocated, leading to memory leaks. To fix this issue, invoke usb_free_urb() to free the allocated urb before returning from the function. Signed-off-by: Wenwen Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 96ece5798677ae26b3a1c9d315b6ccd9836e1287 Author: Martin Blumenstingl Date: Fri Aug 16 00:31:55 2019 +0200 clk: Fix potential NULL dereference in clk_fetch_parent_index() [ Upstream commit 24876f09a7dfe36a82f53d304d8c1bceb3257a0f ] Don't compare the parent clock name with a NULL name in the clk_parent_map. This prevents a kernel crash when passing NULL core->parents[i].name to strcmp(). An example which triggered this is a mux clock with four parents when each of them is referenced in the clock driver using clk_parent_data.fw_name and then calling clk_set_parent(clk, 3rd_parent) on this mux. In this case the first parent is also the HW default so core->parents[i].hw is populated when the clock is registered. Calling clk_set_parent(clk, 3rd_parent) will then go through all parents and skip the first parent because it's hw pointer doesn't match. For the second parent no hw pointer is cached yet and clk_core_get(core, 1) returns a non-matching pointer (which is correct because we are comparing the second with the third parent). Comparing the result of clk_core_get(core, 2) with the requested parent gives a match. However we don't reach this point because right after the clk_core_get(core, 1) mismatch the old code tried to !strcmp(parent->name, NULL) (where the second argument is actually core->parents[i].name, but that was never populated by the clock driver). Signed-off-by: Martin Blumenstingl Link: https://lkml.kernel.org/r/20190815223155.21384-1-martin.blumenstingl@googlemail.com Fixes: fc0c209c147f ("clk: Allow parents to be specified without string names") Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit a6cb8dd3664ee3fec0626e74fdf0291fce00f9c8 Author: Stephen Boyd Date: Tue Aug 13 14:41:47 2019 -0700 clk: Fix falling back to legacy parent string matching [ Upstream commit 4f8c6aba37da199155a121c6cdc38505a9eb0259 ] Calls to clk_core_get() will return ERR_PTR(-EINVAL) if we've started migrating a clk driver to use the DT based style of specifying parents but we haven't made any DT updates yet. This happens when we pass a non-NULL value as the 'name' argument of of_parse_clkspec(). That function returns -EINVAL in such a situation, instead of -ENOENT like we expected. The return value comes back up to clk_core_fill_parent_index() which proceeds to skip calling clk_core_lookup() because the error pointer isn't equal to -ENOENT, it's -EINVAL. Furthermore, we blindly overwrite the error pointer returned by clk_core_get() with NULL when there isn't a legacy .name member specified in the parent map. This isn't too bad right now because we don't really care to differentiate NULL from an error, but in the future we should only try to do a legacy lookup if we know we might find something. This way DT lookups that fail don't try to lookup based on strings when there isn't any string to match, hiding the error from DT parsing. Fix both these problems so that clk provider drivers can use the new style of parent mapping without having to also update their DT at the same time. This patch is based on an earlier patch from Taniya Das which checked for -EINVAL in addition to -ENOENT return values from clk_core_get(). Fixes: 601b6e93304a ("clk: Allow parents to be specified via clkspec index") Cc: Taniya Das Cc: Jerome Brunet Cc: Chen-Yu Tsai Reported-by: Taniya Das Signed-off-by: Stephen Boyd Link: https://lkml.kernel.org/r/20190813214147.34394-1-sboyd@kernel.org Tested-by: Taniya Das Signed-off-by: Sasha Levin commit 7da16490e5a5dc596ae17062f93fe273c86e556d Author: Wenwen Wang Date: Wed Aug 14 01:38:39 2019 -0500 net: myri10ge: fix memory leaks [ Upstream commit 20fb7c7a39b5c719e2e619673b5f5729ee7d2306 ] In myri10ge_probe(), myri10ge_alloc_slices() is invoked to allocate slices related structures. Later on, myri10ge_request_irq() is used to get an irq. However, if this process fails, the allocated slices related structures are not deallocated, leading to memory leaks. To fix this issue, revise the target label of the goto statement to 'abort_with_slices'. Signed-off-by: Wenwen Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0f1c537cf09c687b57c15ce5e9309b7103592a38 Author: Wenwen Wang Date: Wed Aug 14 00:14:49 2019 -0500 liquidio: add cleanup in octeon_setup_iq() [ Upstream commit 6f967f8b1be7001b31c46429f2ee7d275af2190f ] If oct->fn_list.enable_io_queues() fails, no cleanup is executed, leading to memory/resource leaks. To fix this issue, invoke octeon_delete_instr_queue() before returning from the function. Signed-off-by: Wenwen Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 101743ca02841cc0784006af32c2b3ee6bffffae Author: Paolo Bonzini Date: Wed Aug 14 12:07:34 2019 -0400 selftests: kvm: fix vmx_set_nested_state_test [ Upstream commit c930e19790bbbff31c018009907c813fa0925f63 ] vmx_set_nested_state_test is trying to use the KVM_STATE_NESTED_EVMCS without enabling enlightened VMCS first. Correct the outcome of the test, and actually test that it succeeds after the capability is enabled. Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 5aac82ac9c7c073b0f165d5cfabb85239add642f Author: Paolo Bonzini Date: Wed Aug 14 12:02:41 2019 -0400 selftests: kvm: provide common function to enable eVMCS [ Upstream commit 65efa61dc0d536d5f0602c33ee805a57cc07e9dc ] There are two tests already enabling eVMCS and a third is coming. Add a function that enables the capability and tests the result. Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 926a6e9efce95977f31699249ec1d89e0460c6ff Author: Paolo Bonzini Date: Wed Aug 14 18:18:55 2019 +0200 selftests: kvm: do not try running the VM in vmx_set_nested_state_test [ Upstream commit 92cd0f0be3d7adb63611c28693ec0399beded837 ] This test is only covering various edge cases of the KVM_SET_NESTED_STATE ioctl. Running the VM does not really add anything. Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit bf31a46ead594390566032fae80fd1f66485bd68 Author: Wenwen Wang Date: Tue Aug 13 04:18:52 2019 -0500 cxgb4: fix a memory leak bug [ Upstream commit c554336efa9bbc28d6ec14efbee3c7d63c61a34f ] In blocked_fl_write(), 't' is not deallocated if bitmap_parse_user() fails, leading to a memory leak bug. To fix this issue, free t before returning the error. Signed-off-by: Wenwen Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 46bf670f44551801f36733d275a3c9bb5c9a03f5 Author: Dmitry Fomichev Date: Sun Aug 11 11:25:10 2019 -0700 scsi: target: tcmu: avoid use-after-free after command timeout [ Upstream commit a86a75865ff4d8c05f355d1750a5250aec89ab15 ] In tcmu_handle_completion() function, the variable called read_len is always initialized with a value taken from se_cmd structure. If this function is called to complete an expired (timed out) out command, the session command pointed by se_cmd is likely to be already deallocated by the target core at that moment. As the result, this access triggers a use-after-free warning from KASAN. This patch fixes the code not to touch se_cmd when completing timed out TCMU commands. It also resets the pointer to se_cmd at the time when the TCMU_CMD_BIT_EXPIRED flag is set because it is going to become invalid after calling target_complete_cmd() later in the same function, tcmu_check_expired_cmd(). Signed-off-by: Dmitry Fomichev Acked-by: Mike Christie Reviewed-by: Damien Le Moal Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 8e639df33729149bbb50caf152ef55d2f25962c3 Author: Bill Kuzeja Date: Wed Aug 14 10:24:41 2019 -0400 scsi: qla2xxx: Fix gnl.l memory leak on adapter init failure [ Upstream commit 26fa656e9a0cbccddf7db132ea020d2169dbe46e ] If HBA initialization fails unexpectedly (exiting via probe_failed:), we may fail to free vha->gnl.l. So that we don't attempt to double free, set this pointer to NULL after a free and check for NULL at probe_failed: so we know whether or not to call dma_free_coherent. Signed-off-by: Bill Kuzeja Acked-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 6fe444e60cdabe814876a4599e5bd8c2472c1108 Author: Alexandre Courbot Date: Mon Jul 29 14:33:35 2019 +0900 drm/mediatek: set DMA max segment size [ Upstream commit 070955558e820b9a89c570b91b1f21762f62b288 ] This driver requires imported PRIME buffers to appear contiguously in its IO address space. Make sure this is the case by setting the maximum DMA segment size to a more suitable value than the default 64KB. Signed-off-by: Alexandre Courbot Reviewed-by: Tomasz Figa Signed-off-by: CK Hu Signed-off-by: Sasha Levin commit 1e12afb4c60a4b99904326fceca47aef8dfdf8c0 Author: Alexandre Courbot Date: Mon Jul 29 14:33:34 2019 +0900 drm/mediatek: use correct device to import PRIME buffers [ Upstream commit 4c6f3196e6ea111c456c6086dc3f57d4706b0b2d ] PRIME buffers should be imported using the DMA device. To this end, use a custom import function that mimics drm_gem_prime_import_dev(), but passes the correct device. Fixes: 119f5173628aa ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Signed-off-by: Alexandre Courbot Signed-off-by: CK Hu Signed-off-by: Sasha Levin commit 2b4a29f0453394ab1870674feca29559badeceed Author: Pablo Neira Ayuso Date: Tue Aug 13 17:41:13 2019 +0200 netfilter: nft_flow_offload: skip tcp rst and fin packets [ Upstream commit dfe42be15fde16232340b8b2a57c359f51cc10d9 ] TCP rst and fin packets do not qualify to place a flow into the flowtable. Most likely there will be no more packets after connection closure. Without this patch, this flow entry expires and connection tracking picks up the entry in ESTABLISHED state using the fixup timeout, which makes this look inconsistent to the user for a connection that is actually already closed. Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 1dcb0d4eaf85e9c2173b21c3f23a2e9ef324ecd7 Author: YueHaibing Date: Wed Jul 31 20:38:14 2019 +0800 gpio: Fix build error of function redefinition [ Upstream commit 68e03b85474a51ec1921b4d13204782594ef7223 ] when do randbuilding, I got this error: In file included from drivers/hwmon/pmbus/ucd9000.c:19:0: ./include/linux/gpio/driver.h:576:1: error: redefinition of gpiochip_add_pin_range gpiochip_add_pin_range(struct gpio_chip *chip, const char *pinctl_name, ^~~~~~~~~~~~~~~~~~~~~~ In file included from drivers/hwmon/pmbus/ucd9000.c:18:0: ./include/linux/gpio.h:245:1: note: previous definition of gpiochip_add_pin_range was here gpiochip_add_pin_range(struct gpio_chip *chip, const char *pinctl_name, ^~~~~~~~~~~~~~~~~~~~~~ Reported-by: Hulk Robot Fixes: 964cb341882f ("gpio: move pincontrol calls to ") Signed-off-by: YueHaibing Link: https://lore.kernel.org/r/20190731123814.46624-1-yuehaibing@huawei.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit f6bd80bc62231a281b757059f8a7b1d8663d586a Author: Thomas Falcon Date: Mon Aug 12 16:13:06 2019 -0500 ibmveth: Convert multicast list size for little-endian system [ Upstream commit 66cf4710b23ab2adda11155684a2c8826f4fe732 ] The ibm,mac-address-filters property defines the maximum number of addresses the hypervisor's multicast filter list can support. It is encoded as a big-endian integer in the OF device tree, but the virtual ethernet driver does not convert it for use by little-endian systems. As a result, the driver is not behaving as it should on affected systems when a large number of multicast addresses are assigned to the device. Reported-by: Hangbin Liu Signed-off-by: Thomas Falcon Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d45c33d890bc2fbe5485c2b0e964485e86dd4f66 Author: Julian Wiedmann Date: Mon Aug 12 16:44:35 2019 +0200 s390/qeth: serialize cmd reply with concurrent timeout [ Upstream commit 072f79400032f74917726cf76f4248367ea2b5b8 ] Callbacks for a cmd reply run outside the protection of card->lock, to allow for additional cmds to be issued & enqueued in parallel. When qeth_send_control_data() bails out for a cmd without having received a reply (eg. due to timeout), its callback may concurrently be processing a reply that just arrived. In this case, the callback potentially accesses a stale reply->reply_param area that eg. was on-stack and has already been released. To avoid this race, add some locking so that qeth_send_control_data() can (1) wait for a concurrently running callback, and (2) zap any pending callback that still wants to run. Signed-off-by: Julian Wiedmann Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b12691c24ea93a10ee66c457b9ca786b193e1777 Author: Harish Bandi Date: Fri Jul 12 10:39:40 2019 +0530 Bluetooth: hci_qca: Send VS pre shutdown command. [ Upstream commit a2780889e247561744dd8efbd3478a1999b72ae3 ] WCN399x chips are coex chips, it needs a VS pre shutdown command while turning off the BT. So that chip can inform BT is OFF to other active clients. Signed-off-by: Harish Bandi Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 113d5ca748661634a7ce02773a1e5dc552d8c62f Author: Matthias Kaehlcke Date: Tue Jul 9 15:44:50 2019 -0700 Bluetooth: btqca: Add a short delay before downloading the NVM [ Upstream commit 8059ba0bd0e4694e51c2ee6438a77b325f06c0d5 ] On WCN3990 downloading the NVM sometimes fails with a "TLV response size mismatch" error: [ 174.949955] Bluetooth: btqca.c:qca_download_firmware() hci0: QCA Downloading qca/crnv21.bin [ 174.958718] Bluetooth: btqca.c:qca_tlv_send_segment() hci0: QCA TLV response size mismatch It seems the controller needs a short time after downloading the firmware before it is ready for the NVM. A delay as short as 1 ms seems sufficient, make it 10 ms just in case. No event is received during the delay, hence we don't just silently drop an extra event. Signed-off-by: Matthias Kaehlcke Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit ab0f749707eadafe0b8ad9e3efb53f4aaf956599 Author: Nathan Chancellor Date: Sun Aug 11 20:13:45 2019 -0700 net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx [ Upstream commit 125b7e0949d4e72b15c2b1a1590f8cece985a918 ] clang warns: drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical '&&' with constant operand [-Wconstant-logical-operand] if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN) ^ ~~~~~~~~~~~~ drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a bitwise operation if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN) ^~ & drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to silence this warning if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN) ~^~~~~~~~~~~~~~~ 1 warning generated. Explicitly check that NET_IP_ALIGN is not zero, which matches how this is checked in other parts of the tree. Because NET_IP_ALIGN is a build time constant, this check will be constant folded away during optimization. Fixes: 82a9928db560 ("tc35815: Enable StripCRC feature") Link: https://github.com/ClangBuiltLinux/linux/issues/608 Signed-off-by: Nathan Chancellor Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 37a0be861375c41d31c2579e4a223738f8f26be7 Author: Dexuan Cui Date: Fri Aug 9 01:58:08 2019 +0000 hv_netvsc: Fix a warning of suspicious RCU usage [ Upstream commit 6d0d779dca73cd5acb649c54f81401f93098b298 ] This fixes a warning of "suspicious rcu_dereference_check() usage" when nload runs. Fixes: 776e726bfb34 ("netvsc: fix RCU warning in get_stats") Signed-off-by: Dexuan Cui Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 936315c0c94e2659ad48899e11da83c33f58bfe0 Author: Taehee Yoo Date: Thu Aug 8 09:37:56 2019 -0700 ixgbe: fix possible deadlock in ixgbe_service_task() [ Upstream commit 8b6381600d59871fbe44d36522272f961ab42410 ] ixgbe_service_task() calls unregister_netdev() under rtnl_lock(). But unregister_netdev() internally calls rtnl_lock(). So deadlock would occur. Fixes: 59dd45d550c5 ("ixgbe: firmware recovery mode") Signed-off-by: Taehee Yoo Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1dc961de773378a22be8d36f24e777d371921d43 Author: Jakub Kicinski Date: Tue Aug 6 17:19:22 2019 -0700 tools: bpftool: fix error message (prog -> object) [ Upstream commit b3e78adcbf991a4e8b2ebb23c9889e968ec76c5f ] Change an error message to work for any object being pinned not just programs. Fixes: 71bb428fe2c1 ("tools: bpf: add bpftool") Signed-off-by: Jakub Kicinski Reviewed-by: Quentin Monnet Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin commit ea3c243ce799eefc93a81f866f941e34a156d5c3 Author: Pablo Neira Ayuso Date: Fri Aug 9 11:01:35 2019 +0200 netfilter: nf_flow_table: teardown flow timeout race [ Upstream commit 1e5b2471bcc4838df298080ae1ec042c2cbc9ce9 ] Flows that are in teardown state (due to RST / FIN TCP packet) still have their offload flag set on. Hence, the conntrack garbage collector may race to undo the timeout adjustment that the fixup routine performs, leaving the conntrack entry in place with the internal offload timeout (one day). Update teardown flow state to ESTABLISHED and set tracking to liberal, then once the offload bit is cleared, adjust timeout if it is more than the default fixup timeout (conntrack might already have set a lower timeout from the packet path). Fixes: da5984e51063 ("netfilter: nf_flow_table: add support for sending flows back to the slow path") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 96a517d0ba5f6251e0602047348f1a073f2044c1 Author: Pablo Neira Ayuso Date: Fri Aug 9 11:01:33 2019 +0200 netfilter: nf_flow_table: conntrack picks up expired flows [ Upstream commit 3e68db2f6422d711550a32cbc87abd97bb6efab3 ] Update conntrack entry to pick up expired flows, otherwise the conntrack entry gets stuck with the internal offload timeout (one day). The TCP state also needs to be adjusted to ESTABLISHED state and tracking is set to liberal mode in order to give conntrack a chance to pick up the expired flow. Fixes: ac2a66665e23 ("netfilter: add generic flow table infrastructure") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 586f00143091aeaea0905bb02dd37da22b801f22 Author: Pablo Neira Ayuso Date: Fri Aug 9 11:01:27 2019 +0200 netfilter: nf_tables: use-after-free in failing rule with bound set [ Upstream commit 6a0a8d10a3661a036b55af695542a714c429ab7c ] If a rule that has already a bound anonymous set fails to be added, the preparation phase releases the rule and the bound set. However, the transaction object from the abort path still has a reference to the set object that is stale, leading to a use-after-free when checking for the set->bound field. Add a new field to the transaction that specifies if the set is bound, so the abort path can skip releasing it since the rule command owns it and it takes care of releasing it. After this update, the set->bound field is removed. [ 24.649883] Unable to handle kernel paging request at virtual address 0000000000040434 [ 24.657858] Mem abort info: [ 24.660686] ESR = 0x96000004 [ 24.663769] Exception class = DABT (current EL), IL = 32 bits [ 24.669725] SET = 0, FnV = 0 [ 24.672804] EA = 0, S1PTW = 0 [ 24.675975] Data abort info: [ 24.678880] ISV = 0, ISS = 0x00000004 [ 24.682743] CM = 0, WnR = 0 [ 24.685723] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000428952000 [ 24.692207] [0000000000040434] pgd=0000000000000000 [ 24.697119] Internal error: Oops: 96000004 [#1] SMP [...] [ 24.889414] Call trace: [ 24.891870] __nf_tables_abort+0x3f0/0x7a0 [ 24.895984] nf_tables_abort+0x20/0x40 [ 24.899750] nfnetlink_rcv_batch+0x17c/0x588 [ 24.904037] nfnetlink_rcv+0x13c/0x190 [ 24.907803] netlink_unicast+0x18c/0x208 [ 24.911742] netlink_sendmsg+0x1b0/0x350 [ 24.915682] sock_sendmsg+0x4c/0x68 [ 24.919185] ___sys_sendmsg+0x288/0x2c8 [ 24.923037] __sys_sendmsg+0x7c/0xd0 [ 24.926628] __arm64_sys_sendmsg+0x2c/0x38 [ 24.930744] el0_svc_common.constprop.0+0x94/0x158 [ 24.935556] el0_svc_handler+0x34/0x90 [ 24.939322] el0_svc+0x8/0xc [ 24.942216] Code: 37280300 f9404023 91014262 aa1703e0 (f9401863) [ 24.948336] ---[ end trace cebbb9dcbed3b56f ]--- Fixes: f6ac85858976 ("netfilter: nf_tables: unbind set in rule from commit path") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 830b5c3760ff05a78c60202a7cff1d067cb25577 Author: Fuqian Huang Date: Fri Aug 9 13:35:39 2019 +0800 net: tundra: tsi108: use spin_lock_irqsave instead of spin_lock_irq in IRQ context [ Upstream commit 8c25d0887a8bd0e1ca2074ac0c6dff173787a83b ] As spin_unlock_irq will enable interrupts. Function tsi108_stat_carry is called from interrupt handler tsi108_irq. Interrupts are enabled in interrupt handler. Use spin_lock_irqsave/spin_unlock_irqrestore instead of spin_(un)lock_irq in IRQ context to avoid this. Signed-off-by: Fuqian Huang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 60a4f2b2b6b85b4638766a87a3822f3216005048 Author: Marek Szyprowski Date: Thu Aug 8 14:18:39 2019 +0200 clk: samsung: exynos542x: Move MSCL subsystem clocks to its sub-CMU [ Upstream commit baf7b79e1ad79a41fafd8ab8597b9a96962d822d ] M2M scaler clocks require special handling of their parent bus clock during power domain on/off sequences. MSCL clocks were not initially added to the sub-CMU handler, because that time there was no driver for the M2M scaler device and it was not possible to test it. This patch fixes this issue. Parent clock for M2M scaler devices is now properly preserved during MSC power domain on/off sequence. This gives M2M scaler devices proper performance: fullHD XRGB32 image 1000 rotations test takes 3.17s instead of 45.08s. Fixes: b06a532bf1fa ("clk: samsung: Add Exynos5 sub-CMU clock driver") Signed-off-by: Marek Szyprowski Link: https://lkml.kernel.org/r/20190808121839.23892-1-m.szyprowski@samsung.com Acked-by: Sylwester Nawrocki Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit c65a2b20a934fcdc95b875077062d5da4261796f Author: Sylwester Nawrocki Date: Thu Aug 8 16:49:29 2019 +0200 clk: samsung: exynos5800: Move MAU subsystem clocks to MAU sub-CMU [ Upstream commit b6adeb6bc61c2567b9efd815d61a61b34a2e51a6 ] This patch fixes broken sound on Exynos5422/5800 platforms after system/suspend resume cycle in cases where the audio root clock is derived from MAU_EPLL_CLK. In order to preserve state of the USER_MUX_MAU_EPLL_CLK clock mux during system suspend/resume cycle for Exynos5800 we group the MAU block input clocks in "MAU" sub-CMU and add the clock mux control bit to .suspend_regs. This ensures that user configuration of the mux is not lost after the PMU block changes the mux setting to OSC_DIV when switching off the MAU power domain. Adding the SRC_TOP9 register to exynos5800_clk_regs[] array is not sufficient as at the time of the syscore_ops suspend call MAU power domain is already turned off and we already save and subsequently restore an incorrect register's value. Fixes: b06a532bf1fa ("clk: samsung: Add Exynos5 sub-CMU clock driver") Reported-by: Jaafar Ali Suggested-by: Marek Szyprowski Tested-by: Jaafar Ali Signed-off-by: Sylwester Nawrocki Link: https://lkml.kernel.org/r/20190808144929.18685-2-s.nawrocki@samsung.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit f7bd5e9fe13f5504d5ddcfc771a16bccefd19ee1 Author: Sylwester Nawrocki Date: Thu Aug 8 16:49:28 2019 +0200 clk: samsung: Change signature of exynos5_subcmus_init() function [ Upstream commit bf32e7dbfce87d518c0ca77af890eae9ab8d6ab9 ] In order to make it easier in subsequent patch to create different subcmu lists for exynos5420 and exynos5800 SoCs the code is rewritten so we pass an array of pointers to the subcmus initialization function. Fixes: b06a532bf1fa ("clk: samsung: Add Exynos5 sub-CMU clock driver") Tested-by: Jaafar Ali Signed-off-by: Sylwester Nawrocki Link: https://lkml.kernel.org/r/20190808144929.18685-1-s.nawrocki@samsung.com Reviewed-by: Marek Szyprowski Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 8f37477964e920c90392965a90f3a9ddebe0b7e0 Author: Aya Levin Date: Tue Aug 6 15:19:19 2019 +0300 net/mlx5e: Fix error flow of CQE recovery on tx reporter [ Upstream commit 276d197e70bcc47153592f4384675b51c7d83aba ] CQE recovery function begins with test and set of recovery bit. Add an error flow which ensures clearing of this bit when leaving the recovery function, to allow further recoveries to take place. This allows removal of clearing recovery bit on sq activate. Fixes: de8650a82071 ("net/mlx5e: Add tx reporter support") Signed-off-by: Aya Levin Reviewed-by: Tariq Toukan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 701b89908ba1cf65929dee667a982b325fc2d372 Author: Florian Westphal Date: Tue Jul 30 14:57:19 2019 +0200 netfilter: nf_flow_table: fix offload for flows that are subject to xfrm [ Upstream commit 589b474a4b7ce409d6821ef17234a995841bd131 ] This makes the previously added 'encap test' pass. Because its possible that the xfrm dst entry becomes stale while such a flow is offloaded, we need to call dst_check() -- the notifier that handles this for non-tunneled traffic isn't sufficient, because SA or or policies might have changed. If dst becomes stale the flow offload entry will be tagged for teardown and packets will be passed to 'classic' forwarding path. Removing the entry right away is problematic, as this would introduce a race condition with the gc worker. In case flow is long-lived, it could eventually be offloaded again once the gc worker removes the entry from the flow table. Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit b8a132a4c4b6e97c8f157623167c8d5a5b75c1ab Author: Andrii Nakryiko Date: Thu Aug 1 00:24:05 2019 -0700 libbpf: set BTF FD for prog only when there is supported .BTF.ext data [ Upstream commit 3415ec643e7bd644b03026efbe2f2b36cbe9b34b ] 5d01ab7bac46 ("libbpf: fix erroneous multi-closing of BTF FD") introduced backwards-compatibility issue, manifesting itself as -E2BIG error returned on program load due to unknown non-zero btf_fd attribute value for BPF_PROG_LOAD sys_bpf() sub-command. This patch fixes bug by ensuring that we only ever associate BTF FD with program if there is a BTF.ext data that was successfully loaded into kernel, which automatically means kernel supports func_info/line_info and associated BTF FD for progs (checked and ensured also by BTF sanitization code). Fixes: 5d01ab7bac46 ("libbpf: fix erroneous multi-closing of BTF FD") Reported-by: Andrey Ignatov Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit a65fb2895af4a11b2ca0457926ae24c5feeaab6b Author: Andrii Nakryiko Date: Fri Jul 26 14:24:38 2019 -0700 libbpf: fix erroneous multi-closing of BTF FD [ Upstream commit 5d01ab7bac467edfc530e6ccf953921def935c62 ] Libbpf stores associated BTF FD per each instance of bpf_program. When program is unloaded, that FD is closed. This is wrong, because leads to a race and possibly closing of unrelated files, if application simultaneously opens new files while bpf_programs are unloaded. It's also unnecessary, because struct btf "owns" that FD, and btf__free(), called from bpf_object__close() will close it. Thus the fix is to never have per-program BTF FD and fetch it from obj->btf, when necessary. Fixes: 2993e0515bb4 ("tools/bpf: add support to read .BTF.ext sections") Reported-by: Andrey Ignatov Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit fa689968da499a6094228d9409e1cf100290de8a Author: Sven Eckelmann Date: Sun Jul 7 22:15:13 2019 +0200 batman-adv: Fix netlink dumping of all mcast_flags buckets [ Upstream commit fa3a03da549a889fc9dbc0d3c5908eb7882cac8f ] The bucket variable is only updated outside the loop over the mcast_flags buckets. It will only be updated during a dumping run when the dumping has to be interrupted and a new message has to be started. This could result in repeated or missing entries when the multicast flags are dumped to userspace. Fixes: d2d489b7d851 ("batman-adv: Add inconsistent multicast netlink dump detection") Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Sasha Levin commit a4c88340b3ea8caefa1b5d3422bd9925c74b566e Author: Ka-Cheong Poon Date: Mon Aug 26 02:39:12 2019 -0700 net/rds: Fix info leak in rds6_inc_info_copy() [ Upstream commit 7d0a06586b2686ba80c4a2da5f91cb10ffbea736 ] The rds6_inc_info_copy() function has a couple struct members which are leaking stack information. The ->tos field should hold actual information and the ->flags field needs to be zeroed out. Fixes: 3eb450367d08 ("rds: add type of service(tos) infrastructure") Fixes: b7ff8b1036f0 ("rds: Extend RDS API for IPv6 support") Reported-by: 黄ID蝴蝶 Signed-off-by: Dan Carpenter Signed-off-by: Ka-Cheong Poon Acked-by: Santosh Shilimkar Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fdd2bc365fc6ea577db40f7f6566e6f3cdea0181 Author: Davide Caratti Date: Tue Aug 27 12:29:09 2019 +0200 net/sched: pfifo_fast: fix wrong dereference when qdisc is reset [ Upstream commit 04d37cf46a773910f75fefaa9f9488f42bfe1fe2 ] Now that 'TCQ_F_CPUSTATS' bit can be cleared, depending on the value of 'TCQ_F_NOLOCK' bit in the parent qdisc, we need to be sure that per-cpu counters are present when 'reset()' is called for pfifo_fast qdiscs. Otherwise, the following script: # tc q a dev lo handle 1: root htb default 100 # tc c a dev lo parent 1: classid 1:100 htb \ > rate 95Mbit ceil 100Mbit burst 64k [...] # tc f a dev lo parent 1: protocol arp basic classid 1:100 [...] # tc q a dev lo parent 1:100 handle 100: pfifo_fast [...] # tc q d dev lo root can generate the following splat: Unable to handle kernel paging request at virtual address dfff2c01bd148000 Mem abort info: ESR = 0x96000004 Exception class = DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 [dfff2c01bd148000] address between user and kernel address ranges Internal error: Oops: 96000004 [#1] SMP [...] pstate: 80000005 (Nzcv daif -PAN -UAO) pc : pfifo_fast_reset+0x280/0x4d8 lr : pfifo_fast_reset+0x21c/0x4d8 sp : ffff800d09676fa0 x29: ffff800d09676fa0 x28: ffff200012ee22e4 x27: dfff200000000000 x26: 0000000000000000 x25: ffff800ca0799958 x24: ffff1001940f332b x23: 0000000000000007 x22: ffff200012ee1ab8 x21: 0000600de8a40000 x20: 0000000000000000 x19: ffff800ca0799900 x18: 0000000000000000 x17: 0000000000000002 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: ffff1001b922e6e2 x11: 1ffff001b922e6e1 x10: 0000000000000000 x9 : 1ffff001b922e6e1 x8 : dfff200000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 1fffe400025dc45c x4 : 1fffe400025dc357 x3 : 00000c01bd148000 x2 : 0000600de8a40000 x1 : 0000000000000007 x0 : 0000600de8a40004 Call trace: pfifo_fast_reset+0x280/0x4d8 qdisc_reset+0x6c/0x370 htb_reset+0x150/0x3b8 [sch_htb] qdisc_reset+0x6c/0x370 dev_deactivate_queue.constprop.5+0xe0/0x1a8 dev_deactivate_many+0xd8/0x908 dev_deactivate+0xe4/0x190 qdisc_graft+0x88c/0xbd0 tc_get_qdisc+0x418/0x8a8 rtnetlink_rcv_msg+0x3a8/0xa78 netlink_rcv_skb+0x18c/0x328 rtnetlink_rcv+0x28/0x38 netlink_unicast+0x3c4/0x538 netlink_sendmsg+0x538/0x9a0 sock_sendmsg+0xac/0xf8 ___sys_sendmsg+0x53c/0x658 __sys_sendmsg+0xc8/0x140 __arm64_sys_sendmsg+0x74/0xa8 el0_svc_handler+0x164/0x468 el0_svc+0x10/0x14 Code: 910012a0 92400801 d343fc03 11000c21 (38fb6863) Fix this by testing the value of 'TCQ_F_CPUSTATS' bit in 'qdisc->flags', before dereferencing 'qdisc->cpu_qstats'. Changes since v1: - coding style improvements, thanks to Stefano Brivio Fixes: 8a53e616de29 ("net: sched: when clearing NOLOCK, clear TCQ_F_CPUSTATS, too") CC: Paolo Abeni Reported-by: Li Shuang Signed-off-by: Davide Caratti Acked-by: Paolo Abeni Reviewed-by: Stefano Brivio Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e9cc0513248f7ab4e4ab099fbde3bd9e5d262fa2 Author: Davide Caratti Date: Tue Aug 27 23:18:53 2019 +0200 net/sched: pfifo_fast: fix wrong dereference in pfifo_fast_enqueue [ Upstream commit 092e22e586236bba106a82113826a68080a03506 ] Now that 'TCQ_F_CPUSTATS' bit can be cleared, depending on the value of 'TCQ_F_NOLOCK' bit in the parent qdisc, we can't assume anymore that per-cpu counters are there in the error path of skb_array_produce(). Otherwise, the following splat can be seen: Unable to handle kernel paging request at virtual address 0000600dea430008 Mem abort info: ESR = 0x96000005 Exception class = DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000005 CM = 0, WnR = 0 user pgtable: 64k pages, 48-bit VAs, pgdp = 000000007b97530e [0000600dea430008] pgd=0000000000000000, pud=0000000000000000 Internal error: Oops: 96000005 [#1] SMP [...] pstate: 10000005 (nzcV daif -PAN -UAO) pc : pfifo_fast_enqueue+0x524/0x6e8 lr : pfifo_fast_enqueue+0x46c/0x6e8 sp : ffff800d39376fe0 x29: ffff800d39376fe0 x28: 1ffff001a07d1e40 x27: ffff800d03e8f188 x26: ffff800d03e8f200 x25: 0000000000000062 x24: ffff800d393772f0 x23: 0000000000000000 x22: 0000000000000403 x21: ffff800cca569a00 x20: ffff800d03e8ee00 x19: ffff800cca569a10 x18: 00000000000000bf x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: ffff1001a726edd0 x13: 1fffe4000276a9a4 x12: 0000000000000000 x11: dfff200000000000 x10: ffff800d03e8f1a0 x9 : 0000000000000003 x8 : 0000000000000000 x7 : 00000000f1f1f1f1 x6 : ffff1001a726edea x5 : ffff800cca56a53c x4 : 1ffff001bf9a8003 x3 : 1ffff001bf9a8003 x2 : 1ffff001a07d1dcb x1 : 0000600dea430000 x0 : 0000600dea430008 Process ping (pid: 6067, stack limit = 0x00000000dc0aa557) Call trace: pfifo_fast_enqueue+0x524/0x6e8 htb_enqueue+0x660/0x10e0 [sch_htb] __dev_queue_xmit+0x123c/0x2de0 dev_queue_xmit+0x24/0x30 ip_finish_output2+0xc48/0x1720 ip_finish_output+0x548/0x9d8 ip_output+0x334/0x788 ip_local_out+0x90/0x138 ip_send_skb+0x44/0x1d0 ip_push_pending_frames+0x5c/0x78 raw_sendmsg+0xed8/0x28d0 inet_sendmsg+0xc4/0x5c0 sock_sendmsg+0xac/0x108 __sys_sendto+0x1ac/0x2a0 __arm64_sys_sendto+0xc4/0x138 el0_svc_handler+0x13c/0x298 el0_svc+0x8/0xc Code: f9402e80 d538d081 91002000 8b010000 (885f7c03) Fix this by testing the value of 'TCQ_F_CPUSTATS' bit in 'qdisc->flags', before dereferencing 'qdisc->cpu_qstats'. Fixes: 8a53e616de29 ("net: sched: when clearing NOLOCK, clear TCQ_F_CPUSTATS, too") CC: Paolo Abeni CC: Stefano Brivio Reported-by: Li Shuang Signed-off-by: Davide Caratti Acked-by: Paolo Abeni Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0b003edac850ee96653f2005b8ae27fd92ba32d2 Author: Vladimir Oltean Date: Sun Aug 25 21:32:12 2019 +0300 net: dsa: tag_8021q: Future-proof the reserved fields in the custom VID [ Upstream commit bcccb0a535bb99616e4b992568371efab1ab14e8 ] After witnessing the discussion in https://lkml.org/lkml/2019/8/14/151 w.r.t. ioctl extensibility, it became clear that such an issue might prevent that the 3 RSV bits inside the DSA 802.1Q tag might also suffer the same fate and be useless for further extension. So clearly specify that the reserved bits should currently be transmitted as zero and ignored on receive. The DSA tagger already does this (and has always did), and is the only known user so far (no Wireshark dissection plugin, etc). So there should be no incompatibility to speak of. Fixes: 0471dd429cea ("net: dsa: tag_8021q: Create a stable binary format") Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c7f05c1d9bf477d6f3a3067ec74505f88dfda2f3 Author: Marco Hartmann Date: Wed Aug 21 11:00:46 2019 +0000 Add genphy_c45_config_aneg() function to phy-c45.c [ Upstream commit 2ebb991641d3f64b70fec0156e2b6933810177e9 ] Commit 34786005eca3 ("net: phy: prevent PHYs w/o Clause 22 regs from calling genphy_config_aneg") introduced a check that aborts phy_config_aneg() if the phy is a C45 phy. This causes phy_state_machine() to call phy_error() so that the phy ends up in PHY_HALTED state. Instead of returning -EOPNOTSUPP, call genphy_c45_config_aneg() (analogous to the C22 case) so that the state machine can run correctly. genphy_c45_config_aneg() closely resembles mv3310_config_aneg() in drivers/net/phy/marvell10g.c, excluding vendor specific configurations for 1000BaseT. Fixes: 22b56e827093 ("net: phy: replace genphy_10g_driver with genphy_c45_driver") Signed-off-by: Marco Hartmann Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 98ded313ffda65bcd47556270143eaaea9e27e0f Author: Vladimir Oltean Date: Fri Aug 30 04:07:23 2019 +0300 net/sched: cbs: Set default link speed to 10 Mbps in cbs_set_port_rate The discussion to be made is absolutely the same as in the case of previous patch ("taprio: Set default link speed to 10 Mbps in taprio_set_picos_per_byte"). Nothing is lost when setting a default. Cc: Leandro Dorileo Fixes: e0a7683d30e9 ("net/sched: cbs: fix port_rate miscalculation") Acked-by: Vinicius Costa Gomes Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 622f16b3051986775591fcc8c99b19a118205045 Author: Vladimir Oltean Date: Fri Aug 30 04:07:22 2019 +0300 taprio: Set default link speed to 10 Mbps in taprio_set_picos_per_byte The taprio budget needs to be adapted at runtime according to interface link speed. But that handling is problematic. For one thing, installing a qdisc on an interface that doesn't have carrier is not illegal. But taprio prints the following stack trace: [ 31.851373] ------------[ cut here ]------------ [ 31.856024] WARNING: CPU: 1 PID: 207 at net/sched/sch_taprio.c:481 taprio_dequeue+0x1a8/0x2d4 [ 31.864566] taprio: dequeue() called with unknown picos per byte. [ 31.864570] Modules linked in: [ 31.873701] CPU: 1 PID: 207 Comm: tc Not tainted 5.3.0-rc5-01199-g8838fe023cd6 #1689 [ 31.881398] Hardware name: Freescale LS1021A [ 31.885661] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 31.893368] [] (show_stack) from [] (dump_stack+0xb4/0xc8) [ 31.900555] [] (dump_stack) from [] (__warn+0xe0/0xf8) [ 31.907395] [] (__warn) from [] (warn_slowpath_fmt+0x48/0x6c) [ 31.914841] [] (warn_slowpath_fmt) from [] (taprio_dequeue+0x1a8/0x2d4) [ 31.923150] [] (taprio_dequeue) from [] (__qdisc_run+0x90/0x61c) [ 31.930856] [] (__qdisc_run) from [] (net_tx_action+0x12c/0x2bc) [ 31.938560] [] (net_tx_action) from [] (__do_softirq+0x130/0x3c8) [ 31.946350] [] (__do_softirq) from [] (irq_exit+0xbc/0xd8) [ 31.953536] [] (irq_exit) from [] (__handle_domain_irq+0x60/0xb4) [ 31.961328] [] (__handle_domain_irq) from [] (gic_handle_irq+0x58/0x9c) [ 31.969638] [] (gic_handle_irq) from [] (__irq_svc+0x6c/0x90) [ 31.977076] Exception stack(0xe8167b20 to 0xe8167b68) [ 31.982100] 7b20: e9d4bd80 00000cc0 000000cf 00000000 e9d4bd80 c1f38958 00000cc0 c1f38960 [ 31.990234] 7b40: 00000001 000000cf 00000004 e9dc0800 00000000 e8167b70 c0f478ec c0f46d94 [ 31.998363] 7b60: 60070013 ffffffff [ 32.001833] [] (__irq_svc) from [] (netlink_trim+0x18/0xd8) [ 32.009104] [] (netlink_trim) from [] (netlink_broadcast_filtered+0x34/0x414) [ 32.017930] [] (netlink_broadcast_filtered) from [] (netlink_broadcast+0x20/0x28) [ 32.027102] [] (netlink_broadcast) from [] (rtnetlink_send+0x34/0x88) [ 32.035238] [] (rtnetlink_send) from [] (notify_and_destroy+0x2c/0x44) [ 32.043461] [] (notify_and_destroy) from [] (qdisc_graft+0x398/0x470) [ 32.051595] [] (qdisc_graft) from [] (tc_modify_qdisc+0x3a4/0x724) [ 32.059470] [] (tc_modify_qdisc) from [] (rtnetlink_rcv_msg+0x260/0x2ec) [ 32.067864] [] (rtnetlink_rcv_msg) from [] (netlink_rcv_skb+0xb8/0x110) [ 32.076172] [] (netlink_rcv_skb) from [] (netlink_unicast+0x1b4/0x22c) [ 32.084392] [] (netlink_unicast) from [] (netlink_sendmsg+0x33c/0x380) [ 32.092614] [] (netlink_sendmsg) from [] (sock_sendmsg+0x14/0x24) [ 32.100403] [] (sock_sendmsg) from [] (___sys_sendmsg+0x214/0x228) [ 32.108279] [] (___sys_sendmsg) from [] (__sys_sendmsg+0x50/0x8c) [ 32.116068] [] (__sys_sendmsg) from [] (ret_fast_syscall+0x0/0x54) [ 32.123938] Exception stack(0xe8167fa8 to 0xe8167ff0) [ 32.128960] 7fa0: b6fa68c8 000000f8 00000003 bea142d0 00000000 00000000 [ 32.137093] 7fc0: b6fa68c8 000000f8 0052154c 00000128 5d6468a2 00000000 00000028 00558c9c [ 32.145224] 7fe0: 00000070 bea14278 00530d64 b6e17e64 [ 32.150659] ---[ end trace 2139c9827c3e5177 ]--- This happens because the qdisc ->dequeue callback gets called. Which again is not illegal, the qdisc will dequeue even when the interface is up but doesn't have carrier (and hence SPEED_UNKNOWN), and the frames will be dropped further down the stack in dev_direct_xmit(). And, at the end of the day, for what? For calculating the initial budget of an interface which is non-operational at the moment and where frames will get dropped anyway. So if we can't figure out the link speed, default to SPEED_10 and move along. We can also remove the runtime check now. Cc: Leandro Dorileo Fixes: 7b9eba7ba0c1 ("net/sched: taprio: fix picos_per_byte miscalculation") Acked-by: Vinicius Costa Gomes Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4f15d0e51268376155951c11d58190e4026d062d Author: Vladimir Oltean Date: Fri Aug 30 04:07:21 2019 +0300 taprio: Fix kernel panic in taprio_destroy taprio_init may fail earlier than this line: list_add(&q->taprio_list, &taprio_list); i.e. due to the net device not being multi queue. Attempting to remove q from the global taprio_list when it is not part of it will result in a kernel panic. Fix it by matching list_add and list_del better to one another in the order of operations. This way we can keep the deletion unconditional and with lower complexity - O(1). Cc: Leandro Dorileo Fixes: 7b9eba7ba0c1 ("net/sched: taprio: fix picos_per_byte miscalculation") Signed-off-by: Vladimir Oltean Acked-by: Vinicius Costa Gomes Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 61f10b1bb84d7c21e64cf4d6ebf274a829fc850d Author: Hayes Wang Date: Wed Aug 28 09:51:42 2019 +0800 r8152: remove calling netif_napi_del [ Upstream commit 973dc6cfc0e2c43ff29ca5645ceaf1ae694ea110 ] Remove unnecessary use of netif_napi_del. This also avoids to call napi_disable() after netif_napi_del(). Signed-off-by: Hayes Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5a9ceccb638580c5d720dff0902d4c0c33d39a89 Author: Hayes Wang Date: Wed Aug 28 09:51:41 2019 +0800 Revert "r8152: napi hangup fix after disconnect" [ Upstream commit 49d4b14113cae1410eb4654ada5b9583bad971c4 ] This reverts commit 0ee1f4734967af8321ecebaf9c74221ace34f2d5. The commit 0ee1f4734967 ("r8152: napi hangup fix after disconnect") adds a check about RTL8152_UNPLUG to determine if calling napi_disable() is invalid in rtl8152_close(), when rtl8152_disconnect() is called. This avoids to use napi_disable() after calling netif_napi_del(). Howver, commit ffa9fec30ca0 ("r8152: set RTL8152_UNPLUG only for real disconnection") causes that RTL8152_UNPLUG is not always set when calling rtl8152_disconnect(). Therefore, I have to revert commit 0ee1f4734967 ("r8152: napi hangup fix after disconnect"), first. And submit another patch to fix it. Signed-off-by: Hayes Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7e21536433d054c229c9c100f5f1c135fd57f2fa Author: John Hurley Date: Tue Aug 27 22:56:30 2019 -0700 nfp: flower: handle neighbour events on internal ports [ Upstream commit e8024cb483abb2b0290b3ef5e34c736e9de2492f ] Recent code changes to NFP allowed the offload of neighbour entries to FW when the next hop device was an internal port. This allows for offload of tunnel encap when the end-point IP address is applied to such a port. Unfortunately, the neighbour event handler still rejects events that are not associated with a repr dev and so the firmware neighbour table may get out of sync for internal ports. Fix this by allowing internal port neighbour events to be correctly processed. Fixes: 45756dfedab5 ("nfp: flower: allow tunnels to output to internal port") Signed-off-by: John Hurley Reviewed-by: Simon Horman Reviewed-by: Jakub Kicinski Signed-off-by: Jakub Kicinski Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f7ec32a4ae5cb6b78359de1afc37ba7d3ada60ee Author: John Hurley Date: Tue Aug 27 22:56:29 2019 -0700 nfp: flower: prevent ingress block binds on internal ports [ Upstream commit 739d7c5752b255e89ddbb1b0474f3b88ef5cd343 ] Internal port TC offload is implemented through user-space applications (such as OvS) by adding filters at egress via TC clsact qdiscs. Indirect block offload support in the NFP driver accepts both ingress qdisc binds and egress binds if the device is an internal port. However, clsact sends bind notification for both ingress and egress block binds which can lead to the driver registering multiple callbacks and receiving multiple notifications of new filters. Fix this by rejecting ingress block bind callbacks when the port is internal and only adding filter callbacks for egress binds. Fixes: 4d12ba42787b ("nfp: flower: allow offloading of matches on 'internal' ports") Signed-off-by: John Hurley Reviewed-by: Jakub Kicinski Signed-off-by: Jakub Kicinski Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 64a2a93ba3856d16765e5c8a00c133fa8750879a Author: Eric Dumazet Date: Mon Aug 26 09:19:15 2019 -0700 tcp: remove empty skb from write queue in error cases [ Upstream commit fdfc5c8594c24c5df883583ebd286321a80e0a67 ] Vladimir Rutsky reported stuck TCP sessions after memory pressure events. Edge Trigger epoll() user would never receive an EPOLLOUT notification allowing them to retry a sendmsg(). Jason tested the case of sk_stream_alloc_skb() returning NULL, but there are other paths that could lead both sendmsg() and sendpage() to return -1 (EAGAIN), with an empty skb queued on the write queue. This patch makes sure we remove this empty skb so that Jason code can detect that the queue is empty, and call sk->sk_write_space(sk) accordingly. Fixes: ce5ec440994b ("tcp: ensure epoll edge trigger wakeup when write queue is empty") Signed-off-by: Eric Dumazet Cc: Jason Baron Reported-by: Vladimir Rutsky Cc: Soheil Hassas Yeganeh Cc: Neal Cardwell Acked-by: Soheil Hassas Yeganeh Acked-by: Neal Cardwell Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5cef2bfc9e3f9896e6e27fc6316b9819d5b046c4 Author: Willem de Bruijn Date: Tue Aug 27 15:09:33 2019 -0400 tcp: inherit timestamp on mtu probe [ Upstream commit 888a5c53c0d8be6e98bc85b677f179f77a647873 ] TCP associates tx timestamp requests with a byte in the bytestream. If merging skbs in tcp_mtu_probe, migrate the tstamp request. Similar to MSG_EOR, do not allow moving a timestamp from any segment in the probe but the last. This to avoid merging multiple timestamps. Tested with the packetdrill script at https://github.com/wdebruij/packetdrill/commits/mtu_probe-1 Link: http://patchwork.ozlabs.org/patch/1143278/#2232897 Fixes: 4ed2d765dfac ("net-timestamp: TCP timestamping") Signed-off-by: Willem de Bruijn Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 939cc35d5f8179ec7de7ef765a41ae161349f247 Author: Chen-Yu Tsai Date: Thu Aug 29 11:17:24 2019 +0800 net: stmmac: dwmac-rk: Don't fail if phy regulator is absent [ Upstream commit 3b25528e1e355c803e73aa326ce657b5606cda73 ] The devicetree binding lists the phy phy as optional. As such, the driver should not bail out if it can't find a regulator. Instead it should just skip the remaining regulator related code and continue on normally. Skip the remainder of phy_power_on() if a regulator supply isn't available. This also gets rid of the bogus return code. Fixes: 2e12f536635f ("net: stmmac: dwmac-rk: Use standard devicetree property for phy regulator") Signed-off-by: Chen-Yu Tsai Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 505aac7f4e48fbdb7fe405103368261a7a84f3c7 Author: Cong Wang Date: Sun Aug 25 10:01:32 2019 -0700 net_sched: fix a NULL pointer deref in ipt action [ Upstream commit 981471bd3abf4d572097645d765391533aac327d ] The net pointer in struct xt_tgdtor_param is not explicitly initialized therefore is still NULL when dereferencing it. So we have to find a way to pass the correct net pointer to ipt_destroy_target(). The best way I find is just saving the net pointer inside the per netns struct tcf_idrinfo, which could make this patch smaller. Fixes: 0c66dc1ea3f0 ("netfilter: conntrack: register hooks in netns when needed by ruleset") Reported-and-tested-by: itugrok@yahoo.com Cc: Jamal Hadi Salim Cc: Jiri Pirko Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3c6dfd2adb7a71915ff2fb8e40e466d748078103 Author: Vlad Buslov Date: Tue Aug 27 21:49:38 2019 +0300 net: sched: act_sample: fix psample group handling on overwrite [ Upstream commit dbf47a2a094edf58983265e323ca4bdcdb58b5ee ] Action sample doesn't properly handle psample_group pointer in overwrite case. Following issues need to be fixed: - In tcf_sample_init() function RCU_INIT_POINTER() is used to set s->psample_group, even though we neither setting the pointer to NULL, nor preventing concurrent readers from accessing the pointer in some way. Use rcu_swap_protected() instead to safely reset the pointer. - Old value of s->psample_group is not released or deallocated in any way, which results resource leak. Use psample_group_put() on non-NULL value obtained with rcu_swap_protected(). - The function psample_group_put() that released reference to struct psample_group pointed by rcu-pointer s->psample_group doesn't respect rcu grace period when deallocating it. Extend struct psample_group with rcu head and use kfree_rcu when freeing it. Fixes: 5c5670fae430 ("net/sched: Introduce sample tc action") Signed-off-by: Vlad Buslov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5038bd027ac331879445bfff36e9003f3fbfb007 Author: Feng Sun Date: Mon Aug 26 14:46:04 2019 +0800 net: fix skb use after free in netpoll [ Upstream commit 2c1644cf6d46a8267d79ed95cb9b563839346562 ] After commit baeababb5b85d5c4e6c917efe2a1504179438d3b ("tun: return NET_XMIT_DROP for dropped packets"), when tun_net_xmit drop packets, it will free skb and return NET_XMIT_DROP, netpoll_send_skb_on_dev will run into following use after free cases: 1. retry netpoll_start_xmit with freed skb; 2. queue freed skb in npinfo->txq. queue_process will also run into use after free case. hit netpoll_send_skb_on_dev first case with following kernel log: [ 117.864773] kernel BUG at mm/slub.c:306! [ 117.864773] invalid opcode: 0000 [#1] SMP PTI [ 117.864774] CPU: 3 PID: 2627 Comm: loop_printmsg Kdump: loaded Tainted: P OE 5.3.0-050300rc5-generic #201908182231 [ 117.864775] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 [ 117.864775] RIP: 0010:kmem_cache_free+0x28d/0x2b0 [ 117.864781] Call Trace: [ 117.864781] ? tun_net_xmit+0x21c/0x460 [ 117.864781] kfree_skbmem+0x4e/0x60 [ 117.864782] kfree_skb+0x3a/0xa0 [ 117.864782] tun_net_xmit+0x21c/0x460 [ 117.864782] netpoll_start_xmit+0x11d/0x1b0 [ 117.864788] netpoll_send_skb_on_dev+0x1b8/0x200 [ 117.864789] __br_forward+0x1b9/0x1e0 [bridge] [ 117.864789] ? skb_clone+0x53/0xd0 [ 117.864790] ? __skb_clone+0x2e/0x120 [ 117.864790] deliver_clone+0x37/0x50 [bridge] [ 117.864790] maybe_deliver+0x89/0xc0 [bridge] [ 117.864791] br_flood+0x6c/0x130 [bridge] [ 117.864791] br_dev_xmit+0x315/0x3c0 [bridge] [ 117.864792] netpoll_start_xmit+0x11d/0x1b0 [ 117.864792] netpoll_send_skb_on_dev+0x1b8/0x200 [ 117.864792] netpoll_send_udp+0x2c6/0x3e8 [ 117.864793] write_msg+0xd9/0xf0 [netconsole] [ 117.864793] console_unlock+0x386/0x4e0 [ 117.864793] vprintk_emit+0x17e/0x280 [ 117.864794] vprintk_default+0x29/0x50 [ 117.864794] vprintk_func+0x4c/0xbc [ 117.864794] printk+0x58/0x6f [ 117.864795] loop_fun+0x24/0x41 [printmsg_loop] [ 117.864795] kthread+0x104/0x140 [ 117.864795] ? 0xffffffffc05b1000 [ 117.864796] ? kthread_park+0x80/0x80 [ 117.864796] ret_from_fork+0x35/0x40 Signed-off-by: Feng Sun Signed-off-by: Xiaojun Zhao Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit baa513580b252aaffa1233e1a3716e2c1b0ca2e8 Author: Eric Dumazet Date: Tue Aug 27 03:33:12 2019 -0700 mld: fix memory leak in mld_del_delrec() [ Upstream commit a84d016479896b5526a2cc54784e6ffc41c9d6f6 ] Similar to the fix done for IPv4 in commit e5b1c6c6277d ("igmp: fix memory leak in igmpv3_del_delrec()"), we need to make sure mca_tomb and mca_sources are not blindly overwritten. Using swap() then a call to ip6_mc_clear_src() will take care of the missing free. BUG: memory leak unreferenced object 0xffff888117d9db00 (size 64): comm "syz-executor247", pid 6918, jiffies 4294943989 (age 25.350s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 fe 88 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000005b463030>] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline] [<000000005b463030>] slab_post_alloc_hook mm/slab.h:522 [inline] [<000000005b463030>] slab_alloc mm/slab.c:3319 [inline] [<000000005b463030>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548 [<00000000939cbf94>] kmalloc include/linux/slab.h:552 [inline] [<00000000939cbf94>] kzalloc include/linux/slab.h:748 [inline] [<00000000939cbf94>] ip6_mc_add1_src net/ipv6/mcast.c:2236 [inline] [<00000000939cbf94>] ip6_mc_add_src+0x31f/0x420 net/ipv6/mcast.c:2356 [<00000000d8972221>] ip6_mc_source+0x4a8/0x600 net/ipv6/mcast.c:449 [<000000002b203d0d>] do_ipv6_setsockopt.isra.0+0x1b92/0x1dd0 net/ipv6/ipv6_sockglue.c:748 [<000000001f1e2d54>] ipv6_setsockopt+0x89/0xd0 net/ipv6/ipv6_sockglue.c:944 [<00000000c8f7bdf9>] udpv6_setsockopt+0x4e/0x90 net/ipv6/udp.c:1558 [<000000005a9a0c5e>] sock_common_setsockopt+0x38/0x50 net/core/sock.c:3139 [<00000000910b37b2>] __sys_setsockopt+0x10f/0x220 net/socket.c:2084 [<00000000e9108023>] __do_sys_setsockopt net/socket.c:2100 [inline] [<00000000e9108023>] __se_sys_setsockopt net/socket.c:2097 [inline] [<00000000e9108023>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2097 [<00000000f4818160>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:296 [<000000008d367e8f>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: 1666d49e1d41 ("mld: do not remove mld souce list info when set link down") Fixes: 9c8bb163ae78 ("igmp, mld: Fix memory leak in igmpv3/mld_del_delrec()") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman