I'm back after a short break. Sorry for delay. On Wed, Oct 02, 2024 at 10:27 AM +02, Michal Luczaj wrote: > On 9/27/24 11:15, Jakub Sitnicki wrote: >> On Fri, Sep 27, 2024 at 12:54 AM +02, Michal Luczaj wrote: >>> ... >>> Here's a follow up: my guess is that some checks are missing. I'm not sure >>> if it's the best approach, but this fixes things for me: >> >> So you have already found a bug with a negative test. Nice. >> >> Your patch makes sense to me. > > Great, I'll submit it properly. > > Another thing I've noticed is that unsupported (non-TCP) sk_msg redirects > fail silently, i.e. send() is successful, then packet appears to be > dropped, but because the BPF_SK_MSG_VERDICT program is never run, the > verdict[SK_DROP] isn't updated. Is this by design? That's curious. We don't override the proto::sendmsg callback for protocols which don't support sk_msg redirects, like UDP: https://elixir.bootlin.com/linux/v6.12-rc2/source/net/ipv4/udp_bpf.c#L114 The packet should get delivered to the peer socket as w/o sockmap. I will have to double check that. > Also, for unsupported af_vsock sk_skb-to-ingress we hit the warning: > > [ 233.396654] rx_queue is empty, but rx_bytes is non-zero > [ 233.396702] WARNING: CPU: 11 PID: 40601 at net/vmw_vsock/virtio_transport_common.c:589 virtio_transport_stream_dequeue+0x2e5/0x2f0 > > I'll try to fix that. Now, the series begin to grow long. Should the fixes > come separately? Thanks. And yes - if possible, better to push fixes separately. Because they go through the bpf tree, and they will still land in the upcoming -rc releases (and get backported). While improvements go through bpf-next. Of course that sometimes makes life more difficult if the improvements depend on some fixes... Not sure if anything from bpf-next gets backported if it has a Fixes tag. We can ask the stable kernel maintainers, if needed.
