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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 24 Jul 2007 15:36:29 -0400
From:	"Beauchemin, Mark" <Mark.Beauchemin@...amorenet.com>
To:	"Ingo Molnar" <mingo@...e.hu>
Cc:	"Thomas Gleixner" <tglx@...utronix.de>,
	<linux-kernel@...r.kernel.org>,
	"David Miller" <davem@...emloft.net>
Subject: RE: [PATCH -rt] Preemption problem in kernel RT Patch

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



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