Re: Xen panic when shutting down ARINC653 cpupool

[Jürgen Groß <jgross@xxxxxxxx>]

On 17.03.25 06:07, Choi, Anderson wrote:
> I'd like to report xen panic when shutting down an ARINC653 domain with the 
> following setup.
> Note that this is only observed when CONFIG_DEBUG is enabled.
>
> [Test environment]
> Yocto release : 5.05
> Xen release : 4.19 (hash = 026c9fa29716b0ff0f8b7c687908e71ba29cf239)
> Target machine : QEMU ARM64
> Number of physical CPUs : 4
>
> [Xen config]
> CONFIG_DEBUG = y
>
> [CPU pool configuration files]
> cpupool_arinc0.cfg
> - name= "Pool-arinc0"
> - sched="arinc653"
> - cpus=["2"]
>
> [Domain configuration file]
> dom1.cfg
> - vcpus = 1
> - pool = "Pool-arinc0"
>
> $ xl cpupool-cpu-remove Pool-0 2
> $ xl cpupool-create -f cpupool_arinc0.cfg
> $ xl create dom1.cfg
> $ a653_sched -P Pool-arinc0 dom1:100
>
> ** Wait for DOM1 to complete boot.**
>
> $ xl shutdown dom1
>
> [xen log]
> root@boeing-linux-ref:~# xl shutdown dom1
> Shutting down domain 1
> root@boeing-linux-ref:~# (XEN) Assertion '!in_irq() && (local_irq_is_enabled() || 
> num_online_cpus() <= 1)' failed at common/xmalloc_tlsf.c:714
> (XEN) ----[ Xen-4.19.1-pre  arm64  debug=y  Tainted: I      ]----
> (XEN) CPU:    2
> (XEN) PC:     00000a000022d2b0 xfree+0x130/0x1a4
> (XEN) LR:     00000a000022d2a4
> (XEN) SP:     00008000fff77b50
> (XEN) CPSR:   00000000200002c9 MODE:64-bit EL2h (Hypervisor, handler)
> ...
> (XEN) Xen call trace:
> (XEN)    [<00000a000022d2b0>] xfree+0x130/0x1a4 (PC)
> (XEN)    [<00000a000022d2a4>] xfree+0x124/0x1a4 (LR)
> (XEN)    [<00000a00002321f0>] arinc653.c#a653sched_free_udata+0x50/0xc4
> (XEN)    [<00000a0000241bc0>] core.c#sched_move_domain_cleanup+0x5c/0x80
> (XEN)    [<00000a0000245328>] sched_move_domain+0x69c/0x70c
> (XEN)    [<00000a000022f840>] cpupool.c#cpupool_move_domain_locked+0x38/0x70
> (XEN)    [<00000a0000230f20>] cpupool_move_domain+0x34/0x54
> (XEN)    [<00000a0000206c40>] domain_kill+0xc0/0x15c
> (XEN)    [<00000a000022e0d4>] do_domctl+0x904/0x12ec
> (XEN)    [<00000a0000277a1c>] traps.c#do_trap_hypercall+0x1f4/0x288
> (XEN)    [<00000a0000279018>] do_trap_guest_sync+0x448/0x63c
> (XEN)    [<00000a0000262c80>] entry.o#guest_sync_slowpath+0xa8/0xd8
> (XEN)
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 2:
> (XEN) Assertion '!in_irq() && (local_irq_is_enabled() || num_online_cpus() <= 
> 1)' failed at common/xmalloc_tlsf.c:714
> (XEN) ****************************************
>
> In commit 19049f8d (sched: fix locking in a653sched_free_vdata()), locking was 
> introduced to prevent a race against the list manipulation but leads to 
> assertion failure when the ARINC 653 domain is shutdown.
>
> I think this can be fixed by calling xfree() after spin_unlock_irqrestore() as 
> shown below.
>
> xen/common/sched/arinc653.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/xen/common/sched/arinc653.c b/xen/common/sched/arinc653.c
> index 7bf288264c..1615f1bc46 100644
> --- a/xen/common/sched/arinc653.c
> +++ b/xen/common/sched/arinc653.c
> @@ -463,10 +463,11 @@ a653sched_free_udata(const struct scheduler *ops, void 
> *priv)
>       if ( !is_idle_unit(av->unit) )
>           list_del(&av->list);
>
> -    xfree(av);
>       update_schedule_units(ops);
>
>       spin_unlock_irqrestore(&sched_priv->lock, flags);
> +
> +    xfree(av);
>   }
>
> Can I hear your opinion on this?
Yes, this seems the right way to fix the issue.

Could you please send a proper patch (please have a look at [1] in case
you are unsure how a proper patch should look like)?


Juergen

[1] 
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/process/sending-patches.pandoc

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature