[dm-devel] [RFC][PATCH 0/3] dm-raid1: fix deadlock at suspend after suspend was interrupted

[Takahiro Yasui]

Hi Ueda-san,

Kiyoshi Ueda wrote:
> On 01/21/2010 07:58 AM +0900, Takahiro Yasui wrote:
>> Kiyoshi Ueda wrote:
>>> On 01/20/2010 05:40 AM +0900, Takahiro Yasui wrote:
>>>> Introduce a target handler, cancel_presuspend, to cancel status changes
>>>> done by a target specific presuspend handler.
>>> How about using ->resume as a cancelling method?
>>> Though you have to audit existing targets' ->resume handler,
>>> I think it's better idea than adding another target handler
>>> just for this purpose.
> <snip>
>> I'm afraid that we need to modify each target's resume handler so that
>> they work properly even after processing presuspend handler but before
>> postsuspend handler.
>>
>> Please let me know if there is some oversight.
> 
> There is no oversight.
> Perhaps I should have said 'audit (and modify if necessary)'.
> 
> If auditing and modifying all targets are difficult, I don't object
> your approach which adds ->cancel_presuspend.
> But ->cancel_presuspend should be a subset of ->resume and it should
> make some code duplication.  If ->resume can always restore target state
> correctly, it may avoid such duplication.
> 
> Althrough I'm not sure the following idea is really reasonable,
> I think it should be worth to consider about it:
>   When ->postsuspend is called and the device is really suspended,
>   DMF_SUSPENDED flag is set in md->flags.
>   So targets' ->resume handler can use it to check ->postsuspend
>   had been called or not.

Hmm. It looks good idea.

By exporting dm_suspended(), targets running in kernel space, can get
the current status and choose actions to cancel state changes done
in presuspend(). One execption is dm-log-userspace. It calls user space
functions. So other solution is needed.

I will try to update this patch set according to your suggestions.

Thanks,
Taka