* Re: [bug report] blktests rnbd/001 hang on s390x server
From: Haris Iqbal @ 2026-04-13 9:49 UTC (permalink / raw)
To: Yi Zhang; +Cc: linux-block, jinpu.wang, Shinichiro Kawasaki,
Zhijian Li (Fujitsu)
In-Reply-To: <CAJpMwyjAQhL9H_5Odz3zg12D-ja3VdsbZbwE2TxuLEsaP5KQbg@mail.gmail.com>
On Tue, Mar 24, 2026 at 11:10 AM Haris Iqbal <haris.iqbal@ionos.com> wrote:
>
> On Sat, Mar 21, 2026 at 2:00 PM Yi Zhang <yi.zhang@redhat.com> wrote:
> >
> > Hi
> >
> > I found this issue when I running blktests rnbd/ on s390x server,
> > please help check it and let me know if you need any info, thanks.
>
> Thanks for reporting.
> We'll take a look and come back.
>
> >
> > dmesg:
> > [ 72.319120] rdma_rxe: loaded
> > [ 72.358181] rtrs_server L2371: Loading module rtrs_server, proto
> > 2.0: (max_chunk_size: 131072 (pure IO 126976, headers 4096) ,
> > sess_queue_depth: 512, always_invalidate: 1)
> > [ 72.380277] loop: module loaded
> > [ 72.399060] run blktests rnbd/001 at 2026-03-21 08:42:02
> > [ 72.408570] infiniband enc600_rxe: set active
> > [ 72.408573] infiniband enc600_rxe: added enc600
> > [ 72.422914] rnbd_client L607: Mapping device /dev/loop0 on session
> > blktest, (access_mode: rw, nr_poll_queues: 0)
> > [ 72.488056] rnbd_client L1192: [session=blktest] mapped 2/2
> > default/read queues.
> > [ 72.488199] rtrs_server L1058: <blktest>: Processing read request
> > failed, invalid message
> >
> > # uname -r
> > 7.0.0-0.rc4.260317g2d1373e4246d.37.fc45.s390x
> >
> > # ps aux | grep rnbd
> > root 1492 0.0 0.0 8276 4436 pts/0 S+ 08:42 0:00
> > /bin/bash ./check rnbd/001
> > root 1521 0.0 0.0 8288 3292 pts/0 S+ 08:42 0:00
> > /bin/bash ./check rnbd/001
> > root 1523 0.0 0.0 8424 3664 pts/0 D+ 08:42 0:00
> > /bin/bash ./check rnbd/001
> >
> > # cat /proc/1523/stack
> > [<0>] send_usr_msg+0x120/0x170 [rnbd_client]
> > [<0>] send_msg_sess_info+0x1d2/0x210 [rnbd_client]
> > [<0>] find_and_get_or_create_sess+0x274/0x2f0 [rnbd_client]
> > [<0>] rnbd_clt_map_device+0xf6/0x7b0 [rnbd_client]
> > [<0>] rnbd_clt_map_device_store+0x228/0x320 [rnbd_client]
> > [<0>] kernfs_fop_write_iter+0x168/0x220
> > [<0>] vfs_write+0x282/0x450
> > [<0>] ksys_write+0x84/0x110
> > [<0>] __do_syscall+0x166/0x600
> > [<0>] system_call+0x6e/0x90
> >
> > --
> > Best Regards,
> > Yi Zhang
Hi,
We have the following patch which fixes the crash for us. However, we
tested the changes in virtualized s390x VM, and observed a few hangs
initially, which later went away. We are not sure if it was because
the virtualization was slow or something else. Do you have s390x
hardware to test and confirm that the below change fixes the issue
cleanly without any other hangs/crashes?
From 85f8bb94b7357d50cd9daf5c5eb72a7c39cfdeba Mon Sep 17 00:00:00 2001
From: Grzegorz Prajsner <grzegorz.prajsner@ionos.com>
Date: Thu, 9 Apr 2026 13:29:59 +0200
Subject: [PATCH] RDMA/rtrs-srv: Fix processing messages for Big-Endian archs
Convert msg->sg_cnt from le16 to cpu endianness before processing
it. This fixes bug processing messages on Big-Endian architectures.
Signed-off-by: Grzegorz Prajsner <grzegorz.prajsner@ionos.com>
Signed-off-by: Md Haris Iqbal <haris.iqbal@ionos.com>
---
drivers/infiniband/ulp/rtrs/rtrs-srv.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/ulp/rtrs/rtrs-srv.c
b/drivers/infiniband/ulp/rtrs/rtrs-srv.c
index 0140bfaed721..978daa69e096 100644
--- a/drivers/infiniband/ulp/rtrs/rtrs-srv.c
+++ b/drivers/infiniband/ulp/rtrs/rtrs-srv.c
@@ -1044,7 +1044,7 @@ static void process_read(struct rtrs_srv_con *con,
struct rtrs_srv_ctx *ctx = srv->ctx;
struct rtrs_srv_op *id;
- size_t usr_len, data_len;
+ size_t usr_len, data_len, sg_cnt;
void *data;
int ret;
@@ -1054,7 +1054,8 @@ static void process_read(struct rtrs_srv_con *con,
rtrs_srv_state_str(srv_path->state));
return;
}
- if (msg->sg_cnt != 1 && msg->sg_cnt != 0) {
+ sg_cnt = le16_to_cpu(msg->sg_cnt);
+ if (sg_cnt != 1 && sg_cnt != 0) {
rtrs_err_rl(s,
"Processing read request failed, invalid
message\n");
return;
--
2.43.0
> >
^ permalink raw reply related
* Re: [PATCH 2/4] tools: ynl-gen-c: optionally emit structs and helpers
From: Christoph Böhmwalder @ 2026-04-13 11:48 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: <20260412125502.3f8ff576@kernel.org>
On Sun, Apr 12, 2026 at 12:55:02PM -0700, Jakub Kicinski wrote:
>On Tue, 7 Apr 2026 19:33:54 +0200 Christoph Böhmwalder wrote:
>> The new flags in the genetlink-legacy spec that are required for
>> existing consumers to keep working are:
>>
>> "default": a literal value or C define that sets the default value
>> for an attribute, consumed by set_defaults().
>>
>> "required": if true, from_attrs() returns an error when this
>> attribute is missing from the request message.
>>
>> "nla-policy-type": can be used to override the NLA type used in
>> policy arrays. This is needed when the semantic type differs from
>> the wire type for backward compatibility: genl_magic maps s32 fields
>> to NLA_U32/nla_get_u32, and existing userspace might depend on this
>> encoding. The immediate motivation is DRBD, whose genl spec
>> definition predates the addition of signed types in genl. However,
>> this is a generic issue that potentially affects multiple families:
>> for example, nftables has NFTA_HOOK_PRIORITY as s32 in the spec but
>> NLA_U32 in the actual kernel policy.
>
>The series doesn't apply for me (neither to Linus's tree nor
>to networking trees), so I didn't experiment with this code.
It's based on for-7.1/block in Jens' tree because there are some
prerequisite commits on there that haven't made it to master yet.
If required, I can also send the net-specific patches based on another
tree, just thought it made sense to keep it all together to have the
whole context in one place.
>Are the new code gen additions purely for the kernel?
Yes. The DRBD userspace utilities re-use the kernel headers and manually
construct messages using libgenl, so we can just do the same for the
legacy family.
>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.
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?
Thoughts?
^ permalink raw reply
* Re: [PATCH v10 13/13] docs: add io_queue flag to isolcpus
From: Ming Lei @ 2026-04-13 15:11 UTC (permalink / raw)
To: Aaron Tomlin
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: <6glgsbk2djsz4cqtbp2ht4274dw4rveq6fojlnpnuvx6zmpjxw@i43jo2l4qlz4>
On Sun, Apr 12, 2026 at 06:50:33PM -0400, Aaron Tomlin wrote:
> On Sat, Apr 11, 2026 at 08:52:00PM +0800, Ming Lei wrote:
> > > The critical issue lies at the invocation of group_cpus_evenly(). Without
> > > this patchset, the core logic lacks the necessary constraints to respect
> > > CPU isolation. It is entirely possible, and indeed happens in practice, for
> > > an isolated CPU to be assigned to a CPU mask group.
> >
> > It is one bug report? No, because it doesn't show any trouble from user
> > viewpoint.
>
> Hi Ming,
>
> The lack of a formal bug report does not negate the fact that the current
> behaviour silently breaks the fundamental contract of CPU isolation from
> the administrator's perspective.
>
> To illustrate the user-visible impact, the following demonstrates the
> difference between relying on isolcpus=managed_irq and isolcpus=io_queue
> under 7.0.0-rc3-00065-gd80965e205a5, which includes this series.
>
> The Broadcom MPI3 Storage Controller driver allocates a full complement of
> 48 operational queue pairs. Consequently, a number of MSI-X vectors are
> generated and mapped directly onto the isolated cores thereby breaching
> isolation.
>
> # uname -r
> 7.0.0-rc3-00065-gd80965e205a5
>
> # tr ' ' '\n' < /proc/cmdline | grep isolcpus=
> isolcpus=managed_irq,domain,2-47
>
> # cat /sys/devices/system/cpu/isolated
> 2-47
>
> # dmesg | grep -A 6 'MSI-X vectors supported:'
> [ 2.981705] mpi3mr0: MSI-X vectors supported: 128, no of cores: 48,
> [ 2.981705] mpi3mr0: MSI-X vectors requested: 49 poll_queues 0
> [ 3.001915] mpi3mr0: trying to create 48 operational queue pairs
> [ 3.011214] mpi3mr0: allocating operational queues through segmented queues
> [ 3.101903] mpi3mr0: successfully created 48 operational queue pairs(default/polled) queue = (2/0)
> [ 3.111468] mpi3mr0: controller initialization completed successfully
>
> # awk '/mpi3mr0/ { print $1" "$NF }' /proc/interrupts
> 78: mpi3mr0-msix0
> 79: mpi3mr0-msix1
> 80: mpi3mr0-msix2
> 81: mpi3mr0-msix3
> 82: mpi3mr0-msix4
> 83: mpi3mr0-msix5
> 84: mpi3mr0-msix6
> 85: mpi3mr0-msix7
> 86: mpi3mr0-msix8
> 87: mpi3mr0-msix9
> 88: mpi3mr0-msix10
> 89: mpi3mr0-msix11
> 90: mpi3mr0-msix12
> ...
> 122: mpi3mr0-msix44
> 123: mpi3mr0-msix45
> 124: mpi3mr0-msix46
> 125: mpi3mr0-msix47
> 126: mpi3mr0-msix48
>
> # grep -H '' /proc/irq/{119,120,121,122}/{effective,smp}_affinity_list
> /proc/irq/119/effective_affinity_list:42
> /proc/irq/119/smp_affinity_list:42
> /proc/irq/120/effective_affinity_list:43
> /proc/irq/120/smp_affinity_list:43
> /proc/irq/121/effective_affinity_list:44
> /proc/irq/121/smp_affinity_list:44
> /proc/irq/122/effective_affinity_list:45
> /proc/irq/122/smp_affinity_list:45
But typical applications aren't supposed to submit IOs from these isolated CPUs, so
in reality, it isn't a big deal.
>
>
> Now with isolcpus=io_queue,2-47 the allocation is structurally restricted
> at the source. The driver creates only two operational queues, confining
> all resulting interrupts exclusively to housekeeping CPUs (0 and 1):
>
> # uname -r
> 7.0.0-rc3-00065-gd80965e205a5
>
> # tr ' ' '\n' < /proc/cmdline | grep isolcpus=
> isolcpus=io_queue,domain,2-47
>
> # cat /sys/devices/system/cpu/isolated
> 2-47
>
> # dmesg | grep -A 6 'MSI-X vectors supported:'
> [ 3.284850] mpi3mr0: MSI-X vectors supported: 128, no of cores: 48,
> [ 3.284851] mpi3mr0: MSI-X vectors requested: 49 poll_queues 0
> [ 3.305492] mpi3mr0: allocated vectors (3) are less than configured (49)
> [ 3.316528] mpi3mr0: trying to create 2 operational queue pairs
> [ 3.328013] mpi3mr0: allocating operational queues through segmented queues
> [ 3.340697] mpi3mr0: successfully created 2 operational queue pairs(default/polled) queue = (2/0)
> [ 3.350664] mpi3mr0: controller initialization completed successfully
>
> # awk '/mpi3mr0/ { print $1" "$NF }' /proc/interrupts
> 79: mpi3mr0-msix0
> 80: mpi3mr0-msix1
> 81: mpi3mr0-msix2
>
> # grep -H '' /proc/irq/{79,80,81}/{effective,smp}_affinity_list
> /proc/irq/79/effective_affinity_list:1
> /proc/irq/79/smp_affinity_list:1
> /proc/irq/80/effective_affinity_list:1
> /proc/irq/80/smp_affinity_list:1
> /proc/irq/81/effective_affinity_list:0
> /proc/irq/81/smp_affinity_list:0
>
> > Sebastian explains/shows how "isolcpus=managed_irq" works perfectly in the
> > following link:
> >
> > https://lore.kernel.org/all/20260401110232.ET5RxZfl@linutronix.de/
> >
> > You have reviewed it...
> >
> > 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.
Thanks,
Ming
^ permalink raw reply
* [PATCH] floppy: fix reference leak on platform_device_register() failure
From: Guangshuo Li @ 2026-04-13 15:31 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>
---
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);
goto out_remove_drives;
+ }
registered[drive] = true;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 02/12] block/bdev: Annotate the blk_holder_ops callback invocations
From: Bart Van Assche @ 2026-04-13 16:06 UTC (permalink / raw)
To: Marco Elver
Cc: Christoph Hellwig, Jens Axboe, linux-block, Damien Le Moal,
Nathan Chancellor
In-Reply-To: <CANpmjNONpHgSzavkbqdbM2N0oCtt2_2+UqBCMWjMaWEcWrCy4w@mail.gmail.com>
On 4/12/26 11:00 PM, Marco Elver wrote:
> For now, that's intended - focus is on getting rid of false positives.
> Doing what you suggest above would require abusing the attributes to
> effectively become type qualifiers; that's generally questionable,
> because that's not what attributes are meant to do (and reworking TSA
> to provide real type-qualifiers is an intrusion into the type system
> that's also a hard sell). So for now, I'll try to do the simpler
> change, and later may look into adding -Wthread-safety specific
> warnings that points out such mismatches.
Is there agreement that the Linux kernel Clang build shouldn't break, no
matter what version of Clang is used to build the kernel (ignoring Clang
bugs)? If so, I think we either need a new macro to annotate function
pointers or thread-safety checking has to be disabled for Clang versions
that do not support annotating function pointers.
If I annotate function pointers with __releases() then the following
error message is reported with a Clang compiler built from the LLVM main
branch:
In file included from block/blk-core.c:16:
In file included from ./include/linux/module.h:20:
In file included from ./include/linux/elf.h:6:
In file included from ./arch/x86/include/asm/elf.h:10:
In file included from ./arch/x86/include/asm/ia32.h:7:
In file included from ./include/linux/compat.h:17:
./include/linux/fs.h:2309:55: error: use of undeclared identifier 'sb'
2309 | void (*kill_sb) (struct super_block *sb)
__releases(&sb->s_umount);
|
How to prevent such error messages? Is adding the capability to the
Linux kernel to detect whether or not annotating function pointers is
supported and introducing a new macro for annotating function pointers
the only solution?
Additionally, the __release() annotations introduced by this patch will
have to be surrounded by an #ifdef/#endif pair or thread-safety checking
in the Linux kernel will have to be disabled for Clang versions that do
not support adding attributes to function pointers.
Thanks,
Bart.
^ permalink raw reply
* Re: [PATCH 2/4] tools: ynl-gen-c: optionally emit structs and helpers
From: Jakub Kicinski @ 2026-04-13 17:49 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: <adzVUdf74CVk2DwJ@localhost.localdomain>
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?
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.
> 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 v3 02/12] block/bdev: Annotate the blk_holder_ops callback invocations
From: Marco Elver @ 2026-04-13 20:03 UTC (permalink / raw)
To: Bart Van Assche
Cc: Christoph Hellwig, Jens Axboe, linux-block, Damien Le Moal,
Nathan Chancellor, Peter Zijlstra
In-Reply-To: <2a2c46fb-c934-4ecc-b3cb-4e4114a6d6bf@acm.org>
On Mon, 13 Apr 2026 at 18:06, Bart Van Assche <bvanassche@acm.org> wrote:
>
> On 4/12/26 11:00 PM, Marco Elver wrote:
> > For now, that's intended - focus is on getting rid of false positives.
> > Doing what you suggest above would require abusing the attributes to
> > effectively become type qualifiers; that's generally questionable,
> > because that's not what attributes are meant to do (and reworking TSA
> > to provide real type-qualifiers is an intrusion into the type system
> > that's also a hard sell). So for now, I'll try to do the simpler
> > change, and later may look into adding -Wthread-safety specific
> > warnings that points out such mismatches.
>
> Is there agreement that the Linux kernel Clang build shouldn't break, no
> matter what version of Clang is used to build the kernel (ignoring Clang
> bugs)? If so, I think we either need a new macro to annotate function
> pointers or thread-safety checking has to be disabled for Clang versions
> that do not support annotating function pointers.
>
> If I annotate function pointers with __releases() then the following
> error message is reported with a Clang compiler built from the LLVM main
> branch:
Note the function pointer support hasn't been merged yet - waiting for
someone to review my LLVM PR...
> In file included from block/blk-core.c:16:
> In file included from ./include/linux/module.h:20:
> In file included from ./include/linux/elf.h:6:
> In file included from ./arch/x86/include/asm/elf.h:10:
> In file included from ./arch/x86/include/asm/ia32.h:7:
> In file included from ./include/linux/compat.h:17:
> ./include/linux/fs.h:2309:55: error: use of undeclared identifier 'sb'
> 2309 | void (*kill_sb) (struct super_block *sb)
> __releases(&sb->s_umount);
> |
>
> How to prevent such error messages? Is adding the capability to the
> Linux kernel to detect whether or not annotating function pointers is
> supported and introducing a new macro for annotating function pointers
> the only solution?
>
> Additionally, the __release() annotations introduced by this patch will
> have to be surrounded by an #ifdef/#endif pair or thread-safety checking
> in the Linux kernel will have to be disabled for Clang versions that do
> not support adding attributes to function pointers.
Either conditionally enabling differently named macros as you suggest,
or simply bumping the Clang compiler version. I think for Context
Analysis specifically we're better off bumping the required compiler
version, because otherwise we end up with a mess of macros we have to
undo later.
I already sent the patch to bump min. Clang to 23 for Context
Analysis: https://lore.kernel.org/all/acqELlVC6vEeEF-W@elver.google.com/
[1]
While for 1-2 new features we might be fine with more macros (as I
initially tried for the multi-arg guarded_by), I think that doesn't
scale if we need to support more versions and even more features. I
think that's also what Peter suggested, and last I checked he's just
waiting for the dev version of Clang 23 to be new enough to take the
above patch [1].
I hope the function pointer support will land in Clang 23 as well
(when it will be released in ~August). So once the function pointer
support lands, we should definitely bump min. Clang version.
While it's not that convenient that Clang 22 will become unsupported
for Context Analysis, I think in the longer term we're better off
(cleaner code, less quirks, easier to maintain). I think we suspected
we'll have to bump the required version sooner than later - but
hopefully Clang 23 is "the one." ;-)
^ permalink raw reply
* Re: [GIT PULL] Block changes for the 7.1 merge window
From: pr-tracker-bot @ 2026-04-14 0:30 UTC (permalink / raw)
To: Jens Axboe; +Cc: Linus Torvalds, linux-block@vger.kernel.org
In-Reply-To: <d59c7b0e-1cc8-43ae-89aa-ca37e08387f9@kernel.dk>
The pull request you sent on Sat, 11 Apr 2026 17:40:24 -0600:
> https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux.git tags/for-7.1/block-20260411
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7fe6ac157b7e15c8976bd62ad7cb98e248884e83
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH 8/8] RFC: use a TASK_FIFO kthread for read completion support
From: Dave Chinner @ 2026-04-14 0:58 UTC (permalink / raw)
To: Gao Xiang
Cc: 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: <7f0d072b-97a7-405f-bff5-d3819de2e3dd@linux.alibaba.com>
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.
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.
> If Sandeep has more time, I hope he could have more time to
> test since I don't work on Android anymore: In principle,
> I still think RT thread is needed somewhere for such usage
> since lowest latencies is needed.
All that is needed is for the kworker thread to be scheduled to run
immeidately after the interrupt that scheduled the work exits. This
does not require dedicated per-cpu kernel tasks or RT scheduling....
> Compared to the scheduling latency issues, interested users
> don't care "individual subsystems needing their own set of
> per-cpu kernel tasks just sitting around idle most of of
> the time". If end users care it more, they can just turn
> it off by Kconfig.
Distros enable all these subsystems all the time, so saying
"turn it off via kconfig" is not a viable mitigation
strategy. Proliferation of dedicated per-CPU worker task pools is a
known problem, and we really don't want to regress back to those
days when a typical system had thousands of dedicated per-cpu work
queues that largely did nothing most of the time.
-Dave.
--
Dave Chinner
dgc@kernel.org
^ permalink raw reply
* Re: [PATCH 8/8] RFC: use a TASK_FIFO kthread for read completion support
From: Gao Xiang @ 2026-04-14 2:23 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, linux-block,
linux-kernel, linux-xfs, linux-fsdevel, linux-mm, Sandeep Dhavale
In-Reply-To: <ad2RKNo2FGhpzJQp@dread>
On 2026/4/14 08:58, Dave Chinner 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.
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_.
Thus, if there is another dedicated mechanism which can provide
a lightweight task context and is scheduled to run immediately
after the softirq: that would fit our requirement and I believe
it's useful for other various use cases, but currently there is
no such clean infra; RT threads can just fulfill our requirement
in a less elegant way.
>
> 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.
>
> 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.
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.
Additionally, we also need a way to set nice if we decide to switch
to the new BIO_COMPLETE_IN_TASK approach as well if the nice way
really works.
>
> 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.
>
>> If Sandeep has more time, I hope he could have more time to
>> test since I don't work on Android anymore: In principle,
>> I still think RT thread is needed somewhere for such usage
>> since lowest latencies is needed.
>
> All that is needed is for the kworker thread to be scheduled to run
> immeidately after the interrupt that scheduled the work exits. This
> does not require dedicated per-cpu kernel tasks or RT scheduling....
Right and not sure, it needs some latency evaluation with
heavy background/foreground app pressures.
>
>> Compared to the scheduling latency issues, interested users
>> don't care "individual subsystems needing their own set of
>> per-cpu kernel tasks just sitting around idle most of of
>> the time". If end users care it more, they can just turn
>> it off by Kconfig.
>
> Distros enable all these subsystems all the time, so saying
> "turn it off via kconfig" is not a viable mitigation
> strategy. Proliferation of dedicated per-CPU worker task pools is a
> known problem, and we really don't want to regress back to those
> days when a typical system had thousands of dedicated per-cpu work
> queues that largely did nothing most of the time.
That kconfig is off by default, but all Android vendors
turn it on, and that latency issue is particularly vital
for Android ecosystem.
Currently RT threads won't be used for other use cases even
desktop use cases: Android workloads are pretty harsh
even compared to desktops for example.
Thanks,
Gao Xiang
>
> -Dave.
>
^ permalink raw reply
* Re: [RFC PATCH] zram: support asynchronous GC for lazy slot freeing
From: Xueyuan Chen @ 2026-04-14 5:49 UTC (permalink / raw)
To: ryncsn
Cc: baohua, minchan, senozhatsky, akpm, linux-mm, axboe, linux-block,
linux-kernel, kasong, chrisl, justinjiang, liulei.rjpt,
xueyuan.chen21
In-Reply-To: <adt3Q_SRToF6fb3W@KASONG-MC4>
On Sun, Apr 12, 2026 at 07:48:48PM +0800, Kairui Song wrote:
[...]
>What is making this slot_free so costly? zs_free?
Yes, I've captured some perf data on RK3588 cpu2:
- 3.79% 0.42% zram [zram] [k] slot_free
- 89.04% slot_free
- 65.40% zs_free
+ 77.29% free_zspage
+ 21.75% kmem_cache_free
0.68% __kern_my_cpu_offset
+ 13.19% _raw_spin_unlock
+ 4.86% _raw_read_unlock
4.75% obj_free
+ 4.72% _raw_read_lock
3.64% fix_fullness_group
+ 2.02% _raw_spin_lock
+ 1.31% kmem_cache_free
It's clear that zs_free is the primary hotspot, accounting for ~65.40%
of the total slot_free cycles. Beyond that, have some read and spin lock
in slot_free.
--
Thanks,
Xueyuan
^ permalink raw reply
* Re: [PATCH v2 2/2] block: relax pgmap check in bio_add_page for compatible zone device pages
From: Christoph Hellwig @ 2026-04-14 8:14 UTC (permalink / raw)
To: Naman Jain
Cc: Jens Axboe, Christoph Hellwig, Chaitanya Kulkarni, John Hubbard,
Logan Gunthorpe, linux-kernel, linux-block, Saurabh Sengar,
Long Li, Michael Kelley
In-Reply-To: <20260410153414.4159050-3-namjain@linux.microsoft.com>
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* zloop fixes
From: Christoph Hellwig @ 2026-04-14 8:17 UTC (permalink / raw)
To: Jens Axboe, Damien Le Moal; +Cc: linux-block
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(-)
^ permalink raw reply
* [PATCH 1/6] zloop: fix write pointer calculation in zloop_forget_cache
From: Christoph Hellwig @ 2026-04-14 8:17 UTC (permalink / raw)
To: Jens Axboe, Damien Le Moal; +Cc: linux-block
In-Reply-To: <20260414081811.549755-1-hch@lst.de>
The write pointer is absolute and in sector units, so we need to
convert it to a relative byte address first.
Fixes: c505448748f7 ("zloop: forget write cache on force removal")
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/block/zloop.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/block/zloop.c b/drivers/block/zloop.c
index 8baf642037fd..672948d3653e 100644
--- a/drivers/block/zloop.c
+++ b/drivers/block/zloop.c
@@ -1401,8 +1401,17 @@ static void zloop_forget_cache(struct zloop_device *zlo)
zlo->disk->part0, ret);
continue;
}
- if (old_wp < zone->wp)
- zloop_truncate(file, old_wp);
+
+ if (old_wp > zone->wp)
+ continue;
+ /*
+ * This should not happen, if we recored a full zone, it can't
+ * be active.
+ */
+ if (WARN_ON_ONCE(old_wp == ULLONG_MAX))
+ continue;
+
+ zloop_truncate(file, (old_wp - zone->start) << SECTOR_SHIFT);
}
}
--
2.53.0
^ permalink raw reply related
* [PATCH 2/6] zloop: use vfs_truncate
From: Christoph Hellwig @ 2026-04-14 8:17 UTC (permalink / raw)
To: Jens Axboe, Damien Le Moal; +Cc: linux-block
In-Reply-To: <20260414081811.549755-1-hch@lst.de>
While vfs_truncate does various extra checks that we don't really need,
it is always better to use a VFS helper rather than open coding the
logic.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/block/zloop.c | 17 ++---------------
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/block/zloop.c b/drivers/block/zloop.c
index 672948d3653e..fc54480ed62d 100644
--- a/drivers/block/zloop.c
+++ b/drivers/block/zloop.c
@@ -1363,20 +1363,6 @@ static int zloop_ctl_add(struct zloop_options *opts)
return ret;
}
-static void zloop_truncate(struct file *file, loff_t pos)
-{
- struct mnt_idmap *idmap = file_mnt_idmap(file);
- struct dentry *dentry = file_dentry(file);
- struct iattr newattrs;
-
- newattrs.ia_size = pos;
- newattrs.ia_valid = ATTR_SIZE;
-
- inode_lock(dentry->d_inode);
- notify_change(idmap, dentry, &newattrs, NULL);
- inode_unlock(dentry->d_inode);
-}
-
static void zloop_forget_cache(struct zloop_device *zlo)
{
unsigned int i;
@@ -1411,7 +1397,8 @@ static void zloop_forget_cache(struct zloop_device *zlo)
if (WARN_ON_ONCE(old_wp == ULLONG_MAX))
continue;
- zloop_truncate(file, (old_wp - zone->start) << SECTOR_SHIFT);
+ vfs_truncate(&file->f_path,
+ (old_wp - zone->start) << SECTOR_SHIFT);
}
}
--
2.53.0
^ permalink raw reply related
* [PATCH 3/6] zloop: improve the unaligned write pointer warning
From: Christoph Hellwig @ 2026-04-14 8:17 UTC (permalink / raw)
To: Jens Axboe, Damien Le Moal; +Cc: linux-block
In-Reply-To: <20260414081811.549755-1-hch@lst.de>
Use the IS_ALIGNED helper and avoid extra conversions, and tell the
user what the unaligned size is.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/block/zloop.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/block/zloop.c b/drivers/block/zloop.c
index fc54480ed62d..a738f8629062 100644
--- a/drivers/block/zloop.c
+++ b/drivers/block/zloop.c
@@ -313,9 +313,9 @@ static int zloop_update_seq_zone(struct zloop_device *zlo, unsigned int zone_no)
return -EINVAL;
}
- if (file_sectors & ((zlo->block_size >> SECTOR_SHIFT) - 1)) {
- pr_err("Zone %u file size not aligned to block size %u\n",
- zone_no, zlo->block_size);
+ if (!IS_ALIGNED(stat.size, zlo->block_size)) {
+ pr_err("Zone %u file size (%llu) not aligned to block size %u\n",
+ zone_no, stat.size, zlo->block_size);
return -EINVAL;
}
--
2.53.0
^ permalink raw reply related
* [PATCH 4/6] zloop: set RQF_QUIET when completing requests on deleted devices
From: Christoph Hellwig @ 2026-04-14 8:17 UTC (permalink / raw)
To: Jens Axboe, Damien Le Moal; +Cc: linux-block
In-Reply-To: <20260414081811.549755-1-hch@lst.de>
Reduce the dmesg spam for tests that involve device deletion.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/block/zloop.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/block/zloop.c b/drivers/block/zloop.c
index a738f8629062..7257188dd3a8 100644
--- a/drivers/block/zloop.c
+++ b/drivers/block/zloop.c
@@ -891,8 +891,10 @@ static blk_status_t zloop_queue_rq(struct blk_mq_hw_ctx *hctx,
struct zloop_cmd *cmd = blk_mq_rq_to_pdu(rq);
struct zloop_device *zlo = rq->q->queuedata;
- if (data_race(READ_ONCE(zlo->state)) == Zlo_deleting)
+ if (data_race(READ_ONCE(zlo->state)) == Zlo_deleting) {
+ rq->rq_flags |= RQF_QUIET;
return BLK_STS_IOERR;
+ }
/*
* If we need to strongly order zone append operations, set the request
--
2.53.0
^ permalink raw reply related
* [PATCH 5/6] zloop: factor out zloop_mark_{full,empty} helpers
From: Christoph Hellwig @ 2026-04-14 8:17 UTC (permalink / raw)
To: Jens Axboe, Damien Le Moal; +Cc: linux-block
In-Reply-To: <20260414081811.549755-1-hch@lst.de>
Move a few chunks of duplicated code into helpers.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/block/zloop.c | 48 +++++++++++++++++++++++--------------------
1 file changed, 26 insertions(+), 22 deletions(-)
diff --git a/drivers/block/zloop.c b/drivers/block/zloop.c
index 7257188dd3a8..3f69206d674a 100644
--- a/drivers/block/zloop.c
+++ b/drivers/block/zloop.c
@@ -288,6 +288,24 @@ static bool zloop_do_open_zone(struct zloop_device *zlo,
}
}
+static void zloop_mark_full(struct zloop_device *zlo, struct zloop_zone *zone)
+{
+ lockdep_assert_held(&zone->wp_lock);
+
+ zloop_lru_remove_open_zone(zlo, zone);
+ zone->cond = BLK_ZONE_COND_FULL;
+ zone->wp = ULLONG_MAX;
+}
+
+static void zloop_mark_empty(struct zloop_device *zlo, struct zloop_zone *zone)
+{
+ lockdep_assert_held(&zone->wp_lock);
+
+ zloop_lru_remove_open_zone(zlo, zone);
+ zone->cond = BLK_ZONE_COND_EMPTY;
+ zone->wp = zone->start;
+}
+
static int zloop_update_seq_zone(struct zloop_device *zlo, unsigned int zone_no)
{
struct zloop_zone *zone = &zlo->zones[zone_no];
@@ -321,13 +339,9 @@ static int zloop_update_seq_zone(struct zloop_device *zlo, unsigned int zone_no)
spin_lock_irqsave(&zone->wp_lock, flags);
if (!file_sectors) {
- zloop_lru_remove_open_zone(zlo, zone);
- zone->cond = BLK_ZONE_COND_EMPTY;
- zone->wp = zone->start;
+ zloop_mark_empty(zlo, zone);
} else if (file_sectors == zlo->zone_capacity) {
- zloop_lru_remove_open_zone(zlo, zone);
- zone->cond = BLK_ZONE_COND_FULL;
- zone->wp = ULLONG_MAX;
+ zloop_mark_full(zlo, zone);
} else {
if (zone->cond != BLK_ZONE_COND_IMP_OPEN &&
zone->cond != BLK_ZONE_COND_EXP_OPEN)
@@ -429,9 +443,7 @@ static int zloop_reset_zone(struct zloop_device *zlo, unsigned int zone_no)
}
spin_lock_irqsave(&zone->wp_lock, flags);
- zloop_lru_remove_open_zone(zlo, zone);
- zone->cond = BLK_ZONE_COND_EMPTY;
- zone->wp = zone->start;
+ zloop_mark_empty(zlo, zone);
clear_bit(ZLOOP_ZONE_SEQ_ERROR, &zone->flags);
spin_unlock_irqrestore(&zone->wp_lock, flags);
@@ -477,9 +489,7 @@ static int zloop_finish_zone(struct zloop_device *zlo, unsigned int zone_no)
}
spin_lock_irqsave(&zone->wp_lock, flags);
- zloop_lru_remove_open_zone(zlo, zone);
- zone->cond = BLK_ZONE_COND_FULL;
- zone->wp = ULLONG_MAX;
+ zloop_mark_full(zlo, zone);
clear_bit(ZLOOP_ZONE_SEQ_ERROR, &zone->flags);
spin_unlock_irqrestore(&zone->wp_lock, flags);
@@ -616,11 +626,8 @@ static int zloop_seq_write_prep(struct zloop_cmd *cmd)
*/
if (!is_append || !zlo->ordered_zone_append) {
zone->wp += nr_sectors;
- if (zone->wp == zone_end) {
- zloop_lru_remove_open_zone(zlo, zone);
- zone->cond = BLK_ZONE_COND_FULL;
- zone->wp = ULLONG_MAX;
- }
+ if (zone->wp == zone_end)
+ zloop_mark_full(zlo, zone);
}
out_unlock:
spin_unlock_irqrestore(&zone->wp_lock, flags);
@@ -873,11 +880,8 @@ static bool zloop_set_zone_append_sector(struct request *rq)
rq->__sector = zone->wp;
zone->wp += blk_rq_sectors(rq);
- if (zone->wp >= zone_end) {
- zloop_lru_remove_open_zone(zlo, zone);
- zone->cond = BLK_ZONE_COND_FULL;
- zone->wp = ULLONG_MAX;
- }
+ if (zone->wp >= zone_end)
+ zloop_mark_full(zlo, zone);
spin_unlock_irqrestore(&zone->wp_lock, flags);
--
2.53.0
^ permalink raw reply related
* [PATCH 6/6] zloop: remove irq-safe locking
From: Christoph Hellwig @ 2026-04-14 8:17 UTC (permalink / raw)
To: Jens Axboe, Damien Le Moal; +Cc: linux-block
In-Reply-To: <20260414081811.549755-1-hch@lst.de>
All of zloop runs in user context, so drop the irq-safe locking.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/block/zloop.c | 37 +++++++++++++++----------------------
1 file changed, 15 insertions(+), 22 deletions(-)
diff --git a/drivers/block/zloop.c b/drivers/block/zloop.c
index 3f69206d674a..55eeb6aac0ea 100644
--- a/drivers/block/zloop.c
+++ b/drivers/block/zloop.c
@@ -311,7 +311,6 @@ static int zloop_update_seq_zone(struct zloop_device *zlo, unsigned int zone_no)
struct zloop_zone *zone = &zlo->zones[zone_no];
struct kstat stat;
sector_t file_sectors;
- unsigned long flags;
int ret;
lockdep_assert_held(&zone->lock);
@@ -337,7 +336,7 @@ static int zloop_update_seq_zone(struct zloop_device *zlo, unsigned int zone_no)
return -EINVAL;
}
- spin_lock_irqsave(&zone->wp_lock, flags);
+ spin_lock(&zone->wp_lock);
if (!file_sectors) {
zloop_mark_empty(zlo, zone);
} else if (file_sectors == zlo->zone_capacity) {
@@ -348,7 +347,7 @@ static int zloop_update_seq_zone(struct zloop_device *zlo, unsigned int zone_no)
zone->cond = BLK_ZONE_COND_CLOSED;
zone->wp = zone->start + file_sectors;
}
- spin_unlock_irqrestore(&zone->wp_lock, flags);
+ spin_unlock(&zone->wp_lock);
return 0;
}
@@ -381,7 +380,6 @@ static int zloop_open_zone(struct zloop_device *zlo, unsigned int zone_no)
static int zloop_close_zone(struct zloop_device *zlo, unsigned int zone_no)
{
struct zloop_zone *zone = &zlo->zones[zone_no];
- unsigned long flags;
int ret = 0;
if (test_bit(ZLOOP_ZONE_CONV, &zone->flags))
@@ -400,13 +398,13 @@ static int zloop_close_zone(struct zloop_device *zlo, unsigned int zone_no)
break;
case BLK_ZONE_COND_IMP_OPEN:
case BLK_ZONE_COND_EXP_OPEN:
- spin_lock_irqsave(&zone->wp_lock, flags);
+ spin_lock(&zone->wp_lock);
zloop_lru_remove_open_zone(zlo, zone);
if (zone->wp == zone->start)
zone->cond = BLK_ZONE_COND_EMPTY;
else
zone->cond = BLK_ZONE_COND_CLOSED;
- spin_unlock_irqrestore(&zone->wp_lock, flags);
+ spin_unlock(&zone->wp_lock);
break;
case BLK_ZONE_COND_EMPTY:
case BLK_ZONE_COND_FULL:
@@ -424,7 +422,6 @@ static int zloop_close_zone(struct zloop_device *zlo, unsigned int zone_no)
static int zloop_reset_zone(struct zloop_device *zlo, unsigned int zone_no)
{
struct zloop_zone *zone = &zlo->zones[zone_no];
- unsigned long flags;
int ret = 0;
if (test_bit(ZLOOP_ZONE_CONV, &zone->flags))
@@ -442,10 +439,10 @@ static int zloop_reset_zone(struct zloop_device *zlo, unsigned int zone_no)
goto unlock;
}
- spin_lock_irqsave(&zone->wp_lock, flags);
+ spin_lock(&zone->wp_lock);
zloop_mark_empty(zlo, zone);
clear_bit(ZLOOP_ZONE_SEQ_ERROR, &zone->flags);
- spin_unlock_irqrestore(&zone->wp_lock, flags);
+ spin_unlock(&zone->wp_lock);
unlock:
mutex_unlock(&zone->lock);
@@ -470,7 +467,6 @@ static int zloop_reset_all_zones(struct zloop_device *zlo)
static int zloop_finish_zone(struct zloop_device *zlo, unsigned int zone_no)
{
struct zloop_zone *zone = &zlo->zones[zone_no];
- unsigned long flags;
int ret = 0;
if (test_bit(ZLOOP_ZONE_CONV, &zone->flags))
@@ -488,10 +484,10 @@ static int zloop_finish_zone(struct zloop_device *zlo, unsigned int zone_no)
goto unlock;
}
- spin_lock_irqsave(&zone->wp_lock, flags);
+ spin_lock(&zone->wp_lock);
zloop_mark_full(zlo, zone);
clear_bit(ZLOOP_ZONE_SEQ_ERROR, &zone->flags);
- spin_unlock_irqrestore(&zone->wp_lock, flags);
+ spin_unlock(&zone->wp_lock);
unlock:
mutex_unlock(&zone->lock);
@@ -581,10 +577,9 @@ static int zloop_seq_write_prep(struct zloop_cmd *cmd)
bool is_append = req_op(rq) == REQ_OP_ZONE_APPEND;
struct zloop_zone *zone = &zlo->zones[zone_no];
sector_t zone_end = zone->start + zlo->zone_capacity;
- unsigned long flags;
int ret = 0;
- spin_lock_irqsave(&zone->wp_lock, flags);
+ spin_lock(&zone->wp_lock);
/*
* Zone append operations always go at the current write pointer, but
@@ -630,7 +625,7 @@ static int zloop_seq_write_prep(struct zloop_cmd *cmd)
zloop_mark_full(zlo, zone);
}
out_unlock:
- spin_unlock_irqrestore(&zone->wp_lock, flags);
+ spin_unlock(&zone->wp_lock);
return ret;
}
@@ -868,13 +863,12 @@ static bool zloop_set_zone_append_sector(struct request *rq)
struct zloop_zone *zone = &zlo->zones[zone_no];
sector_t zone_end = zone->start + zlo->zone_capacity;
sector_t nr_sectors = blk_rq_sectors(rq);
- unsigned long flags;
- spin_lock_irqsave(&zone->wp_lock, flags);
+ spin_lock(&zone->wp_lock);
if (zone->cond == BLK_ZONE_COND_FULL ||
zone->wp + nr_sectors > zone_end) {
- spin_unlock_irqrestore(&zone->wp_lock, flags);
+ spin_unlock(&zone->wp_lock);
return false;
}
@@ -883,7 +877,7 @@ static bool zloop_set_zone_append_sector(struct request *rq)
if (zone->wp >= zone_end)
zloop_mark_full(zlo, zone);
- spin_unlock_irqrestore(&zone->wp_lock, flags);
+ spin_unlock(&zone->wp_lock);
return true;
}
@@ -944,7 +938,6 @@ static int zloop_report_zones(struct gendisk *disk, sector_t sector,
struct zloop_device *zlo = disk->private_data;
struct blk_zone blkz = {};
unsigned int first, i;
- unsigned long flags;
int ret;
first = disk_zone_no(disk, sector);
@@ -968,9 +961,9 @@ static int zloop_report_zones(struct gendisk *disk, sector_t sector,
blkz.start = zone->start;
blkz.len = zlo->zone_size;
- spin_lock_irqsave(&zone->wp_lock, flags);
+ spin_lock(&zone->wp_lock);
blkz.wp = zone->wp;
- spin_unlock_irqrestore(&zone->wp_lock, flags);
+ spin_unlock(&zone->wp_lock);
blkz.cond = zone->cond;
if (test_bit(ZLOOP_ZONE_CONV, &zone->flags)) {
blkz.type = BLK_ZONE_TYPE_CONVENTIONAL;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] iov_iter: use kmemdup_array for dup_iter to harden against overflow
From: Christoph Hellwig @ 2026-04-14 8:18 UTC (permalink / raw)
To: Wang Haoran; +Cc: viro, akpm, linux-block, linux-fsdevel, linux-kernel
In-Reply-To: <20260413060655.1139141-1-haoranwangsec@gmail.com>
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH 4/5] block: add a bio_submit_or_kill helper
From: Christoph Hellwig @ 2026-04-14 8:24 UTC (permalink / raw)
To: Bart Van Assche
Cc: Christoph Hellwig, Jens Axboe, Carlos Maiolino, Damien Le Moal,
linux-block, linux-xfs, Keith Busch
In-Reply-To: <b2e8e413-39bf-4255-8aad-a30d7fd676ea@acm.org>
On Tue, Apr 07, 2026 at 11:37:50AM -0700, Bart Van Assche wrote:
> Without this change, if a fatal signal is pending before the loop starts,
> -EINTR is returned. With this patch applied, 0 is returned,
> isn't it?
I looked at this a bit, and it turns that while this indeed changes the
behavior for discard, the other ioctls had the return 0 when nothing
was submitted before the thread got killed behavior, and this makes
discard match them.
Given that we won't return from the system call for a fatal kill it
should not matter. Adding Keith who wrote all this to confirm.
^ permalink raw reply
* Re: [PATCH 1/6] zloop: fix write pointer calculation in zloop_forget_cache
From: Damien Le Moal @ 2026-04-14 9:26 UTC (permalink / raw)
To: Christoph Hellwig, Jens Axboe; +Cc: linux-block
In-Reply-To: <20260414081811.549755-2-hch@lst.de>
On 4/14/26 10:17, Christoph Hellwig wrote:
> The write pointer is absolute and in sector units, so we need to
> convert it to a relative byte address first.
>
> Fixes: c505448748f7 ("zloop: forget write cache on force removal")
> 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 2/6] zloop: use vfs_truncate
From: Damien Le Moal @ 2026-04-14 9:26 UTC (permalink / raw)
To: Christoph Hellwig, Jens Axboe; +Cc: linux-block
In-Reply-To: <20260414081811.549755-3-hch@lst.de>
On 4/14/26 10:17, Christoph Hellwig wrote:
> While vfs_truncate does various extra checks that we don't really need,
> it is always better to use a VFS helper rather than open coding the
> logic.
>
> 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 3/6] zloop: improve the unaligned write pointer warning
From: Damien Le Moal @ 2026-04-14 9:27 UTC (permalink / raw)
To: Christoph Hellwig, Jens Axboe; +Cc: linux-block
In-Reply-To: <20260414081811.549755-4-hch@lst.de>
On 4/14/26 10:17, Christoph Hellwig wrote:
> Use the IS_ALIGNED helper and avoid extra conversions, and tell the
> user what the unaligned size is.
>
> 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 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