linux-kernel - Re: 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]

Date:	Mon, 18 Dec 2006 20:30:12 +1100
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Andrew Morton <akpm@...l.org>
CC:	Linus Torvalds <torvalds@...l.org>, andrei.popa@...eo.ro,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Hugh Dickins <hugh@...itas.com>,
	Florian Weimer <fw@...eb.enyo.de>,
	Marc Haber <mh+linux-kernel@...schlus.de>,
	Martin Michlmayr <tbm@...ius.com>
Subject: Re: 2.6.19 file content corruption on ext3

Andrew Morton wrote:
> On Sun, 17 Dec 2006 21:50:43 -0800 (PST)
> Linus Torvalds <torvalds@...l.org> wrote:
> 
> 
>>
>>On Mon, 18 Dec 2006, Nick Piggin wrote:
>>
>>>I can't see how that's exactly a problem -- so long as the page does not
>>>get reclaimed (it won't, because we have a ref on it) then all that matters
>>>is that the page eventually gets marked dirty.
>>
>>But the point being that "try_to_free_buffers()" marks it clean 
>>AFTERWARDS.
>>
>>So yes, the page gets marked dirty in the pte's - the hardware generally 
>>does that for us, so we don't have to worry about that part going on.
>>
>>But "try_to_free_buffers()" seems to clear those dirty bits without 
>>serializing it really any way. It just says "ok, I will now clear them". 
>>Without knowing whether the dirty bits got set before the IO that cleared 
>>the buffer head dirty bits or not.
> 
> 
> Yes, I can't see anything correct about the current behaviour.
> 
> But I'm going blue in the face here trying to feed try_to_free_buffers() a
> page_mapped(page), without success.  pagevec_strip() presumably isn't
> triggering.

I can trigger it here, with a kernel patch to call pagevec_strip
unconditionally. I am seeing it clearing pte dirty bits, which is surely
a dataloss bug.

BUG: warning at mm/page-writeback.c:862/clear_page_dirty_warn()
  [<c013f65a>] clear_page_dirty_warn+0xdb/0xdd
  [<c0174309>] try_to_free_buffers+0x6b/0x7e
  [<c01937ec>] ext3_releasepage+0x0/0x74
  [<c013bb48>] try_to_release_page+0x2c/0x40
  [<c0140925>] pagevec_strip+0x52/0x54
  [<c0141580>] shrink_active_list+0x2a0/0x3c8
  [<c0142100>] shrink_zone+0xcd/0xea
  [<c014266d>] kswapd+0x311/0x41e
  [<c012c6aa>] autoremove_wake_function+0x0/0x37
  [<c014235c>] kswapd+0x0/0x41e
  [<c012c527>] kthread+0xde/0xe2
  [<c012c449>] kthread+0x0/0xe2
  [<c010395b>] kernel_thread_helper+0x7/0x1c
  =======================

(clear_page_dirty_warn() is test_clear_page_dirty which WARN_ON()s the
result of page_mkclean)


> This will (at least) cause truncate to do peculiar things. 
> do_invalidatepage() runs discard_buffer() against the dirty page and will
> then expect try_to_free_buffers() to remove those buffers and then clean
> the page.  truncate_complete_page() will clean the page, but it still has
> those invalidated buffers.  We'll end up with a large number of clean,
> unused pages on the LRU, with attached buffers.  These should eventually
> get reaped, but it'll change the page aging dynamics.

This isn't so nice. I wonder if you could just ClearPageDirty before
calling try_to_free_buffers in this case, or is that too much of a
hack? Ideally I guess you want a variant that is happy to discard
dirtiness (alternatively, my proposal to redirty the page if we find
a dirty pte should also handle this).

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 
-
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/