linux-kernel - RE: [Intel-wired-lan] [PATCH iwl-next v3] igb: Retrieve Tx timestamp directly from interrupt for i210

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <IA3PR11MB898682AE39689F854F3BA178E599A@IA3PR11MB8986.namprd11.prod.outlook.com>
Date: Thu, 5 Feb 2026 12:20:11 +0000
From: "Loktionov, Aleksandr" <aleksandr.loktionov@...el.com>
To: Kurt Kanzenbach <kurt@...utronix.de>, "Nguyen, Anthony L"
	<anthony.l.nguyen@...el.com>, "Kitszel, Przemyslaw"
	<przemyslaw.kitszel@...el.com>
CC: Paul Menzel <pmenzel@...gen.mpg.de>, Vadim Fedorenko
	<vadim.fedorenko@...ux.dev>, "Gomes, Vinicius" <vinicius.gomes@...el.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>, Richard Cochran
	<richardcochran@...il.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, Andrew Lunn <andrew+netdev@...n.ch>, "Eric
 Dumazet" <edumazet@...gle.com>, "intel-wired-lan@...ts.osuosl.org"
	<intel-wired-lan@...ts.osuosl.org>, "Keller, Jacob E"
	<jacob.e.keller@...el.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
	<pabeni@...hat.com>, "David S. Miller" <davem@...emloft.net>, "Sebastian
 Andrzej Siewior" <bigeasy@...utronix.de>
Subject: RE: [Intel-wired-lan] [PATCH iwl-next v3] igb: Retrieve Tx timestamp
 directly from interrupt for i210



> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@...osl.org> On Behalf
> Of Kurt Kanzenbach
> Sent: Thursday, February 5, 2026 12:58 PM
> To: Loktionov, Aleksandr <aleksandr.loktionov@...el.com>; Nguyen,
> Anthony L <anthony.l.nguyen@...el.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@...el.com>
> Cc: Paul Menzel <pmenzel@...gen.mpg.de>; Vadim Fedorenko
> <vadim.fedorenko@...ux.dev>; Gomes, Vinicius
> <vinicius.gomes@...el.com>; netdev@...r.kernel.org; Richard Cochran
> <richardcochran@...il.com>; linux-kernel@...r.kernel.org; Andrew Lunn
> <andrew+netdev@...n.ch>; Eric Dumazet <edumazet@...gle.com>; intel-
> wired-lan@...ts.osuosl.org; Keller, Jacob E
> <jacob.e.keller@...el.com>; Jakub Kicinski <kuba@...nel.org>; Paolo
> Abeni <pabeni@...hat.com>; David S. Miller <davem@...emloft.net>;
> Sebastian Andrzej Siewior <bigeasy@...utronix.de>
> Subject: Re: [Intel-wired-lan] [PATCH iwl-next v3] igb: Retrieve Tx
> timestamp directly from interrupt for i210
> 
> On Thu Feb 05 2026, Loktionov, Aleksandr wrote:
> >> +/**
> >> + * igb_ptp_tx_tstamp_event
> >> + * @adapter: pointer to igb adapter
> >> + *
> >> + * This function checks the TSYNCTXCTL valid bit and stores the Tx
> >> +hardware
> >> + * timestamp at the current skb.
> >> + **/
> >> +void igb_ptp_tx_tstamp_event(struct igb_adapter *adapter) {
> >> +	struct e1000_hw *hw = &adapter->hw;
> >> +	u32 tsynctxctl;
> >> +
> >> +	if (!adapter->ptp_tx_skb)
> >> +		return;
> >> +
> >> +	tsynctxctl = rd32(E1000_TSYNCTXCTL);
> >> +	if (WARN_ON_ONCE(!(tsynctxctl & E1000_TSYNCTXCTL_VALID)))
> >> +		return;
> >> +
> >> +	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?
> 
> AFAICS skb_tstamp_tx() is safe to call here.
> 
> > spin_lock_irqsave(&wq_head->lock, flags);  <- RT mutex can sleep
> 
> In case you're worried about PREEMPT_RT: On -RT the IRQ runs a
> dedicated thread. BTW I've tested this with and without -RT and with
> CONFIG_DEBUG_ATOMIC_SLEEP.
> 
> Thanks,
> Kurt

Thank you, Kurt for sharing your experience. I don't have so many experience with RT Linux.
For me calling a function, not designed to be called from IRQ context is a SUS.
So, I rose the question about sleeping.

But there is also a question about non-RT Kernels with Shared IRQ Vectors...
I.e. regular packet processing (NAPI poll in softirq) and PTP timestamp events (in hardirq).

I suspect we have potentially broken drivers with shared vectors (MSI-X should be safe I hope).

I'd like the comment to be added:
/* Safe to call from IRQ: dedicated misc vector + RT-safe on PREEMPT_RT */
igb_ptp_tx_hwtstamp(adapter);

But in long term perspective prefer to refactor moving to NAPI is the safer, more maintainable pattern.

What do you think?
Alex