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: <1185110313.6819.8.camel@localhost.localdomain>
Date:	Sun, 22 Jul 2007 14:18:33 +0100
From:	Richard Purdie <rpurdie@...ys.net>
To:	Pierre Ossman <drzeus-mmc@...eus.cx>
Cc:	kernel list <linux-kernel@...r.kernel.org>
Subject: Re: MMC/SD Root filesystem suspend/resume problems

On Thu, 2007-07-19 at 19:03 +0200, Pierre Ossman wrote:
> On Thu, 19 Jul 2007 16:53:39 +0100
> Richard Purdie <rpurdie@...ys.net> wrote:
> > Lots of Linux handhelds use MMC/SD devices as the root file system.
> > This has worked quite reliably for many kernel versions. In 2.6.22,
> > it seems that if you suspend such a system then resume it, the device
> > locks up. Trying to execute anything on the filesystem results in a
> > "Permission Denied" message. I did see a message from the MMC
> > subsystem saying it had redetected the card. There are also messages
> > on the console like "MMC: killing requests for dead queue" each time
> > you suspend/resume.
> 
> The card is removed when you suspend and readded when you resume.
> That's the only safe thing we can do until we get suspend support in
> the filesystems.
> 
> If you really want to shoot yourself in the foot, there is a Kconfig
> option that keeps the card around across the suspend.

I enabled the MMC_UNSAFE_RESUME option and the problems I was seeing was
"fixed". I think having this option is a bad idea (in its current form)
as it doesn't actually stop filesystem corruption.

With the option disabled, if a filesystem is mounted when you suspend my
tests show the filesystem is corrupted. At least if the option is
enabled, the filesystem is only corrupted if you remove the card whilst
suspended which is more preferable.

I guess the solution would be to abort the suspend if mounted systems
were detected and the option was disabled? Alternatively the option
could be "auto" enabled only for mounted systems maybe with a printk
warning?

Of course the best solution would be to have filesystems support
suspend/resume requests since other subsystems like pcmcia also suffer
this problem and would benefit from this but I accept that teaching
filesystems this is more difficult.

Regards,

Richard


-
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