linux-kernel - Re: [RFC] block integrity: Fix write after checksum calculation problem

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:	Wed, 13 Apr 2011 17:48:48 -0700
From:	Mingming Cao <cmm@...ibm.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Chris Mason <chris.mason@...cle.com>,
	Jeff Layton <jlayton@...hat.com>, djwong <djwong@...ibm.com>,
	Jan Kara <jack@...e.cz>, Dave Chinner <david@...morbit.com>,
	Joel Becker <jlbec@...lplan.org>,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	Jens Axboe <axboe@...nel.dk>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Mingming Cao <mcao@...ibm.com>,
	linux-scsi <linux-scsi@...r.kernel.org>
Subject: Re: [RFC] block integrity: Fix write after checksum calculation
 problem

On Mon, 2011-04-11 at 20:57 -0400, Christoph Hellwig wrote:
> On Mon, Apr 11, 2011 at 05:46:52PM -0700, Mingming Cao wrote:
> > Oh, right. Currently ext4_page_mkwrite drops the page lock before
> > calling it's dirty the page (by write_begin() and write_end().  I
> > suspect regrab the lock() after write_end() (with your proposed change)
> > and returning with locked still leave the dirty by ext4_page_mkwrite
> > unlocked.  We probably should to keep the page locked the page during
> > the entire ext4_page_mkwrite() call. Any reason to drop the page lock()
> > before calling aops->write_begin()?
> 
> write_begin takes the page lock by itself.  That's one of the reasons why
> block_page_mkwrite doesn't use plain ->write_begin / write_end, the
> other beeing that we already get a page passed to use, so there's no
> need to do the pagecache lookup or allocation done by
> grab_cache_page_write_begin.
> 
> The best thing would be to completely drop ext4's current version
> of page_mkwrite and start out with a copy of block_page_mkwrite which
> has the journalling calls added back into it.

The problem is the locking order, we can't hold page lock then start the
journal lock. Kjournald will need to hold the journal lock first, then
commit, commit may need to callback writepages, which need to hold the
page lock.


I looked at ext3, in that case, ext3 even don't have ext3_page_mkwrite()
to do the stable page yet. It requires some block reservation/delayed
allocation for filling holes in mmaped IO case. Jan tried that before I
don't think the proposal get far.


Now looking back ext4_page_mkwrite(), it calls write_begin(), as long as
we do wait in write_begin() things would be fine, right? It seems
Darrick already did that wait per Dave Chinner's suggestion when grab
the page and lock that page. But still a puzzle to me why that's not
sufficient.


Mingming
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


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