[dm-devel] Panic in multipath's trigger_event function

[goggin, edward]

Trigger_event() has paniced maybe 3 or 4 times now, with one
simple dd process running while serially rebooting both
(active and passive) service processors of a two service
processor EMC CLARiion as part of a non-destructive
upgrade (NDU) of ucode.

I think the problem is that when the old table/map for a multipath
mapped device is swapped for a new one by dm_swap_table(), it
is possible that the trigger_event work_struct field of the multipath
structure for the old map is actively queued to a cpu work queue
when table_destroy() sets about to de-allocate the memory for the
old table, the dm_target, and calls the multipath destructor
multipath_dtr() to de-allocate the multipath structure memory.  If
any of these things happen before the work queue entry is serviced,
trigger_event() will refer to stale dm_table, dm_target, or multipath
structure memory.  This problem does not happen with the 
process_queued_ios() event callback because these entries are
flushed and waited for by dm_suspend() before dm_resume() calls
dm_swap_table().

In this case, the panic occurs when trigger_event() de-references
the ti struct dm_target field of the old multipath structure because
the dm_target structure memory for the multipath target was
de-allocated via vfree() and the reference to the ti field of the
multipath structure is to unmapped kernel memory.

Several solutions come to mind, namely (1) using reference counts
for the multipath structure and (2) flushing the default work queue
in the multipath destructor.  I've included a patch for the latter in this
email.

 <<dm-mpath c.patch>> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dm-mpath c.patch
Type: application/octet-stream
Size: 329 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20050222/eec75211/attachment.obj>