Akihiko Odaki wrote:

On 2025/01/10 17:33, Michael S. Tsirkin wrote:

quoted

On Fri, Jan 10, 2025 at 01:38:06PM +0900, Akihiko Odaki wrote:

quoted

On 2025/01/09 21:46, Willem de Bruijn wrote:

quoted

Akihiko Odaki wrote:

quoted

On 2025/01/09 16:31, Michael S. Tsirkin wrote:

quoted

On Thu, Jan 09, 2025 at 03:58:44PM +0900, Akihiko Odaki wrote:

quoted

tun used to simply advance iov_iter when it needs to pad virtio header,
which leaves the garbage in the buffer as is. This is especially
problematic when tun starts to allow enabling the hash reporting
feature; even if the feature is enabled, the packet may lack a hash
value and may contain a hole in the virtio header because the packet
arrived before the feature gets enabled or does not contain the
header fields to be hashed. If the hole is not filled with zero, it is
impossible to tell if the packet lacks a hash value.

Zero is a valid hash value, so cannot be used as an indication that
hashing is inactive.

Zeroing will initialize the hash_report field to
VIRTIO_NET_HASH_REPORT_NONE, which tells it does not have a hash value.

quoted

quoted

quoted

quoted

In theory, a user of tun can fill the buffer with zero before calling
read() to avoid such a problem, but leaving the garbage in the buffer is
awkward anyway so fill the buffer in tun.

Signed-off-by: Akihiko Odaki <redacted>

But if the user did it, you have just overwritten his value,
did you not?

Yes. but that means the user expects some part of buffer is not filled
after read() or recvmsg(). I'm a bit worried that not filling the buffer
may break assumptions others (especially the filesystem and socket
infrastructures in the kernel) may have.

If this is user memory that is ignored by the kernel, just reflected
back, then there is no need in general to zero it. There are many such
instances, also in msg_control.

More specifically, is there any instance of recvmsg() implementation which
returns N and does not fill the complete N bytes of msg_iter?

The one in tun. It was a silly idea but it has been here for years now.

Except tun. If there is such an example of recvmsg() implementation and 
it is not accidental and people have agreed to keep it functioning, we 
can confidently say this construct is safe without fearing pushback from 
people maintaining filesystem/networking infrastructure. Ultimately I 
want those people decide if this can be supported for the future or not.

It seems preferable to write a value.

Userspace should have not assumption that whatever it writes there
will be reflected unmodified. That said, that is the tiny risk of
changing this in established code.

If it worked without issue so far, without hashing, then probably the
change should only go to net-next.

As said, there are examples in msg_control. I don't immediately have
an example where this is the case in msg_data today. A search for
iov_iter_advance might show something.