linux-kernel - Re: Semphore -> mutex in the device tree

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: <Pine.LNX.4.44L0.0804181014170.5443-100000@iolanthe.rowland.org>
Date:	Fri, 18 Apr 2008 10:27:02 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	Kernel development list <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>,
	Paul E McKenney <paulmck@...ux.vnet.ibm.com>
Subject: Re: Semphore -> mutex in the device tree

On Fri, 18 Apr 2008, Peter Zijlstra wrote:

> > Even so there is a potential for trouble.  I don't know of any concrete
> > examples like this in the kernel, but they might exist.  Suppose a
> > driver keeps a private mutex associated with each device it manages.  
> > Normally the device's lock would be acquired first and the private
> > mutex second.  But there could be places where the driver acquires a
> > child device's lock while holding the parent's mutex; this would look
> > to lockdep like a violation.
> 
> So lockdep cares about classes and the hierarchy of thereof; so given
> your example:
> 
>    parent_tree_level
>      child_tree_level
>        device_lock
> 
> Its perfectly fine to take a lock from 'parent_tree_level' and then a
> lock from 'device_lock', skipping the class in the middle - as long as
> you thereafter never acquire a lock from it.
> 
> So given a pre-determined class hierarchy, you're not required to take
> all locks in that hierarchy; as long as you always go down. If you ever
> take a lock so that moves up in the hierarchy you're in trouble.

We must be talking at cross purposes.  Are classes and subclasses all 
that lockdep looks at?

Let's take a simpler example.  Suppose driver D's probe routine 
registers a child device.  Then we have:

	Subsystem:		Register device A with driver core

	Driver core:		Lock device A with NESTING_PARENT
				Call D:probe()

	D:probe():		Register device B with driver core
				as a child of A

	Driver core:		Lock device B with NESTING_PARENT
				Call E:probe()

(where E is the appropriate driver for B).  Is this a lockdep 
violation?  Both A and B are locked with the same nesting level, 
because they are locked by the same code in the driver core, but 
one is the parent of the other in the device tree.


Or maybe I misunderstood, and you're proposing to use a node's level in
the tree as its lockdep nesting level.  In that case, consider this
example.  Suppose driver D associates a private mutex M with each of
its devices.  Suppose D is managing device A at level 4 and device B at
level 5.  Then we might have:

	D:		Lock device B at level 5
	D:		Lock B's associated M

(which tells lockdep that M comes after level 5), together with

	D:		Lock device A at level 4
	D:		Lock A's associated M
	D:		Lock A's child at level 5

Won't this then be a lockdep violation (since M is now locked before a
device at level 5)?

Alan Stern

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