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

sashiko-bot@kernel.org 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/871pde3o54.fsf@yellow.woof/ (local)

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