On 2019-12-14, Rasmus Villemoes linux@rasmusvillemoes.dk wrote:
On 13/12/2019 23.23, Aleksa Sarai wrote:
The design of the original open_how struct layout was such that it ensured that there would be no un-labelled (and thus potentially non-zero) padding to avoid issues with struct expansion, as well as providing a uniform representation on all architectures (to avoid complications with OPEN_HOW_SIZE versioning).
However, there were a few other desirable features which were not fulfilled by the previous struct layout:
Adding new features (other than new flags) should always result in the struct getting larger. However, by including a padding field, it was possible for new fields to be added without expanding the structure. This would somewhat complicate version-number based checking of feature support.
A non-zero bit in __padding yielded -EINVAL when it should arguably have been -E2BIG (because the padding bits are effectively yet-to-be-used fields). However, the semantics are not entirely clear because userspace may expect -E2BIG to only signify that the structure is too big. It's much simpler to just provide the guarantee that new fields will always result in a struct size increase, and -E2BIG indicates you're using a field that's too recent for an older kernel.
And when the first extension adds another u64 field, that padding has to be added back in and checked for being 0, at which point the padding is again yet-to-be-used fields.
Maybe I'm missing something, but what is the issue with
struct open_how { u64 flags; u64 resolve; u16 mode; u64 next_extension; } __attribute__((packed));
It was my understanding that __aligned_u64 was used to ensure consistent layouts, not that it was needed for safety against unaligned accesses.
So what exactly is the problem with returning EINVAL now?
I would argue that -EINVAL was the wrong choice of return code from the outset (and if we do keep the padding, I will send a patch to switch it to -E2BIG -- see below). The purpose of -E2BIG for the newer "extensible" syscalls is to differentiate between using an unsupported extension field and an unsupported (or invalid) flag.
This will be useful for a few other extension ideas for these types of syscalls (related to allowing userspace to more efficiently figure out what flags are supported by the kernel without having to try each one separately).
- The padding wasted space needlessly, and would very likely not be used up entirely by future extensions for a long time (because it couldn't fit a u64).
Who knows, it does fit a u32. And if the struct is to be 8-byte aligned (see below), it doesn't actually waste space.
Yeah, though giving it some more thought I think this might be a better layout to avoid this problem:
struct open_how { __aligned_u64 flags; __aligned_u64 resolve; __u16 mode; __u16 __padding[3]; /* must be zero */ };
That way, we won't end up with a u16 which we never use (and we won't have multiple __padding fields in the future).
diff --git a/include/uapi/linux/fcntl.h b/include/uapi/linux/fcntl.h index d886bdb585e4..0e070c7f568a 100644 --- a/include/uapi/linux/fcntl.h +++ b/include/uapi/linux/fcntl.h @@ -109,17 +109,16 @@
- O_TMPFILE} are set.
- @flags: O_* flags.
- @mode: O_CREAT/O_TMPFILE file mode.
- @resolve: RESOLVE_* flags.
*/
- @mode: O_CREAT/O_TMPFILE file mode.
struct open_how {
- __aligned_u64 flags;
- __u64 flags;
- __u64 resolve; __u16 mode;
- __u16 __padding[3]; /* must be zeroed */
- __aligned_u64 resolve;
-}; +} __attribute__((packed));
IIRC, gcc assumes such a struct has alignment 1, which means that it will generate horrible code to access it. So if you do this (and I don't think it's a good idea), I think you'd also want to include a __attribute__((__aligned__(8))) - or perhaps that can be accomplished by just keeping flags as an explicitly aligned member. But that will of course bump its sizeof() back to 24, at which point it seems better to just make the padding explicit.
Yeah, you're quite right -- I was aware that GCC generated "less than great" code for aligned(1) structures, but wasn't sure whether it would be seen as being a serious enough issue to NACK the change.
There is an additional problem -- unfortunately, having the struct be __attribute__((aligned(8))) doesn't solve the Rust representation problem because Rust can't represent a struct as both being #[repr(packed)] and #[repr(align(n))]. Obviously the kernel doesn't really care about Rust language restrictions, but given one of the main users of how->resolve will be libpathrs, I'd prefer to not make my own life any harder if possible. ;)
So, given all of the above, I suggest that instead I send something like this instead:
diff --git a/fs/open.c b/fs/open.c index 50a46501bcc9..6c97f52453fe 100644 --- a/fs/open.c +++ b/fs/open.c @@ -994,7 +994,7 @@ static inline int build_open_flags(const struct open_how *how, if (how->resolve & ~VALID_RESOLVE_FLAGS) return -EINVAL; if (memchr_inv(how->__padding, 0, sizeof(how->__padding))) - return -EINVAL; + return -E2BIG;
/* Deal with the mode. */ if (WILL_CREATE(flags)) { diff --git a/include/uapi/linux/fcntl.h b/include/uapi/linux/fcntl.h index d886bdb585e4..c307640071c8 100644 --- a/include/uapi/linux/fcntl.h +++ b/include/uapi/linux/fcntl.h @@ -114,9 +114,9 @@ */ struct open_how { __aligned_u64 flags; + __aligned_u64 resolve; __u16 mode; __u16 __padding[3]; /* must be zeroed */ - __aligned_u64 resolve; };
#define OPEN_HOW_SIZE_VER0 24 /* sizeof first published struct */ diff --git a/tools/testing/selftests/openat2/openat2_test.c b/tools/testing/selftests/openat2/openat2_test.c index 0b64fedc008b..88e3614cbb3a 100644 --- a/tools/testing/selftests/openat2/openat2_test.c +++ b/tools/testing/selftests/openat2/openat2_test.c @@ -61,15 +61,15 @@ void test_openat2_struct(void) { .name = "normal struct (non-zero padding[0])", .arg.inner.flags = O_RDONLY, .arg.inner.__padding = {0xa0, 0x00, 0x00}, - .size = sizeof(struct open_how_ext), .err = -EINVAL }, + .size = sizeof(struct open_how_ext), .err = -E2BIG }, { .name = "normal struct (non-zero padding[1])", .arg.inner.flags = O_RDONLY, .arg.inner.__padding = {0x00, 0x1a, 0x00}, - .size = sizeof(struct open_how_ext), .err = -EINVAL }, + .size = sizeof(struct open_how_ext), .err = -E2BIG }, { .name = "normal struct (non-zero padding[2])", .arg.inner.flags = O_RDONLY, .arg.inner.__padding = {0x00, 0x00, 0xef}, - .size = sizeof(struct open_how_ext), .err = -EINVAL }, + .size = sizeof(struct open_how_ext), .err = -E2BIG },
/* TODO: Once expanded, check zero-padding. */