[dm-devel] [PATCH 0/2] dm era: avoid deadlock when swapping table with dm-era target

[Nikos Tsironis]

On 1/19/23 14:58, Zdenek Kabelac wrote:
> Dne 19. 01. 23 v 10:36 Nikos Tsironis napsal(a):
>> On 1/18/23 18:28, Mike Snitzer wrote:
>>> On Wed, Jan 18 2023 at  7:29P -0500,
>>> Nikos Tsironis <ntsironis at arrikto.com> wrote:
>>>
>>>
>>
>> Hi Mike,
>>
>> Thanks for the quick reply.
>>
>> I couldn't find this constraint documented anywhere and since the
>> various DM targets seem to allow message operations while the device is
>> suspended I drew the wrong conclusion.
> 
> Hi  Nikos
> 
> 
> Some notes from lvm2 developer - we work with these constrains:
> 
> DM target should  not need to allocate bunch of memory while suspended (target should preallocated pool of some memory if it really needs to do it in this case).
> 
> DM target should check and allocate everything it can in the 'load' phase and error as early as possibly (so loaded inactive table can be cleared/dropped and 'resume' target can continue its work).
> 
> Error in suspend phase is typically the last moment -we can handle failure 'somehow'.
> 
> Handling failure in 'resume' is a can of worm with no good solution - so resume really should do as minimal as possible and should work with everything already prepared from load & suspend.
> 
> 'DM status/info'  should work while device is suspend - but no allocation should be needed in this case to produce result.
> 
> Sending messages to a suspended target should not be needed - if it is - it should be most likely solved via  'table reload' change (target design change).
> 
> Loading to the inactive table slot should not be break anything for the active table slot  (table clear shall resume at suspend point).
> 
> Surely the list could go longer - but these basics are crucial.
> 

Hi Zdenek,

That's great information! Thanks a lot for sharing it.

Regards,
Nikos