| Message ID | 20230906130922.142845-1-f.ebner@proxmox.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2,1/2] hw/ide: reset: cancel async DMA operation before resetting state | expand |
On Wednesday, 6 September 2023 Fiona Ebner <f.ebner@proxmox.com> wrote: > If there is a pending DMA operation during ide_bus_reset(), the fact > that the IDEState is already reset before the operation is canceled > can be problematic. In particular, ide_dma_cb() might be called and > then use the reset IDEState which contains the signature after the > reset. When used to construct the IO operation this leads to > ide_get_sector() returning 0 and nsector being 1. This is particularly > bad, because a write command will thus destroy the first sector which > often contains a partition table or similar. Tested-by: simon.rowe@nutanix.com
Ping Am 06.09.23 um 15:09 schrieb Fiona Ebner: > If there is a pending DMA operation during ide_bus_reset(), the fact > that the IDEState is already reset before the operation is canceled > can be problematic. In particular, ide_dma_cb() might be called and > then use the reset IDEState which contains the signature after the > reset. When used to construct the IO operation this leads to > ide_get_sector() returning 0 and nsector being 1. This is particularly > bad, because a write command will thus destroy the first sector which > often contains a partition table or similar. > > Traces showing the unsolicited write happening with IDEState > 0x5595af6949d0 being used after reset: > >> ahci_port_write ahci(0x5595af6923f0)[0]: port write [reg:PxSCTL] @ 0x2c: 0x00000300 >> ahci_reset_port ahci(0x5595af6923f0)[0]: reset port >> ide_reset IDEstate 0x5595af6949d0 >> ide_reset IDEstate 0x5595af694da8 >> ide_bus_reset_aio aio_cancel >> dma_aio_cancel dbs=0x7f64600089a0 >> dma_blk_cb dbs=0x7f64600089a0 ret=0 >> dma_complete dbs=0x7f64600089a0 ret=0 cb=0x5595acd40b30 >> ahci_populate_sglist ahci(0x5595af6923f0)[0] >> ahci_dma_prepare_buf ahci(0x5595af6923f0)[0]: prepare buf limit=512 prepared=512 >> ide_dma_cb IDEState 0x5595af6949d0; sector_num=0 n=1 cmd=DMA WRITE >> dma_blk_io dbs=0x7f6420802010 bs=0x5595ae2c6c30 offset=0 to_dev=1 >> dma_blk_cb dbs=0x7f6420802010 ret=0 > >> (gdb) p *qiov >> $11 = {iov = 0x7f647c76d840, niov = 1, {{nalloc = 1, local_iov = {iov_base = 0x0, >> iov_len = 512}}, {__pad = "\001\000\000\000\000\000\000\000\000\000\000", >> size = 512}}} >> (gdb) bt >> #0 blk_aio_pwritev (blk=0x5595ae2c6c30, offset=0, qiov=0x7f6420802070, flags=0, >> cb=0x5595ace6f0b0 <dma_blk_cb>, opaque=0x7f6420802010) >> at ../block/block-backend.c:1682 >> #1 0x00005595ace6f185 in dma_blk_cb (opaque=0x7f6420802010, ret=<optimized out>) >> at ../softmmu/dma-helpers.c:179 >> #2 0x00005595ace6f778 in dma_blk_io (ctx=0x5595ae0609f0, >> sg=sg@entry=0x5595af694d00, offset=offset@entry=0, align=align@entry=512, >> io_func=io_func@entry=0x5595ace6ee30 <dma_blk_write_io_func>, >> io_func_opaque=io_func_opaque@entry=0x5595ae2c6c30, >> cb=0x5595acd40b30 <ide_dma_cb>, opaque=0x5595af6949d0, >> dir=DMA_DIRECTION_TO_DEVICE) at ../softmmu/dma-helpers.c:244 >> #3 0x00005595ace6f90a in dma_blk_write (blk=0x5595ae2c6c30, >> sg=sg@entry=0x5595af694d00, offset=offset@entry=0, align=align@entry=512, >> cb=cb@entry=0x5595acd40b30 <ide_dma_cb>, opaque=opaque@entry=0x5595af6949d0) >> at ../softmmu/dma-helpers.c:280 >> #4 0x00005595acd40e18 in ide_dma_cb (opaque=0x5595af6949d0, ret=<optimized out>) >> at ../hw/ide/core.c:953 >> #5 0x00005595ace6f319 in dma_complete (ret=0, dbs=0x7f64600089a0) >> at ../softmmu/dma-helpers.c:107 >> #6 dma_blk_cb (opaque=0x7f64600089a0, ret=0) at ../softmmu/dma-helpers.c:127 >> #7 0x00005595ad12227d in blk_aio_complete (acb=0x7f6460005b10) >> at ../block/block-backend.c:1527 >> #8 blk_aio_complete (acb=0x7f6460005b10) at ../block/block-backend.c:1524 >> #9 blk_aio_write_entry (opaque=0x7f6460005b10) at ../block/block-backend.c:1594 >> #10 0x00005595ad258cfb in coroutine_trampoline (i0=<optimized out>, >> i1=<optimized out>) at ../util/coroutine-ucontext.c:177 > > Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> > Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
On 24/10/23 12:54, Fiona Ebner wrote: > Ping John seems busy, I'll take these 2 patches. Thanks Fiona! > Am 06.09.23 um 15:09 schrieb Fiona Ebner: >> If there is a pending DMA operation during ide_bus_reset(), the fact >> that the IDEState is already reset before the operation is canceled >> can be problematic. In particular, ide_dma_cb() might be called and >> then use the reset IDEState which contains the signature after the >> reset. When used to construct the IO operation this leads to >> ide_get_sector() returning 0 and nsector being 1. This is particularly >> bad, because a write command will thus destroy the first sector which >> often contains a partition table or similar. >> >> Traces showing the unsolicited write happening with IDEState >> 0x5595af6949d0 being used after reset: >> >>> ahci_port_write ahci(0x5595af6923f0)[0]: port write [reg:PxSCTL] @ 0x2c: 0x00000300 >>> ahci_reset_port ahci(0x5595af6923f0)[0]: reset port >>> ide_reset IDEstate 0x5595af6949d0 >>> ide_reset IDEstate 0x5595af694da8 >>> ide_bus_reset_aio aio_cancel >>> dma_aio_cancel dbs=0x7f64600089a0 >>> dma_blk_cb dbs=0x7f64600089a0 ret=0 >>> dma_complete dbs=0x7f64600089a0 ret=0 cb=0x5595acd40b30 >>> ahci_populate_sglist ahci(0x5595af6923f0)[0] >>> ahci_dma_prepare_buf ahci(0x5595af6923f0)[0]: prepare buf limit=512 prepared=512 >>> ide_dma_cb IDEState 0x5595af6949d0; sector_num=0 n=1 cmd=DMA WRITE >>> dma_blk_io dbs=0x7f6420802010 bs=0x5595ae2c6c30 offset=0 to_dev=1 >>> dma_blk_cb dbs=0x7f6420802010 ret=0 >> >>> (gdb) p *qiov >>> $11 = {iov = 0x7f647c76d840, niov = 1, {{nalloc = 1, local_iov = {iov_base = 0x0, >>> iov_len = 512}}, {__pad = "\001\000\000\000\000\000\000\000\000\000\000", >>> size = 512}}} >>> (gdb) bt >>> #0 blk_aio_pwritev (blk=0x5595ae2c6c30, offset=0, qiov=0x7f6420802070, flags=0, >>> cb=0x5595ace6f0b0 <dma_blk_cb>, opaque=0x7f6420802010) >>> at ../block/block-backend.c:1682 >>> #1 0x00005595ace6f185 in dma_blk_cb (opaque=0x7f6420802010, ret=<optimized out>) >>> at ../softmmu/dma-helpers.c:179 >>> #2 0x00005595ace6f778 in dma_blk_io (ctx=0x5595ae0609f0, >>> sg=sg@entry=0x5595af694d00, offset=offset@entry=0, align=align@entry=512, >>> io_func=io_func@entry=0x5595ace6ee30 <dma_blk_write_io_func>, >>> io_func_opaque=io_func_opaque@entry=0x5595ae2c6c30, >>> cb=0x5595acd40b30 <ide_dma_cb>, opaque=0x5595af6949d0, >>> dir=DMA_DIRECTION_TO_DEVICE) at ../softmmu/dma-helpers.c:244 >>> #3 0x00005595ace6f90a in dma_blk_write (blk=0x5595ae2c6c30, >>> sg=sg@entry=0x5595af694d00, offset=offset@entry=0, align=align@entry=512, >>> cb=cb@entry=0x5595acd40b30 <ide_dma_cb>, opaque=opaque@entry=0x5595af6949d0) >>> at ../softmmu/dma-helpers.c:280 >>> #4 0x00005595acd40e18 in ide_dma_cb (opaque=0x5595af6949d0, ret=<optimized out>) >>> at ../hw/ide/core.c:953 >>> #5 0x00005595ace6f319 in dma_complete (ret=0, dbs=0x7f64600089a0) >>> at ../softmmu/dma-helpers.c:107 >>> #6 dma_blk_cb (opaque=0x7f64600089a0, ret=0) at ../softmmu/dma-helpers.c:127 >>> #7 0x00005595ad12227d in blk_aio_complete (acb=0x7f6460005b10) >>> at ../block/block-backend.c:1527 >>> #8 blk_aio_complete (acb=0x7f6460005b10) at ../block/block-backend.c:1524 >>> #9 blk_aio_write_entry (opaque=0x7f6460005b10) at ../block/block-backend.c:1594 >>> #10 0x00005595ad258cfb in coroutine_trampoline (i0=<optimized out>, >>> i1=<optimized out>) at ../util/coroutine-ucontext.c:177 >> >> Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> >> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> >
06.09.2023 16:09, Fiona Ebner wrote: > If there is a pending DMA operation during ide_bus_reset(), the fact > that the IDEState is already reset before the operation is canceled > can be problematic. In particular, ide_dma_cb() might be called and > then use the reset IDEState which contains the signature after the > reset. When used to construct the IO operation this leads to > ide_get_sector() returning 0 and nsector being 1. This is particularly > bad, because a write command will thus destroy the first sector which > often contains a partition table or similar. > > Traces showing the unsolicited write happening with IDEState > 0x5595af6949d0 being used after reset: > >> ahci_port_write ahci(0x5595af6923f0)[0]: port write [reg:PxSCTL] @ 0x2c: 0x00000300 >> ahci_reset_port ahci(0x5595af6923f0)[0]: reset port >> ide_reset IDEstate 0x5595af6949d0 >> ide_reset IDEstate 0x5595af694da8 >> ide_bus_reset_aio aio_cancel >> dma_aio_cancel dbs=0x7f64600089a0 >> dma_blk_cb dbs=0x7f64600089a0 ret=0 >> dma_complete dbs=0x7f64600089a0 ret=0 cb=0x5595acd40b30 >> ahci_populate_sglist ahci(0x5595af6923f0)[0] >> ahci_dma_prepare_buf ahci(0x5595af6923f0)[0]: prepare buf limit=512 prepared=512 >> ide_dma_cb IDEState 0x5595af6949d0; sector_num=0 n=1 cmd=DMA WRITE >> dma_blk_io dbs=0x7f6420802010 bs=0x5595ae2c6c30 offset=0 to_dev=1 >> dma_blk_cb dbs=0x7f6420802010 ret=0 > >> (gdb) p *qiov >> $11 = {iov = 0x7f647c76d840, niov = 1, {{nalloc = 1, local_iov = {iov_base = 0x0, >> iov_len = 512}}, {__pad = "\001\000\000\000\000\000\000\000\000\000\000", >> size = 512}}} >> (gdb) bt >> #0 blk_aio_pwritev (blk=0x5595ae2c6c30, offset=0, qiov=0x7f6420802070, flags=0, >> cb=0x5595ace6f0b0 <dma_blk_cb>, opaque=0x7f6420802010) >> at ../block/block-backend.c:1682 >> #1 0x00005595ace6f185 in dma_blk_cb (opaque=0x7f6420802010, ret=<optimized out>) >> at ../softmmu/dma-helpers.c:179 >> #2 0x00005595ace6f778 in dma_blk_io (ctx=0x5595ae0609f0, >> sg=sg@entry=0x5595af694d00, offset=offset@entry=0, align=align@entry=512, >> io_func=io_func@entry=0x5595ace6ee30 <dma_blk_write_io_func>, >> io_func_opaque=io_func_opaque@entry=0x5595ae2c6c30, >> cb=0x5595acd40b30 <ide_dma_cb>, opaque=0x5595af6949d0, >> dir=DMA_DIRECTION_TO_DEVICE) at ../softmmu/dma-helpers.c:244 >> #3 0x00005595ace6f90a in dma_blk_write (blk=0x5595ae2c6c30, >> sg=sg@entry=0x5595af694d00, offset=offset@entry=0, align=align@entry=512, >> cb=cb@entry=0x5595acd40b30 <ide_dma_cb>, opaque=opaque@entry=0x5595af6949d0) >> at ../softmmu/dma-helpers.c:280 >> #4 0x00005595acd40e18 in ide_dma_cb (opaque=0x5595af6949d0, ret=<optimized out>) >> at ../hw/ide/core.c:953 >> #5 0x00005595ace6f319 in dma_complete (ret=0, dbs=0x7f64600089a0) >> at ../softmmu/dma-helpers.c:107 >> #6 dma_blk_cb (opaque=0x7f64600089a0, ret=0) at ../softmmu/dma-helpers.c:127 >> #7 0x00005595ad12227d in blk_aio_complete (acb=0x7f6460005b10) >> at ../block/block-backend.c:1527 >> #8 blk_aio_complete (acb=0x7f6460005b10) at ../block/block-backend.c:1524 >> #9 blk_aio_write_entry (opaque=0x7f6460005b10) at ../block/block-backend.c:1594 >> #10 0x00005595ad258cfb in coroutine_trampoline (i0=<optimized out>, >> i1=<optimized out>) at ../util/coroutine-ucontext.c:177 > > Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> > Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Ping? Has this bugfix been lost somehow? /mjt
Am 26.10.23 um 08:17 schrieb Michael Tokarev: > 06.09.2023 16:09, Fiona Ebner wrote: >> If there is a pending DMA operation during ide_bus_reset(), the fact >> that the IDEState is already reset before the operation is canceled >> can be problematic. In particular, ide_dma_cb() might be called and >> then use the reset IDEState which contains the signature after the >> reset. When used to construct the IO operation this leads to >> ide_get_sector() returning 0 and nsector being 1. This is particularly >> bad, because a write command will thus destroy the first sector which >> often contains a partition table or similar. >> >> Traces showing the unsolicited write happening with IDEState >> 0x5595af6949d0 being used after reset: >> >>> ahci_port_write ahci(0x5595af6923f0)[0]: port write [reg:PxSCTL] @ >>> 0x2c: 0x00000300 >>> ahci_reset_port ahci(0x5595af6923f0)[0]: reset port >>> ide_reset IDEstate 0x5595af6949d0 >>> ide_reset IDEstate 0x5595af694da8 >>> ide_bus_reset_aio aio_cancel >>> dma_aio_cancel dbs=0x7f64600089a0 >>> dma_blk_cb dbs=0x7f64600089a0 ret=0 >>> dma_complete dbs=0x7f64600089a0 ret=0 cb=0x5595acd40b30 >>> ahci_populate_sglist ahci(0x5595af6923f0)[0] >>> ahci_dma_prepare_buf ahci(0x5595af6923f0)[0]: prepare buf limit=512 >>> prepared=512 >>> ide_dma_cb IDEState 0x5595af6949d0; sector_num=0 n=1 cmd=DMA WRITE >>> dma_blk_io dbs=0x7f6420802010 bs=0x5595ae2c6c30 offset=0 to_dev=1 >>> dma_blk_cb dbs=0x7f6420802010 ret=0 >> >>> (gdb) p *qiov >>> $11 = {iov = 0x7f647c76d840, niov = 1, {{nalloc = 1, local_iov = >>> {iov_base = 0x0, >>> iov_len = 512}}, {__pad = >>> "\001\000\000\000\000\000\000\000\000\000\000", >>> size = 512}}} >>> (gdb) bt >>> #0 blk_aio_pwritev (blk=0x5595ae2c6c30, offset=0, >>> qiov=0x7f6420802070, flags=0, >>> cb=0x5595ace6f0b0 <dma_blk_cb>, opaque=0x7f6420802010) >>> at ../block/block-backend.c:1682 >>> #1 0x00005595ace6f185 in dma_blk_cb (opaque=0x7f6420802010, >>> ret=<optimized out>) >>> at ../softmmu/dma-helpers.c:179 >>> #2 0x00005595ace6f778 in dma_blk_io (ctx=0x5595ae0609f0, >>> sg=sg@entry=0x5595af694d00, offset=offset@entry=0, >>> align=align@entry=512, >>> io_func=io_func@entry=0x5595ace6ee30 <dma_blk_write_io_func>, >>> io_func_opaque=io_func_opaque@entry=0x5595ae2c6c30, >>> cb=0x5595acd40b30 <ide_dma_cb>, opaque=0x5595af6949d0, >>> dir=DMA_DIRECTION_TO_DEVICE) at ../softmmu/dma-helpers.c:244 >>> #3 0x00005595ace6f90a in dma_blk_write (blk=0x5595ae2c6c30, >>> sg=sg@entry=0x5595af694d00, offset=offset@entry=0, >>> align=align@entry=512, >>> cb=cb@entry=0x5595acd40b30 <ide_dma_cb>, >>> opaque=opaque@entry=0x5595af6949d0) >>> at ../softmmu/dma-helpers.c:280 >>> #4 0x00005595acd40e18 in ide_dma_cb (opaque=0x5595af6949d0, >>> ret=<optimized out>) >>> at ../hw/ide/core.c:953 >>> #5 0x00005595ace6f319 in dma_complete (ret=0, dbs=0x7f64600089a0) >>> at ../softmmu/dma-helpers.c:107 >>> #6 dma_blk_cb (opaque=0x7f64600089a0, ret=0) at >>> ../softmmu/dma-helpers.c:127 >>> #7 0x00005595ad12227d in blk_aio_complete (acb=0x7f6460005b10) >>> at ../block/block-backend.c:1527 >>> #8 blk_aio_complete (acb=0x7f6460005b10) at >>> ../block/block-backend.c:1524 >>> #9 blk_aio_write_entry (opaque=0x7f6460005b10) at >>> ../block/block-backend.c:1594 >>> #10 0x00005595ad258cfb in coroutine_trampoline (i0=<optimized out>, >>> i1=<optimized out>) at ../util/coroutine-ucontext.c:177 >> >> Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> >> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> > > Ping? Has this bugfix been lost somehow? > I sent a ping 2 days ago and it'll be picked up by Philippe :) https://lists.nongnu.org/archive/html/qemu-devel/2023-10/msg08296.html And CC-ing stable. Sorry, didn't think about that before. Best Regards, Fiona
diff --git a/hw/ide/core.c b/hw/ide/core.c index ee116891ed..c8af89785e 100644 --- a/hw/ide/core.c +++ b/hw/ide/core.c @@ -2515,19 +2515,19 @@ static void ide_dummy_transfer_stop(IDEState *s) void ide_bus_reset(IDEBus *bus) { - bus->unit = 0; - bus->cmd = 0; - ide_reset(&bus->ifs[0]); - ide_reset(&bus->ifs[1]); - ide_clear_hob(bus); - - /* pending async DMA */ + /* pending async DMA - needs the IDEState before it is reset */ if (bus->dma->aiocb) { trace_ide_bus_reset_aio(); blk_aio_cancel(bus->dma->aiocb); bus->dma->aiocb = NULL; } + bus->unit = 0; + bus->cmd = 0; + ide_reset(&bus->ifs[0]); + ide_reset(&bus->ifs[1]); + ide_clear_hob(bus); + /* reset dma provider too */ if (bus->dma->ops->reset) { bus->dma->ops->reset(bus->dma);