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
| ||
|
Date: Tue, 16 Oct 2007 03:35:08 -0600 From: ebiederm@...ssion.com (Eric W. Biederman) To: Nick Piggin <nickpiggin@...oo.com.au> Cc: Andrew Morton <akpm@...ux-foundation.org>, Christian Borntraeger <borntraeger@...ibm.com>, linux-mm@...ck.org, linux-kernel@...r.kernel.org, Martin Schwidefsky <schwidefsky@...ibm.com>, "Theodore Ts'o" <tytso@....edu> Subject: Re: [PATCH] rd: Preserve the dirty bit in init_page_buffers() Nick Piggin <nickpiggin@...oo.com.au> writes: > On Tuesday 16 October 2007 08:40, Eric W. Biederman wrote: >> The problem: When we are trying to free buffers try_to_free_buffers() >> will look at ramdisk pages with clean buffer heads and remove the >> dirty bit from the page. Resulting in ramdisk pages with data that get >> removed from the page cache. Ouch! >> >> Buffer heads appear on ramdisk pages when a filesystem calls >> __getblk() which through a series of function calls eventually calls >> init_page_buffers(). >> >> So to fix the mismatch between buffer head and page state this patch >> modifies init_page_buffers() to transfer the dirty bit from the page to >> the buffer heads like we currently do for the uptodate bit. >> >> This patch is safe as only __getblk calls init_page_buffers, and >> there are only two implementations of block devices cached in the >> page cache. The generic implementation in block_dev.c and the >> implementation in rd.c. >> >> The generic implementation of block devices always does everything >> in terms of buffer heads so it always has buffer heads allocated >> before a page is marked dirty so this change does not affect it. > > This is probably a good idea. Was this causing the reiserfs problems? > If so, I think we should be concentrating on what the real problem > is with reiserfs... (or at least why this so obviously correct > looking patch is wrong). I think it was my cleanup patch that was sitting on top of this, That caused the problems. Eric - 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/
Powered by blists - more mailing lists