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] [day] [month] [year] [list]
Date:	Wed, 15 Aug 2007 12:15:45 -0700
From:	Jay Vosburgh <fubar@...ibm.com>
To:	"Mike Snitzer" <snitzer@...il.com>
cc:	"Andy Gospodarek" <andy@...yhouse.net>,
	"Stephen Hemminger" <shemminger@...l.org>,
	"Jeff Garzik" <jeff@...zik.org>, netdev@...r.kernel.org
Subject: Re: [PATCH 1/1] bonding: eliminate RTNL assertion spew 

Mike Snitzer <snitzer@...il.com> wrote:

>I'd very much like to help out.  The "rtnl assertion spew" isn't
>instilling confidence in customers I've been working with.  If you'd
>like to send me patches in private I'd help test them ASAP.

	I'll send you some stuff off-list in a bit.

>Could you elaborate on the associated risk of _not_ fixing these
>issues?  balance-alb _seems_ to be working even though these traces
>occur on initialization.  But these rtnl traces are clearly more
>generic than balance-alb.

	There are really a couple of things going on.

	One danger is that some network device drivers may sleep in
certain critical sections (set MAC address, for example) while bonding
holds some lock.  Most drivers don't have potential sleeps here, but a
few do.  The most notable as I recall are a subset of the tg3 devices,

	The other danger is that some callback in the notifier call when
the MAC address changes may sleep.

	These are both separate from the RTNL warnings, which are a
notification that the interface is being messed with, but RTNL isn't
held.  The danger here is that a concurrent, independent, operation
could acquire RTNL and simultaneously fiddle with the interface.

	The ultimate problem with fixing it is that the locking in
bonding was implemented before these locking constraints existed, and
untangling the locking to conform to the new rules is fairly invovled.
Andy and I have been through several iterations of a "final" patch, and
we keep finding regressions.

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@...ibm.com
-
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