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
| ||
|
Message-ID: <20090329134901.GB13737@elf.ucw.cz> Date: Sun, 29 Mar 2009 15:49:01 +0200 From: Pavel Machek <pavel@....cz> To: M?ns Rullg?rd <mans@...sr.com> Cc: "Andreas T.Auer" <andreas.t.auer_lkml_73537@...us.ath.cx>, linux-kernel@...r.kernel.org, linux-ext4@...r.kernel.org Subject: Re: Zero length files - an alternative approach? On Sun 2009-03-29 13:10:23, M?ns Rullg?rd wrote: > "Andreas T.Auer" <andreas.t.auer_lkml_73537@...us.ath.cx> writes: > > > On 29.03.2009 13:22 M?ns Rullg?rd wrote: > >> Consider this scenario: > >> > >> 1. Create/write/close newfile > >> 2. Rename newfile to oldfile > >> 3. Open/read oldfile. This must return the new contents. > >> 4. System crash and reboot before delayed allocation/flush complete > >> 5. Open/read oldfile. Old contents now returned. > >> > >> This rollback isn't obviously, to me at least, without problems of its > >> own. > >> > > Having the old data in 5) is far better than having no data in 5). > > Of course having old data is better than no data. However, fsync() > and similar approaches make a rollback to old data after new data has > been visible impossible or far less likely than the suggested one. Untrue. Unless you fsync after rename, you can get olddata. fsync() is easy. But some people _want_ to have either newdata _or_ olddata, but don't care which one, and would prefer to avoid fsync. That's where replace() should help... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists