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

[Zdenek Kabelac]

Dne 03. 12. 21 v 15:42 Nikos Tsironis napsal(a):
> On 12/2/21 5:41 PM, Zdenek Kabelac wrote:
>> 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.
>>>
> Hi Zdenek,
>
> Thanks for the feedback. There doesn't seem to be any documentation
> mentioning that loading the new table should happen before suspend, so
> thanks a lot for explaining it.
>
> Unfortunately, this isn't what causes the deadlock. The following
> sequence, which loads the table before suspend, also results in a
> deadlock:
>
> 1. Create device with dm-era target
>
>    # dmsetup create eradev --table "0 1048576 era /dev/datavg/erameta 
> /dev/datavg/eradata 8192"
>
> 2. 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"
>
> 3. Suspend the device
>
>    # dmsetup suspend eradev
>
> 4. Retrieve the status of the device. This blocks for the reasons I
>    explained in my previous email.
>
>    # dmsetup status eradev


Hi

Querying 'status' while the device is suspend is the next issue you need to 
fix in your workflow.

Normally 'status' operation may need to flush queued IO operations to get 
accurate data.

So you should query states before you start to mess with tables.

If you want to get 'status' without flushing - use:   'dmsetup status --noflush'.


> 5. Resume the device. This deadlocks for the reasons I explained in my
>    previous email.
>
>    # dmsetup resume eradev
>
> 6. The dmesg logs are the same as the ones I included in my previous
>    email.
>
> I have explained the reasons for the deadlock in my previous email, but
> I would be more than happy to discuss them more.
>

There is no bug - if your only problem is 'stuck'  status while you have 
devices in suspended state.

You should NOT be doing basically anything while being suspend!!

i.e. imagine you suspend 'swap' device and while you are in suspened state 
kernel decides to swap memory pages - so you get instantly frozen here.

For this reason lvm2 while doing  'suspend/resume' sequance preallocates all 
memory in front of this operation - does very minimal set of operation between 
suspend/resume to minimize also latencies and so on.

Clearly if you suspend just some 'supportive'  disk of yours - you likely are 
no in danger of blocking your swap - but the 'status --noflush' logic still 
applies.


Regards

Zdenek