Re: [PATCH net 4/5] afs: Fix further netns teardown to cancel the preallocation charger
From: Simon Horman <horms@kernel.org>
Date: 2026-06-18 09:29:17
Also in:
lkml
This is an AI-generated review of your patch. The human sending this email has considered the AI review valid, or at least plausible. Full review at: https://sashiko.dev --- afs: Fix further netns teardown to cancel the preallocation charger This commit modifies the afs network namespace teardown process to wait for the preallocation charger work item. It addresses a small window where the work item could be requeued after being cancelled by flushing the workqueue on which the charger runs. Link: https://sashiko.dev/#/patchset/20260609140911.838677-1-dhowells%40redhat.com
quoted hunk ↗ jump to hunk
diff --git a/fs/afs/rxrpc.c b/fs/afs/rxrpc.c --- a/fs/afs/rxrpc.c +++ b/fs/afs/rxrpc.c@@ -130,6 +130,7 @@ void afs_close_socket(struct afs_net *net) cancel_work_sync(&net->charge_preallocation_work); kernel_listen(net->socket, 0); flush_workqueue(afs_async_calls); + flush_workqueue(afs_wq);
[Severity: High]
Will flushing the system-wide global workqueue here cause cross-namespace
stalls during teardown?
It appears afs_wq is allocated once in afs_init() as a system-wide workqueue
shared by all AFS network namespaces:
fs/afs/main.c:afs_init() {
...
afs_wq = alloc_workqueue("afs", WQ_PERCPU, 0);
...
}
Other namespaces use afs_wq for operations like cell management, which can
block for tens of seconds waiting for userspace DNS lookups via the
request_key mechanism.
Since afs_close_socket() runs in the context of the global cleanup_net
worker thread, does this stall the destruction of all network namespaces
system-wide until unrelated AFS work across the entire system finishes?
Would it be safer to explicitly call
cancel_work_sync(&net->charge_preallocation_work) a second time here instead
of flushing the shared queue?