linux-kernel - Re: [PATCH 7/7] driver-core : convert semaphore to mutex in struct class

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:	Fri, 18 Jan 2008 00:26:26 +0100
From:	Jarek Poplawski <jarkao2@...il.com>
To:	Dave Young <hidave.darkstar@...il.com>
Cc:	Alan Stern <stern@...land.harvard.edu>, Greg KH <gregkh@...e.de>,
	stefanr@...6.in-berlin.de, David Brownell <david-b@...bell.net>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 7/7] driver-core : convert semaphore to mutex in struct
	class

On Thu, Jan 17, 2008 at 09:31:55PM +0100, Jarek Poplawski wrote:
> On Thu, Jan 17, 2008 at 02:57:36PM -0500, Alan Stern wrote:
> > On Thu, 17 Jan 2008, Jarek Poplawski wrote:
> > 
> > > On Thu, Jan 17, 2008 at 10:16:30AM -0500, Alan Stern wrote:
> > > > On Thu, 17 Jan 2008, Dave Young wrote:
> > > > 
> > > > > > Your meaning isn't clear.  Do you mean that your patch doesn't generate
> > > > > > any lockdep warnings at all?  Or do you mean that it generates a single
> > > > > > lockdep warning at boot time and then no more warnings afterward?
> > > > > 
> > > > > I means the latter one.
> > > > 
> > > > That's very bad.
> > > > 
> > > > For each type of violation, lockdep only gives one error message.  So
> > > > the fact that you get one message at boot time and then no more doesn't
> > > > mean the code is almost right -- it probably means the code has lots of
> > > > errors and you're seeing only the first one.
> > > 
> > > I hope it's better than this: lockdep really stops checking after first
> > > warning, but I've understood from David's description that after fixing
> > > this one place lockdep seems to be pleased.
> > 
> > That isn't what Dave said above; he said that lockdep produces a single
> > warning at bootup.  If he did mention anything about one place being
> > fixed up or lockdep being pleased, it was a while back and I've lost 
> > track of it.
> > 
> > If I recall correctly the nature of the warning was that a method
> > routine for one class (called with the class's mutex held) was creating
> > a second class and locking that class's mutex.  In principle this is
> > perfectly legal and should be allowed for arbitrary depths of nesting,
> > even though it is the sort of thing lockdep is currently unable to
> > handle.
> 
> You are definitely right! After first reading Dave's description I got
> it the same way, but after re-reading I probably was misled with this
> "thus"! Only now I've had a look at this warning and there is really
> mutex_lock_nested(). Sorry Alan!

But, on the other hand, mutex_lock() is really mutex_lock_nested(), and
after second checking this lockdep warning from Jan. 3, it seems
impossible it was get after this patch...

Dave, could you please answer with full sentence if there is any lockdep
warning possible after applying these 1-7/7 patches, and if so, attach
current warning? Otherwise, I'll have apologized for this everybody from
the list soon!

Jarek P.
--
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/