Re: dm: bind new table before destroying old

[Kiyoshi Ueda <k-ueda@ct.jp.nec.com>]

Hi Alasdair,

On 11/11/2009 10:16 AM +0900, Alasdair G Kergon wrote:
> Questions:
> 
>   Do all the targets correctly flush or push back everything during a
>   suspend (including workqueues)?
> 
>   Do all the targets correctly sync to disk all internal state that
>   needs to be preserved during a suspend?
> 
> In other words, in the case of an already-suspended target, the target
> 'dtr' functions should only be freeing memory and other resources and
> not causing I/O to any of the table's devices.
> 
> All targets are supposed to be behave this way already, but please
> would you check the targets with which you are familiar anyway?

I have checked multipath and found 2 issues.

multipath flushes all normal I/Os before suspend completion.
But multipath doesn't flush some workqueues until the table destruction.
Also, such works can be added and kicked even after suspend completion
through message ioctl.

For example, [de]activate_path() and trigger_event() are such works.
"reinstate path" message will trigger activate_path() work and
activate_path() may send some SCSI commands (through pg_init()) to
the underlying devices of the already-suspended target.
(Also, "fail_path" message will trigger deactivate_path() work
 and deactivate_path() may abort the underlying device's queue
 of the already-suspended target.)

So moving the table destruction after the resume (in your another
patch) could/might cause some race problems between new_table and
old_table if they have a same underlying device.
(e.g. pg_init() race, aborting queue after resume.)

I believe dm-mpath needs to flush such workqueues in postsuspend.
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
  Or/And 
  - Targets must not kick any work influencing external themselves
    in their message ioctl handlers.

Thanks,
Kiyoshi Ueda