[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a0COfvLvnL7WCZY6xp+y=gKhm_RakUJbR9DSbzjit3pGQ@mail.gmail.com>
Date: Wed, 6 Oct 2021 09:59:59 +0200
From: Arnd Bergmann <arnd@...db.de>
To: Richard Palethorpe <rpalethorpe@...e.com>
Cc: Arnd Bergmann <arnd@...db.de>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Stefano Garzarella <sgarzare@...hat.com>,
Arseny Krasnov <arseny.krasnov@...persky.com>,
Colin Ian King <colin.king@...onical.com>,
Norbert Slusarek <nslusarek@....net>,
Andra Paraschiv <andraprs@...zon.com>,
Deepa Dinamani <deepa.kernel@...il.com>,
Willem de Bruijn <willemb@...gle.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Networking <netdev@...r.kernel.org>, rpalethorpe@...hiejp.com
Subject: Re: [PATCH] vsock: Handle compat 32-bit timeout
On Wed, Oct 6, 2021 at 9:48 AM Richard Palethorpe <rpalethorpe@...e.com> wrote:
>
> Allow 32-bit timevals to be used with a 64-bit kernel.
>
> This allows the LTP regression test vsock01 to run without
> modification in 32-bit compat mode.
>
> Fixes: fe0c72f3db11 ("socket: move compat timeout handling into sock.c")
> Signed-off-by: Richard Palethorpe <rpalethorpe@...e.com>
>
> ---
>
> This is one of those fixes where I am not sure if we should just
> change the test instead. Because it's not clear if someone is likely
> to use vsock's in 32-bit compat mode?
We try very hard to ensure that compat mode works for every interface,
so it should be fixed in the kernel. Running compat mode is common
on memory-restricted machines, e.g. on cloud platforms and on deeply
embedded systems.
However, I think fixing the SO_VM_SOCKETS_CONNECT_TIMEOUT
to support 64-bit timeouts would actually be more important here. I think
what you need to do is to define the macro the same way
as the SO_TIMESTAMP one:
#define SO_RCVTIMEO (sizeof(time_t) == sizeof(__kernel_long_t) ? \
SO_RCVTIMEO_OLD : SO_RCVTIMEO_NEW)
#define SO_TIMESTAMP (sizeof(time_t) == sizeof(__kernel_long_t) ? \
SO_TIMESTAMP_OLD : SO_TIMESTAMP_NEW)
...
to ensure that user space picks an interface that matches the
user space definition of 'struct timeval'.
Your change looks correct otherwise, but I think you should first
add the new interface for 64-bit timeouts, since that likely changes
the code in a way that makes your current patch no longer the
best way to write it.
Arnd
Powered by blists - more mailing lists