commit 472493c8a425f62200882c2c6acb1be2e29b3c03 Author: Greg Kroah-Hartman Date: Tue Mar 30 14:32:09 2021 +0200 Linux 5.10.27 Tested-by: Andrei Rabusov Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Jason Self Tested-by: Hulk Robot Tested-by: Shuah Khan Tested-by: Linux Kernel Functional Testing Tested-by: Jon Hunter Link: https://lore.kernel.org/r/20210329101340.196712908@linuxfoundation.org Link: https://lore.kernel.org/r/20210329075629.172032742@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 3a1ca9bd4f5a647439e82e07b03d072781d9d180 Author: Jan Beulich Date: Fri Mar 26 16:28:57 2021 +0100 xen-blkback: don't leak persistent grants from xen_blkbk_map() commit a846738f8c3788d846ed1f587270d2f2e3d32432 upstream. The fix for XSA-365 zapped too many of the ->persistent_gnt[] entries. Ones successfully obtained should not be overwritten, but instead left for xen_blkbk_unmap_prepare() to pick up and put. This is XSA-371. Signed-off-by: Jan Beulich Cc: stable@vger.kernel.org Reviewed-by: Juergen Gross Reviewed-by: Wei Liu Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 03a1c3253f25c7752999d2deb4809514599e346d Author: Marc Kleine-Budde Date: Sat Mar 20 20:21:54 2021 +0100 can: peak_usb: Revert "can: peak_usb: add forgotten supported devices" commit 5d7047ed6b7214fbabc16d8712a822e256b1aa44 upstream. In commit 6417f03132a6 ("module: remove never implemented MODULE_SUPPORTED_DEVICE") the MODULE_SUPPORTED_DEVICE macro was removed from the kerne entirely. Shortly before this patch was applied mainline the commit 59ec7b89ed3e ("can: peak_usb: add forgotten supported devices") was added to net/master. As this would result in a merge conflict, let's revert this patch. Fixes: 59ec7b89ed3e ("can: peak_usb: add forgotten supported devices") Link: https://lore.kernel.org/r/20210320192649.341832-1-mkl@pengutronix.de Suggested-by: Leon Romanovsky Cc: Stephane Grosjean Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit f12d05f70282df0af59ee891f5cbfe147c1d9a41 Author: Christoph Hellwig Date: Fri Mar 12 20:55:36 2021 +0100 nvme: fix the nsid value to print in nvme_validate_or_alloc_ns commit f4f9fc29e56b6fa9d7fa65ec51d3c82aff99c99b upstream. ns can be NULL at this point, and my move of the check from the original patch by Chaitanya broke this. Fixes: 0ec84df4953b ("nvme-core: check ctrl css before setting up zns") Signed-off-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 36478a9ec5afd4efd031527d0371bf8f61e5aa91 Author: David S. Miller Date: Fri Mar 12 12:15:03 2021 -0800 Revert "net: bonding: fix error return code of bond_neigh_init()" commit 080bfa1e6d928a5d1f185cc44e5f3c251df06df5 upstream. This reverts commit 2055a99da8a253a357bdfd359b3338ef3375a26c. This change rejects legitimate configurations. A slave doesn't need to exist nor implement ndo_slave_setup. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 451ba16cc5b79518b4804eaeed7c8260733f95cb Author: Roger Pau Monne Date: Wed Mar 24 13:24:24 2021 +0100 Revert "xen: fix p2m size in dom0 for disabled memory hotplug case" commit af44a387e743ab7aa39d3fb5e29c0a973cf91bdc upstream. This partially reverts commit 882213990d32 ("xen: fix p2m size in dom0 for disabled memory hotplug case") There's no need to special case XEN_UNPOPULATED_ALLOC anymore in order to correctly size the p2m. The generic memory hotplug option has already been tied together with the Xen hotplug limit, so enabling memory hotplug should already trigger a properly sized p2m on Xen PV. Note that XEN_UNPOPULATED_ALLOC depends on ZONE_DEVICE which pulls in MEMORY_HOTPLUG. Leave the check added to __set_phys_to_machine and the adjusted comment about EXTRA_MEM_RATIO. Signed-off-by: Roger Pau Monné Reviewed-by: Boris Ostrovsky Link: https://lore.kernel.org/r/20210324122424.58685-3-roger.pau@citrix.com Signed-off-by: Greg Kroah-Hartman [boris: fixed formatting issues] Signed-off-by: Boris Ostrovsky commit df61d3cff422433527d3bc388f69484f0781d226 Author: Sabyrzhan Tasbolatov Date: Wed Feb 24 15:58:00 2021 +0600 fs/ext4: fix integer overflow in s_log_groups_per_flex commit f91436d55a279f045987e8b8c1385585dca54be9 upstream. syzbot found UBSAN: shift-out-of-bounds in ext4_mb_init [1], when 1 << sbi->s_es->s_log_groups_per_flex is bigger than UINT_MAX, where sbi->s_mb_prefetch is unsigned integer type. 32 is the maximum allowed power of s_log_groups_per_flex. Following if check will also trigger UBSAN shift-out-of-bound: if (1 << sbi->s_es->s_log_groups_per_flex >= UINT_MAX) { So I'm checking it against the raw number, perhaps there is another way to calculate UINT_MAX max power. Also use min_t as to make sure it's uint type. [1] UBSAN: shift-out-of-bounds in fs/ext4/mballoc.c:2713:24 shift exponent 60 is too large for 32-bit type 'int' Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x137/0x1be lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:148 [inline] __ubsan_handle_shift_out_of_bounds+0x432/0x4d0 lib/ubsan.c:395 ext4_mb_init_backend fs/ext4/mballoc.c:2713 [inline] ext4_mb_init+0x19bc/0x19f0 fs/ext4/mballoc.c:2898 ext4_fill_super+0xc2ec/0xfbe0 fs/ext4/super.c:4983 Reported-by: syzbot+a8b4b0c60155e87e9484@syzkaller.appspotmail.com Signed-off-by: Sabyrzhan Tasbolatov Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20210224095800.3350002-1-snovitoll@gmail.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 0229b5926dc980f4f1094c7aae72727520363a6a Author: Jan Kara Date: Mon Feb 22 18:16:26 2021 +0100 ext4: add reclaim checks to xattr code commit 163f0ec1df33cf468509ff38cbcbb5eb0d7fac60 upstream. Syzbot is reporting that ext4 can enter fs reclaim from kvmalloc() while the transaction is started like: fs_reclaim_acquire+0x117/0x150 mm/page_alloc.c:4340 might_alloc include/linux/sched/mm.h:193 [inline] slab_pre_alloc_hook mm/slab.h:493 [inline] slab_alloc_node mm/slub.c:2817 [inline] __kmalloc_node+0x5f/0x430 mm/slub.c:4015 kmalloc_node include/linux/slab.h:575 [inline] kvmalloc_node+0x61/0xf0 mm/util.c:587 kvmalloc include/linux/mm.h:781 [inline] ext4_xattr_inode_cache_find fs/ext4/xattr.c:1465 [inline] ext4_xattr_inode_lookup_create fs/ext4/xattr.c:1508 [inline] ext4_xattr_set_entry+0x1ce6/0x3780 fs/ext4/xattr.c:1649 ext4_xattr_ibody_set+0x78/0x2b0 fs/ext4/xattr.c:2224 ext4_xattr_set_handle+0x8f4/0x13e0 fs/ext4/xattr.c:2380 ext4_xattr_set+0x13a/0x340 fs/ext4/xattr.c:2493 This should be impossible since transaction start sets PF_MEMALLOC_NOFS. Add some assertions to the code to catch if something isn't working as expected early. Link: https://lore.kernel.org/linux-ext4/000000000000563a0205bafb7970@google.com/ Signed-off-by: Jan Kara Link: https://lore.kernel.org/r/20210222171626.21884-1-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 25e809bf8bece0b167aeb4d1f543b9db540c98b6 Author: Markus Theil Date: Sat Feb 13 14:36:53 2021 +0100 mac80211: fix double free in ibss_leave commit 3bd801b14e0c5d29eeddc7336558beb3344efaa3 upstream. Clear beacon ie pointer and ie length after free in order to prevent double free. ================================================================== BUG: KASAN: double-free or invalid-free \ in ieee80211_ibss_leave+0x83/0xe0 net/mac80211/ibss.c:1876 CPU: 0 PID: 8472 Comm: syz-executor100 Not tainted 5.11.0-rc6-syzkaller #0 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x107/0x163 lib/dump_stack.c:120 print_address_description.constprop.0.cold+0x5b/0x2c6 mm/kasan/report.c:230 kasan_report_invalid_free+0x51/0x80 mm/kasan/report.c:355 ____kasan_slab_free+0xcc/0xe0 mm/kasan/common.c:341 kasan_slab_free include/linux/kasan.h:192 [inline] __cache_free mm/slab.c:3424 [inline] kfree+0xed/0x270 mm/slab.c:3760 ieee80211_ibss_leave+0x83/0xe0 net/mac80211/ibss.c:1876 rdev_leave_ibss net/wireless/rdev-ops.h:545 [inline] __cfg80211_leave_ibss+0x19a/0x4c0 net/wireless/ibss.c:212 __cfg80211_leave+0x327/0x430 net/wireless/core.c:1172 cfg80211_leave net/wireless/core.c:1221 [inline] cfg80211_netdev_notifier_call+0x9e8/0x12c0 net/wireless/core.c:1335 notifier_call_chain+0xb5/0x200 kernel/notifier.c:83 call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:2040 call_netdevice_notifiers_extack net/core/dev.c:2052 [inline] call_netdevice_notifiers net/core/dev.c:2066 [inline] __dev_close_many+0xee/0x2e0 net/core/dev.c:1586 __dev_close net/core/dev.c:1624 [inline] __dev_change_flags+0x2cb/0x730 net/core/dev.c:8476 dev_change_flags+0x8a/0x160 net/core/dev.c:8549 dev_ifsioc+0x210/0xa70 net/core/dev_ioctl.c:265 dev_ioctl+0x1b1/0xc40 net/core/dev_ioctl.c:511 sock_do_ioctl+0x148/0x2d0 net/socket.c:1060 sock_ioctl+0x477/0x6a0 net/socket.c:1177 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:739 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Reported-by: syzbot+93976391bf299d425f44@syzkaller.appspotmail.com Signed-off-by: Markus Theil Link: https://lore.kernel.org/r/20210213133653.367130-1-markus.theil@tu-ilmenau.de Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 39e1a35ea65ab60bbc8fdd8d5c547ad77204b222 Author: Florian Fainelli Date: Wed Mar 10 10:46:10 2021 -0800 net: dsa: b53: VLAN filtering is global to all users commit d45c36bafb94e72fdb6dee437279b61b6d97e706 upstream. The bcm_sf2 driver uses the b53 driver as a library but does not make usre of the b53_setup() function, this made it fail to inherit the vlan_filtering_is_global attribute. Fix this by moving the assignment to b53_switch_alloc() which is used by bcm_sf2. Fixes: 7228b23e68f7 ("net: dsa: b53: Let DSA handle mismatched VLAN filtering settings") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d3b5a04b8ce51877c245fdb454d3a4f4ba86b74d Author: Heiner Kallweit Date: Sat Mar 20 21:40:08 2021 +0100 r8169: fix DMA being used after buffer free if WoL is enabled commit f658b90977d2e79822a558e48116e059a7e75dec upstream. IOMMU errors have been reported if WoL is enabled and interface is brought down. It turned out that the network chip triggers DMA transfers after the DMA buffers have been freed. For WoL to work we need to leave rx enabled, therefore simply stop the chip from being a DMA busmaster. Fixes: 567ca57faa62 ("r8169: add rtl8169_up") Tested-by: Paul Blazejowski Signed-off-by: Heiner Kallweit Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8dc08a2962c855f4a88923017445799474ff6446 Author: Martin Willi Date: Tue Mar 2 13:24:23 2021 +0100 can: dev: Move device back to init netns on owning netns delete commit 3a5ca857079ea022e0b1b17fc154f7ad7dbc150f upstream. When a non-initial netns is destroyed, the usual policy is to delete all virtual network interfaces contained, but move physical interfaces back to the initial netns. This keeps the physical interface visible on the system. CAN devices are somewhat special, as they define rtnl_link_ops even if they are physical devices. If a CAN interface is moved into a non-initial netns, destroying that netns lets the interface vanish instead of moving it back to the initial netns. default_device_exit() skips CAN interfaces due to having rtnl_link_ops set. Reproducer: ip netns add foo ip link set can0 netns foo ip netns delete foo WARNING: CPU: 1 PID: 84 at net/core/dev.c:11030 ops_exit_list+0x38/0x60 CPU: 1 PID: 84 Comm: kworker/u4:2 Not tainted 5.10.19 #1 Workqueue: netns cleanup_net [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0x94/0xa8) [] (dump_stack) from [] (__warn+0xb8/0x114) [] (__warn) from [] (warn_slowpath_fmt+0x7c/0xac) [] (warn_slowpath_fmt) from [] (ops_exit_list+0x38/0x60) [] (ops_exit_list) from [] (cleanup_net+0x230/0x380) [] (cleanup_net) from [] (process_one_work+0x1d8/0x438) [] (process_one_work) from [] (worker_thread+0x64/0x5a8) [] (worker_thread) from [] (kthread+0x148/0x14c) [] (kthread) from [] (ret_from_fork+0x14/0x2c) To properly restore physical CAN devices to the initial netns on owning netns exit, introduce a flag on rtnl_link_ops that can be set by drivers. For CAN devices setting this flag, default_device_exit() considers them non-virtual, applying the usual namespace move. The issue was introduced in the commit mentioned below, as at that time CAN devices did not have a dellink() operation. Fixes: e008b5fc8dc7 ("net: Simplfy default_device_exit and improve batching.") Link: https://lore.kernel.org/r/20210302122423.872326-1-martin@strongswan.org Signed-off-by: Martin Willi Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 24256b4d87eb8021e50826ccfbf4d0c03b483060 Author: Arnd Bergmann Date: Tue Mar 23 22:52:50 2021 +0100 ch_ktls: fix enum-conversion warning commit 6f235a69e59484e382dc31952025b0308efedc17 upstream. gcc points out an incorrect enum assignment: drivers/net/ethernet/chelsio/inline_crypto/ch_ktls/chcr_ktls.c: In function 'chcr_ktls_cpl_set_tcb_rpl': drivers/net/ethernet/chelsio/inline_crypto/ch_ktls/chcr_ktls.c:684:22: warning: implicit conversion from 'enum ' to 'enum ch_ktls_open_state' [-Wenum-conversion] This appears harmless, and should apparently use 'CH_KTLS_OPEN_SUCCESS' instead of 'false', with the same value '0'. Fixes: efca3878a5fb ("ch_ktls: Issue if connection offload fails") Reviewed-by: Andrew Lunn Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6f15c02ebbe9f6a6b255a3888e0f782887605b72 Author: Matthew Wilcox (Oracle) Date: Sat Mar 20 05:40:38 2021 +0000 fs/cachefiles: Remove wait_bit_key layout dependency commit 39f985c8f667c80a3d1eb19d31138032fa36b09e upstream. Cachefiles was relying on wait_page_key and wait_bit_key being the same layout, which is fragile. Now that wait_page_key is exposed in the pagemap.h header, we can remove that fragility A comment on the need to maintain structure layout equivalence was added by Linus[1] and that is no longer applicable. Fixes: 62906027091f ("mm: add PageWaiters indicating tasks are waiting for a page bit") Signed-off-by: Matthew Wilcox (Oracle) Reviewed-by: Christoph Hellwig Signed-off-by: David Howells Tested-by: kafs-testing@auristor.com cc: linux-cachefs@redhat.com cc: linux-mm@kvack.org Link: https://lore.kernel.org/r/20210320054104.1300774-2-willy@infradead.org/ Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3510ca20ece0150af6b10c77a74ff1b5c198e3e2 [1] Signed-off-by: Greg Kroah-Hartman commit 002ea848d7fd3bdcb6281e75bdde28095c2cd549 Author: Hugh Dickins Date: Sun Mar 28 17:13:13 2021 -0700 mm/memcg: fix 5.10 backport of splitting page memcg The straight backport of 5.12's e1baddf8475b ("mm/memcg: set memcg when splitting page") works fine in 5.11, but turned out to be wrong for 5.10: because that relies on a separate flag, which must also be set for the memcg to be recognized and uncharged and cleared when freeing. Fix that. Signed-off-by: Hugh Dickins Signed-off-by: Greg Kroah-Hartman commit 2c163520e12b6551e6482491b3cad3c84daa4626 Author: Isaku Yamahata Date: Thu Mar 18 13:26:57 2021 -0700 x86/mem_encrypt: Correct physical address calculation in __set_clr_pte_enc() commit 8249d17d3194eac064a8ca5bc5ca0abc86feecde upstream. The pfn variable contains the page frame number as returned by the pXX_pfn() functions, shifted to the right by PAGE_SHIFT to remove the page bits. After page protection computations are done to it, it gets shifted back to the physical address using page_level_shift(). That is wrong, of course, because that function determines the shift length based on the level of the page in the page table but in all the cases, it was shifted by PAGE_SHIFT before. Therefore, shift it back using PAGE_SHIFT to get the correct physical address. [ bp: Rewrite commit message. ] Fixes: dfaaec9033b8 ("x86: Add support for changing memory encryption attribute in early boot") Signed-off-by: Isaku Yamahata Signed-off-by: Borislav Petkov Reviewed-by: Kirill A. Shutemov Reviewed-by: Tom Lendacky Cc: Link: https://lkml.kernel.org/r/81abbae1657053eccc535c16151f63cd049dcb97.1616098294.git.isaku.yamahata@intel.com Signed-off-by: Greg Kroah-Hartman commit c6c9bc4f261d9c83d3ad81968ec0f8b6a2cc0ff4 Author: Thomas Gleixner Date: Mon Mar 22 09:46:13 2021 +0100 locking/mutex: Fix non debug version of mutex_lock_io_nested() commit 291da9d4a9eb3a1cb0610b7f4480f5b52b1825e7 upstream. If CONFIG_DEBUG_LOCK_ALLOC=n then mutex_lock_io_nested() maps to mutex_lock() which is clearly wrong because mutex_lock() lacks the io_schedule_prepare()/finish() invocations. Map it to mutex_lock_io(). Fixes: f21860bac05b ("locking/mutex, sched/wait: Fix the mutex_lock_io_nested() define") Signed-off-by: Thomas Gleixner Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/878s6fshii.fsf@nanos.tec.linutronix.de Signed-off-by: Greg Kroah-Hartman commit d4ce2a8f465dfa007298c6b156cf1b0033d6a2c3 Author: Shyam Prasad N Date: Thu Mar 25 12:34:54 2021 +0000 cifs: Adjust key sizes and key generation routines for AES256 encryption commit 45a4546c6167a2da348a31ca439d8a8ff773b6ea upstream. For AES256 encryption (GCM and CCM), we need to adjust the size of a few fields to 32 bytes instead of 16 to accommodate the larger keys. Also, the L value supplied to the key generator needs to be changed from to 256 when these algorithms are used. Keeping the ioctl struct for dumping keys of the same size for now. Will send out a different patch for that one. Signed-off-by: Shyam Prasad N Reviewed-by: Ronnie Sahlberg CC: # v5.10+ Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 86cc799e1d9d96358ed8fe4c868b42b2fd6c7646 Author: Steve French Date: Fri Mar 26 18:41:55 2021 -0500 smb3: fix cached file size problems in duplicate extents (reflink) commit cfc63fc8126a93cbf95379bc4cad79a7b15b6ece upstream. There were two problems (one of which could cause data corruption) that were noticed with duplicate extents (ie reflink) when debugging why various xfstests were being incorrectly skipped (e.g. generic/138, generic/140, generic/142). First, we were not updating the file size locally in the cache when extending a file due to reflink (it would refresh after actimeo expires) but xfstest was checking the size immediately which was still 0 so caused the test to be skipped. Second, we were setting the target file size (which could shrink the file) in all cases to the end of the reflinked range rather than only setting the target file size when reflink would extend the file. CC: Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 2423511cc5baf23bdac3dbc171beab094c3b5107 Author: Jia-Ju Bai Date: Sun Mar 7 19:52:41 2021 -0800 scsi: mpt3sas: Fix error return code of mpt3sas_base_attach() [ Upstream commit 3401ecf7fc1b9458a19d42c0e26a228f18ac7dda ] When kzalloc() returns NULL, no error return code of mpt3sas_base_attach() is assigned. To fix this bug, r is assigned with -ENOMEM in this case. Link: https://lore.kernel.org/r/20210308035241.3288-1-baijiaju1990@gmail.com Fixes: c696f7b83ede ("scsi: mpt3sas: Implement device_remove_in_progress check in IOCTL path") Reported-by: TOTE Robot Signed-off-by: Jia-Ju Bai Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 6b977fea78de067da698088e167714516a4a31b1 Author: Jia-Ju Bai Date: Sun Mar 7 19:30:24 2021 -0800 scsi: qedi: Fix error return code of qedi_alloc_global_queues() [ Upstream commit f69953837ca5d98aa983a138dc0b90a411e9c763 ] When kzalloc() returns NULL to qedi->global_queues[i], no error return code of qedi_alloc_global_queues() is assigned. To fix this bug, status is assigned with -ENOMEM in this case. Link: https://lore.kernel.org/r/20210308033024.27147-1-baijiaju1990@gmail.com Fixes: ace7f46ba5fd ("scsi: qedi: Add QLogic FastLinQ offload iSCSI driver framework.") Reported-by: TOTE Robot Acked-by: Manish Rangankar Signed-off-by: Jia-Ju Bai Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 62bb066cdfb63bb2a5dc1dc1dc1775ba07ceabea Author: Bart Van Assche Date: Sat Mar 20 16:23:53 2021 -0700 scsi: Revert "qla2xxx: Make sure that aborted commands are freed" [ Upstream commit 39c0c8553bfb5a3d108aa47f1256076d507605e3 ] Calling vha->hw->tgt.tgt_ops->free_cmd() from qlt_xmit_response() is wrong since the command for which a response is sent must remain valid until the SCSI target core calls .release_cmd(). It has been observed that the following scenario triggers a kernel crash: - qlt_xmit_response() calls qlt_check_reserve_free_req() - qlt_check_reserve_free_req() returns -EAGAIN - qlt_xmit_response() calls vha->hw->tgt.tgt_ops->free_cmd(cmd) - transport_handle_queue_full() tries to retransmit the response Fix this crash by reverting the patch that introduced it. Link: https://lore.kernel.org/r/20210320232359.941-2-bvanassche@acm.org Fixes: 0dcec41acb85 ("scsi: qla2xxx: Make sure that aborted commands are freed") Cc: Quinn Tran Cc: Mike Christie Reviewed-by: Daniel Wagner Reviewed-by: Himanshu Madhani Signed-off-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit fc062d21c011dc9e9e49f20e26fb5930fa24c720 Author: David Jeffery Date: Thu Feb 11 09:38:07 2021 -0500 block: recalculate segment count for multi-segment discards correctly [ Upstream commit a958937ff166fc60d1c3a721036f6ff41bfa2821 ] When a stacked block device inserts a request into another block device using blk_insert_cloned_request, the request's nr_phys_segments field gets recalculated by a call to blk_recalc_rq_segments in blk_cloned_rq_check_limits. But blk_recalc_rq_segments does not know how to handle multi-segment discards. For disk types which can handle multi-segment discards like nvme, this results in discard requests which claim a single segment when it should report several, triggering a warning in nvme and causing nvme to fail the discard from the invalid state. WARNING: CPU: 5 PID: 191 at drivers/nvme/host/core.c:700 nvme_setup_discard+0x170/0x1e0 [nvme_core] ... nvme_setup_cmd+0x217/0x270 [nvme_core] nvme_loop_queue_rq+0x51/0x1b0 [nvme_loop] __blk_mq_try_issue_directly+0xe7/0x1b0 blk_mq_request_issue_directly+0x41/0x70 ? blk_account_io_start+0x40/0x50 dm_mq_queue_rq+0x200/0x3e0 blk_mq_dispatch_rq_list+0x10a/0x7d0 ? __sbitmap_queue_get+0x25/0x90 ? elv_rb_del+0x1f/0x30 ? deadline_remove_request+0x55/0xb0 ? dd_dispatch_request+0x181/0x210 __blk_mq_do_dispatch_sched+0x144/0x290 ? bio_attempt_discard_merge+0x134/0x1f0 __blk_mq_sched_dispatch_requests+0x129/0x180 blk_mq_sched_dispatch_requests+0x30/0x60 __blk_mq_run_hw_queue+0x47/0xe0 __blk_mq_delay_run_hw_queue+0x15b/0x170 blk_mq_sched_insert_requests+0x68/0xe0 blk_mq_flush_plug_list+0xf0/0x170 blk_finish_plug+0x36/0x50 xlog_cil_committed+0x19f/0x290 [xfs] xlog_cil_process_committed+0x57/0x80 [xfs] xlog_state_do_callback+0x1e0/0x2a0 [xfs] xlog_ioend_work+0x2f/0x80 [xfs] process_one_work+0x1b6/0x350 worker_thread+0x53/0x3e0 ? process_one_work+0x350/0x350 kthread+0x11b/0x140 ? __kthread_bind_mask+0x60/0x60 ret_from_fork+0x22/0x30 This patch fixes blk_recalc_rq_segments to be aware of devices which can have multi-segment discards. It calculates the correct discard segment count by counting the number of bio as each discard bio is considered its own segment. Fixes: 1e739730c5b9 ("block: optionally merge discontiguous discard bios into a single request") Signed-off-by: David Jeffery Reviewed-by: Ming Lei Reviewed-by: Laurence Oberman Link: https://lore.kernel.org/r/20210211143807.GA115624@redhat Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit dcf2dfc1614d64bc3366bdeeb302f32bc2050c4a Author: Pavel Begunkov Date: Fri Mar 19 10:21:19 2021 +0000 io_uring: fix provide_buffers sign extension [ Upstream commit d81269fecb8ce16eb07efafc9ff5520b2a31c486 ] io_provide_buffers_prep()'s "p->len * p->nbufs" to sign extension problems. Not a huge problem as it's only used for access_ok() and increases the checked length, but better to keep typing right. Reported-by: Colin Ian King Fixes: efe68c1ca8f49 ("io_uring: validate the full range of provided buffers for access") Signed-off-by: Pavel Begunkov Reviewed-by: Colin Ian King Link: https://lore.kernel.org/r/562376a39509e260d8532186a06226e56eb1f594.1616149233.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit efb334c4e5ffd98d1de9d0ede16703ced913ad71 Author: Ian Rogers Date: Tue Mar 9 15:49:45 2021 -0800 perf synthetic events: Avoid write of uninitialized memory when generating PERF_RECORD_MMAP* records [ Upstream commit 2a76f6de07906f0bb5f2a13fb02845db1695cc29 ] Account for alignment bytes in the zero-ing memset. Fixes: 1a853e36871b533c ("perf record: Allow specifying a pid to record") Signed-off-by: Ian Rogers Acked-by: Jiri Olsa Cc: Ingo Molnar Cc: Alexander Shishkin Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Stephane Eranian Link: http://lore.kernel.org/lkml/20210309234945.419254-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 5febe60a80213d4ed50073a9b324409619112adb Author: Adrian Hunter Date: Mon Mar 8 17:11:43 2021 +0200 perf auxtrace: Fix auxtrace queue conflict [ Upstream commit b410ed2a8572d41c68bd9208555610e4b07d0703 ] The only requirement of an auxtrace queue is that the buffers are in time order. That is achieved by making separate queues for separate perf buffer or AUX area buffer mmaps. That generally means a separate queue per cpu for per-cpu contexts, and a separate queue per thread for per-task contexts. When buffers are added to a queue, perf checks that the buffer cpu and thread id (tid) match the queue cpu and thread id. However, generally, that need not be true, and perf will queue buffers correctly anyway, so the check is not needed. In addition, the check gets erroneously hit when using sample mode to trace multiple threads. Consequently, fix that case by removing the check. Fixes: e502789302a6 ("perf auxtrace: Add helpers for queuing AUX area tracing data") Reported-by: Andi Kleen Signed-off-by: Adrian Hunter Reviewed-by: Andi Kleen Cc: Jiri Olsa Link: http://lore.kernel.org/lkml/20210308151143.18338-1-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 4a5891992c680d69d7e490e4d0428d17779d8e85 Author: Andy Shevchenko Date: Mon Mar 22 18:31:00 2021 +0200 ACPI: scan: Use unique number for instance_no [ Upstream commit eb50aaf960e3bedfef79063411ffd670da94b84b ] The decrementation of acpi_device_bus_id->instance_no in acpi_device_del() is incorrect, because it may cause a duplicate instance number to be allocated next time a device with the same acpi_device_bus_id is added. Replace above mentioned approach by using IDA framework. While at it, define the instance range to be [0, 4096). Fixes: e49bd2dd5a50 ("ACPI: use PNPID:instance_no as bus_id of ACPI device") Fixes: ca9dc8d42b30 ("ACPI / scan: Fix acpi_bus_id_list bookkeeping") Signed-off-by: Andy Shevchenko Cc: 4.10+ # 4.10+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 2ba9964a96531b3cb3899187093718f328e3adeb Author: Rafael J. Wysocki Date: Thu Jan 14 19:46:47 2021 +0100 ACPI: scan: Rearrange memory allocation in acpi_device_add() [ Upstream commit c1013ff7a5472db637c56bb6237f8343398c03a7 ] The upfront allocation of new_bus_id is done to avoid allocating memory under acpi_device_lock, but it doesn't really help, because (1) it leads to many unnecessary memory allocations for _ADR devices, (2) kstrdup_const() is run under that lock anyway and (3) it complicates the code. Rearrange acpi_device_add() to allocate memory for a new struct acpi_device_bus_id instance only when necessary, eliminate a redundant local variable from it and reduce the number of labels in there. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Reviewed-by: Hans de Goede Signed-off-by: Sasha Levin commit c33f918758fa11143caec15e6e565edb103bf761 Author: Mark Tomlinson Date: Mon Mar 8 14:24:11 2021 +1300 Revert "netfilter: x_tables: Update remaining dereference to RCU" [ Upstream commit abe7034b9a8d57737e80cc16d60ed3666990bdbf ] This reverts commit 443d6e86f821a165fae3fc3fc13086d27ac140b1. This (and the following) patch basically re-implemented the RCU mechanisms of patch 784544739a25. That patch was replaced because of the performance problems that it created when replacing tables. Now, we have the same issue: the call to synchronize_rcu() makes replacing tables slower by as much as an order of magnitude. Revert these patches and fix the issue in a different way. Signed-off-by: Mark Tomlinson Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit de2e6b4e32d6be7ed2218c1b20a9f81f8859ec2a Author: Sean Christopherson Date: Wed Mar 24 21:37:23 2021 -0700 mm/mmu_notifiers: ensure range_end() is paired with range_start() [ Upstream commit c2655835fd8cabdfe7dab737253de3ffb88da126 ] If one or more notifiers fails .invalidate_range_start(), invoke .invalidate_range_end() for "all" notifiers. If there are multiple notifiers, those that did not fail are expecting _start() and _end() to be paired, e.g. KVM's mmu_notifier_count would become imbalanced. Disallow notifiers that can fail _start() from implementing _end() so that it's unnecessary to either track which notifiers rejected _start(), or had already succeeded prior to a failed _start(). Note, the existing behavior of calling _start() on all notifiers even after a previous notifier failed _start() was an unintented "feature". Make it canon now that the behavior is depended on for correctness. As of today, the bug is likely benign: 1. The only caller of the non-blocking notifier is OOM kill. 2. The only notifiers that can fail _start() are the i915 and Nouveau drivers. 3. The only notifiers that utilize _end() are the SGI UV GRU driver and KVM. 4. The GRU driver will never coincide with the i195/Nouveau drivers. 5. An imbalanced kvm->mmu_notifier_count only causes soft lockup in the _guest_, and the guest is already doomed due to being an OOM victim. Fix the bug now to play nice with future usage, e.g. KVM has a potential use case for blocking memslot updates in KVM while an invalidation is in-progress, and failure to unblock would result in said updates being blocked indefinitely and hanging. Found by inspection. Verified by adding a second notifier in KVM that periodically returns -EAGAIN on non-blockable ranges, triggering OOM, and observing that KVM exits with an elevated notifier count. Link: https://lkml.kernel.org/r/20210311180057.1582638-1-seanjc@google.com Fixes: 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu notifiers") Signed-off-by: Sean Christopherson Suggested-by: Jason Gunthorpe Reviewed-by: Jason Gunthorpe Cc: David Rientjes Cc: Ben Gardon Cc: Michal Hocko Cc: "Jérôme Glisse" Cc: Andrea Arcangeli Cc: Johannes Weiner Cc: Dimitri Sivanich Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 42aa210795d8d74dac9ce068419f04481ab6f191 Author: Shin'ichiro Kawasaki Date: Tue Mar 16 13:36:02 2021 +0900 dm table: Fix zoned model check and zone sectors check [ Upstream commit 2d669ceb69c276f7637cf760287ca4187add082e ] Commit 24f6b6036c9e ("dm table: fix zoned iterate_devices based device capability checks") triggered dm table load failure when dm-zoned device is set up for zoned block devices and a regular device for cache. The commit inverted logic of two callback functions for iterate_devices: device_is_zoned_model() and device_matches_zone_sectors(). The logic of device_is_zoned_model() was inverted then all destination devices of all targets in dm table are required to have the expected zoned model. This is fine for dm-linear, dm-flakey and dm-crypt on zoned block devices since each target has only one destination device. However, this results in failure for dm-zoned with regular cache device since that target has both regular block device and zoned block devices. As for device_matches_zone_sectors(), the commit inverted the logic to require all zoned block devices in each target have the specified zone_sectors. This check also fails for regular block device which does not have zones. To avoid the check failures, fix the zone model check and the zone sectors check. For zone model check, introduce the new feature flag DM_TARGET_MIXED_ZONED_MODEL, and set it to dm-zoned target. When the target has this flag, allow it to have destination devices with any zoned model. For zone sectors check, skip the check if the destination device is not a zoned block device. Also add comments and improve an error message to clarify expectations to the two checks. Fixes: 24f6b6036c9e ("dm table: fix zoned iterate_devices based device capability checks") Signed-off-by: Shin'ichiro Kawasaki Signed-off-by: Damien Le Moal Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit 3fdebc2d8e7965f946a3d716ffdd482e66c1f46c Author: Mark Tomlinson Date: Mon Mar 8 14:24:13 2021 +1300 netfilter: x_tables: Use correct memory barriers. [ Upstream commit 175e476b8cdf2a4de7432583b49c871345e4f8a1 ] When a new table value was assigned, it was followed by a write memory barrier. This ensured that all writes before this point would complete before any writes after this point. However, to determine whether the rules are unused, the sequence counter is read. To ensure that all writes have been done before these reads, a full memory barrier is needed, not just a write memory barrier. The same argument applies when incrementing the counter, before the rules are read. Changing to using smp_mb() instead of smp_wmb() fixes the kernel panic reported in cc00bcaa5899 (which is still present), while still maintaining the same speed of replacing tables. The smb_mb() barriers potentially slow the packet path, however testing has shown no measurable change in performance on a 4-core MIPS64 platform. Fixes: 7f5c6d4f665b ("netfilter: get rid of atomic ops in fast path") Signed-off-by: Mark Tomlinson Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 520be4d1af9c624260103f241d23675c8e21f292 Author: Mark Tomlinson Date: Mon Mar 8 14:24:12 2021 +1300 Revert "netfilter: x_tables: Switch synchronization to RCU" [ Upstream commit d3d40f237480abf3268956daf18cdc56edd32834 ] This reverts commit cc00bcaa589914096edef7fb87ca5cee4a166b5c. This (and the preceding) patch basically re-implemented the RCU mechanisms of patch 784544739a25. That patch was replaced because of the performance problems that it created when replacing tables. Now, we have the same issue: the call to synchronize_rcu() makes replacing tables slower by as much as an order of magnitude. Prior to using RCU a script calling "iptables" approx. 200 times was taking 1.16s. With RCU this increased to 11.59s. Revert these patches and fix the issue in a different way. Signed-off-by: Mark Tomlinson Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 87771c9b09bbf4642433f49586124f36bdad650f Author: Florian Fainelli Date: Thu Mar 11 16:52:50 2021 -0800 net: phy: broadcom: Fix RGMII delays for BCM50160 and BCM50610M [ Upstream commit b1dd9bf688b0dcc5a34dca660de46c7570bd9243 ] The PHY driver entry for BCM50160 and BCM50610M calls bcm54xx_config_init() but does not call bcm54xx_config_clock_delay() in order to configuration appropriate clock delays on the PHY, fix that. Fixes: 733336262b28 ("net: phy: Allow BCM5481x PHYs to setup internal TX/RX clock delay") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 485335a637c8f2909f7c1932b1820d1d9f9db9f8 Author: Robert Hancock Date: Tue Feb 16 16:54:52 2021 -0600 net: phy: broadcom: Set proper 1000BaseX/SGMII interface mode for BCM54616S [ Upstream commit 3afd0218992a8d1398e9791d6c2edd4c948ae7ee ] The default configuration for the BCM54616S PHY may not match the desired mode when using 1000BaseX or SGMII interface modes, such as when it is on an SFP module. Add code to explicitly set the correct mode using programming sequences provided by Bel-Fuse: https://www.belfuse.com/resources/datasheets/powersolutions/ds-bps-sfp-1gbt-05-series.pdf https://www.belfuse.com/resources/datasheets/powersolutions/ds-bps-sfp-1gbt-06-series.pdf Signed-off-by: Robert Hancock Acked-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 837a3ae33459f25ad895e828088b505b60349983 Author: Florian Fainelli Date: Fri Feb 12 19:46:30 2021 -0800 net: phy: broadcom: Avoid forward for bcm54xx_config_clock_delay() [ Upstream commit 133bf7b4fbbe58cff5492e37e95e75c88161f1b8 ] Avoid a forward declaration by moving the callers of bcm54xx_config_clock_delay() below its body. Signed-off-by: Florian Fainelli Reviewed-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9a5267264fc2f366b687b400487ec06747f054b6 Author: Michael Walle Date: Tue Feb 9 17:38:52 2021 +0100 net: phy: introduce phydev->port [ Upstream commit 4217a64e18a1647a0dbc68cb3169a5a06f054ec8 ] At the moment, PORT_MII is reported in the ethtool ops. This is odd because it is an interface between the MAC and the PHY and no external port. Some network card drivers will overwrite the port to twisted pair or fiber, though. Even worse, the MDI/MDIX setting is only used by ethtool if the port is twisted pair. Set the port to PORT_TP by default because most PHY drivers are copper ones. If there is fibre support and it is enabled, the PHY driver will set it to PORT_FIBRE. This will change reporting PORT_MII to either PORT_TP or PORT_FIBRE; except for the genphy fallback driver. Suggested-by: Andrew Lunn Signed-off-by: Michael Walle Reviewed-by: Florian Fainelli Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c4934e65c8bc06c84d79c1c8fa59d6e54ab0faee Author: Robert Hancock Date: Thu Mar 11 14:05:18 2021 -0600 net: axienet: Fix probe error cleanup [ Upstream commit 59cd4f19267a0aab87a8c07e4426eb7187ee548d ] The driver did not always clean up all allocated resources when probe failed. Fix the probe cleanup path to clean up everything that was allocated. Fixes: 57baf8cc70ea ("net: axienet: Handle deferred probe on clock properly") Signed-off-by: Robert Hancock Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3e08fd4a82986f200baa77312b1f248bb567b04e Author: Robert Hancock Date: Wed Oct 28 11:14:29 2020 -0600 net: axienet: Properly handle PCS/PMA PHY for 1000BaseX mode [ Upstream commit 1a02556086fc0eb16e0a0d09043e9ffb0e31c7db ] Update the axienet driver to properly support the Xilinx PCS/PMA PHY component which is used for 1000BaseX and SGMII modes, including properly configuring the auto-negotiation mode of the PHY and reading the negotiated state from the PHY. Signed-off-by: Robert Hancock Reviewed-by: Radhey Shyam Pandey Link: https://lore.kernel.org/r/20201028171429.1699922-1-robert.hancock@calian.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d65e7d0c74499c53c5f9d939e2f913560f89c5a3 Author: Li RongQing Date: Thu Jan 21 13:54:23 2021 -0800 igb: avoid premature Rx buffer reuse [ Upstream commit 98dfb02aa22280bd8833836d1b00ab0488fa951f ] Igb needs a similar fix as commit 75aab4e10ae6a ("i40e: avoid premature Rx buffer reuse") The page recycle code, incorrectly, relied on that a page fragment could not be freed inside xdp_do_redirect(). This assumption leads to that page fragments that are used by the stack/XDP redirect can be reused and overwritten. To avoid this, store the page count prior invoking xdp_do_redirect(). Longer explanation: Intel NICs have a recycle mechanism. The main idea is that a page is split into two parts. One part is owned by the driver, one part might be owned by someone else, such as the stack. t0: Page is allocated, and put on the Rx ring +--------------- used by NIC ->| upper buffer (rx_buffer) +--------------- | lower buffer +--------------- page count == USHRT_MAX rx_buffer->pagecnt_bias == USHRT_MAX t1: Buffer is received, and passed to the stack (e.g.) +--------------- | upper buff (skb) +--------------- used by NIC ->| lower buffer (rx_buffer) +--------------- page count == USHRT_MAX rx_buffer->pagecnt_bias == USHRT_MAX - 1 t2: Buffer is received, and redirected +--------------- | upper buff (skb) +--------------- used by NIC ->| lower buffer (rx_buffer) +--------------- Now, prior calling xdp_do_redirect(): page count == USHRT_MAX rx_buffer->pagecnt_bias == USHRT_MAX - 2 This means that buffer *cannot* be flipped/reused, because the skb is still using it. The problem arises when xdp_do_redirect() actually frees the segment. Then we get: page count == USHRT_MAX - 1 rx_buffer->pagecnt_bias == USHRT_MAX - 2 From a recycle perspective, the buffer can be flipped and reused, which means that the skb data area is passed to the Rx HW ring! To work around this, the page count is stored prior calling xdp_do_redirect(). Fixes: 9cbc948b5a20 ("igb: add XDP support") Signed-off-by: Li RongQing Reviewed-by: Alexander Duyck Tested-by: Vishakha Jambekar Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit c7eb3e12f18fc060d50d39c778e26929c5a0319f Author: Daniel Borkmann Date: Wed Mar 10 01:38:10 2021 +0100 net, bpf: Fix ip6ip6 crash with collect_md populated skbs [ Upstream commit a188bb5638d41aa99090ebf2f85d3505ab13fba5 ] I ran into a crash where setting up a ip6ip6 tunnel device which was /not/ set to collect_md mode was receiving collect_md populated skbs for xmit. The BPF prog was populating the skb via bpf_skb_set_tunnel_key() which is assigning special metadata dst entry and then redirecting the skb to the device, taking ip6_tnl_start_xmit() -> ipxip6_tnl_xmit() -> ip6_tnl_xmit() and in the latter it performs a neigh lookup based on skb_dst(skb) where we trigger a NULL pointer dereference on dst->ops->neigh_lookup() since the md_dst_ops do not populate neigh_lookup callback with a fake handler. Transform the md_dst_ops into generic dst_blackhole_ops that can also be reused elsewhere when needed, and use them for the metadata dst entries as callback ops. Also, remove the dst_md_discard{,_out}() ops and rely on dst_discard{,_out}() from dst_init() which free the skb the same way modulo the splat. Given we will be able to recover just fine from there, avoid any potential splats iff this gets ever triggered in future (or worse, panic on warns when set). Fixes: f38a9eb1f77b ("dst: Metadata destinations") Signed-off-by: Daniel Borkmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0a245acbce8991668d5406f128f2c06a310c99a1 Author: Daniel Borkmann Date: Wed Mar 10 01:38:09 2021 +0100 net: Consolidate common blackhole dst ops [ Upstream commit c4c877b2732466b4c63217baad05c96f775912c7 ] Move generic blackhole dst ops to the core and use them from both ipv4_dst_blackhole_ops and ip6_dst_blackhole_ops where possible. No functional change otherwise. We need these also in other locations and having to define them over and over again is not great. Signed-off-by: Daniel Borkmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 33cd5f88b5bf01135e06d5d77aa6a59d899ce993 Author: Sasha Levin Date: Sat Mar 27 18:27:53 2021 -0400 bpf: Don't do bpf_cgroup_storage_set() for kuprobe/tp programs [ Upstream commit 05a68ce5fa51a83c360381630f823545c5757aa2 ] For kuprobe and tracepoint bpf programs, kernel calls trace_call_bpf() which calls BPF_PROG_RUN_ARRAY_CHECK() to run the program array. Currently, BPF_PROG_RUN_ARRAY_CHECK() also calls bpf_cgroup_storage_set() to set percpu cgroup local storage with NULL value. This is due to Commit 394e40a29788 ("bpf: extend bpf_prog_array to store pointers to the cgroup storage") which modified __BPF_PROG_RUN_ARRAY() to call bpf_cgroup_storage_set() and this macro is also used by BPF_PROG_RUN_ARRAY_CHECK(). kuprobe and tracepoint programs are not allowed to call bpf_get_local_storage() helper hence does not access percpu cgroup local storage. Let us change BPF_PROG_RUN_ARRAY_CHECK() not to modify percpu cgroup local storage. The issue is observed when I tried to debug [1] where percpu data is overwritten due to preempt_disable -> migration_disable change. This patch does not completely fix the above issue, which will be addressed separately, e.g., multiple cgroup prog runs may preempt each other. But it does fix any potential issue caused by tracing program overwriting percpu cgroup storage: - in a busy system, a tracing program is to run between bpf_cgroup_storage_set() and the cgroup prog run. - a kprobe program is triggered by a helper in cgroup prog before bpf_get_local_storage() is called. [1] https://lore.kernel.org/bpf/CAKH8qBuXCfUz=w8L+Fj74OaUpbosO29niYwTki7e3Ag044_aww@mail.gmail.com/T Fixes: 394e40a29788 ("bpf: extend bpf_prog_array to store pointers to the cgroup storage") Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Acked-by: Roman Gushchin Link: https://lore.kernel.org/bpf/20210309185028.3763817-1-yhs@fb.com Signed-off-by: Sasha Levin commit d95696f537d6aef952f2611aee8cc2be1ff8fe09 Author: Potnuri Bharat Teja Date: Thu Mar 25 00:34:53 2021 +0530 RDMA/cxgb4: Fix adapter LE hash errors while destroying ipv6 listening server [ Upstream commit 3408be145a5d6418ff955fe5badde652be90e700 ] Not setting the ipv6 bit while destroying ipv6 listening servers may result in potential fatal adapter errors due to lookup engine memory hash errors. Therefore always set ipv6 field while destroying ipv6 listening servers. Fixes: 830662f6f032 ("RDMA/cxgb4: Add support for active and passive open connection with IPv6 address") Link: https://lore.kernel.org/r/20210324190453.8171-1-bharat@chelsio.com Signed-off-by: Potnuri Bharat Teja Reviewed-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit b740e58324c8a0121bd7c9fb197e470b24fc0aad Author: Roger Pau Monne Date: Wed Mar 24 13:24:23 2021 +0100 xen/x86: make XEN_BALLOON_MEMORY_HOTPLUG_LIMIT depend on MEMORY_HOTPLUG [ Upstream commit 2b514ec72706a31bea0c3b97e622b81535b5323a ] The Xen memory hotplug limit should depend on the memory hotplug generic option, rather than the Xen balloon configuration. It's possible to have a kernel with generic memory hotplug enabled, but without Xen balloon enabled, at which point memory hotplug won't work correctly due to the size limitation of the p2m. Rename the option to XEN_MEMORY_HOTPLUG_LIMIT since it's no longer tied to ballooning. Fixes: 9e2369c06c8a18 ("xen: add helpers to allocate unpopulated memory") Signed-off-by: Roger Pau Monné Reviewed-by: Boris Ostrovsky Link: https://lore.kernel.org/r/20210324122424.58685-2-roger.pau@citrix.com Signed-off-by: Boris Ostrovsky Signed-off-by: Sasha Levin commit 889c56ea941ed327e037db04b7630f1c85d777df Author: Colin Ian King Date: Tue Mar 23 12:32:45 2021 +0000 octeontx2-af: Fix memory leak of object buf [ Upstream commit 9e0a537d06fc36861e4f78d0a7df1fe2b3592714 ] Currently the error return path when lfs fails to allocate is not free'ing the memory allocated to buf. Fix this by adding the missing kfree. Addresses-Coverity: ("Resource leak") Fixes: f7884097141b ("octeontx2-af: Formatting debugfs entry rsrc_alloc.") Signed-off-by: Colin Ian King Acked-by: Sunil Goutham Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 558454ec5170731fd3ab18837625073d08a0386b Author: Vladimir Oltean Date: Mon Mar 22 20:21:08 2021 +0200 net: bridge: don't notify switchdev for local FDB addresses [ Upstream commit 6ab4c3117aec4e08007d9e971fa4133e1de1082d ] As explained in this discussion: https://lore.kernel.org/netdev/20210117193009.io3nungdwuzmo5f7@skbuf/ the switchdev notifiers for FDB entries managed to have a zero-day bug. The bridge would not say that this entry is local: ip link add br0 type bridge ip link set swp0 master br0 bridge fdb add dev swp0 00:01:02:03:04:05 master local and the switchdev driver would be more than happy to offload it as a normal static FDB entry. This is despite the fact that 'local' and non-'local' entries have completely opposite directions: a local entry is locally terminated and not forwarded, whereas a static entry is forwarded and not locally terminated. So, for example, DSA would install this entry on swp0 instead of installing it on the CPU port as it should. There is an even sadder part, which is that the 'local' flag is implicit if 'static' is not specified, meaning that this command produces the same result of adding a 'local' entry: bridge fdb add dev swp0 00:01:02:03:04:05 master I've updated the man pages for 'bridge', and after reading it now, it should be pretty clear to any user that the commands above were broken and should have never resulted in the 00:01:02:03:04:05 address being forwarded (this behavior is coherent with non-switchdev interfaces): https://patchwork.kernel.org/project/netdevbpf/cover/20210211104502.2081443-1-olteanv@gmail.com/ If you're a user reading this and this is what you want, just use: bridge fdb add dev swp0 00:01:02:03:04:05 master static Because switchdev should have given drivers the means from day one to classify FDB entries as local/non-local, but didn't, it means that all drivers are currently broken. So we can just as well omit the switchdev notifications for local FDB entries, which is exactly what this patch does to close the bug in stable trees. For further development work where drivers might want to trap the local FDB entries to the host, we can add a 'bool is_local' to br_switchdev_fdb_call_notifiers(), and selectively make drivers act upon that bit, while all the others ignore those entries if the 'is_local' bit is set. Fixes: 6b26b51b1d13 ("net: bridge: Add support for notifying devices about FDB add/del") Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7d019b2d0f270219646c53cbba7c633fec76b5cb Author: Lukasz Luba Date: Tue Mar 23 14:56:08 2021 +0000 PM: EM: postpone creating the debugfs dir till fs_initcall [ Upstream commit fb9d62b27ab1e07d625591549c314b7d406d21df ] The debugfs directory '/sys/kernel/debug/energy_model' is needed before the Energy Model registration can happen. With the recent change in debugfs subsystem it's not allowed to create this directory at early stage (core_initcall). Thus creating this directory would fail. Postpone the creation of the EM debug dir to later stage: fs_initcall. It should be safe since all clients: CPUFreq drivers, Devfreq drivers will be initialized in later stages. The custom debug log below prints the time of creation the EM debug dir at fs_initcall and successful registration of EMs at later stages. [ 1.505717] energy_model: creating rootdir [ 3.698307] cpu cpu0: EM: created perf domain [ 3.709022] cpu cpu1: EM: created perf domain Fixes: 56348560d495 ("debugfs: do not attempt to create a new file before the filesystem is initalized") Reported-by: Ionela Voinescu Signed-off-by: Lukasz Luba Reviewed-by: Greg Kroah-Hartman Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 08a5f812ad6c6a78a37fc6462bbee089a1342ed3 Author: Aya Levin Date: Thu Mar 11 17:46:35 2021 +0200 net/mlx5e: Fix error path for ethtool set-priv-flag [ Upstream commit 4eacfe72e3e037e3fc019113df32c39a705148c2 ] Expose error value when failing to comply to command: $ ethtool --set-priv-flags eth2 rx_cqe_compress [on/off] Fixes: be7e87f92b58 ("net/mlx5e: Fail safe cqe compressing/moderation mode setting") Signed-off-by: Aya Levin Reviewed-by: Tariq Toukan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 624f0dc8f7f4ab2bc4efff7174161c83884d53ec Author: Dima Chumak Date: Thu Mar 4 21:28:11 2021 +0200 net/mlx5e: Offload tuple rewrite for non-CT flows [ Upstream commit 96b5b4585843e3c83fb1930e5dfbefd0fb889c55 ] Setting connection tracking OVS flows and then setting non-CT flows that use tuple rewrite action (e.g. mod_tp_dst), causes the latter flows not being offloaded. Fix by using a stricter condition in modify_header_match_supported() to check tuple rewrite support only for flows with CT action. The check is factored out into standalone modify_tuple_supported() function to aid readability. Fixes: 7e36feeb0467 ("net/mlx5e: CT: Don't offload tuple rewrites for established tuples") Signed-off-by: Dima Chumak Reviewed-by: Paul Blakey Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit c83207bb02d6bd0e3ad1e0c0e2e8487b2ac72f47 Author: Alaa Hleihel Date: Wed Mar 10 17:01:46 2021 +0200 net/mlx5e: Allow to match on MPLS parameters only for MPLS over UDP [ Upstream commit 7d6c86e3ccb5ceea767df5c7a9a17cdfccd3df9a ] Currently, we support hardware offload only for MPLS over UDP. However, rules matching on MPLS parameters are now wrongly offloaded for regular MPLS, without actually taking the parameters into consideration when doing the offload. Fix it by rejecting such unsupported rules. Fixes: 72046a91d134 ("net/mlx5e: Allow to match on mpls parameters") Signed-off-by: Alaa Hleihel Reviewed-by: Roi Dayan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 0be13d01473a0bbbec47a5b316a1727d7c94e278 Author: Huy Nguyen Date: Thu Mar 18 20:33:19 2021 -0500 net/mlx5: Add back multicast stats for uplink representor [ Upstream commit a07231084da2207629b42244380ae2f1e10bd9b4 ] The multicast counter got removed from uplink representor due to the cited patch. Fixes: 47c97e6b10a1 ("net/mlx5e: Fix multicast counter not up-to-date in "ip -s"") Signed-off-by: Huy Nguyen Reviewed-by: Daniel Jurgens Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 65c021e7359006cf6bd632941f667c84f0be8a04 Author: Rafael J. Wysocki Date: Fri Mar 19 15:47:31 2021 +0100 PM: runtime: Defer suspending suppliers [ Upstream commit 5244f5e2d801259af877ee759e8c22364c607072 ] Because the PM-runtime status of the device is not updated in __rpm_callback(), attempts to suspend the suppliers of the given device triggered by the rpm_put_suppliers() call in there may cause a supplier to be suspended completely before the status of the consumer is updated to RPM_SUSPENDED, which is confusing. To avoid that (1) modify __rpm_callback() to only decrease the PM-runtime usage counter of each supplier and (2) make rpm_suspend() try to suspend the suppliers after changing the consumer's status to RPM_SUSPENDED, in analogy with the device's parent. Link: https://lore.kernel.org/linux-pm/CAPDyKFqm06KDw_p8WXsM4dijDbho4bb6T4k50UqqvR1_COsp8g@mail.gmail.com/ Fixes: 21d5c57b3726 ("PM / runtime: Use device links") Reported-by: elaine.zhang Diagnosed-by: Ulf Hansson Reviewed-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 3db5fc556515e4676ee89f6736e0cf0c3e3c6072 Author: Pavel Tatashin Date: Fri Mar 19 16:50:54 2021 -0400 arm64: kdump: update ppos when reading elfcorehdr [ Upstream commit 141f8202cfa4192c3af79b6cbd68e7760bb01b5a ] The ppos points to a position in the old kernel memory (and in case of arm64 in the crash kernel since elfcorehdr is passed as a segment). The function should update the ppos by the amount that was read. This bug is not exposed by accident, but other platforms update this value properly. So, fix it in ARM64 version of elfcorehdr_read() as well. Signed-off-by: Pavel Tatashin Fixes: e62aaeac426a ("arm64: kdump: provide /proc/vmcore file") Reviewed-by: Tyler Hicks Link: https://lore.kernel.org/r/20210319205054.743368-1-pasha.tatashin@soleen.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 447a011bb40d2cefa6df367b84757c95616d2803 Author: Fabio Estevam Date: Sat Mar 20 08:56:03 2021 -0300 drm/msm: Fix suspend/resume on i.MX5 [ Upstream commit a9748134ea4aad989e52a6a91479e0acfd306e5b ] When putting iMX5 into suspend, the following flow is observed: [ 70.023427] [] (msm_atomic_commit_tail) from [] (commit_tail+0x9c/0x18c) [ 70.031890] [] (commit_tail) from [] (drm_atomic_helper_commit+0x1a0/0x1d4) [ 70.040627] [] (drm_atomic_helper_commit) from [] (drm_atomic_helper_disable_all+0x1c4/0x1d4) [ 70.050913] [] (drm_atomic_helper_disable_all) from [] (drm_atomic_helper_suspend+0xb8/0x170) [ 70.061198] [] (drm_atomic_helper_suspend) from [] (drm_mode_config_helper_suspend+0x24/0x58) In the i.MX5 case, priv->kms is not populated (as i.MX5 does not use any of the Qualcomm display controllers), causing a NULL pointer dereference in msm_atomic_commit_tail(): [ 24.268964] 8<--- cut here --- [ 24.274602] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 24.283434] pgd = (ptrval) [ 24.286387] [00000000] *pgd=ca212831 [ 24.290788] Internal error: Oops: 17 [#1] SMP ARM [ 24.295609] Modules linked in: [ 24.298777] CPU: 0 PID: 197 Comm: init Not tainted 5.11.0-rc2-next-20210111 #333 [ 24.306276] Hardware name: Freescale i.MX53 (Device Tree Support) [ 24.312442] PC is at msm_atomic_commit_tail+0x54/0xb9c [ 24.317743] LR is at commit_tail+0xa4/0x1b0 Fix the problem by calling drm_mode_config_helper_suspend/resume() only when priv->kms is available. Fixes: ca8199f13498 ("drm/msm/dpu: ensure device suspend happens during PM sleep") Signed-off-by: Fabio Estevam Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit c7552dee62a0ae25f55e5b02bb1b4bcdf7eb5519 Author: Dmitry Baryshkov Date: Sat Mar 20 08:56:02 2021 -0300 drm/msm: fix shutdown hook in case GPU components failed to bind [ Upstream commit 623f279c77811475ac8fd5635cc4e4451aa71291 ] If GPU components have failed to bind, shutdown callback would fail with the following backtrace. Add safeguard check to stop that oops from happening and allow the board to reboot. [ 66.617046] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 66.626066] Mem abort info: [ 66.628939] ESR = 0x96000006 [ 66.632088] EC = 0x25: DABT (current EL), IL = 32 bits [ 66.637542] SET = 0, FnV = 0 [ 66.640688] EA = 0, S1PTW = 0 [ 66.643924] Data abort info: [ 66.646889] ISV = 0, ISS = 0x00000006 [ 66.650832] CM = 0, WnR = 0 [ 66.653890] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000107f81000 [ 66.660505] [0000000000000000] pgd=0000000100bb2003, p4d=0000000100bb2003, pud=0000000100897003, pmd=0000000000000000 [ 66.671398] Internal error: Oops: 96000006 [#1] PREEMPT SMP [ 66.677115] Modules linked in: [ 66.680261] CPU: 6 PID: 352 Comm: reboot Not tainted 5.11.0-rc2-00309-g79e3faa756b2 #38 [ 66.688473] Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) [ 66.695347] pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--) [ 66.701507] pc : msm_atomic_commit_tail+0x78/0x4e0 [ 66.706437] lr : commit_tail+0xa4/0x184 [ 66.710381] sp : ffff8000108f3af0 [ 66.713791] x29: ffff8000108f3af0 x28: ffff418c44337000 [ 66.719242] x27: 0000000000000000 x26: ffff418c40a24490 [ 66.724693] x25: ffffd3a842a4f1a0 x24: 0000000000000008 [ 66.730146] x23: ffffd3a84313f030 x22: ffff418c444ce000 [ 66.735598] x21: ffff418c408a4980 x20: 0000000000000000 [ 66.741049] x19: 0000000000000000 x18: ffff800010710fbc [ 66.746500] x17: 000000000000000c x16: 0000000000000001 [ 66.751954] x15: 0000000000010008 x14: 0000000000000068 [ 66.757405] x13: 0000000000000001 x12: 0000000000000000 [ 66.762855] x11: 0000000000000001 x10: 00000000000009b0 [ 66.768306] x9 : ffffd3a843192000 x8 : ffff418c44337000 [ 66.773757] x7 : 0000000000000000 x6 : 00000000a401b34e [ 66.779210] x5 : 00ffffffffffffff x4 : 0000000000000000 [ 66.784660] x3 : 0000000000000000 x2 : ffff418c444ce000 [ 66.790111] x1 : ffffd3a841dce530 x0 : ffff418c444cf000 [ 66.795563] Call trace: [ 66.798075] msm_atomic_commit_tail+0x78/0x4e0 [ 66.802633] commit_tail+0xa4/0x184 [ 66.806217] drm_atomic_helper_commit+0x160/0x390 [ 66.811051] drm_atomic_commit+0x4c/0x60 [ 66.815082] drm_atomic_helper_disable_all+0x1f4/0x210 [ 66.820355] drm_atomic_helper_shutdown+0x80/0x130 [ 66.825276] msm_pdev_shutdown+0x14/0x20 [ 66.829303] platform_shutdown+0x28/0x40 [ 66.833330] device_shutdown+0x158/0x330 [ 66.837357] kernel_restart+0x40/0xa0 [ 66.841122] __do_sys_reboot+0x228/0x250 [ 66.845148] __arm64_sys_reboot+0x28/0x34 [ 66.849264] el0_svc_common.constprop.0+0x74/0x190 [ 66.854187] do_el0_svc+0x24/0x90 [ 66.857595] el0_svc+0x14/0x20 [ 66.860739] el0_sync_handler+0x1a4/0x1b0 [ 66.864858] el0_sync+0x174/0x180 [ 66.868269] Code: 1ac020a0 2a000273 eb02007f 54ffff01 (f9400285) [ 66.874525] ---[ end trace 20dedb2a3229fec8 ]--- Fixes: 9d5cbf5fe46e ("drm/msm: add shutdown support for display platform_driver") Signed-off-by: Dmitry Baryshkov Signed-off-by: Fabio Estevam Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 0b7bc92c198680212cc32f24901d602d9f2e34e4 Author: Oliver Hartkopp Date: Fri Mar 19 11:06:19 2021 +0100 can: isotp: tx-path: zero initialize outgoing CAN frames [ Upstream commit b5f020f82a8e41201c6ede20fa00389d6980b223 ] Commit d4eb538e1f48 ("can: isotp: TX-path: ensure that CAN frame flags are initialized") ensured the TX flags to be properly set for outgoing CAN frames. In fact the root cause of the issue results from a missing initialization of outgoing CAN frames created by isotp. This is no problem on the CAN bus as the CAN driver only picks the correctly defined content from the struct can(fd)_frame. But when the outgoing frames are monitored (e.g. with candump) we potentially leak some bytes in the unused content of struct can(fd)_frame. Fixes: e057dd3fc20f ("can: add ISO 15765-2:2016 transport protocol") Cc: Marc Kleine-Budde Link: https://lore.kernel.org/r/20210319100619.10858-1-socketcan@hartkopp.net Signed-off-by: Oliver Hartkopp Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit ccd5565feea346697c1d1e8e9cd042218b49c44b Author: Zqiang Date: Wed Mar 17 11:09:15 2021 +0800 bpf: Fix umd memory leak in copy_process() [ Upstream commit f60a85cad677c4f9bb4cadd764f1d106c38c7cf8 ] The syzbot reported a memleak as follows: BUG: memory leak unreferenced object 0xffff888101b41d00 (size 120): comm "kworker/u4:0", pid 8, jiffies 4294944270 (age 12.780s) backtrace: [] alloc_pid+0x66/0x560 [] copy_process+0x1465/0x25e0 [] kernel_clone+0xf3/0x670 [] kernel_thread+0x61/0x80 [] call_usermodehelper_exec_work [] call_usermodehelper_exec_work+0xc4/0x120 [] process_one_work+0x2c9/0x600 [] worker_thread+0x59/0x5d0 [] kthread+0x178/0x1b0 [] ret_from_fork+0x1f/0x30 unreferenced object 0xffff888110ef5c00 (size 232): comm "kworker/u4:0", pid 8414, jiffies 4294944270 (age 12.780s) backtrace: [] kmem_cache_zalloc [] __alloc_file+0x1f/0xf0 [] alloc_empty_file+0x69/0x120 [] alloc_file+0x33/0x1b0 [] alloc_file_pseudo+0xb2/0x140 [] create_pipe_files+0x138/0x2e0 [] umd_setup+0x33/0x220 [] call_usermodehelper_exec_async+0xb4/0x1b0 [] ret_from_fork+0x1f/0x30 After the UMD process exits, the pipe_to_umh/pipe_from_umh and tgid need to be released. Fixes: d71fa5c9763c ("bpf: Add kernel module with user mode driver that populates bpffs.") Reported-by: syzbot+44908bb56d2bfe56b28e@syzkaller.appspotmail.com Signed-off-by: Zqiang Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20210317030915.2865-1-qiang.zhang@windriver.com Signed-off-by: Sasha Levin commit eeadce8811d35990da78fa05c8db0308727dd210 Author: Jean-Philippe Brucker Date: Fri Mar 19 12:25:54 2021 +0100 libbpf: Fix BTF dump of pointer-to-array-of-struct [ Upstream commit 901ee1d750f29a335423eeb9463c3ca461ca18c2 ] The vmlinux.h generated from BTF is invalid when building drivers/phy/ti/phy-gmii-sel.c with clang: vmlinux.h:61702:27: error: array type has incomplete element type ‘struct reg_field’ 61702 | const struct reg_field (*regfields)[3]; | ^~~~~~~~~ bpftool generates a forward declaration for this struct regfield, which compilers aren't happy about. Here's a simplified reproducer: struct inner { int val; }; struct outer { struct inner (*ptr_to_array)[2]; } A; After build with clang -> bpftool btf dump c -> clang/gcc: ./def-clang.h:11:23: error: array has incomplete element type 'struct inner' struct inner (*ptr_to_array)[2]; Member ptr_to_array of struct outer is a pointer to an array of struct inner. In the DWARF generated by clang, struct outer appears before struct inner, so when converting BTF of struct outer into C, bpftool issues a forward declaration to struct inner. With GCC the DWARF info is reversed so struct inner gets fully defined. That forward declaration is not sufficient when compilers handle an array of the struct, even when it's only used through a pointer. Note that we can trigger the same issue with an intermediate typedef: struct inner { int val; }; typedef struct inner inner2_t[2]; struct outer { inner2_t *ptr_to_array; } A; Becomes: struct inner; typedef struct inner inner2_t[2]; And causes: ./def-clang.h:10:30: error: array has incomplete element type 'struct inner' typedef struct inner inner2_t[2]; To fix this, clear through_ptr whenever we encounter an intermediate array, to make the inner struct part of a strong link and force full declaration. Fixes: 351131b51c7a ("libbpf: add btf_dump API for BTF-to-C conversion") Signed-off-by: Jean-Philippe Brucker Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210319112554.794552-2-jean-philippe@linaro.org Signed-off-by: Sasha Levin commit 7693b64ae508d71e42c7fd88b90845b65a25e818 Author: Hangbin Liu Date: Fri Mar 19 22:33:14 2021 +0800 selftests: forwarding: vxlan_bridge_1d: Fix vxlan ecn decapsulate value [ Upstream commit 5aa3c334a449bab24519c4967f5ac2b3304c8dcf ] The ECN bit defines ECT(1) = 1, ECT(0) = 2. So inner 0x02 + outer 0x01 should be inner ECT(0) + outer ECT(1). Based on the description of __INET_ECN_decapsulate, the final decapsulate value should be ECT(1). So fix the test expect value to 0x01. Before the fix: TEST: VXLAN: ECN decap: 01/02->0x02 [FAIL] Expected to capture 10 packets, got 0. After the fix: TEST: VXLAN: ECN decap: 01/02->0x01 [ OK ] Fixes: a0b61f3d8ebf ("selftests: forwarding: vxlan_bridge_1d: Add an ECN decap test") Signed-off-by: Hangbin Liu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5ebb9947b488a73c03a7d1aec7142f3873d6704f Author: David Brazdil Date: Fri Mar 19 13:05:41 2021 +0000 selinux: vsock: Set SID for socket returned by accept() [ Upstream commit 1f935e8e72ec28dddb2dc0650b3b6626a293d94b ] For AF_VSOCK, accept() currently returns sockets that are unlabelled. Other socket families derive the child's SID from the SID of the parent and the SID of the incoming packet. This is typically done as the connected socket is placed in the queue that accept() removes from. Reuse the existing 'security_sk_clone' hook to copy the SID from the parent (server) socket to the child. There is no packet SID in this case. Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") Signed-off-by: David Brazdil Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1e01729999c07f05c66afaf521baa8cc559fdd32 Author: Corentin Labbe Date: Fri Mar 19 13:44:22 2021 +0000 net: stmmac: dwmac-sun8i: Provide TX and RX fifo sizes [ Upstream commit 014dfa26ce1c647af09bf506285ef67e0e3f0a6b ] MTU cannot be changed on dwmac-sun8i. (ip link set eth0 mtu xxx returning EINVAL) This is due to tx_fifo_size being 0, since this value is used to compute valid MTU range. Like dwmac-sunxi (with commit 806fd188ce2a ("net: stmmac: dwmac-sunxi: Provide TX and RX fifo sizes")) dwmac-sun8i need to have tx and rx fifo sizes set. I have used values from datasheets. After this patch, setting a non-default MTU (like 1000) value works and network is still useable. Tested-on: sun8i-h3-orangepi-pc Tested-on: sun8i-r40-bananapi-m2-ultra Tested-on: sun50i-a64-bananapi-m64 Tested-on: sun50i-h5-nanopi-neo-plus2 Tested-on: sun50i-h6-pine-h64 Fixes: 9f93ac8d408 ("net-next: stmmac: Add dwmac-sun8i") Reported-by: Belisko Marek Signed-off-by: Corentin Labbe Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 961d9a6e47b9880068317638dbd413b3a5691a25 Author: Hayes Wang Date: Fri Mar 19 15:37:21 2021 +0800 r8152: limit the RX buffer size of RTL8153A for USB 2.0 [ Upstream commit f91a50d8b51b5c8ef1cfb08115a005bba4250507 ] If the USB host controller is EHCI, the throughput is reduced from 300Mb/s to 60Mb/s, when the rx buffer size is modified from 16K to 32K. According to the EHCI spec, the maximum size of the qTD is 20K. Therefore, when the driver uses more than 20K buffer, the latency time of EHCI would be increased. And, it let the RTL8153A get worse throughput. However, the driver uses alloc_pages() for rx buffer, so I limit the rx buffer to 16K rather than 20K. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205923 Fixes: ec5791c202ac ("r8152: separate the rx buffer size") Reported-by: Robert Davies Signed-off-by: Hayes Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2330d46db081367db6b20161ed280b5024799fe8 Author: Jesse Brandeburg Date: Wed Mar 3 12:51:03 2021 -0800 igb: check timestamp validity [ Upstream commit f0a03a026857d6c7766eb7d5835edbf5523ca15c ] Add a couple of checks to make sure timestamping is on and that the timestamp value from DMA is valid. This avoids any functional issues that could come from a misinterpreted time stamp. One of the functions changed doesn't need a return value added because there was no value in checking from the calling locations. While here, fix a couple of reverse christmas tree issues next to the code being changed. Fixes: f56e7bba22fa ("igb: Pull timestamp from fragment before adding it to skb") Fixes: 9cbc948b5a20 ("igb: add XDP support") Signed-off-by: Jesse Brandeburg Tested-by: Dave Switzer Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 421e0d731070fb497212ba929df3623cfce4561d Author: Johan Hovold Date: Thu Mar 18 16:57:49 2021 +0100 net: cdc-phonet: fix data-interface release on probe failure [ Upstream commit c79a707072fe3fea0e3c92edee6ca85c1e53c29f ] Set the disconnected flag before releasing the data interface in case netdev registration fails to avoid having the disconnect callback try to deregister the never registered netdev (and trigger a WARN_ON()). Fixes: 87cf65601e17 ("USB host CDC Phonet network interface driver") Signed-off-by: Johan Hovold Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 943e1583bf8a5cbcedfc4a00d92d8aac9e7e436d Author: Jiri Bohac Date: Thu Mar 18 04:42:53 2021 +0100 net: check all name nodes in __dev_alloc_name [ Upstream commit 6c015a2256801597fadcbc11d287774c9c512fa5 ] __dev_alloc_name(), when supplied with a name containing '%d', will search for the first available device number to generate a unique device name. Since commit ff92741270bf8b6e78aa885f166b68c7a67ab13a ("net: introduce name_node struct to be used in hashlist") network devices may have alternate names. __dev_alloc_name() does take these alternate names into account, possibly generating a name that is already taken and failing with -ENFILE as a result. This demonstrates the bug: # rmmod dummy 2>/dev/null # ip link property add dev lo altname dummy0 # modprobe dummy numdummies=1 modprobe: ERROR: could not insert 'dummy': Too many open files in system Instead of creating a device named dummy1, modprobe fails. Fix this by checking all the names in the d->name_node list, not just d->name. Signed-off-by: Jiri Bohac Fixes: ff92741270bf ("net: introduce name_node struct to be used in hashlist") Reviewed-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 748a158359d7c442ded1f29efe49975deec7f08f Author: Hariprasad Kelam Date: Thu Mar 18 19:45:48 2021 +0530 octeontx2-af: fix infinite loop in unmapping NPC counter [ Upstream commit 64451b98306bf1334a62bcd020ec92bdb4cb68db ] unmapping npc counter works in a way by traversing all mcam entries to find which mcam rule is associated with counter. But loop cursor variable 'entry' is not incremented before checking next mcam entry which resulting in infinite loop. This in turn hogs the kworker thread forever and no other mbox message is processed by AF driver after that. Fix this by updating entry value before checking next mcam entry. Fixes: a958dd59f9ce ("octeontx2-af: Map or unmap NPC MCAM entry and counter") Signed-off-by: Hariprasad Kelam Signed-off-by: Sunil Kovvuri Goutham Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b553f45c76ec245c50cfc42e290af795e0abeb22 Author: Geetha sowjanya Date: Thu Mar 18 19:45:47 2021 +0530 octeontx2-pf: Clear RSS enable flag on interace down [ Upstream commit f12098ce9b43e1a6fcaa524acbd90f9118a74c0a ] RSS configuration can not be get/set when interface is in down state as they required mbox communication. RSS enable flag status is used for set/get configuration. Current code do not clear the RSS enable flag on interface down which lead to mbox error while trying to set/get RSS configuration. Fixes: 85069e95e531 ("octeontx2-pf: Receive side scaling support") Signed-off-by: Geetha sowjanya Signed-off-by: Hariprasad Kelam Signed-off-by: Sunil Kovvuri Goutham Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 11e94cfa9dd8003282abff3d529250b0fe94f3ca Author: Geetha sowjanya Date: Thu Mar 18 19:45:46 2021 +0530 octeontx2-af: Fix irq free in rvu teardown [ Upstream commit ae2619dd4fccdad9876aa5f900bd85484179c50f ] Current devlink code try to free already freed irqs as the irq_allocate flag is not cleared after free leading to kernel crash while removing rvu driver. The patch fixes the irq free sequence and clears the irq_allocate flag on free. Fixes: 7304ac4567bc ("octeontx2-af: Add mailbox IRQ and msg handlers") Signed-off-by: Geetha sowjanya Signed-off-by: Hariprasad Kelam Signed-off-by: Sunil Kovvuri Goutham Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit da517ca38dc615015ad5e5d4b3e11c61fcdcff4a Author: Subbaraya Sundeep Date: Thu Mar 18 19:45:44 2021 +0530 octeontx2-af: Remove TOS field from MKEX TX [ Upstream commit ce86c2a531e2f2995ee55ea527c1f39ba1d95f73 ] The MKEX profile describes what packet fields need to be extracted from the input packet and how to place those packet fields in the output key for MCAM matching. The MKEX profile can be in a way where higher layer packet fields can overwrite lower layer packet fields in output MCAM Key. Hence MKEX profile is always ensured that there are no overlaps between any of the layers. But the commit 42006910b5ea ("octeontx2-af: cleanup KPU config data") introduced TX TOS field which overlaps with DMAC in MCAM key. This led to AF driver returning error when TX rule is installed with DMAC as match criteria since DMAC gets overwritten and cannot be supported. This patch fixes the issue by removing TOS field from MKEX TX profile. Fixes: 42006910b5ea ("octeontx2-af: cleanup KPU config data") Signed-off-by: Subbaraya Sundeep Signed-off-by: Hariprasad Kelam Signed-off-by: Sunil Kovvuri Goutham Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1055796ca03132e028a0a0a9b3118943b1e73f0c Author: Stanislaw Kardach Date: Sun Nov 15 01:22:51 2020 +0530 octeontx2-af: Modify default KEX profile to extract TX packet fields [ Upstream commit f1517f6f1d6fd97a18836b0fb6921f2cb105eeb4 ] The current default Key Extraction(KEX) profile can only use RX packet fields while generating the MCAM search key. The profile can't be used for matching TX packet fields. This patch modifies the default KEX profile to add support for extracting TX packet fields into MCAM search key. Enabled Tx KPU packet parsing by configuring TX PKIND in tx_parse_cfg. Modified the KEX profile to extract 2 bytes of VLAN TCI from an offset of 2 bytes from LB_PTR. The LB_PTR points to the byte offset where the VLAN header starts. The NPC KPU parser profile has been modified to point LB_PTR to the starting byte offset of VLAN header which points to the tpid field. Signed-off-by: Stanislaw Kardach Signed-off-by: Sunil Goutham Signed-off-by: Naveen Mamindlapalli Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f896ae2886d18c7875e4a1ddd9b4d9bf152ed0e8 Author: Rakesh Babu Date: Thu Mar 18 19:45:43 2021 +0530 octeontx2-af: Formatting debugfs entry rsrc_alloc. [ Upstream commit f7884097141b615b6ce89c16f456a53902b4eec3 ] With the existing rsrc_alloc's format, there is misalignment for the pcifunc entries whose VF's index is a double digit. This patch fixes this. pcifunc NPA NIX0 NIX1 SSO GROUP SSOWS TIM CPT0 CPT1 REE0 REE1 PF0:VF0 8 5 PF0:VF1 9 3 PF0:VF10 18 10 PF0:VF11 19 8 PF0:VF12 20 11 PF0:VF13 21 9 PF0:VF14 22 12 PF0:VF15 23 10 PF1 0 0 Fixes: 23205e6d06d4 ("octeontx2-af: Dump current resource provisioning status") Signed-off-by: Rakesh Babu Signed-off-by: Hariprasad Kelam Signed-off-by: Sunil Kovvuri Goutham Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5f64c4c550c88d2994693117b1d3eb100783b350 Author: Jakub Kicinski Date: Wed Mar 17 09:55:15 2021 -0700 ipv6: weaken the v4mapped source check [ Upstream commit dcc32f4f183ab8479041b23a1525d48233df1d43 ] This reverts commit 6af1799aaf3f1bc8defedddfa00df3192445bbf3. Commit 6af1799aaf3f ("ipv6: drop incoming packets having a v4mapped source address") introduced an input check against v4mapped addresses. Use of such addresses on the wire is indeed questionable and not allowed on public Internet. As the commit pointed out https://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02 lists potential issues. Unfortunately there are applications which use v4mapped addresses, and breaking them is a clear regression. For example v4mapped addresses (or any semi-valid addresses, really) may be used for uni-direction event streams or packet export. Since the issue which sparked the addition of the check was with TCP and request_socks in particular push the check down to TCPv6 and DCCP. This restores the ability to receive UDPv6 packets with v4mapped address as the source. Keep using the IPSTATS_MIB_INHDRERRORS statistic to minimize the user-visible changes. Fixes: 6af1799aaf3f ("ipv6: drop incoming packets having a v4mapped source address") Reported-by: Sunyi Shao Signed-off-by: Jakub Kicinski Acked-by: Mat Martineau Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9e48a3bc8ba26c5fa66f4efd75e84f89c127f67a Author: dillon min Date: Wed Mar 17 23:45:09 2021 +0800 ARM: dts: imx6ull: fix ubi filesystem mount failed [ Upstream commit e4817a1b6b77db538bc0141c3b138f2df803ce87 ] For NAND Ecc layout, there is a dependency from old kernel's nand driver setting and current. if old kernel use 4 bit ecc , we should use 4 bit in new kernel either. else will run into following error at filesystem mounting. So, enable fsl,use-minimum-ecc from device tree, to fix this mismatch [ 9.449265] ubi0: scanning is finished [ 9.463968] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 22528 bytes from PEB 513:4096, read only 22528 bytes, retry [ 9.486940] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 22528 bytes from PEB 513:4096, read only 22528 bytes, retry [ 9.509906] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 22528 bytes from PEB 513:4096, read only 22528 bytes, retry [ 9.532845] ubi0 error: ubi_io_read: error -74 (ECC error) while reading 22528 bytes from PEB 513:4096, read 22528 bytes Fixes: f9ecf10cb88c ("ARM: dts: imx6ull: add MYiR MYS-6ULX SBC") Signed-off-by: dillon min Reviewed-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit b4c574e4b47113090e57cfbdb7bd46f10094fed8 Author: Kumar Kartikeya Dwivedi Date: Wed Mar 17 17:28:58 2021 +0530 libbpf: Use SOCK_CLOEXEC when opening the netlink socket [ Upstream commit 58bfd95b554f1a23d01228672f86bb489bdbf4ba ] Otherwise, there exists a small window between the opening and closing of the socket fd where it may leak into processes launched by some other thread. Fixes: 949abbe88436 ("libbpf: add function to setup XDP") Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Daniel Borkmann Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20210317115857.6536-1-memxor@gmail.com Signed-off-by: Sasha Levin commit 86e525bc04f24d503cc6178d19f61b51727e6e91 Author: Namhyung Kim Date: Wed Mar 17 23:54:14 2021 +0900 libbpf: Fix error path in bpf_object__elf_init() [ Upstream commit 8f3f5792f2940c16ab63c614b26494c8689c9c1e ] When it failed to get section names, it should call into bpf_object__elf_finish() like others. Fixes: 88a82120282b ("libbpf: Factor out common ELF operations and improve logging") Signed-off-by: Namhyung Kim Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20210317145414.884817-1-namhyung@kernel.org Signed-off-by: Sasha Levin commit 4280132339ce99b6521216d8b8e56b1bb462189e Author: Yinjun Zhang Date: Wed Mar 17 13:42:24 2021 +0100 netfilter: flowtable: Make sure GC works periodically in idle system [ Upstream commit 740b486a8d1f966e68ac0666f1fd57441a7cda94 ] Currently flowtable's GC work is initialized as deferrable, which means GC cannot work on time when system is idle. So the hardware offloaded flow may be deleted for timeout, since its used time is not timely updated. Resolve it by initializing the GC work as delayed work instead of deferrable. Fixes: c29f74e0df7a ("netfilter: nf_flow_table: hardware offload support") Signed-off-by: Yinjun Zhang Signed-off-by: Louis Peens Signed-off-by: Simon Horman Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 186d8dc40a65f0248df2ed34292f1296158d0be4 Author: Pablo Neira Ayuso Date: Wed Mar 17 12:54:57 2021 +0100 netfilter: nftables: allow to update flowtable flags [ Upstream commit 7b35582cd04ace2fd1807c1b624934e465cc939d ] Honor flowtable flags from the control update path. Disallow disabling to toggle hardware offload support though. Fixes: 8bb69f3b2918 ("netfilter: nf_tables: add flowtable offload control plane") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 4a741b4df032de7de45e709ead6d8e4f5ce8d20b Author: Pablo Neira Ayuso Date: Wed Mar 17 11:31:55 2021 +0100 netfilter: nftables: report EOPNOTSUPP on unsupported flowtable flags [ Upstream commit 7e6136f1b7272b2202817cff37ada355eb5e6784 ] Error was not set accordingly. Fixes: 8bb69f3b2918 ("netfilter: nf_tables: add flowtable offload control plane") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit a96a8cb0500aab0fa7521c8677c7805cea477c50 Author: wenxu Date: Wed Mar 17 12:02:43 2021 +0800 net/sched: cls_flower: fix only mask bit check in the validate_ct_state [ Upstream commit afa536d8405a9ca36e45ba035554afbb8da27b82 ] The ct_state validate should not only check the mask bit and also check mask_bit & key_bit.. For the +new+est case example, The 'new' and 'est' bits should be set in both state_mask and state flags. Or the -new-est case also will be reject by kernel. When Openvswitch with two flows ct_state=+trk+new,action=commit,forward ct_state=+trk+est,action=forward A packet go through the kernel and the contrack state is invalid, The ct_state will be +trk-inv. Upcall to the ovs-vswitchd, the finally dp action will be drop with -new-est+trk. Fixes: 1bcc51ac0731 ("net/sched: cls_flower: Reject invalid ct_state flags rules") Fixes: 3aed8b63336c ("net/sched: cls_flower: validate ct_state for invalid and reply flags") Signed-off-by: wenxu Reviewed-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6233c2d096338cd4b7ad97f1e2f84f97b06e15f0 Author: Shannon Nelson Date: Tue Mar 16 17:07:47 2021 -0700 ionic: linearize tso skb with too many frags [ Upstream commit d2c21422323b06938b3c070361dc544f047489d7 ] We were linearizing non-TSO skbs that had too many frags, but we weren't checking number of frags on TSO skbs. This could lead to a bad page reference when we received a TSO skb with more frags than the Tx descriptor could support. v2: use gso_segs rather than yet another division don't rework the check on the nr_frags Fixes: 0f3154e6bcb3 ("ionic: Add Tx and Rx handling") Signed-off-by: Shannon Nelson Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7637048707e53c78810d9529bda92cbc820dc488 Author: Dmitry Baryshkov Date: Thu Feb 25 01:47:51 2021 +0300 drm/msm/dsi: fix check-before-set in the 7nm dsi_pll code [ Upstream commit 3b24cdfc721a5f1098da22f9f68ff5f4a5efccc9 ] Fix setting min/max DSI PLL rate for the V4.1 7nm DSI PLL (used on sm8250). Current code checks for pll->type before it is set (as it is set in the msm_dsi_pll_init() after calling device-specific functions. Cc: Jonathan Marek Fixes: 1ef7c99d145c ("drm/msm/dsi: add support for 7nm DSI PHY/PLL") Signed-off-by: Dmitry Baryshkov Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 126aa8f234246654e121f37b49b4a5d249e2a86a Author: Alexei Starovoitov Date: Tue Mar 16 12:58:15 2021 -0700 ftrace: Fix modify_ftrace_direct. [ Upstream commit 8a141dd7f7060d1e64c14a5257e0babae20ac99b ] The following sequence of commands: register_ftrace_direct(ip, addr1); modify_ftrace_direct(ip, addr1, addr2); unregister_ftrace_direct(ip, addr2); will cause the kernel to warn: [ 30.179191] WARNING: CPU: 2 PID: 1961 at kernel/trace/ftrace.c:5223 unregister_ftrace_direct+0x130/0x150 [ 30.180556] CPU: 2 PID: 1961 Comm: test_progs W O 5.12.0-rc2-00378-g86bc10a0a711-dirty #3246 [ 30.182453] RIP: 0010:unregister_ftrace_direct+0x130/0x150 When modify_ftrace_direct() changes the addr from old to new it should update the addr stored in ftrace_direct_funcs. Otherwise the final unregister_ftrace_direct() won't find the address and will cause the splat. Fixes: 0567d6809182 ("ftrace: Add modify_ftrace_direct()") Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Reviewed-by: Steven Rostedt (VMware) Link: https://lore.kernel.org/bpf/20210316195815.34714-1-alexei.starovoitov@gmail.com Signed-off-by: Sasha Levin commit 29b8834cf828cfa2cabdcf00d21e1a1865af6064 Author: Louis Peens Date: Tue Mar 16 19:13:10 2021 +0100 nfp: flower: fix pre_tun mask id allocation [ Upstream commit d8ce0275e45ec809a33f98fc080fe7921b720dfb ] pre_tun_rule flows does not follow the usual add-flow path, instead they are used to update the pre_tun table on the firmware. This means that if the mask-id gets allocated here the firmware will never see the "NFP_FL_META_FLAG_MANAGE_MASK" flag for the specific mask id, which triggers the allocation on the firmware side. This leads to the firmware mask being corrupted and causing all sorts of strange behaviour. Fixes: f12725d98cbe ("nfp: flower: offload pre-tunnel rules") Signed-off-by: Louis Peens Signed-off-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 47dae14b21f7da4cf9ea3359aa4b4c75bf55636a Author: Louis Peens Date: Tue Mar 16 19:13:09 2021 +0100 nfp: flower: add ipv6 bit to pre_tunnel control message [ Upstream commit 5c4f5e19d6a8e159127b9d653bb67e0dc7a28047 ] Differentiate between ipv4 and ipv6 flows when configuring the pre_tunnel table to prevent them trampling each other in the table. Fixes: 783461604f7e ("nfp: flower: update flow merge code to support IPv6 tunnels") Signed-off-by: Louis Peens Signed-off-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 259b0122dea543fc637ce3d3d0ebe19cf58c179d Author: Louis Peens Date: Tue Mar 16 19:13:08 2021 +0100 nfp: flower: fix unsupported pre_tunnel flows [ Upstream commit 982e5ee23d764fe6158f67a7813d416335e978b0 ] There are some pre_tunnel flows combinations which are incorrectly being offloaded without proper support, fix these. - Matching on MPLS is not supported for pre_tun. - Match on IPv4/IPv6 layer must be present. - Destination MAC address must match pre_tun.dev MAC Fixes: 120ffd84a9ec ("nfp: flower: verify pre-tunnel rules") Signed-off-by: Louis Peens Signed-off-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit aeff815e76ef520bbbd33ff6f9ff39c1f067e73d Author: Carlos Llamas Date: Tue Mar 16 01:04:29 2021 +0000 selftests/net: fix warnings on reuseaddr_ports_exhausted [ Upstream commit 81f711d67a973bf8a6db9556faf299b4074d536e ] Fix multiple warnings seen with gcc 10.2.1: reuseaddr_ports_exhausted.c:32:41: warning: missing braces around initializer [-Wmissing-braces] 32 | struct reuse_opts unreusable_opts[12] = { | ^ 33 | {0, 0, 0, 0}, | { } { } Fixes: 7f204a7de8b0 ("selftests: net: Add SO_REUSEADDR test to check if 4-tuples are fully utilized.") Signed-off-by: Carlos Llamas Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit bd63bd78d303fa1ddd9fb4a2e04f0018003c256c Author: Brian Norris Date: Tue Feb 23 13:19:26 2021 +0800 mac80211: Allow HE operation to be longer than expected. [ Upstream commit 0f7e90faddeef53a3568f449a0c3992d77510b66 ] We observed some Cisco APs sending the following HE Operation IE in associate response: ff 0a 24 f4 3f 00 01 fc ff 00 00 00 Its HE operation parameter is 0x003ff4, so the expected total length is 7 which does not match the actual length = 10. This causes association failing with "HE AP is missing HE Capability/operation." According to P802.11ax_D4 Table9-94, HE operation is extensible, and according to 802.11-2016 10.27.8, STA should discard the part beyond the maximum length and parse the truncated element. Allow HE operation element to be longer than expected to handle this case and future extensions. Fixes: e4d005b80dee ("mac80211: refactor extended element parsing") Signed-off-by: Brian Norris Signed-off-by: Yen-lin Lai Link: https://lore.kernel.org/r/20210223051926.2653301-1-yenlinlai@chromium.org Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit f865127b1d26aab28696bcb136c492253fc2e4bf Author: Johannes Berg Date: Fri Feb 12 11:22:14 2021 +0100 mac80211: fix rate mask reset [ Upstream commit 1944015fe9c1d9fa5e9eb7ffbbb5ef8954d6753b ] Coverity reported the strange "if (~...)" condition that's always true. It suggested that ! was intended instead of ~, but upon further analysis I'm convinced that what really was intended was a comparison to 0xff/0xffff (in HT/VHT cases respectively), since this indicates that all of the rates are enabled. Change the comparison accordingly. I'm guessing this never really mattered because a reset to not having a rate mask is basically equivalent to having a mask that enables all rates. Reported-by: Colin Ian King Fixes: 2ffbe6d33366 ("mac80211: fix and optimize MCS mask handling") Fixes: b119ad6e726c ("mac80211: add rate mask logic for vht rates") Reviewed-by: Colin Ian King Link: https://lore.kernel.org/r/20210212112213.36b38078f569.I8546a20c80bc1669058eb453e213630b846e107b@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 48d0b548b49ecdf183e0c25911d4ee300ad79348 Author: Torin Cooper-Bennun Date: Wed Mar 3 14:43:51 2021 +0000 can: m_can: m_can_rx_peripheral(): fix RX being blocked by errors [ Upstream commit e98d9ee64ee2cc9b1d1a8e26610ec4d0392ebe50 ] For M_CAN peripherals, m_can_rx_handler() was called with quota = 1, which caused any error handling to block RX from taking place until the next time the IRQ handler is called. This had been observed to cause RX to be blocked indefinitely in some cases. This is fixed by calling m_can_rx_handler with a sensibly high quota. Fixes: f524f829b75a ("can: m_can: Create a m_can platform framework") Link: https://lore.kernel.org/r/20210303144350.4093750-1-torin@maxiluxsystems.com Suggested-by: Marc Kleine-Budde Signed-off-by: Torin Cooper-Bennun Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit afaca48e30175ba32a8aa0cd630ea0934a03883d Author: Torin Cooper-Bennun Date: Wed Mar 3 10:31:52 2021 +0000 can: m_can: m_can_do_rx_poll(): fix extraneous msg loss warning [ Upstream commit c0e399f3baf42279f48991554240af8c457535d1 ] Message loss from RX FIFO 0 is already handled in m_can_handle_lost_msg(), with netdev output included. Removing this warning also improves driver performance under heavy load, where m_can_do_rx_poll() may be called many times before this interrupt is cleared, causing this message to be output many times (thanks Mariusz Madej for this report). Fixes: e0d1f4816f2a ("can: m_can: add Bosch M_CAN controller support") Link: https://lore.kernel.org/r/20210303103151.3760532-1-torin@maxiluxsystems.com Reported-by: Mariusz Madej Signed-off-by: Torin Cooper-Bennun Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 4fcf59c2499039893149c5ad18a869249fe860af Author: Tong Zhang Date: Mon Mar 1 21:55:40 2021 -0500 can: c_can: move runtime PM enable/disable to c_can_platform [ Upstream commit 6e2fe01dd6f98da6cae8b07cd5cfa67abc70d97d ] Currently doing modprobe c_can_pci will make the kernel complain: Unbalanced pm_runtime_enable! this is caused by pm_runtime_enable() called before pm is initialized. This fix is similar to 227619c3ff7c, move those pm_enable/disable code to c_can_platform. Fixes: 4cdd34b26826 ("can: c_can: Add runtime PM support to Bosch C_CAN/D_CAN controller") Link: http://lore.kernel.org/r/20210302025542.987600-1-ztong0001@gmail.com Signed-off-by: Tong Zhang Tested-by: Uwe Kleine-König Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 524320e8034a9100bea04f311297a395f31bb857 Author: Tong Zhang Date: Sun Feb 28 21:45:11 2021 -0500 can: c_can_pci: c_can_pci_remove(): fix use-after-free [ Upstream commit 0429d6d89f97ebff4f17f13f5b5069c66bde8138 ] There is a UAF in c_can_pci_remove(). dev is released by free_c_can_dev() and is used by pci_iounmap(pdev, priv->base) later. To fix this issue, save the mmio address before releasing dev. Fixes: 5b92da0443c2 ("c_can_pci: generic module for C_CAN/D_CAN on PCI") Link: https://lore.kernel.org/r/20210301024512.539039-1-ztong0001@gmail.com Signed-off-by: Tong Zhang Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit f9a5974b9719afc0f9108844b93151f86b21225f Author: Jimmy Assarsson Date: Tue Mar 9 10:17:23 2021 +0100 can: kvaser_pciefd: Always disable bus load reporting [ Upstream commit 7c6e6bce08f918b64459415f58061d4d6df44994 ] Under certain circumstances, when switching from Kvaser's linuxcan driver (kvpciefd) to the SocketCAN driver (kvaser_pciefd), the bus load reporting is not disabled. This is flooding the kernel log with prints like: [3485.574677] kvaser_pciefd 0000:02:00.0: Received unexpected packet type 0x00000009 Always put the controller in the expected state, instead of assuming that bus load reporting is inactive. Note: If bus load reporting is enabled when the driver is loaded, you will still get a number of bus load packages (and printouts), before it is disabled. Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices") Link: https://lore.kernel.org/r/20210309091724.31262-1-jimmyassarsson@gmail.com Signed-off-by: Jimmy Assarsson Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit af3e6c3dcf5407ef98acd51c9faa727ed25e15c2 Author: Angelo Dureghello Date: Tue Mar 16 00:15:10 2021 +0100 can: flexcan: flexcan_chip_freeze(): fix chip freeze for missing bitrate [ Upstream commit 47c5e474bc1e1061fb037d13b5000b38967eb070 ] For cases when flexcan is built-in, bitrate is still not set at registering. So flexcan_chip_freeze() generates: [ 1.860000] *** ZERO DIVIDE *** FORMAT=4 [ 1.860000] Current process id is 1 [ 1.860000] BAD KERNEL TRAP: 00000000 [ 1.860000] PC: [<402e70c8>] flexcan_chip_freeze+0x1a/0xa8 To allow chip freeze, using an hardcoded timeout when bitrate is still not set. Fixes: ec15e27cc890 ("can: flexcan: enable RX FIFO after FRZ/HALT valid") Link: https://lore.kernel.org/r/20210315231510.650593-1-angelo@kernel-space.org Signed-off-by: Angelo Dureghello [mkl: use if instead of ? operator] Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 0cbadc0fb54ca7fbff1a6c175007bcb1c4b495e8 Author: Stephane Grosjean Date: Tue Mar 9 09:21:27 2021 +0100 can: peak_usb: add forgotten supported devices [ Upstream commit 59ec7b89ed3e921cd0625a8c83f31a30d485fdf8 ] Since the peak_usb driver also supports the CAN-USB interfaces "PCAN-USB X6" and "PCAN-Chip USB" from PEAK-System GmbH, this patch adds their names to the list of explicitly supported devices. Fixes: ea8b65b596d7 ("can: usb: Add support of PCAN-Chip USB stamp module") Fixes: f00b534ded60 ("can: peak: Add support for PCAN-USB X6 USB interface") Link: https://lore.kernel.org/r/20210309082128.23125-3-s.grosjean@peak-system.com Signed-off-by: Stephane Grosjean Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 3b3d9279be6c74633132280d0d167ec9694dea41 Author: Marc Kleine-Budde Date: Thu Feb 18 21:24:20 2021 +0100 can: isotp: TX-path: ensure that CAN frame flags are initialized [ Upstream commit d4eb538e1f48b3cf7bb6cb9eb39fe3e9e8a701f7 ] The previous patch ensures that the TX flags (struct can_isotp_ll_options::tx_flags) are 0 for classic CAN frames or a user configured value for CAN-FD frames. This patch sets the CAN frames flags unconditionally to the ISO-TP TX flags, so that they are initialized to a proper value. Otherwise when running "candump -x" on a classical CAN ISO-TP stream shows wrongly set "B" and "E" flags. | $ candump any,0:0,#FFFFFFFF -extA | [...] | can0 TX B E 713 [8] 2B 0A 0B 0C 0D 0E 0F 00 | can0 TX B E 713 [8] 2C 01 02 03 04 05 06 07 | can0 TX B E 713 [8] 2D 08 09 0A 0B 0C 0D 0E | can0 TX B E 713 [8] 2E 0F 00 01 02 03 04 05 Fixes: e057dd3fc20f ("can: add ISO 15765-2:2016 transport protocol") Link: https://lore.kernel.org/r/20210218215434.1708249-2-mkl@pengutronix.de Cc: Oliver Hartkopp Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit f88517dae95bc4811739b66ffbc652101e6ba7e7 Author: Marc Kleine-Budde Date: Thu Feb 18 21:58:36 2021 +0100 can: isotp: isotp_setsockopt(): only allow to set low level TX flags for CAN-FD [ Upstream commit e4912459bd5edd493b61bc7c3a5d9b2eb17f5a89 ] CAN-FD frames have struct canfd_frame::flags, while classic CAN frames don't. This patch refuses to set TX flags (struct can_isotp_ll_options::tx_flags) on non CAN-FD isotp sockets. Fixes: e057dd3fc20f ("can: add ISO 15765-2:2016 transport protocol") Link: https://lore.kernel.org/r/20210218215434.1708249-2-mkl@pengutronix.de Cc: Oliver Hartkopp Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 63f2a9bd3133a5171c90177a71c44dd116e89558 Author: Alexander Ovechkin Date: Mon Mar 15 14:05:45 2021 +0300 tcp: relookup sock for RST+ACK packets handled by obsolete req sock [ Upstream commit 7233da86697efef41288f8b713c10c2499cffe85 ] Currently tcp_check_req can be called with obsolete req socket for which big socket have been already created (because of CPU race or early demux assigning req socket to multiple packets in gro batch). Commit e0f9759f530bf789e984 ("tcp: try to keep packet if SYN_RCV race is lost") added retry in case when tcp_check_req is called for PSH|ACK packet. But if client sends RST+ACK immediatly after connection being established (it is performing healthcheck, for example) retry does not occur. In that case tcp_check_req tries to close req socket, leaving big socket active. Fixes: e0f9759f530 ("tcp: try to keep packet if SYN_RCV race is lost") Signed-off-by: Alexander Ovechkin Reported-by: Oleg Senin Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 50f41f2e29ff1980f7edfca40bbf81a4336b9feb Author: Eric Dumazet Date: Mon Mar 15 03:06:58 2021 -0700 tipc: better validate user input in tipc_nl_retrieve_key() [ Upstream commit 0217ed2848e8538bcf9172d97ed2eeb4a26041bb ] Before calling tipc_aead_key_size(ptr), we need to ensure we have enough data to dereference ptr->keylen. We probably also want to make sure tipc_aead_key_size() wont overflow with malicious ptr->keylen values. Syzbot reported: BUG: KMSAN: uninit-value in __tipc_nl_node_set_key net/tipc/node.c:2971 [inline] BUG: KMSAN: uninit-value in tipc_nl_node_set_key+0x9bf/0x13b0 net/tipc/node.c:3023 CPU: 0 PID: 21060 Comm: syz-executor.5 Not tainted 5.11.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x21c/0x280 lib/dump_stack.c:120 kmsan_report+0xfb/0x1e0 mm/kmsan/kmsan_report.c:118 __msan_warning+0x5f/0xa0 mm/kmsan/kmsan_instr.c:197 __tipc_nl_node_set_key net/tipc/node.c:2971 [inline] tipc_nl_node_set_key+0x9bf/0x13b0 net/tipc/node.c:3023 genl_family_rcv_msg_doit net/netlink/genetlink.c:739 [inline] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] genl_rcv_msg+0x1319/0x1610 net/netlink/genetlink.c:800 netlink_rcv_skb+0x6fa/0x810 net/netlink/af_netlink.c:2494 genl_rcv+0x63/0x80 net/netlink/genetlink.c:811 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline] netlink_unicast+0x11d6/0x14a0 net/netlink/af_netlink.c:1330 netlink_sendmsg+0x1740/0x1840 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg net/socket.c:672 [inline] ____sys_sendmsg+0xcfc/0x12f0 net/socket.c:2345 ___sys_sendmsg net/socket.c:2399 [inline] __sys_sendmsg+0x714/0x830 net/socket.c:2432 __compat_sys_sendmsg net/compat.c:347 [inline] __do_compat_sys_sendmsg net/compat.c:354 [inline] __se_compat_sys_sendmsg+0xa7/0xc0 net/compat.c:351 __ia32_compat_sys_sendmsg+0x4a/0x70 net/compat.c:351 do_syscall_32_irqs_on arch/x86/entry/common.c:79 [inline] __do_fast_syscall_32+0x102/0x160 arch/x86/entry/common.c:141 do_fast_syscall_32+0x6a/0xc0 arch/x86/entry/common.c:166 do_SYSENTER_32+0x73/0x90 arch/x86/entry/common.c:209 entry_SYSENTER_compat_after_hwframe+0x4d/0x5c RIP: 0023:0xf7f60549 Code: 03 74 c0 01 10 05 03 74 b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 RSP: 002b:00000000f555a5fc EFLAGS: 00000296 ORIG_RAX: 0000000000000172 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000020000200 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Uninit was created at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:121 [inline] kmsan_internal_poison_shadow+0x5c/0xf0 mm/kmsan/kmsan.c:104 kmsan_slab_alloc+0x8d/0xe0 mm/kmsan/kmsan_hooks.c:76 slab_alloc_node mm/slub.c:2907 [inline] __kmalloc_node_track_caller+0xa37/0x1430 mm/slub.c:4527 __kmalloc_reserve net/core/skbuff.c:142 [inline] __alloc_skb+0x2f8/0xb30 net/core/skbuff.c:210 alloc_skb include/linux/skbuff.h:1099 [inline] netlink_alloc_large_skb net/netlink/af_netlink.c:1176 [inline] netlink_sendmsg+0xdbc/0x1840 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg net/socket.c:672 [inline] ____sys_sendmsg+0xcfc/0x12f0 net/socket.c:2345 ___sys_sendmsg net/socket.c:2399 [inline] __sys_sendmsg+0x714/0x830 net/socket.c:2432 __compat_sys_sendmsg net/compat.c:347 [inline] __do_compat_sys_sendmsg net/compat.c:354 [inline] __se_compat_sys_sendmsg+0xa7/0xc0 net/compat.c:351 __ia32_compat_sys_sendmsg+0x4a/0x70 net/compat.c:351 do_syscall_32_irqs_on arch/x86/entry/common.c:79 [inline] __do_fast_syscall_32+0x102/0x160 arch/x86/entry/common.c:141 do_fast_syscall_32+0x6a/0xc0 arch/x86/entry/common.c:166 do_SYSENTER_32+0x73/0x90 arch/x86/entry/common.c:209 entry_SYSENTER_compat_after_hwframe+0x4d/0x5c Fixes: e1f32190cf7d ("tipc: add support for AEAD key setting via netlink") Signed-off-by: Eric Dumazet Cc: Tuong Lien Cc: Jon Maloy Cc: Ying Xue Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ddeba5b39ccadaac9abce231ead451a4baaff77c Author: Ong Boon Leong Date: Mon Mar 15 12:33:42 2021 +0800 net: phylink: Fix phylink_err() function name error in phylink_major_config [ Upstream commit d82c6c1aaccd2877b6082cebcb1746a13648a16d ] if pl->mac_ops->mac_finish() failed, phylink_err should use "mac_finish" instead of "mac_prepare". Fixes: b7ad14c2fe2d4 ("net: phylink: re-implement interface configuration with PCS") Signed-off-by: Ong Boon Leong Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 375f5169f23147044958cdcb57bd5c411292adbe Author: Xie He Date: Sun Mar 14 04:21:01 2021 -0700 net: hdlc_x25: Prevent racing between "x25_close" and "x25_xmit"/"x25_rx" [ Upstream commit bf0ffea336b493c0a8c8bc27b46683ecf1e8f294 ] "x25_close" is called by "hdlc_close" in "hdlc.c", which is called by hardware drivers' "ndo_stop" function. "x25_xmit" is called by "hdlc_start_xmit" in "hdlc.c", which is hardware drivers' "ndo_start_xmit" function. "x25_rx" is called by "hdlc_rcv" in "hdlc.c", which receives HDLC frames from "net/core/dev.c". "x25_close" races with "x25_xmit" and "x25_rx" because their callers race. However, we need to ensure that the LAPB APIs called in "x25_xmit" and "x25_rx" are called before "lapb_unregister" is called in "x25_close". This patch adds locking to ensure when "x25_xmit" and "x25_rx" are doing their work, "lapb_unregister" is not yet called in "x25_close". Reasons for not solving the racing between "x25_close" and "x25_xmit" by calling "netif_tx_disable" in "x25_close": 1. We still need to solve the racing between "x25_close" and "x25_rx"; 2. The design of the HDLC subsystem assumes the HDLC hardware drivers have full control over the TX queue, and the HDLC protocol drivers (like this driver) have no control. Controlling the queue here in the protocol driver may interfere with hardware drivers' control of the queue. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Xie He Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ee39ee5f437c1741cb9d1bde5b1aace11de50cb0 Author: Florian Westphal Date: Mon Mar 15 11:31:09 2021 +0100 netfilter: ctnetlink: fix dump of the expect mask attribute [ Upstream commit b58f33d49e426dc66e98ed73afb5d97b15a25f2d ] Before this change, the mask is never included in the netlink message, so "conntrack -E expect" always prints 0.0.0.0. In older kernels the l3num callback struct was passed as argument, based on tuple->src.l3num. After the l3num indirection got removed, the call chain is based on m.src.l3num, but this value is 0xffff. Init l3num to the correct value. Fixes: f957be9d349a3 ("netfilter: conntrack: remove ctnetlink callbacks from l3 protocol trackers") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit d5380ceede6fe2d2e305ee9664403089291eca9f Author: Hangbin Liu Date: Tue Mar 9 11:22:14 2021 +0800 selftests/bpf: Set gopt opt_class to 0 if get tunnel opt failed [ Upstream commit 31254dc9566221429d2cfb45fd5737985d70f2b6 ] When fixing the bpf test_tunnel.sh geneve failure. I only fixed the IPv4 part but forgot the IPv6 issue. Similar with the IPv4 fixes 557c223b643a ("selftests/bpf: No need to drop the packet when there is no geneve opt"), when there is no tunnel option and bpf_skb_get_tunnel_opt() returns error, there is no need to drop the packets and break all geneve rx traffic. Just set opt_class to 0 and keep returning TC_ACT_OK at the end. Fixes: 557c223b643a ("selftests/bpf: No need to drop the packet when there is no geneve opt") Fixes: 933a741e3b82 ("selftests/bpf: bpf tunnel test.") Signed-off-by: Hangbin Liu Signed-off-by: Daniel Borkmann Acked-by: William Tu Link: https://lore.kernel.org/bpf/20210309032214.2112438-1-liuhangbin@gmail.com Signed-off-by: Sasha Levin commit 33cc382c5830c7fbbc69625c3cb29b5fd0f808f2 Author: Alexander Lobakin Date: Fri Mar 12 20:08:57 2021 +0000 flow_dissector: fix byteorder of dissected ICMP ID [ Upstream commit a25f822285420486f5da434efc8d940d42a83bce ] flow_dissector_key_icmp::id is of type u16 (CPU byteorder), ICMP header has its ID field in network byteorder obviously. Sparse says: net/core/flow_dissector.c:178:43: warning: restricted __be16 degrades to integer Convert ID value to CPU byteorder when storing it into flow_dissector_key_icmp. Fixes: 5dec597e5cd0 ("flow_dissector: extract more ICMP information") Signed-off-by: Alexander Lobakin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit fce6fb90218935f7319265459484b3762c80d0a8 Author: Eric Dumazet Date: Fri Mar 12 08:59:48 2021 -0800 net: qrtr: fix a kernel-infoleak in qrtr_recvmsg() [ Upstream commit 50535249f624d0072cd885bcdce4e4b6fb770160 ] struct sockaddr_qrtr has a 2-byte hole, and qrtr_recvmsg() currently does not clear it before copying kernel data to user space. It might be too late to name the hole since sockaddr_qrtr structure is uapi. BUG: KMSAN: kernel-infoleak in kmsan_copy_to_user+0x9c/0xb0 mm/kmsan/kmsan_hooks.c:249 CPU: 0 PID: 29705 Comm: syz-executor.3 Not tainted 5.11.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x21c/0x280 lib/dump_stack.c:120 kmsan_report+0xfb/0x1e0 mm/kmsan/kmsan_report.c:118 kmsan_internal_check_memory+0x202/0x520 mm/kmsan/kmsan.c:402 kmsan_copy_to_user+0x9c/0xb0 mm/kmsan/kmsan_hooks.c:249 instrument_copy_to_user include/linux/instrumented.h:121 [inline] _copy_to_user+0x1ac/0x270 lib/usercopy.c:33 copy_to_user include/linux/uaccess.h:209 [inline] move_addr_to_user+0x3a2/0x640 net/socket.c:237 ____sys_recvmsg+0x696/0xd50 net/socket.c:2575 ___sys_recvmsg net/socket.c:2610 [inline] do_recvmmsg+0xa97/0x22d0 net/socket.c:2710 __sys_recvmmsg net/socket.c:2789 [inline] __do_sys_recvmmsg net/socket.c:2812 [inline] __se_sys_recvmmsg+0x24a/0x410 net/socket.c:2805 __x64_sys_recvmmsg+0x62/0x80 net/socket.c:2805 do_syscall_64+0x9f/0x140 arch/x86/entry/common.c:48 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x465f69 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f43659d6188 EFLAGS: 00000246 ORIG_RAX: 000000000000012b RAX: ffffffffffffffda RBX: 000000000056bf60 RCX: 0000000000465f69 RDX: 0000000000000008 RSI: 0000000020003e40 RDI: 0000000000000003 RBP: 00000000004bfa8f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000010060 R11: 0000000000000246 R12: 000000000056bf60 R13: 0000000000a9fb1f R14: 00007f43659d6300 R15: 0000000000022000 Local variable ----addr@____sys_recvmsg created at: ____sys_recvmsg+0x168/0xd50 net/socket.c:2550 ____sys_recvmsg+0x168/0xd50 net/socket.c:2550 Bytes 2-3 of 12 are uninitialized Memory access of size 12 starts at ffff88817c627b40 Data copied to user address 0000000020000140 Fixes: bdabad3e363d ("net: Add Qualcomm IPC router") Signed-off-by: Eric Dumazet Cc: Courtney Cavin Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6d3635ed12e780375857cbd80d2b46229443c669 Author: Alex Elder Date: Fri Mar 12 09:12:48 2021 -0600 net: ipa: terminate message handler arrays [ Upstream commit 3a9ef3e11c5d33e5cb355b4aad1a4caad2407541 ] When a QMI handle is initialized, an array of message handler structures is provided, defining how any received message should be handled based on its type and message ID. The QMI core code traverses this array when a message arrives and calls the function associated with the (type, msg_id) found in the array. The array is supposed to be terminated with an empty (all zero) entry though. Without it, an unsupported message will cause the QMI core code to go past the end of the array. Fix this bug, by properly terminating the message handler arrays provided when QMI handles are set up by the IPA driver. Fixes: 530f9216a9537 ("soc: qcom: ipa: AP/modem communications") Reported-by: Sujit Kautkar Signed-off-by: Alex Elder Reviewed-by: Bjorn Andersson Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1701bd22b05d772cfd1a3fac15d4e00b57215c87 Author: Douglas Anderson Date: Wed Feb 24 09:50:25 2021 -0800 clk: qcom: gcc-sc7180: Use floor ops for the correct sdcc1 clk [ Upstream commit 148ddaa89d4a0a927c4353398096cc33687755c1 ] While picking commit a8cd989e1a57 ("mmc: sdhci-msm: Warn about overclocking SD/MMC") back to my tree I was surprised that it was reporting warnings. I thought I fixed those! Looking closer at the fix, I see that I totally bungled it (or at least I halfway bungled it). The SD card clock got fixed (and that was the one I was really focused on fixing), but I totally adjusted the wrong clock for eMMC. Sigh. Let's fix my dumb mistake. Now both SD and eMMC have floor for the "apps" clock. This doesn't matter a lot for the final clock rate for HS400 eMMC but could matter if someone happens to put some slower eMMC on a sc7180. We also transition through some of these lower rates sometimes and having them wrong could cause problems during these transitions. These were the messages I was seeing at boot: mmc1: Card appears overclocked; req 52000000 Hz, actual 100000000 Hz mmc1: Card appears overclocked; req 52000000 Hz, actual 100000000 Hz mmc1: Card appears overclocked; req 104000000 Hz, actual 192000000 Hz Fixes: 6d37a8d19283 ("clk: qcom: gcc-sc7180: Use floor ops for sdcc clks") Signed-off-by: Douglas Anderson Link: https://lore.kernel.org/r/20210224095013.1.I2e2ba4978cfca06520dfb5d757768f9c42140f7c@changeid Reviewed-by: Taniya Das Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit b50c46ef67d602b449bf5fd730a4a64ba2f6016f Author: Dylan Hung Date: Fri Mar 12 11:04:05 2021 +1030 ftgmac100: Restart MAC HW once [ Upstream commit 6897087323a2fde46df32917462750c069668b2f ] The interrupt handler may set the flag to reset the mac in the future, but that flag is not cleared once the reset has occurred. Fixes: 10cbd6407609 ("ftgmac100: Rework NAPI & interrupts handling") Signed-off-by: Dylan Hung Acked-by: Benjamin Herrenschmidt Reviewed-by: Joel Stanley Signed-off-by: Joel Stanley Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e64a5a5b8e93a4064da38cde8b25e68750c60d54 Author: Florian Fainelli Date: Wed Mar 10 20:53:42 2021 -0800 net: phy: broadcom: Add power down exit reset state delay [ Upstream commit 7a1468ba0e02eee24ae1353e8933793a27198e20 ] Per the datasheet, when we clear the power down bit, the PHY remains in an internal reset state for 40us and then resume normal operation. Account for that delay to avoid any issues in the future if genphy_resume() changes. Fixes: fe26821fa614 ("net: phy: broadcom: Wire suspend/resume for BCM54810") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 87378c850fee4f41f3d816aeaa0b5e69f2522f51 Author: Lv Yunlong Date: Wed Mar 10 20:01:40 2021 -0800 net/qlcnic: Fix a use after free in qlcnic_83xx_get_minidump_template [ Upstream commit db74623a3850db99cb9692fda9e836a56b74198d ] In qlcnic_83xx_get_minidump_template, fw_dump->tmpl_hdr was freed by vfree(). But unfortunately, it is used when extended is true. Fixes: 7061b2bdd620e ("qlogic: Deletion of unnecessary checks before two function calls") Signed-off-by: Lv Yunlong Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 648b62f10cec8070e9d0ce82d3c2828cfba75b4a Author: Dinghao Liu Date: Sun Feb 28 17:44:23 2021 +0800 e1000e: Fix error handling in e1000_set_d0_lplu_state_82571 [ Upstream commit b52912b8293f2c496f42583e65599aee606a0c18 ] There is one e1e_wphy() call in e1000_set_d0_lplu_state_82571 that we have caught its return value but lack further handling. Check and terminate the execution flow just like other e1e_wphy() in this function. Fixes: bc7f75fa9788 ("[E1000E]: New pci-express e1000 driver (currently for ICH9 devices only)") Signed-off-by: Dinghao Liu Acked-by: Sasha Neftin Tested-by: Dvora Fuxbrumer Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 8ed431fec35568ad228d5be46831059e456b0337 Author: Vitaly Lifshits Date: Wed Oct 21 14:59:37 2020 +0300 e1000e: add rtnl_lock() to e1000_reset_task [ Upstream commit 21f857f0321d0d0ea9b1a758bd55dc63d1cb2437 ] A possible race condition was found in e1000_reset_task, after discovering a similar issue in igb driver via commit 024a8168b749 ("igb: reinit_locked() should be called with rtnl_lock"). Added rtnl_lock() and rtnl_unlock() to avoid this. Fixes: bc7f75fa9788 ("[E1000E]: New pci-express e1000 driver (currently for ICH9 devices only)") Suggested-by: Jakub Kicinski Signed-off-by: Vitaly Lifshits Tested-by: Dvora Fuxbrumer Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 5994a096570f8c90bf37a5ce4dea8904db83d0b4 Author: Andre Guedes Date: Tue Mar 9 22:42:56 2021 -0800 igc: Fix igc_ptp_rx_pktstamp() [ Upstream commit fc9e5020971d57d7d0b3fef9e2ab2108fcb5588b ] The comment describing the timestamps layout in the packet buffer is wrong and the code is actually retrieving the timestamp in Timer 1 reference instead of Timer 0. This hasn't been a big issue so far because hardware is configured to report both timestamps using Timer 0 (see IGC_SRRCTL register configuration in igc_ptp_enable_rx_timestamp() helper). This patch fixes the comment and the code so we retrieve the timestamp in Timer 0 reference as expected. This patch also takes the opportunity to get rid of the hw.mac.type check since it is not required. Fixes: 81b055205e8ba ("igc: Add support for RX timestamping") Signed-off-by: Andre Guedes Signed-off-by: Vedang Patel Signed-off-by: Jithu Joseph Reviewed-by: Maciej Fijalkowski Tested-by: Dvora Fuxbrumer Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 0963fadcf536cc7905b0904a4a05a2eb742e9255 Author: Muhammad Husaini Zulkifli Date: Sat Feb 20 00:36:48 2021 +0800 igc: Fix Supported Pause Frame Link Setting [ Upstream commit 9a4a1cdc5ab52118c1f2b216f4240830b6528d32 ] The Supported Pause Frame always display "No" even though the Advertised pause frame showing the correct setting based on the pause parameters via ethtool. Set bit in link_ksettings to "Supported" for Pause Frame. Before output: Supported pause frame use: No Expected output: Supported pause frame use: Symmetric Fixes: 8c5ad0dae93c ("igc: Add ethtool support") Signed-off-by: Muhammad Husaini Zulkifli Reviewed-by: Malli C Tested-by: Dvora Fuxbrumer Acked-by: Sasha Neftin Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit d5330d5cc3adcfaaecbe1d3b5bd7a5c93f783186 Author: Muhammad Husaini Zulkifli Date: Sat Feb 20 00:36:47 2021 +0800 igc: Fix Pause Frame Advertising [ Upstream commit 8876529465c368beafd51a70f79d7a738f2aadf4 ] Fix Pause Frame Advertising when getting the advertisement via ethtool. Remove setting the "advertising" bit in link_ksettings during default case when Tx and Rx are in off state with Auto Negotiate off. Below is the original output of advertisement link during Tx and Rx off: Advertised pause frame use: Symmetric Receive-only Expected output: Advertised pause frame use: No Fixes: 8c5ad0dae93c ("igc: Add ethtool support") Signed-off-by: Muhammad Husaini Zulkifli Reviewed-by: Malli C Acked-by: Sasha Neftin Tested-by: Dvora Fuxbrumer Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit d85ffade499ada9cc7c21a77611cc3fcf3f66a3a Author: Sasha Neftin Date: Tue Oct 20 16:34:00 2020 +0300 igc: reinit_locked() should be called with rtnl_lock [ Upstream commit 6da262378c99b17b1a1ac2e42aa65acc1bd471c7 ] This commit applies to the igc_reset_task the same changes that were applied to the igb driver in commit 024a8168b749 ("igb: reinit_locked() should be called with rtnl_lock") and fix possible race in reset subtask. Fixes: 0507ef8a0372 ("igc: Add transmit and receive fastpath and interrupt handlers") Suggested-by: Jakub Kicinski Signed-off-by: Sasha Neftin Tested-by: Dvora Fuxbrumer Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 4c91fc60e3f60be4cfcf180c247de97995b1ed00 Author: Florian Fainelli Date: Wed Mar 10 14:17:58 2021 -0800 net: dsa: bcm_sf2: Qualify phydev->dev_flags based on port [ Upstream commit 47142ed6c34d544ae9f0463e58d482289cbe0d46 ] Similar to commit 92696286f3bb37ba50e4bd8d1beb24afb759a799 ("net: bcmgenet: Set phydev->dev_flags only for internal PHYs") we need to qualify the phydev->dev_flags based on whether the port is connected to an internal or external PHY otherwise we risk having a flags collision with a completely different interpretation depending on the driver. Fixes: aa9aef77c761 ("net: dsa: bcm_sf2: communicate integrated PHY revision to PHY driver") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f64270027928adb74531ded0a59824cdd88d717e Author: Eric Dumazet Date: Wed Mar 10 08:26:41 2021 -0800 net: sched: validate stab values [ Upstream commit e323d865b36134e8c5c82c834df89109a5c60dab ] iproute2 package is well behaved, but malicious user space can provide illegal shift values and trigger UBSAN reports. Add stab parameter to red_check_params() to validate user input. syzbot reported: UBSAN: shift-out-of-bounds in ./include/net/red.h:312:18 shift exponent 111 is too large for 64-bit type 'long unsigned int' CPU: 1 PID: 14662 Comm: syz-executor.3 Not tainted 5.12.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x141/0x1d7 lib/dump_stack.c:120 ubsan_epilogue+0xb/0x5a lib/ubsan.c:148 __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:327 red_calc_qavg_from_idle_time include/net/red.h:312 [inline] red_calc_qavg include/net/red.h:353 [inline] choke_enqueue.cold+0x18/0x3dd net/sched/sch_choke.c:221 __dev_xmit_skb net/core/dev.c:3837 [inline] __dev_queue_xmit+0x1943/0x2e00 net/core/dev.c:4150 neigh_hh_output include/net/neighbour.h:499 [inline] neigh_output include/net/neighbour.h:508 [inline] ip6_finish_output2+0x911/0x1700 net/ipv6/ip6_output.c:117 __ip6_finish_output net/ipv6/ip6_output.c:182 [inline] __ip6_finish_output+0x4c1/0xe10 net/ipv6/ip6_output.c:161 ip6_finish_output+0x35/0x200 net/ipv6/ip6_output.c:192 NF_HOOK_COND include/linux/netfilter.h:290 [inline] ip6_output+0x1e4/0x530 net/ipv6/ip6_output.c:215 dst_output include/net/dst.h:448 [inline] NF_HOOK include/linux/netfilter.h:301 [inline] NF_HOOK include/linux/netfilter.h:295 [inline] ip6_xmit+0x127e/0x1eb0 net/ipv6/ip6_output.c:320 inet6_csk_xmit+0x358/0x630 net/ipv6/inet6_connection_sock.c:135 dccp_transmit_skb+0x973/0x12c0 net/dccp/output.c:138 dccp_send_reset+0x21b/0x2b0 net/dccp/output.c:535 dccp_finish_passive_close net/dccp/proto.c:123 [inline] dccp_finish_passive_close+0xed/0x140 net/dccp/proto.c:118 dccp_terminate_connection net/dccp/proto.c:958 [inline] dccp_close+0xb3c/0xe60 net/dccp/proto.c:1028 inet_release+0x12e/0x280 net/ipv4/af_inet.c:431 inet6_release+0x4c/0x70 net/ipv6/af_inet6.c:478 __sock_release+0xcd/0x280 net/socket.c:599 sock_close+0x18/0x20 net/socket.c:1258 __fput+0x288/0x920 fs/file_table.c:280 task_work_run+0xdd/0x1a0 kernel/task_work.c:140 tracehook_notify_resume include/linux/tracehook.h:189 [inline] Fixes: 8afa10cbe281 ("net_sched: red: Avoid illegal values") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 400199d6e6f6ec9d211913b304e87b1b27cd89a3 Author: Eric Dumazet Date: Wed Mar 10 01:56:36 2021 -0800 macvlan: macvlan_count_rx() needs to be aware of preemption [ Upstream commit dd4fa1dae9f4847cc1fd78ca468ad69e16e5db3e ] macvlan_count_rx() can be called from process context, it is thus necessary to disable preemption before calling u64_stats_update_begin() syzbot was able to spot this on 32bit arch: WARNING: CPU: 1 PID: 4632 at include/linux/seqlock.h:271 __seqprop_assert include/linux/seqlock.h:271 [inline] WARNING: CPU: 1 PID: 4632 at include/linux/seqlock.h:271 __seqprop_assert.constprop.0+0xf0/0x11c include/linux/seqlock.h:269 Modules linked in: Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 4632 Comm: kworker/1:3 Not tainted 5.12.0-rc2-syzkaller #0 Hardware name: ARM-Versatile Express Workqueue: events macvlan_process_broadcast Backtrace: [<82740468>] (dump_backtrace) from [<827406dc>] (show_stack+0x18/0x1c arch/arm/kernel/traps.c:252) r7:00000080 r6:60000093 r5:00000000 r4:8422a3c4 [<827406c4>] (show_stack) from [<82751b58>] (__dump_stack lib/dump_stack.c:79 [inline]) [<827406c4>] (show_stack) from [<82751b58>] (dump_stack+0xb8/0xe8 lib/dump_stack.c:120) [<82751aa0>] (dump_stack) from [<82741270>] (panic+0x130/0x378 kernel/panic.c:231) r7:830209b4 r6:84069ea4 r5:00000000 r4:844350d0 [<82741140>] (panic) from [<80244924>] (__warn+0xb0/0x164 kernel/panic.c:605) r3:8404ec8c r2:00000000 r1:00000000 r0:830209b4 r7:0000010f [<80244874>] (__warn) from [<82741520>] (warn_slowpath_fmt+0x68/0xd4 kernel/panic.c:628) r7:81363f70 r6:0000010f r5:83018e50 r4:00000000 [<827414bc>] (warn_slowpath_fmt) from [<81363f70>] (__seqprop_assert include/linux/seqlock.h:271 [inline]) [<827414bc>] (warn_slowpath_fmt) from [<81363f70>] (__seqprop_assert.constprop.0+0xf0/0x11c include/linux/seqlock.h:269) r8:5a109000 r7:0000000f r6:a568dac0 r5:89802300 r4:00000001 [<81363e80>] (__seqprop_assert.constprop.0) from [<81364af0>] (u64_stats_update_begin include/linux/u64_stats_sync.h:128 [inline]) [<81363e80>] (__seqprop_assert.constprop.0) from [<81364af0>] (macvlan_count_rx include/linux/if_macvlan.h:47 [inline]) [<81363e80>] (__seqprop_assert.constprop.0) from [<81364af0>] (macvlan_broadcast+0x154/0x26c drivers/net/macvlan.c:291) r5:89802300 r4:8a927740 [<8136499c>] (macvlan_broadcast) from [<81365020>] (macvlan_process_broadcast+0x258/0x2d0 drivers/net/macvlan.c:317) r10:81364f78 r9:8a86d000 r8:8a9c7e7c r7:8413aa5c r6:00000000 r5:00000000 r4:89802840 [<81364dc8>] (macvlan_process_broadcast) from [<802696a4>] (process_one_work+0x2d4/0x998 kernel/workqueue.c:2275) r10:00000008 r9:8404ec98 r8:84367a02 r7:ddfe6400 r6:ddfe2d40 r5:898dac80 r4:8a86d43c [<802693d0>] (process_one_work) from [<80269dcc>] (worker_thread+0x64/0x54c kernel/workqueue.c:2421) r10:00000008 r9:8a9c6000 r8:84006d00 r7:ddfe2d78 r6:898dac94 r5:ddfe2d40 r4:898dac80 [<80269d68>] (worker_thread) from [<80271f40>] (kthread+0x184/0x1a4 kernel/kthread.c:292) r10:85247e64 r9:898dac80 r8:80269d68 r7:00000000 r6:8a9c6000 r5:89a2ee40 r4:8a97bd00 [<80271dbc>] (kthread) from [<80200114>] (ret_from_fork+0x14/0x20 arch/arm/kernel/entry-common.S:158) Exception stack(0x8a9c7fb0 to 0x8a9c7ff8) Fixes: 412ca1550cbe ("macvlan: Move broadcasts into a work queue") Signed-off-by: Eric Dumazet Cc: Herbert Xu Reported-by: syzbot Acked-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2514c7ad115e762562c7bdd58bb1ab3425a98245 Author: Ido Schimmel Date: Wed Mar 10 12:28:01 2021 +0200 drop_monitor: Perform cleanup upon probe registration failure [ Upstream commit 9398e9c0b1d44eeb700e9e766c02bcc765c82570 ] In the rare case that drop_monitor fails to register its probe on the 'napi_poll' tracepoint, it will not deactivate its hysteresis timer as part of the error path. If the hysteresis timer was armed by the shortly lived 'kfree_skb' probe and user space retries to initiate tracing, a warning will be emitted for trying to initialize an active object [1]. Fix this by properly undoing all the operations that were done prior to probe registration, in both software and hardware code paths. Note that syzkaller managed to fail probe registration by injecting a slab allocation failure [2]. [1] ODEBUG: init active (active state 0) object type: timer_list hint: sched_send_work+0x0/0x60 include/linux/list.h:135 WARNING: CPU: 1 PID: 8649 at lib/debugobjects.c:505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505 Modules linked in: CPU: 1 PID: 8649 Comm: syz-executor.0 Not tainted 5.11.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505 [...] Call Trace: __debug_object_init+0x524/0xd10 lib/debugobjects.c:588 debug_timer_init kernel/time/timer.c:722 [inline] debug_init kernel/time/timer.c:770 [inline] init_timer_key+0x2d/0x340 kernel/time/timer.c:814 net_dm_trace_on_set net/core/drop_monitor.c:1111 [inline] set_all_monitor_traces net/core/drop_monitor.c:1188 [inline] net_dm_monitor_start net/core/drop_monitor.c:1295 [inline] net_dm_cmd_trace+0x720/0x1220 net/core/drop_monitor.c:1339 genl_family_rcv_msg_doit+0x228/0x320 net/netlink/genetlink.c:739 genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] genl_rcv_msg+0x328/0x580 net/netlink/genetlink.c:800 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502 genl_rcv+0x24/0x40 net/netlink/genetlink.c:811 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:672 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2348 ___sys_sendmsg+0xf3/0x170 net/socket.c:2402 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2435 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae [2] FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 1 CPU: 1 PID: 8645 Comm: syz-executor.0 Not tainted 5.11.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: dump_stack+0xfa/0x151 should_fail.cold+0x5/0xa should_failslab+0x5/0x10 __kmalloc+0x72/0x3f0 tracepoint_add_func+0x378/0x990 tracepoint_probe_register+0x9c/0xe0 net_dm_cmd_trace+0x7fc/0x1220 genl_family_rcv_msg_doit+0x228/0x320 genl_rcv_msg+0x328/0x580 netlink_rcv_skb+0x153/0x420 genl_rcv+0x24/0x40 netlink_unicast+0x533/0x7d0 netlink_sendmsg+0x856/0xd90 sock_sendmsg+0xcf/0x120 ____sys_sendmsg+0x6e8/0x810 ___sys_sendmsg+0xf3/0x170 __sys_sendmsg+0xe5/0x1b0 do_syscall_64+0x2d/0x70 entry_SYSCALL_64_after_hwframe+0x44/0xae Fixes: 70c69274f354 ("drop_monitor: Initialize timer and work item upon tracing enable") Fixes: 8ee2267ad33e ("drop_monitor: Convert to using devlink tracepoint") Reported-by: syzbot+779559d6503f3a56213d@syzkaller.appspotmail.com Signed-off-by: Ido Schimmel Reviewed-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7f041ee8effdb61c9ef38f91d9d8430b7efd7654 Author: Wei Wang Date: Tue Mar 9 18:20:35 2021 -0800 ipv6: fix suspecious RCU usage warning [ Upstream commit 28259bac7f1dde06d8ba324e222bbec9d4e92f2b ] Syzbot reported the suspecious RCU usage in nexthop_fib6_nh() when called from ipv6_route_seq_show(). The reason is ipv6_route_seq_start() calls rcu_read_lock_bh(), while nexthop_fib6_nh() calls rcu_dereference_rtnl(). The fix proposed is to add a variant of nexthop_fib6_nh() to use rcu_dereference_bh_rtnl() for ipv6_route_seq_show(). The reported trace is as follows: ./include/net/nexthop.h:416 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by syz-executor.0/17895: at: seq_read+0x71/0x12a0 fs/seq_file.c:169 at: seq_file_net include/linux/seq_file_net.h:19 [inline] at: ipv6_route_seq_start+0xaf/0x300 net/ipv6/ip6_fib.c:2616 stack backtrace: CPU: 1 PID: 17895 Comm: syz-executor.0 Not tainted 4.15.0-syzkaller #0 Call Trace: [] __dump_stack lib/dump_stack.c:17 [inline] [] dump_stack+0xd8/0x147 lib/dump_stack.c:53 [] lockdep_rcu_suspicious+0x153/0x15d kernel/locking/lockdep.c:5745 [] nexthop_fib6_nh include/net/nexthop.h:416 [inline] [] ipv6_route_native_seq_show net/ipv6/ip6_fib.c:2488 [inline] [] ipv6_route_seq_show+0x436/0x7a0 net/ipv6/ip6_fib.c:2673 [] seq_read+0xccf/0x12a0 fs/seq_file.c:276 [] proc_reg_read+0x10c/0x1d0 fs/proc/inode.c:231 [] do_loop_readv_writev fs/read_write.c:714 [inline] [] do_loop_readv_writev fs/read_write.c:701 [inline] [] do_iter_read+0x49e/0x660 fs/read_write.c:935 [] vfs_readv+0xfb/0x170 fs/read_write.c:997 [] kernel_readv fs/splice.c:361 [inline] [] default_file_splice_read+0x487/0x9c0 fs/splice.c:416 [] do_splice_to+0x129/0x190 fs/splice.c:879 [] splice_direct_to_actor+0x256/0x890 fs/splice.c:951 [] do_splice_direct+0x1dd/0x2b0 fs/splice.c:1060 [] do_sendfile+0x597/0xce0 fs/read_write.c:1459 [] SYSC_sendfile64 fs/read_write.c:1520 [inline] [] SyS_sendfile64+0x155/0x170 fs/read_write.c:1506 [] do_syscall_64+0x1ff/0x310 arch/x86/entry/common.c:305 [] entry_SYSCALL_64_after_hwframe+0x42/0xb7 Fixes: f88d8ea67fbdb ("ipv6: Plumb support for nexthop object in a fib6_info") Reported-by: syzbot Signed-off-by: Wei Wang Cc: David Ahern Cc: Ido Schimmel Cc: Petr Machata Cc: Eric Dumazet Reviewed-by: Ido Schimmel Reviewed-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 61219de4641363d87aa45c63bf8648cbaceaba78 Author: Maor Dickman Date: Tue Feb 16 13:39:18 2021 +0200 net/mlx5e: Don't match on Geneve options in case option masks are all zero [ Upstream commit 385d40b042e60aa0b677d7b400a0fefb44bcbaf4 ] The cited change added offload support for Geneve options without verifying the validity of the options masks, this caused offload of rules with match on Geneve options with class,type and data masks which are zero to fail. Fix by ignoring the match on Geneve options in case option masks are all zero. Fixes: 9272e3df3023 ("net/mlx5e: Geneve, Add support for encap/decap flows offload") Signed-off-by: Maor Dickman Reviewed-by: Roi Dayan Reviewed-by: Oz Shlomo Reviewed-by: Yevgeny Kliteynik Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit d0be25fa4f960dac846c894f43d481f3fa521864 Author: Maxim Mikityanskiy Date: Thu Feb 11 15:51:11 2021 +0200 net/mlx5e: When changing XDP program without reset, take refs for XSK RQs [ Upstream commit e5eb01344e9b09bb9d255b9727449186f7168df8 ] Each RQ (including XSK RQs) takes a reference to the XDP program. When an XDP program is attached or detached, the channels and queues are recreated, however, there is a special flow for changing an active XDP program to another one. In that flow, channels and queues stay alive, but the refcounts of the old and new XDP programs are adjusted. This flow didn't increment refcount by the number of active XSK RQs, and this commit fixes it. Fixes: db05815b36cb ("net/mlx5e: Add XSK zero-copy support") Signed-off-by: Maxim Mikityanskiy Reviewed-by: Tariq Toukan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 60b5ff15b41d0904a3806dab6f0f147258294d1e Author: Tariq Toukan Date: Tue Jan 12 13:21:17 2021 +0200 net/mlx5e: RX, Mind the MPWQE gaps when calculating offsets [ Upstream commit d5dd03b26ba49c4ffe67ee1937add82293c19794 ] Since cited patch, MLX5E_REQUIRED_WQE_MTTS is not a power of two. Hence, usage of MLX5E_LOG_ALIGNED_MPWQE_PPW should be replaced, as it lost some accuracy. Use the designated macro to calculate the number of required MTTs. This makes sure the solution in cited patch works properly. While here, un-inline mlx5e_get_mpwqe_offset(), and remove the unused RQ parameter. Fixes: c3c9402373fe ("net/mlx5e: Add resiliency in Striding RQ mode for packets larger than MTU") Signed-off-by: Tariq Toukan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 9857de932b30e794fbf63f0a0175643468ff9a15 Author: Georgi Valkov Date: Mon Mar 8 10:30:38 2021 -0800 libbpf: Fix INSTALL flag order [ Upstream commit e7fb6465d4c8e767e39cbee72464e0060ab3d20c ] It was reported ([0]) that having optional -m flag between source and destination arguments in install command breaks bpftools cross-build on MacOS. Move -m to the front to fix this issue. [0] https://github.com/openwrt/openwrt/pull/3959 Fixes: 7110d80d53f4 ("libbpf: Makefile set specified permission mode") Signed-off-by: Georgi Valkov Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20210308183038.613432-1-andrii@kernel.org Signed-off-by: Sasha Levin commit f7c3d7615e6c62d13e2b56b9eaf029f682e44cf8 Author: Tal Lossos Date: Sun Mar 7 14:09:48 2021 +0200 bpf: Change inode_storage's lookup_elem return value from NULL to -EBADF [ Upstream commit 769c18b254ca191b45047e1fcb3b2ce56fada0b6 ] bpf_fd_inode_storage_lookup_elem() returned NULL when getting a bad FD, which caused -ENOENT in bpf_map_copy_value. -EBADF error is better than -ENOENT for a bad FD behaviour. The patch was partially contributed by CyberArk Software, Inc. Fixes: 8ea636848aca ("bpf: Implement bpf_local_storage for inodes") Signed-off-by: Tal Lossos Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Acked-by: KP Singh Link: https://lore.kernel.org/bpf/20210307120948.61414-1-tallossos@gmail.com Signed-off-by: Sasha Levin commit 926cde9eec67cf3fe29cd68aaf4b759455c29046 Author: Maciej Fijalkowski Date: Wed Mar 3 16:29:03 2021 +0100 veth: Store queue_mapping independently of XDP prog presence [ Upstream commit edbea922025169c0e5cdca5ebf7bf5374cc5566c ] Currently, veth_xmit() would call the skb_record_rx_queue() only when there is XDP program loaded on peer interface in native mode. If peer has XDP prog in generic mode, then netif_receive_generic_xdp() has a call to netif_get_rxqueue(skb), so for multi-queue veth it will not be possible to grab a correct rxq. To fix that, store queue_mapping independently of XDP prog presence on peer interface. Fixes: 638264dc9022 ("veth: Support per queue XDP ring") Signed-off-by: Maciej Fijalkowski Signed-off-by: Daniel Borkmann Acked-by: Toshiaki Makita Link: https://lore.kernel.org/bpf/20210303152903.11172-1-maciej.fijalkowski@intel.com Signed-off-by: Sasha Levin commit f47a9b2570adafd274387d1b82a09fcb3424019f Author: Tony Lindgren Date: Thu Feb 18 13:46:33 2021 +0200 soc: ti: omap-prm: Fix occasional abort on reset deassert for dra7 iva [ Upstream commit effe89e40037038db7711bdab5d3401fe297d72c ] On reset deassert, we must wait a bit after the rstst bit change before we allow clockdomain autoidle again. Otherwise we get the following oops sometimes on dra7 with iva: Unhandled fault: imprecise external abort (0x1406) at 0x00000000 44000000.ocp:L3 Standard Error: MASTER MPU TARGET IVA_CONFIG (Read Link): At Address: 0x0005A410 : Data Access in User mode during Functional access Internal error: : 1406 [#1] SMP ARM ... (sysc_write_sysconfig) from [] (sysc_enable_module+0xcc/0x260) (sysc_enable_module) from [] (sysc_runtime_resume+0xc8/0x174) (sysc_runtime_resume) from [] (genpd_runtime_resume+0x94/0x224) (genpd_runtime_resume) from [] (__rpm_callback+0xd8/0x180) It is unclear what all devices this might affect, but presumably other devices with the rstst bit too can be affected. So let's just enable the delay for all the devices with rstst bit for now. Later on we may want to limit the list to the know affected devices if needed. Fixes: d30cd83f6853 ("soc: ti: omap-prm: add support for denying idle for reset clockdomain") Reported-by: Yongqin Liu Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 1f798907b4355ac6320d68f67fed1e8bc5d2a778 Author: Tony Lindgren Date: Wed Feb 10 10:53:48 2021 +0200 ARM: OMAP2+: Fix smartreflex init regression after dropping legacy data [ Upstream commit fbfa463be8dc7957ee4f81556e9e1ea2a951807d ] When I dropped legacy data for omap4 and dra7 smartreflex in favor of device tree based data, it seems I only testd for the "SmartReflex Class3 initialized" line in dmesg. I missed the fact that there is also omap_devinit_smartreflex() that happens later, and now it produces an error on boot for "No Voltage table for the corresponding vdd. Cannot create debugfs entries for n-values". This happens as we no longer have the smartreflex instance legacy data, and have not yet moved completely to device tree based booting for the driver. Let's fix the issue by changing the smartreflex init to use names. This should all eventually go away in favor of doing the init in the driver based on devicetree compatible value. Note that dra7xx_init_early() is not calling any voltage domain init like omap54xx_voltagedomains_init(), or a dra7 specific voltagedomains init. This means that on dra7 smartreflex is still not fully initialized, and also seems to be missing the related devicetree nodes. Fixes: a6b1e717e942 ("ARM: OMAP2+: Drop legacy platform data for omap4 smartreflex") Fixes: e54740b4afe8 ("ARM: OMAP2+: Drop legacy platform data for dra7 smartreflex") Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 965e6cb8d4c9e206852e5217dc8a95f58bb00b9e Author: Grygorii Strashko Date: Thu Jan 28 21:15:48 2021 +0200 bus: omap_l3_noc: mark l3 irqs as IRQF_NO_THREAD [ Upstream commit 7d7275b3e866cf8092bd12553ec53ba26864f7bb ] The main purpose of l3 IRQs is to catch OCP bus access errors and identify corresponding code places by showing call stack, so it's important to handle L3 interconnect errors as fast as possible. On RT these IRQs will became threaded and will be scheduled much more late from the moment actual error occurred so showing completely useless information. Hence, mark l3 IRQs as IRQF_NO_THREAD so they will not be forced threaded on RT or if force_irqthreads = true. Fixes: 0ee7261c9212 ("drivers: bus: Move the OMAP interconnect driver to drivers/bus/") Signed-off-by: Grygorii Strashko Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 921aae17bb0f02181fa05cf5580ebc855fdbd74d Author: Mikulas Patocka Date: Fri Mar 26 14:32:32 2021 -0400 dm ioctl: fix out of bounds array access when no devices commit 4edbe1d7bcffcd6269f3b5eb63f710393ff2ec7a upstream. If there are not any dm devices, we need to zero the "dev" argument in the first structure dm_name_list. However, this can cause out of bounds write, because the "needed" variable is zero and len may be less than eight. Fix this bug by reporting DM_BUFFER_FULL_FLAG if the result buffer is too small to hold the "nl->dev" value. Signed-off-by: Mikulas Patocka Reported-by: Dan Carpenter Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit d8b36c483d4708409f963095739aebe25b52a5c2 Author: JeongHyeon Lee Date: Thu Mar 11 21:10:50 2021 +0900 dm verity: fix DM_VERITY_OPTS_MAX value commit 160f99db943224e55906dd83880da1a704c6e6b9 upstream. Three optional parameters must be accepted at once in a DM verity table, e.g.: (verity_error_handling_mode) (ignore_zero_block) (check_at_most_once) Fix this to be possible by incrementing DM_VERITY_OPTS_MAX. Signed-off-by: JeongHyeon Lee Fixes: 843f38d382b1 ("dm verity: add 'check_at_most_once' option to only validate hashes once") Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 1e2d70d08adede3d5d8426c9fd1af427564a137f Author: Imre Deak Date: Mon Mar 22 22:28:17 2021 +0200 drm/i915: Fix the GT fence revocation runtime PM logic commit 8840e3bd981f128846b01c12d3966d115e8617c9 upstream. To optimize some task deferring it until runtime resume unless someone holds a runtime PM reference (because in this case the task can be done w/o the overhead of runtime resume), we have to use the runtime PM get-if-active logic: If the runtime PM usage count is 0 (and so get-if-in-use would return false) the runtime suspend handler is not necessarily called yet (it could be just pending), so the device is not necessarily powered down, and so the runtime resume handler is not guaranteed to be called. The fence revocation depends on the above deferral, so add a get-if-active helper and use it during fence revocation. v2: - Add code comment explaining the fence reg programming deferral logic to i915_vma_revoke_fence(). (Chris) - Add Cc: stable and Fixes: tags. (Chris) - Fix the function docbook comment. Cc: Chris Wilson Cc: # v4.12+ Fixes: 181df2d458f3 ("drm/i915: Take rpm wakelock for releasing the fence on unbind") Reviewed-by: Chris Wilson Signed-off-by: Imre Deak Link: https://patchwork.freedesktop.org/patch/msgid/20210322204223.919936-1-imre.deak@intel.com (cherry picked from commit 9d58aa46291d4d696bb1eac3436d3118f7bf2573) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit da6a9b5b17994fe2bcc152044674736b24bcaf57 Author: Alex Deucher Date: Thu Mar 18 16:44:10 2021 -0400 drm/amdgpu: Add additional Sienna Cichlid PCI ID commit c933b111094f2818571fc51b81b98ee0d370c035 upstream. Add new DID. Reviewed-by: Guchun Chen Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit dc28098f40b44705389fcae8596dc6a7668a95b3 Author: Alex Deucher Date: Tue Feb 16 12:22:40 2021 -0500 drm/amdgpu/display: restore AUX_DPHY_TX_CONTROL for DCN2.x commit 5c458585c0141754cdcbf25feebb547dd671b559 upstream. Commit 098214999c8f added fetching of the AUX_DPHY register values from the vbios, but it also changed the default values in the case when there are no values in the vbios. This causes problems with displays with high refresh rates. To fix this, switch back to the original default value for AUX_DPHY_TX_CONTROL. Fixes: 098214999c8f ("drm/amd/display: Read VBIOS Golden Settings Tbl") Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1426 Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher Cc: Igor Kravchenko Cc: Aric Cyr Cc: Aurabindo Pillai Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e02f765fa784b7bf121451b8e2af2a69676a7710 Author: Kenneth Feng Date: Thu Mar 11 12:19:57 2021 +0800 drm/amd/pm: workaround for audio noise issue commit 9d03730ecbc5afabfda26d4dbb014310bc4ea4d9 upstream. On some Intel platforms, audio noise can be detected due to high pcie speed switch latency. This patch leaverages ppfeaturemask to fix to the highest pcie speed then disable pcie switching. v2: coding style fix Signed-off-by: Kenneth Feng Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit f771b2b3eb2f4c4a2a2456f59b43de3942709c43 Author: Daniel Vetter Date: Mon Mar 1 10:52:53 2021 +0100 drm/etnaviv: Use FOLL_FORCE for userptr commit cd5297b0855f17c8b4e3ef1d20c6a3656209c7b3 upstream. Nothing checks userptr.ro except this call to pup_fast, which means there's nothing actually preventing userspace from writing to this. Which means you can just read-only mmap any file you want, userptr it and then write to it with the gpu. Not good. The right way to handle this is FOLL_WRITE | FOLL_FORCE, which will break any COW mappings and update tracking for MAY_WRITE mappings so there's no exploit and the vm isn't confused about what's going on. For any legit use case there's no difference from what userspace can observe and do. Reviewed-by: Lucas Stach Cc: stable@vger.kernel.org Cc: John Hubbard Signed-off-by: Daniel Vetter Cc: Lucas Stach Cc: Russell King Cc: Christian Gmeiner Cc: etnaviv@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20210301095254.1946084-1-daniel.vetter@ffwll.ch Signed-off-by: Greg Kroah-Hartman commit 546f7fcc451c6c20a0fac23ad5bea1353e08cfbb Author: Mimi Zohar Date: Fri Mar 19 11:17:23 2021 -0400 integrity: double check iint_cache was initialized commit 92063f3ca73aab794bd5408d3361fd5b5ea33079 upstream. The kernel may be built with multiple LSMs, but only a subset may be enabled on the boot command line by specifying "lsm=". Not including "integrity" on the ordered LSM list may result in a NULL deref. As reported by Dmitry Vyukov: in qemu: qemu-system-x86_64 -enable-kvm -machine q35,nvdimm -cpu max,migratable=off -smp 4 -m 4G,slots=4,maxmem=16G -hda wheezy.img -kernel arch/x86/boot/bzImage -nographic -vga std -soundhw all -usb -usbdevice tablet -bt hci -bt device:keyboard -net user,host=10.0.2.10,hostfwd=tcp::10022-:22 -net nic,model=virtio-net-pci -object memory-backend-file,id=pmem1,share=off,mem-path=/dev/zero,size=64M -device nvdimm,id=nvdimm1,memdev=pmem1 -append "console=ttyS0 root=/dev/sda earlyprintk=serial rodata=n oops=panic panic_on_warn=1 panic=86400 lsm=smack numa=fake=2 nopcid dummy_hcd.num=8" -pidfile vm_pid -m 2G -cpu host But it crashes on NULL deref in integrity_inode_get during boot: Run /sbin/init as init process BUG: kernel NULL pointer dereference, address: 000000000000001c PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP KASAN CPU: 3 PID: 1 Comm: swapper/0 Not tainted 5.12.0-rc2+ #97 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-44-g88ab0c15525c-prebuilt.qemu.org 04/01/2014 RIP: 0010:kmem_cache_alloc+0x2b/0x370 mm/slub.c:2920 Code: 57 41 56 41 55 41 54 41 89 f4 55 48 89 fd 53 48 83 ec 10 44 8b 3d d9 1f 90 0b 65 48 8b 04 25 28 00 00 00 48 89 44 24 08 31 c0 <8b> 5f 1c 4cf RSP: 0000:ffffc9000032f9d8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888017fc4f00 RCX: 0000000000000000 RDX: ffff888040220000 RSI: 0000000000000c40 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: ffff888019263627 R10: ffffffff83937cd1 R11: 0000000000000000 R12: 0000000000000c40 R13: ffff888019263538 R14: 0000000000000000 R15: 0000000000ffffff FS: 0000000000000000(0000) GS:ffff88802d180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000001c CR3: 000000000b48e000 CR4: 0000000000750ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: integrity_inode_get+0x47/0x260 security/integrity/iint.c:105 process_measurement+0x33d/0x17e0 security/integrity/ima/ima_main.c:237 ima_bprm_check+0xde/0x210 security/integrity/ima/ima_main.c:474 security_bprm_check+0x7d/0xa0 security/security.c:845 search_binary_handler fs/exec.c:1708 [inline] exec_binprm fs/exec.c:1761 [inline] bprm_execve fs/exec.c:1830 [inline] bprm_execve+0x764/0x19a0 fs/exec.c:1792 kernel_execve+0x370/0x460 fs/exec.c:1973 try_to_run_init_process+0x14/0x4e init/main.c:1366 kernel_init+0x11d/0x1b8 init/main.c:1477 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 Modules linked in: CR2: 000000000000001c ---[ end trace 22d601a500de7d79 ]--- Since LSMs and IMA may be configured at build time, but not enabled at run time, panic the system if "integrity" was not initialized before use. Reported-by: Dmitry Vyukov Fixes: 79f7865d844c ("LSM: Introduce "lsm=" for boottime LSM selection") Cc: stable@vger.kernel.org Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit 5f7b515df003ca05a308b316d7b8b0034ea98094 Author: Claudiu Beznea Date: Wed Apr 11 19:05:03 2018 +0300 ARM: dts: at91-sama5d27_som1: fix phy address to 7 commit 221c3a09ddf70a0a51715e6c2878d8305e95c558 upstream. Fix the phy address to 7 for Ethernet PHY on SAMA5D27 SOM1. No connection established if phy address 0 is used. The board uses the 24 pins version of the KSZ8081RNA part, KSZ8081RNA pin 16 REFCLK as PHYAD bit [2] has weak internal pull-down. But at reset, connected to PD09 of the MPU it's connected with an internal pull-up forming PHYAD[2:0] = 7. Signed-off-by: Claudiu Beznea Fixes: 2f61929eb10a ("ARM: dts: at91: at91-sama5d27_som1: fix PHY ID") Cc: Ludovic Desroches Signed-off-by: Nicolas Ferre Cc: # 4.14+ Signed-off-by: Greg Kroah-Hartman commit 2a0d35962ff114cc92f29d01d4a10f06fcdaeaec Author: Nicolas Ferre Date: Wed Mar 10 16:20:06 2021 +0100 ARM: dts: at91: sam9x60: fix mux-mask to match product's datasheet commit 2c69c8a1736eace8de491d480e6e577a27c2087c upstream. Fix the whole mux-mask table according to datasheet for the sam9x60 product. Too much functions for pins were disabled leading to misunderstandings when enabling more peripherals or taking this table as an example for another board. Take advantage of this fix to move the mux-mask in the SoC file where it belongs and use lower case letters for hex numbers like everywhere in the file. Signed-off-by: Nicolas Ferre Fixes: 1e5f532c2737 ("ARM: dts: at91: sam9x60: add device tree for soc and board") Cc: # 5.6+ Cc: Sandeep Sheriker Mallikarjun Reviewed-by: Tudor Ambarus Link: https://lore.kernel.org/r/20210310152006.15018-1-nicolas.ferre@microchip.com Signed-off-by: Greg Kroah-Hartman commit 0b6cd8802d320a0574a998f3631e4211fe717f8f Author: Federico Pellegrin Date: Sun Feb 7 06:00:22 2021 +0100 ARM: dts: at91: sam9x60: fix mux-mask for PA7 so it can be set to A, B and C commit 664979bba8169d775959452def968d1a7c03901f upstream. According to the datasheet PA7 can be set to either function A, B or C (see table 6-2 of DS60001579D). The previous value would permit just configuring with function C. Signed-off-by: Federico Pellegrin Fixes: 1e5f532c2737 ("ARM: dts: at91: sam9x60: add device tree for soc and board") Cc: # 5.6+ Cc: Sandeep Sheriker Mallikarjun Signed-off-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman commit 1c103f51225122fece466986f0a28dd6fd9b88ae Author: Horia Geantă Date: Sun Mar 7 22:47:36 2021 +0200 arm64: dts: ls1043a: mark crypto engine dma coherent commit 4fb3a074755b7737c4081cffe0ccfa08c2f2d29d upstream. Crypto engine (CAAM) on LS1043A platform is configured HW-coherent, mark accordingly the DT node. Lack of "dma-coherent" property for an IP that is configured HW-coherent can lead to problems, similar to what has been reported for LS1046A. Cc: # v4.8+ Fixes: 63dac35b58f4 ("arm64: dts: ls1043a: add crypto node") Link: https://lore.kernel.org/linux-crypto/fe6faa24-d8f7-d18f-adfa-44fa0caa1598@arm.com Signed-off-by: Horia Geantă Acked-by: Li Yang Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 4f35b64ba8233c73b81dab3896f3067ea3a9f131 Author: Horia Geantă Date: Sun Mar 7 22:47:37 2021 +0200 arm64: dts: ls1012a: mark crypto engine dma coherent commit ba8da03fa7dff59d9400250aebd38f94cde3cb0f upstream. Crypto engine (CAAM) on LS1012A platform is configured HW-coherent, mark accordingly the DT node. Lack of "dma-coherent" property for an IP that is configured HW-coherent can lead to problems, similar to what has been reported for LS1046A. Cc: # v4.12+ Fixes: 85b85c569507 ("arm64: dts: ls1012a: add crypto node") Signed-off-by: Horia Geantă Acked-by: Li Yang Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 3883f335b5eee8a079df0b9ead515329e9680b6f Author: Horia Geantă Date: Sun Mar 7 22:47:35 2021 +0200 arm64: dts: ls1046a: mark crypto engine dma coherent commit 9c3a16f88385e671b63a0de7b82b85e604a80f42 upstream. Crypto engine (CAAM) on LS1046A platform is configured HW-coherent, mark accordingly the DT node. As reported by Greg and Sascha, and explained by Robin, lack of "dma-coherent" property for an IP that is configured HW-coherent can lead to problems, e.g. on v5.11: > kernel BUG at drivers/crypto/caam/jr.c:247! > Internal error: Oops - BUG: 0 [#1] PREEMPT SMP > Modules linked in: > CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.11.0-20210225-3-00039-g434215968816-dirty #12 > Hardware name: TQ TQMLS1046A SoM on Arkona AT1130 (C300) board (DT) > pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--) > pc : caam_jr_dequeue+0x98/0x57c > lr : caam_jr_dequeue+0x98/0x57c > sp : ffff800010003d50 > x29: ffff800010003d50 x28: ffff8000118d4000 > x27: ffff8000118d4328 x26: 00000000000001f0 > x25: ffff0008022be480 x24: ffff0008022c6410 > x23: 00000000000001f1 x22: ffff8000118d4329 > x21: 0000000000004d80 x20: 00000000000001f1 > x19: 0000000000000001 x18: 0000000000000020 > x17: 0000000000000000 x16: 0000000000000015 > x15: ffff800011690230 x14: 2e2e2e2e2e2e2e2e > x13: 2e2e2e2e2e2e2020 x12: 3030303030303030 > x11: ffff800011700a38 x10: 00000000fffff000 > x9 : ffff8000100ada30 x8 : ffff8000116a8a38 > x7 : 0000000000000001 x6 : 0000000000000000 > x5 : 0000000000000000 x4 : 0000000000000000 > x3 : 00000000ffffffff x2 : 0000000000000000 > x1 : 0000000000000000 x0 : 0000000000001800 > Call trace: > caam_jr_dequeue+0x98/0x57c > tasklet_action_common.constprop.0+0x164/0x18c > tasklet_action+0x44/0x54 > __do_softirq+0x160/0x454 > __irq_exit_rcu+0x164/0x16c > irq_exit+0x1c/0x30 > __handle_domain_irq+0xc0/0x13c > gic_handle_irq+0x5c/0xf0 > el1_irq+0xb4/0x180 > arch_cpu_idle+0x18/0x30 > default_idle_call+0x3c/0x1c0 > do_idle+0x23c/0x274 > cpu_startup_entry+0x34/0x70 > rest_init+0xdc/0xec > arch_call_rest_init+0x1c/0x28 > start_kernel+0x4ac/0x4e4 > Code: 91392021 912c2000 d377d8c6 97f24d96 (d4210000) Cc: # v4.10+ Fixes: 8126d88162a5 ("arm64: dts: add QorIQ LS1046A SoC support") Link: https://lore.kernel.org/linux-crypto/fe6faa24-d8f7-d18f-adfa-44fa0caa1598@arm.com Reported-by: Greg Ungerer Reported-by: Sascha Hauer Tested-by: Sascha Hauer Signed-off-by: Horia Geantă Acked-by: Greg Ungerer Acked-by: Li Yang Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 1ced45535d4bb8df3d84e41534dbe67c58c01955 Author: Mark Rutland Date: Fri Mar 19 18:41:06 2021 +0000 arm64: stacktrace: don't trace arch_stack_walk() commit c607ab4f916d4d5259072eca34055d3f5a795c21 upstream. We recently converted arm64 to use arch_stack_walk() in commit: 5fc57df2f6fd ("arm64: stacktrace: Convert to ARCH_STACKWALK") The core stacktrace code expects that (when tracing the current task) arch_stack_walk() starts a trace at its caller, and does not include itself in the trace. However, arm64's arch_stack_walk() includes itself, and so traces include one more entry than callers expect. The core stacktrace code which calls arch_stack_walk() tries to skip a number of entries to prevent itself appearing in a trace, and the additional entry prevents skipping one of the core stacktrace functions, leaving this in the trace unexpectedly. We can fix this by having arm64's arch_stack_walk() begin the trace with its caller. The first value returned by the trace will be __builtin_return_address(0), i.e. the caller of arch_stack_walk(). The first frame record to be unwound will be __builtin_frame_address(1), i.e. the caller's frame record. To prevent surprises, arch_stack_walk() is also marked noinline. While __builtin_frame_address(1) is not safe in portable code, local GCC developers have confirmed that it is safe on arm64. To find the caller's frame record, the builtin can safely dereference the current function's frame record or (in theory) could stash the original FP into another GPR at function entry time, neither of which are problematic. Prior to this patch, the tracing code would unexpectedly show up in traces of the current task, e.g. | # cat /proc/self/stack | [<0>] stack_trace_save_tsk+0x98/0x100 | [<0>] proc_pid_stack+0xb4/0x130 | [<0>] proc_single_show+0x60/0x110 | [<0>] seq_read_iter+0x230/0x4d0 | [<0>] seq_read+0xdc/0x130 | [<0>] vfs_read+0xac/0x1e0 | [<0>] ksys_read+0x6c/0xfc | [<0>] __arm64_sys_read+0x20/0x30 | [<0>] el0_svc_common.constprop.0+0x60/0x120 | [<0>] do_el0_svc+0x24/0x90 | [<0>] el0_svc+0x2c/0x54 | [<0>] el0_sync_handler+0x1a4/0x1b0 | [<0>] el0_sync+0x170/0x180 After this patch, the tracing code will not show up in such traces: | # cat /proc/self/stack | [<0>] proc_pid_stack+0xb4/0x130 | [<0>] proc_single_show+0x60/0x110 | [<0>] seq_read_iter+0x230/0x4d0 | [<0>] seq_read+0xdc/0x130 | [<0>] vfs_read+0xac/0x1e0 | [<0>] ksys_read+0x6c/0xfc | [<0>] __arm64_sys_read+0x20/0x30 | [<0>] el0_svc_common.constprop.0+0x60/0x120 | [<0>] do_el0_svc+0x24/0x90 | [<0>] el0_svc+0x2c/0x54 | [<0>] el0_sync_handler+0x1a4/0x1b0 | [<0>] el0_sync+0x170/0x180 Erring on the side of caution, I've given this a spin with a bunch of toolchains, verifying the output of /proc/self/stack and checking that the assembly looked sound. For GCC (where we require version 5.1.0 or later) I tested with the kernel.org crosstool binares for versions 5.5.0, 6.4.0, 6.5.0, 7.3.0, 7.5.0, 8.1.0, 8.3.0, 8.4.0, 9.2.0, and 10.1.0. For clang (where we require version 10.0.1 or later) I tested with the llvm.org binary releases of 11.0.0, and 11.0.1. Fixes: 5fc57df2f6fd ("arm64: stacktrace: Convert to ARCH_STACKWALK") Signed-off-by: Mark Rutland Cc: Catalin Marinas Cc: Chen Jun Cc: Marco Elver Cc: Mark Brown Cc: Will Deacon Cc: # 5.10.x Reviewed-by: Catalin Marinas Reviewed-by: Mark Brown Link: https://lore.kernel.org/r/20210319184106.5688-1-mark.rutland@arm.com Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 53d3c8063590968f415d67e2708f679edfab6d6c Author: Vegard Nossum Date: Tue Mar 23 14:20:33 2021 -0700 ACPICA: Always create namespace nodes using acpi_ns_create_node() commit 25928deeb1e4e2cdae1dccff349320c6841eb5f8 upstream. ACPICA commit 29da9a2a3f5b2c60420893e5c6309a0586d7a329 ACPI is allocating an object using kmalloc(), but then frees it using kmem_cache_free(<"Acpi-Namespace" kmem_cache>). This is wrong and can lead to boot failures manifesting like this: hpet0: 3 comparators, 64-bit 100.000000 MHz counter clocksource: Switched to clocksource tsc-early BUG: unable to handle page fault for address: 000000003ffe0018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.6.0+ #211 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 RIP: 0010:kmem_cache_alloc+0x70/0x1d0 Code: 00 00 4c 8b 45 00 65 49 8b 50 08 65 4c 03 05 6f cc e7 7e 4d 8b 20 4d 85 e4 0f 84 3d 01 00 00 8b 45 20 48 8b 7d 00 48 8d 4a 01 <49> 8b 1c 04 4c 89 e0 65 48 0f c7 0f 0f 94 c0 84 c0 74 c5 8b 45 20 RSP: 0000:ffffc90000013df8 EFLAGS: 00010206 RAX: 0000000000000018 RBX: ffffffff81c49200 RCX: 0000000000000002 RDX: 0000000000000001 RSI: 0000000000000dc0 RDI: 000000000002b300 RBP: ffff88803e403d00 R08: ffff88803ec2b300 R09: 0000000000000001 R10: 0000000000000dc0 R11: 0000000000000006 R12: 000000003ffe0000 R13: ffffffff8110a583 R14: 0000000000000dc0 R15: ffffffff81c49a80 FS: 0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000003ffe0018 CR3: 0000000001c0a001 CR4: 00000000003606f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __trace_define_field+0x33/0xa0 event_trace_init+0xeb/0x2b4 tracer_init_tracefs+0x60/0x195 ? register_tracer+0x1e7/0x1e7 do_one_initcall+0x74/0x160 kernel_init_freeable+0x190/0x1f0 ? rest_init+0x9a/0x9a kernel_init+0x5/0xf6 ret_from_fork+0x35/0x40 CR2: 000000003ffe0018 ---[ end trace 707efa023f2ee960 ]--- RIP: 0010:kmem_cache_alloc+0x70/0x1d0 Bisection leads to unrelated changes in slab; Vlastimil Babka suggests an unrelated layout or slab merge change merely exposed the underlying bug. Link: https://lore.kernel.org/lkml/4dc93ff8-f86e-f4c9-ebeb-6d3153a78d03@oracle.com/ Link: https://lore.kernel.org/r/a1461e21-c744-767d-6dfc-6641fd3e3ce2@siemens.com Link: https://github.com/acpica/acpica/commit/29da9a2a Fixes: f79c8e4136ea ("ACPICA: Namespace: simplify creation of the initial/default namespace") Reported-by: Jan Kiszka Diagnosed-by: Vlastimil Babka Diagnosed-by: Kees Cook Signed-off-by: Vegard Nossum Signed-off-by: Bob Moore Signed-off-by: Erik Kaneda Cc: 5.10+ # 5.10+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 36fe73bd0af9c065233235df016a665d2dc1eed8 Author: Chris Chiu Date: Fri Mar 12 11:24:30 2021 +0800 ACPI: video: Add missing callback back for Sony VPCEH3U1E commit c1d1e25a8c542816ae8dee41b81a18d30c7519a0 upstream. The .callback of the quirk for Sony VPCEH3U1E was unintetionally removed by the commit 25417185e9b5 ("ACPI: video: Add DMI quirk for GIGABYTE GB-BXBT-2807"). Add it back to make sure the quirk for Sony VPCEH3U1E works as expected. Fixes: 25417185e9b5 ("ACPI: video: Add DMI quirk for GIGABYTE GB-BXBT-2807") Signed-off-by: Chris Chiu Reported-by: Pavel Machek Reviewed-by: Pavel Machek (CIP) Cc: 5.11+ # 5.11+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 1f5c9efad9fef7286c78aeac902f19d06754029c Author: Nick Desaulniers Date: Wed Mar 24 21:37:44 2021 -0700 gcov: fix clang-11+ support commit 60bcf728ee7c60ac2a1f9a0eaceb3a7b3954cd2b upstream. LLVM changed the expected function signatures for llvm_gcda_start_file() and llvm_gcda_emit_function() in the clang-11 release. Users of clang-11 or newer may have noticed their kernels failing to boot due to a panic when enabling CONFIG_GCOV_KERNEL=y +CONFIG_GCOV_PROFILE_ALL=y. Fix up the function signatures so calling these functions doesn't panic the kernel. Link: https://reviews.llvm.org/rGcdd683b516d147925212724b09ec6fb792a40041 Link: https://reviews.llvm.org/rG13a633b438b6500ecad9e4f936ebadf3411d0f44 Link: https://lkml.kernel.org/r/20210312224132.3413602-2-ndesaulniers@google.com Signed-off-by: Nick Desaulniers Reported-by: Prasad Sodagudi Suggested-by: Nathan Chancellor Reviewed-by: Fangrui Song Tested-by: Nathan Chancellor Acked-by: Peter Oberparleiter Reviewed-by: Nathan Chancellor Cc: [5.4+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6e63cc1fe2532d1aa851a540677e29ba802bf071 Author: Andrey Konovalov Date: Wed Mar 24 21:37:20 2021 -0700 kasan: fix per-page tags for non-page_alloc pages commit cf10bd4c4aff8dd64d1aa7f2a529d0c672bc16af upstream. To allow performing tag checks on page_alloc addresses obtained via page_address(), tag-based KASAN modes store tags for page_alloc allocations in page->flags. Currently, the default tag value stored in page->flags is 0x00. Therefore, page_address() returns a 0x00ffff... address for pages that were not allocated via page_alloc. This might cause problems. A particular case we encountered is a conflict with KFENCE. If a KFENCE-allocated slab object is being freed via kfree(page_address(page) + offset), the address passed to kfree() will get tagged with 0x00 (as slab pages keep the default per-page tags). This leads to is_kfence_address() check failing, and a KFENCE object ending up in normal slab freelist, which causes memory corruptions. This patch changes the way KASAN stores tag in page-flags: they are now stored xor'ed with 0xff. This way, KASAN doesn't need to initialize per-page flags for every created page, which might be slow. With this change, page_address() returns natively-tagged (with 0xff) pointers for pages that didn't have tags set explicitly. This patch fixes the encountered conflict with KFENCE and prevents more similar issues that can occur in the future. Link: https://lkml.kernel.org/r/1a41abb11c51b264511d9e71c303bb16d5cb367b.1615475452.git.andreyknvl@google.com Fixes: 2813b9c02962 ("kasan, mm, arm64: tag non slab memory allocated via pagealloc") Signed-off-by: Andrey Konovalov Reviewed-by: Marco Elver Cc: Catalin Marinas Cc: Will Deacon Cc: Vincenzo Frascino Cc: Dmitry Vyukov Cc: Andrey Ryabinin Cc: Alexander Potapenko Cc: Peter Collingbourne Cc: Evgenii Stepanov Cc: Branislav Rankov Cc: Kevin Brodsky Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit fe03ccc3ce906a31005637263fb82dd84d5d1dac Author: Miaohe Lin Date: Wed Mar 24 21:37:17 2021 -0700 hugetlb_cgroup: fix imbalanced css_get and css_put pair for shared mappings commit d85aecf2844ff02a0e5f077252b2461d4f10c9f0 upstream. The current implementation of hugetlb_cgroup for shared mappings could have different behavior. Consider the following two scenarios: 1.Assume initial css reference count of hugetlb_cgroup is 1: 1.1 Call hugetlb_reserve_pages with from = 1, to = 2. So css reference count is 2 associated with 1 file_region. 1.2 Call hugetlb_reserve_pages with from = 2, to = 3. So css reference count is 3 associated with 2 file_region. 1.3 coalesce_file_region will coalesce these two file_regions into one. So css reference count is 3 associated with 1 file_region now. 2.Assume initial css reference count of hugetlb_cgroup is 1 again: 2.1 Call hugetlb_reserve_pages with from = 1, to = 3. So css reference count is 2 associated with 1 file_region. Therefore, we might have one file_region while holding one or more css reference counts. This inconsistency could lead to imbalanced css_get() and css_put() pair. If we do css_put one by one (i.g. hole punch case), scenario 2 would put one more css reference. If we do css_put all together (i.g. truncate case), scenario 1 will leak one css reference. The imbalanced css_get() and css_put() pair would result in a non-zero reference when we try to destroy the hugetlb cgroup. The hugetlb cgroup directory is removed __but__ associated resource is not freed. This might result in OOM or can not create a new hugetlb cgroup in a busy workload ultimately. In order to fix this, we have to make sure that one file_region must hold exactly one css reference. So in coalesce_file_region case, we should release one css reference before coalescence. Also only put css reference when the entire file_region is removed. The last thing to note is that the caller of region_add() will only hold one reference to h_cg->css for the whole contiguous reservation region. But this area might be scattered when there are already some file_regions reside in it. As a result, many file_regions may share only one h_cg->css reference. In order to ensure that one file_region must hold exactly one css reference, we should do css_get() for each file_region and release the reference held by caller when they are done. [linmiaohe@huawei.com: fix imbalanced css_get and css_put pair for shared mappings] Link: https://lkml.kernel.org/r/20210316023002.53921-1-linmiaohe@huawei.com Link: https://lkml.kernel.org/r/20210301120540.37076-1-linmiaohe@huawei.com Fixes: 075a61d07a8e ("hugetlb_cgroup: add accounting for shared mappings") Reported-by: kernel test robot (auto build test ERROR) Signed-off-by: Miaohe Lin Reviewed-by: Mike Kravetz Cc: Aneesh Kumar K.V Cc: Wanpeng Li Cc: Mina Almasry Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 269042e8ffed672e29999789debed357efda72af Author: Phillip Lougher Date: Wed Mar 24 21:37:35 2021 -0700 squashfs: fix xattr id and id lookup sanity checks commit 8b44ca2b634527151af07447a8090a5f3a043321 upstream. The checks for maximum metadata block size is missing SQUASHFS_BLOCK_OFFSET (the two byte length count). Link: https://lkml.kernel.org/r/2069685113.2081245.1614583677427@webmail.123-reg.co.uk Fixes: f37aa4c7366e23f ("squashfs: add more sanity checks in id lookup") Signed-off-by: Phillip Lougher Cc: Sean Nyekjaer Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 61d72c5952c4ce52039105b6c6bcd884de7a98a1 Author: Sean Nyekjaer Date: Wed Mar 24 21:37:32 2021 -0700 squashfs: fix inode lookup sanity checks commit c1b2028315c6b15e8d6725e0d5884b15887d3daa upstream. When mouting a squashfs image created without inode compression it fails with: "unable to read inode lookup table" It turns out that the BLOCK_OFFSET is missing when checking the SQUASHFS_METADATA_SIZE agaist the actual size. Link: https://lkml.kernel.org/r/20210226092903.1473545-1-sean@geanix.com Fixes: eabac19e40c0 ("squashfs: add more sanity checks in inode lookup") Signed-off-by: Sean Nyekjaer Acked-by: Phillip Lougher Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 1d215fcbc4ef305614871bbb2399f7b4670cb266 Author: Thomas Hebb Date: Wed Mar 24 21:37:29 2021 -0700 z3fold: prevent reclaim/free race for headless pages commit 6d679578fe9c762c8fbc3d796a067cbba84a7884 upstream. Commit ca0246bb97c2 ("z3fold: fix possible reclaim races") introduced the PAGE_CLAIMED flag "to avoid racing on a z3fold 'headless' page release." By atomically testing and setting the bit in each of z3fold_free() and z3fold_reclaim_page(), a double-free was avoided. However, commit dcf5aedb24f8 ("z3fold: stricter locking and more careful reclaim") appears to have unintentionally broken this behavior by moving the PAGE_CLAIMED check in z3fold_reclaim_page() to after the page lock gets taken, which only happens for non-headless pages. For headless pages, the check is now skipped entirely and races can occur again. I have observed such a race on my system: page:00000000ffbd76b7 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x165316 flags: 0x2ffff0000000000() raw: 02ffff0000000000 ffffea0004535f48 ffff8881d553a170 0000000000000000 raw: 0000000000000000 0000000000000011 00000000ffffffff 0000000000000000 page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0) ------------[ cut here ]------------ kernel BUG at include/linux/mm.h:707! invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 2 PID: 291928 Comm: kworker/2:0 Tainted: G B 5.10.7-arch1-1-kasan #1 Hardware name: Gigabyte Technology Co., Ltd. H97N-WIFI/H97N-WIFI, BIOS F9b 03/03/2016 Workqueue: zswap-shrink shrink_worker RIP: 0010:__free_pages+0x10a/0x130 Code: c1 e7 06 48 01 ef 45 85 e4 74 d1 44 89 e6 31 d2 41 83 ec 01 e8 e7 b0 ff ff eb da 48 c7 c6 e0 32 91 88 48 89 ef e8 a6 89 f8 ff <0f> 0b 4c 89 e7 e8 fc 79 07 00 e9 33 ff ff ff 48 89 ef e8 ff 79 07 RSP: 0000:ffff88819a2ffb98 EFLAGS: 00010296 RAX: 0000000000000000 RBX: ffffea000594c5a8 RCX: 0000000000000000 RDX: 1ffffd4000b298b7 RSI: 0000000000000000 RDI: ffffea000594c5b8 RBP: ffffea000594c580 R08: 000000000000003e R09: ffff8881d5520bbb R10: ffffed103aaa4177 R11: 0000000000000001 R12: ffffea000594c5b4 R13: 0000000000000000 R14: ffff888165316000 R15: ffffea000594c588 FS: 0000000000000000(0000) GS:ffff8881d5500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7c8c3654d8 CR3: 0000000103f42004 CR4: 00000000001706e0 Call Trace: z3fold_zpool_shrink+0x9b6/0x1240 shrink_worker+0x35/0x90 process_one_work+0x70c/0x1210 worker_thread+0x539/0x1200 kthread+0x330/0x400 ret_from_fork+0x22/0x30 Modules linked in: rfcomm ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ccm algif_aead des_generic libdes ecb algif_skcipher cmac bnep md4 algif_hash af_alg vfat fat intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel iwlmvm hid_logitech_hidpp kvm at24 mac80211 snd_hda_codec_realtek iTCO_wdt snd_hda_codec_generic intel_pmc_bxt snd_hda_codec_hdmi ledtrig_audio iTCO_vendor_support mei_wdt mei_hdcp snd_hda_intel snd_intel_dspcfg libarc4 soundwire_intel irqbypass iwlwifi soundwire_generic_allocation rapl soundwire_cadence intel_cstate snd_hda_codec intel_uncore btusb joydev mousedev snd_usb_audio pcspkr btrtl uvcvideo nouveau btbcm i2c_i801 btintel snd_hda_core videobuf2_vmalloc i2c_smbus snd_usbmidi_lib videobuf2_memops bluetooth snd_hwdep soundwire_bus snd_soc_rt5640 videobuf2_v4l2 cfg80211 snd_soc_rl6231 videobuf2_common snd_rawmidi lpc_ich alx videodev mdio snd_seq_device snd_soc_core mc ecdh_generic mxm_wmi mei_me hid_logitech_dj wmi snd_compress e1000e ac97_bus mei ttm rfkill snd_pcm_dmaengine ecc snd_pcm snd_timer snd soundcore mac_hid acpi_pad pkcs8_key_parser it87 hwmon_vid crypto_user fuse ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 dm_crypt cbc encrypted_keys trusted tpm rng_core usbhid dm_mod crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel crypto_simd cryptd glue_helper xhci_pci xhci_pci_renesas i915 video intel_gtt i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm agpgart ---[ end trace 126d646fc3dc0ad8 ]--- To fix the issue, re-add the earlier test and set in the case where we have a headless page. Link: https://lkml.kernel.org/r/c8106dbe6d8390b290cd1d7f873a2942e805349e.1615452048.git.tommyhebb@gmail.com Fixes: dcf5aedb24f8 ("z3fold: stricter locking and more careful reclaim") Signed-off-by: Thomas Hebb Reviewed-by: Vitaly Wool Cc: Jongseok Kim Cc: Snild Dolkow Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e4642090734e63017f02e14dfbdd41164b9e4783 Author: Ido Schimmel Date: Wed Mar 24 21:43:32 2021 +0200 psample: Fix user API breakage commit e43accba9b071dcd106b5e7643b1b106a158cbb1 upstream. Cited commit added a new attribute before the existing group reference count attribute, thereby changing its value and breaking existing applications on new kernels. Before: # psample -l libpsample ERROR psample_group_foreach: failed to recv message: Operation not supported After: # psample -l Group Num Refcount Group Seq 1 1 0 Fix by restoring the value of the old attribute and remove the misleading comments from the enumerator to avoid future bugs. Cc: stable@vger.kernel.org Fixes: d8bed686ab96 ("net: psample: Add tunnel support") Signed-off-by: Ido Schimmel Reported-by: Adiel Bidani Reviewed-by: Jiri Pirko Reviewed-by: Petr Machata Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a4be7e4ed5d9badf733470799bd6835cc9bf6cc6 Author: Hans de Goede Date: Sun Mar 21 17:35:13 2021 +0100 platform/x86: intel-vbtn: Stop reporting SW_DOCK events commit 538d2dd0b9920334e6596977a664e9e7bac73703 upstream. Stop reporting SW_DOCK events because this breaks suspend-on-lid-close. SW_DOCK should only be reported for docking stations, but all the DSDTs in my DSDT collection which use the intel-vbtn code, always seem to use this for 2-in-1s / convertibles and set SW_DOCK=1 when in laptop-mode (in tandem with setting SW_TABLET_MODE=0). This causes userspace to think the laptop is docked to a port-replicator and to disable suspend-on-lid-close, which is undesirable. Map the dock events to KEY_IGNORE to avoid this broken SW_DOCK reporting. Note this may theoretically cause us to stop reporting SW_DOCK on some device where the 0xCA and 0xCB intel-vbtn events are actually used for reporting docking to a classic docking-station / port-replicator but I'm not aware of any such devices. Also the most important thing is that we only report SW_DOCK when it reliably reports being docked to a classic docking-station without any false positives, which clearly is not the case here. If there is a chance of reporting false positives then it is better to not report SW_DOCK at all. Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210321163513.72328-1-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman commit 4f67d3e8c0ac6e857f01ce59567eecd6f0f79c46 Author: Mian Yousaf Kaukab Date: Thu Mar 18 09:50:26 2021 +0100 netsec: restore phy power state after controller reset commit 804741ac7b9f2fdebe3740cb0579cb8d94d49e60 upstream. Since commit 8e850f25b581 ("net: socionext: Stop PHY before resetting netsec") netsec_netdev_init() power downs phy before resetting the controller. However, the state is not restored once the reset is complete. As a result it is not possible to bring up network on a platform with Broadcom BCM5482 phy. Fix the issue by restoring phy power state after controller reset is complete. Fixes: 8e850f25b581 ("net: socionext: Stop PHY before resetting netsec") Cc: stable@vger.kernel.org Signed-off-by: Mian Yousaf Kaukab Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 19c9967e495ec182efa0f1d4689e338f7db00e3c Author: Ondrej Mosnacek Date: Thu Mar 18 22:53:02 2021 +0100 selinux: fix variable scope issue in live sidtab conversion commit 6406887a12ee5dcdaffff1a8508d91113d545559 upstream. Commit 02a52c5c8c3b ("selinux: move policy commit after updating selinuxfs") moved the selinux_policy_commit() call out of security_load_policy() into sel_write_load(), which caused a subtle yet rather serious bug. The problem is that security_load_policy() passes a reference to the convert_params local variable to sidtab_convert(), which stores it in the sidtab, where it may be accessed until the policy is swapped over and RCU synchronized. Before 02a52c5c8c3b, selinux_policy_commit() was called directly from security_load_policy(), so the convert_params pointer remained valid all the way until the old sidtab was destroyed, but now that's no longer the case and calls to sidtab_context_to_sid() on the old sidtab after security_load_policy() returns may cause invalid memory accesses. This can be easily triggered using the stress test from commit ee1a84fdfeed ("selinux: overhaul sidtab to fix bug and improve performance"): ``` function rand_cat() { echo $(( $RANDOM % 1024 )) } function do_work() { while true; do echo -n "system_u:system_r:kernel_t:s0:c$(rand_cat),c$(rand_cat)" \ >/sys/fs/selinux/context 2>/dev/null || true done } do_work >/dev/null & do_work >/dev/null & do_work >/dev/null & while load_policy; do echo -n .; sleep 0.1; done kill %1 kill %2 kill %3 ``` Fix this by allocating the temporary sidtab convert structures dynamically and passing them among the selinux_policy_{load,cancel,commit} functions. Fixes: 02a52c5c8c3b ("selinux: move policy commit after updating selinuxfs") Cc: stable@vger.kernel.org Tested-by: Tyler Hicks Reviewed-by: Tyler Hicks Signed-off-by: Ondrej Mosnacek [PM: merge fuzz in security.h and services.c] Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 9731e08a338194db0d3b3212ed42ad2f06cedcc8 Author: Ondrej Mosnacek Date: Thu Mar 18 22:53:01 2021 +0100 selinux: don't log MAC_POLICY_LOAD record on failed policy load commit 519dad3bcd809dc1523bf80ab0310ddb3bf00ade upstream. If sel_make_policy_nodes() fails, we should jump to 'out', not 'out1', as the latter would incorrectly log an MAC_POLICY_LOAD audit record, even though the policy hasn't actually been reloaded. The 'out1' jump label now becomes unused and can be removed. Fixes: 02a52c5c8c3b ("selinux: move policy commit after updating selinuxfs") Cc: stable@vger.kernel.org Signed-off-by: Ondrej Mosnacek Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 3b87d0c5834b39295a7d152bab2f59250b29bca8 Author: Filipe Manana Date: Thu Mar 18 11:22:05 2021 +0000 btrfs: fix sleep while in non-sleep context during qgroup removal commit 0bb788300990d3eb5582d3301a720f846c78925c upstream. While removing a qgroup's sysfs entry we end up taking the kernfs_mutex, through kobject_del(), while holding the fs_info->qgroup_lock spinlock, producing the following trace: [821.843637] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:281 [821.843641] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 28214, name: podman [821.843644] CPU: 3 PID: 28214 Comm: podman Tainted: G W 5.11.6 #15 [821.843646] Hardware name: Dell Inc. PowerEdge R330/084XW4, BIOS 2.11.0 12/08/2020 [821.843647] Call Trace: [821.843650] dump_stack+0xa1/0xfb [821.843656] ___might_sleep+0x144/0x160 [821.843659] mutex_lock+0x17/0x40 [821.843662] kernfs_remove_by_name_ns+0x1f/0x80 [821.843666] sysfs_remove_group+0x7d/0xe0 [821.843668] sysfs_remove_groups+0x28/0x40 [821.843670] kobject_del+0x2a/0x80 [821.843672] btrfs_sysfs_del_one_qgroup+0x2b/0x40 [btrfs] [821.843685] __del_qgroup_rb+0x12/0x150 [btrfs] [821.843696] btrfs_remove_qgroup+0x288/0x2a0 [btrfs] [821.843707] btrfs_ioctl+0x3129/0x36a0 [btrfs] [821.843717] ? __mod_lruvec_page_state+0x5e/0xb0 [821.843719] ? page_add_new_anon_rmap+0xbc/0x150 [821.843723] ? kfree+0x1b4/0x300 [821.843725] ? mntput_no_expire+0x55/0x330 [821.843728] __x64_sys_ioctl+0x5a/0xa0 [821.843731] do_syscall_64+0x33/0x70 [821.843733] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [821.843736] RIP: 0033:0x4cd3fb [821.843741] RSP: 002b:000000c000906b20 EFLAGS: 00000206 ORIG_RAX: 0000000000000010 [821.843744] RAX: ffffffffffffffda RBX: 000000c000050000 RCX: 00000000004cd3fb [821.843745] RDX: 000000c000906b98 RSI: 000000004010942a RDI: 000000000000000f [821.843747] RBP: 000000c000907cd0 R08: 000000c000622901 R09: 0000000000000000 [821.843748] R10: 000000c000d992c0 R11: 0000000000000206 R12: 000000000000012d [821.843749] R13: 000000000000012c R14: 0000000000000200 R15: 0000000000000049 Fix this by removing the qgroup sysfs entry while not holding the spinlock, since the spinlock is only meant for protection of the qgroup rbtree. Reported-by: Stuart Shelton Link: https://lore.kernel.org/linux-btrfs/7A5485BB-0628-419D-A4D3-27B1AF47E25A@gmail.com/ Fixes: 49e5fb46211de0 ("btrfs: qgroup: export qgroups in sysfs") CC: stable@vger.kernel.org # 5.10+ Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 771dfb3c531d1ecce209c82161227d66b24d7784 Author: Sean Christopherson Date: Tue Mar 16 11:44:33 2021 -0700 KVM: x86: Protect userspace MSR filter with SRCU, and set atomically-ish [ Upstream commit b318e8decf6b9ef1bcf4ca06fae6d6a2cb5d5c5c ] Fix a plethora of issues with MSR filtering by installing the resulting filter as an atomic bundle instead of updating the live filter one range at a time. The KVM_X86_SET_MSR_FILTER ioctl() isn't truly atomic, as the hardware MSR bitmaps won't be updated until the next VM-Enter, but the relevant software struct is atomically updated, which is what KVM really needs. Similar to the approach used for modifying memslots, make arch.msr_filter a SRCU-protected pointer, do all the work configuring the new filter outside of kvm->lock, and then acquire kvm->lock only when the new filter has been vetted and created. That way vCPU readers either see the old filter or the new filter in their entirety, not some half-baked state. Yuan Yao pointed out a use-after-free in ksm_msr_allowed() due to a TOCTOU bug, but that's just the tip of the iceberg... - Nothing is __rcu annotated, making it nigh impossible to audit the code for correctness. - kvm_add_msr_filter() has an unpaired smp_wmb(). Violation of kernel coding style aside, the lack of a smb_rmb() anywhere casts all code into doubt. - kvm_clear_msr_filter() has a double free TOCTOU bug, as it grabs count before taking the lock. - kvm_clear_msr_filter() also has memory leak due to the same TOCTOU bug. The entire approach of updating the live filter is also flawed. While installing a new filter is inherently racy if vCPUs are running, fixing the above issues also makes it trivial to ensure certain behavior is deterministic, e.g. KVM can provide deterministic behavior for MSRs with identical settings in the old and new filters. An atomic update of the filter also prevents KVM from getting into a half-baked state, e.g. if installing a filter fails, the existing approach would leave the filter in a half-baked state, having already committed whatever bits of the filter were already processed. [*] https://lkml.kernel.org/r/20210312083157.25403-1-yaoyuan0329os@gmail.com Fixes: 1a155254ff93 ("KVM: x86: Introduce MSR filtering") Cc: stable@vger.kernel.org Cc: Alexander Graf Reported-by: Yuan Yao Signed-off-by: Sean Christopherson Message-Id: <20210316184436.2544875-2-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 394e4fd67946dca595f1b63d37ab32f680df6884 Author: Peter Zijlstra Date: Thu Mar 18 11:27:19 2021 +0100 static_call: Fix static_call_set_init() [ Upstream commit 68b1eddd421d2b16c6655eceb48918a1e896bbbc ] It turns out that static_call_set_init() does not preserve the other flags; IOW. it clears TAIL if it was set. Fixes: 9183c3f9ed710 ("static_call: Add inline static call infrastructure") Reported-by: Sumit Garg Signed-off-by: Peter Zijlstra (Intel) Acked-by: Jarkko Sakkinen Tested-by: Sumit Garg Link: https://lkml.kernel.org/r/20210318113610.519406371@infradead.org Signed-off-by: Sasha Levin commit 0fefb5f3e5742cac36bcaea1be06c577e22fb6f7 Author: Peter Zijlstra Date: Thu Feb 25 23:03:51 2021 +0100 static_call: Fix the module key fixup [ Upstream commit 50bf8080a94d171e843fc013abec19d8ab9f50ae ] Provided the target address of a R_X86_64_PC32 relocation is aligned, the low two bits should be invariant between the relative and absolute value. Turns out the address is not aligned and things go sideways, ensure we transfer the bits in the absolute form when fixing up the key address. Fixes: 73f44fe19d35 ("static_call: Allow module use without exposing static_call_key") Reported-by: Steven Rostedt Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Tested-by: Steven Rostedt (VMware) Link: https://lkml.kernel.org/r/20210225220351.GE4746@worktop.programming.kicks-ass.net Signed-off-by: Sasha Levin commit a63068e93917927d443e32609dde9298bcd14833 Author: Josh Poimboeuf Date: Wed Jan 27 17:18:37 2021 -0600 static_call: Allow module use without exposing static_call_key [ Upstream commit 73f44fe19d359635a607e8e8daa0da4001c1cfc2 ] When exporting static_call_key; with EXPORT_STATIC_CALL*(), the module can use static_call_update() to change the function called. This is not desirable in general. Not exporting static_call_key however also disallows usage of static_call(), since objtool needs the key to construct the static_call_site. Solve this by allowing objtool to create the static_call_site using the trampoline address when it builds a module and cannot find the static_call_key symbol. The module loader will then try and map the trampole back to a key before it constructs the normal sites list. Doing this requires a trampoline -> key associsation, so add another magic section that keeps those. Originally-by: Peter Zijlstra (Intel) Signed-off-by: Josh Poimboeuf Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://lkml.kernel.org/r/20210127231837.ifddpn7rhwdaepiu@treble Signed-off-by: Sasha Levin commit 433cd7ca386c832a6e165d76f376c29dcac14fbb Author: Peter Zijlstra Date: Mon Jan 18 15:12:18 2021 +0100 static_call: Pull some static_call declarations to the type headers [ Upstream commit 880cfed3a012d7863f42251791cea7fe78c39390 ] Some static call declarations are going to be needed on low level header files. Move the necessary material to the dedicated static call types header to avoid inclusion dependency hell. Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Frederic Weisbecker Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://lkml.kernel.org/r/20210118141223.123667-4-frederic@kernel.org Signed-off-by: Sasha Levin commit 533c293f737c68045dd628d6dae05255c9fa1993 Author: Sergei Trofimovich Date: Fri Mar 12 21:08:27 2021 -0800 ia64: fix ptrace(PTRACE_SYSCALL_INFO_EXIT) sign [ Upstream commit 61bf318eac2c13356f7bd1c6a05421ef504ccc8a ] In https://bugs.gentoo.org/769614 Dmitry noticed that `ptrace(PTRACE_GET_SYSCALL_INFO)` does not return error sign properly. The bug is in mismatch between get/set errors: static inline long syscall_get_error(struct task_struct *task, struct pt_regs *regs) { return regs->r10 == -1 ? regs->r8:0; } static inline long syscall_get_return_value(struct task_struct *task, struct pt_regs *regs) { return regs->r8; } static inline void syscall_set_return_value(struct task_struct *task, struct pt_regs *regs, int error, long val) { if (error) { /* error < 0, but ia64 uses > 0 return value */ regs->r8 = -error; regs->r10 = -1; } else { regs->r8 = val; regs->r10 = 0; } } Tested on v5.10 on rx3600 machine (ia64 9040 CPU). Link: https://lkml.kernel.org/r/20210221002554.333076-2-slyfox@gentoo.org Link: https://bugs.gentoo.org/769614 Signed-off-by: Sergei Trofimovich Reported-by: Dmitry V. Levin Reviewed-by: Dmitry V. Levin Cc: John Paul Adrian Glaubitz Cc: Oleg Nesterov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit d76e207991c462d7a8b4f8b7f8dcb6f2387abfe9 Author: Sergei Trofimovich Date: Fri Mar 12 21:08:23 2021 -0800 ia64: fix ia64_syscall_get_set_arguments() for break-based syscalls [ Upstream commit 0ceb1ace4a2778e34a5414e5349712ae4dc41d85 ] In https://bugs.gentoo.org/769614 Dmitry noticed that `ptrace(PTRACE_GET_SYSCALL_INFO)` does not work for syscalls called via glibc's syscall() wrapper. ia64 has two ways to call syscalls from userspace: via `break` and via `eps` instructions. The difference is in stack layout: 1. `eps` creates simple stack frame: no locals, in{0..7} == out{0..8} 2. `break` uses userspace stack frame: may be locals (glibc provides one), in{0..7} == out{0..8}. Both work fine in syscall handling cde itself. But `ptrace(PTRACE_GET_SYSCALL_INFO)` uses unwind mechanism to re-extract syscall arguments but it does not account for locals. The change always skips locals registers. It should not change `eps` path as kernel's handler already enforces locals=0 and fixes `break`. Tested on v5.10 on rx3600 machine (ia64 9040 CPU). Link: https://lkml.kernel.org/r/20210221002554.333076-1-slyfox@gentoo.org Link: https://bugs.gentoo.org/769614 Signed-off-by: Sergei Trofimovich Reported-by: Dmitry V. Levin Cc: Oleg Nesterov Cc: John Paul Adrian Glaubitz Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 7077d5e7f07439a45d2b645ba1ed4ca67592a835 Author: Fenghua Yu Date: Fri Mar 12 21:07:15 2021 -0800 mm/fork: clear PASID for new mm [ Upstream commit 82e69a121be4b1597ce758534816a8ee04c8b761 ] When a new mm is created, its PASID should be cleared, i.e. the PASID is initialized to its init state 0 on both ARM and X86. This patch was part of the series introducing mm->pasid, but got lost along the way [1]. It still makes sense to have it, because each address space has a different PASID. And the IOMMU code in iommu_sva_alloc_pasid() expects the pasid field of a new mm struct to be cleared. [1] https://lore.kernel.org/linux-iommu/YDgh53AcQHT+T3L0@otcwcpicx3.sc.intel.com/ Link: https://lkml.kernel.org/r/20210302103837.2562625-1-jean-philippe@linaro.org Signed-off-by: Fenghua Yu Signed-off-by: Jean-Philippe Brucker Reviewed-by: Tony Luck Cc: Jacob Pan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 07feac84efc65c7d0a4ad44096334766bbe68dcb Author: Daniel Wagner Date: Thu Mar 11 16:19:17 2021 +0100 block: Suppress uevent for hidden device when removed [ Upstream commit 9ec491447b90ad6a4056a9656b13f0b3a1e83043 ] register_disk() suppress uevents for devices with the GENHD_FL_HIDDEN but enables uevents at the end again in order to announce disk after possible partitions are created. When the device is removed the uevents are still on and user land sees 'remove' messages for devices which were never 'add'ed to the system. KERNEL[95481.571887] remove /devices/virtual/nvme-fabrics/ctl/nvme5/nvme0c5n1 (block) Let's suppress the uevents for GENHD_FL_HIDDEN by not enabling the uevents at all. Signed-off-by: Daniel Wagner Reviewed-by: Christoph Hellwig Reviewed-by: Martin Wilck Link: https://lore.kernel.org/r/20210311151917.136091-1-dwagner@suse.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 9f704608010b94c84948cf4cbdf79994052341e7 Author: J. Bruce Fields Date: Thu Jan 28 17:36:38 2021 -0500 nfs: we don't support removing system.nfs4_acl [ Upstream commit 4f8be1f53bf615102d103c0509ffa9596f65b718 ] The NFSv4 protocol doesn't have any notion of reomoving an attribute, so removexattr(path,"system.nfs4_acl") doesn't make sense. There's no documented return value. Arguably it could be EOPNOTSUPP but I'm a little worried an application might take that to mean that we don't support ACLs or xattrs. How about EINVAL? Signed-off-by: J. Bruce Fields Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 3dab008e23bdd1807e0a987ebdf6f5dfc673c348 Author: Dmitry Monakhov Date: Wed Mar 10 12:06:41 2021 +0000 nvme-pci: add the DISABLE_WRITE_ZEROES quirk for a Samsung PM1725a [ Upstream commit abbb5f5929ec6c52574c430c5475c158a65c2a8c ] This adds a quirk for Samsung PM1725a drive which fixes timeouts and I/O errors due to the fact that the controller does not properly handle the Write Zeroes command, dmesg log: nvme nvme0: I/O 528 QID 10 timeout, aborting nvme nvme0: I/O 529 QID 10 timeout, aborting nvme nvme0: I/O 530 QID 10 timeout, aborting nvme nvme0: I/O 531 QID 10 timeout, aborting nvme nvme0: I/O 532 QID 10 timeout, aborting nvme nvme0: I/O 533 QID 10 timeout, aborting nvme nvme0: I/O 534 QID 10 timeout, aborting nvme nvme0: I/O 535 QID 10 timeout, aborting nvme nvme0: Abort status: 0x0 nvme nvme0: Abort status: 0x0 nvme nvme0: Abort status: 0x0 nvme nvme0: Abort status: 0x0 nvme nvme0: Abort status: 0x0 nvme nvme0: Abort status: 0x0 nvme nvme0: Abort status: 0x0 nvme nvme0: Abort status: 0x0 nvme nvme0: I/O 528 QID 10 timeout, reset controller nvme nvme0: controller is down; will reset: CSTS=0x3, PCI_STATUS=0x10 nvme nvme0: Device not ready; aborting reset, CSTS=0x3 nvme nvme0: Device not ready; aborting reset, CSTS=0x3 nvme nvme0: Removing after probe failure status: -19 nvme0n1: detected capacity change from 6251233968 to 0 blk_update_request: I/O error, dev nvme0n1, sector 32776 op 0x1:(WRITE) flags 0x3000 phys_seg 6 prio class 0 blk_update_request: I/O error, dev nvme0n1, sector 113319936 op 0x9:(WRITE_ZEROES) flags 0x800 phys_seg 0 prio class 0 Buffer I/O error on dev nvme0n1p2, logical block 1, lost async page write blk_update_request: I/O error, dev nvme0n1, sector 113319680 op 0x9:(WRITE_ZEROES) flags 0x0 phys_seg 0 prio class 0 Buffer I/O error on dev nvme0n1p2, logical block 2, lost async page write blk_update_request: I/O error, dev nvme0n1, sector 113319424 op 0x9:(WRITE_ZEROES) flags 0x0 phys_seg 0 prio class 0 Buffer I/O error on dev nvme0n1p2, logical block 3, lost async page write blk_update_request: I/O error, dev nvme0n1, sector 113319168 op 0x9:(WRITE_ZEROES) flags 0x0 phys_seg 0 prio class 0 Buffer I/O error on dev nvme0n1p2, logical block 4, lost async page write blk_update_request: I/O error, dev nvme0n1, sector 113318912 op 0x9:(WRITE_ZEROES) flags 0x0 phys_seg 0 prio class 0 Buffer I/O error on dev nvme0n1p2, logical block 5, lost async page write blk_update_request: I/O error, dev nvme0n1, sector 113318656 op 0x9:(WRITE_ZEROES) flags 0x0 phys_seg 0 prio class 0 Buffer I/O error on dev nvme0n1p2, logical block 6, lost async page write blk_update_request: I/O error, dev nvme0n1, sector 113318400 op 0x9:(WRITE_ZEROES) flags 0x0 phys_seg 0 prio class 0 blk_update_request: I/O error, dev nvme0n1, sector 113318144 op 0x9:(WRITE_ZEROES) flags 0x0 phys_seg 0 prio class 0 blk_update_request: I/O error, dev nvme0n1, sector 113317888 op 0x9:(WRITE_ZEROES) flags 0x0 phys_seg 0 prio class 0 Signed-off-by: Dmitry Monakhov Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 8f0534c96ac80bb05dfa74897c151f49b37d6663 Author: Lv Yunlong Date: Wed Mar 10 21:44:13 2021 -0800 nvme-rdma: Fix a use after free in nvmet_rdma_write_data_done [ Upstream commit abec6561fc4e0fbb19591a0b35676d8c783b5493 ] In nvmet_rdma_write_data_done, rsp is recoverd by wc->wr_cqe and freed by nvmet_rdma_release_rsp(). But after that, pr_info() used the freed chunk's member object and could leak the freed chunk address with wc->wr_cqe by computing the offset. Signed-off-by: Lv Yunlong Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit c7b3f6db97c2c3969564f270d941d12f6ddbc0eb Author: Chaitanya Kulkarni Date: Mon Mar 8 20:58:21 2021 -0800 nvme-core: check ctrl css before setting up zns [ Upstream commit 0ec84df4953bd42c6583a555773f1d4996a061eb ] Ensure multiple Command Sets are supported before starting to setup a ZNS namespace. Signed-off-by: Chaitanya Kulkarni [hch: move the check around a bit] Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 9083dc773d67d41d562ceb6a99a8c2f5160f90c7 Author: Hannes Reinecke Date: Fri Feb 26 08:17:28 2021 +0100 nvme-fc: return NVME_SC_HOST_ABORTED_CMD when a command has been aborted [ Upstream commit ae3afe6308b43bbf49953101d4ba2c1c481133a8 ] When a command has been aborted we should return NVME_SC_HOST_ABORTED_CMD to be consistent with the other transports. Signed-off-by: Hannes Reinecke Reviewed-by: Sagi Grimberg Reviewed-by: James Smart Reviewed-by: Daniel Wagner Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 4d6aea29a795ff8b52e3669447162a1942f0b49d Author: Hannes Reinecke Date: Fri Feb 26 08:17:27 2021 +0100 nvme-fc: set NVME_REQ_CANCELLED in nvme_fc_terminate_exchange() [ Upstream commit 3c7aafbc8d3d4d90430dfa126847a796c3e4ecfc ] nvme_fc_terminate_exchange() is being called when exchanges are being deleted, and as such we should be setting the NVME_REQ_CANCELLED flag to have identical behaviour on all transports. Signed-off-by: Hannes Reinecke Reviewed-by: Keith Busch Reviewed-by: Sagi Grimberg Reviewed-by: James Smart Reviewed-by: Daniel Wagner Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 7e62a89b51dd927853137eb1b9814b0451535390 Author: Hannes Reinecke Date: Fri Feb 26 08:17:26 2021 +0100 nvme: add NVME_REQ_CANCELLED flag in nvme_cancel_request() [ Upstream commit d3589381987ec879b03f8ce3039df57e87f05901 ] NVME_REQ_CANCELLED is translated into -EINTR in nvme_submit_sync_cmd(), so we should be setting this flags during nvme_cancel_request() to ensure that the callers to nvme_submit_sync_cmd() will get the correct error code when the controller is reset. Signed-off-by: Hannes Reinecke Reviewed-by: Keith Busch Reviewed-by: Sagi Grimberg Reviewed-by: Chao Leng Reviewed-by: Daniel Wagner Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit d8b17df7bf8052dbdb1503e9066899e679d3bb2d Author: Hannes Reinecke Date: Fri Feb 26 08:17:25 2021 +0100 nvme: simplify error logic in nvme_validate_ns() [ Upstream commit d95c1f4179a7f3ea8aa728ed00252a8ed0f8158f ] We only should remove namespaces when we get fatal error back from the device or when the namespace IDs have changed. So instead of painfully masking out error numbers which might indicate that the error should be ignored we could use an NVME status code to indicated when the namespace should be removed. That simplifies the final logic and makes it less error-prone. Signed-off-by: Hannes Reinecke Reviewed-by: Keith Busch Reviewed-by: Sagi Grimberg Reviewed-by: Daniel Wagner Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit b91230a0013f8a80192be6f0d77bcb89142eff32 Author: Christian König Date: Mon Mar 8 19:22:13 2021 +0100 drm/radeon: fix AGP dependency [ Upstream commit cba2afb65cb05c3d197d17323fee4e3c9edef9cd ] When AGP is compiled as module radeon must be compiled as module as well. Signed-off-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 35d4f071282852181582312c47ccdcecbab284d4 Author: Nirmoy Das Date: Mon Mar 8 15:22:22 2021 +0100 drm/amdgpu: fb BO should be ttm_bo_type_device [ Upstream commit 521f04f9e3ffc73ef96c776035f8a0a31b4cdd81 ] FB BO should not be ttm_bo_type_kernel type and amdgpufb_create_pinned_object() pins the FB BO anyway. Signed-off-by: Nirmoy Das Acked-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a255d14eb5dc592ad74bfee53adbce63a73fdc50 Author: Sung Lee Date: Fri Feb 26 13:20:43 2021 -0500 drm/amd/display: Revert dram_clock_change_latency for DCN2.1 [ Upstream commit b0075d114c33580f5c9fa9cee8e13d06db41471b ] [WHY & HOW] Using values provided by DF for latency may cause hangs in multi display configurations. Revert change to previous value. Tested-by: Daniel Wheeler Signed-off-by: Sung Lee Reviewed-by: Haonan Wang Acked-by: Eryk Brol Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d27b0964ade97211fa7a8cd0010ddc8737a054a5 Author: Damien Le Moal Date: Wed Mar 10 18:09:19 2021 +0900 block: Fix REQ_OP_ZONE_RESET_ALL handling [ Upstream commit faa44c69daf9ccbd5b8a1aee13e0e0d037c0be17 ] Similarly to a single zone reset operation (REQ_OP_ZONE_RESET), execute REQ_OP_ZONE_RESET_ALL operations with REQ_SYNC set. Signed-off-by: Damien Le Moal Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c9d1f6ad1e256fd5b59339bee03bd0e4d0fc3e47 Author: satya priya Date: Wed Feb 24 14:03:08 2021 +0530 regulator: qcom-rpmh: Correct the pmic5_hfsmps515 buck [ Upstream commit e610e072c87a30658479a7b4c51e1801cb3f450c ] Correct the REGULATOR_LINEAR_RANGE and n_voltges for pmic5_hfsmps515 buck. Signed-off-by: satya priya Link: https://lore.kernel.org/r/1614155592-14060-4-git-send-email-skakit@codeaurora.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6366a5bb888baee5d9f7a5b6168066366e541117 Author: Mark Brown Date: Tue Mar 9 19:03:04 2021 +0000 kselftest: arm64: Fix exit code of sve-ptrace [ Upstream commit 07e644885bf6727a48db109fad053cb43f3c9859 ] We track if sve-ptrace encountered a failure in a variable but don't actually use that value when we exit the program, do so. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20210309190304.39169-1-broonie@kernel.org Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit da5bc0c21c04840b235650b1aac8d4421fdb366a Author: Peter Zijlstra Date: Mon Mar 8 09:38:12 2021 +0100 u64_stats,lockdep: Fix u64_stats_init() vs lockdep [ Upstream commit d5b0e0677bfd5efd17c5bbb00156931f0d41cb85 ] Jakub reported that: static struct net_device *rtl8139_init_board(struct pci_dev *pdev) { ... u64_stats_init(&tp->rx_stats.syncp); u64_stats_init(&tp->tx_stats.syncp); ... } results in lockdep getting confused between the RX and TX stats lock. This is because u64_stats_init() is an inline calling seqcount_init(), which is a macro using a static variable to generate a lockdep class. By wrapping that in an inline, we negate the effect of the macro and fold the static key variable, hence the confusion. Fix by also making u64_stats_init() a macro for the case where it matters, leaving the other case an inline for argument validation etc. Reported-by: Jakub Kicinski Debugged-by: "Ahmed S. Darwish" Signed-off-by: Peter Zijlstra (Intel) Tested-by: "Erhard F." Link: https://lkml.kernel.org/r/YEXicy6+9MksdLZh@hirez.programming.kicks-ass.net Signed-off-by: Sasha Levin commit f89338395545991d176477462ca0f08f36161d5c Author: Julian Braha Date: Mon Feb 22 13:06:07 2021 -0500 staging: rtl8192e: fix kconfig dependency on CRYPTO [ Upstream commit 7c36194558cf49a86a53b5f60db8046c5e3013ae ] When RTLLIB_CRYPTO_TKIP is enabled and CRYPTO is disabled, Kbuild gives the following warning: WARNING: unmet direct dependencies detected for CRYPTO_MICHAEL_MIC Depends on [n]: CRYPTO [=n] Selected by [m]: - RTLLIB_CRYPTO_TKIP [=m] && STAGING [=y] && RTLLIB [=m] WARNING: unmet direct dependencies detected for CRYPTO_LIB_ARC4 Depends on [n]: CRYPTO [=n] Selected by [m]: - RTLLIB_CRYPTO_TKIP [=m] && STAGING [=y] && RTLLIB [=m] - RTLLIB_CRYPTO_WEP [=m] && STAGING [=y] && RTLLIB [=m] This is because RTLLIB_CRYPTO_TKIP selects CRYPTO_MICHAEL_MIC and CRYPTO_LIB_ARC4, without depending on or selecting CRYPTO, despite those config options being subordinate to CRYPTO. Acked-by: Randy Dunlap Signed-off-by: Julian Braha Link: https://lore.kernel.org/r/20210222180607.399753-1-julianbraha@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit eb4154fb61e210b4a3b3c1a4b0e045c7d516255b Author: Tomer Tayar Date: Fri Feb 19 14:05:33 2021 +0200 habanalabs: Call put_pid() when releasing control device [ Upstream commit 27ac5aada024e0821c86540ad18f37edadd77d5e ] The refcount of the "hl_fpriv" structure is not used for the control device, and thus hl_hpriv_put() is not called when releasing this device. This results with no call to put_pid(), so add it explicitly in hl_device_release_ctrl(). Signed-off-by: Tomer Tayar Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin commit f2b38f03a3f71c30c77a4516b26c8bea13cc08ce Author: Rob Gardner Date: Sun Feb 28 22:48:16 2021 -0700 sparc64: Fix opcode filtering in handling of no fault loads [ Upstream commit e5e8b80d352ec999d2bba3ea584f541c83f4ca3f ] is_no_fault_exception() has two bugs which were discovered via random opcode testing with stress-ng. Both are caused by improper filtering of opcodes. The first bug can be triggered by a floating point store with a no-fault ASI, for instance "sta %f0, [%g0] #ASI_PNF", opcode C1A01040. The code first tests op3[5] (0x1000000), which denotes a floating point instruction, and then tests op3[2] (0x200000), which denotes a store instruction. But these bits are not mutually exclusive, and the above mentioned opcode has both bits set. The intent is to filter out stores, so the test for stores must be done first in order to have any effect. The second bug can be triggered by a floating point load with one of the invalid ASI values 0x8e or 0x8f, which pass this check in is_no_fault_exception(): if ((asi & 0xf2) == ASI_PNF) An example instruction is "ldqa [%l7 + %o7] #ASI 0x8f, %f38", opcode CF95D1EF. Asi values greater than 0x8b (ASI_SNFL) are fatal in handle_ldf_stq(), and is_no_fault_exception() must not allow these invalid asi values to make it that far. In both of these cases, handle_ldf_stq() reacts by calling sun4v_data_access_exception() or spitfire_data_access_exception(), which call is_no_fault_exception() and results in an infinite recursion. Signed-off-by: Rob Gardner Tested-by: Anatoly Pugachev Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 58b34195b33f675c6bdd49319d4403fe5ae8f422 Author: Wei Yongjun Date: Mon Mar 8 12:35:01 2021 +0000 umem: fix error return code in mm_pci_probe() [ Upstream commit eeb05595d22c19c8f814ff893dcf88ec277a2365 ] Fix to return negative error code -ENOMEM from the blk_alloc_queue() and dma_alloc_coherent() error handling cases instead of 0, as done elsewhere in this function. Reported-by: Hulk Robot Signed-off-by: Wei Yongjun Link: https://lore.kernel.org/r/20210308123501.2573816-1-weiyongjun1@huawei.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit feaa91193ad38d1cdeea0fa5e1ec1eeaf1fc9a36 Author: Jiri Slaby Date: Wed Mar 3 11:43:14 2021 +0100 kbuild: dummy-tools: fix inverted tests for gcc [ Upstream commit b3d9fc1436808a4ef9927e558b3415e728e710c5 ] There is a test in Kconfig which takes inverted value of a compiler check: * config CC_HAS_INT128 def_bool !$(cc-option,$(m64-flag) -D__SIZEOF_INT128__=0) This results in CC_HAS_INT128 not being in super-config generated by dummy-tools. So take this into account in the gcc script. Signed-off-by: Jiri Slaby Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit ede8be3ae078113fb536159a548890ecc39fbc87 Author: Masahiro Yamada Date: Sun Feb 28 15:10:25 2021 +0900 kbuild: add image_name to no-sync-config-targets [ Upstream commit 993bdde94547887faaad4a97f0b0480a6da271c3 ] 'make image_name' needs include/config/auto.conf to show the correct output because KBUILD_IMAGE depends on CONFIG options, but should not attempt to resync the configuration. Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 264bb27b9fe456cf722bd83d3bdbaca394b801ee Author: Paul Cercueil Date: Sun Mar 7 17:20:14 2021 +0000 irqchip/ingenic: Add support for the JZ4760 [ Upstream commit 5fbecd2389f48e1415799c63130d0cdce1cf3f60 ] Add support for the interrupt controller found in the JZ4760 SoC, which works exactly like the one in the JZ4770. Signed-off-by: Paul Cercueil Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20210307172014.73481-2-paul@crapouillou.net Signed-off-by: Sasha Levin commit b684c380f0b9cd993ce45673dc9ef852ad6c3739 Author: Paulo Alcantara Date: Mon Mar 8 12:00:48 2021 -0300 cifs: change noisy error message to FYI [ Upstream commit e3d100eae44b42f309c1366efb8397368f1cf8ed ] A customer has reported that their dmesg were being flooded by CIFS: VFS: \\server Cancelling wait for mid xxx cmd: a CIFS: VFS: \\server Cancelling wait for mid yyy cmd: b CIFS: VFS: \\server Cancelling wait for mid zzz cmd: c because some processes that were performing statfs(2) on the share had been interrupted due to their automount setup when certain users logged in and out. Change it to FYI as they should be mostly informative rather than error messages. Signed-off-by: Paulo Alcantara (SUSE) Reviewed-by: Aurelien Aptel Reviewed-by: Ronnie Sahlberg Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 758bca385a7916a913be341ffd39e88a1243c4a0 Author: Tong Zhang Date: Sun Mar 7 22:25:30 2021 -0500 atm: idt77252: fix null-ptr-dereference [ Upstream commit 4416e98594dc04590ebc498fc4e530009535c511 ] this one is similar to the phy_data allocation fix in uPD98402, the driver allocate the idt77105_priv and store to dev_data but later dereference using dev->dev_data, which will cause null-ptr-dereference. fix this issue by changing dev_data to phy_data so that PRIV(dev) can work correctly. Signed-off-by: Tong Zhang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f35954a3961b71e6ad0667cd7bb8f430f3401aaa Author: Tong Zhang Date: Sun Mar 7 22:25:29 2021 -0500 atm: uPD98402: fix incorrect allocation [ Upstream commit 3153724fc084d8ef640c611f269ddfb576d1dcb1 ] dev->dev_data is set in zatm.c, calling zatm_start() will overwrite this dev->dev_data in uPD98402_start() and a subsequent PRIV(dev)->lock (i.e dev->phy_data->lock) will result in a null-ptr-dereference. I believe this is a typo and what it actually want to do is to allocate phy_data instead of dev_data. Signed-off-by: Tong Zhang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 852143ed96e2cac4a973041a24f443cc6315e055 Author: Alex Marginean Date: Sun Mar 7 15:23:38 2021 +0200 net: enetc: set MAC RX FIFO to recommended value [ Upstream commit 1b2395dfff5bb40228a187f21f577cd90673d344 ] On LS1028A, the MAC RX FIFO defaults to the value 2, which is too high and may lead to RX lock-up under traffic at a rate higher than 6 Gbps. Set it to 1 instead, as recommended by the hardware design team and by later versions of the ENETC block guide. Signed-off-by: Alex Marginean Reviewed-by: Claudiu Manoil Reviewed-by: Jason Liu Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 697082b125b07c57faffd70b12a42891d0803dd1 Author: Paul Cercueil Date: Sun Mar 7 13:17:49 2021 +0000 net: davicom: Use platform_get_irq_optional() [ Upstream commit 2e2696223676d56db1a93acfca722c1b96cd552d ] The second IRQ line really is optional, so use platform_get_irq_optional() to obtain it. Signed-off-by: Paul Cercueil Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e6946ef438487695fd273294af2375c13e1b3a54 Author: Jia-Ju Bai Date: Sun Mar 7 01:12:56 2021 -0800 net: wan: fix error return code of uhdlc_init() [ Upstream commit 62765d39553cfd1ad340124fe1e280450e8c89e2 ] When priv->rx_skbuff or priv->tx_skbuff is NULL, no error return code of uhdlc_init() is assigned. To fix this bug, ret is assigned with -ENOMEM in these cases. Reported-by: TOTE Robot Signed-off-by: Jia-Ju Bai Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 184dc037575ca7d47edd5f37d6ada6dc11e8dad9 Author: Jia-Ju Bai Date: Sun Mar 7 00:40:12 2021 -0800 net: hisilicon: hns: fix error return code of hns_nic_clear_all_rx_fetch() [ Upstream commit 143c253f42bad20357e7e4432087aca747c43384 ] When hns_assemble_skb() returns NULL to skb, no error return code of hns_nic_clear_all_rx_fetch() is assigned. To fix this bug, ret is assigned with -ENOMEM in this case. Reported-by: TOTE Robot Signed-off-by: Jia-Ju Bai Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9d1a5392aca1943bfea6f424346764db75018431 Author: Frank Sorenson Date: Mon Mar 8 12:12:13 2021 -0600 NFS: Correct size calculation for create reply length [ Upstream commit ad3dbe35c833c2d4d0bbf3f04c785d32f931e7c9 ] CREATE requests return a post_op_fh3, rather than nfs_fh3. The post_op_fh3 includes an extra word to indicate 'handle_follows'. Without that additional word, create fails when full 64-byte filehandles are in use. Add NFS3_post_op_fh_sz, and correct the size calculation for NFS3_createres_sz. Signed-off-by: Frank Sorenson Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 2479c6b9ef36f9fd7ed37dbeb8f220bdeb175710 Author: Timo Rothenpieler Date: Tue Feb 23 15:19:01 2021 +0100 nfs: fix PNFS_FLEXFILE_LAYOUT Kconfig default [ Upstream commit a0590473c5e6c4ef17c3132ad08fbad170f72d55 ] This follows what was done in 8c2fabc6542d9d0f8b16bd1045c2eda59bdcde13. With the default being m, it's impossible to build the module into the kernel. Signed-off-by: Timo Rothenpieler Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit b48779c863c018bd5ec4ba966cebf2ab656093b8 Author: Yang Li Date: Tue Feb 23 16:35:58 2021 +0800 gpiolib: acpi: Add missing IRQF_ONESHOT [ Upstream commit 6e5d5791730b55a1f987e1db84b078b91eb49e99 ] fixed the following coccicheck: ./drivers/gpio/gpiolib-acpi.c:176:7-27: ERROR: Threaded IRQ with no primary handler requested without IRQF_ONESHOT Make sure threaded IRQs without a primary handler are always request with IRQF_ONESHOT Reported-by: Abaci Robot Signed-off-by: Yang Li Acked-by: Andy Shevchenko Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit 9443aef16fca8071032e702e1386d5c40a4a0832 Author: Sudeep Holla Date: Thu Feb 18 22:23:26 2021 +0000 cpufreq: blacklist Arm Vexpress platforms in cpufreq-dt-platdev [ Upstream commit fbb31cb805fd3574d3be7defc06a7fd2fd9af7d2 ] Add "arm,vexpress" to cpufreq-dt-platdev blacklist since the actual scaling is handled by the firmware cpufreq drivers(scpi, scmi and vexpress-spc). Signed-off-by: Sudeep Holla Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 6d7dce3bdfc4d38d64212f458c6778dcd2bead00 Author: Bob Peterson Date: Thu Feb 25 11:11:09 2021 -0500 gfs2: fix use-after-free in trans_drain [ Upstream commit 1a5a2cfd34c17db73c53ef127272c8c1ae220485 ] This patch adds code to function trans_drain to remove drained bd elements from the ail lists, if queued, before freeing the bd. If we don't remove the bd from the ail, function ail_drain will try to reference the bd after it has been freed by trans_drain. Thanks to Andy Price for his analysis of the problem. Reported-by: Andy Price Signed-off-by: Bob Peterson Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 419ebba40dbf7f60cc0bde11cb35702b7c820b1c Author: Aurelien Aptel Date: Thu Mar 4 17:51:48 2021 +0000 cifs: ask for more credit on async read/write code paths [ Upstream commit 88fd98a2306755b965e4f4567f84e73db3b6738c ] When doing a large read or write workload we only very gradually increase the number of credits which can cause problems with parallelizing large i/o (I/O ramps up more slowly than it should for large read/write workloads) especially with multichannel when the number of credits on the secondary channels starts out low (e.g. less than about 130) or when recovering after server throttled back the number of credit. Signed-off-by: Aurelien Aptel Reviewed-by: Shyam Prasad N Signed-off-by: Steve French Signed-off-by: Sasha Levin commit b8bfda6e08b8a419097eea5a8e57671bc36f9939 Author: Michael Braun Date: Thu Mar 4 20:52:52 2021 +0100 gianfar: fix jumbo packets+napi+rx overrun crash [ Upstream commit d8861bab48b6c1fc3cdbcab8ff9d1eaea43afe7f ] When using jumbo packets and overrunning rx queue with napi enabled, the following sequence is observed in gfar_add_rx_frag: | lstatus | | skb | t | lstatus, size, flags | first | len, data_len, *ptr | ---+--------------------------------------+-------+-----------------------+ 13 | 18002348, 9032, INTERRUPT LAST | 0 | 9600, 8000, f554c12e | 12 | 10000640, 1600, INTERRUPT | 0 | 8000, 6400, f554c12e | 11 | 10000640, 1600, INTERRUPT | 0 | 6400, 4800, f554c12e | 10 | 10000640, 1600, INTERRUPT | 0 | 4800, 3200, f554c12e | 09 | 10000640, 1600, INTERRUPT | 0 | 3200, 1600, f554c12e | 08 | 14000640, 1600, INTERRUPT FIRST | 0 | 1600, 0, f554c12e | 07 | 14000640, 1600, INTERRUPT FIRST | 1 | 0, 0, f554c12e | 06 | 1c000080, 128, INTERRUPT LAST FIRST | 1 | 0, 0, abf3bd6e | 05 | 18002348, 9032, INTERRUPT LAST | 0 | 8000, 6400, c5a57780 | 04 | 10000640, 1600, INTERRUPT | 0 | 6400, 4800, c5a57780 | 03 | 10000640, 1600, INTERRUPT | 0 | 4800, 3200, c5a57780 | 02 | 10000640, 1600, INTERRUPT | 0 | 3200, 1600, c5a57780 | 01 | 10000640, 1600, INTERRUPT | 0 | 1600, 0, c5a57780 | 00 | 14000640, 1600, INTERRUPT FIRST | 1 | 0, 0, c5a57780 | So at t=7 a new packets is started but not finished, probably due to rx overrun - but rx overrun is not indicated in the flags. Instead a new packets starts at t=8. This results in skb->len to exceed size for the LAST fragment at t=13 and thus a negative fragment size added to the skb. This then crashes: kernel BUG at include/linux/skbuff.h:2277! Oops: Exception in kernel mode, sig: 5 [#1] ... NIP [c04689f4] skb_pull+0x2c/0x48 LR [c03f62ac] gfar_clean_rx_ring+0x2e4/0x844 Call Trace: [ec4bfd38] [c06a84c4] _raw_spin_unlock_irqrestore+0x60/0x7c (unreliable) [ec4bfda8] [c03f6a44] gfar_poll_rx_sq+0x48/0xe4 [ec4bfdc8] [c048d504] __napi_poll+0x54/0x26c [ec4bfdf8] [c048d908] net_rx_action+0x138/0x2c0 [ec4bfe68] [c06a8f34] __do_softirq+0x3a4/0x4fc [ec4bfed8] [c0040150] run_ksoftirqd+0x58/0x70 [ec4bfee8] [c0066ecc] smpboot_thread_fn+0x184/0x1cc [ec4bff08] [c0062718] kthread+0x140/0x144 [ec4bff38] [c0012350] ret_from_kernel_thread+0x14/0x1c This patch fixes this by checking for computed LAST fragment size, so a negative sized fragment is never added. In order to prevent the newer rx frame from getting corrupted, the FIRST flag is checked to discard the incomplete older frame. Signed-off-by: Michael Braun Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2d0fba5a2e9fefe20a124412fa34ce0ab29e3d88 Author: Denis Efremov Date: Fri Mar 5 20:02:12 2021 +0300 sun/niu: fix wrong RXMAC_BC_FRM_CNT_COUNT count [ Upstream commit 155b23e6e53475ca3b8c2a946299b4d4dd6a5a1e ] RXMAC_BC_FRM_CNT_COUNT added to mp->rx_bcasts twice in a row in niu_xmac_interrupt(). Remove the second addition. Signed-off-by: Denis Efremov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 81b1a8f14436b48068964cc6fab3e8224bb60b02 Author: Jia-Ju Bai Date: Thu Mar 4 19:10:10 2021 -0800 net: intel: iavf: fix error return code of iavf_init_get_resources() [ Upstream commit 6650d31f21b8a0043613ae0a4a2e42e49dc20b2d ] When iavf_process_config() fails, no error return code of iavf_init_get_resources() is assigned. To fix this bug, err is assigned with the return value of iavf_process_config(), and then err is checked. Reported-by: TOTE Robot Signed-off-by: Jia-Ju Bai Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5f86016bdfa7770dbddf633223a63284ce5259e5 Author: Jia-Ju Bai Date: Thu Mar 4 18:06:48 2021 -0800 net: tehuti: fix error return code in bdx_probe() [ Upstream commit 38c26ff3048af50eee3fcd591921357ee5bfd9ee ] When bdx_read_mac() fails, no error return code of bdx_probe() is assigned. To fix this bug, err is assigned with -EFAULT as error return code. Reported-by: TOTE Robot Signed-off-by: Jia-Ju Bai Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 71b996c9b883313be4320954c902e84031399fd9 Author: Xunlei Pang Date: Fri Mar 5 16:13:27 2021 +0800 blk-cgroup: Fix the recursive blkg rwstat [ Upstream commit 4f44657d74873735e93a50eb25014721a66aac19 ] The current blkio.throttle.io_service_bytes_recursive doesn't work correctly. As an example, for the following blkcg hierarchy: (Made 1GB READ in test1, 512MB READ in test2) test / \ test1 test2 $ head -n 1 test/test1/blkio.throttle.io_service_bytes_recursive 8:0 Read 1073684480 $ head -n 1 test/test2/blkio.throttle.io_service_bytes_recursive 8:0 Read 537448448 $ head -n 1 test/blkio.throttle.io_service_bytes_recursive 8:0 Read 537448448 Clearly, above data of "test" reflects "test2" not "test1"+"test2". Do the correct summary in blkg_rwstat_recursive_sum(). Signed-off-by: Xunlei Pang Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit b171748b7953c6d9344c68e21cbcb1e7ba154bf3 Author: Nitin Rawat Date: Tue Feb 23 21:36:48 2021 -0800 scsi: ufs: ufs-qcom: Disable interrupt in reset path [ Upstream commit 4a791574a0ccf36eb3a0a46fbd71d2768df3eef9 ] Disable interrupt in reset path to flush pending IRQ handler in order to avoid possible NoC issues. Link: https://lore.kernel.org/r/1614145010-36079-3-git-send-email-cang@codeaurora.org Reviewed-by: Avri Altman Signed-off-by: Nitin Rawat Signed-off-by: Can Guo Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 028210541b3c2b6c81ddc893b6cd54a68bbb23fc Author: Dinghao Liu Date: Sun Jan 3 16:08:42 2021 +0800 ixgbe: Fix memleak in ixgbe_configure_clsu32 [ Upstream commit 7a766381634da19fc837619b0a34590498d9d29a ] When ixgbe_fdir_write_perfect_filter_82599() fails, input allocated by kzalloc() has not been freed, which leads to memleak. Signed-off-by: Dinghao Liu Reviewed-by: Paul Menzel Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 4dc123500c3bcdb834a3685bc412bf7e2813ea3f Author: Mark Pearson Date: Tue Mar 2 09:10:03 2021 -0500 ALSA: hda: ignore invalid NHLT table [ Upstream commit a14a6219996ee6f6e858d83b11affc7907633687 ] On some Lenovo systems if the microphone is disabled in the BIOS only the NHLT table header is created, with no data. This means the endpoints field is not correctly set to zero - leading to an unintialised variable and hence invalid descriptors are parsed leading to page faults. The Lenovo firmware team is addressing this, but adding a check preventing invalid tables being parsed is worthwhile. Tested on a Lenovo T14. Tested-by: Philipp Leskovitz Reported-by: Philipp Leskovitz Signed-off-by: Mark Pearson Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210302141003.7342-1-markpearson@lenovo.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 18f27fc6bcc20f5425a42456330cffdc8a8e5c04 Author: Hayes Wang Date: Wed Mar 3 16:39:47 2021 +0800 Revert "r8152: adjust the settings about MAC clock speed down for RTL8153" [ Upstream commit 4b5dc1a94d4f92b5845e98bd9ae344b26d933aad ] This reverts commit 134f98bcf1b898fb9d6f2b91bc85dd2e5478b4b8. The r8153_mac_clk_spd() is used for RTL8153A only, because the register table of RTL8153B is different from RTL8153A. However, this function would be called when RTL8153B calls r8153_first_init() and r8153_enter_oob(). That causes RTL8153B becomes unstable when suspending and resuming. The worst case may let the device stop working. Besides, revert this commit to disable MAC clock speed down for RTL8153A. It would avoid the known issue when enabling U1. The data of the first control transfer may be wrong when exiting U1. Signed-off-by: Hayes Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f8f6190094a379156ea69e04b41aff2ae04556a2 Author: Tong Zhang Date: Sat Feb 27 22:55:50 2021 -0500 atm: lanai: dont run lanai_dev_close if not open [ Upstream commit a2bd45834e83d6c5a04d397bde13d744a4812dfc ] lanai_dev_open() can fail. When it fail, lanai->base is unmapped and the pci device is disabled. The caller, lanai_init_one(), then tries to run atm_dev_deregister(). This will subsequently call lanai_dev_close() and use the already released MMIO area. To fix this issue, set the lanai->base to NULL if open fail, and test the flag in lanai_dev_close(). [ 8.324153] lanai: lanai_start() failed, err=19 [ 8.324819] lanai(itf 0): shutting down interface [ 8.325211] BUG: unable to handle page fault for address: ffffc90000180024 [ 8.325781] #PF: supervisor write access in kernel mode [ 8.326215] #PF: error_code(0x0002) - not-present page [ 8.326641] PGD 100000067 P4D 100000067 PUD 100139067 PMD 10013a067 PTE 0 [ 8.327206] Oops: 0002 [#1] SMP KASAN NOPTI [ 8.327557] CPU: 0 PID: 95 Comm: modprobe Not tainted 5.11.0-rc7-00090-gdcc0b49040c7 #12 [ 8.328229] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-48-gd9c812dda519-4 [ 8.329145] RIP: 0010:lanai_dev_close+0x4f/0xe5 [lanai] [ 8.329587] Code: 00 48 c7 c7 00 d3 01 c0 e8 49 4e 0a c2 48 8d bd 08 02 00 00 e8 6e 52 14 c1 48 80 [ 8.330917] RSP: 0018:ffff8881029ef680 EFLAGS: 00010246 [ 8.331196] RAX: 000000000003fffe RBX: ffff888102fb4800 RCX: ffffffffc001a98a [ 8.331572] RDX: ffffc90000180000 RSI: 0000000000000246 RDI: ffff888102fb4000 [ 8.331948] RBP: ffff888102fb4000 R08: ffffffff8115da8a R09: ffffed102053deaa [ 8.332326] R10: 0000000000000003 R11: ffffed102053dea9 R12: ffff888102fb48a4 [ 8.332701] R13: ffffffffc00123c0 R14: ffff888102fb4b90 R15: ffff888102fb4b88 [ 8.333077] FS: 00007f08eb9056a0(0000) GS:ffff88815b400000(0000) knlGS:0000000000000000 [ 8.333502] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 8.333806] CR2: ffffc90000180024 CR3: 0000000102a28000 CR4: 00000000000006f0 [ 8.334182] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 8.334557] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 8.334932] Call Trace: [ 8.335066] atm_dev_deregister+0x161/0x1a0 [atm] [ 8.335324] lanai_init_one.cold+0x20c/0x96d [lanai] [ 8.335594] ? lanai_send+0x2a0/0x2a0 [lanai] [ 8.335831] local_pci_probe+0x6f/0xb0 [ 8.336039] pci_device_probe+0x171/0x240 [ 8.336255] ? pci_device_remove+0xe0/0xe0 [ 8.336475] ? kernfs_create_link+0xb6/0x110 [ 8.336704] ? sysfs_do_create_link_sd.isra.0+0x76/0xe0 [ 8.336983] really_probe+0x161/0x420 [ 8.337181] driver_probe_device+0x6d/0xd0 [ 8.337401] device_driver_attach+0x82/0x90 [ 8.337626] ? device_driver_attach+0x90/0x90 [ 8.337859] __driver_attach+0x60/0x100 [ 8.338065] ? device_driver_attach+0x90/0x90 [ 8.338298] bus_for_each_dev+0xe1/0x140 [ 8.338511] ? subsys_dev_iter_exit+0x10/0x10 [ 8.338745] ? klist_node_init+0x61/0x80 [ 8.338956] bus_add_driver+0x254/0x2a0 [ 8.339164] driver_register+0xd3/0x150 [ 8.339370] ? 0xffffffffc0028000 [ 8.339550] do_one_initcall+0x84/0x250 [ 8.339755] ? trace_event_raw_event_initcall_finish+0x150/0x150 [ 8.340076] ? free_vmap_area_noflush+0x1a5/0x5c0 [ 8.340329] ? unpoison_range+0xf/0x30 [ 8.340532] ? ____kasan_kmalloc.constprop.0+0x84/0xa0 [ 8.340806] ? unpoison_range+0xf/0x30 [ 8.341014] ? unpoison_range+0xf/0x30 [ 8.341217] do_init_module+0xf8/0x350 [ 8.341419] load_module+0x3fe6/0x4340 [ 8.341621] ? vm_unmap_ram+0x1d0/0x1d0 [ 8.341826] ? ____kasan_kmalloc.constprop.0+0x84/0xa0 [ 8.342101] ? module_frob_arch_sections+0x20/0x20 [ 8.342358] ? __do_sys_finit_module+0x108/0x170 [ 8.342604] __do_sys_finit_module+0x108/0x170 [ 8.342841] ? __ia32_sys_init_module+0x40/0x40 [ 8.343083] ? file_open_root+0x200/0x200 [ 8.343298] ? do_sys_open+0x85/0xe0 [ 8.343491] ? filp_open+0x50/0x50 [ 8.343675] ? exit_to_user_mode_prepare+0xfc/0x130 [ 8.343935] do_syscall_64+0x33/0x40 [ 8.344132] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 8.344401] RIP: 0033:0x7f08eb887cf7 [ 8.344594] Code: 48 89 57 30 48 8b 04 24 48 89 47 38 e9 1d a0 02 00 48 89 f8 48 89 f7 48 89 d6 41 [ 8.345565] RSP: 002b:00007ffcd5c98ad8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 8.345962] RAX: ffffffffffffffda RBX: 00000000008fea70 RCX: 00007f08eb887cf7 [ 8.346336] RDX: 0000000000000000 RSI: 00000000008fd9e0 RDI: 0000000000000003 [ 8.346711] RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000001 [ 8.347085] R10: 00007f08eb8eb300 R11: 0000000000000246 R12: 00000000008fd9e0 [ 8.347460] R13: 0000000000000000 R14: 00000000008fddd0 R15: 0000000000000001 [ 8.347836] Modules linked in: lanai(+) atm [ 8.348065] CR2: ffffc90000180024 [ 8.348244] ---[ end trace 7fdc1c668f2003e5 ]--- [ 8.348490] RIP: 0010:lanai_dev_close+0x4f/0xe5 [lanai] [ 8.348772] Code: 00 48 c7 c7 00 d3 01 c0 e8 49 4e 0a c2 48 8d bd 08 02 00 00 e8 6e 52 14 c1 48 80 [ 8.349745] RSP: 0018:ffff8881029ef680 EFLAGS: 00010246 [ 8.350022] RAX: 000000000003fffe RBX: ffff888102fb4800 RCX: ffffffffc001a98a [ 8.350397] RDX: ffffc90000180000 RSI: 0000000000000246 RDI: ffff888102fb4000 [ 8.350772] RBP: ffff888102fb4000 R08: ffffffff8115da8a R09: ffffed102053deaa [ 8.351151] R10: 0000000000000003 R11: ffffed102053dea9 R12: ffff888102fb48a4 [ 8.351525] R13: ffffffffc00123c0 R14: ffff888102fb4b90 R15: ffff888102fb4b88 [ 8.351918] FS: 00007f08eb9056a0(0000) GS:ffff88815b400000(0000) knlGS:0000000000000000 [ 8.352343] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 8.352647] CR2: ffffc90000180024 CR3: 0000000102a28000 CR4: 00000000000006f0 [ 8.353022] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 8.353397] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 8.353958] modprobe (95) used greatest stack depth: 26216 bytes left Signed-off-by: Tong Zhang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6f6e459475721b93bb215125f22b71eeb6ee87af Author: Tong Zhang Date: Sat Feb 27 16:15:06 2021 -0500 atm: eni: dont release is never initialized [ Upstream commit 4deb550bc3b698a1f03d0332cde3df154d1b6c1e ] label err_eni_release is reachable when eni_start() fail. In eni_start() it calls dev->phy->start() in the last step, if start() fail we don't need to call phy->stop(), if start() is never called, we neither need to call phy->stop(), otherwise null-ptr-deref will happen. In order to fix this issue, don't call phy->stop() in label err_eni_release [ 4.875714] ================================================================== [ 4.876091] BUG: KASAN: null-ptr-deref in suni_stop+0x47/0x100 [suni] [ 4.876433] Read of size 8 at addr 0000000000000030 by task modprobe/95 [ 4.876778] [ 4.876862] CPU: 0 PID: 95 Comm: modprobe Not tainted 5.11.0-rc7-00090-gdcc0b49040c7 #2 [ 4.877290] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-48-gd94 [ 4.877876] Call Trace: [ 4.878009] dump_stack+0x7d/0xa3 [ 4.878191] kasan_report.cold+0x10c/0x10e [ 4.878410] ? __slab_free+0x2f0/0x340 [ 4.878612] ? suni_stop+0x47/0x100 [suni] [ 4.878832] suni_stop+0x47/0x100 [suni] [ 4.879043] eni_do_release+0x3b/0x70 [eni] [ 4.879269] eni_init_one.cold+0x1152/0x1747 [eni] [ 4.879528] ? _raw_spin_lock_irqsave+0x7b/0xd0 [ 4.879768] ? eni_ioctl+0x270/0x270 [eni] [ 4.879990] ? __mutex_lock_slowpath+0x10/0x10 [ 4.880226] ? eni_ioctl+0x270/0x270 [eni] [ 4.880448] local_pci_probe+0x6f/0xb0 [ 4.880650] pci_device_probe+0x171/0x240 [ 4.880864] ? pci_device_remove+0xe0/0xe0 [ 4.881086] ? kernfs_create_link+0xb6/0x110 [ 4.881315] ? sysfs_do_create_link_sd.isra.0+0x76/0xe0 [ 4.881594] really_probe+0x161/0x420 [ 4.881791] driver_probe_device+0x6d/0xd0 [ 4.882010] device_driver_attach+0x82/0x90 [ 4.882233] ? device_driver_attach+0x90/0x90 [ 4.882465] __driver_attach+0x60/0x100 [ 4.882671] ? device_driver_attach+0x90/0x90 [ 4.882903] bus_for_each_dev+0xe1/0x140 [ 4.883114] ? subsys_dev_iter_exit+0x10/0x10 [ 4.883346] ? klist_node_init+0x61/0x80 [ 4.883557] bus_add_driver+0x254/0x2a0 [ 4.883764] driver_register+0xd3/0x150 [ 4.883971] ? 0xffffffffc0038000 [ 4.884149] do_one_initcall+0x84/0x250 [ 4.884355] ? trace_event_raw_event_initcall_finish+0x150/0x150 [ 4.884674] ? unpoison_range+0xf/0x30 [ 4.884875] ? ____kasan_kmalloc.constprop.0+0x84/0xa0 [ 4.885150] ? unpoison_range+0xf/0x30 [ 4.885352] ? unpoison_range+0xf/0x30 [ 4.885557] do_init_module+0xf8/0x350 [ 4.885760] load_module+0x3fe6/0x4340 [ 4.885960] ? vm_unmap_ram+0x1d0/0x1d0 [ 4.886166] ? ____kasan_kmalloc.constprop.0+0x84/0xa0 [ 4.886441] ? module_frob_arch_sections+0x20/0x20 [ 4.886697] ? __do_sys_finit_module+0x108/0x170 [ 4.886941] __do_sys_finit_module+0x108/0x170 [ 4.887178] ? __ia32_sys_init_module+0x40/0x40 [ 4.887419] ? file_open_root+0x200/0x200 [ 4.887634] ? do_sys_open+0x85/0xe0 [ 4.887826] ? filp_open+0x50/0x50 [ 4.888009] ? fpregs_assert_state_consistent+0x4d/0x60 [ 4.888287] ? exit_to_user_mode_prepare+0x2f/0x130 [ 4.888547] do_syscall_64+0x33/0x40 [ 4.888739] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 4.889010] RIP: 0033:0x7ff62fcf1cf7 [ 4.889202] Code: 48 89 57 30 48 8b 04 24 48 89 47 38 e9 1d a0 02 00 48 89 f8 48 89 f71 [ 4.890172] RSP: 002b:00007ffe6644ade8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 4.890570] RAX: ffffffffffffffda RBX: 0000000000f2ca70 RCX: 00007ff62fcf1cf7 [ 4.890944] RDX: 0000000000000000 RSI: 0000000000f2b9e0 RDI: 0000000000000003 [ 4.891318] RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000001 [ 4.891691] R10: 00007ff62fd55300 R11: 0000000000000246 R12: 0000000000f2b9e0 [ 4.892064] R13: 0000000000000000 R14: 0000000000f2bdd0 R15: 0000000000000001 [ 4.892439] ================================================================== Signed-off-by: Tong Zhang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 75e967a04d373bdd7155abc55d69544646be00f9 Author: Michael Ellerman Date: Thu Feb 18 23:30:58 2021 +1100 powerpc/4xx: Fix build errors from mfdcr() [ Upstream commit eead089311f4d935ab5d1d8fbb0c42ad44699ada ] lkp reported a build error in fsp2.o: CC arch/powerpc/platforms/44x/fsp2.o {standard input}:577: Error: unsupported relocation against base Which comes from: pr_err("GESR0: 0x%08x\n", mfdcr(base + PLB4OPB_GESR0)); Where our mfdcr() macro is stringifying "base + PLB4OPB_GESR0", and passing that to the assembler, which obviously doesn't work. The mfdcr() macro already checks that the argument is constant using __builtin_constant_p(), and if not calls the out-of-line version of mfdcr(). But in this case GCC is smart enough to notice that "base + PLB4OPB_GESR0" will be constant, even though it's not something we can immediately stringify into a register number. Segher pointed out that passing the register number to the inline asm as a constant would be better, and in fact it fixes the build error, presumably because it gives GCC a chance to resolve the value. While we're at it, change mtdcr() similarly. Reported-by: kernel test robot Suggested-by: Segher Boessenkool Signed-off-by: Michael Ellerman Acked-by: Feng Tang Link: https://lore.kernel.org/r/20210218123058.748882-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit 4a104e4d4d9dbc7422f50be64ebdc8d9a4a030ca Author: Heiko Thiery Date: Thu Feb 25 22:15:16 2021 +0100 net: fec: ptp: avoid register access when ipg clock is disabled [ Upstream commit 6a4d7234ae9a3bb31181f348ade9bbdb55aeb5c5 ] When accessing the timecounter register on an i.MX8MQ the kernel hangs. This is only the case when the interface is down. This can be reproduced by reading with 'phc_ctrl eth0 get'. Like described in the change in 91c0d987a9788dcc5fe26baafd73bf9242b68900 the igp clock is disabled when the interface is down and leads to a system hang. So we check if the ptp clock status before reading the timecounter register. Signed-off-by: Heiko Thiery Acked-by: Richard Cochran Link: https://lore.kernel.org/r/20210225211514.9115-1-heiko.thiery@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 50c75680bdce30df9497a620db9d2c1ea5f8a3a2 Author: Joakim Zhang Date: Thu Feb 25 17:01:12 2021 +0800 net: stmmac: fix dma physical address of descriptor when display ring [ Upstream commit bfaf91ca848e758ed7be99b61fd936d03819fa56 ] Driver uses dma_alloc_coherent to allocate dma memory for descriptors, dma_alloc_coherent will return both the virtual address and physical address. AFAIK, virt_to_phys could not convert virtual address to physical address, for which memory is allocated by dma_alloc_coherent. dwmac4_display_ring() function is broken for various descriptor, it only support normal descriptor(struct dma_desc) now, this patch also extends to support all descriptor types. Signed-off-by: Joakim Zhang Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a9daba140178df9ad5bffd646517709086d10854 Author: Felix Fietkau Date: Tue Feb 16 14:51:18 2021 +0100 mt76: fix tx skb error handling in mt76_dma_tx_queue_skb [ Upstream commit ae064fc0e32a4d28389086d9f4b260a0c157cfee ] When running out of room in the tx queue after calling drv->tx_prepare_skb, the buffer list will already have been modified on MT7615 and newer drivers. This can leak a DMA mapping and will show up as swiotlb allocation failures on x86. Fix this by moving the queue length check further up. This is less accurate, since it can overestimate the needed room in the queue on MT7615 and newer, but the difference is small enough to not matter in practice. Signed-off-by: Felix Fietkau Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210216135119.23809-1-nbd@nbd.name Signed-off-by: Sasha Levin commit efb12c03fcd0ca9cca2a1bde790348c25485c5c0 Author: Zhou Guanghui Date: Fri Mar 12 21:08:33 2021 -0800 mm/memcg: set memcg when splitting page commit e1baddf8475b06cc56f4bafecf9a32a124343d9f upstream. As described in the split_page() comment, for the non-compound high order page, the sub-pages must be freed individually. If the memcg of the first page is valid, the tail pages cannot be uncharged when be freed. For example, when alloc_pages_exact is used to allocate 1MB continuous physical memory, 2MB is charged(kmemcg is enabled and __GFP_ACCOUNT is set). When make_alloc_exact free the unused 1MB and free_pages_exact free the applied 1MB, actually, only 4KB(one page) is uncharged. Therefore, the memcg of the tail page needs to be set when splitting a page. Michel: There are at least two explicit users of __GFP_ACCOUNT with alloc_exact_pages added recently. See 7efe8ef274024 ("KVM: arm64: Allocate stage-2 pgd pages with GFP_KERNEL_ACCOUNT") and c419621873713 ("KVM: s390: Add memcg accounting to KVM allocations"), so this is not just a theoretical issue. Link: https://lkml.kernel.org/r/20210304074053.65527-3-zhouguanghui1@huawei.com Signed-off-by: Zhou Guanghui Acked-by: Johannes Weiner Reviewed-by: Zi Yan Reviewed-by: Shakeel Butt Acked-by: Michal Hocko Cc: Hanjun Guo Cc: Hugh Dickins Cc: Kefeng Wang Cc: "Kirill A. Shutemov" Cc: Nicholas Piggin Cc: Rui Xiang Cc: Tianhong Ding Cc: Weilong Chen Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6143a1d193e9ecc18250516594655c5a6fbc3a7b Author: Zhou Guanghui Date: Fri Mar 12 21:08:30 2021 -0800 mm/memcg: rename mem_cgroup_split_huge_fixup to split_page_memcg and add nr_pages argument commit be6c8982e4ab9a41907555f601b711a7e2a17d4c upstream. Rename mem_cgroup_split_huge_fixup to split_page_memcg and explicitly pass in page number argument. In this way, the interface name is more common and can be used by potential users. In addition, the complete info(memcg and flag) of the memcg needs to be set to the tail pages. Link: https://lkml.kernel.org/r/20210304074053.65527-2-zhouguanghui1@huawei.com Signed-off-by: Zhou Guanghui Acked-by: Johannes Weiner Reviewed-by: Zi Yan Reviewed-by: Shakeel Butt Acked-by: Michal Hocko Cc: Hugh Dickins Cc: "Kirill A. Shutemov" Cc: Nicholas Piggin Cc: Kefeng Wang Cc: Hanjun Guo Cc: Tianhong Ding Cc: Weilong Chen Cc: Rui Xiang Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Hugh Dickins Signed-off-by: Greg Kroah-Hartman