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? > + } 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
