[dm-devel] Deadlock when swapping a table with a dm-era target

[Zdenek Kabelac]

Dne 01. 12. 21 v 18:07 Nikos Tsironis napsal(a):
> Hello,
>
> Under certain conditions, swapping a table, that includes a dm-era
> target, with a new table, causes a deadlock.
>
> This happens when a status (STATUSTYPE_INFO) or message IOCTL is blocked
> in the suspended dm-era target.
>
> dm-era executes all metadata operations in a worker thread, which stops
> processing requests when the target is suspended, and resumes again when
> the target is resumed.
>
> So, running 'dmsetup status' or 'dmsetup message' for a suspended dm-era
> device blocks, until the device is resumed.
>
> This seems to be a problem on its own.
>
> If we then load a new table to the device, while the aforementioned
> dmsetup command is blocked in dm-era, and resume the device, we
> deadlock.
>
> The problem is that the 'dmsetup status' and 'dmsetup message' commands
> hold a reference to the live table, i.e., they hold an SRCU read lock on
> md->io_barrier, while they are blocked.
>
> When the device is resumed, the old table is replaced with the new one
> by dm_swap_table(), which ends up calling synchronize_srcu() on
> md->io_barrier.
>
> Since the blocked dmsetup command is holding the SRCU read lock, and the
> old table is never resumed, 'dmsetup resume' blocks too, and we have a
> deadlock.
>
> Steps to reproduce:
>
> 1. Create device with dm-era target
>
>    # dmsetup create eradev --table "0 1048576 era /dev/datavg/erameta 
> /dev/datavg/eradata 8192"
>
> 2. Suspend the device
>
>    # dmsetup suspend eradev
>
> 3. Load new table to device, e.g., to resize the device
>
>    # dmsetup load eradev --table "0 2097152 era /dev/datavg/erameta 
> /dev/datavg/eradata 8192"
>

Your sequence is faulty - you must always preload  new table before suspend.

Suspend&Resume should be absolutely minimal in its timing.

Also nothing should be allocating memory in suspend so that's why suspend has 
to be used after table line is fully loaded.

Regards


Zdenek