Re: [PATCH] xfs: Fix error pointer dereference

["Darrick J. Wong" <djwong@kernel.org>]

On Thu, Feb 19, 2026 at 11:25:38AM +1100, NeilBrown wrote:
> On Thu, 19 Feb 2026, Darrick J. Wong wrote:
> > On Wed, Feb 18, 2026 at 01:51:15PM -0600, Ethan Tidmore wrote:
> > > The function try_lookup_noperm() can return an error pointer and is not
> > > checked for one. Add checks for error pointer.
> > > 
> > > Detected by Smatch:
> > > fs/xfs/scrub/orphanage.c:449 xrep_adoption_check_dcache() error: 
> > > 'd_child' dereferencing possible ERR_PTR()
> > > 
> > > fs/xfs/scrub/orphanage.c:485 xrep_adoption_zap_dcache() error: 
> > > 'd_child' dereferencing possible ERR_PTR()
> > > 
> > > Fixes: 06c567403ae5a ("Use try_lookup_noperm() instead of d_hash_and_lookup() outside of VFS")
> > 
> > Cc: <stable@vger.kernel.org> # v6.16
> 
> I don't think this is justified.  In this use case try_lookup_noperm()
> will never actually return an error.

Sure, but a future update to try_lookup_noperm that *does* introduce the
possibility of an ERR_PTR return could get backported to 6.18, at which
point this code is now broken.  I think I'd rather just clean all this
up all at once.

> > 
> > > Signed-off-by: Ethan Tidmore <ethantidmore06@gmail.com>
> > > ---
> > >  fs/xfs/scrub/orphanage.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/fs/xfs/scrub/orphanage.c b/fs/xfs/scrub/orphanage.c
> > > index 52a108f6d5f4..cdb0f486f50c 100644
> > > --- a/fs/xfs/scrub/orphanage.c
> > > +++ b/fs/xfs/scrub/orphanage.c
> > > @@ -442,7 +442,7 @@ xrep_adoption_check_dcache(
> > >  		return 0;
> > >  
> > >  	d_child = try_lookup_noperm(&qname, d_orphanage);
> > 
> > "Look up a dentry by name in the dcache, returning NULL if it does not
> > currently exist."
> > 
> > Could you please fix the documentation since try_lookup_noperm can
> > return ERR_PTR values?
> 
> Fair - I'll include a patch with my next batch.
> 
> > 
> > > -	if (d_child) {
> > > +	if (!IS_ERR_OR_NULL(d_child)) {
> > 
> > If d_child is an ERR_PTR, shouldn't we extract that error value and
> > return it instead of zero?
> 
> This is a purely cosmetic question as no error is actually returned in
> practice.  So whatever you feel most comfortable with is best.

If we're going to check for an ERR_PTR value (even if one cannot
currently be returned) then we should pass it upwards.  We might as well
get rid of all the lurking broken logic all at once.

--D

> NeilBrown
> 
> 
> > 
> > --D
> > 
> > >  		trace_xrep_adoption_check_child(sc->mp, d_child);
> > >  
> > >  		if (d_is_positive(d_child)) {
> > > @@ -479,7 +479,7 @@ xrep_adoption_zap_dcache(
> > >  		return;
> > >  
> > >  	d_child = try_lookup_noperm(&qname, d_orphanage);
> > > -	while (d_child != NULL) {
> > > +	while (!IS_ERR_OR_NULL(d_child)) {
> > >  		trace_xrep_adoption_invalidate_child(sc->mp, d_child);
> > >  
> > >  		ASSERT(d_is_negative(d_child));
> > > -- 
> > > 2.53.0
> > > 
> > > 
> > 
> 
>