* Re: [PATCH 14/33] rust: bump `bindgen` minimum supported version to 0.71.1 (Debian Trixie)
From: Tamir Duberstein @ 2026-04-01 22:59 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-15-ojeda@kernel.org>
On Wed, 01 Apr 2026 13:45:21 +0200, Miguel Ojeda <ojeda@kernel.org> 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].
>
> [...]
Acked-by: Tamir Duberstein <tamird@kernel.org>
--
Tamir Duberstein <tamird@kernel.org>
^ permalink raw reply
* Re: [PATCH 13/33] rust: block: update `const_refs_to_static` MSRV TODO comment
From: Tamir Duberstein @ 2026-04-01 22:59 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-14-ojeda@kernel.org>
On Wed, 01 Apr 2026 13:45:20 +0200, Miguel Ojeda <ojeda@kernel.org> wrote:
> diff --git a/rust/kernel/block/mq/gen_disk.rs b/rust/kernel/block/mq/gen_disk.rs
> index c8b0ecb17082..912cb805caf5 100644
> --- a/rust/kernel/block/mq/gen_disk.rs
> +++ b/rust/kernel/block/mq/gen_disk.rs
> @@ -140,9 +140,7 @@ pub fn build<T: Operations>(
> devnode: None,
> alternative_gpt_sector: None,
> get_unique_id: None,
> - // TODO: Set to THIS_MODULE. Waiting for const_refs_to_static feature to
> - // be merged (unstable in rustc 1.78 which is staged for linux 6.10)
> - // <https://github.com/rust-lang/rust/issues/119618>
> + // TODO: Set to `THIS_MODULE`.
Good first issue?
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
--
Tamir Duberstein <tamird@kernel.org>
^ permalink raw reply
* Re: [PATCH 12/33] rust: macros: update `extract_if` MSRV TODO comment
From: Tamir Duberstein @ 2026-04-01 22:59 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-13-ojeda@kernel.org>
On Wed, 01 Apr 2026 13:45:19 +0200, Miguel Ojeda <ojeda@kernel.org> 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.
Perhaps the TODO could mention this alternative. Would probably make a
good first issue.
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
--
Tamir Duberstein <tamird@kernel.org>
^ permalink raw reply
* Re: [PATCH 11/33] rust: alloc: simplify with `NonNull::add()` now that it is stable
From: Tamir Duberstein @ 2026-04-01 22:59 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-12-ojeda@kernel.org>
On Wed, 01 Apr 2026 13:45:18 +0200, Miguel Ojeda <ojeda@kernel.org> wrote:
> Currently we need to go through raw pointers and then re-create the
> `NonNull` from the result of offsetting the raw pointer.
>
> Thus, now that we bump the Rust minimum version, simplify using
> `NonNull::add()` and clean the TODO note.
This description is inconsistent with the previous one which had
citations for both the feature (function in this case) and the feature
in which it became stable (available in this case). I don't prefer
either style in particular, just that things are consistent.
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
--
Tamir Duberstein <tamird@kernel.org>
^ permalink raw reply
* Re: [PATCH 10/33] rust: transmute: simplify code with Rust 1.80.0 `split_at_*checked()`
From: Tamir Duberstein @ 2026-04-01 22:59 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-11-ojeda@kernel.org>
On Wed, 01 Apr 2026 13:45:17 +0200, Miguel Ojeda <ojeda@kernel.org> wrote:
> `feature(split_at_checked)` [1] has been stabilized in Rust 1.80.0 [2],
> which is beyond our new minimum Rust version (Rust 1.85.0).
"beyond" is probably not the right word here?
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
--
Tamir Duberstein <tamird@kernel.org>
^ permalink raw reply
* Re: [PATCH 09/33] rust: kbuild: make `--remap-path-prefix` workaround conditional
From: Tamir Duberstein @ 2026-04-01 22:59 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-10-ojeda@kernel.org>
On Wed, 01 Apr 2026 13:45:16 +0200, Miguel Ojeda <ojeda@kernel.org> wrote:
> The Internal Compiler Error that the comment mentions [1] was fixed in
> Rust 1.87.0 [2]. And, for other workarounds, we plan on limiting where
> we apply them [3].
>
> Thus limit the ICE one too.
>
> This will help to make sure the workaround is not needed anymore on
> newer versions.
>
> [...]
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
--
Tamir Duberstein <tamird@kernel.org>
^ permalink raw reply
* Re: [PATCH 08/33] rust: kbuild: simplify `--remap-path-prefix` workaround
From: Tamir Duberstein @ 2026-04-01 22:59 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-9-ojeda@kernel.org>
On Wed, 01 Apr 2026 13:45:15 +0200, Miguel Ojeda <ojeda@kernel.org> wrote:
Does this simplify the workaround, or just remove one instance of it?
> [...]
>
> Note that commit dda135077ecc ("rust: build: remap path to avoid
> absolute path") re-landed the `--remap-path-prefix` flag (together with
> `--remap-path-scope`), so we keep the workaround, i.e. an alternative
> could have been to simply delete the skip entirely, but since we still
> have it and it will be needed when this gets merged, let's keep it.
The use of "re-landed" is confusing without a mention of commit
8cf5b3f83614 ("Revert "kbuild, rust: use -fremap-path-prefix to make
paths relative""). Though this whole thing might be clearer without a
mention of that history; the important part is that there's no
conditional use of `--remap-path-scope` in the base commit but there
will be when dda135077ecc is merged (the use of "this" in "this gets
merged" is also ambiguous).
>
>
> diff --git a/rust/Makefile b/rust/Makefile
> index 193cf06eea64..708530ee3613 100644
> --- a/rust/Makefile
> +++ b/rust/Makefile
> @@ -142,10 +142,9 @@ rustdoc_modifiers_workaround := $(if $(call rustc-min-version,108800),-Cunsafe-a
> # Similarly, for doctests (https://github.com/rust-lang/rust/issues/146465).
> doctests_modifiers_workaround := $(rustdoc_modifiers_workaround)$(if $(call rustc-min-version,109100),$(comma)sanitizer)
>
> -# `rustc` recognizes `--remap-path-prefix` since 1.26.0, but `rustdoc` only
> -# since Rust 1.81.0. Moreover, `rustdoc` ICEs on out-of-tree builds since Rust
> -# 1.82.0 (https://github.com/rust-lang/rust/issues/138520). Thus workaround both
> -# issues skipping the flag. The former also applies to `RUSTDOC TK`.
> +# `rustdoc` ICEs on out-of-tree builds in Rust < 1.87.0
> +# (https://github.com/rust-lang/rust/issues/138520). Thus workaround the
> +# issue skipping the flag.
_by_ skipping the flag? this is preexisting, though.
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
--
Tamir Duberstein <tamird@kernel.org>
^ permalink raw reply
* Re: [PATCH 07/33] rust: kbuild: remove `feature(...)`s that are now stable
From: Tamir Duberstein @ 2026-04-01 22:59 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-8-ojeda@kernel.org>
On Wed, 01 Apr 2026 13:45:14 +0200, Miguel Ojeda <ojeda@kernel.org> wrote:
> Now that the Rust minimum version is 1.85.0, there is no need to enable
> certain features that are stable.
>
> Thus clean them up.
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
--
Tamir Duberstein <tamird@kernel.org>
^ permalink raw reply
* Re: [PATCH 06/33] rust: kbuild: remove skipping of `-Wrustdoc::unescaped_backticks`
From: Tamir Duberstein @ 2026-04-01 22:59 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-7-ojeda@kernel.org>
On Wed, 01 Apr 2026 13:45:13 +0200, Miguel Ojeda <ojeda@kernel.org> wrote:
> Back in Rust 1.82.0, I cleaned the `rustdoc::unescaped_backticks` lint in
> upstream Rust and added tests so that hopefully it would not regress [1].
>
> Thus we can remove it from our side given the Rust minimum version bump.
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
--
Tamir Duberstein <tamird@kernel.org>
^ permalink raw reply
* Re: [PATCH 05/33] rust: remove `RUSTC_HAS_COERCE_POINTEE` and simplify code
From: Tamir Duberstein @ 2026-04-01 22:59 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-6-ojeda@kernel.org>
On Wed, 01 Apr 2026 13:45:12 +0200, Miguel Ojeda <ojeda@kernel.org> wrote:
> With the Rust version bump in place, the `RUSTC_HAS_COERCE_POINTEE`
> Kconfig (automatic) option is always true.
>
> Thus remove the option and simplify the code.
>
> In particular, this includes removing our use of the predecessor unstable
> features we used with Rust < 1.84.0 (`coerce_unsized`, `dispatch_from_dyn`
> and `unsize`).
>
> [...]
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
--
Tamir Duberstein <tamird@kernel.org>
^ permalink raw reply
* Re: [PATCH 04/33] rust: remove `RUSTC_HAS_SLICE_AS_FLATTENED` and simplify code
From: Tamir Duberstein @ 2026-04-01 22:59 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-5-ojeda@kernel.org>
On Wed, 01 Apr 2026 13:45:11 +0200, Miguel Ojeda <ojeda@kernel.org> wrote:
> With the Rust version bump in place, the `RUSTC_HAS_SLICE_AS_FLATTENED`
> Kconfig (automatic) option is always true.
>
> Thus remove the option and simplify the code.
>
> In particular, this includes removing the `slice` module which contained
> the temporary slice helpers, i.e. the `AsFlattened` extension trait and
> its `impl`s.
>
> [...]
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
--
Tamir Duberstein <tamird@kernel.org>
^ permalink raw reply
* Re: [PATCH 03/33] rust: simplify `RUSTC_VERSION` Kconfig conditions
From: Tamir Duberstein @ 2026-04-01 22:59 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-4-ojeda@kernel.org>
On Wed, 01 Apr 2026 13:45:10 +0200, Miguel Ojeda <ojeda@kernel.org> wrote:
> With the Rust version bump in place, several Kconfig conditions based on
> `RUSTC_VERSION` are always true.
>
> Thus simplify them.
>
> The minimum supported major LLVM version by our new Rust minimum version
> is now LLVM 18, instead of LLVM 16. However, there are no possible
> cleanups for `RUSTC_LLVM_VERSION`.
>
> [...]
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
--
Tamir Duberstein <tamird@kernel.org>
^ permalink raw reply
* Re: [PATCH 02/33] rust: bump Clippy's MSRV and clean `incompatible_msrv` allows
From: Tamir Duberstein @ 2026-04-01 22:59 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-3-ojeda@kernel.org>
On Wed, 01 Apr 2026 13:45:09 +0200, Miguel Ojeda <ojeda@kernel.org> wrote:
> Following the Rust compiler bump, we can now update Clippy's MSRV we
> set in the configuration, which will improve the diagnostics it generates.
>
> Thus do so and clean a few of the `allow`s that are not needed anymore.
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
--
Tamir Duberstein <tamird@kernel.org>
^ permalink raw reply
* Re: [PATCH 01/33] rust: bump Rust minimum supported version to 1.85.0 (Debian Trixie)
From: Tamir Duberstein @ 2026-04-01 22:59 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-2-ojeda@kernel.org>
On Wed, 01 Apr 2026 13:45:08 +0200, Miguel Ojeda <ojeda@kernel.org> 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).
>
> [...]
Acked-by: Tamir Duberstein <tamird@kernel.org>
--
Tamir Duberstein <tamird@kernel.org>
^ permalink raw reply
* Re: [PATCH RFC v4 10/44] KVM: guest_memfd: Add support for KVM_SET_MEMORY_ATTRIBUTES2
From: Ackerley Tng @ 2026-04-01 22:46 UTC (permalink / raw)
To: Michael Roth
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: <cqkyz4zxosmev6lnbasa32ed5jjfljrx3gr6plyjfhrtbysuwr@rg5noy6y6ayu>
Michael Roth <michael.roth@amd.com> writes:
> On Thu, Mar 26, 2026 at 03:24:19PM -0700, Ackerley Tng wrote:
>> For shared to private conversions, if refcounts on any of the folios
>> within the range are elevated, fail the conversion with -EAGAIN.
>>
>> At the point of shared to private conversion, all folios in range are
>> also unmapped. The filemap_invalidate_lock() is held, so no faulting
>> can occur. Hence, from that point on, only transient refcounts can be
>> taken on the folios associated with that guest_memfd.
>>
>> Hence, it is safe to do the conversion from shared to private.
>>
>> After conversion is complete, refcounts may become elevated, but that
>> is fine since users of transient refcounts don't actually access
>> memory.
>>
>> For private to shared conversions, there are no refcount checks, since
>> the guest is the only user of private pages, and guest_memfd will be the
>> only holder of refcounts on private pages.
>
> I think KVM_CAP_GUEST_MEMFD_MEMORY_ATTRIBUTES deserves some mention in
> the commit log.
>
Will update this in the next revision. Thanks!
>>
>>
>> [...snip...]
>>
>>
>> +Set attributes for a range of offsets within a guest_memfd to
>> +KVM_MEMORY_ATTRIBUTE_PRIVATE to limit the specified guest_memfd backed
>> +memory range for guest_use. Even if KVM_CAP_GUEST_MEMFD_MMAP is
>> +supported, after a successful call to set
>> +KVM_MEMORY_ATTRIBUTE_PRIVATE, the requested range will not be mappable
>> +into host userspace and will only be mappable by the guest.
>> +
>> +To allow the range to be mappable into host userspace again, call
>> +KVM_SET_MEMORY_ATTRIBUTES2 on the guest_memfd again with
>> +KVM_MEMORY_ATTRIBUTE_PRIVATE unset.
>> +
>> +If this ioctl returns -EAGAIN, the offset of the page with unexpected
>> +refcounts will be returned in `error_offset`. This can occur if there
>> +are transient refcounts on the pages, taken by other parts of the
>> +kernel.
>
> That's only true for the guest_memfd ioctl, for KVM ioctl these new
> fields and r/w behavior are basically ignored. So you might need to be
> clearer on which fields/behavior are specific to guest_memfd like in
> the preceeding paragraphs..
>
Yes, will update in the next revision, thanks!
> ..or maybe it's better to do the opposite and just have a blanket 'for
> now, all newly-described behavior pertains only to usage via a
> guest_memfd ioctl, and for KVM ioctls only the fields/behaviors common
> with KVM_SET_MEMORY_ATTRIBUTES are applicable.', since it doesn't seem
> like vm_memory_attributes=1 is long for this world and that's the only
> case where KVM memory attribute ioctls seem relevant.
>
> But then it makes me wonder, if we adopt the semantics I mentioned
> earlier and have KVM_CAP_GUEST_MEMFD_MEMORY_ATTRIBUTES advertise both
> the gmem ioctl support as well as the struct kvm_memory_attributes2
> support, if we should even advertise KVM_CAP_MEMORY_ATTRIBUTES2 at all
> as part of this series.
>
Read your other email as well, thanks for reviewing!
It makes sense, hope this captures what you suggested. In v5,
If vm_memory_attributes == 1:
(KVM_CAP_MEMORY_ATTRIBUTES2 will be removed (will return 0))
If vm_memory_attributes == 0 aka attributes are tracked by guest_memfd:
KVM_CAP_GUEST_MEMFD_MEMORY_ATTRIBUTES2 will return valid attributes
(KVM_CAP_MEMORY_ATTRIBUTES2 will be removed (will return 0))
So yup, KVM_CAP_MEMORY_ATTRIBUTES2 will not even be #defined at all.
>> +
>> +Userspace is expected to figure out how to remove all known refcounts
>> +on the shared pages, such as refcounts taken by get_user_pages(), and
>> +try the ioctl again. A possible source of these long term refcounts is
>> +if the guest_memfd memory was pinned in IOMMU page tables.
>
> One might read this to mean error_offset is used purely for the EAGAIN
> case, so it might be worth touching on the other cases as well.
>
Will update this in the next revision.
> -Mike
>
>>
>> [...snip...]
>>
^ permalink raw reply
* Re: [PATCH RFC v4 10/44] KVM: guest_memfd: Add support for KVM_SET_MEMORY_ATTRIBUTES2
From: Ackerley Tng @ 2026-04-01 22:38 UTC (permalink / raw)
To: Michael Roth
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: <2r4mmfiuisw26qymahnbh2oxqkkrywqev477kc4rlkcyx7tels@c7ple7kdgpo3>
Michael Roth <michael.roth@amd.com> writes:
>
> [...snip...]
>
>> static unsigned long kvm_get_vm_memory_attributes(struct kvm *kvm, gfn_t gfn)
>> {
>> @@ -2635,6 +2625,8 @@ static int kvm_vm_ioctl_set_mem_attributes(struct kvm *kvm,
>> return -EINVAL;
>> if (!PAGE_ALIGNED(attrs->address) || !PAGE_ALIGNED(attrs->size))
>> return -EINVAL;
>> + if (attrs->error_offset)
>> + return -EINVAL;
>> for (i = 0; i < ARRAY_SIZE(attrs->reserved); i++) {
>> if (attrs->reserved[i])
>> return -EINVAL;
>> @@ -4983,6 +4975,11 @@ static int kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg)
>> return 1;
>> case KVM_CAP_GUEST_MEMFD_FLAGS:
>> return kvm_gmem_get_supported_flags(kvm);
>> + case KVM_CAP_GUEST_MEMFD_MEMORY_ATTRIBUTES:
>> + if (vm_memory_attributes)
>> + return 0;
>> +
>> + return kvm_supported_mem_attributes(kvm);
>
> Based on the discussion from the PUCK call this morning,
Thanks for copying the discussion here, I'll start attending PUCK to
catch those discussions too :)
> it sounds like it
> would be a good idea to limit kvm_supported_mem_attributes() to only
> reporting KVM_MEMORY_ATTRIBUTE_PRIVATE if the underlying CoCo
> implementation has all the necessary enablement to support in-place
> conversion via guest_memfd. In the case of SNP, there is a
> documentation/parameter check in snp_launch_update() that needs to be
> relaxed in order for userspace to be able to pass in a NULL 'src'
> parameter (since, for in-place conversion, it would be initialized in place
> as shared memory prior to the call, since by the time kvm_gmem_poulate()
> it will have been set to private and therefore cannot be faulted in via
> GUP (and if it could, we'd be unecessarily copying the src back on top
> of itself since src/dst are the same).
Could this be a separate thing? If I'm understanding you correctly, it's
not strictly a requirement for snp_launch_update() to first support a
NULL 'src' parameter before this series lands.
Without this series, the startup procedure is to have memory set up in
non-guest_memfd shared memory, and then snp_launch_update()-ed into
guest_memfd private memory.
With this series, it is a little troublesome, but the startup procedure
can still set up memory in guest_memfd shared memory, then copy
everything out to some temporary memory, then set guest_memfd memory to
private, then snp_launch_update() the temporary memory into guest_memfd
private memory.
We would be unnecessarily copying the src (now in some temporary memory)
back onto itself. Can that be a separate patch series?
Btw, if snp_launch_update() is going to accept a NULL src parameter and
launch-update the src in-place:
+ Will userspace have to set that memory to private before calling launch
update?
+ If yes, then would we need some other mode of conversion that is
not ZERO and not quite PRESERVE (since PRESERVE is defined as that
the guest will see what the host wrote post-encryption, but it
sounds like launch update is doing the encryption)
+ Or should launch update be called when that memory is shared? Will
launch update then also set that memory to private in guest_memfd?
>
> So maybe there should be an arch hook to check a whitelist of VM types
> that support KVM_MEMORY_ATTRIBUTE_PRIVATE when vm_memory_attributes=0,
> and if we decide to enable it for SNP as part of this series you could
> include the 1-2 patches needed there, or I could enable the SNP support
> separately as a small series and I guess that would then become a prereq
> for the SNP self-tests?
>
> Not sure if additional enablement is needed for TDX or not before
> KVM_MEMORY_ATTRIBUTE_PRIVATE would be advertised, but similar
> considerations there.
>
> -Mike
>
>> #endif
>> default:
>> break;
>>
>> --
>> 2.53.0.1018.g2bb0e51243-goog
>>
^ permalink raw reply
* Re: [PATCH RFC v4 07/44] KVM: guest_memfd: Only prepare folios for private pages
From: Ackerley Tng @ 2026-04-01 21:43 UTC (permalink / raw)
To: Michael Roth
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: <s4dbqrv2c6yzt4nsflfarnggtl25xlz6mzg74tfeg3eskceno6@6l5hpfmcbju3>
Michael Roth <michael.roth@amd.com> writes:
> 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?
>
My bad, it was. I just force-pushed to github to synchronize them with
this patch series.
> 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.
>
Thanks for checking :)
> -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 5/5] types: Add standard __ob_trap and __ob_wrap scalar types
From: Kees Cook @ 2026-04-01 21:41 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Linus Torvalds, Justin Stitt, Miguel Ojeda, Nathan Chancellor,
Andrew Morton, Andy Shevchenko, Arnd Bergmann, Mark Rutland,
Matthew Wilcox (Oracle), Suren Baghdasaryan, Thomas Gleixner,
Finn Thain, Geert Uytterhoeven, Thomas Weißschuh, llvm,
Marco Elver, Jonathan Corbet, Nicolas Schier, Greg Kroah-Hartman,
linux-kernel, kasan-dev, linux-hardening, linux-doc, linux-kbuild
In-Reply-To: <20260401093820.GX3738786@noisy.programming.kicks-ass.net>
On Wed, Apr 01, 2026 at 11:38:20AM +0200, Peter Zijlstra wrote:
> On Tue, Mar 31, 2026 at 01:31:16PM -0700, Kees Cook wrote:
>
> > int func()
> > {
> > ...
> > u8 __ob_trap product = 5;
> > ...
> > product = a * b; // if store is truncated, goto __overflow
> > ...
> > return product;
> >
> > __overflow:
> > pr_info("%u\n", product); // shows "5"
> > return -1;
> > }
> >
> > (Isn't this just an implicit "try"?)
>
> So I like this implicit try with a default label, and mostly I expect
> this will be fine.
>
> But as Linus already mentioned, sometimes you might want more. Could we
> perhaps also have an explicit version, something along the lines of:
>
> int func()
> {
> int __ob_trap size;
>
> size = try(count * flex_size, __mul_overflow);
> size = try(size + base_size, __add_overflow);
>
> obj = kzalloc(size,...);
>
> }
>
> where we have something like:
>
> #define try(stmt, _label) ({ \
> __label __overflow; \
> if (0) { \
> __overflow: \
> goto _label; \
> } \
> stmt; })
>
> That is, have the overflow trapped and confined in the
> statement-expression by using the overflow label as a local label and
> use this little trampoline to re-direct to a custom label.
Yeah, that should work, and gives us a nice way to create handler
overrides. We've have to make sure the "locally defined" labels (with
__label__) and __ob_trap worked together sanely.
--
Kees Cook
^ permalink raw reply
* Re: [PATCH RFC v4 10/44] KVM: guest_memfd: Add support for KVM_SET_MEMORY_ATTRIBUTES2
From: Sean Christopherson @ 2026-04-01 21:12 UTC (permalink / raw)
To: Michael Roth
Cc: Ackerley Tng, 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,
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: <2r4mmfiuisw26qymahnbh2oxqkkrywqev477kc4rlkcyx7tels@c7ple7kdgpo3>
On Wed, Apr 01, 2026, Michael Roth wrote:
> On Thu, Mar 26, 2026 at 03:24:19PM -0700, Ackerley Tng wrote:
> > #ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> > static unsigned long kvm_get_vm_memory_attributes(struct kvm *kvm, gfn_t gfn)
> > {
> > @@ -2635,6 +2625,8 @@ static int kvm_vm_ioctl_set_mem_attributes(struct kvm *kvm,
> > return -EINVAL;
> > if (!PAGE_ALIGNED(attrs->address) || !PAGE_ALIGNED(attrs->size))
> > return -EINVAL;
> > + if (attrs->error_offset)
> > + return -EINVAL;
> > for (i = 0; i < ARRAY_SIZE(attrs->reserved); i++) {
> > if (attrs->reserved[i])
> > return -EINVAL;
> > @@ -4983,6 +4975,11 @@ static int kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg)
> > return 1;
> > case KVM_CAP_GUEST_MEMFD_FLAGS:
> > return kvm_gmem_get_supported_flags(kvm);
> > + case KVM_CAP_GUEST_MEMFD_MEMORY_ATTRIBUTES:
> > + if (vm_memory_attributes)
> > + return 0;
> > +
> > + return kvm_supported_mem_attributes(kvm);
>
> Based on the discussion from the PUCK call this morning, it sounds like it
> would be a good idea to limit kvm_supported_mem_attributes() to only
> reporting KVM_MEMORY_ATTRIBUTE_PRIVATE if the underlying CoCo
> implementation has all the necessary enablement to support in-place
> conversion via guest_memfd. In the case of SNP, there is a
> documentation/parameter check in snp_launch_update() that needs to be
> relaxed in order for userspace to be able to pass in a NULL 'src'
> parameter (since, for in-place conversion, it would be initialized in place
> as shared memory prior to the call, since by the time kvm_gmem_poulate()
> it will have been set to private and therefore cannot be faulted in via
> GUP (and if it could, we'd be unecessarily copying the src back on top
> of itself since src/dst are the same).
>
> So maybe there should be an arch hook to check a whitelist of VM types
> that support KVM_MEMORY_ATTRIBUTE_PRIVATE when vm_memory_attributes=0,
> and if we decide to enable it for SNP as part of this series you could
> include the 1-2 patches needed there, or I could enable the SNP support
> separately as a small series and I guess that would then become a prereq
> for the SNP self-tests?
If it's trivial-ish, my preference would be to include SNP as part of this series,
_before_ KVM_CAP_GUEST_MEMFD_MEMORY_ATTRIBUTES is exposed to userspace. I think
that would avoid the need for pivoting on the VM type? I.e. don't advertise
support until all VM types play nice.
> Not sure if additional enablement is needed for TDX or not before
> KVM_MEMORY_ATTRIBUTE_PRIVATE would be advertised, but similar
> considerations there.
^ permalink raw reply
* Re: [PATCH RFC v4 25/44] KVM: selftests: Test basic single-page conversion flow
From: Sean Christopherson @ 2026-04-01 21:08 UTC (permalink / raw)
To: Ackerley Tng
Cc: aik, andrew.jones, binbin.wu, brauner, chao.p.peng, david,
ira.weiny, jmattson, jroedel, jthoughton, michael.roth, 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,
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: <CAEvNRgE6Tn81Yddgbjqs-gs491NzpppjbDHKzpmdPCxgSPeUPQ@mail.gmail.com>
On Tue, Mar 31, 2026, Ackerley Tng wrote:
> Ackerley Tng <ackerleytng@google.com> writes:
Please trim your replies (even more, since you did trim a little).
> > +static void run_guest_do_rmw(struct kvm_vcpu *vcpu, loff_t pgoff,
> > + char expected_val, char write_val)
> > +{
> > + struct ucall uc;
> > + int r;
> > +
> > + guest_data.mem = (void *)GUEST_MEMFD_SHARING_TEST_GVA + pgoff * page_size;
> > + guest_data.expected_val = expected_val;
> > + guest_data.write_val = write_val;
> > + sync_global_to_guest(vcpu->vm, guest_data);
> > +
> > + do {
> > + r = __vcpu_run(vcpu);
> > + } while (r == -1 && errno == EINTR);
> > +
> > + TEST_ASSERT_EQ(r, 0);
>
> TEST_ASSERT_EQ() ends up calling exit() on failures, which skips
> FIXTURE_TEARDOWN().
>
> Other than the explicit assertions not working with the
> kselftest_harness, kvm selftest library functions like vm_mem_add() also
> call TEST_ASSERT, which doesn't play nice with kselftest_harness.
>
> Any suggestions for this? Should we use the kselftest framework with
> these tests?
>
> (I ran into this issue while trying to test something else, where I
> needed FIXTURE_TEARDOWN() to clean up system state.)
>
> Or is it "okay" in this case since FIXTURE_TEARDOWN() only cleans up
> stuff that would happen if the program exits anyway?
Can you see if any of the ideas in https://lore.kernel.org/all/ZjUwqEXPA5QVItyX@google.com
would help? Converting more tests to TAP+FIXTURE is still on my wish list, I've
just never been able to carve out cycles to see it through.
^ permalink raw reply
* Re: [PATCH RFC v4 08/44] KVM: Introduce KVM_SET_MEMORY_ATTRIBUTES2
From: Sean Christopherson @ 2026-04-01 21:04 UTC (permalink / raw)
To: Michael Roth
Cc: Ackerley Tng, 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,
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: <cxmtst7txfodp6lo4ipue3trohx2ge7nkagkfzfixfdnlf5qlo@e3jw3tmbe272>
On Tue, Mar 31, 2026, Michael Roth wrote:
> On Thu, Mar 26, 2026 at 03:24:17PM -0700, Ackerley Tng wrote:
> > Introduce a "version 2" of KVM_SET_MEMORY_ATTRIBUTES to support returning
> > information back to userspace.
>
> Hi Ackerley,
>
> Not trying to bikeshed below, but I'm working on getting related QEMU
> patches cleaned up to post soon and was working through some of the new
> uAPI bits, and plumbing some of these capabilities in seems a little
> awkward in a couple places so wondering if we should revisit how some of
> this API is defined...
>
> >
> > This new ioctl and structure will, in a later patch, be shared as a
> > guest_memfd ioctl, where the padding in the new kvm_memory_attributes2
> > structure will be for writing the response from the guest_memfd ioctl to
> > userspace.
> >
> > A new ioctl is necessary for these reasons:
> >
> > 1. KVM_SET_MEMORY_ATTRIBUTES is currently a write-only ioctl and does not
> > allow userspace to read fields. There's nothing in code (yet?) that
> > validates this, but using _IOWR for consistency would be prudent.
> >
> > 2. KVM_SET_MEMORY_ATTRIBUTES, when used as a guest_memfd ioctl, will need
> > an additional field to provide userspace with more error details.
> >
> > Alternatively, a completely new ioctl could be defined, unrelated to
> > KVM_SET_MEMORY_ATTRIBUTES, but using the same ioctl number and struct for
> > the vm and guest_memfd ioctls streamlines the interface for userspace. In
> > addition, any memory attributes, implemented on the vm or guest_memfd
> > ioctl, can be easily shared with the other.
> >
> > Add KVM_CAP_MEMORY_ATTRIBUTES2 to indicate that struct
> > kvm_memory_attributes2 exists and can be used either with
> > KVM_SET_MEMORY_ATTRIBUTES2 via the vm or guest_memfd ioctl.
>
> The guest_memfd support for the KVM_SET_MEMORY_ATTRIBUTES2 ioctl isn't
> added until patch #10, and to scan for it you sort of need to infer it
> via KVM_CAP_GUEST_MEMFD_MEMORY_ATTRIBUTES reporting non-zero (i.e.
> KVM_MEMORY_ATTRIBUTE_PRIVATE), so it's confusing to state that
> KVM_CAP_MEMORY_ATTRIBUTES2 means you can use the struct via a guest_memfd
> ioctl.
>
> I think the above is trying to simply say that the corresponding struct
> exists, and remain agnostic about how it can be used. But if that were
> the case, there would be no way to know when KVM_SET_MEMORY_ATTRIBUTES2 is
> available in the first place, so in the case of KVM ioctls at least,
> KVM_CAP_MEMORY_ATTRIBUTES2 is advertising both the struct and the ioctl,
> whereas for guest_memfd it's only advertising the struct and not saying
> anything about whether a similar gmem ioctl is available to use it.
+1 to everything Mike said.
> Instead, maybe they should both have the same semantics:
>
> KVM_CAP_MEMORY_ATTRIBUTES2: *SET_ATTRIBUTES* ioctl exists for KVM that utilizes
> struct kvm_memory_attributes2
>
> KVM_CAP_GUEST_MEMFD_MEMORY_ATTRIBUTES: *SET_ATTRIBUTES* ioctl exists for
> guest_memfd that utilizes struct kvm_memory_attributes2
>
> In which case you would leave out any mention of guest_memfd here as far as
> the documentation does, and then in patch #10 you could modify it to be
> something like:
>
> 4.145 KVM_SET_MEMORY_ATTRIBUTES2
> ---------------------------------
>
> -:Capability: KVM_CAP_MEMORY_ATTRIBUTES2
> +:Capability: KVM_CAP_MEMORY_ATTRIBUTES2, KVM_GUEST_MEMFD_CAP_MEMORY_ATTRIBUTES
> -:Architectures: x86
> +:Architectures: all
> -:Type: vm ioctl
> +:Type: vm, guest_memfd ioctl
> :Parameters: struct kvm_memory_attributes2 (in/out)
> :Returns: 0 on success, <0 on error
As discussed at PUCK, I think we should omit KVM_CAP_MEMORY_ATTRIBUTES2 and
vm-scoped support entirely until it's needed (which may be never).
> and *then* add in your mentions of how the usage/fields differ for
> guest_memfd/KVM_GUEST_MEMFD_CAP_MEMORY_ATTRIBUTES case vs. KVM ioctls.
>
> This avoids needing to issue 2 checks for the guest_memfd variant vs. 1
> for KVM, but more importantly avoids subtle differences in how these
> similarly-named capabilities are used/documented that might cause
> unecessary confusion.
^ permalink raw reply
* Re: [PATCH 3/5] compiler_attributes: Add overflow_behavior macros __ob_trap and __ob_wrap
From: Kees Cook @ 2026-04-01 20:55 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Justin Stitt, Miguel Ojeda, Marco Elver, Andrey Konovalov,
Andrey Ryabinin, Jonathan Corbet, Shuah Khan, Miguel Ojeda,
Nathan Chancellor, kasan-dev, linux-doc, llvm, Linus Torvalds,
Nicolas Schier, Arnd Bergmann, Greg Kroah-Hartman, Andrew Morton,
linux-kernel, linux-hardening, linux-kbuild
In-Reply-To: <20260401203053.GC3254421@noisy.programming.kicks-ass.net>
On Wed, Apr 01, 2026 at 10:30:53PM +0200, Peter Zijlstra wrote:
> On Wed, Apr 01, 2026 at 01:21:17PM -0700, Kees Cook wrote:
> > On Wed, Apr 01, 2026 at 11:08:15AM +0200, Peter Zijlstra wrote:
> > > On Tue, Mar 31, 2026 at 12:52:10PM -0700, Kees Cook wrote:
> > >
> > > > I think for this series, __ob_trap/__ob_wrap is what should be used.
> > > >
> > > > And for other folks, the background here is that we originally wanted
> > > > to use macros for "__trap" and "__wrap", but the powerpc C compiler
> > > > (both Clang and GCC) have a builtin macro named "__trap" already. So
> > > > I switched to just using the Clang-native type qualifier. We can use
> > > > the attribute style too, but there was a lot of confusion during the
> > > > Clang development phases where people kept forgetting this was a type
> > > > qualifier, not an attribute (i.e. the attribute is an internal alias
> > > > for the qualifier, and the qualifier is a new type).
> > >
> > > Since you mention qualifiers...
> > >
> > > What is the result of __typeof_unqual__(int __ob_trap) ?
> >
> > Hmm, it seems like "const" doesn't get peeled off. That can be fixed, if
> > that's needed?
> >
> > 'typeof_unqual(int)' (aka 'int')
> > 'typeof_unqual(__ob_trap int)' (aka '__ob_trap int')
> > 'typeof_unqual(const int)' (aka 'int')
> > 'typeof_unqual(__ob_trap const int)' (aka '__ob_trap const int')
>
> So how can something be called a qualifier if unqual doesn't strip it?
>
> (We might already have had this discussion, but I can't find the answer
> in the LLVM documentation page and didn't search our previous
> correspondence on this).
I'll let Justin answer this correctly, but I suspect I'm using the wrong
name for things. I think I should have said "keyword"? The mechanism
produces a distinct type, so it's not actually a "qualifier", but the
intent is that they are distinct types (this came from a long long
discussion with the LLVM devs, etc), but that they have implicit casts
to the non-obt scalars, but Justin knows more on this.
--
Kees Cook
^ permalink raw reply
* Re: [PATCH 5/5] types: Add standard __ob_trap and __ob_wrap scalar types
From: Kees Cook @ 2026-04-01 20:52 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Linus Torvalds, Justin Stitt, Miguel Ojeda, Nathan Chancellor,
Andrew Morton, Andy Shevchenko, Arnd Bergmann, Mark Rutland,
Matthew Wilcox (Oracle), Suren Baghdasaryan, Thomas Gleixner,
Finn Thain, Geert Uytterhoeven, Thomas Weißschuh, llvm,
Marco Elver, Jonathan Corbet, Nicolas Schier, Greg Kroah-Hartman,
linux-kernel, kasan-dev, linux-hardening, linux-doc, linux-kbuild
In-Reply-To: <20260401083137.GT3738786@noisy.programming.kicks-ass.net>
On Wed, Apr 01, 2026 at 10:31:37AM +0200, Peter Zijlstra wrote:
> On Tue, Mar 31, 2026 at 01:31:16PM -0700, Kees Cook wrote:
>
> (still slowly digesting the thread)
>
> > Yeah, as you mentioned earlier, I'd agree that nesting is rarely
> > useful. The only thing I'd want to be careful about is ordering/scope. I
> > *think* it would just operate as a "goto" and things like the cleanup.h
> > handlers wouldn't be involved: they operate when a scope is crossed
> > like before. And I think the overflow result wouldn't be represented
> > anywhere. i.e. the wrapped/truncated value wouldn't be stored:
> >
> > int func()
> > {
> > ...
> > u8 __ob_trap product = 5;
> > ...
> > product = a * b; // if store is truncated, goto __overflow
> > ...
> > return product;
> >
> > __overflow:
> > pr_info("%u\n", product); // shows "5"
> > return -1;
> > }
>
> Note that there is a 'fun' problem with this in combination with
> cleanup.h.
>
> Something like:
>
> int func()
> {
> u8 __ob_trap prod = 0;
>
> scoped_guard (mutex, &my_lock) {
> prod = a * b;
> }
>
> return prod;
>
> __overflow:
> // whatever
> return -1;
> }
>
> is fine. *HOWEVER*, something like:
>
> int func()
> {
> int __ob_trap size = base + count * extra;
> int err;
>
> struct my_obj *obj __cleanup(kfree) = kzalloc(size, GFP_KERNEL);
>
> err = my_obj_init(obj);
> if (err)
> return ERR_PTR(err);
>
> return_ptr(obj);
>
> __overflow:
> // what now..
> return NULL;
> }
>
> is most terribly broken. Specifically, the goto will jump into the scope
> of obj -- and that is not allowed.
Right, this has been my primary concern about having an implicit "goto"
sprinkled basically anywhere into the code flow. However, it does seem
that initialization checking is aware of the problem:
void func(void)
{
unsigned long __ob_trap value = ({ goto weird; 256; });
size_t outcome = 99;
outcome = get_outcome();
pr_info("outcome: %zu\n", outcome);
return;
weird:
pr_info("value: %lu\n", value);
pr_info("outcome: %zu\n", outcome);
}
../drivers/misc/lkdtm/bugs.c:1059:35: warning: variable 'outcome' is uninitialized when used here [-Wuninitialized]
1059 | pr_info("outcome: %zu\n", outcome);
| ^~~~~~~
../drivers/misc/lkdtm/bugs.c:1021:2: note: variable 'outcome' is declared here
1021 | size_t outcome = 99;
| ^
../drivers/misc/lkdtm/bugs.c:1058:33: warning: variable 'value' is uninitialized when used here [-Wuninitialized]
1058 | pr_info("value: %lu\n", value);
| ^~~~~
../drivers/misc/lkdtm/bugs.c:1020:2: note: variable 'value' is declared here
1020 | unsigned long __ob_trap value = ({ goto weird; 256; });
| ^
But most importantly, if I add a cleanup after it, it gets rejected:
unsigned long __ob_trap value = ({ goto weird; 256; });
size_t outcome = 99;
u8 *obj __cleanup(kfree) = kzalloc(33, GFP_KERNEL);
...
../drivers/misc/lkdtm/bugs.c:1021:37: error: cannot jump from this goto statement to its label
1021 | unsigned long __ob_trap value = ({ goto weird; 256; });
| ^
../drivers/misc/lkdtm/bugs.c:1023:6: note: jump bypasses initialization of variable with __attribute__((cleanup))
1023 | u8 *obj __cleanup(kfree) = kzalloc(33, GFP_KERNEL);
| ^
(Though I would note that GCC does _not_ refuse the jump when there is a
cleanup; it only see the other two uninitialized values.)
So that makes it not totally broken, but it does make it a bit fragile.
Another concern I have is dealing with older compilers and how to
"hide" the label and its code. e.g. if I remove the "goto" from above:
../drivers/misc/lkdtm/bugs.c:1060:1: warning: label 'weird' defined but not used [-Wunused-label]
1060 | weird:
| ^~~~~
Oddly, the unreachable code isn't a problem, so we could just wrap the
label is some macro like:
#define force_label(x) if (0) goto x; x
force_label(weird):
pr_info("value: %lu\n", value);
pr_info("outcome: %zu\n", outcome);
--
Kees Cook
^ permalink raw reply
* Re: [PATCH 3/5] compiler_attributes: Add overflow_behavior macros __ob_trap and __ob_wrap
From: Peter Zijlstra @ 2026-04-01 20:30 UTC (permalink / raw)
To: Kees Cook
Cc: Justin Stitt, Miguel Ojeda, Marco Elver, Andrey Konovalov,
Andrey Ryabinin, Jonathan Corbet, Shuah Khan, Miguel Ojeda,
Nathan Chancellor, kasan-dev, linux-doc, llvm, Linus Torvalds,
Nicolas Schier, Arnd Bergmann, Greg Kroah-Hartman, Andrew Morton,
linux-kernel, linux-hardening, linux-kbuild
In-Reply-To: <202604011313.AD471BC8@keescook>
On Wed, Apr 01, 2026 at 01:21:17PM -0700, Kees Cook wrote:
> On Wed, Apr 01, 2026 at 11:08:15AM +0200, Peter Zijlstra wrote:
> > On Tue, Mar 31, 2026 at 12:52:10PM -0700, Kees Cook wrote:
> >
> > > I think for this series, __ob_trap/__ob_wrap is what should be used.
> > >
> > > And for other folks, the background here is that we originally wanted
> > > to use macros for "__trap" and "__wrap", but the powerpc C compiler
> > > (both Clang and GCC) have a builtin macro named "__trap" already. So
> > > I switched to just using the Clang-native type qualifier. We can use
> > > the attribute style too, but there was a lot of confusion during the
> > > Clang development phases where people kept forgetting this was a type
> > > qualifier, not an attribute (i.e. the attribute is an internal alias
> > > for the qualifier, and the qualifier is a new type).
> >
> > Since you mention qualifiers...
> >
> > What is the result of __typeof_unqual__(int __ob_trap) ?
>
> Hmm, it seems like "const" doesn't get peeled off. That can be fixed, if
> that's needed?
>
> 'typeof_unqual(int)' (aka 'int')
> 'typeof_unqual(__ob_trap int)' (aka '__ob_trap int')
> 'typeof_unqual(const int)' (aka 'int')
> 'typeof_unqual(__ob_trap const int)' (aka '__ob_trap const int')
So how can something be called a qualifier if unqual doesn't strip it?
(We might already have had this discussion, but I can't find the answer
in the LLVM documentation page and didn't search our previous
correspondence on this).
^ permalink raw reply
* Re: [PATCH 5/5] types: Add standard __ob_trap and __ob_wrap scalar types
From: Kees Cook @ 2026-04-01 20:23 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Linus Torvalds, Justin Stitt, Miguel Ojeda, Nathan Chancellor,
Andrew Morton, Andy Shevchenko, Arnd Bergmann, Mark Rutland,
Matthew Wilcox (Oracle), Suren Baghdasaryan, Thomas Gleixner,
Finn Thain, Geert Uytterhoeven, Thomas Weißschuh, llvm,
Marco Elver, Jonathan Corbet, Nicolas Schier, Greg Kroah-Hartman,
linux-kernel, kasan-dev, linux-hardening, linux-doc, linux-kbuild
In-Reply-To: <20260401085706.GU3738786@noisy.programming.kicks-ass.net>
On Wed, Apr 01, 2026 at 10:57:06AM +0200, Peter Zijlstra wrote:
> On Tue, Mar 31, 2026 at 01:31:16PM -0700, Kees Cook wrote:
>
> > int func()
> > {
> > ...
> > u8 __ob_trap product = 5;
> > ...
> > product = a * b; // if store is truncated, goto __overflow
> > ...
> > return product;
> >
> > __overflow:
> > pr_info("%u\n", product); // shows "5"
>
> I'm confused by this 'product is still 5' thing. It seems to me that
> making this happen will, in general, require more instructions/registers
> than allowing the old value to be clobbered and have product be the
> truncated result of whatever overflow.
Yeah, that's fair. That's what happens to "out" already with the existing
check_{op}_overflow(a, b, &out) builtins, and what happens right now
with the "while (var--)" exception (var will wrap even as an __ob_trap).
--
Kees Cook
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox