lkml.org 
[lkml]   [2007]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRE: [PATCH -rt] Preemption problem in kernel RT Patch
Date
From
Thomas,


> please fix your mail client to do proper line wraps at column 78.

Outlook sucks. I'll install thunderbird this weekend. sorry.

> Nice, but nevertheless wrong theory.
>
> This check is part of the RT-Patch and it _is_ entirely correct:
> Something tries to do a spin_lock() on a lock, which the same task has
> already locked before. That's what the BUG_ON is catching.
>
> There is nothing which can make a task magically the owner of a lock,
> whether preemption is enabled or not.

Thanks for straightening me out. I was reading the function
try_to_take_rt_mutex wrong... The problem makes more sense now. The tunnel
code encapsulates the current packet in a new packet and calls ip_output
to get it to the destination. If the routing table is changing(which
I'm doing when this happens) it could be called recursively. The tunnel
code tries to handle recursion at the top of ipip_tunnel_xmit:

if (tunnel->recursion++) {
tunnel->stat.collisions++;
goto tx_error;
}
The problem is it tries to take dev->lock which it already owns in
dev_queue_xmit before the check for recursion.

Unfortunately, every time I put in debug to see the routing
changes which cause the bug, it doesn't happen. I'll certainly try to
reproduce it with CONFIG_PROVE_LOCKING on, but it won't be till end of next
week as we have a release going out.

Thanks for your help,

Mark Beauchemin





-
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: 2007-06-23 16:09    [W:0.094 / U:0.292 seconds]
©2003-2014 Jasper Spaans. Advertise on this site