linux-kernel - Re: Power Management with rootfs on SDMMC.

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: <20090102122148.175cff4a@mjolnir.drzeus.cx>
Date:	Fri, 2 Jan 2009 12:21:48 +0100
From:	Pierre Ossman <drzeus-list@...eus.cx>
To:	Andreas Mohr <andi@...as.de>
Cc:	Sriram V <vshrirama@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: Power Management with rootfs on SDMMC.

On Fri, 2 Jan 2009 11:21:52 +0100
Andreas Mohr <andi@...as.de> wrote:

> 
> There have been long threads on mobile phone and netbook related forums about issues
> with seemingly "any slightly advanced use whatsoever" of partitions on SD cards.
> 

As you may notice, you only get egg on your face when you suspend, so
it's really just the single problem. Granted, it's still a big one.

> IMHO in this strongly increasingly netbook- and mobile phone-enabled world it's
> a bloody shame that:
> - we have a hanging suspend/resume on an SD rootfs (often the only way of
>   achieving serious Linux use on a mobile phone!)

I take it this is without CONFIG_MMC_UNSAFE_RESUME.

The fundamental problem is that we have no way of detecting if a card
was removed during suspend, meaning we cannot guarantee that we'll
return the hardware to the upper layers in the same state it was
before the suspend.

There are two improvements that can be made here:

- Don't power down the card during suspend. This eats more power and
  might not be supported on all systems, but it allows us to detect any
  removal. This has been on my todo list for ages, but I haven't found
  any time to implement it (or even test if I have any systems that
  might support it).

- Have upper layers handle removal detection. E.g. in the common case
  of rootfs, the filesystem driver verifies that the storage is in the
  same state when it resumes as it was when it suspended. This requires
  a lot of work though as AFAIK there is no suspend functionality in
  either the block layer or the VFS.

> - we lose partition mounts due to full device re-probing instead of re-using the
>   same minor device ID after resume

This is a block layer issue, and I don't know if it's fixable.

Basically the problem is that someone is keeping the resources
associated with the pre-suspend block device pinned in memory. When the
post-suspend block device is created, it cannot reuse the device IDs
since they are still in use.

> - installing a swap partition on an SD card and then resuming can easily
>   go as far as __even completely corrupting__ the entire SD card partitioning
>   plus first partition (corrupts first 1kB of the card: both table and partition)
>   People then immediately resort to a non-helpful "Don't Do This, Ever" reply
>   (using swap partition on SD and suspend, see http://dev.laptop.org/ticket/6532#comment:10),

Hmm... I was under the impression that they got this fixed nice and
proper. Perhaps comment 34 should be sent to lkml and/or added to the
kernel bugzilla.

Rgds
-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  rdesktop, core developer          http://www.rdesktop.org

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.

Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)