From: Konstantin Shkolnyy <kshk@linux.ibm.com>
To: Stefano Garzarella <sgarzare@redhat.com>
Cc: virtualization@lists.linux.dev, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, mjrosato@linux.ibm.com
Subject: Re: [PATCH v4 2/2] vsock/test: fix parameter types in SO_VM_SOCKETS_* calls
Date: Thu, 31 Oct 2024 11:04:06 -0500 [thread overview]
Message-ID: <9accb7aa-d440-40dd-aee9-10b334b0a087@linux.ibm.com> (raw)
In-Reply-To: <7o2b3ggh7ojcoiyh5dcgu5y6436tqjarvmvavxmbm2id3fggdu@46rhdjnyqdpr>
On 10/31/2024 09:16, Stefano Garzarella wrote:
> On Tue, Oct 29, 2024 at 09:49:54AM -0500, Konstantin Shkolnyy wrote:
>> Change parameters of SO_VM_SOCKETS_* to uint64_t so that they are always
>
> In include/uapi/linux/vm_sockets.h we talk about "unsigned long long",
> but in the kernel code we use u64. IIUC "unsigned long long" should be
> u64 on every architecture, at least till we will have some 128-bit cpu,
> right?
I'm not sure what "unsigned long long" would be on a 128-bit machine.
> What about using `unsigned long long` as documented in the vm_sockets.h?
I use uint64_t because the kernel uses u64. I think, this way the code
isn't vulnerable to potential variability of "unsigned long long".
If we change to "unsigned long long" should we also change the kernel
to "unsigned long long"?
next prev parent reply other threads:[~2024-10-31 16:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-29 14:49 [PATCH v4 0/2] vsock/test: fix wrong setsockopt() parameters Konstantin Shkolnyy
2024-10-29 14:49 ` [PATCH v4 1/2] vsock/test: fix failures due to wrong SO_RCVLOWAT parameter Konstantin Shkolnyy
2024-10-29 14:49 ` [PATCH v4 2/2] vsock/test: fix parameter types in SO_VM_SOCKETS_* calls Konstantin Shkolnyy
2024-10-31 14:16 ` Stefano Garzarella
2024-10-31 16:04 ` Konstantin Shkolnyy [this message]
2024-11-04 10:30 ` Stefano Garzarella
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9accb7aa-d440-40dd-aee9-10b334b0a087@linux.ibm.com \
--to=kshk@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mjrosato@linux.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=sgarzare@redhat.com \
--cc=virtualization@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox