* Re: Repeatable, raid1+O_DIRECT, hang/warn
From: Keith Busch @ 2026-06-15 20:09 UTC (permalink / raw)
To: Dr. David Alan Gilbert; +Cc: linux-block, dm-devel
In-Reply-To: <ajBRnUqXd7DqxLiG@kbusch-mbp>
On Mon, Jun 15, 2026 at 01:25:17PM -0600, Keith Busch wrote:
> In the meantime, since I so far can't reproduce this after including my
> previous proposal, I may have to request trying out a debug patch to get
> some more visibility on what's happening if that's okay.
Going in a different direction here, there's no reason to recreate the
lower level bio's from scratch when they originate from an incoming bio.
We can just clone it along with an iterator pointing to the original.
Can you try this one out? This was successful when I ran your reproducer
and cuts out a lot of code too with a performance bonus for large IO.
---
diff --git a/drivers/md/dm-io.c b/drivers/md/dm-io.c
index 1db565b376200..28adfeb58f240 100644
--- a/drivers/md/dm-io.c
+++ b/drivers/md/dm-io.c
@@ -170,12 +170,11 @@ struct dpages {
struct page **p, unsigned long *len, unsigned int *offset);
void (*next_page)(struct dpages *dp);
- union {
- unsigned int context_u;
- struct bvec_iter context_bi;
- };
+ unsigned int context_u;
void *context_ptr;
+ struct bio *orig_bio;
+
void *vma_invalidate_address;
unsigned long vma_invalidate_size;
};
@@ -210,44 +209,6 @@ static void list_dp_init(struct dpages *dp, struct page_list *pl, unsigned int o
dp->context_ptr = pl;
}
-/*
- * Functions for getting the pages from a bvec.
- */
-static void bio_get_page(struct dpages *dp, struct page **p,
- unsigned long *len, unsigned int *offset)
-{
- struct bio_vec bvec = bvec_iter_bvec((struct bio_vec *)dp->context_ptr,
- dp->context_bi);
-
- *p = bvec.bv_page;
- *len = bvec.bv_len;
- *offset = bvec.bv_offset;
-
- /* avoid figuring it out again in bio_next_page() */
- dp->context_bi.bi_sector = (sector_t)bvec.bv_len;
-}
-
-static void bio_next_page(struct dpages *dp)
-{
- unsigned int len = (unsigned int)dp->context_bi.bi_sector;
-
- bvec_iter_advance((struct bio_vec *)dp->context_ptr,
- &dp->context_bi, len);
-}
-
-static void bio_dp_init(struct dpages *dp, struct bio *bio)
-{
- dp->get_page = bio_get_page;
- dp->next_page = bio_next_page;
-
- /*
- * We just use bvec iterator to retrieve pages, so it is ok to
- * access the bvec table directly here
- */
- dp->context_ptr = bio->bi_io_vec;
- dp->context_bi = bio->bi_iter;
-}
-
/*
* Functions for getting the pages from a VMA.
*/
@@ -332,6 +293,21 @@ static void do_region(const blk_opf_t opf, unsigned int region,
return;
}
+ if (dp->orig_bio) {
+ bio = bio_alloc_clone(where->bdev, dp->orig_bio, GFP_NOIO,
+ &io->client->bios);
+ bio->bi_iter.bi_sector = where->sector;
+ bio->bi_iter.bi_size = where->count << SECTOR_SHIFT;
+ bio->bi_opf = opf;
+ bio->bi_end_io = endio;
+ bio->bi_ioprio = ioprio;
+ store_io_and_region_in_bio(bio, io, region);
+
+ atomic_inc(&io->count);
+ submit_bio(bio);
+ return;
+ }
+
/*
* where->count may be zero if op holds a flush and we need to
* send a zero-sized flush.
@@ -468,6 +444,7 @@ static int dp_init(struct dm_io_request *io_req, struct dpages *dp,
dp->vma_invalidate_address = NULL;
dp->vma_invalidate_size = 0;
+ dp->orig_bio = NULL;
switch (io_req->mem.type) {
case DM_IO_PAGE_LIST:
@@ -475,7 +452,11 @@ static int dp_init(struct dm_io_request *io_req, struct dpages *dp,
break;
case DM_IO_BIO:
- bio_dp_init(dp, io_req->mem.ptr.bio);
+ /*
+ * The destination bios clone this bio's biovec directly, so
+ * there are no per-page accessors to set up here.
+ */
+ dp->orig_bio = io_req->mem.ptr.bio;
break;
case DM_IO_VMA:
--
^ permalink raw reply related
* Re: [PATCH 08/19] parisc: define DPS root partition type UUID
From: James Bottomley @ 2026-06-15 20:02 UTC (permalink / raw)
To: Vincent Mailhol, Jens Axboe, Davidlohr Bueso, Alexander Viro,
Christian Brauner, Jan Kara
Cc: linux-kernel, linux-block, linux-efi, linux-fsdevel, Helge Deller,
linux-parisc
In-Reply-To: <20260615-discoverable-root_partitions-v1-8-39c78fac42e2@kernel.org>
On Mon, 2026-06-15 at 18:09 +0200, Vincent Mailhol wrote:
> DPS [1] assigns GPT partition type UUIDs to operating system
> partitions. Root partitions use architecture-specific type UUIDs so
> the OS can discover the intended root filesystem without relying on a
> root= cmdline option.
>
> Define DPS_ROOT_PARTITION_TYPE_UUID in asm/dps_root.h for parisc and
> select ARCH_HAS_DPS_ROOT_PARTITION_TYPE_UUID.
>
> [1] The Discoverable Partitions Specification (DPS)
> Link:
> https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
How are you planning to make this work for parisc? Some systems have a
PALO boot partition (fdisk type 0xf0) but the more modern way is to
place palo inside a hidden ext4 inode in /boot. The way parisc IODC
works is very similar to the way MSDOS boots with the palo location
table in the first block so I theorize that would probably work for gpt
partitions as well ... I'm just not sure anyone has tested it.
However, to get this to work with PALO for auto discovery, you'd need
palo patches to recognize the DPS UUID and no-one seems to have
submitted anything to palo for this.
Regards,
James
^ permalink raw reply
* Re: Repeatable, raid1+O_DIRECT, hang/warn
From: Keith Busch @ 2026-06-15 19:25 UTC (permalink / raw)
To: Dr. David Alan Gilbert; +Cc: linux-block, dm-devel
In-Reply-To: <ajA5kpUraXqh9ag9@gallifrey>
On Mon, Jun 15, 2026 at 05:42:42PM +0000, Dr. David Alan Gilbert wrote:
> * Keith Busch (kbusch@kernel.org) wrote:
> > On Mon, Jun 15, 2026 at 04:37:39PM +0000, Dr. David Alan Gilbert wrote:
> > > Hi Keith,
> > > Thanks for the patch, alas it doesn't seem to be helping here;
> > > the first warn is still the same
> > > and it still hangs the test process hard and eventually BUGs at
> > >
> > > void blk_mq_end_request(struct request *rq, blk_status_t error)
> > > {
> > > if (blk_update_request(rq, error, blk_rq_bytes(rq)))
> > > BUG();
> >
> > Oh, that was not expected.
> >
> > What is the dma alignment requirement of your backing devices? You can
> > find the attribute for sda at /sys/block/sda/queue/dma_alignment. I'm
> > expecting 511, but just want to double check.
>
> Yeh looks like it:
> /sys/block/sda/queue/dma_alignment:511
> /sys/block/sdb/queue/dma_alignment:511
>
> all of the lvm also looks like it is.
Thanks for confirming.
I'm struggling to see how you're getting there with your reproducer with
the proposal included. I can see other short comings with preadv or
really large pread's, but not with a 4k pread. For those other issues
this patch can fix it:
https://lore.kernel.org/linux-block/20260612223205.465913-1-kbusch@meta.com/
It is currently staged for upstream, so hasn't landed yet. But again, I
don't think those conditions apply to what you're seeing, but worth a
shot on top of the previous proposal to use byte units instead of
sectors.
In the meantime, since I so far can't reproduce this after including my
previous proposal, I may have to request trying out a debug patch to get
some more visibility on what's happening if that's okay.
^ permalink raw reply
* Re: [PATCH 12/19] x86: define DPS root partition type UUIDs
From: Matthew Wilcox @ 2026-06-15 18:05 UTC (permalink / raw)
To: Dave Hansen
Cc: Vincent Mailhol, Jens Axboe, Davidlohr Bueso, Alexander Viro,
Christian Brauner, Jan Kara, linux-kernel, linux-block, linux-efi,
linux-fsdevel, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86
In-Reply-To: <03be57ae-0e41-4b8a-adc5-bdd85ccce951@intel.com>
On Mon, Jun 15, 2026 at 09:46:41AM -0700, Dave Hansen wrote:
> There are a lot of ways to do this. I'm just not a super big fan of the
> current proposal.
>
> So, boiling it down:
>
> 1. Should more than one UUID be supported per kernel build?
> 2. Should the UUIDs be defined in arch code or generic code?
> 3. Kconfig or #ifdefs?
Further questions ... why do this in the kernel? Seems perfectly
suited to be in initramfs where we can throw away the code after boot.
^ permalink raw reply
* Re: Repeatable, raid1+O_DIRECT, hang/warn
From: Dr. David Alan Gilbert @ 2026-06-15 17:42 UTC (permalink / raw)
To: Keith Busch; +Cc: linux-block, dm-devel
In-Reply-To: <ajA0L-u-r4nhbpfl@kbusch-mbp>
* Keith Busch (kbusch@kernel.org) wrote:
> On Mon, Jun 15, 2026 at 04:37:39PM +0000, Dr. David Alan Gilbert wrote:
> > Hi Keith,
> > Thanks for the patch, alas it doesn't seem to be helping here;
> > the first warn is still the same
> > and it still hangs the test process hard and eventually BUGs at
> >
> > void blk_mq_end_request(struct request *rq, blk_status_t error)
> > {
> > if (blk_update_request(rq, error, blk_rq_bytes(rq)))
> > BUG();
>
> Oh, that was not expected.
>
> What is the dma alignment requirement of your backing devices? You can
> find the attribute for sda at /sys/block/sda/queue/dma_alignment. I'm
> expecting 511, but just want to double check.
Yeh looks like it:
/sys/block/sda/queue/dma_alignment:511
/sys/block/sdb/queue/dma_alignment:511
all of the lvm also looks like it is.
Dave
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux | Happy \
\ dave @ treblig.org | | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
^ permalink raw reply
* Re: Repeatable, raid1+O_DIRECT, hang/warn
From: Keith Busch @ 2026-06-15 17:19 UTC (permalink / raw)
To: Dr. David Alan Gilbert; +Cc: linux-block, dm-devel
In-Reply-To: <ajAqUwo3eTm1c2_J@gallifrey>
On Mon, Jun 15, 2026 at 04:37:39PM +0000, Dr. David Alan Gilbert wrote:
> Hi Keith,
> Thanks for the patch, alas it doesn't seem to be helping here;
> the first warn is still the same
> and it still hangs the test process hard and eventually BUGs at
>
> void blk_mq_end_request(struct request *rq, blk_status_t error)
> {
> if (blk_update_request(rq, error, blk_rq_bytes(rq)))
> BUG();
Oh, that was not expected.
What is the dma alignment requirement of your backing devices? You can
find the attribute for sda at /sys/block/sda/queue/dma_alignment. I'm
expecting 511, but just want to double check.
^ permalink raw reply
* Re: [PATCH 00/19] init: discoverable root partitions, a.k.a. an omittable "root=" cmdline option
From: Al Viro @ 2026-06-15 17:04 UTC (permalink / raw)
To: Vincent Mailhol
Cc: Jens Axboe, Davidlohr Bueso, Christian Brauner, Jan Kara,
linux-kernel, linux-block, linux-efi, linux-fsdevel,
Richard Henderson, Matt Turner, Magnus Lindholm, linux-alpha,
Vineet Gupta, linux-snps-arc, Russell King, linux-arm-kernel,
Catalin Marinas, Will Deacon, Huacai Chen, WANG Xuerui, loongarch,
Thomas Bogendoerfer, linux-mips, James E.J. Bottomley,
Helge Deller, linux-parisc, Madhavan Srinivasan, Michael Ellerman,
linuxppc-dev, Paul Walmsley, Palmer Dabbelt, Albert Ou,
linux-riscv, Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
linux-s390, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <20260615-discoverable-root_partitions-v1-0-39c78fac42e2@kernel.org>
On Mon, Jun 15, 2026 at 06:08:56PM +0200, Vincent Mailhol wrote:
> Tested with GRUB, which implements the LoaderDevicePartUUID EFI variable
> in its bli module [3]. With this, I was able to boot a kernel with a
> completely empty cmdline and no initrd.
>
> [1] The Discoverable Partitions Specification (DPS)
> Link: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
>
> [2] systemd-gpt-auto-generator
> Link: https://www.freedesktop.org/software/systemd/man/latest/systemd-gpt-auto-generator.html
>
> [3] GRUB -- §16.2 bli
> Link: https://www.gnu.org/software/grub/manual/grub/html_node/bli_005fmodule.html
So what does that thing, tied to EFI as it is, have to do with architectures where
* firmware is rather unlike EFI
* firmware wouldn't know what to do with GPT
* GRUB is *not* ported to, let alone used
such as, say it, the very first one mentioned at your [1]?
Or is that conditional upon "if anyone wants to design replacement firmware
for those, and if they agree to follow our wishlist"?
^ permalink raw reply
* Re: [PATCH 12/19] x86: define DPS root partition type UUIDs
From: Dave Hansen @ 2026-06-15 16:46 UTC (permalink / raw)
To: Vincent Mailhol, Jens Axboe, Davidlohr Bueso, Alexander Viro,
Christian Brauner, Jan Kara
Cc: linux-kernel, linux-block, linux-efi, linux-fsdevel,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86
In-Reply-To: <20260615-discoverable-root_partitions-v1-12-39c78fac42e2@kernel.org>
On 6/15/26 09:09, Vincent Mailhol wrote:
> +#ifdef CONFIG_X86_64
> +#define DPS_ROOT_PARTITION_TYPE_UUID "4f68bce3-e8cd-4db1-96e7-fbcaf984b709"
> +#else
> +#define DPS_ROOT_PARTITION_TYPE_UUID "44479540-f297-41b2-9af7-d131d5f0458a"
> +#endif
This doesn't make a whole lot of sense to me. 64-bit kernels can run
32-bit userspace just fine.
But this #ifdef as proposed means that only a 32-bit *OR* 64-bit kernel
can auto-discover a given partition.
I kinda think you should just have an array of strings for these things,
maybe glued together with some preprocessor magic. Logically something
like this:
const char* const uuids[] = {
#ifdef CONFIG_ARM64
"b921b045-1df0-41c3-af44-4c6f280d3fae"
#endif
#ifdef CONFIG_X86_64
"4f68bce3-e8cd-4db1-96e7-fbcaf984b709",
#endif
#if defined(CONFIG_X86) && defined(CONFIG_COMPAT32)
"44479540-f297-41b2-9af7-d131d5f0458a",
#endif
...
};
... and then search the array. I honestly don't think you need to
sprinkle UUIDs all over the architectures.
It could probably also be done almost entirely in Kconfig. This could be
in, say block/partitions/Kconfig, or arch/*/Kconfig:
config DPS_ROOT_PARTITION_TYPE_UUID_1
string
default "4f68bce3-e8cd-4db1-96e7-fbcaf984b709" if X86_64
default "b921b045-1df0-41c3-af44-4c6f280d3fae" if ARM64
...
config DPS_ROOT_PARTITION_TYPE_UUID_2
string
default "44479540-f297-41b2-9af7-..." if X86 && COMPAT_32
const char* const uuids[] = {
#ifdef CONFIG_DPS_ROOT_PARTITION_TYPE_UUID_1
CONFIG_DPS_ROOT_PARTITION_TYPE_UUID_1
#endif
#ifdef CONFIG_DPS_ROOT_PARTITION_TYPE_UUID_2
CONFIG_DPS_ROOT_PARTITION_TYPE_UUID_2
#endif
...
};
There are a lot of ways to do this. I'm just not a super big fan of the
current proposal.
So, boiling it down:
1. Should more than one UUID be supported per kernel build?
2. Should the UUIDs be defined in arch code or generic code?
3. Kconfig or #ifdefs?
^ permalink raw reply
* Re: Repeatable, raid1+O_DIRECT, hang/warn
From: Dr. David Alan Gilbert @ 2026-06-15 16:37 UTC (permalink / raw)
To: Keith Busch; +Cc: linux-block, dm-devel
In-Reply-To: <ajAb0m9cNraQn2Pw@kbusch-mbp>
* Keith Busch (kbusch@kernel.org) wrote:
> On Mon, Jun 15, 2026 at 09:20:23AM -0600, Keith Busch wrote:
> > On Sun, Jun 14, 2026 at 05:57:48PM +0000, Dr. David Alan Gilbert wrote:
> > > Jun 14 18:08:32 dalek kernel: device-mapper: raid1: Mirror read failed from 252:24. Trying alternative device.
> > > Jun 14 18:08:32 dalek kernel: ------------[ cut here ]------------
> > > Jun 14 18:08:32 dalek dmeventd[1010]: Primary mirror device 252:24 read failed.
> > > Jun 14 18:08:32 dalek kernel: WARNING: block/bio.c:1044 at bio_add_page+0x18b/0x250, CPU#15: kworker/15:1/369
> > > Jun 14 18:08:32 dalek dmeventd[1010]: main-lvol0 is now in-sync.
> > > Jun 14 18:08:32 dalek kernel: Modules linked in: nft_masq nft_reject_ipv4 act_csum cls_u32 sch_htb nf_nat_tftp nf_conntrack_tftp bridge stp llc rfkill nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reje>
> > > Jun 14 18:08:32 dalek kernel: drm_panel_backlight_quirks gpu_sched drm_suballoc_helper video nvme drm_display_helper nvme_core cec nvme_keyring sp5100_tco nvme_auth wmi serio_raw fuse scsi_dh_alua i2c_dev scsi_dh_rdac scsi_dh_emc
> > > Jun 14 18:08:32 dalek kernel: CPU: 15 UID: 0 PID: 369 Comm: kworker/15:1 Not tainted 7.1.0-rc7+ #786 PREEMPT(lazy)
> > > Jun 14 18:08:32 dalek kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./X570 Pro4, BIOS P3.10 07/13/2020
> > > Jun 14 18:08:32 dalek kernel: Workqueue: kmirrord do_mirror
> > > Jun 14 18:08:32 dalek kernel: RIP: 0010:bio_add_page+0x18b/0x250
> > > Jun 14 18:08:32 dalek kernel: Code: 24 10 4c 8b 04 24 84 c0 0f 85 c9 00 00 00 41 0f b7 40 78 48 8b 74 24 08 8b 4c 24 14 e9 b4 fe ff ff 0f 0b 31 c0 e9 55 d1 af 00 <0f> 0b eb f5 48 8b 7f 08 83 7f 60 05 0f 85 00 ff ff ff 49 8b 3b 4c
> > > Jun 14 18:08:32 dalek kernel: RSP: 0018:ffffd1fb8176fc10 EFLAGS: 00010246
> > > Jun 14 18:08:32 dalek kernel: RAX: 0000000000000000 RBX: ffffd1fb8176fd18 RCX: 0000000000000000
> > > Jun 14 18:08:32 dalek kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8d1a8eb28b00
> > > Jun 14 18:08:32 dalek kernel: RBP: 0000000000000000 R08: ffffd1fb8176fc38 R09: ffffd1fb8176fc40
> > > Jun 14 18:08:32 dalek kernel: R10: ffffd1fb8176fc34 R11: 0000000000000000 R12: 0000000000000000
> > > Jun 14 18:08:32 dalek kernel: R13: ffffd1fb8176fd90 R14: 0000000000000001 R15: ffff8d1a8eb28b00
> > > Jun 14 18:08:32 dalek kernel: FS: 0000000000000000(0000) GS:ffff8d29d161f000(0000) knlGS:0000000000000000
> > > Jun 14 18:08:32 dalek kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > > Jun 14 18:08:32 dalek kernel: CR2: 00007f0ddcd7b9d0 CR3: 000000023dcbf000 CR4: 0000000000350ef0
> > > Jun 14 18:08:32 dalek kernel: Call Trace:
> > > Jun 14 18:08:32 dalek kernel: <TASK>
> > > Jun 14 18:08:32 dalek kernel: do_region+0x227/0x2a0
> >
> > I think the problem is that do_region is tracking the "remaining" in
> > sector granularity, but devices can have dma alignment such that it's
> > valid to have sub-sector vectors. Rounding the length appended
> > to_sectors() creates a 0 length subtraction, so the loop thinks no
> > progress is made and loops forever. If we track it in bytes instead of
> > sectors, then that should fix this observation.
>
> I recreated your observation and this patch below appears to fix the
> stuck behavior.
Hi Keith,
Thanks for the patch, alas it doesn't seem to be helping here;
the first warn is still the same
and it still hangs the test process hard and eventually BUGs at
void blk_mq_end_request(struct request *rq, blk_status_t error)
{
if (blk_update_request(rq, error, blk_rq_bytes(rq)))
BUG();
Dave
> ---
> diff --git a/drivers/md/dm-io.c b/drivers/md/dm-io.c
> index 1db565b376200..d72b9331c2fd1 100644
> --- a/drivers/md/dm-io.c
> +++ b/drivers/md/dm-io.c
> @@ -362,19 +362,26 @@ static void do_region(const blk_opf_t opf, unsigned int region,
> bio->bi_iter.bi_size = num_sectors << SECTOR_SHIFT;
> remaining -= num_sectors;
> } else {
> - while (remaining) {
> + unsigned long byte_remaining = to_bytes(remaining);
> +
> + while (byte_remaining) {
> /*
> * Try and add as many pages as possible.
> */
> dp->get_page(dp, &page, &len, &offset);
> - len = min(len, to_bytes(remaining));
> + len = min(len, byte_remaining);
> if (!bio_add_page(bio, page, len, offset))
> break;
>
> offset = 0;
> - remaining -= to_sector(len);
> + byte_remaining -= len;
> dp->next_page(dp);
> }
> + remaining = to_sector(byte_remaining);
> }
>
> atomic_inc(&io->count);
> --
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux | Happy \
\ dave @ treblig.org | | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
^ permalink raw reply
* Re: [PATCH V2] blk-cgroup: defer blkcg css_put until blkg is unlinked from queue
From: Yu Kuai @ 2026-06-15 16:16 UTC (permalink / raw)
To: Zizhi Wo, axboe, tj, josef, linux-block
Cc: cgroups, yangerkun, chengzhihao1, houtao1, yukuai
In-Reply-To: <20260615115556.1225472-1-wozizhi@huaweicloud.com>
Hi，
在 2026/6/15 19:55, Zizhi Wo 写道:
> From: Zizhi Wo <wozizhi@huawei.com>
>
> [BUG]
> Our fuzz testing triggered a blkcg use-after-free issue:
>
> BUG: KASAN: slab-use-after-free in _raw_spin_lock+0x75/0xe0
> Call Trace:
> ...
> blkcg_deactivate_policy+0x244/0x4d0
> ioc_rqos_exit+0x44/0xe0
> rq_qos_exit+0xba/0x120
> __del_gendisk+0x50b/0x800
> del_gendisk+0xff/0x190
> ...
>
> [CAUSE]
> process1 process2
> cgroup_rmdir
> ...
> css_killed_work_fn
> offline_css
> ...
> blkcg_destroy_blkgs
> ...
> __blkg_release
> css_put(&blkg->blkcg->css)
> blkg_free
> INIT_WORK(xxx, blkg_free_workfn)
> schedule_work
> css_put
> ...
> blkcg_css_free
> kfree(blkcg)--------blkcg has been freed!!!
> ====================================schedule_work
> blkg_free_workfn
> __del_gendisk
> rq_qos_exit
> ioc_rqos_exit
> blkcg_deactivate_policy
> mutex_lock(&q->blkcg_mutex)
> spin_lock_irq(&q->queue_lock)
> list_for_each_entry(blkg, xxx)
> blkcg = blkg->blkcg
> spin_lock(&blkcg->lock)-------UAF!!!
> mutex_lock(&q->blkcg_mutex)
> spin_lock_irq(&q->queue_lock)
> /* Only then is the blkg removed from the list */
> list_del_init(&blkg->q_node)
>
> As a result, a blkg can still be reachable through q->blkg_list while
> its ->blkcg has already been freed.
>
> [Fix]
> Fix this by deferring the blkcg css_put() until after the blkg has been
> unlinked from q->blkg_list in blkg_free_workfn(). This ensures that the
> blkcg outlives every blkg still reachable through q->blkg_list, so any
> iterator holding q->queue_lock is guaranteed to observe a valid
> blkg->blkcg.
>
> While at it, move css_tryget_online() from blkg_create() into blkg_alloc()
> so that the css reference is owned by the alloc/free pair rather than
> straddling layers:
> blkg_alloc() <-> blkg_free()
> blkg_create() <-> blkg_destroy()
>
> Fixes: f1c006f1c685 ("blk-cgroup: synchronize pd_free_fn() from blkg_free_workfn() and blkcg_deactivate_policy()")
> Suggested-by: Hou Tao <houtao1@huawei.com>
> Signed-off-by: Zizhi Wo <wozizhi@huawei.com>
> ---
> v2:
> - Move css_tryget_online() from blkg_create() into blkg_alloc() so the
> css reference follows the blkg's own lifetime, making the put in
> blkg_free_workfn() symmetric with the get in blkg_alloc().
>
> v1: https://lore.kernel.org/all/20260518010932.633707-1-wozizhi@huaweicloud.com/
>
> block/blk-cgroup.c | 24 ++++++++++++------------
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
> index bc63bd220865..27414c291e49 100644
> --- a/block/blk-cgroup.c
> +++ b/block/blk-cgroup.c
> @@ -132,10 +132,15 @@ static void blkg_free_workfn(struct work_struct *work)
> if (blkg->parent)
> blkg_put(blkg->parent);
> spin_lock_irq(&q->queue_lock);
> list_del_init(&blkg->q_node);
> spin_unlock_irq(&q->queue_lock);
> + /*
> + * Release blkcg css ref only after blkg is removed from q->blkg_list,
> + * so concurrent iterators won't see a blkg with a freed blkcg.
> + */
> + css_put(&blkg->blkcg->css);
> mutex_unlock(&q->blkcg_mutex);
Please move css_put after mutex_unlock, unless there is a strong reason.
With above change, feel free to add:
Reviewed-by: Yu Kuai <yukuai@fygo.io>
>
> blk_put_queue(q);
> free_percpu(blkg->iostat_cpu);
> percpu_ref_exit(&blkg->refcnt);
> @@ -177,12 +182,10 @@ static void __blkg_release(struct rcu_head *rcu)
> * blkg_stat_lock is for serializing blkg stat update
> */
> for_each_possible_cpu(cpu)
> __blkcg_rstat_flush(blkcg, cpu);
>
> - /* release the blkcg and parent blkg refs this blkg has been holding */
> - css_put(&blkg->blkcg->css);
> blkg_free(blkg);
> }
>
> /*
> * A group is RCU protected, but having an rcu lock does not mean that one
> @@ -311,10 +314,13 @@ static struct blkcg_gq *blkg_alloc(struct blkcg *blkcg, struct gendisk *disk,
> blkg->iostat_cpu = alloc_percpu_gfp(struct blkg_iostat_set, gfp_mask);
> if (!blkg->iostat_cpu)
> goto out_exit_refcnt;
> if (!blk_get_queue(disk->queue))
> goto out_free_iostat;
> + /* blkg holds a reference to blkcg */
> + if (!css_tryget_online(&blkcg->css))
> + goto out_put_queue;
>
> blkg->q = disk->queue;
> INIT_LIST_HEAD(&blkg->q_node);
> blkg->blkcg = blkcg;
> blkg->iostat.blkg = blkg;
> @@ -351,10 +357,12 @@ static struct blkcg_gq *blkg_alloc(struct blkcg *blkcg, struct gendisk *disk,
>
> out_free_pds:
> while (--i >= 0)
> if (blkg->pd[i])
> blkcg_policy[i]->pd_free_fn(blkg->pd[i]);
> + css_put(&blkcg->css);
> +out_put_queue:
> blk_put_queue(disk->queue);
> out_free_iostat:
> free_percpu(blkg->iostat_cpu);
> out_exit_refcnt:
> percpu_ref_exit(&blkg->refcnt);
> @@ -379,32 +387,26 @@ static struct blkcg_gq *blkg_create(struct blkcg *blkcg, struct gendisk *disk,
> if (blk_queue_dying(disk->queue)) {
> ret = -ENODEV;
> goto err_free_blkg;
> }
>
> - /* blkg holds a reference to blkcg */
> - if (!css_tryget_online(&blkcg->css)) {
> - ret = -ENODEV;
> - goto err_free_blkg;
> - }
> -
> /* allocate */
> if (!new_blkg) {
> new_blkg = blkg_alloc(blkcg, disk, GFP_NOWAIT);
> if (unlikely(!new_blkg)) {
> ret = -ENOMEM;
> - goto err_put_css;
> + goto err_free_blkg;
> }
> }
> blkg = new_blkg;
>
> /* link parent */
> if (blkcg_parent(blkcg)) {
> blkg->parent = blkg_lookup(blkcg_parent(blkcg), disk->queue);
> if (WARN_ON_ONCE(!blkg->parent)) {
> ret = -ENODEV;
> - goto err_put_css;
> + goto err_free_blkg;
> }
> blkg_get(blkg->parent);
> }
>
> /* invoke per-policy init */
> @@ -440,12 +442,10 @@ static struct blkcg_gq *blkg_create(struct blkcg *blkcg, struct gendisk *disk,
>
> /* @blkg failed fully initialized, use the usual release path */
> blkg_put(blkg);
> return ERR_PTR(ret);
>
> -err_put_css:
> - css_put(&blkcg->css);
> err_free_blkg:
> if (new_blkg)
> blkg_free(new_blkg);
> return ERR_PTR(ret);
> }
--
Thanks,
Kuai
^ permalink raw reply
* [PATCH 19/19] docs: document discoverable root partitions
From: Vincent Mailhol @ 2026-06-15 16:09 UTC (permalink / raw)
To: Jens Axboe, Davidlohr Bueso, Alexander Viro, Christian Brauner,
Jan Kara
Cc: linux-kernel, linux-block, linux-efi, linux-fsdevel,
Vincent Mailhol, Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <20260615-discoverable-root_partitions-v1-0-39c78fac42e2@kernel.org>
Document the automatic root block device discovery feature.
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Shuah Khan <skhan@linuxfoundation.org>
Cc: linux-doc@vger.kernel.org
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
---
Documentation/admin-guide/discoverable-root.rst | 33 +++++++++++++++++++++++++
Documentation/admin-guide/index.rst | 1 +
Documentation/admin-guide/kernel-parameters.txt | 5 ++++
3 files changed, 39 insertions(+)
diff --git a/Documentation/admin-guide/discoverable-root.rst b/Documentation/admin-guide/discoverable-root.rst
new file mode 100644
index 000000000000..9645bf39e405
--- /dev/null
+++ b/Documentation/admin-guide/discoverable-root.rst
@@ -0,0 +1,33 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _discoverable_root:
+
+Discoverable root partitions
+============================
+
+On EFI systems using a supported architecture, the kernel can discover the root
+block device from GPT partition type UUID metadata on the disk containing the
+active EFI System Partition.
+
+This follows the `Discoverable Partitions Specification`_ which defines a list
+of architecture-specific root partition type UUIDs.
+
+Specifying ``root=`` on the kernel command line takes precedence and entirely
+disables this automatic root partition discovery.
+
+The disk to search is identified by the Boot Loader Interface
+``LoaderDevicePartUUID`` EFI variable. If multiple partitions on that disk match
+the architecture root partition type UUID, the kernel selects the first match in
+block device enumeration order. Systems should not expose multiple eligible root
+partitions unless that ordering is intended.
+
+Partitions marked with the DPS ``no-auto`` GPT attribute are skipped. This
+allows a partition with an otherwise discoverable type UUID to opt out from
+automatic discovery.
+
+The DPS read-only attribute is not enforced by kernel root discovery. The
+root filesystem is mounted read-only by default unless ``rw`` is specified,
+and user space remains responsible for later remount policy.
+
+.. _Discoverable Partitions Specification:
+ https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
index cd28dfe91b06..0d9c2796ae09 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -50,6 +50,7 @@ Booting the kernel
bootconfig
kernel-parameters
+ discoverable-root
efi-stub
initrd
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index f68bf1cdb53b..c9bfa010883c 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -6696,6 +6696,11 @@ Kernel parameters
ramdisk, "nfs" and "cifs" for root on a network file
system, or "mtd" and "ubi" for mounting from raw flash.
+ If this option is omitted, the kernel may try to
+ discover the root block device from the GPT partition
+ type UUID metadata when additional requirements are met.
+ See Documentation/admin-guide/discoverable-root.rst.
+
rootdelay= [KNL] Delay (in seconds) to pause before attempting to
mount the root filesystem
--
2.53.0
^ permalink raw reply related
* [PATCH 18/19] init: discover root by DPS partition type UUID
From: Vincent Mailhol @ 2026-06-15 16:09 UTC (permalink / raw)
To: Jens Axboe, Davidlohr Bueso, Alexander Viro, Christian Brauner,
Jan Kara
Cc: linux-kernel, linux-block, linux-efi, linux-fsdevel,
Vincent Mailhol
In-Reply-To: <20260615-discoverable-root_partitions-v1-0-39c78fac42e2@kernel.org>
When the root= cmdline option is absent, try to discover the root block
device using the architecture's DPS root partition type UUID.
DPS limits root discovery to the disk containing the active EFI System
Partition. Read LoaderDevicePartUUID from the Boot Loader Interface and
pass it to early_lookup_bdev_by_type_uuid() so the block lookup only
considers partitions on that disk.
Print a dedicated wait message while waiting for a discoverable root
partition and emit an informational message when discovery succeeds.
If LoaderDevicePartUUID cannot be read or does not contain a valid UUID,
clear root_wait so the kernel does not keep retrying a discovery path
that cannot succeed.
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
---
init/do_mounts.c | 89 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 87 insertions(+), 2 deletions(-)
diff --git a/init/do_mounts.c b/init/do_mounts.c
index 5fb5aeb88da9..20c176945b32 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -10,6 +10,7 @@
#include <linux/delay.h>
#include <linux/mount.h>
#include <linux/device.h>
+#include <linux/efi.h>
#include <linux/init.h>
#include <linux/fs.h>
#include <linux/initrd.h>
@@ -19,6 +20,8 @@
#include <linux/ramfs.h>
#include <linux/shmem_fs.h>
#include <linux/ktime.h>
+#include <linux/ucs2_string.h>
+#include <linux/uuid.h>
#include <linux/nfs_fs.h>
#include <linux/nfs_fs_sb.h>
@@ -402,9 +405,86 @@ void __init mount_root(char *root_device_name)
}
}
+#ifdef CONFIG_DPS_ROOT_AUTO_DISCOVERY
+static char efi_partuuid[EFI_VARIABLE_GUID_LEN + 1] __initdata;
+
+static int __init efi_loader_get_device_part_uuid(char *efi_uuid, size_t size)
+{
+ efi_char16_t efi_uuid_ucs2[EFI_VARIABLE_GUID_LEN + 1] = {};
+ unsigned long efi_uuid_ucs2_size = sizeof(efi_uuid_ucs2);
+ efi_status_t status;
+
+ if (!efi_rt_services_supported(EFI_RT_SUPPORTED_GET_VARIABLE))
+ return -EOPNOTSUPP;
+
+ status = efi.get_variable(L"LoaderDevicePartUUID",
+ &LINUX_EFI_LOADER_ENTRY_GUID, NULL,
+ &efi_uuid_ucs2_size, efi_uuid_ucs2);
+ if (status != EFI_SUCCESS)
+ return efi_status_to_err(status);
+
+ if (ucs2_as_utf8((u8 *)efi_uuid, efi_uuid_ucs2, size) != UUID_STRING_LEN ||
+ !uuid_is_valid(efi_uuid))
+ return -EINVAL;
+
+ return 0;
+}
+
+static int __init lookup_dps_root(dev_t *dev)
+{
+ static const char dps_root_partition_type_uuid[] __initconst =
+ DPS_ROOT_PARTITION_TYPE_UUID;
+ int err;
+
+ err = early_lookup_bdev_by_type_uuid(dps_root_partition_type_uuid,
+ efi_partuuid, dev);
+ if (!err)
+ pr_info("VFS: Discovered root partition with GPT type UUID %s\n",
+ dps_root_partition_type_uuid);
+
+ return err;
+}
+
+static dev_t __init try_dps_root_discovery(void)
+{
+ dev_t dev;
+ int err;
+
+ err = efi_loader_get_device_part_uuid(efi_partuuid,
+ sizeof(efi_partuuid));
+ if (err) {
+ pr_err("VFS: Unable to get LoaderDevicePartUUID EFI variable: %pe, skipping root partition discovery\n",
+ ERR_PTR(err));
+ if (root_wait) {
+ pr_err("Disabling rootwait\n");
+ root_wait = 0;
+ }
+ return 0;
+ }
+
+ if (!lookup_dps_root(&dev))
+ return dev;
+
+ return 0;
+}
+#else
+static int __init lookup_dps_root(dev_t *dev)
+{
+ return 0;
+}
+
+static dev_t __init try_dps_root_discovery(void)
+{
+ return 0;
+}
+#endif
+
static int __init lookup_root_device(char *root_device_name)
{
- return early_lookup_bdev(root_device_name, &ROOT_DEV);
+ if (root_device_name[0])
+ return early_lookup_bdev(root_device_name, &ROOT_DEV);
+ else
+ return lookup_dps_root(&ROOT_DEV);
}
/* wait for any asynchronous scanning to complete */
@@ -415,7 +495,10 @@ static void __init wait_for_root(char *root_device_name)
if (ROOT_DEV != 0)
return;
- pr_info("Waiting for root device %s...\n", root_device_name);
+ if (root_device_name[0])
+ pr_info("Waiting for root device %s...\n", root_device_name);
+ else if (IS_ENABLED(CONFIG_DPS_ROOT_AUTO_DISCOVERY))
+ pr_info("Waiting for discoverable root partition...\n");
end = ktime_add_ms(ktime_get_raw(), root_wait);
@@ -480,6 +563,8 @@ void __init prepare_namespace(void)
if (saved_root_name[0])
ROOT_DEV = parse_root_device(saved_root_name);
+ else
+ ROOT_DEV = try_dps_root_discovery();
initrd_load();
--
2.53.0
^ permalink raw reply related
* [PATCH 17/19] init: factor out root device lookup into lookup_root_device()
From: Vincent Mailhol @ 2026-06-15 16:09 UTC (permalink / raw)
To: Jens Axboe, Davidlohr Bueso, Alexander Viro, Christian Brauner,
Jan Kara
Cc: linux-kernel, linux-block, linux-efi, linux-fsdevel,
Vincent Mailhol
In-Reply-To: <20260615-discoverable-root_partitions-v1-0-39c78fac42e2@kernel.org>
DPS root detection will also need to work if root_wait is set, meaning
that wait_for_root() needs to handle the DPS logic.
Move early_lookup_bdev() out of wait_for_root() into the new
lookup_root_device() so later changes can extend the lookup policy
without duplicating the retry logic.
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
---
init/do_mounts.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/init/do_mounts.c b/init/do_mounts.c
index 95e0b3a0f711..5fb5aeb88da9 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -402,6 +402,11 @@ void __init mount_root(char *root_device_name)
}
}
+static int __init lookup_root_device(char *root_device_name)
+{
+ return early_lookup_bdev(root_device_name, &ROOT_DEV);
+}
+
/* wait for any asynchronous scanning to complete */
static void __init wait_for_root(char *root_device_name)
{
@@ -415,7 +420,7 @@ static void __init wait_for_root(char *root_device_name)
end = ktime_add_ms(ktime_get_raw(), root_wait);
while (!driver_probe_done() ||
- early_lookup_bdev(root_device_name, &ROOT_DEV) < 0) {
+ lookup_root_device(root_device_name) < 0) {
msleep(5);
if (root_wait > 0 && ktime_after(ktime_get_raw(), end))
break;
--
2.53.0
^ permalink raw reply related
* [PATCH 16/19] block: don't discover partition with DPS no-auto GPT attribute
From: Vincent Mailhol @ 2026-06-15 16:09 UTC (permalink / raw)
To: Jens Axboe, Davidlohr Bueso, Alexander Viro, Christian Brauner,
Jan Kara
Cc: linux-kernel, linux-block, linux-efi, linux-fsdevel,
Vincent Mailhol
In-Reply-To: <20260615-discoverable-root_partitions-v1-0-39c78fac42e2@kernel.org>
DPS [1] defines GPT attribute bit 63 as no-auto. Partitions with this
bit set must not be used by automatic discovery.
Add the new GPT_ATTRIBUTE_NO_AUTO flag to designate the GPT attribute
bit 63.
Add the new ADDPART_FLAG_NO_AUTO flag and set it when
GPT_ATTRIBUTE_NO_AUTO is set during the partition scan. Then, propagate
it to the new BD_NO_AUTO_DISCOVERY flag.
Finally, add a condition to match_dev_by_type_uuid() to exclude any
partition with that flag from the automatic discovery.
[1] The Discoverable Partitions Specification (DPS)
Link: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
---
block/blk.h | 1 +
block/early-lookup.c | 1 +
block/partitions/core.c | 2 ++
block/partitions/efi.c | 2 ++
block/partitions/efi.h | 3 +++
include/linux/blk_types.h | 1 +
6 files changed, 10 insertions(+)
diff --git a/block/blk.h b/block/blk.h
index b998a7761faf..14e0f349ff14 100644
--- a/block/blk.h
+++ b/block/blk.h
@@ -604,6 +604,7 @@ void blk_free_ext_minor(unsigned int minor);
#define ADDPART_FLAG_RAID 1
#define ADDPART_FLAG_WHOLEDISK 2
#define ADDPART_FLAG_READONLY 4
+#define ADDPART_FLAG_NO_AUTO 8
int bdev_add_partition(struct gendisk *disk, int partno, sector_t start,
sector_t length);
int bdev_del_partition(struct gendisk *disk, int partno);
diff --git a/block/early-lookup.c b/block/early-lookup.c
index cd10785e70ac..8db0abec141e 100644
--- a/block/early-lookup.c
+++ b/block/early-lookup.c
@@ -266,6 +266,7 @@ static int __init match_dev_by_type_uuid(struct device *dev, const void *data)
const struct uuidcmp *cmp = data;
return bdev->bd_disk == cmp->disk && bdev->bd_meta_info &&
+ !bdev_test_flag(bdev, BD_NO_AUTO_DISCOVERY) &&
!strcasecmp(cmp->uuid, bdev->bd_meta_info->type_uuid);
}
diff --git a/block/partitions/core.c b/block/partitions/core.c
index 5d5332ce586b..4529ea1d308e 100644
--- a/block/partitions/core.c
+++ b/block/partitions/core.c
@@ -382,6 +382,8 @@ static struct block_device *add_partition(struct gendisk *disk, int partno,
if (flags & ADDPART_FLAG_READONLY)
bdev_set_flag(bdev, BD_READ_ONLY);
+ if (flags & ADDPART_FLAG_NO_AUTO)
+ bdev_set_flag(bdev, BD_NO_AUTO_DISCOVERY);
/* everything is up and running, commence */
err = xa_insert(&disk->part_tbl, partno, bdev, GFP_KERNEL);
diff --git a/block/partitions/efi.c b/block/partitions/efi.c
index 4a3835ed9561..50c21625e256 100644
--- a/block/partitions/efi.c
+++ b/block/partitions/efi.c
@@ -739,6 +739,8 @@ int efi_partition(struct parsed_partitions *state)
/* If this is a RAID volume, tell md */
if (!efi_guidcmp(ptes[i].partition_type_guid, PARTITION_LINUX_RAID_GUID))
state->parts[i + 1].flags = ADDPART_FLAG_RAID;
+ if (le64_to_cpu(ptes[i].attributes) & GPT_ATTRIBUTE_NO_AUTO)
+ state->parts[i + 1].flags |= ADDPART_FLAG_NO_AUTO;
info = &state->parts[i + 1].info;
efi_guid_to_str(&ptes[i].unique_partition_guid, info->uuid);
diff --git a/block/partitions/efi.h b/block/partitions/efi.h
index 1f56f93b2804..fb50edb66e84 100644
--- a/block/partitions/efi.h
+++ b/block/partitions/efi.h
@@ -11,6 +11,7 @@
#ifndef FS_PART_EFI_H_INCLUDED
#define FS_PART_EFI_H_INCLUDED
+#include <linux/bits.h>
#include <linux/types.h>
#include <linux/fs.h>
#include <linux/kernel.h>
@@ -30,6 +31,8 @@
#define GPT_HEADER_REVISION_V1 0x00010000
#define GPT_PRIMARY_PARTITION_TABLE_LBA 1
+#define GPT_ATTRIBUTE_NO_AUTO BIT_U64(63)
+
#define PARTITION_SYSTEM_GUID \
EFI_GUID( 0xC12A7328, 0xF81F, 0x11d2, \
0xBA, 0x4B, 0x00, 0xA0, 0xC9, 0x3E, 0xC9, 0x3B)
diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
index 8808ee76e73c..c6cdc99b0490 100644
--- a/include/linux/blk_types.h
+++ b/include/linux/blk_types.h
@@ -54,6 +54,7 @@ struct block_device {
#ifdef CONFIG_FAIL_MAKE_REQUEST
#define BD_MAKE_IT_FAIL (1u<<12)
#endif
+#define BD_NO_AUTO_DISCOVERY (1u<<13)
dev_t bd_dev;
struct address_space *bd_mapping; /* page cache */
--
2.53.0
^ permalink raw reply related
* [PATCH 15/19] block: store GPT attributes as a raw value
From: Vincent Mailhol @ 2026-06-15 16:09 UTC (permalink / raw)
To: Jens Axboe, Davidlohr Bueso, Alexander Viro, Christian Brauner,
Jan Kara
Cc: linux-kernel, linux-block, linux-efi, linux-fsdevel,
Vincent Mailhol
In-Reply-To: <20260615-discoverable-root_partitions-v1-0-39c78fac42e2@kernel.org>
struct _gpt_entry_attributes currently models the GPT partition entry
attributes field with bitfields. This is broken on machines using the
__BIG_ENDIAN_BITFIELD ABI because GPT always stores the attributes on
disk as a 64-bit little-endian.
No current code consumes individual fields from that structure. So just
remove struct _gpt_entry_attributes entirely and replace it by an __le64
value in struct _gpt_entry.
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
---
block/partitions/efi.h | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/block/partitions/efi.h b/block/partitions/efi.h
index 84b9f36b9e47..1f56f93b2804 100644
--- a/block/partitions/efi.h
+++ b/block/partitions/efi.h
@@ -75,18 +75,12 @@ typedef struct _gpt_header {
*/
} __packed gpt_header;
-typedef struct _gpt_entry_attributes {
- u64 required_to_function:1;
- u64 reserved:47;
- u64 type_guid_specific:16;
-} __packed gpt_entry_attributes;
-
typedef struct _gpt_entry {
efi_guid_t partition_type_guid;
efi_guid_t unique_partition_guid;
__le64 starting_lba;
__le64 ending_lba;
- gpt_entry_attributes attributes;
+ __le64 attributes;
__le16 partition_name[72/sizeof(__le16)];
} __packed gpt_entry;
--
2.53.0
^ permalink raw reply related
* [PATCH 14/19] block: add early_lookup_bdev_by_type_uuid()
From: Vincent Mailhol @ 2026-06-15 16:09 UTC (permalink / raw)
To: Jens Axboe, Davidlohr Bueso, Alexander Viro, Christian Brauner,
Jan Kara
Cc: linux-kernel, linux-block, linux-efi, linux-fsdevel,
Vincent Mailhol
In-Reply-To: <20260615-discoverable-root_partitions-v1-0-39c78fac42e2@kernel.org>
Add early_lookup_bdev_by_type_uuid() to find the root block device by
its GPT type UUID on the disk containing the active EFI System
Partition.
DPS [1] requires OS partition discovery to be limited to the disk
containing the active EFI System Partition. Reuse the existing block
class lookup and UUID matching callback to identify that disk, then do a
second lookup constrained to it. If the disk contains several partitions
with a matching type UUID, use the first match, following the DPS
discovery rule.
Extend struct uuidcmp with the new disk field so that it can be used in
the new match_dev_by_type_uuid() callback function.
Update devt_from_partuuid() to initialize cmp with a designated
initializer so that the new cmp.disk field is zero-initialized. This is
not strictly needed, but keeps the code cleaner.
[1] The Discoverable Partitions Specification (DPS)
Link: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
---
block/early-lookup.c | 67 +++++++++++++++++++++++++++++++++++++++++++++++---
include/linux/blkdev.h | 4 +++
2 files changed, 68 insertions(+), 3 deletions(-)
diff --git a/block/early-lookup.c b/block/early-lookup.c
index 3fb57f7d2b12..cd10785e70ac 100644
--- a/block/early-lookup.c
+++ b/block/early-lookup.c
@@ -5,10 +5,12 @@
*/
#include <linux/blkdev.h>
#include <linux/ctype.h>
+#include <linux/uuid.h>
struct uuidcmp {
const char *uuid;
int len;
+ struct gendisk *disk;
};
/**
@@ -45,13 +47,11 @@ static int __init match_dev_by_uuid(struct device *dev, const void *data)
*/
static int __init devt_from_partuuid(const char *uuid_str, dev_t *devt)
{
- struct uuidcmp cmp;
+ struct uuidcmp cmp = { .uuid = uuid_str };
struct device *dev = NULL;
int offset = 0;
char *slash;
- cmp.uuid = uuid_str;
-
slash = strchr(uuid_str, '/');
/* Check for optional partition number offset attributes. */
if (slash) {
@@ -252,6 +252,67 @@ int __init early_lookup_bdev(const char *name, dev_t *devt)
return devt_from_devnum(name, devt);
}
+#ifdef CONFIG_DPS_ROOT_AUTO_DISCOVERY
+/**
+ * match_dev_by_type_uuid - callback for finding a partition using its type UUID
+ * @dev: device passed in by the caller
+ * @data: opaque pointer to the desired struct uuidcmp to match
+ *
+ * Returns: 1 if the device matches, and 0 otherwise.
+ */
+static int __init match_dev_by_type_uuid(struct device *dev, const void *data)
+{
+ struct block_device *bdev = dev_to_bdev(dev);
+ const struct uuidcmp *cmp = data;
+
+ return bdev->bd_disk == cmp->disk && bdev->bd_meta_info &&
+ !strcasecmp(cmp->uuid, bdev->bd_meta_info->type_uuid);
+}
+
+/**
+ * early_lookup_bdev_by_type_uuid - look up a partition by its type UUID
+ * @type_uuid: partition type UUID to search for
+ * @efi_partuuid: partition UUID identifying the active EFI partition
+ * @devt: matching dev_t result
+ *
+ * This helper follows the Discoverable Partitions Specification rules. It uses
+ * @efi_partuuid to find the disk containing the active EFI System Partition,
+ * then searches only partitions on that disk for the partition type UUID
+ * specified by @type_uuid.
+ *
+ * Returns: 0 on success or a negative error code on failure.
+ */
+int __init early_lookup_bdev_by_type_uuid(const char *type_uuid,
+ const char *efi_partuuid, dev_t *devt)
+{
+ struct uuidcmp efi_cmp = {
+ .uuid = efi_partuuid,
+ .len = UUID_STRING_LEN,
+ };
+ struct uuidcmp type_cmp = {
+ .uuid = type_uuid,
+ };
+ struct device *efi_dev;
+ struct device *type_dev;
+
+ efi_dev = class_find_device(&block_class, NULL, &efi_cmp,
+ &match_dev_by_uuid);
+ if (!efi_dev)
+ return -ENODEV;
+
+ type_cmp.disk = dev_to_disk(efi_dev);
+ type_dev = class_find_device(&block_class, NULL, &type_cmp,
+ &match_dev_by_type_uuid);
+ put_device(efi_dev);
+ if (!type_dev)
+ return -ENODEV;
+
+ *devt = type_dev->devt;
+ put_device(type_dev);
+ return 0;
+}
+#endif
+
static char __init *bdevt_str(dev_t devt, char *buf)
{
if (MAJOR(devt) <= 0xff && MINOR(devt) <= 0xff) {
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 8ce85d21a1f4..c2b7d07c92e7 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1800,6 +1800,10 @@ void sync_bdevs(bool wait);
void bdev_statx(const struct path *path, struct kstat *stat, u32 request_mask);
void printk_all_partitions(void);
int __init early_lookup_bdev(const char *pathname, dev_t *dev);
+#ifdef CONFIG_DPS_ROOT_AUTO_DISCOVERY
+int __init early_lookup_bdev_by_type_uuid(const char *type_uuid,
+ const char *efi_partuuid, dev_t *dev);
+#endif
#else
static inline void invalidate_bdev(struct block_device *bdev)
{
--
2.53.0
^ permalink raw reply related
* [PATCH 13/19] block: store GPT partition type UUID
From: Vincent Mailhol @ 2026-06-15 16:09 UTC (permalink / raw)
To: Jens Axboe, Davidlohr Bueso, Alexander Viro, Christian Brauner,
Jan Kara
Cc: linux-kernel, linux-block, linux-efi, linux-fsdevel,
Vincent Mailhol
In-Reply-To: <20260615-discoverable-root_partitions-v1-0-39c78fac42e2@kernel.org>
DPS [1] identifies OS partitions by GPT partition type UUID.
Keep that UUID in partition_meta_info and populate it while scanning EFI
partition tables so early root discovery can use it.
[1] The Discoverable Partitions Specification (DPS)
Link: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
---
block/partitions/efi.c | 1 +
include/linux/blkdev.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/block/partitions/efi.c b/block/partitions/efi.c
index 9865d59093fa..4a3835ed9561 100644
--- a/block/partitions/efi.c
+++ b/block/partitions/efi.c
@@ -742,6 +742,7 @@ int efi_partition(struct parsed_partitions *state)
info = &state->parts[i + 1].info;
efi_guid_to_str(&ptes[i].unique_partition_guid, info->uuid);
+ efi_guid_to_str(&ptes[i].partition_type_guid, info->type_uuid);
/* Naively convert UTF16-LE to 7 bits. */
label_max = min(ARRAY_SIZE(info->volname) - 1,
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 890128cdea1c..8ce85d21a1f4 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -67,6 +67,7 @@ extern const struct class block_class;
struct partition_meta_info {
char uuid[PARTITION_META_INFO_UUIDLTH];
+ char type_uuid[PARTITION_META_INFO_UUIDLTH];
u8 volname[PARTITION_META_INFO_VOLNAMELTH];
};
--
2.53.0
^ permalink raw reply related
* [PATCH 12/19] x86: define DPS root partition type UUIDs
From: Vincent Mailhol @ 2026-06-15 16:09 UTC (permalink / raw)
To: Jens Axboe, Davidlohr Bueso, Alexander Viro, Christian Brauner,
Jan Kara
Cc: linux-kernel, linux-block, linux-efi, linux-fsdevel,
Vincent Mailhol, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86
In-Reply-To: <20260615-discoverable-root_partitions-v1-0-39c78fac42e2@kernel.org>
DPS [1] assigns GPT partition type UUIDs to operating system partitions.
Root partitions use architecture-specific type UUIDs so the OS can
discover the intended root filesystem without relying on a root= cmdline
option.
Define DPS_ROOT_PARTITION_TYPE_UUID in asm/dps_root.h for the x86
32/64-bit variants described by the specification and select
ARCH_HAS_DPS_ROOT_PARTITION_TYPE_UUID.
[1] The Discoverable Partitions Specification (DPS)
Link: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
Cc: Thomas Gleixner <tglx@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: x86@kernel.org
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
---
arch/x86/Kconfig | 1 +
arch/x86/include/asm/dps_root.h | 12 ++++++++++++
2 files changed, 13 insertions(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index b875d2f27e48..6b6e7b56f972 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -82,6 +82,7 @@ config X86
select ARCH_HAS_DEBUG_VM_PGTABLE if !X86_PAE
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_DMA_OPS if GART_IOMMU || XEN
+ select ARCH_HAS_DPS_ROOT_PARTITION_TYPE_UUID
select ARCH_HAS_EARLY_DEBUG if KGDB
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_EXECMEM_ROX if X86_64 && STRICT_MODULE_RWX
diff --git a/arch/x86/include/asm/dps_root.h b/arch/x86/include/asm/dps_root.h
new file mode 100644
index 000000000000..7c6ba5519d88
--- /dev/null
+++ b/arch/x86/include/asm/dps_root.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef _ASM_X86_DPS_ROOT_H
+#define _ASM_X86_DPS_ROOT_H
+
+#ifdef CONFIG_X86_64
+#define DPS_ROOT_PARTITION_TYPE_UUID "4f68bce3-e8cd-4db1-96e7-fbcaf984b709"
+#else
+#define DPS_ROOT_PARTITION_TYPE_UUID "44479540-f297-41b2-9af7-d131d5f0458a"
+#endif
+
+#endif /* _ASM_X86_DPS_ROOT_H */
--
2.53.0
^ permalink raw reply related
* [PATCH 11/19] s390: define DPS root partition type UUIDs
From: Vincent Mailhol @ 2026-06-15 16:09 UTC (permalink / raw)
To: Jens Axboe, Davidlohr Bueso, Alexander Viro, Christian Brauner,
Jan Kara
Cc: linux-kernel, linux-block, linux-efi, linux-fsdevel,
Vincent Mailhol, Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
linux-s390
In-Reply-To: <20260615-discoverable-root_partitions-v1-0-39c78fac42e2@kernel.org>
DPS [1] assigns GPT partition type UUIDs to operating system partitions.
Root partitions use architecture-specific type UUIDs so the OS can
discover the intended root filesystem without relying on a root= cmdline
option.
Define DPS_ROOT_PARTITION_TYPE_UUID in asm/dps_root.h for the s390
(32-bit) and s390x (64-bit) variants described by the specification and
select ARCH_HAS_DPS_ROOT_PARTITION_TYPE_UUID.
[1] The Discoverable Partitions Specification (DPS)
Link: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: linux-s390@vger.kernel.org
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
---
arch/s390/Kconfig | 1 +
arch/s390/include/asm/dps_root.h | 12 ++++++++++++
2 files changed, 13 insertions(+)
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index 9921a3772bf7..af2cf67fffd7 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -91,6 +91,7 @@ config S390
select ARCH_HAS_DEBUG_WX
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_DMA_OPS if PCI
+ select ARCH_HAS_DPS_ROOT_PARTITION_TYPE_UUID
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FORCE_DMA_UNENCRYPTED
select ARCH_HAS_FORTIFY_SOURCE
diff --git a/arch/s390/include/asm/dps_root.h b/arch/s390/include/asm/dps_root.h
new file mode 100644
index 000000000000..e72e44a66097
--- /dev/null
+++ b/arch/s390/include/asm/dps_root.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef _ASM_S390_DPS_ROOT_H
+#define _ASM_S390_DPS_ROOT_H
+
+#ifdef CONFIG_64BIT
+#define DPS_ROOT_PARTITION_TYPE_UUID "5eead9a9-fe09-4a1e-a1d7-520d00531306"
+#else
+#define DPS_ROOT_PARTITION_TYPE_UUID "08a7acea-624c-4a20-91e8-6e0fa67d23f9"
+#endif
+
+#endif /* _ASM_S390_DPS_ROOT_H */
--
2.53.0
^ permalink raw reply related
* [PATCH 10/19] riscv: define DPS root partition type UUIDs
From: Vincent Mailhol @ 2026-06-15 16:09 UTC (permalink / raw)
To: Jens Axboe, Davidlohr Bueso, Alexander Viro, Christian Brauner,
Jan Kara
Cc: linux-kernel, linux-block, linux-efi, linux-fsdevel,
Vincent Mailhol, Paul Walmsley, Palmer Dabbelt, Albert Ou,
linux-riscv
In-Reply-To: <20260615-discoverable-root_partitions-v1-0-39c78fac42e2@kernel.org>
DPS [1] assigns GPT partition type UUIDs to operating system partitions.
Root partitions use architecture-specific type UUIDs so the OS can
discover the intended root filesystem without relying on a root= cmdline
option.
Define DPS_ROOT_PARTITION_TYPE_UUID in asm/dps_root.h for the RISC-V
32/64-bit variants described by the specification and select
ARCH_HAS_DPS_ROOT_PARTITION_TYPE_UUID.
[1] The Discoverable Partitions Specification (DPS)
Link: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
Cc: Paul Walmsley <pjw@kernel.org>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: linux-riscv@lists.infradead.org
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
---
arch/riscv/Kconfig | 1 +
arch/riscv/include/asm/dps_root.h | 12 ++++++++++++
2 files changed, 13 insertions(+)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 1a2fadccd4c4..526be67e858a 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -28,6 +28,7 @@ config RISCV
select ARCH_HAS_DEBUG_VIRTUAL if MMU
select ARCH_HAS_DEBUG_VM_PGTABLE
select ARCH_HAS_DEBUG_WX
+ select ARCH_HAS_DPS_ROOT_PARTITION_TYPE_UUID
select ARCH_HAS_ELF_CORE_EFLAGS if BINFMT_ELF && ELF_CORE
select ARCH_HAS_FAST_MULTIPLIER
select ARCH_HAS_FORTIFY_SOURCE
diff --git a/arch/riscv/include/asm/dps_root.h b/arch/riscv/include/asm/dps_root.h
new file mode 100644
index 000000000000..86f8e1dbd6ad
--- /dev/null
+++ b/arch/riscv/include/asm/dps_root.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef _ASM_RISCV_DPS_ROOT_H
+#define _ASM_RISCV_DPS_ROOT_H
+
+#ifdef CONFIG_64BIT
+#define DPS_ROOT_PARTITION_TYPE_UUID "72ec70a6-cf74-40e6-bd49-4bda08e8f224"
+#else
+#define DPS_ROOT_PARTITION_TYPE_UUID "60d5a7fe-8e7d-435c-b714-3dd8162144e1"
+#endif
+
+#endif /* _ASM_RISCV_DPS_ROOT_H */
--
2.53.0
^ permalink raw reply related
* [PATCH 09/19] powerpc: define DPS root partition type UUIDs
From: Vincent Mailhol @ 2026-06-15 16:09 UTC (permalink / raw)
To: Jens Axboe, Davidlohr Bueso, Alexander Viro, Christian Brauner,
Jan Kara
Cc: linux-kernel, linux-block, linux-efi, linux-fsdevel,
Vincent Mailhol, Madhavan Srinivasan, Michael Ellerman,
linuxppc-dev
In-Reply-To: <20260615-discoverable-root_partitions-v1-0-39c78fac42e2@kernel.org>
DPS [1] assigns GPT partition type UUIDs to operating system partitions.
Root partitions use architecture-specific type UUIDs so the OS can
discover the intended root filesystem without relying on a root= cmdline
option.
Define DPS_ROOT_PARTITION_TYPE_UUID in asm/dps_root.h for the powerpc
endian and 32/64-bit variants described by the specification and select
ARCH_HAS_DPS_ROOT_PARTITION_TYPE_UUID.
[1] The Discoverable Partitions Specification (DPS)
Link: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/dps_root.h | 16 ++++++++++++++++
2 files changed, 17 insertions(+)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index e93df95b79e7..e611280a6057 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -134,6 +134,7 @@ config PPC
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_DMA_MAP_DIRECT if PPC_PSERIES
select ARCH_HAS_DMA_OPS if PPC64
+ select ARCH_HAS_DPS_ROOT_PARTITION_TYPE_UUID
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_GCOV_PROFILE_ALL
select ARCH_HAS_GIGANTIC_PAGE if ARCH_SUPPORTS_HUGETLBFS
diff --git a/arch/powerpc/include/asm/dps_root.h b/arch/powerpc/include/asm/dps_root.h
new file mode 100644
index 000000000000..6b3592a73d3d
--- /dev/null
+++ b/arch/powerpc/include/asm/dps_root.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef _ASM_POWERPC_DPS_ROOT_H
+#define _ASM_POWERPC_DPS_ROOT_H
+
+#ifdef CONFIG_PPC64
+#ifdef CONFIG_CPU_LITTLE_ENDIAN
+#define DPS_ROOT_PARTITION_TYPE_UUID "c31c45e6-3f39-412e-80fb-4809c4980599"
+#else
+#define DPS_ROOT_PARTITION_TYPE_UUID "912ade1d-a839-4913-8964-a10eee08fbd2"
+#endif
+#else
+#define DPS_ROOT_PARTITION_TYPE_UUID "1de3f1ef-fa98-47b5-8dcd-4a860a654d78"
+#endif
+
+#endif /* _ASM_POWERPC_DPS_ROOT_H */
--
2.53.0
^ permalink raw reply related
* [PATCH 08/19] parisc: define DPS root partition type UUID
From: Vincent Mailhol @ 2026-06-15 16:09 UTC (permalink / raw)
To: Jens Axboe, Davidlohr Bueso, Alexander Viro, Christian Brauner,
Jan Kara
Cc: linux-kernel, linux-block, linux-efi, linux-fsdevel,
Vincent Mailhol, James E.J. Bottomley, Helge Deller, linux-parisc
In-Reply-To: <20260615-discoverable-root_partitions-v1-0-39c78fac42e2@kernel.org>
DPS [1] assigns GPT partition type UUIDs to operating system partitions.
Root partitions use architecture-specific type UUIDs so the OS can
discover the intended root filesystem without relying on a root= cmdline
option.
Define DPS_ROOT_PARTITION_TYPE_UUID in asm/dps_root.h for parisc and
select ARCH_HAS_DPS_ROOT_PARTITION_TYPE_UUID.
[1] The Discoverable Partitions Specification (DPS)
Link: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
Cc: Helge Deller <deller@gmx.de>
Cc: linux-parisc@vger.kernel.org
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
---
arch/parisc/Kconfig | 1 +
arch/parisc/include/asm/dps_root.h | 8 ++++++++
2 files changed, 9 insertions(+)
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index d3afac2f0d9b..94f0a758176a 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -24,6 +24,7 @@ config PARISC
select ARCH_STACKWALK
select ARCH_HAS_CACHE_LINE_SIZE
select ARCH_HAS_DEBUG_VM_PGTABLE
+ select ARCH_HAS_DPS_ROOT_PARTITION_TYPE_UUID
select HAVE_RELIABLE_STACKTRACE
select RTC_CLASS
select RTC_DRV_GENERIC
diff --git a/arch/parisc/include/asm/dps_root.h b/arch/parisc/include/asm/dps_root.h
new file mode 100644
index 000000000000..bf475cd5b01c
--- /dev/null
+++ b/arch/parisc/include/asm/dps_root.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef _ASM_PARISC_DPS_ROOT_H
+#define _ASM_PARISC_DPS_ROOT_H
+
+#define DPS_ROOT_PARTITION_TYPE_UUID "1aacdb3b-5444-4138-bd9e-e5c2239b2346"
+
+#endif /* _ASM_PARISC_DPS_ROOT_H */
--
2.53.0
^ permalink raw reply related
* [PATCH 07/19] mips: define DPS root partition type UUIDs
From: Vincent Mailhol @ 2026-06-15 16:09 UTC (permalink / raw)
To: Jens Axboe, Davidlohr Bueso, Alexander Viro, Christian Brauner,
Jan Kara
Cc: linux-kernel, linux-block, linux-efi, linux-fsdevel,
Vincent Mailhol, Thomas Bogendoerfer, linux-mips
In-Reply-To: <20260615-discoverable-root_partitions-v1-0-39c78fac42e2@kernel.org>
DPS [1] assigns GPT partition type UUIDs to operating system partitions.
Root partitions use architecture-specific type UUIDs so the OS can
discover the intended root filesystem without relying on a root= cmdline
option.
Define DPS_ROOT_PARTITION_TYPE_UUID in asm/dps_root.h for the MIPS
endian and 32/64-bit variants described by the specification and select
ARCH_HAS_DPS_ROOT_PARTITION_TYPE_UUID.
[1] The Discoverable Partitions Specification (DPS)
Link: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: linux-mips@vger.kernel.org
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
---
arch/mips/Kconfig | 1 +
arch/mips/include/asm/dps_root.h | 20 ++++++++++++++++++++
2 files changed, 21 insertions(+)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 4364f3dba688..15dd7d336cfa 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -10,6 +10,7 @@ config MIPS
select ARCH_HAS_CURRENT_STACK_POINTER
select ARCH_HAS_DEBUG_VIRTUAL if !64BIT
select ARCH_HAS_DMA_OPS if MACH_JAZZ
+ select ARCH_HAS_DPS_ROOT_PARTITION_TYPE_UUID
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_KCOV
select ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE if !EVA
diff --git a/arch/mips/include/asm/dps_root.h b/arch/mips/include/asm/dps_root.h
new file mode 100644
index 000000000000..b07cab7399ad
--- /dev/null
+++ b/arch/mips/include/asm/dps_root.h
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef _ASM_MIPS_DPS_ROOT_H
+#define _ASM_MIPS_DPS_ROOT_H
+
+#ifdef CONFIG_CPU_LITTLE_ENDIAN
+#ifdef CONFIG_64BIT
+#define DPS_ROOT_PARTITION_TYPE_UUID "700bda43-7a34-4507-b179-eeb93d7a7ca3"
+#else
+#define DPS_ROOT_PARTITION_TYPE_UUID "37c58c8a-d913-4156-a25f-48b1b64e07f0"
+#endif
+#else
+#ifdef CONFIG_64BIT
+#define DPS_ROOT_PARTITION_TYPE_UUID "d113af76-80ef-41b4-bdb6-0cff4d3d4a25"
+#else
+#define DPS_ROOT_PARTITION_TYPE_UUID "e9434544-6e2c-47cc-bae2-12d6deafb44c"
+#endif
+#endif
+
+#endif /* _ASM_MIPS_DPS_ROOT_H */
--
2.53.0
^ permalink raw reply related
* [PATCH 06/19] loongarch: define DPS root partition type UUID
From: Vincent Mailhol @ 2026-06-15 16:09 UTC (permalink / raw)
To: Jens Axboe, Davidlohr Bueso, Alexander Viro, Christian Brauner,
Jan Kara
Cc: linux-kernel, linux-block, linux-efi, linux-fsdevel,
Vincent Mailhol, Huacai Chen, WANG Xuerui, loongarch
In-Reply-To: <20260615-discoverable-root_partitions-v1-0-39c78fac42e2@kernel.org>
DPS [1] assigns GPT partition type UUIDs to operating system partitions.
Root partitions use architecture-specific type UUIDs so the OS can
discover the intended root filesystem without relying on a root= cmdline
option.
Define DPS_ROOT_PARTITION_TYPE_UUID in asm/dps_root.h for LoongArch64
and select ARCH_HAS_DPS_ROOT_PARTITION_TYPE_UUID.
[1] The Discoverable Partitions Specification (DPS)
Link: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
Cc: Huacai Chen <chenhuacai@kernel.org>
Cc: WANG Xuerui <kernel@xen0n.name>
Cc: loongarch@lists.linux.dev
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
---
arch/loongarch/Kconfig | 1 +
arch/loongarch/include/asm/dps_root.h | 8 ++++++++
2 files changed, 9 insertions(+)
diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig
index 606597da46b8..64c27740b8a1 100644
--- a/arch/loongarch/Kconfig
+++ b/arch/loongarch/Kconfig
@@ -17,6 +17,7 @@ config LOONGARCH
select ARCH_HAS_CPU_FINALIZE_INIT
select ARCH_HAS_CURRENT_STACK_POINTER
select ARCH_HAS_DEBUG_VM_PGTABLE
+ select ARCH_HAS_DPS_ROOT_PARTITION_TYPE_UUID
select ARCH_HAS_FAST_MULTIPLIER
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_KCOV
diff --git a/arch/loongarch/include/asm/dps_root.h b/arch/loongarch/include/asm/dps_root.h
new file mode 100644
index 000000000000..6022b60428ad
--- /dev/null
+++ b/arch/loongarch/include/asm/dps_root.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef _ASM_LOONGARCH_DPS_ROOT_H
+#define _ASM_LOONGARCH_DPS_ROOT_H
+
+#define DPS_ROOT_PARTITION_TYPE_UUID "77055800-792c-4f94-b39a-98c91b762bb6"
+
+#endif /* _ASM_LOONGARCH_DPS_ROOT_H */
--
2.53.0
^ permalink raw reply related
* [PATCH 05/19] arm64: define DPS root partition type UUID
From: Vincent Mailhol @ 2026-06-15 16:09 UTC (permalink / raw)
To: Jens Axboe, Davidlohr Bueso, Alexander Viro, Christian Brauner,
Jan Kara
Cc: linux-kernel, linux-block, linux-efi, linux-fsdevel,
Vincent Mailhol, Catalin Marinas, Will Deacon, linux-arm-kernel
In-Reply-To: <20260615-discoverable-root_partitions-v1-0-39c78fac42e2@kernel.org>
DPS [1] assigns GPT partition type UUIDs to operating system partitions.
Root partitions use architecture-specific type UUIDs so the OS can
discover the intended root filesystem without relying on a root= cmdline
option.
Define DPS_ROOT_PARTITION_TYPE_UUID in asm/dps_root.h for arm64 and select
ARCH_HAS_DPS_ROOT_PARTITION_TYPE_UUID.
[1] The Discoverable Partitions Specification (DPS)
Link: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/dps_root.h | 8 ++++++++
2 files changed, 9 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index fe60738e5943..190f8dde63b2 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -26,6 +26,7 @@ config ARM64
select ARCH_HAS_DEBUG_VM_PGTABLE
select ARCH_HAS_DMA_OPS if XEN
select ARCH_HAS_DMA_PREP_COHERENT
+ select ARCH_HAS_DPS_ROOT_PARTITION_TYPE_UUID
select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
select ARCH_HAS_FAST_MULTIPLIER
select ARCH_HAS_FORTIFY_SOURCE
diff --git a/arch/arm64/include/asm/dps_root.h b/arch/arm64/include/asm/dps_root.h
new file mode 100644
index 000000000000..7344f9a52343
--- /dev/null
+++ b/arch/arm64/include/asm/dps_root.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef _ASM_ARM64_DPS_ROOT_H
+#define _ASM_ARM64_DPS_ROOT_H
+
+#define DPS_ROOT_PARTITION_TYPE_UUID "b921b045-1df0-41c3-af44-4c6f280d3fae"
+
+#endif /* _ASM_ARM64_DPS_ROOT_H */
--
2.53.0
^ permalink raw reply related
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