* Re: cleanup the RAID5 XOR library
From: Eric Biggers @ 2026-02-28 7:35 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Andrew Morton, Richard Henderson, Matt Turner, Magnus Lindholm,
Russell King, Catalin Marinas, Will Deacon, Huacai Chen,
WANG Xuerui, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, David S. Miller, Andreas Larsson,
Richard Weinberger, Anton Ivanov, Johannes Berg, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Herbert Xu, Dan Williams, Chris Mason, David Sterba,
Arnd Bergmann, Song Liu, Yu Kuai, Li Nan, linux-alpha,
linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, linux-s390, sparclinux, linux-um, linux-crypto,
linux-btrfs, linux-arch, linux-raid
In-Reply-To: <20260226151106.144735-1-hch@lst.de>
On Thu, Feb 26, 2026 at 07:10:12AM -0800, Christoph Hellwig wrote:
> Hi all,
>
> the XOR library used for the RAID5 parity is a bit of a mess right now.
> The main file sits in crypto/ despite not being cryptography and not
> using the crypto API, with the generic implementations sitting in
> include/asm-generic and the arch implementations sitting in an asm/
> header in theory. The latter doesn't work for many cases, so
> architectures often build the code directly into the core kernel, or
> create another module for the architecture code.
>
> Changes this to a single module in lib/ that also contains the
> architecture optimizations, similar to the library work Eric Biggers
> has done for the CRC and crypto libraries later. After that it changes
> to better calling conventions that allow for smarter architecture
> implementations (although none is contained here yet), and uses
> static_call to avoid indirection function call overhead.
>
> A git tree is also available here:
>
> git://git.infradead.org/users/hch/misc.git xor-improvements
>
> Gitweb:
>
> https://git.infradead.org/?p=users/hch/misc.git;a=shortlog;h=refs/heads/xor-improvements
Overall this looks great. xor_gen() really needs a KUnit test, though.
Without that, how was this tested?
Later we should remove some of the obsolete implementations, such as the
alpha or x86 MMX ones. Those platforms have no optimized code in
lib/crc/ or lib/crypto/, and I doubt anyone cares. But that should be a
separate series later: porting them over unchanged is the right call for
now so that this series doesn't get blocked on debates about removals...
Also, I notice that no one has optimized this for the latest x86_64 CPUs
by using the vpternlogd instruction to do 3-input XORs. That would be
another good future project.
- Eric
^ permalink raw reply
* Re: [PATCH 18/25] x86: move the XOR code to lib/raid/
From: Peter Zijlstra @ 2026-02-28 10:31 UTC (permalink / raw)
To: Eric Biggers
Cc: Christoph Hellwig, Andrew Morton, Richard Henderson, Matt Turner,
Magnus Lindholm, Russell King, Catalin Marinas, Will Deacon,
Huacai Chen, WANG Xuerui, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, David S. Miller, Andreas Larsson,
Richard Weinberger, Anton Ivanov, Johannes Berg, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Herbert Xu, Dan Williams, Chris Mason, David Sterba,
Arnd Bergmann, Song Liu, Yu Kuai, Li Nan, linux-alpha,
linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, linux-s390, sparclinux, linux-um, linux-crypto,
linux-btrfs, linux-arch, linux-raid
In-Reply-To: <20260227235529.GA31321@quark>
On Fri, Feb 27, 2026 at 03:55:29PM -0800, Eric Biggers wrote:
> On Fri, Feb 27, 2026 at 03:30:16PM +0100, Peter Zijlstra wrote:
> > On Thu, Feb 26, 2026 at 07:10:30AM -0800, Christoph Hellwig wrote:
> > > Move the optimized XOR code out of line into lib/raid.
> > >
> > > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > > ---
> > > arch/x86/include/asm/xor.h | 518 ++----------------
> > > arch/x86/include/asm/xor_64.h | 32 --
> > > lib/raid/xor/Makefile | 8 +
> > > .../xor_avx.h => lib/raid/xor/x86/xor-avx.c | 14 +-
> > > .../xor_32.h => lib/raid/xor/x86/xor-mmx.c | 60 +-
> > > lib/raid/xor/x86/xor-sse.c | 476 ++++++++++++++++
> >
> > I gotta ask, why lib/raid/xor/$arch/ instead of something like
> > arch/$arch/lib/xor ?
>
> Similar to lib/crypto/ and lib/crc/, it allows the translation units
> (either .c or .S files) containing architecture-optimized XOR code to be
> included directly in the xor.ko module, where they should be.
>
> Previously, these were always built into the core kernel even if
> XOR_BLOCKS was 'n' or 'm', or they were built into a separate module
> xor-neon.ko which xor.ko depended on. So either the code was included
> unnecessarily, or there was an extra module.
>
> Technically we could instead have the lib makefile compile stuff in
> arch/, but that would be unusual. It's much cleaner to have the
> directory structure match the build system.
Hmm, I suppose. Its just weird that we now have to look in both
arch/$foo and lib/*/$foo/ to find all arch code.
And I don't suppose symlinks would make it better?
^ permalink raw reply
* Re: [PATCH] block: remove bdev_nonrot()
From: Martin K. Petersen @ 2026-02-28 23:06 UTC (permalink / raw)
To: Damien Le Moal
Cc: Jens Axboe, linux-block, Song Liu, Yu Kuai, linux-raid,
Martin K . Petersen, linux-scsi, target-devel, David Sterba,
linux-btrfs, Theodore Ts'o, linux-ext4, Andreas Dilger,
Andrew Morton, Chris Li, Kairui Song, linux-mm
In-Reply-To: <20260226075448.2229655-1-dlemoal@kernel.org>
Damien,
> bdev_nonrot() is simply the negative return value of bdev_rot(). So
> replace all call sites of bdev_nonrot() with calls to bdev_rot() and
> remove bdev_nonrot().
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
--
Martin K. Petersen
^ permalink raw reply
* FAILED: Patch "md/bitmap: fix GPF in write_page caused by resize race" failed to apply to 6.12-stable tree
From: Sasha Levin @ 2026-03-01 1:23 UTC (permalink / raw)
To: stable, jinpu.wang; +Cc: Yu Kuai, linux-raid
The patch below does not apply to the 6.12-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
Thanks,
Sasha
------------------ original commit in Linus's tree ------------------
From 46ef85f854dfa9d5226b3c1c46493d79556c9589 Mon Sep 17 00:00:00 2001
From: Jack Wang <jinpu.wang@ionos.com>
Date: Tue, 20 Jan 2026 11:24:56 +0100
Subject: [PATCH] md/bitmap: fix GPF in write_page caused by resize race
A General Protection Fault occurs in write_page() during array resize:
RIP: 0010:write_page+0x22b/0x3c0 [md_mod]
This is a use-after-free race between bitmap_daemon_work() and
__bitmap_resize(). The daemon iterates over `bitmap->storage.filemap`
without locking, while the resize path frees that storage via
md_bitmap_file_unmap(). `quiesce()` does not stop the md thread,
allowing concurrent access to freed pages.
Fix by holding `mddev->bitmap_info.mutex` during the bitmap update.
Link: https://lore.kernel.org/linux-raid/20260120102456.25169-1-jinpu.wang@ionos.com
Closes: https://lore.kernel.org/linux-raid/CAMGffE=Mbfp=7xD_hYxXk1PAaCZNSEAVeQGKGy7YF9f2S4=NEA@mail.gmail.com/T/#u
Cc: stable@vger.kernel.org
Fixes: d60b479d177a ("md/bitmap: add bitmap_resize function to allow bitmap resizing.")
Signed-off-by: Jack Wang <jinpu.wang@ionos.com>
Signed-off-by: Yu Kuai <yukuai@fnnas.com>
---
drivers/md/md-bitmap.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/md/md-bitmap.c b/drivers/md/md-bitmap.c
index dbe4c4b9a1daf..1d4a050dab3ab 100644
--- a/drivers/md/md-bitmap.c
+++ b/drivers/md/md-bitmap.c
@@ -2453,6 +2453,7 @@ static int __bitmap_resize(struct bitmap *bitmap, sector_t blocks,
memcpy(page_address(store.sb_page),
page_address(bitmap->storage.sb_page),
sizeof(bitmap_super_t));
+ mutex_lock(&bitmap->mddev->bitmap_info.mutex);
spin_lock_irq(&bitmap->counts.lock);
md_bitmap_file_unmap(&bitmap->storage);
bitmap->storage = store;
@@ -2560,7 +2561,7 @@ static int __bitmap_resize(struct bitmap *bitmap, sector_t blocks,
set_page_attr(bitmap, i, BITMAP_PAGE_DIRTY);
}
spin_unlock_irq(&bitmap->counts.lock);
-
+ mutex_unlock(&bitmap->mddev->bitmap_info.mutex);
if (!init) {
__bitmap_unplug(bitmap);
bitmap->mddev->pers->quiesce(bitmap->mddev, 0);
--
2.51.0
^ permalink raw reply related
* FAILED: Patch "md/bitmap: fix GPF in write_page caused by resize race" failed to apply to 6.6-stable tree
From: Sasha Levin @ 2026-03-01 1:34 UTC (permalink / raw)
To: stable, jinpu.wang; +Cc: Yu Kuai, linux-raid
The patch below does not apply to the 6.6-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
Thanks,
Sasha
------------------ original commit in Linus's tree ------------------
From 46ef85f854dfa9d5226b3c1c46493d79556c9589 Mon Sep 17 00:00:00 2001
From: Jack Wang <jinpu.wang@ionos.com>
Date: Tue, 20 Jan 2026 11:24:56 +0100
Subject: [PATCH] md/bitmap: fix GPF in write_page caused by resize race
A General Protection Fault occurs in write_page() during array resize:
RIP: 0010:write_page+0x22b/0x3c0 [md_mod]
This is a use-after-free race between bitmap_daemon_work() and
__bitmap_resize(). The daemon iterates over `bitmap->storage.filemap`
without locking, while the resize path frees that storage via
md_bitmap_file_unmap(). `quiesce()` does not stop the md thread,
allowing concurrent access to freed pages.
Fix by holding `mddev->bitmap_info.mutex` during the bitmap update.
Link: https://lore.kernel.org/linux-raid/20260120102456.25169-1-jinpu.wang@ionos.com
Closes: https://lore.kernel.org/linux-raid/CAMGffE=Mbfp=7xD_hYxXk1PAaCZNSEAVeQGKGy7YF9f2S4=NEA@mail.gmail.com/T/#u
Cc: stable@vger.kernel.org
Fixes: d60b479d177a ("md/bitmap: add bitmap_resize function to allow bitmap resizing.")
Signed-off-by: Jack Wang <jinpu.wang@ionos.com>
Signed-off-by: Yu Kuai <yukuai@fnnas.com>
---
drivers/md/md-bitmap.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/md/md-bitmap.c b/drivers/md/md-bitmap.c
index dbe4c4b9a1daf..1d4a050dab3ab 100644
--- a/drivers/md/md-bitmap.c
+++ b/drivers/md/md-bitmap.c
@@ -2453,6 +2453,7 @@ static int __bitmap_resize(struct bitmap *bitmap, sector_t blocks,
memcpy(page_address(store.sb_page),
page_address(bitmap->storage.sb_page),
sizeof(bitmap_super_t));
+ mutex_lock(&bitmap->mddev->bitmap_info.mutex);
spin_lock_irq(&bitmap->counts.lock);
md_bitmap_file_unmap(&bitmap->storage);
bitmap->storage = store;
@@ -2560,7 +2561,7 @@ static int __bitmap_resize(struct bitmap *bitmap, sector_t blocks,
set_page_attr(bitmap, i, BITMAP_PAGE_DIRTY);
}
spin_unlock_irq(&bitmap->counts.lock);
-
+ mutex_unlock(&bitmap->mddev->bitmap_info.mutex);
if (!init) {
__bitmap_unplug(bitmap);
bitmap->mddev->pers->quiesce(bitmap->mddev, 0);
--
2.51.0
^ permalink raw reply related
* FAILED: Patch "md/bitmap: fix GPF in write_page caused by resize race" failed to apply to 6.1-stable tree
From: Sasha Levin @ 2026-03-01 1:43 UTC (permalink / raw)
To: stable, jinpu.wang; +Cc: Yu Kuai, linux-raid
The patch below does not apply to the 6.1-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
Thanks,
Sasha
------------------ original commit in Linus's tree ------------------
From 46ef85f854dfa9d5226b3c1c46493d79556c9589 Mon Sep 17 00:00:00 2001
From: Jack Wang <jinpu.wang@ionos.com>
Date: Tue, 20 Jan 2026 11:24:56 +0100
Subject: [PATCH] md/bitmap: fix GPF in write_page caused by resize race
A General Protection Fault occurs in write_page() during array resize:
RIP: 0010:write_page+0x22b/0x3c0 [md_mod]
This is a use-after-free race between bitmap_daemon_work() and
__bitmap_resize(). The daemon iterates over `bitmap->storage.filemap`
without locking, while the resize path frees that storage via
md_bitmap_file_unmap(). `quiesce()` does not stop the md thread,
allowing concurrent access to freed pages.
Fix by holding `mddev->bitmap_info.mutex` during the bitmap update.
Link: https://lore.kernel.org/linux-raid/20260120102456.25169-1-jinpu.wang@ionos.com
Closes: https://lore.kernel.org/linux-raid/CAMGffE=Mbfp=7xD_hYxXk1PAaCZNSEAVeQGKGy7YF9f2S4=NEA@mail.gmail.com/T/#u
Cc: stable@vger.kernel.org
Fixes: d60b479d177a ("md/bitmap: add bitmap_resize function to allow bitmap resizing.")
Signed-off-by: Jack Wang <jinpu.wang@ionos.com>
Signed-off-by: Yu Kuai <yukuai@fnnas.com>
---
drivers/md/md-bitmap.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/md/md-bitmap.c b/drivers/md/md-bitmap.c
index dbe4c4b9a1daf..1d4a050dab3ab 100644
--- a/drivers/md/md-bitmap.c
+++ b/drivers/md/md-bitmap.c
@@ -2453,6 +2453,7 @@ static int __bitmap_resize(struct bitmap *bitmap, sector_t blocks,
memcpy(page_address(store.sb_page),
page_address(bitmap->storage.sb_page),
sizeof(bitmap_super_t));
+ mutex_lock(&bitmap->mddev->bitmap_info.mutex);
spin_lock_irq(&bitmap->counts.lock);
md_bitmap_file_unmap(&bitmap->storage);
bitmap->storage = store;
@@ -2560,7 +2561,7 @@ static int __bitmap_resize(struct bitmap *bitmap, sector_t blocks,
set_page_attr(bitmap, i, BITMAP_PAGE_DIRTY);
}
spin_unlock_irq(&bitmap->counts.lock);
-
+ mutex_unlock(&bitmap->mddev->bitmap_info.mutex);
if (!init) {
__bitmap_unplug(bitmap);
bitmap->mddev->pers->quiesce(bitmap->mddev, 0);
--
2.51.0
^ permalink raw reply related
* FAILED: Patch "md/bitmap: fix GPF in write_page caused by resize race" failed to apply to 5.15-stable tree
From: Sasha Levin @ 2026-03-01 1:52 UTC (permalink / raw)
To: stable, jinpu.wang; +Cc: Yu Kuai, linux-raid
The patch below does not apply to the 5.15-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
Thanks,
Sasha
------------------ original commit in Linus's tree ------------------
From 46ef85f854dfa9d5226b3c1c46493d79556c9589 Mon Sep 17 00:00:00 2001
From: Jack Wang <jinpu.wang@ionos.com>
Date: Tue, 20 Jan 2026 11:24:56 +0100
Subject: [PATCH] md/bitmap: fix GPF in write_page caused by resize race
A General Protection Fault occurs in write_page() during array resize:
RIP: 0010:write_page+0x22b/0x3c0 [md_mod]
This is a use-after-free race between bitmap_daemon_work() and
__bitmap_resize(). The daemon iterates over `bitmap->storage.filemap`
without locking, while the resize path frees that storage via
md_bitmap_file_unmap(). `quiesce()` does not stop the md thread,
allowing concurrent access to freed pages.
Fix by holding `mddev->bitmap_info.mutex` during the bitmap update.
Link: https://lore.kernel.org/linux-raid/20260120102456.25169-1-jinpu.wang@ionos.com
Closes: https://lore.kernel.org/linux-raid/CAMGffE=Mbfp=7xD_hYxXk1PAaCZNSEAVeQGKGy7YF9f2S4=NEA@mail.gmail.com/T/#u
Cc: stable@vger.kernel.org
Fixes: d60b479d177a ("md/bitmap: add bitmap_resize function to allow bitmap resizing.")
Signed-off-by: Jack Wang <jinpu.wang@ionos.com>
Signed-off-by: Yu Kuai <yukuai@fnnas.com>
---
drivers/md/md-bitmap.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/md/md-bitmap.c b/drivers/md/md-bitmap.c
index dbe4c4b9a1daf..1d4a050dab3ab 100644
--- a/drivers/md/md-bitmap.c
+++ b/drivers/md/md-bitmap.c
@@ -2453,6 +2453,7 @@ static int __bitmap_resize(struct bitmap *bitmap, sector_t blocks,
memcpy(page_address(store.sb_page),
page_address(bitmap->storage.sb_page),
sizeof(bitmap_super_t));
+ mutex_lock(&bitmap->mddev->bitmap_info.mutex);
spin_lock_irq(&bitmap->counts.lock);
md_bitmap_file_unmap(&bitmap->storage);
bitmap->storage = store;
@@ -2560,7 +2561,7 @@ static int __bitmap_resize(struct bitmap *bitmap, sector_t blocks,
set_page_attr(bitmap, i, BITMAP_PAGE_DIRTY);
}
spin_unlock_irq(&bitmap->counts.lock);
-
+ mutex_unlock(&bitmap->mddev->bitmap_info.mutex);
if (!init) {
__bitmap_unplug(bitmap);
bitmap->mddev->pers->quiesce(bitmap->mddev, 0);
--
2.51.0
^ permalink raw reply related
* FAILED: Patch "md/bitmap: fix GPF in write_page caused by resize race" failed to apply to 5.10-stable tree
From: Sasha Levin @ 2026-03-01 2:02 UTC (permalink / raw)
To: stable, jinpu.wang; +Cc: Yu Kuai, linux-raid
The patch below does not apply to the 5.10-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
Thanks,
Sasha
------------------ original commit in Linus's tree ------------------
From 46ef85f854dfa9d5226b3c1c46493d79556c9589 Mon Sep 17 00:00:00 2001
From: Jack Wang <jinpu.wang@ionos.com>
Date: Tue, 20 Jan 2026 11:24:56 +0100
Subject: [PATCH] md/bitmap: fix GPF in write_page caused by resize race
A General Protection Fault occurs in write_page() during array resize:
RIP: 0010:write_page+0x22b/0x3c0 [md_mod]
This is a use-after-free race between bitmap_daemon_work() and
__bitmap_resize(). The daemon iterates over `bitmap->storage.filemap`
without locking, while the resize path frees that storage via
md_bitmap_file_unmap(). `quiesce()` does not stop the md thread,
allowing concurrent access to freed pages.
Fix by holding `mddev->bitmap_info.mutex` during the bitmap update.
Link: https://lore.kernel.org/linux-raid/20260120102456.25169-1-jinpu.wang@ionos.com
Closes: https://lore.kernel.org/linux-raid/CAMGffE=Mbfp=7xD_hYxXk1PAaCZNSEAVeQGKGy7YF9f2S4=NEA@mail.gmail.com/T/#u
Cc: stable@vger.kernel.org
Fixes: d60b479d177a ("md/bitmap: add bitmap_resize function to allow bitmap resizing.")
Signed-off-by: Jack Wang <jinpu.wang@ionos.com>
Signed-off-by: Yu Kuai <yukuai@fnnas.com>
---
drivers/md/md-bitmap.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/md/md-bitmap.c b/drivers/md/md-bitmap.c
index dbe4c4b9a1daf..1d4a050dab3ab 100644
--- a/drivers/md/md-bitmap.c
+++ b/drivers/md/md-bitmap.c
@@ -2453,6 +2453,7 @@ static int __bitmap_resize(struct bitmap *bitmap, sector_t blocks,
memcpy(page_address(store.sb_page),
page_address(bitmap->storage.sb_page),
sizeof(bitmap_super_t));
+ mutex_lock(&bitmap->mddev->bitmap_info.mutex);
spin_lock_irq(&bitmap->counts.lock);
md_bitmap_file_unmap(&bitmap->storage);
bitmap->storage = store;
@@ -2560,7 +2561,7 @@ static int __bitmap_resize(struct bitmap *bitmap, sector_t blocks,
set_page_attr(bitmap, i, BITMAP_PAGE_DIRTY);
}
spin_unlock_irq(&bitmap->counts.lock);
-
+ mutex_unlock(&bitmap->mddev->bitmap_info.mutex);
if (!init) {
__bitmap_unplug(bitmap);
bitmap->mddev->pers->quiesce(bitmap->mddev, 0);
--
2.51.0
^ permalink raw reply related
* 4 TiB WD SN700 drives drop off of Sonnet Card
From: Justin Piszcz @ 2026-03-01 11:39 UTC (permalink / raw)
To: LKML, linux-nvme, linux-raid
Hello,
Kernel: 6.12.73
Distribution: Debian Stable Trixie
There are long outstanding issues with these WD Red SN700 4TiB drives
with an ASUS FlahsStor Gen1.
I have 16 drives on two x8 Sonnet boards and the same issue is
occurring across two different platforms. Are these drives completely
defective when used in a software raid configuration?
Does anyone have a specific kernel parameter to make these drives work
without dropping off the bus— or is it time to retire/replace these
drives? On various forums the below parameters had been tested
previously and did not help.
[Sun Mar 1 00:30:58 2026] nvme nvme0: controller is down; will reset:
CSTS=0xffffffff, PCI_STATUS=0xffff
[Sun Mar 1 00:30:58 2026] nvme nvme0: Does your device have a faulty
power saving mode enabled?
[Sun Mar 1 00:30:58 2026] nvme nvme0: Try
"nvme_core.default_ps_max_latency_us=0 pcie_aspm=off pcie_port_pm=off"
and report a bug
[Sun Mar 1 00:31:03 2026] nvme 0000:03:00.0: Unable to change power
state from D3cold to D0, device inaccessible
[Sun Mar 1 00:31:03 2026] nvme nvme0: Disabling device after reset failure: -19
[Sun Mar 1 00:31:03 2026] md/raid:md0: Disk failure on nvme0n1p1,
disabling device.
Justin
^ permalink raw reply
* Re: [PATCH 03/25] um/xor: don't override XOR_SELECT_TEMPLATE
From: Johannes Berg @ 2026-03-02 7:38 UTC (permalink / raw)
To: Eric Biggers, Christoph Hellwig
Cc: Andrew Morton, Richard Henderson, Matt Turner, Magnus Lindholm,
Russell King, Catalin Marinas, Will Deacon, Huacai Chen,
WANG Xuerui, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, David S. Miller, Andreas Larsson,
Richard Weinberger, Anton Ivanov, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Herbert Xu,
Dan Williams, Chris Mason, David Sterba, Arnd Bergmann, Song Liu,
Yu Kuai, Li Nan, linux-alpha, linux-kernel, linux-arm-kernel,
loongarch, linuxppc-dev, linux-riscv, linux-s390, sparclinux,
linux-um, linux-crypto, linux-btrfs, linux-arch, linux-raid
In-Reply-To: <20260228043006.GA65277@quark>
On Fri, 2026-02-27 at 20:30 -0800, Eric Biggers wrote:
> On Thu, Feb 26, 2026 at 07:10:15AM -0800, Christoph Hellwig wrote:
> > XOR_SELECT_TEMPLATE is only ever called with a NULL argument, so all the
> > ifdef'ery doesn't do anything. With our without this, the time travel
> > mode should work fine on CPUs that support AVX2, as the AVX2
> > implementation is forced in this case, and won't work otherwise.
>
[snip]
> I'm not following this change. Previously, in TT_MODE_INFCPU mode,
> XOR_SELECT_TEMPLATE(NULL) returned &xor_block_avx, &xor_block_sse_pf64,
> or &xor_block_8regs, causing the benchmark to be skipped. After this
> change, the benchmark starts being done on CPUs that don't support AVX.
Yeah the commit message is confusing - the change itself is really
trading one (potential?) issue (CPUs w/o AVX) against another old issue
(benchmark never terminates in TT_MODE_INFCPU).
However, since commit c055e3eae0f1 ("crypto: xor - use ktime for
template benchmarking") the latter issue doesn't even exist any more, so
it now works without it, though it doesn't really benchmark anything.
But that's fine too, nobody is going to be overly concerned about the
performance here, I think, and if so there's really no good way to fix
that other than providing a config option for an individual
implementation.
johannes
^ permalink raw reply
* Re: [PATCH] block: remove bdev_nonrot()
From: Jens Axboe @ 2026-03-02 21:04 UTC (permalink / raw)
To: Damien Le Moal, Paul Menzel
Cc: linux-block, Song Liu, Yu Kuai, linux-raid, Martin K . Petersen,
linux-scsi, target-devel, David Sterba, linux-btrfs,
Theodore Ts'o, linux-ext4, Andreas Dilger, Andrew Morton,
Chris Li, Kairui Song, linux-mm
In-Reply-To: <a2993605-2cdb-42b2-85fc-b071f07af4c3@kernel.org>
On 2/26/26 5:27 AM, Damien Le Moal wrote:
> > Is it worth the change, as it looks quite subjective if you prefer the
>> one or the other way?
>
> I think it is a nice cleanup, but I will let Jens and other
> maintainers decide on the worth of this patch.
It's a bit of pointless churn, but I kind of suspected this was coming
when we added the bdev_rot() helper and now had both of them. So I guess
we may as well finish it, as we're half-way there anyway.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH] block: remove bdev_nonrot()
From: Jens Axboe @ 2026-03-02 21:04 UTC (permalink / raw)
To: linux-block, Song Liu, Yu Kuai, linux-raid, Martin K . Petersen,
linux-scsi, target-devel, David Sterba, linux-btrfs,
Theodore Ts'o, linux-ext4, Andreas Dilger, Andrew Morton,
Chris Li, Kairui Song, linux-mm, Damien Le Moal
In-Reply-To: <20260226075448.2229655-1-dlemoal@kernel.org>
On Thu, 26 Feb 2026 16:54:48 +0900, Damien Le Moal wrote:
> bdev_nonrot() is simply the negative return value of bdev_rot().
> So replace all call sites of bdev_nonrot() with calls to bdev_rot()
> and remove bdev_nonrot().
>
>
Applied, thanks!
[1/1] block: remove bdev_nonrot()
commit: d47f7c173262bbeb09645ec72bf91755eed6b1b3
Best regards,
--
Jens Axboe
^ permalink raw reply
* [PATCH v3] md/raid10: fix deadlock with check operation and nowait requests
From: Josh Hunt @ 2026-03-03 0:56 UTC (permalink / raw)
To: song, yukuai, linan122, linux-raid; +Cc: ncroxon, Josh Hunt, stable
When an array check is running it will raise the barrier at which point
normal requests will become blocked and increment the nr_pending value to
signal there is work pending inside of wait_barrier(). NOWAIT requests
do not block and so will return immediately with an error, and additionally
do not increment nr_pending in wait_barrier(). Upstream change
43806c3d5b9b ("raid10: cleanup memleak at raid10_make_request") added a
call to raid_end_bio_io() to fix a memory leak when NOWAIT requests hit
this condition. raid_end_bio_io() eventually calls allow_barrier() and
it will unconditionally do an atomic_dec_and_test(&conf->nr_pending) even
though the corresponding increment on nr_pending didn't happen in the
NOWAIT case.
This can be easily seen by starting a check operation while an application is
doing nowait IO on the same array. This results in a deadlocked state due to
nr_pending value underflowing and so the md resync thread gets stuck waiting
for nr_pending to == 0.
Output of r10conf state of the array when we hit this condition:
crash> struct r10conf.barrier,nr_pending,nr_waiting,nr_queued <addr of r10conf>
barrier = 1,
nr_pending = {
counter = -41
},
nr_waiting = 15,
nr_queued = 0,
Example of md_sync thread stuck waiting on raise_barrier() and other requests
stuck in wait_barrier():
md1_resync
[<0>] raise_barrier+0xce/0x1c0
[<0>] raid10_sync_request+0x1ca/0x1ed0
[<0>] md_do_sync+0x779/0x1110
[<0>] md_thread+0x90/0x160
[<0>] kthread+0xbe/0xf0
[<0>] ret_from_fork+0x34/0x50
[<0>] ret_from_fork_asm+0x1a/0x30
kworker/u1040:2+flush-253:4
[<0>] wait_barrier+0x1de/0x220
[<0>] regular_request_wait+0x30/0x180
[<0>] raid10_make_request+0x261/0x1000
[<0>] md_handle_request+0x13b/0x230
[<0>] __submit_bio+0x107/0x1f0
[<0>] submit_bio_noacct_nocheck+0x16f/0x390
[<0>] ext4_io_submit+0x24/0x40
[<0>] ext4_do_writepages+0x254/0xc80
[<0>] ext4_writepages+0x84/0x120
[<0>] do_writepages+0x7a/0x260
[<0>] __writeback_single_inode+0x3d/0x300
[<0>] writeback_sb_inodes+0x1dd/0x470
[<0>] __writeback_inodes_wb+0x4c/0xe0
[<0>] wb_writeback+0x18b/0x2d0
[<0>] wb_workfn+0x2a1/0x400
[<0>] process_one_work+0x149/0x330
[<0>] worker_thread+0x2d2/0x410
[<0>] kthread+0xbe/0xf0
[<0>] ret_from_fork+0x34/0x50
[<0>] ret_from_fork_asm+0x1a/0x30
Fixes: 43806c3d5b9b ("raid10: cleanup memleak at raid10_make_request")
Cc: stable@vger.kernel.org
Signed-off-by: Josh Hunt <johunt@akamai.com>
---
v3:
* Call free_r10bio() as per Yu Kuai's suggestion
---
drivers/md/raid10.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index 9debb20cf129..b4892c5d571c 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -1184,7 +1184,7 @@ static void raid10_read_request(struct mddev *mddev, struct bio *bio,
}
if (!regular_request_wait(mddev, conf, bio, r10_bio->sectors)) {
- raid_end_bio_io(r10_bio);
+ free_r10bio(r10_bio);
return;
}
@@ -1372,7 +1372,7 @@ static void raid10_write_request(struct mddev *mddev, struct bio *bio,
sectors = r10_bio->sectors;
if (!regular_request_wait(mddev, conf, bio, sectors)) {
- raid_end_bio_io(r10_bio);
+ free_r10bio(r10_bio);
return;
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2] md/raid10: fix deadlock with check operation and nowait requests
From: Josh Hunt @ 2026-03-03 0:54 UTC (permalink / raw)
To: yukuai, song, linan122, linux-raid; +Cc: ncroxon, stable
In-Reply-To: <f382704c-8a3a-4c94-8fc0-46938e720894@fnnas.com>
On 2/25/26 9:24 PM, Yu Kuai wrote:
> !-------------------------------------------------------------------|
> This Message Is From an External Sender
> This message came from outside your organization.
> |-------------------------------------------------------------------!
>
> Hi,
>
> 在 2026/2/11 0:51, Josh Hunt 写道:
>> When an array check is running it will raise the barrier at which point
>> normal requests will become blocked and increment the nr_pending value to
>> signal there is work pending inside of wait_barrier(). NOWAIT requests
>> do not block and so will return immediately with an error, and additionally
>> do not increment nr_pending in wait_barrier(). Upstream change
>> 43806c3d5b9b ("raid10: cleanup memleak at raid10_make_request") added a
>> call to raid_end_bio_io() to fix a memory leak when NOWAIT requests hit
>> this condition. raid_end_bio_io() eventually calls allow_barrier() and
>> it will unconditionally do an atomic_dec_and_test(&conf->nr_pending) even
>> though the corresponding increment on nr_pending didn't happen in the
>> NOWAIT case.
>>
>> This can be easily seen by starting a check operation while an application is
>> doing nowait IO on the same array. This results in a deadlocked state due to
>> nr_pending value underflowing and so the md resync thread gets stuck waiting
>> for nr_pending to == 0.
>>
>> Output of r10conf state of the array when we hit this condition:
>>
>> crash> struct r10conf.barrier,nr_pending,nr_waiting,nr_queued <addr of r10conf>
>> barrier = 1,
>> nr_pending = {
>> counter = -41
>> },
>> nr_waiting = 15,
>> nr_queued = 0,
>>
>> Example of md_sync thread stuck waiting on raise_barrier() and other requests
>> stuck in wait_barrier():
>>
>> md1_resync
>> [<0>] raise_barrier+0xce/0x1c0
>> [<0>] raid10_sync_request+0x1ca/0x1ed0
>> [<0>] md_do_sync+0x779/0x1110
>> [<0>] md_thread+0x90/0x160
>> [<0>] kthread+0xbe/0xf0
>> [<0>] ret_from_fork+0x34/0x50
>> [<0>] ret_from_fork_asm+0x1a/0x30
>>
>> kworker/u1040:2+flush-253:4
>> [<0>] wait_barrier+0x1de/0x220
>> [<0>] regular_request_wait+0x30/0x180
>> [<0>] raid10_make_request+0x261/0x1000
>> [<0>] md_handle_request+0x13b/0x230
>> [<0>] __submit_bio+0x107/0x1f0
>> [<0>] submit_bio_noacct_nocheck+0x16f/0x390
>> [<0>] ext4_io_submit+0x24/0x40
>> [<0>] ext4_do_writepages+0x254/0xc80
>> [<0>] ext4_writepages+0x84/0x120
>> [<0>] do_writepages+0x7a/0x260
>> [<0>] __writeback_single_inode+0x3d/0x300
>> [<0>] writeback_sb_inodes+0x1dd/0x470
>> [<0>] __writeback_inodes_wb+0x4c/0xe0
>> [<0>] wb_writeback+0x18b/0x2d0
>> [<0>] wb_workfn+0x2a1/0x400
>> [<0>] process_one_work+0x149/0x330
>> [<0>] worker_thread+0x2d2/0x410
>> [<0>] kthread+0xbe/0xf0
>> [<0>] ret_from_fork+0x34/0x50
>> [<0>] ret_from_fork_asm+0x1a/0x30
>>
>> Fixes: 43806c3d5b9b ("raid10: cleanup memleak at raid10_make_request")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Josh Hunt <johunt@akamai.com>
>> ---
>> drivers/md/raid10.c | 40 +++++++++++++++++++++++++++-------------
>> 1 file changed, 27 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
>> index 9debb20cf129..b05066dde693 100644
>> --- a/drivers/md/raid10.c
>> +++ b/drivers/md/raid10.c
>> @@ -68,6 +68,7 @@
>> */
>>
>> static void allow_barrier(struct r10conf *conf);
>> +static void allow_barrier_nowait(struct r10conf *conf);
>> static void lower_barrier(struct r10conf *conf);
>> static int _enough(struct r10conf *conf, int previous, int ignore);
>> static int enough(struct r10conf *conf, int ignore);
>> @@ -317,7 +318,7 @@ static void reschedule_retry(struct r10bio *r10_bio)
>> * operation and are ready to return a success/failure code to the buffer
>> * cache layer.
>> */
>> -static void raid_end_bio_io(struct r10bio *r10_bio)
>> +static void raid_end_bio_io(struct r10bio *r10_bio, bool adjust_pending)
>> {
>> struct bio *bio = r10_bio->master_bio;
>> struct r10conf *conf = r10_bio->mddev->private;
>> @@ -332,7 +333,10 @@ static void raid_end_bio_io(struct r10bio *r10_bio)
>> * Wake up any possible resync thread that waits for the device
>> * to go idle.
>> */
>> - allow_barrier(conf);
>> + if (adjust_pending)
>> + allow_barrier(conf);
>> + else
>> + allow_barrier_nowait(conf);
>>
>> free_r10bio(r10_bio);
>> }
>> @@ -414,7 +418,7 @@ static void raid10_end_read_request(struct bio *bio)
>> uptodate = 1;
>> }
>> if (uptodate) {
>> - raid_end_bio_io(r10_bio);
>> + raid_end_bio_io(r10_bio, true);
>> rdev_dec_pending(rdev, conf->mddev);
>> } else {
>> /*
>> @@ -446,7 +450,7 @@ static void one_write_done(struct r10bio *r10_bio)
>> if (test_bit(R10BIO_MadeGood, &r10_bio->state))
>> reschedule_retry(r10_bio);
>> else
>> - raid_end_bio_io(r10_bio);
>> + raid_end_bio_io(r10_bio, true);
>> }
>> }
>> }
>> @@ -1030,13 +1034,23 @@ static bool wait_barrier(struct r10conf *conf, bool nowait)
>> return ret;
>> }
>>
>> -static void allow_barrier(struct r10conf *conf)
>> +static void __allow_barrier(struct r10conf *conf, bool adjust_pending)
>> {
>> - if ((atomic_dec_and_test(&conf->nr_pending)) ||
>> + if ((adjust_pending && atomic_dec_and_test(&conf->nr_pending)) ||
>> (conf->array_freeze_pending))
>> wake_up_barrier(conf);
>> }
>>
>> +static void allow_barrier(struct r10conf *conf)
>> +{
>> + __allow_barrier(conf, true);
>> +}
>> +
>> +static void allow_barrier_nowait(struct r10conf *conf)
>> +{
>> + __allow_barrier(conf, false);
>> +}
>> +
>> static void freeze_array(struct r10conf *conf, int extra)
>> {
>> /* stop syncio and normal IO and wait for everything to
>> @@ -1184,7 +1198,7 @@ static void raid10_read_request(struct mddev *mddev, struct bio *bio,
>> }
>>
>> if (!regular_request_wait(mddev, conf, bio, r10_bio->sectors)) {
>> - raid_end_bio_io(r10_bio);
>> + raid_end_bio_io(r10_bio, false);
>> return;
>> }
>>
>> @@ -1195,7 +1209,7 @@ static void raid10_read_request(struct mddev *mddev, struct bio *bio,
>> mdname(mddev), b,
>> (unsigned long long)r10_bio->sector);
>> }
>> - raid_end_bio_io(r10_bio);
>> + raid_end_bio_io(r10_bio, true);
>> return;
>> }
>> if (err_rdev)
>> @@ -1240,7 +1254,7 @@ static void raid10_read_request(struct mddev *mddev, struct bio *bio,
>> return;
>> err_handle:
>> atomic_dec(&rdev->nr_pending);
>> - raid_end_bio_io(r10_bio);
>> + raid_end_bio_io(r10_bio, true);
>> }
>>
>> static void raid10_write_one_disk(struct mddev *mddev, struct r10bio *r10_bio,
>> @@ -1372,7 +1386,7 @@ static void raid10_write_request(struct mddev *mddev, struct bio *bio,
>>
>> sectors = r10_bio->sectors;
>> if (!regular_request_wait(mddev, conf, bio, sectors)) {
>> - raid_end_bio_io(r10_bio);
>> + raid_end_bio_io(r10_bio, false);
>
> There really is problem, however the analyze seems a bit wrong.
>
> The master_bio is already handled with bio_wouldblock_error(), it's wrong
> to call raid_end_bio_io() directly. Looks like this problem can be fixed by
> calling free_r10bio() instead.
Thanks for the feedback. I tried this and indeed it does also fix the
issue for me so will send over a v3 here shortly. Appreciate the help!
>
>> return;
>> }
>>
>> @@ -1523,7 +1537,7 @@ static void raid10_write_request(struct mddev *mddev, struct bio *bio,
>> }
>> }
>>
>> - raid_end_bio_io(r10_bio);
>> + raid_end_bio_io(r10_bio, true);
>> }
>>
>> static void __make_request(struct mddev *mddev, struct bio *bio, int sectors)
>> @@ -2952,7 +2966,7 @@ static void handle_write_completed(struct r10conf *conf, struct r10bio *r10_bio)
>> if (test_bit(R10BIO_WriteError,
>> &r10_bio->state))
>> close_write(r10_bio);
>> - raid_end_bio_io(r10_bio);
>> + raid_end_bio_io(r10_bio, true);
>> }
>> }
>> }
>> @@ -2987,7 +3001,7 @@ static void raid10d(struct md_thread *thread)
>> if (test_bit(R10BIO_WriteError,
>> &r10_bio->state))
>> close_write(r10_bio);
>> - raid_end_bio_io(r10_bio);
>> + raid_end_bio_io(r10_bio, true);
>> }
>> }
>>
>
Josh
^ permalink raw reply
* [PATCH] md/raid5: clean up stale declaration and misplaced comment
From: Chen Cheng @ 2026-03-03 11:16 UTC (permalink / raw)
To: Song Liu, Yu Kuai; +Cc: Li Nan, linux-raid
Remove the unused md_raid5_kick_device() declaration from raid5.h -
no definition exists for this function.
Move the handle_stripe() documentation comment from above
analyse_stripe() to directly above handle_stripe() where it belongs.
Signed-off-by: Chen Cheng <chencheng@fnnas.com>
---
drivers/md/raid5.c | 26 ++++++++++++--------------
drivers/md/raid5.h | 1 -
2 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index a8e8d431071b..48504b0e496b 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -4594,20 +4594,6 @@ static void handle_stripe_expansion(struct r5conf *conf, struct stripe_head *sh)
async_tx_quiesce(&tx);
}
-/*
- * handle_stripe - do things to a stripe.
- *
- * We lock the stripe by setting STRIPE_ACTIVE and then examine the
- * state of various bits to see what needs to be done.
- * Possible results:
- * return some read requests which now have data
- * return some write requests which are safely on storage
- * schedule a read on some buffers
- * schedule a write of some buffers
- * return confirmation of parity correctness
- *
- */
-
static void analyse_stripe(struct stripe_head *sh, struct stripe_head_state *s)
{
struct r5conf *conf = sh->raid_conf;
@@ -4901,6 +4887,18 @@ static void break_stripe_batch_list(struct stripe_head *head_sh,
set_bit(STRIPE_HANDLE, &head_sh->state);
}
+/*
+ * handle_stripe - do things to a stripe.
+ *
+ * We lock the stripe by setting STRIPE_ACTIVE and then examine the
+ * state of various bits to see what needs to be done.
+ * Possible results:
+ * return some read requests which now have data
+ * return some write requests which are safely on storage
+ * schedule a read on some buffers
+ * schedule a write of some buffers
+ * return confirmation of parity correctness
+ */
static void handle_stripe(struct stripe_head *sh)
{
struct stripe_head_state s;
diff --git a/drivers/md/raid5.h b/drivers/md/raid5.h
index 110b1c2d0a86..1c7b710fc9c1 100644
--- a/drivers/md/raid5.h
+++ b/drivers/md/raid5.h
@@ -801,7 +801,6 @@ raid5_get_dev_page(struct stripe_head *sh, int disk_idx)
}
#endif
-void md_raid5_kick_device(struct r5conf *conf);
int raid5_set_cache_size(struct mddev *mddev, int size);
sector_t raid5_compute_blocknr(struct stripe_head *sh, int i, int previous);
void raid5_release_stripe(struct stripe_head *sh);
--
2.51.0
^ permalink raw reply related
* [PATCH 0/3] md: bitmap grow fixes
From: Su Yue @ 2026-03-03 3:37 UTC (permalink / raw)
To: linux-raid; +Cc: song, xni, linan122, yukuai, heming.zhao, l, Su Yue
Hi, This series is to fixes bugs exposed by mdadm/clustermd-autotest.
The bugs are not cluster md only but also bitmap related.
I'll find time to add test cases to mdadm. Thanks.
Su Yue (3):
md: restore bitmap/location to fix wrong bitmap offset while growing
md: call md_bitmap_create,destroy in location_store
md: remove member group from bitmap_operations
drivers/md/md-bitmap.c | 45 +++++++++++++++++++++++++++++++++++-----
drivers/md/md-bitmap.h | 5 ++++-
drivers/md/md-llbitmap.c | 13 +++++++++++-
drivers/md/md.c | 20 ++++++++++++------
drivers/md/md.h | 2 ++
5 files changed, 72 insertions(+), 13 deletions(-)
--
2.53.0
^ permalink raw reply
* [PATCH 1/3] md: restore bitmap/location to fix wrong bitmap offset while growing
From: Su Yue @ 2026-03-03 3:37 UTC (permalink / raw)
To: linux-raid; +Cc: song, xni, linan122, yukuai, heming.zhao, l, Su Yue
In-Reply-To: <20260303033731.83885-1-glass.su@suse.com>
Before commit fb8cc3b0d9db ("md/md-bitmap: delay registration of bitmap_ops until creating bitmap")
if CONFIG_MD_BITMAP is enabled, both bitmap none, internal and clustered have
the sysfs file bitmap/location.
After the commit, if bitmap is none, bitmap/location doesn't exist anymore.
It breaks 'grow' behavior of a md array of madam with MD_FEATURE_BITMAP_OFFSET.
Take level=mirror and metadata=1.2 as an example:
$ mdadm --create /dev/md0 -f --bitmap=none --raid-devices=2 --level=mirror \
--metadata=1.2 /dev/vdd /dev/vde
$ mdadm --grow /dev/md0 --bitmap=internal
$ cat /sys/block/md0/md/bitmap/location
Before:+8
After: +2
While growing bitmap from none to internal, clustered and llbitmap,
mdadm/Grow.c:Grow_addbitmap() tries to detect bitmap/location first.
1)If bitmap/location exists, it sets bitmap/location after getinfo_super().
2)If bitmap/location doesn't exist, mdadm just calls md_set_array_info() then
mddev->bitmap_info.default_offset will be used.
Situation can be worse if growing none to clustered, bitmap offset of the node
calling `madm --grow` will be changed but the other node are reading bitmap sb from
the old location.
Here restore sysfs file bitmap/location for ID_BITMAP_NONE and ID_BITMAP.
And it d adds the entry for llbitmap too.
New attribute_group md_bitmap_common_group is introduced and created in
md_alloc() as before commit fb8cc3b0d9db.
Add New operations register_group and unregister_group to struct bitmap_operations.
Fixes: fb8cc3b0d9db ("md/md-bitmap: delay registration of bitmap_ops until creating bitmap")
Signed-off-by: Su Yue <glass.su@suse.com>
---
drivers/md/md-bitmap.c | 32 +++++++++++++++++++++++++++++++-
drivers/md/md-bitmap.h | 5 +++++
drivers/md/md-llbitmap.c | 13 +++++++++++++
drivers/md/md.c | 16 ++++++++++++----
4 files changed, 61 insertions(+), 5 deletions(-)
diff --git a/drivers/md/md-bitmap.c b/drivers/md/md-bitmap.c
index 83378c033c72..8ff1dc94ed78 100644
--- a/drivers/md/md-bitmap.c
+++ b/drivers/md/md-bitmap.c
@@ -2956,7 +2956,6 @@ __ATTR(max_backlog_used, S_IRUGO | S_IWUSR,
behind_writes_used_show, behind_writes_used_reset);
static struct attribute *md_bitmap_attrs[] = {
- &bitmap_location.attr,
&bitmap_space.attr,
&bitmap_timeout.attr,
&bitmap_backlog.attr,
@@ -2967,11 +2966,40 @@ static struct attribute *md_bitmap_attrs[] = {
NULL
};
+static struct attribute *md_bitmap_common_attrs[] = {
+ &bitmap_location.attr,
+ NULL
+};
+
static struct attribute_group md_bitmap_group = {
.name = "bitmap",
.attrs = md_bitmap_attrs,
};
+static struct attribute_group md_bitmap_common_group = {
+ .name = "bitmap",
+ .attrs = md_bitmap_common_attrs,
+};
+
+int md_sysfs_create_common_group(struct mddev *mddev)
+{
+ return sysfs_create_group(&mddev->kobj, &md_bitmap_common_group);
+}
+
+static int bitmap_register_group(struct mddev *mddev)
+{
+ /*
+ * md_bitmap_group and md_bitmap_common_group are using same name
+ * 'bitmap'.
+ */
+ return sysfs_merge_group(&mddev->kobj, &md_bitmap_group);
+}
+
+static void bitmap_unregister_group(struct mddev *mddev)
+{
+ sysfs_unmerge_group(&mddev->kobj, &md_bitmap_group);
+}
+
static struct bitmap_operations bitmap_ops = {
.head = {
.type = MD_BITMAP,
@@ -3013,6 +3041,8 @@ static struct bitmap_operations bitmap_ops = {
.set_pages = bitmap_set_pages,
.free = md_bitmap_free,
+ .register_group = bitmap_register_group,
+ .unregister_group = bitmap_unregister_group,
.group = &md_bitmap_group,
};
diff --git a/drivers/md/md-bitmap.h b/drivers/md/md-bitmap.h
index b42a28fa83a0..371791e9011d 100644
--- a/drivers/md/md-bitmap.h
+++ b/drivers/md/md-bitmap.h
@@ -125,6 +125,9 @@ struct bitmap_operations {
void (*set_pages)(void *data, unsigned long pages);
void (*free)(void *data);
+ int (*register_group)(struct mddev *mddev);
+ void (*unregister_group)(struct mddev *mddev);
+
struct attribute_group *group;
};
@@ -169,6 +172,8 @@ static inline void md_bitmap_end_sync(struct mddev *mddev, sector_t offset,
mddev->bitmap_ops->end_sync(mddev, offset, blocks);
}
+int md_sysfs_create_common_group(struct mddev *mddev);
+
#ifdef CONFIG_MD_BITMAP
int md_bitmap_init(void);
void md_bitmap_exit(void);
diff --git a/drivers/md/md-llbitmap.c b/drivers/md/md-llbitmap.c
index bf398d7476b3..24ff5f7f8751 100644
--- a/drivers/md/md-llbitmap.c
+++ b/drivers/md/md-llbitmap.c
@@ -1561,6 +1561,16 @@ static struct attribute_group md_llbitmap_group = {
.attrs = md_llbitmap_attrs,
};
+static int llbitmap_register_group(struct mddev *mddev)
+{
+ return sysfs_create_group(&mddev->kobj, &md_llbitmap_group);
+}
+
+static void llbitmap_unregister_group(struct mddev *mddev)
+{
+ sysfs_remove_group(&mddev->kobj, &md_llbitmap_group);
+}
+
static struct bitmap_operations llbitmap_ops = {
.head = {
.type = MD_BITMAP,
@@ -1597,6 +1607,9 @@ static struct bitmap_operations llbitmap_ops = {
.dirty_bits = llbitmap_dirty_bits,
.write_all = llbitmap_write_all,
+ .register_group = llbitmap_register_group,
+ .unregister_group = llbitmap_unregister_group,
+
.group = &md_llbitmap_group,
};
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 3ce6f9e9d38e..ab969e950ea8 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -703,8 +703,8 @@ static bool mddev_set_bitmap_ops(struct mddev *mddev)
mddev->bitmap_ops = (void *)head;
xa_unlock(&md_submodule);
- if (!mddev_is_dm(mddev) && mddev->bitmap_ops->group) {
- if (sysfs_create_group(&mddev->kobj, mddev->bitmap_ops->group))
+ if (!mddev_is_dm(mddev) && mddev->bitmap_ops->register_group) {
+ if (mddev->bitmap_ops->register_group(mddev))
pr_warn("md: cannot register extra bitmap attributes for %s\n",
mdname(mddev));
else
@@ -724,8 +724,8 @@ static bool mddev_set_bitmap_ops(struct mddev *mddev)
static void mddev_clear_bitmap_ops(struct mddev *mddev)
{
if (!mddev_is_dm(mddev) && mddev->bitmap_ops &&
- mddev->bitmap_ops->group)
- sysfs_remove_group(&mddev->kobj, mddev->bitmap_ops->group);
+ mddev->bitmap_ops->unregister_group)
+ mddev->bitmap_ops->unregister_group(mddev);
mddev->bitmap_ops = NULL;
}
@@ -6369,6 +6369,14 @@ struct mddev *md_alloc(dev_t dev, char *name)
return ERR_PTR(error);
}
+ /*
+ * md_sysfs_remove_common_group is not needed because mddev_delayed_delete
+ * calls kobject_put(&mddev->kobj) if mddev is to be deleted.
+ */
+ if (md_sysfs_create_common_group(mddev))
+ pr_warn("md: cannot register common bitmap attributes for %s\n",
+ mdname(mddev));
+
kobject_uevent(&mddev->kobj, KOBJ_ADD);
mddev->sysfs_state = sysfs_get_dirent_safe(mddev->kobj.sd, "array_state");
mddev->sysfs_level = sysfs_get_dirent_safe(mddev->kobj.sd, "level");
--
2.53.0
^ permalink raw reply related
* [PATCH 2/3] md: call md_bitmap_create,destroy in location_store
From: Su Yue @ 2026-03-03 3:37 UTC (permalink / raw)
To: linux-raid; +Cc: song, xni, linan122, yukuai, heming.zhao, l, Su Yue
In-Reply-To: <20260303033731.83885-1-glass.su@suse.com>
If commit
'md: restore bitmap/location to fix wrong bitmap offset while growing'
is applied, mdadm will call update_array_info() while growing bitmap from
none to internal via location_store(). md_bitmap_create() is needed to set
mddev->bitmap_ops otherwise mddev->bitmap_ops->get_stats() in
update_array_info() will trigger kernel NULL pointer dereference.
Fixes: fb8cc3b0d9db ("md/md-bitmap: delay registration of bitmap_ops until creating bitmap")
Signed-off-by: Su Yue <glass.su@suse.com>
---
drivers/md/md-bitmap.c | 12 +++++++++---
drivers/md/md.c | 4 ++--
drivers/md/md.h | 2 ++
3 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/md/md-bitmap.c b/drivers/md/md-bitmap.c
index 8ff1dc94ed78..8abec00496b4 100644
--- a/drivers/md/md-bitmap.c
+++ b/drivers/md/md-bitmap.c
@@ -2618,7 +2618,7 @@ location_store(struct mddev *mddev, const char *buf, size_t len)
goto out;
}
- bitmap_destroy(mddev);
+ md_bitmap_destroy(mddev);
mddev->bitmap_info.offset = 0;
if (mddev->bitmap_info.file) {
struct file *f = mddev->bitmap_info.file;
@@ -2653,15 +2653,21 @@ location_store(struct mddev *mddev, const char *buf, size_t len)
goto out;
}
+ /*
+ * lockless bitmap shoudle have set bitmap_id
+ * using bitmap_type, so always ID_BITMAP.
+ */
+ if (mddev->bitmap_id == ID_BITMAP_NONE)
+ mddev->bitmap_id = ID_BITMAP;
mddev->bitmap_info.offset = offset;
- rv = bitmap_create(mddev);
+ rv = md_bitmap_create(mddev);
if (rv)
goto out;
rv = bitmap_load(mddev);
if (rv) {
mddev->bitmap_info.offset = 0;
- bitmap_destroy(mddev);
+ md_bitmap_destroy(mddev);
goto out;
}
}
diff --git a/drivers/md/md.c b/drivers/md/md.c
index ab969e950ea8..80beaff5ad39 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -6455,7 +6455,7 @@ static void md_safemode_timeout(struct timer_list *t)
static int start_dirty_degraded;
-static int md_bitmap_create(struct mddev *mddev)
+int md_bitmap_create(struct mddev *mddev)
{
if (mddev->bitmap_id == ID_BITMAP_NONE)
return -EINVAL;
@@ -6466,7 +6466,7 @@ static int md_bitmap_create(struct mddev *mddev)
return mddev->bitmap_ops->create(mddev);
}
-static void md_bitmap_destroy(struct mddev *mddev)
+void md_bitmap_destroy(struct mddev *mddev)
{
if (!md_bitmap_registered(mddev))
return;
diff --git a/drivers/md/md.h b/drivers/md/md.h
index ac84289664cd..ed69244af00d 100644
--- a/drivers/md/md.h
+++ b/drivers/md/md.h
@@ -895,6 +895,8 @@ static inline void safe_put_page(struct page *p)
int register_md_submodule(struct md_submodule_head *msh);
void unregister_md_submodule(struct md_submodule_head *msh);
+int md_bitmap_create(struct mddev *mddev);
+void md_bitmap_destroy(struct mddev *mddev);
extern struct md_thread *md_register_thread(
void (*run)(struct md_thread *thread),
--
2.53.0
^ permalink raw reply related
* [PATCH 3/3] md: remove member group from bitmap_operations
From: Su Yue @ 2026-03-03 3:37 UTC (permalink / raw)
To: linux-raid; +Cc: song, xni, linan122, yukuai, heming.zhao, l, Su Yue
In-Reply-To: <20260303033731.83885-1-glass.su@suse.com>
The member is unused now so remove it.
Signed-off-by: Su Yue <glass.su@suse.com>
---
drivers/md/md-bitmap.c | 1 -
drivers/md/md-bitmap.h | 2 --
drivers/md/md-llbitmap.c | 2 --
3 files changed, 5 deletions(-)
diff --git a/drivers/md/md-bitmap.c b/drivers/md/md-bitmap.c
index 8abec00496b4..bb04e3c17043 100644
--- a/drivers/md/md-bitmap.c
+++ b/drivers/md/md-bitmap.c
@@ -3049,7 +3049,6 @@ static struct bitmap_operations bitmap_ops = {
.register_group = bitmap_register_group,
.unregister_group = bitmap_unregister_group,
- .group = &md_bitmap_group,
};
int md_bitmap_init(void)
diff --git a/drivers/md/md-bitmap.h b/drivers/md/md-bitmap.h
index 371791e9011d..c81489aaa767 100644
--- a/drivers/md/md-bitmap.h
+++ b/drivers/md/md-bitmap.h
@@ -127,8 +127,6 @@ struct bitmap_operations {
int (*register_group)(struct mddev *mddev);
void (*unregister_group)(struct mddev *mddev);
-
- struct attribute_group *group;
};
/* the bitmap API */
diff --git a/drivers/md/md-llbitmap.c b/drivers/md/md-llbitmap.c
index 24ff5f7f8751..78f5fafd59ba 100644
--- a/drivers/md/md-llbitmap.c
+++ b/drivers/md/md-llbitmap.c
@@ -1609,8 +1609,6 @@ static struct bitmap_operations llbitmap_ops = {
.register_group = llbitmap_register_group,
.unregister_group = llbitmap_unregister_group,
-
- .group = &md_llbitmap_group,
};
int md_llbitmap_init(void)
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] block: remove bdev_nonrot()
From: Hannes Reinecke @ 2026-03-03 7:05 UTC (permalink / raw)
To: Damien Le Moal, Jens Axboe, linux-block, Song Liu, Yu Kuai,
linux-raid, Martin K . Petersen, linux-scsi, target-devel,
David Sterba, linux-btrfs, Theodore Ts'o, linux-ext4,
Andreas Dilger, Andrew Morton, Chris Li, Kairui Song, linux-mm
In-Reply-To: <20260226075448.2229655-1-dlemoal@kernel.org>
On 2/26/26 08:54, Damien Le Moal wrote:
> bdev_nonrot() is simply the negative return value of bdev_rot().
> So replace all call sites of bdev_nonrot() with calls to bdev_rot()
> and remove bdev_nonrot().
>
> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
> ---
> drivers/md/raid1.c | 2 +-
> drivers/md/raid10.c | 2 +-
> drivers/md/raid5.c | 2 +-
> drivers/target/target_core_file.c | 2 +-
> drivers/target/target_core_iblock.c | 2 +-
> fs/btrfs/volumes.c | 4 ++--
> fs/ext4/mballoc-test.c | 2 +-
> fs/ext4/mballoc.c | 2 +-
> include/linux/blkdev.h | 5 -----
> mm/swapfile.c | 2 +-
> 10 files changed, 10 insertions(+), 15 deletions(-)
>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
^ permalink raw reply
* Re: [PATCH 01/25] xor: assert that xor_blocks is not called from interrupt context
From: Christoph Hellwig @ 2026-03-03 16:00 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Christoph Hellwig, Andrew Morton, Richard Henderson, Matt Turner,
Magnus Lindholm, Russell King, Catalin Marinas, Will Deacon,
Huacai Chen, WANG Xuerui, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, David S. Miller, Andreas Larsson,
Richard Weinberger, Anton Ivanov, Johannes Berg, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Herbert Xu, Dan Williams, Chris Mason, David Sterba,
Arnd Bergmann, Song Liu, Yu Kuai, Li Nan, linux-alpha,
linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, linux-s390, sparclinux, linux-um, linux-crypto,
linux-btrfs, linux-arch, linux-raid
In-Reply-To: <20260227142455.GG1282955@noisy.programming.kicks-ass.net>
On Fri, Feb 27, 2026 at 03:24:55PM +0100, Peter Zijlstra wrote:
> > unsigned long *p1, *p2, *p3, *p4;
> >
> > + WARN_ON_ONCE(in_interrupt());
>
> Your changelog makes it sound like you want:
>
> WARN_ON_ONCE(!in_task());
>
> But perhaps something like so:
>
> lockdep_assert_preempt_enabled();
>
> Would do? That ensures we are in preemptible context, which is much the
> same. That also ensures the cost of this assertion is only paid on debug
> kernels.
No idea honestly. The kernel FPU/vector helpers generally don't work
from irq context, and I want to assert that. Happy to do whatever
version works best for that.
^ permalink raw reply
* Re: [PATCH 04/25] xor: move to lib/raid/
From: Christoph Hellwig @ 2026-03-03 16:01 UTC (permalink / raw)
To: Eric Biggers
Cc: Christoph Hellwig, Andrew Morton, Richard Henderson, Matt Turner,
Magnus Lindholm, Russell King, Catalin Marinas, Will Deacon,
Huacai Chen, WANG Xuerui, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, David S. Miller, Andreas Larsson,
Richard Weinberger, Anton Ivanov, Johannes Berg, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Herbert Xu, Dan Williams, Chris Mason, David Sterba,
Arnd Bergmann, Song Liu, Yu Kuai, Li Nan, linux-alpha,
linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, linux-s390, sparclinux, linux-um, linux-crypto,
linux-btrfs, linux-arch, linux-raid
In-Reply-To: <20260228043523.GB65277@quark>
On Fri, Feb 27, 2026 at 08:35:23PM -0800, Eric Biggers wrote:
> This adds lib/raid/ alongside the existing lib/raid6/ directory. Is
> that the intended final state, or is the intent for the code in
> lib/raid6/ to eventually be moved to a subdirectory of lib/raid/
> (alongside the "xor" subdirectory)?
Yes, the raid6 code will get a dutup and move after this. And we'll
also plan to add a library for more than 2 parities eventually.
^ permalink raw reply
* Re: [PATCH 07/25] xor: split xor.h
From: Christoph Hellwig @ 2026-03-03 16:03 UTC (permalink / raw)
To: Eric Biggers
Cc: Christoph Hellwig, Andrew Morton, Richard Henderson, Matt Turner,
Magnus Lindholm, Russell King, Catalin Marinas, Will Deacon,
Huacai Chen, WANG Xuerui, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, David S. Miller, Andreas Larsson,
Richard Weinberger, Anton Ivanov, Johannes Berg, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Herbert Xu, Dan Williams, Chris Mason, David Sterba,
Arnd Bergmann, Song Liu, Yu Kuai, Li Nan, linux-alpha,
linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, linux-s390, sparclinux, linux-um, linux-crypto,
linux-btrfs, linux-arch, linux-raid
In-Reply-To: <20260228044355.GD65277@quark>
On Fri, Feb 27, 2026 at 08:43:55PM -0800, Eric Biggers wrote:
> On Thu, Feb 26, 2026 at 07:10:19AM -0800, Christoph Hellwig wrote:
> > Keep xor.h for the public API, and split the struct xor_block_template
> > definition that is only needed by the xor.ko core and
> > architecture-specific optimizations into a separate xor_impl.h header.
> >
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > ---
> > arch/arm/lib/xor-neon.c | 1 +
> > arch/s390/lib/xor.c | 2 +-
> > include/linux/raid/xor.h | 22 +---------------------
> > include/linux/raid/xor_impl.h | 25 +++++++++++++++++++++++++
> > lib/raid/xor/xor-core.c | 1 +
> > 5 files changed, 29 insertions(+), 22 deletions(-)
> > create mode 100644 include/linux/raid/xor_impl.h
>
> arch/arm64/lib/xor-neon.c needs to be updated to include xor_impl.h.
As of this patch it is not using anything from that header (but
neither from the public xor.h).
^ permalink raw reply
* Re: [PATCH 16/25] sparc: move the XOR code to lib/raid/
From: Christoph Hellwig @ 2026-03-03 16:04 UTC (permalink / raw)
To: Eric Biggers
Cc: Christoph Hellwig, Andrew Morton, Richard Henderson, Matt Turner,
Magnus Lindholm, Russell King, Catalin Marinas, Will Deacon,
Huacai Chen, WANG Xuerui, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, David S. Miller, Andreas Larsson,
Richard Weinberger, Anton Ivanov, Johannes Berg, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Herbert Xu, Dan Williams, Chris Mason, David Sterba,
Arnd Bergmann, Song Liu, Yu Kuai, Li Nan, linux-alpha,
linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, linux-s390, sparclinux, linux-um, linux-crypto,
linux-btrfs, linux-arch, linux-raid
In-Reply-To: <20260228054716.GF65277@quark>
On Fri, Feb 27, 2026 at 09:47:16PM -0800, Eric Biggers wrote:
> On Thu, Feb 26, 2026 at 07:10:28AM -0800, Christoph Hellwig wrote:
> > diff --git a/arch/sparc/lib/xor.S b/lib/raid/xor/sparc/xor-niagara.S
> > similarity index 53%
> > rename from arch/sparc/lib/xor.S
> > rename to lib/raid/xor/sparc/xor-niagara.S
> > index 35461e3b2a9b..f8749a212eb3 100644
> > --- a/arch/sparc/lib/xor.S
> > +++ b/lib/raid/xor/sparc/xor-niagara.S
> > @@ -1,11 +1,8 @@
> > /* SPDX-License-Identifier: GPL-2.0 */
> > /*
> > - * arch/sparc64/lib/xor.S
> > - *
> > * High speed xor_block operation for RAID4/5 utilizing the
> > - * UltraSparc Visual Instruction Set and Niagara store-init/twin-load.
> > + * Niagara store-init/twin-load.
> > *
> > - * Copyright (C) 1997, 1999 Jakub Jelinek (jj@ultra.linux.cz)
> > * Copyright (C) 2006 David S. Miller <davem@davemloft.net>
> > */
> >
> > @@ -16,343 +13,6 @@
> > #include <asm/dcu.h>
> > #include <asm/spitfire.h>
> >
>
> <linux/export.h> can be removed from the two assembly files, since all
> the invocations of EXPORT_SYMBOL() in them were removed.
>
> Also, xor-niagara.S ended up without a .text directive at the beginning.
> Probably it was unnecessary anyway. However, this seems unintentional,
> given that xor-vis.S still has it.
I'll probably undo the split and just do the mechanical move for the
next version. This was a bit too much change even if a split would be
my preferred outcome.
^ permalink raw reply
* Re: [PATCH 18/25] x86: move the XOR code to lib/raid/
From: Christoph Hellwig @ 2026-03-03 16:05 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Eric Biggers, Christoph Hellwig, Andrew Morton, Richard Henderson,
Matt Turner, Magnus Lindholm, Russell King, Catalin Marinas,
Will Deacon, Huacai Chen, WANG Xuerui, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
Christian Borntraeger, Sven Schnelle, David S. Miller,
Andreas Larsson, Richard Weinberger, Anton Ivanov, Johannes Berg,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Herbert Xu, Dan Williams, Chris Mason,
David Sterba, Arnd Bergmann, Song Liu, Yu Kuai, Li Nan,
linux-alpha, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-riscv, linux-s390, sparclinux, linux-um,
linux-crypto, linux-btrfs, linux-arch, linux-raid
In-Reply-To: <20260228103117.GK1282955@noisy.programming.kicks-ass.net>
On Sat, Feb 28, 2026 at 11:31:17AM +0100, Peter Zijlstra wrote:
> Hmm, I suppose. Its just weird that we now have to look in both
> arch/$foo and lib/*/$foo/ to find all arch code.
We've had instance of that for a long time, e.g. lib/raid6/
> And I don't suppose symlinks would make it better?
Ugg, just purely from the organizaton perspective it would make
things a lot worse. I'm also not sure how well git copes with
symlinks.
^ 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