linux-kernel - Re: Zero length files - an alternative approach?

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>] [day] [month] [year] [list]

Message-Id: <E1LoOkP-0001bk-D6@be1.7eggert.dyndns.org>
Date:	Mon, 30 Mar 2009 23:10:20 +0200
From:	Bodo Eggert <7eggert@....de>
To:	Chris Mason <chris.mason@...cle.com>,
	Måns Rullgård <mans@...sr.com>,
	linux-kernel@...r.kernel.org, linux-ext4@...r.kernel.org
Subject: Re: Zero length files - an alternative approach?

Chris Mason <chris.mason@...cle.com> wrote:
> On Sun, 2009-03-29 at 12:22 +0100, Måns Rullgård wrote:

>> Consider this scenario:
>> 
>> 1. Create/write/close newfile
>> 2. Rename newfile to oldfile
> 
> 2a. create oldfile again
> 2b. fsync 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.
>> 
> 
> What happens to the new generation of oldfile?  We could insert
> dependency tracking so that we know the fsync of oldfile is supposed to
> also fsync the rename'd new file.

If rename() is BEFORE create(oldfile) and if create(oldfile) is committed,
oldfile will be the newly created file. If the sync() is interrupted by the
crash, any intermediate state may appear. If the system crashes before
create(), either the old oldfile or newfile should be visible.

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