linux.git/net/9p, branch v6.16 Linux kernel source tree netfs: Fix the request's work item to not require a ref 2025-05-21T12:35:20+00:00 David Howells dhowells@redhat.com 2025-05-19T09:07:03+00:00 20d72b00ca814d748f5663484e5c53bb2bf37a3a When the netfs_io_request struct's work item is queued, it must be supplied with a ref to the work item struct to prevent it being deallocated whilst on the queue or whilst it is being processed. This is tricky to manage as we have to get a ref before we try and queue it and then we may find it's already queued and is thus already holding a ref - in which case we have to try and get rid of the ref again. The problem comes if we're in BH or IRQ context and need to drop the ref: if netfs_put_request() reduces the count to 0, we have to do the cleanup - but the cleanup may need to wait. Fix this by adding a new work item to the request, ->cleanup_work, and dispatching that when the refcount hits zero. That can then synchronously cancel any outstanding work on the main work item before doing the cleanup. Adding a new work item also deals with another problem upstream where it's sometimes changing the work func in the put function and requeuing it - which has occasionally in the past caused the cleanup to happen incorrectly. As a bonus, this allows us to get rid of the 'was_async' parameter from a bunch of functions. This indicated whether the put function might not be permitted to sleep. Fixes: 3d3c95046742 ("netfs: Provide readahead and readpage netfs helpers") Signed-off-by: David Howells <dhowells@redhat.com> Link: https://lore.kernel.org/20250519090707.2848510-4-dhowells@redhat.com cc: Paulo Alcantara <pc@manguebit.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: Steve French <stfrench@microsoft.com> cc: linux-cifs@vger.kernel.org cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner <brauner@kernel.org> 
When the netfs_io_request struct's work item is queued, it must be supplied
with a ref to the work item struct to prevent it being deallocated whilst
on the queue or whilst it is being processed.  This is tricky to manage as
we have to get a ref before we try and queue it and then we may find it's
already queued and is thus already holding a ref - in which case we have to
try and get rid of the ref again.

The problem comes if we're in BH or IRQ context and need to drop the ref:
if netfs_put_request() reduces the count to 0, we have to do the cleanup -
but the cleanup may need to wait.

Fix this by adding a new work item to the request, ->cleanup_work, and
dispatching that when the refcount hits zero.  That can then synchronously
cancel any outstanding work on the main work item before doing the cleanup.

Adding a new work item also deals with another problem upstream where it's
sometimes changing the work func in the put function and requeuing it -
which has occasionally in the past caused the cleanup to happen
incorrectly.

As a bonus, this allows us to get rid of the 'was_async' parameter from a
bunch of functions.  This indicated whether the put function might not be
permitted to sleep.

Fixes: 3d3c95046742 ("netfs: Provide readahead and readpage netfs helpers")
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://lore.kernel.org/20250519090707.2848510-4-dhowells@redhat.com
cc: Paulo Alcantara <pc@manguebit.com>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: Steve French <stfrench@microsoft.com>
cc: linux-cifs@vger.kernel.org
cc: netfs@lists.linux.dev
cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
9p: Use hashtable.h for hash_errmap 2025-03-22T21:20:48+00:00 Sasha Levin sashal@kernel.org 2025-03-20T14:52:00+00:00 ad2e2a77dcc7912c737a07fe061d93c414c6745e Convert hash_errmap in error.c to use the generic hashtable implementation from hashtable.h instead of the manual hlist_head array implementation. This simplifies the code and makes it more maintainable by using the standard hashtable API and removes the need for manual hash table management. Signed-off-by: Sasha Levin <sashal@kernel.org> Message-ID: <20250320145200.3124863-1-sashal@kernel.org> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org> 
Convert hash_errmap in error.c to use the generic hashtable
implementation from hashtable.h instead of the manual hlist_head array
implementation.

This simplifies the code and makes it more maintainable by using the
standard hashtable API and removes the need for manual hash table
management.

Signed-off-by: Sasha Levin <sashal@kernel.org>
Message-ID: <20250320145200.3124863-1-sashal@kernel.org>
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
9p/trans_fd: mark concurrent read and writes to p9_conn->err 2025-03-19T12:20:31+00:00 Ignacio Encinas ignacio@iencinas.com 2025-03-18T21:39:02+00:00 fbc0283fbeae27b88448c90305e738991457fee2 Writes for the error value of a connection are spinlock-protected inside p9_conn_cancel, but lockless reads are present elsewhere to avoid performing unnecessary work after an error has been met. Mark the write and lockless reads to make KCSAN happy. Mark the write as exclusive following the recommendation in "Lock-Protected Writes with Lockless Reads" in tools/memory-model/Documentation/access-marking.txt while we are at it. Mark p9_fd_request and p9_conn_cancel m->err reads despite the fact that they do not race with concurrent writes for stylistic reasons. Reported-by: syzbot+d69a7cc8c683c2cb7506@syzkaller.appspotmail.com Reported-by: syzbot+483d6c9b9231ea7e1851@syzkaller.appspotmail.com Signed-off-by: Ignacio Encinas <ignacio@iencinas.com> Message-ID: <20250318-p9_conn_err_benign_data_race-v3-1-290bb18335cc@iencinas.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org> 
Writes for the error value of a connection are spinlock-protected inside
p9_conn_cancel, but lockless reads are present elsewhere to avoid
performing unnecessary work after an error has been met.

Mark the write and lockless reads to make KCSAN happy. Mark the write as
exclusive following the recommendation in "Lock-Protected Writes with
Lockless Reads" in tools/memory-model/Documentation/access-marking.txt
while we are at it.

Mark p9_fd_request and p9_conn_cancel m->err reads despite the fact that
they do not race with concurrent writes for stylistic reasons.

Reported-by: syzbot+d69a7cc8c683c2cb7506@syzkaller.appspotmail.com
Reported-by: syzbot+483d6c9b9231ea7e1851@syzkaller.appspotmail.com
Signed-off-by: Ignacio Encinas <ignacio@iencinas.com>
Message-ID: <20250318-p9_conn_err_benign_data_race-v3-1-290bb18335cc@iencinas.com>
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
9p/net: return error on bogus (longer than requested) replies 2025-03-19T12:20:25+00:00 Dominique Martinet asmadeus@codewreck.org 2025-03-16T21:51:06+00:00 ad6d4558a7112af9e5f6727ac24fd8cd17469739 Up until now we've been considering longer than requested replies as acceptable, printing a message and just truncating the data, but it makes more sense to consider these an error. Make these fail with EIO instead. Suggested-by: Christian Schoenebeck <linux_oss@crudebyte.com> Message-ID: <20250317-p9_bogus_io_error-v1-1-9639f6d1561f@codewreck.org> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org> 
Up until now we've been considering longer than requested replies as
acceptable, printing a message and just truncating the data,
but it makes more sense to consider these an error.

Make these fail with EIO instead.

Suggested-by: Christian Schoenebeck <linux_oss@crudebyte.com>
Message-ID: <20250317-p9_bogus_io_error-v1-1-9639f6d1561f@codewreck.org>
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
9p/net: fix improper handling of bogus negative read/write replies 2025-03-19T12:19:59+00:00 Dominique Martinet asmadeus@codewreck.org 2025-03-19T11:20:15+00:00 d0259a856afca31d699b706ed5e2adf11086c73b In p9_client_write() and p9_client_read_once(), if the server incorrectly replies with success but a negative write/read count then we would consider written (negative) <= rsize (positive) because both variables were signed. Make variables unsigned to avoid this problem. The reproducer linked below now fails with the following error instead of a null pointer deref: 9pnet: bogus RWRITE count (4294967295 > 3) Reported-by: Robert Morris <rtm@mit.edu> Closes: https://lore.kernel.org/16271.1734448631@26-5-164.dynamic.csail.mit.edu Message-ID: <20250319-9p_unsigned_rw-v3-1-71327f1503d0@codewreck.org> Reviewed-by: Christian Schoenebeck <linux_oss@crudebyte.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org> 
In p9_client_write() and p9_client_read_once(), if the server
incorrectly replies with success but a negative write/read count then we
would consider written (negative) <= rsize (positive) because both
variables were signed.

Make variables unsigned to avoid this problem.

The reproducer linked below now fails with the following error instead
of a null pointer deref:
9pnet: bogus RWRITE count (4294967295 > 3)

Reported-by: Robert Morris <rtm@mit.edu>
Closes: https://lore.kernel.org/16271.1734448631@26-5-164.dynamic.csail.mit.edu
Message-ID: <20250319-9p_unsigned_rw-v3-1-71327f1503d0@codewreck.org>
Reviewed-by: Christian Schoenebeck <linux_oss@crudebyte.com>
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
net/9p/fd: support ipv6 for trans=tcp 2025-01-20T13:05:25+00:00 Joshua Murphy joshuamurphy@posteo.net 2025-01-18T19:12:36+00:00 a22a29655c42d0263a7a84d5d808bfd55f20c53a Allows specifying an IPv6 address when mounting a remote 9p file system. Signed-off-by: Joshua Murphy <joshuamurphy@posteo.net> Message-ID: <20250118192122.327-2-joshuamurphy@posteo.net> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org> 
Allows specifying an IPv6 address when mounting a remote 9p file system.

Signed-off-by: Joshua Murphy <joshuamurphy@posteo.net>
Message-ID: <20250118192122.327-2-joshuamurphy@posteo.net>
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
net/9p/usbg: allow building as standalone module 2024-11-22T14:48:14+00:00 Dominique Martinet asmadeus@codewreck.org 2024-11-22T14:43:02+00:00 e0260d530b73ee969ae971d14daa02376dcfc93f There is no reason only the usbg transport would not be its own module, so make it tristate. In particular, this fixes a couple of issues the current bool had: - trans_usbg was apparently not compiled at all when NET_9P=m - the workaround added in commit 2193ede180dd ("net/9p/usbg: fix CONFIG_USB_GADGET dependency") became redundant because a tristate item cannot be built-in when its dependency is a module, so we can depend on USB_GADGET "normally" again. Cc: Michael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lkml.kernel.org/r/ZzhWRPDNwu225NWz@codewreck.org Message-ID: <20241122144754.1231919-1-asmadeus@codewreck.org> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org> 
There is no reason only the usbg transport would not be its own module,
so make it tristate.

In particular, this fixes a couple of issues the current bool had:
- trans_usbg was apparently not compiled at all when NET_9P=m
- the workaround added in commit 2193ede180dd ("net/9p/usbg: fix
CONFIG_USB_GADGET dependency") became redundant because a tristate item
cannot be built-in when its dependency is a module, so we can depend on
USB_GADGET "normally" again.

Cc: Michael Grzeschik <m.grzeschik@pengutronix.de>
Link: https://lkml.kernel.org/r/ZzhWRPDNwu225NWz@codewreck.org
Message-ID: <20241122144754.1231919-1-asmadeus@codewreck.org>
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
9p/xen: fix release of IRQ 2024-11-22T14:36:19+00:00 Alex Zenla alex@edera.dev 2024-11-21T22:51:00+00:00 e43c608f40c065b30964f0a806348062991b802d Kernel logs indicate an IRQ was double-freed. Pass correct device ID during IRQ release. Fixes: 71ebd71921e45 ("xen/9pfs: connect to the backend") Signed-off-by: Alex Zenla <alex@edera.dev> Signed-off-by: Alexander Merritt <alexander@edera.dev> Signed-off-by: Ariadne Conill <ariadne@ariadne.space> Reviewed-by: Juergen Gross <jgross@suse.com> Message-ID: <20241121225100.5736-1-alexander@edera.dev> [Dominique: remove confusing variable reset to 0] Signed-off-by: Dominique Martinet <asmadeus@codewreck.org> 
Kernel logs indicate an IRQ was double-freed.

Pass correct device ID during IRQ release.

Fixes: 71ebd71921e45 ("xen/9pfs: connect to the backend")
Signed-off-by: Alex Zenla <alex@edera.dev>
Signed-off-by: Alexander Merritt <alexander@edera.dev>
Signed-off-by: Ariadne Conill <ariadne@ariadne.space>
Reviewed-by: Juergen Gross <jgross@suse.com>
Message-ID: <20241121225100.5736-1-alexander@edera.dev>
[Dominique: remove confusing variable reset to 0]
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
9p/xen: fix init sequence 2024-11-21T12:11:39+00:00 Alex Zenla alex@edera.dev 2024-11-19T21:16:33+00:00 7ef3ae82a6ebbf4750967d1ce43bcdb7e44ff74b Large amount of mount hangs observed during hotplugging of 9pfs devices. The 9pfs Xen driver attempts to initialize itself more than once, causing the frontend and backend to disagree: the backend listens on a channel that the frontend does not send on, resulting in stalled processing. Only allow initialization of 9p frontend once. Fixes: c15fe55d14b3b ("9p/xen: fix connection sequence") Signed-off-by: Alex Zenla <alex@edera.dev> Signed-off-by: Alexander Merritt <alexander@edera.dev> Signed-off-by: Ariadne Conill <ariadne@ariadne.space> Reviewed-by: Juergen Gross <jgross@suse.com> Message-ID: <20241119211633.38321-1-alexander@edera.dev> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org> 
Large amount of mount hangs observed during hotplugging of 9pfs devices. The
9pfs Xen driver attempts to initialize itself more than once, causing the
frontend and backend to disagree: the backend listens on a channel that the
frontend does not send on, resulting in stalled processing.

Only allow initialization of 9p frontend once.

Fixes: c15fe55d14b3b ("9p/xen: fix connection sequence")
Signed-off-by: Alex Zenla <alex@edera.dev>
Signed-off-by: Alexander Merritt <alexander@edera.dev>
Signed-off-by: Ariadne Conill <ariadne@ariadne.space>
Reviewed-by: Juergen Gross <jgross@suse.com>
Message-ID: <20241119211633.38321-1-alexander@edera.dev>
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
net/9p/usbg: fix handling of the failed kzalloc() memory allocation 2024-11-16T08:23:19+00:00 Mirsad Todorovac mtodorovac69@gmail.com 2024-11-09T21:18:41+00:00 ff1060813d9347e8c45c8b8cff93a4dfdb6726ad On the linux-next, next-20241108 vanilla kernel, the coccinelle tool gave the following error report: ./net/9p/trans_usbg.c:912:5-11: ERROR: allocation function on line 911 returns NULL not ERR_PTR on failure kzalloc() failure is fixed to handle the NULL return case on the memory exhaustion. Fixes: a3be076dc174d ("net/9p/usbg: Add new usb gadget function transport") Cc: Michael Grzeschik <m.grzeschik@pengutronix.de> Cc: Eric Van Hensbergen <ericvh@kernel.org> Cc: Latchesar Ionkov <lucho@ionkov.net> Cc: Dominique Martinet <asmadeus@codewreck.org> Cc: Christian Schoenebeck <linux_oss@crudebyte.com> Cc: v9fs@lists.linux.dev Cc: linux-kernel@vger.kernel.org Signed-off-by: Mirsad Todorovac <mtodorovac69@gmail.com> Message-ID: <20241109211840.721226-2-mtodorovac69@gmail.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org> 
On the linux-next, next-20241108 vanilla kernel, the coccinelle tool gave the
following error report:

./net/9p/trans_usbg.c:912:5-11: ERROR: allocation function on line 911 returns
NULL not ERR_PTR on failure

kzalloc() failure is fixed to handle the NULL return case on the memory exhaustion.

Fixes: a3be076dc174d ("net/9p/usbg: Add new usb gadget function transport")
Cc: Michael Grzeschik <m.grzeschik@pengutronix.de>
Cc: Eric Van Hensbergen <ericvh@kernel.org>
Cc: Latchesar Ionkov <lucho@ionkov.net>
Cc: Dominique Martinet <asmadeus@codewreck.org>
Cc: Christian Schoenebeck <linux_oss@crudebyte.com>
Cc: v9fs@lists.linux.dev
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Mirsad Todorovac <mtodorovac69@gmail.com>
Message-ID: <20241109211840.721226-2-mtodorovac69@gmail.com>
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>