Re: [PATCH v4] page_alloc: assert IRQs are enabled in heap alloc/free

[David Vrabel <dvrabel@xxxxxxxxxx>]

On 26/04/2022 15:14, Julien Grall wrote:
> Hi,
>
> On 26/04/2022 15:01, Jan Beulich wrote:
> > On 25.04.2022 15:28, David Vrabel wrote:
> > > --- a/xen/common/page_alloc.c
> > > +++ b/xen/common/page_alloc.c
> > > @@ -162,6 +162,13 @@
> > >   static char __initdata opt_badpage[100] = "";
> > >   string_param("badpage", opt_badpage);
> > > +/*
> > > + * Heap allocations may need TLB flushes which require IRQs to be
> > > + * enabled (except when only 1 PCPU is online).
> > > + */
> > > +#define ASSERT_ALLOC_CONTEXT() \
> > > +    ASSERT(!in_irq() && (local_irq_is_enabled() || num_online_cpus() 
> > > <= 1))
> > At least one of these tightened assertions triggers on Arm, as per the
> > most recent smoke flight. I'm going to revert this for the time being.
>  From the serial console [1]:
>
> (XEN) Xen call trace:
> (XEN)    [<0022a510>] alloc_xenheap_pages+0x120/0x150 (PC)
> (XEN)    [<00000000>] 00000000 (LR)
> (XEN)    [<002736ac>] arch/arm/mm.c#xen_pt_update+0x144/0x6e4
> (XEN)    [<002740d4>] map_pages_to_xen+0x10/0x20
> (XEN)    [<00236864>] __vmap+0x400/0x4a4
> (XEN)    [<0026aee8>] 
> arch/arm/alternative.c#__apply_alternatives_multi_stop+0x144/0x1ec
> (XEN)    [<0022fe40>] stop_machine_run+0x23c/0x300
An allocation inside a stop_machine_run() action function. That is what 
the asserts were designed to catch.
I did try the run the GitLab CI pipelines but it is setup to use runners 
that are only available to the Xen Project group, so forking the repo 
doesn't work.
Can my (personal) GitLab be added as a Developer to the Xen Project 
group? I think this is the intended way for people to run the CI 
pipelines on their own branches.
David