On Wed, Jul 27 2016 at 3:06pm -0400, Bart Van Assche <bart.vanassche@xxxxxxxxxxx> wrote: > On 07/27/2016 08:52 AM, Benjamin Marzinski wrote: > >if you look in drivers/md/dm-ioctl.c at do_resume(), device mapper > >internally does a suspend when you call resume with a new table loaded. > >That's when these suspends are happening. > > > >In the userspace tools, this happens in the DM_DEVICE_RESUME calls after > >dm_addmap_reload(), which loads the new table. These all happen in the > >domap() function. multipathd's only call to dm_addmap_reload() with flush = true is the ACT_RESIZE case in do_map(). > Thanks Ben for chiming in. As far as I can see md->map is only used > in the I/O submission path but not in the I/O completion path. So > why to suspend and resume I/O before activating the new map? Do you > think it would be safe to activate the new map without suspending > and resuming I/O? That is the DM state machine. Before a new table can be swapped in, via resume, the old map needs to first be suspended. I appreciate you just hunting for _why_ on this but questioning this aspect of userspace <-> kernel ioctl interface between multipathd and dm-mpath isn't productive. I'll focus on reviewing 4.7's flag management (if there is anywhere that queue_if_no_path and the saved_ variant are managed without holding the lock). Basically the 4.7 changes that reduced/dropped holding the m->lock in so many places could have allowed for some race that is causing must_push_back() to return false (in 4.7) when it previously return true (<= 4.6). -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
