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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox