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]
Date:	Tue, 4 Mar 2008 12:30:41 -0800
From:	David Brownell <david-b@...bell.net>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Pierre Ossman <drzeus-mmc@...eus.cx>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	Zdenek Kabelac <zdenek.kabelac@...il.com>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: Bugs in MMC [was: [Bug 10030] Suspend doesn't work when SD card is inserted]

On Tuesday 04 March 2008, Alan Stern wrote:
> On Tue, 4 Mar 2008, David Brownell wrote:
> 
> > > I don't understand this comment.  Suppose a card was inserted while the 
> > > system was hibernating.  If the core didn't reprobe, when would that 
> > > card be discovered?
> > 
> > The host controller would tell the core to check for a card, exactly
> > like it does at all other times.
> 
> But how would the host controller know to do that?  Isn't card 
> insertion detection often driven by interrupts?  If a card is 
> inserted while the computer is off, no interrupt will be generated.

I'm talking about Real Suspend States (tm), not hibernation.
The systems in question tend to not support hibernation.

In particular:  system sleep states where IRQs work ... that's a
common way for non-x86 platforms to work.


> > That's the natural alternative to having the MMC core assume that card
> > detection was broken in low power states, so that the core needed to
> > forcibly remove the cards before suspend, and reprobe during resume
> > processing.
> 
> Is that the assumption the MMC core was really making?  Are you sure it 
> wasn't assuming something else (perhaps equally as bad)?

On the systems I was looking at, that assumption seems equivalent to
what the latest MMC core is assuming.  (I think this came as part of
the rewrite/refactoring a while back.)  But since the assumptions aren't
documented as such, you could say all guesses are equal.  ;)


> > Having the MMC core make such needless assumptions can cause problems
> > for the upper layers, including filesystems.
> 
> What's wrong with a superfluous probe at resume time, besides the waste 
> of a few milliseconds?

I'm more concerned with the undesirable removal of devices at suspend
time ... ones with mounted filesystems etc.

- Dave

--
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