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>] [day] [month] [year] [list]
Date:	Thu, 3 May 2007 10:12:10 +0200 (CEST)
From:	Guennadi Liakhovetski <gl@...-ac.de>
To:	Paul Mackerras <paulus@...ba.org>
Cc:	irda-users@...ts.sourceforge.net, netdev@...r.kernel.org,
	Samuel Ortiz <samuel@...tiz.org>
Subject: ppp_generic.c recursive spinlock_bh(&pch->downl)

Hi Paul,

This has been discussed on these lists since some time already, but as we 
don't seem to come to a proper fix, I decided to summarize our problem 
once again.

A short summary from the ppp PoV:

ppp_push()
{
	spin_lock_bh(&pch->downl);
	pch->chan->ops->start_xmit(pch->chan, skb)
	{
		...
		ppp_output_wakeup()
		{
			ppp_channel_push()
			{
				spin_lock_bh(&pch->downl);
BANG!...

This happens with IrNET. So, the question is, is it legitimate to call 
ppp_channel_push() from the .start_xmit() method? How do other ppp drivers 
do it? Looks like, for examplke, ppp_async checks explicitly for 
recursion, synctty does a try_spinlock_bh()... Is it just a bug in IrNET 
and one just cannot do this, or is there a simple fix for this?

Samuel's suggestion is to offload the call to ppp_output_wakeup() to the 
keventd workqueue, but we haven't been able to make this work properly so 
far.

I have a dirty workaround, whereby I explicitly verify recursion in 
ppp_channel_push(). This works, but it doesn't seem to be a good solution.

Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ