Re: [PATCH v6 01/18] tracing/remotes: Gate tracefs files opening on trace remote registration

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Medium] Error paths in `trace_remote_register()` leak the dynamically allocated `trace_remote` object and tracefs directories when initialization fails.
--

--- Patch [1]: [PATCH v6 01/18] tracing/remotes: Gate tracefs files opening on trace remote registration ---
commit cea65090c9ee422e607003e731a26fe505c23e56
Author: Vincent Donnefort <vdonnefort@google.com>

tracing/remotes: Gate tracefs files opening on trace remote registration

This patch adds a global list to track registered trace remotes, preventing
users from accessing tracefs files for remotes that are about to be
destroyed. Tracefs open operations are now gated based on whether the
remote is present in this list.

> diff --git a/kernel/trace/trace_remote.c b/kernel/trace/trace_remote.c
> --- a/kernel/trace/trace_remote.c
> +++ b/kernel/trace/trace_remote.c
[ ... ]
> @@ -932,8 +999,12 @@ int trace_remote_register(const char *name, struct trace_remote_callbacks *cbs,
>  	}
>  
>  	ret = cbs->init ? cbs->init(remote->dentry, priv) : 0;
> -	if (ret)
> +	if (ret) {
>  		pr_err("Init failed for trace remote '%s' (%d)\n", name, ret);

[Severity: Medium]
This is a pre-existing issue, but does this error path leak the dynamically
allocated trace_remote object and its tracefs directories?

If cbs->init() or an earlier step like trace_remote_register_events() fails,
the function returns an error code without cleaning up the remote pointer or
calling tracefs_remove(remote->dentry). Will this prevent the remote from
being re-registered later due to tracefs naming collisions?

> +	} else {
> +		guard(mutex)(&trace_remotes_lock);
> +		list_add(&remote->node, &trace_remotes);
> +	}
>  
>  	return ret;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260817135517.3919534-1-vdonnefort@google.com?part=1