[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [BUG] hw/xen: features published after InitWait since 240cc11369fc



On Fri, 2026-09-11 at 13:31 +0100, David Woodhouse wrote:
> 
>  - While testing hot-plug of xen-net-device we hit an unrelated,
>    pre-existing heap corruption ("double free or corruption (!prev)")
>    on qemu exit after hot-plugging a xen-net-device, present on
>    current master both with and without the fix. It looks like the
>    same class of exit-notifier-vs-net_cleanup() teardown ordering
>    issue as commit 9000666052 ("xen-block: fix segv on unrealize")
>    was for xen-block. That will be chased separately.

It has a fix for that too now, FWIW, but I don't have the bandwidth
right now to reimplement it with meat fingers so I might just file the
bug instead.

I wasn't *actually* setting out to comment on the AI policy today  — in
fact I didn't really have a strong opinion on it. I spend enough of my
life tilting at windmills *intentionally*; this wasn't meant to be one
of them.

Letting the tool reply in its own voice and pretending I was held
hostage was mostly meant as a joke, as *well* as being the only way I
was going to look at that bug today (it would have taken me a *long*
time to do all that testing of old and new failure modes, finding the
net device path that *does* reproduce it locally, fixing the other
problem with that, and finally confirming that it all works).

But our policies should be based on actual data and the holistic
outcomes they achieve, and this is just data which we can take into
account on one side of the balance, even if the other side remains more
compelling.

Attachment: smime.p7s
Description: S/MIME cryptographic signature


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.