Linux kernel stable tree (mirror) https://git.radix-linux.su/kernel/linux.git/atom?h=v6.2 2022-12-02T14:59:15+00:00 2022-12-02T14:59:15+00:00 Christophe JAILLET christophe.jaillet@wanadoo.fr 2022-11-27T12:59:25+00:00 urn:sha1:6e0149a55379d6b91948cf6e94e700eb7dbaa518 The 9p fs does not use IDR or IDA functionalities. So there is no point in including <linux/idr.h>. Remove it. Link: https://lkml.kernel.org/r/3d1e0ed9714eaee7e18d9f5b0b4bfa49b00b286d.1669553950.git.christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Christian Schoenebeck <linux_oss@crudebyte.com> [Dominique: reword subject] Signed-off-by: Dominique Martinet <asmadeus@codewreck.org> 2022-07-02T09:52:21+00:00 Yang Li yang.lee@linux.alibaba.com 2022-06-15T01:20:39+00:00 urn:sha1:e3baced02a521a6f213b29053db76394aa22d5e1 Remove warnings found by running scripts/kernel-doc, which is caused by using 'make W=1'. fs/9p/fid.c:35: warning: Function parameter or member 'pfid' not described in 'v9fs_fid_add' fs/9p/fid.c:35: warning: Excess function parameter 'fid' description in 'v9fs_fid_add' fs/9p/fid.c:80: warning: Function parameter or member 'pfid' not described in 'v9fs_open_fid_add' fs/9p/fid.c:80: warning: Excess function parameter 'fid' description in 'v9fs_open_fid_add' Link: https://lkml.kernel.org/r/20220615012039.43479-1-yang.lee@linux.alibaba.com Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> [Dominique: further adjust comment] Signed-off-by: Dominique Martinet <asmadeus@codewreck.org> 2022-07-02T09:52:21+00:00 Dominique Martinet asmadeus@codewreck.org 2022-06-12T07:05:39+00:00 urn:sha1:dafbe689736f62c696ac64809b17bdc752cfbe76 Simplify p9_fid_put cleanup path in many 9p functions since the function is noop on null or error fids. Also make the *_add_fid() helpers "steal" the fid by nulling its pointer, so put after them will be noop. This should lead to no change of behaviour Link: https://lkml.kernel.org/r/20220612085330.1451496-7-asmadeus@codewreck.org Reviewed-by: Tyler Hicks <tyhicks@linux.microsoft.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org> 2022-07-02T09:52:21+00:00 Dominique Martinet asmadeus@codewreck.org 2022-06-12T04:42:32+00:00 urn:sha1:b48dbb998d70b7f48c2ec0a15c3cf47136808e4e I was recently reminded that it is not clear that p9_client_clunk() was actually just decrementing refcount and clunking only when that reaches zero: make it clear through a set of helpers. This will also allow instrumenting refcounting better for debugging next patch Link: https://lkml.kernel.org/r/20220612085330.1451496-5-asmadeus@codewreck.org Reviewed-by: Tyler Hicks <tyhicks@linux.microsoft.com> Reviewed-by: Christian Schoenebeck <linux_oss@crudebyte.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org> 2022-07-02T09:52:21+00:00 Tyler Hicks tyhicks@linux.microsoft.com 2022-05-27T00:00:03+00:00 urn:sha1:b296d05746b7fa0d663e3b11abf0e03eab6e03e6 Fix s/patch/path/ typo and make it clear that we're talking about multiple path components. Link: https://lkml.kernel.org/r/20220527000003.355812-6-tyhicks@linux.microsoft.com Signed-off-by: Tyler Hicks <tyhicks@linux.microsoft.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org> 2022-07-02T09:52:21+00:00 Tyler Hicks tyhicks@linux.microsoft.com 2022-05-27T00:00:02+00:00 urn:sha1:47b1e3432b06c17b2d123b7ad30f04dd97b6d6f7 Remove the ofid variable that's local to the conditional block in favor of the old_fid variable that's local to the entire function. Link: https://lkml.kernel.org/r/20220527000003.355812-5-tyhicks@linux.microsoft.com Signed-off-by: Tyler Hicks <tyhicks@linux.microsoft.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org> 2022-07-02T09:52:21+00:00 Tyler Hicks tyhicks@linux.microsoft.com 2022-05-27T00:00:01+00:00 urn:sha1:c58c72d301d3d16ba1167d56417af39761829030 Cloning during a path component walk is only needed when the old fid used for the walk operation is the root fid. Make that clear by comparing the two fids rather than using an additional variable. Link: https://lkml.kernel.org/r/20220527000003.355812-4-tyhicks@linux.microsoft.com Signed-off-by: Tyler Hicks <tyhicks@linux.microsoft.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org> 2022-07-02T09:52:21+00:00 Tyler Hicks tyhicks@linux.microsoft.com 2022-05-27T00:00:00+00:00 urn:sha1:cba83f47fc0ef52638870890e9e352afcc56dd73 Improve readability by using a new variable when dealing with the root fid. The root fid requires special handling in comparison to other fids used during fid lookup. Link: https://lkml.kernel.org/r/20220527000003.355812-3-tyhicks@linux.microsoft.com Signed-off-by: Tyler Hicks <tyhicks@linux.microsoft.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org> 2022-06-15T03:05:33+00:00 Tyler Hicks tyhicks@linux.microsoft.com 2022-05-26T23:59:59+00:00 urn:sha1:2a3dcbccd64ba35c045fac92272ff981c4cbef44 Decrement the refcount of the parent dentry's fid after walking each path component during a full path walk for a lookup. Failure to do so can lead to fids that are not clunked until the filesystem is unmounted, as indicated by this warning: 9pnet: found fid 3 not clunked The improper refcounting after walking resulted in open(2) returning -EIO on any directories underneath the mount point when using the virtio transport. When using the fd transport, there's no apparent issue until the filesytem is unmounted and the warning above is emitted to the logs. In some cases, the user may not yet be attached to the filesystem and a new root fid, associated with the user, is created and attached to the root dentry before the full path walk is performed. Increment the new root fid's refcount to two in that situation so that it can be safely decremented to one after it is used for the walk operation. The new fid will still be attached to the root dentry when v9fs_fid_lookup_with_uid() returns so a final refcount of one is correct/expected. Link: https://lkml.kernel.org/r/20220527000003.355812-2-tyhicks@linux.microsoft.com Link: https://lkml.kernel.org/r/20220612085330.1451496-4-asmadeus@codewreck.org Fixes: 6636b6dcc3db ("9p: add refcount to p9_fid struct") Cc: stable@vger.kernel.org Signed-off-by: Tyler Hicks <tyhicks@linux.microsoft.com> Reviewed-by: Christian Schoenebeck <linux_oss@crudebyte.com> [Dominique: fix clunking fid multiple times discussed in second link] Signed-off-by: Dominique Martinet <asmadeus@codewreck.org> 2022-01-30T13:13:37+00:00 Dominique Martinet asmadeus@codewreck.org 2022-01-29T09:42:59+00:00 urn:sha1:22e424feb6658c5d6789e45121830357809c59cb 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>