All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: Aleksa Sarai <cyphar@cyphar.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Jeff Layton <jlayton@kernel.org>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	Arnd Bergmann <arnd@arndb.de>,
	David Howells <dhowells@redhat.com>,
	Shuah Khan <shuah@kernel.org>,
	Shuah Khan <skhan@linuxfoundation.org>
Cc: Christian Brauner <christian@brauner.io>,
	Eric Biederman <ebiederm@xmission.com>,
	Andy Lutomirski <luto@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Kees Cook <keescook@chromium.org>, Jann Horn <jannh@google.com>,
	Tycho Andersen <tycho@tycho.ws>,
	David Drysdale <drysdale@google.com>,
	Chanho Min <chanho.min@lge.com>, Oleg Nesterov <oleg@redhat.com>,
	Aleksa Sarai <asarai@suse.de>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	containers@lists.linux-foundation.org,
	linux-alpha@vger.kernel.org, linux-api@vger.kernel.org,
	linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-fsdevel@vger.kernel.org, linux-ia64@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	linux-m
Subject: Re: [PATCH v9 08/10] open: openat2(2) syscall
Date: Thu, 18 Jul 2019 14:48:12 +0000	[thread overview]
Message-ID: <845e4364-685f-343b-46fb-c418766dce3e@rasmusvillemoes.dk> (raw)
In-Reply-To: <20190706145737.5299-9-cyphar@cyphar.com>

On 06/07/2019 16.57, Aleksa Sarai wrote:
> 
> --- a/fs/open.c
> +++ b/fs/open.c
> @@ -928,24 +928,32 @@ struct file *open_with_fake_path(const struct path *path, int flags,
>  }
>  EXPORT_SYMBOL(open_with_fake_path);
>  
> -static inline int build_open_flags(int flags, umode_t mode, struct open_flags *op)
> +static inline int build_open_flags(struct open_how how, struct open_flags *op)
>  {

How does passing such a huge struct by value affect code generation?
Does gcc actually inline the function (and does it even inline the old
one given that it's already non-trivial and has more than one caller).

>  	int lookup_flags = 0;
> -	int acc_mode = ACC_MODE(flags);
> +	int opath_mask = 0;
> +	int acc_mode = ACC_MODE(how.flags);
> +
> +	if (how.resolve & ~VALID_RESOLVE_FLAGS)
> +		return -EINVAL;
> +	if (!(how.flags & (O_PATH | O_CREAT | __O_TMPFILE)) && how.mode != 0)
> +		return -EINVAL;
> +	if (memchr_inv(how.reserved, 0, sizeof(how.reserved)))
> +		return -EINVAL;

How about passing how by const reference, and copy the few fields you
need to local variables. That would at least simplify this patch by
eliminating a lot of the

> -	flags &= VALID_OPEN_FLAGS;
> +	how.flags &= VALID_OPEN_FLAGS;
>  
> -	if (flags & (O_CREAT | __O_TMPFILE))
> -		op->mode = (mode & S_IALLUGO) | S_IFREG;
> +	if (how.flags & (O_CREAT | __O_TMPFILE))
> +		op->mode = (how.mode & S_IALLUGO) | S_IFREG;

churn.

>  
> diff --git a/include/linux/fcntl.h b/include/linux/fcntl.h
> index 2868ae6c8fc1..e59917292213 100644
> --- a/include/linux/fcntl.h
> +++ b/include/linux/fcntl.h
> @@ -4,13 +4,26 @@
>  
>  #include <uapi/linux/fcntl.h>
>  
> -/* list of all valid flags for the open/openat flags argument: */
> +/* Should open_how.mode be set for older syscalls wrappers? */
> +#define OPENHOW_MODE(flags, mode) \
> +	(((flags) | (O_CREAT | __O_TMPFILE)) ? (mode) : 0)
> +

Typo: (((flags) & (O_CREAT | __O_TMPFILE)) ? (mode) : 0)

> +/**
> + * Arguments for how openat2(2) should open the target path. If @extra is zero,
> + * then openat2(2) is identical to openat(2).
> + *
> + * @flags: O_* flags (unknown flags ignored).
> + * @mode: O_CREAT file mode (ignored otherwise).

should probably say "O_CREAT/O_TMPFILE file mode".

> + * @upgrade_mask: restrict how the O_PATH may be re-opened (ignored otherwise).
> + * @resolve: RESOLVE_* flags (-EINVAL on unknown flags).
> + * @reserved: reserved for future extensions, must be zeroed.
> + */
> +struct open_how {
> +	__u32 flags;
> +	union {
> +		__u16 mode;
> +		__u16 upgrade_mask;
> +	};
> +	__u16 resolve;

So mode and upgrade_mask are naturally u16 aka mode_t. And yes, they
probably never need to be used together, so the union works. That then
makes the next member 2-byte aligned, so using a u16 for the resolve
flags brings us to an 8-byte boundary, and 11 unused flag bits should be
enough for a while. But it seems a bit artificial to cram all this
together and then add 56 bytes of reserved space.

Rasmus

WARNING: multiple messages have this Message-ID (diff)
From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: Aleksa Sarai <cyphar@cyphar.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Jeff Layton <jlayton@kernel.org>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	Arnd Bergmann <arnd@arndb.de>,
	David Howells <dhowells@redhat.com>,
	Shuah Khan <shuah@kernel.org>,
	Shuah Khan <skhan@linuxfoundation.org>
Cc: Christian Brauner <christian@brauner.io>,
	Eric Biederman <ebiederm@xmission.com>,
	Andy Lutomirski <luto@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Kees Cook <keescook@chromium.org>, Jann Horn <jannh@google.com>,
	Tycho Andersen <tycho@tycho.ws>,
	David Drysdale <drysdale@google.com>,
	Chanho Min <chanho.min@lge.com>, Oleg Nesterov <oleg@redhat.com>,
	Aleksa Sarai <asarai@suse.de>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	containers@lists.linux-foundation.org,
	linux-alpha@vger.kernel.org, linux-api@vger.kernel.org,
	linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-fsdevel@vger.kernel.org, linux-ia64@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
	linux-xtensa@linux-xtensa.org, sparclinux@vger.kernel.org
Subject: Re: [PATCH v9 08/10] open: openat2(2) syscall
Date: Thu, 18 Jul 2019 16:48:12 +0200	[thread overview]
Message-ID: <845e4364-685f-343b-46fb-c418766dce3e@rasmusvillemoes.dk> (raw)
In-Reply-To: <20190706145737.5299-9-cyphar@cyphar.com>

On 06/07/2019 16.57, Aleksa Sarai wrote:
> 
> --- a/fs/open.c
> +++ b/fs/open.c
> @@ -928,24 +928,32 @@ struct file *open_with_fake_path(const struct path *path, int flags,
>  }
>  EXPORT_SYMBOL(open_with_fake_path);
>  
> -static inline int build_open_flags(int flags, umode_t mode, struct open_flags *op)
> +static inline int build_open_flags(struct open_how how, struct open_flags *op)
>  {

How does passing such a huge struct by value affect code generation?
Does gcc actually inline the function (and does it even inline the old
one given that it's already non-trivial and has more than one caller).

>  	int lookup_flags = 0;
> -	int acc_mode = ACC_MODE(flags);
> +	int opath_mask = 0;
> +	int acc_mode = ACC_MODE(how.flags);
> +
> +	if (how.resolve & ~VALID_RESOLVE_FLAGS)
> +		return -EINVAL;
> +	if (!(how.flags & (O_PATH | O_CREAT | __O_TMPFILE)) && how.mode != 0)
> +		return -EINVAL;
> +	if (memchr_inv(how.reserved, 0, sizeof(how.reserved)))
> +		return -EINVAL;

How about passing how by const reference, and copy the few fields you
need to local variables. That would at least simplify this patch by
eliminating a lot of the

> -	flags &= VALID_OPEN_FLAGS;
> +	how.flags &= VALID_OPEN_FLAGS;
>  
> -	if (flags & (O_CREAT | __O_TMPFILE))
> -		op->mode = (mode & S_IALLUGO) | S_IFREG;
> +	if (how.flags & (O_CREAT | __O_TMPFILE))
> +		op->mode = (how.mode & S_IALLUGO) | S_IFREG;

churn.

>  
> diff --git a/include/linux/fcntl.h b/include/linux/fcntl.h
> index 2868ae6c8fc1..e59917292213 100644
> --- a/include/linux/fcntl.h
> +++ b/include/linux/fcntl.h
> @@ -4,13 +4,26 @@
>  
>  #include <uapi/linux/fcntl.h>
>  
> -/* list of all valid flags for the open/openat flags argument: */
> +/* Should open_how.mode be set for older syscalls wrappers? */
> +#define OPENHOW_MODE(flags, mode) \
> +	(((flags) | (O_CREAT | __O_TMPFILE)) ? (mode) : 0)
> +

Typo: (((flags) & (O_CREAT | __O_TMPFILE)) ? (mode) : 0)

> +/**
> + * Arguments for how openat2(2) should open the target path. If @extra is zero,
> + * then openat2(2) is identical to openat(2).
> + *
> + * @flags: O_* flags (unknown flags ignored).
> + * @mode: O_CREAT file mode (ignored otherwise).

should probably say "O_CREAT/O_TMPFILE file mode".

> + * @upgrade_mask: restrict how the O_PATH may be re-opened (ignored otherwise).
> + * @resolve: RESOLVE_* flags (-EINVAL on unknown flags).
> + * @reserved: reserved for future extensions, must be zeroed.
> + */
> +struct open_how {
> +	__u32 flags;
> +	union {
> +		__u16 mode;
> +		__u16 upgrade_mask;
> +	};
> +	__u16 resolve;

So mode and upgrade_mask are naturally u16 aka mode_t. And yes, they
probably never need to be used together, so the union works. That then
makes the next member 2-byte aligned, so using a u16 for the resolve
flags brings us to an 8-byte boundary, and 11 unused flag bits should be
enough for a while. But it seems a bit artificial to cram all this
together and then add 56 bytes of reserved space.

Rasmus

WARNING: multiple messages have this Message-ID (diff)
From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: Aleksa Sarai <cyphar@cyphar.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Jeff Layton <jlayton@kernel.org>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	Arnd Bergmann <arnd@arndb.de>,
	David Howells <dhowells@redhat.com>,
	Shuah Khan <shuah@kernel.org>,
	Shuah Khan <skhan@linuxfoundation.org>
Cc: Christian Brauner <christian@brauner.io>,
	Eric Biederman <ebiederm@xmission.com>,
	Andy Lutomirski <luto@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Kees Cook <keescook@chromium.org>, Jann Horn <jannh@google.com>,
	Tycho Andersen <tycho@tycho.ws>,
	David Drysdale <drysdale@google.com>,
	Chanho Min <chanho.min@lge.com>, Oleg Nesterov <oleg@redhat.com>,
	Aleksa Sarai <asarai@suse.de>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	containers@lists.linux-foundation.org,
	linux-alpha@vger.kernel.org, linux-api@vger.kernel.org,
	linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-fsdevel@vger.kernel.org, linux-ia64@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	linux-m
Subject: Re: [PATCH v9 08/10] open: openat2(2) syscall
Date: Thu, 18 Jul 2019 16:48:12 +0200	[thread overview]
Message-ID: <845e4364-685f-343b-46fb-c418766dce3e@rasmusvillemoes.dk> (raw)
In-Reply-To: <20190706145737.5299-9-cyphar@cyphar.com>

On 06/07/2019 16.57, Aleksa Sarai wrote:
> 
> --- a/fs/open.c
> +++ b/fs/open.c
> @@ -928,24 +928,32 @@ struct file *open_with_fake_path(const struct path *path, int flags,
>  }
>  EXPORT_SYMBOL(open_with_fake_path);
>  
> -static inline int build_open_flags(int flags, umode_t mode, struct open_flags *op)
> +static inline int build_open_flags(struct open_how how, struct open_flags *op)
>  {

How does passing such a huge struct by value affect code generation?
Does gcc actually inline the function (and does it even inline the old
one given that it's already non-trivial and has more than one caller).

>  	int lookup_flags = 0;
> -	int acc_mode = ACC_MODE(flags);
> +	int opath_mask = 0;
> +	int acc_mode = ACC_MODE(how.flags);
> +
> +	if (how.resolve & ~VALID_RESOLVE_FLAGS)
> +		return -EINVAL;
> +	if (!(how.flags & (O_PATH | O_CREAT | __O_TMPFILE)) && how.mode != 0)
> +		return -EINVAL;
> +	if (memchr_inv(how.reserved, 0, sizeof(how.reserved)))
> +		return -EINVAL;

How about passing how by const reference, and copy the few fields you
need to local variables. That would at least simplify this patch by
eliminating a lot of the

> -	flags &= VALID_OPEN_FLAGS;
> +	how.flags &= VALID_OPEN_FLAGS;
>  
> -	if (flags & (O_CREAT | __O_TMPFILE))
> -		op->mode = (mode & S_IALLUGO) | S_IFREG;
> +	if (how.flags & (O_CREAT | __O_TMPFILE))
> +		op->mode = (how.mode & S_IALLUGO) | S_IFREG;

churn.

>  
> diff --git a/include/linux/fcntl.h b/include/linux/fcntl.h
> index 2868ae6c8fc1..e59917292213 100644
> --- a/include/linux/fcntl.h
> +++ b/include/linux/fcntl.h
> @@ -4,13 +4,26 @@
>  
>  #include <uapi/linux/fcntl.h>
>  
> -/* list of all valid flags for the open/openat flags argument: */
> +/* Should open_how.mode be set for older syscalls wrappers? */
> +#define OPENHOW_MODE(flags, mode) \
> +	(((flags) | (O_CREAT | __O_TMPFILE)) ? (mode) : 0)
> +

Typo: (((flags) & (O_CREAT | __O_TMPFILE)) ? (mode) : 0)

> +/**
> + * Arguments for how openat2(2) should open the target path. If @extra is zero,
> + * then openat2(2) is identical to openat(2).
> + *
> + * @flags: O_* flags (unknown flags ignored).
> + * @mode: O_CREAT file mode (ignored otherwise).

should probably say "O_CREAT/O_TMPFILE file mode".

> + * @upgrade_mask: restrict how the O_PATH may be re-opened (ignored otherwise).
> + * @resolve: RESOLVE_* flags (-EINVAL on unknown flags).
> + * @reserved: reserved for future extensions, must be zeroed.
> + */
> +struct open_how {
> +	__u32 flags;
> +	union {
> +		__u16 mode;
> +		__u16 upgrade_mask;
> +	};
> +	__u16 resolve;

So mode and upgrade_mask are naturally u16 aka mode_t. And yes, they
probably never need to be used together, so the union works. That then
makes the next member 2-byte aligned, so using a u16 for the resolve
flags brings us to an 8-byte boundary, and 11 unused flag bits should be
enough for a while. But it seems a bit artificial to cram all this
together and then add 56 bytes of reserved space.

Rasmus

WARNING: multiple messages have this Message-ID (diff)
From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: Aleksa Sarai <cyphar@cyphar.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Jeff Layton <jlayton@kernel.org>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	Arnd Bergmann <arnd@arndb.de>,
	David Howells <dhowells@redhat.com>,
	Shuah Khan <shuah@kernel.org>,
	Shuah Khan <skhan@linuxfoundation.org>
Cc: linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
	Alexei Starovoitov <ast@kernel.org>,
	Oleg Nesterov <oleg@redhat.com>,
	linux-kselftest@vger.kernel.org, sparclinux@vger.kernel.org,
	linux-arch@vger.kernel.org, linux-s390@vger.kernel.org,
	Tycho Andersen <tycho@tycho.ws>, Aleksa Sarai <asarai@suse.de>,
	linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org,
	linux-xtensa@linux-xtensa.org, Kees Cook <keescook@chromium.org>,
	Jann Horn <jannh@google.com>,
	linuxppc-dev@lists.ozlabs.org, linux-m68k@lists.linux-m68k.org,
	Andy Lutomirski <luto@kernel.org>,
	David Drysdale <drysdale@google.com>,
	Christian Brauner <christian@brauner.io>,
	linux-parisc@vger.kernel.org, linux-api@vger.kernel.org,
	Chanho Min <chanho.min@lge.com>,
	linux-kernel@vger.kernel.org,
	Eric Biederman <ebiederm@xmission.com>,
	linux-alpha@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	containers@lists.linux-foundation.org
Subject: Re: [PATCH v9 08/10] open: openat2(2) syscall
Date: Thu, 18 Jul 2019 16:48:12 +0200	[thread overview]
Message-ID: <845e4364-685f-343b-46fb-c418766dce3e@rasmusvillemoes.dk> (raw)
In-Reply-To: <20190706145737.5299-9-cyphar@cyphar.com>

On 06/07/2019 16.57, Aleksa Sarai wrote:
> 
> --- a/fs/open.c
> +++ b/fs/open.c
> @@ -928,24 +928,32 @@ struct file *open_with_fake_path(const struct path *path, int flags,
>  }
>  EXPORT_SYMBOL(open_with_fake_path);
>  
> -static inline int build_open_flags(int flags, umode_t mode, struct open_flags *op)
> +static inline int build_open_flags(struct open_how how, struct open_flags *op)
>  {

How does passing such a huge struct by value affect code generation?
Does gcc actually inline the function (and does it even inline the old
one given that it's already non-trivial and has more than one caller).

>  	int lookup_flags = 0;
> -	int acc_mode = ACC_MODE(flags);
> +	int opath_mask = 0;
> +	int acc_mode = ACC_MODE(how.flags);
> +
> +	if (how.resolve & ~VALID_RESOLVE_FLAGS)
> +		return -EINVAL;
> +	if (!(how.flags & (O_PATH | O_CREAT | __O_TMPFILE)) && how.mode != 0)
> +		return -EINVAL;
> +	if (memchr_inv(how.reserved, 0, sizeof(how.reserved)))
> +		return -EINVAL;

How about passing how by const reference, and copy the few fields you
need to local variables. That would at least simplify this patch by
eliminating a lot of the

> -	flags &= VALID_OPEN_FLAGS;
> +	how.flags &= VALID_OPEN_FLAGS;
>  
> -	if (flags & (O_CREAT | __O_TMPFILE))
> -		op->mode = (mode & S_IALLUGO) | S_IFREG;
> +	if (how.flags & (O_CREAT | __O_TMPFILE))
> +		op->mode = (how.mode & S_IALLUGO) | S_IFREG;

churn.

>  
> diff --git a/include/linux/fcntl.h b/include/linux/fcntl.h
> index 2868ae6c8fc1..e59917292213 100644
> --- a/include/linux/fcntl.h
> +++ b/include/linux/fcntl.h
> @@ -4,13 +4,26 @@
>  
>  #include <uapi/linux/fcntl.h>
>  
> -/* list of all valid flags for the open/openat flags argument: */
> +/* Should open_how.mode be set for older syscalls wrappers? */
> +#define OPENHOW_MODE(flags, mode) \
> +	(((flags) | (O_CREAT | __O_TMPFILE)) ? (mode) : 0)
> +

Typo: (((flags) & (O_CREAT | __O_TMPFILE)) ? (mode) : 0)

> +/**
> + * Arguments for how openat2(2) should open the target path. If @extra is zero,
> + * then openat2(2) is identical to openat(2).
> + *
> + * @flags: O_* flags (unknown flags ignored).
> + * @mode: O_CREAT file mode (ignored otherwise).

should probably say "O_CREAT/O_TMPFILE file mode".

> + * @upgrade_mask: restrict how the O_PATH may be re-opened (ignored otherwise).
> + * @resolve: RESOLVE_* flags (-EINVAL on unknown flags).
> + * @reserved: reserved for future extensions, must be zeroed.
> + */
> +struct open_how {
> +	__u32 flags;
> +	union {
> +		__u16 mode;
> +		__u16 upgrade_mask;
> +	};
> +	__u16 resolve;

So mode and upgrade_mask are naturally u16 aka mode_t. And yes, they
probably never need to be used together, so the union works. That then
makes the next member 2-byte aligned, so using a u16 for the resolve
flags brings us to an 8-byte boundary, and 11 unused flag bits should be
enough for a while. But it seems a bit artificial to cram all this
together and then add 56 bytes of reserved space.

Rasmus

WARNING: multiple messages have this Message-ID (diff)
From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: Aleksa Sarai <cyphar@cyphar.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Jeff Layton <jlayton@kernel.org>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	Arnd Bergmann <arnd@arndb.de>,
	David Howells <dhowells@redhat.com>,
	Shuah Khan <shuah@kernel.org>,
	Shuah Khan <skhan@linuxfoundation.org>
Cc: linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
	Alexei Starovoitov <ast@kernel.org>,
	Oleg Nesterov <oleg@redhat.com>,
	linux-kselftest@vger.kernel.org, sparclinux@vger.kernel.org,
	linux-arch@vger.kernel.org, linux-s390@vger.kernel.org,
	Tycho Andersen <tycho@tycho.ws>, Aleksa Sarai <asarai@suse.de>,
	linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org,
	linux-xtensa@linux-xtensa.org, Kees Cook <keescook@chromium.org>,
	Jann Horn <jannh@google.com>,
	linuxppc-dev@lists.ozlabs.org, linux-m68k@lists.linux-m68k.org,
	Andy Lutomirski <luto@kernel.org>,
	David Drysdale <drysdale@google.com>,
	Christian Brauner <christian@brauner.io>,
	linux-parisc@vger.kernel.org, linux-api@vger.kernel.org,
	Chanho Min <chanho.min@lge.com>,
	linux-kernel@vger.kernel.org,
	Eric Biederman <ebiederm@xmission.com>,
	linux-alpha@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	containers@lists.linux-foundation.org
Subject: Re: [PATCH v9 08/10] open: openat2(2) syscall
Date: Thu, 18 Jul 2019 16:48:12 +0200	[thread overview]
Message-ID: <845e4364-685f-343b-46fb-c418766dce3e@rasmusvillemoes.dk> (raw)
In-Reply-To: <20190706145737.5299-9-cyphar@cyphar.com>

On 06/07/2019 16.57, Aleksa Sarai wrote:
> 
> --- a/fs/open.c
> +++ b/fs/open.c
> @@ -928,24 +928,32 @@ struct file *open_with_fake_path(const struct path *path, int flags,
>  }
>  EXPORT_SYMBOL(open_with_fake_path);
>  
> -static inline int build_open_flags(int flags, umode_t mode, struct open_flags *op)
> +static inline int build_open_flags(struct open_how how, struct open_flags *op)
>  {

How does passing such a huge struct by value affect code generation?
Does gcc actually inline the function (and does it even inline the old
one given that it's already non-trivial and has more than one caller).

>  	int lookup_flags = 0;
> -	int acc_mode = ACC_MODE(flags);
> +	int opath_mask = 0;
> +	int acc_mode = ACC_MODE(how.flags);
> +
> +	if (how.resolve & ~VALID_RESOLVE_FLAGS)
> +		return -EINVAL;
> +	if (!(how.flags & (O_PATH | O_CREAT | __O_TMPFILE)) && how.mode != 0)
> +		return -EINVAL;
> +	if (memchr_inv(how.reserved, 0, sizeof(how.reserved)))
> +		return -EINVAL;

How about passing how by const reference, and copy the few fields you
need to local variables. That would at least simplify this patch by
eliminating a lot of the

> -	flags &= VALID_OPEN_FLAGS;
> +	how.flags &= VALID_OPEN_FLAGS;
>  
> -	if (flags & (O_CREAT | __O_TMPFILE))
> -		op->mode = (mode & S_IALLUGO) | S_IFREG;
> +	if (how.flags & (O_CREAT | __O_TMPFILE))
> +		op->mode = (how.mode & S_IALLUGO) | S_IFREG;

churn.

>  
> diff --git a/include/linux/fcntl.h b/include/linux/fcntl.h
> index 2868ae6c8fc1..e59917292213 100644
> --- a/include/linux/fcntl.h
> +++ b/include/linux/fcntl.h
> @@ -4,13 +4,26 @@
>  
>  #include <uapi/linux/fcntl.h>
>  
> -/* list of all valid flags for the open/openat flags argument: */
> +/* Should open_how.mode be set for older syscalls wrappers? */
> +#define OPENHOW_MODE(flags, mode) \
> +	(((flags) | (O_CREAT | __O_TMPFILE)) ? (mode) : 0)
> +

Typo: (((flags) & (O_CREAT | __O_TMPFILE)) ? (mode) : 0)

> +/**
> + * Arguments for how openat2(2) should open the target path. If @extra is zero,
> + * then openat2(2) is identical to openat(2).
> + *
> + * @flags: O_* flags (unknown flags ignored).
> + * @mode: O_CREAT file mode (ignored otherwise).

should probably say "O_CREAT/O_TMPFILE file mode".

> + * @upgrade_mask: restrict how the O_PATH may be re-opened (ignored otherwise).
> + * @resolve: RESOLVE_* flags (-EINVAL on unknown flags).
> + * @reserved: reserved for future extensions, must be zeroed.
> + */
> +struct open_how {
> +	__u32 flags;
> +	union {
> +		__u16 mode;
> +		__u16 upgrade_mask;
> +	};
> +	__u16 resolve;

So mode and upgrade_mask are naturally u16 aka mode_t. And yes, they
probably never need to be used together, so the union works. That then
makes the next member 2-byte aligned, so using a u16 for the resolve
flags brings us to an 8-byte boundary, and 11 unused flag bits should be
enough for a while. But it seems a bit artificial to cram all this
together and then add 56 bytes of reserved space.

Rasmus

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-07-18 14:48 UTC|newest]

Thread overview: 243+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-06 14:57 [PATCH v9 00/10] namei: openat2(2) path resolution restrictions Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` Aleksa Sarai
2019-07-06 14:57 ` [PATCH v9 01/10] namei: obey trailing magic-link DAC permissions Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-12  4:14   ` Al Viro
2019-07-12  4:14     ` Al Viro
2019-07-12  4:14     ` Al Viro
2019-07-12  4:14     ` Al Viro
2019-07-12  4:14     ` Al Viro
2019-07-12  6:36     ` Al Viro
2019-07-12  6:36       ` Al Viro
2019-07-12  6:36       ` Al Viro
2019-07-12  6:36       ` Al Viro
2019-07-12  6:36       ` Al Viro
2019-07-12 12:20     ` Aleksa Sarai
2019-07-12 12:20       ` Aleksa Sarai
2019-07-12 12:20       ` Aleksa Sarai
2019-07-12 12:20       ` Aleksa Sarai
2019-07-12 12:20       ` Aleksa Sarai
2019-07-12 12:20       ` Aleksa Sarai
2019-07-12 13:10       ` Al Viro
2019-07-12 13:10         ` Al Viro
2019-07-12 13:10         ` Al Viro
2019-07-12 13:10         ` Al Viro
2019-07-12 13:10         ` Al Viro
2019-07-14  7:11         ` Aleksa Sarai
2019-07-14  7:11           ` Aleksa Sarai
2019-07-14  7:11           ` Aleksa Sarai
2019-07-14  7:11           ` Aleksa Sarai
2019-07-14  7:11           ` Aleksa Sarai
2019-07-06 14:57 ` [PATCH v9 02/10] procfs: switch magic-link modes to be more sane Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57 ` [PATCH v9 03/10] open: O_EMPTYPATH: procfs-less file descriptor re-opening Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57 ` [PATCH v9 04/10] namei: split out nd->dfd handling to dirfd_path_init Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-12  4:20   ` Al Viro
2019-07-12  4:20     ` Al Viro
2019-07-12  4:20     ` Al Viro
2019-07-12  4:20     ` Al Viro
2019-07-12  4:20     ` Al Viro
2019-07-12 12:07     ` Aleksa Sarai
2019-07-12 12:07       ` Aleksa Sarai
2019-07-12 12:07       ` Aleksa Sarai
2019-07-12 12:07       ` Aleksa Sarai
2019-07-12 12:07       ` Aleksa Sarai
2019-07-12 12:12       ` Aleksa Sarai
2019-07-12 12:12         ` Aleksa Sarai
2019-07-12 12:12         ` Aleksa Sarai
2019-07-12 12:12         ` Aleksa Sarai
2019-07-12 12:12         ` Aleksa Sarai
2019-07-12 12:12         ` Aleksa Sarai
2019-07-06 14:57 ` [PATCH v9 05/10] namei: O_BENEATH-style path resolution flags Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-12  4:33   ` Al Viro
2019-07-12  4:33     ` Al Viro
2019-07-12  4:33     ` Al Viro
2019-07-12  4:33     ` Al Viro
2019-07-12  4:33     ` Al Viro
2019-07-12  4:33     ` Al Viro
2019-07-12 10:57     ` Aleksa Sarai
2019-07-12 10:57       ` Aleksa Sarai
2019-07-12 10:57       ` Aleksa Sarai
2019-07-12 10:57       ` Aleksa Sarai
2019-07-12 10:57       ` Aleksa Sarai
2019-07-12 12:39       ` Al Viro
2019-07-12 12:39         ` Al Viro
2019-07-12 12:39         ` Al Viro
2019-07-12 12:39         ` Al Viro
2019-07-12 12:39         ` Al Viro
2019-07-12 12:39         ` Al Viro
2019-07-12 12:55         ` Al Viro
2019-07-12 12:55           ` Al Viro
2019-07-12 12:55           ` Al Viro
2019-07-12 12:55           ` Al Viro
2019-07-12 12:55           ` Al Viro
2019-07-12 13:25           ` Al Viro
2019-07-12 13:25             ` Al Viro
2019-07-12 13:25             ` Al Viro
2019-07-12 13:25             ` Al Viro
2019-07-12 13:25             ` Al Viro
2019-07-12 13:25             ` Al Viro
2019-07-12 15:00             ` Al Viro
2019-07-12 15:00               ` Al Viro
2019-07-12 15:00               ` Al Viro
2019-07-12 15:00               ` Al Viro
2019-07-12 15:00               ` Al Viro
2019-07-13  2:41               ` Al Viro
2019-07-13  2:41                 ` Al Viro
2019-07-13  2:41                 ` Al Viro
2019-07-13  2:41                 ` Al Viro
2019-07-13  2:41                 ` Al Viro
2019-07-14  3:58                 ` Al Viro
2019-07-14  3:58                   ` Al Viro
2019-07-14  3:58                   ` Al Viro
2019-07-14  3:58                   ` Al Viro
2019-07-14  3:58                   ` Al Viro
2019-07-16  8:03                   ` Aleksa Sarai
2019-07-16  8:03                     ` Aleksa Sarai
2019-07-16  8:03                     ` Aleksa Sarai
2019-07-16  8:03                     ` Aleksa Sarai
2019-07-16  8:03                     ` Aleksa Sarai
2019-07-14  7:00                 ` Aleksa Sarai
2019-07-14  7:00                   ` Aleksa Sarai
2019-07-14  7:00                   ` Aleksa Sarai
2019-07-14  7:00                   ` Aleksa Sarai
2019-07-14  7:00                   ` Aleksa Sarai
2019-07-14 14:36                   ` Al Viro
2019-07-14 14:36                     ` Al Viro
2019-07-14 14:36                     ` Al Viro
2019-07-14 14:36                     ` Al Viro
2019-07-14 14:36                     ` Al Viro
2019-07-18  3:17                     ` Aleksa Sarai
2019-07-18  3:17                       ` Aleksa Sarai
2019-07-18  3:17                       ` Aleksa Sarai
2019-07-18  3:17                       ` Aleksa Sarai
2019-07-18  3:17                       ` Aleksa Sarai
2019-07-14 10:31             ` Aleksa Sarai
2019-07-14 10:31               ` Aleksa Sarai
2019-07-14 10:31               ` Aleksa Sarai
2019-07-14 10:31               ` Aleksa Sarai
2019-07-14 10:31               ` Aleksa Sarai
2019-07-06 14:57 ` [PATCH v9 06/10] namei: LOOKUP_IN_ROOT: chroot-like path resolution Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57 ` [PATCH v9 07/10] namei: aggressively check for nd->root escape on ".." resolution Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57 ` [PATCH v9 08/10] open: openat2(2) syscall Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-18 14:48   ` Rasmus Villemoes [this message]
2019-07-18 14:48     ` Rasmus Villemoes
2019-07-18 14:48     ` Rasmus Villemoes
2019-07-18 14:48     ` Rasmus Villemoes
2019-07-18 14:48     ` Rasmus Villemoes
2019-07-18 15:21     ` Aleksa Sarai
2019-07-18 15:21       ` Aleksa Sarai
2019-07-18 15:21       ` Aleksa Sarai
2019-07-18 15:21       ` Aleksa Sarai
2019-07-18 15:21       ` Aleksa Sarai
2019-07-18 15:10   ` Arnd Bergmann
2019-07-18 15:10     ` Arnd Bergmann
2019-07-18 15:10     ` Arnd Bergmann
2019-07-18 15:10     ` Arnd Bergmann
2019-07-18 15:10     ` Arnd Bergmann
2019-07-18 15:10     ` Arnd Bergmann
2019-07-18 16:12     ` Aleksa Sarai
2019-07-18 16:12       ` Aleksa Sarai
2019-07-18 16:12       ` Aleksa Sarai
2019-07-18 16:12       ` Aleksa Sarai
2019-07-18 16:12       ` Aleksa Sarai
2019-07-18 16:12       ` Aleksa Sarai
2019-07-18 21:29       ` Arnd Bergmann
2019-07-18 21:29         ` Arnd Bergmann
2019-07-18 21:29         ` Arnd Bergmann
2019-07-18 21:29         ` Arnd Bergmann
2019-07-18 21:29         ` Arnd Bergmann
2019-07-18 21:29         ` Arnd Bergmann
2019-07-19  2:12         ` Dmitry V. Levin
2019-07-19  2:12           ` Dmitry V. Levin
2019-07-19  2:12           ` Dmitry V. Levin
2019-07-19  2:12           ` Dmitry V. Levin
2019-07-19  2:12           ` Dmitry V. Levin
2019-07-19  2:12           ` Dmitry V. Levin
2019-07-19  2:12           ` Dmitry V. Levin
2019-07-19 10:29           ` Christian Brauner
2019-07-19 10:29             ` Christian Brauner
2019-07-19 10:29             ` Christian Brauner
2019-07-19 10:29             ` Christian Brauner
2019-07-19 10:29             ` Christian Brauner
2019-07-19 10:29             ` Christian Brauner
2019-07-19  1:59   ` Dmitry V. Levin
2019-07-19  1:59     ` Dmitry V. Levin
2019-07-19  1:59     ` Dmitry V. Levin
2019-07-19  1:59     ` Dmitry V. Levin
2019-07-19  1:59     ` Dmitry V. Levin
2019-07-19  2:19     ` Aleksa Sarai
2019-07-19  2:19       ` Aleksa Sarai
2019-07-19  2:19       ` Aleksa Sarai
2019-07-19  2:19       ` Aleksa Sarai
2019-07-19  2:19       ` Aleksa Sarai
2019-07-06 14:57 ` [PATCH v9 09/10] kselftest: save-and-restore errno to allow for %m formatting Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57 ` [PATCH v9 10/10] selftests: add openat2(2) selftests Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-06 14:57   ` Aleksa Sarai
2019-07-08  1:15   ` Michael Ellerman
2019-07-08  1:15     ` Michael Ellerman
2019-07-08  1:15     ` Michael Ellerman
2019-07-08  1:15     ` Michael Ellerman
2019-07-08  1:15     ` Michael Ellerman
2019-07-08  1:15     ` Michael Ellerman
2019-07-08  1:15     ` Michael Ellerman
2019-07-08  5:47     ` Aleksa Sarai
2019-07-08  5:47       ` Aleksa Sarai
2019-07-08  5:47       ` Aleksa Sarai
2019-07-08  5:47       ` Aleksa Sarai
2019-07-08  5:47       ` Aleksa Sarai
2019-07-12 15:11 ` [PATCH v9 00/10] namei: openat2(2) path resolution restrictions Al Viro
2019-07-12 15:11   ` Al Viro
2019-07-12 15:11   ` Al Viro
2019-07-12 15:11   ` Al Viro
2019-07-12 15:11   ` Al Viro
2019-07-12 15:32   ` Aleksa Sarai
2019-07-12 15:32     ` Aleksa Sarai
2019-07-12 15:32     ` Aleksa Sarai
2019-07-12 15:32     ` Aleksa Sarai
2019-07-12 15:32     ` Aleksa Sarai

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=845e4364-685f-343b-46fb-c418766dce3e@rasmusvillemoes.dk \
    --to=linux@rasmusvillemoes.dk \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=asarai@suse.de \
    --cc=ast@kernel.org \
    --cc=bfields@fieldses.org \
    --cc=chanho.min@lge.com \
    --cc=christian@brauner.io \
    --cc=containers@lists.linux-foundation.org \
    --cc=cyphar@cyphar.com \
    --cc=dhowells@redhat.com \
    --cc=drysdale@google.com \
    --cc=ebiederm@xmission.com \
    --cc=jannh@google.com \
    --cc=jlayton@kernel.org \
    --cc=keescook@chromium.org \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=oleg@redhat.com \
    --cc=shuah@kernel.org \
    --cc=skhan@linuxfoundation.org \
    --cc=torvalds@linux-foundation.org \
    --cc=tycho@tycho.ws \
    --cc=viro@zeniv.linux.org.uk \
    /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.