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

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