I wasn't talking about the vmalloc()ed area. I meant to
say that the 8kB piece allocated by fork() doubles as a
kernel stack for the process.
This can be very bad when a driver inside the kernel
expects a physically contiguous area and (as a result)
scribbles over other data that happened to be physically
contiguous to the first page of the stack.
Then there could occur a context switch which would swap
out that _other_ piece of memory, which happened to
contain a kernel stack piece of memory...
> swapout code is vma based and vmalloc() doesnt use vmas, it uses it's own
> private list ...
>
> besides performance another problem with the patch is that certain drivers
> allocate SCSI structures on the kernel stack and do DMA to it. I have
That is almost exactly what I said :)
> found out the hard way when i tried to implement vmalloc()-style kernel
> stacks (see the MMU kernel patch stack) 2 years ago. While this could
> theoretically be fixed (the driver), and while on certain architectures we
> use an MMU stack (certain Sparcs), it's generally a good idea to have all
> kernel memory 'directly' mapped, it's a robust concept.
I'm busy on the allocator, but there are certain other things
that have priority right now. This is mainly because the
allocator probably isn't going to make it before 2.2 anyway.
It also is because I don't want another allocator that's been
put together in a hurry, I want one that supports _all_ wanted
and needed features. This takes some time to design properly...
Rik.
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu