Thread (28 messages) flat view 28 messages, 9 authors, 2001-02-08

Re: context overflow

From: <hidden>
Date: 2001-01-22 22:08:24

Dan Malek wrote:
tom_gall@vnet.ibm.com wrote:
quoted
  current->mm I believe is correct. active_mm for tasks in user space just point
back to mm. kernel space tasks will have an mm of NULL yet their active_mm will
point back to the last user space task they ran.
Not exactly.  Every task running on a CPU must have an active_mm, and
it represents the current context for the MMU.  This active_mm comes
from a single threaded application's 'mm', or in the case of a
thread without an 'mm' from the previous application that ran, or
from somewhere else depending upon VM_CLONE games.
Hi Dan,

  Pat and I huddled around your note and gave this some more thought. Still not
convinced it's wrong tho.
The point you are missing is 'active_mm' represents the current
context for the MMU.  If you get a context overflow, you can't skip
getting and setting a context for an active task just because it
doesn't have a 'current->mm'.  Your modification to do this
results in a task running on a CPU with a "NO CONTEXT" mm, and worse
and incorrect VSID/ASID/PID/whatever for the task running on that MMU.
  active_mm represents the current context of USER space, not kernel space. I
think that's the important point here. If a task doesn't have a current->mm it's
a kernel task. It shouldn't be using the Segment Registers in the context.
Right? A kernel task should only be concerned with addresses in the range of
C0000000-FFFFFFFF which aren't in the context.

  If what you say is true that incorrect VSID/ASID etc could be handed out, I'm
wondering how my box has been up running and stable since last week. It's not
proof that it's right but I would think something would have melted down by
now....
quoted
  The reason for this patch is in the case where the idle task comes in on one
processor and on another processor it has encountered a context overflow.
It's not just the idle task.  It could be any task that is supposed
to get an active_mm from someone else.
  Since current->mm is NULL, it's a kernel task... granted it doesn't have to be
the idle task but it shouldn't matter. Or when you say any task, are you saying
that user tasks as well?

  Correct me if I'm wrong but from the code we were looking at the sched.c when
you pass through switch_mm from a kernel task to a user task, it catches it and
you go from state of NO CONTEXT to the correct context.

  Beat me over the head with a crowbar please if I'm missing something.

Regards,

Tom
--
Tom Gall - PowerPC Linux Team    "Where's the ka-boom? There was
Linux Technology Center           supposed to be an earth
(w) tom_gall@vnet.ibm.com         shattering ka-boom!"
(w) 507-253-4558                 -- Marvin Martian
(h) tgall@rochcivictheatre.org
http://oss.software.ibm.com/developerworks/opensource/linux

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help