* Re: [PATCH RFC 2/2] nvme: set integrity metadata size for EXT_LBAS non-PI namespace
From: Christoph Hellwig @ 2026-05-07 5:49 UTC (permalink / raw)
To: Chao Shi
Cc: linux-nvme, linux-block, hch, kbusch, sagi, axboe, Sungwoo Kim,
Dave Tian, Weidong Zhu
In-Reply-To: <20260427003457.1264511-2-coshi036@gmail.com>
On Sun, Apr 26, 2026 at 08:34:57PM -0400, Chao Shi wrote:
> + /*
> + * For PCIe EXT_LBAS non-PI namespaces the block layer sets
> + * capacity to 0 (we return false) to prevent block I/O, but a
> + * cached-rq bio may bypass bio_queue_enter freeze serialisation
> + * and reach nvme_setup_rw() with head->ms != 0 and no
> + * REQ_INTEGRITY set. Populate bi->metadata_size so that
> + * bio_integrity_action() returns non-zero and bio_integrity_prep()
> + * sets REQ_INTEGRITY on any such bio, preventing the WARN_ON_ONCE
> + * at nvme_setup_rw() (addressed by patch 1/2).
This sounds like the Bug Keith is trying to fix in the block layer
("blk-mq: check for stale cached request in blk_mq_submit_bio") ?
^ permalink raw reply
* Re: [PATCH v4] block: bio-integrity: Fix null-ptr-deref in bio_integrity_map_user()
From: Sungwoo Kim @ 2026-05-07 7:01 UTC (permalink / raw)
To: Shin'ichiro Kawasaki
Cc: Jens Axboe, Keith Busch, Chao Shi, Weidong Zhu, Dave Tian,
linux-block, linux-kernel
In-Reply-To: <afM2oyQTraSWa5vO@shinmob>
Hello,
Just a gentle reminder on this patch in case it got missed.
Please let me know if there are any concerns or changes needed.
Thanks,
Sungwoo.
On Thu, Apr 30, 2026 at 9:35 AM Shin'ichiro Kawasaki
<shinichiro.kawasaki@wdc.com> wrote:
>
> On Apr 27, 2026 / 00:09, Sungwoo Kim wrote:
> > pin_user_pages_fast() can partially succeed and return the number of
> > pages that were actually pinned. However, the bio_integrity_map_user()
> > does not handle this partial pinning. This leads to a general protection
> > fault since bvec_from_pages() dereferences an unpinned page address,
> > which is 0.
> >
> > To fix this, add a check to verify that all requested memory is pinned.
> > If partial pinning occurs, unpin the memory and return -EFAULT.
> >
> > Reproducer in blktest: https://github.com/linux-blktests/blktests/pull/244
>
> The blktests Pull Request modifies the test case nvme/064 to write with 80KiB
> size metadata. With this change, I confirmed that the Oops below was recreated
> on my test system using the kernel v7.1-rc1.
>
> >
> > Kernel Oops:
> >
> > Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI
> > KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
> > CPU: 0 UID: 0 PID: 1061 Comm: nvme-passthroug Not tainted 7.0.0-11783-g90957f9314e8-dirty #16 PREEMPT(lazy)
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014
> > RIP: 0010:bio_integrity_map_user.cold+0x1b0/0x9d6
> >
> > Fixes: 492c5d455969 ("block: bio-integrity: directly map user buffers")
> > Acked-by: Chao Shi <cshi008@fiu.edu>
> > Acked-by: Weidong Zhu <weizhu@fiu.edu>
> > Acked-by: Dave Tian <daveti@purdue.edu>
> > Signed-off-by: Sungwoo Kim <iam@sung-woo.kim>
> > ---
> > V3: https://lore.kernel.org/linux-block/20260420020327.1667156-3-iam@sung-woo.kim/
> >
> > V3->V4
> > - Addressed a sashiko's comments [1], if it makes sense.
> > - V3 wrongly assumed that iov_iter_extract_pages() always pins user
> > memory.
> > - V3 insufficiently handled the return value range.
> >
> > [1] https://sashiko.dev/#/patchset/20260420020327.1667156-3-iam%40sung-woo.kim
>
> I applied this v4 patch to v7.1-rc1 kernel. With this, I confirmed that the
> Oops goes away. Looks good from testing point of view.
>
> Tested-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
>
^ permalink raw reply
* Re: [PATCH v6 1/1] block/blk-mq: use atomic_t for quiesce_depth to avoid lock contention on RT
From: Sebastian Andrzej Siewior @ 2026-05-07 7:45 UTC (permalink / raw)
To: Bart Van Assche
Cc: Ionut Nechita (Wind River), axboe, linux-block, clrkwllms,
rostedt, ming.lei, muchun.song, mkhalfella, chris.friesen,
linux-kernel, linux-rt-devel, linux-rt-users, stable, ionut_n2001,
sunlightlinux
In-Reply-To: <713ba2ae-e322-4e56-b0b8-89766f7f65c1@acm.org>
On 2026-05-06 11:43:32 [+0200], Bart Van Assche wrote:
> On 5/6/26 9:47 AM, Sebastian Andrzej Siewior wrote:
> > On 2026-05-06 09:14:33 [+0200], Bart Van Assche wrote:
> > > If the atomic_inc() in blk_mq_quiesce_queue_nowait() is protected by
> > > hctx->queue->queue_lock then the above code doesn't have to be modified.
> >
> > But wouldn't the atomic_inc + barrier avoid the need to have the lock?
> > Isn't this a normal pattern? If the lock is kept, we could use
> > non-atomic ops here then. But this avoids having the lock.
>
> I strongly prefer a spinlock + non-atomic variables rather than using an
> atomic variable and barriers because algorithms that use a spinlock are
> easier to verify.
Hmmm. If we keep the lock, then there is no need for the atomic and we
keep int counter. Then we are where we are right now with the lock
synchronizing everything.
Isn't this also improving the performance for the !RT case or is it
simply not that visible here?
> Thanks,
>
> Bart.
Sebastian
^ permalink raw reply
* Re: [PATCH v4] block: bio-integrity: Fix null-ptr-deref in bio_integrity_map_user()
From: Jens Axboe @ 2026-05-07 7:51 UTC (permalink / raw)
To: Sungwoo Kim, Keith Busch
Cc: Chao Shi, Weidong Zhu, Dave Tian, linux-block, linux-kernel
In-Reply-To: <20260427040926.987166-3-iam@sung-woo.kim>
> diff --git a/block/bio-integrity.c b/block/bio-integrity.c
> index e54c6e06e1cb..766cc2d1d51c 100644
> --- a/block/bio-integrity.c
> +++ b/block/bio-integrity.c
> @@ -403,6 +403,23 @@ int bio_integrity_map_user(struct bio *bio, struct iov_iter *iter)
> if (unlikely(ret < 0))
> goto free_bvec;
>
> + /* Handle partial pinning. This can happen when pin_user_pages_fast()
> + * returns fewer pages than requested
> + */
Please follow the multi-line comment style used in the code around you.
> + if (user_backed_iter(iter) && unlikely(ret != bytes)) {
> + if (0 < ret) {
And never do this, it's so much worse to read than if (ret > 0)
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH RFC 2/2] nvme: set integrity metadata size for EXT_LBAS non-PI namespace
From: Keith Busch @ 2026-05-07 8:05 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Chao Shi, linux-nvme, linux-block, sagi, axboe, Sungwoo Kim,
Dave Tian, Weidong Zhu
In-Reply-To: <20260507054944.GB19796@lst.de>
On Thu, May 07, 2026 at 07:49:44AM +0200, Christoph Hellwig wrote:
> On Sun, Apr 26, 2026 at 08:34:57PM -0400, Chao Shi wrote:
> > + /*
> > + * For PCIe EXT_LBAS non-PI namespaces the block layer sets
> > + * capacity to 0 (we return false) to prevent block I/O, but a
> > + * cached-rq bio may bypass bio_queue_enter freeze serialisation
> > + * and reach nvme_setup_rw() with head->ms != 0 and no
> > + * REQ_INTEGRITY set. Populate bi->metadata_size so that
> > + * bio_integrity_action() returns non-zero and bio_integrity_prep()
> > + * sets REQ_INTEGRITY on any such bio, preventing the WARN_ON_ONCE
> > + * at nvme_setup_rw() (addressed by patch 1/2).
>
> This sounds like the Bug Keith is trying to fix in the block layer
> ("blk-mq: check for stale cached request in blk_mq_submit_bio") ?
Both issues are dealing with cached request corner cases, but they're
not really related. My bug fix is specifically when those requests are
freed, while this one is just racing with them.
For this patch's issue, how is the host being triggered to rescan? If
you're sending a "Format NVM" command, the driver would have frozen the
queues first, which would have waited for any cached requests to flush
out and prevent new ones from being allocated until after the format has
been updated in the driver.
It's possible to format the namespace from a different controller the
host doesn't know about, so we've always had a race where the actual
format is different than what the host knows about. The rescan would
have to be triggered some other way in that case (either through AEN or
manual sysfs/ioctl trigger).
We always ensure the queue is frozen when we update the queue limits in
this path too, so the driver and block layer should always be in sync
even if it's not in sync with the device. That in itself can be pretty
nasty, but we'd need a new NVMe TP to define a way to fix that. But
specifically on the driver warning here, I'm not sure how it is getting
triggered due to the existing freeze semantics around the queue limits
update.
^ permalink raw reply
* Re: [PATCH] zram: fix use-after-free in zram_writeback_endio
From: Sergey Senozhatsky @ 2026-05-07 9:40 UTC (permalink / raw)
To: Minchan Kim
Cc: Richard Chang, Sergey Senozhatsky, Jens Axboe, Andrew Morton,
bgeffon, liumartin, linux-kernel, linux-block, linux-mm
In-Reply-To: <afoc5qLvK2PDQKb-@google.com>
On (26/05/05 09:37), Minchan Kim wrote:
> > @@ -966,9 +966,8 @@ static void zram_writeback_endio(struct bio *bio)
> >
> > spin_lock_irqsave(&wb_ctl->done_lock, flags);
> > list_add(&req->entry, &wb_ctl->done_reqs);
> > - spin_unlock_irqrestore(&wb_ctl->done_lock, flags);
> > -
> > wake_up(&wb_ctl->done_wait);
> > + spin_unlock_irqrestore(&wb_ctl->done_lock, flags);
> > }
> >
>
> I agree this will fix the issue, but using a lock to extend the lifetime of
> an object to avoid a UAF is not a good pattern. Object lifetime shared between
> process and interrupt contexts should be managed explicitly using refcount.
->num_inflight is a ref-counter, basically. The problem is that
completion is a two-step process, only one part of each is synchronized
with the writeback context. I honestly don't want to have two ref-counts:
one for requests pending zram completion and one for active endio contexts.
Maybe we can repurpose num_inflight instead.
> Furthermore, keeping wake_up() outside the critical section minimizes
> interrupt-disabled latency
So I considered that, but isn't endio already called from IRQ context?
Just asking. We wakeup only one waiter (writeback task), so it's not
that bad CPU-cycles wise. Do you think it's really a concern?
wake_up() under spin-lock solves the problem of a unsynchronized
two-stages endio process.
> and avoids nesting spinlocks (done_lock -> done_wait.lock), reducing
> the risk of future lockdep issues, just in case.
I considered lockdep as well but ruled it out as impossible scenario,
nesting here is strictly uni-directional, we never call into zram from
the scheduler. Just saying.
> It definitely will add more overhead for the submission/completion paths to deal
> with the refcount, but I think we should go that way at the cost of runtime.
Dunno, something like below maybe?
---
drivers/block/zram/zram_drv.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index ce2e1c79fc75..27fe50d666d7 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -967,7 +967,7 @@ static int zram_writeback_complete(struct zram *zram, struct zram_wb_req *req)
static void zram_writeback_endio(struct bio *bio)
{
struct zram_wb_req *req = container_of(bio, struct zram_wb_req, bio);
- struct zram_wb_ctl *wb_ctl = bio->bi_private;
+ struct zram_wb_ctl *wb_ctl = READ_ONCE(bio->bi_private);
unsigned long flags;
spin_lock_irqsave(&wb_ctl->done_lock, flags);
@@ -975,6 +975,7 @@ static void zram_writeback_endio(struct bio *bio)
spin_unlock_irqrestore(&wb_ctl->done_lock, flags);
wake_up(&wb_ctl->done_wait);
+ atomic_dec(&wb_ctl->num_inflight);
}
static void zram_submit_wb_request(struct zram *zram,
@@ -998,7 +999,7 @@ static int zram_complete_done_reqs(struct zram *zram,
unsigned long flags;
int ret = 0, err;
- while (atomic_read(&wb_ctl->num_inflight) > 0) {
+ for (;;) {
spin_lock_irqsave(&wb_ctl->done_lock, flags);
req = list_first_entry_or_null(&wb_ctl->done_reqs,
struct zram_wb_req, entry);
@@ -1006,7 +1007,6 @@ static int zram_complete_done_reqs(struct zram *zram,
list_del(&req->entry);
spin_unlock_irqrestore(&wb_ctl->done_lock, flags);
- /* ->num_inflight > 0 doesn't mean we have done requests */
if (!req)
break;
@@ -1014,7 +1014,6 @@ static int zram_complete_done_reqs(struct zram *zram,
if (err)
ret = err;
- atomic_dec(&wb_ctl->num_inflight);
release_pp_slot(zram, req->pps);
req->pps = NULL;
@@ -1129,8 +1128,11 @@ static int zram_writeback_slots(struct zram *zram,
if (req)
release_wb_req(req);
- while (atomic_read(&wb_ctl->num_inflight) > 0) {
- wait_event(wb_ctl->done_wait, !list_empty(&wb_ctl->done_reqs));
+ while (atomic_read(&wb_ctl->num_inflight) ||
+ !list_empty(&wb_ctl->done_reqs)) {
+ wait_event_timeout(wb_ctl->done_wait,
+ !list_empty(&wb_ctl->done_reqs),
+ HZ);
err = zram_complete_done_reqs(zram, wb_ctl);
if (err)
ret = err;
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* Re: [PATCH v3 00/10] Add dmabuf read/write via io_uring
From: Ming Lei @ 2026-05-07 9:50 UTC (permalink / raw)
To: Pavel Begunkov
Cc: Jens Axboe, Keith Busch, Christoph Hellwig, Sagi Grimberg,
Alexander Viro, Christian Brauner, Andrew Morton, Sumit Semwal,
Christian König, linux-block, linux-kernel, linux-nvme,
linux-fsdevel, io-uring, linux-media, dri-devel, linaro-mm-sig,
Nitesh Shetty, Kanchan Joshi, Anuj Gupta, Tushar Gohad,
William Power, Phil Cayton, Jason Gunthorpe
In-Reply-To: <6873d617-c904-45f3-bad9-e1ae39cfecd2@gmail.com>
On Wed, May 06, 2026 at 10:02:11AM +0100, Pavel Begunkov wrote:
> Hey Ming,
>
> On 5/4/26 16:29, Ming Lei wrote:
> > On Wed, Apr 29, 2026 at 04:25:46PM +0100, Pavel Begunkov wrote:
> > > The patch set allows to register a dmabuf to an io_uring instance for
> > > a specified file and use it with io_uring read / write requests. The
> > > infrastructure is not tied to io_uring and there could be more users
> > > in the future. A similar idea was attempted some years ago by Keith [1],
> > > from where I borrowed a good number of changes, and later was brough up
> > > by Tushar and Vishal from Intel.
> > >
> > > It's an opt-in feature for files, and they need to implement a new
> > > file operation to use it. Only NVMe block devices are supported in this
> > > series. The user API is built on top of io_uring's "registered buffers",
> > > where a dmabuf is registered in a special way, but after it can be used
> > > as any other "registered buffer" with IORING_OP_{READ,WRITE}_FIXED
> > > requests. It's created via a new file operation and the resulted map is
> > > then passed through the I/O stack in a new iterator type. There is some
> > > additional infrastructure to bind it all, which also counts requests
> > > using a dmabuf map and managing lifetimes, which is used to implement
> > > map invalidation.
> > >
> > > It was tested for GPU <-> NVMe transfers. Also, as it maintains a
> > > long-term dma mapping, it helps with the IOMMU cost. The numbers
> > > below are for udmabuf reads previously run by Anuj for different
> > > IOMMU modes:
> >
> > Plain registered buffer is long-live too, which raises question: does this
> > framework need to take it into account from beginning?
>
> Not sure I follow, mind expanding on what should be accounted?
> Are you suggesting that we might want to use normal registered
> buffers in a similar way? I.e. giving the driver an ability to
> pre-register them?
Yeah, normal registered buffer is long-live too, which is exactly
what the driver cares for the long-term dma mapping motivation.
>
> > BTW, inspired by this approach, I adds similar feature to ublk via UBLK_IO_F_SHMEM_ZC
> > which can maintain long-term vfio dma mapping over registered user-place aligned buffer.
>
> Interesting, just too a glance, and it looks like what David Wei
> was thinking to add to fuse, but IIUC he gave up exactly because the
> client will need to cooperate and that could be troublesome.
Here the cooperation is minimized, maybe one shmem/hugetlb path, or memfd,
and it is one optimization and opt-in, and fallback to normal path
if application doesn't cooperate.
>
> Should we try to push everything under the same interface instead of
> keeping a ublk specific one? Again to the point that it requires
If generic interface can be figured out, it shouldn't be a big deal for
ublk to switch to it, and the usage is simple actually.
So far, ublk supports both FS and nvme block device.
And cooperation can't be avoided for this usage no matter if generic or
driver specific implementation is taken, for both fuse & ublk.
> a cooperative client, but if it's something more generic, the user
> might just try to use it as a general optimisation. In the same way
> it'll be helpful to fuse, and as a bonus you wouldn't need tree look
> ups (but mandates clients using registered buffers as a downside).
Yeah, but tree lookup is fast enough in case of huge page for typical
application, and it is simple in concept.
Thanks,
Ming
^ permalink raw reply
* Re: [PATCH v6 1/1] block/blk-mq: use atomic_t for quiesce_depth to avoid lock contention on RT
From: Bart Van Assche @ 2026-05-07 10:41 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Ionut Nechita (Wind River), axboe, linux-block, clrkwllms,
rostedt, ming.lei, muchun.song, mkhalfella, chris.friesen,
linux-kernel, linux-rt-devel, linux-rt-users, stable, ionut_n2001,
sunlightlinux
In-Reply-To: <20260507074502.cFMtH9BB@linutronix.de>
On 5/7/26 9:45 AM, Sebastian Andrzej Siewior wrote:
> On 2026-05-06 11:43:32 [+0200], Bart Van Assche wrote:
>> On 5/6/26 9:47 AM, Sebastian Andrzej Siewior wrote:
>>> On 2026-05-06 09:14:33 [+0200], Bart Van Assche wrote:
>>>> If the atomic_inc() in blk_mq_quiesce_queue_nowait() is protected by
>>>> hctx->queue->queue_lock then the above code doesn't have to be modified.
>>>
>>> But wouldn't the atomic_inc + barrier avoid the need to have the lock?
>>> Isn't this a normal pattern? If the lock is kept, we could use
>>> non-atomic ops here then. But this avoids having the lock.
>>
>> I strongly prefer a spinlock + non-atomic variables rather than using an
>> atomic variable and barriers because algorithms that use a spinlock are
>> easier to verify.
>
> Hmmm. If we keep the lock, then there is no need for the atomic and we
> keep int counter. Then we are where we are right now with the lock
> synchronizing everything.
> Isn't this also improving the performance for the !RT case or is it
> simply not that visible here?
Agreed that not obtaining the queue_lock from blk_mq_run_hw_queue() is
an interesting improvement. But I'm not sure the new
smp_mb__after_atomic() and smp_rmb() calls are needed. Block layer calls
of blk_mq_quiesce_queue_nowait() are followed by a
blk_mq_wait_quiesce_done() call. The latter calls either
synchronize_srcu() or synchronize_rcu(). Either is sufficient to
guarantee global visibility of the change of the queue state to "quiesced".
This patch removes a spin_lock() call from
blk_mq_quiesce_queue_nowait(). That spin_lock() call guarantees that
other CPUs will observe the "quiesced" state after the store operations
that precede the blk_mq_quiesce_queue_nowait() call. I don't think that
any block layer code depends on this but I noticed that this change has
not been mentioned in the patch description. A similar comment applies
to the blk_mq_unquiesce_queue() changes: the ordering guarantees
provided by the removed spin_lock() call have not been preserved. There
is probably code in the block layer that depends on the "unquiesced"
state only being observed after prior stores performed by the same CPU
core.
Thanks,
Bart.
^ permalink raw reply
* [PATCH] block: Fix typo in comment
From: Md Shofiqul Islam @ 2026-05-07 10:58 UTC (permalink / raw)
To: axboe; +Cc: linux-block, linux-kernel, Md Shofiqul Islam
Fix a typo in a comment in bio_split_alignment(): "occured" should
be "occurred".
Signed-off-by: Md Shofiqul Islam <shofiqtest@gmail.com>
---
block/blk-merge.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/blk-merge.c b/block/blk-merge.c
index fcf09325b2..395b23ed95 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -403,7 +403,7 @@ int bio_split_io_at(struct bio *bio, const struct queue_limits *lim,
* there may either be too many discontiguous vectors for the max
* segments limit, or contain virtual boundary gaps without having a
* valid block sized split. A zero byte result means one of those
- * conditions occured.
+ * conditions occurred.
*/
bytes = ALIGN_DOWN(bytes, bio_split_alignment(bio, lim));
if (!bytes)
--
2.54.0.windows.1
^ permalink raw reply related
* Re: [PATCH] block: Fix typo in comment
From: Jens Axboe @ 2026-05-07 11:11 UTC (permalink / raw)
To: Md Shofiqul Islam; +Cc: linux-block, linux-kernel
In-Reply-To: <20260507105836.25757-1-shofiqtest@gmail.com>
On 5/7/26 4:58 AM, Md Shofiqul Islam wrote:
> Fix a typo in a comment in bio_split_alignment(): "occured" should
> be "occurred".
>
> Signed-off-by: Md Shofiqul Islam <shofiqtest@gmail.com>
> ---
> block/blk-merge.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/block/blk-merge.c b/block/blk-merge.c
> index fcf09325b2..395b23ed95 100644
> --- a/block/blk-merge.c
> +++ b/block/blk-merge.c
> @@ -403,7 +403,7 @@ int bio_split_io_at(struct bio *bio, const struct queue_limits *lim,
> * there may either be too many discontiguous vectors for the max
> * segments limit, or contain virtual boundary gaps without having a
> * valid block sized split. A zero byte result means one of those
> - * conditions occured.
> + * conditions occurred.
Generally happy to take typo fixes if they come with real fixes too,
otherwise it's just unnecessary churn that potentially causes stable
backport issues.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH 1/2] block: pass a minsize argument to bio_iov_iter_bounce
From: Pankaj Raghav (Samsung) @ 2026-05-07 11:36 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jens Axboe, Christian Brauner, Darrick J. Wong, linux-block,
linux-xfs, linux-fsdevel
In-Reply-To: <20260507050153.1298375-2-hch@lst.de>
On Thu, May 07, 2026 at 07:01:47AM +0200, Christoph Hellwig wrote:
> When bouncing for block size > PAGE_SIZE file systems that require
> file system block size alignment (e.g. zoned XFS), the bio needs to
> be big enough to fit an entire block.
Not related to the patch but I am wondering why we don't need this for
non-zoned bs > PS configurations.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Looks good.
Reviewed-by: Pankaj Raghav <p.raghav@samsung.com>
--
Pankaj
^ permalink raw reply
* [PATCH] block: blk-merge: Replace == false comparisons with !
From: Md Shofiqul Islam @ 2026-05-07 12:10 UTC (permalink / raw)
To: axboe; +Cc: linux-block, linux-kernel, Md Shofiqul Islam
The kernel coding style prefers the negation operator '!' over explicit
comparison against 'false'. Replace four such comparisons in
ll_new_hw_segment(), ll_merge_requests_fn(), and blk_rq_merge_ok().
Also fix a typo in a comment: "occured" -> "occurred".
Signed-off-by: Md Shofiqul Islam <shofiqtest@gmail.com>
---
block/blk-merge.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/block/blk-merge.c b/block/blk-merge.c
index fcf09325b2..427b77219a 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -403,7 +403,7 @@ int bio_split_io_at(struct bio *bio, const struct queue_limits *lim,
* there may either be too many discontiguous vectors for the max
* segments limit, or contain virtual boundary gaps without having a
* valid block sized split. A zero byte result means one of those
- * conditions occured.
+ * conditions occurred.
*/
bytes = ALIGN_DOWN(bytes, bio_split_alignment(bio, lim));
if (!bytes)
@@ -547,7 +547,7 @@ static inline int ll_new_hw_segment(struct request *req, struct bio *bio,
if (!blk_cgroup_mergeable(req, bio))
goto no_merge;
- if (blk_integrity_merge_bio(req->q, req, bio) == false)
+ if (!blk_integrity_merge_bio(req->q, req, bio))
goto no_merge;
/* discard request merge won't add new segment */
@@ -649,7 +649,7 @@ static int ll_merge_requests_fn(struct request_queue *q, struct request *req,
if (!blk_cgroup_mergeable(req, next->bio))
return 0;
- if (blk_integrity_merge_rq(q, req, next) == false)
+ if (!blk_integrity_merge_rq(q, req, next))
return 0;
if (!bio_crypt_ctx_merge_rq(req, next))
@@ -905,7 +905,7 @@ bool blk_rq_merge_ok(struct request *rq, struct bio *bio)
if (!blk_cgroup_mergeable(rq, bio))
return false;
- if (blk_integrity_merge_bio(rq->q, rq, bio) == false)
+ if (!blk_integrity_merge_bio(rq->q, rq, bio))
return false;
if (!bio_crypt_rq_ctx_compatible(rq, bio))
return false;
@@ -915,7 +915,7 @@ bool blk_rq_merge_ok(struct request *rq, struct bio *bio)
return false;
if (rq->bio->bi_ioprio != bio->bi_ioprio)
return false;
- if (blk_atomic_write_mergeable_rq_bio(rq, bio) == false)
+ if (!blk_atomic_write_mergeable_rq_bio(rq, bio))
return false;
return true;
--
2.54.0.windows.1
^ permalink raw reply related
* Re: [PATCH] block: blk-merge: Replace == false comparisons with !
From: Jens Axboe @ 2026-05-07 12:17 UTC (permalink / raw)
To: Md Shofiqul Islam; +Cc: linux-block, linux-kernel
In-Reply-To: <20260507121056.25801-1-shofiqtest@gmail.com>
On 5/7/26 6:10 AM, Md Shofiqul Islam wrote:
> The kernel coding style prefers the negation operator '!' over explicit
> comparison against 'false'. Replace four such comparisons in
> ll_new_hw_segment(), ll_merge_requests_fn(), and blk_rq_merge_ok().
>
> Also fix a typo in a comment: "occured" -> "occurred".
My previous reply was not an invitation to just add more unnecessary
churn... I said "with a related fix", not "with unnecessary churn".
--
Jens Axboe
^ permalink raw reply
* [PATCH v2 0/8] Support for block device NVMEM providers
From: Loic Poulain @ 2026-05-07 15:24 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Srinivas Kandagatla, Andrew Lunn, Heiner Kallweit,
Russell King, Saravana Kannan
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
Loic Poulain, Konrad Dybcio
On embedded devices, it is common for factory provisioning to store
device-specific information, such as Ethernet or WiFi MAC addresses,
in a dedicated area of an eMMC partition. This avoids the need for
and additional EEPROM/OTP and leverages the persistence of eMMC.
One example is the Arduino UNO-Q, where the WiFi MAC address and the
Bluetooth Device address are stored in the eMMC Boot1 partition.
Until now, accessing this information required a custom bootloader
to read the data and inject it into the Device Tree before handing
control over to the kernel. This approach is fragile and leads to
device-specific workarounds.
Rather than adding a new NVMEM provider specifically to the eMMC
subsystem, the new support operates at the block layer, allowing any
block device to behave like other non-volatile memories such as EEPROM
or OTP.
This series builds on earlier work by Daniel Golle that enables block
devices to act as NVMEM providers:
https://lore.kernel.org/all/6061aa4201030b9bb2f8d03ef32a564fdb786ed1.1709667858.git.daniel@makrotopia.org/
It also introduces an NVMEM layout description for the Arduino UNO-Q,
allowing device-specific data stored in the eMMC Boot1 partition to
be accessed in a standard way.
WiFi and Ethernet already support retrieving MAC addresses from NVMEM.
Bluetooth requires similar support, which is also addressed.
Note that this is currently limited to MMC-backed block devices, as
only the MMC core associates a firmware node with the block device
(add_disk_fwnode). This can be easily extended in the future to
support additional block drivers.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
Changes in v2:
- Fix example nvmem-layout cells to use compatible = "mac-base"
- Squash WiFi MAC and Bluetooth BD address consumer patches into the nvmem layout patch
- Fix possible use-after-free in blk-nvmem: bnv (nvmem priv) linked to nvmem lifetime
- Simplify nvmem-cell-names from items: - const: to plain const:
- Factor out common NVMEM EUI-48 retrieval logic
- Reorder changes
- Link to v1: https://lore.kernel.org/r/20260428-block-as-nvmem-v1-0-6ad23e75190a@oss.qualcomm.com
---
Daniel Golle (1):
block: implement NVMEM provider
Loic Poulain (7):
dt-bindings: mmc: Document support for nvmem-layout
dt-bindings: net: wireless: qcom,ath10k: Add NVMEM MAC address cell
dt-bindings: bluetooth: qcom: Add NVMEM BD address cell
net: of_net: Add of_get_nvmem_eui48() helper for EUI-48 lookup
Bluetooth: hci_sync: Add NVMEM-backed BD address retrieval
Bluetooth: qca: Set NVMEM BD address quirks when address is invalid
arm64: dts: qcom: arduino-imola: Describe NVMEM layout for WiFi/BT addresses
.../devicetree/bindings/mmc/mmc-card.yaml | 24 +++
.../net/bluetooth/qcom,bluetooth-common.yaml | 9 +
.../bindings/net/wireless/qcom,ath10k.yaml | 9 +
arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts | 34 ++++
block/Kconfig | 9 +
block/Makefile | 1 +
block/blk-nvmem.c | 188 +++++++++++++++++++++
drivers/bluetooth/btqca.c | 5 +-
drivers/nvmem/core.c | 13 ++
include/linux/nvmem-consumer.h | 6 +
include/linux/of_net.h | 7 +
include/net/bluetooth/hci.h | 18 ++
net/bluetooth/hci_sync.c | 39 ++++-
net/core/of_net.c | 47 ++++--
14 files changed, 395 insertions(+), 14 deletions(-)
---
base-commit: 47c4835fc0fed583d01d90387b67633950eba2b2
change-id: 20260428-block-as-nvmem-4b308e8bda9a
Best regards,
--
Loic Poulain <loic.poulain@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v2 1/8] dt-bindings: mmc: Document support for nvmem-layout
From: Loic Poulain @ 2026-05-07 15:24 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Srinivas Kandagatla, Andrew Lunn, Heiner Kallweit,
Russell King, Saravana Kannan
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
Loic Poulain
In-Reply-To: <20260507-block-as-nvmem-v2-0-bf17edd5134e@oss.qualcomm.com>
Add support for an nvmem-layout subnode under an eMMC hardware
partition. This allows the partition to be exposed as an NVMEM
provider and its internal layout to be described. For example,
an eMMC boot partition can be used to store device-specific
information such as a WiFi MAC address.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
.../devicetree/bindings/mmc/mmc-card.yaml | 24 ++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.yaml b/Documentation/devicetree/bindings/mmc/mmc-card.yaml
index a61d6c96df759102f9c1fbfd548b026a77921cae..b21426a49cf1d9aae5b4e8e447b5be11b08c96bf 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-card.yaml
+++ b/Documentation/devicetree/bindings/mmc/mmc-card.yaml
@@ -40,6 +40,9 @@ patternProperties:
contains:
const: fixed-partitions
+ nvmem-layout:
+ $ref: /schemas/nvmem/layouts/nvmem-layout.yaml
+
required:
- compatible
- reg
@@ -86,6 +89,27 @@ examples:
read-only;
};
};
+
+ partitions-boot2 {
+ nvmem-layout {
+ compatible = "fixed-layout";
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ mac-addr@4400 {
+ compatible = "mac-base";
+ reg = <0x4400 0x6>;
+ #nvmem-cell-cells = <1>;
+ };
+
+ bd-addr@5400 {
+ compatible = "mac-base";
+ reg = <0x5400 0x6>;
+ #nvmem-cell-cells = <1>;
+ };
+ };
+ };
};
};
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/8] dt-bindings: net: wireless: qcom,ath10k: Add NVMEM MAC address cell
From: Loic Poulain @ 2026-05-07 15:24 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Srinivas Kandagatla, Andrew Lunn, Heiner Kallweit,
Russell King, Saravana Kannan
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
Loic Poulain
In-Reply-To: <20260507-block-as-nvmem-v2-0-bf17edd5134e@oss.qualcomm.com>
Add support for an NVMEM cell provider with the standard "mac-address"
cell name. This allows the ath10k device to retrieve its MAC address
from non-volatile storage such as an EEPROM or an eMMC partition.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
index c21d66c7cd558ab792524be9afec8b79272d1c87..96e025cd1e3acacf3da270ed43955b0d6acdb7de 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
@@ -92,6 +92,15 @@ properties:
ieee80211-freq-limit: true
+ nvmem-cells:
+ maxItems: 1
+ description:
+ Nvmem data cell that contains a 6 byte MAC address with the most
+ significant byte first (big-endian).
+
+ nvmem-cell-names:
+ const: mac-address
+
qcom,calibration-data:
$ref: /schemas/types.yaml#/definitions/uint8-array
description:
--
2.34.1
^ permalink raw reply related
* [PATCH v2 3/8] dt-bindings: bluetooth: qcom: Add NVMEM BD address cell
From: Loic Poulain @ 2026-05-07 15:24 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Srinivas Kandagatla, Andrew Lunn, Heiner Kallweit,
Russell King, Saravana Kannan
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
Loic Poulain
In-Reply-To: <20260507-block-as-nvmem-v2-0-bf17edd5134e@oss.qualcomm.com>
Add support for an NVMEM cell provider for "local-bd-address",
allowing the Bluetooth stack to retrieve controller's BD address
from non-volatile storage such as an EEPROM or an eMMC partition.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
.../devicetree/bindings/net/bluetooth/qcom,bluetooth-common.yaml | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/bluetooth/qcom,bluetooth-common.yaml b/Documentation/devicetree/bindings/net/bluetooth/qcom,bluetooth-common.yaml
index c8e9c55c1afb4c8e05ba2dae41ce2db4194b4a0f..7cb28f30c9af032082f23311f2fc89a32f266f17 100644
--- a/Documentation/devicetree/bindings/net/bluetooth/qcom,bluetooth-common.yaml
+++ b/Documentation/devicetree/bindings/net/bluetooth/qcom,bluetooth-common.yaml
@@ -22,4 +22,13 @@ properties:
description:
boot firmware is incorrectly passing the address in big-endian order
+ nvmem-cells:
+ maxItems: 1
+ description:
+ Nvmem data cell that contains a 6 byte BD address with the most
+ significant byte first (big-endian).
+
+ nvmem-cell-names:
+ const: local-bd-address
+
additionalProperties: true
--
2.34.1
^ permalink raw reply related
* [PATCH v2 4/8] block: implement NVMEM provider
From: Loic Poulain @ 2026-05-07 15:24 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Srinivas Kandagatla, Andrew Lunn, Heiner Kallweit,
Russell King, Saravana Kannan
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
Loic Poulain
In-Reply-To: <20260507-block-as-nvmem-v2-0-bf17edd5134e@oss.qualcomm.com>
From: Daniel Golle <daniel@makrotopia.org>
On embedded devices using an eMMC it is common that one or more partitions
on the eMMC are used to store MAC addresses and Wi-Fi calibration EEPROM
data. Allow referencing the partition in device tree for the kernel and
Wi-Fi drivers accessing it via the NVMEM layer.
To safely defer the freeing of the provider private data until all
consumers have released their cells, a nvmem_dev() accessor is added to
the NVMEM core to expose the struct device embedded in struct nvmem_device.
This allows registering a devm action on the nvmem device itself, ensuring
the private data outlives any active cell references.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Co-developed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
block/Kconfig | 9 ++
block/Makefile | 1 +
block/blk-nvmem.c | 188 +++++++++++++++++++++++++++++++++++++++++
drivers/nvmem/core.c | 13 +++
include/linux/nvmem-consumer.h | 6 ++
5 files changed, 217 insertions(+)
diff --git a/block/Kconfig b/block/Kconfig
index 15027963472d7b40e27b9097a5993c457b5b3054..0b33747e16dc33473683706f75c92bdf8b648f7c 100644
--- a/block/Kconfig
+++ b/block/Kconfig
@@ -209,6 +209,15 @@ config BLK_INLINE_ENCRYPTION_FALLBACK
by falling back to the kernel crypto API when inline
encryption hardware is not present.
+config BLK_NVMEM
+ bool "Block device NVMEM provider"
+ depends on OF
+ depends on NVMEM
+ help
+ Allow block devices (or partitions) to act as NVMEM providers,
+ typically used with eMMC to store MAC addresses or Wi-Fi
+ calibration data on embedded devices.
+
source "block/partitions/Kconfig"
config BLK_PM
diff --git a/block/Makefile b/block/Makefile
index 7dce2e44276c4274c11a0a61121c83d9c43d6e0c..d7ac389e71902bc091a8800ea266190a43b3e63d 100644
--- a/block/Makefile
+++ b/block/Makefile
@@ -36,3 +36,4 @@ obj-$(CONFIG_BLK_INLINE_ENCRYPTION) += blk-crypto.o blk-crypto-profile.o \
blk-crypto-sysfs.o
obj-$(CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK) += blk-crypto-fallback.o
obj-$(CONFIG_BLOCK_HOLDER_DEPRECATED) += holder.o
+obj-$(CONFIG_BLK_NVMEM) += blk-nvmem.o
diff --git a/block/blk-nvmem.c b/block/blk-nvmem.c
new file mode 100644
index 0000000000000000000000000000000000000000..96c0ffc51b1862a75644f3f94add35d59577d86b
--- /dev/null
+++ b/block/blk-nvmem.c
@@ -0,0 +1,188 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * block device NVMEM provider
+ *
+ * Copyright (c) 2024 Daniel Golle <daniel@makrotopia.org>
+ *
+ * Useful on devices using a partition on an eMMC for MAC addresses or
+ * Wi-Fi calibration EEPROM data.
+ */
+
+#include "blk.h"
+#include <linux/nvmem-provider.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/of.h>
+#include <linux/pagemap.h>
+#include <linux/property.h>
+
+static void blk_nvmem_free(void *data)
+{
+ kfree(data);
+}
+
+/* List of all NVMEM devices */
+static LIST_HEAD(nvmem_devices);
+static DEFINE_MUTEX(devices_mutex);
+
+struct blk_nvmem {
+ struct nvmem_device *nvmem;
+ dev_t devt;
+ bool removed;
+ struct list_head list;
+};
+
+static int blk_nvmem_reg_read(void *priv, unsigned int from,
+ void *val, size_t bytes)
+{
+ blk_mode_t mode = BLK_OPEN_READ | BLK_OPEN_RESTRICT_WRITES;
+ unsigned long offs = from & ~PAGE_MASK, to_read;
+ pgoff_t f_index = from >> PAGE_SHIFT;
+ struct blk_nvmem *bnv = priv;
+ size_t bytes_left = bytes;
+ struct file *bdev_file;
+ struct folio *folio;
+ void *p;
+ int ret = 0;
+
+ if (bnv->removed)
+ return -ENODEV;
+
+ bdev_file = bdev_file_open_by_dev(bnv->devt, mode, priv, NULL);
+ if (!bdev_file)
+ return -ENODEV;
+
+ if (IS_ERR(bdev_file))
+ return PTR_ERR(bdev_file);
+
+ while (bytes_left) {
+ folio = read_mapping_folio(bdev_file->f_mapping, f_index++, NULL);
+ if (IS_ERR(folio)) {
+ ret = PTR_ERR(folio);
+ goto err_release_bdev;
+ }
+ to_read = min_t(unsigned long, bytes_left, PAGE_SIZE - offs);
+ p = folio_address(folio) + offset_in_folio(folio, offs);
+ memcpy(val, p, to_read);
+ offs = 0;
+ bytes_left -= to_read;
+ val += to_read;
+ folio_put(folio);
+ }
+
+err_release_bdev:
+ fput(bdev_file);
+
+ return ret;
+}
+
+static int blk_nvmem_register(struct device *dev)
+{
+ struct device_node *np = dev_of_node(dev);
+ struct block_device *bdev = dev_to_bdev(dev);
+ struct nvmem_config config = {};
+ struct blk_nvmem *bnv;
+
+ /* skip devices which do not have a device tree node */
+ if (!np)
+ return 0;
+
+ /* skip devices without an nvmem layout defined */
+ if (!of_get_child_by_name(np, "nvmem-layout"))
+ return 0;
+
+ /*
+ * skip block device too large to be represented as NVMEM devices
+ * which are using an 'int' as address
+ */
+ if (bdev_nr_bytes(bdev) > INT_MAX)
+ return -EFBIG;
+
+ bnv = kzalloc_obj(*bnv);
+ if (!bnv)
+ return -ENOMEM;
+
+ config.id = NVMEM_DEVID_NONE;
+ config.dev = &bdev->bd_device;
+ config.name = dev_name(&bdev->bd_device);
+ config.owner = THIS_MODULE;
+ config.priv = bnv;
+ config.reg_read = blk_nvmem_reg_read;
+ config.size = bdev_nr_bytes(bdev);
+ config.word_size = 1;
+ config.stride = 1;
+ config.read_only = true;
+ config.root_only = true;
+ config.ignore_wp = true;
+ config.of_node = to_of_node(dev->fwnode);
+
+ bnv->devt = bdev->bd_device.devt;
+ bnv->nvmem = nvmem_register(&config);
+ if (IS_ERR(bnv->nvmem)) {
+ dev_err_probe(&bdev->bd_device, PTR_ERR(bnv->nvmem),
+ "Failed to register NVMEM device\n");
+
+ kfree(bnv);
+ return PTR_ERR(bnv->nvmem);
+ }
+
+ /*
+ * Free bnv only when the nvmem device is fully released (i.e. when
+ * its kref hits zero), not at unregister time. This prevents a
+ * use-after-free if a consumer still holds an nvmem_cell reference
+ * when the block device is removed: nvmem_unregister() only does a
+ * kref_put(), so reg_read could still be called with bnv as priv
+ * until the last consumer drops its cell.
+ */
+ if (devm_add_action(nvmem_dev(bnv->nvmem), blk_nvmem_free, bnv)) {
+ nvmem_unregister(bnv->nvmem);
+ kfree(bnv);
+ return -ENOMEM;
+ }
+
+ mutex_lock(&devices_mutex);
+ list_add_tail(&bnv->list, &nvmem_devices);
+ mutex_unlock(&devices_mutex);
+
+ return 0;
+}
+
+static void blk_nvmem_unregister(struct device *dev)
+{
+ struct blk_nvmem *bnv_c, *bnv = NULL;
+
+ mutex_lock(&devices_mutex);
+ list_for_each_entry(bnv_c, &nvmem_devices, list) {
+ if (bnv_c->devt == dev_to_bdev(dev)->bd_device.devt) {
+ bnv = bnv_c;
+ break;
+ }
+ }
+
+ if (!bnv) {
+ mutex_unlock(&devices_mutex);
+ return;
+ }
+
+ list_del(&bnv->list);
+ mutex_unlock(&devices_mutex);
+ bnv->removed = true;
+ nvmem_unregister(bnv->nvmem);
+}
+
+static struct class_interface blk_nvmem_bus_interface __refdata = {
+ .class = &block_class,
+ .add_dev = &blk_nvmem_register,
+ .remove_dev = &blk_nvmem_unregister,
+};
+
+static int __init blk_nvmem_init(void)
+{
+ int ret;
+
+ ret = class_interface_register(&blk_nvmem_bus_interface);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+device_initcall(blk_nvmem_init);
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 311cb2e5a5c02d2c6979d7c9bbb7f94abdfbdad1..ee3481229c20b3063c86d0dd66aabbf6b5e29169 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -2154,6 +2154,19 @@ const char *nvmem_dev_name(struct nvmem_device *nvmem)
}
EXPORT_SYMBOL_GPL(nvmem_dev_name);
+/**
+ * nvmem_dev() - Get the struct device of a given nvmem device.
+ *
+ * @nvmem: nvmem device.
+ *
+ * Return: pointer to the struct device of the nvmem device.
+ */
+struct device *nvmem_dev(struct nvmem_device *nvmem)
+{
+ return &nvmem->dev;
+}
+EXPORT_SYMBOL_GPL(nvmem_dev);
+
/**
* nvmem_dev_size() - Get the size of a given nvmem device.
*
diff --git a/include/linux/nvmem-consumer.h b/include/linux/nvmem-consumer.h
index 34c0e58dfa26636d2804fcc7e0bc4a875ee73dae..ce387c89dc8e4bc1241f3b6f36be8c6c95e282ed 100644
--- a/include/linux/nvmem-consumer.h
+++ b/include/linux/nvmem-consumer.h
@@ -82,6 +82,7 @@ int nvmem_device_cell_write(struct nvmem_device *nvmem,
const char *nvmem_dev_name(struct nvmem_device *nvmem);
size_t nvmem_dev_size(struct nvmem_device *nvmem);
+struct device *nvmem_dev(struct nvmem_device *nvmem);
void nvmem_add_cell_lookups(struct nvmem_cell_lookup *entries,
size_t nentries);
@@ -220,6 +221,11 @@ static inline const char *nvmem_dev_name(struct nvmem_device *nvmem)
return NULL;
}
+static inline struct device *nvmem_dev(struct nvmem_device *nvmem)
+{
+ return NULL;
+}
+
static inline void
nvmem_add_cell_lookups(struct nvmem_cell_lookup *entries, size_t nentries) {}
static inline void
--
2.34.1
^ permalink raw reply related
* [PATCH v2 5/8] net: of_net: Add of_get_nvmem_eui48() helper for EUI-48 lookup
From: Loic Poulain @ 2026-05-07 15:24 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Srinivas Kandagatla, Andrew Lunn, Heiner Kallweit,
Russell King, Saravana Kannan
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
Loic Poulain
In-Reply-To: <20260507-block-as-nvmem-v2-0-bf17edd5134e@oss.qualcomm.com>
Factor out the common NVMEM EUI-48 retrieval logic from
of_get_mac_address_nvmem() into a new of_get_nvmem_eui48() helper that
accepts the NVMEM cell name as a parameter. This allows other subsystems
(e.g. Bluetooth) to reuse the same lookup-validate-copy pattern with a
different cell name, without duplicating code.
of_get_mac_address_nvmem() is updated to call of_get_nvmem_eui48() with
"mac-address", preserving its existing behavior.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
include/linux/of_net.h | 7 +++++++
net/core/of_net.c | 47 +++++++++++++++++++++++++++++++++++------------
2 files changed, 42 insertions(+), 12 deletions(-)
diff --git a/include/linux/of_net.h b/include/linux/of_net.h
index d88715a0b3a52f87af23d47791bea3baf5be5200..7854ba555d9a55f3d020a37fe00a27ae52e0e5dc 100644
--- a/include/linux/of_net.h
+++ b/include/linux/of_net.h
@@ -15,6 +15,7 @@ struct net_device;
extern int of_get_phy_mode(struct device_node *np, phy_interface_t *interface);
extern int of_get_mac_address(struct device_node *np, u8 *mac);
extern int of_get_mac_address_nvmem(struct device_node *np, u8 *mac);
+int of_get_nvmem_eui48(struct device_node *np, const char *cell_name, u8 *addr);
int of_get_ethdev_address(struct device_node *np, struct net_device *dev);
extern struct net_device *of_find_net_device_by_node(struct device_node *np);
#else
@@ -34,6 +35,12 @@ static inline int of_get_mac_address_nvmem(struct device_node *np, u8 *mac)
return -ENODEV;
}
+static inline int of_get_nvmem_eui48(struct device_node *np,
+ const char *cell_name, u8 *addr)
+{
+ return -ENODEV;
+}
+
static inline int of_get_ethdev_address(struct device_node *np, struct net_device *dev)
{
return -ENODEV;
diff --git a/net/core/of_net.c b/net/core/of_net.c
index 93ea425b9248a23f4f95a336e9cdbf0053248e32..79b289de0f16aa5f8724e84d6f2300648c25b6c4 100644
--- a/net/core/of_net.c
+++ b/net/core/of_net.c
@@ -61,9 +61,6 @@ static int of_get_mac_addr(struct device_node *np, const char *name, u8 *addr)
int of_get_mac_address_nvmem(struct device_node *np, u8 *addr)
{
struct platform_device *pdev = of_find_device_by_node(np);
- struct nvmem_cell *cell;
- const void *mac;
- size_t len;
int ret;
/* Try lookup by device first, there might be a nvmem_cell_lookup
@@ -75,27 +72,53 @@ int of_get_mac_address_nvmem(struct device_node *np, u8 *addr)
return ret;
}
- cell = of_nvmem_cell_get(np, "mac-address");
+ ret = of_get_nvmem_eui48(np, "mac-address", addr);
+ if (ret)
+ return ret;
+
+ if (!is_valid_ether_addr(addr))
+ return -EINVAL;
+
+ return 0;
+}
+EXPORT_SYMBOL(of_get_mac_address_nvmem);
+
+/**
+ * of_get_nvmem_eui48 - Read a 6-byte EUI-48 address from a named NVMEM cell.
+ * @np: Device node to look up the NVMEM cell from.
+ * @cell_name: Name of the NVMEM cell (e.g. "mac-address", "local-bd-address").
+ * @addr: Output buffer for the 6-byte address.
+ *
+ * Reads the named NVMEM cell and validates that it contains a non-zero 6-byte
+ * address. Returns 0 on success, negative errno on failure.
+ */
+int of_get_nvmem_eui48(struct device_node *np, const char *cell_name, u8 *addr)
+{
+ struct nvmem_cell *cell;
+ const void *eui48;
+ size_t len;
+
+ cell = of_nvmem_cell_get(np, cell_name);
if (IS_ERR(cell))
return PTR_ERR(cell);
- mac = nvmem_cell_read(cell, &len);
+ eui48 = nvmem_cell_read(cell, &len);
nvmem_cell_put(cell);
- if (IS_ERR(mac))
- return PTR_ERR(mac);
+ if (IS_ERR(eui48))
+ return PTR_ERR(eui48);
- if (len != ETH_ALEN || !is_valid_ether_addr(mac)) {
- kfree(mac);
+ if (len != ETH_ALEN || !memchr_inv(eui48, 0, ETH_ALEN)) {
+ kfree(eui48);
return -EINVAL;
}
- memcpy(addr, mac, ETH_ALEN);
- kfree(mac);
+ memcpy(addr, eui48, ETH_ALEN);
+ kfree(eui48);
return 0;
}
-EXPORT_SYMBOL(of_get_mac_address_nvmem);
+EXPORT_SYMBOL_GPL(of_get_nvmem_eui48);
/**
* of_get_mac_address()
--
2.34.1
^ permalink raw reply related
* [PATCH v2 6/8] Bluetooth: hci_sync: Add NVMEM-backed BD address retrieval
From: Loic Poulain @ 2026-05-07 15:24 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Srinivas Kandagatla, Andrew Lunn, Heiner Kallweit,
Russell King, Saravana Kannan
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
Loic Poulain
In-Reply-To: <20260507-block-as-nvmem-v2-0-bf17edd5134e@oss.qualcomm.com>
Some devices store the Bluetooth BD address in non-volatile
memory, which can be accessed through the NVMEM framework.
Similar to Ethernet or WiFi MAC addresses, add support for
reading the BD address from a 'local-bd-address' NVMEM cell.
As with the device-tree provided BD address, add a quirk to
indicate whether a device or platform should attempt to read
the address from NVMEM when no valid in-chip address is present.
Also add a quirk to indicate if the address is stored in
big-endian byte order.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
include/net/bluetooth/hci.h | 18 ++++++++++++++++++
net/bluetooth/hci_sync.c | 39 ++++++++++++++++++++++++++++++++++++++-
2 files changed, 56 insertions(+), 1 deletion(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 572b1c620c5d653a1fe10b26c1b0ba33e8f4968f..7686466d1109253b0d75edeb5f6a99fb98ce4cc6 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -164,6 +164,24 @@ enum {
*/
HCI_QUIRK_BDADDR_PROPERTY_BROKEN,
+ /* When this quirk is set, the public Bluetooth address
+ * initially reported by HCI Read BD Address command
+ * is considered invalid. The public BD Address can be
+ * retrieved via a 'local-bd-address' NVMEM cell.
+ *
+ * This quirk can be set before hci_register_dev is called or
+ * during the hdev->setup vendor callback.
+ */
+ HCI_QUIRK_USE_BDADDR_NVMEM,
+
+ /* When this quirk is set, the Bluetooth Device Address provided by
+ * the 'local-bd-address' NVMEM is stored in big-endian order.
+ *
+ * This quirk can be set before hci_register_dev is called or
+ * during the hdev->setup vendor callback.
+ */
+ HCI_QUIRK_BDADDR_NVMEM_BE,
+
/* When this quirk is set, the duplicate filtering during
* scanning is based on Bluetooth devices addresses. To allow
* RSSI based updates, restart scanning if needed.
diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
index fd3aacdea512a37c22b9a2be90c89ddca4b4d99f..589ccdfa26c1281d6eb979370523fff0d7920302 100644
--- a/net/bluetooth/hci_sync.c
+++ b/net/bluetooth/hci_sync.c
@@ -7,6 +7,7 @@
*/
#include <linux/property.h>
+#include <linux/of_net.h>
#include <net/bluetooth/bluetooth.h>
#include <net/bluetooth/hci_core.h>
@@ -3588,6 +3589,37 @@ int hci_powered_update_sync(struct hci_dev *hdev)
return 0;
}
+/**
+ * hci_dev_get_bd_addr_from_nvmem - Get the Bluetooth Device Address
+ * (BD_ADDR) for a HCI device from
+ * an NVMEM cell.
+ * @hdev: The HCI device
+ *
+ * Search for 'local-bd-address' NVMEM cell in the device firmware node.
+ *
+ * All-zero BD addresses are rejected (unprovisioned).
+ */
+static int hci_dev_get_bd_addr_from_nvmem(struct hci_dev *hdev)
+{
+ struct device_node *np = dev_of_node(hdev->dev.parent);
+ u8 ba[sizeof(bdaddr_t)];
+ int err;
+
+ if (!np)
+ return -ENODEV;
+
+ err = of_get_nvmem_eui48(np, "local-bd-address", ba);
+ if (err)
+ return err;
+
+ if (hci_test_quirk(hdev, HCI_QUIRK_BDADDR_NVMEM_BE))
+ baswap(&hdev->public_addr, (bdaddr_t *)ba);
+ else
+ bacpy(&hdev->public_addr, (bdaddr_t *)ba);
+
+ return 0;
+}
+
/**
* hci_dev_get_bd_addr_from_property - Get the Bluetooth Device Address
* (BD_ADDR) for a HCI device from
@@ -5042,12 +5074,17 @@ static int hci_dev_setup_sync(struct hci_dev *hdev)
* its setup callback.
*/
invalid_bdaddr = hci_test_quirk(hdev, HCI_QUIRK_INVALID_BDADDR) ||
- hci_test_quirk(hdev, HCI_QUIRK_USE_BDADDR_PROPERTY);
+ hci_test_quirk(hdev, HCI_QUIRK_USE_BDADDR_PROPERTY) ||
+ hci_test_quirk(hdev, HCI_QUIRK_USE_BDADDR_NVMEM);
if (!ret) {
if (hci_test_quirk(hdev, HCI_QUIRK_USE_BDADDR_PROPERTY) &&
!bacmp(&hdev->public_addr, BDADDR_ANY))
hci_dev_get_bd_addr_from_property(hdev);
+ if (hci_test_quirk(hdev, HCI_QUIRK_USE_BDADDR_NVMEM) &&
+ !bacmp(&hdev->public_addr, BDADDR_ANY))
+ hci_dev_get_bd_addr_from_nvmem(hdev);
+
if (invalid_bdaddr && bacmp(&hdev->public_addr, BDADDR_ANY) &&
hdev->set_bdaddr) {
ret = hdev->set_bdaddr(hdev, &hdev->public_addr);
--
2.34.1
^ permalink raw reply related
* [PATCH v2 7/8] Bluetooth: qca: Set NVMEM BD address quirks when address is invalid
From: Loic Poulain @ 2026-05-07 15:24 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Srinivas Kandagatla, Andrew Lunn, Heiner Kallweit,
Russell King, Saravana Kannan
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
Loic Poulain
In-Reply-To: <20260507-block-as-nvmem-v2-0-bf17edd5134e@oss.qualcomm.com>
When the controller BD address is invalid (zero or default),
set the NVMEM quirks to allow retrieving the address from a
'local-bd-address' NVMEM cell. The BD address is often stored
alongside the WiFi MAC address in big-endian format, so also
set the big-endian quirk.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
drivers/bluetooth/btqca.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c
index dda76365726f0bfe0e80e05fe04859fa4f0592e1..df33eacfd29fa680f393f90215150743e6001d5b 100644
--- a/drivers/bluetooth/btqca.c
+++ b/drivers/bluetooth/btqca.c
@@ -721,8 +721,11 @@ static int qca_check_bdaddr(struct hci_dev *hdev, const struct qca_fw_config *co
}
bda = (struct hci_rp_read_bd_addr *)skb->data;
- if (!bacmp(&bda->bdaddr, &config->bdaddr))
+ if (!bacmp(&bda->bdaddr, &config->bdaddr)) {
hci_set_quirk(hdev, HCI_QUIRK_USE_BDADDR_PROPERTY);
+ hci_set_quirk(hdev, HCI_QUIRK_USE_BDADDR_NVMEM);
+ hci_set_quirk(hdev, HCI_QUIRK_BDADDR_NVMEM_BE);
+ }
kfree_skb(skb);
--
2.34.1
^ permalink raw reply related
* [PATCH v2 8/8] arm64: dts: qcom: arduino-imola: Describe NVMEM layout for WiFi/BT addresses
From: Loic Poulain @ 2026-05-07 15:24 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Srinivas Kandagatla, Andrew Lunn, Heiner Kallweit,
Russell King, Saravana Kannan
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
Loic Poulain, Konrad Dybcio
In-Reply-To: <20260507-block-as-nvmem-v2-0-bf17edd5134e@oss.qualcomm.com>
On Arduino Uno-Q, the eMMC boot1 partition is factory provisioned
with device-specific information such as the WiFi MAC address
and the Bluetooth BD address. This partition can serve as an
alternative to additional non-volatile memory, such as a
dedicated EEPROM.
The eMMC boot partitions are typically good candidates, as they
are relatively small, read-only by default (and can be enforced
as hardware read-only), and are not affected by board reflashing
procedures, which generally target the eMMC user or GP partitions.
Describe the corresponding nvmem-layout for the WiFi and Bluetooth
addresses, and point the WiFi and Bluetooth nodes to the appropriate
NVMEM cells to retrieve them.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts | 34 ++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts b/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts
index bf088fa9807f040f0c8f405f9111b01790b09377..6ed91cccae2fbf0723629a4db12d2724312d50b2 100644
--- a/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts
+++ b/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts
@@ -409,7 +409,35 @@ &sdhc_1 {
no-sdio;
no-sd;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
status = "okay";
+
+ card@0 {
+ compatible = "mmc-card";
+ reg = <0>;
+
+ partitions-boot1 {
+ nvmem-layout {
+ compatible = "fixed-layout";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ wifi_mac_addr: mac-addr@4400 {
+ compatible = "mac-base";
+ reg = <0x4400 0x6>;
+ #nvmem-cell-cells = <1>;
+ };
+
+ bd_addr: bd-addr@5400 {
+ compatible = "mac-base";
+ reg = <0x5400 0x6>;
+ #nvmem-cell-cells = <1>;
+ };
+ };
+ };
+ };
};
&spi5 {
@@ -512,6 +540,9 @@ bluetooth {
vddch0-supply = <&pm4125_l22>;
enable-gpios = <&tlmm 87 GPIO_ACTIVE_HIGH>;
max-speed = <3000000>;
+
+ nvmem-cells = <&bd_addr 0>;
+ nvmem-cell-names = "local-bd-address";
};
};
@@ -557,6 +588,9 @@ &wifi {
qcom,ath10k-calibration-variant = "ArduinoImola";
firmware-name = "qcm2290";
+ nvmem-cells = <&wifi_mac_addr 0>;
+ nvmem-cell-names = "mac-address";
+
status = "okay";
};
--
2.34.1
^ permalink raw reply related
* Re: [PATCH RFC 1/2] nvme: downgrade WARN in nvme_setup_rw to pr_debug
From: Keith Busch @ 2026-05-07 18:12 UTC (permalink / raw)
To: Chao Shi
Cc: linux-nvme, linux-block, hch, sagi, axboe, Sungwoo Kim, Dave Tian,
Weidong Zhu
In-Reply-To: <20260427003457.1264511-1-coshi036@gmail.com>
On Sun, Apr 26, 2026 at 08:34:56PM -0400, Chao Shi wrote:
> In both cases the bio was submitted without REQ_INTEGRITY (because
> blk_get_integrity() returned NULL at dispatch time, so
> bio_integrity_action() returned 0 and bio_integrity_prep() was not
> called), and it reaches nvme_setup_rw() for a namespace where
> head->ms != 0. The existing BLK_STS_NOTSUPP return correctly handles
> this dispatch; the WARN_ON_ONCE is a false positive.
This is what I'm not really following. The cached request holds a
reference on the queue that prevents the queue freeze from proceeding.
This driver freezes the queue along with the queue limits update. As I
mentioned in the other patch, that was supposed to ensure the block
layer had the updated limits before it could allocate a request, so I
think we need to understand how that was defeated to get to a real
solution.
^ permalink raw reply
* Re: [PATCH 6.12] block: fix memory leak in in bio_map_user_iov()
From: Fedor Pchelkin @ 2026-05-07 18:52 UTC (permalink / raw)
To: Dmitry Antipov
Cc: Greg Kroah-Hartman, stable, Jens Axboe, linux-block,
Christoph Hellwig, lvc-project
In-Reply-To: <20260505094529.406783-1-dmantipov@yandex.ru>
Hi,
On Tue, 05. May 12:45, Dmitry Antipov wrote:
> Local fuzzing has observed the following issue with 6.12.82 (and
> then reproduced with 6.12.85 as well):
>
> BUG: memory leak
> unreferenced object 0xffff88810c568000 (size 2048):
> comm "syz.2.17", pid 1369, jiffies 4294894662
> hex dump (first 32 bytes):
> a8 62 6f 15 80 88 ff ff 00 00 00 00 00 00 00 00 .bo.............
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> backtrace (crc 43ffe8f):
> kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline]
> slab_post_alloc_hook mm/slub.c:4152 [inline]
> slab_alloc_node mm/slub.c:4197 [inline]
> __do_kmalloc_node mm/slub.c:4331 [inline]
> __kmalloc_node_noprof+0x428/0x510 mm/slub.c:4338
> __kvmalloc_node_noprof+0xb5/0x240 mm/util.c:658
> kvmalloc_array_node_noprof include/linux/slab.h:1040 [inline]
> want_pages_array lib/iov_iter.c:992 [inline]
> iov_iter_extract_user_pages lib/iov_iter.c:1818 [inline]
Presumably root of the problem is located inside
iov_iter_extract_user_pages(). I suppose the leak you're hitting is
because pin_user_pages_fast() there fails, right?
In some form the issue is present in current upstream as well. For
example, there is another callsite of iov_iter_extract_pages() in
block/bio-integrity.c where the same pattern still persists. This implies
we'd better fix the callee and make it clean up any memory it may have
already allocated in case it fails. [ there's about a dozen of
iov_iter_extract_pages() callsites in mainline, they should be checked
of course when adding constraints to the function contract ]
That change could then be ported to the relevant stable kernels as well
without big conflicts.
> iov_iter_extract_pages+0x51b/0x14d0 lib/iov_iter.c:1884
> bio_map_user_iov+0x325/0xa50 block/blk-map.c:304
> blk_rq_map_user_iov+0x248/0x790 block/blk-map.c:646
> blk_rq_map_user+0x123/0x190 block/blk-map.c:673
> scsi_bsg_sg_io_fn+0x8d4/0xb00 drivers/scsi/scsi_bsg.c:53
> bsg_sg_io+0x1b7/0x2b0 block/bsg.c:67
> bsg_ioctl+0x3a4/0x5b0 block/bsg.c:151
> vfs_ioctl fs/ioctl.c:51 [inline]
> __do_sys_ioctl fs/ioctl.c:907 [inline]
> __se_sys_ioctl fs/ioctl.c:893 [inline]
> __x64_sys_ioctl+0x194/0x220 fs/ioctl.c:893
> do_syscall_x64 arch/x86/entry/common.c:47 [inline]
> do_syscall_64+0x90/0x170 arch/x86/entry/common.c:78
> entry_SYSCALL_64_after_hwframe+0x76/0x7e
>
> Since 'iov_iter_extract_user_pages()' may reallocate (that is,
> replace an initial stack-allocated array with the one allocated via
> 'kvmalloc_array()'), this array must be freed, if actually replaced,
> when handling error returned from 'iov_iter_extract_pages()'.
>
> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
> ---
> (not sure about Fixes: due to a lot of renames and moves in this area)
If agreed on the need for iov_iter_extract_user_pages() adjustment, then
it could be 7d58fe731028 ("iov_iter: Add a function to extract a page list
from an iterator").
> ---
> block/blk-map.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/block/blk-map.c b/block/blk-map.c
> index b5fd1d857461..8523646054f0 100644
> --- a/block/blk-map.c
> +++ b/block/blk-map.c
> @@ -305,6 +305,8 @@ static int bio_map_user_iov(struct request *rq, struct iov_iter *iter,
> nr_vecs, extraction_flags, &offs);
> if (unlikely(bytes <= 0)) {
> ret = bytes ? bytes : -EFAULT;
> + if (pages != stack_pages)
> + kvfree(pages);
> goto out_unmap;
> }
>
> --
> 2.54.0
^ permalink raw reply
* Re: [PATCH] zram: fix use-after-free in zram_writeback_endio
From: Minchan Kim @ 2026-05-07 22:56 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Richard Chang, Jens Axboe, Andrew Morton, bgeffon, liumartin,
linux-kernel, linux-block, linux-mm
In-Reply-To: <afw2919RiZje9xzq@google.com>
On Thu, May 07, 2026 at 06:40:37PM +0900, Sergey Senozhatsky wrote:
> On (26/05/05 09:37), Minchan Kim wrote:
> > > @@ -966,9 +966,8 @@ static void zram_writeback_endio(struct bio *bio)
> > >
> > > spin_lock_irqsave(&wb_ctl->done_lock, flags);
> > > list_add(&req->entry, &wb_ctl->done_reqs);
> > > - spin_unlock_irqrestore(&wb_ctl->done_lock, flags);
> > > -
> > > wake_up(&wb_ctl->done_wait);
> > > + spin_unlock_irqrestore(&wb_ctl->done_lock, flags);
> > > }
> > >
> >
> > I agree this will fix the issue, but using a lock to extend the lifetime of
> > an object to avoid a UAF is not a good pattern. Object lifetime shared between
> > process and interrupt contexts should be managed explicitly using refcount.
>
> ->num_inflight is a ref-counter, basically. The problem is that
> completion is a two-step process, only one part of each is synchronized
> with the writeback context. I honestly don't want to have two ref-counts:
> one for requests pending zram completion and one for active endio contexts.
> Maybe we can repurpose num_inflight instead.
If it can make the code much clearer and simpler, I have no objection.
>
> > Furthermore, keeping wake_up() outside the critical section minimizes
> > interrupt-disabled latency
>
> So I considered that, but isn't endio already called from IRQ context?
> Just asking. We wakeup only one waiter (writeback task), so it's not
> that bad CPU-cycles wise. Do you think it's really a concern?
I don't think it will have any measurable impact; I was just pointing out
a theoretical one.
>
> wake_up() under spin-lock solves the problem of a unsynchronized
> two-stages endio process.
>
> > and avoids nesting spinlocks (done_lock -> done_wait.lock), reducing
> > the risk of future lockdep issues, just in case.
>
> I considered lockdep as well but ruled it out as impossible scenario,
> nesting here is strictly uni-directional, we never call into zram from
> the scheduler. Just saying.
Sure. I just prefer to avoid adding more lock dependencies without a strong
justification, to prevent potential locking issues in the future.
>
> > It definitely will add more overhead for the submission/completion paths to deal
> > with the refcount, but I think we should go that way at the cost of runtime.
>
> Dunno, something like below maybe?
>
> ---
> drivers/block/zram/zram_drv.c | 14 ++++++++------
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index ce2e1c79fc75..27fe50d666d7 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -967,7 +967,7 @@ static int zram_writeback_complete(struct zram *zram, struct zram_wb_req *req)
> static void zram_writeback_endio(struct bio *bio)
> {
> struct zram_wb_req *req = container_of(bio, struct zram_wb_req, bio);
> - struct zram_wb_ctl *wb_ctl = bio->bi_private;
> + struct zram_wb_ctl *wb_ctl = READ_ONCE(bio->bi_private);
> unsigned long flags;
>
> spin_lock_irqsave(&wb_ctl->done_lock, flags);
> @@ -975,6 +975,7 @@ static void zram_writeback_endio(struct bio *bio)
> spin_unlock_irqrestore(&wb_ctl->done_lock, flags);
>
> wake_up(&wb_ctl->done_wait);
> + atomic_dec(&wb_ctl->num_inflight);
> }
>
> static void zram_submit_wb_request(struct zram *zram,
> @@ -998,7 +999,7 @@ static int zram_complete_done_reqs(struct zram *zram,
> unsigned long flags;
> int ret = 0, err;
>
> - while (atomic_read(&wb_ctl->num_inflight) > 0) {
> + for (;;) {
> spin_lock_irqsave(&wb_ctl->done_lock, flags);
> req = list_first_entry_or_null(&wb_ctl->done_reqs,
> struct zram_wb_req, entry);
> @@ -1006,7 +1007,6 @@ static int zram_complete_done_reqs(struct zram *zram,
> list_del(&req->entry);
> spin_unlock_irqrestore(&wb_ctl->done_lock, flags);
>
> - /* ->num_inflight > 0 doesn't mean we have done requests */
> if (!req)
> break;
>
> @@ -1014,7 +1014,6 @@ static int zram_complete_done_reqs(struct zram *zram,
> if (err)
> ret = err;
>
> - atomic_dec(&wb_ctl->num_inflight);
> release_pp_slot(zram, req->pps);
> req->pps = NULL;
>
> @@ -1129,8 +1128,11 @@ static int zram_writeback_slots(struct zram *zram,
> if (req)
> release_wb_req(req);
>
> - while (atomic_read(&wb_ctl->num_inflight) > 0) {
> - wait_event(wb_ctl->done_wait, !list_empty(&wb_ctl->done_reqs));
> + while (atomic_read(&wb_ctl->num_inflight) ||
> + !list_empty(&wb_ctl->done_reqs)) {
> + wait_event_timeout(wb_ctl->done_wait,
> + !list_empty(&wb_ctl->done_reqs),
> + HZ);
> err = zram_complete_done_reqs(zram, wb_ctl);
> if (err)
> ret = err;
I understand why you used a timeout here, but I still don't think it's a good
idea since the user could wait for up to a second unnecessarily during the
race.
What I prefer is simple and explicit lifetime management for wb_ctl using
refcount. It directly addresses the core issue (UAF of wb_ctl) in a standard,
robust way without needing workarounds like timeouts. The runtime overhead
of kref will be negligible.
Something like this:
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index a324ede6206d..28ab4a24e77f 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -33,6 +33,7 @@
#include <linux/cpuhotplug.h>
#include <linux/part_stat.h>
#include <linux/kernel_read_file.h>
+#include <linux/kref.h>
#include "zram_drv.h"
@@ -504,6 +505,7 @@ struct zram_wb_ctl {
wait_queue_head_t done_wait;
spinlock_t done_lock;
atomic_t num_inflight;
+ struct kref kref;
};
struct zram_wb_req {
@@ -829,11 +831,8 @@ static void release_wb_req(struct zram_wb_req *req)
kfree(req);
}
-static void release_wb_ctl(struct zram_wb_ctl *wb_ctl)
+static void __release_wb_ctl(struct zram_wb_ctl *wb_ctl)
{
- if (!wb_ctl)
- return;
-
/* We should never have inflight requests at this point */
WARN_ON(atomic_read(&wb_ctl->num_inflight));
WARN_ON(!list_empty(&wb_ctl->done_reqs));
@@ -850,6 +849,18 @@ static void release_wb_ctl(struct zram_wb_ctl *wb_ctl)
kfree(wb_ctl);
}
+static void release_wb_ctl_kref(struct kref *kref)
+{
+ struct zram_wb_ctl *wb_ctl = container_of(kref, struct zram_wb_ctl, kref);
+
+ __release_wb_ctl(wb_ctl);
+}
+
+static void release_wb_ctl(struct zram_wb_ctl *wb_ctl)
+{
+ kref_put(&wb_ctl->kref, release_wb_ctl_kref);
+}
+
static struct zram_wb_ctl *init_wb_ctl(struct zram *zram)
{
struct zram_wb_ctl *wb_ctl;
@@ -864,6 +875,7 @@ static struct zram_wb_ctl *init_wb_ctl(struct zram *zram)
atomic_set(&wb_ctl->num_inflight, 0);
init_waitqueue_head(&wb_ctl->done_wait);
spin_lock_init(&wb_ctl->done_lock);
+ kref_init(&wb_ctl->kref);
for (i = 0; i < zram->wb_batch_size; i++) {
struct zram_wb_req *req;
@@ -985,6 +997,7 @@ static void zram_writeback_endio(struct bio *bio)
spin_unlock_irqrestore(&wb_ctl->done_lock, flags);
wake_up(&wb_ctl->done_wait);
+ kref_put(&wb_ctl->kref, release_wb_ctl_kref);
}
static void zram_submit_wb_request(struct zram *zram,
@@ -996,6 +1009,7 @@ static void zram_submit_wb_request(struct zram *zram,
* so that we don't over-submit.
*/
zram_account_writeback_submit(zram);
+ kref_get(&wb_ctl->kref);
atomic_inc(&wb_ctl->num_inflight);
req->bio.bi_private = wb_ctl;
submit_bio(&req->bio);
@@ -1276,8 +1290,8 @@ static ssize_t writeback_store(struct device *dev,
wb_ctl = init_wb_ctl(zram);
if (!wb_ctl) {
- ret = -ENOMEM;
- goto out;
+ release_pp_ctl(zram, pp_ctl);
+ return -ENOMEM;
}
args = skip_spaces(buf);
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox