From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Anton Blanchard <anton@samba.org>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org,
Andi Kleen <ak@muc.de>, Ian Molton <spyro@f2s.com>,
Russell King <rmk@arm.linux.org.uk>
Subject: Re: [PATCH] Use MM_VM_SIZE in exit_mmap
Date: Wed, 26 Jan 2005 11:17:11 +1100 [thread overview]
Message-ID: <41F6E187.40305@yahoo.com.au> (raw)
In-Reply-To: <20050125142210.GI5920@krispykreme.ozlabs.ibm.com>
[Hi, please cc Andi on 4 level page tables stuff too]
Anton Blanchard wrote:
> Hi,
>
> The 4 level pagetable code changed the exit_mmap code to rely on
> TASK_SIZE. On some architectures (eg ppc64 and ia64), this is a per task
> property and bad things can happen in certain circumstances when using
> it.
>
> It is possible for one task to end up "owning" an mm from another - we
> have seen this with the procfs code when process 1 accesses
> /proc/pid/cmdline of process 2 while it is exiting. Process 2 exits
> but does not tear its mm down. Later on process 1 finishes with the proc
> file and the mm gets torn down at this point.
>
> Now if process 1 was 32bit and process 2 was 64bit then we end up using
> a bad value for TASK_SIZE in exit_mmap. We only tear down part of the
> address space and leave half initialised pagetables and entries in the
> MMU etc.
>
> MM_VM_SIZE() was created for this purpose (and is used in the next line
> for tlb_finish_mmu), so use it. I moved the PGD round up of TASK_SIZE
> into the default MM_VM_SIZE.
>
Yep, looks like the right thing to do. I don't know about moving the
rounding into MM_VM_SIZE though - it is basically just a requirement of
clear_page_range. Might be better to leave it there?
> As an aside, all architectures except one define FIRST_USER_PGD_NR as 0:
>
> include/asm-arm26/pgtable.h:#define FIRST_USER_PGD_NR 1
>
> It would be nice to get rid of one more magic constant and just clear
> from 0 ... MM_VM_SIZE(). That would make it consistent with the
> tlb_flush_mmu call below it too.
>
Considering the comments by Ian and Russell, can we remove the special
casing by going in the other direction; feed FIRST_USER_PGD_NR * PGDIR_SIZE
to tlb_finish_mmu? Ian, Russell, this would only be a change to your
architectures... so long as your tlb_finish_mmu isn't doing something
special when it sees a zero argument AFAIKS that would be OK?
next prev parent reply other threads:[~2005-01-26 0:20 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-25 14:22 [PATCH] Use MM_VM_SIZE in exit_mmap Anton Blanchard
2005-01-25 16:46 ` Chris Wedgwood
2005-01-25 16:57 ` Anton Blanchard
2005-01-25 17:13 ` Chris Wedgwood
2005-01-27 20:46 ` [PATCH RFC] Change (some) TASK_SIZE to task_vtop(current) Chris Wedgwood
2005-01-25 23:02 ` [PATCH] Use MM_VM_SIZE in exit_mmap Ian Molton
2005-01-25 23:39 ` Russell King
2005-01-26 0:01 ` Anton Blanchard
2005-01-26 0:17 ` Nick Piggin [this message]
2005-01-26 6:44 ` Andi Kleen
2005-01-26 7:39 ` William Lee Irwin III
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=41F6E187.40305@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=ak@muc.de \
--cc=akpm@osdl.org \
--cc=anton@samba.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rmk@arm.linux.org.uk \
--cc=spyro@f2s.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.