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]

Date:	Sun, 4 Jan 2009 09:53:08 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
cc:	Pavel Machek <pavel@...e.cz>, Andreas Mohr <andi@...as.de>,
	Sriram V <vshrirama@...il.com>,
	Pierre Ossman <drzeus-list@...eus.cx>,
	linux-kernel@...r.kernel.org
Subject: Re: Power Management with rootfs on SDMMC.

On Sun, 4 Jan 2009, Alan Cox wrote:
> 
> The distribution question is 'how do you make that decision reliably and
> correctly ?'. That is closely followed by 'what state should it end up in
> if the relevant scripts don't run for some reason ?' - which is clearly
> "not persistent" for safety reasons.

No.

You clearly haven't even read my emails. I quote:

  And yes, the "sane defaults" may well be that FATFS does _not_ make the 
  media be persistent.

however, the sane default remains that things like / and /home _should_ be 
marked persistent.

> I was simply pointing out that
> 
> - the general distribution default cannot be one that harms user data on
> music players

No you were not. You were repeatign that mantra as if it was relevant, 
when it isn't.

> - that you can fix it more elegantly by quiescing and validating file
> systems across a suspend/resume

Send me a patch. 

Hint: you can't sanely even validate it without teaching the USB layer 
_not_ to disconnect and re-connect the damn thing on resume (ie set the 
"persistent" flag), because that can easily cause totally unrelated 
changes to cause the device to be re-enumerated. How do you even find it? 

In other words, you're wrong. 

The only sane thing to do is what I already outlined: teach the 
mount-points (and yes, on a per-mount-point basis) to mark the devices 
persistent, and make the device drivers honor that.

Then, in _addition_, you can - once the device stays around - you can also 
add a filesystem callback for suspend/resume, and make the filesystem try 
to do extra sanity checking. 

But quite frankly, that's very much the secondary stage, since it won't 
matter in any sane real situation (ie once you've simply said that "we 
don't cae about FAT being persistent"). And it's a secondary stage also 
simply because it needs to happen _after_ you've already made the ones you 
care about persistent, since it simply won't work otherwise.

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