linux-ext4 - Re: [patch 0/2] i

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] [day] [month] [year] [list]

Date:	Thu, 31 May 2007 11:12:35 -0700
From:	Mingming Cao <cmm@...ibm.com>
To:	David Chinner <dgc@....com>
Cc:	Jean noel Cordenner <jean-noel.cordenner@...l.net>,
	linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	nfsv4@...ux-nfs.org
Subject: Re: [patch 0/2] i_version update

On Thu, 2007-05-31 at 10:33 +1000, David Chinner wrote:
> On Wed, May 30, 2007 at 04:32:57PM -0700, Mingming Cao wrote:
> > On Wed, 2007-05-30 at 10:21 +1000, David Chinner wrote:
> > > On Fri, May 25, 2007 at 06:25:31PM +0200, Jean noel Cordenner wrote:
> > > > Hi,
> > > > 
> > > > This is an update of the i_version patch.
> > > > The i_version field is a 64bit counter that is set on every inode
> > > > creation and that is incremented every time the inode data is modified
> > > > (similarly to the "ctime" time-stamp).
> > > 
> > > My understanding (please correct me if I'm wrong) is that the
> > > requirements are much more rigourous than simply incrementing an in
> > > memory counter on every change.  i.e. the this counter has to
> > > survive server crashes intact so clients never see the counter go
> > > backwards. That means version number changes need to be journalled
> > > along with the operation that caused the change of the version
> > > number.
> > > 
> > Yeah, the i_version is the in memeory counter. From the patch it looks
> > like the counter is being updated inside ext4_mark_iloc_dirty(), so it
> > is being journalled and being flush to on-disk ext4 inode structure
> > immediately (On-disk ext4 inode structure is being modified/expanded to
> > store the counter in the first patch). 
> 
> Ok, that catches most things (I missed that), but the version number still
> needs to change on file data changes, right? So if we are overwriting the
> file, we're calling __mark_inode_dirty(I_DIRTY_PAGES) which means you don't
> get the callout and so the version number doesn't change or get logged. In
> that case, the version number is not doing what it needs to do, right?
> 

Hmm, maybe I missed something... but looking at the code again, in the
case of overwrite (file date updated),it seems the ctime/mtime is being
updated and the inode is being dirtied, so the version number is being
updated.

 vfs_write()->..
	->__generic_file_aio_write_nolock()
		->file_update_time()
			->mark_inode_dirty_sync()
			->__mark_inode_dirty(I_DIRTY_SYNC)
				->ext4_dirty_inode()
					->ext4_mark_inode_dirty()

Regards,
Mingming

-
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