panic from zio_write_gang_block() when creating dump device on fragmented rpool
When the amount of memory in the system changes, we automatically increase the size of the dump device. The dump device is allocated with ZIO_FLAG_NODATA, so that we just allocate the space and don't write to it (yet - we'll write when the system dumps). If the rpool is fragmented, then we may end up trying to create gang blocks for the dump device. What should happen is that we allocate the gang blocks, and then the zvol_dumpify() code will notice that there are gang blocks in the dump device, and fail to activate it for dump (since we don't have code to support this).
However, when we create the gang block for the dump device (with ZIO_FLAG_NODATA), we get a panic from zio_write_gang_block(), because pio->io_abd is NULL. It should be fine for this to be NULL, since we have ZIO_FLAG_NODATA we should not be touching it. However, with the ABD changes we are now doing "abd_get_offset(pio->io_abd, ...)" which will panic since the io_abd is NULL.
The solution is for zio_write_gang_block() to pass a NULL abd to zio_write() instead of calling abd_get_offset(pio->io_abd == NULL), when ZIO_FLAG_NODATA is set.
Updated by Electric Monk about 1 year ago
- % Done changed from 0 to 100
- Status changed from New to Closed
commit 7341a7de4f0489193e0cfe11049a7bcf1596a4db Author: Brad Lewis <email@example.com> Date: 2018-09-18T20:49:10.000Z 9677 panic from zio_write_gang_block() when creating dump device on fragmented rpool Reviewed by: Matt Ahrens <firstname.lastname@example.org> Reviewed by: George Wilson <email@example.com> Reviewed by: Prashanth Sreenivasa <firstname.lastname@example.org> Approved by: Robert Mustacchi <email@example.com>