linux-kernel - Re: Bugs in MMC [was: [Bug 10030] Suspend doesn't work when SD card is inserted]

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: <Pine.LNX.4.44L0.0803061528460.9174-100000@iolanthe.rowland.org>
Date:	Thu, 6 Mar 2008 15:33:41 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Pavel Machek <pavel@....cz>
cc:	David Brownell <david-b@...bell.net>,
	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 Thu, 6 Mar 2008, Pavel Machek wrote:

> On Tue 2008-03-04 16:00:51, Alan Stern wrote:
> > On Tue, 4 Mar 2008, David Brownell wrote:
> > 
> > > > 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.
> > 
> > On that we can agree.  The removal is done if the host doesn't define a 
> > resume method.  There doesn't seem to be any point to that, given that 
> > the probing during resume will determine whether a card has in fact 
> > been removed.
> 
> Hmm, if the driver is sleeping too deeply, user might have removed the
> card and put in different one, without driver noticing. That would be
> _bad_.

Ironically, the very same problem now exists with the USB mass-storage 
driver.  I don't see any way for the driver itself to solve it, 
especially during a hibernation (which can be a _very_ deep sleep).

One thing that could be done is for filesystems to verify, after a 
system sleep, that their superblocks haven't changed.  There could 
still be issues with non-mounted partitions, if they have live entries 
in the block cache, but it would be an improvement.

Do you know the right people to mention this to?  Anybody in filesystem 
development interested in suspend/hibernation issues?

Alan Stern

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