linux-kernel - Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)

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: <Pine.LNX.4.64.0612201543540.3576@woody.osdl.org>
Date:	Wed, 20 Dec 2006 15:55:25 -0800 (PST)
From:	Linus Torvalds <torvalds@...l.org>
To:	David Chinner <dgc@....com>
cc:	Martin Michlmayr <tbm@...ius.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Hugh Dickins <hugh@...itas.com>,
	Nick Piggin <nickpiggin@...oo.com.au>,
	Arjan van de Ven <arjan@...radead.org>,
	Andrei Popa <andrei.popa@...eo.ro>,
	Andrew Morton <akpm@...l.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Florian Weimer <fw@...eb.enyo.de>,
	Marc Haber <mh+linux-kernel@...schlus.de>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	Arnd Bergmann <arnd.bergmann@...ibm.com>,
	gordonfarquharson@...il.com
Subject: Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content
 corruption on ext3)

On Thu, 21 Dec 2006, David Chinner wrote:
> 
> XFS appears to call clear_page_dirty to get the mapping tree dirty
> tag set correctly at the same time the page dirty flag is cleared. I
> note that this can be done by set_page_writeback() if we clear the
> dirty flag on the page first when we are writing back the entire page.

Yes. I think the XFS routine should just use "clear_page_dirty_fir_io()", 
since that matches what it actually wants to do (surprise surprise, it's 
going to write it out).

HOWEVER. Why is it conditional? Can somebody who understands XFS tell me 
why "clear_dirty" would ever be 0? I can grep the sources, and I see that 
it's an unconditional 1 in one call-site, but then in the other one it 
does

	xfs_start_page_writeback(page, wbc, !page_dirty, count);

and that part just blows my mind. Why would you do a 
xfs_start_page_writeback() and _not_ write the page out? Is this for a 
partial-page-only case?

Anyway, your patch looks fine. It seems to be the right thing to do. I'm 
just wondering why we're not always cleaning the whole page, and why we'd 
not set it unconditionally dirty?

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