linux-kernel - Re: sync, reboot, and corrupting data [was Re: 2.6.29 -mm merge plans]

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:	Sat, 10 Jan 2009 23:12:32 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	Pavel Machek <pavel@...e.cz>
Cc:	Andi Kleen <andi@...stfloor.org>, Nick Piggin <npiggin@...e.de>,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: sync, reboot, and corrupting data [was Re: 2.6.29 -mm merge plans]

On Sat, Jan 10, 2009 at 10:32:23PM +0100, Pavel Machek wrote:
> On Sat 2009-01-10 16:07:29, Andi Kleen wrote:
> > On Thu, Jan 08, 2009 at 02:24:55PM +0100, Pavel Machek wrote:
> > > On Wed 2009-01-07 03:57:25, Andi Kleen wrote:
> > > > > sys_sync B which is invoked *after* sys_sync caller A should not
> > > > > return before A. If you didn't have a global lock, they'd tend to
> > > > > block one another's pages anyway. I think it's OK.
> > > > 
> > > > It means that you cannot reboot because reboot does sync.
> > > > What happens when the sync gets stuck somewhere on a really
> > > > slow device?
> > > 
> > > And what do you propose? Silently corrupt data on the slow device?
> > 
> > Yes not writing is better than being unable to reboot.
> 
> Disagreed.

Well you're just forcing the user to press power/reset/sysrq-b which
will pretty much guarantee data loss if anything is unwritten.

> maybe reboot utility should not call sync()...

I think it should call sync(), but have a suitable timeout.
Never spend more than 10 seconds on the sync. And give user visible 
feedback during the countdown.

Now of course fixing the complete IO stack to support timeouts
might be too hard (although in theory they're already supposed
to have them, but as we know that doesn't always work reliable)

One alternative would be to do it with a background thread
(which seems to be en vogue right now anyways)
Ok I suppose with that Nick's lock is actually ok, although
I still don't like it very much.

-Andi

-- 
ak@...ux.intel.com
--
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/