Revert "fs/9p: search open fids first"
authorDominique Martinet <asmadeus@codewreck.org>
Sat, 29 Jan 2022 09:42:59 +0000 (18:42 +0900)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Tue, 8 Feb 2022 17:34:04 +0000 (18:34 +0100)
commitb9e9f848c82b1b568d6b35d931b7ddc6de6b3706
tree70c476e06716b7f4a712b3b875c867618b6293f4
parenta7b717fa15165d3d9245614680bebc48a52ac05d
Revert "fs/9p: search open fids first"

commit 22e424feb6658c5d6789e45121830357809c59cb upstream.

This reverts commit 478ba09edc1f2f2ee27180a06150cb2d1a686f9c.

That commit was meant as a fix for setattrs with by fd (e.g. ftruncate)
to use an open fid instead of the first fid it found on lookup.
The proper fix for that is to use the fid associated with the open file
struct, available in iattr->ia_file for such operations, and was
actually done just before in 66246641609b ("9p: retrieve fid from file
when file instance exist.")
As such, this commit is no longer required.

Furthermore, changing lookup to return open fids first had unwanted side
effects, as it turns out the protocol forbids the use of open fids for
further walks (e.g. clone_fid) and we broke mounts for some servers
enforcing this rule.

Note this only reverts to the old working behaviour, but it's still
possible for lookup to return open fids if dentry->d_fsdata is not set,
so more work is needed to make sure we respect this rule in the future,
for example by adding a flag to the lookup functions to only match
certain fid open modes depending on caller requirements.

Link: https://lkml.kernel.org/r/20220130130651.712293-1-asmadeus@codewreck.org
Fixes: 478ba09edc1f ("fs/9p: search open fids first")
Cc: stable@vger.kernel.org # v5.11+
Reported-by: ron minnich <rminnich@gmail.com>
Reported-by: ng@0x80.stream
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fs/9p/fid.c