[dm-devel] dm-mq and end_clone_request()
Mike Snitzer
snitzer at redhat.com
Wed Jul 27 19:54:27 UTC 2016
On Wed, Jul 27 2016 at 3:06pm -0400,
Bart Van Assche <bart.vanassche at sandisk.com> 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).
More information about the dm-devel
mailing list