Messages in this thread | | | Date | Fri, 23 Mar 2001 06:35:48 -0300 (BRT) | From | Marcelo Tosatti <> | Subject | Re: Patch(?): linux-2.4.3-pre6/mm/vmalloc.c could return with init_mm.page_table_lock held |
| |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |