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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Removing `unix_schedule_gc()` from `unix_prepare_fpl()` prevents proactive garbage collection of cyclic AF_UNIX FDs.
--

--- Patch [2]: [PATCH net-next v2 2/3] af_unix: Do not wait for garbage collector in sendmsg() ---
commit beb11f61735b0b337472eab3fcd9041c544b30de
Author: Nam Cao <namcao@xxxxxxxxxxxxx>

af_unix: Do not wait for garbage collector in sendmsg()

This commit removes the unix_schedule_gc() call from unix_prepare_fpl()
during sendmsg(). The patch notes that previous soft lockup and OOM issues
are already mitigated by async garbage collection and RLIMIT_NOFILE checks.

> diff --git a/net/unix/garbage.c b/net/unix/garbage.c
> index 0783555e25266..f180c59b3da9d 100644
> --- a/net/unix/garbage.c
> +++ b/net/unix/garbage.c
> @@ -300,8 +300,6 @@ int unix_prepare_fpl(struct scm_fp_list *fpl)
>  	if (!fpl->edges)
>  		goto err;
>  
> -	unix_schedule_gc(fpl->user);
> -
>  	return 0;
>  
>  err:

[Severity: High]
Does removing the unix_schedule_gc() call from unix_prepare_fpl() prevent
proactive garbage collection of cyclic AF_UNIX file descriptors?

If a long-running application creates a cycle of AF_UNIX sockets and closes
its own file descriptors to them, the cycle maintains a positive f_count.
Without this call triggering the garbage collector, the uncollected cyclic
sockets could accumulate until the application reaches its RLIMIT_NOFILE
quota, causing subsequent socket operations to fail.

Additionally, does this change leave the user parameter logic in
unix_schedule_gc() as dead code?

If the remaining callers now only pass NULL, the user quota checks in
unix_schedule_gc() will no longer be reachable:

net/unix/garbage.c:unix_schedule_gc() {
	...
	if (user &&
	    READ_ONCE(user->unix_inflight) < UNIX_INFLIGHT_SANE_USER)
		return;
	...
}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1784268931.git.namcao@xxxxxxxxxxxxx?part=2