commit e7a89836a274efd5cce216fe6d20a0bbfbdfd456 Author: Greg Kroah-Hartman Date: Mon Apr 13 13:16:42 2020 +0200 Linux 5.5.17 commit 16bb207363d22ac7e45b055ff6022cc85dcbd286 Author: Ilya Dryomov Date: Mon Feb 10 22:51:08 2020 +0100 ceph: canonicalize server path in place commit b27a939e8376a3f1ed09b9c33ef44d20f18ec3d0 upstream. syzbot reported that 4fbc0c711b24 ("ceph: remove the extra slashes in the server path") had caused a regression where an allocation could be done under a spinlock -- compare_mount_options() is called by sget_fc() with sb_lock held. We don't really need the supplied server path, so canonicalize it in place and compare it directly. To make this work, the leading slash is kept around and the logic in ceph_real_mount() to skip it is restored. CEPH_MSG_CLIENT_SESSION now reports the same (i.e. canonicalized) path, with the leading slash of course. Fixes: 4fbc0c711b24 ("ceph: remove the extra slashes in the server path") Reported-by: syzbot+98704a51af8e3d9425a9@syzkaller.appspotmail.com Signed-off-by: Ilya Dryomov Reviewed-by: Jeff Layton Signed-off-by: Luis Henriques Signed-off-by: Greg Kroah-Hartman commit 11b9a2869f3f67679499fc49247e4eb19d8c8331 Author: Xiubo Li Date: Fri Dec 20 09:34:04 2019 -0500 ceph: remove the extra slashes in the server path commit 4fbc0c711b2464ee1551850b85002faae0b775d5 upstream. It's possible to pass the mount helper a server path that has more than one contiguous slash character. For example: $ mount -t ceph 192.168.195.165:40176:/// /mnt/cephfs/ In the MDS server side the extra slashes of the server path will be treated as snap dir, and then we can get the following debug logs: ceph: mount opening path // ceph: open_root_inode opening '//' ceph: fill_trace 0000000059b8a3bc is_dentry 0 is_target 1 ceph: alloc_inode 00000000dc4ca00b ceph: get_inode created new inode 00000000dc4ca00b 1.ffffffffffffffff ino 1 ceph: get_inode on 1=1.ffffffffffffffff got 00000000dc4ca00b And then when creating any new file or directory under the mount point, we can hit the following BUG_ON in ceph_fill_trace(): BUG_ON(ceph_snap(dir) != dvino.snap); Have the client ignore the extra slashes in the server path when mounting. This will also canonicalize the path, so that identical mounts can be consilidated. 1) "//mydir1///mydir//" 2) "/mydir1/mydir" 3) "/mydir1/mydir/" Regardless of the internal treatment of these paths, the kernel still stores the original string including the leading '/' for presentation to userland. URL: https://tracker.ceph.com/issues/42771 Signed-off-by: Xiubo Li Reviewed-by: Jeff Layton Signed-off-by: Ilya Dryomov Signed-off-by: Luis Henriques Signed-off-by: Greg Kroah-Hartman commit f5e096520d8f02478dd2b7ec047c85017a1ac6a8 Author: Arnd Bergmann Date: Tue Jan 7 22:51:39 2020 +0100 ARM: imx: only select ARM_ERRATA_814220 for ARMv7-A commit c74067a0f776c1d695a713a4388c3b6a094ee40a upstream. i.MX7D is supported for either the v7-A or the v7-M cores, but the latter causes a warning: WARNING: unmet direct dependencies detected for ARM_ERRATA_814220 Depends on [n]: CPU_V7 [=n] Selected by [y]: - SOC_IMX7D [=y] && ARCH_MXC [=y] && (ARCH_MULTI_V7 [=n] || ARM_SINGLE_ARMV7M [=y]) Make the select statement conditional. Fixes: 4562fa4c86c9 ("ARM: imx: Enable ARM_ERRATA_814220 for i.MX6UL and i.MX7D") Signed-off-by: Arnd Bergmann Signed-off-by: Shawn Guo Cc: Christian Eggers Signed-off-by: Greg Kroah-Hartman commit 324ce997b05525f455a2dfd662269cbe3ec6ed34 Author: Anson Huang Date: Wed Dec 11 10:53:36 2019 +0800 ARM: imx: Enable ARM_ERRATA_814220 for i.MX6UL and i.MX7D commit 4562fa4c86c92a2df635fe0697c9e06379738741 upstream. ARM_ERRATA_814220 has below description: The v7 ARM states that all cache and branch predictor maintenance operations that do not specify an address execute, relative to each other, in program order. However, because of this erratum, an L2 set/way cache maintenance operation can overtake an L1 set/way cache maintenance operation. This ERRATA only affected the Cortex-A7 and present in r0p2, r0p3, r0p4, r0p5. i.MX6UL and i.MX7D have Cortex-A7 r0p5 inside, need to enable ARM_ERRATA_814220 for proper workaround. Signed-off-by: Anson Huang Signed-off-by: Shawn Guo Cc: Christian Eggers Signed-off-by: Greg Kroah-Hartman commit 63e12a5ff2d9d91da8aa234dfe10b358dc0e94ce Author: Alex Vesker Date: Thu Mar 5 14:38:41 2020 +0200 IB/mlx5: Replace tunnel mpls capability bits for tunnel_offloads commit 41e684ef3f37ce6e5eac3fb5b9c7c1853f4b0447 upstream. Until now the flex parser capability was used in ib_query_device() to indicate tunnel_offloads_caps support for mpls_over_gre/mpls_over_udp. Newer devices and firmware will have configurations with the flexparser but without mpls support. Testing for the flex parser capability was a mistake, the tunnel_stateless capability was intended for detecting mpls and was introduced at the same time as the flex parser capability. Otherwise userspace will be incorrectly informed that a future device supports MPLS when it does not. Link: https://lore.kernel.org/r/20200305123841.196086-1-leon@kernel.org Cc: # 4.17 Fixes: e818e255a58d ("IB/mlx5: Expose MPLS related tunneling offloads") Signed-off-by: Alex Vesker Reviewed-by: Ariel Levkovich Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 2ce11796d63eedbb3b9f4837501ef87e27042ba7 Author: Kaike Wan Date: Thu Mar 26 12:38:07 2020 -0400 IB/hfi1: Fix memory leaks in sysfs registration and unregistration commit 5c15abc4328ad696fa61e2f3604918ed0c207755 upstream. When the hfi1 driver is unloaded, kmemleak will report the following issue: unreferenced object 0xffff8888461a4c08 (size 8): comm "kworker/0:0", pid 5, jiffies 4298601264 (age 2047.134s) hex dump (first 8 bytes): 73 64 6d 61 30 00 ff ff sdma0... backtrace: [<00000000311a6ef5>] kvasprintf+0x62/0xd0 [<00000000ade94d9f>] kobject_set_name_vargs+0x1c/0x90 [<0000000060657dbb>] kobject_init_and_add+0x5d/0xb0 [<00000000346fe72b>] 0xffffffffa0c5ecba [<000000006cfc5819>] 0xffffffffa0c866b9 [<0000000031c65580>] 0xffffffffa0c38e87 [<00000000e9739b3f>] local_pci_probe+0x41/0x80 [<000000006c69911d>] work_for_cpu_fn+0x16/0x20 [<00000000601267b5>] process_one_work+0x171/0x380 [<0000000049a0eefa>] worker_thread+0x1d1/0x3f0 [<00000000909cf2b9>] kthread+0xf8/0x130 [<0000000058f5f874>] ret_from_fork+0x35/0x40 This patch fixes the issue by: - Releasing dd->per_sdma[i].kobject in hfi1_unregister_sysfs(). - This will fix the memory leak. - Calling kobject_put() to unwind operations only for those entries in dd->per_sdma[] whose operations have succeeded (including the current one that has just failed) in hfi1_verbs_register_sysfs(). Cc: Fixes: 0cb2aa690c7e ("IB/hfi1: Add sysfs interface for affinity setup") Link: https://lore.kernel.org/r/20200326163807.21129.27371.stgit@awfm-01.aw.intel.com Reviewed-by: Mike Marciniszyn Signed-off-by: Kaike Wan Signed-off-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 1debbfcca2378c7bd4c4b2d800c905a67a6871de Author: Kaike Wan Date: Thu Mar 26 12:38:14 2020 -0400 IB/hfi1: Call kobject_put() when kobject_init_and_add() fails commit dfb5394f804ed4fcea1fc925be275a38d66712ab upstream. When kobject_init_and_add() returns an error in the function hfi1_create_port_files(), the function kobject_put() is not called for the corresponding kobject, which potentially leads to memory leak. This patch fixes the issue by calling kobject_put() even if kobject_init_and_add() fails. Cc: Link: https://lore.kernel.org/r/20200326163813.21129.44280.stgit@awfm-01.aw.intel.com Reviewed-by: Mike Marciniszyn Signed-off-by: Kaike Wan Signed-off-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 126f803fd13ed8a60fd439f592c81c1d82c6fe43 Author: Paul Cercueil Date: Fri Mar 6 23:29:27 2020 +0100 ASoC: jz4740-i2s: Fix divider written at incorrect offset in register commit 9401d5aa328e64617d87abd59af1c91cace4c3e4 upstream. The 4-bit divider value was written at offset 8, while the jz4740 programming manual locates it at offset 0. Fixes: 26b0aad80a86 ("ASoC: jz4740: Add dynamic sampling rate support to jz4740-i2s") Signed-off-by: Paul Cercueil Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200306222931.39664-2-paul@crapouillou.net Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 14b0581fb9ef65263f3c93ba14df3807e2d336ef Author: Jonghwan Choi Date: Thu Mar 19 23:00:44 2020 +0900 ASoC: tas2562: Fixed incorrect amp_level setting. commit eedf8a126629bf9db8ad3a2a5dc9dc1798fb2302 upstream. According to the tas2562 datasheet,the bits[5:1] represents the amp_level value. So to set the amp_level value correctly,the shift value should be set to 1. Signed-off-by: Jonghwan Choi Acked-by: Dan Murphy Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200319140043.GA6688@jhbirdchoi-MS-7B79 Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 0cc7f888024376857715eef59509028aa4aa98a1 Author: Hans de Goede Date: Fri Apr 3 17:48:34 2020 +0200 platform/x86: intel_int0002_vgpio: Use acpi_register_wakeup_handler() commit 767191db8220db29f78c031f4d27375173c336d5 upstream. The Power Management Events (PMEs) the INT0002 driver listens for get signalled by the Power Management Controller (PMC) using the same IRQ as used for the ACPI SCI. Since commit fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system") the SCI triggering, without there being a wakeup cause recognized by the ACPI sleep code, will no longer wakeup the system. This breaks PMEs / wakeups signalled to the INT0002 driver, the system never leaves the s2idle_loop() now. Use acpi_register_wakeup_handler() to register a function which checks the GPE0a_STS register for a PME and trigger a wakeup when a PME has been signalled. Fixes: fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system") Cc: 5.4+ # 5.4+ Signed-off-by: Hans de Goede Acked-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 40b211c3c76542e6bfaff4fcf33d1beaa2e8e00a Author: Hans de Goede Date: Fri Apr 3 17:48:33 2020 +0200 ACPI: PM: Add acpi_[un]register_wakeup_handler() commit ddfd9dcf270ce23ed1985b66fcfa163920e2e1b8 upstream. Since commit fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system") the SCI triggering without there being a wakeup cause recognized by the ACPI sleep code will no longer wakeup the system. This works as intended, but this is a problem for devices where the SCI is shared with another device which is also a wakeup source. In the past these, from the pov of the ACPI sleep code, spurious SCIs would still cause a wakeup so the wakeup from the device sharing the interrupt would actually wakeup the system. This now no longer works. This is a problem on e.g. Bay Trail-T and Cherry Trail devices where some peripherals (typically the XHCI controller) can signal a Power Management Event (PME) to the Power Management Controller (PMC) to wakeup the system, this uses the same interrupt as the SCI. These wakeups are handled through a special INT0002 ACPI device which checks for events in the GPE0a_STS for this and takes care of acking the PME so that the shared interrupt stops triggering. The change to the ACPI sleep code to ignore the spurious SCI, causes the system to no longer wakeup on these PME events. To make things worse this means that the INT0002 device driver interrupt handler will no longer run, causing the PME to not get cleared and resulting in the system hanging. Trying to wakeup the system after such a PME through e.g. the power button no longer works. Add an acpi_register_wakeup_handler() function which registers a handler to be called from acpi_s2idle_wake() and when the handler returns true, return true from acpi_s2idle_wake(). The INT0002 driver will use this mechanism to check the GPE0a_STS register from acpi_s2idle_wake() and to tell the system to wakeup if a PME is signaled in the register. Fixes: fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system") Cc: 5.4+ # 5.4+ Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 32f862e6920d43b57361cc23dac58307c0109f92 Author: Martin Kaiser Date: Thu Mar 5 21:58:20 2020 +0100 hwrng: imx-rngc - fix an error path commit 47a1f8e8b3637ff5f7806587883d7d94068d9ee8 upstream. Make sure that the rngc interrupt is masked if the rngc self test fails. Self test failure means that probe fails as well. Interrupts should be masked in this case, regardless of the error. Cc: stable@vger.kernel.org Fixes: 1d5449445bd0 ("hwrng: mx-rngc - add a driver for Freescale RNGC") Reviewed-by: PrasannaKumar Muralidharan Signed-off-by: Martin Kaiser Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 7deaad9918f52c6191497d0e6ff0d56698f4962d Author: David Ahern Date: Wed Apr 1 21:02:25 2020 -0700 tools/accounting/getdelays.c: fix netlink attribute length commit 4054ab64e29bb05b3dfe758fff3c38a74ba753bb upstream. A recent change to the netlink code: 6e237d099fac ("netlink: Relax attr validation for fixed length types") logs a warning when programs send messages with invalid attributes (e.g., wrong length for a u32). Yafang reported this error message for tools/accounting/getdelays.c. send_cmd() is wrongly adding 1 to the attribute length. As noted in include/uapi/linux/netlink.h nla_len should be NLA_HDRLEN + payload length, so drop the +1. Fixes: 9e06d3f9f6b1 ("per task delay accounting taskstats interface: documentation fix") Reported-by: Yafang Shao Signed-off-by: David Ahern Signed-off-by: Andrew Morton Tested-by: Yafang Shao Cc: Johannes Berg Cc: Shailabh Nagar Cc: Link: http://lkml.kernel.org/r/20200327173111.63922-1-dsahern@kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e4e37de2788b3e3dad5a6cbc52cafb8572afa31c Author: Lu Baolu Date: Wed Jan 15 11:03:58 2020 +0800 iommu/vt-d: Allow devices with RMRRs to use identity domain commit 9235cb13d7d17baba0b3a9277381258361e95c16 upstream. Since commit ea2447f700cab ("intel-iommu: Prevent devices with RMRRs from being placed into SI Domain"), the Intel IOMMU driver doesn't allow any devices with RMRR locked to use the identity domain. This was added to to fix the issue where the RMRR info for devices being placed in and out of the identity domain gets lost. This identity maps all RMRRs when setting up the identity domain, so that devices with RMRRs could also use it. Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Cc: Alan Stern Cc: John Donnelly Signed-off-by: Greg Kroah-Hartman commit bff310a965867674e6f99bbae35b41310a7e4457 Author: Saravana Kannan Date: Fri Feb 21 17:40:34 2020 -0800 driver core: Reevaluate dev->links.need_for_probe as suppliers are added commit 1745d299af5b373abad08fa29bff0d31dc6aff21 upstream. A previous patch 03324507e66c ("driver core: Allow fwnode_operations.add_links to differentiate errors") forgot to update all call sites to fwnode_operations.add_links. This patch fixes that. Legend: -> Denotes RHS is an optional/potential supplier for LHS => Denotes RHS is a mandatory supplier for LHS Example: Device A => Device X Device A -> Device Y Before this patch: 1. Device A is added. 2. Device A is marked as waiting for mandatory suppliers 3. Device X is added 4. Device A is left marked as waiting for mandatory suppliers Step 4 is wrong since all mandatory suppliers of Device A have been added. After this patch: 1. Device A is added. 2. Device A is marked as waiting for mandatory suppliers 3. Device X is added 4. Device A is no longer considered as waiting for mandatory suppliers This is the correct behavior. Fixes: 03324507e66c ("driver core: Allow fwnode_operations.add_links to differentiate errors") Signed-off-by: Saravana Kannan Link: https://lore.kernel.org/r/20200222014038.180923-2-saravanak@google.com Signed-off-by: Greg Kroah-Hartman commit 85347edb2a04673fbd6be31b2288f9a8f7cc5174 Author: Qiujun Huang Date: Sun Mar 29 16:56:47 2020 +0800 fbcon: fix null-ptr-deref in fbcon_switch commit b139f8b00db4a8ea75a4174346eafa48041aa489 upstream. Set logo_shown to FBCON_LOGO_CANSHOW when the vc was deallocated. syzkaller report: https://lkml.org/lkml/2020/3/27/403 general protection fault, probably for non-canonical address 0xdffffc000000006c: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000360-0x0000000000000367] RIP: 0010:fbcon_switch+0x28f/0x1740 drivers/video/fbdev/core/fbcon.c:2260 Call Trace: redraw_screen+0x2a8/0x770 drivers/tty/vt/vt.c:1008 vc_do_resize+0xfe7/0x1360 drivers/tty/vt/vt.c:1295 fbcon_init+0x1221/0x1ab0 drivers/video/fbdev/core/fbcon.c:1219 visual_init+0x305/0x5c0 drivers/tty/vt/vt.c:1062 do_bind_con_driver+0x536/0x890 drivers/tty/vt/vt.c:3542 do_take_over_console+0x453/0x5b0 drivers/tty/vt/vt.c:4122 do_fbcon_takeover+0x10b/0x210 drivers/video/fbdev/core/fbcon.c:588 fbcon_fb_registered+0x26b/0x340 drivers/video/fbdev/core/fbcon.c:3259 do_register_framebuffer drivers/video/fbdev/core/fbmem.c:1664 [inline] register_framebuffer+0x56e/0x980 drivers/video/fbdev/core/fbmem.c:1832 dlfb_usb_probe.cold+0x1743/0x1ba3 drivers/video/fbdev/udlfb.c:1735 usb_probe_interface+0x310/0x800 drivers/usb/core/driver.c:374 accessing vc_cons[logo_shown].d->vc_top causes the bug. Reported-by: syzbot+732528bae351682f1f27@syzkaller.appspotmail.com Signed-off-by: Qiujun Huang Acked-by: Sam Ravnborg Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20200329085647.25133-1-hqjagain@gmail.com Signed-off-by: Greg Kroah-Hartman commit b89fe15f75e8e75978c2fc89122fb14234e5f89e Author: Bart Van Assche Date: Mon Mar 9 21:26:17 2020 -0700 blk-mq: Keep set->nr_hw_queues and set->map[].nr_queues in sync commit 6e66b49392419f3fe134e1be583323ef75da1e4b upstream. blk_mq_map_queues() and multiple .map_queues() implementations expect that set->map[HCTX_TYPE_DEFAULT].nr_queues is set to the number of hardware queues. Hence set .nr_queues before calling these functions. This patch fixes the following kernel warning: WARNING: CPU: 0 PID: 2501 at include/linux/cpumask.h:137 Call Trace: blk_mq_run_hw_queue+0x19d/0x350 block/blk-mq.c:1508 blk_mq_run_hw_queues+0x112/0x1a0 block/blk-mq.c:1525 blk_mq_requeue_work+0x502/0x780 block/blk-mq.c:775 process_one_work+0x9af/0x1740 kernel/workqueue.c:2269 worker_thread+0x98/0xe40 kernel/workqueue.c:2415 kthread+0x361/0x430 kernel/kthread.c:255 Fixes: ed76e329d74a ("blk-mq: abstract out queue map") # v5.0 Reported-by: syzbot+d44e1b26ce5c3e77458d@syzkaller.appspotmail.com Signed-off-by: Bart Van Assche Reviewed-by: Ming Lei Reviewed-by: Chaitanya Kulkarni Cc: Johannes Thumshirn Cc: Hannes Reinecke Cc: Ming Lei Cc: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 8f2d0bd1dfb0da1ee744094bfab9cb7c6f81edf3 Author: Avihai Horon Date: Wed Mar 18 12:17:41 2020 +0200 RDMA/cm: Update num_paths in cma_resolve_iboe_route error flow commit 987914ab841e2ec281a35b54348ab109b4c0bb4e upstream. After a successful allocation of path_rec, num_paths is set to 1, but any error after such allocation will leave num_paths uncleared. This causes to de-referencing a NULL pointer later on. Hence, num_paths needs to be set back to 0 if such an error occurs. The following crash from syzkaller revealed it. kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI CPU: 0 PID: 357 Comm: syz-executor060 Not tainted 4.18.0+ #311 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org 04/01/2014 RIP: 0010:ib_copy_path_rec_to_user+0x94/0x3e0 Code: f1 f1 f1 f1 c7 40 0c 00 00 f4 f4 65 48 8b 04 25 28 00 00 00 48 89 45 c8 31 c0 e8 d7 60 24 ff 48 8d 7b 4c 48 89 f8 48 c1 e8 03 <42> 0f b6 14 30 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 RSP: 0018:ffff88006586f980 EFLAGS: 00010207 RAX: 0000000000000009 RBX: 0000000000000000 RCX: 1ffff1000d5fe475 RDX: ffff8800621e17c0 RSI: ffffffff820d45f9 RDI: 000000000000004c RBP: ffff88006586fa50 R08: ffffed000cb0df73 R09: ffffed000cb0df72 R10: ffff88006586fa70 R11: ffffed000cb0df73 R12: 1ffff1000cb0df30 R13: ffff88006586fae8 R14: dffffc0000000000 R15: ffff88006aff2200 FS: 00000000016fc880(0000) GS:ffff88006d000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000040 CR3: 0000000063fec000 CR4: 00000000000006b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? ib_copy_path_rec_from_user+0xcc0/0xcc0 ? __mutex_unlock_slowpath+0xfc/0x670 ? wait_for_completion+0x3b0/0x3b0 ? ucma_query_route+0x818/0xc60 ucma_query_route+0x818/0xc60 ? ucma_listen+0x1b0/0x1b0 ? sched_clock_cpu+0x18/0x1d0 ? sched_clock_cpu+0x18/0x1d0 ? ucma_listen+0x1b0/0x1b0 ? ucma_write+0x292/0x460 ucma_write+0x292/0x460 ? ucma_close_id+0x60/0x60 ? sched_clock_cpu+0x18/0x1d0 ? sched_clock_cpu+0x18/0x1d0 __vfs_write+0xf7/0x620 ? ucma_close_id+0x60/0x60 ? kernel_read+0x110/0x110 ? time_hardirqs_on+0x19/0x580 ? lock_acquire+0x18b/0x3a0 ? finish_task_switch+0xf3/0x5d0 ? _raw_spin_unlock_irq+0x29/0x40 ? _raw_spin_unlock_irq+0x29/0x40 ? finish_task_switch+0x1be/0x5d0 ? __switch_to_asm+0x34/0x70 ? __switch_to_asm+0x40/0x70 ? security_file_permission+0x172/0x1e0 vfs_write+0x192/0x460 ksys_write+0xc6/0x1a0 ? __ia32_sys_read+0xb0/0xb0 ? entry_SYSCALL_64_after_hwframe+0x3e/0xbe ? do_syscall_64+0x1d/0x470 do_syscall_64+0x9e/0x470 entry_SYSCALL_64_after_hwframe+0x49/0xbe Fixes: 3c86aa70bf67 ("RDMA/cm: Add RDMA CM support for IBoE devices") Link: https://lore.kernel.org/r/20200318101741.47211-1-leon@kernel.org Signed-off-by: Avihai Horon Reviewed-by: Maor Gottlieb Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit dbed22f174d807633d6d569857901bcb26d4c393 Author: Qiujun Huang Date: Sun Mar 8 17:45:27 2020 +0800 Bluetooth: RFCOMM: fix ODEBUG bug in rfcomm_dev_ioctl commit 71811cac8532b2387b3414f7cd8fe9e497482864 upstream. Needn't call 'rfcomm_dlc_put' here, because 'rfcomm_dlc_exists' didn't increase dlc->refcnt. Reported-by: syzbot+4496e82090657320efc6@syzkaller.appspotmail.com Signed-off-by: Qiujun Huang Suggested-by: Hillf Danton Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit ee114957ff52009ab77a40bc626b0a44caf608a3 Author: Bernard Metzler Date: Fri Feb 28 18:35:34 2020 +0100 RDMA/siw: Fix passive connection establishment commit 33fb27fd54465c74cbffba6315b2f043e90cec4c upstream. Holding the rtnl_lock while iterating a devices interface address list potentially causes deadlocks with the cma_netdev_callback. While this was implemented to limit the scope of a wildcard listen to addresses of the current device only, a better solution limits the scope of the socket to the device. This completely avoiding locking, and also results in significant code simplification. Fixes: c421651fa229 ("RDMA/siw: Add missing rtnl_lock around access to ifa") Link: https://lore.kernel.org/r/20200228173534.26815-1-bmt@zurich.ibm.com Reported-by: syzbot+55de90ab5f44172b0c90@syzkaller.appspotmail.com Suggested-by: Jason Gunthorpe Signed-off-by: Bernard Metzler Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 157391c38676134a6d69959638f9e4df784e1b68 Author: Jason Gunthorpe Date: Thu Feb 27 16:36:51 2020 -0400 RDMA/cma: Teach lockdep about the order of rtnl and lock commit 32ac9e4399b12d3e54d312a0e0e30ed5cd19bd4e upstream. This lock ordering only happens when bonding is enabled and a certain bonding related event fires. However, since it can happen this is a global restriction on lock ordering. Teach lockdep about the order directly and unconditionally so bugs here are found quickly. See https://syzkaller.appspot.com/bug?extid=55de90ab5f44172b0c90 Link: https://lore.kernel.org/r/20200227203651.GA27185@ziepe.ca Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit b538f04af4ea3d60ce274bf8107349f71b2298e5 Author: Jason Gunthorpe Date: Tue Feb 18 15:45:38 2020 -0400 RDMA/ucma: Put a lock around every call to the rdma_cm layer commit 7c11910783a1ea17e88777552ef146cace607b3c upstream. The rdma_cm must be used single threaded. This appears to be a bug in the design, as it does have lots of locking that seems like it should allow concurrency. However, when it is all said and done every single place that uses the cma_exch() scheme is broken, and all the unlocked reads from the ucma of the cm_id data are wrong too. syzkaller has been finding endless bugs related to this. Fixing this in any elegant way is some enormous amount of work. Take a very big hammer and put a mutex around everything to do with the ucma_context at the top of every syscall. Fixes: 75216638572f ("RDMA/cma: Export rdma cm interface to userspace") Link: https://lore.kernel.org/r/20200218210432.GA31966@ziepe.ca Reported-by: syzbot+adb15cf8c2798e4e0db4@syzkaller.appspotmail.com Reported-by: syzbot+e5579222b6a3edd96522@syzkaller.appspotmail.com Reported-by: syzbot+4b628fcc748474003457@syzkaller.appspotmail.com Reported-by: syzbot+29ee8f76017ce6cf03da@syzkaller.appspotmail.com Reported-by: syzbot+6956235342b7317ec564@syzkaller.appspotmail.com Reported-by: syzbot+b358909d8d01556b790b@syzkaller.appspotmail.com Reported-by: syzbot+6b46b135602a3f3ac99e@syzkaller.appspotmail.com Reported-by: syzbot+8458d13b13562abf6b77@syzkaller.appspotmail.com Reported-by: syzbot+bd034f3fdc0402e942ed@syzkaller.appspotmail.com Reported-by: syzbot+c92378b32760a4eef756@syzkaller.appspotmail.com Reported-by: syzbot+68b44a1597636e0b342c@syzkaller.appspotmail.com Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit e401ca7a383ead8f6b54b18d05fd28f7bf7fd4ff Author: Hou Tao Date: Mon Feb 10 21:26:34 2020 +0800 ubi: fastmap: Free unused fastmap anchor peb during detach commit c16f39d14a7e0ec59881fbdb22ae494907534384 upstream. When CONFIG_MTD_UBI_FASTMAP is enabled, fm_anchor will be assigned a free PEB during ubi_wl_init() or ubi_update_fastmap(). However if fastmap is not used or disabled on the MTD device, ubi_wl_entry related with the PEB will not be freed during detach. So Fix it by freeing the unused fastmap anchor during detach. Fixes: f9c34bb52997 ("ubi: Fix producing anchor PEBs") Reported-by: syzbot+f317896aae32eb281a58@syzkaller.appspotmail.com Reviewed-by: Sascha Hauer Signed-off-by: Hou Tao Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit daa6d912cd7536e98c056723e850ff41f673179c Author: Christian Borntraeger Date: Thu Feb 20 20:04:03 2020 -0800 include/uapi/linux/swab.h: fix userspace breakage, use __BITS_PER_LONG for swap commit 467d12f5c7842896d2de3ced74e4147ee29e97c8 upstream. QEMU has a funny new build error message when I use the upstream kernel headers: CC block/file-posix.o In file included from /home/cborntra/REPOS/qemu/include/qemu/timer.h:4, from /home/cborntra/REPOS/qemu/include/qemu/timed-average.h:29, from /home/cborntra/REPOS/qemu/include/block/accounting.h:28, from /home/cborntra/REPOS/qemu/include/block/block_int.h:27, from /home/cborntra/REPOS/qemu/block/file-posix.c:30: /usr/include/linux/swab.h: In function `__swab': /home/cborntra/REPOS/qemu/include/qemu/bitops.h:20:34: error: "sizeof" is not defined, evaluates to 0 [-Werror=undef] 20 | #define BITS_PER_LONG (sizeof (unsigned long) * BITS_PER_BYTE) | ^~~~~~ /home/cborntra/REPOS/qemu/include/qemu/bitops.h:20:41: error: missing binary operator before token "(" 20 | #define BITS_PER_LONG (sizeof (unsigned long) * BITS_PER_BYTE) | ^ cc1: all warnings being treated as errors make: *** [/home/cborntra/REPOS/qemu/rules.mak:69: block/file-posix.o] Error 1 rm tests/qemu-iotests/socket_scm_helper.o This was triggered by commit d5767057c9a ("uapi: rename ext2_swab() to swab() and share globally in swab.h"). That patch is doing #include but it uses BITS_PER_LONG. The kernel file asm/bitsperlong.h provide only __BITS_PER_LONG. Let us use the __ variant in swap.h Link: http://lkml.kernel.org/r/20200213142147.17604-1-borntraeger@de.ibm.com Fixes: d5767057c9a ("uapi: rename ext2_swab() to swab() and share globally in swab.h") Signed-off-by: Christian Borntraeger Cc: Yury Norov Cc: Allison Randal Cc: Joe Perches Cc: Thomas Gleixner Cc: William Breathitt Gray Cc: Torsten Hilbrich Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bbdeb8fdcfa8cf427a739db2c14e986b302b6831 Author: Kees Cook Date: Wed Apr 1 21:04:23 2020 -0700 slub: improve bit diffusion for freelist ptr obfuscation commit 1ad53d9fa3f6168ebcf48a50e08b170432da2257 upstream. Under CONFIG_SLAB_FREELIST_HARDENED=y, the obfuscation was relatively weak in that the ptr and ptr address were usually so close that the first XOR would result in an almost entirely 0-byte value[1], leaving most of the "secret" number ultimately being stored after the third XOR. A single blind memory content exposure of the freelist was generally sufficient to learn the secret. Add a swab() call to mix bits a little more. This is a cheap way (1 cycle) to make attacks need more than a single exposure to learn the secret (or to know _where_ the exposure is in memory). kmalloc-32 freelist walk, before: ptr ptr_addr stored value secret ffff90c22e019020@ffff90c22e019000 is 86528eb656b3b5bd (86528eb656b3b59d) ffff90c22e019040@ffff90c22e019020 is 86528eb656b3b5fd (86528eb656b3b59d) ffff90c22e019060@ffff90c22e019040 is 86528eb656b3b5bd (86528eb656b3b59d) ffff90c22e019080@ffff90c22e019060 is 86528eb656b3b57d (86528eb656b3b59d) ffff90c22e0190a0@ffff90c22e019080 is 86528eb656b3b5bd (86528eb656b3b59d) ... after: ptr ptr_addr stored value secret ffff9eed6e019020@ffff9eed6e019000 is 793d1135d52cda42 (86528eb656b3b59d) ffff9eed6e019040@ffff9eed6e019020 is 593d1135d52cda22 (86528eb656b3b59d) ffff9eed6e019060@ffff9eed6e019040 is 393d1135d52cda02 (86528eb656b3b59d) ffff9eed6e019080@ffff9eed6e019060 is 193d1135d52cdae2 (86528eb656b3b59d) ffff9eed6e0190a0@ffff9eed6e019080 is f93d1135d52cdac2 (86528eb656b3b59d) [1] https://blog.infosectcbr.com.au/2020/03/weaknesses-in-linux-kernel-heap.html Fixes: 2482ddec670f ("mm: add SLUB free list pointer obfuscation") Reported-by: Silvio Cesare Signed-off-by: Kees Cook Signed-off-by: Andrew Morton Cc: Christoph Lameter Cc: Pekka Enberg Cc: David Rientjes Cc: Joonsoo Kim Cc: Link: http://lkml.kernel.org/r/202003051623.AF4F8CB@keescook Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b83fb35b0300f810f44537ca15277e6b3e3f4aed Author: Yury Norov Date: Thu Jan 30 22:16:40 2020 -0800 uapi: rename ext2_swab() to swab() and share globally in swab.h commit d5767057c9a76a29f073dad66b7fa12a90e8c748 upstream. ext2_swab() is defined locally in lib/find_bit.c However it is not specific to ext2, neither to bitmaps. There are many potential users of it, so rename it to just swab() and move to include/uapi/linux/swab.h ABI guarantees that size of unsigned long corresponds to BITS_PER_LONG, therefore drop unneeded cast. Link: http://lkml.kernel.org/r/20200103202846.21616-1-yury.norov@gmail.com Signed-off-by: Yury Norov Cc: Allison Randal Cc: Joe Perches Cc: Thomas Gleixner Cc: William Breathitt Gray Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0ac798074dfd5273e5f514e634bb9effbf5ebafd Author: Thinh Nguyen Date: Thu Mar 5 13:24:01 2020 -0800 usb: dwc3: gadget: Wrap around when skip TRBs commit 2dedea035ae82c5af0595637a6eda4655532b21e upstream. When skipping TRBs, we need to account for wrapping around the ring buffer and not modifying some invalid TRBs. Without this fix, dwc3 won't be able to check for available TRBs. Cc: stable Fixes: 7746a8dfb3f9 ("usb: dwc3: gadget: extract dwc3_gadget_ep_skip_trbs()") Signed-off-by: Thinh Nguyen Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 2a00767b35c3536602f94e27e0e3faa7819b22c7 Author: Jason A. Donenfeld Date: Fri Feb 21 21:10:37 2020 +0100 random: always use batched entropy for get_random_u{32,64} commit 69efea712f5b0489e67d07565aad5c94e09a3e52 upstream. It turns out that RDRAND is pretty slow. Comparing these two constructions: for (i = 0; i < CHACHA_BLOCK_SIZE; i += sizeof(ret)) arch_get_random_long(&ret); and long buf[CHACHA_BLOCK_SIZE / sizeof(long)]; extract_crng((u8 *)buf); it amortizes out to 352 cycles per long for the top one and 107 cycles per long for the bottom one, on Coffee Lake Refresh, Intel Core i9-9880H. And importantly, the top one has the drawback of not benefiting from the real rng, whereas the bottom one has all the nice benefits of using our own chacha rng. As get_random_u{32,64} gets used in more places (perhaps beyond what it was originally intended for when it was introduced as get_random_{int,long} back in the md5 monstrosity era), it seems like it might be a good thing to strengthen its posture a tiny bit. Doing this should only be stronger and not any weaker because that pool is already initialized with a bunch of rdrand data (when available). This way, we get the benefits of the hardware rng as well as our own rng. Another benefit of this is that we no longer hit pitfalls of the recent stream of AMD bugs in RDRAND. One often used code pattern for various things is: do { val = get_random_u32(); } while (hash_table_contains_key(val)); That recent AMD bug rendered that pattern useless, whereas we're really very certain that chacha20 output will give pretty distributed numbers, no matter what. So, this simplification seems better both from a security perspective and from a performance perspective. Signed-off-by: Jason A. Donenfeld Reviewed-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20200221201037.30231-1-Jason@zx2c4.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit c431ce39614ee1750e0ae380c524a282d2bb340e Author: Sven Schnelle Date: Wed Jan 22 13:38:22 2020 +0100 s390: prevent leaking kernel address in BEAR commit 0b38b5e1d0e2f361e418e05c179db05bb688bbd6 upstream. When userspace executes a syscall or gets interrupted, BEAR contains a kernel address when returning to userspace. This make it pretty easy to figure out where the kernel is mapped even with KASLR enabled. To fix this, add lpswe to lowcore and always execute it there, so userspace sees only the lowcore address of lpswe. For this we have to extend both critical_cleanup and the SWITCH_ASYNC macro to also check for lpswe addresses in lowcore. Fixes: b2d24b97b2a9 ("s390/kernel: add support for kernel address space layout randomization (KASLR)") Cc: # v5.2+ Reviewed-by: Gerald Schaefer Signed-off-by: Sven Schnelle Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 5914019dc23d7d0cf83c3fdb3f3e917a41f865ef Author: Oleksij Rempel Date: Wed Apr 1 11:57:32 2020 +0200 net: phy: at803x: fix clock sink configuration on ATH8030 and ATH8035 [ Upstream commit b1f4c209d84057b6d40b939b6e4404854271d797 ] The masks in priv->clk_25m_reg and priv->clk_25m_mask are one-bits-set for the values that comprise the fields, not zero-bits-set. This patch fixes the clock frequency configuration for ATH8030 and ATH8035 Atheros PHYs by removing the erroneous "~". To reproduce this bug, configure the PHY with the device tree binding "qca,clk-out-frequency" and remove the machine specific PHY fixups. Fixes: 2f664823a47021 ("net: phy: at803x: add device tree binding") Signed-off-by: Oleksij Rempel Reported-by: Russell King Reviewed-by: Russell King Tested-by: Russell King Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 200482d2e8715741ff7e85735980b01d7e0da012 Author: Rahul Lakkireddy Date: Wed Apr 1 01:17:01 2020 +0530 cxgb4: free MQPRIO resources in shutdown path [ Upstream commit cef8dac96bc108633f5090bb3a9988d734dc1ee0 ] Perform missing MQPRIO resource cleanup in PCI shutdown path. Also, fix MQPRIO MSIX bitmap leak in resource cleanup. Fixes: b1396c2bd675 ("cxgb4: parse and configure TC-MQPRIO offload") Signed-off-by: Rahul Lakkireddy Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4de78bededafc1ee38038c6f552759ef2c36ae84 Author: Heiner Kallweit Date: Sat Apr 4 23:48:45 2020 +0200 r8169: change back SG and TSO to be disabled by default [ Upstream commit 95099c569a9fdbe186a27447dfa8a5a0562d4b7f ] There has been a number of reports that using SG/TSO on different chip versions results in tx timeouts. However for a lot of people SG/TSO works fine. Therefore disable both features by default, but allow users to enable them. Use at own risk! Fixes: 93681cd7d94f ("r8169: enable HW csum and TSO") Signed-off-by: Heiner Kallweit Signed-off-by: Greg Kroah-Hartman commit 6628deb61b0fd29349a9048c21fbaaecae3ba1a1 Author: Petr Machata Date: Sun Apr 5 09:50:22 2020 +0300 mlxsw: spectrum_flower: Do not stop at FLOW_ACTION_VLAN_MANGLE [ Upstream commit ccfc569347f870830e7c7cf854679a06cf9c45b5 ] The handler for FLOW_ACTION_VLAN_MANGLE ends by returning whatever the lower-level function that it calls returns. If there are more actions lined up after this action, those are never offloaded. Fix by only bailing out when the called function returns an error. Fixes: a150201a70da ("mlxsw: spectrum: Add support for vlan modify TC action") Signed-off-by: Petr Machata Reviewed-by: Jiri Pirko Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b97bd356fcf80a32157262b645c17dbae39d10a8 Author: Will Deacon Date: Fri Apr 3 16:13:21 2020 +0100 tun: Don't put_page() for all negative return values from XDP program [ Upstream commit bee348907d19d654e8524d3a946dcd25b693aa7e ] When an XDP program is installed, tun_build_skb() grabs a reference to the current page fragment page if the program returns XDP_REDIRECT or XDP_TX. However, since tun_xdp_act() passes through negative return values from the XDP program, it is possible to trigger the error path by mistake and accidentally drop a reference to the fragments page without taking one, leading to a spurious free. This is believed to be the cause of some KASAN use-after-free reports from syzbot [1], although without a reproducer it is not possible to confirm whether this patch fixes the problem. Ensure that we only drop a reference to the fragments page if the XDP transmit or redirect operations actually fail. [1] https://syzkaller.appspot.com/bug?id=e76a6af1be4acd727ff6bbca669833f98cbf5d95 Cc: "David S. Miller" Cc: Alexei Starovoitov Cc: Daniel Borkmann CC: Eric Dumazet Acked-by: Jason Wang Fixes: 8ae1aff0b331 ("tuntap: split out XDP logic") Signed-off-by: Will Deacon Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 51fafff685ba3b1228e1def7d79094a951585574 Author: Richard Palethorpe Date: Wed Apr 1 12:06:39 2020 +0200 slcan: Don't transmit uninitialized stack data in padding [ Upstream commit b9258a2cece4ec1f020715fe3554bc2e360f6264 ] struct can_frame contains some padding which is not explicitly zeroed in slc_bump. This uninitialized data will then be transmitted if the stack initialization hardening feature is not enabled (CONFIG_INIT_STACK_ALL). This commit just zeroes the whole struct including the padding. Signed-off-by: Richard Palethorpe Fixes: a1044e36e457 ("can: add slcan driver for serial/USB-serial CAN adapters") Reviewed-by: Kees Cook Cc: linux-can@vger.kernel.org Cc: netdev@vger.kernel.org Cc: security@kernel.org Cc: wg@grandegger.com Cc: mkl@pengutronix.de Cc: davem@davemloft.net Acked-by: Marc Kleine-Budde Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 12bec59386ce2385642795ebb1d5a5a9248f0d72 Author: Jisheng Zhang Date: Fri Apr 3 10:23:29 2020 +0800 net: stmmac: dwmac1000: fix out-of-bounds mac address reg setting [ Upstream commit 3e1221acf6a8f8595b5ce354bab4327a69d54d18 ] Commit 9463c4455900 ("net: stmmac: dwmac1000: Clear unused address entries") cleared the unused mac address entries, but introduced an out-of bounds mac address register programming bug -- After setting the secondary unicast mac addresses, the "reg" value has reached netdev_uc_count() + 1, thus we should only clear address entries if (addr < perfect_addr_number) Fixes: 9463c4455900 ("net: stmmac: dwmac1000: Clear unused address entries") Signed-off-by: Jisheng Zhang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 469f92c834de058de6b95d393130aacb0aa88043 Author: Cong Wang Date: Thu Apr 2 20:58:51 2020 -0700 net_sched: fix a missing refcnt in tcindex_init() [ Upstream commit a8eab6d35e22f4f21471f16147be79529cd6aaf7 ] The initial refcnt of struct tcindex_data should be 1, it is clear that I forgot to set it to 1 in tcindex_init(). This leads to a dec-after-zero warning. Reported-by: syzbot+8325e509a1bf83ec741d@syzkaller.appspotmail.com Fixes: 304e024216a8 ("net_sched: add a temporary refcnt for struct tcindex_data") Cc: Jamal Hadi Salim Cc: Jiri Pirko Cc: Paul E. McKenney Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ac4979442a84c5a7f5cd96e2bdb5235f2c78f2a6 Author: Cong Wang Date: Sat Mar 28 12:12:59 2020 -0700 net_sched: add a temporary refcnt for struct tcindex_data [ Upstream commit 304e024216a802a7dc8ba75d36de82fa136bbf3e ] Although we intentionally use an ordered workqueue for all tc filter works, the ordering is not guaranteed by RCU work, given that tcf_queue_work() is esstenially a call_rcu(). This problem is demostrated by Thomas: CPU 0: tcf_queue_work() tcf_queue_work(&r->rwork, tcindex_destroy_rexts_work); -> Migration to CPU 1 CPU 1: tcf_queue_work(&p->rwork, tcindex_destroy_work); so the 2nd work could be queued before the 1st one, which leads to a free-after-free. Enforcing this order in RCU work is hard as it requires to change RCU code too. Fortunately we can workaround this problem in tcindex filter by taking a temporary refcnt, we only refcnt it right before we begin to destroy it. This simplifies the code a lot as a full refcnt requires much more changes in tcindex_set_parms(). Reported-by: syzbot+46f513c3033d592409d2@syzkaller.appspotmail.com Fixes: 3d210534cc93 ("net_sched: fix a race condition in tcindex_destroy()") Cc: Thomas Gleixner Cc: Paul E. McKenney Cc: Jamal Hadi Salim Cc: Jiri Pirko Signed-off-by: Cong Wang Reviewed-by: Paul E. McKenney Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 28433acda1a7a530afe96ee1ebd4f40e5f7d93e5 Author: Oleksij Rempel Date: Fri Apr 3 09:53:25 2020 +0200 net: phy: micrel: kszphy_resume(): add delay after genphy_resume() before accessing PHY registers [ Upstream commit 6110dff776f7fa65c35850ef65b41d3b39e2fac2 ] After the power-down bit is cleared, the chip internally triggers a global reset. According to the KSZ9031 documentation, we have to wait at least 1ms for the reset to finish. If the chip is accessed during reset, read will return 0xffff, while write will be ignored. Depending on the system performance and MDIO bus speed, we may or may not run in to this issue. This bug was discovered on an iMX6QP system with KSZ9031 PHY and attached PHY interrupt line. If IRQ was used, the link status update was lost. In polling mode, the link status update was always correct. The investigation showed, that during a read-modify-write access, the read returned 0xffff (while the chip was still in reset) and corresponding write hit the chip _after_ reset and triggered (due to the 0xffff) another reset in an undocumented bit (register 0x1f, bit 1), resulting in the next write being lost due to the new reset cycle. This patch fixes the issue by adding a 1...2 ms sleep after the genphy_resume(). Fixes: 836384d2501d ("net: phy: micrel: Add specific suspend") Signed-off-by: Oleksij Rempel Reviewed-by: Andrew Lunn Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4c0fc5b184fc589b7b993411a7162f72c4660593 Author: Chuanhong Guo Date: Fri Apr 3 19:28:24 2020 +0800 net: dsa: mt7530: fix null pointer dereferencing in port5 setup [ Upstream commit 0452800f6db4ed0a42ffb15867c0acfd68829f6a ] The 2nd gmac of mediatek soc ethernet may not be connected to a PHY and a phy-handle isn't always available. Unfortunately, mt7530 dsa driver assumes that the 2nd gmac is always connected to switch port 5 and setup mt7530 according to phy address of 2nd gmac node, causing null pointer dereferencing when phy-handle isn't defined in dts. This commit fix this setup code by checking return value of of_parse_phandle before using it. Fixes: 38f790a80560 ("net: dsa: mt7530: Add support for port 5") Signed-off-by: Chuanhong Guo Reviewed-by: Vivien Didelot Reviewed-by: Florian Fainelli Tested-by: René van Dorst Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e02afb9be9f72d5c2c3b9248638d56939300086b Author: Florian Fainelli Date: Sun Apr 5 13:00:30 2020 -0700 net: dsa: bcm_sf2: Ensure correct sub-node is parsed [ Upstream commit afa3b592953bfaecfb4f2f335ec5f935cff56804 ] When the bcm_sf2 was converted into a proper platform device driver and used the new dsa_register_switch() interface, we would still be parsing the legacy DSA node that contained all the port information since the platform firmware has intentionally maintained backward and forward compatibility to client programs. Ensure that we do parse the correct node, which is "ports" per the revised DSA binding. Fixes: d9338023fb8e ("net: dsa: bcm_sf2: Make it a real platform device driver") Signed-off-by: Florian Fainelli Reviewed-by: Vivien Didelot Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3e1701448571b09c3540f2edf7c17237cd9acc0e Author: Florian Fainelli Date: Sat Apr 4 14:35:17 2020 -0700 net: dsa: bcm_sf2: Do not register slave MDIO bus with OF [ Upstream commit 536fab5bf5826404534a6c271f622ad2930d9119 ] We were registering our slave MDIO bus with OF and doing so with assigning the newly created slave_mii_bus of_node to the master MDIO bus controller node. This is a bad thing to do for a number of reasons: - we are completely lying about the slave MII bus is arranged and yet we still want to control which MDIO devices it probes. It was attempted before to play tricks with the bus_mask to perform that: https://www.spinics.net/lists/netdev/msg429420.html but the approach was rightfully rejected - the device_node reference counting is messed up and we are effectively doing a double probe on the devices we already probed using the master, this messes up all resources reference counts (such as clocks) The proper fix for this as indicated by David in his reply to the thread above is to use a platform data style registration so as to control exactly which devices we probe: https://www.spinics.net/lists/netdev/msg430083.html By using mdiobus_register(), our slave_mii_bus->phy_mask value is used as intended, and all the PHY addresses that must be redirected towards our slave MDIO bus is happening while other addresses get redirected towards the master MDIO bus. Fixes: 461cd1b03e32 ("net: dsa: bcm_sf2: Register our slave MDIO bus") Signed-off-by: Florian Fainelli Reviewed-by: Vivien Didelot Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 139380fc0e9c03c250b560be1bc612e6a099945d Author: Jarod Wilson Date: Mon Mar 30 11:22:19 2020 -0400 ipv6: don't auto-add link-local address to lag ports [ Upstream commit 744fdc8233f6aa9582ce08a51ca06e59796a3196 ] Bonding slave and team port devices should not have link-local addresses automatically added to them, as it can interfere with openvswitch being able to properly add tc ingress. Basic reproducer, courtesy of Marcelo: $ ip link add name bond0 type bond $ ip link set dev ens2f0np0 master bond0 $ ip link set dev ens2f1np2 master bond0 $ ip link set dev bond0 up $ ip a s 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens2f0np0: mtu 1500 qdisc mq master bond0 state UP group default qlen 1000 link/ether 00:0f:53:2f:ea:40 brd ff:ff:ff:ff:ff:ff 5: ens2f1np2: mtu 1500 qdisc mq master bond0 state DOWN group default qlen 1000 link/ether 00:0f:53:2f:ea:40 brd ff:ff:ff:ff:ff:ff 11: bond0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:0f:53:2f:ea:40 brd ff:ff:ff:ff:ff:ff inet6 fe80::20f:53ff:fe2f:ea40/64 scope link valid_lft forever preferred_lft forever (above trimmed to relevant entries, obviously) $ sysctl net.ipv6.conf.ens2f0np0.addr_gen_mode=0 net.ipv6.conf.ens2f0np0.addr_gen_mode = 0 $ sysctl net.ipv6.conf.ens2f1np2.addr_gen_mode=0 net.ipv6.conf.ens2f1np2.addr_gen_mode = 0 $ ip a l ens2f0np0 2: ens2f0np0: mtu 1500 qdisc mq master bond0 state UP group default qlen 1000 link/ether 00:0f:53:2f:ea:40 brd ff:ff:ff:ff:ff:ff inet6 fe80::20f:53ff:fe2f:ea40/64 scope link tentative valid_lft forever preferred_lft forever $ ip a l ens2f1np2 5: ens2f1np2: mtu 1500 qdisc mq master bond0 state DOWN group default qlen 1000 link/ether 00:0f:53:2f:ea:40 brd ff:ff:ff:ff:ff:ff inet6 fe80::20f:53ff:fe2f:ea40/64 scope link tentative valid_lft forever preferred_lft forever Looks like addrconf_sysctl_addr_gen_mode() bypasses the original "is this a slave interface?" check added by commit c2edacf80e15, and results in an address getting added, while w/the proposed patch added, no address gets added. This simply adds the same gating check to another code path, and thus should prevent the same devices from erroneously obtaining an ipv6 link-local address. Fixes: d35a00b8e33d ("net/ipv6: allow sysctl to change link-local address generation mode") Reported-by: Moshe Levi CC: Stephen Hemminger CC: Marcelo Ricardo Leitner CC: netdev@vger.kernel.org Signed-off-by: Jarod Wilson Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit edbcbf1281149bf51a47a23ce0c617b049e0175e Author: Herat Ramani Date: Wed Apr 1 01:16:09 2020 +0530 cxgb4: fix MPS index overwrite when setting MAC address [ Upstream commit 41aa8561ca3fc5748391f08cc5f3e561923da52c ] cxgb4_update_mac_filt() earlier requests firmware to add a new MAC address into MPS TCAM. The MPS TCAM index returned by firmware is stored in pi->xact_addr_filt. However, the saved MPS TCAM index gets overwritten again with the return value of cxgb4_update_mac_filt(), which is wrong. When trying to update to another MAC address later, the wrong MPS TCAM index is sent to firmware, which causes firmware to return error, because it's not the same MPS TCAM index that firmware had sent earlier to driver. So, fix by removing the wrong overwrite being done after call to cxgb4_update_mac_filt(). Fixes: 3f8cfd0d95e6 ("cxgb4/cxgb4vf: Program hash region for {t4/t4vf}_change_mac()") Signed-off-by: Herat Ramani Signed-off-by: Rahul Lakkireddy Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman