From: Christian Brauner <brauner@kernel•org>
To: Mark Brown <broonie@kernel•org>
Cc: Chuck Lever <chuck.lever@oracle•com>,
Miklos Szeredi <mszeredi@redhat•com>,
Linux Kernel Mailing List <linux-kernel@vger•kernel.org>,
Linux Next Mailing List <linux-next@vger•kernel.org>
Subject: Re: linux-next: build failure after merge of the nfsd tree
Date: Thu, 28 May 2026 10:30:07 +0200 [thread overview]
Message-ID: <20260528-schalldicht-krampf-gefesselt-1be0e54eaa10@brauner> (raw)
In-Reply-To: <894b9eb2-e054-40e4-a423-1ee5412a5e91@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 904 bytes --]
On Mon, May 25, 2026 at 02:08:44PM +0100, Mark Brown wrote:
> On Mon, May 25, 2026 at 01:57:46PM +0100, Mark Brown wrote:
>
> > After merging the nfsd tree, today's linux-next build (arm64 allnoconfig)
> > failed like this:
>
> > ld: Unexpected GOT/PLT entries detected!
> > ld: Unexpected run-time procedure linkages detected!
>
> > I didn't figure out exactly which commit did this but I'm guessing it's
> > one of these from the vfs-brauner tree that you've pulled in:
>
> > 1cd9d2387c05a (simple_xattr: change interface to pass struct simple_xattrs **)
> > 12e9e3cd03b5a (simpe_xattr: use per-sb cache)
>
> > I have used the version from next-20260522 instead.
>
> Unsurprisingly the vfs-brauner tree also acquired the same build failure
> so I also held it back at next-20260522.
@Miklos, I'm switching this back to jhash() otherwise we have to
default-select xxhash. See appended patch.
[-- Attachment #2: 0001-fs-xattr-use-jhash-for-simple_xattr-hashing.patch --]
[-- Type: text/x-diff, Size: 3217 bytes --]
From 9393223b7e9fec1a73ebb5b572f6843d29d86456 Mon Sep 17 00:00:00 2001
From: Christian Brauner <brauner@kernel•org>
Date: Thu, 28 May 2026 10:23:26 +0200
Subject: [PATCH] fs/xattr: use jhash for simple_xattr hashing
After commit c81b88b8932b ("simpe_xattr: use per-sb cache") switched
sx_hashfn() from jhash() to xxh32(), arm64 allnoconfig fails to link:
ld: fs/xattr.o: in function `simple_xattr_obj_hashfn':
xattr.c:(.text+0x2f0): undefined reference to `xxh32'
ld: fs/xattr.o: in function `simple_xattr_hashfn':
xattr.c:(.text+0x340): undefined reference to `xxh32'
ld: fs/xattr.o: in function `simple_xattr_get':
xattr.c:(.text+0x2374): undefined reference to `xxh32'
xxh32() lives in lib/xxhash.c, which is only built when CONFIG_XXHASH
is selected. fs/xattr.o is built unconditionally via fs/Makefile's
obj-y, so a caller from fs/xattr.c needs XXHASH wired in too.
The obvious fix is to add a hidden always-y config in fs/Kconfig that
selects XXHASH. But that is the wrong fix for this code: xxh32()
does not actually buy simple_xattr anything over jhash() at these
key sizes.
xxh32's throughput advantage comes from a four-lane multiply-add main
loop that processes 16 bytes per iteration, designed for the
checksum- and compression-sized payloads xxhash was written for (lz4,
zstd, btrfs csum, ksm page dedup). The fixed setup cost of priming
those four lanes only amortizes once the input is well past one
iteration. The keys hashed in sx_hashfn() are tiny - 8 bytes for the
parent list_head pointer and ~10-30 bytes for typical xattr names
like "user.foo" or "security.evm" - exactly the size regime where
jhash equals or beats xxh32. Both pass SMHasher and have equivalent
avalanche properties, so the rhashtable's collision rate is
unchanged.
Switch sx_hashfn() back to jhash(). It is header-inline, has the
same distribution quality on these inputs, matches the hash used by
the original rhashtable-based infrastructure in commit b32c4a213698
("xattr: add rhashtable-based simple_xattr infrastructure"), and
avoids dragging lib/xxhash.o into every kernel build for a two-call
hash composer that does not benefit from xxh32's bulk-hashing
strengths.
Reported-by: Mark Brown <broonie@kernel•org>
Closes: https://lore.kernel.org/all/ahRHShZFjI8AsT8G@sirena.org.uk
Fixes: c81b88b8932b ("simpe_xattr: use per-sb cache")
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel•org>
---
fs/xattr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/xattr.c b/fs/xattr.c
index 31cae48e11a4..4416033af881 100644
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -23,7 +23,7 @@
#include <linux/vmalloc.h>
#include <linux/posix_acl_xattr.h>
#include <linux/rhashtable.h>
-#include <linux/xxhash.h>
+#include <linux/jhash.h>
#include <linux/uaccess.h>
@@ -1277,7 +1277,7 @@ struct simple_xattr *simple_xattr_alloc(const void *value, size_t size)
static u32 sx_hashfn(const char *name, const struct list_head *parent, u32 seed)
{
- return xxh32(name, strlen(name), xxh32(&parent, sizeof(parent), seed));
+ return jhash(name, strlen(name), jhash(&parent, sizeof(parent), seed));
}
static u32 simple_xattr_hashfn(const void *data, u32 len, u32 seed)
--
2.47.3
next prev parent reply other threads:[~2026-05-28 8:30 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-25 12:57 linux-next: build failure after merge of the nfsd tree Mark Brown
2026-05-25 13:08 ` Mark Brown
2026-05-28 8:30 ` Christian Brauner [this message]
2026-05-28 8:36 ` Miklos Szeredi
2026-06-01 12:53 ` Mark Brown
2026-06-01 13:00 ` Miklos Szeredi
-- strict thread matches above, loose matches on Subject: below --
2026-06-03 8:24 Mark Brown
2026-06-03 12:55 ` tanze
2020-05-08 0:47 Stephen Rothwell
2020-05-12 0:22 ` J. Bruce Fields
2018-10-05 0:01 Stephen Rothwell
2018-10-04 23:54 Stephen Rothwell
2017-08-25 0:24 Stephen Rothwell
2017-08-30 23:48 ` Stephen Rothwell
2017-08-31 15:55 ` J. Bruce Fields
2015-07-20 23:57 Stephen Rothwell
2015-07-21 5:10 ` Kinglong Mee
2014-08-19 16:38 Stephen Rothwell
2014-05-28 2:07 Stephen Rothwell
2014-05-28 18:57 ` J. Bruce Fields
2014-05-26 1:18 Stephen Rothwell
2014-05-27 21:22 ` J. Bruce Fields
2013-04-29 1:24 Stephen Rothwell
2013-04-29 14:53 ` Chuck Lever
2013-04-29 15:45 ` J. Bruce Fields
2013-04-29 16:05 ` Chuck Lever
2013-04-29 16:21 ` Trond Myklebust
2013-04-29 17:04 ` Chuck Lever
2013-04-29 17:37 ` Simo Sorce
2013-04-29 17:38 ` J. Bruce Fields
2013-04-29 17:47 ` Chuck Lever
2013-04-29 17:57 ` Simo Sorce
2013-04-29 17:59 ` J. Bruce Fields
2013-04-29 18:30 ` Chuck Lever
2013-04-29 18:57 ` J. Bruce Fields
2013-04-29 19:14 ` Chuck Lever
2013-04-29 16:29 ` Simo Sorce
2013-04-29 16:37 ` Chuck Lever
2013-04-29 16:46 ` Simo Sorce
2013-03-01 1:04 Stephen Rothwell
2013-03-01 1:19 ` Myklebust, Trond
2013-03-02 3:42 ` J. Bruce Fields
2013-02-02 2:04 Stephen Rothwell
2013-02-02 12:57 ` J. Bruce Fields
2013-02-03 14:41 ` J. Bruce Fields
2013-02-08 5:41 ` Stanislav Kinsbursky
2013-02-08 21:19 ` J. Bruce Fields
2011-11-15 23:29 Stephen Rothwell
2011-11-16 0:14 ` J. Bruce Fields
2011-11-16 1:26 ` J. Bruce Fields
2010-09-23 1:34 Stephen Rothwell
2010-09-23 2:33 ` J. Bruce Fields
2010-09-23 2:51 ` Neil Brown
2010-09-23 4:03 ` J. Bruce Fields
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=20260528-schalldicht-krampf-gefesselt-1be0e54eaa10@brauner \
--to=brauner@kernel$(echo .)org \
--cc=broonie@kernel$(echo .)org \
--cc=chuck.lever@oracle$(echo .)com \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=mszeredi@redhat$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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