Messages in this thread | | | Date | Fri, 6 May 2022 19:13:59 +0300 | From | "Kirill A. Shutemov" <> | Subject | Re: [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
| |