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 12:04:15 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
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.

> > I don't believe "auto-destroy my music collection" is a sane default...
> 
> You are missing the point.

Nope.

> You have one totally made-up example of something that may happen as a 
> result of a default I didn't even advocate (but you didn't read my email). 

Actually I went and verified the behaviour of the iRiver iHP20.

> There really was nothing theoretical in my issue. On a certain class of 
> hardware, you absolutely _have_ to make your /home or / partition be 
> behind a USB thing, because nothing else has enough space on it.

Yes clearly.

> And your made-up example wouldn't even trigger if we just made a per-mount 

What made up example ?

> decision to mark devices persistent.

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.

> So why are you arguing?

I'm not aware I was. I was simply pointing out that

- the general distribution default cannot be one that harms user data on
music players
- that you can fix it more elegantly by quiescing and validating file
systems across a suspend/resume

neither of which appears to disagree with the point that you want USB (or
increasingly SD card) to be able to autoresume when it holds file
systems. It does however make clear which way around any kernel default
should be.

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