netdev - Re: [Intel-wired-lan] [PATCH iwl-next] igb: Retrieve Tx timestamp directly from interrupt

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: <20250815164157.jIKm3gdS@linutronix.de>
Date: Fri, 15 Aug 2025 18:41:57 +0200
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Paul Menzel <pmenzel@...gen.mpg.de>
Cc: Kurt Kanzenbach <kurt@...utronix.de>,
	Tony Nguyen <anthony.l.nguyen@...el.com>,
	Przemek Kitszel <przemyslaw.kitszel@...el.com>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Richard Cochran <richardcochran@...il.com>,
	Vinicius Costa Gomes <vinicius.gomes@...el.com>,
	intel-wired-lan@...ts.osuosl.org, netdev@...r.kernel.org
Subject: Re: [Intel-wired-lan] [PATCH iwl-next] igb: Retrieve Tx timestamp
 directly from interrupt

On 2025-08-15 14:54:16 [+0200], Paul Menzel wrote:
> > > Do you have a reproducer for the issue, so others can test.
> > 
> > Yeah, I do have a reproducer:
> > 
> >   - Run ptp4l with 40ms tx timeout (--tx_timestamp_timeout)
> >   - Run periodic RT tasks (e.g. with SCHED_FIFO 1) with run time of
> >     50-100ms per CPU core
> > 
> > This leads to sporadic error messages from ptp4l such as "increasing
> > tx_timestamp_timeout or increasing kworker priority may correct this
> > issue, but a driver bug likely causes it"
> > 
> > However, increasing the kworker priority is not an option, simply
> > because this kworker is doing non-related PTP work items as well.
> > 
> > As the time sync interrupt already signals that the Tx timestamp is
> > available, there's no need to schedule a work item in this case. I might
> > have missed something though. But my testing looked good. The warn_on
> > never triggered.
> 
> Great. Maybe add that too, as, at least for me, realtime stuff is something
> I do not do, so pointers would help me.

If you ask for an explicit reproducer that you would have to have task
that does
	struct sched_param param = { .sched_priority = 1 };
	sched_setscheduler(0, SCHED_FIFO, &param);

and let it run for to exceed the ptp4l timeout. But in general it does
not require a real time task to trigger the problem. A busy CPU with a
lot of pending worker will do the trick, too. You just need "enough" CPU
work so the scheduler puts other tasks on the CPU before the kworker,
which retrieves the timestamp, is scheduled.

> Paul

Sebastian