Re: [PATCH net-next v2 3/3] af_unix: Clean up unix_schedule_gc()

sashiko-bot@kernel.org writes:

[Severity: High]
Does this call trigger the garbage collector for every exiting task in the
system?

If an unprivileged user creates a live AF_UNIX cyclic reference and leaves
them open, while queueing a large number of normal inflight sockets up to
RLIMIT_NOFILE, the live cycle causes unix_graph_state to persistently be
UNIX_GRAPH_CYCLIC.

Every task exit would then constantly queue unix_gc_work, which executes
unix_walk_scc_fast() under the unix_gc_lock spinlock, iterating over all
inflight sockets:

net/unix/garbage.c:unix_walk_scc_fast() {
    ...
    while (!list_empty(&unix_unvisited_vertices)) {
    ...
}

Could this O(N) loop iterating over all inflight sockets while holding the
unix_gc_lock cause severe lock contention and a system-wide performance
degradation for any AF_UNIX operations like sendmsg and recvmsg that block
on this lock?

Yes. But this is also a pre-existing issue. An unprivileged user can
already create a huge live circle, and then repeatedly create and close
a AF_UNIX socket which constantly schedules the garbage collector.

Perhaps we should think about a GC scheduling policy. Perhaps like other
garbage collector designs which get scheduled when memory runs low, or
maybe periodic? I can put this on my todo list.

Nam