[dm-devel] staged dm_internal_{suspend, resume} related changes for wider review

Mikulas Patocka mpatocka at redhat.com
Wed Nov 5 12:43:55 UTC 2014



On Tue, 4 Nov 2014, Mike Snitzer wrote:

> > > Hi
> > >
> > > As I said on irc - it is not correct to take a mutex from one syscall and
> > > drop the mutex from another syscall.
> > 
> > I didn't modify that aspect of dm_internal_suspend+resume.  I only extended
> > the interface to other targets via export.
> > 
> > > I hope Joe can use the bio prison to block bios while the pool is
> > > suspended.
> > 
> > We'll see.
> 
> Joe said today: "bio-prison thing isn't going to work, since we need the
> worker thread to complete as part of the [thin-pool] suspend".

If you block bios coming into the prison in pool's presuspend method 
(similar to this patch 
https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-for-3.19&id=2d616 
), the worker thread is still active, so it should process bios.

You can for example set the flag in the prison meaning that the prison is 
suspended and then call dm_internal_suspend immediatelly followed by 
dm_internal_resume - that will clear in-progress bios and prevent new bios 
from coming in (and we don't need to change dm_internal_suspend and 
dm_internal_resume to become so big).

> And the following patch fixes the locking issue you raised:

... it complicates the generic code even more than before.

Mikulas




More information about the dm-devel mailing list