Messages in this thread | | | Date | Mon, 1 Mar 1999 01:02:36 -0500 (EST) | From | Alexander Viro <> | Subject | Re: [Real fix] Re: Kernel panic: can't push onto full stack |
| |
Michael sent me the lis of oopsen for the second patch. All of them are in the same place and it looks, uhm, interesting. Fragment in question: fs/proc/array.c::get_stat() static int get_stat(int pid, char * buffer) { struct task_struct *tsk; unsigned long vsize, eip, esp, wchan; long priority, nice; int tty_pgrp; sigset_t sigign, sigcatch; char state;
read_lock(&tasklist_lock); tsk = find_task_by_pid(pid); read_unlock(&tasklist_lock); /* FIXME!! This should be done after the last use */ if (!tsk) return 0; state = *get_task_state(tsk); vsize = eip = esp = 0; if (tsk->mm && tsk->mm != &init_mm) { struct vm_area_struct *vma = tsk->mm->mmap; while (vma) { vsize += vma->vm_end - vma->vm_start; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ At that point vma is 08010000. WIth obvious results. Aside of our story - shouldn't we grab the semaphore on tsk->mm here? ISTR that there were problems in proc/array.c. Andrea, could you comment on that? I don't think that it's the cause of problem - it rather looks like a result of earlier fandango on the core, but... Another thing: with the first patch (with additional s/max_files/2*max_files/) oops was pretty interesting - kfree_skbmem() had passed bogus address (0xdcfa1600) to kfree() (Michael - my apologies, initially I've misinterpreted it). It came from inet_recvmsg(). AFAICS in unix_gc() we never mess with queues of AF_INET sockets, so it sounds, erm, interesting. Michael, could you grep through your logs for EIP: and send me the stuff around it (gzipped, if possible ;-)? Alan, you wrote about other reports - were they on l-k too? When did it happen? I couldn't find them in archives ;-/ Cheers, Al
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |