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:	Sat, 23 Jun 2007 16:26:06 +0200
From:	Thomas Gleixner <tglx@...utronix.de>
To:	"Beauchemin, Mark" <Mark.Beauchemin@...amorenet.com>
Cc:	linux-kernel@...r.kernel.org, mingo@...e.hu,
	David Miller <davem@...emloft.net>
Subject: RE: [PATCH -rt] Preemption problem in kernel RT Patch

Mark,

On Sat, 2007-06-23 at 10:08 -0400, Beauchemin, Mark wrote:
> 	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.

Hmm, this sounds scary. On a vanilla kernel (with debugging disabled),
this code will simply deadlock.

Do you have a test case? If you need more help, please contact the
netdev folks (netdev@...r.kernel.org).

> 	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.

Well, you won't see much more than you already debugged. You see the
place where the lock was taken and the call trace of the function in the
same way you have seen it with the BUG_ON().

	tglx


-
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/