Received-SPF: pass (google.com: domain of linux-kernel+bounces-131059-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Sender: Ingo Molnar <mingo.kernel.org@gmail.com>
Date: Thu, 4 Apr 2024 09:56:54 +0200
From: Ingo Molnar <mingo@kernel.org>
To: Brian Gerst <brgerst@gmail.com>
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>
Subject: Re: [PATCH 1/1] x86/mm/pae: Align up pteval_t, pmdval_t and pudval_t
 to avoid split locks
Message-ID: <Zg5dRkSncIeHsP0H@gmail.com>
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>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAMzpN2iK0+okEKnX_EgfmdLSg9Gze_BVO4fEG3TBuzwD-yj8bA@mail.gmail.com>


* 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).

Thanks,

	Ingo