From: Andrea Arcangeli <andrea@suse.de>
To: Andi Kleen <ak@suse.de>
Cc: Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org, Dave Hansen <haveblue@us.ibm.com>
Subject: Re: fix iounmap and a pageattr memleak (x86 and x86-64)
Date: Tue, 15 Feb 2005 11:48:27 +0100 [thread overview]
Message-ID: <20050215104827.GY13712@opteron.random> (raw)
In-Reply-To: <20050215103915.GB2623@wotan.suse.de>
On Tue, Feb 15, 2005 at 11:39:15AM +0100, Andi Kleen wrote:
> On Tue, Feb 15, 2005 at 12:15:54AM +0100, Andrea Arcangeli wrote:
> > Hello,
> >
> > the fix for this bug in 2.6.11-rc3 for this bug is wrong, I thought I
>
> Can you describe what exactly is wrong?
the wrong thing is that if I change the size of the guard page in
vmalloc.c, the arch code will break. the guard page is a debugging knob,
people may want to remove it someday to save virtual address space, and
they shouldn't be required to look after N architectures.
Plus people will keep forgetting that p->size has the guard page
included if you don't fix it the right way, x86-64 and x86 have been
corrupting the pageattr of the next physical pages because of that for a
long time.
Plus if you applied the best fix in vmalloc.c, you wouldn't even need to
touch x86 and x86-64 arch dependent code, you could call
change_page_attr on p->size without having to do -PAGE_SIZE.
At least you should define a VMALLOC_GUARD_PAGE_SIZE, or something,
the hardcoding of p->size-PAGE_SIZE looks wrong to me.
next prev parent reply other threads:[~2005-02-15 10:48 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-28 19:21 fix iounmap and a pageattr memleak (x86 and x86-64) Andrea Arcangeli
2004-11-05 8:07 ` Andrea Arcangeli
2004-11-05 8:31 ` Andi Kleen
2004-11-05 8:49 ` Andrea Arcangeli
2005-02-14 23:15 ` Andrea Arcangeli
2005-02-15 10:39 ` Andi Kleen
2005-02-15 10:48 ` Andrea Arcangeli [this message]
2005-02-15 10:51 ` Andi Kleen
2005-02-15 11:11 ` Andrea Arcangeli
2005-02-15 13:14 ` Hugh Dickins
-- strict thread matches above, loose matches on Subject: below --
2004-11-02 21:21 Dave Hansen
2004-11-02 22:07 ` Andrea Arcangeli
2004-11-02 22:21 ` Dave Hansen
2004-11-02 22:29 ` Andrew Morton
2004-11-02 22:34 ` Dave Hansen
2004-11-03 0:54 ` Andrea Arcangeli
2004-11-02 22:45 ` Dave Hansen
2004-11-02 23:00 ` Dave Hansen
2004-11-03 1:35 ` Andrea Arcangeli
2004-11-03 1:43 ` Dave Hansen
2004-11-03 2:26 ` Andrea Arcangeli
2004-11-03 2:48 ` Dave Hansen
2004-11-03 3:05 ` Andrea Arcangeli
2004-11-03 19:37 ` Dave Hansen
2004-11-05 0:02 ` Dave Hansen
2004-11-05 0:40 ` Dave Hansen
2004-11-05 0:53 ` Andrea Arcangeli
2004-11-05 1:55 ` Dave Hansen
2004-11-05 2:08 ` Andrea Arcangeli
2004-11-05 2:23 ` Dave Hansen
2004-11-05 4:03 ` Andrea Arcangeli
2004-11-05 4:20 ` Andrea Arcangeli
2004-11-02 23:04 ` Andrew Morton
2004-11-03 1:40 ` Andrea Arcangeli
2004-11-02 22:34 ` Jason Baron
2004-11-02 23:12 ` Andrea Arcangeli
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=20050215104827.GY13712@opteron.random \
--to=andrea@suse.de \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=haveblue@us.ibm.com \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox