More information (was Re: Event loop stall bug in hostapd-0.7.3)

[Bryan Phillippe]

On Jan 12, 2012, at 11:29 AM, Johannes Berg wrote:

> On Thu, 2012-01-12 at 11:17 -0800, Ben Greear wrote:
>> On 01/12/2012 11:14 AM, Bryan Phillippe wrote:
>>> 
>>> Oh, I forgot to post that:
>>> 
>>> [155186.946703] hostapd       S 0fd16088     0   415    929 0x00000000
>>> [155186.952994] Call Trace:
>>> [155186.955541] [deab5ac0] [cdb0ada0] 0xcdb0ada0 (unreliable)
>>> [155186.961050] [deab5b80] [c00089d0] __switch_to+0x9c/0xc4
>>> [155186.966379] [deab5b90] [c03bfbb0] schedule+0x1e0/0x350
>>> [155186.971621] [deab5be0] [c03c0250] schedule_timeout+0x158/0x19c
>>> [155186.977567] [deab5c20] [c02cc184] sock_alloc_send_pskb+0x1a4/0x364
>>> [155186.983857] [deab5c80] [c03aee7c] packet_sendmsg+0x7e4/0x9f4
>>> [155186.989622] [deab5cf0] [c02c80cc] sock_sendmsg+0x90/0xc8
>>> [155186.995039] [deab5dc0] [c02c8904] sys_sendmsg+0x234/0x2d8
>>> [155187.000544] [deab5f10] [c02ca250] sys_socketcall+0x144/0x258
>>> [155187.006309] [deab5f40] [c0011348] ret_from_syscall+0x0/0x3c
>>> [155187.012008] --- Exception: c01 at 0xfd16088
>>> [155187.012013]     LR = 0x1004e430
>>> 
>>> So I guess sock_alloc_send_pskb() is where it's going to sleep.  I'll keep digging into it.
>>> 
>>> As a test I did an fcntl(drv->monitor_sock, F_SETFL, O_NONBLOCK) on the socket at creation time and then made hostapd exit if there is ever a write error.
>> 
>> If you build symbols into your kernel you can figure out the line of code that is sock_alloc_send_pskb+0x1a4/0x364
>> using gdb.
> 
> It's almost certainly sock_wait_for_wmem()
> 
> johannes
> 

Agreed; I've looked through the code and this is where schedule_timeout() is called.

--
-bp