From: Michal Luczaj <redacted>
Date: Wed, 26 Jun 2024 12:48:27 +0200

On 6/23/24 07:19, Kuniyuki Iwashima wrote:

quoted

From: Michal Luczaj <redacted>
Date: Sun, 23 Jun 2024 00:43:27 +0200

quoted

I gotta ask, is there a reason for unlinking an already consumed
('consumed' as in 'unix_skb_len(skb) == 0') skb so late, in manage_oob()?
IOW, can't it be unlinked immediately once it's consumed in
unix_stream_recv_urg()? I suppose that would simplify things.

I also thought that before, but we can't do that.

Even after reading OOB data, we need to remember the position
and break recv() at that point.  That's why the skb is unlinked
in manage_oob() rather than unix_stream_recv_urg().

Ahh, I see. Thanks for explaining.

One more thing about unix sockmap. AF_UNIX SOCK_DGRAM supports 0-length
packets. But sockmap doesn't handle that; once a 0-length skb/msg is in the
psock queue, unix_bpf_recvmsg() starts throwing -EFAULT. Sockmap'ed AF_INET
SOCK_DGRAM does the same, so is this a bug or a feature?

I guess it's kind of safeguard.

The retval 0 has special meaning for SOCK_STREAM as EOF/shutdown().
If we bypass 0-byte dgram to SOCK_STREAM sk, the application will be
confused as if the original peer has disconnected.

At least, -EFAULT avoids such confusion so that can only the true
peer trigger 0-byte via the saved ->recvmsg().

So, the requirement would be similar to scm handling, we need to
recognize the sockmap verdict and destination to support full
features.