linux-ext4 - Re: [PATCH RFC] ext3 data=guarded v3

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:	Thu, 16 Apr 2009 15:38:07 -0400
From:	Chris Mason <chris.mason@...cle.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Mike Galbraith <efault@....de>, Jan Kara <jack@...e.cz>,
	"Theodore Ts'o" <tytso@....edu>,
	Linux Kernel Developers List <linux-kernel@...r.kernel.org>,
	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH RFC] ext3 data=guarded v3

On Thu, 2009-04-16 at 11:37 -0700, Linus Torvalds wrote:
> 
> On Thu, 16 Apr 2009, Chris Mason wrote:
> > 
> > Ah ok, it is just a missed i_size update.  Basically because file_write
> > doesn't wait for page writeback to finish, someone can be updating
> > i_size at the same time the end_io handler for the last page is running.
> > 
> > Git triggers this when it does the sha1flush just before closing the
> > file.
> 
> Can you say exactly what the IO pattern is?
> 
> One of the original git design issues was to actually never _ever_ do 
> anything even half-way strange in the filesystem patterns, exactly because 
> I've seen so many filesystem bugs over the years.
> 

I wish it were git doing something fancy, but this is a good old
fashioned bug in the guarded code.  I was missing the on disk update
when you appended onto the end of the file without adding a new block. 

The race in my code I mentioned was there too, but when doing small
appends to the file without other writes, the size of the race window is
infinite.

The bug was usually hidden because the updated i_size was usually copied
out when the orphan link was deleted, but small appends with no other
file traffic didn't trigger that code.  This is the old "works fine
under load but fails when lightly used" problem.

Git made the whole thing much easier to track down.  I didn't have to
read the git code to know the packed files from the good data=ordered
and bad data=guarded run were supposed to be the same, the sha was right
in the filename ;)  Just a quick diff of the hexdumps made it clear
where the bug had to be.

-chris

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