Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Subject: Re: NFS, two d_delete() calls in nfs_unlink()
To:     "NeilBrown" <neilb@suse.de>
Cc:     trond.myklebust@hammerspace.com, linux-nfs@vger.kernel.org
In-Reply-To: <166079133167.5425.16635199337074058478@noble.neil.brown.name>
References: <7634.1660728564@jrobl> <166079133167.5425.16635199337074058478@noble.neil.brown.name>
From:   hooanon05g@gmail.com
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9450.1660793491.1@jrobl>
Date:   Thu, 18 Aug 2022 12:31:31 +0900
Message-ID: <9451.1660793491@jrobl>
Precedence: bulk

"NeilBrown":
> Thanks for the report.
> This possibility of calling d_delete() twice has been present
> since  9019fb391de0 in v5.16.

I don't think 9019fb391de0 is a problem.
Before v6.0-rc1, the target dentry was unhashed by __d_drop() call in
nfs_unlink(), and nfs_dentry_handle_enoent() skipped calling d_delete()
by simple_positive(). d_delete() was called only once via
nfs_dentry_remove_handle_error().

In v6.0-rc1, the dentry is not unhashed and nfs_dentry_handle_enoent()
doesn't skip calling d_delete().


> How did you discover this bug, and why do you think my patch
> caused it?

I met this problem during a stress test aiming a filesystem I am
developing.
And I think unhashing causes nfs_dentry_handle_enoent() to call
d_delete().


J. R. Okajima