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

Powered by blists - more mailing lists