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: <20110104091347.GA2760@infradead.org>
Date:	Tue, 4 Jan 2011 04:13:48 -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 06:52:48PM +1100, Nick Piggin wrote:
> Right if you want a helper to get the correct mask of bits required
> that's fine and I agree, but locking is a different issue too: if
> filesystems are trying to keep private state in sync with vfs state,
> then they _need_ to do it properly with the proper locking. I think
> your hfsplus implementation had a bug or two in this area didn't it?
> (although I ended up getting side tracked with all these bugs half
> way through looking at that).

It's not locking, but ordering that was the issue.  It's an issue caused
by the VFS interfaces, but not really related to the area you work
on currently.  If ->dirty_inode told us what was dirtied it would be
a lot simpler.  Alternatively we should just stop requiring filesystems
to participate in the I_DIRTY_SYNC/DATASYNC protocol.  In general it's
much easier for the filesystem to keep that state by itself in proper
granularity.  But I lost the fight to have the timestamp updates go
through proper methods instead of just writing into the VFS inode and
marking the inode dirty long ago, so we'll have to live with it.
--
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/