Hi all,
After merging the vfs-brauner tree, today's linux-next build (arm64
allnoconfig) failed like this:
In file included from <command-line>:
/tmp/next/build/fs/fcntl.c: In function 'fcntl_init':
/tmp/next/build/include/linux/compiler_types.h:699:45: error: call to
'__compiletime_assert_614' declared with attribute error: BUILD_BUG_ON
failed: 21 - 1 != HWEIGHT32( (VALID_OPENAT2_FLAGS & ~(O_NONBLOCK |
O_NDELAY)) | __FMODE_EXEC)
699 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^
/tmp/next/build/include/linux/compiler_types.h:680:25: note: in definition
of macro '__compiletime_assert'
680 | prefix ## suffix(); \
| ^~~~~~
/tmp/next/build/include/linux/compiler_types.h:699:9: note: in expansion
of macro '_compiletime_assert'
699 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^~~~~~~~~~~~~~~~~~~
/tmp/next/build/include/linux/build_bug.h:40:37: note: in expansion of
macro 'compiletime_assert'
40 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
| ^~~~~~~~~~~~~~~~~~
/tmp/next/build/include/linux/build_bug.h:51:9: note: in expansion of
macro 'BUILD_BUG_ON_MSG'
51 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
| ^~~~~~~~~~~~~~~~
/tmp/next/build/fs/fcntl.c:1172:9: note: in expansion of macro
'BUILD_BUG_ON'
1172 | BUILD_BUG_ON(21 - 1 /* for O_RDONLY being 0 */ !=
| ^~~~~~~~~~~~
Caused by commits
3adfed795a99d (openat2: new OPENAT2_REGULAR flag support)
6703991ad3a35 (vfs: add O_EMPTYPATH to openat(2)/openat2(2))
interacting with each other. Due to complex conflcits with netfs on the
old vfs-brauner tree I have applied the following fixup but since both
commits are coming from the vfs-brauner tree it's really not a merge
fixup:
From db4170bfa75dbd45e3f2e1a03f98c512fb2409b7 Mon Sep 17 00:00:00 2001
From: Mark Brown <broonie@kernel.org>
Date: Mon, 18 May 2026 11:26:07 +0100
Subject: [PATCH] openat: Fix collision between OPENAT2_REGULAR and O_EMPTYPATH
The commits
3adfed795a99d (openat2: new OPENAT2_REGULAR flag support)
6703991ad3a35 (vfs: add O_EMPTYPATH to openat(2)/openat2(2))
both defined new flags for openat2() but used the same numeric value for
them, with the second commit also using a different style for
specifying the flag (shifting rather than using an absolute value),
triggering build failures. Deduplicate the defintions.
Fixes: 6703991ad3a35 ("vfs: add O_EMPTYPATH to openat(2)/openat2(2)")
Signed-off-by: Mark Brown <broonie@kernel.org>
---
fs/fcntl.c | 2 +-
include/uapi/asm-generic/fcntl.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/fcntl.c b/fs/fcntl.c
index 240bb511557a1..7e953d4a807de 100644
--- a/fs/fcntl.c
+++ b/fs/fcntl.c
@@ -1169,7 +1169,7 @@ static int __init fcntl_init(void)
* Exceptions: O_NONBLOCK is a two bit define on parisc; O_NDELAY
* is defined as O_NONBLOCK on some platforms and not on others.
*/
- BUILD_BUG_ON(21 - 1 /* for O_RDONLY being 0 */ !=
+ BUILD_BUG_ON(22 - 1 /* for O_RDONLY being 0 */ !=
HWEIGHT32(
(VALID_OPENAT2_FLAGS & ~(O_NONBLOCK | O_NDELAY)) |
__FMODE_EXEC));
diff --git a/include/uapi/asm-generic/fcntl.h b/include/uapi/asm-generic/fcntl.h
index 3c6062007b26f..c4b0e7153fa87 100644
--- a/include/uapi/asm-generic/fcntl.h
+++ b/include/uapi/asm-generic/fcntl.h
@@ -93,7 +93,7 @@
#endif
#ifndef O_EMPTYPATH
-#define O_EMPTYPATH (1 << 26) /* allow empty path */
+#define O_EMPTYPATH 0100000000 /* allow empty path */
#endif
/* a horrid kludge trying to make sure that this will fail on old kernels */
--
2.47.3
On Mon, May 18, 2026 at 11:47:24AM +0100, Mark Brown wrote: > Hi all, > > After merging the vfs-brauner tree, today's linux-next build (arm64 > allnoconfig) failed like this: > Caused by commits > 3adfed795a99d (openat2: new OPENAT2_REGULAR flag support) > 6703991ad3a35 (vfs: add O_EMPTYPATH to openat(2)/openat2(2)) > interacting with each other. Due to complex conflcits with netfs on the > old vfs-brauner tree I have applied the following fixup but since both > commits are coming from the vfs-brauner tree it's really not a merge > fixup: ...and my fixup fails to build on sparc64_defconfig :/
Hi Mark, On Mon, May 18, 2026 at 10:32 PM Mark Brown <broonie@kernel.org> wrote: > > On Mon, May 18, 2026 at 11:47:24AM +0100, Mark Brown wrote: > > Hi all, > > > > After merging the vfs-brauner tree, today's linux-next build (arm64 > > allnoconfig) failed like this: > > > Caused by commits > > > 3adfed795a99d (openat2: new OPENAT2_REGULAR flag support) > > 6703991ad3a35 (vfs: add O_EMPTYPATH to openat(2)/openat2(2)) > > > interacting with each other. Due to complex conflcits with netfs on the > > old vfs-brauner tree I have applied the following fixup but since both > > commits are coming from the vfs-brauner tree it's really not a merge > > fixup: > > ...and my fixup fails to build on sparc64_defconfig :/ (1 << 26) doesn't seem to be 0100000000 rather 0400000000 . 0100000000 conflicts with O_PATH in arch/sparc/include/uapi/asm/fcntl.h dorjoy@desktop:~$ python3 Python 3.14.4 (main, Apr 16 2026, 00:00:00) [GCC 16.0.1 20260321 (Red Hat 16.0.1-0)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> a = (1 << 26) >>> oct(a) '0o400000000' I looked at the O_EMPTYPATH changes in git.kernel.org and it defines O_EMPTYPATH only in include/uapi/asm-generic/fcntl.h . That is why it was probably chosen to be (1 << 26) i.e., 0400000000 since at that time this value did not conflict with the other explicit values in architecture specific fcnl.h files. But as far as I see, I defined 0400000000 as OPENAT2_REGULAR in arch/sparc/include/uapi/asm/fcntl.h during my work. So this value probably needs to be something else, for example, (1 << 27) i.e., 01000000000 to avoid conflict after merging? Regards, Dorjoy
On Mon, May 18, 2026 at 11:06:05PM +0600, Dorjoy Chowdhury wrote: > On Mon, May 18, 2026 at 10:32 PM Mark Brown <broonie@kernel.org> wrote: > > > 3adfed795a99d (openat2: new OPENAT2_REGULAR flag support) > > > 6703991ad3a35 (vfs: add O_EMPTYPATH to openat(2)/openat2(2)) > > ...and my fixup fails to build on sparc64_defconfig :/ > (1 << 26) doesn't seem to be 0100000000 rather 0400000000 . Yeah, like I said I renumbered due to the conflict with the asm-generic OPENAT2_REGULAR. > 0100000000 conflicts with O_PATH in > arch/sparc/include/uapi/asm/fcntl.h Figured it'd be an arch specific version of a similar thing - I didn't audit them as you can see. > I looked at the O_EMPTYPATH changes in git.kernel.org and it defines > O_EMPTYPATH only in include/uapi/asm-generic/fcntl.h . That is why it > was probably chosen to be (1 << 26) i.e., 0400000000 since at that > time this value did not conflict with the other explicit values in > architecture specific fcnl.h files. But as far as I see, I defined > 0400000000 as OPENAT2_REGULAR in arch/sparc/include/uapi/asm/fcntl.h > during my work. So this value probably needs to be something else, for > example, (1 << 27) i.e., 01000000000 to avoid conflict after merging? Yeah, just some value that isn't already in use - the compile assert is doing it's job here.
> Op 18-05-2026 19:13 CEST schreef Mark Brown <broonie@kernel.org>: > > Figured it'd be an arch specific version of a similar thing - I didn't > audit them as you can see. > These confusions with octal numbers in lists that aren't even ordered is why I would prefer to use shifted values instead. I don't see any reason actually why we should not just convert them all, apart from churning and perhaps not doing it correctly (which would be bad). My rationale for mixing was to use 1 << n at least for the remaining bits. If I remember correctly, this is also what Aleksa preferred. Thanks for looking into this, Jori.
On Mon, May 18, 2026 at 09:12:44PM +0200, Jori Koolstra wrote: > > Op 18-05-2026 19:13 CEST schreef Mark Brown <broonie@kernel.org>: > > Figured it'd be an arch specific version of a similar thing - I didn't > > audit them as you can see. > These confusions with octal numbers in lists that aren't even ordered is > why I would prefer to use shifted values instead. I don't see any reason > actually why we should not just convert them all, apart from churning and > perhaps not doing it correctly (which would be bad). My rationale for mixing > was to use 1 << n at least for the remaining bits. If I remember correctly, > this is also what Aleksa preferred. Yeah, shifted values do make sense to me as well - other than the inconsistent style the only issue I saw was that it's a bit less obvious that the values collide.
> Op 19-05-2026 18:24 CEST schreef Mark Brown <broonie@kernel.org>: > > > On Mon, May 18, 2026 at 09:12:44PM +0200, Jori Koolstra wrote: > > > Op 18-05-2026 19:13 CEST schreef Mark Brown <broonie@kernel.org>: > > > > Figured it'd be an arch specific version of a similar thing - I didn't > > > audit them as you can see. > > > These confusions with octal numbers in lists that aren't even ordered is > > why I would prefer to use shifted values instead. I don't see any reason > > actually why we should not just convert them all, apart from churning and > > perhaps not doing it correctly (which would be bad). My rationale for mixing > > was to use 1 << n at least for the remaining bits. If I remember correctly, > > this is also what Aleksa preferred. > > Yeah, shifted values do make sense to me as well - other than the > inconsistent style the only issue I saw was that it's a bit less obvious > that the values collide. Yeah, that's unfortunate. @Christian, can we get rid of these octal values? Or is that too much churn?
© 2016 - 2026 Red Hat, Inc.