On Mon, Jan 27, 2020 at 12:08:00AM +0200, Amir Goldstein wrote:
> If a disconnected dentry gets looked up and renamed between the
> call to exportfs_get_name() and lookup_one_len_unlocked(), and if also
> lookup_one_len_unlocked() returns ERR_PTR(-ENOENT), maybe because old
> parent was deleted, we return an error, although dentry may be connected.
>
> Commit 909e22e05353 ("exportfs: fix 'passing zero to ERR_PTR()'
> warning") changes this behavior from always returning success,
> regardless if dentry was reconnected by somoe other task, to always
> returning a failure.
>
> Change the lookup error handling to match that of exportfs_get_name()
> error handling and return success after getting -ENOENT and verifying
> that some other task has connected the dentry for us.
It's not that simple, unfortunately. For one thing, lookup_one_len_unlocked()
will normally return a negative dentry, not ERR_PTR(-ENOENT). For another,
it *can* fail for any number of other reasons (-ENOMEM, for example), without
anyone having ever looked it up.
So I agree that the damn thing needs work, but I don't believe that this
is the right fix.
