On Monday November 7, heiko.carstens@xxxxxxxxxx wrote: > > > Ok, I'll dust it off, make sure it seems to work (at the time I first > > > wrote it, I think it caused 'md' to deadlock) and submit it. > > > > > > NeilBrown > > > > > > > For your consideration and testing (it works for me, but I'd like to > > see it tested a bit more heavily in a variety of configurations). > > Works fine for me. Thank you! > Thanks for the feed-back. > However I noticed another recursive call while dumping all call traces: > ... > [<00000000001e1952>] zfcp_scsi_command_async+0xf6/0x1c4 > [<000000000013cd6a>] scsi_dispatch_cmd+0x1ae/0x37c > [<0000000000143dc4>] scsi_request_fn+0x1dc/0x390 > [<000000000012f65a>] generic_unplug_device+0x2a/0x38 > [<0000000000181262>] dm_table_unplug_all+0x42/0x58 > [<000000000017e598>] dm_unplug_all+0x2c/0x44 > [<0000000000181262>] dm_table_unplug_all+0x42/0x58 > [<000000000017e598>] dm_unplug_all+0x2c/0x44 > [<00000000000782aa>] block_sync_page+0x4e/0x68 > [<00000000000514f8>] sync_page+0x48/0x68 > [<00000000002ab36e>] __wait_on_bit+0x9a/0xe0 > ... Hmm.. This (and a similar one with ->issue_flush_fn) would be a lot harder to unwind, but it is also much more benign. These sorts of calls should always be very shallow. I don't think there is anything useful that can be done here, and I'm not convinced there is a real problem. It is worth noticing it and keeping it in mind though. Thanks, NeilBrown -- dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
