mbox series

[RFC,v1,0/4] virtio/vsock: some updates for MSG_PEEK flag

Message ID 20230618062451.79980-1-AVKrasnov@sberdevices.ru (mailing list archive)
Headers show
Series virtio/vsock: some updates for MSG_PEEK flag | expand

Message

Arseniy Krasnov June 18, 2023, 6:24 a.m. UTC
Hello,

This patchset does several things around MSG_PEEK flag support. In
general words it reworks MSG_PEEK test and adds support for this flag
in SOCK_SEQPACKET logic. Here is per-patch description:

1) This is cosmetic change for SOCK_STREAM implementation of MSG_PEEK:
   1) I think there is no need of "safe" mode walk here as there is no
      "unlink" of skbs inside loop (it is MSG_PEEK mode - we don't change
      queue).
   2) Nested while loop is removed: in case of MSG_PEEK we just walk
      over skbs and copy data from each one. I guess this nested loop
      even didn't behave as loop - it always executed just for single
      iteration.

2) This adds MSG_PEEK support for SOCK_SEQPACKET. It could be implemented
   be reworking MSG_PEEK callback for SOCK_STREAM to support SOCK_SEQPACKET
   also, but I think it will be more simple and clear from potential
   bugs to implemented it as separate function thus not mixing logics
   for both types of socket. So I've added it as dedicated function.

3) This is reworked MSG_PEEK test for SOCK_STREAM. Previous version just
   sent single byte, then tried to read it with MSG_PEEK flag, then read
   it in normal way. New version is more complex: now sender uses buffer
   instead of single byte and this buffer is initialized with random
   values. Receiver tests several things:
   1) Read empty socket with MSG_PEEK flag.
   2) Read part of buffer with MSG_PEEK flag.
   3) Read whole buffer with MSG_PEEK flag, then checks that it is same
      as buffer from 2) (limited by size of buffer from 2) of course).
   4) Read whole buffer without any flags, then checks that is is same
      as buffer from 3).

4) This is MSG_PEEK test for SOCK_SEQPACKET. It works in the same way
   as for SOCK_STREAM, except it also checks combination of MSG_TRUNC
   and MSG_PEEK.

Head is:
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=d20dd0ea14072e8a90ff864b2c1603bd68920b4b

Arseniy Krasnov (4):
  virtio/vsock: rework MSG_PEEK for SOCK_STREAM
  virtio/vsock: support MSG_PEEK for SOCK_SEQPACKET
  vsock/test: rework MSG_PEEK test for SOCK_STREAM
  vsock/test: MSG_PEEK test for SOCK_SEQPACKET

 net/vmw_vsock/virtio_transport_common.c | 104 +++++++++++++++-----
 tools/testing/vsock/vsock_test.c        | 124 ++++++++++++++++++++++--
 2 files changed, 196 insertions(+), 32 deletions(-)

Comments

Stefano Garzarella June 26, 2023, 4:30 p.m. UTC | #1
On Sun, Jun 18, 2023 at 09:24:47AM +0300, Arseniy Krasnov wrote:
>Hello,
>
>This patchset does several things around MSG_PEEK flag support. In
>general words it reworks MSG_PEEK test and adds support for this flag
>in SOCK_SEQPACKET logic. Here is per-patch description:
>
>1) This is cosmetic change for SOCK_STREAM implementation of MSG_PEEK:
>   1) I think there is no need of "safe" mode walk here as there is no
>      "unlink" of skbs inside loop (it is MSG_PEEK mode - we don't change
>      queue).
>   2) Nested while loop is removed: in case of MSG_PEEK we just walk
>      over skbs and copy data from each one. I guess this nested loop
>      even didn't behave as loop - it always executed just for single
>      iteration.
>
>2) This adds MSG_PEEK support for SOCK_SEQPACKET. It could be implemented
>   be reworking MSG_PEEK callback for SOCK_STREAM to support SOCK_SEQPACKET
>   also, but I think it will be more simple and clear from potential
>   bugs to implemented it as separate function thus not mixing logics
>   for both types of socket. So I've added it as dedicated function.
>
>3) This is reworked MSG_PEEK test for SOCK_STREAM. Previous version just
>   sent single byte, then tried to read it with MSG_PEEK flag, then read
>   it in normal way. New version is more complex: now sender uses buffer
>   instead of single byte and this buffer is initialized with random
>   values. Receiver tests several things:
>   1) Read empty socket with MSG_PEEK flag.
>   2) Read part of buffer with MSG_PEEK flag.
>   3) Read whole buffer with MSG_PEEK flag, then checks that it is same
>      as buffer from 2) (limited by size of buffer from 2) of course).
>   4) Read whole buffer without any flags, then checks that is is same
>      as buffer from 3).
>
>4) This is MSG_PEEK test for SOCK_SEQPACKET. It works in the same way
>   as for SOCK_STREAM, except it also checks combination of MSG_TRUNC
>   and MSG_PEEK.
>
>Head is:
>https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=d20dd0ea14072e8a90ff864b2c1603bd68920b4b

Nice cleanup, LGTM, but I'd like a comment from Bobby.

Thanks,
Stefano
Arseniy Krasnov June 27, 2023, 11:58 a.m. UTC | #2
On 26.06.2023 19:30, Stefano Garzarella wrote:
> On Sun, Jun 18, 2023 at 09:24:47AM +0300, Arseniy Krasnov wrote:
>> Hello,
>>
>> This patchset does several things around MSG_PEEK flag support. In
>> general words it reworks MSG_PEEK test and adds support for this flag
>> in SOCK_SEQPACKET logic. Here is per-patch description:
>>
>> 1) This is cosmetic change for SOCK_STREAM implementation of MSG_PEEK:
>>   1) I think there is no need of "safe" mode walk here as there is no
>>      "unlink" of skbs inside loop (it is MSG_PEEK mode - we don't change
>>      queue).
>>   2) Nested while loop is removed: in case of MSG_PEEK we just walk
>>      over skbs and copy data from each one. I guess this nested loop
>>      even didn't behave as loop - it always executed just for single
>>      iteration.
>>
>> 2) This adds MSG_PEEK support for SOCK_SEQPACKET. It could be implemented
>>   be reworking MSG_PEEK callback for SOCK_STREAM to support SOCK_SEQPACKET
>>   also, but I think it will be more simple and clear from potential
>>   bugs to implemented it as separate function thus not mixing logics
>>   for both types of socket. So I've added it as dedicated function.
>>
>> 3) This is reworked MSG_PEEK test for SOCK_STREAM. Previous version just
>>   sent single byte, then tried to read it with MSG_PEEK flag, then read
>>   it in normal way. New version is more complex: now sender uses buffer
>>   instead of single byte and this buffer is initialized with random
>>   values. Receiver tests several things:
>>   1) Read empty socket with MSG_PEEK flag.
>>   2) Read part of buffer with MSG_PEEK flag.
>>   3) Read whole buffer with MSG_PEEK flag, then checks that it is same
>>      as buffer from 2) (limited by size of buffer from 2) of course).
>>   4) Read whole buffer without any flags, then checks that is is same
>>      as buffer from 3).
>>
>> 4) This is MSG_PEEK test for SOCK_SEQPACKET. It works in the same way
>>   as for SOCK_STREAM, except it also checks combination of MSG_TRUNC
>>   and MSG_PEEK.
>>
>> Head is:
>> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=d20dd0ea14072e8a90ff864b2c1603bd68920b4b
> 
> Nice cleanup, LGTM, but I'd like a comment from Bobby.

Got it, thanks!

Thanks, Arseniy

> 
> Thanks,
> Stefano
>