On Fri, Apr 20, 2012 at 03:54:38AM +0100, Al Viro wrote: > and filp_close() would, if that turns out to be possible, call fput_nodefer() > instead of fput(). If we *do* have places where we need deferral in > filp_close() (and I'm fairly sure that any such place is a deadlock right > now), well, we'll need a variant of filp_close() sans the call of fput...() > and those places would call that, followed by full (deferring) fput(). BTW, some of those filp_close() are simply wrong - e.g. a big pile in drivers/media/video/cx25821/*.c should be fput(). And yes, we have at least some under mutex - binder_lock held by binder_ioctl(), which ends up doing binder_transaction() with its failure cleanup hitting close_filp(). On an arbitrary struct file. It *probably* doesn't deadlock on the spot, since binder_release() itself contains a deferral mechanism (perhaps they'd spotted the deadlock, perhaps there are other reasons to have it). -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
