From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Matt Mackall <mpm@selenic.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Gerald Schaefer <gerald.schaefer@de.ibm.com>,
akpm@linux-foundation.org
Subject: Re: [PATCH] acquire mmap semaphore in pagemap_read.
Date: Thu, 12 Mar 2009 16:54:51 +0100 [thread overview]
Message-ID: <20090312165451.1a7ef22f@skybase> (raw)
In-Reply-To: <1236871414.3213.50.camel@calx>
On Thu, 12 Mar 2009 10:23:34 -0500
Matt Mackall <mpm@selenic.com> wrote:
> Well it means we may have to reintroduce the very annoying double
> buffering from various earlier implementations. But let's leave this
> discussion until after we've figured out what to do about the walker
> code.
About the walker code. I've realized that there is another way to fix
this. The TASK_SIZE definition is currently used for two things: 1) as
a maximum mappable address, 2) the size of the address space for a
process. And there lies a problem: while a process is using a reduced
page table 1) and 2) differ. If I make TASK_SIZE give you the current
size of the address space then it is not possible to mmap an object
beyond 4TB and the page table upgrade never happens. If I make
TASK_SIZE return the maximum mappable address the page table walker
breaks. The solution could be to introduce MAX_TASK_SIZE and use that
in the mmap code to find out what can be mapped.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
WARNING: multiple messages have this Message-ID (diff)
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Matt Mackall <mpm@selenic.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Gerald Schaefer <gerald.schaefer@de.ibm.com>,
akpm@linux-foundation.org
Subject: Re: [PATCH] acquire mmap semaphore in pagemap_read.
Date: Thu, 12 Mar 2009 16:54:51 +0100 [thread overview]
Message-ID: <20090312165451.1a7ef22f@skybase> (raw)
In-Reply-To: <1236871414.3213.50.camel@calx>
On Thu, 12 Mar 2009 10:23:34 -0500
Matt Mackall <mpm@selenic.com> wrote:
> Well it means we may have to reintroduce the very annoying double
> buffering from various earlier implementations. But let's leave this
> discussion until after we've figured out what to do about the walker
> code.
About the walker code. I've realized that there is another way to fix
this. The TASK_SIZE definition is currently used for two things: 1) as
a maximum mappable address, 2) the size of the address space for a
process. And there lies a problem: while a process is using a reduced
page table 1) and 2) differ. If I make TASK_SIZE give you the current
size of the address space then it is not possible to mmap an object
beyond 4TB and the page table upgrade never happens. If I make
TASK_SIZE return the maximum mappable address the page table walker
breaks. The solution could be to introduce MAX_TASK_SIZE and use that
in the mmap code to find out what can be mapped.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
--
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 prev parent reply other threads:[~2009-03-12 15:58 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-12 10:33 [PATCH] acquire mmap semaphore in pagemap_read Martin Schwidefsky
2009-03-12 10:33 ` Martin Schwidefsky
2009-03-12 11:45 ` Alexey Dobriyan
2009-03-12 11:45 ` Alexey Dobriyan
2009-03-12 11:54 ` Martin Schwidefsky
2009-03-12 11:54 ` Martin Schwidefsky
2009-03-12 15:23 ` Matt Mackall
2009-03-12 15:23 ` Matt Mackall
2009-03-12 15:27 ` Martin Schwidefsky
2009-03-12 15:27 ` Martin Schwidefsky
2009-03-12 15:41 ` Brice Goglin
2009-03-12 15:41 ` Brice Goglin
2009-03-12 15:46 ` Martin Schwidefsky
2009-03-12 15:46 ` Martin Schwidefsky
2009-03-12 15:54 ` Martin Schwidefsky [this message]
2009-03-12 15:54 ` Martin Schwidefsky
2009-03-17 12:04 ` Martin Schwidefsky
2009-03-17 12:04 ` Martin Schwidefsky
2009-03-17 16:21 ` Matt Mackall
2009-03-17 16:21 ` Matt Mackall
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=20090312165451.1a7ef22f@skybase \
--to=schwidefsky@de.ibm.com \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=gerald.schaefer@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mpm@selenic.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.