lkml.org 
[lkml]   [2004]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [2.4.28-rc1] process stuck in release_task() call
Hello Willy Tarreau!
In article <20041111083312.GE783@alpha.home.local> you wrote:

> > > >>EIP; c012073d <release_task+1fd/230> <=====
> (...)
> > > c0120540 <release_task>:
> > > c0120540: 55 push %ebp
> > > ....
> > > c0120736: 89 d8 mov %ebx,%eax
> > > c0120738: e8 73 dd 01 00 call c013e4b0 <free_pages> <= here
> >
> > is this release_task+1fd? Can you send me the full disassemble of release_task?

> Yes it is because the next instruction after call will be at c0120738+5 =
> c012073d = release_task+1fd. (the return address on the stack is the
> address of the next instruction after the call).

> > It can't be blocked here, its a "call" instruction.

> Seems rather strange indeed ! Perhaps this is not the disassembled function
> of the *running* kernel ?

This is also strange for me. Stack trace should point into __free_pages_ok()
address space. Only this function work with lock's.

> it would be good to disassemble vmlinux and ensure that it is exactly
> the one currently running.

This is code from vmlinux-2.4.28-rc1.

> I too have already lost lots of time searching a wrong bug because I
> disassembled the wrong kernel, so I'm certain it can happen even when
> we're very careful :-(

[skipp]

PS: Please, keep CC: to me.
-
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/

\
 
 \ /
  Last update: 2005-03-22 14:07    [W:0.045 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site