Received:  by oss.sgi.com id <S42244AbQJJQAq>;
	Tue, 10 Oct 2000 09:00:46 -0700
Received: from canospam.agcs.com ([130.131.166.29]:63920 "EHLO
        canospam.agcs.com") by oss.sgi.com with ESMTP id <S42215AbQJJQAZ>;
	Tue, 10 Oct 2000 09:00:25 -0700
Received: from frontier. (marshal.agcs.com [130.131.60.2])
	by canospam.agcs.com (8.9.3/8.9.1) with SMTP id IAA09401
	for <netdev@oss.sgi.com>; Tue, 10 Oct 2000 08:59:23 -0700 (MST)
Posted-Date: Tue, 10 Oct 2000 08:59:23 -0700 (MST)
Received: from pxmail1.agcs.com (pxmail1.agcs.com [130.131.168.5])
	by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id IAA19754
	for <netdev@oss.sgi.com>; Tue, 10 Oct 2000 08:58:09 -0700 (MST)
Received: from agcs.com ([130.131.166.110]) by pxmail1.agcs.com
          (Netscape Messaging Server 3.61)  with ESMTP id AAA17C7;
          Tue, 10 Oct 2000 08:58:39 -0700
Message-ID: <39E33CAF.1F9C51E2@agcs.com>
Date:   Tue, 10 Oct 2000 08:58:39 -0700
From:   Ben Greear <greearb@agcs.com>
Reply-To: greearb@agcs.com
Organization: AG Communication Systems
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To:     Gleb Natapov <gleb@nbase.co.il>
CC:     Ben Greear <greearb@candelatech.com>,
        vlan-devel@lists.sourceforge.net,
        VLAN Mailing List <vlan@Scry.WANfear.com>,
        "netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: Re: [Vlan-devel] Some more questions on multicast & VLAN.
References: <39E0E2C0.559EE3F3@candelatech.com> <20001010104223.A8550@nbase.co.il> <39E33C3D.873C5D3D@candelatech.com> <20001010174806.A967@nbase.co.il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Gleb Natapov wrote:

> On Tue, Oct 10, 2000 at 08:56:45AM -0700, Ben Greear wrote:
> >
> [...]
> > You mentioned that there was a race condition when using SMP, could you explain
> > that one a bit more?  We could probably put a lock around it if we need to, in
> > order to make it safe.
>
>  Not a race condition, but deadlock. Look at linux/net/core/dev_mcast.c. VLAN set_multicast_list()
> function is called from dev_mc_upload() while holding dev_mc_lock. When you try to add or delete
> MC address to/from underlying device from your set_multicast_list() you call dev_mc_{delete,add}
> and they also try to grab the same lock, oops deadlock ;)

Make the dev_mc_lock acquisition conditional:
if (global_vlan_dev_mc_lock_already_grabbed == 1) {
  /* don't get it again, VLAN code already obtained it... */
}
else {
  /* go get the lock.. */
 ....
}

Sure, it isn't beautiful, but it might work untill the subsystem is re-worked a bit...

Ben

>
>
> --
>                         Gleb.

--
Ben Greear        greearb@agcs.com   Pager: 202-2717
(623) 581 4980    "More weight!" -- _The Crucible._
http://hydrogen:8080/home/greearb/public_html/index.html