Re: [PATCH net-next v4 1/1] af_unix: Do not wait for garbage collector in sendmsg()

Kuniyuki Iwashima <[email protected]> writes:

> On Fri, Aug 7, 2026 at 6:07 PM Jakub Kicinski <[email protected]> wrote:
>>
>> On Tue,  4 Aug 2026 08:46:16 +0200 Nam Cao wrote:
>> > AF_UNIX sockets' sendmsg() schedules and blocks on the garbage collector if
>> > user has too many inflight unix sockets and there is cyclic reference in
>> > the system. This causes real-time issues, as cyclic reference can be
>> > created by any task in the system, and high priority tasks who do need to
>> > send lots of AF_UNIX sockets get blocked by the garbage collector which
>> > runs as workqueue, causing a priority inversion scenario.
>>
>> Hi Kuniyuki! Any thoughts?
>
> flush_work() makes an insane process slow down by itself and
> the sane users (whose peers receive fd in timely manner) can
> likely acquire the gc lock before insane users.

As mentioned in the cover letter, our definition of "sane users" is
quite arbitrary. I acknowledge that it likely cover most users out
there, possibly all of them. But we can never tell for sure.

> The commit message assumes the GC is low priority,

GC runs as workqueue and thus is low priority.

> and it will be easier to trigger OOM and soft lockup without the
> penalty.

Sorry, perhaps I am still confused somewhere, but how can OOM or soft
lockup be triggered?

At best (or worst?), a task can make the GC iterates over RLIMIT_NOFILE
inflight sockets, so there wouldn't be a soft lockup.

And the number of inflight sockets is capped at RLIMIT_NOFILE, so there
wouldn't be an OOM issue either.

> If priority inversion on RT kernel is the only problem here, there will
> be more flush_work() instances triggered from userspace,

Yes, you are correct and this happens often. The solution usually is
avoiding workqueue. Some times we replace the workqueue with a dedicated
kthread, other times we drop the workqueue and execute the work
synchronously. Otherwise we accept that such API is not real-time-safe
and should not be used by real-time application (we have on-going work
in run-time verification monitors that tell user if they are using an
unsafe API).

> and the real problem is that flush_work() does not implement priority
> inheritance like mutex.

This idea has been brought up in the past. Unfortunately it is no easy
feat.

Nam