public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Greg KH <greg@kroah.com>, Kay Sievers <kay.sievers@vrfy.org>,
	"Van De Ven, Arjan" <arjan.van.de.ven@intel.com>,
	Al Viro <viro@ZenIV.linux.org.uk>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Fixing the main programmer thinko with the device model
Date: Mon, 24 Mar 2008 10:39:48 -0500	[thread overview]
Message-ID: <1206373188.3494.36.camel@localhost.localdomain> (raw)

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



             reply	other threads:[~2008-03-24 15:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-24 15:39 James Bottomley [this message]
2008-03-24 17:58 ` Fixing the main programmer thinko with the device model Greg KH
2008-03-24 18:08   ` James Bottomley
2008-03-25  9:57     ` Andi Kleen
2008-03-26  4:16       ` Greg KH
2008-03-26  5:07         ` Kay Sievers
2008-03-26  5:23           ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1206373188.3494.36.camel@localhost.localdomain \
    --to=james.bottomley@hansenpartnership.com \
    --cc=arjan.van.de.ven@intel.com \
    --cc=greg@kroah.com \
    --cc=kay.sievers@vrfy.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@ZenIV.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox