* [PATCH v3 03/10] block: move bvec init into __bio_clone
From: Pavel Begunkov @ 2026-04-29 15:25 UTC (permalink / raw)
To: 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
Cc: asml.silence, Nitesh Shetty, Kanchan Joshi, Anuj Gupta,
Tushar Gohad, William Power, Phil Cayton, Jason Gunthorpe
In-Reply-To: <cover.1777475843.git.asml.silence@gmail.com>
To quote Cristoph: "Historically __bio_clone itself does not clone the
payload, just the bio. But we got rid of the callers that want to clone
a bio but not the payload long time ago". So let's move ->bi_io_vec
assignment into __bio_clone(), so we have a single point where it's set.
Suggested-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
---
block/bio.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/block/bio.c b/block/bio.c
index 4d46af0cd256..0734b50d4992 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -851,6 +851,7 @@ static int __bio_clone(struct bio *bio, struct bio *bio_src, gfp_t gfp)
bio->bi_write_hint = bio_src->bi_write_hint;
bio->bi_write_stream = bio_src->bi_write_stream;
bio->bi_iter = bio_src->bi_iter;
+ bio->bi_io_vec = bio_src->bi_io_vec;
if (bio->bi_bdev) {
if (bio->bi_bdev == bio_src->bi_bdev &&
@@ -893,8 +894,6 @@ struct bio *bio_alloc_clone(struct block_device *bdev, struct bio *bio_src,
bio_put(bio);
return NULL;
}
- bio->bi_io_vec = bio_src->bi_io_vec;
-
return bio;
}
EXPORT_SYMBOL(bio_alloc_clone);
@@ -914,7 +913,7 @@ int bio_init_clone(struct block_device *bdev, struct bio *bio,
{
int ret;
- bio_init(bio, bdev, bio_src->bi_io_vec, 0, bio_src->bi_opf);
+ bio_init(bio, bdev, NULL, 0, bio_src->bi_opf);
ret = __bio_clone(bio, bio_src, gfp);
if (ret)
bio_uninit(bio);
--
2.53.0
^ permalink raw reply related
* [PATCH v3 02/10] iov_iter: add iterator type for dmabuf maps
From: Pavel Begunkov @ 2026-04-29 15:25 UTC (permalink / raw)
To: 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
Cc: asml.silence, Nitesh Shetty, Kanchan Joshi, Anuj Gupta,
Tushar Gohad, William Power, Phil Cayton, Jason Gunthorpe
In-Reply-To: <cover.1777475843.git.asml.silence@gmail.com>
Introduce a new iterator type for dmabuf maps. The map in an opaque
object with internals and format specific to the subsystem / driver, and
only it can use that subsystem / driver for issuing IO. The task of the
middle layers is to pass the map / iterator further down, maybe doing
basic splitting and length checking. The iterator can only be used by
operations of the file the associated map was created for.
Suggested-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
---
include/linux/uio.h | 11 +++++++++++
lib/iov_iter.c | 29 +++++++++++++++++++++++------
2 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/include/linux/uio.h b/include/linux/uio.h
index a9bc5b3067e3..75051aed70de 100644
--- a/include/linux/uio.h
+++ b/include/linux/uio.h
@@ -12,6 +12,7 @@
struct page;
struct folio_queue;
+struct io_dmabuf_map;
typedef unsigned int __bitwise iov_iter_extraction_t;
@@ -29,6 +30,7 @@ enum iter_type {
ITER_FOLIOQ,
ITER_XARRAY,
ITER_DISCARD,
+ ITER_DMABUF_MAP,
};
#define ITER_SOURCE 1 // == WRITE
@@ -71,6 +73,7 @@ struct iov_iter {
const struct folio_queue *folioq;
struct xarray *xarray;
void __user *ubuf;
+ struct io_dmabuf_map *dmabuf_map;
};
size_t count;
};
@@ -155,6 +158,11 @@ static inline bool iov_iter_is_xarray(const struct iov_iter *i)
return iov_iter_type(i) == ITER_XARRAY;
}
+static inline bool iov_iter_is_dmabuf_map(const struct iov_iter *i)
+{
+ return iov_iter_type(i) == ITER_DMABUF_MAP;
+}
+
static inline unsigned char iov_iter_rw(const struct iov_iter *i)
{
return i->data_source ? WRITE : READ;
@@ -300,6 +308,9 @@ void iov_iter_folio_queue(struct iov_iter *i, unsigned int direction,
unsigned int first_slot, unsigned int offset, size_t count);
void iov_iter_xarray(struct iov_iter *i, unsigned int direction, struct xarray *xarray,
loff_t start, size_t count);
+void iov_iter_dmabuf_map(struct iov_iter *i, unsigned int direction,
+ struct io_dmabuf_map *map,
+ loff_t off, size_t count);
ssize_t iov_iter_get_pages2(struct iov_iter *i, struct page **pages,
size_t maxsize, unsigned maxpages, size_t *start);
ssize_t iov_iter_get_pages_alloc2(struct iov_iter *i, struct page ***pages,
diff --git a/lib/iov_iter.c b/lib/iov_iter.c
index 243662af1af7..e2253684b991 100644
--- a/lib/iov_iter.c
+++ b/lib/iov_iter.c
@@ -575,7 +575,8 @@ void iov_iter_advance(struct iov_iter *i, size_t size)
{
if (unlikely(i->count < size))
size = i->count;
- if (likely(iter_is_ubuf(i)) || unlikely(iov_iter_is_xarray(i))) {
+ if (likely(iter_is_ubuf(i)) || unlikely(iov_iter_is_xarray(i)) ||
+ unlikely(iov_iter_is_dmabuf_map(i))) {
i->iov_offset += size;
i->count -= size;
} else if (likely(iter_is_iovec(i) || iov_iter_is_kvec(i))) {
@@ -631,7 +632,8 @@ void iov_iter_revert(struct iov_iter *i, size_t unroll)
return;
}
unroll -= i->iov_offset;
- if (iov_iter_is_xarray(i) || iter_is_ubuf(i)) {
+ if (iov_iter_is_xarray(i) || iter_is_ubuf(i) ||
+ iov_iter_is_dmabuf_map(i)) {
BUG(); /* We should never go beyond the start of the specified
* range since we might then be straying into pages that
* aren't pinned.
@@ -775,6 +777,20 @@ void iov_iter_xarray(struct iov_iter *i, unsigned int direction,
}
EXPORT_SYMBOL(iov_iter_xarray);
+void iov_iter_dmabuf_map(struct iov_iter *i, unsigned int direction,
+ struct io_dmabuf_map *map,
+ loff_t off, size_t count)
+{
+ WARN_ON(direction & ~(READ | WRITE));
+ *i = (struct iov_iter){
+ .iter_type = ITER_DMABUF_MAP,
+ .data_source = direction,
+ .dmabuf_map = map,
+ .count = count,
+ .iov_offset = off,
+ };
+}
+
/**
* iov_iter_discard - Initialise an I/O iterator that discards data
* @i: The iterator to initialise.
@@ -841,7 +857,7 @@ static unsigned long iov_iter_alignment_bvec(const struct iov_iter *i)
unsigned long iov_iter_alignment(const struct iov_iter *i)
{
- if (likely(iter_is_ubuf(i))) {
+ if (likely(iter_is_ubuf(i)) || iov_iter_is_dmabuf_map(i)) {
size_t size = i->count;
if (size)
return ((unsigned long)i->ubuf + i->iov_offset) | size;
@@ -872,7 +888,7 @@ unsigned long iov_iter_gap_alignment(const struct iov_iter *i)
size_t size = i->count;
unsigned k;
- if (iter_is_ubuf(i))
+ if (iter_is_ubuf(i) || iov_iter_is_dmabuf_map(i))
return 0;
if (WARN_ON(!iter_is_iovec(i)))
@@ -1469,11 +1485,12 @@ EXPORT_SYMBOL_GPL(import_ubuf);
void iov_iter_restore(struct iov_iter *i, struct iov_iter_state *state)
{
if (WARN_ON_ONCE(!iov_iter_is_bvec(i) && !iter_is_iovec(i) &&
- !iter_is_ubuf(i)) && !iov_iter_is_kvec(i))
+ !iter_is_ubuf(i) && !iov_iter_is_kvec(i) &&
+ !iov_iter_is_dmabuf_map(i)))
return;
i->iov_offset = state->iov_offset;
i->count = state->count;
- if (iter_is_ubuf(i))
+ if (iter_is_ubuf(i) || iov_iter_is_dmabuf_map(i))
return;
/*
* For the *vec iters, nr_segs + iov is constant - if we increment
--
2.53.0
^ permalink raw reply related
* [PATCH v3 01/10] file: add callback for creating long-term dmabuf maps
From: Pavel Begunkov @ 2026-04-29 15:25 UTC (permalink / raw)
To: 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
Cc: asml.silence, Nitesh Shetty, Kanchan Joshi, Anuj Gupta,
Tushar Gohad, William Power, Phil Cayton, Jason Gunthorpe
In-Reply-To: <cover.1777475843.git.asml.silence@gmail.com>
Introduce a new file callback that allows creating long-term dma
mapping. All necessary information together with a dmabuf will be passed
in the second argument of type struct io_dmabuf_token, which will be
defined in following patches.
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
---
include/linux/fs.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index b5b01bb22d12..c5558aab4628 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1920,6 +1920,7 @@ struct dir_context {
struct io_uring_cmd;
struct offset_ctx;
+struct io_dmabuf_token;
typedef unsigned int __bitwise fop_flags_t;
@@ -1967,6 +1968,7 @@ struct file_operations {
int (*uring_cmd_iopoll)(struct io_uring_cmd *, struct io_comp_batch *,
unsigned int poll_flags);
int (*mmap_prepare)(struct vm_area_desc *);
+ int (*create_dmabuf_token)(struct file *, struct io_dmabuf_token *);
} __randomize_layout;
/* Supports async buffered reads */
--
2.53.0
^ permalink raw reply related
* [PATCH v3 00/10] Add dmabuf read/write via io_uring
From: Pavel Begunkov @ 2026-04-29 15:25 UTC (permalink / raw)
To: 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
Cc: asml.silence, Nitesh Shetty, Kanchan Joshi, Anuj Gupta,
Tushar Gohad, William Power, Phil Cayton, Jason Gunthorpe
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:
- STRICT: before = 570 KIOPS, after = 5.01 MIOPS
- LAZY: before = 1.93 MIOPS, after = 5.01 MIOPS
- PASSTHROUGH: before = 5.01 MIOPS, after = 5.01 MIOPS
There are some liburing tests that can serve as an example:
git: https://github.com/isilence/liburing.git rw-dmabuf-tests-v3
url: https://github.com/isilence/liburing/tree/rw-dmabuf-tests-v3
[1] https://lore.kernel.org/io-uring/20220805162444.3985535-1-kbusch@fb.com/
v3: - Rework io_uring registration
- Move token/map infrastructure code out of blk-mq
- Simplify callbacks: remove a separate blk-mq table, which was
mostly just forwarding calls (to nvme).
- Don't skip dma sync depending on request direction
- Fix a couple of hangs
- Rename s/dma/dmabuf/
- Other small changes
v2: - Don't pass raw dma addresses, wrap it into a driver specific object
- Split into two objects: token and map
- Implement move_notify
Pavel Begunkov (10):
file: add callback for creating long-term dmabuf maps
iov_iter: add iterator type for dmabuf maps
block: move bvec init into __bio_clone
block: introduce dma map backed bio type
lib: add dmabuf token infrastructure
block: forward create_dmabuf_token to drivers
nvme-pci: implement dma_token backed requests
io_uring/rsrc: introduce buf registration structure
io_uring/rsrc: extend buffer update
io_uring/rsrc: add dmabuf backed registered buffers
block/bio.c | 28 +++-
block/blk-merge.c | 14 ++
block/blk.h | 3 +-
block/fops.c | 16 ++
drivers/nvme/host/pci.c | 282 ++++++++++++++++++++++++++++++++
include/linux/bio.h | 19 ++-
include/linux/blk-mq.h | 9 +
include/linux/blk_types.h | 8 +-
include/linux/fs.h | 2 +
include/linux/io_dmabuf_token.h | 92 +++++++++++
include/linux/io_uring_types.h | 5 +
include/linux/uio.h | 11 ++
include/uapi/linux/io_uring.h | 31 +++-
io_uring/io_uring.c | 3 +-
io_uring/rsrc.c | 266 +++++++++++++++++++++++++-----
io_uring/rsrc.h | 30 +++-
io_uring/rw.c | 4 +-
lib/Kconfig | 4 +
lib/Makefile | 2 +
lib/io_dmabuf_token.c | 272 ++++++++++++++++++++++++++++++
lib/iov_iter.c | 29 +++-
21 files changed, 1071 insertions(+), 59 deletions(-)
create mode 100644 include/linux/io_dmabuf_token.h
create mode 100644 lib/io_dmabuf_token.c
--
2.53.0
^ permalink raw reply
* Re: [PATCH v2 2/3] dm-inlinecrypt: add target for inline block device encryption
From: Benjamin Marzinski @ 2026-04-29 15:25 UTC (permalink / raw)
To: Linlin Zhang
Cc: linux-block, ebiggers, mpatocka, gmazyland, linux-kernel,
adrianvovk, dm-devel, quic_mdalam, israelr, hch, axboe
In-Reply-To: <7ab5cd97-30b7-42ca-80ce-6d9cd8c45b73@oss.qualcomm.com>
On Wed, Apr 29, 2026 at 08:34:00PM +0800, Linlin Zhang wrote:
>
>
> On 4/29/2026 12:36 AM, Benjamin Marzinski wrote:
> > On Tue, Apr 28, 2026 at 05:20:07PM +0800, Linlin Zhang wrote:
> >>
> >>
> >> On 4/28/2026 7:21 AM, Benjamin Marzinski wrote:
> >>> On Mon, Apr 27, 2026 at 01:23:27AM -0400, Benjamin Marzinski wrote:
> >>>> On Fri, Apr 10, 2026 at 06:40:30AM -0700, Linlin Zhang wrote:
> >>>>> From: Eric Biggers <ebiggers@google.com>
> >>>>> + /*
> >>>>> + * Since we've added an encryption context to the bio and
> >>>>> + * blk-crypto-fallback may be needed to process it, it's necessary to
> >>>>> + * use the fallback-aware bio submission code rather than
> >>>>> + * unconditionally returning DM_MAPIO_REMAPPED.
> >>>>> + *
> >>>>> + * To get the correct accounting for a dm target in the case where
> >>>>> + * __blk_crypto_submit_bio() doesn't take ownership of the bio (returns
> >>>>> + * true), call __blk_crypto_submit_bio() directly and return
> >>>>> + * DM_MAPIO_REMAPPED in that case, rather than relying on
> >>>>> + * blk_crypto_submit_bio() which calls submit_bio() in that case.
> >>>>> + */
> >>>>> + if (__blk_crypto_submit_bio(bio))
> >>>>
> >>>> This will still double account for fallback writes (which call
> >>>> submit_bio() on the encrypted bios, and return DM_MAPIO_SUBMITTED here).
> >>>
> >>> Just to clarify, I'm talking about the vmstats accounting. The IO
> >>> originally gets accounted by submit_bio() when the bio is submitted to
> >>> the dm device. For actual inline encryption and fallback reads, dm will
> >>> submit the bio to the underlying device using submit_bio_noacct() to
> >>> avoid double-counting the IO.
> >>>
> >>> For fallback writes, __blk_crypto_submit_bio() will submit the encrypted
> >>> bios to the underlying device with submit_bio(). This adds the IO
> >>> sectors again, even though it's the same IO, only encrypted now.
> >>
> >>
> >> Right, thanks for calling this out.
> >>
> >> For fallback writes, the IO is still double-counted. Given that this only
> >> affects IO accounting in the blk-crypto fallback write slow-path and not
> >> correctness, I think this is an acceptable tradeoff, and we can leave a
> >> TODO to revisit the accounting once a better solution exists.
> >>
> >> Add the bellow to the annotate.
> >>
> >> /*
> >> * TODO: blk-crypto fallback write slow-path currently double-accounts
> >> * IO in vmstat, as encrypted bios are submitted via submit_bio().
> >> * This does not affect data correctness. Consider fixing this if
> >> * a cleaner accounting model for derived bios is introduced.
> >> */
> >>
> >> Do you agree?
> >
> > You could add an extra argument, for instance "bool need_acct", to
> > __blk_crypto_submit_bio(), and plumb it through to
> > __blk_crypto_fallback_encrypt_bio(), where it could be used to choose
> > between calling submit_bio() and and submit_bio_noacct().
> >
> > We could even add a flag to cloned bios for stacked devices, that could
> > be checked in submit_bio(), so we didn't need to have
> > submit_bio_noacct(). But this is a pretty niche case with other
> > solutions, so I'm not sure if it warrants adding more checks to
> > submit_bio().
> >
> > I do agree that people probably aren't using dm-inlinecrypt for devices
> > where they don't actually have inline encryption capabilities, so it's
> > not a major issue. What to you think, Mikulas?
>
> Thanks for the suggestions.
>
> Adding a bool need_acct parameter to __blk_crypto_submit_bio() would require
> updating all existing callers, which feels rather intrusive given that the
> accounting issue only affects the blk‑crypto fallback write slow‑path. I’m a
> bit concerned that this would broaden the scope of the change more than
> necessary for the problem at hand.
I get your concern, and I'd like a second opinion on how much we should
care about this, but it doesn't look like there are many other callers
that would be effected here. The only existing caller of
__blk_crypto_submit_bio() is blk_crypto_submit_bio(), which would just
call it with "need_acct=true". Looking at the code path below
__blk_crypto_submit_bio() that would need to change for submitting the
bios:
__blk_crypto_submit_bio() is the only caller of
blk_crypto_fallback_bio_prep()
blk_crypto_fallback_bio_prep() is the only caller of
blk_crypto_fallback_encrypt_bio().
blk_crypto_fallback_encrypt_bio() is the only caller of
__blk_crypto_fallback_encrypt_bio(), which is the function that would
need to choose between submit_bio() and submit_bio_noacct().
Doing this would change the crypto API (by necessity, since we're adding
a new argument to __blk_crypto_submit_bio() for stacking devices to
use), and it is adds a extra argument to a number of functions, just to
handle this corner case. But it is still a relatively contained change.
-Ben
^ permalink raw reply
* Re: [LSF/MM/BPF TOPIC] A block level, active-active replication solution
From: Haris Iqbal @ 2026-04-29 14:26 UTC (permalink / raw)
To: Bart Van Assche; +Cc: lsf-pc, linux-block, Jia Li
In-Reply-To: <CAJpMwyha9Tuzn1nEDvfPbdaPFa6WbVBO91QoPEKJC+DB7V4PBw@mail.gmail.com>
On Thu, Feb 19, 2026 at 11:43 AM Haris Iqbal <haris.iqbal@ionos.com> wrote:
>
> On Fri, Feb 13, 2026 at 6:32 PM Bart Van Assche <bvanassche@acm.org> wrote:
> >
> > On 2/3/26 7:09 AM, Haris Iqbal wrote:
> > > We would like to present the idea and internal workings of the
> > > solution, and also discuss design and some benchmarking results
> > > (comparison with RAID1 over RNBD/NVMeOF devices, or DRBD) during
> > > LSF/MM/BPF. We also want to get feedback, and potentially get more
> > > people involved in the project.
Hello,
As mentioned earlier, we have open sourced the RMR+BRMR code and the
documentation is also public.
https://github.com/ionos-cloud/RMR
https://ionos-cloud.github.io/rmr.io/
> >
> > Please prepare for the question why the choice has been made to
> > implement this functionality as a new kernel module instead of
> > integrating this functionality in the DRBD kernel driver.
>
> Hi Bart,
>
>
> In short, it was mostly because of 2 reasons.
> 1) We wanted to keep the "single-hop replication and syncing" offering
> in a generic transport module (RMR), so that it can be used re-used by
> other modules in the future.
> 2) We think that DRBD’s core abstractions (per‑node peer replication,
> single lower device) are orthogonal to “active-active replication”
> model.
>
> We can discuss this further during the summit.
> I assume when you said to "prepare for the question", you meant the same?
>
> >
> > Thanks,
> >
> > Bart.
^ permalink raw reply
* Re: [PATCH blktests] blktrace/001: Skip test when kernel lockdown is enabled
From: Shin'ichiro Kawasaki @ 2026-04-29 13:52 UTC (permalink / raw)
To: Disha Goel; +Cc: linux-block
In-Reply-To: <20260424141143.64528-1-disgoel@linux.ibm.com>
On Apr 24, 2026 / 19:41, Disha Goel wrote:
> The blktrace/001 test fails on systems with Secure Boot enabled due to
> kernel lockdown preventing access to debugfs. The test attempts to run
> blktrace which requires access to /sys/kernel/debug/block/*/trace*
> files, but kernel lockdown (enabled automatically with Secure Boot)
> blocks this access, resulting in "Operation not permitted" errors.
Hello Disha, thanks for the patch. I tried to recreate the "Operation not
permitted" error on my test node, but I can not recreate it. I tried the
command lines below, and saw blktrace worked fine with lockdown=confidentiality
condition. This means that blktrace can access /sys/kernel/debug/block/*/trace*
even when the kernel is locked down.
---------------------------------------------------------------------
root@testnode1:~# cat /sys/kernel/security/lockdown
[none] integrity confidentiality
root@testnode1:~# echo confidentiality > /sys/kernel/security/lockdown
root@testnode1:~# cat /sys/kernel/security/lockdown
none integrity [confidentiality]
root@testnode1:~# cd /tmp
root@testnode1:/tmp# blktrace -d /dev/sdc &
[1] 1014
root@testnode1:/tmp# dd if=/dev/zero of=/dev/sdc bs=4k count=1 oflag=direct
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 0.00274992 s, 1.5 MB/s
root@testnode1:/tmp# kill 1014
root@testnode1:/tmp# === sdc ===
CPU 0: 6 events, 1 KiB data
CPU 1: 0 events, 0 KiB data
CPU 2: 658 events, 31 KiB data
CPU 3: 797 events, 38 KiB data
Total: 1461 events (dropped 0), 69 KiB data
[1]+ Done blktrace -d /dev/sdc
root@testnode1:/tmp# blkparse -i sdc | head
8,32 2 1 0.000000000 1048 Q WS 0 + 8 [dd]
8,32 2 0 0.000013242 1048 1,0 m N bfq [bfq_limit_depth] wr_busy 0 sync 1 depth 256
8,32 2 2 0.001495890 1048 G WS 0 + 8 [dd]
8,32 2 3 0.001497997 1048 P N [dd]
8,32 2 4 0.001499079 1048 U N [dd] 1
8,32 2 0 0.001574560 1048 1,0 m N bfq0A new_ioprio 4 new_weight 40
8,32 2 0 0.001577177 1048 1,0 m N bfq1048S allocated
8,32 2 0 0.001581069 1048 1,0 m N bfq1048S get_request 00000000e21f70ba: bfqq 000000001cef6c8d, 2
8,32 2 5 0.001583291 1048 I WS 0 + 8 [dd]
8,32 2 0 0.001584861 1048 1,0 m N bfq1048S add_request 1
---------------------------------------------------------------------
I would like to understand why the blktrace error happens in your environment
and does not happen in my environment. It will affect how to judge the skip of
the test case blktrace/001.
Could you share your system set up conditions? FYI, I used Fedora 43, QEMU VM,
Intel server and v7.1-rc1 kernel for the trial above. I'm guessing any
difference between the two environments causes the blktrace behavior difference.
P.S. I found that kmemleak does not work when lockdown=confidentiality
condition. This indicates that the kernel lockdown feature works for kmemleak
as expected.
---------------------------------------------------------------------
root@testnode1:~# cat /sys/kernel/debug/kmemleak
root@testnode1:~# cat /sys/kernel/security/lockdown
[none] integrity confidentiality
root@testnode1:~# echo confidentiality > /sys/kernel/security/lockdown
root@testnode1:~# cat /sys/kernel/security/lockdown
none integrity [confidentiality]
root@testnode1:~# cat /sys/kernel/debug/kmemleak
cat: /sys/kernel/debug/kmemleak: Operation not permitted
---------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH 7/9] Bluetooth: hci_sync: Add NVMEM-backed BD address retrieval
From: Andrew Lunn @ 2026-04-29 13:15 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Loic Poulain, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Jens Axboe,
Johannes Berg, Jeff Johnson, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, linux-mmc, devicetree, linux-kernel, linux-arm-msm,
linux-block, linux-wireless, ath10k, linux-bluetooth, netdev,
daniel
In-Reply-To: <CAMRc=Me9G9vd06a39vi_UrXCTkUtJQRogm2MqgnwLS_r3Thyzg@mail.gmail.com>
On Wed, Apr 29, 2026 at 10:53:13AM +0200, Bartosz Golaszewski wrote:
> On Tue, Apr 28, 2026 at 4:23 PM Loic Poulain
> <loic.poulain@oss.qualcomm.com> wrote:
> >
> > 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>
> > ---
>
> Is there any reason why we can't extend the existing
> of_get_mac_address() with another property name and use it here? It
> already has support for mac addresses from nvmem.
Does it even need to be a different property name? Is a bluetooth MAC
address somehow different to an Ethernet MAC address? Isn't it just a
EUI-48, independent of it being Ethernet, Bluetooth, wifi, fddi, token
ring, homing pigeon?
Andrew
^ permalink raw reply
* Re: [PATCH v2 2/3] dm-inlinecrypt: add target for inline block device encryption
From: Linlin Zhang @ 2026-04-29 12:34 UTC (permalink / raw)
To: Benjamin Marzinski
Cc: linux-block, ebiggers, mpatocka, gmazyland, linux-kernel,
adrianvovk, dm-devel, quic_mdalam, israelr, hch, axboe
In-Reply-To: <afDh8XRWW_JgaUP3@redhat.com>
On 4/29/2026 12:36 AM, Benjamin Marzinski wrote:
> On Tue, Apr 28, 2026 at 05:20:07PM +0800, Linlin Zhang wrote:
>>
>>
>> On 4/28/2026 7:21 AM, Benjamin Marzinski wrote:
>>> On Mon, Apr 27, 2026 at 01:23:27AM -0400, Benjamin Marzinski wrote:
>>>> On Fri, Apr 10, 2026 at 06:40:30AM -0700, Linlin Zhang wrote:
>>>>> From: Eric Biggers <ebiggers@google.com>
>>>>> + /*
>>>>> + * Since we've added an encryption context to the bio and
>>>>> + * blk-crypto-fallback may be needed to process it, it's necessary to
>>>>> + * use the fallback-aware bio submission code rather than
>>>>> + * unconditionally returning DM_MAPIO_REMAPPED.
>>>>> + *
>>>>> + * To get the correct accounting for a dm target in the case where
>>>>> + * __blk_crypto_submit_bio() doesn't take ownership of the bio (returns
>>>>> + * true), call __blk_crypto_submit_bio() directly and return
>>>>> + * DM_MAPIO_REMAPPED in that case, rather than relying on
>>>>> + * blk_crypto_submit_bio() which calls submit_bio() in that case.
>>>>> + */
>>>>> + if (__blk_crypto_submit_bio(bio))
>>>>
>>>> This will still double account for fallback writes (which call
>>>> submit_bio() on the encrypted bios, and return DM_MAPIO_SUBMITTED here).
>>>
>>> Just to clarify, I'm talking about the vmstats accounting. The IO
>>> originally gets accounted by submit_bio() when the bio is submitted to
>>> the dm device. For actual inline encryption and fallback reads, dm will
>>> submit the bio to the underlying device using submit_bio_noacct() to
>>> avoid double-counting the IO.
>>>
>>> For fallback writes, __blk_crypto_submit_bio() will submit the encrypted
>>> bios to the underlying device with submit_bio(). This adds the IO
>>> sectors again, even though it's the same IO, only encrypted now.
>>
>>
>> Right, thanks for calling this out.
>>
>> For fallback writes, the IO is still double-counted. Given that this only
>> affects IO accounting in the blk-crypto fallback write slow-path and not
>> correctness, I think this is an acceptable tradeoff, and we can leave a
>> TODO to revisit the accounting once a better solution exists.
>>
>> Add the bellow to the annotate.
>>
>> /*
>> * TODO: blk-crypto fallback write slow-path currently double-accounts
>> * IO in vmstat, as encrypted bios are submitted via submit_bio().
>> * This does not affect data correctness. Consider fixing this if
>> * a cleaner accounting model for derived bios is introduced.
>> */
>>
>> Do you agree?
>
> You could add an extra argument, for instance "bool need_acct", to
> __blk_crypto_submit_bio(), and plumb it through to
> __blk_crypto_fallback_encrypt_bio(), where it could be used to choose
> between calling submit_bio() and and submit_bio_noacct().
>
> We could even add a flag to cloned bios for stacked devices, that could
> be checked in submit_bio(), so we didn't need to have
> submit_bio_noacct(). But this is a pretty niche case with other
> solutions, so I'm not sure if it warrants adding more checks to
> submit_bio().
>
> I do agree that people probably aren't using dm-inlinecrypt for devices
> where they don't actually have inline encryption capabilities, so it's
> not a major issue. What to you think, Mikulas?
Thanks for the suggestions.
Adding a bool need_acct parameter to __blk_crypto_submit_bio() would require
updating all existing callers, which feels rather intrusive given that the
accounting issue only affects the blk‑crypto fallback write slow‑path. I’m a
bit concerned that this would broaden the scope of the change more than
necessary for the problem at hand.
An alternative might be to track this at the bio level instead — for example,
by introducing a bio flag or metadata that indicates whether accounting should
be charged for a derived/cloned bio. That would avoid having to thread additional
parameters through multiple blk‑crypto entry points. However, this likely needs
a broader discussion to make sure it fits well with existing stacking and
accounting semantics.
Also, as discussed, the current behavior does not affect data correctness; it
only results in double vmstat accounting for fallback writes. Given that
dm‑inlinecrypt is expected to be used primarily on devices with actual inline
encryption support, the fallback write path should be relatively uncommon in
practice.
With that in mind, would it be acceptable to merge the current change as‑is,
with an explicit TODO documenting the double‑accounting in the fallback write path,
and revisit the accounting model in a follow‑up patch once we have agreement on a
cleaner solution? What do you think, Ben and Mikulas?
Happy to iterate further if there’s a preferred direction here.
>
> -Ben
>
>>>
>>> -Ben
>>>
>>>>
>>>> -Ben
>>>>
>>>>> + return DM_MAPIO_REMAPPED;
>>>>> + return DM_MAPIO_SUBMITTED;
>>>>> +}
>>>>
>>>
>
^ permalink raw reply
* Re: [PATCH v2 2/3] dm-inlinecrypt: add target for inline block device encryption
From: Linlin Zhang @ 2026-04-29 12:16 UTC (permalink / raw)
To: Benjamin Marzinski
Cc: linux-block, ebiggers, mpatocka, gmazyland, linux-kernel,
adrianvovk, dm-devel, quic_mdalam, israelr, hch, axboe
In-Reply-To: <afDeUNNWEIlxl5HC@redhat.com>
On 4/29/2026 12:20 AM, Benjamin Marzinski wrote:
> On Tue, Apr 28, 2026 at 06:43:08PM +0800, Linlin Zhang wrote:
>> Correct the response to Benjamin's comments.
>>
>> On 4/27/2026 8:20 PM, Linlin Zhang wrote:
>>>
>>>
>>> On 4/27/2026 9:19 AM, Benjamin Marzinski wrote:
>>>> On Fri, Apr 10, 2026 at 06:40:30AM -0700, Linlin Zhang wrote:
>>>>> From: Eric Biggers <ebiggers@google.com>
>>>>> +
>>>>> +static int inlinecrypt_map(struct dm_target *ti, struct bio *bio)
>>>>> +{
>>>>> + const struct inlinecrypt_ctx *ctx = ti->private;
>>>>> + sector_t sector_in_target;
>>>>> + u64 dun[BLK_CRYPTO_DUN_ARRAY_SIZE] = {};
>>>>> +
>>>>> + bio_set_dev(bio, ctx->dev->bdev);
>>>>> +
>>>>> + /*
>>>>> + * If the bio is a device-level request which doesn't target a specific
>>>>> + * sector, there's nothing more to do.
>>>>> + */
>>>>> + if (bio_sectors(bio) == 0)
>>>>> + return DM_MAPIO_REMAPPED;
>>>>> +
>>>>> + /*
>>>>> + * The bio should never have an encryption context already, since
>>>>> + * dm-inlinecrypt doesn't pass through any inline encryption
>>>>> + * capabilities to the layer above it.
>>>>> + */
>>>>> + if (WARN_ON_ONCE(bio_has_crypt_ctx(bio)))
>>>>> + return DM_MAPIO_KILL;
>>>>> +
>>>>> + /* Map the bio's sector to the underlying device. (512-byte sectors) */
>>>>> + sector_in_target = dm_target_offset(ti, bio->bi_iter.bi_sector);
>>>>> + bio->bi_iter.bi_sector = ctx->start + sector_in_target;
>>>>> + /*
>>>>> + * If the bio doesn't have any data (e.g. if it's a DISCARD request),
>>>>> + * there's nothing more to do.
>>>>> + */
>>>>> + if (!bio_has_data(bio))
>>>>> + return DM_MAPIO_REMAPPED;
>>>>> +
>>>>> + /* Calculate the DUN and enforce data-unit (crypto sector) alignment. */
>>>>> + dun[0] = ctx->iv_offset + sector_in_target; /* 512-byte sectors */
>>>>> + if (dun[0] & ((ctx->sector_size >> SECTOR_SHIFT) - 1))
>>>>> + return DM_MAPIO_KILL;
>>>>
>>>> If ctx->iv_offset is not a multiple of ctx->sector_size, this will
>>>> always fail. ctx->iv_offset should probably get validated in
>>>> inlinecrypt_ctr()
>>>
>>> ACK
>>>
>>> Yes, this assumes iv_offset is aligned to sector_size when large crypto
>>> sectors are used. That’s a requirement of dm-inlinecrypt semantics, and
>>> adding an explicit check in inlinecrypt_ctr() would make this fail earlier
>>> and more clearly.
>>
>> Sorry, the last response is wrong. No need to add check in inlinecrypt_ctr().
>>
>> iv_offset is the starting offset for IVs that are generated as if the target were
>> preceded by iv_offset 512-byte sectors.
>>
>> I think this concern is based on an implicit assumption that
>> sector_in_target is always data-unit (crypto sector) aligned. In this
>> target, however, sector_in_target is derived from dm_target_offset() and
>> is in 512-byte sectors, so it is not guaranteed to be a multiple of
>> (sector_size >> SECTOR_SHIFT).
>
> sector_in_target should be guaranteed to be sector_size aligned.
> inlinecrypt_io_hints() sets the device logical block size to at least
> ctx->sector_size, and validate_hardware_logical_block_alignment() makes
> sure that the target starts on a logical block boundary. The block
> layer enforces IO to be aligned with the logical block size, so
> an IO that starts 7 sectors into a device with a 4096 ctx->sector_size
> should be impossible.
Thanks for the detailed clarification!
In the next patch, I will add an explicit alignment check in ctr() to ensure that
iv_offset is aligned to the configured sector size. For example:
if (ctx->iv_offset & ((ctx->sector_size >> SECTOR_SHIFT) - 1)) {
ti->error = "Wrong alignment of iv_offset sector";
err = -EINVAL;
}
Please let me know if you would like this validation to be handled differently,
or if additional checks are needed.
>
> -Ben
>
^ permalink raw reply
* Re: [PATCH] rust: block: fix comment referring to states by wrong labels
From: Hsiu Che Yu @ 2026-04-29 10:35 UTC (permalink / raw)
To: Andreas Hindborg
Cc: Hsiu Che Yu, Boqun Feng, Miguel Ojeda, Gary Guo,
Björn Roy Baron, Benno Lossin, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Peter Zijlstra (Intel), linux-block,
rust-for-linux, linux-kernel
In-Reply-To: <87cxzioyt4.fsf@t14s.mail-host-address-is-not-set>
On Wed, Apr 29, 2026 at 12:17:43PM +0200, Andreas Hindborg wrote:
>Thanks for the patch. Please be aware that this mistake is fixed in the
>latest rust null block series [1]. Please take a look at that series if
>you have more patches for the rust block subsystem queued.
Thank you for letting me know. I'll take a look at the series.
Best regards,
Hsiu
^ permalink raw reply
* Re: [PATCH] rust: block: fix comment referring to states by wrong labels
From: Andreas Hindborg @ 2026-04-29 10:17 UTC (permalink / raw)
To: Hsiu Che Yu, Boqun Feng, Miguel Ojeda, Gary Guo,
Björn Roy Baron, Benno Lossin, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Peter Zijlstra (Intel)
Cc: linux-block, rust-for-linux, linux-kernel, Hsiu Che Yu
In-Reply-To: <20260428-fix-docs-mq-req-v1-1-260079853836@gmail.com>
Hi,
"Hsiu Che Yu" <yu.whisper.personal@gmail.com> writes:
> The comment in `Request` describing the four ownership states referred
> to states 2 and 3 as "B" and "C", which are inconsistent with the
> numbering scheme used throughout the same comment block.
>
> Update the labels to use "2" and "3" to match the existing numbered list.
>
> Fixes: a307bf1db5448 ("rust: block: convert `block::mq` to use `Refcount`")
> Signed-off-by: Hsiu Che Yu <yu.whisper.personal@gmail.com>
> ---
> rust/kernel/block/mq/request.rs | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/rust/kernel/block/mq/request.rs b/rust/kernel/block/mq/request.rs
> index ce3e30c81cb5..75d3fdf896e0 100644
> --- a/rust/kernel/block/mq/request.rs
> +++ b/rust/kernel/block/mq/request.rs
> @@ -39,7 +39,7 @@
> /// back ownership to the block layer.
> ///
> /// Note that the driver can still obtain new `ARef` even if there is no `ARef`s in existence by
> -/// using `tag_to_rq`, hence the need to distinguish B and C.
> +/// using `tag_to_rq`, hence the need to distinguish 2 and 3.
> ///
> /// The states are tracked through the private `refcount` field of
> /// `RequestDataWrapper`. This structure lives in the private data area of the C
>
> ---
> base-commit: b4e07588e743c989499ca24d49e752c074924a9a
> change-id: 20260428-fix-docs-mq-req-d2a0fe1b6471
>
> Best regards,
> --
> Hsiu Che Yu <yu.whisper.personal@gmail.com>
Thanks for the patch. Please be aware that this mistake is fixed in the
latest rust null block series [1]. Please take a look at that series if
you have more patches for the rust block subsystem queued.
Best regards,
Andreas Hindborg
[1] https://lore.kernel.org/rust-for-linux/20260216-rnull-v6-19-rc5-send-v1-0-de9a7af4b469@kernel.org/
^ permalink raw reply
* [PATCH] block/blk-iolatency: Add the processing flow of the chained bio in the QoS and define the related types to solve the problem of incorrect inflight processing in the QoS. The usage of the done_split_bio abstract function in the blk-iolatency project.
From: Li kunyu @ 2026-04-29 9:41 UTC (permalink / raw)
To: axboe, tj, josef; +Cc: linux-block, linux-kernel, Li kunyu
Signed-off-by: Li kunyu <likunyu10@163.com>
---
block/bio.c | 2 ++
block/blk-iolatency.c | 34 ++++++++++++++++++++++++++++++++++
block/blk-merge.c | 7 ++++++-
block/blk-rq-qos.h | 11 +++++++++++
include/linux/blk_types.h | 2 ++
5 files changed, 55 insertions(+), 1 deletion(-)
diff --git a/block/bio.c b/block/bio.c
index b8972dba68a0..7740701afc7f 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -1733,6 +1733,8 @@ static inline bool bio_remaining_done(struct bio *bio)
return true;
}
+ rq_qos_done_split_bio(bio);
+
return false;
}
diff --git a/block/blk-iolatency.c b/block/blk-iolatency.c
index 53e8dd2dfa8a..ba5870bf14c5 100644
--- a/block/blk-iolatency.c
+++ b/block/blk-iolatency.c
@@ -632,6 +632,39 @@ static void blkcg_iolatency_done_bio(struct rq_qos *rqos, struct bio *bio)
}
}
+static void blkcg_iolatency_done_split_bio(struct rq_qos *rqos, struct bio *bio)
+{
+ struct blkcg_gq *blkg;
+ struct rq_wait *rqw;
+ struct iolatency_grp *iolat;
+ int inflight = 0;
+
+ blkg = bio->bi_blkg;
+ if (!blkg || !bio_flagged(bio, BIO_QOS_CHAIN_CHILD))
+ return;
+
+ iolat = blkg_to_lat(bio->bi_blkg);
+ if (!iolat)
+ return;
+
+ if (!iolat->blkiolat->enabled)
+ return;
+
+ while (blkg && blkg->parent) {
+ iolat = blkg_to_lat(blkg);
+ if (!iolat) {
+ blkg = blkg->parent;
+ continue;
+ }
+ rqw = &iolat->rq_wait;
+
+ inflight = atomic_dec_return(&rqw->inflight);
+ WARN_ON_ONCE(inflight < 0);
+
+ blkg = blkg->parent;
+ }
+}
+
static void blkcg_iolatency_exit(struct rq_qos *rqos)
{
struct blk_iolatency *blkiolat = BLKIOLATENCY(rqos);
@@ -645,6 +678,7 @@ static void blkcg_iolatency_exit(struct rq_qos *rqos)
static const struct rq_qos_ops blkcg_iolatency_ops = {
.throttle = blkcg_iolatency_throttle,
.done_bio = blkcg_iolatency_done_bio,
+ .done_split_bio = blkcg_iolatency_done_split_bio,
.exit = blkcg_iolatency_exit,
};
diff --git a/block/blk-merge.c b/block/blk-merge.c
index fcf09325b22e..c236f9b34044 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -151,8 +151,13 @@ static struct bio *bio_submit_split(struct bio *bio, int split_sectors)
if (split_sectors) {
bio = bio_submit_split_bioset(bio, split_sectors,
&bio->bi_bdev->bd_disk->bio_split);
- if (bio)
+ if (bio) {
bio->bi_opf |= REQ_NOMERGE;
+ /* Fix the issue where the inflight statistics
+ * of the chained bio in the QoS are incorrect.
+ */
+ bio_set_flag(split, BIO_QOS_CHAIN_CHILD);
+ }
}
return bio;
diff --git a/block/blk-rq-qos.h b/block/blk-rq-qos.h
index a747a504fe42..496a27b9d412 100644
--- a/block/blk-rq-qos.h
+++ b/block/blk-rq-qos.h
@@ -45,6 +45,7 @@ struct rq_qos_ops {
void (*cleanup)(struct rq_qos *, struct bio *);
void (*queue_depth_changed)(struct rq_qos *);
void (*exit)(struct rq_qos *);
+ void (*done_split_bio)(struct rq_qos *, struct bio *);
const struct blk_mq_debugfs_attr *debugfs_attrs;
};
@@ -108,6 +109,7 @@ void __rq_qos_throttle(struct rq_qos *rqos, struct bio *bio);
void __rq_qos_track(struct rq_qos *rqos, struct request *rq, struct bio *bio);
void __rq_qos_merge(struct rq_qos *rqos, struct request *rq, struct bio *bio);
void __rq_qos_done_bio(struct rq_qos *rqos, struct bio *bio);
+void __rq_qos_done_split_bio(struct rq_qos *rqos, struct bio *bio);
void __rq_qos_queue_depth_changed(struct rq_qos *rqos);
static inline void rq_qos_cleanup(struct request_queue *q, struct bio *bio)
@@ -157,6 +159,15 @@ static inline void rq_qos_done_bio(struct bio *bio)
__rq_qos_done_bio(q->rq_qos, bio);
}
+static inline void rq_qos_done_split_bio(struct bio *bio)
+{
+ if (bio->bi_bdev && bio_flagged(bio, BIO_QOS_CHAIN_CHILD)) {
+ struct request_queue *q = bdev_get_queue(bio->bi_bdev);
+ if (q->rq_qos)
+ __rq_qos_done_split_bio(q->rq_qos, bio);
+ }
+}
+
static inline void rq_qos_throttle(struct request_queue *q, struct bio *bio)
{
if (test_bit(QUEUE_FLAG_QOS_ENABLED, &q->queue_flags) && q->rq_qos) {
diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
index 8808ee76e73c..63fee89ecc14 100644
--- a/include/linux/blk_types.h
+++ b/include/linux/blk_types.h
@@ -322,6 +322,8 @@ enum {
BIO_REMAPPED,
BIO_ZONE_WRITE_PLUGGING, /* bio handled through zone write plugging */
BIO_EMULATES_ZONE_APPEND, /* bio emulates a zone append operation */
+ BIO_QOS_CHAIN_CHILD, /* chained bio child, used for segmenting out
+ * the bio */
BIO_FLAG_LAST
};
--
2.47.3
^ permalink raw reply related
* Re: [PATCH 9/9] arm64: dts: qcom: arduino-imola: Get Bluetooth BD address from NVMEM
From: Konrad Dybcio @ 2026-04-29 9:32 UTC (permalink / raw)
To: Loic Poulain, 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
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel
In-Reply-To: <20260428-block-as-nvmem-v1-9-6ad23e75190a@oss.qualcomm.com>
On 4/28/26 4:23 PM, Loic Poulain wrote:
> On Arduino Uno-Q, the Bluetooth Device address is stored in the eMMC
> boot1 partition. Point to the appropriate NVMEM cell to retrieve it.
>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 4/9] dt-bindings: net: wireless: qcom,ath10k: Add NVMEM MAC address cell
From: Konrad Dybcio @ 2026-04-29 9:31 UTC (permalink / raw)
To: Loic Poulain, 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
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel
In-Reply-To: <20260428-block-as-nvmem-v1-4-6ad23e75190a@oss.qualcomm.com>
On 4/28/26 4:23 PM, Loic Poulain wrote:
> 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>
> ---
> .../devicetree/bindings/net/wireless/qcom,ath10k.yaml | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> index c21d66c7cd558ab792524be9afec8b79272d1c87..7155d8b15cc145c3a7d703db0c9c3e056a54c07e 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> @@ -92,6 +92,16 @@ 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:
> + items:
> + - const: mac-address
This can just be "const: mac-address" if you don't expect any additional
entries
Konrad
^ permalink raw reply
* Re: [PATCH 5/9] arm64: dts: qcom: arduino-imola: Get WiFi MAC from NVMEM
From: Konrad Dybcio @ 2026-04-29 9:30 UTC (permalink / raw)
To: Loic Poulain, 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
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel
In-Reply-To: <20260428-block-as-nvmem-v1-5-6ad23e75190a@oss.qualcomm.com>
On 4/28/26 4:23 PM, Loic Poulain wrote:
> On Arduino Uno-Q, the WiFi MAC address is stored in the eMMC
> boot1 partition. Point to the appropriate NVMEM cell to
> retrieve it.
>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* [PATCH] block/blk-iolatency: Add the processing flow of the chained bio in the QoS and define the related types to solve the problem of incorrect inflight processing in the QoS. The usage of the done_split_bio abstract function in the blk-iolatency project.
From: Li kunyu @ 2026-04-29 9:29 UTC (permalink / raw)
To: axboe, tj, josef; +Cc: linux-block, linux-kernel, Li kunyu
Signed-off-by: Li kunyu <likunyu10@163.com>
---
block/bio.c | 2 ++
block/blk-iolatency.c | 34 ++++++++++++++++++++++++++++++++++
block/blk-merge.c | 6 +++++-
block/blk-rq-qos.h | 11 +++++++++++
include/linux/blk_types.h | 2 ++
5 files changed, 54 insertions(+), 1 deletion(-)
diff --git a/block/bio.c b/block/bio.c
index b8972dba68a0..7740701afc7f 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -1733,6 +1733,8 @@ static inline bool bio_remaining_done(struct bio *bio)
return true;
}
+ rq_qos_done_split_bio(bio);
+
return false;
}
diff --git a/block/blk-iolatency.c b/block/blk-iolatency.c
index 53e8dd2dfa8a..ba5870bf14c5 100644
--- a/block/blk-iolatency.c
+++ b/block/blk-iolatency.c
@@ -632,6 +632,39 @@ static void blkcg_iolatency_done_bio(struct rq_qos *rqos, struct bio *bio)
}
}
+static void blkcg_iolatency_done_split_bio(struct rq_qos *rqos, struct bio *bio)
+{
+ struct blkcg_gq *blkg;
+ struct rq_wait *rqw;
+ struct iolatency_grp *iolat;
+ int inflight = 0;
+
+ blkg = bio->bi_blkg;
+ if (!blkg || !bio_flagged(bio, BIO_QOS_CHAIN_CHILD))
+ return;
+
+ iolat = blkg_to_lat(bio->bi_blkg);
+ if (!iolat)
+ return;
+
+ if (!iolat->blkiolat->enabled)
+ return;
+
+ while (blkg && blkg->parent) {
+ iolat = blkg_to_lat(blkg);
+ if (!iolat) {
+ blkg = blkg->parent;
+ continue;
+ }
+ rqw = &iolat->rq_wait;
+
+ inflight = atomic_dec_return(&rqw->inflight);
+ WARN_ON_ONCE(inflight < 0);
+
+ blkg = blkg->parent;
+ }
+}
+
static void blkcg_iolatency_exit(struct rq_qos *rqos)
{
struct blk_iolatency *blkiolat = BLKIOLATENCY(rqos);
@@ -645,6 +678,7 @@ static void blkcg_iolatency_exit(struct rq_qos *rqos)
static const struct rq_qos_ops blkcg_iolatency_ops = {
.throttle = blkcg_iolatency_throttle,
.done_bio = blkcg_iolatency_done_bio,
+ .done_split_bio = blkcg_iolatency_done_split_bio,
.exit = blkcg_iolatency_exit,
};
diff --git a/block/blk-merge.c b/block/blk-merge.c
index fcf09325b22e..26373b9c02d3 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -151,8 +151,12 @@ static struct bio *bio_submit_split(struct bio *bio, int split_sectors)
if (split_sectors) {
bio = bio_submit_split_bioset(bio, split_sectors,
&bio->bi_bdev->bd_disk->bio_split);
- if (bio)
+ if (bio) {
bio->bi_opf |= REQ_NOMERGE;
+ /* Fix the issue where the inflight statistics
+ * of the chained bio in the QoS are incorrect.
+ */
+ bio_set_flag(split, BIO_QOS_CHAIN_CHILD);
}
return bio;
diff --git a/block/blk-rq-qos.h b/block/blk-rq-qos.h
index a747a504fe42..496a27b9d412 100644
--- a/block/blk-rq-qos.h
+++ b/block/blk-rq-qos.h
@@ -45,6 +45,7 @@ struct rq_qos_ops {
void (*cleanup)(struct rq_qos *, struct bio *);
void (*queue_depth_changed)(struct rq_qos *);
void (*exit)(struct rq_qos *);
+ void (*done_split_bio)(struct rq_qos *, struct bio *);
const struct blk_mq_debugfs_attr *debugfs_attrs;
};
@@ -108,6 +109,7 @@ void __rq_qos_throttle(struct rq_qos *rqos, struct bio *bio);
void __rq_qos_track(struct rq_qos *rqos, struct request *rq, struct bio *bio);
void __rq_qos_merge(struct rq_qos *rqos, struct request *rq, struct bio *bio);
void __rq_qos_done_bio(struct rq_qos *rqos, struct bio *bio);
+void __rq_qos_done_split_bio(struct rq_qos *rqos, struct bio *bio);
void __rq_qos_queue_depth_changed(struct rq_qos *rqos);
static inline void rq_qos_cleanup(struct request_queue *q, struct bio *bio)
@@ -157,6 +159,15 @@ static inline void rq_qos_done_bio(struct bio *bio)
__rq_qos_done_bio(q->rq_qos, bio);
}
+static inline void rq_qos_done_split_bio(struct bio *bio)
+{
+ if (bio->bi_bdev && bio_flagged(bio, BIO_QOS_CHAIN_CHILD)) {
+ struct request_queue *q = bdev_get_queue(bio->bi_bdev);
+ if (q->rq_qos)
+ __rq_qos_done_split_bio(q->rq_qos, bio);
+ }
+}
+
static inline void rq_qos_throttle(struct request_queue *q, struct bio *bio)
{
if (test_bit(QUEUE_FLAG_QOS_ENABLED, &q->queue_flags) && q->rq_qos) {
diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
index 8808ee76e73c..63fee89ecc14 100644
--- a/include/linux/blk_types.h
+++ b/include/linux/blk_types.h
@@ -322,6 +322,8 @@ enum {
BIO_REMAPPED,
BIO_ZONE_WRITE_PLUGGING, /* bio handled through zone write plugging */
BIO_EMULATES_ZONE_APPEND, /* bio emulates a zone append operation */
+ BIO_QOS_CHAIN_CHILD, /* chained bio child, used for segmenting out
+ * the bio */
BIO_FLAG_LAST
};
--
2.47.3
^ permalink raw reply related
* Re: [PATCH 7/9] Bluetooth: hci_sync: Add NVMEM-backed BD address retrieval
From: Bartosz Golaszewski @ 2026-04-29 8:53 UTC (permalink / raw)
To: Loic Poulain
Cc: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Marcel Holtmann, Luiz Augusto von Dentz,
Balakrishna Godavarthi, Rocky Liao, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, linux-mmc, devicetree,
linux-kernel, linux-arm-msm, linux-block, linux-wireless, ath10k,
linux-bluetooth, netdev, daniel
In-Reply-To: <20260428-block-as-nvmem-v1-7-6ad23e75190a@oss.qualcomm.com>
On Tue, Apr 28, 2026 at 4:23 PM Loic Poulain
<loic.poulain@oss.qualcomm.com> wrote:
>
> 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>
> ---
Is there any reason why we can't extend the existing
of_get_mac_address() with another property name and use it here? It
already has support for mac addresses from nvmem.
Bart
^ permalink raw reply
* Re: [PATCH v12 05/13] blk-mq: add blk_mq_{online|possible}_queue_affinity
From: Hannes Reinecke @ 2026-04-29 7:15 UTC (permalink / raw)
To: Daniel Wagner, Sebastian Andrzej Siewior
Cc: Aaron Tomlin, axboe, kbusch, hch, sagi, mst, aacraid,
James.Bottomley, martin.petersen, liyihang9, kashyap.desai,
sumit.saxena, shivasharan.srikanteshwara, chandrakanth.patil,
sathya.prakash, sreekanth.reddy, suganath-prabu.subramani,
ranjan.kumar, jinpu.wang, tglx, mingo, peterz, juri.lelli,
vincent.guittot, akpm, maz, ruanjinjie, yphbchou0911, wagi,
frederic, longman, chenridong, kch, ming.lei, tom.leiming, steve,
sean, chjohnst, neelx, mproche, nick.lange, marco.crivellari,
linux-block, linux-kernel, virtualization, linux-nvme, linux-scsi,
megaraidlinux.pdl, mpi3mr-linuxdrv.pdl, MPT-FusionLinux.pdl
In-Reply-To: <c4927a2b-c18d-42ce-8a60-d6d388155671@flourine.local>
On 4/28/26 14:53, Daniel Wagner wrote:
> On Mon, Apr 27, 2026 at 05:34:16PM +0200, Sebastian Andrzej Siewior wrote:
>> Which driver uses cpu_possible_mask? This mask is assigned at boot time
>> once the kernel figured how many CPUs are possible based on ACPI or
>> whatever the system uses. This mask does not change.
>>
>> I only see drivers/scsi/lpfc/lpfc_init.c using it. Looking at
>> cpu_possible_mask might not be the right thing. It is usually the same
>> thing as "online" except on system where ACPI thinks that something
>> could be added via hotplug _or_ if the admin shuts down a CPU via
>> cpuhotplug _or_ boots with less (there a command line option for
>> that).
>
> These HBAs are used on PowerPC which supports lpar (CPUs can be added
> during runtime) I am told it's properly the only driver which is caring
> about this type configuration, thus a bit of an odd ball.
>
>> In case cpu_possible_mask != cpu_online_mask the intention is to
>> allocate memory and setup irqs for the offline CPUs?
>
> I can't answer this. The lpfc driver has several strategies implemented
> how it spreads its resources.
The intention is to setup the driver queue affinity only once (knowing
that all possible CPUs are handled correctly), avoiding a driver
reconfiguration on CPU hotplug.
Not the most efficient one, sure.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
^ permalink raw reply
* Re: [PATCH 0/9] Support for block device NVMEM providers
From: Andrew Lunn @ 2026-04-29 1:05 UTC (permalink / raw)
To: Loic Poulain
Cc: 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, linux-mmc, devicetree, linux-kernel, linux-arm-msm,
linux-block, linux-wireless, ath10k, linux-bluetooth, netdev,
daniel
In-Reply-To: <20260428-block-as-nvmem-v1-0-6ad23e75190a@oss.qualcomm.com>
> Note that this is currently limited to eMMC-backed block devices, as
> only the eMMC 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.
Would this be
https://elixir.bootlin.com/linux/v7.0.1/source/drivers/mmc/core/block.c#L2641
Looking at that function, mmc_blk_alloc_req() i don't see it doing
anything different between an eMMC and MMC.
An eMMC you don't expect to go away, since it is soldered
down. However an MMC can be ejected. Is the code prepared for that?
Andrew
^ permalink raw reply
* Re: [PATCH v2 2/3] dm-inlinecrypt: add target for inline block device encryption
From: Benjamin Marzinski @ 2026-04-28 16:36 UTC (permalink / raw)
To: Linlin Zhang
Cc: linux-block, ebiggers, mpatocka, gmazyland, linux-kernel,
adrianvovk, dm-devel, quic_mdalam, israelr, hch, axboe
In-Reply-To: <6390db35-7f8e-4d00-9c1f-43d676007910@oss.qualcomm.com>
On Tue, Apr 28, 2026 at 05:20:07PM +0800, Linlin Zhang wrote:
>
>
> On 4/28/2026 7:21 AM, Benjamin Marzinski wrote:
> > On Mon, Apr 27, 2026 at 01:23:27AM -0400, Benjamin Marzinski wrote:
> >> On Fri, Apr 10, 2026 at 06:40:30AM -0700, Linlin Zhang wrote:
> >>> From: Eric Biggers <ebiggers@google.com>
> >>> + /*
> >>> + * Since we've added an encryption context to the bio and
> >>> + * blk-crypto-fallback may be needed to process it, it's necessary to
> >>> + * use the fallback-aware bio submission code rather than
> >>> + * unconditionally returning DM_MAPIO_REMAPPED.
> >>> + *
> >>> + * To get the correct accounting for a dm target in the case where
> >>> + * __blk_crypto_submit_bio() doesn't take ownership of the bio (returns
> >>> + * true), call __blk_crypto_submit_bio() directly and return
> >>> + * DM_MAPIO_REMAPPED in that case, rather than relying on
> >>> + * blk_crypto_submit_bio() which calls submit_bio() in that case.
> >>> + */
> >>> + if (__blk_crypto_submit_bio(bio))
> >>
> >> This will still double account for fallback writes (which call
> >> submit_bio() on the encrypted bios, and return DM_MAPIO_SUBMITTED here).
> >
> > Just to clarify, I'm talking about the vmstats accounting. The IO
> > originally gets accounted by submit_bio() when the bio is submitted to
> > the dm device. For actual inline encryption and fallback reads, dm will
> > submit the bio to the underlying device using submit_bio_noacct() to
> > avoid double-counting the IO.
> >
> > For fallback writes, __blk_crypto_submit_bio() will submit the encrypted
> > bios to the underlying device with submit_bio(). This adds the IO
> > sectors again, even though it's the same IO, only encrypted now.
>
>
> Right, thanks for calling this out.
>
> For fallback writes, the IO is still double-counted. Given that this only
> affects IO accounting in the blk-crypto fallback write slow-path and not
> correctness, I think this is an acceptable tradeoff, and we can leave a
> TODO to revisit the accounting once a better solution exists.
>
> Add the bellow to the annotate.
>
> /*
> * TODO: blk-crypto fallback write slow-path currently double-accounts
> * IO in vmstat, as encrypted bios are submitted via submit_bio().
> * This does not affect data correctness. Consider fixing this if
> * a cleaner accounting model for derived bios is introduced.
> */
>
> Do you agree?
You could add an extra argument, for instance "bool need_acct", to
__blk_crypto_submit_bio(), and plumb it through to
__blk_crypto_fallback_encrypt_bio(), where it could be used to choose
between calling submit_bio() and and submit_bio_noacct().
We could even add a flag to cloned bios for stacked devices, that could
be checked in submit_bio(), so we didn't need to have
submit_bio_noacct(). But this is a pretty niche case with other
solutions, so I'm not sure if it warrants adding more checks to
submit_bio().
I do agree that people probably aren't using dm-inlinecrypt for devices
where they don't actually have inline encryption capabilities, so it's
not a major issue. What to you think, Mikulas?
-Ben
> >
> > -Ben
> >
> >>
> >> -Ben
> >>
> >>> + return DM_MAPIO_REMAPPED;
> >>> + return DM_MAPIO_SUBMITTED;
> >>> +}
> >>
> >
^ permalink raw reply
* [PATCH] dept: update documentation function names to match implementation
From: Yunseong Kim @ 2026-04-28 16:26 UTC (permalink / raw)
To: bagasdotme
Cc: 2407018371, Dai.Ngo, Liam.Howlett, a.hindborg, ada.coupriediaz,
adilger.kernel, akpm, alex.gaynor, alexander.shishkin, aliceryhl,
amir73il, andi.shyti, andrii, anna, arnd, ast, baolin.wang,
bigeasy, bjorn3_gh, boqun.feng, bp, brauner, broonie, bsegall,
byungchul, catalin.marinas, chenhuacai, chris.p.wilson,
christian.koenig, chuck.lever, cl, clrkwllms, corbet, da.gomez,
dakr, damien.lemoal, dan.j.williams, daniel.vetter, dave.hansen,
david, dennis, dietmar.eggemann, djwong, dri-devel, duyuyang,
dwmw, francesco, frederic, gary, geert+renesas, geert, gregkh,
guoweikang.kernel, gustavo, gwan-gyeong.mun, hamohammed.sa,
hannes, harry.yoo, hch, her0gyugyu, hpa, jack, jglisse,
jiangshanlai, jlayton, joel.granados, joel, joelagnelf,
johannes.berg, josef, josh, jpoimboe, juri.lelli, kees,
kernel-team, kernel_team, kevin.brodsky, kristina.martsenko,
lillian, linaro-mm-sig, link, linux-arch, linux-arm-kernel,
linux-block, linux-doc, linux-ext4, linux-fsdevel, linux-i2c,
linux-ide, linux-kernel, linux-media, linux-mm, linux-modules,
linux-nfs, linux-rt-devel, linux, longman, lorenzo.stoakes,
lossin, luto, mark.rutland, masahiroy, mathieu.desnoyers,
matthew.brost, max.byungchul.park, mcgrof, melissa.srw, mgorman,
mhocko, miguel.ojeda.sandonis, minchan, mingo, mjguzik,
neeraj.upadhyay, neil, neilb, netdev, ngupta, ojeda, okorniev,
oleg, paulmck, penberg, peterz, petr.pavlu, qiang.zhang, rcu,
richard.weiyang, rientjes, rodrigosiqueiramelo, rostedt, rppt,
rust-for-linux, samitolvanen, sashal, shakeel.butt, sj,
sumit.semwal, surenb, tglx, thomas.weissschuh, tim.c.chen, tj,
tmgross, tom, torvalds, trondmy, tytso, urezki, usamaarif642,
vbabka, vdavydov.dev, vincent.guittot, vschneid, wangfushuai,
wangkefeng.wang, will, willy, wsa+renesas, x86, yeoreum.yun, ysk,
yunseong.kim, yuzhao, ziy, Yunseong Kim
In-Reply-To: <aTN38kJjBftxnjm9@archie.me>
Synchronize function names in the documentation with the actual
implementation to fix naming inconsistencies.
Signed-off-by: Yunseong Kim <yunseong.kim@est.tech>
---
Documentation/dev-tools/dept.rst | 2 +-
Documentation/dev-tools/dept_api.rst | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/dev-tools/dept.rst b/Documentation/dev-tools/dept.rst
index 333166464543..31b2fe629fab 100644
--- a/Documentation/dev-tools/dept.rst
+++ b/Documentation/dev-tools/dept.rst
@@ -97,7 +97,7 @@ No. What about the following?
mutex_lock A
mutex_lock A <- DEADLOCK
- wait_for_complete B <- DEADLOCK
+ wait_for_completion B <- DEADLOCK
complete B
mutex_unlock A
mutex_unlock A
diff --git a/Documentation/dev-tools/dept_api.rst b/Documentation/dev-tools/dept_api.rst
index 409116a62849..74e7b1424ad5 100644
--- a/Documentation/dev-tools/dept_api.rst
+++ b/Documentation/dev-tools/dept_api.rst
@@ -113,7 +113,7 @@ Do not use these APIs directly. The raw APIs of dept are:
dept_stage_wait(map, key, ip, wait_func, time);
dept_request_event_wait_commit();
dept_clean_stage();
- dept_stage_event(task, ip);
+ dept_ttwu_stage_wait(task, ip);
dept_ecxt_enter(map, evt_flags, ip, ecxt_func, evt_func, sub_local);
dept_ecxt_holding(map, evt_flags);
dept_request_event(map, ext_wgen);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 2/3] dm-inlinecrypt: add target for inline block device encryption
From: Benjamin Marzinski @ 2026-04-28 16:20 UTC (permalink / raw)
To: Linlin Zhang
Cc: linux-block, ebiggers, mpatocka, gmazyland, linux-kernel,
adrianvovk, dm-devel, quic_mdalam, israelr, hch, axboe
In-Reply-To: <f92f318b-5c99-4880-906c-136aa180d58c@oss.qualcomm.com>
On Tue, Apr 28, 2026 at 06:43:08PM +0800, Linlin Zhang wrote:
> Correct the response to Benjamin's comments.
>
> On 4/27/2026 8:20 PM, Linlin Zhang wrote:
> >
> >
> > On 4/27/2026 9:19 AM, Benjamin Marzinski wrote:
> >> On Fri, Apr 10, 2026 at 06:40:30AM -0700, Linlin Zhang wrote:
> >>> From: Eric Biggers <ebiggers@google.com>
> >>> +
> >>> +static int inlinecrypt_map(struct dm_target *ti, struct bio *bio)
> >>> +{
> >>> + const struct inlinecrypt_ctx *ctx = ti->private;
> >>> + sector_t sector_in_target;
> >>> + u64 dun[BLK_CRYPTO_DUN_ARRAY_SIZE] = {};
> >>> +
> >>> + bio_set_dev(bio, ctx->dev->bdev);
> >>> +
> >>> + /*
> >>> + * If the bio is a device-level request which doesn't target a specific
> >>> + * sector, there's nothing more to do.
> >>> + */
> >>> + if (bio_sectors(bio) == 0)
> >>> + return DM_MAPIO_REMAPPED;
> >>> +
> >>> + /*
> >>> + * The bio should never have an encryption context already, since
> >>> + * dm-inlinecrypt doesn't pass through any inline encryption
> >>> + * capabilities to the layer above it.
> >>> + */
> >>> + if (WARN_ON_ONCE(bio_has_crypt_ctx(bio)))
> >>> + return DM_MAPIO_KILL;
> >>> +
> >>> + /* Map the bio's sector to the underlying device. (512-byte sectors) */
> >>> + sector_in_target = dm_target_offset(ti, bio->bi_iter.bi_sector);
> >>> + bio->bi_iter.bi_sector = ctx->start + sector_in_target;
> >>> + /*
> >>> + * If the bio doesn't have any data (e.g. if it's a DISCARD request),
> >>> + * there's nothing more to do.
> >>> + */
> >>> + if (!bio_has_data(bio))
> >>> + return DM_MAPIO_REMAPPED;
> >>> +
> >>> + /* Calculate the DUN and enforce data-unit (crypto sector) alignment. */
> >>> + dun[0] = ctx->iv_offset + sector_in_target; /* 512-byte sectors */
> >>> + if (dun[0] & ((ctx->sector_size >> SECTOR_SHIFT) - 1))
> >>> + return DM_MAPIO_KILL;
> >>
> >> If ctx->iv_offset is not a multiple of ctx->sector_size, this will
> >> always fail. ctx->iv_offset should probably get validated in
> >> inlinecrypt_ctr()
> >
> > ACK
> >
> > Yes, this assumes iv_offset is aligned to sector_size when large crypto
> > sectors are used. That’s a requirement of dm-inlinecrypt semantics, and
> > adding an explicit check in inlinecrypt_ctr() would make this fail earlier
> > and more clearly.
>
> Sorry, the last response is wrong. No need to add check in inlinecrypt_ctr().
>
> iv_offset is the starting offset for IVs that are generated as if the target were
> preceded by iv_offset 512-byte sectors.
>
> I think this concern is based on an implicit assumption that
> sector_in_target is always data-unit (crypto sector) aligned. In this
> target, however, sector_in_target is derived from dm_target_offset() and
> is in 512-byte sectors, so it is not guaranteed to be a multiple of
> (sector_size >> SECTOR_SHIFT).
sector_in_target should be guaranteed to be sector_size aligned.
inlinecrypt_io_hints() sets the device logical block size to at least
ctx->sector_size, and validate_hardware_logical_block_alignment() makes
sure that the target starts on a logical block boundary. The block
layer enforces IO to be aligned with the logical block size, so
an IO that starts 7 sectors into a device with a 4096 ctx->sector_size
should be impossible.
-Ben
^ permalink raw reply
* Re: [GIT PULL] md-7.1-20260428
From: Jens Axboe @ 2026-04-28 14:41 UTC (permalink / raw)
To: Yu Kuai
Cc: linux-block, linux-raid, Song Liu, Li Nan, Xiao Ni,
Abd-Alrhman Masalkhi, Benjamin Marzinski, Junrui Luo, Keith Busch
In-Reply-To: <20260428143340.1088943-1-yukuai@fnnas.com>
On 4/28/26 8:33 AM, Yu Kuai wrote:
> Hi Jens,
>
> Please consider pulling the following changes into your block-7.1
> branch.
>
> This pull request contains:
>
> Bug Fixes:
> - Fix a raid5 UAF on IO across the reshape position.
> - Avoid failing RAID1/RAID10 devices for invalid IO errors.
> - Fix RAID10 divide-by-zero when far_copies is zero.
> - Restore bitmap grow through sysfs.
>
> Cleanups:
> - Use mddev_is_dm() instead of open-coding gendisk checks.
> - Use ATTRIBUTE_GROUPS() for md default sysfs attributes.
> - Replace open-coded wait loops with wait_event helpers.
>
> Others:
> - Add Xiao Ni as md/raid reviewer.
Two notes:
1) Why are you rebasing the tree right before sending it? There
should be zero need to do that, please don't.
2) Please switch to https://patch.msgid.link/ for you Link tags,
if they are just links to the patch submission. That makes it
clear this is the case, just the patch. You can use lore for
actual bug reports etc.
Pulled, but please change the above two things going forward.
--
Jens Axboe
^ permalink raw reply
* [GIT PULL] md-7.1-20260428
From: Yu Kuai @ 2026-04-28 14:33 UTC (permalink / raw)
To: Jens Axboe
Cc: linux-block, linux-raid, Song Liu, Li Nan, Xiao Ni,
Abd-Alrhman Masalkhi, Benjamin Marzinski, Junrui Luo, Keith Busch
Hi Jens,
Please consider pulling the following changes into your block-7.1
branch.
This pull request contains:
Bug Fixes:
- Fix a raid5 UAF on IO across the reshape position.
- Avoid failing RAID1/RAID10 devices for invalid IO errors.
- Fix RAID10 divide-by-zero when far_copies is zero.
- Restore bitmap grow through sysfs.
Cleanups:
- Use mddev_is_dm() instead of open-coding gendisk checks.
- Use ATTRIBUTE_GROUPS() for md default sysfs attributes.
- Replace open-coded wait loops with wait_event helpers.
Others:
- Add Xiao Ni as md/raid reviewer.
Thanks,
Kuai
---
The following changes since commit 0898a817621a2f0cddca8122d9b974003fe5036d:
cdrom, scsi: sr: propagate read-only status to block layer via set_disk_ro() (2026-04-27 15:52:51 -0600)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/mdraid/linux.git tags/md-7.1-20260428
for you to fetch changes up to 3b2f70eab5a2cd15e27b1447e66e45302b28ff2c:
md: use ATTRIBUTE_GROUPS() for md default sysfs attributes (2026-04-28 20:44:38 +0800)
----------------------------------------------------------------
Abd-Alrhman Masalkhi (5):
md: replace wait loop with wait_event() in md_handle_request()
md: use mddev_lock_nointr() in mddev_suspend_and_lock_nointr()
md/raid1: replace wait loop with wait_event_idle() in raid1_write_request()
md: use mddev_is_dm() instead of open-coding gendisk checks
md: use ATTRIBUTE_GROUPS() for md default sysfs attributes
Benjamin Marzinski (1):
md/raid5: Fix UAF on IO across the reshape position
Junrui Luo (1):
md/raid10: fix divide-by-zero in setup_geo() with zero far_copies
Keith Busch (1):
md/raid1,raid10: don't fail devices for invalid IO errors
Xiao Ni (1):
MAINTAINERS: Add Xiao Ni as md/raid reviewer
Yu Kuai (3):
md: factor bitmap creation away from sysfs handling
md/md-bitmap: split bitmap sysfs groups
md/md-bitmap: add a none backend for bitmap grow
MAINTAINERS | 1 +
drivers/md/md-bitmap.c | 131 ++++++++++++++++++++++++++++++----
drivers/md/md-bitmap.h | 2 +-
drivers/md/md-llbitmap.c | 7 +-
drivers/md/md.c | 182 ++++++++++++++++++++++++++---------------------
drivers/md/md.h | 6 +-
drivers/md/raid1-10.c | 7 +-
drivers/md/raid1.c | 15 ++--
drivers/md/raid10.c | 2 +
drivers/md/raid5.c | 7 +-
10 files changed, 251 insertions(+), 109 deletions(-)
^ permalink raw reply
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