From: sashiko-bot@kernel.org
To: "Dan Williams" <djbw@kernel.org>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH 05/15] device core: Add "device evidence" 'validate' command
Date: Sun, 05 Jul 2026 22:26:32 +0000 [thread overview]
Message-ID: <20260705222632.F320B1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260705220819.2472765-6-djbw@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Holding the global `device_evidence_lock` across the provider's `evidence_read_begin()` callback blocks system-wide operations and causes global lock contention.
--
commit e225a84deccb758c0117766e62b3f41123a9e5e3
Author: Dan Williams <djbw@kernel.org>
device core: Add "device evidence" 'validate' command
When DMA is to be enabled for a PCI TDISP device, the CC VM passes a digest
of the device evidence used to make the trust decision. This commit adds a
validate command to require the CC VM to ack and not invalidate the evidence
before the next DMA enable event.
> diff --git a/drivers/base/evidence.c b/drivers/base/evidence.c
> --- a/drivers/base/evidence.c
> +++ b/drivers/base/evidence.c
[ ... ]
> @@ -446,6 +446,48 @@ int device_evidence_nl_read_dumpit(struct sk_buff *skb,
> return device_evidence_read(skb, cb);
> }
>
> +int device_evidence_nl_validate_doit(struct sk_buff *skb,
> + struct genl_info *info)
> +{
> + const struct device_evidence_ops *ops;
> + struct device_evidence *evidence;
> + struct device_evidence_ctx _ctx;
> + u32 generation;
> + int rc;
> +
> + if (GENL_REQ_ATTR_CHECK(info, DEVICE_EVIDENCE_A_OBJECT_GENERATION)) {
> + NL_SET_ERR_MSG(info->extack, "missing evidence generation");
> + return -EINVAL;
> + }
> + generation = nla_get_u32(info->attrs[DEVICE_EVIDENCE_A_OBJECT_GENERATION]);
> +
> + ACQUIRE(mutex_intr, lock)(&device_evidence_lock);
> + if ((rc = ACQUIRE_ERR(mutex_intr, &lock)))
> + return rc;
> +
> + struct device_evidence_ctx *ctx __free(put_ctx) =
> + device_evidence_ctx_setup(info, &_ctx);
> + if (IS_ERR(ctx))
> + return PTR_ERR(ctx);
> +
> + ops = ctx->subsys->ops;
> + evidence = ops->evidence_read_begin(ctx->dev);
[Severity: Medium]
Will holding device_evidence_lock across the evidence_read_begin() callback
cause global lock contention and system-wide stalls?
If a slow hardware refresh operation starts on one device and acquires its
per-device evidence lock, and a concurrent validate command on that same
device blocks in evidence_read_begin() while holding the global
device_evidence_lock:
Device A (refresh):
acquires evidence->lock for write
(slow hardware communication)
Device A (validate):
device_evidence_nl_validate_doit()
acquires device_evidence_lock
evidence_read_begin()
blocks on evidence->lock
It seems this would cause any concurrent read or validate commands on unrelated
devices (like Device B) to block on the global device_evidence_lock until
Device A's hardware operation completes.
Could the global lock scope be reduced here to prevent this stall?
> + if (IS_ERR(evidence)) {
> + NL_SET_ERR_MSG(info->extack, "failed to acquire evidence context");
> + return PTR_ERR(evidence);
> + }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260705220819.2472765-1-djbw@kernel.org?part=5
next prev parent reply other threads:[~2026-07-05 22:26 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-05 22:08 [PATCH 00/15] Device Evidence and Trust for PCI Security Protocol (TDISP) Dan Williams
2026-07-05 22:08 ` [PATCH 01/15] netlink: specs: Introduce multi-message blobs for SPDM Dan Williams
2026-07-05 22:13 ` sashiko-bot
2026-07-05 22:08 ` [PATCH 02/15] tools: ynl: Teach pyynl to handle blobs Dan Williams
2026-07-05 22:18 ` sashiko-bot
2026-07-05 22:08 ` [PATCH 03/15] tools: ynl: Teach ynl_gen_c to validate and dump 'blob' attributes Dan Williams
2026-07-05 22:20 ` sashiko-bot
2026-07-05 22:08 ` [PATCH 04/15] device core: Introduce "device evidence" over netlink Dan Williams
2026-07-05 22:20 ` sashiko-bot
2026-07-05 22:08 ` [PATCH 05/15] device core: Add "device evidence" 'validate' command Dan Williams
2026-07-05 22:26 ` sashiko-bot [this message]
2026-07-05 22:08 ` [PATCH 06/15] PCI/TSM: Add device evidence support Dan Williams
2026-07-05 22:16 ` sashiko-bot
2026-07-05 22:08 ` [PATCH 07/15] modules: Document the global async_probe parameter Dan Williams
2026-07-05 22:15 ` sashiko-bot
2026-07-05 22:08 ` [PATCH 08/15] device core: Initial device trust infrastructure Dan Williams
2026-07-05 22:17 ` sashiko-bot
2026-07-06 13:45 ` Jason Gunthorpe
2026-07-05 22:08 ` [PATCH 09/15] PCI, device core: Move "untrusted" concept to DEVICE_TRUST_ADVERSARY Dan Williams
2026-07-05 22:25 ` sashiko-bot
2026-07-06 13:49 ` Jason Gunthorpe
2026-07-07 13:04 ` Robin Murphy
2026-07-05 22:08 ` [PATCH 10/15] PCI/TSM: Add device interface security LOCKED support Dan Williams
2026-07-05 22:25 ` sashiko-bot
2026-07-05 22:08 ` [PATCH 11/15] PCI/TSM: Add device interface security RUN support Dan Williams
2026-07-05 22:21 ` sashiko-bot
2026-07-05 22:08 ` [PATCH 12/15] PCI/TSM: Add device interface security DMA enable/disable Dan Williams
2026-07-05 22:25 ` sashiko-bot
2026-07-05 22:08 ` [PATCH 13/15] PCI, device core: Add private memory access for DEVICE_TRUST_TCB Dan Williams
2026-07-05 22:28 ` sashiko-bot
2026-07-06 12:42 ` Aneesh Kumar K.V
2026-07-05 22:08 ` [PATCH 14/15] PCI/TSM: Create MMIO descriptors via TDISP Report Dan Williams
2026-07-05 22:24 ` sashiko-bot
2026-07-05 22:08 ` [PATCH 15/15] PCI/TSM: Add relative MMIO offset support? Dan Williams
2026-07-05 22:25 ` sashiko-bot
2026-07-06 12:51 ` [PATCH 00/15] Device Evidence and Trust for PCI Security Protocol (TDISP) Jason Gunthorpe
2026-07-06 20:55 ` Dan Williams (nvidia)
2026-07-07 12:43 ` Jason Gunthorpe
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=20260705222632.F320B1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=djbw@kernel.org \
--cc=linux-pci@vger.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.