Re: Patch(?): linux-2.4.3-pre6/mm/vmalloc.c could return with

[Marcelo Tosatti]

On Fri, 23 Mar 2001, Adam J. Richter wrote:

> 	[Sorry for posting three messages to linux-kernel about this.
> Each time I was pretty sure I was done for the night.  Anyhow, I
> hope this proposed patch makes up for it.]
> 
> 	In linux-2.4.3-pre6, a call to vmalloc can result in a call to
> pte_alloc without the appropriate page_table_lock being held.  Here is
> the call graph, from my post of about half an hour ago:
> 
>         vmalloc
>         __vmalloc
>         vmalloc_area_pages
>         alloc_area_pmd
>         pte_alloc ...which assumes (here incorrectly) that
>                 mm->page_table_lock is held, and sometimes releases
>                 and reacquires mm->page_table_lock.
> 
> 	Not only does pte_alloc expect mm->page_table_lock 
> to be held when it is called, but it also sometimes releases and
> reacquires it.  vmalloc did not release this lock either, of course.
> So, the next attempt to acquire the same mm->page_table_lock spin lock
> hangs.
> 
> 	The symptom that I had noticed was the agpgart.o module hanging
> at module initialization, but it is a much more general problem, and
> could explain all sorts of hangs in 2.4.3-pre6.
> 
> 	Anyhow, with this patch, agpgart.o loads just fine and the
> kernel seems to have suffered no negative side effects.  I am
> not confident in exactly where I chose to put the spin_lock and
> spin_unlock calls, so I would recommend a careful examination of
> this patch before integrating.

There is no need to hold mm->page_table_lock for vmalloced memory.

I guess a better solution is to make the vmalloc codepath use
"pte_alloc_vmalloc" (or something like that) which would be a
spinlock-free version of pte_alloc (like the old one).