* Re: [PATCH V2] bio: fix kmemleak false positives from percpu bio alloc cache
From: Jens Axboe @ 2026-04-02 13:09 UTC (permalink / raw)
To: linux-block, Ming Lei; +Cc: Yi Zhang
In-Reply-To: <20260326144058.2392319-1-ming.lei@redhat.com>
On Thu, 26 Mar 2026 22:40:58 +0800, Ming Lei wrote:
> When a bio is allocated from the mempool with REQ_ALLOC_CACHE set and
> later completed, bio_put() places it into the per-cpu bio_alloc_cache
> via bio_put_percpu_cache() instead of freeing it back to the
> mempool/slab. The slab allocation remains tracked by kmemleak, but the
> only reference to the bio is through the percpu cache's free_list,
> which kmemleak fails to trace through percpu memory. This causes
> kmemleak to report the cached bios as unreferenced objects.
>
> [...]
Applied, thanks!
[1/1] bio: fix kmemleak false positives from percpu bio alloc cache
commit: c691e4b0d80be423f0a7443b53898eafe9c8754b
Best regards,
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH 6.1.y 5/8] nvme-apple: remove an extra queue reference
From: Heyne, Maximilian @ 2026-04-02 12:31 UTC (permalink / raw)
To: Fedor Pchelkin
Cc: Christoph Hellwig, Sagi Grimberg, stable@vger.kernel.org,
Sven Peter, Chaitanya Kulkarni, Keith Busch, Jens Axboe,
Hector Martin, Alyssa Rosenzweig, James E.J. Bottomley,
Martin K. Petersen, Alim Akhtar, Avri Altman, Bart Van Assche,
Sasha Levin, Peter Wang, Greg Kroah-Hartman, Seunghui Lee,
Sanjeev Yadav, Wonkon Kim, Brian Kao, Hannes Reinecke, Ming Lei,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
asahi@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-nvme@lists.infradead.org, linux-scsi@vger.kernel.org
In-Reply-To: <20260401232116-53765a086f3855a30962fb81-pchelkin@ispras>
On Wed, Apr 01, 2026 at 11:45:57PM +0300, Fedor Pchelkin wrote:
> Hello,
>
> "Heyne, Maximilian" <mheyne@amazon.de> wrote:
> > From: Christoph Hellwig <hch@lst.de>
> >
> > [ Upstream commit 941f7298c70c7668416e7845fa76eb72c07d966b ]
> >
> > Now that blk_mq_destroy_queue does not release the queue reference, there
> > is no need for a second admin queue reference to be held by the
> > apple_nvme structure.
>
> This patch is probably buggy in upstream. It removes extra reference
> ->get, but doesn't remove the corresponding ->put which is located
> inside apple_nvme_free_ctrl().
Now I'm seeing this as well. Has the same problem as the pci driver in
6.1 where blk_put_queue is called from nvme_free_ctrl() and again from
apple_nvme_free_ctrl(). Thank you for catching this. I don't have the
hardware to test this.
Are you going to send a fix upstream? It's looks to be broken on master,
too.
>
> I'm reporting here currently just for the heads up - was looking at the
> same nvme regression problem at 6.1.y, found this thread, and the
> nvme-apple changes appeared suspicious.
>
> nvme-apple patch is not required to fix the regression (this also holds
> true for [PATCH 6.1.y 3/8] scsi: remove an extra queue reference). Maybe
> they shouldn't go to stable.
I think, I'll send a v2 of the patch set without these 2 patches. It's
probably easier for Greg to apply.
>
> That said, the other part of the backport series FWIW looks good to me,
> and I've also verified it resolves the 6.1.y regression.
You may leave a Tested-by if you want ;-)
>
> Thanks.
>
> >
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
> > Reviewed-by: Sven Peter <sven@svenpeter.dev>
> > Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
> > Reviewed-by: Keith Busch <kbusch@kernel.org>
> > Link: https://lore.kernel.org/r/20221018135720.670094-5-hch@lst.de
> > Signed-off-by: Jens Axboe <axboe@kernel.dk>
> > Signed-off-by: Maximilian Heyne <mheyne@amazon.de>
> > ---
> > drivers/nvme/host/apple.c | 9 ---------
> > 1 file changed, 9 deletions(-)
> >
> > diff --git a/drivers/nvme/host/apple.c b/drivers/nvme/host/apple.c
> > index c5fc293c22123..c84ebfcfdeb88 100644
> > --- a/drivers/nvme/host/apple.c
> > +++ b/drivers/nvme/host/apple.c
> > @@ -1507,15 +1507,6 @@ static int apple_nvme_probe(struct platform_device *pdev)
> > goto put_dev;
> > }
> >
> > - if (!blk_get_queue(anv->ctrl.admin_q)) {
> > - nvme_start_admin_queue(&anv->ctrl);
> > - blk_mq_destroy_queue(anv->ctrl.admin_q);
> > - blk_put_queue(anv->ctrl.admin_q);
> > - anv->ctrl.admin_q = NULL;
> > - ret = -ENODEV;
> > - goto put_dev;
> > - }
> > -
> > nvme_reset_ctrl(&anv->ctrl);
> > async_schedule(apple_nvme_async_probe, anv);
> >
> > --
> > 2.50.1
Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christof Hellmis, Andreas Stieger
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597
^ permalink raw reply
* Re: [PATCH V2] bio: fix kmemleak false positives from percpu bio alloc cache
From: Ming Lei @ 2026-04-02 9:47 UTC (permalink / raw)
To: Jens Axboe, linux-block; +Cc: Yi Zhang
In-Reply-To: <20260326144058.2392319-1-ming.lei@redhat.com>
On Thu, Mar 26, 2026 at 10:41 PM Ming Lei <ming.lei@redhat.com> wrote:
>
> When a bio is allocated from the mempool with REQ_ALLOC_CACHE set and
> later completed, bio_put() places it into the per-cpu bio_alloc_cache
> via bio_put_percpu_cache() instead of freeing it back to the
> mempool/slab. The slab allocation remains tracked by kmemleak, but the
> only reference to the bio is through the percpu cache's free_list,
> which kmemleak fails to trace through percpu memory. This causes
> kmemleak to report the cached bios as unreferenced objects.
>
> Use symmetric kmemleak_free()/kmemleak_alloc() calls to properly track
> bios across percpu cache transitions:
>
> - bio_put_percpu_cache: call kmemleak_free() when a bio enters the
> cache, unregistering it from kmemleak tracking.
>
> - bio_alloc_percpu_cache: call kmemleak_alloc() when a bio is taken
> from the cache for reuse, re-registering it so that genuine leaks
> of reused bios remain detectable.
>
> - __bio_alloc_cache_prune: call kmemleak_alloc() before bio_free() so
> that kmem_cache_free()'s internal kmemleak_free() has a matching
> allocation to pair with.
>
> Tested-by: Yi Zhang <yi.zhang@redhat.com>
> Signed-off-by: Ming Lei <ming.lei@redhat.com>
> ---
> V2:
> - rebase on for-7.1/block
> - add helper of bio_slab_addr()
Hello Jens,
Ping...
Thanks,
^ permalink raw reply
* Re: [PATCH v9 09/13] isolation: Introduce io_queue isolcpus type
From: Sebastian Andrzej Siewior @ 2026-04-02 9:09 UTC (permalink / raw)
To: Aaron Tomlin
Cc: axboe, kbusch, hch, sagi, mst, aacraid, James.Bottomley,
martin.petersen, liyihang9, kashyap.desai, sumit.saxena,
shivasharan.srikanteshwara, chandrakanth.patil, sathya.prakash,
sreekanth.reddy, suganath-prabu.subramani, ranjan.kumar,
jinpu.wang, tglx, mingo, peterz, juri.lelli, vincent.guittot,
akpm, maz, ruanjinjie, yphbchou0911, wagi, frederic, longman,
chenridong, hare, kch, ming.lei, steve, sean, chjohnst, neelx,
mproche, linux-block, linux-kernel, virtualization, linux-nvme,
linux-scsi, megaraidlinux.pdl, mpi3mr-linuxdrv.pdl,
MPT-FusionLinux.pdl
In-Reply-To: <c7phvlvohdn2ksc2jymxk5foolwlqaqq2jzcdv7oic4uzomh3j@yjimbwcnnst3>
On 2026-04-01 16:58:22 [-0400], Aaron Tomlin wrote:
> Hi Sebastian,
Hi,
> Thank you for taking the time to document the "managed_irq" behaviour; it
> is immensely helpful. You raise a highly pertinent point regarding the
> potential proliferation of "isolcpus=" flags. It is certainly a situation
> that must be managed carefully to prevent every subsystem from demanding
> its own bit.
>
> To clarify the reasoning behind introducing "io_queue" rather than strictly
> relying on managed_irq:
>
> The managed_irq flag belongs firmly to the interrupt subsystem. It dictates
> whether a CPU is eligible to receive hardware interrupts whose affinity is
> managed by the kernel. Whilst many modern block drivers use managed IRQs,
> the block layer multi-queue mapping encompasses far more than just
> interrupt routing. It maps logical queues to CPUs to handle I/O submission,
> software queues, and crucially, poll queues, which do not utilise
> interrupts at all. Furthermore, there are specific drivers that do not use
> the managed IRQ infrastructure but still rely on the block layer for queue
> distribution.
Could you tell block which queue maps to which CPU at /sys/block/$$/mq/
level? Then you have one queue going to one CPU.
Then the drive could request one or more interrupts managed or not. For
managed you could specify a CPU mask which you desire to occupy.
You have the case where
- you have more queues than CPUs
- use all of them
- use less
- less queues than CPUs
- mapped a queue to more than once CPU in case it goes down or becomes
not available
- mapped to one CPU
Ideally you solve this at one level so that the device(s) can request
less queues than CPUs if told so without patching each and every driver.
This should give you the freedom to isolate CPUs, decide at boot time
which CPUs get I/O queues assigned. At run time you can tell which
queues go to which CPUs. If you shutdown a queue, the interrupt remains
but does not get any I/O requests assigned so no problem. If the CPU
goes down, same thing.
I am trying to come up with a design here which I haven't found so far.
But I might be late to the party and everyone else is fully aware.
> If managed_irq were solely relied upon, the IRQ subsystem would
> successfully keep hardware interrupts off the isolated CPUs, but the block
The managed_irqs can't be influence by userland. The CPUs are auto
distributed.
> layer would still blindly map polling queues or non-managed queues to those
> same isolated CPUs. This would force isolated CPUs to process I/O
> submissions or handle polling tasks, thereby breaking the strict isolation.
>
> Regarding the point about the networking subsystem, it is a very valid
> comparison. If the networking layer wishes to respect isolcpus in the
> future, adding a net flag would indeed exacerbate the bit proliferation.
Networking could also have different cases like adding a RX filter and
having HW putting packet based on it in a dedicated queue. But also in
this case I would like to have the freedome to decide which isolated
CPUs should receive interrupts/ traffic and which don't.
> For the present time, retaining io_queue seems the most prudent approach to
> ensure that block queue mapping remains semantically distinct from
> interrupt delivery. This provides an immediate and clean architectural
> boundary. However, if the consensus amongst the maintainers suggests that
> this is too granular, alternative approaches could certainly be considered
> for the future. For instance, a broader, more generic flag could be
> introduced to encompass both block and future networking queue mappings.
> Alternatively, if semantic conflation is deemed acceptable, the existing
> managed_irq housekeeping mask could simply be overloaded within the block
> layer to restrict all queue mappings.
>
> Keeping the current separation appears to be the cleanest solution for this
> series, but your thoughts, and those of the wider community, on potentially
> migrating to a consolidated generic flag in the future would be very much
> welcomed.
I just don't like introducing yet another boot argument, making it a
boot constraint while in my naive view this could be managed at some
degree via sysfs as suggested above.
>
> Kind regards,
Sebastian
^ permalink raw reply
* Re: [PATCH 2/2] block: allow different-pgmap pages as separate bvecs in bio_add_page
From: Naman Jain @ 2026-04-02 8:55 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jens Axboe, Chaitanya Kulkarni, John Hubbard, Logan Gunthorpe,
linux-kernel, linux-block, Saurabh Sengar, Long Li,
Michael Kelley
In-Reply-To: <20260402053057.GA11783@lst.de>
On 4/2/2026 11:00 AM, Christoph Hellwig wrote:
> On Thu, Apr 02, 2026 at 10:51:05AM +0530, Naman Jain wrote:
>> When a direct I/O request spans pages from different chunks (different
>> pgmaps), the current code rejected the second page entirely:
>>
>> if (!zone_device_pages_have_same_pgmap(bv->bv_page, page))
>> return 0; // Rejection - forces bio split or I/O error
>>
>> Both chunks are regular RAM from the DMA perspective
>> (MEMORY_DEVICE_GENERIC, not P2PDMA). The only requirement is that they not
>> be merged into the same bvec segment, which patch 1/2 enforces by adding
>> the pgmap check to biovec_phys_mergeable().
>>
>> This patch allows pages from different pgmaps to be added as separate bvec
>> entries in the same bio, eliminating bio splits and I/O failures
>> when buffers span pgmap boundaries.
>
> Which as I said we can't do in general, as different pgmaps cna have
> different DMA mapping requirements. We might be able to relax this
> if we know multiple pgmaps can be mapped in the same way. I.e.
> replace zone_device_pages_have_same_pgmap with
> zone_device_pages_compatible and add additional conditions to it.
>
>> --- a/block/bio-integrity.c
>> +++ b/block/bio-integrity.c
>> @@ -231,6 +231,9 @@ int bio_integrity_add_page(struct bio *bio, struct page
>> *page,
>> if (bip->bip_vcnt > 0) {
>> struct bio_vec *bv = &bip->bip_vec[bip->bip_vcnt - 1];
>>
>> + if (is_pci_p2pdma_page(bv->bv_page) !=
>> + is_pci_p2pdma_page(page))
>> + return 0;
>> if (zone_device_pages_have_same_pgmap(bv->bv_page, page) &&
>
> The above is implied by not having the same pgmap.
Thanks. If I understand correctly, here is how this would look like.
Please let me know if this is what you suggested.
diff --git a/block/bio-integrity.c b/block/bio-integrity.c
index e79eaf0477943..e54c6e06e1cbb 100644
--- a/block/bio-integrity.c
+++ b/block/bio-integrity.c
@@ -231,10 +231,10 @@ int bio_integrity_add_page(struct bio *bio, struct
page *page,
if (bip->bip_vcnt > 0) {
struct bio_vec *bv = &bip->bip_vec[bip->bip_vcnt - 1];
- if (!zone_device_pages_have_same_pgmap(bv->bv_page, page))
+ if (!zone_device_pages_compatible(bv->bv_page, page))
return 0;
-
- if (bvec_try_merge_hw_page(q, bv, page, len, offset)) {
+ if (zone_device_pages_have_same_pgmap(bv->bv_page, page) &&
+ bvec_try_merge_hw_page(q, bv, page, len, offset)) {
bip->bip_iter.bi_size += len;
return len;
}
diff --git a/block/bio.c b/block/bio.c
index 77067fa346d35..0e70bb912338c 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -1034,10 +1034,10 @@ int bio_add_page(struct bio *bio, struct page *page,
if (bio->bi_vcnt > 0) {
struct bio_vec *bv = &bio->bi_io_vec[bio->bi_vcnt - 1];
- if (!zone_device_pages_have_same_pgmap(bv->bv_page, page))
+ if (!zone_device_pages_compatible(bv->bv_page, page))
return 0;
-
- if (bvec_try_merge_page(bv, page, len, offset)) {
+ if (zone_device_pages_have_same_pgmap(bv->bv_page, page) &&
+ bvec_try_merge_page(bv, page, len, offset)) {
bio->bi_iter.bi_size += len;
return len;
}
diff --git a/block/blk.h b/block/blk.h
index 0cb3441638284..c5710ba4c81b9 100644
--- a/block/blk.h
+++ b/block/blk.h
@@ -136,6 +136,23 @@ static inline bool biovec_phys_mergeable(struct
request_queue *q,
return true;
}
+/*
+ * Check if two pages from potentially different zone device pgmaps can
+ * coexist as separate bvec entries in the same bio.
+ *
+ * The block DMA iterator (blk_dma_map_iter_start) caches the P2PDMA
mapping
+ * state from the first segment and applies it to all subsequent
segments, so
+ * P2PDMA and non-P2PDMA pages must never be mixed in the same bio.
+ *
+ * Other zone device types (FS_DAX, GENERIC) use the same
dma_map_phys() path
+ * as normal RAM. PRIVATE and COHERENT pages never appear in bios.
+ */
+static inline bool zone_device_pages_compatible(const struct page *a,
+ const struct page *b)
+{
+ return is_pci_p2pdma_page(a) == is_pci_p2pdma_page(b);
+}
+
static inline bool __bvec_gap_to_prev(const struct queue_limits *lim,
struct bio_vec *bprv, unsigned int offset)
{
^ permalink raw reply related
* Re: [PATCH v9 09/13] isolation: Introduce io_queue isolcpus type
From: Sebastian Andrzej Siewior @ 2026-04-02 7:58 UTC (permalink / raw)
To: Waiman Long
Cc: Aaron Tomlin, axboe, kbusch, hch, sagi, mst, aacraid,
James.Bottomley, martin.petersen, liyihang9, kashyap.desai,
sumit.saxena, shivasharan.srikanteshwara, chandrakanth.patil,
sathya.prakash, sreekanth.reddy, suganath-prabu.subramani,
ranjan.kumar, jinpu.wang, tglx, mingo, peterz, juri.lelli,
vincent.guittot, akpm, maz, ruanjinjie, yphbchou0911, wagi,
frederic, chenridong, hare, kch, ming.lei, steve, sean, chjohnst,
neelx, mproche, linux-block, linux-kernel, virtualization,
linux-nvme, linux-scsi, megaraidlinux.pdl, mpi3mr-linuxdrv.pdl,
MPT-FusionLinux.pdl
In-Reply-To: <5e6aa61e-0ad0-4027-bba9-cd906ab0d7e8@redhat.com>
On 2026-04-01 15:05:21 [-0400], Waiman Long wrote:
> > Could we please clarify whether we want to keep it and this
> > additionally or if managed_irq could be used instead. This adds another
> > bit. If networking folks jump in on managed_irqs, would they need to
> > duplicate this with their net sub flag?
>
> Yes, I will very much prefer to reuse an existing HK cpumask like
> managed_irqs for this purpose, if possible, rather than adding another
> cpumask that we need to manage. Note that we are in the process of making
> these housekeeping cpumasks modifiable at run time in the near future.
Now if you want to change it at run time, it would mean to reconfigure
the interrupts, device and so on. Not sure if this useful _or_ if it
would be "easier" to just the tell upper layer (block in case of I/O)
not to perform any request on this CPU. Then we would have an interrupt
on that CPU but it wouldn't do anything.
It would only become a problem if you would have less queues than CPUs
and you would like to migrate things.
> Cheers,
> Longman
Sebastian
^ permalink raw reply
* Re: [BUG] RCU stall in blk_mq_timeout_work (potentially a regression in 6.19.7 or 6.19.8)
From: Benjamin Eikel @ 2026-04-02 7:33 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: linux-kernel, Jens Axboe, linux-block,
Linux kernel regressions list
In-Reply-To: <b9262818-14e7-4902-af6c-6c7d3560ac4c@leemhuis.info>
Hi Thorsten and others,
Am Dienstag, 31. März 2026, 10:32:30 Mitteleuropäische Sommerzeit schrieb Thorsten Leemhuis:
> [CCing the regressions list and Jens, the Block layer maintainer, who
> might have an idea what's wrong here and/or how to best debug it]
>
> On 3/27/26 20:28, Benjamin Eikel wrote:
> > Dear Linux kernel developers,
> >
> > I experience repeated RCU stalls in blk_mq_timeout_work causing system
> > freezes. The NVMe drive (more info at the end) shows no errors or
> > controller resets in the kernel log: the hardware appears healthy. No I/O
> > timeout messages precede the stalls.
> >
> > The stall cascades: khugepaged blocks on __lru_add_drain_all waiting for a
> > workqueue flush that cannot complete, and additional kworkers block on a
> > mutex held by the kblockd rescuer thread. The system becomes noticeably
> > unresponsive and then I notice it in the logs.
> >
> > In case the logs are too condensed, please tell me and I can provide them
> > fully. If you have pointers on how this could be reproduced and a commit
> > range,>
> > I could try to bisect the problem.
>
> A bisection with mainline would help a lot. Maybe doing it between
> 6.19.6 and 6.19.8 (which would be quicker) might work out, too (but
> normally it's best to focus on mainline).
I have not yet done this because I do not have a reliable way to reproduce it.
>
> And this is not my area of expertise, but I noticed that some RCU fixes
> went into -rc6, so might be wise to try that first.
I encountered this issue with -rc6 (see log below, same config). I suspect that
this only happens after the notebook has previously been suspended.
Kind regards
Benjamin
== Trace from Linux version 7.0.0-rc6 (1–2 April) ==
Apr 01 20:36:59 thinkpad-benjamin kernel: Linux version 7.0.0-rc6-70-rc6 (benjamin@thinkpad-benjamin) (gcc (Debian 15.2.0-16) 15.2.0, GNU ld (GNU Binutils for Debian) 2.46) #24 SMP PREEMPT_DYNAMIC Tue Mar 31 14:36:43 CEST 2026
Apr 01 20:36:59 thinkpad-benjamin kernel: Command line: BOOT_IMAGE=/vmlinuz-7.0.0-rc6-70-rc6 root=/dev/mapper/thinkpad--benjamin--vg-root ro quiet
[…]
Apr 01 21:06:54 thinkpad-benjamin kernel: PM: suspend entry (s2idle)
[…]
Apr 02 08:44:55 thinkpad-benjamin kernel: PM: suspend exit
[…]
Apr 02 08:50:59 thinkpad-benjamin kernel: INFO: task khugepaged:138 blocked for more than 120 seconds.
Apr 02 08:50:59 thinkpad-benjamin kernel: Not tainted 7.0.0-rc6-70-rc6 #24
Apr 02 08:50:59 thinkpad-benjamin kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Apr 02 08:50:59 thinkpad-benjamin kernel: task:khugepaged state:D stack:0 pid:138 tgid:138 ppid:2 task_flags:0x200040 flags:0x00080000
Apr 02 08:50:59 thinkpad-benjamin kernel: Call Trace:
Apr 02 08:50:59 thinkpad-benjamin kernel: <TASK>
Apr 02 08:50:59 thinkpad-benjamin kernel: __schedule+0x47c/0x1000
Apr 02 08:50:59 thinkpad-benjamin kernel: schedule+0x27/0xd0
Apr 02 08:50:59 thinkpad-benjamin kernel: schedule_timeout+0xbd/0x100
Apr 02 08:50:59 thinkpad-benjamin kernel: wait_for_completion+0x8a/0x140
Apr 02 08:50:59 thinkpad-benjamin kernel: __flush_work+0x276/0x3b0
Apr 02 08:50:59 thinkpad-benjamin kernel: ? __pfx_wq_barrier_func+0x10/0x10
Apr 02 08:50:59 thinkpad-benjamin kernel: __lru_add_drain_all+0x198/0x2b0
Apr 02 08:50:59 thinkpad-benjamin kernel: khugepaged+0x65/0x950
Apr 02 08:50:59 thinkpad-benjamin kernel: ? __pfx_autoremove_wake_function+0x10/0x10
Apr 02 08:50:59 thinkpad-benjamin kernel: ? __pfx_khugepaged+0x10/0x10
Apr 02 08:50:59 thinkpad-benjamin kernel: kthread+0xe3/0x120
Apr 02 08:50:59 thinkpad-benjamin kernel: ? __pfx_kthread+0x10/0x10
Apr 02 08:50:59 thinkpad-benjamin kernel: ret_from_fork+0x2c9/0x360
Apr 02 08:50:59 thinkpad-benjamin kernel: ? __pfx_kthread+0x10/0x10
Apr 02 08:50:59 thinkpad-benjamin kernel: ret_from_fork_asm+0x1a/0x30
Apr 02 08:50:59 thinkpad-benjamin kernel: </TASK>
Apr 02 08:53:00 thinkpad-benjamin kernel: INFO: task khugepaged:138 blocked for more than 241 seconds.
Apr 02 08:53:00 thinkpad-benjamin kernel: Not tainted 7.0.0-rc6-70-rc6 #24
Apr 02 08:53:00 thinkpad-benjamin kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Apr 02 08:53:00 thinkpad-benjamin kernel: task:khugepaged state:D stack:0 pid:138 tgid:138 ppid:2 task_flags:0x200040 flags:0x00080000
Apr 02 08:53:00 thinkpad-benjamin kernel: Call Trace:
Apr 02 08:53:00 thinkpad-benjamin kernel: <TASK>
Apr 02 08:53:00 thinkpad-benjamin kernel: __schedule+0x47c/0x1000
Apr 02 08:53:00 thinkpad-benjamin kernel: schedule+0x27/0xd0
Apr 02 08:53:00 thinkpad-benjamin kernel: schedule_timeout+0xbd/0x100
Apr 02 08:53:00 thinkpad-benjamin kernel: wait_for_completion+0x8a/0x140
Apr 02 08:53:00 thinkpad-benjamin kernel: __flush_work+0x276/0x3b0
Apr 02 08:53:00 thinkpad-benjamin kernel: ? __pfx_wq_barrier_func+0x10/0x10
Apr 02 08:53:00 thinkpad-benjamin kernel: __lru_add_drain_all+0x198/0x2b0
Apr 02 08:53:00 thinkpad-benjamin kernel: khugepaged+0x65/0x950
Apr 02 08:53:00 thinkpad-benjamin kernel: ? __pfx_autoremove_wake_function+0x10/0x10
Apr 02 08:53:00 thinkpad-benjamin kernel: ? __pfx_khugepaged+0x10/0x10
Apr 02 08:53:00 thinkpad-benjamin kernel: kthread+0xe3/0x120
Apr 02 08:53:00 thinkpad-benjamin kernel: ? __pfx_kthread+0x10/0x10
Apr 02 08:53:00 thinkpad-benjamin kernel: ret_from_fork+0x2c9/0x360
Apr 02 08:53:00 thinkpad-benjamin kernel: ? __pfx_kthread+0x10/0x10
Apr 02 08:53:00 thinkpad-benjamin kernel: ret_from_fork_asm+0x1a/0x30
Apr 02 08:53:00 thinkpad-benjamin kernel: </TASK>
Apr 02 08:55:00 thinkpad-benjamin kernel: INFO: task khugepaged:138 blocked for more than 362 seconds.
Apr 02 08:55:00 thinkpad-benjamin kernel: Not tainted 7.0.0-rc6-70-rc6 #24
Apr 02 08:55:00 thinkpad-benjamin kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Apr 02 08:55:00 thinkpad-benjamin kernel: task:khugepaged state:D stack:0 pid:138 tgid:138 ppid:2 task_flags:0x200040 flags:0x00080000
Apr 02 08:55:00 thinkpad-benjamin kernel: Call Trace:
Apr 02 08:55:00 thinkpad-benjamin kernel: <TASK>
Apr 02 08:55:00 thinkpad-benjamin kernel: __schedule+0x47c/0x1000
Apr 02 08:55:00 thinkpad-benjamin kernel: schedule+0x27/0xd0
Apr 02 08:55:00 thinkpad-benjamin kernel: schedule_timeout+0xbd/0x100
Apr 02 08:55:00 thinkpad-benjamin kernel: wait_for_completion+0x8a/0x140
Apr 02 08:55:00 thinkpad-benjamin kernel: __flush_work+0x276/0x3b0
Apr 02 08:55:00 thinkpad-benjamin kernel: ? __pfx_wq_barrier_func+0x10/0x10
Apr 02 08:55:00 thinkpad-benjamin kernel: __lru_add_drain_all+0x198/0x2b0
Apr 02 08:55:00 thinkpad-benjamin kernel: khugepaged+0x65/0x950
Apr 02 08:55:00 thinkpad-benjamin kernel: ? __pfx_autoremove_wake_function+0x10/0x10
Apr 02 08:55:00 thinkpad-benjamin kernel: ? __pfx_khugepaged+0x10/0x10
Apr 02 08:55:00 thinkpad-benjamin kernel: kthread+0xe3/0x120
Apr 02 08:55:00 thinkpad-benjamin kernel: ? __pfx_kthread+0x10/0x10
Apr 02 08:55:00 thinkpad-benjamin kernel: ret_from_fork+0x2c9/0x360
Apr 02 08:55:00 thinkpad-benjamin kernel: ? __pfx_kthread+0x10/0x10
Apr 02 08:55:00 thinkpad-benjamin kernel: ret_from_fork_asm+0x1a/0x30
Apr 02 08:55:00 thinkpad-benjamin kernel: </TASK>
Apr 02 08:57:01 thinkpad-benjamin kernel: INFO: task khugepaged:138 blocked for more than 483 seconds.
Apr 02 08:57:01 thinkpad-benjamin kernel: Not tainted 7.0.0-rc6-70-rc6 #24
Apr 02 08:57:01 thinkpad-benjamin kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Apr 02 08:57:01 thinkpad-benjamin kernel: task:khugepaged state:D stack:0 pid:138 tgid:138 ppid:2 task_flags:0x200040 flags:0x00080000
Apr 02 08:57:01 thinkpad-benjamin kernel: Call Trace:
Apr 02 08:57:01 thinkpad-benjamin kernel: <TASK>
Apr 02 08:57:01 thinkpad-benjamin kernel: __schedule+0x47c/0x1000
Apr 02 08:57:01 thinkpad-benjamin kernel: schedule+0x27/0xd0
Apr 02 08:57:01 thinkpad-benjamin kernel: schedule_timeout+0xbd/0x100
Apr 02 08:57:01 thinkpad-benjamin kernel: wait_for_completion+0x8a/0x140
Apr 02 08:57:01 thinkpad-benjamin kernel: __flush_work+0x276/0x3b0
Apr 02 08:57:01 thinkpad-benjamin kernel: ? __pfx_wq_barrier_func+0x10/0x10
Apr 02 08:57:01 thinkpad-benjamin kernel: __lru_add_drain_all+0x198/0x2b0
Apr 02 08:57:01 thinkpad-benjamin kernel: khugepaged+0x65/0x950
Apr 02 08:57:01 thinkpad-benjamin kernel: ? __pfx_autoremove_wake_function+0x10/0x10
Apr 02 08:57:01 thinkpad-benjamin kernel: ? __pfx_khugepaged+0x10/0x10
Apr 02 08:57:01 thinkpad-benjamin kernel: kthread+0xe3/0x120
Apr 02 08:57:01 thinkpad-benjamin kernel: ? __pfx_kthread+0x10/0x10
Apr 02 08:57:01 thinkpad-benjamin kernel: ret_from_fork+0x2c9/0x360
Apr 02 08:57:01 thinkpad-benjamin kernel: ? __pfx_kthread+0x10/0x10
Apr 02 08:57:01 thinkpad-benjamin kernel: ret_from_fork_asm+0x1a/0x30
Apr 02 08:57:01 thinkpad-benjamin kernel: </TASK>
Apr 02 08:59:02 thinkpad-benjamin kernel: INFO: task kworker/u64:14:126 blocked for more than 120 seconds.
Apr 02 08:59:02 thinkpad-benjamin kernel: Not tainted 7.0.0-rc6-70-rc6 #24
Apr 02 08:59:02 thinkpad-benjamin kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Apr 02 08:59:02 thinkpad-benjamin kernel: task:kworker/u64:14 state:D stack:0 pid:126 tgid:126 ppid:2 task_flags:0x4208060 flags:0x00080000
Apr 02 08:59:02 thinkpad-benjamin kernel: Workqueue: events_unbound idle_cull_fn
Apr 02 08:59:02 thinkpad-benjamin kernel: Call Trace:
Apr 02 08:59:02 thinkpad-benjamin kernel: <TASK>
Apr 02 08:59:02 thinkpad-benjamin kernel: __schedule+0x47c/0x1000
Apr 02 08:59:02 thinkpad-benjamin kernel: schedule+0x27/0xd0
Apr 02 08:59:02 thinkpad-benjamin kernel: schedule_preempt_disabled+0x15/0x30
Apr 02 08:59:02 thinkpad-benjamin kernel: __mutex_lock.constprop.0+0x54b/0xac0
Apr 02 08:59:02 thinkpad-benjamin kernel: ? ttwu_queue_wakelist+0x13c/0x230
Apr 02 08:59:02 thinkpad-benjamin kernel: idle_cull_fn+0x3e/0x170
Apr 02 08:59:02 thinkpad-benjamin kernel: process_one_work+0x19d/0x3a0
Apr 02 08:59:02 thinkpad-benjamin kernel: worker_thread+0x1af/0x320
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_worker_thread+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: kthread+0xe3/0x120
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_kthread+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: ret_from_fork+0x2c9/0x360
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_kthread+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: ret_from_fork_asm+0x1a/0x30
Apr 02 08:59:02 thinkpad-benjamin kernel: </TASK>
Apr 02 08:59:02 thinkpad-benjamin kernel: INFO: task kworker/u64:14:126 is blocked on a mutex likely owned by task kworker/R-kbloc:139.
Apr 02 08:59:02 thinkpad-benjamin kernel: task:kworker/R-kbloc state:R running task stack:0 pid:139 tgid:139 ppid:2 task_flags:0x4208060 flags:0x00080000
Apr 02 08:59:02 thinkpad-benjamin kernel: Call Trace:
Apr 02 08:59:02 thinkpad-benjamin kernel: <TASK>
Apr 02 08:59:02 thinkpad-benjamin kernel: __schedule+0x47c/0x1000
Apr 02 08:59:02 thinkpad-benjamin kernel: preempt_schedule_irq+0x38/0x60
Apr 02 08:59:02 thinkpad-benjamin kernel: asm_common_interrupt+0x26/0x40
Apr 02 08:59:02 thinkpad-benjamin kernel: RIP: 0010:affine_move_task+0x198/0x580
Apr 02 08:59:02 thinkpad-benjamin kernel: Code: 00 49 8b 36 48 8d bb ec 0d 00 00 e8 22 8a d9 00 45 85 ff 44 8b 04 24 0f 84 21 02 00 00 65 ff 0d 4e 73 8b 02 0f 84 6f 03 00 00 <41> 83 e0 04 49 8d 7c 24 08 75 3e e8 18 09 d9 00 b8 ff ff ff ff f0
Apr 02 08:59:02 thinkpad-benjamin kernel: RSP: 0018:ffffcc5f4063fcd8 EFLAGS: 00000246
Apr 02 08:59:02 thinkpad-benjamin kernel: RAX: 0000000000000001 RBX: ffff8af641ab2180 RCX: 0000000000000004
Apr 02 08:59:02 thinkpad-benjamin kernel: RDX: 0000000000000000 RSI: 0000000000000283 RDI: ffff8af640c08dec
Apr 02 08:59:02 thinkpad-benjamin kernel: RBP: ffff8b04a1eb2100 R08: 0000000000000000 R09: 0000000000000283
Apr 02 08:59:02 thinkpad-benjamin kernel: R10: 0000000000000002 R11: 0000000000000000 R12: ffffcc5f4063fd28
Apr 02 08:59:02 thinkpad-benjamin kernel: R13: ffffcc5f4063fd28 R14: ffffcc5f4063fde0 R15: 0000000000000000
Apr 02 08:59:02 thinkpad-benjamin kernel: ? affine_move_task+0x50c/0x580
Apr 02 08:59:02 thinkpad-benjamin kernel: ? srso_alias_return_thunk+0x5/0xfbef5
Apr 02 08:59:02 thinkpad-benjamin kernel: ? set_next_entity+0xe7/0x270
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_migration_cpu_stop+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: ? affine_move_task+0x3c8/0x580
Apr 02 08:59:02 thinkpad-benjamin kernel: __set_cpus_allowed_ptr+0x66/0xc0
Apr 02 08:59:02 thinkpad-benjamin kernel: set_cpus_allowed_ptr+0x3a/0x60
Apr 02 08:59:02 thinkpad-benjamin kernel: worker_attach_to_pool+0x5f/0xd0
Apr 02 08:59:02 thinkpad-benjamin kernel: rescuer_thread+0x12d/0x5d0
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_rescuer_thread+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: kthread+0xe3/0x120
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_kthread+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: ret_from_fork+0x2c9/0x360
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_kthread+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: ret_from_fork_asm+0x1a/0x30
Apr 02 08:59:02 thinkpad-benjamin kernel: </TASK>
Apr 02 08:59:02 thinkpad-benjamin kernel: INFO: task khugepaged:138 blocked for more than 604 seconds.
Apr 02 08:59:02 thinkpad-benjamin kernel: Not tainted 7.0.0-rc6-70-rc6 #24
Apr 02 08:59:02 thinkpad-benjamin kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Apr 02 08:59:02 thinkpad-benjamin kernel: task:khugepaged state:D stack:0 pid:138 tgid:138 ppid:2 task_flags:0x200040 flags:0x00080000
Apr 02 08:59:02 thinkpad-benjamin kernel: Call Trace:
Apr 02 08:59:02 thinkpad-benjamin kernel: <TASK>
Apr 02 08:59:02 thinkpad-benjamin kernel: __schedule+0x47c/0x1000
Apr 02 08:59:02 thinkpad-benjamin kernel: schedule+0x27/0xd0
Apr 02 08:59:02 thinkpad-benjamin kernel: schedule_timeout+0xbd/0x100
Apr 02 08:59:02 thinkpad-benjamin kernel: wait_for_completion+0x8a/0x140
Apr 02 08:59:02 thinkpad-benjamin kernel: __flush_work+0x276/0x3b0
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_wq_barrier_func+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: __lru_add_drain_all+0x198/0x2b0
Apr 02 08:59:02 thinkpad-benjamin kernel: khugepaged+0x65/0x950
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_autoremove_wake_function+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_khugepaged+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: kthread+0xe3/0x120
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_kthread+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: ret_from_fork+0x2c9/0x360
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_kthread+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: ret_from_fork_asm+0x1a/0x30
Apr 02 08:59:02 thinkpad-benjamin kernel: </TASK>
Apr 02 08:59:02 thinkpad-benjamin kernel: INFO: task kworker/u64:16:5369 blocked for more than 120 seconds.
Apr 02 08:59:02 thinkpad-benjamin kernel: Not tainted 7.0.0-rc6-70-rc6 #24
Apr 02 08:59:02 thinkpad-benjamin kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Apr 02 08:59:02 thinkpad-benjamin kernel: task:kworker/u64:16 state:D stack:0 pid:5369 tgid:5369 ppid:2 task_flags:0x4208060 flags:0x00080000
Apr 02 08:59:02 thinkpad-benjamin kernel: Workqueue: events_unbound idle_cull_fn
Apr 02 08:59:02 thinkpad-benjamin kernel: Call Trace:
Apr 02 08:59:02 thinkpad-benjamin kernel: <TASK>
Apr 02 08:59:02 thinkpad-benjamin kernel: __schedule+0x47c/0x1000
Apr 02 08:59:02 thinkpad-benjamin kernel: schedule+0x27/0xd0
Apr 02 08:59:02 thinkpad-benjamin kernel: schedule_preempt_disabled+0x15/0x30
Apr 02 08:59:02 thinkpad-benjamin kernel: __mutex_lock.constprop.0+0x54b/0xac0
Apr 02 08:59:02 thinkpad-benjamin kernel: ? finish_task_switch.isra.0+0x96/0x2c0
Apr 02 08:59:02 thinkpad-benjamin kernel: idle_cull_fn+0x3e/0x170
Apr 02 08:59:02 thinkpad-benjamin kernel: process_one_work+0x19d/0x3a0
Apr 02 08:59:02 thinkpad-benjamin kernel: worker_thread+0x1af/0x320
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_worker_thread+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: kthread+0xe3/0x120
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_kthread+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: ret_from_fork+0x2c9/0x360
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_kthread+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: ret_from_fork_asm+0x1a/0x30
Apr 02 08:59:02 thinkpad-benjamin kernel: </TASK>
Apr 02 08:59:02 thinkpad-benjamin kernel: INFO: task kworker/u64:16:5369 is blocked on a mutex likely owned by task kworker/R-kbloc:139.
Apr 02 08:59:02 thinkpad-benjamin kernel: task:kworker/R-kbloc state:R running task stack:0 pid:139 tgid:139 ppid:2 task_flags:0x4208060 flags:0x00080000
Apr 02 08:59:02 thinkpad-benjamin kernel: Call Trace:
Apr 02 08:59:02 thinkpad-benjamin kernel: <TASK>
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __schedule+0x484/0x1000
Apr 02 08:59:02 thinkpad-benjamin kernel: ? preempt_schedule_irq+0x38/0x60
Apr 02 08:59:02 thinkpad-benjamin kernel: ? asm_common_interrupt+0x26/0x40
Apr 02 08:59:02 thinkpad-benjamin kernel: ? affine_move_task+0x198/0x580
Apr 02 08:59:02 thinkpad-benjamin kernel: ? affine_move_task+0x50c/0x580
Apr 02 08:59:02 thinkpad-benjamin kernel: ? srso_alias_return_thunk+0x5/0xfbef5
Apr 02 08:59:02 thinkpad-benjamin kernel: ? set_next_entity+0xe7/0x270
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_migration_cpu_stop+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: ? affine_move_task+0x3c8/0x580
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __set_cpus_allowed_ptr+0x66/0xc0
Apr 02 08:59:02 thinkpad-benjamin kernel: ? set_cpus_allowed_ptr+0x3a/0x60
Apr 02 08:59:02 thinkpad-benjamin kernel: ? worker_attach_to_pool+0x5f/0xd0
Apr 02 08:59:02 thinkpad-benjamin kernel: ? rescuer_thread+0x12d/0x5d0
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_rescuer_thread+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: ? kthread+0xe3/0x120
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_kthread+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: ? ret_from_fork+0x2c9/0x360
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_kthread+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: ? ret_from_fork_asm+0x1a/0x30
Apr 02 08:59:02 thinkpad-benjamin kernel: </TASK>
Apr 02 08:59:02 thinkpad-benjamin kernel: INFO: task kworker/u64:12:9088 blocked for more than 120 seconds.
Apr 02 08:59:02 thinkpad-benjamin kernel: Not tainted 7.0.0-rc6-70-rc6 #24
Apr 02 08:59:02 thinkpad-benjamin kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Apr 02 08:59:02 thinkpad-benjamin kernel: task:kworker/u64:12 state:D stack:0 pid:9088 tgid:9088 ppid:2 task_flags:0x4208060 flags:0x00080000
Apr 02 08:59:02 thinkpad-benjamin kernel: Workqueue: events_unbound idle_cull_fn
Apr 02 08:59:02 thinkpad-benjamin kernel: Call Trace:
Apr 02 08:59:02 thinkpad-benjamin kernel: <TASK>
Apr 02 08:59:02 thinkpad-benjamin kernel: __schedule+0x47c/0x1000
Apr 02 08:59:02 thinkpad-benjamin kernel: schedule+0x27/0xd0
Apr 02 08:59:02 thinkpad-benjamin kernel: schedule_preempt_disabled+0x15/0x30
Apr 02 08:59:02 thinkpad-benjamin kernel: __mutex_lock.constprop.0+0x54b/0xac0
Apr 02 08:59:02 thinkpad-benjamin kernel: idle_cull_fn+0x3e/0x170
Apr 02 08:59:02 thinkpad-benjamin kernel: process_one_work+0x19d/0x3a0
Apr 02 08:59:02 thinkpad-benjamin kernel: worker_thread+0x1af/0x320
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_worker_thread+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: kthread+0xe3/0x120
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_kthread+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: ret_from_fork+0x2c9/0x360
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_kthread+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: ret_from_fork_asm+0x1a/0x30
Apr 02 08:59:02 thinkpad-benjamin kernel: </TASK>
Apr 02 08:59:02 thinkpad-benjamin kernel: INFO: task kworker/u64:12:9088 is blocked on a mutex likely owned by task kworker/R-kbloc:139.
Apr 02 08:59:02 thinkpad-benjamin kernel: task:kworker/R-kbloc state:R running task stack:0 pid:139 tgid:139 ppid:2 task_flags:0x4208060 flags:0x00080000
Apr 02 08:59:02 thinkpad-benjamin kernel: Call Trace:
Apr 02 08:59:02 thinkpad-benjamin kernel: <TASK>
Apr 02 08:59:02 thinkpad-benjamin kernel: __schedule+0x47c/0x1000
Apr 02 08:59:02 thinkpad-benjamin kernel: preempt_schedule_irq+0x38/0x60
Apr 02 08:59:02 thinkpad-benjamin kernel: asm_common_interrupt+0x26/0x40
Apr 02 08:59:02 thinkpad-benjamin kernel: RIP: 0010:affine_move_task+0x198/0x580
Apr 02 08:59:02 thinkpad-benjamin kernel: Code: 00 49 8b 36 48 8d bb ec 0d 00 00 e8 22 8a d9 00 45 85 ff 44 8b 04 24 0f 84 21 02 00 00 65 ff 0d 4e 73 8b 02 0f 84 6f 03 00 00 <41> 83 e0 04 49 8d 7c 24 08 75 3e e8 18 09 d9 00 b8 ff ff ff ff f0
Apr 02 08:59:02 thinkpad-benjamin kernel: RSP: 0018:ffffcc5f4063fcd8 EFLAGS: 00000246
Apr 02 08:59:02 thinkpad-benjamin kernel: RAX: 0000000000000001 RBX: ffff8af641ab2180 RCX: 0000000000000004
Apr 02 08:59:02 thinkpad-benjamin kernel: RDX: 0000000000000000 RSI: 0000000000000283 RDI: ffff8af640c08dec
Apr 02 08:59:02 thinkpad-benjamin kernel: RBP: ffff8b04a1eb2100 R08: 0000000000000000 R09: 0000000000000283
Apr 02 08:59:02 thinkpad-benjamin kernel: R10: 0000000000000002 R11: 0000000000000000 R12: ffffcc5f4063fd28
Apr 02 08:59:02 thinkpad-benjamin kernel: R13: ffffcc5f4063fd28 R14: ffffcc5f4063fde0 R15: 0000000000000000
Apr 02 08:59:02 thinkpad-benjamin kernel: ? affine_move_task+0x50c/0x580
Apr 02 08:59:02 thinkpad-benjamin kernel: ? srso_alias_return_thunk+0x5/0xfbef5
Apr 02 08:59:02 thinkpad-benjamin kernel: ? set_next_entity+0xe7/0x270
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_migration_cpu_stop+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: ? affine_move_task+0x3c8/0x580
Apr 02 08:59:02 thinkpad-benjamin kernel: __set_cpus_allowed_ptr+0x66/0xc0
Apr 02 08:59:02 thinkpad-benjamin kernel: set_cpus_allowed_ptr+0x3a/0x60
Apr 02 08:59:02 thinkpad-benjamin kernel: worker_attach_to_pool+0x5f/0xd0
Apr 02 08:59:02 thinkpad-benjamin kernel: rescuer_thread+0x12d/0x5d0
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_rescuer_thread+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: kthread+0xe3/0x120
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_kthread+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: ret_from_fork+0x2c9/0x360
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_kthread+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: ret_from_fork_asm+0x1a/0x30
Apr 02 08:59:02 thinkpad-benjamin kernel: </TASK>
Apr 02 08:59:02 thinkpad-benjamin kernel: INFO: task kworker/u64:22:10249 blocked for more than 120 seconds.
Apr 02 08:59:02 thinkpad-benjamin kernel: Not tainted 7.0.0-rc6-70-rc6 #24
Apr 02 08:59:02 thinkpad-benjamin kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Apr 02 08:59:02 thinkpad-benjamin kernel: task:kworker/u64:22 state:D stack:0 pid:10249 tgid:10249 ppid:2 task_flags:0x4208060 flags:0x00080000
Apr 02 08:59:02 thinkpad-benjamin kernel: Workqueue: events_unbound idle_cull_fn
Apr 02 08:59:02 thinkpad-benjamin kernel: Call Trace:
Apr 02 08:59:02 thinkpad-benjamin kernel: <TASK>
Apr 02 08:59:02 thinkpad-benjamin kernel: __schedule+0x47c/0x1000
Apr 02 08:59:02 thinkpad-benjamin kernel: schedule+0x27/0xd0
Apr 02 08:59:02 thinkpad-benjamin kernel: schedule_preempt_disabled+0x15/0x30
Apr 02 08:59:02 thinkpad-benjamin kernel: __mutex_lock.constprop.0+0x54b/0xac0
Apr 02 08:59:02 thinkpad-benjamin kernel: ? finish_task_switch.isra.0+0x96/0x2c0
Apr 02 08:59:02 thinkpad-benjamin kernel: idle_cull_fn+0x3e/0x170
Apr 02 08:59:02 thinkpad-benjamin kernel: process_one_work+0x19d/0x3a0
Apr 02 08:59:02 thinkpad-benjamin kernel: worker_thread+0x1af/0x320
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_worker_thread+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: kthread+0xe3/0x120
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_kthread+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: ret_from_fork+0x2c9/0x360
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_kthread+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: ret_from_fork_asm+0x1a/0x30
Apr 02 08:59:02 thinkpad-benjamin kernel: </TASK>
Apr 02 08:59:02 thinkpad-benjamin kernel: INFO: task kworker/u64:22:10249 is blocked on a mutex likely owned by task kworker/R-kbloc:139.
Apr 02 08:59:02 thinkpad-benjamin kernel: task:kworker/R-kbloc state:R running task stack:0 pid:139 tgid:139 ppid:2 task_flags:0x4208060 flags:0x00080000
Apr 02 08:59:02 thinkpad-benjamin kernel: Call Trace:
Apr 02 08:59:02 thinkpad-benjamin kernel: <TASK>
Apr 02 08:59:02 thinkpad-benjamin kernel: __schedule+0x47c/0x1000
Apr 02 08:59:02 thinkpad-benjamin kernel: preempt_schedule_irq+0x38/0x60
Apr 02 08:59:02 thinkpad-benjamin kernel: asm_common_interrupt+0x26/0x40
Apr 02 08:59:02 thinkpad-benjamin kernel: RIP: 0010:affine_move_task+0x198/0x580
Apr 02 08:59:02 thinkpad-benjamin kernel: Code: 00 49 8b 36 48 8d bb ec 0d 00 00 e8 22 8a d9 00 45 85 ff 44 8b 04 24 0f 84 21 02 00 00 65 ff 0d 4e 73 8b 02 0f 84 6f 03 00 00 <41> 83 e0 04 49 8d 7c 24 08 75 3e e8 18 09 d9 00 b8 ff ff ff ff f0
Apr 02 08:59:02 thinkpad-benjamin kernel: RSP: 0018:ffffcc5f4063fcd8 EFLAGS: 00000246
Apr 02 08:59:02 thinkpad-benjamin kernel: RAX: 0000000000000001 RBX: ffff8af641ab2180 RCX: 0000000000000004
Apr 02 08:59:02 thinkpad-benjamin kernel: RDX: 0000000000000000 RSI: 0000000000000283 RDI: ffff8af640c08dec
Apr 02 08:59:02 thinkpad-benjamin kernel: RBP: ffff8b04a1eb2100 R08: 0000000000000000 R09: 0000000000000283
Apr 02 08:59:02 thinkpad-benjamin kernel: R10: 0000000000000002 R11: 0000000000000000 R12: ffffcc5f4063fd28
Apr 02 08:59:02 thinkpad-benjamin kernel: R13: ffffcc5f4063fd28 R14: ffffcc5f4063fde0 R15: 0000000000000000
Apr 02 08:59:02 thinkpad-benjamin kernel: ? affine_move_task+0x50c/0x580
Apr 02 08:59:02 thinkpad-benjamin kernel: ? srso_alias_return_thunk+0x5/0xfbef5
Apr 02 08:59:02 thinkpad-benjamin kernel: ? set_next_entity+0xe7/0x270
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_migration_cpu_stop+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: ? affine_move_task+0x3c8/0x580
Apr 02 08:59:02 thinkpad-benjamin kernel: __set_cpus_allowed_ptr+0x66/0xc0
Apr 02 08:59:02 thinkpad-benjamin kernel: set_cpus_allowed_ptr+0x3a/0x60
Apr 02 08:59:02 thinkpad-benjamin kernel: worker_attach_to_pool+0x5f/0xd0
Apr 02 08:59:02 thinkpad-benjamin kernel: rescuer_thread+0x12d/0x5d0
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_rescuer_thread+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: kthread+0xe3/0x120
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_kthread+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: ret_from_fork+0x2c9/0x360
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_kthread+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: ret_from_fork_asm+0x1a/0x30
Apr 02 08:59:02 thinkpad-benjamin kernel: </TASK>
Apr 02 08:59:02 thinkpad-benjamin kernel: INFO: task kworker/u64:31:10258 blocked for more than 120 seconds.
Apr 02 08:59:02 thinkpad-benjamin kernel: Not tainted 7.0.0-rc6-70-rc6 #24
Apr 02 08:59:02 thinkpad-benjamin kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Apr 02 08:59:02 thinkpad-benjamin kernel: task:kworker/u64:31 state:D stack:0 pid:10258 tgid:10258 ppid:2 task_flags:0x4208060 flags:0x00080000
Apr 02 08:59:02 thinkpad-benjamin kernel: Workqueue: events_unbound idle_cull_fn
Apr 02 08:59:02 thinkpad-benjamin kernel: Call Trace:
Apr 02 08:59:02 thinkpad-benjamin kernel: <TASK>
Apr 02 08:59:02 thinkpad-benjamin kernel: __schedule+0x47c/0x1000
Apr 02 08:59:02 thinkpad-benjamin kernel: schedule+0x27/0xd0
Apr 02 08:59:02 thinkpad-benjamin kernel: schedule_preempt_disabled+0x15/0x30
Apr 02 08:59:02 thinkpad-benjamin kernel: __mutex_lock.constprop.0+0x54b/0xac0
Apr 02 08:59:02 thinkpad-benjamin kernel: ? ttwu_queue_wakelist+0x13c/0x230
Apr 02 08:59:02 thinkpad-benjamin kernel: idle_cull_fn+0x3e/0x170
Apr 02 08:59:02 thinkpad-benjamin kernel: process_one_work+0x19d/0x3a0
Apr 02 08:59:02 thinkpad-benjamin kernel: worker_thread+0x1af/0x320
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_worker_thread+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: kthread+0xe3/0x120
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_kthread+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: ret_from_fork+0x2c9/0x360
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_kthread+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: ret_from_fork_asm+0x1a/0x30
Apr 02 08:59:02 thinkpad-benjamin kernel: </TASK>
Apr 02 08:59:02 thinkpad-benjamin kernel: INFO: task kworker/u64:31:10258 is blocked on a mutex likely owned by task kworker/R-kbloc:139.
Apr 02 08:59:02 thinkpad-benjamin kernel: task:kworker/R-kbloc state:R running task stack:0 pid:139 tgid:139 ppid:2 task_flags:0x4208060 flags:0x00080000
Apr 02 08:59:02 thinkpad-benjamin kernel: Call Trace:
Apr 02 08:59:02 thinkpad-benjamin kernel: <TASK>
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __schedule+0x484/0x1000
Apr 02 08:59:02 thinkpad-benjamin kernel: ? preempt_schedule_irq+0x38/0x60
Apr 02 08:59:02 thinkpad-benjamin kernel: ? asm_common_interrupt+0x26/0x40
Apr 02 08:59:02 thinkpad-benjamin kernel: ? affine_move_task+0x198/0x580
Apr 02 08:59:02 thinkpad-benjamin kernel: ? affine_move_task+0x50c/0x580
Apr 02 08:59:02 thinkpad-benjamin kernel: ? srso_alias_return_thunk+0x5/0xfbef5
Apr 02 08:59:02 thinkpad-benjamin kernel: ? set_next_entity+0xe7/0x270
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_migration_cpu_stop+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: ? affine_move_task+0x3c8/0x580
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __set_cpus_allowed_ptr+0x66/0xc0
Apr 02 08:59:02 thinkpad-benjamin kernel: ? set_cpus_allowed_ptr+0x3a/0x60
Apr 02 08:59:02 thinkpad-benjamin kernel: ? worker_attach_to_pool+0x5f/0xd0
Apr 02 08:59:02 thinkpad-benjamin kernel: ? rescuer_thread+0x12d/0x5d0
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_rescuer_thread+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: ? kthread+0xe3/0x120
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_kthread+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: ? ret_from_fork+0x2c9/0x360
Apr 02 08:59:02 thinkpad-benjamin kernel: ? __pfx_kthread+0x10/0x10
Apr 02 08:59:02 thinkpad-benjamin kernel: ? ret_from_fork_asm+0x1a/0x30
Apr 02 08:59:02 thinkpad-benjamin kernel: </TASK>
Apr 02 08:59:02 thinkpad-benjamin kernel: Future hung task reports are suppressed, see sysctl kernel.hung_task_warnings
[…]
Apr 02 09:05:10 thinkpad-benjamin kernel: rcu_tasks_wait_gp: rcu_tasks grace period number 9 (since boot) is 2583 jiffies old.
Apr 02 09:05:40 thinkpad-benjamin kernel: rcu_tasks_wait_gp: rcu_tasks grace period number 9 (since boot) is 10136 jiffies old.
[…]
Apr 02 09:07:11 thinkpad-benjamin kernel: rcu_tasks_wait_gp: rcu_tasks grace period number 9 (since boot) is 32832 jiffies old.
[…]
Apr 02 09:08:09 thinkpad-benjamin kernel: sysrq: Emergency Sync
Apr 02 09:08:09 thinkpad-benjamin kernel: Emergency Sync complete
Apr 02 09:08:09 thinkpad-benjamin kernel: sysrq: Emergency Remount R/O
^ permalink raw reply
* [PATCH 3/3] scsi: align scsi_device iodone_cnt to avoid cache line contention
From: Sumit Saxena @ 2026-04-02 7:46 UTC (permalink / raw)
To: martin.petersen, axboe
Cc: linux-scsi, linux-block, mpi3mr-linuxdrv.pdl, James Rizzo,
Sumit Saxena
In-Reply-To: <20260402074637.92417-1-sumit.saxena@broadcom.com>
From: James Rizzo <james.rizzo@broadcom.com>
Place iodone_cnt on its own cache line so it does not share a cache line
with iorequest_cnt, avoiding significant performance hits from false
sharing when request and completion paths update these counters on some
CPU architectures.
Signed-off-by: James Rizzo <james.rizzo@broadcom.com>
Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
---
include/scsi/scsi_device.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
index 9c2a7bbe5891..86c2a3a6b206 100644
--- a/include/scsi/scsi_device.h
+++ b/include/scsi/scsi_device.h
@@ -272,7 +272,9 @@ struct scsi_device {
#define SCSI_DEFAULT_DEVICE_BLOCKED 3
atomic_t iorequest_cnt;
- atomic_t iodone_cnt;
+ /* ensure iorequest_cnt and iodone_cnt are on different cache lines to avoid significant
+ performance hits on cache line contention on some CPU architectures */
+ atomic_t iodone_cnt ____cacheline_aligned_in_smp;
atomic_t ioerr_cnt;
atomic_t iotmo_cnt;
--
2.43.7
^ permalink raw reply related
* [PATCH 2/3] block: align nr_active_requests_shared_tags to avoid cache line contention
From: Sumit Saxena @ 2026-04-02 7:46 UTC (permalink / raw)
To: martin.petersen, axboe
Cc: linux-scsi, linux-block, mpi3mr-linuxdrv.pdl, James Rizzo,
Sumit Saxena
In-Reply-To: <20260402074637.92417-1-sumit.saxena@broadcom.com>
From: James Rizzo <james.rizzo@broadcom.com>
Place nr_active_requests_shared_tags on its own cache line so it does not
share a cache line with nr_requests and other hot fields, avoiding
significant performance hits from false sharing on some CPU architectures.
Signed-off-by: James Rizzo <james.rizzo@broadcom.com>
Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
---
include/linux/blkdev.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index d463b9b5a0a5..7ed566c81c1b 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -561,7 +561,9 @@ struct request_queue {
struct timer_list timeout;
struct work_struct timeout_work;
- atomic_t nr_active_requests_shared_tags;
+ /* ensure nr_active_requests_shared_tags and nr_requests are on different cache lines
+ to avoid significant performance hits on cache line contention on some CPU architectures */
+ atomic_t nr_active_requests_shared_tags ____cacheline_aligned_in_smp;
struct blk_mq_tags *sched_shared_tags;
--
2.43.7
^ permalink raw reply related
* [PATCH 1/3] scsi: use NUMA-local allocation for sdev and starget
From: Sumit Saxena @ 2026-04-02 7:46 UTC (permalink / raw)
To: martin.petersen, axboe
Cc: linux-scsi, linux-block, mpi3mr-linuxdrv.pdl, James Rizzo,
Sumit Saxena
In-Reply-To: <20260402074637.92417-1-sumit.saxena@broadcom.com>
From: James Rizzo <james.rizzo@broadcom.com>
Allocate scsi_device and scsi_target on the same NUMA node as the host
adapter's DMA device to improve memory locality and reduce cross-node
traffic.
Signed-off-by: James Rizzo <james.rizzo@broadcom.com>
Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
---
drivers/scsi/scsi_scan.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index efcaf85ff699..b98c5b7d8018 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -34,6 +34,7 @@
#include <linux/kthread.h>
#include <linux/spinlock.h>
#include <linux/async.h>
+#include <linux/topology.h>
#include <linux/slab.h>
#include <linux/unaligned.h>
@@ -286,9 +287,10 @@ static struct scsi_device *scsi_alloc_sdev(struct scsi_target *starget,
int display_failure_msg = 1, ret;
struct Scsi_Host *shost = dev_to_shost(starget->dev.parent);
struct queue_limits lim;
+ int node = dev_to_node(shost->dma_dev);
- sdev = kzalloc(sizeof(*sdev) + shost->transportt->device_size,
- GFP_KERNEL);
+ sdev = kzalloc_node(sizeof(*sdev) + shost->transportt->device_size,
+ GFP_KERNEL, node);
if (!sdev)
goto out;
@@ -504,8 +506,9 @@ static struct scsi_target *scsi_alloc_target(struct device *parent,
struct scsi_target *starget;
struct scsi_target *found_target;
int error, ref_got;
+ int node = dev_to_node(shost->dma_dev);
- starget = kzalloc(size, GFP_KERNEL);
+ starget = kzalloc_node(size, GFP_KERNEL, node);
if (!starget) {
printk(KERN_ERR "%s: allocation failure\n", __func__);
return NULL;
--
2.43.7
^ permalink raw reply related
* [PATCH 0/3] scsi/block: NUMA-local allocations and false-sharing fixes
From: Sumit Saxena @ 2026-04-02 7:46 UTC (permalink / raw)
To: martin.petersen, axboe
Cc: linux-scsi, linux-block, mpi3mr-linuxdrv.pdl, Sumit Saxena
This series contains three performance improvements targeting the SCSI
and block layers on multi-socket NUMA systems.
On multi-socket NUMA systems we observed extreme I/O throughput variance
of 50-60% between runs. This series identifies and fixes two root causes:
cross-node memory accesses due to NUMA-unaware allocations in the scan
path, and false sharing between hot atomic counters in
struct request_queue and struct scsi_device.
The first patch makes the SCSI scan path allocate scsi_device and
scsi_target on the NUMA node of the host adapter.
The second patch addresses false sharing in struct request_queue.
This patch touches include/linux/blkdev.h, so needs review from
linux-block, an Acked-by from the block maintainer is requested before
merging via the SCSI tree.
The third patch addresses a false-sharing problem in struct
scsi_device.
Performance notes:
Tested on a dual-socket NUMA system with an mpi3mr HBA, running fio
(random read, 4K, QD 64, 16 jobs, 60s, direct I/O).
IOPS figures are in KIOPS (thousands of IOPS):
Configuration Avg KIOPS Range (KIOPS) Spread
Baseline 6,255 4,200 - 6,700 ~37%
Baseline + patches 2-3 (align) 6,653 6,000 - 7,000 ~15%
Baseline + all patches (1-3) 6,649 6,400 - 7,000 ~9%
Key findings:
- Cacheline alignment patches (2-3) raise average IOPS by ~6% and
cut throughput spread from ~37% to ~15%.
- Adding the NUMA allocation patch (1) further tightens the spread
to ~9% with negligible impact on average throughput.
- The combined effect reduces the observed 50-60% run-to-run variance
to under 10%, significantly improving workload predictability.
No functional regressions observed.
This patch series is based on Martin's for-next tree.
James Rizzo (3):
scsi: use NUMA-local allocation for sdev and starget
block: align nr_active_requests_shared_tags to avoid cache line
contention
scsi: align scsi_device iodone_cnt to avoid cache line contention
drivers/scsi/scsi_scan.c | 9 ++++++---
include/linux/blkdev.h | 4 +++-
include/scsi/scsi_device.h | 4 +++-
3 files changed, 12 insertions(+), 5 deletions(-)
--
2.43.7
^ permalink raw reply
* Re: [PATCH 15/33] rust: rust_is_available: remove warning for 0.66.[01] buggy versions
From: Miguel Ojeda @ 2026-04-02 7:12 UTC (permalink / raw)
To: Gary Guo
Cc: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, moderated for non-subscribers,
Alexandre Ghiti, linux-riscv, nouveau, dri-devel, Rae Moar,
linux-kselftest, kunit-dev, Nick Desaulniers, Bill Wendling,
Justin Stitt, llvm, linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <DHHWO582XLXH.1DU3CO41F1PV7@garyguo.net>
On Wed, Apr 1, 2026 at 4:58 PM Gary Guo <gary@garyguo.net> wrote:
>
> The scripts/rust_is_available.sh change looks correct to me, although I couldn't
> get scripts/rust_is_available_test.py to run on NixOS.
>
> Looks like it filtered out PATH but uses /usr/bin/env to find python binary? For
> obvious reasons that will only work if python is located /usr/bin/python.
Yeah, the script has some assumptions on it (e.g. it also assumes
`dash` behavior vs. `bash` in a couple tests which I should relax
too). Happy to change that.
Thanks for testing it :)
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH 2/2] block: allow different-pgmap pages as separate bvecs in bio_add_page
From: Christoph Hellwig @ 2026-04-02 5:30 UTC (permalink / raw)
To: Naman Jain
Cc: Christoph Hellwig, Jens Axboe, Chaitanya Kulkarni, John Hubbard,
Logan Gunthorpe, linux-kernel, linux-block, Saurabh Sengar,
Long Li, Michael Kelley
In-Reply-To: <70c82c3a-d135-4877-ab46-c15d329815f5@linux.microsoft.com>
On Thu, Apr 02, 2026 at 10:51:05AM +0530, Naman Jain wrote:
> When a direct I/O request spans pages from different chunks (different
> pgmaps), the current code rejected the second page entirely:
>
> if (!zone_device_pages_have_same_pgmap(bv->bv_page, page))
> return 0; // Rejection - forces bio split or I/O error
>
> Both chunks are regular RAM from the DMA perspective
> (MEMORY_DEVICE_GENERIC, not P2PDMA). The only requirement is that they not
> be merged into the same bvec segment, which patch 1/2 enforces by adding
> the pgmap check to biovec_phys_mergeable().
>
> This patch allows pages from different pgmaps to be added as separate bvec
> entries in the same bio, eliminating bio splits and I/O failures
> when buffers span pgmap boundaries.
Which as I said we can't do in general, as different pgmaps cna have
different DMA mapping requirements. We might be able to relax this
if we know multiple pgmaps can be mapped in the same way. I.e.
replace zone_device_pages_have_same_pgmap with
zone_device_pages_compatible and add additional conditions to it.
> --- a/block/bio-integrity.c
> +++ b/block/bio-integrity.c
> @@ -231,6 +231,9 @@ int bio_integrity_add_page(struct bio *bio, struct page
> *page,
> if (bip->bip_vcnt > 0) {
> struct bio_vec *bv = &bip->bip_vec[bip->bip_vcnt - 1];
>
> + if (is_pci_p2pdma_page(bv->bv_page) !=
> + is_pci_p2pdma_page(page))
> + return 0;
> if (zone_device_pages_have_same_pgmap(bv->bv_page, page) &&
The above is implied by not having the same pgmap.
^ permalink raw reply
* Re: [PATCH 2/2] block: allow different-pgmap pages as separate bvecs in bio_add_page
From: Naman Jain @ 2026-04-02 5:21 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jens Axboe, Chaitanya Kulkarni, John Hubbard, Logan Gunthorpe,
linux-kernel, linux-block, Saurabh Sengar, Long Li,
Michael Kelley
In-Reply-To: <20260401140850.GC21703@lst.de>
On 4/1/2026 7:38 PM, Christoph Hellwig wrote:
> On Wed, Apr 01, 2026 at 08:23:29AM +0000, Naman Jain wrote:
>> bio_add_page() and bio_integrity_add_page() reject pages from a
>> different dev_pagemap entirely, returning 0 even when the page could
>> be added as a new bvec entry. The pgmap check was intended only to
>> prevent merging into the same bvec segment, not to block the page
>> from being added at all.
>>
>> This causes callers to unnecessarily start a new bio when a buffer
>> spans pages from two different pgmaps, even though the bio has room
>> for another bvec.
>
> This is not unnecessary. A single dma mapping operation can only
> map a single target pgmap. The old SG API works around this by
> doing multiple mapping operation underneath, but compared to that
> just having multiple bios is much easier and more efficient.
>
> What is your use case here?
Hello Christoph,
Thanks for reviewing these patches.
The use case driving this patch is the MSHV VTL driver
(drivers/hv/mshv_vtl_main.c) for VMs with paravisor architecture
(OpenHCL/OpenVMM: https://openvmm.dev/guide/index.html).
In this setup, the guest runs at two Virtual Trust Levels:
- VTL2 (higher privilege): runs a Linux kernel acting as "paravisor"
that handles device I/O on behalf of the guest
- VTL0 (lower privilege): runs the actual guest OS (Windows/Linux)
VTL2 Linux performs block I/O (NVMe, SCSI, etc.) using VTL0's memory as
DMA buffers. To enable this, VTL0 memory is registered into the VTL2
kernel via the MSHV_ADD_VTL0_MEMORY ioctl, which calls
devm_memremap_pages() to create MEMORY_DEVICE_GENERIC zone device pages.
The ioctl is called multiple times, by the Virtual Machine Manager
(VMM), registering VTL0's physical address space in chunks. Each call
creates a separate dev_pagemap. This chunking is necessary because:
1. Firmware/UEFI fragments the guest physical address space (MMIO holes,
reserved regions)
2. Alignment constraints: vmemmap_shift is computed from the range
alignment, and highly aligned large ranges can exceed MAX_FOLIO_ORDER,
causing devm_memremap_pages() to fail
When a direct I/O request spans pages from different chunks (different
pgmaps), the current code rejected the second page entirely:
if (!zone_device_pages_have_same_pgmap(bv->bv_page, page))
return 0; // Rejection - forces bio split or I/O error
Both chunks are regular RAM from the DMA perspective
(MEMORY_DEVICE_GENERIC, not P2PDMA). The only requirement is that they
not be merged into the same bvec segment, which patch 1/2 enforces by
adding the pgmap check to biovec_phys_mergeable().
This patch allows pages from different pgmaps to be added as separate
bvec entries in the same bio, eliminating bio splits and I/O failures
when buffers span pgmap boundaries.
I noticed this while doing kernel upgrade from 6.12 to 6.18 for OpenHCL
kernel.
There's this another concern flagged from Sashiko code review:
https://sashiko.dev/#/patchset/20260401082329.1602328-1-namjain%40linux.microsoft.com
From my code analysis, this issue would not happening as of now, so
this is future proofing the APIs after change 2/2. I would need to add a
check like this to fix this:
diff --git a/block/bio-integrity.c b/block/bio-integrity.c
index 3462697331890..6f2f30a814560 100644
--- a/block/bio-integrity.c
+++ b/block/bio-integrity.c
@@ -231,6 +231,9 @@ int bio_integrity_add_page(struct bio *bio, struct
page *page,
if (bip->bip_vcnt > 0) {
struct bio_vec *bv = &bip->bip_vec[bip->bip_vcnt - 1];
+ if (is_pci_p2pdma_page(bv->bv_page) !=
+ is_pci_p2pdma_page(page))
+ return 0;
if (zone_device_pages_have_same_pgmap(bv->bv_page, page) &&
bvec_try_merge_hw_page(q, bv, page, len, offset)) {
bip->bip_iter.bi_size += len;
diff --git a/block/bio.c b/block/bio.c
index 7715e59e68613..6216a554de68b 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -1034,6 +1034,9 @@ int bio_add_page(struct bio *bio, struct page *page,
if (bio->bi_vcnt > 0) {
struct bio_vec *bv = &bio->bi_io_vec[bio->bi_vcnt - 1];
+ if (is_pci_p2pdma_page(bv->bv_page) !=
+ is_pci_p2pdma_page(page))
+ return 0;
if (zone_device_pages_have_same_pgmap(bv->bv_page, page) &&
bvec_try_merge_page(bv, page, len, offset)) {
bio->bi_iter.bi_size += len;
Please let me know what you think about this.
Thanks,
Naman
^ permalink raw reply related
* [PATCH 6.1.y] block: fix resource leak in blk_register_queue() error path
From: Robert Garcia @ 2026-04-02 2:30 UTC (permalink / raw)
To: stable, Zheng Qixing
Cc: Jens Axboe, Robert Garcia, Christoph Hellwig, Yu Kuai,
linux-block, linux-kernel
From: Zheng Qixing <zhengqixing@huawei.com>
[ Upstream commit 40f2eb9b531475dd01b683fdaf61ca3cfd03a51e ]
When registering a queue fails after blk_mq_sysfs_register() is
successful but the function later encounters an error, we need
to clean up the blk_mq_sysfs resources.
Add the missing blk_mq_sysfs_unregister() call in the error path
to properly clean up these resources and prevent a memory leak.
Fixes: 320ae51feed5 ("blk-mq: new multi-queue block IO queueing mechanism")
Signed-off-by: Zheng Qixing <zhengqixing@huawei.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Yu Kuai <yukuai3@huawei.com>
Link: https://lore.kernel.org/r/20250412092554.475218-1-zhengqixing@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
[ Minor context change fixed. ]
Signed-off-by: Robert Garcia <rob_garcia@163.com>
---
block/blk-sysfs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c
index c74e8273511a..c2418e9fb45a 100644
--- a/block/blk-sysfs.c
+++ b/block/blk-sysfs.c
@@ -867,6 +867,8 @@ int blk_register_queue(struct gendisk *disk)
elv_unregister_queue(q);
disk_unregister_independent_access_ranges(disk);
mutex_unlock(&q->sysfs_lock);
+ if (queue_is_mq(q))
+ blk_mq_sysfs_unregister(disk);
mutex_unlock(&q->sysfs_dir_lock);
kobject_del(&q->kobj);
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 13/33] rust: block: update `const_refs_to_static` MSRV TODO comment
From: Gary Guo @ 2026-04-02 1:43 UTC (permalink / raw)
To: Tamir Duberstein, Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <177508434450.73816.3437422593454602087.b4-review@b4>
On Wed Apr 1, 2026 at 11:59 PM BST, Tamir Duberstein wrote:
> On Wed, 01 Apr 2026 13:45:20 +0200, Miguel Ojeda <ojeda@kernel.org> wrote:
>> diff --git a/rust/kernel/block/mq/gen_disk.rs b/rust/kernel/block/mq/gen_disk.rs
>> index c8b0ecb17082..912cb805caf5 100644
>> --- a/rust/kernel/block/mq/gen_disk.rs
>> +++ b/rust/kernel/block/mq/gen_disk.rs
>> @@ -140,9 +140,7 @@ pub fn build<T: Operations>(
>> devnode: None,
>> alternative_gpt_sector: None,
>> get_unique_id: None,
>> - // TODO: Set to THIS_MODULE. Waiting for const_refs_to_static feature to
>> - // be merged (unstable in rustc 1.78 which is staged for linux 6.10)
>> - // <https://github.com/rust-lang/rust/issues/119618>
>> + // TODO: Set to `THIS_MODULE`.
>
> Good first issue?
It's actually quite tricky. There're already attempts on the list, although I'm
not very happy with the solution.
The tricky part is that `THIS_MODULE` needs to be supplied by the leaf module,
it cannot be constructed inside the kernel crate.
Best,
Gary
>
> Reviewed-by: Tamir Duberstein <tamird@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] block: Increase BLK_DEF_MAX_SECTORS_CAP
From: Damien Le Moal @ 2026-04-01 23:31 UTC (permalink / raw)
To: Keith Busch
Cc: Mira Limbeck, axboe, hch, linux-block, martin.petersen,
Friedrich Weber
In-Reply-To: <ac2GOOLzui0U0BTJ@kbusch-mbp>
On 2026/04/02 5:55, Keith Busch wrote:
> On Thu, Apr 02, 2026 at 05:02:22AM +0900, Damien Le Moal wrote:
>> On 4/1/26 19:32, Mira Limbeck wrote:
>>>
>>> Apr 01 11:41:19 pve-test-hba kernel: sd 9:2:2:0: [sdc] tag#3962 page boundary curr_buff: 0x00000000f4d7cfce
>>> Apr 01 11:41:19 pve-test-hba kernel: BUG: unable to handle page fault for address: ff3a241243d70000
>>> Apr 01 11:41:19 pve-test-hba kernel: #PF: supervisor write access in kernel mode
>>> Apr 01 11:41:19 pve-test-hba kernel: #PF: error_code(0x0002) - not-present page
>>> Apr 01 11:41:19 pve-test-hba kernel: PGD 100010067 P4D 10066d067 PUD 10066e067 PMD 11f0fa067 PTE 0
>>> Apr 01 11:41:19 pve-test-hba kernel: Oops: Oops: 0002 [#3] SMP NOPTI
>>> Apr 01 11:41:19 pve-test-hba kernel: CPU: 15 UID: 0 PID: 6695 Comm: vgs Tainted: G D W E 7.0.0-rc6 #19 PREEMPT(full)
>>> Apr 01 11:41:19 pve-test-hba kernel: Tainted: [D]=DIE, [W]=WARN, [E]=UNSIGNED_MODULE
>>> Apr 01 11:41:19 pve-test-hba kernel: Hardware name: <snip>
>>> Apr 01 11:41:19 pve-test-hba kernel: RIP: 0010:_base_build_sg_scmd_ieee+0x478/0x590 [mpt3sas]
>>
>> There may be an issue with the mpt3sas driver with large commands.
>>
>> However, I am using that driver all day long and doing lots of testing with
>> gigantic read/write commands all the time. I have never seen any issues.
>> The difference is that I am using the SAS-SATA FW for the Broadcom HBA, so no
>> NVMe support, and my target devices are SAS or SATA HDDs, not SSDs.
>
> It's only the NVMe attached ones that use base_make_prp_nvme, and it
> looks like the ioc->pcie_sgl_dma_pool that provides the buffer for the
> entries is too small for a transfer larger than 2MB. So it's overrunning
> the allocated buffer.
Keith,
Thanks for checking. I had not look at the code yet. Given this, this should be
fairly straightforward to fix. I will have a look and send a patch.
--
Damien Le Moal
Western Digital Research
^ permalink raw reply
* Re: [PATCH 33/33] rust: kbuild: allow `clippy::precedence` for Rust < 1.86.0
From: Tamir Duberstein @ 2026-04-01 22:59 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-34-ojeda@kernel.org>
On Wed, 01 Apr 2026 13:45:40 +0200, Miguel Ojeda <ojeda@kernel.org> wrote:
> The Clippy `precedence` lint was extended in Rust 1.85.0 to include
> bitmasking and shift operations [1]. However, because it generated
> many hits, in Rust 1.86.0 it was split into a new `precedence_bits`
> lint which is not enabled by default [2].
Might be good to retain some of this in a code comment.
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
--
Tamir Duberstein <tamird@kernel.org>
^ permalink raw reply
* Re: [PATCH 32/33] rust: kbuild: support global per-version flags
From: Tamir Duberstein @ 2026-04-01 22:59 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-33-ojeda@kernel.org>
On Wed, 01 Apr 2026 13:45:39 +0200, Miguel Ojeda <ojeda@kernel.org> wrote:
> [...]
> defined after the `include/config/auto.conf` inclusion (where
> `CONFIG_RUSTC_VERSION` becomes available), and append it to
> `rust_common_flags`, `KBUILD_HOSTRUSTFLAGS` and `KBUILD_RUSTFLAGS`.
>
> An alternative is moving all those three down, but that would mean
> separating them from the other `KBUILD_*` variables.
My prefernece is avoiding duplication over grouping, but either choice
should be justified by a code comment that acknowledges the
duplication/inconsisntecy.
--
Tamir Duberstein <tamird@kernel.org>
^ permalink raw reply
* Re: [PATCH 30/33] docs: rust: general-information: use real example
From: Tamir Duberstein @ 2026-04-01 22:59 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-31-ojeda@kernel.org>
On Wed, 01 Apr 2026 13:45:37 +0200, Miguel Ojeda <ojeda@kernel.org> wrote:
> Currently the example in the documentation shows a version-based name
> for the Kconfig example:
>
> RUSTC_VERSION_MIN_107900
>
> The reason behind it was to possibly avoid repetition in case several
> features used the same minimum.
>
> [...]
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
--
Tamir Duberstein <tamird@kernel.org>
^ permalink raw reply
* Re: [PATCH 29/33] docs: rust: general-information: simplify Kconfig example
From: Tamir Duberstein @ 2026-04-01 22:59 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-30-ojeda@kernel.org>
On Wed, 01 Apr 2026 13:45:36 +0200, Miguel Ojeda <ojeda@kernel.org> wrote:
> There is no need to use `def_bool y if <expr>` -- one can simply write
> `def_bool <expr>`.
>
> In fact, the simpler form is how we actually use them in practice in
> `init/Kconfig`.
>
> Thus simplify the example.
>
> [...]
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
--
Tamir Duberstein <tamird@kernel.org>
^ permalink raw reply
* Re: [PATCH 28/33] docs: rust: quick-start: remove GDB/Binutils mention
From: Tamir Duberstein @ 2026-04-01 22:59 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-29-ojeda@kernel.org>
On Wed, 01 Apr 2026 13:45:35 +0200, Miguel Ojeda <ojeda@kernel.org> wrote:
> The versions provided nowadays by even a distribution like Debian Stable
> (and Debian Old Stable) are newer than those mentioned [1].
>
> Thus remove the workaround.
>
> Note that the minimum binutils version in the kernel is still 2.30, so
> one could argue part of the note is still relevant, but it is unlikely
> a kernel developer using such an old binutils is enabling Rust on a
> modern kernel, especially when using distribution toolchains, e.g. the
> Rust minimum version is not satisfied by Debian Old Stable.
>
> [...]
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
--
Tamir Duberstein <tamird@kernel.org>
^ permalink raw reply
* Re: [PATCH 27/33] docs: rust: quick-start: remove Nix "unstable channel" note
From: Tamir Duberstein @ 2026-04-01 22:59 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-28-ojeda@kernel.org>
On Wed, 01 Apr 2026 13:45:34 +0200, Miguel Ojeda <ojeda@kernel.org> wrote:
> Nix does not need the "unstable channel" note, since its packages are
> recent enough even in the stable channel [1][2].
>
> Thus remove it to simplify the documentation.
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
--
Tamir Duberstein <tamird@kernel.org>
^ permalink raw reply
* Re: [PATCH 26/33] docs: rust: quick-start: remove Gentoo "testing" note
From: Tamir Duberstein @ 2026-04-01 22:59 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-27-ojeda@kernel.org>
On Wed, 01 Apr 2026 13:45:33 +0200, Miguel Ojeda <ojeda@kernel.org> wrote:
> Gentoo does not need the "testing" note, since its packages are recent
> enough even in the stable branch [1][2].
>
> Thus remove it to simplify the documentation.
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
--
Tamir Duberstein <tamird@kernel.org>
^ permalink raw reply
* Re: [PATCH 25/33] docs: rust: quick-start: add Ubuntu 26.04 LTS and remove subsection title
From: Tamir Duberstein @ 2026-04-01 22:59 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-26-ojeda@kernel.org>
On Wed, 01 Apr 2026 13:45:32 +0200, Miguel Ojeda <ojeda@kernel.org> wrote:
> Ubuntu 26.04 LTS (Resolute Raccoon) is scheduled to be released in a few
> weeks [1], and it has a recent enough Rust toolchain, just like Ubuntu
> 25.10 has [2][3].
>
> We could update the title and the paragraph, but to simplify and to
> make it more consistent with the other distributions' sections, let's
> instead just remove that title. It will also reduce the differences
> later on to keep it updated. Eventually, when we remove the remaining
> subsection for older LTSs, Ubuntu should be a small section like the
> other distributions.
>
> [...]
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
--
Tamir Duberstein <tamird@kernel.org>
^ 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