[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7045d1666ac5722820a43fffa7f2e6fb3c2eb485.camel@surriel.com>
Date: Mon, 13 Jan 2025 16:10:41 -0500
From: Rik van Riel <riel@...riel.com>
To: Tom Lendacky <thomas.lendacky@....com>, x86@...nel.org
Cc: linux-kernel@...r.kernel.org, bp@...en8.de, peterz@...radead.org,
dave.hansen@...ux.intel.com, zhengqi.arch@...edance.com,
nadav.amit@...il.com, kernel-team@...a.com, linux-mm@...ck.org,
akpm@...ux-foundation.org, jannh@...gle.com
Subject: Re: [PATCH v4 05/12] x86/mm: add INVLPGB support code
On Mon, 2025-01-13 at 08:21 -0600, Tom Lendacky wrote:
> On 1/12/25 09:53, Rik van Riel wrote:
> >
> > +static inline void __invlpgb(unsigned long asid, unsigned long
> > pcid, unsigned long addr,
> > + int extra_count, bool pmd_stride,
> > unsigned long flags)
> > +{
> > + u32 edx = (pcid << 16) | asid;
> > + u32 ecx = (pmd_stride << 31);
> > + u64 rax = addr | flags;
> > +
> > + /* Protect against negative numbers. */
> > + extra_count = max(extra_count, 0);
> > + ecx |= extra_count;
>
> A bad ECX value (ECX[15:0] > invlpgb_count_max) will result in a #GP,
> is
> that ok?
The calling code ensures we do not call this code
with more than invlpgb_count_max pages at a time.
Given the choice between "a bug in the calling code
crashes the kernel" and "a bug in the calling code
results in a missed TLB flush", I'm guessing the
crash is probably better.
--
All Rights Reversed.
Powered by blists - more mailing lists