linux-kernel - Re: [patch 7/8] fs: fix or note I_DIRTY handling bugs in filesystems

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: <20110104063944.GA1910@infradead.org>
Date:	Tue, 4 Jan 2011 01:39:44 -0500
From:	Christoph Hellwig <hch@...radead.org>
To:	Nick Piggin <npiggin@...nel.dk>
Cc:	Christoph Hellwig <hch@...radead.org>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>, mfasheh@...e.com,
	joel.becker@...cle.com, swhiteho@...hat.com
Subject: Re: [patch 7/8] fs: fix or note I_DIRTY handling bugs in filesystems

On Tue, Jan 04, 2011 at 05:04:52PM +1100, Nick Piggin wrote:
> However I strongly believe that filesystems should be able to access
> and manipulate the inode dirty state directly. If you agree with that,
> then I think they should be able to access the lock required for that.
> Filesystems will want to keep their internal state in synch with vfs
> visible state most likely (eg. like your hfsplus patches), and _every_
> time we do "loose" coupling between state bits like this (eg. page and
> buffer state; page and pte state; etc), it turns out to be a huge mess
> of races and subtle code and ordering.

I've probably done the two most complicated fsync implementations in xfs
and hfsplys myself, and I'd really prefer the interface to be as simple
as possible.  The way the I_DIRTY_* flags and the datasync parameter to
->fsync interact are almost a receipe for getting it wrong, which in
fact most implementations that tried to be smart did.  See gfs2 and
ocfs2 comments in this threads for classic examples.

If we actually get filesystems that need to do smarts in
checking/clearing the I_DIRTY_* flag we can discuss proper interfaces
for it - duplicating guts of i_state manipulations sounds like a
relatively bad idea for that.  Note that my fsync_helper still gives
filesystems a lot of information, just not in a redundant and confusing
way.  The dirty argument still tells if datasync-relevant or
non-datasyns relevant (aka timestampts) metadata was dirty, so if a
filesystem needs to write them back in different ways it still can.

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