On 8/17/23 2:46 PM, Alexei Starovoitov wrote:
To avoid other potential optname cases that may run into similar situation and
requires the bpf prog work around it again like the above, it needs a way to
track whether a bpf prog has changed the optval in runtime. If it is not
changed, use the result from the kernel set/getsockopt. If reading/writing to
optval is done through a kfunc, this can be tracked. The kfunc can also directly
read/write the user memory in optval, avoid the pre-alloc kernel memory and the
PAGE_SIZE limit but this is a minor point.
so I'm still not following what sleepable progs that can access everything
would help the existing situation.
I agree that sleepable bpf sockopt should be free from old mistakes,
but people might still write old-style non-sleeptable bpf sockopt and
might repeat the same mistakes.
I'm missing the value of the new interface. It's better, sure, but why?
Do we expect to rewrite existing sockopt progs in sleepable way?
It might not be easy due to sleepable limitations like maps and whatever else.
so far our sockopt progs only uses sk local storage that can support sleepable
and we can all move to the sleepable way to avoid any future quirk.
Agree that others may have sockopt prog that has hard dependency on
non-sleepable. If the existing non-sleepable and sleepable inter-leaved
together, it would end up hitting similar issue.
Lets drop the idea of this set.
