On 05/02/2026 10:37, Loktionov, Aleksandr wrote:
-----Original Message-----
From: Sebastian Andrzej Siewior <[email protected]>
Sent: Thursday, February 5, 2026 11:04 AM
To: Loktionov, Aleksandr <[email protected]>
Cc: Kurt Kanzenbach <[email protected]>; Nguyen, Anthony L
<[email protected]>; Kitszel, Przemyslaw
<[email protected]>; Paul Menzel <[email protected]>;
Vadim Fedorenko <[email protected]>; Gomes, Vinicius
<[email protected]>; [email protected]; Richard Cochran
<[email protected]>; [email protected]; Andrew Lunn
<[email protected]>; Eric Dumazet <[email protected]>; intel-
[email protected]; Keller, Jacob E
<[email protected]>; Jakub Kicinski <[email protected]>; Paolo
Abeni <[email protected]>; David S. Miller <[email protected]>
Subject: Re: RE: [Intel-wired-lan] [PATCH iwl-next v3] igb: Retrieve
Tx timestamp directly from interrupt for i210
On 2026-02-05 09:47:14 [+0000], Loktionov, Aleksandr wrote:
…
--- a/drivers/net/ethernet/intel/igb/igb_ptp.c
+++ b/drivers/net/ethernet/intel/igb/igb_ptp.c
@@ -796,6 +796,28 @@ static int igb_ptp_verify_pin(struct
…
+ igb_ptp_tx_hwtstamp(adapter); <-Calls existing function
designed for work queue!
skb_tstamp_tx() can sleep
Smells like sleep-in-atomic isn't it?
How or where can it sleep?
Sebastian
igb_ptp_tx_hwtstamp() -> https://elixir.bootlin.com/linux/v6.19-rc5/C/ident/skb_tstamp_tx
-> https://elixir.bootlin.com/linux/v6.19-rc5/C/ident/__skb_complete_tx_timestamp ->
https://elixir.bootlin.com/linux/v6.19-rc5/C/ident/sock_queue_err_skb ->
https://elixir.bootlin.com/linux/v6.19-rc5/C/ident/skb_queue_tail ->
https://elixir.bootlin.com/linux/v6.19-rc5/source/net/core/skbuff.c#L4075
spin_lock_irqsave(&wq_head->lock, flags); <- RT mutex can sleep
Hmm... that actually means we have some drivers broken for RT kernels if
they are processing TX timestamps within a single irq vector:
- hisilicon/hns3
- intel/i40e (and ice probably)
- marvell/mvpp2
For igb/igc/i40e it's still OK to process TX timestamps directly in
MSI-X configuration, as ring processing has separate vector, right?
But in general skb_tstamp_tx should be moved to BH processing (NAPI poll
callback).
