Re: [PATCHv5 08/12] x86/mm: Provide helpers for unaccepted memory

["Kirill A. Shutemov" <kirill@shutemov.name>]

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