imrcpan/erofs-linux
1
0 Fork 0
mirror of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs.git synced 2026-10-28 12:53:14 +01:00
Code Issues Packages Projects Releases Wiki Activity
1,484,698 Commits 5 Branches 1,033 Tags
dev
Commit Graph
11 Commits
Author SHA1 Message Date
Jan Polensky fc1118cdc3 rust/bindgen_parameters: Mark s390 types as opaque to prevent repr conflicts 
Bindgen attempts to generate Rust layouts for a number of s390 structs
that are packed but contain, or transitively contain, aligned fields.
Rust rejects such layouts with E0588 ("packed type cannot transitively
contain a #[repr(align)] type").

Add the affected s390 types to the opaque type list so bindgen emits
opaque blob types instead of full representations. This matches existing
workarounds for x86 types such as alt_instr and x86_msi_data.

Link: https://lore.kernel.org/all/[email protected]/
Acked-by: Miguel Ojeda <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Acked-by: Heiko Carstens <[email protected]>
Signed-off-by: Jan Polensky <[email protected]>
Signed-off-by: Alexander Gordeev <[email protected]>
 2026-06-10 16:25:13 +02:00
Alice Ryhl 9e5946de3a rust: declare cfi_encoding for lru_status 
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 <[email protected]>
Link: https://patch.msgid.link/[email protected]
[ Rebased on top of the minimum Rust version bump series which provide
  the required `bindgen` version. - Miguel ]
Reviewed-by: Gary Guo <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
 2026-04-07 10:00:25 +02:00
Miguel Ojeda 518b9ad2fa rust: kbuild: remove "try keyword" workaround for bindgen < 0.59.2 
There is a workaround that has not been needed, even already after commit
08ab786556 ("rust: bindgen: upgrade to 0.65.1"), but it does not hurt.

Thus remove it.

Reviewed-by: Tamir Duberstein <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
 2026-04-07 09:51:39 +02:00
Lorenzo Stoakes 2b6a3f061f mm: declare VMA flags by bit 
Patch series "initial work on making VMA flags a bitmap", v3.

We are in the rather silly situation that we are running out of VMA flags
as they are currently limited to a system word in size.

This leads to absurd situations where we limit features to 64-bit
architectures only because we simply do not have the ability to add a flag
for 32-bit ones.

This is very constraining and leads to hacks or, in the worst case, simply
an inability to implement features we want for entirely arbitrary reasons.

This also of course gives us something of a Y2K type situation in mm where
we might eventually exhaust all of the VMA flags even on 64-bit systems.

This series lays the groundwork for getting away from this limitation by
establishing VMA flags as a bitmap whose size we can increase in future
beyond 64 bits if required.

This is necessarily a highly iterative process given the extensive use of
VMA flags throughout the kernel, so we start by performing basic steps.

Firstly, we declare VMA flags by bit number rather than by value,
retaining the VM_xxx fields but in terms of these newly introduced
VMA_xxx_BIT fields.

While we are here, we use sparse annotations to ensure that, when dealing
with VMA bit number parameters, we cannot be passed values which are not
declared as such - providing some useful type safety.

We then introduce an opaque VMA flag type, much like the opaque mm_struct
flag type introduced in commit bb6525f2f8 ("mm: add bitmap mm->flags
field"), which we establish in union with vma->vm_flags (but still set at
system word size meaning there is no functional or data type size change).

We update the vm_flags_xxx() helpers to use this new bitmap, introducing
sensible helpers to do so.

This series lays the foundation for further work to expand the use of
bitmap VMA flags and eventually eliminate these arbitrary restrictions.


This patch (of 4):

In order to lay the groundwork for VMA flags being a bitmap rather than a
system word in size, we need to be able to consistently refer to VMA flags
by bit number rather than value.

Take this opportunity to do so in an enum which we which is additionally
useful for tooling to extract metadata from.

This additionally makes it very clear which bits are being used for what
at a glance.

We use the VMA_ prefix for the bit values as it is logical to do so since
these reference VMAs.  We consistently suffix with _BIT to make it clear
what the values refer to.

We declare bit values even when the flags that use them would not be
enabled by config options as this is simply clearer and clearly defines
what bit numbers are used for what, at no additional cost.

We declare a sparse-bitwise type vma_flag_t which ensures that users can't
pass around invalid VMA flags by accident and prepares for future work
towards VMA flags being a bitmap where we want to ensure bit values are
type safe.

To make life easier, we declare some macro helpers - DECLARE_VMA_BIT()
allows us to avoid duplication in the enum bit number declarations (and
maintaining the sparse __bitwise attribute), and INIT_VM_FLAG() is used to
assist with declaration of flags.

Unfortunately we can't declare both in the enum, as we run into issue with
logic in the kernel requiring that flags are preprocessor definitions, and
additionally we cannot have a macro which declares another macro so we
must define each flag macro directly.

Additionally, update the VMA userland testing vma_internal.h header to
include these changes.

We also have to fix the parameters to the vma_flag_*_atomic() functions
since VMA_MAYBE_GUARD_BIT is now of type vma_flag_t and sparse will
complain otherwise.

We have to update some rather silly if-deffery found in mm/task_mmu.c
which would otherwise break.

Finally, we update the rust binding helper as now it cannot auto-detect
the flags at all.

Link: https://lkml.kernel.org/r/[email protected]
Link: https://lkml.kernel.org/r/3a35e5a0bcfa00e84af24cbafc0653e74deda64a.1764064556.git.lorenzo.stoakes@oracle.com
Signed-off-by: Lorenzo Stoakes <[email protected]>
Acked-by: Vlastimil Babka <[email protected]>
Reviewed-by: Pedro Falcato <[email protected]>
Acked-by: Alice Ryhl <[email protected]>	[rust]
Cc: Alex Gaynor <[email protected]>
Cc: Alistair Popple <[email protected]>
Cc: Andreas Hindborg <[email protected]>
Cc: Axel Rasmussen <[email protected]>
Cc: Baolin Wang <[email protected]>
Cc: Baoquan He <[email protected]>
Cc: Barry Song <[email protected]>
Cc: Ben Segall <[email protected]>
Cc: Björn Roy Baron <[email protected]>
Cc: Boqun Feng <[email protected]>
Cc: Byungchul Park <[email protected]>
Cc: Chengming Zhou <[email protected]>
Cc: Chris Li <[email protected]>
Cc: Danilo Krummrich <[email protected]>
Cc: David Hildenbrand <[email protected]>
Cc: David Rientjes <[email protected]>
Cc: Dev Jain <[email protected]>
Cc: Dietmar Eggemann <[email protected]>
Cc: Gary Guo <[email protected]>
Cc: Gregory Price <[email protected]>
Cc: "Huang, Ying" <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Jann Horn <[email protected]>
Cc: Jason Gunthorpe <[email protected]>
Cc: Johannes Weiner <[email protected]>
Cc: John Hubbard <[email protected]>
Cc: Joshua Hahn <[email protected]>
Cc: Juri Lelli <[email protected]>
Cc: Kairui Song <[email protected]>
Cc: Kees Cook <[email protected]>
Cc: Kemeng Shi <[email protected]>
Cc: Lance Yang <[email protected]>
Cc: Leon Romanovsky <[email protected]>
Cc: Liam Howlett <[email protected]>
Cc: Mathew Brost <[email protected]>
Cc: Matthew Wilcox (Oracle) <[email protected]>
Cc: Mel Gorman <mgorman <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Miguel Ojeda <[email protected]>
Cc: Mike Rapoport <[email protected]>
Cc: Muchun Song <[email protected]>
Cc: Nhat Pham <[email protected]>
Cc: Nico Pache <[email protected]>
Cc: Oscar Salvador <[email protected]>
Cc: Peter Xu <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Qi Zheng <[email protected]>
Cc: Rakie Kim <[email protected]>
Cc: Rik van Riel <[email protected]>
Cc: Ryan Roberts <[email protected]>
Cc: Shakeel Butt <[email protected]>
Cc: Steven Rostedt <[email protected]>
Cc: Suren Baghdasaryan <[email protected]>
Cc: Trevor Gross <[email protected]>
Cc: Valentin Schneider <[email protected]>
Cc: Vincent Guittot <[email protected]>
Cc: Wei Xu <[email protected]>
Cc: xu xin <[email protected]>
Cc: Yuanchu Xie <[email protected]>
Cc: Zi Yan <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
 2025-11-29 10:41:08 -08:00
Benno Lossin 4846300ba8 rust: derive Zeroable for all structs & unions generated by bindgen where possible 
Using the `--with-derive-custom-{struct,union}` option of bindgen, add
`#[derive(MaybeZeroable)]` to every struct & union. This makes those
types implement `Zeroable` if all their fields implement it.

Sadly bindgen doesn't add custom derives to the `__BindgenBitfieldUnit`
struct. So manually implement `Zeroable` for that.

Signed-off-by: Benno Lossin <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
[ Formatted comment. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>
 2025-09-08 14:03:17 +02:00
Danilo Krummrich 8efe8816a7 rust: alloc: add ARCH_KMALLOC_MINALIGN to bindgen blocklist 
For some architectures, such as X86_64, ARCH_KMALLOC_MINALIGN is not
resolvable for bindgen. E.g. due to being defined as
__alignof__(unsigned long long).

Hence, we have to create a rust helper, i.e. let the C compiler evaluate
the expression and store it in a const.

However, if for other architectures, such as arm64,
ARCH_KMALLOC_MINALIGN does evaluate to something that can be directly
processed by bindgen, we end up with multiple definitions of
ARCH_KMALLOC_MINALIGN in the generated bindings.

	error[E0428]: the name `ARCH_KMALLOC_MINALIGN` is defined multiple times
	      --> /builddir/build/BUILD/kernel-6.17.0-build/kernel-next-20250818/linux-6.17.0-0.0.next.20250818.423.vanilla.fc44.aarch64/rust/bindings/bindings_generated.rs:134545:1
	       |
	9622   | pub const ARCH_KMALLOC_MINALIGN: u32 = 8;
	       | ----------------------------------------- previous definition of the value `ARCH_KMALLOC_MINALIGN` here
	...
	134545 | pub const ARCH_KMALLOC_MINALIGN: usize = 8;
	       | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `ARCH_KMALLOC_MINALIGN` redefined here
	       |
	       = note: `ARCH_KMALLOC_MINALIGN` must be defined only once in the value namespace of this module

To fix this up, add ARCH_KMALLOC_MINALIGN to the blocklist of bindgen,
such that we always only generate the symbol from the rust helper.

Reported-by: Thorsten Leemhuis <[email protected]>
Closes: https://lore.kernel.org/all/[email protected]/
Fixes: 1b1a946dc2 ("rust: alloc: specify the minimum alignment of each allocator")
Tested-by: Thorsten Leemhuis <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Danilo Krummrich <[email protected]>
 2025-08-19 20:01:18 +02:00
Gary Guo 2fd6f55c04 rust: map __kernel_size_t and friends also to usize/isize 
Currently bindgen has special logic to recognise `size_t` and `ssize_t`
and map them to Rust `usize` and `isize`. Similarly, `ptrdiff_t` is
mapped to `isize`.

However this falls short for `__kernel_size_t`, `__kernel_ssize_t` and
`__kernel_ptrdiff_t`. To ensure that they are mapped to usize/isize
rather than 32/64 integers depending on platform, blocklist them in
bindgen parameters and manually provide their definition.

Signed-off-by: Gary Guo <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Reviewed-by: Trevor Gross <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Formatted comment. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>
 2024-11-10 23:58:00 +01:00
Gary Guo 732cd686cd rust: fix ARCH_SLAB_MINALIGN multiple definition error 
We use const helpers in form of

    const size_t RUST_CONST_HELPER_ARCH_SLAB_MINALIGN = ARCH_SLAB_MINALIGN;

to aid generation of constants by bindgen because it is otherwise a
macro definition of an expression and bindgen doesn't expand the
constant. The helpers are then have `RUST_CONST_HELPER` prefix stripped
and exposed to Rust code as if `ARCH_SLAB_MISALIGN` is generated
natively by bindgen.

This works well for most constants, but on RISC-V, `ARCH_SLAB_MINALIGN`
is defined directly as literal constant if `!CONFIG_MMU`, and bindgen
would generate `ARCH_SLAB_MINALIGN` directly, thus conflict with the
one generated through the helper.

To fix this, we simply need to block bindgen from generating directly
without going through helper.

Reported-by: kernel test robot <[email protected]>
Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
Signed-off-by: Gary Guo <[email protected]>
Reviewed-by: Christian Schrefl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
 2024-09-26 17:52:35 +02:00
Matthew Maurer bad098d768 rust: Ignore preserve-most functions 
Neither bindgen nor Rust know about the preserve-most calling
convention, and Clang describes it as unstable. Since we aren't using
functions with this calling convention from Rust, blocklist them.

These functions are only added to the build when list hardening is
enabled, which is likely why others didn't notice this yet.

Signed-off-by: Matthew Maurer <[email protected]>
Reviewed-by: Martin Rodriguez Reboredo <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Used Markdown for consistency with the other comments in the file. ]
Signed-off-by: Miguel Ojeda <[email protected]>
 2023-12-13 01:09:55 +01:00
Arnaldo Carvalho de Melo 3098cb655e rust: bindgen: Add alt_instr as opaque type 
To address this build error:

    BINDGEN rust/bindings/bindings_generated.rs
    BINDGEN rust/bindings/bindings_helpers_generated.rs
    EXPORTS rust/exports_core_generated.h
    RUSTC P rust/libmacros.so
    RUSTC L rust/compiler_builtins.o
    RUSTC L rust/alloc.o
    RUSTC L rust/bindings.o
    RUSTC L rust/build_error.o
    EXPORTS rust/exports_alloc_generated.h
  error[E0588]: packed type cannot transitively contain a `#[repr(align)]` type
       --> /var/home/acme/git/linux/rust/bindings/bindings_generated.rs:10094:1
        |
  10094 | / pub struct alt_instr {
  10095 | |     pub instr_offset: s32,
  10096 | |     pub repl_offset: s32,
  10097 | |     pub __bindgen_anon_1: alt_instr__bindgen_ty_1,
  10098 | |     pub instrlen: u8_,
  10099 | |     pub replacementlen: u8_,
  10100 | | }
        | |_^
        |
  note: `alt_instr__bindgen_ty_1__bindgen_ty_1` has a `#[repr(align)]` attribute
       --> /var/home/acme/git/linux/rust/bindings/bindings_generated.rs:10111:1
        |
  10111 | / pub struct alt_instr__bindgen_ty_1__bindgen_ty_1 {
  10112 | |     pub _bitfield_1: __BindgenBitfieldUnit<[u8; 4usize], u16>,
  10113 | | }
        | |_^
  note: `alt_instr` contains a field of type `alt_instr__bindgen_ty_1`
       --> /var/home/acme/git/linux/rust/bindings/bindings_generated.rs:10097:9
        |
  10097 |     pub __bindgen_anon_1: alt_instr__bindgen_ty_1,
        |         ^^^^^^^^^^^^^^^^
  note: ...which contains a field of type `alt_instr__bindgen_ty_1__bindgen_ty_1`
       --> /var/home/acme/git/linux/rust/bindings/bindings_generated.rs:10104:9
        |
  10104 |     pub __bindgen_anon_1: alt_instr__bindgen_ty_1__bindgen_ty_1,
        |         ^^^^^^^^^^^^^^^^

  error: aborting due to previous error

  For more information about this error, try `rustc --explain E0588`.
  make[1]: *** [rust/Makefile:389: rust/bindings.o] Error 1
  make: *** [Makefile:1293: prepare] Error 2

Cc: Derek Barbosa <[email protected]>
Cc: Miguel Ojeda <[email protected]>
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Fixes: 5d1dd961e7 ("x86/alternatives: Add alt_instr.flags")
Reported-by: kernel test robot <[email protected]>
Reported-by: Vincenzo Palazzo <[email protected]>
Reviewed-by: Martin Rodriguez Reboredo <[email protected]>
Reviewed-by: Vincenzo Palazzo <[email protected]>
Signed-off-by: Miguel Ojeda <[email protected]>
 2023-03-02 22:44:15 +01:00
Miguel Ojeda 2f7ab1267d Kbuild: add Rust support 
Having most of the new files in place, we now enable Rust support
in the build system, including `Kconfig` entries related to Rust,
the Rust configuration printer and a few other bits.

Reviewed-by: Kees Cook <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>
Tested-by: Nick Desaulniers <[email protected]>
Reviewed-by: Greg Kroah-Hartman <[email protected]>
Co-developed-by: Alex Gaynor <[email protected]>
Signed-off-by: Alex Gaynor <[email protected]>
Co-developed-by: Finn Behrens <[email protected]>
Signed-off-by: Finn Behrens <[email protected]>
Co-developed-by: Adam Bratschi-Kaye <[email protected]>
Signed-off-by: Adam Bratschi-Kaye <[email protected]>
Co-developed-by: Wedson Almeida Filho <[email protected]>
Signed-off-by: Wedson Almeida Filho <[email protected]>
Co-developed-by: Michael Ellerman <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Co-developed-by: Sven Van Asbroeck <[email protected]>
Signed-off-by: Sven Van Asbroeck <[email protected]>
Co-developed-by: Gary Guo <[email protected]>
Signed-off-by: Gary Guo <[email protected]>
Co-developed-by: Boris-Chengbiao Zhou <[email protected]>
Signed-off-by: Boris-Chengbiao Zhou <[email protected]>
Co-developed-by: Boqun Feng <[email protected]>
Signed-off-by: Boqun Feng <[email protected]>
Co-developed-by: Douglas Su <[email protected]>
Signed-off-by: Douglas Su <[email protected]>
Co-developed-by: Dariusz Sosnowski <[email protected]>
Signed-off-by: Dariusz Sosnowski <[email protected]>
Co-developed-by: Antonio Terceiro <[email protected]>
Signed-off-by: Antonio Terceiro <[email protected]>
Co-developed-by: Daniel Xu <[email protected]>
Signed-off-by: Daniel Xu <[email protected]>
Co-developed-by: Björn Roy Baron <[email protected]>
Signed-off-by: Björn Roy Baron <[email protected]>
Co-developed-by: Martin Rodriguez Reboredo <[email protected]>
Signed-off-by: Martin Rodriguez Reboredo <[email protected]>
Signed-off-by: Miguel Ojeda <[email protected]>
 2022-09-28 09:02:20 +02:00