| Message ID | 20210422135834.406688-1-its@irrelevant.dk |
|---|---|
| Headers | show |
| Series | hw/block/nvme: fix msix uninit | expand |
On Apr 22 15:58, Klaus Jensen wrote: >From: Klaus Jensen <k.jensen@samsung.com> > >Hi Peter, > >The commit message on the patch describes the issue. This is a QEMU >crashing bug in -rc4 that I introduced early in the cycle and never >found in time. Lack of testing device hotplugging is the cause for that. > >I'm not sure what to say other than I'm terribly sorry for introducing >this and if this means an -rc5 needs to be rolled, then I'm even more >sorry. > >I think an acceptance test could have caught this, and I am already >working on an acceptance test suite for the nvme device, so I'll add >something that test this as well. But, well, it doesn't help now. > >Klaus Jensen (1): > hw/block/nvme: fix invalid msix exclusive uninit > > hw/block/nvme.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >-- >2.31.1 > > As far as I can tell, to cause this crash, monitor access is required, so I am not sure if we can get away with a note on this in the release notes and fix this in a potential stable release or next.
On Thu, 22 Apr 2021 at 15:07, Klaus Jensen <its@irrelevant.dk> wrote: > > On Apr 22 15:58, Klaus Jensen wrote: > >From: Klaus Jensen <k.jensen@samsung.com> > > > >Hi Peter, > > > >The commit message on the patch describes the issue. This is a QEMU > >crashing bug in -rc4 that I introduced early in the cycle and never > >found in time. Lack of testing device hotplugging is the cause for that. > > > >I'm not sure what to say other than I'm terribly sorry for introducing > >this and if this means an -rc5 needs to be rolled, then I'm even more > >sorry. > > > >I think an acceptance test could have caught this, and I am already > >working on an acceptance test suite for the nvme device, so I'll add > >something that test this as well. But, well, it doesn't help now. > As far as I can tell, to cause this crash, monitor access is required, > so I am not sure if we can get away with a note on this in the release > notes and fix this in a potential stable release or next. Is this a regression since 5.2 ? thanks -- PMM
On Apr 22 19:58, Peter Maydell wrote: >On Thu, 22 Apr 2021 at 15:07, Klaus Jensen <its@irrelevant.dk> wrote: >> >> On Apr 22 15:58, Klaus Jensen wrote: >> >From: Klaus Jensen <k.jensen@samsung.com> >> > >> >Hi Peter, >> > >> >The commit message on the patch describes the issue. This is a QEMU >> >crashing bug in -rc4 that I introduced early in the cycle and never >> >found in time. Lack of testing device hotplugging is the cause for that. >> > >> >I'm not sure what to say other than I'm terribly sorry for introducing >> >this and if this means an -rc5 needs to be rolled, then I'm even more >> >sorry. >> > >> >I think an acceptance test could have caught this, and I am already >> >working on an acceptance test suite for the nvme device, so I'll add >> >something that test this as well. But, well, it doesn't help now. > >> As far as I can tell, to cause this crash, monitor access is required, >> so I am not sure if we can get away with a note on this in the release >> notes and fix this in a potential stable release or next. > >Is this a regression since 5.2 ? > Yes.
From: Klaus Jensen <k.jensen@samsung.com> Hi Peter, The commit message on the patch describes the issue. This is a QEMU crashing bug in -rc4 that I introduced early in the cycle and never found in time. Lack of testing device hotplugging is the cause for that. I'm not sure what to say other than I'm terribly sorry for introducing this and if this means an -rc5 needs to be rolled, then I'm even more sorry. I think an acceptance test could have caught this, and I am already working on an acceptance test suite for the nvme device, so I'll add something that test this as well. But, well, it doesn't help now. Klaus Jensen (1): hw/block/nvme: fix invalid msix exclusive uninit hw/block/nvme.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)