Message-ID: <45B085AA.70109@drzeus.cx>
Date: Fri, 19 Jan 2007 09:47:38 +0100
From: Pierre Ossman <drzeus-list@drzeus.cx>
User-Agent: Thunderbird 1.5.0.9 (X11/20061223)
MIME-Version: 1.0
To: Alex Dubov <oakad@yahoo.com>
CC: linux-kernel@vger.kernel.org
Subject: Re: mmc: correct semantics of the mmc_host_remove
References: <20070119015037.8318.qmail@web36709.mail.mud.yahoo.com>
In-Reply-To: <20070119015037.8318.qmail@web36709.mail.mud.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1438
Lines: 34

Alex Dubov wrote:
> Greetings.
>
> It appears to me that under certain circumstances mmc layer will issue requests to the host after
> mmc_host_remove returns. This happens, for example, in tifm_sd driver because mmc_host may be
> removed mid-transfer, as the socket shall be freed for possible reuse by different media type.
> Currently, the only solution is to sleep a little somewhere after mmc_remove_host but before
> mmc_free_host. I think the correct way to handle the situation is to ensure that mmc_host is never
> accessed by the mmc layer after mmc_remove_host returns.
>
>   

That shouldn't be possible. Are you using the block queue fixes I wrote?
Otherwise you will get problems like this.

Basically, when you call mmc_host_remove(), it will remove all card
devices. That shouldn't complete until all card drivers have released
control of the card. At that point there is no one else accessing the
device. If you see something else, then we have a bug somewhere.

Rgds

-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/