mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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 1/3] af_unix: Schedule the garbage collector at task exit
Date: Sat, 18 Jul 2026 06:27:35 +0000	[thread overview]
Message-ID: <20260718062736.199E41F000E9@smtp.kernel.org> (raw)
In-Reply-To: <d500ff36af658ad412e5d6f8d5665070359ef68e.1784268931.git.namcao@linutronix.de>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The patch reuses `unix_schedule_gc()` in `do_exit()`, but its `gc_in_progress` optimization introduces a race condition that leaks cyclic sockets during concurrent task exits.
--

--- Patch [1]: [PATCH net-next v2 1/3] af_unix: Schedule the garbage collector at task exit ---
commit a622ecdd6ba9403d5e403273ed947355870471a8
Author: Nam Cao <namcao@linutronix.de>

af_unix: Schedule the garbage collector at task exit

This commit aims to resolve an issue where dead cyclic reference AF_UNIX
sockets stay behind indefinitely when a task exits. It does so by
scheduling the garbage collector during task exit, after the task's file
descriptors have been closed.

> diff --git a/kernel/exit.c b/kernel/exit.c
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -997,6 +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() */

[Severity: Medium]
Will this race with concurrent task exits and leak cyclic sockets?

In net/unix/garbage.c, unix_schedule_gc() only queues the work if a garbage
collection is not already running:

void unix_schedule_gc(void)
{
        if (!READ_ONCE(gc_in_progress))
                queue_work(system_dfl_wq, &unix_gc_work);
}

If Task A and Task B exit concurrently with dead cyclic sockets:

Task A calls unix_schedule_gc() and triggers the work, which sets
gc_in_progress to true.

Task B then calls unix_schedule_gc() while the GC is running, observes
gc_in_progress is true, and silently skips queuing the work.

Task B's newly dead cycles might be missed by the currently running GC pass.
Since no new GC is queued by Task B, won't those sockets stay behind
indefinitely until another unrelated task exits, defeating the purpose of
the patch for concurrent exits?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1784268931.git.namcao@linutronix.de?part=1

  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 [this message]
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

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.199E41F000E9@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome