From: sashiko-bot@kernel.org
To: "Konstantin Sinyuk" <ksinyuk@kernel.org>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [RFC PATCH 01/12] drm/fabric: add core object model and provider API
Date: Tue, 25 Aug 2026 08:10:36 +0000 [thread overview]
Message-ID: <20260825081037.27FAD1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <83513555d01ea2ccc426020c97afee78d0376288.1787552412.git.ksinyuk@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] drm_fabric_endpoint_find_by_dev_name() skips ambiguity checking when busname is provided.
--
--- Patch [1]: [RFC PATCH 01/12] drm/fabric: add core object model and provider API ---
commit a52787ad8ee51af45c9fca91640883affafd66ca
Author: Ilia Levi <ilia.levi@intel.com>
drm/fabric: add core object model and provider API
This commit introduces a common DRM object model for interconnect fabrics,
endpoints, ports, and peers. It provides a registry and a provider API to
manage object identities, relationships, and lifetimes under a central lock.
> diff --git a/drivers/gpu/drm/fabric/drm_fabric.c b/drivers/gpu/drm/fabric/drm_fabric.c
> new file mode 100644
> index 0000000000000..8769d7bdcde1f
> --- /dev/null
> +++ b/drivers/gpu/drm/fabric/drm_fabric.c
[ ... ]
> +/*
> + * Returns NULL if no endpoint matches, or ERR_PTR(-EINVAL) if @devname is
> + * ambiguous across buses and @busname does not disambiguate it.
> + */
> +struct drm_fabric_endpoint *
> +drm_fabric_endpoint_find_by_dev_name(const char *devname, const char *busname)
> +{
> + struct drm_fabric_endpoint *match = NULL;
> + struct drm_fabric_endpoint *ep;
> + unsigned long idx;
> +
> + lockdep_assert_held(&drm_fabric_lock);
> + xa_for_each(&drm_fabric_ep_xa, idx, ep) {
> + if (strcmp(dev_name(ep->parent), devname))
> + continue;
> +
> + if (busname) {
> + if (strcmp(dev_bus_name(ep->parent), busname))
> + continue;
> + return ep;
[Severity: Medium]
Does this early return bypass the ambiguity check if a single parent device
registers multiple endpoints?
When a busname is provided, this path returns the very first matching endpoint
it finds. If a device matching both the devname and busname has registered
multiple endpoints, this silently resolves to the first one instead of
rejecting the ambiguous lookup with ERR_PTR(-EINVAL).
The code block just below this handles the ambiguity correctly when busname
is not provided. Should the busname path also continue checking the rest of
the xarray to ensure only one match exists?
> + }
> +
> + if (match)
> + return ERR_PTR(-EINVAL);
> +
> + match = ep;
> + }
> +
> + return match;
> +}
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1787552412.git.ksinyuk@kernel.org?part=1
next prev parent reply other threads:[~2026-08-25 8:10 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-24 8:09 [RFC PATCH 0/12] drm/fabric: vendor-neutral topology infrastructure for scale-up accelerator interconnects Konstantin Sinyuk
2026-08-24 8:09 ` [RFC PATCH 01/12] drm/fabric: add core object model and provider API Konstantin Sinyuk
2026-08-25 8:10 ` sashiko-bot [this message]
2026-08-24 8:09 ` [RFC PATCH 02/12] drm/fabric: add query uAPI and generated headers Konstantin Sinyuk
2026-08-25 8:10 ` sashiko-bot
2026-08-24 8:09 ` [RFC PATCH 03/12] drm/fabric: implement query netlink operations Konstantin Sinyuk
2026-08-25 8:10 ` sashiko-bot
2026-08-24 8:09 ` [RFC PATCH 04/12] drm/fabric: add read-only synthetic provider Konstantin Sinyuk
2026-08-24 8:09 ` [RFC PATCH 05/12] drm/fabric: add object-model KUnit tests Konstantin Sinyuk
2026-08-24 8:09 ` [RFC PATCH 06/12] drm/fabric: add YNL query and policy selftests Konstantin Sinyuk
2026-08-25 8:10 ` sashiko-bot
2026-08-24 8:09 ` [RFC PATCH 07/12] drm/fabric: add topology-provisioning core Konstantin Sinyuk
2026-08-24 8:09 ` [RFC PATCH 08/12] drm/fabric: add provisioning netlink uAPI Konstantin Sinyuk
2026-08-25 8:10 ` sashiko-bot
2026-08-24 8:09 ` [RFC PATCH 09/12] drm/fabric: implement mutation netlink operations Konstantin Sinyuk
2026-08-25 8:10 ` sashiko-bot
2026-08-24 8:09 ` [RFC PATCH 10/12] drm/fabric: make the synthetic provider writable Konstantin Sinyuk
2026-08-24 8:09 ` [RFC PATCH 11/12] drm/fabric: add mutation KUnit tests Konstantin Sinyuk
2026-08-25 8:10 ` sashiko-bot
2026-08-24 8:09 ` [RFC PATCH 12/12] drm/fabric: add mutation netlink selftests Konstantin Sinyuk
2026-08-26 9:32 ` [RFC PATCH 0/12] drm/fabric: vendor-neutral topology infrastructure for scale-up accelerator interconnects Leon Romanovsky
2026-08-26 15:38 ` Konstantin Sinyuk
2026-08-27 17:09 ` Leon Romanovsky
2026-08-28 16:13 ` Rodrigo Vivi
2026-09-01 11:01 ` Leon Romanovsky
2026-09-01 15:25 ` Rodrigo Vivi
2026-09-02 7:10 ` Leon Romanovsky
2026-08-31 11:45 ` Konstantin Sinyuk
2026-08-27 12:35 ` Jiri Pirko
2026-08-28 16:28 ` Rodrigo Vivi
2026-08-28 17:03 ` Jason Gunthorpe
2026-08-31 11:45 ` Konstantin Sinyuk
2026-08-31 12:23 ` Jason Gunthorpe
2026-08-31 11:45 ` Konstantin Sinyuk
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=20260825081037.27FAD1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=ksinyuk@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.