* 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 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 RFC v4 07/44] KVM: guest_memfd: Only prepare folios for private pages
From: Michael Roth @ 2026-04-01 15:16 UTC (permalink / raw)
To: Ackerley Tng
Cc: aik, andrew.jones, binbin.wu, brauner, chao.p.peng, david,
ira.weiny, jmattson, jroedel, jthoughton, oupton, pankaj.gupta,
qperret, rick.p.edgecombe, rientjes, shivankg, steven.price,
tabba, willy, wyihan, yan.y.zhao, forkloop, pratyush,
suzuki.poulose, aneesh.kumar, Paolo Bonzini, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Jonathan Corbet, Shuah Khan, Shuah Khan,
Vishal Annapurve, Andrew Morton, Chris Li, Kairui Song,
Kemeng Shi, Nhat Pham, Baoquan He, Barry Song, Axel Rasmussen,
Yuanchu Xie, Wei Xu, Jason Gunthorpe, Vlastimil Babka, kvm,
linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest,
linux-mm
In-Reply-To: <CAEvNRgF+FjJ1EWSR_rzD1=N040ZitiRrM2O3N0Kj5yN5rT3h+Q@mail.gmail.com>
On Wed, Apr 01, 2026 at 07:05:16AM -0700, Ackerley Tng wrote:
> Ackerley Tng <ackerleytng@google.com> writes:
>
> > All-shared guest_memfd used to be only supported for non-CoCo VMs where
> > preparation doesn't apply. INIT_SHARED is about to be supported for
> > non-CoCo VMs in a later patch in this series.
> >
> > In addition, KVM_SET_MEMORY_ATTRIBUTES2 is about to be supported in
> > guest_memfd in a later patch in this series.
> >
> > This means that the kvm fault handler may now call kvm_gmem_get_pfn() on a
> > shared folio for a CoCo VM where preparation applies.
> >
> > Add a check to make sure that preparation is only performed for private
> > folios.
> >
> > Preparation will be undone on freeing (see kvm_gmem_free_folio()) and on
> > conversion to shared.
> >
> > Signed-off-by: Ackerley Tng <ackerleytng@google.com>
> > ---
> > virt/kvm/guest_memfd.c | 9 ++++++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
> > index b6ffa8734175d..d414ebfcb4c19 100644
> > --- a/virt/kvm/guest_memfd.c
> > +++ b/virt/kvm/guest_memfd.c
> > @@ -900,6 +900,7 @@ int kvm_gmem_get_pfn(struct kvm *kvm, struct kvm_memory_slot *slot,
> > int *max_order)
> > {
> > pgoff_t index = kvm_gmem_get_index(slot, gfn);
> > + struct inode *inode;
> > struct folio *folio;
> > int r = 0;
> >
> > @@ -907,7 +908,8 @@ int kvm_gmem_get_pfn(struct kvm *kvm, struct kvm_memory_slot *slot,
> > if (!file)
> > return -EFAULT;
> >
> > - filemap_invalidate_lock_shared(file_inode(file)->i_mapping);
> > + inode = file_inode(file);
> > + filemap_invalidate_lock_shared(inode->i_mapping);
> >
> > folio = __kvm_gmem_get_pfn(file, slot, index, pfn, max_order);
> > if (IS_ERR(folio)) {
> > @@ -920,7 +922,8 @@ int kvm_gmem_get_pfn(struct kvm *kvm, struct kvm_memory_slot *slot,
> > folio_mark_uptodate(folio);
> > }
> >
> > - r = kvm_gmem_prepare_folio(kvm, slot, gfn, folio);
> > + if (kvm_gmem_is_private_mem(inode, index))
> > + r = kvm_gmem_prepare_folio(kvm, slot, gfn, folio);
>
> Michael, I might have misunderstood you at the last guest_memfd call:
> sev_gmem_prepare() doesn't prepare a page for being a shared page,
> right? Does this work? That prepare is only called to "make private"?
Hmm, I guess your guest_memfd-inplace-conversion-v4 branch is out of sync with
these patches?
I have the below local patch based on top of that for SNP-specific enablement,
which is basically identically, so suffice to say: yes, this should work
for SNP :) If any architecture pops up that needs to do some prep in
advance of mapping shared pages, then we could potentially plumb the
shared/private flag through to the arch-specific prep hook, as was also
suggested on the call, but it doesn't seem like that's needed by any
users for now.
-Mike
Author: Michael Roth <michael.roth@amd.com>
Date: Mon Oct 27 07:58:32 2025 -0500
KVM: guest_memfd: Don't prepare shared folios
In the current guest_memfd logic, "preparation" is only used currently
to describe the additional work of putting a guest_memfd page into an
architecturally-defined "private" state, such as updating RMP table
entries for SEV-SNP guests. As such, there's no input to the
corresponding kvm_arch_gmem_prepare() hooks as to whether a page is
being prepared/accessed as shared or as private, so "preparation" will
end up being erroneously done on pages that were supposed to remain in a
shared state. Rather than plumb through the additional information
needed to distinguish between shared vs. private preparation, just
continue to only do preparation on private pages, as was the case prior
to support for GUEST_MEMFD_FLAG_MMAP being introduced.
Signed-off-by: Michael Roth <michael.roth@amd.com>
diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
index 3acc6d983449..4869e59e4fc5 100644
--- a/virt/kvm/guest_memfd.c
+++ b/virt/kvm/guest_memfd.c
@@ -1249,7 +1249,8 @@ int kvm_gmem_get_pfn(struct kvm *kvm, struct kvm_memory_slot *slot,
folio_mark_uptodate(folio);
}
- r = kvm_gmem_prepare_folio(kvm, slot, gfn, folio);
+ if (!kvm_gmem_is_shared_mem(file_inode(file), index))
+ r = kvm_gmem_prepare_folio(kvm, slot, gfn, folio);
folio_unlock(folio);
>
> >
> > folio_unlock(folio);
> >
> > @@ -930,7 +933,7 @@ int kvm_gmem_get_pfn(struct kvm *kvm, struct kvm_memory_slot *slot,
> > folio_put(folio);
> >
> > out:
> > - filemap_invalidate_unlock_shared(file_inode(file)->i_mapping);
> > + filemap_invalidate_unlock_shared(inode->i_mapping);
> > return r;
> > }
> > EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_gmem_get_pfn);
> >
> > --
> > 2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply
* Re: [PATCH V10 00/10] famfs: port into fuse
From: John Groves @ 2026-04-01 15:15 UTC (permalink / raw)
To: John Groves
Cc: Miklos Szeredi, Dan Williams, Bernd Schubert, Alison Schofield,
John Groves, Jonathan Corbet, Shuah Khan, Vishal Verma,
Dave Jiang, Matthew Wilcox, Jan Kara, Alexander Viro,
David Hildenbrand, Christian Brauner, Darrick J . Wong,
Randy Dunlap, Jeff Layton, Amir Goldstein, Jonathan Cameron,
Stefan Hajnoczi, Joanne Koong, Josef Bacik, Bagas Sanjaya,
Chen Linxuan, James Morse, Fuad Tabba, Sean Christopherson,
Shivank Garg, Ackerley Tng, Gregory Price, Aravind Ramesh,
Ajay Joshi, venkataravis@micron.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, nvdimm@lists.linux.dev,
linux-cxl@vger.kernel.org, linux-fsdevel@vger.kernel.org
In-Reply-To: <0100019d43e5f632-f5862a3e-361c-4b54-a9a6-96c242a8f17a-000000@email.amazonses.com>
On 26/03/31 12:37PM, John Groves wrote:
> From: John Groves <john@groves.net>
>
> NOTE: this series depends on the famfs dax series in Ira's for-7.1/dax-famfs
> branch [0]
>
> Changes v9 -> v10
> - Rebased to Ira's for-7.1/dax-famfs branch [0], which contains the required
> dax patches
> - Add parentheses to FUSE_IS_VIRTIO_DAX() macro, in case something bad is
> passed in as fuse_inode (thanks Jonathan's AI)
>
> Description:
>
> This patch series introduces famfs into the fuse file system framework.
> Famfs depends on the bundled dax patch set.
>
> The famfs user space code can be found at [1].
>
> Fuse Overview:
>
> Famfs started as a standalone file system, but this series is intended to
> permanently supersede that implementation. At a high level, famfs adds
> two new fuse server messages:
>
> GET_FMAP - Retrieves a famfs fmap (the file-to-dax map for a famfs
> file)
> GET_DAXDEV - Retrieves the details of a particular daxdev that was
> referenced by an fmap
>
> Famfs Overview
>
> Famfs exposes shared memory as a file system. Famfs consumes shared
> memory from dax devices, and provides memory-mappable files that map
> directly to the memory - no page cache involvement. Famfs differs from
> conventional file systems in fs-dax mode, in that it handles in-memory
> metadata in a sharable way (which begins with never caching dirty shared
> metadata).
>
> Famfs started as a standalone file system [2,3], but the consensus at
> LSFMM was that it should be ported into fuse [4,5].
>
> The key performance requirement is that famfs must resolve mapping faults
> without upcalls. This is achieved by fully caching the file-to-devdax
> metadata for all active files. This is done via two fuse client/server
> message/response pairs: GET_FMAP and GET_DAXDEV.
>
> Famfs remains the first fs-dax file system that is backed by devdax
> rather than pmem in fs-dax mode (hence the need for the new dax mode).
>
> Notes
>
> - When a file is opened in a famfs mount, the OPEN is followed by a
> GET_FMAP message and response. The "fmap" is the full file-to-dax
> mapping, allowing the fuse/famfs kernel code to handle
> read/write/fault without any upcalls.
>
> - After each GET_FMAP, the fmap is checked for extents that reference
> previously-unknown daxdevs. Each such occurrence is handled with a
> GET_DAXDEV message and response.
>
> - Daxdevs are stored in a table (which might become an xarray at some
> point). When entries are added to the table, we acquire exclusive
> access to the daxdev via the fs_dax_get() call (modeled after how
> fs-dax handles this with pmem devices). Famfs provides
> holder_operations to devdax, providing a notification path in the
> event of memory errors or forced reconfiguration.
>
> - If devdax notifies famfs of memory errors on a dax device, famfs
> currently blocks all subsequent accesses to data on that device. The
> recovery is to re-initialize the memory and file system. Famfs is
> memory, not storage...
>
> - Because famfs uses backing (devdax) devices, only privileged mounts are
> supported (i.e. the fuse server requires CAP_SYS_RAWIO).
>
> - The famfs kernel code never accesses the memory directly - it only
> facilitates read, write and mmap on behalf of user processes, using
> fmap metadata provided by its privileged fuse server. As such, the
> RAS of the shared memory affects applications, but not the kernel.
>
> - Famfs has backing device(s), but they are devdax (char) rather than
> block. Right now there is no way to tell the vfs layer that famfs has a
> char backing device (unless we say it's block, but it's not). Currently
> we use the standard anonymous fuse fs_type - but I'm not sure that's
> ultimately optimal (thoughts?)
>
> Changes v8 -> v9
> - Kconfig: fs/fuse/Kconfig:CONFIG_FUSE_FAMFS_DAX now depends on the
> new CONFIG_DEV_DAX_FSDEV (from drivers/dax/Kconfig) rather than
> just CONFIG_DEV_DAX and CONFIG_FS_DAX. (CONFIG_FUSE_FAMFS_DAX
> depends on those...)
>
> Changes v7 -> v8
> - Moved to inline __free declaration in fuse_get_fmap() and
> famfs_fuse_meta_alloc(), famfs_teardown()
> - Adopted FIELD_PREP() macro rather than manual bitfield manipulation
> - Minor doc edits
> - I dropped adding magic numbers to include/uapi/linux/magic.h. That
> can be done later if appropriate
>
> Changes v6 -> v7
> - Fixed a regression in famfs_interleave_fileofs_to_daxofs() that
> was reported by Intel's kernel test robot
> - Added a check in __fsdev_dax_direct_access() for negative return
> from pgoff_to_phys(), which would indicate an out-of-range offset
> - Fixed a bug in __famfs_meta_free(), where not all interleaved
> extents were freed
> - Added chunksize alignment checks in famfs_fuse_meta_alloc() and
> famfs_interleave_fileofs_to_daxofs() as interleaved chunks must
> be PTE or PMD aligned
> - Simplified famfs_file_init_dax() a bit
> - Re-ran CM's kernel code review prompts on the entire series and
> fixed several minor issues
>
> Changes v4 -> v5 -> v6
> - None. Re-sending due to technical difficulties
>
> Changes v3 [9] -> v4
> - The patch "dax: prevent driver unbind while filesystem holds device"
> has been dropped. Dan Williams indicated that the favored behavior is
> for a file system to stop working if an underlying driver is unbound,
> rather than preventing the unbind.
> - The patch "famfs_fuse: Famfs mount opt: -o shadow=<shadowpath>" has
> been dropped. Found a way for the famfs user space to do without the
> -o opt (via getxattr).
> - Squashed the fs/fuse/Kconfig patch into the first subsequent patch
> that needed the change
> ("famfs_fuse: Basic fuse kernel ABI enablement for famfs")
> - Many review comments addressed.
> - Addressed minor kerneldoc infractions reported by test robot.
>
> Changes v2 [7] -> v3
> - Dax: Completely new fsdev driver (drivers/dax/fsdev.c) replaces the
> dev_dax_iomap modifications to bus.c/device.c. Devdax devices can now
> be switched among 'devdax', 'famfs' and 'system-ram' modes via daxctl
> or sysfs.
> - Dax: fsdev uses MEMORY_DEVICE_FS_DAX type and leaves folios at order-0
> (no vmemmap_shift), allowing fs-dax to manage folio lifecycles
> dynamically like pmem does.
> - Dax: The "poisoned page" problem is properly fixed via
> fsdev_clear_folio_state(), which clears stale mapping/compound state
> when fsdev binds. The temporary WARN_ON_ONCE workaround in fs/dax.c
> has been removed.
> - Dax: Added dax_set_ops() so fsdev can set dax_operations at bind time
> (and clear them on unbind), since the dax_device is created before we
> know which driver will bind.
> - Dax: Added custom bind/unbind sysfs handlers; unbind return -EBUSY if a
> filesystem holds the device, preventing unbind while famfs is mounted.
> - Fuse: Famfs mounts now require that the fuse server/daemon has
> CAP_SYS_RAWIO because they expose raw memory devices.
> - Fuse: Added DAX address_space_operations with noop_dirty_folio since
> famfs is memory-backed with no writeback required.
> - Rebased to latest kernels, fully compatible with Alistair Popple
> et. al's recent dax refactoring.
> - Ran this series through Chris Mason's code review AI prompts to check
> for issues - several subtle problems found and fixed.
> - Dropped RFC status - this version is intended to be mergeable.
>
> Changes v1 [8] -> v2:
>
> - The GET_FMAP message/response has been moved from LOOKUP to OPEN, as
> was the pretty much unanimous consensus.
> - Made the response payload to GET_FMAP variable sized (patch 12)
> - Dodgy kerneldoc comments cleaned up or removed.
> - Fixed memory leak of fc->shadow in patch 11 (thanks Joanne)
> - Dropped many pr_debug and pr_notice calls
>
>
> References
>
> [0] - https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git/
> [1] - https://famfs.org (famfs user space)
> [2] - https://lore.kernel.org/linux-cxl/cover.1708709155.git.john@groves.net/
> [3] - https://lore.kernel.org/linux-cxl/cover.1714409084.git.john@groves.net/
> [4] - https://lwn.net/Articles/983105/ (lsfmm 2024)
> [5] - https://lwn.net/Articles/1020170/ (lsfmm 2025)
> [6] - https://lore.kernel.org/linux-cxl/cover.8068ad144a7eea4a813670301f4d2a86a8e68ec4.1740713401.git-series.apopple@nvidia.com/
> [7] - https://lore.kernel.org/linux-fsdevel/20250703185032.46568-1-john@groves.net/ (famfs fuse v2)
> [8] - https://lore.kernel.org/linux-fsdevel/20250421013346.32530-1-john@groves.net/ (famfs fuse v1)
> [9] - https://lore.kernel.org/linux-fsdevel/20260107153244.64703-1-john@groves.net/T/#mb2c868801be16eca82dab239a1d201628534aea7 (famfs fuse v3)
>
>
> John Groves (10):
> famfs_fuse: Update macro s/FUSE_IS_DAX/FUSE_IS_VIRTIO_DAX/
> famfs_fuse: Basic fuse kernel ABI enablement for famfs
> famfs_fuse: Plumb the GET_FMAP message/response
> famfs_fuse: Create files with famfs fmaps
> famfs_fuse: GET_DAXDEV message and daxdev_table
> famfs_fuse: Plumb dax iomap and fuse read/write/mmap
> famfs_fuse: Add holder_operations for dax notify_failure()
> famfs_fuse: Add DAX address_space_operations with noop_dirty_folio
> famfs_fuse: Add famfs fmap metadata documentation
> famfs_fuse: Add documentation
>
> Documentation/filesystems/famfs.rst | 142 ++++
> Documentation/filesystems/index.rst | 1 +
> MAINTAINERS | 10 +
> fs/fuse/Kconfig | 13 +
> fs/fuse/Makefile | 1 +
> fs/fuse/dir.c | 2 +-
> fs/fuse/famfs.c | 1180 +++++++++++++++++++++++++++
> fs/fuse/famfs_kfmap.h | 167 ++++
> fs/fuse/file.c | 45 +-
> fs/fuse/fuse_i.h | 116 ++-
> fs/fuse/inode.c | 35 +-
> fs/fuse/iomode.c | 2 +-
> fs/namei.c | 1 +
> include/uapi/linux/fuse.h | 88 ++
> 14 files changed, 1790 insertions(+), 13 deletions(-)
> create mode 100644 Documentation/filesystems/famfs.rst
> create mode 100644 fs/fuse/famfs.c
> create mode 100644 fs/fuse/famfs_kfmap.h
>
>
> base-commit: 2ae624d5a555d47a735fb3f4d850402859a4db77
> --
> 2.53.0
>
>
Miklos,
I would appreciate a read on what you're thinking WRT merging famfs. The
dax patches are ready; this series should be applied on top of Ira's
for-7.1/dax-famfs branch, which is at [1].
I saw that you had the famfs series in your for-next branch briefly a
couple of weeks ago, but it didn't build because it depends on the dax
series. It will build and run cleanly if you put it on Ira's branch above.
Famfs has been in use for a long time, though availability of sharable cxl
memory is still limited; that is changing with early availability (now) of
sharable JBOMs up to 100TB.
The presence of famfs won't affect anybody who doesn't use it though...
What are your thoughts?
Thanks,
John
[1] - https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git/
^ 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 v2] bootconfig: Apply early options from embedded config
From: Breno Leitao @ 2026-04-01 15:01 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Jonathan Corbet, Shuah Khan, linux-kernel, linux-trace-kernel,
linux-doc, oss, paulmck, rostedt, kernel-team
In-Reply-To: <20260401224853.d8ed517a344c4be51d371a9c@kernel.org>
On Wed, Apr 01, 2026 at 10:48:53PM +0900, Masami Hiramatsu wrote:
> > The challenge extends beyond that. There are numerous early_parameter()
> > definitions scattered throughout the kernel that may or may not be
> > utilized by setup_arch().
> >
> > For example, consider `early_param("mitigations", ..)` in
> > ./kernel/cpu.c. This modifies the cpu_mitigations global variable, which
> > is referenced in various locations across different architectures.
> >
> > It's worth noting that we have over 300 early_parameter() instances in
> > the kernel.
> >
> > Given this, analyzing all these early parameters and examining each one
> > individually represents a substantial amount of work.
>
> Yes, that may require a substantial amount of work. But to improve
> the kernel framework around the parameter handling, eventually we
> need to examine each early parameter.
I'm still uncertain about this approach. The goal is to identify and
categorize the early parameters that are parsed prior to bootconfig
initialization.
Moreover, this work could become obsolete if bootconfig's initialization
point shifts earlier or later in the boot sequence, necessitating
another comprehensive analysis.
Conversely, if we successfully move bootconfig initialization earlier
by breaking the dependency of memblock (assuming this is feasible), the
vast majority of early parameters would execute after bootconfig is
configured, eliminating the need for this extensive categorization work.
Please, feel free to tell what approach might be better for the project.
> > Are there alternative approaches? At this point, I'm leaning toward
> > breaking bootconfig's dependency on memblock, allowing us to invoke it
> > before setup_arch(). Is this the only practical solution available?!
>
> Basically, the memblock dependency comes from allocating copy of data.
> Only for the embedded bootconfig, we can just pass copy memory block
> to the xbc_init(). Something like;
>
> xbc_init() {
> xbc_data = memblock_alloc();
> memcpy(xbc_data, data);
> __xbc_init(xbc_data);
> }
>
> embedded_xbc_init() {
> __xbc_init(embedded_bootconfig_data);
> }
>
> Afterwards, we can pass mixture of embedded bootcofnigt and initrd
> bootconfig data to parser again.
>
> (But in this case, we must be careful not to override the early
> parameters that we have already applied.)
Do you have any additional recommendations if I proceed with this
approach?
Thank you for your detailed responses and insights.
--breno
^ 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
* Re: [PATCH 01/33] rust: bump Rust minimum supported version to 1.85.0 (Debian Trixie)
From: Benno Lossin @ 2026-04-01 14:57 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, 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-2-ojeda@kernel.org>
On Wed Apr 1, 2026 at 1:45 PM CEST, Miguel Ojeda wrote:
> As proposed in the past in e.g. LPC 2025 and the Maintainers Summit [1],
> we are going to follow Debian Stable's Rust versions as our minimum
> supported version.
>
> Debian Trixie was released with a Rust 1.85.0 toolchain [2], which it
> still uses to this day [3] (i.e. no update to Rust 1.85.1).
>
> Debian Trixie's release happened on 2025-08-09 [4], which means that a
> fair amount of time has passed since its release for kernel developers
> to upgrade.
>
> Thus bump the minimum to the new version.
>
> Then, in later commits, clean up most of the workarounds and other bits
> that this upgrade of the minimum allows us.
>
> pin-init was left as-is since the patches come from upstream. And the
> vendored crates are unmodified, since we do not want to change those.
>
> Note that the minimum LLVM major version for Rust 1.85.0 is LLVM 18 (the
> Rust upstream binaries use LLVM 19.1.7), thus e.g. `RUSTC_LLVM_VERSION`
> tests can also be updated, but there are no suitable ones to simplify.
>
> Ubuntu 25.10 also has a recent enough Rust toolchain [5], and they also
> provide versioned packages with a Rust 1.85.1 toolchain even back to
> Ubuntu 22.04 LTS [6].
>
> Link: https://lwn.net/Articles/1050174/ [1]
> Link: https://www.debian.org/releases/trixie/release-notes/whats-new.en.html#desktops-and-well-known-packages [2]
> Link: https://packages.debian.org/trixie/rustc [3]
> Link: https://www.debian.org/releases/trixie/ [4]
> Link: https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=rustc [5]
> Link: https://launchpad.net/ubuntu/+source/rustc-1.85 [6]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Very happy to see this!
Acked-by: Benno Lossin <lossin@kernel.org>
Cheers,
Benno
> ---
> Documentation/process/changes.rst | 2 +-
> scripts/min-tool-version.sh | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCH v5] PCI: s390: Expose the UID as an arch specific PCI slot attribute
From: Niklas Schnelle @ 2026-04-01 14:50 UTC (permalink / raw)
To: Bjorn Helgaas, Jonathan Corbet, Lukas Wunner, Shuah Khan
Cc: Alexander Gordeev, Christian Borntraeger, Gerald Schaefer,
Gerd Bayer, Heiko Carstens, Julian Ruess, Matthew Rosato,
Peter Oberparleiter, Ramesh Errabolu, Sven Schnelle,
Vasily Gorbik, linux-doc, linux-kernel, linux-pci, linux-s390,
Niklas Schnelle
On s390, an individual PCI function can generally be identified by two
identifiers, the FID and the UID. Which identifier is used depends on
the scope and the platform configuration.
The first identifier, the FID, is always available and identifies a PCI
device uniquely within a machine. The FID may be virtualized by
hypervisors, but on the LPAR level, the machine scope makes it
impossible to create the same configuration based on FIDs on two
different LPARs of the same machine, and difficult to reuse across
machines.
Such matching LPAR configurations are useful, though, allowing
standardized setups and booting a Linux installation on different LPARs.
To this end the UID, or user-defined identifier, was introduced. While
it is only guaranteed to be unique within an LPAR and only if indicated
by firmware, it allows users to replicate PCI device setups.
On s390, which uses a machine hypervisor, a per PCI function hotplug
model is used. The shortcoming with the UID then is, that it is not
visible to the user without first attaching the PCI function and
accessing the "uid" device attribute. The FID, on the other hand, is
used as the slot name and is thus known even with the PCI function in
standby.
Remedy this shortcoming by providing the UID as an attribute on the slot
allowing the user to identify a PCI function based on the UID without
having to first attach it. Do this via a macro mechanism analogous to
what was introduced by commit 265baca69a07 ("s390/pci: Stop usurping
pdev->dev.groups") for the PCI device attributes.
Reviewed-by: Gerd Bayer <gbayer@linux.ibm.com>
Reviewed-by: Julian Ruess <julianr@linux.ibm.com>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
---
Note: I considered adding the UID as a generic slot index attribute
analogous to the PCI device index attribute (SMBIOS index / s390 UID)
but decided against it as this seems rather s390 specific.
v4->v5:
- Rebase on v7.0-rc6
- Reworded note
- Add documentation for the new attribute
- Link to v4: https://lore.kernel.org/r/20251217-uid_slot-v4-1-559ceb59ba69@linux.ibm.com
v3->v4:
- Rebase on v6.19-rc1
- Collect R-bs
- Link to v3: https://lore.kernel.org/r/20251015-uid_slot-v3-1-44389895c1bb@linux.ibm.com
---
---
Documentation/arch/s390/pci.rst | 7 +++++++
arch/s390/include/asm/pci.h | 4 ++++
arch/s390/pci/pci_sysfs.c | 20 ++++++++++++++++++++
drivers/pci/slot.c | 13 ++++++++++++-
4 files changed, 43 insertions(+), 1 deletion(-)
diff --git a/Documentation/arch/s390/pci.rst b/Documentation/arch/s390/pci.rst
index d5755484d8e75c7bf67a350e61bbe04f0452a2fa..03afb57ece4df90a75597cb34c1f048c2e162b67 100644
--- a/Documentation/arch/s390/pci.rst
+++ b/Documentation/arch/s390/pci.rst
@@ -55,6 +55,13 @@ Entries specific to zPCI functions and entries that hold zPCI information.
- /sys/bus/pci/slots/XXXXXXXX/power
+ In addition to using the FID as the name of the slot the slot directory
+ also contains the following s390 specific slot attributes
+
+ - uid
+ The User-defined identifier (UID) of the function which may be configured
+ by this slot. See also the corresponding attribute of the device.
+
A physical function that currently supports a virtual function cannot be
powered off until all virtual functions are removed with:
echo 0 > /sys/bus/pci/devices/XXXX:XX:XX.X/sriov_numvf
diff --git a/arch/s390/include/asm/pci.h b/arch/s390/include/asm/pci.h
index c0ff19dab5807c7e1aabb48a0e9436aac45ec97d..5dcf35f0f325f5f44b28109a1c8d9aef18401035 100644
--- a/arch/s390/include/asm/pci.h
+++ b/arch/s390/include/asm/pci.h
@@ -208,6 +208,10 @@ extern const struct attribute_group zpci_ident_attr_group;
&pfip_attr_group, \
&zpci_ident_attr_group,
+extern const struct attribute_group zpci_slot_attr_group;
+
+#define ARCH_PCI_SLOT_GROUPS (&zpci_slot_attr_group)
+
extern unsigned int s390_pci_force_floating __initdata;
extern unsigned int s390_pci_no_rid;
diff --git a/arch/s390/pci/pci_sysfs.c b/arch/s390/pci/pci_sysfs.c
index c2444a23e26c4218832bb91930b5f0ffd498d28f..d98d97df792adb3c7e415a8d374cc2f3a65fbb52 100644
--- a/arch/s390/pci/pci_sysfs.c
+++ b/arch/s390/pci/pci_sysfs.c
@@ -187,6 +187,17 @@ static ssize_t index_show(struct device *dev,
}
static DEVICE_ATTR_RO(index);
+static ssize_t zpci_uid_slot_show(struct pci_slot *slot, char *buf)
+{
+ struct zpci_dev *zdev = container_of(slot->hotplug, struct zpci_dev,
+ hotplug_slot);
+
+ return sysfs_emit(buf, "0x%x\n", zdev->uid);
+}
+
+static struct pci_slot_attribute zpci_slot_attr_uid =
+ __ATTR(uid, 0444, zpci_uid_slot_show, NULL);
+
static umode_t zpci_index_is_visible(struct kobject *kobj,
struct attribute *attr, int n)
{
@@ -243,6 +254,15 @@ const struct attribute_group pfip_attr_group = {
.attrs = pfip_attrs,
};
+static struct attribute *zpci_slot_attrs[] = {
+ &zpci_slot_attr_uid.attr,
+ NULL,
+};
+
+const struct attribute_group zpci_slot_attr_group = {
+ .attrs = zpci_slot_attrs,
+};
+
static struct attribute *clp_fw_attrs[] = {
&uid_checking_attr.attr,
NULL,
diff --git a/drivers/pci/slot.c b/drivers/pci/slot.c
index 787311614e5b6ebb39e7284f9b9f205a0a684d6d..2f8fcfbbec24e73d0bb6e40fd04c05a94f518045 100644
--- a/drivers/pci/slot.c
+++ b/drivers/pci/slot.c
@@ -96,7 +96,18 @@ static struct attribute *pci_slot_default_attrs[] = {
&pci_slot_attr_cur_speed.attr,
NULL,
};
-ATTRIBUTE_GROUPS(pci_slot_default);
+
+static const struct attribute_group pci_slot_default_group = {
+ .attrs = pci_slot_default_attrs,
+};
+
+static const struct attribute_group *pci_slot_default_groups[] = {
+ &pci_slot_default_group,
+#ifdef ARCH_PCI_SLOT_GROUPS
+ ARCH_PCI_SLOT_GROUPS,
+#endif
+ NULL,
+};
static const struct kobj_type pci_slot_ktype = {
.sysfs_ops = &pci_slot_sysfs_ops,
---
base-commit: 7aaa8047eafd0bd628065b15757d9b48c5f9c07d
change-id: 20250923-uid_slot-e3559cf5ca30
Best regards,
--
Niklas Schnelle
^ permalink raw reply related
* Re: [PATCH net-next v3 2/3] dpll: add frequency monitoring callback ops
From: Vadim Fedorenko @ 2026-04-01 14:47 UTC (permalink / raw)
To: Ivan Vecera, netdev
Cc: Arkadiusz Kubalewski, David S. Miller, Donald Hunter,
Eric Dumazet, Jakub Kicinski, Jiri Pirko, Jonathan Corbet,
Michal Schmidt, Paolo Abeni, Petr Oros, Prathosh Satish,
Shuah Khan, Simon Horman, linux-doc, linux-kernel
In-Reply-To: <20260401091237.1071995-3-ivecera@redhat.com>
On 01/04/2026 10:12, Ivan Vecera wrote:
> Add new callback operations for a dpll device:
> - freq_monitor_get(..) - to obtain current state of frequency monitor
> feature from dpll device,
> - freq_monitor_set(..) - to allow feature configuration.
>
> Add new callback operation for a dpll pin:
> - measured_freq_get(..) - to obtain the measured frequency in mHz.
>
> Obtain the feature state value using the get callback and provide it to
> the user if the device driver implements callbacks. The measured_freq_get
> pin callback is only invoked when the frequency monitor is enabled.
> The freq_monitor_get device callback is required when measured_freq_get
> is provided by the driver.
>
> Execute the set callback upon user requests.
>
> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
> ---
> Changes v2 -> v3:
> - Made freq_monitor_get required when measured_freq_get is present (Jakub)
>
> Changes v1 -> v2:
> - Renamed actual-frequency to measured-frequency (Vadim)
> ---
> drivers/dpll/dpll_netlink.c | 92 +++++++++++++++++++++++++++++++++++++
> include/linux/dpll.h | 10 ++++
> 2 files changed, 102 insertions(+)
>
> diff --git a/drivers/dpll/dpll_netlink.c b/drivers/dpll/dpll_netlink.c
> index 83cbd64abf5a4..576d0cd074bd4 100644
> --- a/drivers/dpll/dpll_netlink.c
> +++ b/drivers/dpll/dpll_netlink.c
> @@ -175,6 +175,26 @@ dpll_msg_add_phase_offset_monitor(struct sk_buff *msg, struct dpll_device *dpll,
> return 0;
> }
>
> +static int
> +dpll_msg_add_freq_monitor(struct sk_buff *msg, struct dpll_device *dpll,
> + struct netlink_ext_ack *extack)
> +{
> + const struct dpll_device_ops *ops = dpll_device_ops(dpll);
> + enum dpll_feature_state state;
> + int ret;
> +
> + if (ops->freq_monitor_set && ops->freq_monitor_get) {
> + ret = ops->freq_monitor_get(dpll, dpll_priv(dpll),
> + &state, extack);
> + if (ret)
> + return ret;
> + if (nla_put_u32(msg, DPLL_A_FREQUENCY_MONITOR, state))
> + return -EMSGSIZE;
> + }
> +
> + return 0;
> +}
> +
> static int
> dpll_msg_add_phase_offset_avg_factor(struct sk_buff *msg,
> struct dpll_device *dpll,
> @@ -400,6 +420,40 @@ static int dpll_msg_add_ffo(struct sk_buff *msg, struct dpll_pin *pin,
> ffo);
> }
>
> +static int dpll_msg_add_measured_freq(struct sk_buff *msg, struct dpll_pin *pin,
> + struct dpll_pin_ref *ref,
> + struct netlink_ext_ack *extack)
> +{
> + const struct dpll_device_ops *dev_ops = dpll_device_ops(ref->dpll);
> + const struct dpll_pin_ops *ops = dpll_pin_ops(ref);
> + struct dpll_device *dpll = ref->dpll;
> + enum dpll_feature_state state;
> + u64 measured_freq;
> + int ret;
> +
> + if (!ops->measured_freq_get)
> + return 0;
> + if (WARN_ON(!dev_ops->freq_monitor_get))
> + return -EINVAL;
I think pin registration function has to be adjusted to not allow
measured_freq_get() callback if device doesn't have freq_monitor_get()
callback (or both freq_monitor_{s,g}et). Then this defensive part can
be completely removed.
> + ret = dev_ops->freq_monitor_get(dpll, dpll_priv(dpll),
^ permalink raw reply
* Re: [PATCH 14/33] rust: bump `bindgen` minimum supported version to 0.71.1 (Debian Trixie)
From: Gary Guo @ 2026-04-01 14:38 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-15-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda wrote:
> As proposed in the past in e.g. LPC 2025 and the Maintainers Summit [1],
> we are going to follow Debian Stable's `bindgen` versions as our minimum
> supported version.
>
> Debian Trixie was released with `bindgen` 0.71.1, which it still uses
> to this day [2].
>
> Debian Trixie's release happened on 2025-08-09 [3], which means that a
> fair amount of time has passed since its release for kernel developers
> to upgrade.
>
> Thus bump the minimum to the new version.
>
> Then, in later commits, clean up most of the workarounds and other bits
> that this upgrade of the minimum allows us.
>
> Ubuntu 25.10 also has a recent enough `bindgen` [4] (even the already
> unsupported Ubuntu 25.04 had it), and they also provide versioned packages
> with `bindgen` 0.71.1 back to Ubuntu 24.04 LTS [5].
>
> Link: https://lwn.net/Articles/1050174/ [1]
> Link: https://packages.debian.org/trixie/bindgen [2]
> Link: https://www.debian.org/releases/trixie/ [3]
> Link: https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=bindgen [4]
> Link: https://launchpad.net/ubuntu/+source/rust-bindgen-0.71 [5]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> Documentation/process/changes.rst | 2 +-
> scripts/min-tool-version.sh | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: [PATCH 13/33] rust: block: update `const_refs_to_static` MSRV TODO comment
From: Gary Guo @ 2026-04-01 14:37 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-14-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda wrote:
> `feature(const_refs_to_static)` was stabilized in Rust 1.83.0 [1].
>
> Thus update the comment to reflect that.
>
> Link: https://github.com/rust-lang/rust/pull/129759 [1]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> rust/kernel/block/mq/gen_disk.rs | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
^ permalink raw reply
* Re: [PATCH v2 06/22] vfio/pci: Retrieve preserved device files after Live Update
From: Pratyush Yadav @ 2026-04-01 14:36 UTC (permalink / raw)
To: David Matlack
Cc: Alex Williamson, Adithya Jayachandran, Alexander Graf,
Alex Mastro, Alistair Popple, Andrew Morton, Ankit Agrawal,
Bjorn Helgaas, Chris Li, David Rientjes, Jacob Pan,
Jason Gunthorpe, Jason Gunthorpe, Jonathan Corbet, Josh Hilke,
Kevin Tian, kexec, kvm, Leon Romanovsky, Leon Romanovsky,
linux-doc, linux-kernel, linux-kselftest, linux-mm, linux-pci,
Lukas Wunner, Michał Winiarski, Mike Rapoport, Parav Pandit,
Pasha Tatashin, Pranjal Shrivastava, Pratyush Yadav,
Raghavendra Rao Ananta, Rodrigo Vivi, Saeed Mahameed,
Samiullah Khawaja, Shuah Khan, Thomas Hellström,
Tomita Moeko, Vipin Sharma, Vivek Kasireddy, William Tu, Yi Liu,
Zhu Yanjun
In-Reply-To: <aaDZ-ffs4kiUo3GY@google.com>
On Thu, Feb 26 2026, David Matlack wrote:
> On 2026-02-26 03:52 PM, Alex Williamson wrote:
>> On Thu, 29 Jan 2026 21:24:53 +0000 David Matlack <dmatlack@google.com> wrote:
>
>> > diff --git a/drivers/vfio/device_cdev.c b/drivers/vfio/device_cdev.c
>> > index 8ceca24ac136..935f84a35875 100644
>> > --- a/drivers/vfio/device_cdev.c
>> > +++ b/drivers/vfio/device_cdev.c
>> > @@ -52,6 +46,19 @@ int vfio_device_fops_cdev_open(struct inode *inode, struct file *filep)
>> > vfio_device_put_registration(device);
>> > return ret;
>> > }
>> > +EXPORT_SYMBOL_GPL(__vfio_device_fops_cdev_open);
>>
>> I really dislike that we're exporting the underscore variant, which
>> implies it's an internal function that the caller should understand the
>> constraints, without outlining any constraints.
>>
>> I'm not sure what a good alternative is. We can drop fops since this
>> isn't called from file_operations. Maybe vfio_device_cdev_open_file().
>
> Ack. Due to the bug you pointed out below, I think the changes in this
> file will look fairly different in the next version. But no matter what
> I'll avoid exporting a underscore variant without outlining the
> constraints.
I haven't yet had a chance to read v3 so maybe you already solved this
problem. But I dealt with some similar problems for the memfd patches
[0] and the hugetlb patches [1]. What I did was to just use/add a
internal header (mm/internal.h or mm/hugetlb_internal.h). This lets you
share functions within your subsystem but avoid exporting everywhere
else.
I see that there already is drivers/vfio/vfio.h so perhaps you can use
that to avoid exporting these functions outside the subsystem?
[0] https://git.kernel.org/torvalds/c/ed6f45f81bf9
[1] https://lore.kernel.org/linux-mm/20251206230222.853493-6-pratyush@kernel.org/
[...]
--
Regards,
Pratyush Yadav
^ permalink raw reply
* Re: [PATCH 12/33] rust: macros: update `extract_if` MSRV TODO comment
From: Gary Guo @ 2026-04-01 14:18 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-13-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda wrote:
> `feature(extract_if)` was stabilized in Rust 1.87.0 [1].
>
> Thus update the comment to reflect that.
>
> Alternatively, we could use it unstably already.
>
> Link: https://github.com/rust-lang/rust/pull/137109 [1]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
> ---
> rust/macros/kunit.rs | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/rust/macros/kunit.rs b/rust/macros/kunit.rs
> index 6be880d634e2..6f6d746b8dbb 100644
> --- a/rust/macros/kunit.rs
> +++ b/rust/macros/kunit.rs
> @@ -87,7 +87,7 @@ pub(crate) fn kunit_tests(test_suite: Ident, mut module: ItemMod) -> Result<Toke
> continue;
> };
>
> - // TODO: Replace below with `extract_if` when MSRV is bumped above 1.85.
> + // TODO: Replace with `extract_if` when MSRV is >= 1.87.0.
> let before_len = f.attrs.len();
> f.attrs.retain(|attr| !attr.path().is_ident("test"));
> if f.attrs.len() == before_len {
When I write the comment the intention is to enable the unstable feature and
switch.
Best,
Gary
diff --git a/rust/macros/kunit.rs b/rust/macros/kunit.rs
index 6be880d634e2..ae20ed6768f1 100644
--- a/rust/macros/kunit.rs
+++ b/rust/macros/kunit.rs
@@ -87,10 +87,11 @@ pub(crate) fn kunit_tests(test_suite: Ident, mut module: ItemMod) -> Result<Toke
continue;
};
- // TODO: Replace below with `extract_if` when MSRV is bumped above 1.85.
- let before_len = f.attrs.len();
- f.attrs.retain(|attr| !attr.path().is_ident("test"));
- if f.attrs.len() == before_len {
+ if f.attrs
+ .extract_if(.., |attr| attr.path().is_ident("test"))
+ .count()
+ == 0
+ {
processed_items.push(Item::Fn(f));
continue;
}
diff --git a/rust/macros/lib.rs b/rust/macros/lib.rs
index 0c36194d9971..2cfd59e0f9e7 100644
--- a/rust/macros/lib.rs
+++ b/rust/macros/lib.rs
@@ -6,6 +6,9 @@
// and thus add a dependency on `include/config/RUSTC_VERSION_TEXT`, which is
// touched by Kconfig when the version string from the compiler changes.
+// Stable since Rust 1.87.0.
+#![feature(extract_if)]
+//
// Stable since Rust 1.88.0 under a different name, `proc_macro_span_file`,
// which was added in Rust 1.88.0. This is why `cfg_attr` is used here, i.e.
// to avoid depending on the full `proc_macro_span` on Rust >= 1.88.0.
^ permalink raw reply related
* [PATCH] doc: fix typo in serial-console documentation
From: George Jones @ 2026-04-01 14:12 UTC (permalink / raw)
To: linux-doc; +Cc: George Jones
In-Reply-To: <20260401141212.23955-1-gjones.dev@gmail.com>
Signed-off-by: George Jones <gjones.dev@gmail.com>
---
Documentation/admin-guide/serial-console.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/serial-console.rst b/Documentation/admin-guide/serial-console.rst
index 1609e7479249..d3260f7846f5 100644
--- a/Documentation/admin-guide/serial-console.rst
+++ b/Documentation/admin-guide/serial-console.rst
@@ -55,7 +55,7 @@ times. In this case, there are the following two rules:
subsystems.
This rule is used also when the last console= parameter is not used
- for other reasons. For example, because of a typo or because
+ for other reasons. For example, due to a typo or
the hardware is not available.
The result might be surprising. For example, the following two command
--
2.43.0
^ permalink raw reply related
* [PATCH] doc: fix typo in coding-style documentation (reformat)
From: George Jones @ 2026-04-01 14:12 UTC (permalink / raw)
To: linux-doc; +Cc: Zack Mackintire
In-Reply-To: <20260401141212.23955-1-gjones.dev@gmail.com>
From: Zack Mackintire <zackm@gmail.com>
Signed-off-by: Zack Mackintire <zackm@gmail.com>
---
Documentation/process/coding-style.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst
index 35b381230f6e..28040b3d0e1a 100644
--- a/Documentation/process/coding-style.rst
+++ b/Documentation/process/coding-style.rst
@@ -719,7 +719,7 @@ re-formatting you may want to take a look at the man page. But
remember: ``indent`` is not a fix for bad programming.
Note that you can also use the ``clang-format`` tool to help you with
-these rules, to quickly re-format parts of your code automatically,
+these rules, to quickly reformat parts of your code automatically,
and to review full files in order to spot coding style mistakes,
typos and possible improvements. It is also handy for sorting ``#includes``,
for aligning variables/macros, for reflowing text and other similar tasks.
--
2.43.0
^ permalink raw reply related
* [PATCH] doc: clarify wording for ntrig sensor disconnect behavior
From: George Jones @ 2026-04-01 14:12 UTC (permalink / raw)
To: linux-doc; +Cc: George Jones
In-Reply-To: <20260401141212.23955-1-gjones.dev@gmail.com>
Signed-off-by: George Jones <gjones.dev@gmail.com>
---
Documentation/input/devices/ntrig.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/input/devices/ntrig.rst b/Documentation/input/devices/ntrig.rst
index 1559f53495cb..cba4803ade8d 100644
--- a/Documentation/input/devices/ntrig.rst
+++ b/Documentation/input/devices/ntrig.rst
@@ -41,7 +41,7 @@ The following parameters are used to configure filters to reduce noise:
When the last finger is removed from the device, it sends a number of empty
frames. By holding off on deactivation for a few frames we can tolerate false
-erroneous disconnects, where the sensor may mistakenly not detect a finger that
+erroneous disconnects, where the sensor may fail to detect a finger that
is still present. Thus deactivate_slack addresses problems where a users might
see breaks in lines during drawing, or drop an object during a long drag.
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox