kernel.git/net/9p/trans_virtio.c, branch linux-rolling-stable

9p: convert to the new mount API

2025-11-03T07:49:53Z

Convert 9p to the new mount API. This patch consolidates all parsing into fs/9p/v9fs.c, which stores all results into a filesystem context which can be passed to the various transports as needed. Some of the parsing helper functions such as get_cache_mode() have been eliminated in favor of using the new mount API's enum param type, for simplicity. Signed-off-by: Eric Sandeen Message-ID: <20251010214222.1347785-5-sandeen@redhat.com> [ Dominique: handled source explicitly as per follow-up discussion ] Signed-off-by: Dominique Martinet

net/9p: cleanup: change p9_trans_module->def to bool

2025-11-03T07:49:29Z

'->def' is only ever used as a true/false flag Reported-by: Christophe JAILLET Message-ID: <20251103-v9fs_trans_def_bool-v1-1-f33dc7ed9e81@codewreck.org> Signed-off-by: Dominique Martinet

9p: Use kvmalloc for message buffers on supported transports

2025-11-03T07:41:24Z

While developing a 9P server (https://github.com/Barre/ZeroFS) and testing it under high-load, I was running into allocation failures. The failures occur even with plenty of free memory available because kmalloc requires contiguous physical memory. This results in errors like: ls: page allocation failure: order:7, mode:0x40c40(GFP_NOFS|__GFP_COMP) This patch introduces a transport capability flag (supports_vmalloc) that indicates whether a transport can work with vmalloc'd buffers (non-physically contiguous memory). Transports requiring DMA should leave this flag as false. The fd-based transports (tcp, unix, fd) set this flag to true, and p9_fcall_init will use kvmalloc instead of kmalloc for these transports. This allows the allocator to fall back to vmalloc when contiguous physical memory is not available. Additionally, if kmem_cache_alloc fails, the code falls back to kvmalloc for transports that support it. Signed-off-by: Pierre Barre Reviewed-by: Christian Schoenebeck Message-ID: Signed-off-by: Dominique Martinet

net: 9p: virtio: drop owner assignment

2024-05-22T12:31:17Z

virtio core already sets the .owner, so driver does not need to. Signed-off-by: Krzysztof Kozlowski Message-Id: <20240331-module-owner-virtio-v2-18-98f04bfaf46a@linaro.org> Signed-off-by: Michael S. Tsirkin

9p: virtio: skip incrementing unused variable

2023-07-20T19:14:50Z

Fix the following scan-build warning: net/9p/trans_virtio.c:504:3: warning: Value stored to 'in' is never read [deadcode.DeadStores] in += pack_sg_list_p(chan->sg, out + in, VIRTQUEUE_NUM, ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I'm honestly not 100% sure about this one; I'm tempted to think we could (should?) just check the return value of pack_sg_list_p to skip the in_sgs++ and setting sgs[] if it didn't process anything, but I'm not sure it should ever happen so this is probably fine as is. Just removing the assignment at least makes it clear the return value isn't used, so it's an improvement in terms of readability. Reviewed-by: Simon Horman Signed-off-by: Dominique Martinet Signed-off-by: Eric Van Hensbergen

9p: virtio: make sure 'offs' is initialized in zc_request

2023-07-20T19:14:50Z

Similarly to the previous patch: offs can be used in handle_rerrors without initializing on small payloads; in this case handle_rerrors will not use it because of the size check, but it doesn't hurt to make sure it is zero to please scan-build. This fixes the following warning: net/9p/trans_virtio.c:539:3: warning: 3rd function call argument is an uninitialized value [core.CallAndMessage] handle_rerror(req, in_hdr_len, offs, in_pages); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Reviewed-by: Simon Horman Signed-off-by: Dominique Martinet Signed-off-by: Eric Van Hensbergen

9p: virtio: fix unlikely null pointer deref in handle_rerror

2023-07-20T19:14:50Z

handle_rerror can dereference the pages pointer, but it is not necessarily set for small payloads. In practice these should be filtered out by the size check, but might as well double-check explicitly. This fixes the following scan-build warnings: net/9p/trans_virtio.c:401:24: warning: Dereference of null pointer [core.NullDereference] memcpy_from_page(to, *pages++, offs, n); ^~~~~~~~ net/9p/trans_virtio.c:406:23: warning: Dereference of null pointer (loaded from variable 'pages') [core.NullDereference] memcpy_from_page(to, *pages, offs, size); ^~~~~~ Reviewed-by: Simon Horman Signed-off-by: Dominique Martinet Signed-off-by: Eric Van Hensbergen

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

2022-12-13T04:02:15Z

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

9p/net: Remove unneeded idr.h #include

2022-12-02T14:59:20Z

The 9p net files don't use IDR or IDA functionalities. So there is no point in including . Remove it. Link: https://lkml.kernel.org/r/9e386018601d7e4a9e5d7da8fc3e9555ebb25c87.1669560387.git.christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET Reviewed-by: Christian Schoenebeck Signed-off-by: Dominique Martinet

net/9p: add 'pooled_rbuffers' flag to struct p9_trans_module

2022-10-04T22:05:41Z

This is a preparatory change for the subsequent patch: the RDMA transport pulls the buffers for its 9p response messages from a shared pool. [1] So this case has to be considered when choosing an appropriate response message size in the subsequent patch. Link: https://lore.kernel.org/all/Ys3jjg52EIyITPua@codewreck.org/ [1] Link: https://lkml.kernel.org/r/79d24310226bc4eb037892b5c097ec4ad4819a03.1657920926.git.linux_oss@crudebyte.com Signed-off-by: Christian Schoenebeck Signed-off-by: Dominique Martinet