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 -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
