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:	Thu, 17 Jan 2008 14:57:36 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Jarek Poplawski <jarkao2@...il.com>
cc:	Dave Young <hidave.darkstar@...il.com>, 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, 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.

> On the other hand, according to Greg the code is OK, so if there are any
> such warnings they simply have to be false! (...Unless you trust lockdep
> more?!)

It's not a matter of trust or of false warnings.  People shouldn't 
tolerate any lockdep warnings at all; otherwise they will start to 
ignore the valid ones.

Alan Stern

P.S.: Just because Greg says the code is okay doesn't mean it will 
please lockdep -- it doesn't even mean the code really is okay!  I've 
known Greg to make an occasional mistake.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ