linux-kernel - Re: [PATCH 01/12] Use mutex instead of semaphore in driver core

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:	Sat, 29 Dec 2007 22:42:47 -0800
From:	David Brownell <david-b@...bell.net>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Dave Young <hidave.darkstar@...il.com>, Greg KH <gregkh@...e.de>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCH 01/12] Use mutex instead of semaphore in driver core

On Saturday 29 December 2007, Alan Stern wrote:
> lockdep warns whenever a task acquires a mutex while holding another
> mutex of the same kind (that is, the same member in another structure
> of the same type).  But there are lots of places where the kernel needs
> to acquire dev->sem for one device while already holding
> dev->parent->sem.

Not just devices.  I've seen the same issue with genirq when
enabling or disabling wakeup:  while holding irq_desc[354].lock
it must also acquire the parent IRQ's irq_desc[37].lock so it
can update that parent IRQ's wake flag ... because the wake
signal goes from the child up to the parent up to the logic
that kicks the clock framework and thence the CPU, and software
must enable at least some of those paths by hand.

And lockdep says "[ INFO: possible recursive locking detected ]".
But the analysis is "ignore that one, it's a false alarm".

> There's no way to remove these, which means there's 
> no way to prevent lockdep from issuing a warning.

There may be no *efficient* way to do that.  If it tracked
every lock individually these false alarms could go away;
but that would increase the overhead to create and destroy
such locks too.

Such tradeoffs are what make it Engineering, not Science.  ;)

- Dave

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