linux-kernel - Re: Lockdep false positive in sysfs

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: <878vhg3mrh.fsf@xmission.com>
Date:	Fri, 27 Apr 2012 14:09:22 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Tejun Heo <tj@...nel.org>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	Peter Zijlstra <peterz@...radead.org>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: Lockdep false positive in sysfs

Tejun Heo <tj@...nel.org> writes:

> On Fri, Apr 27, 2012 at 02:27:26PM -0400, Alan Stern wrote:
>> Which do you prefer: temporarily dropping the lockdep annotation, or
>> deferring the work to the per-task work queue?  Note that these "flush
>> before returning to userspace" things aren't in the kernel yet.
>
> It's about lockdep.  Let's not spill out to other areas unnecessarily.
> I'd much prefer just working around lockdep annotation.

It is also about a locking scheme that makes analysis hard.

Doing something so we don't have false lockdep warnings is good
so people can concentrate on things that are clearly problems.

However it would be nice if we could sort out the locking so that it
isn't so tricky that neither lockdep nor sparse can figure it out.

I have the sneaking suspicion that idioms that tangle up our automatic
tools are also idioms that are likely to result in maintenance problems
at some point.

Another possibility to to look at the situation and realize that pci has
a maxium depth of 256 (bus numbers). And that usb also has a maxium
depth of I believe 256 ( If I read it right usb hubs are transparent to
usb enumeration so the maximum depth is the maximum number of usb ids
and I think the usb id is a 8 bit number).  I don't think anything else
even nests so deeply.  So it may be reasonable to declare an array of
256 or perhaps 1024 lockdep keys and limit the device tree when lockdep
is enabled to 1024 layers deep.

At which point we are at a point where lockdep can actually analyze the
behavior.

I don't mind the attitude we are clever careful programmers we can
handle the complexity and we can get away without the tool help us, but
I would much rather see the attitude that we are clever careful
programmers and we can figure out how to make the tool help us instead
of just ignoring it.

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