Avi Kivity wrote:
Well, dup_mm() can't work (and now that I think about it, for more
reasons -- what if the process has threads?).
We lock out multithreaded users already, -EINVAL.
-
This SF.net email is sponsored by:
Carsten Otte wrote:
Avi Kivity wrote:
Well, dup_mm() can't work (and now that I think about it, for more
reasons -- what if the process has threads?).
We lock out multithreaded users already, -EINVAL.
Would be much better if this can be avoided. It's surprising.
--
Any sufficiently
Am Freitag, den 21.03.2008, 11:29 -0700 schrieb Dave Hansen:
What you've done with dup_mm() is probably the brute-force way that I
would have done it had I just been trying to make a proof of concept or
something. I'm worried that there are a bunch of corner cases that
haven't been
Martin Schwidefsky wrote:
On Sun, 2008-03-23 at 12:15 +0200, Avi Kivity wrote:
Can you convert the page tables at a later time without doing a
wholesale replacement of the mm? It should be a bit easier to keep
people off the pagetables than keep their grubby mitts off the mm
itself.
Heiko Carstens wrote:
What you've done with dup_mm() is probably the brute-force way that I
would have done it had I just been trying to make a proof of concept or
something. I'm worried that there are a bunch of corner cases that
haven't been considered.
What if someone else is poking
On Sun, 2008-03-23 at 12:15 +0200, Avi Kivity wrote:
Can you convert the page tables at a later time without doing a
wholesale replacement of the mm? It should be a bit easier to keep
people off the pagetables than keep their grubby mitts off the mm
itself.
Yes, as far as I can
What you've done with dup_mm() is probably the brute-force way that I
would have done it had I just been trying to make a proof of concept or
something. I'm worried that there are a bunch of corner cases that
haven't been considered.
What if someone else is poking around with ptrace or
On Thu, 2008-03-20 at 21:35 +0100, Carsten Otte wrote:
Dave Hansen wrote:
Well, and more fundamentally: do we really want dup_mm() able to be
called from other code?
Maybe we need a bit more detailed justification why fork() itself isn't
good enough. It looks to me like they basically
Dave Hansen wrote:
On Thu, 2008-03-20 at 21:35 +0100, Carsten Otte wrote:
Dave Hansen wrote:
Well, and more fundamentally: do we really want dup_mm() able to be
called from other code?
Maybe we need a bit more detailed justification why fork() itself isn't
good enough. It looks to me like
From: Martin Schwidefsky [EMAIL PROTECTED]
The SIE instruction on s390 uses the 2nd half of the page table page to
virtualize the storage keys of a guest. This patch offers the s390_enable_sie
function, which reorganizes the page tables of a single-threaded process to
reserve space in the page
Carsten Otte wrote:
+struct mm_struct *dup_mm(struct task_struct *tsk);
No prototypes in .c files. Put this in an appropriate header.
J
-
This SF.net email is sponsored by: Microsoft
Defy all challenges.
On Thu, 2008-03-20 at 10:28 -0700, Jeremy Fitzhardinge wrote:
Carsten Otte wrote:
+struct mm_struct *dup_mm(struct task_struct *tsk);
No prototypes in .c files. Put this in an appropriate header.
Well, and more fundamentally: do we really want dup_mm() able to be
called from other code?
Dave Hansen wrote:
Well, and more fundamentally: do we really want dup_mm() able to be
called from other code?
Maybe we need a bit more detailed justification why fork() itself isn't
good enough. It looks to me like they basically need an arch-specific
argument to fork, telling the new
13 matches
Mail list logo
