Received-SPF: pass (google.com: domain of linux-kernel+bounces-45502-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
References: <20231215194828.2611213-1-mmaurer@google.com> <CANiq72musVZbNW5MuhrRJEmA8G_D3D7Ms0pTYu16WrqhFx2pXg@mail.gmail.com>
 <f17ce61b-7f4f-4851-aa23-b8489686b840@intel.com>
In-Reply-To: <f17ce61b-7f4f-4851-aa23-b8489686b840@intel.com>
From: Matthew Maurer <mmaurer@google.com>
Date: Tue, 30 Jan 2024 15:54:25 -0800
Message-ID: <CAGSQo01SLbT2rb8CnXx1hk-17-HHQzVNBqszAa4qMbpa-BbQfQ@mail.gmail.com>
Subject: Re: [PATCH] x86: rust: Disable entry padding with Rust
To: Dave Hansen <dave.hansen@intel.com>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>, Thomas Gleixner <tglx@linutronix.de>, 
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, 
	Miguel Ojeda <ojeda@kernel.org>, Alex Gaynor <alex.gaynor@gmail.com>, 
	Wedson Almeida Filho <wedsonaf@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>, Boqun Feng <boqun.feng@gmail.com>, 
	Gary Guo <gary@garyguo.net>, =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= <bjorn3_gh@protonmail.com>, 
	Benno Lossin <benno.lossin@proton.me>, Andreas Hindborg <a.hindborg@samsung.com>, 
	Alice Ryhl <aliceryhl@google.com>, linux-kernel@vger.kernel.org, 
	rust-for-linux@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 30, 2024 at 3:46=E2=80=AFPM Dave Hansen <dave.hansen@intel.com>=
 wrote:
>
> On 1/28/24 09:48, Miguel Ojeda wrote:
> > On Fri, Dec 15, 2023 at 8:48=E2=80=AFPM Matthew Maurer <mmaurer@google.=
com> wrote:
> >> rustc-1.73.0 used by Linux does not support entry padding. Mark entry
> >> padding support as explicitly incompatible with Rust.
> > We are now at 1.74.1 and moving to 1.75.0 for the next cycle, which
> > does not support it yet, in case whoever applies the patch wants to
> > update it in the description.
> >
> >> Signed-off-by: Matthew Maurer <mmaurer@google.com>
> > x86: are you picking this one up through your tree? Thanks!
>
> Do we need a 'rust-option' equivalent of 'cc-option', like:
>
> config CC_HAS_ENTRY_PADDING
>         def_bool $(cc-option,-fpatchable-function-entry=3D16,16)
>
> That way this doesn't become a temporary option at all.  We just do:
>
> config RUST_HAS_ENTRY_PADDING
>         def_bool $(rust-option,-fpatchable-function-entry) # or whatever
>
> and:
>
> config HAVE_ENTRY_PADDING
>         def_bool CC_HAS_ENTRY_PADDING
>         depends on !RUST || RUST_HAS_ENTRY_PADDING
>
> and never have to touch this again.
I agree that we'll want something like that in the long term (my
original version of this patch did use something like `rs-option`),
but in this particular case the main thing still being bikeshedded in
the RFC[1] *is* how the option will be specified to the Rust compiler.

We could assume the current form of the RFC which is nearly signed off
on is what will happen, in which case we could add `rs-option` and
test for `-C patchable-function-entry=3Dtotal_nops=3D16,prefix_nops=3D16`,
but there's a chance we could still have to update it until the flag
form is finalized.

Link: https://github.com/rust-lang/rfcs/pull/3543 [1]