linux-kernel - Re: New MMC maintainer needed

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:	Thu, 6 Aug 2009 10:54:01 +0200
From:	Pierre Ossman <pierre@...man.eu>
To:	David Brownell <david-b@...bell.net>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-embedded@...r.kernel.org,
	nico@....org, nicolas.ferre@....atmel.com, hskinnemoen@...el.com,
	tony@...mide.com, manuel.lauss@...il.com, mirq-linux@...e.qmqm.pl,
	ppisa@...ron.com, jarkko.lavinen@...ia.com, ben@...ff.org,
	saschasommer@...enet.de, avorontsov@...mvista.com, oakad@...oo.com,
	ian@...menth.co.uk, HaraldWelte@...tech.com, JosephChan@....com.tw,
	adrian.hunter@...ia.com
Subject: Re: New MMC maintainer needed

On Mon, 3 Aug 2009 18:51:23 -0700
David Brownell <david-b@...bell.net> wrote:

> On Friday 31 July 2009, Pierre Ossman wrote:
> > Restoring back the system state from MMC after a successful hibernation
> > http://marc.info/?t=124818534700003&r=1&w=2
> > 
> > I don't agree with this approach. The point of the workqueue is so that
> > the kernel can do things in parallel, so this patch is a step back. The
> > problem is really with how the kernel doesn't properly cope with
> > asynchronous disk scanning during bootup. The root_delay parameter was
> > added for this for the "normal" case, but it seems more work is needed.
> 

(confusion on my end, I wasn't thinking about root_delay but rootwait)

> Doesn't handing of resumes needs more attention overall?
> 

Very much so. I haven't given that area much love since a) I haven't
had the time, b) I don't have any systems with fancy enough suspend
handling to do anything interesting.

> Example, root on eMMC (e.g. a 32-MByte non-removable chip) wouldn't
> resume at all well the last time I checked ... mounted file systems
> (not just root) made trouble.  Hardware that reliably reports card
> insert/remove was rude in the same ways.

The general lack of removal detection during suspend tends to make
everything more complicated than one would like. But I'm sure it's
manageable just as long as someone puts enough time into it. I'm still
very much opposed to just assuming that the user never removes the card
during suspend though.

Rgds
-- 
     -- Pierre Ossman

  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" (199 bytes)