netdev - 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] [day] [month] [year] [list]

Message-ID: <a22f6805-a92b-43b6-8029-6b467f7f4b36@intel.com>
Date: Thu, 5 Feb 2026 16:05:50 -0800
From: Jacob Keller <jacob.e.keller@...el.com>
To: "Loktionov, Aleksandr" <aleksandr.loktionov@...el.com>, 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>, 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 2/5/2026 4:20 AM, Loktionov, Aleksandr wrote:
> 
> 
>> -----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.
> 

My understanding is that RT is only safe to convert such spinlock_t to 
mutex *because* it also converts IRQs to threads.