> > > >> > > > >> For datagrams (UDP as well as RAW and many non IP protocols), an > > > >> alternative still needs to be found. > > > > > > In udp/raw/..., I don't know how likely is the user space having "cork->tx_flags > > > & SKBTX_ANY_TSTAMP" set but has neither "READ_ONCE(sk->sk_tsflags) & > > > SOF_TIMESTAMPING_OPT_ID" nor "cork->flags & IPCORK_TS_OPT_ID" set. > > > > This is not something to rely on. OPT_ID was added relatively recently. > > Older applications, or any that just use the most straightforward API, > > will not set this. > > > > > If it is > > > unlikely, may be we can just disallow bpf prog from directly setting > > > skb_shinfo(skb)->tskey for this particular skb. > > > > > > For all other cases, in __ip[6]_append_data, directly call a bpf prog and also > > > pass the kernel decided tskey to the bpf prog. > > > > > > The kernel passed tskey could be 0 (meaning the user space has not used it). The > > > bpf prog can give one for the kernel to use. The bpf prog can store the > > > sk_tskey_bpf in the bpf_sk_storage now. Meaning no need to add one to the struct > > > sock. The bpf prog does not have to start from 0 (e.g. start from U32_MAX > > > instead) if it helps. > > > > > > If the kernel passed tskey is not 0, the bpf prog can just use that one > > > (assuming the user space is doing something sane, like the value in > > > SCM_TS_OPT_ID won't be jumping back and front between 0 to U32_MAX). I hope this > > > is very unlikely also (?) but the bpf prog can probably detect this and choose > > > to ignore this sk. > > > > If an applications uses OPT_ID, it is unlikely that they will toggle > > the feature on and off on a per-packet basis. So in the common case > > the program could use the user-set counter or use its own if userspace > > does not enable the feature. In the rare case that an application does > > intermittently set an OPT_ID, the numbering would be erratic. This > > does mean that an actively malicious application could mess with admin > > measurements. > > > > Sorry, I got lost in this part. What would you recommend I should do > about OPT_ID in the next move? Should I keep those three OPT_ID > patches? I did not offer a suggestion. Just pointed out a constraint.
