Re: [PATCH v3 bpf-next 03/11] bpf: tcp: Support bpf_skb_load_bytes() for BPF_SOCK_OPS_RCVQ_CB.

[Martin KaFai Lau <martin.lau@linux.dev>]

On Wed, May 27, 2026 at 02:39:20PM -0700, Kuniyuki Iwashima wrote:
> > > Could you show me what to do next? Thanks in advance. It sounds like
> > > the tx side of bpf timestamping should be adjusted accordingly?
> >
> > imo, the bpf_tcp_ops can land first. and then add net timestamping
> > ops (existing tx and the new rx) in bpf_sock_ops.
> 
> Sounds good to me.  I'll rebase TCP AutoLOWAT feature on top
> of the struct_ops series.

Thanks.

The ops in bpf_tcp_ops do not have a skb arg yet.
A few lines similar to bpf_qdisc_is_valid_access() in bpf_qdisc.c
are needed. I recall it works around btf_ctx_access(). We can
probably clean it up in the future, which should be generic
enough for all struct_ops taking a skb.

I believe the "if (prog->aux->st_ops != &bpf_Qdisc_ops)" check in
bpf_qdisc_kfunc_filter() may get in the way. bpf_dynptr_from_skb
kfunc should not be limited to the bpf_qdisc struct_ops. I think
the net subsystem should allow bpf_dynptr_from_skb as the basic
kfunc for all struct_ops programs as long as skb is a trusted pointer.
You should be able to work around it for now by tweaking bpf_qdisc_kfunc_filter.
The struct_ops program will only have read-only access to the skb
through bpf_dynptr_*() kfuncs.

The struct_ops series will need to address some issues (excluding
the pre-existing ones in cgroup.c) pointed out by Sashiko.
Amery is kind enough to help me figure out how to resolve it
and then respin.