* [PATCH v2] t10-pi: reduce ref tag code duplication
From: Caleb Sander Mateos @ 2026-04-15 21:08 UTC (permalink / raw)
To: Jens Axboe
Cc: linux-block, linux-kernel, Christoph Hellwig, Caleb Sander Mateos,
Anuj Gupta
t10_pi_ref_tag() and ext_pi_ref_tag() are identical except for the final
truncation of the ref tag to 32 or 48 bits. Factor out a helper
full_pi_ref_tag() to return the untruncated ref tag and use it in
t10_pi_ref_tag() and ext_pi_ref_tag().
Signed-off-by: Caleb Sander Mateos <csander@purestorage.com>
Reviewed-by: Anuj Gupta <anuj20.g@samsung.com>
---
v2:
- Move full_pi_ref_tag() earlier (Christoph)
- Use lower_32_bits() (Christoph)
include/linux/t10-pi.h | 25 +++++++++++++------------
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/include/linux/t10-pi.h b/include/linux/t10-pi.h
index 2c59fe3efcd4..b6c2496866ea 100644
--- a/include/linux/t10-pi.h
+++ b/include/linux/t10-pi.h
@@ -2,10 +2,11 @@
#ifndef _LINUX_T10_PI_H
#define _LINUX_T10_PI_H
#include <linux/types.h>
#include <linux/blk-mq.h>
+#include <linux/wordpart.h>
/*
* A T10 PI-capable target device can be formatted with different
* protection schemes. Currently 0 through 3 are defined:
*
@@ -23,10 +24,20 @@ enum t10_dif_type {
T10_PI_TYPE1_PROTECTION = 0x1,
T10_PI_TYPE2_PROTECTION = 0x2,
T10_PI_TYPE3_PROTECTION = 0x3,
};
+static inline u64 full_pi_ref_tag(const struct request *rq)
+{
+ unsigned int shift = ilog2(queue_logical_block_size(rq->q));
+
+ if (IS_ENABLED(CONFIG_BLK_DEV_INTEGRITY) &&
+ rq->q->limits.integrity.interval_exp)
+ shift = rq->q->limits.integrity.interval_exp;
+ return blk_rq_pos(rq) >> (shift - SECTOR_SHIFT);
+}
+
/*
* T10 Protection Information tuple.
*/
struct t10_pi_tuple {
__be16 guard_tag; /* Checksum */
@@ -37,16 +48,11 @@ struct t10_pi_tuple {
#define T10_PI_APP_ESCAPE cpu_to_be16(0xffff)
#define T10_PI_REF_ESCAPE cpu_to_be32(0xffffffff)
static inline u32 t10_pi_ref_tag(struct request *rq)
{
- unsigned int shift = ilog2(queue_logical_block_size(rq->q));
-
- if (IS_ENABLED(CONFIG_BLK_DEV_INTEGRITY) &&
- rq->q->limits.integrity.interval_exp)
- shift = rq->q->limits.integrity.interval_exp;
- return blk_rq_pos(rq) >> (shift - SECTOR_SHIFT) & 0xffffffff;
+ return lower_32_bits(full_pi_ref_tag(rq));
}
struct crc64_pi_tuple {
__be64 guard_tag;
__be16 app_tag;
@@ -62,14 +68,9 @@ static inline u64 lower_48_bits(u64 n)
return n & ((1ull << 48) - 1);
}
static inline u64 ext_pi_ref_tag(struct request *rq)
{
- unsigned int shift = ilog2(queue_logical_block_size(rq->q));
-
- if (IS_ENABLED(CONFIG_BLK_DEV_INTEGRITY) &&
- rq->q->limits.integrity.interval_exp)
- shift = rq->q->limits.integrity.interval_exp;
- return lower_48_bits(blk_rq_pos(rq) >> (shift - SECTOR_SHIFT));
+ return lower_48_bits(full_pi_ref_tag(rq));
}
#endif
--
2.45.2
^ permalink raw reply related
* Re: zloop fixes
From: Jens Axboe @ 2026-04-15 20:03 UTC (permalink / raw)
To: Damien Le Moal, Christoph Hellwig; +Cc: linux-block
In-Reply-To: <20260414081811.549755-1-hch@lst.de>
On Tue, 14 Apr 2026 10:17:45 +0200, Christoph Hellwig wrote:
> 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(-)
>
> [...]
Applied, thanks!
[1/6] zloop: fix write pointer calculation in zloop_forget_cache
commit: 32be3c01c3b8e948a4326ab7e76c1c63dd3e27bc
[2/6] zloop: use vfs_truncate
commit: 14e0077911e3d5e11e94417861e700cbb521a107
[3/6] zloop: improve the unaligned write pointer warning
commit: 6466b211f797ae88073b5826dd764a6a98b67edb
[4/6] zloop: set RQF_QUIET when completing requests on deleted devices
commit: 5b680d7afc4a2fefa0b4f584462c7540de56e2e4
[5/6] zloop: factor out zloop_mark_{full,empty} helpers
commit: ec5c045f6cc879637cb52c9902d5fb7d419bdf47
[6/6] zloop: remove irq-safe locking
commit: 64b437c4a96ae088d46c7d9930c35e77ee1b5b21
Best regards,
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH blktests] nvme/068: add a test for multipath delayed removal
From: Chaitanya Kulkarni @ 2026-04-15 17:58 UTC (permalink / raw)
To: John Garry, shinichiro.kawasaki@wdc.com,
linux-block@vger.kernel.org
Cc: linux-nvme@lists.infradead.org, nilay@linux.ibm.com
In-Reply-To: <20260415104111.1439459-1-john.g.garry@oracle.com>
John,
On 4/15/26 03:41, John Garry wrote:
> For NVMe multipath, the delayed removal feature allows the multipath
> gendisk to remain present when all available paths are gone. The purpose of
> this feature is to ensure that we keep the gendisk for intermittent path
> failures.
>
> The delayed removal works on a timer - when all paths are gone, a timer is
> kicked off; once the timer expires and no paths have returned, the gendisk
> is removed.
>
> When all paths are gone and the gendisk is still present, all reads and
> writes to the disk are queued. If a path returns before the timer
> expiration, the timer canceled and the queued IO is submitted;
> otherwise they fail when the timer expires.
>
> This testcase covers two scenarios in separate parts:
> a. test that IOs submitted after all paths are removed (and do not return)
> fail
> b. test that IOs submitted between all paths removed and a path
> returning succeed
>
> During the period of the timer being active, it must be ensured that the
> nvme-core module is not removed. Otherwise the driver may not be present
> to handle the timeout expiry. The kernel ensures this by taking a
> reference to the module. Ideally, we would try to remove the module during
> this test to prove that this is not possible (and the kernel behaves as
> expected), but that module will probably not be removable anyway due to
> many references. To test this feature, check that the refcount of the
> nvme-core module is incremented when the delayed timer is active.
>
> Signed-off-by: John Garry<john.g.garry@oracle.com>
Thanks you so much for this testcase.
I've failed to add tests in this areas but this will be absolutely
helpful to have it in regular testing.
Looks good.
Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
-ck
^ permalink raw reply
* Re: [REGRESSION][BISECTED] Spurious raid1 device failure triggered by qemu direct IO on 6.18+
From: Keith Busch @ 2026-04-15 15:52 UTC (permalink / raw)
To: Tomás Trnka; +Cc: Jens Axboe, linux-kernel, regressions, linux-block
In-Reply-To: <ad-sprBWPA20iola@kbusch-mbp>
On Wed, Apr 15, 2026 at 09:20:06AM -0600, Keith Busch wrote:
> On Wed, Apr 15, 2026 at 02:18:59PM +0200, Tomás Trnka wrote:
> > Since 6.18, booting a VM that is backed by a raid1 LVM LV makes that LV
> > immediately eject one of the devices. This is apparently because of a direct
> > IO read by QEMU failing. I have bisected the issue to the following commit and
> > confirmed that reverting that commit (plus dependencies
> > 9eab1d4e0d15b633adc170c458c51e8be3b1c553 and
> > b475272f03ca5d0c437c8f899ff229b21010ec83) on top of 6.19.11 fixes the issue.
> >
> > commit 5ff3f74e145adc79b49668adb8de276446acf6be
> > Author: Keith Busch <kbusch@kernel.org>
> > Date: Wed Aug 27 07:12:54 2025 -0700
> >
> > block: simplify direct io validity check
> >
> > The block layer checks all the segments for validity later, so no need
> > for an early check. Just reduce it to a simple position and total length
> > check, and defer the more invasive segment checks to the block layer.
> >
> > Signed-off-by: Keith Busch <kbusch@kernel.org>
> > Reviewed-by: Hannes Reinecke <hare@suse.de>
> > Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
> > Reviewed-by: Christoph Hellwig <hch@lst.de>
> > Signed-off-by: Jens Axboe <axboe@kernel.dk>
> >
> > The issue looks like this:
> >
> > md/raid1:mdX: dm-17: rescheduling sector 0
> > md/raid1:mdX: redirecting sector 0 to other mirror: dm-17
> > (snipped 9 repeats of the preceding two lines)
> > md/raid1:mdX: dm-17: Raid device exceeded read_error threshold [cur 21:max 20]
> > md/raid1:mdX: dm-17: Failing raid device
> > md/raid1:mdX: Disk failure on dm-17, disabling device.
> > md/raid1:mdX: Operation continuing on 1 devices.
> >
> > There's absolutely nothing wrong with the HW, the issue persists even when I
> > move the mirrors to a different pair of PVs (SAS HDD vs SATA SSD).
>
> Thanks for the notice and the logs. Sounds likek something is getting
> sent to the block layer that can't form a viable IO. The commit you
> identified should have still error'ed though, just much earlier in the
> call stack.
>
> Anyway, I'll take a look if there's something I missed handling with the
> stacking setup you're describing.
I think the block layer is working as designed. The problem you're
seeing is likely related to how QEMU probes direct-io limits instead of
doing proper stat/statx type checks. During its probing, it tries
various sizes and offsets, and some of these is invalid. The kernel code
previously still returned the EINVAL error, but it was before entering
the dm raid layer, and qemu reacted by changing its assumptions.
The new kernel code eventually returns the same error, but on the other
side of dm raid stack, and unfortunately dm raid treats this as a device
failure rather than a user error as intended.
Suggest the stacking layers shouldn't consider BLK_STS_INVAL to be a
device error or retryable.
---
diff --git a/drivers/md/raid1-10.c b/drivers/md/raid1-10.c
index c33099925f230..cf1c25f290f36 100644
--- a/drivers/md/raid1-10.c
+++ b/drivers/md/raid1-10.c
@@ -293,8 +293,16 @@ static inline bool raid1_should_read_first(struct mddev *mddev,
* bio with REQ_RAHEAD or REQ_NOWAIT can fail at anytime, before such IO is
* submitted to the underlying disks, hence don't record badblocks or retry
* in this case.
+ *
+ * BLK_STS_INVAL means the request itself is malformed (e.g. unaligned
+ * buffers that violate DMA constraints). Retrying on another mirror will
+ * fail the same way, and counting it against the device is wrong.
*/
static inline bool raid1_should_handle_error(struct bio *bio)
{
- return !(bio->bi_opf & (REQ_RAHEAD | REQ_NOWAIT));
+ if (bio->bi_opf & (REQ_RAHEAD | REQ_NOWAIT))
+ return false;
+ if (bio->bi_status == BLK_STS_INVAL)
+ return false;
+ return true;
}
--
^ permalink raw reply related
* Re: [REGRESSION][BISECTED] Spurious raid1 device failure triggered by qemu direct IO on 6.18+
From: Keith Busch @ 2026-04-15 15:20 UTC (permalink / raw)
To: Tomás Trnka; +Cc: Jens Axboe, linux-kernel, regressions, linux-block
In-Reply-To: <2982107.4sosBPzcNG@electra>
On Wed, Apr 15, 2026 at 02:18:59PM +0200, Tomás Trnka wrote:
> Since 6.18, booting a VM that is backed by a raid1 LVM LV makes that LV
> immediately eject one of the devices. This is apparently because of a direct
> IO read by QEMU failing. I have bisected the issue to the following commit and
> confirmed that reverting that commit (plus dependencies
> 9eab1d4e0d15b633adc170c458c51e8be3b1c553 and
> b475272f03ca5d0c437c8f899ff229b21010ec83) on top of 6.19.11 fixes the issue.
>
> commit 5ff3f74e145adc79b49668adb8de276446acf6be
> Author: Keith Busch <kbusch@kernel.org>
> Date: Wed Aug 27 07:12:54 2025 -0700
>
> block: simplify direct io validity check
>
> The block layer checks all the segments for validity later, so no need
> for an early check. Just reduce it to a simple position and total length
> check, and defer the more invasive segment checks to the block layer.
>
> Signed-off-by: Keith Busch <kbusch@kernel.org>
> Reviewed-by: Hannes Reinecke <hare@suse.de>
> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Jens Axboe <axboe@kernel.dk>
>
> The issue looks like this:
>
> md/raid1:mdX: dm-17: rescheduling sector 0
> md/raid1:mdX: redirecting sector 0 to other mirror: dm-17
> (snipped 9 repeats of the preceding two lines)
> md/raid1:mdX: dm-17: Raid device exceeded read_error threshold [cur 21:max 20]
> md/raid1:mdX: dm-17: Failing raid device
> md/raid1:mdX: Disk failure on dm-17, disabling device.
> md/raid1:mdX: Operation continuing on 1 devices.
>
> There's absolutely nothing wrong with the HW, the issue persists even when I
> move the mirrors to a different pair of PVs (SAS HDD vs SATA SSD).
Thanks for the notice and the logs. Sounds likek something is getting
sent to the block layer that can't form a viable IO. The commit you
identified should have still error'ed though, just much earlier in the
call stack.
Anyway, I'll take a look if there's something I missed handling with the
stacking setup you're describing.
^ permalink raw reply
* [PATCH v2] floppy: fix reference leak on platform_device_register() failure
From: Guangshuo Li @ 2026-04-15 14:57 UTC (permalink / raw)
To: Denis Efremov, Jens Axboe, Greg Kroah-Hartman, linux-block,
linux-kernel
Cc: Guangshuo Li, stable
When platform_device_register() fails in do_floppy_init(), the embedded
struct device in floppy_device[drive] has already been initialized by
device_initialize(), but the failure path jumps to out_remove_drives
without dropping the device reference for the current drive.
Previously registered floppy devices are cleaned up in out_remove_drives,
but the device for the drive that fails registration is not, leading to
a reference leak.
The issue was identified by a static analysis tool I developed and
confirmed by manual review. Fix this by calling put_device() for the
current floppy device before jumping to the common cleanup path.
Fixes: 94fd0db7bfb4a ("[PATCH] Floppy: Add cmos attribute to floppy driver")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
v2:
- Replace put_device() with platform_device_put() in the
platform_device_register() failure path
- Fix the device_add_disk() failure path by unregistering the current
platform device before jumping to out_remove_drives
drivers/block/floppy.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
index 92e446a64371..461e14d19422 100644
--- a/drivers/block/floppy.c
+++ b/drivers/block/floppy.c
@@ -4724,15 +4724,19 @@ static int __init do_floppy_init(void)
floppy_device[drive].dev.groups = floppy_dev_groups;
err = platform_device_register(&floppy_device[drive]);
- if (err)
+ if (err) {
+ platform_device_put(&floppy_device[drive]);
goto out_remove_drives;
-
+ }
registered[drive] = true;
err = device_add_disk(&floppy_device[drive].dev,
disks[drive][0], NULL);
- if (err)
+ if (err) {
+ platform_device_unregister(&floppy_device[drive]);
+ registered[drive] = false;
goto out_remove_drives;
+ }
}
return 0;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v10 13/13] docs: add io_queue flag to isolcpus
From: Aaron Tomlin @ 2026-04-15 14:56 UTC (permalink / raw)
To: Ming Lei
Cc: Ming Lei, 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, bigeasy, yphbchou0911, wagi, frederic,
longman, chenridong, hare, kch, steve, sean, chjohnst, neelx,
mproche, linux-block, linux-kernel, virtualization, linux-nvme,
linux-scsi, megaraidlinux.pdl, mpi3mr-linuxdrv.pdl,
MPT-FusionLinux.pdl
In-Reply-To: <ad0Hk48y5JEeMlFk@fedora>
[-- Attachment #1: Type: text/plain, Size: 690 bytes --]
On Mon, Apr 13, 2026 at 11:11:15PM +0800, Ming Lei wrote:
> But typical applications aren't supposed to submit IOs from these
> isolated CPUs, so in reality, it isn't a big deal.
Hi Ming,
While that may be true for general-purpose workloads, it is a fundamentally
incorrect assumption for the highly specialised environments that actually
rely on strict CPU isolation, such as High-Frequency Trading (HFT).
The requirement in these strict environments is not that the isolated CPU
performs zero I/O. Rather, the requirement is that the isolated CPU must be
shielded from the unpredictable latency of the hardware completion
interrupt.
Kind regards,
--
Aaron Tomlin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v10 13/13] docs: add io_queue flag to isolcpus
From: Aaron Tomlin @ 2026-04-15 14:47 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Ming Lei, Ming Lei, 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, hare, kch, steve, sean, chjohnst,
neelx, mproche, linux-block, linux-kernel, virtualization,
linux-nvme, linux-scsi, megaraidlinux.pdl, mpi3mr-linuxdrv.pdl,
MPT-FusionLinux.pdl
In-Reply-To: <20260415083458.UD3cF5IQ@linutronix.de>
[-- Attachment #1: Type: text/plain, Size: 2588 bytes --]
On Wed, Apr 15, 2026 at 10:34:58AM +0200, Sebastian Andrzej Siewior wrote:
> On 2026-04-13 23:11:15 [+0800], Ming Lei wrote:
> > > > What matters is that IO won't interrupt isolated CPU.
> > >
> > > The isolcpus=managed_irq acts as a "best effort" avoidance algorithm rather
> > > than a strict, unbreakable constraint. This is indicated in the proposed
> > > changes to Documentation/core-api/irq/managed_irq.rst [1].
> >
> > Yes, it is "best effort", but isolated cpu is only take as effective CPU
> > for the hw queue's irq iff all others are offline. Which is just fine for typical
> > use cases, in which IO isn't submitted from isolated CPU.
>
> Couldn't we tackle this by limiting the number of managed interrupts the
> device asks for and then limiting the CPUs it could be bound to?
>
> So if have house keeping CPUs 0/1 and isolated 2-63 then managed_irq= is
> futile since it use 64 interrupts and map each to one CPU. Even if the
> device supports less it would map them evenly across available CPUs.
>
> If the user wishes to initiate I/O from all CPUs but not be bother by
> interrupts we could limit the device to ask for 2 interrupts instead of
> 64 (with the consequence of more queue sharing) and then limit those two
> interrupts to CPU 0 and 1 instead to CPU 0-31 and 32-63 like it would be
> now the case.
>
> Wouldn't that be what the io_queue flag tries to do?
>
Hi Sebastian,
Indeed, you are spot on.
What you have described is precisely the architectural mechanism that this
patchset implements to resolve the issue:
1. Rather than permitting the device driver to blindly allocate 64
queues (and 64 MSI-X vectors) for a 64-core system, the
"isolcpus=io_queue" intercepts this at the block layer. It
throttles the hardware queue allocation to match the number of
online housekeeping CPUs (2 queues in your example). As you rightly
noted, this results in the isolated CPUs sharing those submission
queues.
2. Once those two queues have been allocated, the new
irq_spread_hk_filter() strictly confines their hardware completion
interrupts to CPUs 0 and 1.
By structurally enforcing both of these constraints at initialisation,
"isolcpus=io_queue" entirely prevents the vector exhaustion observed on
large topologies. Furthermore, it provides an absolute guarantee that
hardware completion interrupts will never be routed to the isolated CPUs,
even when an application submits I/O from them.
Kind regards,
--
Aaron Tomlin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 4/8] FOLD: block: change the defer in task context interface to be procedural
From: Matthew Wilcox @ 2026-04-15 14:30 UTC (permalink / raw)
To: Christoph Hellwig
Cc: 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: <20260415054407.GA26893@lst.de>
On Wed, Apr 15, 2026 at 07:44:07AM +0200, Christoph Hellwig wrote:
> 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.
I want to make all writebacks complete in task context so we can change
the i_pages.xa_lock from being irq-disabling to a plain spinlock.
^ permalink raw reply
* Re: [PATCH] floppy: fix reference leak on platform_device_register() failure
From: Denis Efremov (Oracle) @ 2026-04-15 14:15 UTC (permalink / raw)
To: Guangshuo Li
Cc: Jens Axboe, Greg Kroah-Hartman, linux-block, linux-kernel, stable
In-Reply-To: <CANUHTR9MQ8GGpgtGDgRCmjQL_D0jW4E-2OER4Q784xbGd+nJSw@mail.gmail.com>
On 15/04/2026 17:54, Guangshuo Li wrote:
> Hi Denis,
>
> Thank you for the review.
>
> On Wed, 15 Apr 2026 at 21:00, Denis Efremov (Oracle) <efremov@linux.com> wrote:
>>
>> 1. Let's use platform_device_put()
>>
>>> goto out_remove_drives;
>>> + }
>>>
>>> registered[drive] = true;
>>>
>
> My understanding is:
>
> For the platform_device_register() failure case, we should use
> platform_device_put() instead of put_device(), so the failure path
> would look like:
>
> err = platform_device_register(&floppy_device[drive]);
> if (err) {
> platform_device_put(&floppy_device[drive]);
> goto out_remove_drives;
> }
> registered[drive] = true;
Yes, correct.
>
>> err = device_add_disk(&floppy_device[drive].dev,
>> disks[drive][0], NULL);
>> if (err)
>> goto out_remove_drives;
>>
>> 2. We also need to fix this case.
>>
>> platform_device_unregister()
>> registered[drive] = false;
>> goto ...
>>
>> Thanks,
>> Denis
> We also need to handle the device_add_disk() failure case for the
> current drive, since out_remove_drives only cleans up previously
> registered drives. So this path should explicitly unregister the
> current platform device before jumping to the common cleanup path, for
> example:
>
> err = device_add_disk(&floppy_device[drive].dev, disks[drive][0], NULL);
> if (err) {
> platform_device_unregister(&floppy_device[drive]);
> registered[drive] = false;
> goto out_remove_drives;
> }
>
>
> Is my understanding correct? If so, I will prepare and send a v2
> following this pattern.
Yes, correct. Please, send v2.
>
> Thanks,
> Guangshuo
^ permalink raw reply
* Re: [PATCH] floppy: fix reference leak on platform_device_register() failure
From: Guangshuo Li @ 2026-04-15 13:54 UTC (permalink / raw)
To: efremov; +Cc: Jens Axboe, Greg Kroah-Hartman, linux-block, linux-kernel, stable
In-Reply-To: <8afc6b6b-399e-4f77-82e8-3c0e717f765e@linux.com>
Hi Denis,
Thank you for the review.
On Wed, 15 Apr 2026 at 21:00, Denis Efremov (Oracle) <efremov@linux.com> wrote:
>
> 1. Let's use platform_device_put()
>
> > goto out_remove_drives;
> > + }
> >
> > registered[drive] = true;
> >
My understanding is:
For the platform_device_register() failure case, we should use
platform_device_put() instead of put_device(), so the failure path
would look like:
err = platform_device_register(&floppy_device[drive]);
if (err) {
platform_device_put(&floppy_device[drive]);
goto out_remove_drives;
}
registered[drive] = true;
> err = device_add_disk(&floppy_device[drive].dev,
> disks[drive][0], NULL);
> if (err)
> goto out_remove_drives;
>
> 2. We also need to fix this case.
>
> platform_device_unregister()
> registered[drive] = false;
> goto ...
>
> Thanks,
> Denis
We also need to handle the device_add_disk() failure case for the
current drive, since out_remove_drives only cleans up previously
registered drives. So this path should explicitly unregister the
current platform device before jumping to the common cleanup path, for
example:
err = device_add_disk(&floppy_device[drive].dev, disks[drive][0], NULL);
if (err) {
platform_device_unregister(&floppy_device[drive]);
registered[drive] = false;
goto out_remove_drives;
}
Is my understanding correct? If so, I will prepare and send a v2
following this pattern.
Thanks,
Guangshuo
^ permalink raw reply
* Re: [PATCH] floppy: fix reference leak on platform_device_register() failure
From: Denis Efremov (Oracle) @ 2026-04-15 13:00 UTC (permalink / raw)
To: Guangshuo Li, Jens Axboe, Greg Kroah-Hartman, linux-block,
linux-kernel
Cc: stable
In-Reply-To: <20260413153114.3040093-1-lgs201920130244@gmail.com>
Hello,
Thank you for the patch,
On 13/04/2026 19:31, Guangshuo Li wrote:
> When platform_device_register() fails in do_floppy_init(), the embedded
> struct device in floppy_device[drive] has already been initialized by
> device_initialize(), but the failure path jumps to out_remove_drives
> without dropping the device reference for the current drive.
>
> Previously registered floppy devices are cleaned up in out_remove_drives,
> but the device for the drive that fails registration is not, leading to
> a reference leak.
>
> The issue was identified by a static analysis tool I developed and
> confirmed by manual review. Fix this by calling put_device() for the
> current floppy device before jumping to the common cleanup path.
>
> Fixes: 94fd0db7bfb4a ("[PATCH] Floppy: Add cmos attribute to floppy driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> ---
> drivers/block/floppy.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
> index c28786e0fe1c..d9afe495d5c2 100644
> --- a/drivers/block/floppy.c
> +++ b/drivers/block/floppy.c
> @@ -4724,8 +4724,10 @@ static int __init do_floppy_init(void)
> floppy_device[drive].dev.groups = floppy_dev_groups;
>
> err = platform_device_register(&floppy_device[drive]);
> - if (err)
> + if (err) {
> + put_device(&floppy_device[drive].dev);
1. Let's use platform_device_put()
> goto out_remove_drives;
> + }
>
> registered[drive] = true;
>
err = device_add_disk(&floppy_device[drive].dev,
disks[drive][0], NULL);
if (err)
goto out_remove_drives;
2. We also need to fix this case.
platform_device_unregister()
registered[drive] = false;
goto ...
Thanks,
Denis
^ permalink raw reply
* Re: [PATCH 8/8] RFC: use a TASK_FIFO kthread for read completion support
From: Sandeep Dhavale @ 2026-04-15 12:49 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
In-Reply-To: <a7a74185-df02-4906-a0ec-f87e2394aa5f@linux.alibaba.com>
> 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, this was the reasoning when I narrowed it down to per-CPU
kthread approach. Patch has helped reduce app launch times which
has a direct user impact.
>
> But anyway, I think nice -19 can be evaluated if Sandeep have time,
> but such nice value should be set by the filesystem instead of
> the userspace since the reason is as above.
>
I will find some time to re-do this again, including setting nice -19.
-Sandeep.
^ permalink raw reply
* [REGRESSION][BISECTED] Spurious raid1 device failure triggered by qemu direct IO on 6.18+
From: Tomáš Trnka @ 2026-04-15 12:18 UTC (permalink / raw)
To: Jens Axboe, linux-kernel; +Cc: regressions, linux-block, Keith Busch
Since 6.18, booting a VM that is backed by a raid1 LVM LV makes that LV
immediately eject one of the devices. This is apparently because of a direct
IO read by QEMU failing. I have bisected the issue to the following commit and
confirmed that reverting that commit (plus dependencies
9eab1d4e0d15b633adc170c458c51e8be3b1c553 and
b475272f03ca5d0c437c8f899ff229b21010ec83) on top of 6.19.11 fixes the issue.
commit 5ff3f74e145adc79b49668adb8de276446acf6be
Author: Keith Busch <kbusch@kernel.org>
Date: Wed Aug 27 07:12:54 2025 -0700
block: simplify direct io validity check
The block layer checks all the segments for validity later, so no need
for an early check. Just reduce it to a simple position and total length
check, and defer the more invasive segment checks to the block layer.
Signed-off-by: Keith Busch <kbusch@kernel.org>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
The issue looks like this:
md/raid1:mdX: dm-17: rescheduling sector 0
md/raid1:mdX: redirecting sector 0 to other mirror: dm-17
(snipped 9 repeats of the preceding two lines)
md/raid1:mdX: dm-17: Raid device exceeded read_error threshold [cur 21:max 20]
md/raid1:mdX: dm-17: Failing raid device
md/raid1:mdX: Disk failure on dm-17, disabling device.
md/raid1:mdX: Operation continuing on 1 devices.
There's absolutely nothing wrong with the HW, the issue persists even when I
move the mirrors to a different pair of PVs (SAS HDD vs SATA SSD).
The following command is enough to trigger the issue:
/usr/bin/qemu-system-x86_64 -blockdev '{"driver":"host_device","filename":"/
dev/vg_mintaka/lv_test","aio":"native","node-name":"libvirt-1-storage","read-
only":false,"discard":"unmap","cache":{"direct":true,"no-flush":false}}'
According to blktrace below, this seems to be an ordinary direct IO read of
sectors 0-7, but I can't reproduce the issue emulating such a read with dd.
The beginning of blktrace for dm-20 (mirror LV):
252,20 0 3 0.050436097 17815 Q RS 0 + 8 [qemu-system-x86]
252,20 4 1 0.053590884 17179 C RS 0 + 8 [65531]
252,20 9 1 0.071942534 17843 Q RS 0 + 1 [worker]
252,20 10 1 0.077792770 10803 C RS 0 + 1 [0]
for dm-17 (one of the legs of the raid1 mirror):
252,17 0 3 0.050441207 17815 Q RS 0 + 8 [qemu-system-x86]
252,17 0 4 0.050465318 17815 C RS 0 + 8 [65514]
252,17 4 1 0.050491948 17179 Q RS 0 + 8 [mdX_raid1]
252,17 12 1 0.050695772 12662 C RS 0 + 8 [0]
for sda1 that holds that leg (raid1 LV on dm-crypt on sda1; bfq messages
snipped):
8,0 0 7 0.050453828 17815 A RS 902334464 + 8 <- (252,5)
902301696
8,0 0 8 0.050453988 17815 A RS 902336512 + 8 <- (8,1)
902334464
8,1 0 9 0.050454158 17815 Q RS 902336512 + 8 [qemu-system-
x86]
8,1 0 10 0.050455058 17815 C RS 902336512 + 8 [65514]
8,0 4 1 0.050490699 17179 A RS 902334464 + 8 <- (252,5)
902301696
8,0 4 2 0.050490849 17179 A RS 902336512 + 8 <- (8,1)
902334464
8,1 4 3 0.050491009 17179 Q RS 902336512 + 8 [mdX_raid1]
8,1 4 4 0.050498089 17179 G RS 902336512 + 8 [mdX_raid1]
8,1 4 5 0.050500129 17179 P N [mdX_raid1]
8,1 4 6 0.050500939 17179 UT N [mdX_raid1] 1
8,1 4 7 0.050507439 17179 I RS 902336512 + 8 [mdX_raid1]
8,1 4 8 0.050531999 387 D RS 902336512 + 8 [kworker/4:1H]
8,1 15 1 0.050668902 0 C RS 902336512 + 8 [0]
for sdb1 (backing the other leg of the mirror):
8,16 4 1 0.053558754 17179 A RS 902334464 + 8 <- (252,4)
902301696
8,16 4 2 0.053558884 17179 A RS 902336512 + 8 <- (8,17)
902334464
8,17 4 3 0.053559024 17179 Q RS 902336512 + 8 [mdX_raid1]
8,17 4 4 0.053559364 17179 C RS 902336512 + 8 [65514]
8,17 4 0 0.053570484 17179 1,0 m N bfq [bfq_limit_depth]
wr_busy 0 sync 1 depth 48
8,17 4 5 0.053578104 387 D FN [kworker/4:1H]
8,17 15 1 0.053647696 17192 C FN 0 [0]
8,17 15 2 0.053815039 567 D FN [kworker/15:1H]
8,17 15 3 0.053872560 17192 C FN 0 [0]
Full logs can be downloaded from:
https://is.muni.cz/de/ttrnka/qemu-dio-raid1-fail/dmesg.log
https://is.muni.cz/de/ttrnka/qemu-dio-raid1-fail/mapped-devs.lst
https://is.muni.cz/de/ttrnka/qemu-dio-raid1-fail/blktrace.tar.gz
lsblk output (from a different boot, minors might not match mapped-devs.lst):
https://is.muni.cz/de/ttrnka/qemu-dio-raid1-fail/lsblk-t.out
https://is.muni.cz/de/ttrnka/qemu-dio-raid1-fail/lsblk.out
I can share any other info or logs, test patches, or poke around with ftrace
or systemtap as needed.
#regzbot introduced: 5ff3f74e145adc79b49668adb8de276446acf6be
Best regards,
Tomáš
--
Tomáš Trnka
Software for Chemistry & Materials B.V.
De Boelelaan 1109
1081 HV Amsterdam, The Netherlands
https://www.scm.com
^ permalink raw reply
* [PATCH] zram: add accounting for incompressible pages
From: qiwu.chen @ 2026-04-15 10:43 UTC (permalink / raw)
To: senozhatsky, axboe; +Cc: linux-block, qiwu.chen
1. Rename write_incompressible_page to write_huge_page since huge page
could be recompressed with secondary algorithms.
2. Similar to huge page, add incompressible_pages accounting for current
incompressible pages, and incompressible_pages_since accounting for
incompressible pages since zram set up. The accounting value can be showed
by mm_stat.
Signed-off-by: qiwu.chen <qiwu.chen@transsion.com>
---
drivers/block/zram/zram_drv.c | 21 ++++++++++++++++-----
drivers/block/zram/zram_drv.h | 2 ++
2 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index af679375b193..f16d52c4ed79 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -948,6 +948,8 @@ static int zram_writeback_complete(struct zram *zram, struct zram_wb_req *req)
clear_slot_flag(zram, index, ZRAM_IDLE);
if (test_slot_flag(zram, index, ZRAM_HUGE))
atomic64_dec(&zram->stats.huge_pages);
+ if (test_slot_flag(zram, index, ZRAM_INCOMPRESSIBLE))
+ atomic64_dec(&zram->stats.incompressible_pages);
atomic64_sub(get_slot_size(zram, index), &zram->stats.compr_data_size);
zs_free(zram->mem_pool, get_slot_handle(zram, index));
set_slot_handle(zram, index, req->blk_idx);
@@ -1908,7 +1910,7 @@ static ssize_t mm_stat_show(struct device *dev, struct device_attribute *attr,
max_used = atomic_long_read(&zram->stats.max_used_pages);
ret = sysfs_emit(buf,
- "%8llu %8llu %8llu %8lu %8ld %8llu %8lu %8llu %8llu\n",
+ "%8llu %8llu %8llu %8lu %8ld %8llu %8lu %8llu %8llu %8llu %8llu\n",
orig_size << PAGE_SHIFT,
(u64)atomic64_read(&zram->stats.compr_data_size),
mem_used << PAGE_SHIFT,
@@ -1917,7 +1919,9 @@ static ssize_t mm_stat_show(struct device *dev, struct device_attribute *attr,
(u64)atomic64_read(&zram->stats.same_pages),
atomic_long_read(&pool_stats.pages_compacted),
(u64)atomic64_read(&zram->stats.huge_pages),
- (u64)atomic64_read(&zram->stats.huge_pages_since));
+ (u64)atomic64_read(&zram->stats.huge_pages_since),
+ (u64)atomic64_read(&zram->stats.incompressible_pages),
+ (u64)atomic64_read(&zram->stats.incompressible_pages_since));
return ret;
}
@@ -1989,10 +1993,15 @@ static void slot_free(struct zram *zram, u32 index)
#endif
clear_slot_flag(zram, index, ZRAM_IDLE);
- clear_slot_flag(zram, index, ZRAM_INCOMPRESSIBLE);
clear_slot_flag(zram, index, ZRAM_PP_SLOT);
set_slot_comp_priority(zram, index, 0);
+ if (test_slot_flag(zram, index, ZRAM_INCOMPRESSIBLE)) {
+ if (!test_slot_flag(zram, index, ZRAM_WB))
+ atomic64_dec(&zram->stats.incompressible_pages);
+ clear_slot_flag(zram, index, ZRAM_INCOMPRESSIBLE);
+ }
+
if (test_slot_flag(zram, index, ZRAM_HUGE)) {
/*
* Writeback completion decrements ->huge_pages but keeps
@@ -2197,7 +2206,7 @@ static int write_same_filled_page(struct zram *zram, unsigned long fill,
return 0;
}
-static int write_incompressible_page(struct zram *zram, struct page *page,
+static int write_huge_page(struct zram *zram, struct page *page,
u32 index)
{
unsigned long handle;
@@ -2268,7 +2277,7 @@ static int zram_write_page(struct zram *zram, struct page *page, u32 index)
if (comp_len >= huge_class_size) {
zcomp_stream_put(zstrm);
- return write_incompressible_page(zram, page, index);
+ return write_huge_page(zram, page, index);
}
handle = zs_malloc(zram->mem_pool, comp_len,
@@ -2487,6 +2496,8 @@ static int recompress_slot(struct zram *zram, u32 index, struct page *page,
if (prio < zram->num_active_comps)
return 0;
set_slot_flag(zram, index, ZRAM_INCOMPRESSIBLE);
+ atomic64_inc(&zram->stats.incompressible_pages);
+ atomic64_inc(&zram->stats.incompressible_pages_since);
return 0;
}
diff --git a/drivers/block/zram/zram_drv.h b/drivers/block/zram/zram_drv.h
index f0de8f8218f5..cec84638f626 100644
--- a/drivers/block/zram/zram_drv.h
+++ b/drivers/block/zram/zram_drv.h
@@ -85,6 +85,8 @@ struct zram_stats {
atomic64_t same_pages; /* no. of same element filled pages */
atomic64_t huge_pages; /* no. of huge pages */
atomic64_t huge_pages_since; /* no. of huge pages since zram set up */
+ atomic64_t incompressible_pages; /* no. of incompressible pages */
+ atomic64_t incompressible_pages_since; /* no. of incompressible pages since zram set up */
atomic64_t pages_stored; /* no. of pages currently stored */
atomic_long_t max_used_pages; /* no. of maximum pages stored */
atomic64_t miss_free; /* no. of missed free */
--
2.25.1
^ permalink raw reply related
* [PATCH blktests] nvme/068: add a test for multipath delayed removal
From: John Garry @ 2026-04-15 10:41 UTC (permalink / raw)
To: shinichiro.kawasaki, linux-block; +Cc: linux-nvme, nilay, John Garry
For NVMe multipath, the delayed removal feature allows the multipath
gendisk to remain present when all available paths are gone. The purpose of
this feature is to ensure that we keep the gendisk for intermittent path
failures.
The delayed removal works on a timer - when all paths are gone, a timer is
kicked off; once the timer expires and no paths have returned, the gendisk
is removed.
When all paths are gone and the gendisk is still present, all reads and
writes to the disk are queued. If a path returns before the timer
expiration, the timer canceled and the queued IO is submitted;
otherwise they fail when the timer expires.
This testcase covers two scenarios in separate parts:
a. test that IOs submitted after all paths are removed (and do not return)
fail
b. test that IOs submitted between all paths removed and a path
returning succeed
During the period of the timer being active, it must be ensured that the
nvme-core module is not removed. Otherwise the driver may not be present
to handle the timeout expiry. The kernel ensures this by taking a
reference to the module. Ideally, we would try to remove the module during
this test to prove that this is not possible (and the kernel behaves as
expected), but that module will probably not be removable anyway due to
many references. To test this feature, check that the refcount of the
nvme-core module is incremented when the delayed timer is active.
Signed-off-by: John Garry <john.g.garry@oracle.com>
diff --git a/common/rc b/common/rc
index 5350057..6eae0e2 100644
--- a/common/rc
+++ b/common/rc
@@ -117,6 +117,16 @@ _module_not_in_use() {
fi
}
+_module_use_count() {
+ local refcnt
+ if [ -f "/sys/module/$1/refcnt" ]; then
+ refcnt="$(cat /sys/module/"$1"/refcnt)"
+ echo $refcnt
+ return
+ fi
+ echo ""
+}
+
_have_module_param() {
_have_driver "$1" || return
diff --git a/tests/nvme/068 b/tests/nvme/068
new file mode 100644
index 0000000..e06fd6b
--- /dev/null
+++ b/tests/nvme/068
@@ -0,0 +1,118 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-3.0+
+# Copyright (C) 2026 John Garry
+#
+# Test NVMe multipath delayed removal works as expected
+
+. tests/nvme/rc
+. common/xfs
+
+DESCRIPTION="NVMe multipath delayed removal test"
+QUICK=1
+
+requires() {
+ _nvme_requires
+ _have_loop
+ _have_module_param_value nvme_core multipath Y
+ _require_nvme_trtype_is_fabrics
+}
+
+set_conditions() {
+ _set_nvme_trtype "$@"
+}
+
+_delayed_nvme_reconnect_ctrl() {
+ sleep 5
+ _nvme_connect_subsys
+}
+
+test() {
+ echo "Running ${TEST_NAME}"
+
+ _setup_nvmet
+
+ local nvmedev
+ local ns
+ local bytes_written
+ local refcnt_orig
+ local refcnt
+ _nvmet_target_setup
+
+ _nvme_connect_subsys
+
+ # Part a: Prove that writes fail when no path returns. Any reads or
+ # writes are queued during the delayed removal period. If no
+ # paths return before the timer expires, then those IOs should
+ # fail.
+ # During the delayed removal period, ensure that the module
+ # refcnt is incremented, to prove that we cannot remove the
+ # driver during this period.
+ nvmedev=$(_find_nvme_dev "${def_subsysnqn}")
+ ns=$(_find_nvme_ns "${def_subsys_uuid}")
+ refcnt=$(_module_use_count nvme_core)
+ echo 10 > "/sys/block/"$ns"/delayed_removal_secs"
+ refcnt_orig=$(_module_use_count nvme_core)
+ _nvme_disconnect_ctrl "${nvmedev}"
+ sleep 1
+ ns=$(_find_nvme_ns "${def_subsys_uuid}")
+ if [[ "${ns}" = "" ]]; then
+ echo "could not find ns after disconnect"
+ fi
+ refcnt=$(_module_use_count nvme_core)
+ if [ "$refcnt" != "" ] && [ "$refcnt" -le "$refcnt_orig" ]; then
+ echo "module refcount did not increase"
+ fi
+ bytes_written=$(run_xfs_io_pwritev2 /dev/"$ns" 4096)
+ if [ "$bytes_written" == 4096 ]; then
+ echo "wrote successfully after disconnect"
+ fi
+ sleep 10
+ ns=$(_find_nvme_ns "${def_subsys_uuid}")
+ if [[ !"${ns}" = "" ]]; then
+ echo "found ns after delayed removal"
+ fi
+ refcnt=$(_module_use_count nvme_core)
+ if [ "$refcnt" != "" ] && [ "$refcnt" -ne "$refcnt_orig" ]; then
+ echo "module refcount not as original"
+ fi
+
+ # Part b: Ensure writes for an intermittent disconnect are successful.
+ # During an intermittent disconnect, any reads or writes
+ # queued should succeed after a path returns.
+ # Also ensure module refcount behaviour is as expected, as
+ # above.
+ _nvme_connect_subsys
+
+ nvmedev=$(_find_nvme_dev "${def_subsysnqn}")
+ ns=$(_find_nvme_ns "${def_subsys_uuid}")
+ refcnt_orig=$(_module_use_count nvme_core)
+ echo 10 > "/sys/block/"$ns"/delayed_removal_secs"
+ _nvme_disconnect_ctrl "${nvmedev}"
+ sleep 1
+ ns=$(_find_nvme_ns "${def_subsys_uuid}")
+ if [[ "${ns}" = "" ]]; then
+ echo "could not find ns after disconnect"
+ fi
+ _delayed_nvme_reconnect_ctrl "${nvmedev}" &
+ bytes_written=$(run_xfs_io_pwritev2 /dev/"$ns" 4096)
+ if [ "$bytes_written" != 4096 ]; then
+ echo "could not write successfully with reconnect"
+ fi
+ sleep 10
+ ns=$(_find_nvme_ns "${def_subsys_uuid}")
+ if [[ "${ns}" = "" ]]; then
+ echo "could not find ns after delayed reconnect"
+ fi
+ refcnt=$(_module_use_count nvme_core)
+ if [ "$refcnt" != "" ] && [ "$refcnt" -ne "$refcnt_orig" ]; then
+ echo "module refcount not as original"
+ fi
+
+ # Final tidy-up
+ echo 0 > /sys/block/"$ns"/delayed_removal_secs
+ nvmedev=$(_find_nvme_dev "${def_subsysnqn}")
+ _nvme_disconnect_ctrl "${nvmedev}"
+ _nvmet_target_cleanup
+
+ echo "Test complete"
+}
diff --git a/tests/nvme/068.out b/tests/nvme/068.out
new file mode 100644
index 0000000..b913d19
--- /dev/null
+++ b/tests/nvme/068.out
@@ -0,0 +1,3 @@
+Running nvme/068
+pwrite: Input/output error
+Test complete
--
2.43.5
^ permalink raw reply related
* Re: [PATCH v6 00/43] btrfs: add fscrypt support
From: Daniel Vacek @ 2026-04-15 10:21 UTC (permalink / raw)
To: Neal Gompa
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: <CAEg-Je9XevtRv1VLPCQtog6+UrLL32ZWY_TzXVd8mU5Vnp+Nzg@mail.gmail.com>
On Wed, 15 Apr 2026 at 07:30, Neal Gompa <neal@gompa.dev> wrote:
> 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...
Hi Neal,
I wanted to post a new iteration last week but I hit some new issues
that I'm trying to address now.
The WIP is here if you want to have a peek:
https://github.com/dvacek/linux-btrfs/tree/fscrypt
Note, I'll be force-updating it later so don't take even the v7 tag
for granted at this point.
--nX
> --
> 真実はいつも一つ！/ Always, there's only one truth!
^ permalink raw reply
* Re: [PATCH v10 13/13] docs: add io_queue flag to isolcpus
From: Ming Lei @ 2026-04-15 8:58 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Aaron Tomlin, Ming Lei, 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, hare, kch, steve, sean, chjohnst,
neelx, mproche, linux-block, linux-kernel, virtualization,
linux-nvme, linux-scsi, megaraidlinux.pdl, mpi3mr-linuxdrv.pdl,
MPT-FusionLinux.pdl
In-Reply-To: <20260415083458.UD3cF5IQ@linutronix.de>
On Wed, Apr 15, 2026 at 4:35 PM Sebastian Andrzej Siewior
<bigeasy@linutronix.de> wrote:
>
> On 2026-04-13 23:11:15 [+0800], Ming Lei wrote:
> > > > What matters is that IO won't interrupt isolated CPU.
> > >
> > > The isolcpus=managed_irq acts as a "best effort" avoidance algorithm rather
> > > than a strict, unbreakable constraint. This is indicated in the proposed
> > > changes to Documentation/core-api/irq/managed_irq.rst [1].
> >
> > Yes, it is "best effort", but isolated cpu is only take as effective CPU
> > for the hw queue's irq iff all others are offline. Which is just fine for typical
> > use cases, in which IO isn't submitted from isolated CPU.
>
> Couldn't we tackle this by limiting the number of managed interrupts the
> device asks for and then limiting the CPUs it could be bound to?
>
> So if have house keeping CPUs 0/1 and isolated 2-63 then managed_irq= is
> futile since it use 64 interrupts and map each to one CPU. Even if the
> device supports less it would map them evenly across available CPUs.
>
> If the user wishes to initiate I/O from all CPUs but not be bother by
> interrupts we could limit the device to ask for 2 interrupts instead of
> 64 (with the consequence of more queue sharing) and then limit those two
> interrupts to CPU 0 and 1 instead to CPU 0-31 and 32-63 like it would be
> now the case.
>
> Wouldn't that be what the io_queue flag tries to do?
Yes, that is why I call it one optimization, however it does introduce
cost of CPU offline failure, please see patch 11.
Thanks,
Ming Lei
^ permalink raw reply
* Re: [PATCH v10 13/13] docs: add io_queue flag to isolcpus
From: Sebastian Andrzej Siewior @ 2026-04-15 8:34 UTC (permalink / raw)
To: Ming Lei
Cc: Aaron Tomlin, Ming Lei, 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, hare, kch, steve, sean, chjohnst,
neelx, mproche, linux-block, linux-kernel, virtualization,
linux-nvme, linux-scsi, megaraidlinux.pdl, mpi3mr-linuxdrv.pdl,
MPT-FusionLinux.pdl
In-Reply-To: <ad0Hk48y5JEeMlFk@fedora>
On 2026-04-13 23:11:15 [+0800], Ming Lei wrote:
> > > What matters is that IO won't interrupt isolated CPU.
> >
> > The isolcpus=managed_irq acts as a "best effort" avoidance algorithm rather
> > than a strict, unbreakable constraint. This is indicated in the proposed
> > changes to Documentation/core-api/irq/managed_irq.rst [1].
>
> Yes, it is "best effort", but isolated cpu is only take as effective CPU
> for the hw queue's irq iff all others are offline. Which is just fine for typical
> use cases, in which IO isn't submitted from isolated CPU.
Couldn't we tackle this by limiting the number of managed interrupts the
device asks for and then limiting the CPUs it could be bound to?
So if have house keeping CPUs 0/1 and isolated 2-63 then managed_irq= is
futile since it use 64 interrupts and map each to one CPU. Even if the
device supports less it would map them evenly across available CPUs.
If the user wishes to initiate I/O from all CPUs but not be bother by
interrupts we could limit the device to ask for 2 interrupts instead of
64 (with the consequence of more queue sharing) and then limit those two
interrupts to CPU 0 and 1 instead to CPU 0-31 and 32-63 like it would be
now the case.
Wouldn't that be what the io_queue flag tries to do?
> Thanks,
> Ming
Sebastian
^ permalink raw reply
* Re: [PATCH v2 00/10] ublk: add shared memory zero-copy support
From: Ming Lei @ 2026-04-15 8:38 UTC (permalink / raw)
To: Keith Busch; +Cc: Ming Lei, Jens Axboe, linux-block, Caleb Sander Mateos
In-Reply-To: <ad6N4JWaeSGgt7Mr@kbusch-mbp>
On Tue, Apr 14, 2026 at 12:56:32PM -0600, Keith Busch wrote:
> 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?
I understand vhost-user-blk is backend, which can handle UBLK_F_SHMEM_ZC
in zero copy style too from userspace:
https://archive.fosdem.org/2023/schedule/event/sds_vhost_user_blk/attachments/slides/5444/export/events/attachments/sds_vhost_user_blk/slides/5444/stefanha_fosdem_2023.pdf
>
> 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
Yes, this patch just provides another choice, and ublk server can choose
to use any combinations(page copy & shmem_zc, existing zc & shmem_zc, ...).
> 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?
The change in client side is very small, also lots of applications
pre-allocate IO buffers. It is one **supplement** or optimization, which is
fast than user copy or existing zero-copy, and more friendly to handle than
existing zero-copy.
If any DIRECT-IO application wants to take the optimization, the user can add
the small change for triggering client buffer registration, otherwise
everything works just like before.
Honestly the optimization is inspired by the lsfmm proposal "dmabuf backed read/write".
Thanks,
Ming
^ permalink raw reply
* Re: [PATCH 8/8] RFC: use a TASK_FIFO kthread for read completion support
From: David Laight @ 2026-04-15 8:28 UTC (permalink / raw)
To: Dave Chinner
Cc: Gao Xiang, 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
In-Reply-To: <ad2RKNo2FGhpzJQp@dread>
On Tue, 14 Apr 2026 10:58:16 +1000
Dave Chinner <dgc@kernel.org> wrote:
> On Sat, Apr 11, 2026 at 07:44:43AM +0800, Gao Xiang wrote:
> >
> >
> > On 2026/4/11 06:11, Dave Chinner wrote:
> > > On Thu, Apr 09, 2026 at 06:02:21PM +0200, Christoph Hellwig wrote:
> > > > Commit 3fffb589b9a6 ("erofs: add per-cpu threads for decompression as an
> > > > option") explains why workqueue aren't great for low-latency completion
> > > > handling. Switch to a per-cpu kthread to handle it instead. This code
> > > > is based on the erofs code in the above commit, but further simplified
> > > > by directly using a kthread instead of a kthread_work.
> > > >
> > > > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > >
> > > 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...
> >
> > It has been "fixed" but never actually get fixed:
> > https://lore.kernel.org/r/CAB=BE-QaNBn1cVK6c7LM2cLpH_Ck_9SYw-YDYEnNrtwfoyu81Q@mail.gmail.com
> >
> > and workqueues don't have any plan to introduce RT threads;
>
> They don't need to (or should) introduce RT threads. Per-cpu kernel
> threads already get priority over normal user tasks on scheduling
> decisions. However, they do not pre-empt running kernel tasks of
> the same priority.
>
> In general, kernel threads should not use RT scheduling at all - if
> the kernel uses RT prioprity tasks then that can interfere with user
> scheduled RT tasks. This is especially true in this case where a
> non-RT tasks issue the IO, and the IO completion is then scheduled
> with RT priority. IOWs, any unprivileged user can now impact the
> processing time available to, and the response latency of, other
> RT scheduled tasks the system is running.
But might not an IO for a use RT task be sat behind it in the
completion queue?
To avoid priority inversion you need to process the completions.
The non-RT task won't be rescheduled to issue a later request.
The only other way is to force that completion work be done in
the context of the thread that issued the request.
>
> 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.
>
> In theory, this should provide the same benefit, because what RT
> scheduling is doing is pre-empting any user and kernel task that was
> running when the interrupt was delivered to execute the completion
> task immediately.
>
> Setting the workqueue to use kernel threads of a higher scheduler
> prioirty should do the same thing, without the need to use dedicated
> per-cpu RT threads.
We had a related issue with the network stack's use of softint and
threaded napi when trying to receive very high packet rate UDP traffic.
(IIRC something like 500000 200byte RTP audio packets every second.)
There is an absolute requirement to run the ethernet rx processing
in order to avoid dropping packets.
Now normally the code runs as 'softint' making it higher priority
that any user process, but under load it switches to using 'normal
priority' kernel threads which are basically low priority.
Similarly 'threaded napi' uses 'normal priority' threads.
The only we made it work was to manually change the threads to be
a low 'RT FIFO' priority so they got scheduled in preference to
all user processes.
A system may need some user RT threads with a lower priority than
these kernel threads and others with a higher priority.
So defaulting to a middling RT priority may be best.
David
^ permalink raw reply
* Re: [PATCH 1/2] sg: don't use GFP_ATOMIC in sg_start_req
From: John Garry @ 2026-04-15 8:02 UTC (permalink / raw)
To: Christoph Hellwig, Jens Axboe, Doug Gilbert, Martin K. Petersen
Cc: Shin'ichiro Kawasaki, linux-block, linux-scsi
In-Reply-To: <20260415060813.807659-2-hch@lst.de>
On 15/04/2026 07:08, Christoph Hellwig wrote:
> 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>
FWIW:
Reviewed-by: John Garry <john.g.garry@oracle.com>
^ permalink raw reply
* Re: [PATCH 8/8] RFC: use a TASK_FIFO kthread for read completion support
From: Christoph Hellwig @ 2026-04-15 6:59 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Christoph Hellwig, Gao Xiang, 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, Anuj Gupta
In-Reply-To: <20260415063051.H3zA99Qh@linutronix.de>
On Wed, Apr 15, 2026 at 08:30:51AM +0200, Sebastian Andrzej Siewior wrote:
> Not sure why I ended up here
Because this is very similar to ksoftirqd and softirq.c doesn't have a
maintainer, and you were the last one doing substantial changes to it.
And you're also very knowledgeable about PREEMPT_RT, which has a bit of
a history of low-latency user context helpers :)
^ permalink raw reply
* Re: [PATCH 8/8] RFC: use a TASK_FIFO kthread for read completion support
From: Sebastian Andrzej Siewior @ 2026-04-15 6:30 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Gao Xiang, 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, Anuj Gupta
In-Reply-To: <20260415055552.GD26893@lst.de>
On 2026-04-15 07:55:52 [+0200], Christoph Hellwig wrote:
> 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.
Not sure why I ended up here but looking at the patch I don't see how is
different to the kworker solution that is removed. Unless you fiddle
with the thread priority in userland.
The get_cpu() + spin_lock usage breaks on PREEMPT_RT.
The NOHZ_FULL camp might not be happy about putting load on isolated
CPUs. I remember there was some effort to avoid those CPUs.
Sebastian
^ permalink raw reply
* 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
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