Re: [PATCH net-next v2 1/3] af_unix: Schedule the garbage collector at task exit

[email protected] writes:
> [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?

Yes, this is a pre-existing issue and has been discussed at:
https://lore.kernel.org/lkml/[email protected]/

The solution would be removing gc_in_progress and always calling queue_work().

Since this is not a critical issue, I would fix that after this series
is done.

Nam