Vadim Fedorenko wrote: > On 05.02.2026 21:41, Willem de Bruijn wrote: > > Vadim Fedorenko wrote: > >> On 05/02/2026 16:43, Sebastian Andrzej Siewior wrote: > >>> On 2026-02-05 16:27:03 [+0000], Vadim Fedorenko wrote: > >>>>> So the only thing that bothers me is the read_lock_bh() in > >>>>> skb_may_tx_timestamp() which deadlocks if the socket is write-locked on > >>>>> the same CPU. > >>>> > >>>> Alright. Now you make me think whether we should enforce OPT_TSONLY > >>>> option on socket which doesn't have CAP_NET_RAW? Then we can get rid of > >>>> this > >>>> check, and in case sysctl was flipped off - drop TX timestamps as > >>>> it's done now? > >>> > >>> This would "fix" this problem for all users which do deliver the > >>> timestamp from their IRQ handler instead of napi. There are a few of > >>> those… > >>> This would be considered stable material, right? (despite the fact that > >>> we have it for quite some time and nobody complained so far). > >> > >> cc: Willem as he is the author of the check introduced back in 2015. > >> > >> But it's more like a question to maintainers whether it is acceptable > >> way of "fixing" drivers or it's no-go solution > > > > Requiring OPT_TSONLY unless CAP_NET_RAW would break legacy users. > > Well, they are kinda broken already. Without OPT_TSONLY and CAP_NET_RAW all TX > timestamps are silently dropped.
Are you referring to sysctl_tstamp_allow_data? That is enabled by default. > To receive these timestamps users have to get > CAP_NET_RAW permission, and it will work with the updated logic as well...
