On Wed, 6 Mar 2013 10:09:14 +0100 Ingo Molnar <mingo@xxxxxxxxxx> wrote: > > * Mandeep Singh Baines <msb@xxxxxxxxxxxx> wrote: > > > On Tue, Mar 5, 2013 at 5:16 PM, Tejun Heo <tj@xxxxxxxxxx> wrote: > > > On Tue, Mar 05, 2013 at 08:05:07PM -0500, J. Bruce Fields wrote: > > >> If it's really just a 2-line patch to try_to_freeze(), could it just be > > >> carried out-of-tree by people that are specifically working on tracking > > >> down these problems? > > >> > > >> But I don't have strong feelings about it--as long as it doesn't result > > >> in the same known issues getting reported again and again.... > > > > > > Agreed, I don't think a Kconfig option is justified for this. If this > > > is really important, annotate broken paths so that it doesn't trigger > > > spuriously; otherwise, please just remove it. > > > > > > > Fair enough. Let's revert then. I'll rework to use a lockdep annotation. > > > > Maybe, add a new lockdep API: > > > > lockdep_set_held_during_freeze(lock); > > > > Then when we do the check, ignore any locks that set this bit. > > > > Ingo, does this seem like a reasonable design to you? > > Am I reading the discussion correctly that the new warnings show REAL potential > deadlock scenarios, which can hit real users and can lock their box up in entirely > real usage scenarios? > > If yes then guys we _really_ don't want to use lockdep annotation to _HIDE_ bugs. > We typically use them to teach lockdep about things it does not know about. > > How about fixing the deadlocks instead? > I do see how the freezer might fail to suspend certain tasks, but I don't see the deadlock scenario here in the NFS/RPC case. Can someone outline a situation where this might end up deadlocking? If not, then I'd be inclined to say that while this may be a problem, the warning is excessive... -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
