* Re: [PATCH 08/33] rust: kbuild: simplify `--remap-path-prefix` workaround
From: Miguel Ojeda @ 2026-04-01 17:36 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: <DHHVEPJHLGDW.1E6KDP9BUFG5U@garyguo.net>
On Wed, Apr 1, 2026 at 3:59 PM Gary Guo <gary@garyguo.net> wrote:
>
> I'm not sure that I parse this. You do remove the filter-out completely below?
(I see you saw the other commit)
> Looks like this is going to conflict with rust-fixes (which adds the
> --remap-path-scope). Perhaps worth doing a back merge?
It would be only a couple lines conflicting, so it should be fine.
Having said that, when I was doing this, I wondered if we should even
consider keeping the workaround. In other words, locally for
`rust-next`, the "normal" commit would be to remove the workaround
entirely because there the flag doesn't exist to begin with (i.e. the
workaround should have been removed back when the revert landed).
Then, when conflict happens in linux-next, we can just keep the
addition of the flag from your commit -- the rest can say as-is, i.e.
no workaround needed, because you only enable both flags in a version
(1.95.0) where there is no need for the workaround (which was for <
1.87.0).
It is also why I added the second commit here, i.e. the "make it
conditional", because I was testing that indeed we didn't need the
workaround anymore.
So it may just simpler to do that. What I thought was that perhaps the
workaround is good even if we ourselves don't pass the flag, e.g.
someone else may be passing it. But the chances are very low,
restricted to a couple versions, and the error is obvious and at build
time anyway.
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v9 10/13] blk-mq: use hk cpus only when isolcpus=io_queue is enabled
From: Aaron Tomlin @ 2026-04-01 17:16 UTC (permalink / raw)
To: Keith Busch
Cc: axboe, hch, sagi, mst, aacraid, James.Bottomley, martin.petersen,
liyihang9, kashyap.desai, sumit.saxena,
shivasharan.srikanteshwara, chandrakanth.patil, sathya.prakash,
sreekanth.reddy, suganath-prabu.subramani, ranjan.kumar,
jinpu.wang, tglx, mingo, peterz, juri.lelli, vincent.guittot,
akpm, maz, ruanjinjie, bigeasy, yphbchou0911, wagi, frederic,
longman, chenridong, hare, kch, 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: <acxTI2CJlq3npMVa@kbusch-mbp>
[-- Attachment #1: Type: text/plain, Size: 3208 bytes --]
On Tue, Mar 31, 2026 at 05:05:07PM -0600, Keith Busch wrote:
> > +static bool blk_mq_validate(struct blk_mq_queue_map *qmap,
> > + const struct cpumask *active_hctx)
> > +{
> > + /*
> > + * Verify if the mapping is usable when housekeeping
> > + * configuration is enabled
> > + */
> > +
> > + for (int queue = 0; queue < qmap->nr_queues; queue++) {
> > + int cpu;
Hi Keith,
Thank you for taking the time to review and test.
> > +
> > + if (cpumask_test_cpu(queue, active_hctx)) {
> > + /*
> > + * This htcx has at least one online CPU thus it
>
> Typo, should say "hctx".
Acknowledged.
> > + * is able to serve any assigned isolated CPU.
> > + */
> > + continue;
> > + }
> > +
> > + /*
> > + * There is no housekeeping online CPU for this hctx, all
> > + * good as long as all non houskeeping CPUs are also
>
> Typo, "housekeeping".
Acknowledged.
> ...
>
> > void blk_mq_map_queues(struct blk_mq_queue_map *qmap)
> > {
> > - const struct cpumask *masks;
> > + struct cpumask *masks __free(kfree) = NULL;
> > + const struct cpumask *constraint;
> > unsigned int queue, cpu, nr_masks;
> > + cpumask_var_t active_hctx;
> >
> > - masks = group_cpus_evenly(qmap->nr_queues, &nr_masks);
> > - if (!masks) {
> > - for_each_possible_cpu(cpu)
> > - qmap->mq_map[cpu] = qmap->queue_offset;
> > - return;
> > - }
> > + if (!zalloc_cpumask_var(&active_hctx, GFP_KERNEL))
> > + goto fallback;
> > +
> > + if (housekeeping_enabled(HK_TYPE_IO_QUEUE))
> > + constraint = housekeeping_cpumask(HK_TYPE_IO_QUEUE);
> > + else
> > + constraint = cpu_possible_mask;
> > +
> > + /* Map CPUs to the hardware contexts (hctx) */
> > + masks = group_mask_cpus_evenly(qmap->nr_queues, constraint, &nr_masks);
> > + if (!masks)
> > + goto free_fallback;
> >
> > for (queue = 0; queue < qmap->nr_queues; queue++) {
> > - for_each_cpu(cpu, &masks[queue % nr_masks])
> > - qmap->mq_map[cpu] = qmap->queue_offset + queue;
> > + unsigned int idx = (qmap->queue_offset + queue) % nr_masks;
> > +
> > + for_each_cpu(cpu, &masks[idx]) {
> > + qmap->mq_map[cpu] = idx;
>
> I think there's something off with this when we have multiple queue maps. The
> wrapping loses the offset when we've isolated CPUs, so I think the index would
> end up incorrect.
>
> Trying this series out when "nvme.poll_queues=2" with isolcpus set, I am
> getting a kernel panic:
To resolve this comprehensively, I have made the following adjustments:
1. qmap->mq_map now strictly stores the absolute hardware index
(qmap->queue_offset + queue) across both the primary assignment
loop and the unassigned CPU fallback loop.
2. The active_hctx cpumask now strictly tracks the relative index
(queue) for the current map being processed, preventing
out-of-bounds mask tracking.
3. The validation check within blk_mq_validate() has been updated to
correctly compare the absolute index stored in mq_map against the
offset-adjusted queue index.
I shall fold these corrections directly into the next series.
Best regards,
--
Aaron Tomlin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 08/26] block/blk-mq-debugfs: Improve lock context annotations
From: Bart Van Assche @ 2026-04-01 17:04 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jens Axboe, linux-block, Damien Le Moal, Tejun Heo,
Nathan Chancellor
In-Reply-To: <20260326063225.GI24071@lst.de>
On 3/25/26 11:32 PM, Christoph Hellwig wrote:
> Looks fine, althought I'd still love to find a way to avoid all these
> open coded dereferences of the private data pointers using casts.
A possible solution is to introduce new single-line functions that
perform these conversions. Please let me know if you agree with making
this change.
Thanks,
Bart.
^ permalink raw reply
* Re: [PATCH v2 07/26] block/blk-iocost: Add lock context annotations
From: Bart Van Assche @ 2026-04-01 17:01 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jens Axboe, linux-block, Damien Le Moal, Tejun Heo, Josef Bacik
In-Reply-To: <20260326063128.GH24071@lst.de>
On 3/25/26 11:31 PM, Christoph Hellwig wrote:
> and ioc_rqos_throttle does basically totally
> different things based on the same paramter passed as the lock_ioc
> argument to iocg_lock/iocg_unlock.
Hi Christoph,
I looked into splitting ioc_rqos_throttle() into two functions: the
existing code without the code protected by iocg_lock() / iocg_unlock()
and a new function with all the code protected by iocg_lock() and
iocg_unlock(). That new function can tell ioc_rqos_throttle() how to
proceed via its return value. However, the number of parameters of
that new function is large. Almost all local variables declared in
ioc_rqos_throttle() would have to be passed to that new function. Hence,
I prefer not to modify ioc_rqos_throttle().
Thanks,
Bart.
^ permalink raw reply
* Re: [PATCH 3/4] block: add a bio_submit_or_kill helper
From: Bart Van Assche @ 2026-04-01 15:42 UTC (permalink / raw)
To: Christoph Hellwig, Jens Axboe; +Cc: Carlos Maiolino, linux-block, linux-xfs
In-Reply-To: <20260401140433.125924-4-hch@lst.de>
On 4/1/26 7:03 AM, Christoph Hellwig wrote:
> Factor the common logic for the ioctl helpers to either submit a bio or
> end if the process is being killed. As this is now the only user of
> bio_await_chain, open code that.
There are two changes in this patch:
- Inlining of bio_await_chain().
- Introduction of bio_submit_or_kill().
Please consider splitting this patch into two patches such that it
becomes easier to review these changes.
Thanks,
Bart.
^ permalink raw reply
* Re: [PATCH 02/33] rust: bump Clippy's MSRV and clean `incompatible_msrv` allows
From: Danilo Krummrich @ 2026-04-01 15:39 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, 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, 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: <20260401114540.30108-3-ojeda@kernel.org>
On 4/1/26 1:45 PM, Miguel Ojeda wrote:
> drivers/gpu/nova-core/gsp/cmdq.rs | 6 +-----
Acked-by: Danilo Krummrich <dakr@kernel.org>
^ permalink raw reply
* Re: [PATCH 05/33] rust: remove `RUSTC_HAS_COERCE_POINTEE` and simplify code
From: Danilo Krummrich @ 2026-04-01 15:38 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, 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, 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: <20260401114540.30108-6-ojeda@kernel.org>
On 4/1/26 1:45 PM, Miguel Ojeda wrote:
> rust/kernel/alloc/kbox.rs | 29 ++---------------------------
Acked-by: Danilo Krummrich <dakr@kernel.org>
^ permalink raw reply
* Re: [PATCH V2] ublk: use unchecked copy helpers for bio page data
From: Ming Lei @ 2026-04-01 15:36 UTC (permalink / raw)
To: Jens Axboe; +Cc: linux-block, Caleb Sander Mateos
In-Reply-To: <f10b5a3d-33f9-486c-b8e9-6d9286448f69@kernel.dk>
On Wed, Apr 01, 2026 at 09:19:23AM -0600, Jens Axboe wrote:
> On 3/31/26 7:24 PM, Ming Lei wrote:
> > Bio pages may originate from slab caches that lack a usercopy region
> > (e.g. jbd2 frozen metadata buffers allocated via jbd2_alloc()).
> > When CONFIG_HARDENED_USERCOPY is enabled, copy_to_iter() calls
> > check_copy_size() which rejects these slab pages, triggering a
> > kernel BUG in usercopy_abort().
> >
> > This is a false positive: the data is ordinary block I/O content ?
> > the same data the loop/nbd driver writes to its backing file via
> > vfs_iter_write(). The bvec length is always trusted, so the size
> > check in check_copy_size() is not needed either.
> >
> > Switch to _copy_to_iter()/_copy_from_iter() which skip the
> > check_copy_size() wrapper while the underlying copy_to_user()
> > remains unchanged.
> >
> > Fixes: 2299ceec364e ("ublk: use copy_{to,from}_iter() for user copy")
> > Signed-off-by: Ming Lei <ming.lei@redhat.com>
> > ---
> > V2:
> > - update commit log (Caleb Sander Mateos)
> >
> > drivers/block/ublk_drv.c | 12 ++++++++++--
> > 1 file changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c
> > index 2e475bdc54dd..3e329906ae19 100644
> > --- a/drivers/block/ublk_drv.c
> > +++ b/drivers/block/ublk_drv.c
> > @@ -1322,10 +1322,18 @@ static bool ublk_copy_user_bvec(const struct bio_vec *bv, unsigned *offset,
> >
> > len = bv->bv_len - *offset;
> > bv_buf = kmap_local_page(bv->bv_page) + bv->bv_offset + *offset;
> > + /*
> > + * Bio pages may originate from slab caches without a usercopy region
> > + * (e.g. jbd2 frozen metadata buffers). This is the same data that
> > + * the loop driver writes to its backing file ? no exposure risk.
> > + * The bvec length is always trusted, so the size check in
> > + * check_copy_size() is not needed either. Use the unchecked
> > + * helpers to avoid false positives on slab pages.
> > + */
> > if (dir == ITER_DEST)
> > - copied = copy_to_iter(bv_buf, len, uiter);
> > + copied = _copy_to_iter(bv_buf, len, uiter);
> > else
> > - copied = copy_from_iter(bv_buf, len, uiter);
> > + copied = _copy_from_iter(bv_buf, len, uiter);
> >
> > kunmap_local(bv_buf);
>
> Is this just a jbd2 issue? Because we can just get the slab marked
> appropriately to not trigger these warnings.
If the ublk block device is permitted to mount FS, it is inevitable to expose
the meta to ublk userspace daemon, same with loop, or other block device.
Any bio pages backed by slab without a usercopy need to bypass the size check,
which isn't necessary too.
thanks,
Ming
^ permalink raw reply
* Re: [PATCH 2/4] block: factor out a bio_await helper
From: Bart Van Assche @ 2026-04-01 15:35 UTC (permalink / raw)
To: Christoph Hellwig, Jens Axboe; +Cc: Carlos Maiolino, linux-block, linux-xfs
In-Reply-To: <20260401140433.125924-3-hch@lst.de>
On 4/1/26 7:03 AM, Christoph Hellwig wrote:
> +/**
> + * bio_await - call a function on a bio, and wait until it completes
> + * @bio: the bio which describes the I/O
> + * @kick: function called to "kick off" the bio
> + * @priv: private data passed to @kick.
> + *
> + * Wait for the bio as well as any bio chained off it after executing the
> + * passed in callback @kick. The wait for the bio is set up before calling
> + * @kick to ensure that the completion is captured. If @kick is %NULL,
> + * submit_bio() is used instead to submit the bio.
> + *
> + * Note: this overrides the bi_private and bi_end_io fields in the bio.
> + */
> +void bio_await(struct bio *bio, void *priv,
> + void (*kick)(struct bio *bio, void *priv))
Please consider swapping the @priv and @kick arguments because that's
the argument order used elsewhere in the Linux kernel for callback
function pointers and their private data pointer.
> int submit_bio_wait(struct bio *bio)
> {
> - DECLARE_COMPLETION_ONSTACK_MAP(done,
> - bio->bi_bdev->bd_disk->lockdep_map);
> -
> - bio->bi_private = &done;
> - bio->bi_end_io = bio_wait_end_io;
> - bio->bi_opf |= REQ_SYNC;
> - submit_bio(bio);
> - blk_wait_io(&done);
> -
> + bio_await(bio, NULL, NULL);
> return blk_status_to_errno(bio->bi_status);
> }
> EXPORT_SYMBOL(submit_bio_wait);
What happened to the bio->bi_opf |= REQ_SYNC statement? Shouldn't that
statement be preserved?
Otherwise this patch looks good to me.
Thanks,
Bart.
^ permalink raw reply
* Re: [PATCH 1/4] block: unify the synchronous bi_end_io callbacks
From: Bart Van Assche @ 2026-04-01 15:30 UTC (permalink / raw)
To: Christoph Hellwig, Jens Axboe; +Cc: Carlos Maiolino, linux-block, linux-xfs
In-Reply-To: <20260401140433.125924-2-hch@lst.de>
On 4/1/26 7:03 AM, Christoph Hellwig wrote:
> Put the bio in bio_await_chain after waiting for the completion, and
> share the now identical callbacks between submit_bio_wait and
> bio_await_chain.
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
^ permalink raw reply
* Re: [PATCH 33/33] rust: kbuild: allow `clippy::precedence` for Rust < 1.86.0
From: Gary Guo @ 2026-04-01 15:28 UTC (permalink / raw)
To: 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
Cc: 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,
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: <20260401114540.30108-34-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda 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].
>
> In other words, only Rust 1.85 has a different behavior. For instance,
> it reports:
>
> warning: operator precedence can trip the unwary
> --> drivers/gpu/nova-core/fb/hal/ga100.rs:16:5
> |
> 16 | / u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR::read(bar).adr_39_08()) << FLUSH_SYSMEM_ADDR_SHIFT
> 17 | | | u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR_HI::read(bar).adr_63_40())
> 18 | | << FLUSH_SYSMEM_ADDR_SHIFT_HI
> | |_________________________________________^
> |
> = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#precedence
> = note: `-W clippy::precedence` implied by `-W clippy::all`
> = help: to override `-W clippy::all` add `#[allow(clippy::precedence)]`
> help: consider parenthesizing your expression
> |
> 16 ~ (u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR::read(bar).adr_39_08()) << FLUSH_SYSMEM_ADDR_SHIFT) | (u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR_HI::read(bar).adr_63_40())
> 17 + << FLUSH_SYSMEM_ADDR_SHIFT_HI)
> |
>
> warning: operator precedence can trip the unwary
> --> drivers/gpu/nova-core/vbios.rs:511:17
> |
> 511 | / u32::from(data[29]) << 24
> 512 | | | u32::from(data[28]) << 16
> 513 | | | u32::from(data[27]) << 8
> | |______________________________________________^
> |
> = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#precedence
> help: consider parenthesizing your expression
> |
> 511 ~ u32::from(data[29]) << 24
> 512 + | u32::from(data[28]) << 16 | (u32::from(data[27]) << 8)
> |
>
> warning: operator precedence can trip the unwary
> --> drivers/gpu/nova-core/vbios.rs:511:17
> |
> 511 | / u32::from(data[29]) << 24
> 512 | | | u32::from(data[28]) << 16
> | |_______________________________________________^ help: consider parenthesizing your expression: `(u32::from(data[29]) << 24) | (u32::from(data[28]) << 16)`
> |
> = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#precedence
>
> While so far we try our best to keep all versions Clippy-clean, the
> minimum (which is now Rust 1.85.0 after the bump) and the latest stable
> are the most important ones; and this may be considered "false positives"
> with respect to the behavior in other versions.
>
> Thus allow this lint for this version using the per-version flags
> mechanism introduced in the previous commit.
>
> Link: https://github.com/rust-lang/rust-clippy/issues/14097 [1]
> Link: https://github.com/rust-lang/rust-clippy/pull/14115 [2]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Link: https://lore.kernel.org/rust-for-linux/DFVDKMMA7KPC.2DN0951H3H55Y@kernel.org/
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> Makefile | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
^ permalink raw reply
* Re: [PATCH 32/33] rust: kbuild: support global per-version flags
From: Gary Guo @ 2026-04-01 15:26 UTC (permalink / raw)
To: 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
Cc: 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,
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: <20260401114540.30108-33-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda wrote:
> Sometimes it is useful to gate global Rust flags per compiler version.
> For instance, we may want to disable a lint that has false positives in
> a single version [1].
>
> We already had helpers like `rustc-min-version` for that, which we use
> elsewhere, but we cannot currently use them for `rust_common_flags`,
> which contains the global flags for all Rust code (kernel and host),
> because `rustc-min-version` depends on `CONFIG_RUSTC_VERSION`, which
> does not exist when `rust_common_flags` is defined.
>
> Thus, to support that, introduce `rust_common_flags_per_version`,
> 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.
I think I would prefer moving these down.
The current approach append the flags to all variables, which will cause the
following equivalence to stop holding after the flag update.
KBUILD_HOSTRUSTFLAGS := $(rust_common_flags) -O -Cstrip=debuginfo \
-Zallow-features= $(HOSTRUSTFLAGS)
(Per version flags doesn't go before -O anymore, it comes after HOSTRUSTFLAGS).
Best,
Gary
>
> Link: https://lore.kernel.org/rust-for-linux/CANiq72mWdFU11GcCZRchzhy0Gi1QZShvZtyRkHV2O+WA2uTdVQ@mail.gmail.com/ [1]
> Link: https://patch.msgid.link/20260307170929.153892-1-ojeda@kernel.org
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
> ---
> Makefile | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index 1a219bf1c771..20c8179d96ee 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -834,6 +834,14 @@ endif # CONFIG_TRACEPOINTS
>
> export WARN_ON_UNUSED_TRACEPOINTS
>
> +# Per-version Rust flags. These are like `rust_common_flags`, but may
> +# depend on the Rust compiler version (e.g. using `rustc-min-version`).
> +rust_common_flags_per_version :=
> +
> +rust_common_flags += $(rust_common_flags_per_version)
> +KBUILD_HOSTRUSTFLAGS += $(rust_common_flags_per_version)
> +KBUILD_RUSTFLAGS += $(rust_common_flags_per_version)
> +
> include $(srctree)/arch/$(SRCARCH)/Makefile
>
> ifdef need-config
^ permalink raw reply
* Re: [PATCH 31/33] rust: declare cfi_encoding for lru_status
From: Gary Guo @ 2026-04-01 15:20 UTC (permalink / raw)
To: 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
Cc: 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,
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: <20260401114540.30108-32-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda wrote:
> From: Alice Ryhl <aliceryhl@google.com>
>
> By default bindgen will convert 'enum lru_status' into a typedef for an
> integer. For the most part, an integer of the same size as the enum
> results in the correct ABI, but in the specific case of CFI, that is not
> the case. The CFI encoding is supposed to be the same as a struct called
> 'lru_status' rather than the name of the underlying native integer type.
>
> To fix this, tell bindgen to generate a newtype and set the CFI type
> explicitly. Note that we need to set the CFI attribute explicitly as
> bindgen is using repr(transparent), which is otherwise identical to the
> inner type for ABI purposes.
>
> This allows us to remove the page range helper C function in Binder
> without risking a CFI failure when list_lru_walk calls the provided
> function pointer.
>
> The --with-attribute-custom-enum argument requires bindgen v0.71 or
> greater.
>
> [ In particular, the feature was added in 0.71.0 [1][2].
>
> In addition, `feature(cfi_encoding)` has been available since
> Rust 1.71.0 [3].
>
> Link: https://github.com/rust-lang/rust-bindgen/issues/2520 [1]
> Link: https://github.com/rust-lang/rust-bindgen/pull/2866 [2]
> Link: https://github.com/rust-lang/rust/pull/105452 [3]
>
> - Miguel ]
>
> My testing procedure was to add this to the android17-6.18 branch and
> verify that rust_shrink_free_page is successfully called without crash,
> and verify that it does in fact crash when the cfi_encoding is set to
> other values. Note that I couldn't test this on android16-6.12 as that
> branch uses a bindgen version that is too old.
>
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> Link: https://patch.msgid.link/20260223-cfi-lru-status-v2-1-89c6448a63a4@google.com
> [ Rebased on top of the minimum Rust version bump series which provide
> the required `bindgen` version. - Miguel ]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> drivers/android/binder/Makefile | 3 +--
> drivers/android/binder/page_range.rs | 6 +++---
> drivers/android/binder/page_range_helper.c | 24 ----------------------
> drivers/android/binder/page_range_helper.h | 15 --------------
> rust/bindgen_parameters | 4 ++++
> rust/bindings/bindings_helper.h | 1 -
> rust/bindings/lib.rs | 1 +
> rust/uapi/lib.rs | 1 +
> 8 files changed, 10 insertions(+), 45 deletions(-)
> delete mode 100644 drivers/android/binder/page_range_helper.c
> delete mode 100644 drivers/android/binder/page_range_helper.h
^ permalink raw reply
* Re: [PATCH V2] ublk: use unchecked copy helpers for bio page data
From: Jens Axboe @ 2026-04-01 15:19 UTC (permalink / raw)
To: Ming Lei, linux-block; +Cc: Caleb Sander Mateos
In-Reply-To: <20260401012401.3653194-1-ming.lei@redhat.com>
On 3/31/26 7:24 PM, Ming Lei wrote:
> Bio pages may originate from slab caches that lack a usercopy region
> (e.g. jbd2 frozen metadata buffers allocated via jbd2_alloc()).
> When CONFIG_HARDENED_USERCOPY is enabled, copy_to_iter() calls
> check_copy_size() which rejects these slab pages, triggering a
> kernel BUG in usercopy_abort().
>
> This is a false positive: the data is ordinary block I/O content ?
> the same data the loop/nbd driver writes to its backing file via
> vfs_iter_write(). The bvec length is always trusted, so the size
> check in check_copy_size() is not needed either.
>
> Switch to _copy_to_iter()/_copy_from_iter() which skip the
> check_copy_size() wrapper while the underlying copy_to_user()
> remains unchanged.
>
> Fixes: 2299ceec364e ("ublk: use copy_{to,from}_iter() for user copy")
> Signed-off-by: Ming Lei <ming.lei@redhat.com>
> ---
> V2:
> - update commit log (Caleb Sander Mateos)
>
> drivers/block/ublk_drv.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c
> index 2e475bdc54dd..3e329906ae19 100644
> --- a/drivers/block/ublk_drv.c
> +++ b/drivers/block/ublk_drv.c
> @@ -1322,10 +1322,18 @@ static bool ublk_copy_user_bvec(const struct bio_vec *bv, unsigned *offset,
>
> len = bv->bv_len - *offset;
> bv_buf = kmap_local_page(bv->bv_page) + bv->bv_offset + *offset;
> + /*
> + * Bio pages may originate from slab caches without a usercopy region
> + * (e.g. jbd2 frozen metadata buffers). This is the same data that
> + * the loop driver writes to its backing file ? no exposure risk.
> + * The bvec length is always trusted, so the size check in
> + * check_copy_size() is not needed either. Use the unchecked
> + * helpers to avoid false positives on slab pages.
> + */
> if (dir == ITER_DEST)
> - copied = copy_to_iter(bv_buf, len, uiter);
> + copied = _copy_to_iter(bv_buf, len, uiter);
> else
> - copied = copy_from_iter(bv_buf, len, uiter);
> + copied = _copy_from_iter(bv_buf, len, uiter);
>
> kunmap_local(bv_buf);
Is this just a jbd2 issue? Because we can just get the slab marked
appropriately to not trigger these warnings.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH 30/33] docs: rust: general-information: use real example
From: Gary Guo @ 2026-04-01 15:16 UTC (permalink / raw)
To: 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
Cc: 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,
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: <20260401114540.30108-31-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda 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.
>
> However, we ended up preferring to give them a descriptive name for each
> feature added even if that could lead to some repetition. In practice,
> the repetition has not happened so far, and even if it does at some point,
> it is not a big deal.
>
> Thus replace the example in the documentation with one of our current
> examples (after removing previous ones from the bump), to show how they
> actually look like, and in case someone `grep`s for it.
>
> In addition, it has the advantage that it shows the `RUSTC_HAS_*`
> pattern we follow in `init/Kconfig`, similar to the C side.
>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> Documentation/rust/general-information.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: [PATCH 29/33] docs: rust: general-information: simplify Kconfig example
From: Gary Guo @ 2026-04-01 15:16 UTC (permalink / raw)
To: 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
Cc: 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,
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: <20260401114540.30108-30-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda 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.
>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> Documentation/rust/general-information.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
^ permalink raw reply
* Re: [PATCH V2] ublk: use unchecked copy helpers for bio page data
From: Caleb Sander Mateos @ 2026-04-01 15:15 UTC (permalink / raw)
To: Ming Lei; +Cc: Jens Axboe, linux-block
In-Reply-To: <20260401012401.3653194-1-ming.lei@redhat.com>
On Tue, Mar 31, 2026 at 6:24 PM Ming Lei <ming.lei@redhat.com> wrote:
>
> Bio pages may originate from slab caches that lack a usercopy region
> (e.g. jbd2 frozen metadata buffers allocated via jbd2_alloc()).
> When CONFIG_HARDENED_USERCOPY is enabled, copy_to_iter() calls
> check_copy_size() which rejects these slab pages, triggering a
> kernel BUG in usercopy_abort().
>
> This is a false positive: the data is ordinary block I/O content —
> the same data the loop/nbd driver writes to its backing file via
> vfs_iter_write(). The bvec length is always trusted, so the size
> check in check_copy_size() is not needed either.
>
> Switch to _copy_to_iter()/_copy_from_iter() which skip the
> check_copy_size() wrapper while the underlying copy_to_user()
> remains unchanged.
>
> Fixes: 2299ceec364e ("ublk: use copy_{to,from}_iter() for user copy")
> Signed-off-by: Ming Lei <ming.lei@redhat.com>
Acked-by: Caleb Sander Mateos <csander@purestorage.com>
> ---
> V2:
> - update commit log (Caleb Sander Mateos)
>
> drivers/block/ublk_drv.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c
> index 2e475bdc54dd..3e329906ae19 100644
> --- a/drivers/block/ublk_drv.c
> +++ b/drivers/block/ublk_drv.c
> @@ -1322,10 +1322,18 @@ static bool ublk_copy_user_bvec(const struct bio_vec *bv, unsigned *offset,
>
> len = bv->bv_len - *offset;
> bv_buf = kmap_local_page(bv->bv_page) + bv->bv_offset + *offset;
> + /*
> + * Bio pages may originate from slab caches without a usercopy region
> + * (e.g. jbd2 frozen metadata buffers). This is the same data that
> + * the loop driver writes to its backing file — no exposure risk.
> + * The bvec length is always trusted, so the size check in
> + * check_copy_size() is not needed either. Use the unchecked
> + * helpers to avoid false positives on slab pages.
> + */
> if (dir == ITER_DEST)
> - copied = copy_to_iter(bv_buf, len, uiter);
> + copied = _copy_to_iter(bv_buf, len, uiter);
> else
> - copied = copy_from_iter(bv_buf, len, uiter);
> + copied = _copy_from_iter(bv_buf, len, uiter);
>
> kunmap_local(bv_buf);
>
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH 28/33] docs: rust: quick-start: remove GDB/Binutils mention
From: Gary Guo @ 2026-04-01 15:15 UTC (permalink / raw)
To: 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
Cc: 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,
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: <20260401114540.30108-29-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda 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.
I suppose people could have been using an old LTS distro + rustup and run into
this issue. Albeit it's probably quite unlikely.
Reviewed-by: Gary Guo <gary@garyguo.net>
>
> So we are at the point where keeping the docs short and relevant for
> essentially everyone is probably the better trade-off.
>
> Link: https://packages.debian.org/search?suite=all&searchon=names&keywords=binutils [1]
> Link: https://lore.kernel.org/all/CANiq72mCpc9=2TN_zC4NeDMpFQtPXAFvyiP+gRApg2vzspPWmw@mail.gmail.com/
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
> ---
> Documentation/rust/quick-start.rst | 9 ---------
> 1 file changed, 9 deletions(-)
>
> diff --git a/Documentation/rust/quick-start.rst b/Documentation/rust/quick-start.rst
> index 5bbe059a8fa3..a6ec3fa94d33 100644
> --- a/Documentation/rust/quick-start.rst
> +++ b/Documentation/rust/quick-start.rst
> @@ -352,12 +352,3 @@ Hacking
> To dive deeper, take a look at the source code of the samples
> at ``samples/rust/``, the Rust support code under ``rust/`` and
> the ``Rust hacking`` menu under ``Kernel hacking``.
> -
> -If GDB/Binutils is used and Rust symbols are not getting demangled, the reason
> -is the toolchain does not support Rust's new v0 mangling scheme yet.
> -There are a few ways out:
> -
> -- Install a newer release (GDB >= 10.2, Binutils >= 2.36).
> -
> -- Some versions of GDB (e.g. vanilla GDB 10.1) are able to use
> - the pre-demangled names embedded in the debug info (``CONFIG_DEBUG_INFO``).
^ permalink raw reply
* Re: [PATCH 27/33] docs: rust: quick-start: remove Nix "unstable channel" note
From: Gary Guo @ 2026-04-01 15:10 UTC (permalink / raw)
To: 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
Cc: 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,
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: <20260401114540.30108-28-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda 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.
>
> Link: https://search.nixos.org/packages?channel=25.11&query=rust [1]
> Link: https://search.nixos.org/packages?channel=25.11&query=bindgen [2]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> Documentation/rust/quick-start.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: [PATCH 21/33] gpu: nova-core: bindings: remove unneeded `cfg_attr`
From: Gary Guo @ 2026-04-01 15:08 UTC (permalink / raw)
To: 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
Cc: 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,
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: <20260401114540.30108-22-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda wrote:
> These were likely copied from the `bindings` and `uapi` crates, but are
> unneeded since there are no `cfg(test)`s in the bindings.
>
> In addition, the issue that triggered the addition in those crates
> originally is also fixed in `bindgen` (please see the previous commit).
>
> Thus remove them.
>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> drivers/gpu/nova-core/gsp/fw/r570_144.rs | 3 ---
I believe drivers/gpu/nova-core/gsp/fw/r570_144/bindings.rs is generated
manually and checked in to the source tree? It might be useful to actually have
the command line and bindgen version used to generate the file present
somewhere for knowing about possible compatibility issues like this one and
reproducibility..
Best,
Gary
> 1 file changed, 3 deletions(-)
^ permalink raw reply
* Re: [PATCH 20/33] rust: kbuild: remove unneeded old `allow`s for generated layout tests
From: Gary Guo @ 2026-04-01 15:05 UTC (permalink / raw)
To: 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
Cc: 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,
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: <20260401114540.30108-21-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda wrote:
> The issue that required `allow`s for `cfg(test)` code generated by
> `bindgen` for layout testing was fixed back in `bindgen` 0.60.0 [1],
> so it could have been removed even before the version bump, but it does
> not hurt.
>
> Thus remove it now.
>
> Link: https://github.com/rust-lang/rust-bindgen/pull/2203 [1]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> rust/bindings/lib.rs | 4 ----
> rust/uapi/lib.rs | 4 ----
> 2 files changed, 8 deletions(-)
^ permalink raw reply
* Re: [PATCH 19/33] rust: kbuild: remove "`try` keyword" workaround for `bindgen` < 0.59.2
From: Gary Guo @ 2026-04-01 15:05 UTC (permalink / raw)
To: 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
Cc: 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,
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: <20260401114540.30108-20-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda wrote:
> There is a workaround that has not been needed, even already after commit
> 08ab786556ff ("rust: bindgen: upgrade to 0.65.1"), but it does not hurt.
>
> Thus remove it.
>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> rust/bindgen_parameters | 4 ----
> 1 file changed, 4 deletions(-)
^ permalink raw reply
* Re: [PATCH 18/33] rust: kbuild: remove "dummy parameter" workaround for `bindgen` < 0.71.1
From: Gary Guo @ 2026-04-01 15:05 UTC (permalink / raw)
To: 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
Cc: 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,
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: <20260401114540.30108-19-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda wrote:
> Until the version bump of `bindgen`, we needed to pass a dummy parameter
> to avoid failing the `--version` call.
>
> Thus remove it.
>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> init/Kconfig | 7 +------
> scripts/rust_is_available.sh | 8 +-------
> 2 files changed, 2 insertions(+), 13 deletions(-)
^ permalink raw reply
* Re: [PATCH 17/33] rust: kbuild: update `bindgen --rust-target` version and replace comment
From: Gary Guo @ 2026-04-01 15:05 UTC (permalink / raw)
To: 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
Cc: 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,
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: <20260401114540.30108-18-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda wrote:
> As the comment in the `Makefile` explains, previously, we needed to
> limit ourselves to the list of Rust versions known by `bindgen` for its
> `--rust-target` option.
>
> In other words, we needed to consult the versions known by the minimum
> version of `bindgen` that we supported.
>
> Now that we bumped the minimum version of `bindgen`, that limitation
> does not apply anymore.
>
> Thus replace the comment and simply write our minimum supported Rust
> version there, which is much simpler.
>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> rust/Makefile | 16 ++--------------
> 1 file changed, 2 insertions(+), 14 deletions(-)
^ permalink raw reply
* Re: [PATCH 15/33] rust: rust_is_available: remove warning for 0.66.[01] buggy versions
From: Gary Guo @ 2026-04-01 14:58 UTC (permalink / raw)
To: 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
Cc: 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,
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: <20260401114540.30108-16-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda wrote:
> It is not possible anymore to fall into the issue that this warning was
> alerting about given the `bindgen` version bump.
>
> Thus simplify by removing the machinery behind it, including tests.
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.
Best,
Gary
>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
> ---
> scripts/rust_is_available.sh | 13 ------------
> scripts/rust_is_available_bindgen_0_66.h | 2 --
> scripts/rust_is_available_test.py | 26 +++---------------------
> 3 files changed, 3 insertions(+), 38 deletions(-)
> delete mode 100644 scripts/rust_is_available_bindgen_0_66.h
>
> diff --git a/scripts/rust_is_available.sh b/scripts/rust_is_available.sh
> index d2323de0692c..77896e31dab5 100755
> --- a/scripts/rust_is_available.sh
> +++ b/scripts/rust_is_available.sh
> @@ -163,19 +163,6 @@ if [ "$rust_bindings_generator_cversion" -lt "$rust_bindings_generator_min_cvers
> echo >&2 "***"
> exit 1
> fi
> -if [ "$rust_bindings_generator_cversion" -eq 6600 ] ||
> - [ "$rust_bindings_generator_cversion" -eq 6601 ]; then
> - # Distributions may have patched the issue (e.g. Debian did).
> - if ! "$BINDGEN" $(dirname $0)/rust_is_available_bindgen_0_66.h >/dev/null; then
> - echo >&2 "***"
> - echo >&2 "*** Rust bindings generator '$BINDGEN' versions 0.66.0 and 0.66.1 may not"
> - echo >&2 "*** work due to a bug (https://github.com/rust-lang/rust-bindgen/pull/2567),"
> - echo >&2 "*** unless patched (like Debian's)."
> - echo >&2 "*** Your version: $rust_bindings_generator_version"
> - echo >&2 "***"
> - warning=1
> - fi
> -fi
>
> # Check that the `libclang` used by the Rust bindings generator is suitable.
> #
> diff --git a/scripts/rust_is_available_bindgen_0_66.h b/scripts/rust_is_available_bindgen_0_66.h
> deleted file mode 100644
> index c0431293421c..000000000000
> --- a/scripts/rust_is_available_bindgen_0_66.h
> +++ /dev/null
> @@ -1,2 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0 */
> -#define A "\0"
> diff --git a/scripts/rust_is_available_test.py b/scripts/rust_is_available_test.py
> index 4fcc319dea84..b66fa5933844 100755
> --- a/scripts/rust_is_available_test.py
> +++ b/scripts/rust_is_available_test.py
> @@ -54,17 +54,12 @@ else:
> """)
>
> @classmethod
> - def generate_bindgen(cls, version_stdout, libclang_stderr, version_0_66_patched=False, libclang_concat_patched=False):
> + def generate_bindgen(cls, version_stdout, libclang_stderr, libclang_concat_patched=False):
> if libclang_stderr is None:
> libclang_case = f"raise SystemExit({cls.bindgen_default_bindgen_libclang_failure_exit_code})"
> else:
> libclang_case = f"print({repr(libclang_stderr)}, file=sys.stderr)"
>
> - if version_0_66_patched:
> - version_0_66_case = "pass"
> - else:
> - version_0_66_case = "raise SystemExit(1)"
> -
> if libclang_concat_patched:
> libclang_concat_case = "print('pub static mut foofoo: ::std::os::raw::c_int;')"
> else:
> @@ -74,8 +69,6 @@ else:
> import sys
> if "rust_is_available_bindgen_libclang.h" in " ".join(sys.argv):
> {libclang_case}
> -elif "rust_is_available_bindgen_0_66.h" in " ".join(sys.argv):
> - {version_0_66_case}
> elif "rust_is_available_bindgen_libclang_concat.h" in " ".join(sys.argv):
> {libclang_concat_case}
> else:
> @@ -83,8 +76,8 @@ else:
> """)
>
> @classmethod
> - def generate_bindgen_version(cls, stdout, version_0_66_patched=False):
> - return cls.generate_bindgen(stdout, cls.bindgen_default_bindgen_libclang_stderr, version_0_66_patched)
> + def generate_bindgen_version(cls, stdout):
> + return cls.generate_bindgen(stdout, cls.bindgen_default_bindgen_libclang_stderr)
>
> @classmethod
> def generate_bindgen_libclang_failure(cls):
> @@ -245,19 +238,6 @@ else:
> result = self.run_script(self.Expected.FAILURE, { "BINDGEN": bindgen })
> self.assertIn(f"Rust bindings generator '{bindgen}' is too old.", result.stderr)
>
> - def test_bindgen_bad_version_0_66_0_and_0_66_1(self):
> - for version in ("0.66.0", "0.66.1"):
> - with self.subTest(version=version):
> - bindgen = self.generate_bindgen_version(f"bindgen {version}")
> - result = self.run_script(self.Expected.SUCCESS_WITH_WARNINGS, { "BINDGEN": bindgen })
> - self.assertIn(f"Rust bindings generator '{bindgen}' versions 0.66.0 and 0.66.1 may not", result.stderr)
> -
> - def test_bindgen_bad_version_0_66_0_and_0_66_1_patched(self):
> - for version in ("0.66.0", "0.66.1"):
> - with self.subTest(version=version):
> - bindgen = self.generate_bindgen_version(f"bindgen {version}", True)
> - result = self.run_script(self.Expected.SUCCESS, { "BINDGEN": bindgen })
> -
> def test_bindgen_libclang_failure(self):
> bindgen = self.generate_bindgen_libclang_failure()
> result = self.run_script(self.Expected.FAILURE, { "BINDGEN": bindgen })
^ 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