From: Zorro Lang <zlang@kernel.org>
To: fstests@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org
Subject: [PATCH] src/locktest.c: fix build failure of struct delegation
Date: Thu, 13 Aug 2026 23:08:46 +0800 [thread overview]
Message-ID: <20260813150846.280498-1-zlang@kernel.org> (raw)
Since glibc commit f2e3dacbff88 ("Add new constants from Linux 6.12,
6.18 and 6.19 to bits/fcntl-linux.h"), the F_GETDELEG and F_SETDELEG
constants from Linux 6.19 have been added directly into <fcntl.h>.
However, the corresponding full definition for 'struct delegation'
was not included in glibc's userspace wrapper. That causes below
build error:
locktest.c:1065:16: error: variable 'deleg' has initializer but incomplete type
1065 | struct delegation deleg = { .d_type = F_UNLCK };
...
Fix this by isolating the definition of 'struct delegation' from the
command macros via autoconf capability probing:
1. Add an AC_CHECK_TYPES check for 'struct delegation' in configure.ac.
2. In locktest.c, unbind 'struct delegation' from the '#ifndef F_GETDELEG'
guard and wrap it with '#ifndef HAVE_STRUCT_DELEGATION' instead.
Signed-off-by: Zorro Lang <zlang@kernel.org>
---
Hi,
fstests currently fails to build against the latest glibc, with the root
cause detailed in the commit log above.
The glibc now defines F_GETDELEG and F_SETDELEG, but leaves out the actual
'struct delegation' definition. The complete struct is available in <linux/fcntl.h>,
but we cannot simply include both <fcntl.h> and <linux/fcntl.h> due to nasty
namespace redefinition conflicts.
I am not entirely sure if glibc will bring in 'struct delegation', so for now,
I chose to decouple and handle the structure definition independently via
autoconf.
Any thoughts or better suggestions on how we should handle this transition?
Thanks,
Zorro
configure.ac | 4 ++++
src/locktest.c | 2 ++
2 files changed, 6 insertions(+)
diff --git a/configure.ac b/configure.ac
index feb24ddd..6d7ff3ba 100644
--- a/configure.ac
+++ b/configure.ac
@@ -111,6 +111,10 @@ AC_CHECK_TYPES([struct btrfs_ioctl_received_subvol_args], [], [], [[
#include <stddef.h>
#include <linux/btrfs.h>
]])
+AC_CHECK_TYPES([struct delegation], [], [], [[
+#include <stddef.h>
+#include <fcntl.h>
+]])
AC_CHECK_HEADERS([linux/btrfs.h linux/btrfs_tree.h])
AC_CHECK_MEMBERS([struct btrfs_ioctl_vol_args_v2.subvolid], [], [], [[
#include <stddef.h>
diff --git a/src/locktest.c b/src/locktest.c
index 54ee1f07..d0264c94 100644
--- a/src/locktest.c
+++ b/src/locktest.c
@@ -80,7 +80,9 @@ extern int h_errno;
#ifndef F_GETDELEG
#define F_GETDELEG (1024 + 15)
#define F_SETDELEG (1024 + 16)
+#endif
+#ifndef HAVE_STRUCT_DELEGATION
struct delegation {
uint32_t d_flags;
uint16_t d_type;
--
2.55.0
reply other threads:[~2026-08-13 15:08 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20260813150846.280498-1-zlang@kernel.org \
--to=zlang@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).