> Thanks for your comments. I agree we should lock while setting > dtr_in_progress, You can use spinlock when you read or write the variable. Or - without locking, you can use memory barriers - put smp_mb() after you write dtr_in_progress and before you read it. Use ACCESS_ONCE(m->dtr_in_progress) in the if statement where you read dtr_in_progress. Mikulas > I think I overlooked it as its handled in process_queued_ios as well. We > looked into handling this in wait_for_pg_init_completion() but checking > for pg_init_required here will not help as well ( until we prevent > setting pg_init_required while pg_init_in_progress is set ). Here due to > SCSI_DH_RETRY on mode_select, pg_init_done will set the pg_init_required > as activation needs to be retried under normal circumstances. But it > completely differs when multipath target is being destroyed. > Apparently I didn't see any pending_ios in our test while this is > happening. Just path activations are held up since controller was > returning 5/91/36 CC's. With this condition either one of > pg_init_required or pg_init_in_progress flags are set all the time. > Hannes patch will take care of preventing queueing of IO's when > pg_init_in_progress is set, but currently running activation commands > will not return until controller returns SUCCESS on mode_select. > > -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
