Re: [git pull] d_revalidate pile

[Al Viro <viro@zeniv.linux.org.uk>]

On Mon, Jan 27, 2025 at 03:52:16PM -0500, Sasha Levin wrote:
> On Mon, Jan 27, 2025 at 05:36:34PM +0000, Al Viro wrote:
> > On Mon, Jan 27, 2025 at 12:19:54PM -0500, Sasha Levin wrote:
> > 
> > > The full log is at: https://qa-reports.linaro.org/lkft/sashal-linus-next/build/v6.13-rc7-8584-gd4639f3659ae/testrun/27028572/suite/log-parser-test/test/kfence-bug-kfence-out-of-bounds-read-in-d_same_name/log
> > > 
> > > LMK if I should attempt a bisection.
> > 
> > Could you try your setup on 58cf9c383c5c "dcache: back inline names
> > with a struct-wrapped array of unsigned long"?
> 
> It looks like we didn't trigger a warnings on that commit, but I'm not
> sure if the issue reproduces easily.
> 
> I'll start a bisection and see where it takes me...

Interesting...  The thing is, that's the only commit that goes anywhere
near ->d_name reassignments.  That access smells like access just one
byte past struct external_name...  wait a minute.

Could that be load_unaligned_zeropad() stepping just over the end of
external name?

If so, then
	a) it's a false positive (and IIRC, it's not the first time
kfence gets confused by that)
	b) your bisection will probably converge to bdd9951f60f9
"dissolve external_name.u into separate members" which is where we'd
ended up with offsetof(struct external_name, name) being 4 modulo 8.

As a quick test, try to flip the order of head and count in
struct external_name and see if that makes the warning go away.
If it does, I'm pretty certain that theory above is correct.