On Mon, Aug 17, 2026 at 02:09:02PM +0000, [email protected] wrote:
> 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 <[email protected]>
>
> 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?
This is fixed in the following commit.
>
> > + } else {
> > + guard(mutex)(&trace_remotes_lock);
> > + list_add(&remote->node, &trace_remotes);
> > + }
> >
> > return ret;
> > }
>
> --
> Sashiko AI review ยท
> https://sashiko.dev/#/patchset/[email protected]?part=1
--
Vincent
