From: Alison Schofield <alison.schofield@intel.com>
To: Li Chen <me@linux.beauty>
Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
Dan Williams <dan.j.williams@intel.com>,
Vishal Verma <vishal.l.verma@intel.com>,
"Dave Jiang" <dave.jiang@intel.com>,
Ira Weiny <ira.weiny@intel.com>, <virtualization@lists.linux.dev>,
<nvdimm@lists.linux.dev>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 0/5] nvdimm: virtio_pmem: fix request lifetime and converge broken queue failures
Date: Mon, 1 Jun 2026 18:51:26 -0700 [thread overview]
Message-ID: <ah43Hsur7KuTD-2c@aschofie-mobl2.lan> (raw)
In-Reply-To: <20260226025712.2236279-1-me@linux.beauty>
On Thu, Feb 26, 2026 at 10:57:05AM +0800, Li Chen wrote:
> Hi,
>
> The virtio-pmem flush path uses a virtqueue cookie/token to carry a
> per-request context through completion. Under broken virtqueue / notify
> failure conditions, the submitter can return and free the request object
> while the host/backend may still complete the published request. The IRQ
> completion handler then dereferences freed memory when waking waiters,
> which is reported by KASAN as a slab-use-after-free and may manifest as
> lock corruption (e.g. "BUG: spinlock already unlocked") without KASAN.
>
> In addition, the flush path has two wait sites: one for virtqueue
> descriptor availability (-ENOSPC from virtqueue_add_sgs()) and one for
> request completion. If the virtqueue becomes broken, forward progress is
> no longer guaranteed and these waiters may sleep indefinitely unless the
> driver converges the failure and wakes all wait sites.
>
> This series addresses both issues:
>
> 1/5 nvdimm: virtio_pmem: always wake -ENOSPC waiters
> Wake one -ENOSPC waiter for each reclaimed used buffer, decoupled from
> token completion.
>
> 2/5 nvdimm: virtio_pmem: use READ_ONCE()/WRITE_ONCE() for wait flags
> Use READ_ONCE()/WRITE_ONCE() for the wait_event() flags (done and
> wq_buf_avail).
>
> 3/5 nvdimm: virtio_pmem: refcount requests for token lifetime
> Refcount request objects so the token lifetime spans the window where it
> is reachable through the virtqueue until completion/drain drops the
> virtqueue reference.
>
> 4/5 nvdimm: virtio_pmem: converge broken virtqueue to -EIO
> Track a device-level broken state to converge broken/notify failures to
> -EIO: wake all waiters and drain/detach outstanding requests to complete
> them with an error, and fail-fast new requests.
>
> 5/5 nvdimm: virtio_pmem: drain requests in freeze
> Drain outstanding requests in freeze() before tearing down virtqueues so
> waiters do not sleep indefinitely.
>
> Testing was done on QEMU x86_64 with a virtio-pmem device exported as
> /dev/pmem0, formatted with ext4 (-O fast_commit), mounted with DAX, and
> stressed with fsync-heavy workloads.
>
> Thanks,
> Li Chen
Hi Li Chen,
Today I took a look at this set, noting that it's been sitting idle
in our nvdimm backlog for a while. I'm not able to apply it. Can you
post a new rev that applies to 7.1-rc6 ?
Thanks,
Alison
next prev parent reply other threads:[~2026-06-02 1:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-26 2:57 [PATCH v3 0/5] nvdimm: virtio_pmem: fix request lifetime and converge broken queue failures Li Chen
2026-02-26 2:57 ` [PATCH v3 1/5] nvdimm: virtio_pmem: always wake -ENOSPC waiters Li Chen
2026-02-26 2:57 ` [PATCH v3 2/5] nvdimm: virtio_pmem: use READ_ONCE()/WRITE_ONCE() for wait flags Li Chen
2026-02-26 2:57 ` [PATCH v3 3/5] nvdimm: virtio_pmem: refcount requests for token lifetime Li Chen
2026-02-26 2:57 ` [PATCH v3 4/5] nvdimm: virtio_pmem: converge broken virtqueue to -EIO Li Chen
2026-02-26 2:57 ` [PATCH v3 5/5] nvdimm: virtio_pmem: drain requests in freeze Li Chen
2026-06-02 1:51 ` Alison Schofield [this message]
2026-06-09 12:10 ` [PATCH v3 0/5] nvdimm: virtio_pmem: fix request lifetime and converge broken queue failures Li Chen
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=ah43Hsur7KuTD-2c@aschofie-mobl2.lan \
--to=alison.schofield@intel.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=ira.weiny@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=me@linux.beauty \
--cc=nvdimm@lists.linux.dev \
--cc=pankaj.gupta.linux@gmail.com \
--cc=virtualization@lists.linux.dev \
--cc=vishal.l.verma@intel.com \
/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