On Mon, Dec 16, 2013 at 07:51:24AM -0500, Tejun Heo wrote: > On Mon, Dec 16, 2013 at 02:56:52PM +1100, Dave Chinner wrote: > > > What are you suggesting? Implementing separate warm and hot unplug > > > paths? That makes no sense whatsoever. Device hot unplug is just a > > > sub operation of general device unplug which should be able to succeed > > > whether the underlying device is failing IOs or not. > > > > I don't care. Trying to issue IO from an an IO error handling path > > where the device has just been removed is fundamentally broken. > > What? Have you even read the original message? IO error handling > path isn't issuing the IO here. The hot unplug operation is > completely asynchronous to the IO path. What's dead locking is not > the filesystem and IO path but device driver layer and hot unplug > path. IOs are not stalled.
In fact, this deadlock can be reproduced without hotunplug at all. If you initiate warm unplug and warm unplugging races with suspend/resume cycle, it'll behave exactly the same - the IOs from flushing in that scenario would succeed but IOs failing or not has *NOTHING* to do with this deadlock. It'd still happen. It's freezer behaving as a giant lock and other locks of course getting dragged into giant dependency loop. Can you please at least *try* to understand what's going on before throwing strong assertions? -- tejun -- 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/
