linux-ext4 - Re: ext4: Can we talk about bforget() and metadata blocks

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: <20090911181541.GA28764@mit.edu>
Date:	Fri, 11 Sep 2009 14:15:41 -0400
From:	Theodore Tso <tytso@....edu>
To:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
Cc:	Curt Wohlgemuth <curtw@...gle.com>, linux-ext4@...r.kernel.org
Subject: Re: ext4: Can we talk about bforget() and metadata blocks

On Fri, Sep 11, 2009 at 02:08:27PM -0400, Theodore Tso wrote:
> Does that help clarify matters?  Basically, there are three separate
> bugs related to no journal mode that are being addressed by patches in
> the ext4 patch queue:

Whoops, I mixed up the patch names and description for two of them.
Let me try again:

ext4: Make non-journal fsync work properly
      (Found and fixed by Frank; we need to explicitly write out the 
      inode structure to disk during an fsync since we can't depend 
      on the journal doing this for us in no-journal mode.  So this is 
      an issue of the inode itself not getting written out by
      ext4_write_inode, which is called by pdflush and fsync.  
      Since the inode table buffer is marked dirty, the inode will 
      *eventually* be written out, but on a much greater time scale.  
      This caused the increased fragility of ext4 in no-journal mode
      after a power failure.)

ext4: Use bforget() in no journal mode for ext4_journal_{forget,revoke}()
      (Found by Curt, with an initial fix that worked by forcing 
      the dirty buffer to be written to disk, and fixed in a better way 
      by Ted by using bforget.  The problem here relates to an inode that
      is being deleted, which is why there's no reason to write the 
      dirty block to disk; when we were about to deallocate the block ---
      the better fix is to drop the dirty bit by using bforget.)

ext4: Assure that metadata blocks are written during fsync in no journal mode
      (Pointed out by Aneesh, fixed by Ted; this fix makes sure that
      fsync will write out an inode's extent tree and/or indirect blocks,
      which is kinda important.  :-)

(I swapped the patch names/description for the last two.)

> Hopefully this quick Cliff Notes(tm) summary of the ext4 no-journal
> patches in the ext4 patch queue is helpful.

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