[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#405449: marked as done (linux-source-2.6.18: possible data corruption due to race condition in mmap)



Your message dated Wed, 3 Jan 2007 20:49:15 +0100
with message-id <20070103194915.GH26700@baikonur.stro.at>
and subject line Bug#405449: linux-source-2.6.18: possible data corruption due to race condition in mmap
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: linux-source-2.6.18
Version: 2.6.18-7
Severity: normal
Tags: patch

Full story is at http://www.kerneltrap.org/node/7518 . The source still seems to contain an old 
code. I include patch (simple rediff from the new 2.6.20-rc3 source), but I haven't tested it 
thoroughly yet. This bug should probably be tagged as "critical".

Regards,
M.

-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages linux-source-2.6.18 depends on:
ii  binutils                      2.17-3     The GNU assembler, linker and bina
ii  bzip2                         1.0.3-6    high-quality block-sorting file co

Versions of packages linux-source-2.6.18 recommends:
ii  gcc                          4:4.1.1-13  The GNU C compiler
ii  libc6-dev [libc-dev]         2.3.6.ds1-8 GNU C Library: Development Librari
ii  make                         3.81-2      The GNU version of the "make" util

-- no debconf information
--- linux-source-2.6.18-old/mm/page-writeback.c	2006-12-04 15:27:13.000000000 +0100
+++ linux-source-2.6.18/mm/page-writeback.c	2007-01-03 17:36:31.000000000 +0100
@@ -757,19 +757,48 @@
  */
 int clear_page_dirty_for_io(struct page *page)
 {
-	struct address_space *mapping = page_mapping(page);
+        struct address_space *mapping = page_mapping(page);
 
-	if (mapping) {
-		if (TestClearPageDirty(page)) {
-			if (mapping_cap_account_dirty(mapping)) {
-				page_mkclean(page);
-				dec_zone_page_state(page, NR_FILE_DIRTY);
-			}
-			return 1;
-		}
-		return 0;
-	}
-	return TestClearPageDirty(page);
+        if (mapping && mapping_cap_account_dirty(mapping)) {
+                /*
+                 * Yes, Virginia, this is indeed insane.
+                 *
+                 * We use this sequence to make sure that
+                 *  (a) we account for dirty stats properly
+                 *  (b) we tell the low-level filesystem to
+                 *      mark the whole page dirty if it was
+                 *      dirty in a pagetable. Only to then
+                 *  (c) clean the page again and return 1 to
+                 *      cause the writeback.
+                 *
+                 * This way we avoid all nasty races with the
+                 * dirty bit in multiple places and clearing
+                 * them concurrently from different threads.
+                 *
+                 * Note! Normally the "set_page_dirty(page)"
+                 * has no effect on the actual dirty bit - since
+                 * that will already usually be set. But we
+                 * need the side effects, and it can help us
+                 * avoid races.
+                 *
+                 * We basically use the page "master dirty bit"
+                 * as a serialization point for all the different
+                 * threads doing their things.
+                 *
+                 * FIXME! We still have a race here: if somebody
+                 * adds the page back to the page tables in
+                 * between the "page_mkclean()" and the "TestClearPageDirty()",
+                 * we might have it mapped without the dirty bit set.
+                 */
+                if (page_mkclean(page))
+                        set_page_dirty(page);
+                if (TestClearPageDirty(page)) {
+                        dec_zone_page_state(page, NR_FILE_DIRTY);
+                        return 1;
+                }
+                return 0;
+        }
+        return TestClearPageDirty(page);
 }
 EXPORT_SYMBOL(clear_page_dirty_for_io);
 

--- End Message ---
--- Begin Message ---
On Wed, Jan 03, 2007 at 05:51:30PM +0100, Marcin wrote:
> 
> Full story is at http://www.kerneltrap.org/node/7518 . The source still seems to contain an old 
> code. I include patch (simple rediff from the new 2.6.20-rc3 source), but I haven't tested it 
> thoroughly yet. This bug should probably be tagged as "critical".
> 

closing as dup,
check out linux-2.6 source package for more info.

-- 
maks

--- End Message ---

Reply to: