All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: johannst <johannes.stoelp@googlemail.com>
Cc: QEMU Trivial <qemu-trivial@nongnu.org>,
	johannst <johannes.stoelp@gmail.com>,
	Eric Blake <eblake@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [PATCH v0] kvm: unsigned datatype in ioctl wrapper
Date: Sun, 29 Aug 2021 22:09:19 +0100	[thread overview]
Message-ID: <CAFEAcA8TRQdj33Ycm=XzmuUUNApaXVgeDexfS+3Ycg6kLnpmyg@mail.gmail.com> (raw)
In-Reply-To: <20210805193950.514357-1-johannes.stoelp@gmail.com>

On Thu, 5 Aug 2021 at 21:34, johannst <johannes.stoelp@googlemail.com> wrote:
>
> Dear all,
>
> in my opinion the `type` argument in the kvm ioctl wrappers should be of
> type unsigned. Please correct me if I am wrong.

(Ccing Eric as our resident POSIX expert.)

> Due to the same reason as explained in the comment on the
> `irq_set_ioctl` field in `struct KVMState` (accel/kvm/kvm-all.c),
> the kvm ioctl wrapper should take `type` as an unsigned.

The reason in that comment:
    /* The man page (and posix) say ioctl numbers are signed int, but
     * they're not.  Linux, glibc and *BSD all treat ioctl numbers as
     * unsigned, and treating them as signed here can break things */

It would be more helpful to readers to state the reason directly
in the commit message, rather than requiring them to go and look
up a comment in some other file.

(That comment, incidentally, seems to be no longer completely
true: on my system the ioctl manpage says 'unsigned long', though
the glibc info docs say 'int', in contradiction to the ioctl.h
glibc actually ships...)

Of the various KVM_* ioctls we use via these functions, do
any actually have values that would result in invalid sign
extension here ? That is, is this fixing an existing bug, or is
it merely avoiding a potential future bug?

> Signed-off-by: johannst <johannes.stoelp@gmail.com>
> ---
>  accel/kvm/kvm-all.c    | 8 ++++----
>  accel/kvm/trace-events | 8 ++++----
>  include/sysemu/kvm.h   | 8 ++++----
>  3 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
> index 0125c17edb..45cd6edce3 100644
> --- a/accel/kvm/kvm-all.c
> +++ b/accel/kvm/kvm-all.c
> @@ -2967,7 +2967,7 @@ int kvm_cpu_exec(CPUState *cpu)
>      return ret;
>  }
>
> -int kvm_ioctl(KVMState *s, int type, ...)
> +int kvm_ioctl(KVMState *s, unsigned type, ...)

The underlying ioctl() prototype (at least in my Linux /usr/include/sys/ioctl.h
and as documented in the ioctl(2) manpage) uses "unsigned long" for the
request argument; should we do the same ?

-- PMM


  parent reply	other threads:[~2021-08-29 21:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-05 19:39 [PATCH v0] kvm: unsigned datatype in ioctl wrapper johannst
2021-08-13 17:39 ` Johannes Stoelp
2021-08-29 20:19   ` Johannes Stoelp
2021-08-29 21:09 ` Peter Maydell [this message]
2021-08-30 15:47   ` Eric Blake
2021-08-30 17:33     ` Peter Maydell
2021-08-30 18:50       ` Ed Maste
2021-08-30 19:37       ` Johannes S
2021-08-30 20:14         ` Peter Maydell
2021-09-01 20:23           ` Johannes S

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='CAFEAcA8TRQdj33Ycm=XzmuUUNApaXVgeDexfS+3Ycg6kLnpmyg@mail.gmail.com' \
    --to=peter.maydell@linaro.org \
    --cc=eblake@redhat.com \
    --cc=johannes.stoelp@gmail.com \
    --cc=johannes.stoelp@googlemail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-trivial@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.