linux-kernel - Re: MMC/SD Root filesystem suspend/resume problems

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: <20070722165926.54caeca5@poseidon.drzeus.cx>
Date:	Sun, 22 Jul 2007 16:59:26 +0200
From:	Pierre Ossman <drzeus-mmc@...eus.cx>
To:	Richard Purdie <rpurdie@...ys.net>
Cc:	kernel list <linux-kernel@...r.kernel.org>
Subject: Re: MMC/SD Root filesystem suspend/resume problems

On Sun, 22 Jul 2007 15:28:00 +0100
Richard Purdie <rpurdie@...ys.net> wrote:

> 
> Corruption is corruption and it shouldn't happen if we can avoid it.
> It happens with complete certainty in one case and only happens in the
> other if the user does something which is a fairly obvious bad idea
> (which is documented as such).
> 

The corruption will only occur if the filesystem is dirty. Granted, the
mount will be dead and useless, but I wouldn't call that corruption.

Anyway, this behaviour was selected after seeing the long discussion
about how USB should handle the same problem. It was decided that it
was best to play it safe and remove any devices that couldn't be
determined to have remained in the slot. We also have the USB_PERSIST
option these days, which does the same thing as MMC_UNSAFE_RESUME.

> 
> Given I can suspend the device with "echo mem > /sys/power/state",
> that implies we need to fix echo? ;-)
> 

Or that direct usage of /sys/power/state is only for those who know
what they are doing (and have umounted their filesystems beforehand).

> 
> > And if we keep papering over the problems, you reduce the motivation
> > of fixing this properly.
> 
> Maybe although I don't like existing functionality being broken even
> if its less than ideal.
> 

I am of the opinion that it was more broken before I touched it. Silent
corruption is never acceptable in my book. But if it is in yours, just
enable MMC_UNSAFE_RESUME and you'll have the old behaviour.

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/