From: "David S. Miller" <davem@redhat.com>
To: andrea@suse.de
Cc: hugh@veritas.com, torvalds@transmeta.com, akpm@zip.com.au,
cr@sap.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] double flush_page_to_ram
Date: Thu, 09 May 2002 06:13:11 -0700 (PDT) [thread overview]
Message-ID: <20020509.061311.59887036.davem@redhat.com> (raw)
In-Reply-To: <20020509152116.A8428@dualathlon.random>
From: Andrea Arcangeli <andrea@suse.de>
Date: Thu, 9 May 2002 15:21:16 +0200
The reason I did this patch is because it was functional equivalent to
old 2.4 kernels.
in turn old 2.4 kernels were all wrong:
if (no_share) {
struct page *new_page = alloc_page(GFP_HIGHUSER);
if (new_page) {
copy_user_highpage(new_page, old_page, address);
flush_page_to_ram(new_page);
} else
new_page = NOPAGE_OOM;
page_cache_release(page);
return new_page;
}
flush_page_to_ram(old_page);
return old_page;
they don't flush old_page before the the memcpy, they only flush the
_anon_ page _after_ the memcpy like current kernel with vm updates or Hugh's
patch is doing (never the pagecache if it's an early cow).
filemap.c:filemap_nopage() does the flush in 2.4.x, what are you
talking about?
It seems like
moving the early cow into memory.c fixed the flush_page_to_ram bug by
luck, because Hugh's patch is otherwise equivalent to old 2.4 kernels.
Confirm?
No it isn't. In 2.4.x kernels filemap_nopage does the flush just
like it does now in 2.5.x What ancient 2.4.x sources are you looking
at where filemap_nopage does not do the flush_page_to_ram right after
the success: label?
If yes, I prefer to move the flush_page_to_ram on the _pagecache_
_before_ the memcpy into memory.c, it's cleaner if the pagecache layer
doesn't need to care about cache aliasing between kernel direct mapping
and userspace address space (but that it only cares about struct pages
and filesystem, so only kernel side), and that such user-related part is
covered only in memory.c.
NO! The correct answer is to kill off flush_page_to_ram altogether.
It is broken by design, and trying to make it work somehow "better"
in 2.5.x is a losing game. We should make the ports fix up their
stuff for a mechanism that we know _does_ work and that is
flush_dcache_page plus {copy,clear}_user_page().
next prev parent reply other threads:[~2002-05-09 13:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-09 12:03 [PATCH] double flush_page_to_ram Hugh Dickins
2002-05-09 11:56 ` David S. Miller
2002-05-09 13:01 ` Andrea Arcangeli
2002-05-09 12:52 ` David S. Miller
2002-05-09 13:21 ` Andrea Arcangeli
2002-05-09 13:13 ` David S. Miller [this message]
2002-05-09 13:44 ` Andrea Arcangeli
2002-05-09 13:35 ` David S. Miller
2002-05-09 13:50 ` Hugh Dickins
2002-05-09 14:16 ` David S. Miller
2002-05-09 13:18 ` Hugh Dickins
2002-05-09 13:07 ` David S. Miller
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=20020509.061311.59887036.davem@redhat.com \
--to=davem@redhat.com \
--cc=akpm@zip.com.au \
--cc=andrea@suse.de \
--cc=cr@sap.com \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/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.