All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Vladimir Oltean" <vladimir.oltean@nxp.com>
Cc: Frank.Li@kernel.org, imx@lists.linux.dev
Subject: Re: [PATCH v9 2/3] usb: host: tegra: avoid direct dereference of phy->dev.of_node
Date: Mon, 10 Aug 2026 13:08:43 +0000	[thread overview]
Message-ID: <20260810130844.5437E1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260810125614.441667-3-vladimir.oltean@nxp.com>

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

Pre-existing issues:
- [High] Reusing a single `struct notifier_block` (`tegra->id_nb`) across multiple independent USB PHYs corrupts their atomic notifier chains.
- [High] Delayed work can be scheduled after driver removal due to devres-based notifier unregistration.
--

--- Patch [2]: [PATCH v9 2/3] usb: host: tegra: avoid direct dereference of phy->dev.of_node ---
commit 5072858d37310d2ff0794e119a072f8de6f28872
Author: Vladimir Oltean <vladimir.oltean@nxp.com>

usb: host: tegra: avoid direct dereference of phy->dev.of_node

This commit removes direct access to phy->dev.of_node from the Tegra USB
host driver. It implements a parallel lookup path using the 'phys' phandle
to retrieve the OF node. The remote wake debug print is also updated to use
the PHY index instead.

> diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
> --- a/drivers/usb/host/xhci-tegra.c
> +++ b/drivers/usb/host/xhci-tegra.c
> @@ -1515,23 +1516,34 @@ static int tegra_xusb_init_usb_phy(struct tegra_xusb *tegra)
>  	tegra->otg_usb3_port = -EINVAL;
>  
>  	for (i = 0; i < tegra->num_usb_phys; i++) {
> -		struct phy *phy = tegra_xusb_get_phy(tegra, "usb2", i);
[ ... ]
> +		err = of_parse_phandle_with_args(np, "phys", "#phy-cells",
> +						 index, &args);
> +		if (err)
> +			continue;
> +
> +		usbphy = devm_usb_get_phy_by_node(tegra->dev, args.np,
> +						  &tegra->id_nb);

[Severity: High]
This is a pre-existing issue, but does reusing a single struct notifier_block
(tegra->id_nb) across multiple independent USB PHYs corrupt their atomic
notifier chains?

Since tegra_xusb_init_usb_phy() loops over all available usb2 PHYs, it passes
the exact same &tegra->id_nb notifier block to devm_usb_get_phy_by_node().
usb_register_notifier() then links this same block into each PHY's independent
atomic_notifier_head, which overwrites its next pointer.

Could this lead to missed events or infinite loops when the lists are
traversed?

[Severity: High]
This isn't a bug introduced by this patch, but does the devres lifecycle
for this notifier create a use-after-free risk during driver removal?

In tegra_xusb_remove(), cancel_work_sync(&tegra->id_work) is called to
stop pending work, but the notifier remains registered until the devres
release phase via devm_usb_phy_release2().

If a USB PHY event fires in this window, tegra_xhci_id_notify() calls
schedule_work(). Devres then unregisters the notifier and frees the
tegra_xusb structure, causing the workqueue to dereference the freed
structure when it executes.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260810125614.441667-1-vladimir.oltean@nxp.com?part=2

  reply	other threads:[~2026-08-10 13:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-10 12:56 [PATCH v9 0/3] USB prerequisites for PHY consumer/provider split Vladimir Oltean
2026-08-10 12:56 ` [PATCH v9 1/3] usb: add missing headers transitively included by <linux/phy/phy.h> Vladimir Oltean
2026-08-10 17:05   ` Frank Li
2026-08-10 12:56 ` [PATCH v9 2/3] usb: host: tegra: avoid direct dereference of phy->dev.of_node Vladimir Oltean
2026-08-10 13:08   ` sashiko-bot [this message]
2026-08-10 12:56 ` [PATCH v9 3/3] usb: gadget: tegra-xudc: " Vladimir Oltean
2026-08-10 13:07   ` sashiko-bot

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=20260810130844.5437E1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=imx@lists.linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vladimir.oltean@nxp.com \
    /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.