Re: [PATCH] xfs: fix NULL ptr in xfs_attr_leaf_get

[Christoph Hellwig <hch@infradead.org>]

On Tue, Jan 06, 2026 at 10:01:01PM -0800, Christoph Hellwig wrote:
> On Tue, Jan 06, 2026 at 07:40:26AM -0800, Darrick J. Wong wrote:
> > > > Fixes v5.8-rc4-95-g07120f1abdff ("xfs: Add xfs_has_attr and subroutines")
> > > > No reproducer.
> > > 
> > > Eww, what a mess.  I think we're better off to always leave releasing
> > > bp to the caller.  Something like the patch below.  Only compile tested
> > > for now, but I'll kick off an xfstests run.
> > > 
> > > Or maybe we might just kill off xfs_attr_leaf_hasname entirely and open
> > > code it in the three callers, which might end up being more readable?
> > 
> > ...unless this is yet another case of the block layer returning ENODATA,
> > which is then mistaken for returning ENOATTR-but-here's-your-buffer by
> > the xfs_attr code?
> 
> Not really and unless.  This patch (and the full removal that I've
> prepared in the meantime) still fix the missing buffer release in that
> case and make the code easier to follow.  But yes, they would not fix
> the underlying issue, which is why I still think we should not blindly
> propagate block layer errors into b_error.

Having looked at this a bit more, there are clear issued with the calling
convention of xfs_attr_leaf_hasname, which are fixed by removing it as 
done in the patch I just sent.

But this is very clearly another case where ENODATA/ENOATTR can leak from
the buffer cache.  So just as I said back then I think we need to stop
leaking the block status code through the buffer cache.