lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <45B085AA.70109@drzeus.cx>
Date:	Fri, 19 Jan 2007 09:47:38 +0100
From:	Pierre Ossman <drzeus-list@...eus.cx>
To:	Alex Dubov <oakad@...oo.com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: mmc: correct semantics of the mmc_host_remove

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ