From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Pierre Ossman <drzeus-list@drzeus.cx>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: device_del() and references
Date: Tue, 14 Nov 2006 11:24:09 +0000 [thread overview]
Message-ID: <20061114112409.GB15340@flint.arm.linux.org.uk> (raw)
In-Reply-To: <455972D0.1030407@drzeus.cx>
On Tue, Nov 14, 2006 at 08:40:00AM +0100, Pierre Ossman wrote:
> When a card driver has obtained a reference to a card, what makes sure
> we do not destroy that card from under its feet?
Essentially, the driver model. (see the answer to your paragraph below.)
> I suspect that device_del() doesn't return until remove() has been
> called and that our requirement is that the card driver must have
> released all references to the card before its remove routine exits.
Your sentence is confusing - which "remove()" are you talking about
here? If you're talking about mmc_blk_remove() then that's correct.
> If so, then there is the risk of a race in mmc_block. What guarantees
> that the request handler isn't running in parallel with the remove
> function? Again, I suspect that del_gendisk() might grab the queue lock,
> but as there might be stuff left in the queue, this seems insufficient.
Hmm, not sure here. I think you might be right, but the block layer is
*extremely* finaky when it comes to removing stuff.
In short, I don't know - I've forgotten quite a bit about the low level
block interface with MMC since it's something I did once and only once.
Maybe Jens has some ideas?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
prev parent reply other threads:[~2006-11-14 11:24 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-14 7:40 device_del() and references Pierre Ossman
2006-11-14 11:24 ` Russell King [this message]
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=20061114112409.GB15340@flint.arm.linux.org.uk \
--to=rmk+lkml@arm.linux.org.uk \
--cc=drzeus-list@drzeus.cx \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.