Ingo,
> ah ... i think i did it like that because i didnt realize that there
> would be a recursive call sequence, i was concentrating on recursive
> locking.
That makes sense. It doesn't seem right that it gets called
recursive in the first place. I'm not sure, however, if the tunnel
code can help it as it uses ip_output to send packets.
> incidentally, this code got cleaned up in .23-rc1-rt0, and now it looks
> quite similar to your suggested fix. Could you double-check that it
> solves your problem?
I've downloaded .23-rc1-rt0. It appears the issue remains in both places
as seen below:
net/core/dev.c: dev_queue_xmit
#ifdef CONFIG_PREEMPT_RT
if (1) {
#else
int cpu = raw_smp_processor_id(); /* ok because BHs are off */
if (dev->xmit_lock_owner != cpu) {
#endif
and net/sched/sch_generic.c: qdisc_restart
#ifdef CONFIG_PREEMPT_RT
netif_tx_lock(dev);
#else
if (netif_tx_trylock(dev))
/* Another CPU grabbed the driver tx lock */
return handle_dev_cpu_collision(skb, dev, q);
#endif
Mark
-----Original Message-----
From: Ingo Molnar [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 24, 2007 3:15 PM
To: Beauchemin, Mark
Cc: Thomas Gleixner; linux-kernel@vger.kernel.org; David Miller
Subject: Re: [PATCH -rt] Preemption problem in kernel RT Patch
* Beauchemin, Mark <[EMAIL PROTECTED]> wrote:
> I'm not sure why the check for recursion has been removed. In the
> backtrace below, I think it would be caught by this check and not
> recursively call the spinlock code.
ah ... i think i did it like that because i didnt realize that there
would be a recursive call sequence, i was concentrating on recursive
locking.
incidentally, this code got cleaned up in .23-rc1-rt0, and now it looks
quite similar to your suggested fix. Could you double-check that it
solves your problem?
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
