linux-ext4 - Re: possible different donor file naming in e4defrag

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]

Message-Id: <25905DD3-CD3E-42F2-A101-715E7C205CEB@dilger.ca>
Date:	Thu, 11 Sep 2014 15:19:44 -0600
From:	Andreas Dilger <adilger@...ger.ca>
To:	TR Reardon <thomas_reardon@...mail.com>
Cc:	"Darrick J. Wong" <darrick.wong@...cle.com>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: possible different donor file naming in e4defrag

On Sep 11, 2014, at 1:48 PM, TR Reardon <thomas_reardon@...mail.com> wrote:
> Picking this back up.  How would O_TMPFILE avoid races?  It definitely avoids the unwanted mtime/atime update, but then the existing "<filename>.defrag" pseudo-lock file would no longer be available.  How could you use O_TMPFILE and still avoid multiple defrag?  If this isn't possible, then resetting the parent times on unlink(tmpfile), as you suggest, is the simplest way out of this.

Looking at this the opposite way - what are the chances that there
will be concurrent defrags on the same file?  Basically no chance at
all.  So long as it doesn't explode (the kernel would need to protect
against this anyway to avoid malicious apps), the worst case is that
there will be some extra defragmentation done in a very rare case.

Conversely, creating a temporary filename and then resetting the
parent directory timestamp is extra work for every file defragmented,
and is racy because e4defrag may "reset" the time to before the temp
file was created, but clobber a legitimate timestamp update in the
directory from some other concurrent update.  That timestamp update
is always going to be racy, even if e4defrag tries to be careful.

Cheers, Andreas

>> From: adilger@...ger.ca
>> Subject: Re: possible different donor file naming in e4defrag
>> Date: Fri, 15 Aug 2014 23:04:21 +0200
>> To: thomas_reardon@...mail.com
>> 
>> The reason the donor file is created in the same directory as the source is to try and keep the block allocation policy consistent with the original inode.
>> 
>> You may not need a SIGINT handler, since the timestamp could be reset as soon as the file is created and unlinked.
>> 
>> It may also be possible to use O_TMPFILE on newer kernels to create the donor file to avoid any races?
>> 
>> Cheers, Andreas
>> 
> 
> 		 	   		  

Cheers, Andreas

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)