RE: [PATCH -rt] Preemption problem in kernel RT Patch

[Beauchemin, Mark]

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:mingo@xxxxxxx]
Sent: Tuesday, July 24, 2007 3:15 PM
To: Beauchemin, Mark
Cc: Thomas Gleixner; linux-kernel@xxxxxxxxxxxxxxx; David Miller
Subject: Re: [PATCH -rt] Preemption problem in kernel RT Patch



* Beauchemin, Mark <Mark.Beauchemin@xxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/