netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jay Vosburgh <fubar@us.ibm.com>
To: "Mike Snitzer" <snitzer@gmail.com>
Cc: "Andy Gospodarek" <andy@greyhouse.net>,
	"Stephen Hemminger" <shemminger@osdl.org>,
	"Jeff Garzik" <jeff@garzik.org>,
	netdev@vger.kernel.org
Subject: Re: [PATCH 1/1] bonding: eliminate RTNL assertion spew
Date: Wed, 15 Aug 2007 12:15:45 -0700	[thread overview]
Message-ID: <11975.1187205345@death> (raw)
In-Reply-To: <170fa0d20708151136q1535672dvbc90271afe80ec6f@mail.gmail.com>

Mike Snitzer <snitzer@gmail.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@us.ibm.com

  reply	other threads:[~2007-08-15 19:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-09 22:59 [PATCH 1/1] bonding: eliminate RTNL assertion spew Andy Gospodarek
2007-01-09 23:09 ` Stephen Hemminger
2007-01-10 19:33   ` Andy Gospodarek
2007-01-10 19:53     ` Stephen Hemminger
2007-08-15  3:14     ` Mike Snitzer
2007-08-15  3:27       ` Andy Gospodarek
2007-08-15 18:36         ` Mike Snitzer
2007-08-15 19:15           ` Jay Vosburgh [this message]
2007-01-09 23:13 ` Jeff Garzik
2007-01-09 23:34   ` Andy Gospodarek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=11975.1187205345@death \
    --to=fubar@us.ibm.com \
    --cc=andy@greyhouse.net \
    --cc=jeff@garzik.org \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@osdl.org \
    --cc=snitzer@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).