Received-SPF: pass (google.com: domain of linux-kernel+bounces-131739-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240401185451.6897208962d3fc47a12ffb5a@otheo.eu>
 <20240401185712.a80deeb2fddeded0ad42cc04@otheo.eu> <8ee463af-fdbf-4514-bb6e-bf2fd61fbc06@intel.com>
 <20240402192314.a9b4e05637444314f47557e4@otheo.eu> <d7e89d23-b692-4e70-baae-5df5b3984620@intel.com>
 <Zg0L/OfuQtVgFSsG@gmail.com> <CAMzpN2iK0+okEKnX_EgfmdLSg9Gze_BVO4fEG3TBuzwD-yj8bA@mail.gmail.com>
 <Zg5dRkSncIeHsP0H@gmail.com>
In-Reply-To: <Zg5dRkSncIeHsP0H@gmail.com>
From: Brian Gerst <brgerst@gmail.com>
Date: Thu, 4 Apr 2024 11:36:58 -0400
Message-ID: <CAMzpN2hcZNewSmHn77Y-WAZjR-Pir=31dkgRHOzP+=kEa8_LdQ@mail.gmail.com>
Subject: Re: [PATCH 1/1] x86/mm/pae: Align up pteval_t, pmdval_t and pudval_t
 to avoid split locks
To: Ingo Molnar <mingo@kernel.org>
Cc: Dave Hansen <dave.hansen@intel.com>, Javier Pello <devel@otheo.eu>, linux-kernel@vger.kernel.org, 
	x86@kernel.org, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, 
	Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, 
	"H. Peter Anvin" <hpa@zytor.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Apr 4, 2024 at 3:56=E2=80=AFAM Ingo Molnar <mingo@kernel.org> wrote=
:
>
>
> * Brian Gerst <brgerst@gmail.com> wrote:
>
> > > > It's not a technical reason.  It's a practical one: I don't want
> > > > to spend time reviewing the fixes and dealing with the fallout
> > > > and regressions that the fixes might cause.
> > >
> > > Yeah, so it's an indirect technical argument: fixes *with
> > > tradeoffs* like this one have a future maintenance & robustness
> > > cost. Fixes without tradeoffs are fine of course.
> >
> > What tradeoffs are there with this patch?  This would not affect the
> > page tables, since those are already properly aligned.  Forcing
> > alignment of stack variables is only a problem if it tickles a
> > compiler bug.
>
> It creates extra constraints on stack layout that wasn't there before,
> so it can only be an invariant if the compiler can reorder variables,
> or make the stack layout worse (introducing more holes).

For the record, stack alignments are not rare.

objdump -dr vmlinux | grep "and.*,%.sp$" | wc -l

64-bit defconfig: 646
32-bit defconfig: 449


Brian Gerst