From: sashiko-bot@kernel.org
To: "Nam Cao" <namcao@linutronix.de>
Cc: linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev
Subject: Re: [PATCH net-next v2 3/3] af_unix: Clean up unix_schedule_gc()
Date: Sat, 18 Jul 2026 06:27:36 +0000 [thread overview]
Message-ID: <20260718062736.C97A31F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <548b1b624b13fc2582b1236a2c656e4261eb2525.1784268931.git.namcao@linutronix.de>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unconditional garbage collector scheduling in `do_exit()` causes severe lock contention and system-wide DoS when a live AF_UNIX cycle exists.
--
--- Patch [3]: [PATCH net-next v2 3/3] af_unix: Clean up unix_schedule_gc() ---
commit 649d449e71c2d27619a029df46ed559c6fa2ae0c
Author: Nam Cao <namcao@linutronix.de>
af_unix: Clean up unix_schedule_gc()
This patch simplifies unix_schedule_gc() by removing its parameter,
as it was only called with NULL. The user struct parameter and the
logic depending on it are removed.
[ ... ]
> diff --git a/kernel/exit.c b/kernel/exit.c
> index b507b2a24693a..f3bee7cc637d0 100644
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -998,7 +998,7 @@ void __noreturn do_exit(long code)
> exit_sem(tsk);
> exit_shm(tsk);
> exit_files(tsk);
> - unix_schedule_gc(NULL); /* Must be after exit_files() */
> + unix_schedule_gc(); /* Must be after exit_files() */
[Severity: High]
Does this call trigger the garbage collector for every exiting task in the
system?
If an unprivileged user creates a live AF_UNIX cyclic reference and leaves
them open, while queueing a large number of normal inflight sockets up to
RLIMIT_NOFILE, the live cycle causes unix_graph_state to persistently be
UNIX_GRAPH_CYCLIC.
Every task exit would then constantly queue unix_gc_work, which executes
unix_walk_scc_fast() under the unix_gc_lock spinlock, iterating over all
inflight sockets:
net/unix/garbage.c:unix_walk_scc_fast() {
...
while (!list_empty(&unix_unvisited_vertices)) {
...
}
Could this O(N) loop iterating over all inflight sockets while holding the
unix_gc_lock cause severe lock contention and a system-wide performance
degradation for any AF_UNIX operations like sendmsg and recvmsg that block
on this lock?
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1784268931.git.namcao@linutronix.de?part=3
prev parent reply other threads:[~2026-07-18 6:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-17 6:27 [PATCH net-next v2 0/3] af_unix: Fix priority inversion issue Nam Cao
2026-07-17 6:27 ` [PATCH net-next v2 1/3] af_unix: Schedule the garbage collector at task exit Nam Cao
2026-07-17 6:45 ` Nam Cao
2026-07-18 6:27 ` sashiko-bot
2026-07-17 6:27 ` [PATCH net-next v2 2/3] af_unix: Do not wait for garbage collector in sendmsg() Nam Cao
2026-07-18 6:27 ` sashiko-bot
2026-07-17 6:27 ` [PATCH net-next v2 3/3] af_unix: Clean up unix_schedule_gc() Nam Cao
2026-07-18 6:27 ` sashiko-bot [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260718062736.C97A31F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=namcao@linutronix.de \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.