Alan:
I've enclosed a patch against 2.4.18-rc2-ac1, but it appears the same
bug still exists in 2.4.19-pre1-ac1. The "ac"-branch version of
"expand_stack" in "mm/mmap.c" has a code path that doesn't unlock the
spinlock. I noticed when a "gdb" bug tickled it and locked up my
machine.
Kevin Buhr <[email protected]>
* * *
--- linux-2.4.18-rc2-ac1/mm/mmap.c Tue Feb 19 19:13:57 2002
+++ linux-2.4.18-rc2-ac1-local/mm/mmap.c Sat Mar 2 17:58:47 2002
@@ -762,8 +762,10 @@
grow = (vma->vm_start - address) >> PAGE_SHIFT;
/* Overcommit.. */
- if(!vm_enough_memory(grow, 1))
+ if(!vm_enough_memory(grow, 1)) {
+ spin_unlock(&vma->vm_mm->page_table_lock);
return -ENOMEM;
+ }
if (vma->vm_end - address > current->rlim[RLIMIT_STACK].rlim_cur ||
((vma->vm_mm->total_vm + grow) << PAGE_SHIFT) > current->rlim[RLIMIT_AS].rlim_cur) {
This bug also exists in 2.4.19pre2-ac2
-Alex
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - sign up for Fantasy Baseball
http://sports.yahoo.com
> I've enclosed a patch against 2.4.18-rc2-ac1, but it appears the same
> bug still exists in 2.4.19-pre1-ac1. The "ac"-branch version of
> "expand_stack" in "mm/mmap.c" has a code path that doesn't unlock the
> spinlock. I noticed when a "gdb" bug tickled it and locked up my
> machine.
Thanks. Thats one I accidentally introduced when I was doing the strict
oom handling. I'll apply that