Re: [PATCH] PCI: vmd: Flush initiator posted writes before demuxing interrupts on Meteor Lake

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] SRCU structures are destroyed before the IRQ handlers are freed during device teardown, creating a use-after-free window if an interrupt fires.
--

--- Patch [1]: [PATCH] PCI: vmd: Flush initiator posted writes before demuxing interrupts on Meteor Lake ---
commit ee34aa5044fcd3846f8909a9ac941afcd7c5a7d8
Author: Rickey Bartlett <subtexel@gmail.com>

PCI: vmd: Flush initiator posted writes before demuxing interrupts on Meteor Lake

This commit mitigates erratum MTL016 on Meteor Lake VMD devices by issuing
a dummy config read to the child device before handling interrupts. This
read ensures earlier posted writes (like NVMe completions) land in memory
before the demuxed handler executes. This prevents the storage stack from
stalling due to missed completions.

Link: https://lore.kernel.org/all/20240909082657.19660-1-kai.heng.feng@canonical.com/
Link: https://lkml.iu.edu/hypermail/linux/kernel/2409.1/08047.html

> diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
> index 241023ecf6774..e45ef8cb16e47 100644
> --- a/drivers/pci/controller/vmd.c
> +++ b/drivers/pci/controller/vmd.c

[ ... ]

> @@ -756,8 +791,20 @@ static irqreturn_t vmd_irq(int irq, void *data)
>  	int idx;
>  
>  	idx = srcu_read_lock(&irqs->srcu);

[Severity: High]
This is a pre-existing issue, but can this lead to a use-after-free
during device teardown?

The VMD driver allocates IRQs using the managed devm_request_irq(), which
means the IRQ handlers are unregistered by devres after the driver's remove
callback (vmd_remove) returns.

However, vmd_remove() explicitly calls vmd_cleanup_srcu(), which destroys
the per-CPU SRCU structures immediately. If an interrupt fires during the
window between vmd_cleanup_srcu() completing and the devres cleanup,
wouldn't vmd_irq() execute and call srcu_read_lock() on the freed
SRCU structure?

> -	list_for_each_entry_rcu(vmdirq, &irqs->irq_list, node)
> +	list_for_each_entry_rcu(vmdirq, &irqs->irq_list, node) {
> +		/*
> +		 * MTL016: the MSI may have outrun the initiating device's
> +		 * posted writes (e.g. its NVMe completion entry).  A read

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260825043220.9047-1-subtexel@gmail.com?part=1