lkml.org 
[lkml]   [2022]   [May]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCHv5 08/12] x86/mm: Provide helpers for unaccepted memory
On Wed, May 04, 2022 at 01:12:06PM +0200, Borislav Petkov wrote:
> On Mon, Apr 25, 2022 at 06:39:30AM +0300, Kirill A. Shutemov wrote:
> > + unaccepted_memory = __va(boot_params.unaccepted_memory);
> > + range_start = start / PMD_SIZE;
> > +
> > + spin_lock_irqsave(&unaccepted_memory_lock, flags);
> > + for_each_set_bitrange_from(range_start, range_end, unaccepted_memory,
> > + DIV_ROUND_UP(end, PMD_SIZE)) {
> > + unsigned long len = range_end - range_start;
> > +
> > + /* Platform-specific memory-acceptance call goes here */
> > + panic("Cannot accept memory");
>
> Yeah, no, WARN_ON_ONCE() pls.

Failure to accept the memory is fatal. Why pretend it is not?

For TDX it will result in a crash on the first access. Prolonging the
suffering just make it harder to understand what happened.

> > + unsigned long flags;
> > + bool ret = false;
> > +
> > + spin_lock_irqsave(&unaccepted_memory_lock, flags);
> > + while (start < end) {
> > + if (test_bit(start / PMD_SIZE, unaccepted_memory)) {
> > + ret = true;
>
> Wait, what?
>
> That thing is lying: it'll return true for *some* PMD which is accepted
> but not the whole range of [start, end].

That's true. Note also that the check is inherently racy. Other CPU can
get the range or subrange accepted just after spin_unlock().

The check indicates that accept_memory() has to be called on the range
before first access.

Do you have problem with a name? Maybe has_unaccepted_memory()?

--
Kirill A. Shutemov

\
 
 \ /
  Last update: 2022-05-06 18:14    [W:0.085 / U:0.372 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site