On 10/17/2013 08:53 PM, Mike Snitzer wrote:
Thanks for reporting this. Much appreciated. More comments below.
On Thu, Oct 17 2013 at 1:31pm -0400,
Merla, ShivaKrishna <ShivaKrishna.Merla@xxxxxxxxxx> wrote:
Whenever multipath_dtr is happening, we should prevent queueing any further path
activation work. There was a kernel panic where after pg_init_done() decrements
pg_init_in_progress to 0, wait_for_pg_init_completion call assumes there are no
more pending path management commands. But if pg_init_required is set by
pg_init_done call due to retriable mode_select errors , then process_queued_ios()
will again queue the path activation work. If free_multipath call has been
completed by the time activate_path work is called, kernel panic was seen on
accessing multipath members.
Your locking looks suspect to me, see comment inlined below multipath_dtr
But shouldn't we just train multipath_wait_for_pg_init_completion() to
look at m->pg_init_required? Have it wait for both pg_init_required and
pg_init_in_progress to be zero? We'd also have to audit that
pg_init_required cannot be set while pg_init_in_progress.
Hmm.
We _could_ try to resolve it by pushing I/O back onto the request queue
(cf my earlier post 'requeue I/O during pg_init').
I was hoping to excite some comments with that, but seems to be my fate
nowadays to send out patches with no reply.
Anyway, maybe this will be giving it some more attention.
It definitely would avoid this problem, by virtue of not having to queue
I/O internally during pg_init, so we could easily tear down the queue.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@xxxxxxx +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
