On Thu, Feb 12, 2026 at 3:00 AM Dmitry Osipenko
<[email protected]> wrote:
>
> On 2/12/26 10:01, Michael S. Tsirkin wrote:
> > On Thu, Feb 12, 2026 at 01:53:09AM +0300, Dmitry Osipenko wrote:
> >> On 2/12/26 00:32, Joelle van Dyne wrote:
> >>> Yes, it does seem like v1 was picked up and not v2. v1 was broken for this
> >>> reason.
> >>
> >> Thanks for the confirmation. Most likely you will need to send a new
> >> version of the patch fixing the applied one.
> >>
> >> --
> >> Best regards,
> >> Dmitry
> >
> > applied one was v3 according to my records
> > but if it crashes pls do send a fixup.
Sorry for the confusion, I was traveling and when I originally
reviewed this thread, the stack trace + the link to v2 caused me to
claim that it looked like v1 (since it didn't have the NULL name
change) but after looking at the changes properly I see that v3 was
the patch that was picked up. There was no mistake in applying the
wrong patch.

>
> Alright, I previosly missed v3 and see that it's identical to v1, which
> has the crash problem.
v3 is not identical to v1. v1 changed the owner of the region from
itself to the parent object. This fixed the original crash but
introduced a new issue. v2 tried to fix the original crash a different
way that was brittle because it involved manually writing to a field
in the memory region struct. v3 was the proper fix which used a NULL
name which allows the parent to be unset and then we have to use unref
instead of unparent in cleanup.

>
> Joelle, are you aware of this problem with the version that got applied
> to the qemu/staging tree? If yes, could you please send patch fixing it?
Unfortunately, this means that the patch should not have been back
ported. It is possible that the crash which this patch was addressing
was introduced as a result of changes elsewhere. For example
https://lore.kernel.org/all/[email protected]/
changed some internal mechanics of finalize. I didn't raise any
objection to the back port because it seemed like the original code
where the object was its own parent was wrong but I guess it was
working fine somehow. I think in the meantime the best course of
action is to revert the patch in the stable branches.

>
>
> --
> Best regards,
> Dmitry

Reply via email to