[PATCH] cachefiles: Fix excess dput() after end_removing()

David Howells dhowells at redhat.com
Thu Mar 26 00:51:22 PDT 2026


Marc Dionne <marc.c.dionne at gmail.com> wrote:

> I think it is the correct Fixes tag, but I'm not sure that this is
> actually the right fix.  7bb1eb45e43c switched other callers of
> cachefiles_bury_object to use start_removing_dentry, which gets an
> additional ref, and removed the extra dget from
> cachefiles_bury_object.  In the cachefiles_cull case however, the
> dentry is from start_removing and has a single ref on entry to
> cachefiles_bury_object, which is an issue as "rep" may be used there
> after end_removing may have put the last ref.  So the correct is
> probably for cachefiles_cull to add a dget() before the call to
> cachefiles_bury_object.

Ugh.  You're right.

The problem is that we're calling start_removing() without knowing whether we
can just unlink the object.  I wonder if I need to do the lookup in
cachefiles_lookup_for_cull() and only then call start_removing_dentry() if
it's not a directory (directories get moved to the graveyard for cachefilesd
to tear down).

I think the right solution is actually to move start_removing_dentry() down
into cachefiles_bury_object() and make it contingent on the dentry being a
non-dir.

David




More information about the linux-afs mailing list