Milan Broz <mbroz@xxxxxxxxxx> wrote: > On 11/11/2009 04:11 PM, Alasdair G Kergon wrote: > > On Wed, Nov 11, 2009 at 03:56:05PM +0900, Kiyoshi Ueda wrote: > >> I believe dm-mpath needs to flush such workqueues in postsuspend. > > > > Yes - should be an easy change. > > similar problem is probably in crypt target, I'll check it later. > > >> Also, we need something to block message ioctl to suspended device. > > > >> As for the message ioctl, I don't have any good idea, but... > >> - Reject message ioctl to suspended device in dm-ioctl > > > > I think the crypt target expects to be able to do this to manipulate > > the in-core encryption key. > > yes, crypt target must be able to process messages when in suspended state. > I hit a issue like Kiyoshi described of the target_message (multipath_message) generating new work while dev_remove is trying complete in parallel with calling fail_path / reinstate_path. I added two accessor functions to dm-table.c (dm_table_md_suspended and dm_table_md_freeing). I am calling both functions from multipath_message to return early if we are in one of these states. Depending on the usage model of the other targets message functions dm_table_md_freeing (or a new function dm_table_md_deleting) could be called in target_message instead of each targets message function. The test runs using a mutex and the alternate option of using spin_lock are currently passing I will post tomorrow the series for comments. I also tested suspend / resume in parallel with calling fail_path / reinstate_path. -andmike -- Michael Anderson andmike@xxxxxxxxxxxxxxxxxx -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
