Re: LOCKDEP: 3.9-rc1: mount.nfs/4272 still has locks held!

[Jeff Layton]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/