Re: Kernel crash while doing chroot'ed grub2-mkconfig on qemu-emulated Nehalem CPU since late November 6.13 snapshot

[Mike Rapoport <rppt@kernel.org>]

On Fri, Jan 10, 2025 at 09:28:01AM -0800, Adam Williamson wrote:
> On Fri, 2025-01-10 at 11:57 +0200, Mike Rapoport wrote:
> > Hi Adam,
> > 
> > On Thu, Jan 02, 2025 at 12:16:03PM -0800, Adam Williamson wrote:
> > > 
> > > Update on this: over the holidays, I bisected it to
> > > 5185e7f9f3bd754ab60680814afd714e2673ef88 . A kernel with that commit
> > > reverted does not hit the bug.
> > > 
> > > I also did some testing with various CPU model configurations. I think
> > > this actually isn't to do with Nehalem per se, but "virtual machines
> > > where the CPU configuration does not exactly match the host", or
> > > something like that.
> > > 
> > > I tried a bunch of qemu CPU model settings - nehalem, sandybridge,
> > > haswell, Skylake-Client and Cascadelake-Server - and got failures with
> > > all of them, but when I set the model to "host", all tests passed.
> > > 
> > > The tests get farmed out to a cluster of systems which have different
> > > CPUs - one is Broadwell, one is Skylake, one is Cascade Lake - so I
> > > think when I set the model to anything specific, it will match the host
> > > CPU on some or none of those systems, but never *all* of them, so the
> > > bug will always show up.
> > > 
> > > I have emailed the author and reviewer of
> > > 5185e7f9f3bd754ab60680814afd714e2673ef88 (also CCed on this mail) but
> > > have not heard back from them yet. I've sunk over a week into this bug
> > > at this point so it'd be great if someone could look at it. It's not
> > > the biggest regression in the world, but it is a bit awkward for our
> > > automated testing (I'll have to fiddle around to try and set CPU model
> > > 'host' for the most badly-affected tests but ensure we still have
> > > enough tests with 'nehalem' to confirm our baseline isn't moved).
> > > 
> > > Thanks, and happy new year!
> > 
> > Can you please test this patch:
> > 
> > diff --git a/mm/execmem.c b/mm/execmem.c
> > index be6b234c032e..0090a6f422aa 100644
> > --- a/mm/execmem.c
> > +++ b/mm/execmem.c
> > @@ -266,6 +266,7 @@ static int execmem_cache_populate(struct execmem_range *range, size_t size)
> >  	unsigned long vm_flags = VM_ALLOW_HUGE_VMAP;
> >  	struct execmem_area *area;
> >  	unsigned long start, end;
> > +	unsigned int page_shift;
> >  	struct vm_struct *vm;
> >  	size_t alloc_size;
> >  	int err = -ENOMEM;
> > @@ -296,8 +297,9 @@ static int execmem_cache_populate(struct execmem_range *range, size_t size)
> >  	if (err)
> >  		goto err_free_mem;
> >  
> > +	page_shift = get_vm_area_page_order(vm) + PAGE_SHIFT;
> >  	err = vmap_pages_range_noflush(start, end, range->pgprot, vm->pages,
> > -				       PMD_SHIFT);
> > +				       page_shift);
> >  	if (err)
> >  		goto err_free_mem;
> >  
> 
> Hi Mike! Thanks. I can indeed, and I will, but also an update: on
> further testing, sadly, using 'host' CPU for qemu doesn't really avoid
> the bug either :/ The initial test must have just gotten lucky. I
> implemented that as a 'workaround' in our openQA system and dropped the
> five automatic retries per test I was using as a bludgeon, but then
> failures started showing up again :/ So I've had to put the five
> retries back in place for now.
> 
> Sorry if this sent you down any wrong paths, I will test the patch
> unless you tell me it's useless with this new information :)

I don't think that CPU flavour is important here. I'll greatly appreciate
your testing.

> -- 
> Adam Williamson (he/him/his)

-- 
Sincerely yours,
Mike.