kernel/git/stable/linux.git/net/9p/client.c, branch linux-6.4.y

9p: Add additional debug flags and open modes

2023-03-27T02:33:48+00:00

Add some additional debug flags to assist with debugging cache changes. Also add some additional open modes so we can track cache state in fids more directly. Signed-off-by: Eric Van Hensbergen

net/9p: fix bug in client create for .L

2023-02-24T13:42:40+00:00

We are supposed to set fid->mode to reflect the flags that were used to open the file. We were actually setting it to the creation mode which is the default perms of the file not the flags the file was opened with. Signed-off-by: Eric Van Hensbergen Reviewed-by: Dominique Martinet

net/9p: Adjust maximum MSIZE to account for p9 header

2023-02-23T22:39:36+00:00

Add maximum p9 header size to MSIZE to make sure we can have page aligned data. Signed-off-by: Eric Van Hensbergen Reviewed-by: Dominique Martinet

Merge tag '9p-for-6.2-rc1' of https://github.com/martinetd/linux

2022-12-23T19:39:18+00:00

Pull 9p updates from Dominique Martinet: - improve p9_check_errors to check buffer size instead of msize when possible (e.g. not zero-copy) - some more syzbot and KCSAN fixes - minor headers include cleanup * tag '9p-for-6.2-rc1' of https://github.com/martinetd/linux: 9p/client: fix data race on req->status net/9p: fix response size check in p9_check_errors() net/9p: distinguish zero-copy requests 9p/xen: do not memcpy header into req->rc 9p: set req refcount to zero to avoid uninitialized usage 9p/net: Remove unneeded idr.h #include 9p/fs: Remove unneeded idr.h #include

9p/client: fix data race on req->status

2022-12-13T04:02:15+00:00

KCSAN reported a race between writing req->status in p9_client_cb and accessing it in p9_client_rpc's wait_event. Accesses to req itself is protected by the data barrier (writing req fields, write barrier, writing status // reading status, read barrier, reading other req fields), but status accesses themselves apparently also must be annotated properly with WRITE_ONCE/READ_ONCE when we access it without locks. Follows: - error paths writing status in various threads all can notify p9_client_rpc, so these all also need WRITE_ONCE - there's a similar read loop in trans_virtio for zc case that also needs READ_ONCE - other reads in trans_fd should be protected by the trans_fd lock and lists state machine, as corresponding writers all are within trans_fd and should be under the same lock. If KCSAN complains on them we likely will have something else to fix as well, so it's better to leave them unmarked and look again if required. Link: https://lkml.kernel.org/r/20221205124756.426350-1-asmadeus@codewreck.org Reported-by: Naresh Kamboju Suggested-by: Marco Elver Acked-by: Marco Elver Reviewed-by: Christian Schoenebeck Signed-off-by: Dominique Martinet

net/9p: fix response size check in p9_check_errors()

2022-12-05T22:31:18+00:00

Since commit 60ece0833b6c ("net/9p: allocate appropriate reduced message buffers") it is no longer appropriate to check server's response size against msize. Check against the previously allocated buffer capacity instead. - Omit this size check entirely for zero-copy messages, as those always allocate 4k (P9_ZC_HDR_SZ) linear buffers which are not used for actual payload and can be much bigger than 4k. - Replace p9_debug() by pr_err() to make sure this message is always printed in case this error is triggered. - Add 9p message type to error message to ease investigation. Link: https://lkml.kernel.org/r/e0edec84b1c80119ae937ce854b4f5f6dbe2d08c.1669144861.git.linux_oss@crudebyte.com Signed-off-by: Christian Schoenebeck Tested-by: Stefano Stabellini Reported-by: kernel test robot Signed-off-by: Dominique Martinet

net/9p: distinguish zero-copy requests

2022-12-05T22:30:55+00:00

Add boolean `zc` member to struct p9_fcall to distinguish zero-copy messages (not using the linear `sdata` buffer for message payload) from regular messages (which do copy message payload to `sdata` before being further processed). This new member is appended to end of structure to avoid inserting huge padding in generated layout. Link: https://lkml.kernel.org/r/8f2a5c12a446c3b544da64e0b1550e1fb2d6f972.1669144861.git.linux_oss@crudebyte.com Signed-off-by: Christian Schoenebeck Tested-by: Stefano Stabellini Signed-off-by: Dominique Martinet

9p: set req refcount to zero to avoid uninitialized usage

2022-12-02T14:59:20+00:00

When a new request is allocated, the refcount will be zero if it is reused, but if the request is newly allocated from slab, it is not fully initialized before being added to idr. If the p9_read_work got a response before the refcount initiated. It will use a uninitialized req, which will result in a bad request data struct. Here is the logs from syzbot. Corrupted memory at 0xffff88807eade00b [ 0xff 0x07 0x00 0x00 0x00 0x00 0x00 0x00 . . . . . . . . ] (in kfence-#110): p9_fcall_fini net/9p/client.c:248 [inline] p9_req_put net/9p/client.c:396 [inline] p9_req_put+0x208/0x250 net/9p/client.c:390 p9_client_walk+0x247/0x540 net/9p/client.c:1165 clone_fid fs/9p/fid.h:21 [inline] v9fs_fid_xattr_set+0xe4/0x2b0 fs/9p/xattr.c:118 v9fs_xattr_set fs/9p/xattr.c:100 [inline] v9fs_xattr_handler_set+0x6f/0x120 fs/9p/xattr.c:159 __vfs_setxattr+0x119/0x180 fs/xattr.c:182 __vfs_setxattr_noperm+0x129/0x5f0 fs/xattr.c:216 __vfs_setxattr_locked+0x1d3/0x260 fs/xattr.c:277 vfs_setxattr+0x143/0x340 fs/xattr.c:309 setxattr+0x146/0x160 fs/xattr.c:617 path_setxattr+0x197/0x1c0 fs/xattr.c:636 __do_sys_setxattr fs/xattr.c:652 [inline] __se_sys_setxattr fs/xattr.c:648 [inline] __ia32_sys_setxattr+0xc0/0x160 fs/xattr.c:648 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 entry_SYSENTER_compat_after_hwframe+0x70/0x82 Below is a similar scenario, the scenario in the syzbot log looks more complicated than this one, but this patch can fix it. T21124 p9_read_work ======================== second trans ================================= p9_client_walk p9_client_rpc p9_client_prepare_req p9_tag_alloc req = kmem_cache_alloc(p9_req_cache, GFP_NOFS); tag = idr_alloc << preempted >> req->tc.tag = tag; /* req->[refcount/tag] == uninitialized */ m->rreq = p9_tag_lookup(m->client, m->rc.tag); /* increments uninitalized refcount */ refcount_set(&req->refcount, 2); /* cb drops one ref */ p9_client_cb(req) /* reader thread drops its ref: request is incorrectly freed */ p9_req_put(req) /* use after free and ref underflow */ p9_req_put(req) To fix it, we can initialize the refcount to zero before add to idr. Link: https://lkml.kernel.org/r/20221201033310.18589-1-schspa@gmail.com Cc: stable@vger.kernel.org # 6.0+ due to 6cda12864cb0 ("9p: Drop kref usage") Fixes: 728356dedeff ("9p: Add refcount to p9_req_t") Reported-by: syzbot+8f1060e2aaf8ca55220b@syzkaller.appspotmail.com Signed-off-by: Schspa Shi Reviewed-by: Christian Schoenebeck Signed-off-by: Dominique Martinet

use less confusing names for iov_iter direction initializers

2022-11-25T18:01:55+00:00

READ/WRITE proved to be actively confusing - the meanings are "data destination, as used with read(2)" and "data source, as used with write(2)", but people keep interpreting those as "we read data from it" and "we write data to it", i.e. exactly the wrong way. Call them ITER_DEST and ITER_SOURCE - at least that is harder to misinterpret... Signed-off-by: Al Viro

net/9p: allocate appropriate reduced message buffers

2022-10-04T22:05:41+00:00

So far 'msize' was simply used for all 9p message types, which is far too much and slowed down performance tremendously with large values for user configurable 'msize' option. Let's stop this waste by using the new p9_msg_buf_size() function for allocating more appropriate, smaller buffers according to what is actually sent over the wire. Only exception: RDMA transport is currently excluded from this message size optimization - for its response buffers that is - as RDMA transport would not cope with it, due to its response buffers being pulled from a shared pool. [1] Link: https://lore.kernel.org/all/Ys3jjg52EIyITPua@codewreck.org/ [1] Link: https://lkml.kernel.org/r/3f51590535dc96ed0a165b8218c57639cfa5c36c.1657920926.git.linux_oss@crudebyte.com Signed-off-by: Christian Schoenebeck Signed-off-by: Dominique Martinet