Re: [PATCH net v6] usbnet: fix smp_processor_id() use in preemptible context

[Jakub Kicinski]

On Mon,  5 Oct 2026 00:59:25 +0300 Ömer Mete Kaya wrote:
> tx_complete() calls this_cpu_ptr() before disabling preemption, which
> triggers a BUG when running with CONFIG_DEBUG_PREEMPT:
> 
>   BUG: using smp_processor_id() in preemptible code in tx_complete
> 
> Fix by using get_cpu_ptr()/put_cpu_ptr() which disable preemption and
> return the per-CPU pointer atomically. The usbnet_skb_return() hunk
> is a hardening change: that path runs in softirq context so no warning
> fires there, but the same fix is applied for consistency.

This looks odd, how did we miss this for 8 years.

Greg is probably busy, but would be good to get a confirmation
from either him or some other USB expert that the callbacks
can indeed be called in process context.

FWIW stack trace from syzbot

 <TASK>
 check_preemption_disabled+0xd8/0xe0 lib/smp_processor_id.c:47
 tx_complete+0x237/0x770 drivers/net/usb/usbnet.c:1301
 __usb_hcd_giveback_urb+0x38d/0x610 drivers/usb/core/hcd.c:1657
 usb_hcd_giveback_urb+0x3ca/0x4a0 drivers/usb/core/hcd.c:1741
 vhci_recv_ret_submit drivers/usb/usbip/vhci_rx.c:107 [inline]
 vhci_rx_pdu drivers/usb/usbip/vhci_rx.c:242 [inline]
 vhci_rx_loop+0x60e/0xa60 drivers/usb/usbip/vhci_rx.c:265
 kthread+0x370/0x450 kernel/kthread.c:436
 ret_from_fork+0x72b/0xd50 arch/x86/kernel/process.c:158