Re: Xen 4.18 release: Reminder about code freeze

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 28/09/2023 12:04 am, Stefano Stabellini wrote:
> On Mon, 25 Sep 2023, Henry Wang wrote:
>> 3. dom0less vs xenstored setup race Was: xen | Failed pipeline for staging | 
>> 6a47ba2f
>>
>> https://marc.info/?l=xen-devel&m=168312468808977
>>
>> https://marc.info/?l=xen-devel&m=168312687610283
> For this issue I suggest to go with this fix unless someone can produce
> a better fix before RC2. I don't think we should cut RC2 with this issue
> unsolved.
>
> ---
> [PATCH] xenstored: reset domain connection before XENSTORE_CONNECTED
>
> From: Julien Grall <julien@xxxxxxx>
>
> xenstored will set interface->connection to XENSTORE_CONNECTED before
> finalizing the connection which can cause initialization errors on the
> guest side. Make sure to call domain_conn_reset(domain) before setting
> XENSTORE_CONNECTED.
>
> Signed-off-by: Julien Grall <julien@xxxxxxx>
> [stefano: rebase, commit message]
> Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxx>
> Acked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>

No - this hasn't got any better at fixing the problem than the last time
it failed to fix the problem.

You cannot have 3 entities in parallel fight for control in a 2-way
communication channel.

Failure to understand this is what created the problem to begin with.

You took an existing ABI from oxenstored, and implemented it
incompatibly in other entities, had init-dom0less corrupt a shared comms
buffer that it isn't the producer or consumer of, and added bug in Linux
because you didn't write down the behaviour you wanted, let alone the
behaviour you actually provided.

Stop tinkering in the hope that it hides the problem.  You're only
making it harder to fix properly.

Tell me, when was the last time this failed...

~Andrew