On 4/26/23 10:27 AM, Stanislav Fomichev wrote:
As per above, I'll stick a line to the dmest (similar
bpf_warn_invalid_xdp_action), at least to record that this has
happened once.
LMK if you or Danial still don't see a value in printing this..
pr_info_once? hmm... I think it is ok-ish. At least not a warning.
I think almost all of the time the bpf prog forgets to set it to 0 for the long
optval that it has no interest in. However, to suppress this pr_info_once,
setting optlen to 0 will disable the following cgroup-bpf prog from using the
optval as read-only. The case that the printk that may flag is that the bpf prog
did indeed want to change the long optval?
The case we want to printk is where the prog changes some byte in the
first 4k range of the optval and does not touch optlen (or maybe
adjusts optlen to be >PAGE_SIZE and <original_optlen).
I agree that it feels super corner-casy; but it feels like without
some kind of hint, it would be impossible to figure out why it doesn't
work. Or am I overblowing it?
I don't have a better idea how to flag this 'changing the first few bytes of a
long optval is not supported' either. I guess pr_info_once is ok-ish for now to
stop the bleeding in the most common case.
If it can separate the original_optlen > PAGE_SIZE case (ignore and no -EFAULT),
the message probably needs to be less alarming. "bpf setsockopt returned
unexpected optlen" may cause confusion when the bpf prog did not touch the
optval and optlen.
Hopefully this pr_info_once will disappear when the cgroup-bpf prog can directly
read/write the optval without pre-allocation.
