From: sashiko-bot@kernel.org
To: "João Peixoto" <jpeixoto@osyx.tech>
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [RFC PATCH v3 5/6] virt: bao: consolidate the IPC hypercall ID in include/linux/bao.h
Date: Fri, 07 Aug 2026 07:50:41 +0000 [thread overview]
Message-ID: <20260807075042.17C1F1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <db869ed90e16691ea1f0aee051e54daf89f42de8.1786010512.git.jpeixoto@osyx.tech>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing memory barrier (e.g., `wmb()`) before notifying the hypervisor of newly written data, potentially causing the hypervisor or the receiving VM to read stale memory.
--
--- Patch [5]: [RFC PATCH v3 5/6] virt: bao: consolidate the IPC hypercall ID in include/linux/bao.h ---
commit 392291f754c5a86346cd59911eed878c78654f9d
Author: João Peixoto <jpeixoto@osyx.tech>
virt: bao: consolidate the IPC hypercall ID in include/linux/bao.h
This commit consolidates the IPC shared-memory hypercall ID into a common
header. It also simplifies the architecture-specific bao_ipcshmem_hypercall()
helpers by dropping the hypercall_id parameter.
> diff --git a/drivers/virt/bao/ipcshmem/ipcshmem.c b/drivers/virt/bao/ipcshmem/ipcshmem.c
> index 0d46d89ee788b..5bf37c1c7933d 100644
> --- a/drivers/virt/bao/ipcshmem/ipcshmem.c
> +++ b/drivers/virt/bao/ipcshmem/ipcshmem.c
[ ... ]
> @@ -104,7 +101,7 @@ static ssize_t bao_ipcshmem_write(struct file *filp, const char __user *buf,
> *ppos += count;
>
> /* Notify Bao hypervisor */
> - bao_ipcshmem_hypercall(BAO_IPCSHMEM_HYPERCALL_ID, bao->id);
> + bao_ipcshmem_hypercall(bao->id);
[Severity: High]
This isn't a bug introduced by this patch, but is there a missing memory
barrier before notifying the hypervisor here in bao_ipcshmem_write()?
Data is written to the shared memory via copy_from_user() just before this,
but no memory barrier ensures global visibility of the write prior to the
notification.
The ARM SMCCC explicitly states that callers must ensure memory updates are
visible before invoking SMC/HVC, meaning an explicit memory barrier (like
wmb()) is architecturally required to prevent stale reads.
Without it, could the hypervisor or the receiving VM read stale memory before
the stores from copy_from_user() become globally visible across PEs?
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1786010512.git.jpeixoto@osyx.tech?part=5
next prev parent reply other threads:[~2026-08-07 7:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-07 7:39 [RFC PATCH v3 0/6] virt: bao: Add Bao hypervisor IPC and I/O dispatcher drivers João Peixoto
2026-08-07 7:39 ` [RFC PATCH v3 1/6] dt-bindings: bao: add IPC shared-memory device João Peixoto
2026-08-07 7:45 ` sashiko-bot
2026-08-07 7:39 ` [RFC PATCH v3 2/6] virt: bao: add IPC shared-memory driver João Peixoto
2026-08-07 7:56 ` sashiko-bot
2026-08-07 7:39 ` [RFC PATCH v3 3/6] dt-bindings: bao: add I/O dispatcher device João Peixoto
2026-08-07 7:39 ` [RFC PATCH v3 4/6] virt: bao: add I/O dispatcher driver João Peixoto
2026-08-07 7:54 ` sashiko-bot
2026-08-07 7:39 ` [RFC PATCH v3 5/6] virt: bao: consolidate the IPC hypercall ID in include/linux/bao.h João Peixoto
2026-08-07 7:50 ` sashiko-bot [this message]
2026-08-07 7:39 ` [RFC PATCH v3 6/6] MAINTAINERS: add Bao hypervisor entry João Peixoto
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=20260807075042.17C1F1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jpeixoto@osyx.tech \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox