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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130306070631.0f326014@tlielax.poochiereds.net>
Date:	Wed, 6 Mar 2013 07:06:31 -0500
From:	Jeff Layton <jlayton@...hat.com>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Mandeep Singh Baines <msb@...omium.org>, Tejun Heo <tj@...nel.org>,
	"J. Bruce Fields" <bfields@...ldses.org>,
	"Myklebust, Trond" <Trond.Myklebust@...app.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Ming Lei <ming.lei@...onical.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: LOCKDEP: 3.9-rc1: mount.nfs/4272 still has locks held!

On Wed, 6 Mar 2013 10:09:14 +0100
Ingo Molnar <mingo@...nel.org> wrote:

> 
> * Mandeep Singh Baines <msb@...omium.org> wrote:
> 
> > On Tue, Mar 5, 2013 at 5:16 PM, Tejun Heo <tj@...nel.org> 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@...hat.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/