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]

Date:	Wed, 6 Mar 2013 07:59:01 -0800
From:	Mandeep Singh Baines <msb@...omium.org>
To:	Jeff Layton <jlayton@...hat.com>
Cc:	Ingo Molnar <mingo@...nel.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, Mar 6, 2013 at 4:06 AM, Jeff Layton <jlayton@...hat.com> wrote:
> 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...
>

In general, holding a lock and freezing can cause a deadlock if:

1) you froze via the cgroup_freezer subsystem and a task in another
cgroup tried to acquire the same lock
2) the lock was needed later is suspend/hibernate. For example, if the
lock was needed in dpm_suspend by one of the device callbacks. For
hibernate, you also need to worry about any locks that need to be
acquired in order to write to the swap device.
3) another freezing task blocked on this lock and held other locks
needed later in suspend. If that task were skipped by the freezer, you
would deadlock

You will block/prevent suspend if:

4) another freezing task blocked on this lock and was unable to freeze

I think 1) and 4) can happen for the NFS/RPC case. Case 1) requires
cgroup freezer. Case 4) while not causing a deadlock could prevent
your laptop/phone from sleeping and end up burning all your battery.
If suspend is initiated via lid close you won't even know about the
failure.

Regards,
Mandeep

> --
> 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/