- 12 Jan, 2022 2 commits
-
-
Wen Gong authored
Commit b4a0f541 ("ath11k: move peer delete after vdev stop of station for QCA6390 and WCN6855") is to fix firmware crash by changing the WMI command sequence, but actually skip all the peer delete operation, then it lead commit 58595c98 ("ath11k: Fixing dangling pointer issue upon peer delete failure") not take effect, and then happened a use-after-free warning from KASAN. because the peer->sta is not set to NULL and then used later. Change to only skip the WMI_PEER_DELETE_CMDID for QCA6390/WCN6855. log of user-after-free: [ 534.888665] BUG: KASAN: use-after-free in ath11k_dp_rx_update_peer_stats+0x912/0xc10 [ath11k] [ 534.888696] Read of size 8 at addr ffff8881396bb1b8 by task rtcwake/2860 [ 534.888705] CPU: 4 PID: 2860 Comm: rtcwake Kdump: loaded Tainted: G W 5.15.0-wt-ath+ #523 [ 534.888712] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021 [ 534.888716] Call Trace: [ 534.888720] <IRQ> [ 534.888726] dump_stack_lvl+0x57/0x7d [ 534.888736] print_address_description.constprop.0+0x1f/0x170 [ 534.888745] ? ath11k_dp_rx_update_peer_stats+0x912/0xc10 [ath11k] [ 534.888771] kasan_report.cold+0x83/0xdf [ 534.888783] ? ath11k_dp_rx_update_peer_stats+0x912/0xc10 [ath11k] [ 534.888810] ath11k_dp_rx_update_peer_stats+0x912/0xc10 [ath11k] [ 534.888840] ath11k_dp_rx_process_mon_status+0x529/0xa70 [ath11k] [ 534.888874] ? ath11k_dp_rx_mon_status_bufs_replenish+0x3f0/0x3f0 [ath11k] [ 534.888897] ? check_prev_add+0x20f0/0x20f0 [ 534.888922] ? __lock_acquire+0xb72/0x1870 [ 534.888937] ? find_held_lock+0x33/0x110 [ 534.888954] ath11k_dp_rx_process_mon_rings+0x297/0x520 [ath11k] [ 534.888981] ? rcu_read_unlock+0x40/0x40 [ 534.888990] ? ath11k_dp_rx_pdev_alloc+0xd90/0xd90 [ath11k] [ 534.889026] ath11k_dp_service_mon_ring+0x67/0xe0 [ath11k] [ 534.889053] ? ath11k_dp_rx_process_mon_rings+0x520/0x520 [ath11k] [ 534.889075] call_timer_fn+0x167/0x4a0 [ 534.889084] ? add_timer_on+0x3b0/0x3b0 [ 534.889103] ? lockdep_hardirqs_on_prepare.part.0+0x18c/0x370 [ 534.889117] __run_timers.part.0+0x539/0x8b0 [ 534.889123] ? ath11k_dp_rx_process_mon_rings+0x520/0x520 [ath11k] [ 534.889157] ? call_timer_fn+0x4a0/0x4a0 [ 534.889164] ? mark_lock_irq+0x1c30/0x1c30 [ 534.889173] ? clockevents_program_event+0xdd/0x280 [ 534.889189] ? mark_held_locks+0xa5/0xe0 [ 534.889203] run_timer_softirq+0x97/0x180 [ 534.889213] __do_softirq+0x276/0x86a [ 534.889230] __irq_exit_rcu+0x11c/0x180 [ 534.889238] irq_exit_rcu+0x5/0x20 [ 534.889244] sysvec_apic_timer_interrupt+0x8e/0xc0 [ 534.889251] </IRQ> [ 534.889254] <TASK> [ 534.889259] asm_sysvec_apic_timer_interrupt+0x12/0x20 [ 534.889265] RIP: 0010:_raw_spin_unlock_irqrestore+0x38/0x70 [ 534.889271] Code: 74 24 10 e8 ea c2 bf fd 48 89 ef e8 12 53 c0 fd 81 e3 00 02 00 00 75 25 9c 58 f6 c4 02 75 2d 48 85 db 74 01 fb bf 01 00 00 00 <e8> 13 a7 b5 fd 65 8b 05 cc d9 9c 5e 85 c0 74 0a 5b 5d c3 e8 a0 ee [ 534.889276] RSP: 0018:ffffc90002e5f880 EFLAGS: 00000206 [ 534.889284] RAX: 0000000000000006 RBX: 0000000000000200 RCX: ffffffff9f256f10 [ 534.889289] RDX: 0000000000000000 RSI: ffffffffa1c6e420 RDI: 0000000000000001 [ 534.889293] RBP: ffff8881095e6200 R08: 0000000000000001 R09: ffffffffa40d2b8f [ 534.889298] R10: fffffbfff481a571 R11: 0000000000000001 R12: ffff8881095e6e68 [ 534.889302] R13: ffffc90002e5f908 R14: 0000000000000246 R15: 0000000000000000 [ 534.889316] ? mark_lock+0xd0/0x14a0 [ 534.889332] klist_next+0x1d4/0x450 [ 534.889340] ? dpm_wait_for_subordinate+0x2d0/0x2d0 [ 534.889350] device_for_each_child+0xa8/0x140 [ 534.889360] ? device_remove_class_symlinks+0x1b0/0x1b0 [ 534.889370] ? __lock_release+0x4bd/0x9f0 [ 534.889378] ? dpm_suspend+0x26b/0x3f0 [ 534.889390] dpm_wait_for_subordinate+0x82/0x2d0 [ 534.889400] ? dpm_for_each_dev+0xa0/0xa0 [ 534.889410] ? dpm_suspend+0x233/0x3f0 [ 534.889427] __device_suspend+0xd4/0x10c0 [ 534.889440] ? wait_for_completion_io+0x270/0x270 [ 534.889456] ? async_suspend_late+0xe0/0xe0 [ 534.889463] ? async_schedule_node_domain+0x468/0x640 [ 534.889482] dpm_suspend+0x25a/0x3f0 [ 534.889491] ? dpm_suspend_end+0x1a0/0x1a0 [ 534.889497] ? ktime_get+0x214/0x2f0 [ 534.889502] ? lockdep_hardirqs_on+0x79/0x100 [ 534.889509] ? recalibrate_cpu_khz+0x10/0x10 [ 534.889516] ? ktime_get+0x119/0x2f0 [ 534.889528] dpm_suspend_start+0xab/0xc0 [ 534.889538] suspend_devices_and_enter+0x1ca/0x350 [ 534.889546] ? suspend_enter+0x850/0x850 [ 534.889566] enter_state+0x27c/0x3d7 [ 534.889575] pm_suspend.cold+0x42/0x189 [ 534.889583] state_store+0xab/0x160 [ 534.889595] ? sysfs_file_ops+0x160/0x160 [ 534.889601] kernfs_fop_write_iter+0x2b5/0x450 [ 534.889615] new_sync_write+0x36a/0x600 [ 534.889625] ? new_sync_read+0x600/0x600 [ 534.889639] ? rcu_read_unlock+0x40/0x40 [ 534.889668] vfs_write+0x619/0x910 [ 534.889681] ksys_write+0xf4/0x1d0 [ 534.889689] ? __ia32_sys_read+0xa0/0xa0 [ 534.889699] ? lockdep_hardirqs_on_prepare.part.0+0x18c/0x370 [ 534.889707] ? syscall_enter_from_user_mode+0x1d/0x50 [ 534.889719] do_syscall_64+0x3b/0x90 [ 534.889725] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 534.889731] RIP: 0033:0x7f0b9bc931e7 [ 534.889736] Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24 [ 534.889741] RSP: 002b:00007ffd9d34cc88 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 534.889749] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f0b9bc931e7 [ 534.889753] RDX: 0000000000000004 RSI: 0000561cd023c5f0 RDI: 0000000000000004 [ 534.889757] RBP: 0000561cd023c5f0 R08: 0000000000000000 R09: 0000000000000004 [ 534.889761] R10: 0000561ccef842a6 R11: 0000000000000246 R12: 0000000000000004 [ 534.889765] R13: 0000561cd0239590 R14: 00007f0b9bd6f4a0 R15: 00007f0b9bd6e8a0 [ 534.889789] </TASK> [ 534.889796] Allocated by task 2711: [ 534.889800] kasan_save_stack+0x1b/0x40 [ 534.889805] __kasan_kmalloc+0x7c/0x90 [ 534.889810] sta_info_alloc+0x98/0x1ef0 [mac80211] [ 534.889874] ieee80211_prep_connection+0x30b/0x11e0 [mac80211] [ 534.889950] ieee80211_mgd_auth+0x529/0xe00 [mac80211] [ 534.890024] cfg80211_mlme_auth+0x332/0x6f0 [cfg80211] [ 534.890090] nl80211_authenticate+0x839/0xcf0 [cfg80211] [ 534.890147] genl_family_rcv_msg_doit+0x1f4/0x2f0 [ 534.890154] genl_rcv_msg+0x280/0x500 [ 534.890160] netlink_rcv_skb+0x11c/0x340 [ 534.890165] genl_rcv+0x1f/0x30 [ 534.890170] netlink_unicast+0x42b/0x700 [ 534.890176] netlink_sendmsg+0x71b/0xc60 [ 534.890181] sock_sendmsg+0xdf/0x110 [ 534.890187] ____sys_sendmsg+0x5c0/0x850 [ 534.890192] ___sys_sendmsg+0xe4/0x160 [ 534.890197] __sys_sendmsg+0xb2/0x140 [ 534.890202] do_syscall_64+0x3b/0x90 [ 534.890207] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 534.890215] Freed by task 2825: [ 534.890218] kasan_save_stack+0x1b/0x40 [ 534.890223] kasan_set_track+0x1c/0x30 [ 534.890227] kasan_set_free_info+0x20/0x30 [ 534.890232] __kasan_slab_free+0xce/0x100 [ 534.890237] slab_free_freelist_hook+0xf0/0x1a0 [ 534.890242] kfree+0xe5/0x370 [ 534.890248] __sta_info_flush+0x333/0x4b0 [mac80211] [ 534.890308] ieee80211_set_disassoc+0x324/0xd20 [mac80211] [ 534.890382] ieee80211_mgd_deauth+0x537/0xee0 [mac80211] [ 534.890472] cfg80211_mlme_deauth+0x349/0x810 [cfg80211] [ 534.890526] cfg80211_mlme_down+0x1ce/0x270 [cfg80211] [ 534.890578] cfg80211_disconnect+0x4f5/0x7b0 [cfg80211] [ 534.890631] cfg80211_leave+0x24/0x40 [cfg80211] [ 534.890677] wiphy_suspend+0x23d/0x2f0 [cfg80211] [ 534.890723] dpm_run_callback+0xf4/0x1b0 [ 534.890728] __device_suspend+0x648/0x10c0 [ 534.890733] async_suspend+0x16/0xe0 [ 534.890737] async_run_entry_fn+0x90/0x4f0 [ 534.890741] process_one_work+0x866/0x1490 [ 534.890747] worker_thread+0x596/0x1010 [ 534.890751] kthread+0x35d/0x420 [ 534.890756] ret_from_fork+0x22/0x30 [ 534.890763] The buggy address belongs to the object at ffff8881396ba000 which belongs to the cache kmalloc-8k of size 8192 [ 534.890767] The buggy address is located 4536 bytes inside of 8192-byte region [ffff8881396ba000, ffff8881396bc000) [ 534.890772] The buggy address belongs to the page: [ 534.890775] page:ffffea0004e5ae00 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1396b8 [ 534.890780] head:ffffea0004e5ae00 order:3 compound_mapcount:0 compound_pincount:0 [ 534.890784] flags: 0x200000000010200(slab|head|node=0|zone=2) [ 534.890791] raw: 0200000000010200 ffffea000562be08 ffffea0004b04c08 ffff88810004e340 [ 534.890795] raw: 0000000000000000 0000000000010001 00000001ffffffff 0000000000000000 [ 534.890798] page dumped because: kasan: bad access detected [ 534.890804] Memory state around the buggy address: [ 534.890807] ffff8881396bb080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 534.890811] ffff8881396bb100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 534.890814] >ffff8881396bb180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 534.890817] ^ [ 534.890821] ffff8881396bb200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 534.890824] ffff8881396bb280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 534.890827] ================================================================== [ 534.890830] Disabling lock debugging due to kernel taint Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Fixes: b4a0f541 ("ath11k: move peer delete after vdev stop of station for QCA6390 and WCN6855") Signed-off-by:
Wen Gong <quic_wgong@quicinc.com> Signed-off-by:
Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211222070431.29595-1-quic_wgong@quicinc.com
-
P Praneesh authored
LDPC is one the FEC type advertised in msdu_start info2 for HT packet type. Hence, add hardware specific callback for fetching LDPC support from msdu start and enable RX_ENC_FLAG_LDPC flag while passing rx status to mac80211. Tested-on: IPQ8074 WLAN.HK.2.4.0.1-01467-QCAHKSWPL_SILICONZ-1 Signed-off-by:
P Praneesh <quic_ppranees@quicinc.com> Signed-off-by:
-
- 11 Jan, 2022 4 commits
-
-
Karthikeyan Periyasamy authored
When there is an error in peer create process from ath11k_peer_find(), the code attempts to handle a fallback for peer create. When this fallback fails, the driver returns the fallback return code rather than actual error code (-ENOENT). So refactor the fallback routine to return the actual error code. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.5.0.1-01067-QCAHKSWPL_SILICONZ-1 Signed-off-by:
Karthikeyan Periyasamy <periyasa@codeaurora.org> Signed-off-by:
-
Aditya Kumar Singh authored
Currently, ath11k_core_alloc() creates a single thread workqueue. This workqueue is not detroyed during clean up when ath11k modules are unloaded from the kernel and is left as it is. If workqueue is not destroyed, it could lead to kernel memory scarcity in a longer run. This could affect self and other drivers workability as well. Add destroy workqueue in ath11k_core_free(). Tested on: IPQ8074 WLAN.HK.2.4.0.1-01746-QCAHKSWPL_SILICONZ-1 Signed-off-by:
Aditya Kumar Singh <quic_adisi@quicinc.com> Signed-off-by:
-
Wen Gong authored
In function ath10k_wow_convert_8023_to_80211(), it will do memcpy for the new->pattern, and currently the new->pattern and new->mask is same with the old, then the memcpy of new->pattern will also overwrite the old->pattern, because the header format of new->pattern is 802.11, its length is larger than the old->pattern which is 802.3. Then the operation of "Copy frame body" will copy a mistake value because the body memory has been overwrite when memcpy the new->pattern. Assign another empty value to new_pattern to avoid the overwrite issue. Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00049 Fixes: fa3440fa ("ath10k: convert wow pattern from 802.3 to 802.11") Signed-off-by:
-
Yang Yingliang authored
The node pointer is returned by of_find_node_by_type() or of_parse_phandle() with refcount incremented. Calling of_node_put() to aovid the refcount leak. Fixes: 6ac04bdc ("ath11k: Use reserved host DDR addresses from DT for PCI devices") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
-
- 10 Jan, 2022 34 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski authored
Merge in fixes directly in prep for the 5.17 merge window. No conflicts. Signed-off-by:Jakub Kicinski <kuba@kernel.org>
-
Benjamin Yim authored
After this parameter is passed in, there is no usage, and deleting it will not bring any impact. Reviewed-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Benjamin Yim <yan2228598786@gmail.com> Link: https://lore.kernel.org/r/20220109130824.2776-1-yan2228598786@gmail.comSigned-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. So, if dma_set_mask_and_coherent() succeeds, 'pci_using_dac' is known to be 1. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/3011689e8c77d49d7e44509d5a8241320ec408c5.1641754134.git.christophe.jaillet@wanadoo.frSigned-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. So, if dma_set_mask_and_coherent() succeeds, 'pci_using_dac' is known to be 1. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. So, if dma_set_mask_and_coherent() succeeds, 'highdma' is known to be true. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. So, if dma_set_mask_and_coherent() succeeds, 'pci_using_dac' is known to be 1. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. Moreover, dma_set_mask_and_coherent() returns 0 or -EIO, so the return code of the function can be used directly. Finally, inline bnx2x_set_coherency_mask() because it is now only a wrapper for a single dma_set_mask_and_coherent() call. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. Moreover, dma_set_mask_and_coherent() returns 0 or -EIO, so the return code of the function can be used directly. There is no need to 'rc = -EIO' explicitly. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. So if dma_set_mask_and_coherent() succeeds, 'netdev->features' will have NETIF_F_HIGHDMA in all cases. Move the assignment of this feature in be_netdev_init() instead be_probe() which is a much logical place. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. So if dma_set_mask_and_coherent() succeeds, 'dma64' is know to be 'true'. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask will never fail if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. So, if dma_set_mask_and_coherent() succeeds, 'using_dac' is known to be 'true'. This variable can be removed. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask will never fail if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. If dma_set_mask_and_coherent() succeeds, 'ap->pci_using_dac' is known to be 1. So 'pci_using_dac' can be removed from the 'struct ace_private'. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask will never fail if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. If dma_set_mask_and_coherent() succeeds, 'dac_enabled' is known to be 1. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask will never fail if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. So qlcnic_set_dma_mask(), (in qlcnic_main.c) can be simplified a lot and inlined directly in its only caller. If dma_set_mask_and_coherent() succeeds, 'pci_using_dac' is known to be 1. So it can be removed from all the calling chain. qlcnic_setup_netdev() can finally be simplified as-well. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Jakub Kicinski authored
Kees reports quoted commit introduced the following warning on arm64: drivers/net/ethernet/allwinner/sun4i-emac.c:922:60: error: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'resource_size_t' {aka 'long long unsigned int'} [-Werror=format=] 922 | netdev_info(ndev, "get io resource from device: 0x%x, size = %u\n", | ~^ | | | unsigned int | %llx 923 | regs->start, resource_size(regs)); | ~~~~~~~~~~~ | | | resource_size_t {aka long long unsigned int} .. and another one like that for resource_size(). Switch to %pa and a cast. Reported-by:Kees Cook <keescook@chromium.org> Fixes: 47869e82 ("sun4i-emac.c: add dma support") Link: https://lore.kernel.org/r/20220108034438.2227343-1-kuba@kernel.orgSigned-off-by:
-
Yunsheng Lin authored
As page_pool_refill_alloc_cache() is only called by __page_pool_get_cached(), which assumes non-concurrent access as suggested by the comment in __page_pool_get_cached(), and ptr_ring allows concurrent access between consumer and producer, so remove the spinlock in page_pool_refill_alloc_cache(). Signed-off-by:
Yunsheng Lin <linyunsheng@huawei.com> Acked-by:
Jesper Dangaard Brouer <brouer@redhat.com> Link: https://lore.kernel.org/r/20220107090042.13605-1-linyunsheng@huawei.comSigned-off-by:
-
Taehee Yoo authored
amt_send_membership_update() would return -1 but it's return type is bool. So, it should be used TRUE instead of -1. Fixes: cbc21dc1 ("amt: add data plane of amt interface") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Taehee Yoo <ap420073@gmail.com> Link: https://lore.kernel.org/r/20220109163702.6331-1-ap420073@gmail.comSigned-off-by:
-
Pavel Skripkin authored
Syzbot reported uninit value in mcs7830_bind(). The problem was in missing validation check for bytes read via usbnet_read_cmd(). usbnet_read_cmd() internally calls usb_control_msg(), that returns number of bytes read. Code should validate that requested number of bytes was actually read. So, this patch adds missing size validation check inside mcs7830_get_reg() to prevent uninit value bugs Reported-and-tested-by: syzbot+003c0a286b9af5412510@syzkaller.appspotmail.com Fixes: 2a36d708 ("USB: driver for mcs7830 (aka DeLOCK) USB ethernet adapter") Signed-off-by:
Pavel Skripkin <paskripkin@gmail.com> Reviewed-by:
Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20220106225716.7425-1-paskripkin@gmail.comSigned-off-by:
-
Jakub Kicinski authored
Menglong Dong says: ==================== net: skb: introduce kfree_skb_with_reason() In this series patch, the interface kfree_skb_with_reason() is introduced(), which is used to collect skb drop reason, and pass it to 'kfree_skb' tracepoint. Therefor, 'drop_monitor' or eBPF is able to monitor abnormal skb with detail reason. In fact, this series patches are out of the intelligence of David and Steve, I'm just a truck man :/ Previous discussion is here: https://lore.kernel.org/netdev/20211118105752.1d46e990@gandalf.local.home/ https://lore.kernel.org/netdev/67b36bd8-2477-88ac-83a0-35a1eeaf40c9@gmail.com/ In the first patch, kfree_skb_with_reason() is introduced and the 'reason' field is added to 'kfree_skb' tracepoint. In the second patch, 'kfree_skb()' in replaced with 'kfree_skb_with_reason()' in tcp_v4_rcv(). In the third patch, 'kfree_skb_with_reason()' is used in __udp4_lib_rcv(). Changes since v3: - fix some code style problems in skb.h Changes since v2: - rename kfree_skb_with_reason() to kfree_skb_reason() - make kfree_skb() static inline, as Jakub suggested Changes since v1: - rename some drop reason, as David suggested - add the third patch ==================== Link: https://lore.kernel.org/r/20220109063628.526990-1-imagedong@tencent.comSigned-off-by:
-
Menglong Dong authored
Replace kfree_skb() with kfree_skb_reason() in __udp4_lib_rcv. New drop reason 'SKB_DROP_REASON_UDP_CSUM' is added for udp csum error. Signed-off-by:
Menglong Dong <imagedong@tencent.com> Signed-off-by:
-
Menglong Dong authored
Replace kfree_skb() with kfree_skb_reason() in tcp_v4_rcv(). Following drop reasons are added: SKB_DROP_REASON_NO_SOCKET SKB_DROP_REASON_PKT_TOO_SMALL SKB_DROP_REASON_TCP_CSUM SKB_DROP_REASON_TCP_FILTER After this patch, 'kfree_skb' event will print message like this: $ TASK-PID CPU# ||||| TIMESTAMP FUNCTION $ | | | ||||| | | <idle>-0 [000] ..s1. 36.113438: kfree_skb: skbaddr=(____ptrval____) protocol=2048 location=(____ptrval____) reason: NO_SOCKET The reason of skb drop is printed too. Signed-off-by: -
Menglong Dong authored
Introduce the interface kfree_skb_reason(), which is able to pass the reason why the skb is dropped to 'kfree_skb' tracepoint. Add the 'reason' field to 'trace_kfree_skb', therefor user can get more detail information about abnormal skb with 'drop_monitor' or eBPF. All drop reasons are defined in the enum 'skb_drop_reason', and they will be print as string in 'kfree_skb' tracepoint in format of 'reason: XXX'. ( Maybe the reasons should be defined in a uapi header file, so that user space can use them? ) Signed-off-by:
-
Jakub Kicinski authored
Build bot reports: drivers/net/ethernet/mellanox/mlx5/core/en_stats.c: In function 'fec_set_block_stats': drivers/net/ethernet/mellanox/mlx5/core/en_stats.c:1235:48: error: 'outl' undeclared (first use in this function); did you mean 'out'? 1235 | if (mlx5_core_access_reg(mdev, in, sz, outl, sz, MLX5_REG_PPCNT, 0, 0)) | ^~~~ | out Reported-by:Leon Romanovsky <leon@kernel.org> Signed-off-by:
-
Jakub Kicinski authored
Michael Chan says: ==================== bnxt_en: Update for net-next This series adds better error and debug logging for firmware messages. We now also use the firmware provided timeout value for long running commands instead of capping it to 40 seconds. ==================== Link: https://lore.kernel.org/r/1641772485-10421-1-git-send-email-michael.chan@broadcom.comSigned-off-by:
-
Edwin Peer authored
While it has always been possible to infer that an HWRM command was abandoned due to an unhealthy firmware status by the shortened timeout reported, this change improves the log messaging to account for this case explicitly. In the interests of further clarity, the firmware status is now also reported in these new messages. v2: Remove inline keyword for hwrm_wait_must_abort() in .c file. Reviewed-by:
Andy Gospodarek <gospo@broadcom.com> Signed-off-by:
Edwin Peer <edwin.peer@broadcom.com> Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
-
Edwin Peer authored
Some older devices cannot accommodate the 40 seconds timeout cap for long running commands (such as NVRAM commands) due to hardware limitations. Allow these devices to request more time for these long running commands, but print a warning, since the longer timeout may cause the hung task watchdog to trigger. In the case of a firmware update operation, this is preferable to failing outright. v2: Use bp->hwrm_cmd_max_timeout directly without the constants. Fixes: 881d8353 ("bnxt_en: Add an upper bound for all firmware command timeouts.") Signed-off-by:
-
Edwin Peer authored
The current driver design relies on the PF netdev being open in order to intercept the following HWRM commands from a VF: - HWRM_FUNC_VF_CFG - HWRM_CFA_L2_FILTER_ALLOC - HWRM_PORT_PHY_QCFG (only if FW_CAP_LINK_ADMIN is not supported) If the PF is closed, then VFs are subjected to rather inscrutable error messages in response to any configuration requests involving the above command types. Recent firmware distinguishes this problem case from other errors by returning HWRM_ERR_CODE_PF_UNAVAILABLE. In most cases, the appropriate course of action is still to fail, but this can now be accomplished with the aid of more user informative log messages. For L2 filter allocations that are already asynchronous, an automatic retry seems more appropriate. v2: Delete extra newline. Signed-off-by: -
Edwin Peer authored
Add logging of firmware messages. These can be useful for diagnosing issues in the field, but due to their verbosity are only appropriate at a debug message level. Signed-off-by:
-
Nathan Chancellor authored
When building ARCH=arm allmodconfig: drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c: In function ‘iwl_mvm_ftm_rtt_smoothing’: ./include/asm-generic/div64.h:222:35: error: comparison of distinct pointer types lacks a cast [-Werror] 222 | (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \ | ^~ drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c:1070:9: note: in expansion of macro ‘do_div’ 1070 | do_div(rtt_avg, 100); | ^~~~~~ do_div() has to be used with an unsigned 64-bit integer dividend but rtt_avg is a signed 64-bit integer. div_s64() expects a signed 64-bit integer dividend and signed 32-bit divisor, which fits this scenario, so use that function here to fix the warning. Fixes: 8b0f9254 ("iwlwifi: mvm: fix 32-bit build in FTM") Signed-off-by:Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20211227191757.2354329-1-nathan@kernel.orgSigned-off-by:
-
Paul Blakey authored
Netfilter conntrack maintains NAT flags per connection indicating whether NAT was configured for the connection. Openvswitch maintains NAT flags on the per packet flow key ct_state field, indicating whether NAT was actually executed on the packet. When a packet misses from tc to ovs the conntrack NAT flags are set. However, NAT was not necessarily executed on the packet because the connection's state might still be in NEW state. As such, openvswitch wrongly assumes that NAT was executed and sets an incorrect flow key NAT flags. Fix this, by flagging to openvswitch which NAT was actually done in act_ct via tc_skb_ext and tc_skb_cb to the openvswitch module, so the packet flow key NAT flags will be correctly set. Fixes: b57dc7c1 ("net/sched: Introduce action ct") Signed-off-by:
Paul Blakey <paulb@nvidia.com> Acked-by:
Jamal Hadi Salim <jhs@mojatatu.com> Link: https://lore.kernel.org/r/20220106153804.26451-1-paulb@nvidia.comSigned-off-by:
-
