From: Nam Cao <namcao@linutronix.de>
To: Paolo Abeni <pabeni@redhat.com>,
Kuniyuki Iwashima <kuniyu@google.com>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Simon Horman <horms@kernel.org>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rt-devel@lists.linux.dev
Subject: Re: [PATCH net-next v3 1/3] af_unix: Schedule the garbage collector at task exit
Date: Wed, 29 Jul 2026 17:49:18 +0200 [thread overview]
Message-ID: <87wludx0ch.fsf@yellow.woof> (raw)
In-Reply-To: <e9709a13-9fd9-4ee3-88b0-9cc56a1ca07c@redhat.com>
Paolo Abeni <pabeni@redhat.com> writes:
> Sashiko noted this can cause relevant regressions:
>
> https://sashiko.dev/#/patchset/cover.1784712370.git.namcao%40linutronix.de
>
> Generally speaking hooking the unix GC at task exit time does not feel
> right (layering violation). Perhaps scheduling the GC with a reasonable
> timeout in unix_update_graph() would be better?
unix_update_graph() doesn't work. In the reproducer, the sockets'
refcount do not drop to zero and unix_update_graph() is not called.
Thinking about this again, I am tempted to add a close() call back to
struct file_operations and we schedule the GC (with some timeout) in
that callback.
Or we can also periodically run the GC. Or we just ignore this issue, it
is capped by RLIMIT_NOFILE anyway.
I don't really like any of the option. If someone has an idea, please do
let me know.
Nam
next prev parent reply other threads:[~2026-07-29 15:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-22 9:31 [PATCH net-next v3 0/3] af_unix: Fix priority inversion issue Nam Cao
2026-07-22 9:31 ` [PATCH net-next v3 1/3] af_unix: Schedule the garbage collector at task exit Nam Cao
2026-07-28 9:50 ` Paolo Abeni
2026-07-29 15:49 ` Nam Cao [this message]
2026-07-22 9:31 ` [PATCH net-next v3 2/3] af_unix: Do not wait for garbage collector in sendmsg() Nam Cao
2026-07-22 9:31 ` [PATCH net-next v3 3/3] af_unix: Clean up unix_schedule_gc() Nam Cao
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=87wludx0ch.fsf@yellow.woof \
--to=namcao@linutronix.de \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/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