* Re: [PATCH RFC v4 1/3] block: add BIO_COMPLETE_IN_TASK for task-context completion
From: Christoph Hellwig @ 2026-04-15 6:10 UTC (permalink / raw)
To: Tal Zussman
Cc: Jens Axboe, Matthew Wilcox, Christian Brauner, Darrick J. Wong,
Carlos Maiolino, Alexander Viro, Jan Kara, Christoph Hellwig,
linux-block, linux-kernel, linux-xfs, linux-fsdevel, linux-mm
In-Reply-To: <fd94b108-22c1-4eb6-8fb4-b009214976dc@columbia.edu>
On Tue, Apr 14, 2026 at 04:29:29PM -0400, Tal Zussman wrote:
> No problem, thanks!
>
> >> (Although Christoph seems to have proposed moving away from llist again)
> >
> > I think that's a good idea, not a fan of using llist for this, in case
> > that wasn't clear. These are per-cpu lists anyway, and having a constant
> > overhead is better than needing to reverse an llist. IMHO.
>
> Will change it back for the next version.
FYI, the prime reason I switched away form the llist is to make sure
we can atomically check the list emptyness vs the wakeup decision
in the kthread version. But if Jens prefers it for other versions as
well, that's fine.
^ permalink raw reply
* [PATCH 2/2] block: only restrict bio allocation gfp mask asked to block
From: Christoph Hellwig @ 2026-04-15 6:08 UTC (permalink / raw)
To: Jens Axboe, Doug Gilbert, Martin K. Petersen
Cc: Shin'ichiro Kawasaki, linux-block, linux-scsi
In-Reply-To: <20260415060813.807659-1-hch@lst.de>
If the caller is asking for a non-blocking allocation, we should not
further restrict the gfp mask, which just increases the likelihood
of failures.
Fixes: b520c4eef83d ("block: split bio_alloc_bioset more clearly into a fast and slowpath")
Reported-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
block/bio.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/block/bio.c b/block/bio.c
index 641ef0928d73..12341f760b9a 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -544,7 +544,8 @@ struct bio *bio_alloc_bioset(struct block_device *bdev, unsigned short nr_vecs,
if (WARN_ON_ONCE(!mempool_initialized(&bs->bvec_pool) && nr_vecs > 0))
return NULL;
- gfp = try_alloc_gfp(gfp);
+ if (saved_gfp & __GFP_DIRECT_RECLAIM)
+ gfp = try_alloc_gfp(gfp);
if (bs->cache && nr_vecs <= BIO_INLINE_VECS) {
/*
* Set REQ_ALLOC_CACHE even if no cached bio is available to
--
2.53.0
^ permalink raw reply related
* [PATCH 1/2] sg: don't use GFP_ATOMIC in sg_start_req
From: Christoph Hellwig @ 2026-04-15 6:08 UTC (permalink / raw)
To: Jens Axboe, Doug Gilbert, Martin K. Petersen
Cc: Shin'ichiro Kawasaki, linux-block, linux-scsi
In-Reply-To: <20260415060813.807659-1-hch@lst.de>
sg_start_req is called from normal user context and can sleep when
waiting for memory. Switch it to use GFP_KERNEL, which fixes allocation
failures seend with the bio_alloc rework.
Fixes: b520c4eef83d ("block: split bio_alloc_bioset more clearly into a fast and slowpath")
Reported-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Tested-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
---
drivers/scsi/sg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 37bac49f30f0..43265f012ce9 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -1811,7 +1811,7 @@ sg_start_req(Sg_request *srp, unsigned char *cmd)
}
res = blk_rq_map_user_io(rq, md, hp->dxferp, hp->dxfer_len,
- GFP_ATOMIC, iov_count, iov_count, 1, rw);
+ GFP_KERNEL, iov_count, iov_count, 1, rw);
if (!res) {
srp->bio = rq->bio;
--
2.53.0
^ permalink raw reply related
* fix /dev/sg allocation failures register
From: Christoph Hellwig @ 2026-04-15 6:08 UTC (permalink / raw)
To: Jens Axboe, Doug Gilbert, Martin K. Petersen
Cc: Shin'ichiro Kawasaki, linux-block, linux-scsi
Hi all,
Shin'ichiro reported trivially triggerable allocation failures when
using SG_IO on the sg driver. This turn out to be caused by the
bio allocation rework, which makes non-blocking allocation fail
much easier.
This series has two independent patches to fix this from different
angles. The first one changes the completely pointless GFP_ATOMIC
to use GFP_ATOMIC in sg. The other drops the reduction of the gfp
mask in the bio allocator, so that atomic allocations of bios work
as expected, even if they are a pretty bad idea as the bio submission
actually needs a user context anyway. The only other uses of this
seems to be the ocfs2 cluster managed.
^ permalink raw reply
* Re: [PATCH 8/8] RFC: use a TASK_FIFO kthread for read completion support
From: Gao Xiang @ 2026-04-15 6:05 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Dave Chinner, Tal Zussman, Jens Axboe, Matthew Wilcox (Oracle),
Christian Brauner, Darrick J. Wong, Carlos Maiolino, Al Viro,
Jan Kara, Bart Van Assche, linux-block, linux-kernel, linux-xfs,
linux-fsdevel, linux-mm, Sandeep Dhavale, Tejun Heo,
Lai Jiangshan, Thomas Gleixner, Sebastian Andrzej Siewior,
Anuj Gupta
In-Reply-To: <20260415055552.GD26893@lst.de>
On 2026/4/15 13:55, Christoph Hellwig wrote:
> On Tue, Apr 14, 2026 at 10:23:13AM +0800, Gao Xiang wrote:
...
>
>>> Tejun asked Sandeep if setting the workqueue thread priority to
>>> -19 through sysfs (i.e. making them higher priority than normal
>>> kernel threads) had the same effect on latency as using a dedicated
>>> per-cpu RT task thread. THere was no followup.
>>
>> I think the issue is that people are not already working on the
>> same topic:
>>
>> - Unlike large subsystems like XFS, people don't already work on
>> EROFS unless they have new requirements or urgent production
>> issues;
>>
>> - The original latency issue was already considered as "done" in
>> 2023, and I'm not sure if Sandeep could have the bandwidth to
>> pause his current work and test more setups according to this
>> ongoing discussion in 2026.
>
> Which unfortunately might explain the sad state of Android. You
> really need dedicated people around and help to improve core
> infrastructure, instead of adding random Kconfig choices.
Sigh, let's not regard it as a technical problem, and it's more
of a non-technical development resource issue among different
resource groups & vendors.
The detailed background is much much more complex than I could
write all down explicitly here, but at least I will try to
contact with Sandeep and more related people to test again
in 2026 if a cleaner approach can be worked out.
Thanks,
Gao Xiang
^ permalink raw reply
* Re: [PATCH 8/8] RFC: use a TASK_FIFO kthread for read completion support
From: Christoph Hellwig @ 2026-04-15 5:55 UTC (permalink / raw)
To: Gao Xiang
Cc: Dave Chinner, Christoph Hellwig, Tal Zussman, Jens Axboe,
Matthew Wilcox (Oracle), Christian Brauner, Darrick J. Wong,
Carlos Maiolino, Al Viro, Jan Kara, Bart Van Assche, linux-block,
linux-kernel, linux-xfs, linux-fsdevel, linux-mm, Sandeep Dhavale,
Tejun Heo, Lai Jiangshan, Thomas Gleixner,
Sebastian Andrzej Siewior, Anuj Gupta
In-Reply-To: <a7a74185-df02-4906-a0ec-f87e2394aa5f@linux.alibaba.com>
On Tue, Apr 14, 2026 at 10:23:13AM +0800, Gao Xiang wrote:
> All softirq IO completion already works like this although
> softirq tasks are not strictly called "RT tasks" (i.e. a non-RT
> task issues the IO, and the softirq IO completion will interrupt
> all ongoing tasks).
>
> Basically what we want is to get a non-atomic context instead of
> using the current softirq context for read post-processing and
> switch to the task context immediately as you said, because:
>
> - Our post-processing needs to work in task contexts since
> advanced features like compression deduplication need it;
>
> - Even regardless of our specific requirement needing task
> contexts, using a dedicated task context for read
> post-processing is much better than run in the original
> softirq context:
>
> - Algorithmic work could take extra time (especially slow
> LZMA algorithm could take milliseconds on low devices
> (however, we need a common workflow for all algorithms,
> including fast algorithms like lz4) and verify work for
> example); and long processing time will interfere with
> other remaining softirq tasks like sound-playback
> / network softirqs;
>
> - If it is then deferred to softirqd, it just makes this
> latency issue _worse_.
Yes, and the same applies to a lot of other things. A very similar
algorithmic issue is the checksum validation, be that T10-PI or
file system native checksums. We don't want to run them from
soft/hardirq context obviously, but we really need them to preempt
other work on the cpu, and avoid scheduling latency. The case
that started this is a bit different - folio invalidation mostly
needs user context to take sleeping locks, but those are usually
uncontented. Again, getting this work done ASAP as readers
are synchronously waiting is important.
>> Tejun asked Sandeep if setting the workqueue thread priority to
>> -19 through sysfs (i.e. making them higher priority than normal
>> kernel threads) had the same effect on latency as using a dedicated
>> per-cpu RT task thread. THere was no followup.
>
> I think the issue is that people are not already working on the
> same topic:
>
> - Unlike large subsystems like XFS, people don't already work on
> EROFS unless they have new requirements or urgent production
> issues;
>
> - The original latency issue was already considered as "done" in
> 2023, and I'm not sure if Sandeep could have the bandwidth to
> pause his current work and test more setups according to this
> ongoing discussion in 2026.
Which unfortunately might explain the sad state of Android. You
really need dedicated people around and help to improve core
infrastructure, instead of adding random Kconfig choices.
^ permalink raw reply
* Re: [PATCH 8/8] RFC: use a TASK_FIFO kthread for read completion support
From: Christoph Hellwig @ 2026-04-15 5:50 UTC (permalink / raw)
To: Dave Chinner
Cc: Christoph Hellwig, Tal Zussman, Jens Axboe,
Matthew Wilcox (Oracle), Christian Brauner, Darrick J. Wong,
Carlos Maiolino, Al Viro, Jan Kara, Bart Van Assche, Gao Xiang,
linux-block, linux-kernel, linux-xfs, linux-fsdevel, linux-mm,
Tejun Heo, Lai Jiangshan
In-Reply-To: <20260415054835.GB26893@lst.de>
[adding the workqueue maintainers that I should have added]
On Wed, Apr 15, 2026 at 07:48:35AM +0200, Christoph Hellwig wrote:
> On Sat, Apr 11, 2026 at 08:11:22AM +1000, Dave Chinner wrote:
> > Can we please not go back to the (bad) old days of individual
> > subsystems needing their own set of per-cpu kernel tasks just
> > sitting around idle most of of the time? The whole point of the
> > workqueue infrastructure was to get rid of this widely repeated
> > anti-pattern.
> >
> > If there's a latency problem with workqueue scheduling, then we
> > should be fixing that problem rather than working around it in every
> > subsystem that thinkgs it has a workqueue scheduling latency
> > issue...
>
> Fixing the workqueue scheduling would be nice, but the attempts so far
> failed.
>
> In addition to that for a lot of theses cases workqueues are actually a
> surprisingly bad fit - we have items we want to queue up an one single
> function to call on all of them. So the overhead should be a list item
> (which often can be singly linked) in the object, while the workqueue
> also adds flags and a function pointer, bloating the size. We often work
> around this by having a single work_struct work on multiple objects, but
> that just increases the amount of work that needs to be done, including
> atomics and scheduling.
>
> Last but not least bio completion isn't really any random subsystem.
> Block I/O completion is important enough that we have an even more
> epensive softirq allocated to it. I agree that the dynamic
> workqueue-style workers are a much better choise for most use cases,
> though.
---end quoted text---
^ permalink raw reply
* Re: [PATCH 8/8] RFC: use a TASK_FIFO kthread for read completion support
From: Christoph Hellwig @ 2026-04-15 5:48 UTC (permalink / raw)
To: Dave Chinner
Cc: Christoph Hellwig, Tal Zussman, Jens Axboe,
Matthew Wilcox (Oracle), Christian Brauner, Darrick J. Wong,
Carlos Maiolino, Al Viro, Jan Kara, Bart Van Assche, Gao Xiang,
linux-block, linux-kernel, linux-xfs, linux-fsdevel, linux-mm
In-Reply-To: <adl1iqhldFvJwSw-@dread>
On Sat, Apr 11, 2026 at 08:11:22AM +1000, Dave Chinner wrote:
> Can we please not go back to the (bad) old days of individual
> subsystems needing their own set of per-cpu kernel tasks just
> sitting around idle most of of the time? The whole point of the
> workqueue infrastructure was to get rid of this widely repeated
> anti-pattern.
>
> If there's a latency problem with workqueue scheduling, then we
> should be fixing that problem rather than working around it in every
> subsystem that thinkgs it has a workqueue scheduling latency
> issue...
Fixing the workqueue scheduling would be nice, but the attempts so far
failed.
In addition to that for a lot of theses cases workqueues are actually a
surprisingly bad fit - we have items we want to queue up an one single
function to call on all of them. So the overhead should be a list item
(which often can be singly linked) in the object, while the workqueue
also adds flags and a function pointer, bloating the size. We often work
around this by having a single work_struct work on multiple objects, but
that just increases the amount of work that needs to be done, including
atomics and scheduling.
Last but not least bio completion isn't really any random subsystem.
Block I/O completion is important enough that we have an even more
epensive softirq allocated to it. I agree that the dynamic
workqueue-style workers are a much better choise for most use cases,
though.
^ permalink raw reply
* Re: [PATCH 4/8] FOLD: block: change the defer in task context interface to be procedural
From: Christoph Hellwig @ 2026-04-15 5:44 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Christoph Hellwig, Tal Zussman, Jens Axboe, Christian Brauner,
Darrick J. Wong, Carlos Maiolino, Al Viro, Jan Kara, Dave Chinner,
Bart Van Assche, Gao Xiang, linux-block, linux-kernel, linux-xfs,
linux-fsdevel, linux-mm
In-Reply-To: <adj6iibxNot-yc9X@casper.infradead.org>
On Fri, Apr 10, 2026 at 02:26:34PM +0100, Matthew Wilcox wrote:
> > Yes. On the other hand we can actually use it when we don't know if
> > we need to offload beforehand, which enabls the two later conversions
> > and probably more.
>
> I don't understand why we need to remove _this_ way to defer completions
> to take context in order to _add_ the ability to defer completions
> inside the bi_end_io handler.
I don't need to, but we'd better have very strong reasons for two ways
to do the same thing, and I don't really see it here. But I can give it
a try if the consensus is that we want to way to do it, and we're not
worried about people getting the bio-flag one wrong as we could set it
from ->bi_end_io, but it would not do anything.
^ permalink raw reply
* Re: [PATCH v6 00/43] btrfs: add fscrypt support
From: Neal Gompa @ 2026-04-15 5:30 UTC (permalink / raw)
To: Daniel Vacek
Cc: Eric Biggers, Chris Mason, Josef Bacik, Theodore Y. Ts'o,
Jaegeuk Kim, Jens Axboe, David Sterba, linux-block, linux-fscrypt,
linux-btrfs, linux-kernel
In-Reply-To: <CAPjX3Ff0=OOWcPHWam0WEGUY-xx860NHQt=igfZ9102-Zj1nOw@mail.gmail.com>
On Sat, Feb 28, 2026 at 2:57 AM Daniel Vacek <neelx@suse.com> wrote:
>
> On Fri, 27 Feb 2026 at 23:26, Neal Gompa <ngompa13@gmail.com> wrote:
> > On Fri, Feb 27, 2026 at 10:55 AM Daniel Vacek <neelx@suse.com> wrote:
> > > On Sat, 21 Feb 2026 at 21:56, Eric Biggers <ebiggers@kernel.org> wrote:
> > > > On Fri, Feb 06, 2026 at 07:22:32PM +0100, Daniel Vacek wrote:
> > > > > Hello,
> > > > >
> > > > > These are the remaining parts from former series [1] from Omar, Sweet Tea
> > > > > and Josef. Some bits of it were split into the separate set [2] before.
> > > > >
> > > > > Notably, at this stage encryption is not supported with RAID5/6 setup
> > > > > and send is also isabled for now.
> > > >
> > > > Where does this series apply to? There's no base-commit or git tree,
> > > > and it doesn't apply to mainline or btrfs/for-next.
> > >
> > > Hi Eric,
> > >
> > > My apologies, I did not explicitly mention the base. I'll do it next time.
> > > This was based on for-next @20260127 (commit 80dbfe6512d9c).
> > > Since then, some changes occurred that will require additional
> > > touches. No wonder it does not apply anymore.
> > >
> >
> > When you make your next revision, can you also provide a tag or branch
> > that I can use to grab the patches for testing? It would be easier for
> > me than trying to yoink them down from the emails with how many of
> > them there are...
>
> Sure
>
Ping to ask about the refreshed patch set. With 7.0 out the door, it'd
be nice to have an updated set with feedback addressed...
--
真実はいつも一つ！/ Always, there's only one truth!
^ permalink raw reply
* Re: [PATCH 1/7] ublk: widen ublk_shmem_buf_reg.len to __u64 for 4GB buffer support
From: Ming Lei @ 2026-04-14 23:49 UTC (permalink / raw)
To: Caleb Sander Mateos; +Cc: Jens Axboe, linux-block
In-Reply-To: <CADUfDZr39RaLObyXg9sijCOpLF4K2+TZH3ygGiCVxO8aAqwTkw@mail.gmail.com>
On Tue, Apr 14, 2026 at 11:40:36AM -0700, Caleb Sander Mateos wrote:
> On Thu, Apr 9, 2026 at 6:30 AM Ming Lei <tom.leiming@gmail.com> wrote:
> >
> > The __u32 len field cannot represent a 4GB buffer (0x100000000
> > overflows to 0). Change it to __u64 so buffers up to 4GB can be
> > registered. Add a reserved field for alignment and validate it
> > is zero.
> >
> > The kernel enforces a default max of 4GB (UBLK_SHMEM_BUF_SIZE_MAX)
> > which may be increased in future.
> >
> > Signed-off-by: Ming Lei <tom.leiming@gmail.com>
> > ---
> > drivers/block/ublk_drv.c | 9 ++++++++-
> > include/uapi/linux/ublk_cmd.h | 3 ++-
> > 2 files changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c
> > index 2e475bdc54dd..ada9a2e32ea9 100644
> > --- a/drivers/block/ublk_drv.c
> > +++ b/drivers/block/ublk_drv.c
> > @@ -63,6 +63,9 @@
> > #define UBLK_CMD_REG_BUF _IOC_NR(UBLK_U_CMD_REG_BUF)
> > #define UBLK_CMD_UNREG_BUF _IOC_NR(UBLK_U_CMD_UNREG_BUF)
> >
> > +/* Default max shmem buffer size: 4GB (may be increased in future) */
> > +#define UBLK_SHMEM_BUF_SIZE_MAX (1ULL << 32)
> > +
> > #define UBLK_IO_REGISTER_IO_BUF _IOC_NR(UBLK_U_IO_REGISTER_IO_BUF)
> > #define UBLK_IO_UNREGISTER_IO_BUF _IOC_NR(UBLK_U_IO_UNREGISTER_IO_BUF)
> >
> > @@ -5351,11 +5354,15 @@ static int ublk_ctrl_reg_buf(struct ublk_device *ub,
> > if (buf_reg.flags & ~UBLK_SHMEM_BUF_READ_ONLY)
> > return -EINVAL;
> >
> > + if (buf_reg.reserved)
> > + return -EINVAL;
> > +
> > addr = buf_reg.addr;
> > size = buf_reg.len;
> > nr_pages = size >> PAGE_SHIFT;
> >
> > - if (!size || !PAGE_ALIGNED(size) || !PAGE_ALIGNED(addr))
> > + if (!size || size > UBLK_SHMEM_BUF_SIZE_MAX ||
>
> Should be >=? Otherwise, LGTM.
It should be ">" because we do want to support 4GB size buffer.
Thanks,
Ming
^ permalink raw reply
* Re: [PATCH RFC v4 1/3] block: add BIO_COMPLETE_IN_TASK for task-context completion
From: Tal Zussman @ 2026-04-14 20:29 UTC (permalink / raw)
To: Jens Axboe
Cc: Matthew Wilcox, Christian Brauner, Darrick J. Wong,
Carlos Maiolino, Alexander Viro, Jan Kara, Christoph Hellwig,
linux-block, linux-kernel, linux-xfs, linux-fsdevel, linux-mm
In-Reply-To: <fb64ba71-7284-4768-979b-84919f2aa5f0@kernel.dk>
On 4/9/26 8:46 PM, Jens Axboe wrote:
> On 4/9/26 12:54 PM, Tal Zussman wrote:
>> On 4/8/26 7:36 PM, Jens Axboe wrote:
>>> On Apr 8, 2026, at 4:51PM, Tal Zussman <tz2294@columbia.edu> wrote:
>>>>
>>>> Going to send v5 shortly -- tested with and without the llist reversal and
>>>> it didn't seem to make much of a difference. This was on a single-disk VM
>>>> though, so any stress testing you could do would be very helpful.
>>>>
>>>
>>> With all due respect, a single test like that isn?t going to be that useful. I'd be wary of making that change willy nilly and just thinking it's fine, worked fine on the one case I tested?.
>>
>> Understood -- unfortunately that's what I have access to at the moment. I
>> can requisition a machine with 2, maybe 3 disks, and test more thoroughly on
>> that before sending the next version, but that'll take a few days. You had
>> previously offered to test on your big box, so was hoping that was still on
>> the table :)
>
> I can do that, but I'm OOO for the next week, so won't be until I'm
> back.
>
No problem, thanks!
>> (Although Christoph seems to have proposed moving away from llist again)
>
> I think that's a good idea, not a fan of using llist for this, in case
> that wasn't clear. These are per-cpu lists anyway, and having a constant
> overhead is better than needing to reverse an llist. IMHO.
Will change it back for the next version.
> --
> Jens Axboe
>
^ permalink raw reply
* Re: [PATCH v2 00/10] ublk: add shared memory zero-copy support
From: Keith Busch @ 2026-04-14 18:56 UTC (permalink / raw)
To: Ming Lei; +Cc: Jens Axboe, linux-block, Caleb Sander Mateos
In-Reply-To: <20260331153207.3635125-1-ming.lei@redhat.com>
On Tue, Mar 31, 2026 at 11:31:51PM +0800, Ming Lei wrote:
> Hello,
>
> Add shared memory based zero-copy (UBLK_F_SHMEM_ZC) support for ublk.
>
> The ublk server and its client share a memory region (e.g. memfd or
> hugetlbfs file) via MAP_SHARED mmap. The server registers this region
> with the kernel via UBLK_U_CMD_REG_BUF, which pins the pages and
> builds a PFN maple tree. When I/O arrives, the driver looks up bio
> pages in the maple tree - if they match registered buffer pages, the
> data is used directly without copying.
I feel if you have the ability to change an application to cooperatively
share memfd's with a ublk server, then why wouldn't you go one step
further: use vhost-user-blk and skip the kernel entirely?
The value for the existing ublk zero-copy setup was that original/legacy
applications didn't need to change. Of course it has the limitation of
what the ublk server can access, but if you're trying to get around that
with cooperative clients, then why not go all the way? What is ublk
providing here?
^ permalink raw reply
* Re: [PATCH 1/7] ublk: widen ublk_shmem_buf_reg.len to __u64 for 4GB buffer support
From: Caleb Sander Mateos @ 2026-04-14 18:40 UTC (permalink / raw)
To: Ming Lei; +Cc: Jens Axboe, linux-block
In-Reply-To: <20260409133020.3780098-2-tom.leiming@gmail.com>
On Thu, Apr 9, 2026 at 6:30 AM Ming Lei <tom.leiming@gmail.com> wrote:
>
> The __u32 len field cannot represent a 4GB buffer (0x100000000
> overflows to 0). Change it to __u64 so buffers up to 4GB can be
> registered. Add a reserved field for alignment and validate it
> is zero.
>
> The kernel enforces a default max of 4GB (UBLK_SHMEM_BUF_SIZE_MAX)
> which may be increased in future.
>
> Signed-off-by: Ming Lei <tom.leiming@gmail.com>
> ---
> drivers/block/ublk_drv.c | 9 ++++++++-
> include/uapi/linux/ublk_cmd.h | 3 ++-
> 2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c
> index 2e475bdc54dd..ada9a2e32ea9 100644
> --- a/drivers/block/ublk_drv.c
> +++ b/drivers/block/ublk_drv.c
> @@ -63,6 +63,9 @@
> #define UBLK_CMD_REG_BUF _IOC_NR(UBLK_U_CMD_REG_BUF)
> #define UBLK_CMD_UNREG_BUF _IOC_NR(UBLK_U_CMD_UNREG_BUF)
>
> +/* Default max shmem buffer size: 4GB (may be increased in future) */
> +#define UBLK_SHMEM_BUF_SIZE_MAX (1ULL << 32)
> +
> #define UBLK_IO_REGISTER_IO_BUF _IOC_NR(UBLK_U_IO_REGISTER_IO_BUF)
> #define UBLK_IO_UNREGISTER_IO_BUF _IOC_NR(UBLK_U_IO_UNREGISTER_IO_BUF)
>
> @@ -5351,11 +5354,15 @@ static int ublk_ctrl_reg_buf(struct ublk_device *ub,
> if (buf_reg.flags & ~UBLK_SHMEM_BUF_READ_ONLY)
> return -EINVAL;
>
> + if (buf_reg.reserved)
> + return -EINVAL;
> +
> addr = buf_reg.addr;
> size = buf_reg.len;
> nr_pages = size >> PAGE_SHIFT;
>
> - if (!size || !PAGE_ALIGNED(size) || !PAGE_ALIGNED(addr))
> + if (!size || size > UBLK_SHMEM_BUF_SIZE_MAX ||
Should be >=? Otherwise, LGTM.
Best,
Caleb
> + !PAGE_ALIGNED(size) || !PAGE_ALIGNED(addr))
> return -EINVAL;
>
> disk = ublk_get_disk(ub);
> diff --git a/include/uapi/linux/ublk_cmd.h b/include/uapi/linux/ublk_cmd.h
> index ecd258847d3d..66d93efccd51 100644
> --- a/include/uapi/linux/ublk_cmd.h
> +++ b/include/uapi/linux/ublk_cmd.h
> @@ -89,8 +89,9 @@
> /* Parameter buffer for UBLK_U_CMD_REG_BUF, pointed to by ctrl_cmd.addr */
> struct ublk_shmem_buf_reg {
> __u64 addr; /* userspace virtual address of shared memory */
> - __u32 len; /* buffer size in bytes (page-aligned, max 4GB) */
> + __u64 len; /* buffer size in bytes, page-aligned, default max 4GB */
> __u32 flags;
> + __u32 reserved;
> };
>
> /* Pin pages without FOLL_WRITE; usable with write-sealed memfd */
> --
> 2.53.0
>
^ permalink raw reply
* Re: zloop fixes
From: Johannes Thumshirn @ 2026-04-14 16:20 UTC (permalink / raw)
To: Christoph Hellwig, Jens Axboe, Damien Le Moal; +Cc: linux-block
In-Reply-To: <20260414081811.549755-1-hch@lst.de>
On 4/14/26 10:17 AM, Christoph Hellwig wrote:
> Hi all,
>
> this series fixes a bad bug and a few minor issues in the new zloop code
> queued up for 7.1.
>
> Diffstat:
> zloop.c | 123 ++++++++++++++++++++++++++++++----------------------------------
> 1 file changed, 59 insertions(+), 64 deletions(-)
>
Looks good,
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
^ permalink raw reply
* Re: [PATCH 2/4] tools: ynl-gen-c: optionally emit structs and helpers
From: Jakub Kicinski @ 2026-04-14 15:35 UTC (permalink / raw)
To: Christoph Böhmwalder
Cc: Jens Axboe, drbd-dev, linux-kernel, Lars Ellenberg,
Philipp Reisner, linux-block, Donald Hunter, Eric Dumazet, netdev
In-Reply-To: <ad4ox7ibZoiW-tje@localhost.localdomain>
On Tue, 14 Apr 2026 14:08:58 +0200 Christoph Böhmwalder wrote:
> But we still need to support the current family via a compat path, and
> I would much rather have two YNL-based families than one genl_magic and
> one YNL-based. Carrying both sounds like a nightmare.
>
> So the spec proposed in this series would never actually be used to
> generate a userspace client, if that's what you're asking. We would
> continue to use the current libgenl-based approach, with some userspace
> compat shims to make it work with YNL. Then, when "drbd2" comes along,
> we could "do things properly".
Let's jump to the drbd2 work.
^ permalink raw reply
* Re: [PATCH v6 24/43] btrfs: add extent encryption context tree item type
From: Mark Harmstone @ 2026-04-14 14:23 UTC (permalink / raw)
To: Daniel Vacek, Chris Mason
Cc: Chris Mason, Josef Bacik, Eric Biggers, Theodore Y. Ts'o,
Jaegeuk Kim, Jens Axboe, David Sterba, linux-block, linux-fscrypt,
linux-btrfs, linux-kernel
In-Reply-To: <CAPjX3FdgJKQyM0tdCksgLAtVyjos_nx3TRg6rvjYB1wE2QH1Cw@mail.gmail.com>
On 18/02/2026 5.25 pm, Daniel Vacek wrote:
> On Sun, 8 Feb 2026 at 16:17, Chris Mason <clm@meta.com> wrote:
>> Daniel Vacek <neelx@suse.com> wrote:
>>> From: Josef Bacik <josef@toxicpanda.com>
>>>
>>> The fscrypt encryption context will be stored as a new tree item type.
>>> This gives us flexibility to include different things in the future.
>>>
>>> Also update the tree-checker to validate the new item type.
>>
>> Hi everyone,
>>
>> I'm running the btrfs for-next branch, along with the encryption patch set
>> through my AI review prompts:
>>
>> https://github.com/masoncl/review-prompts
>>
>> I'm working on some btrfs specific instructions, but hopefully these reviews
>> are already useful. I've kept the headers to make it easier to double check
>> that I'm actually replying to the right email, but please let me know if any
>> parts of this are incorrect:
>>
>> commit 203bfb91a4db9c826fa7f72034c13a1810a1b605
>> Author: Josef Bacik <josef@toxicpanda.com>
>>
>> btrfs: add extent encryption context tree item type
>>
>> The fscrypt encryption context will be stored as a new tree item type.
>> This gives us flexibility to include different things in the future.
>> Also update the tree-checker to validate the new item type.
>>
>>> diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
>>> index 3c0db279f592e..639462164d089 100644
>>> --- a/fs/btrfs/file.c
>>> +++ b/fs/btrfs/file.c
>>
>> [ ... ]
>>
>>> @@ -496,6 +503,60 @@ int btrfs_drop_extents(struct btrfs_trans_handle *trans,
>>> args->extent_inserted = true;
>>> }
>>>
>>> + if (first_ctx <= last_ctx) {
>>> + int slot, nritems;
>>> +
>>> + btrfs_release_path(path);
>>> +
>>> + key.objectid = ino;
>>> + key.type = BTRFS_FSCRYPT_CTX_KEY;
>>> + key.offset = first_ctx;
>>> +
>>> + ret = btrfs_search_slot(trans, root, &key, path, modify_tree, !!modify_tree);
>>> + if (ret < 0)
>>> + goto out_ctx;
>>
>> [ ... ]
>>
>>> +out_ctx:
>>> + if (args->path && args->extent_inserted) {
>>> + btrfs_release_path(path);
>>> +
>>> + key.objectid = ino;
>>> + key.type = BTRFS_EXTENT_DATA_KEY;
>>> + key.offset = args->start;
>>> + ret = btrfs_search_slot(trans, root, &key, path, 0, 0);
>>> + }
>>> + }
>>> +
>>
>> Can btrfs_search_slot() at line 556 overwrite an error that occurred
>> earlier in the out_ctx path?
>>
>> If btrfs_search_slot() at line 515 fails and execution jumps to out_ctx,
>> but args->path and args->extent_inserted are both true, the second
>> btrfs_search_slot() call will overwrite the original error stored in ret.
>>
>> If this second search succeeds (returns 0 or >0), the function returns
>> success to the caller despite the fscrypt context cleanup having failed.
>> This could lead to inconsistent filesystem state where extent data was
>> inserted but the corresponding fscrypt context items were not properly
>> cleaned up.
>
> Right, the original error should be returned. We do not care that much
> about the latter if the former failed.
> This should do the trick:
>
> --- a/fs/btrfs/file.c
> +++ b/fs/btrfs/file.c
> @@ -549,12 +549,16 @@ int btrfs_drop_extents(struct btrfs_trans_handle *trans,
> }
> out_ctx:
> if (args->path && args->extent_inserted) {
> + int err;
> +
> btrfs_release_path(path);
>
> key.objectid = ino;
> key.type = BTRFS_EXTENT_DATA_KEY;
> key.offset = args->start;
> - ret = btrfs_search_slot(trans, root, &key, path, 0, 0);
> + err = btrfs_search_slot(trans, root, &key, path, 0, 0);
> + if (err && ret >= 0)
> + ret = err;
> }
> }
>
>
>>> diff --git a/fs/btrfs/tree-checker.c b/fs/btrfs/tree-checker.c
>>> index 9675dbcd78a3b..776901f297fea 100644
>>> --- a/fs/btrfs/tree-checker.c
>>> +++ b/fs/btrfs/tree-checker.c
>>
>> [ ... ]
>>
>>> +static int check_fscrypt_context(struct extent_buffer *leaf,
>>> + struct btrfs_key *key, int slot,
>>> + struct btrfs_key *prev_key)
>>> +{
>>> + u32 sectorsize = leaf->fs_info->sectorsize;
>>> + u32 item_size = btrfs_item_size(leaf, slot);
>>> +
>>> + if (unlikely(!IS_ALIGNED(key->offset, sectorsize))) {
>>> + file_extent_err(leaf, slot,
>>> +"unaligned file_offset for encryption context, have %llu should be aligned to %u",
>>> + key->offset, sectorsize);
>>> + return -EUCLEAN;
>>> + }
>>> +
>>> + /*
>>> + * Previous key must have the same key->objectid (ino).
>>> + * It can be XATTR_ITEM, INODE_ITEM or just another EXTENT_DATA.
>>> + * But if objectids mismatch, it means we have a missing
>>> + * INODE_ITEM.
>>> + */
>>
>> This isn't a bug, but the comment says "It can be XATTR_ITEM, INODE_ITEM
>> or just another EXTENT_DATA" - can EXTENT_DATA actually be the previous
>> key type?
>>
>> For BTRFS_FSCRYPT_CTX_KEY (type=42), EXTENT_DATA (type=108) cannot be a
>> previous key because keys are sorted by (objectid, type, offset) and
>> 108 > 42.
>>
>> The correct previous key types would be: XATTR_ITEM, INODE_ITEM,
>> FSCRYPT_INODE_CTX_KEY, or another FSCRYPT_CTX_KEY.
>
> Spot on! The comment is wrong. I realized that later but never fixed it here.
> This is because of the redesign. In v5 the crypt context was embedded
> in the extent data item, so they could have been next to each other.
> This should look better:
>
> --- a/fs/btrfs/tree-checker.c
> +++ b/fs/btrfs/tree-checker.c
> @@ -220,10 +220,9 @@ static int check_fscrypt_context(struct
> extent_buffer *leaf,
> }
>
> /*
> - * Previous key must have the same key->objectid (ino).
> - * It can be XATTR_ITEM, INODE_ITEM or just another EXTENT_DATA.
> - * But if objectids mismatch, it means we have a missing
> - * INODE_ITEM.
> + * Previous key must have the same key->objectid (ino). It can be
> + * XATTR_ITEM, INODE_ITEM, FSCRYPT_INODE_CTX_KEY, or another
> FSCRYPT_CTX_KEY.
> + * But if objectids mismatch, it means we have a missing INODE_ITEM.
> */
> if (unlikely(!check_prev_ino(leaf, key, slot, prev_key)))
> return -EUCLEAN;
>
>>> @@ -214,6 +248,7 @@ static int check_extent_data_item(struct extent_buffer *leaf,
>>> u32 item_size = btrfs_item_size(leaf, slot);
>>> u64 extent_end;
>>> u8 policy;
>>> + u8 fe_type;
>>>
>>> if (unlikely(!IS_ALIGNED(key->offset, sectorsize))) {
>>> file_extent_err(leaf, slot,
>>
>> [ ... ]
>>
>>> @@ -298,6 +333,19 @@ static int check_extent_data_item(struct extent_buffer *leaf,
>>> return 0;
>>> }
>>>
>>> + if (policy == BTRFS_ENCRYPTION_FSCRYPT) {
>>> + /*
>>> + * Only regular and prealloc extents should have an encryption
>>> + * context.
>>> + */
>>> + if (unlikely(fe_type != BTRFS_FILE_EXTENT_REG &&
>>> + fe_type != BTRFS_FILE_EXTENT_PREALLOC)) {
>>> + file_extent_err(leaf, slot,
>>> + "invalid type for encrypted file extent, have %u", fe_type);
>>> + return -EUCLEAN;
>>> + }
>>> + }
>>
>> Can this validation check detect encrypted inline extents? Looking at
>> the function flow, inline extents (BTRFS_FILE_EXTENT_INLINE) are handled
>> at lines 310-333 and return before reaching this check.
>>
>> If a corrupted filesystem has an encrypted inline extent, it would pass
>> tree-checker validation. Should the encryption check be moved to also
>> cover the inline extent path, or should inline extents explicitly reject
>> BTRFS_ENCRYPTION_FSCRYPT?
>
> Inline extents are not encrypted.
Hi Daniel,
I've been playing around with this, and from what I gather:
* max_inline seems to be forced to 0, meaning that inline encrypted
extents won't be created
* symlinks still use inline extents, but AFAICS their values get munged
by fscrypt
Which suggests that we ought to be setting the encrypted flag on for
inline extents in symlinks.
Please tell me if I've misunderstood any of this.
Thanks
Mark
> Thanks.
>
> --nX
>
> On Sun, 8 Feb 2026 at 16:17, Chris Mason <clm@meta.com> wrote:
>>
>> Daniel Vacek <neelx@suse.com> wrote:
>>> From: Josef Bacik <josef@toxicpanda.com>
>>>
>>> The fscrypt encryption context will be stored as a new tree item type.
>>> This gives us flexibility to include different things in the future.
>>>
>>> Also update the tree-checker to validate the new item type.
>>
>> Hi everyone,
>>
>> I'm running the btrfs for-next branch, along with the encryption patch set
>> through my AI review prompts:
>>
>> https://github.com/masoncl/review-prompts
>>
>> I'm working on some btrfs specific instructions, but hopefully these reviews
>> are already useful. I've kept the headers to make it easier to double check
>> that I'm actually replying to the right email, but please let me know if any
>> parts of this are incorrect:
>>
>> commit 203bfb91a4db9c826fa7f72034c13a1810a1b605
>> Author: Josef Bacik <josef@toxicpanda.com>
>>
>> btrfs: add extent encryption context tree item type
>>
>> The fscrypt encryption context will be stored as a new tree item type.
>> This gives us flexibility to include different things in the future.
>> Also update the tree-checker to validate the new item type.
>>
>>> diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
>>> index 3c0db279f592e..639462164d089 100644
>>> --- a/fs/btrfs/file.c
>>> +++ b/fs/btrfs/file.c
>>
>> [ ... ]
>>
>>> @@ -496,6 +503,60 @@ int btrfs_drop_extents(struct btrfs_trans_handle *trans,
>>> args->extent_inserted = true;
>>> }
>>>
>>> + if (first_ctx <= last_ctx) {
>>> + int slot, nritems;
>>> +
>>> + btrfs_release_path(path);
>>> +
>>> + key.objectid = ino;
>>> + key.type = BTRFS_FSCRYPT_CTX_KEY;
>>> + key.offset = first_ctx;
>>> +
>>> + ret = btrfs_search_slot(trans, root, &key, path, modify_tree, !!modify_tree);
>>> + if (ret < 0)
>>> + goto out_ctx;
>>
>> [ ... ]
>>
>>> +out_ctx:
>>> + if (args->path && args->extent_inserted) {
>>> + btrfs_release_path(path);
>>> +
>>> + key.objectid = ino;
>>> + key.type = BTRFS_EXTENT_DATA_KEY;
>>> + key.offset = args->start;
>>> + ret = btrfs_search_slot(trans, root, &key, path, 0, 0);
>>> + }
>>> + }
>>> +
>>
>> Can btrfs_search_slot() at line 556 overwrite an error that occurred
>> earlier in the out_ctx path?
>>
>> If btrfs_search_slot() at line 515 fails and execution jumps to out_ctx,
>> but args->path and args->extent_inserted are both true, the second
>> btrfs_search_slot() call will overwrite the original error stored in ret.
>>
>> If this second search succeeds (returns 0 or >0), the function returns
>> success to the caller despite the fscrypt context cleanup having failed.
>> This could lead to inconsistent filesystem state where extent data was
>> inserted but the corresponding fscrypt context items were not properly
>> cleaned up.
>>
>>> diff --git a/fs/btrfs/tree-checker.c b/fs/btrfs/tree-checker.c
>>> index 9675dbcd78a3b..776901f297fea 100644
>>> --- a/fs/btrfs/tree-checker.c
>>> +++ b/fs/btrfs/tree-checker.c
>>
>> [ ... ]
>>
>>> +static int check_fscrypt_context(struct extent_buffer *leaf,
>>> + struct btrfs_key *key, int slot,
>>> + struct btrfs_key *prev_key)
>>> +{
>>> + u32 sectorsize = leaf->fs_info->sectorsize;
>>> + u32 item_size = btrfs_item_size(leaf, slot);
>>> +
>>> + if (unlikely(!IS_ALIGNED(key->offset, sectorsize))) {
>>> + file_extent_err(leaf, slot,
>>> +"unaligned file_offset for encryption context, have %llu should be aligned to %u",
>>> + key->offset, sectorsize);
>>> + return -EUCLEAN;
>>> + }
>>> +
>>> + /*
>>> + * Previous key must have the same key->objectid (ino).
>>> + * It can be XATTR_ITEM, INODE_ITEM or just another EXTENT_DATA.
>>> + * But if objectids mismatch, it means we have a missing
>>> + * INODE_ITEM.
>>> + */
>>
>> This isn't a bug, but the comment says "It can be XATTR_ITEM, INODE_ITEM
>> or just another EXTENT_DATA" - can EXTENT_DATA actually be the previous
>> key type?
>>
>> For BTRFS_FSCRYPT_CTX_KEY (type=42), EXTENT_DATA (type=108) cannot be a
>> previous key because keys are sorted by (objectid, type, offset) and
>> 108 > 42.
>>
>> The correct previous key types would be: XATTR_ITEM, INODE_ITEM,
>> FSCRYPT_INODE_CTX_KEY, or another FSCRYPT_CTX_KEY.
>>
>>> @@ -214,6 +248,7 @@ static int check_extent_data_item(struct extent_buffer *leaf,
>>> u32 item_size = btrfs_item_size(leaf, slot);
>>> u64 extent_end;
>>> u8 policy;
>>> + u8 fe_type;
>>>
>>> if (unlikely(!IS_ALIGNED(key->offset, sectorsize))) {
>>> file_extent_err(leaf, slot,
>>
>> [ ... ]
>>
>>> @@ -298,6 +333,19 @@ static int check_extent_data_item(struct extent_buffer *leaf,
>>> return 0;
>>> }
>>>
>>> + if (policy == BTRFS_ENCRYPTION_FSCRYPT) {
>>> + /*
>>> + * Only regular and prealloc extents should have an encryption
>>> + * context.
>>> + */
>>> + if (unlikely(fe_type != BTRFS_FILE_EXTENT_REG &&
>>> + fe_type != BTRFS_FILE_EXTENT_PREALLOC)) {
>>> + file_extent_err(leaf, slot,
>>> + "invalid type for encrypted file extent, have %u", fe_type);
>>> + return -EUCLEAN;
>>> + }
>>> + }
>>
>> Can this validation check detect encrypted inline extents? Looking at
>> the function flow, inline extents (BTRFS_FILE_EXTENT_INLINE) are handled
>> at lines 310-333 and return before reaching this check.
>>
>> If a corrupted filesystem has an encrypted inline extent, it would pass
>> tree-checker validation. Should the encryption check be moved to also
>> cover the inline extent path, or should inline extents explicitly reject
>> BTRFS_ENCRYPTION_FSCRYPT?
>>
>
^ permalink raw reply
* Re: [PATCH 03/13] libmultipath: Add path selection support
From: John Garry @ 2026-04-14 13:10 UTC (permalink / raw)
To: Nilay Shroff, hch, kbusch, sagi, axboe, martin.petersen,
james.bottomley, hare
Cc: jmeneghi, linux-nvme, linux-scsi, michael.christie, snitzer,
bmarzins, dm-devel, linux-block, linux-kernel
In-Reply-To: <6dc8e0d7-9b2b-4867-9df7-6853f4b2fa05@linux.ibm.com>
On 14/04/2026 12:43, Nilay Shroff wrote:
>>
>> about the queue-depth iopolicy, why is depth per controller and not
>> per NS (path)? The following does not mention:
>>
>> https://lore.kernel.org/linux-nvme/20240625122605.857462-3-
>> jmeneghi@redhat.com/
>>
>> Is the idea that some controller may have another NS attached and have
>> traffic there, and we need to account according to this also?
>>
> Yes, the idea is that congestion should be evaluated at the controller
> level rather than per-namespace.
> In NVMe, multiple namespaces can be attached to the same controller, and
> all of them share the same
> transport path and I/O queue resources (submission and completion
> queues). As a result, any contention
> or congestion is fundamentally observed at the controller, and not at an
> individual namespace.
>
> If we were to track queue depth per namespace, it could give a
> misleading view of the actual load on
> the underlying path, since multiple namespaces may be contributing to
> the same set of queues. In contrast,
> tracking queue depth per controller provides a more accurate
> representation of the total outstanding I/O
> and the level of congestion on that path.
>
> In a multipath configuration, this allows us to compare controllers
> directly. For example, if one controller
> has a lower queue depth than another, it is likely experiencing less
> contention and may offer lower latency,
> making it a better candidate for forwarding I/O.
ok, thanks for the info. So on this basis I would think that SCSI host
would be where we track requests for scsi-multipath. I need to consider
it more... Hannes, thoughts?
John
^ permalink raw reply
* Re: [PATCH 2/4] tools: ynl-gen-c: optionally emit structs and helpers
From: Christoph Böhmwalder @ 2026-04-14 12:08 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Jens Axboe, drbd-dev, linux-kernel, Lars Ellenberg,
Philipp Reisner, linux-block, Donald Hunter, Eric Dumazet, netdev
In-Reply-To: <20260413104939.5ef4d9dc@kernel.org>
On Mon, Apr 13, 2026 at 10:49:39AM -0700, Jakub Kicinski wrote:
>On Mon, 13 Apr 2026 13:48:32 +0200 Christoph Böhmwalder wrote:
>> >Can we just commit the code they output and leave the YNL itself be?
>> >Every single legacy family has some weird quirks the point of YNL
>> >is to get rid of them, not support them all..
>>
>> Fair enough, we could also do that. Though the question then becomes
>> whether we want to keep the YAML spec for the "drbd" family (patch 3 of
>> this series) in Documentation/.
>>
>> I would argue it makes sense to keep it around somewhere so that the old
>> family is somehow documented, but obviously that yaml file won't work
>> with the unmodified generator.
>
>To be clear (correct me if I misunderstood) it looked like we would be
>missing out on "automating" things, so extra work would still need to
>be done in the C code / manually written headers. But pure YNL (eg
>Python or Rust) client _would_ work? They could generate correct
>requests and parse responses, right?
I haven't tested this, but yes, a regular YNL client should work with
this spec. The new flags only influence kernel codegen, so a client
that doesn't know about them could still construct valid messages and
parse responses.
However, if we drop patch 2 completely, the new flags won't be in the
genetlink-legacy schema either, so schema validation would fail when
trying to generate.
>If yes, keeping it makes sense. FWIW all the specs we have for "old"
>networking families (routing etc) also don't replace any kernel code.
>They are purely to enable user space libraries in various languages.
>Whether having broad languages support for drbd or you just have one
>well known user space stack - I dunno.
Well, one of the main motivations for porting the current "drbd" family
to YNL is to get rid of the genl_magic infrastructure. We intend to add
a new modernized "drbd2" family, which will be fully YNL-based from the
start.
But we still need to support the current family via a compat path, and
I would much rather have two YNL-based families than one genl_magic and
one YNL-based. Carrying both sounds like a nightmare.
So the spec proposed in this series would never actually be used to
generate a userspace client, if that's what you're asking. We would
continue to use the current libgenl-based approach, with some userspace
compat shims to make it work with YNL. Then, when "drbd2" comes along,
we could "do things properly".
Might also be worth to mention that we are also experimenting with
Rust-based userspace utilities at the moment, so once we have "drbd2",
there will be a real benefit to having multi-language support.
So I'm fine with whichever route you want to take here, as long as
it enables us to move away from genl_magic.
If we decide to carry the "drbd" spec in-tree, that would then pretty
much only be for documentation purposes. Otherwise there would be
generated code where the spec it was generated from is non-existant,
which may be surprising.
>
>> Maybe keep it, but with a comment at the top that notes that
>> - this family is deprecated and "frozen",
>> - the spec is only for documentation purposes, and
>> - the spec doesn't work with the upstream parser?
>
>The past point needs a clarification, I guess..
^ permalink raw reply
* Re: [PATCH 03/13] libmultipath: Add path selection support
From: Nilay Shroff @ 2026-04-14 11:43 UTC (permalink / raw)
To: John Garry, hch, kbusch, sagi, axboe, martin.petersen,
james.bottomley, hare
Cc: jmeneghi, linux-nvme, linux-scsi, michael.christie, snitzer,
bmarzins, dm-devel, linux-block, linux-kernel
In-Reply-To: <bc18ad6f-10b1-4a28-b88d-aed5754b968d@oracle.com>
On 4/14/26 3:33 PM, John Garry wrote:
> Hi Nilay,
>
>>>
>>> I think so, but we will need scsi to maintain such a count internally to support this policy. And for NVMe we will need some abstraction to lookup the per-controller QD for a mpath_device.
>>>
>> This raises another question regarding the current framework. From what I can see, all NVMe multipath I/O policies are currently supported for SCSI as well. Going forward, if we introduce a new I/O policy for NVMe that does not make sense for SCSI, how can we ensure that the new policy is supported only for NVMe and not for SCSI? Conversely, we may also want to introduce a policy that is relevant only for SCSI but not for NVMe.
>>
>> With the current framework, it seems difficult to restrict a policy to a specific transport. It appears that all policies are implicitly shared between NVMe and SCSI.
>>
>> Would it make sense to introduce some abstraction for I/O policies in the framework so that a given policy can be implemented and exposed only for the relevant transport (e.g., NVMe-only or SCSI-only), rather than requiring it to be supported by both?
>
> I am just coming back to this now....
>
> about the queue-depth iopolicy, why is depth per controller and not per NS (path)? The following does not mention:
>
> https://lore.kernel.org/linux-nvme/20240625122605.857462-3-jmeneghi@redhat.com/
>
> Is the idea that some controller may have another NS attached and have traffic there, and we need to account according to this also?
>
Yes, the idea is that congestion should be evaluated at the controller level rather than per-namespace.
In NVMe, multiple namespaces can be attached to the same controller, and all of them share the same
transport path and I/O queue resources (submission and completion queues). As a result, any contention
or congestion is fundamentally observed at the controller, and not at an individual namespace.
If we were to track queue depth per namespace, it could give a misleading view of the actual load on
the underlying path, since multiple namespaces may be contributing to the same set of queues. In contrast,
tracking queue depth per controller provides a more accurate representation of the total outstanding I/O
and the level of congestion on that path.
In a multipath configuration, this allows us to compare controllers directly. For example, if one controller
has a lower queue depth than another, it is likely experiencing less contention and may offer lower latency,
making it a better candidate for forwarding I/O.
Thanks,
--Nilay
^ permalink raw reply
* Re: [PATCH 03/13] libmultipath: Add path selection support
From: John Garry @ 2026-04-14 10:03 UTC (permalink / raw)
To: Nilay Shroff, hch, kbusch, sagi, axboe, martin.petersen,
james.bottomley, hare
Cc: jmeneghi, linux-nvme, linux-scsi, michael.christie, snitzer,
bmarzins, dm-devel, linux-block, linux-kernel
In-Reply-To: <02288590-486e-4243-8352-c756c6879629@linux.ibm.com>
Hi Nilay,
>>
>> I think so, but we will need scsi to maintain such a count internally
>> to support this policy. And for NVMe we will need some abstraction to
>> lookup the per-controller QD for a mpath_device.
>>
> This raises another question regarding the current framework. From what
> I can see, all NVMe multipath I/O policies are currently supported for
> SCSI as well. Going forward, if we introduce a new I/O policy for NVMe
> that does not make sense for SCSI, how can we ensure that the new policy
> is supported only for NVMe and not for SCSI? Conversely, we may also
> want to introduce a policy that is relevant only for SCSI but not for NVMe.
>
> With the current framework, it seems difficult to restrict a policy to a
> specific transport. It appears that all policies are implicitly shared
> between NVMe and SCSI.
>
> Would it make sense to introduce some abstraction for I/O policies in
> the framework so that a given policy can be implemented and exposed only
> for the relevant transport (e.g., NVMe-only or SCSI-only), rather than
> requiring it to be supported by both?
I am just coming back to this now....
about the queue-depth iopolicy, why is depth per controller and not per
NS (path)? The following does not mention:
https://lore.kernel.org/linux-nvme/20240625122605.857462-3-jmeneghi@redhat.com/
Is the idea that some controller may have another NS attached and have
traffic there, and we need to account according to this also?
Thanks,
John
^ permalink raw reply
* Re: [PATCH] iov_iter: use kmemdup_array for dup_iter to harden against overflow
From: Christian Brauner @ 2026-04-14 9:46 UTC (permalink / raw)
To: Wang Haoran
Cc: Christian Brauner, linux-block, linux-fsdevel, linux-kernel, viro,
akpm
In-Reply-To: <20260413060655.1139141-1-haoranwangsec@gmail.com>
On Mon, 13 Apr 2026 14:06:55 +0800, Wang Haoran wrote:
> While auditing the Linux 7.0-rc2 kernel, I identified a potential security
> vulnerability in the iov_iter framework's memory allocation logic.
>
> The dup_iter() function, which is exported via EXPORT_SYMBOL, currently
> uses kmemdup() with a raw multiplication to allocate the duplicate iovec array:
>
> new->iov = kmemdup(from->iov, nr_segs * sizeof(struct iovec), gfp);
>
> [...]
Applied to the vfs-7.2.misc branch of the vfs/vfs.git tree.
Patches in the vfs-7.2.misc branch should appear in linux-next soon.
Please report any outstanding bugs that were missed during review in a
new review to the original patch series allowing us to drop it.
It's encouraged to provide Acked-bys and Reviewed-bys even though the
patch has now been applied. If possible patch trailers will be updated.
Note that commit hashes shown below are subject to change due to rebase,
trailer updates or similar. If in doubt, please check the listed branch.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
branch: vfs-7.2.misc
[1/1] iov_iter: use kmemdup_array for dup_iter to harden against overflow
https://git.kernel.org/vfs/vfs/c/ea5efcc5c589
^ permalink raw reply
* Re: [PATCH 6/6] zloop: remove irq-safe locking
From: Damien Le Moal @ 2026-04-14 9:30 UTC (permalink / raw)
To: Christoph Hellwig, Jens Axboe; +Cc: linux-block
In-Reply-To: <20260414081811.549755-7-hch@lst.de>
On 4/14/26 10:17, Christoph Hellwig wrote:
> All of zloop runs in user context, so drop the irq-safe locking.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Looks good.
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
--
Damien Le Moal
Western Digital Research
^ permalink raw reply
* Re: [PATCH 5/6] zloop: factor out zloop_mark_{full,empty} helpers
From: Damien Le Moal @ 2026-04-14 9:29 UTC (permalink / raw)
To: Christoph Hellwig, Jens Axboe; +Cc: linux-block
In-Reply-To: <20260414081811.549755-6-hch@lst.de>
On 4/14/26 10:17, Christoph Hellwig wrote:
> Move a few chunks of duplicated code into helpers.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Nice cleanup !
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
--
Damien Le Moal
Western Digital Research
^ permalink raw reply
* Re: [PATCH 4/6] zloop: set RQF_QUIET when completing requests on deleted devices
From: Damien Le Moal @ 2026-04-14 9:28 UTC (permalink / raw)
To: Christoph Hellwig, Jens Axboe; +Cc: linux-block
In-Reply-To: <20260414081811.549755-5-hch@lst.de>
On 4/14/26 10:17, Christoph Hellwig wrote:
> Reduce the dmesg spam for tests that involve device deletion.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Looks good.
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
--
Damien Le Moal
Western Digital Research
^ 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