From: Andrew Morton <akpm@linux-foundation.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Nick Piggin <nickpiggin@yahoo.com.au>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [patch 1/8] fix race in clear_page_dirty_for_io()
Date: Wed, 7 Mar 2007 02:15:18 -0800 [thread overview]
Message-ID: <20070307021518.3b1ff4a2.akpm@linux-foundation.org> (raw)
In-Reply-To: <20070307082337.101759335@szeredi.hu>
(cc's reinstated)
On Wed, 07 Mar 2007 09:09:50 +0100 Miklos Szeredi <miklos@szeredi.hu> wrote:
> There's a race in clear_page_dirty_for_io() that allows a page to have
> cleared PG_dirty, while being mapped read-write into the page table(s).
I assume you refer to this:
* 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;
}
I guess the comment actually refers to a writefault after the
set_page_dirty() and before the TestClearPageDirty(). The fault handler
will run set_page_dirty() and will return to userspace to rerun the write.
The page then gets set pte-dirty but this thread of control will now make
the page !PageDirty() and will write it out.
With Nick's proposed lock-the-page-in-pagefaults patches, we have
lock_page() synchronisation between pagefaults and
clear_page_dirty_for_io() which I think will fix this.
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Nick Piggin <nickpiggin@yahoo.com.au>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [patch 1/8] fix race in clear_page_dirty_for_io()
Date: Wed, 7 Mar 2007 02:15:18 -0800 [thread overview]
Message-ID: <20070307021518.3b1ff4a2.akpm@linux-foundation.org> (raw)
In-Reply-To: <20070307082337.101759335@szeredi.hu>
(cc's reinstated)
On Wed, 07 Mar 2007 09:09:50 +0100 Miklos Szeredi <miklos@szeredi.hu> wrote:
> There's a race in clear_page_dirty_for_io() that allows a page to have
> cleared PG_dirty, while being mapped read-write into the page table(s).
I assume you refer to this:
* 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;
}
I guess the comment actually refers to a writefault after the
set_page_dirty() and before the TestClearPageDirty(). The fault handler
will run set_page_dirty() and will return to userspace to rerun the write.
The page then gets set pte-dirty but this thread of control will now make
the page !PageDirty() and will write it out.
With Nick's proposed lock-the-page-in-pagefaults patches, we have
lock_page() synchronisation between pagefaults and
clear_page_dirty_for_io() which I think will fix this.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next parent reply other threads:[~2007-03-07 10:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20070307080949.290171170@szeredi.hu>
[not found] ` <20070307082337.101759335@szeredi.hu>
2007-03-07 10:15 ` Andrew Morton [this message]
2007-03-07 10:15 ` [patch 1/8] fix race in clear_page_dirty_for_io() Andrew Morton
2007-03-07 10:31 ` Miklos Szeredi
2007-03-07 10:31 ` Miklos Szeredi
2007-03-06 18:04 [patch 0/8] VFS/VM patches Miklos Szeredi
2007-03-06 18:04 ` [patch 1/8] fix race in clear_page_dirty_for_io() Miklos Szeredi
2007-03-06 22:25 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070307021518.3b1ff4a2.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=miklos@szeredi.hu \
--cc=nickpiggin@yahoo.com.au \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.