All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Bartosz Golaszewski" <bartosz.golaszewski@oss.qualcomm.com>
Cc: devicetree@vger.kernel.org, robh@kernel.org, imx@lists.linux.dev,
	Frank.Li@kernel.org, conor+dt@kernel.org,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 14/19] drm/xe/i2c: use platform_device_set_fwnode()
Date: Tue, 30 Jun 2026 09:18:40 +0000	[thread overview]
Message-ID: <20260630091840.E340E1F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260629-pdev-fwnode-ref-v2-14-8abe2513f96e@oss.qualcomm.com>

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

Pre-existing issues:
- [High] Missing cancel_work_sync() in driver teardown and error paths allows a pending background work to execute after the 'xe_i2c' structure is freed.
--

commit 1ceae3ee709a0fb69c698acf7a00cab2a5e1829c
Author: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

drm/xe/i2c: use platform_device_set_fwnode()

Ahead of reworking the reference counting logic for platform devices,
encapsulate the assignment of the firmware node for dynamically allocated
platform devices with the provided helper.

> diff --git a/drivers/gpu/drm/xe/xe_i2c.c b/drivers/gpu/drm/xe/xe_i2c.c
> index 706783863d07d..af4ebd93ad8e6 100644
> --- a/drivers/gpu/drm/xe/xe_i2c.c
> +++ b/drivers/gpu/drm/xe/xe_i2c.c
> @@ -123,7 +123,7 @@ static int xe_i2c_register_adapter(struct xe_i2c *i2c)
>  	}
>  
>  	pdev->dev.parent = i2c->drm_dev;
> -	pdev->dev.fwnode = fwnode;
> +	platform_device_set_fwnode(pdev, fwnode);
>  	i2c->adapter_node = fwnode;
>  	i2c->pdev = pdev;
>  

[Severity: High]
This is a pre-existing issue, but I noticed a potential use-after-free
involving the background work item in this file.

If platform_device_add() (called just below this block) triggers the bus
notifier but ultimately fails, the asynchronously scheduled i2c->work remains
pending.

When xe_i2c_probe() handles the error by unregistering the notifier and
returning, devres immediately frees the i2c structure. Later, when the work
executes, could it write to i2c->client[0] in freed memory?

The xe_i2c_probe() error path currently does this:

err_unregister_notifier:
	bus_unregister_notifier(&i2c_bus_type, &i2c->bus_notifier);

	return ret;

A similar scenario appears to exist in the standard teardown path, as
xe_i2c_remove() does not cancel the pending work:

static void xe_i2c_remove(void *arg)
{
	...
	bus_unregister_notifier(&i2c_bus_type, &i2c->bus_notifier);
	xe_i2c_unregister_adapter(i2c);
	xe_i2c_remove_irq(i2c);
}

Should cancel_work_sync(&i2c->work) be added to both the probe error path
and the remove function to ensure the work item doesn't execute after the
structure is freed?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260629-pdev-fwnode-ref-v2-0-8abe2513f96e@oss.qualcomm.com?part=14

  reply	other threads:[~2026-06-30  9:18 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-29  9:12 [PATCH v2 00/19] driver core: count references of the platform device's fwnode, not OF node Bartosz Golaszewski
2026-06-29  9:12 ` [PATCH v2 01/19] powerpc/powermac: fix OF node refcount Bartosz Golaszewski
2026-06-29  9:12 ` [PATCH v2 02/19] driver core: platform: provide platform_device_set_of_node() Bartosz Golaszewski
2026-06-30  9:18   ` sashiko-bot
2026-06-30 11:37   ` Manuel Ebner
2026-06-30 13:22     ` Bartosz Golaszewski
2026-07-01 15:05       ` Manuel Ebner
2026-06-29  9:12 ` [PATCH v2 03/19] driver core: platform: provide platform_device_set_fwnode() Bartosz Golaszewski
2026-06-29  9:12 ` [PATCH v2 04/19] driver core: platform: provide platform_device_set_of_node_from_dev() Bartosz Golaszewski
2026-06-29  9:12 ` [PATCH v2 05/19] of: platform: use platform_device_set_of_node() Bartosz Golaszewski
2026-06-29  9:12 ` [PATCH v2 06/19] powerpc/powermac: " Bartosz Golaszewski
2026-06-29  9:12 ` [PATCH v2 07/19] i2c: pxa-pci: " Bartosz Golaszewski
2026-06-30  9:18   ` sashiko-bot
2026-06-29  9:12 ` [PATCH v2 08/19] iommu/fsl: " Bartosz Golaszewski
2026-06-29 14:08   ` Frank Li
2026-06-29  9:12 ` [PATCH v2 09/19] net: bcmgenet: " Bartosz Golaszewski
2026-06-29 23:15   ` Jakub Kicinski
2026-06-30  9:18   ` sashiko-bot
2026-06-29  9:12 ` [PATCH v2 10/19] pmdomain: imx: " Bartosz Golaszewski
2026-06-30  9:18   ` sashiko-bot
2026-06-30 15:27   ` Frank Li
2026-06-29  9:12 ` [PATCH v2 11/19] mfd: tps6586: " Bartosz Golaszewski
2026-06-29  9:12 ` [PATCH v2 12/19] slimbus: qcom-ngd-ctrl: " Bartosz Golaszewski
2026-06-29  9:25   ` Konrad Dybcio
2026-06-29  9:12 ` [PATCH v2 13/19] net: mv643xx: " Bartosz Golaszewski
2026-06-29 23:16   ` Jakub Kicinski
2026-06-29  9:12 ` [PATCH v2 14/19] drm/xe/i2c: use platform_device_set_fwnode() Bartosz Golaszewski
2026-06-30  9:18   ` sashiko-bot [this message]
2026-06-29  9:12 ` [PATCH v2 15/19] platform/surface: gpe: " Bartosz Golaszewski
2026-06-29  9:12 ` [PATCH v2 16/19] usb: chipidea: use platform_device_set_of_node_from_dev() Bartosz Golaszewski
2026-06-29  9:12 ` [PATCH v2 17/19] usb: musb: " Bartosz Golaszewski
2026-06-30  9:18   ` sashiko-bot
2026-06-29  9:12 ` [PATCH v2 18/19] reset: rzg2l: " Bartosz Golaszewski
2026-06-29  9:12 ` [PATCH v2 19/19] driver core: platform: count references to all kinds of firmware nodes Bartosz Golaszewski
2026-06-29 16:21   ` Andy Shevchenko
2026-06-30  9:18   ` sashiko-bot
2026-06-29 16:23 ` [PATCH v2 00/19] driver core: count references of the platform device's fwnode, not OF node Andy Shevchenko
2026-06-29 23:20 ` ✓ CI.KUnit: success for driver core: count references of the platform device's fwnode, not OF node (rev2) Patchwork
2026-06-30  0:24 ` ✓ Xe.CI.BAT: " Patchwork
2026-06-30 12:47 ` ✓ Xe.CI.FULL: " Patchwork

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=20260630091840.E340E1F00A3D@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=bartosz.golaszewski@oss.qualcomm.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=imx@lists.linux.dev \
    --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.