linux-kernel - Re: [PULL REQUEST] ext3, jbd, ext2, and quota fixes for 3.1-rc1

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:	Tue, 26 Jul 2011 12:14:28 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Al Viro <viro@...iv.linux.org.uk>, Jan Kara <jack@...e.cz>,
	Josef Bacik <josef@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PULL REQUEST] ext3, jbd, ext2, and quota fixes for 3.1-rc1

On Tue, Jul 26, 2011 at 11:59 AM, Christoph Hellwig <hch@...radead.org> wrote:
>
> In addition to beeing bogus the code also is useless.  fsync on a file
> explicitly does not guarantee anything at all about the parent, and
> never really has on Linux either.

Well, it may never have done that, but it might still be a case of
quality-of-implementation.

The data blocks and inode indirect blocks being stable on disk doesn't
help hugely if you cannnot actually reach the inode itself.

But yeah, I suspect it's not worth the bother. For many common
situations, it's the rename that moves it to the final place that is
the critical one as far as parent directory is concerned, not the
fsync of the file itself.

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