vmalloc.c question

vmalloc.c question

[Neil Booth]

I have a simple question about vmalloc.c. I'm probably missing something
obvious, but it appears to me that the list "vmlist" of the kernel's
virtual memory areas is not protected by any kind of locking mechanism,
and thus subject to races. (e.g. two CPUs trying to insert a new virtual
memory block in the same place at the same time in get_vm_area).

Or what am I missing?

Thanks,

Neil.
--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: vmalloc.c question

[Kanoj Sarcar]

On Feb 19,  7:24pm, Neil Booth wrote:
> Subject: vmalloc.c question
> I have a simple question about vmalloc.c. I'm probably missing something
> obvious, but it appears to me that the list "vmlist" of the kernel's
> virtual memory areas is not protected by any kind of locking mechanism,
> and thus subject to races. (e.g. two CPUs trying to insert a new virtual
> memory block in the same place at the same time in get_vm_area).
>
> Or what am I missing?
>

Actually, the ia32 specific ioremap function also calls into the
get_vm_area() function. I was assuming that the giant kernel_lock
protects the "vmlist".

Kanoj
--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: vmalloc.c question

[Benjamin C.R. LaHaise]

On Fri, 19 Feb 1999, Neil Booth wrote:

> I have a simple question about vmalloc.c. I'm probably missing something
> obvious, but it appears to me that the list "vmlist" of the kernel's
> virtual memory areas is not protected by any kind of locking mechanism,
> and thus subject to races. (e.g. two CPUs trying to insert a new virtual
> memory block in the same place at the same time in get_vm_area).

That's probably because it assumes the caller holds the global kernel
lock (which is okay -- vmalloc can't be called from bottom half or irq
context safely anyways).

		-ben

--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/