linux-kernel - Fixing the main programmer thinko with the device model

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1206373188.3494.36.camel@localhost.localdomain>
Date:	Mon, 24 Mar 2008 10:39:48 -0500
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Greg KH <greg@...ah.com>, Kay Sievers <kay.sievers@...y.org>,
	"Van De Ven, Arjan" <arjan.van.de.ven@...el.com>,
	Al Viro <viro@...IV.linux.org.uk>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Fixing the main programmer thinko with the device model

Having just spent the weekend tracking two separate driver model
problems through SCSI, I believe the biggest trap everyone falls into
with the driver model (well, OK, at least with SCSI) is to try to defer
a callback to the device ->release routine without realising that
somewhere along the callback path we're going to drop a reference to the
device.

You can do this very inadvertently:  One developer didn't realise
bsg_unregister_queue() released a ref, and another didn't realise that
transport_destroy_device() held one.

The real problem is that it's fantastically easy to do this ... it's not
at all clear which of the cleanup routines actually release references
unless you dig down into them and it's very difficult to detect because
all that happens is that devices don't get released when they should,
which isn't something we ever warn about.

So, what I was wondering is:  is there any way we can reliably detect
and warn when someone does this.  Could something like lockdep (although
I can't really see how dynamic detection will work because the device
->release routine is never called) or a static code analysis tool like
sparse be modified to detect the unreleaseable references?

James

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