mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@SteelEye.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg KH <greg@kroah.com>,
	Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] driver core: remove unneeded klist methods
Date: Sun, 22 Jan 2006 10:30:05 -0600	[thread overview]
Message-ID: <1137947405.4058.10.camel@mulgrave> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0601202321430.14739-100000@netrider.rowland.org>

On Fri, 2006-01-20 at 23:37 -0500, Alan Stern wrote:
> The problem is that put_device must not be called while holding a
> spinlock.  This has always been true, but we only started noticing it
> recently when Greg added a might_sleep.  Your klist method would call
> put_device while holding the klist's spinlock.

Right, but we currently have this problem everywhere throughout the
code.  Avoiding it by not taking references doesn't look to be the right
way to go because then we have to dismantle the whole refcounting
infrastructure.

> Not so.  A device structure can't be freed before device_del returns, and
> the patch makes device_del call klist_remove instead of klist_del.  The
> difference between the two is that klist_remove blocks until all iterators
> have finished using the klist node.  New iterators can't start using it
> because the routine removes the node from the klist.

Sorry ... forgot to mention that part ... the change from _del to
_remove ties us up with a wait for the list to actually remove.  This is
potentially dangerous because you're waiting on events you don't
control.  Additionally, next_child isn't refcounted, so it could
potentially disappear out from under you.

James



  reply	other threads:[~2006-01-22 16:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-20 16:39 Alan Stern
2006-01-20 19:19 ` James Bottomley
2006-01-21  4:37   ` Alan Stern
2006-01-22 16:30     ` James Bottomley [this message]
2006-01-22 22:13       ` Alan Stern
2006-01-23 21:07       ` Alan Stern

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=1137947405.4058.10.camel@mulgrave \
    --to=james.bottomley@steeleye.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /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

all inboxes | Powered by JetHome®