On Monday November 7, [email protected] 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
