On 2024-01-16 05:49, Paolo Abeni wrote:On Thu, 2024-01-11 at 18:00 -0500, jmaloy(a)redhat.com wrote: > From: Jon Maloy <jmaloy(a)redhat.com> > > When reading received messages from a socket with MSG_PEEK, we may want > to read the contents with an offset, like we can do with pread/preadv() > when reading files. Currently, it is not possible to do that.[...]I would expect doing the same thing with a different protocol to cause an EFAULT, as it should. But I haven't tried it. This is a change to TCP only, at least until somebody decides to implement it elsewhere (why not?)+ err = -EINVAL; + goto out; + } + peek_offset = msg->msg_iter.__iov[0].iov_len; + msg->msg_iter.__iov = &msg->msg_iter.__iov[1]; + msg->msg_iter.nr_segs -= 1; + msg->msg_iter.count -= peek_offset; + len -= peek_offset; + *seq += peek_offset; + }IMHO this does not look like the correct interface to expose such functionality. Doing the same with a different protocol should cause a SIGSEG or the like, right?What about using/implementing SO_PEEK_OFF support instead?I looked at SO_PEEK_OFF, and it honestly looks both awkward and limited. We would have to make frequent calls to setsockopt(), something that would beat much of the purpose of this feature. I stand by my opinion here. This feature is simple, non-intrusive, totally backwards compatible and implies no changes to the API or BPI. I would love to hear other opinions on this, though. Regards /jonCheers, Paolo