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  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]
Date:   Tue, 21 Jul 2020 10:16:32 -0700
From:   Jacob Keller <>
To:     Vladimir Oltean <>
Subject: Re: [PATCH net-next 3/3] docs: networking: timestamping: add a set of
 frequently asked questions

On 7/20/2020 3:13 PM, Vladimir Oltean wrote:>
> Yes, indeed, a lot of them are exclusively checking
> "skb_shinfo(skb)->tx_flags & SKBTX_IN_PROGRESS", without any further
> verification that they have hardware timestamping enabled in the first
> place, a lot more than I remembered. Some of the occurrences are
> actually new.
> I think at least part of the reason why this keeps going on is that
> there aren't any hard and fast rules that say you shouldn't do it. When
> there isn't even a convincing percentage of DSA/PHY drivers that do set
> SKBTX_HW_TSTAMP, the chances are pretty low that you'll get a stacked
> PHC driver that sets the flag, plus a MAC driver that checks for it
> incorrectly. So people tend to ignore this case. Even though, if stacked
> DSA drivers started supporting software TX timestamping (which is not
> unlikely, given the fact that this would also give you compatibility
> with PHY timestamping), I'm sure things would change, because more
> people would become aware of the issue once mv88e6xxx starts getting
> affected.
> What I've been trying to do is at least try to get people (especially
> people who have a lot of XP with 1588 drivers) to agree on a common set
> of guidelines that are explicitly written down. I think that's step #1.
> -Vladimir

Right. I think the guideline should be:

This flag indicates to the stack whether or not a hardware Tx timestamp
has been started. It's primary purpose is to prevent sending software
timestamps if a hw timestamp is provided.

1) set the flag whenever you start a tx timestamp

2) do not assume you are the only driver that will set the flag for a
given skb. Use a separate mechanism to decide if that skb is supposed to
have a timestamp.

Powered by blists - more mailing lists