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).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
