public inbox for [email protected]
 help / color / mirror / Atom feed
From: Andreas Dilger <[email protected]>
To: Kees Cook <[email protected]>
Cc: Stefano Garzarella <[email protected]>,
	Jens Axboe <[email protected]>,
	Christian Brauner <[email protected]>,
	Jann Horn <[email protected]>, Jeff Moyer <[email protected]>,
	linux-fsdevel <[email protected]>,
	Sargun Dhillon <[email protected]>,
	Alexander Viro <[email protected]>,
	Kernel Hardening <[email protected]>,
	Stefan Hajnoczi <[email protected]>,
	Linux Kernel Mailing List <[email protected]>,
	Aleksa Sarai <[email protected]>,
	[email protected]
Subject: Re: [PATCH v4 1/3] io_uring: use an enumeration for io_uring_register(2) opcodes
Date: Wed, 26 Aug 2020 13:52:38 -0600	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <202008261241.074D8765@keescook>

[-- Attachment #1: Type: text/plain, Size: 1882 bytes --]

On Aug 26, 2020, at 1:43 PM, Kees Cook <[email protected]> wrote:
> 
> On Thu, Aug 13, 2020 at 05:32:52PM +0200, Stefano Garzarella wrote:
>> The enumeration allows us to keep track of the last
>> io_uring_register(2) opcode available.
>> 
>> Behaviour and opcodes names don't change.
>> 
>> Signed-off-by: Stefano Garzarella <[email protected]>
>> ---
>> include/uapi/linux/io_uring.h | 27 ++++++++++++++++-----------
>> 1 file changed, 16 insertions(+), 11 deletions(-)
>> 
>> diff --git a/include/uapi/linux/io_uring.h b/include/uapi/linux/io_uring.h
>> index d65fde732518..cdc98afbacc3 100644
>> --- a/include/uapi/linux/io_uring.h
>> +++ b/include/uapi/linux/io_uring.h
>> @@ -255,17 +255,22 @@ struct io_uring_params {
>> /*
>>  * io_uring_register(2) opcodes and arguments
>>  */
>> -#define IORING_REGISTER_BUFFERS		0
>> -#define IORING_UNREGISTER_BUFFERS	1
>> -#define IORING_REGISTER_FILES		2
>> -#define IORING_UNREGISTER_FILES		3
>> -#define IORING_REGISTER_EVENTFD		4
>> -#define IORING_UNREGISTER_EVENTFD	5
>> -#define IORING_REGISTER_FILES_UPDATE	6
>> -#define IORING_REGISTER_EVENTFD_ASYNC	7
>> -#define IORING_REGISTER_PROBE		8
>> -#define IORING_REGISTER_PERSONALITY	9
>> -#define IORING_UNREGISTER_PERSONALITY	10
>> +enum {
>> +	IORING_REGISTER_BUFFERS,
> 
> Actually, one *tiny* thought. Since this is UAPI, do we want to be extra
> careful here and explicitly assign values? We can't change the meaning
> of a number (UAPI) but we can add new ones, etc? This would help if an
> OP were removed (to stop from triggering a cascade of changed values)...
> 
> for example:
> 
> enum {
> 	IORING_REGISTER_BUFFERS = 0,
> 	IORING_UNREGISTER_BUFFERS = 1,
> 	...

Definitely that is preferred, IMHO, for enums used as part of UAPI,
as it avoids accidental changes to the values, and it also makes it
easier to see what the actual values are.

Cheers, Andreas






[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 873 bytes --]

  reply	other threads:[~2020-08-26 19:52 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-13 15:32 [PATCH v4 0/3] io_uring: add restrictions to support untrusted applications and guests Stefano Garzarella
2020-08-13 15:32 ` [PATCH v4 1/3] io_uring: use an enumeration for io_uring_register(2) opcodes Stefano Garzarella
2020-08-26 19:40   ` Kees Cook
2020-08-26 19:43   ` Kees Cook
2020-08-26 19:52     ` Andreas Dilger [this message]
2020-08-27  7:11       ` Stefano Garzarella
2020-08-13 15:32 ` [PATCH v4 2/3] io_uring: add IOURING_REGISTER_RESTRICTIONS opcode Stefano Garzarella
2020-08-26 19:46   ` Kees Cook
2020-08-27  7:12     ` Stefano Garzarella
2020-08-13 15:32 ` [PATCH v4 3/3] io_uring: allow disabling rings during the creation Stefano Garzarella
2020-08-26 19:50   ` Kees Cook
2020-08-27  7:18     ` Stefano Garzarella
2020-08-27 15:04       ` Kees Cook
2020-08-25 15:20 ` [PATCH v4 0/3] io_uring: add restrictions to support untrusted applications and guests Stefano Garzarella
2020-08-26 16:47   ` Jens Axboe
2020-08-26 19:40     ` Kees Cook
2020-08-27  7:24       ` 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 \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /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