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/