All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Mayuresh Chitale" <mayuresh.chitale@oss.qualcomm.com>
Cc: conor+dt@kernel.org, devicetree@vger.kernel.org, robh@kernel.org
Subject: Re: [PATCH v6 03/14] gtrace: Add RISC-V platform driver for the gtrace framework
Date: Thu, 01 Oct 2026 05:36:28 +0000	[thread overview]
Message-ID: <20261001053628.9ECE81F008A0@smtp.kernel.org> (raw)
In-Reply-To: <20261001052243.3042627-4-mayuresh.chitale@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
- [High] of: use-after-free of device node in rvtrace_platform_probe()
- [High] core: use-after-free hazard in rvtrace_platform_remove() during unregistration
- [Medium] of: memory leak of rep_node and rdev_node in gtrace_of_parse_outconns()
- [Medium] of: fwnode handle leak on -EPROBE_DEFER error path in gtrace_of_parse_outconns()
- [Medium] of: fwnode handle references leaked on rvtrace_platform_probe() error paths
- [Medium] module: missing MODULE_DEVICE_TABLE prevents automatic driver loading
--

commit 70aceab46d8019c787fc4aee6cb3f8a0b2772885
Author: Anup Patel <anup.patel@oss.qualcomm.com>

gtrace: Add RISC-V platform driver for the gtrace framework

The RISC-V trace components defined by the RISC-V Trace Control Interface
Specification are memory mapped devices which are organized in a
graph-like topology and described in the device tree.

Add the RISC-V platform driver for the gtrace framework. The driver
parses the RISC-V component topology from the device tree, discovers the
type and version of each component from its IMPL register, provides the
RISC-V register level control ops and registers each component with the
gtrace core.

> diff --git a/drivers/hwtracing/gtrace/gtrace-of.c b/drivers/hwtracing/gtrace/gtrace-of.c
> new file mode 100644
> --- /dev/null
> +++ b/drivers/hwtracing/gtrace/gtrace-of.c
[ ... ]
> +		conn->dest_port = rep.port;
> +		conn->dest_fwnode = of_fwnode_handle(rdev_node);
> +		fwnode_handle_get(conn->dest_fwnode);
> +		conn->dest_comp = gtrace_find_by_fwnode(conn->dest_fwnode);
> +		if (!conn->dest_comp) {
> +			ret = -EPROBE_DEFER;
> +			of_node_put(ep_node);
> +			of_node_put(rep_node);
> +			of_node_put(rdev_node);
> +			break;

[Severity: Medium]
Does this error path leak the conn->dest_fwnode reference?

The fwnode reference count was incremented by fwnode_handle_get(), but the
newly allocated conn has not yet been placed into the pdata->outconns array.
Consequently, the error cleanup loop at the done label skips this connection.

> +		}
> +
> +		pdata->outconns[i] = conn;
> +		i++;

[Severity: Medium]
Does the success path of this endpoint parsing loop leak the device node
references?

The of_graph_get_remote_endpoint() and of_graph_get_port_parent() calls
acquire references to device nodes. On the success path, these references
are never released with of_node_put() before advancing to the next iteration.

> +	}
> +
> +done:
> +	if (ret) {
> +		for (i = 0; i < pdata->nr_outconns && pdata->outconns; i++) {
> +			conn = pdata->outconns[i];
> +			if (conn && conn->dest_fwnode)
> +				fwnode_handle_put(conn->dest_fwnode);
> +		}
> +	}
> +	of_node_put(parent);
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(gtrace_of_parse_outconns);
[ ... ]
> diff --git a/drivers/hwtracing/gtrace/rvtrace-platform.c b/drivers/hwtracing/gtrace/rvtrace-platform.c
> new file mode 100644
> --- /dev/null
> +++ b/drivers/hwtracing/gtrace/rvtrace-platform.c
[ ... ]
> +	pdata->bound_cpu = -1;
> +	node = of_parse_phandle(dev_of_node(dev), "cpus", 0);
> +	if (node) {
> +		ret = of_cpu_node_to_id(node);
> +		of_node_put(node);
> +		if (ret < 0)
> +			return dev_err_probe(dev, ret, "failed to get CPU id for %pOF\n", node);

[Severity: High]
Does this code trigger a use-after-free on the device node?

The node reference is explicitly released via of_node_put() before it is
passed to dev_err_probe(), where the %pOF specifier will dereference the
now-freed node pointer to extract its name.

> +		pdata->bound_cpu = ret;
> +	}
> +
> +	/* Default control poll timeout */
> +	pdata->control_poll_timeout_usecs = 10;
> +
> +	ret = gtrace_of_parse_outconns(pdata);
> +	if (ret)
> +		return dev_err_probe(dev, ret, "failed to parse output connections\n");
> +
> +	ret = gtrace_of_parse_inconns(pdata);
> +	if (ret)
> +		return dev_err_probe(dev, ret, "failed to parse input connections\n");
> +
> +	/* Reset the component before it is registered with the gtrace core. */
> +	ret = rvtrace_hw_reset(pdata);
> +	if (ret)
> +		return dev_err_probe(dev, ret, "failed to reset component\n");

[Severity: Medium]
Do these error paths leak the fwnode references stored in the outconns array?

The earlier call to gtrace_of_parse_outconns() allocates and acquires fwnode
references, storing them in pdata->outconns. If a subsequent call fails, the
probe function immediately returns an error. Because devm does not
automatically release fwnode references, and the custom teardown logic in
rvtrace_platform_remove() is bypassed on probe failure, these references
appear to be lost.

> +
> +	impl = gtrace_read32(pdata, RVTRACE_COMPONENT_IMPL_OFFSET);
[ ... ]
> +static void rvtrace_platform_remove(struct platform_device *pdev)
> +{
> +	struct gtrace_component *comp = platform_get_drvdata(pdev);
> +	struct gtrace_platform_data *pdata = comp->pdata;
> +	struct gtrace_connection *conn;
> +	int i;
> +
> +	for (i = 0; i < pdata->nr_outconns; i++) {
> +		conn = pdata->outconns[i];
> +		if (conn && conn->dest_fwnode)
> +			fwnode_handle_put(conn->dest_fwnode);
> +	}
> +
> +	gtrace_unregister_component(comp);

[Severity: High]
Does this sequence introduce a use-after-free hazard during unregistration?

The fwnode references are prematurely dropped before unregistering the
component. However, gtrace_unregister_component() relies on these pointers
internally during its teardown process, matching the fwnode device elements.
If the prior fwnode_handle_put() was the final reference, the memory is
freed, and the subsequent match access is a use-after-free.

> +}
> +
> +static const struct of_device_id rvtrace_platform_match[] = {
> +	{ .compatible = "riscv,trace-component", .data = (void *)GTRACE_FORMAT_ETRACE },
> +	{}
> +};

[Severity: Medium]
Is MODULE_DEVICE_TABLE(of, rvtrace_platform_match) missing here?

Without it, the driver fails to export the necessary modaliases to userspace,
preventing the driver from loading automatically when its hardware matches
are present in modular builds.

> +
> +static struct platform_driver rvtrace_platform_driver = {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261001052243.3042627-1-mayuresh.chitale@oss.qualcomm.com?part=3

  reply	other threads:[~2026-10-01  5:36 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-01  5:22 [PATCH v6 00/14] Linux RISC-V trace framework and drivers Mayuresh Chitale
2026-10-01  5:22 ` Mayuresh Chitale
2026-10-01  5:22 ` [PATCH v6 01/14] dt-bindings: Add RISC-V trace component bindings Mayuresh Chitale
2026-10-01  5:22   ` Mayuresh Chitale
2026-10-01  5:33   ` sashiko-bot
2026-10-01  5:22 ` [PATCH v6 02/14] hwtracing: gtrace: Initial implementation of gtrace framework Mayuresh Chitale
2026-10-01  5:22   ` Mayuresh Chitale
2026-10-01  5:37   ` sashiko-bot
2026-10-01  5:22 ` [PATCH v6 03/14] gtrace: Add RISC-V platform driver for the " Mayuresh Chitale
2026-10-01  5:22   ` Mayuresh Chitale
2026-10-01  5:36   ` sashiko-bot [this message]
2026-10-01  5:22 ` [PATCH v6 04/14] gtrace: Add functions to create/destroy a trace component path Mayuresh Chitale
2026-10-01  5:22   ` Mayuresh Chitale
2026-10-01  5:36   ` sashiko-bot
2026-10-01  5:22 ` [PATCH v6 05/14] gtrace: Add functions to start/stop tracing on a " Mayuresh Chitale
2026-10-01  5:22   ` Mayuresh Chitale
2026-10-01  5:36   ` sashiko-bot
2026-10-01  5:22 ` [PATCH v6 06/14] gtrace: Add RISC-V Trace encoder driver Mayuresh Chitale
2026-10-01  5:22   ` Mayuresh Chitale
2026-10-01  5:34   ` sashiko-bot
2026-10-01  5:22 ` [PATCH v6 07/14] gtrace: Add function to copy into perf AUX buffer Mayuresh Chitale
2026-10-01  5:22   ` Mayuresh Chitale
2026-10-01  5:40   ` sashiko-bot
2026-10-01  5:22 ` [PATCH v6 08/14] perf: Add gtrace AUX buffer trace format type Mayuresh Chitale
2026-10-01  5:22   ` Mayuresh Chitale
2026-10-01  5:22 ` [PATCH v6 09/14] gtrace: Add RISC-V Trace ramsink driver Mayuresh Chitale
2026-10-01  5:22   ` Mayuresh Chitale
2026-10-01  5:42   ` sashiko-bot
2026-10-01  5:22 ` [PATCH v6 10/14] riscv: Enable DMA_RESTRICTED_POOL in defconfig Mayuresh Chitale
2026-10-01  5:22   ` Mayuresh Chitale
2026-10-01  5:22 ` [PATCH v6 11/14] gtrace: Add perf driver for tracing using perf tool Mayuresh Chitale
2026-10-01  5:22   ` Mayuresh Chitale
2026-10-01  5:44   ` sashiko-bot
2026-10-01  5:22 ` [PATCH v6 12/14] perf tools: Add RISC-V trace PMU record capabilities Mayuresh Chitale
2026-10-01  5:22   ` Mayuresh Chitale
2026-10-01  5:22 ` [PATCH v6 13/14] perf tools: Initial support for gtrace decoder Mayuresh Chitale
2026-10-01  5:22   ` Mayuresh Chitale
2026-10-01  5:35   ` sashiko-bot
2026-10-01  5:22 ` [PATCH v6 14/14] MAINTAINERS: Add entry for RISC-V trace framework Mayuresh Chitale
2026-10-01  5:22   ` Mayuresh Chitale

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261001053628.9ECE81F008A0@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=mayuresh.chitale@oss.qualcomm.com \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.