To: Andrew Morton <akpm@osdl.org>, mst@mellanox.co.il
Cc: Roland Dreier <rolandd@cisco.com>, linux-kernel@vger.kernel.org,
       openib-general@openib.org
Subject: Re: [git patch review 1/4] IPoIB: Don't start send-only joins while
 multicast thread is stopped
References: <1139689341370-68b63fa9b8e76d91@cisco.com>
	<20060211140209.57af1b16.akpm@osdl.org>
From: Roland Dreier <rdreier@cisco.com>
Date: Sat, 11 Feb 2006 18:03:18 -0800
In-Reply-To: <20060211140209.57af1b16.akpm@osdl.org> (Andrew Morton's
 message of "Sat, 11 Feb 2006 14:02:09 -0800")
Message-ID: <ada8xsh49ll.fsf@cisco.com>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.17 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 942
Lines: 34

 > Roland Dreier <rolandd@cisco.com> wrote:
 > >
 > >  +	spin_lock_irq(&priv->lock);
 > >  +	set_bit(IPOIB_MCAST_STARTED, &priv->flags);
 > >  +	spin_unlock_irq(&priv->lock);
 > 
 > Strange to put a lock around an atomic op like that.
 > 
 > Sometimes it's valid.   If another cpu was doing:
 > 
 > 	spin_lock(lock);
 > 
 > 	if (test_bit(IPOIB_MCAST_STARTED))
 > 		something();
 > 	...
 > 	if (test_bit(IPOIB_MCAST_STARTED))
 > 		something_else();
 > 
 > 	spin_unlock(lock);
 > 
 > then the locked set_bit() makes sense.
 > 
 > But often it doesn't ;)

Good point.  Michael, any reason why the lock is there around the
set_bit()?  (And similarly for the corresponding clear_bit())

Thanks,
 Roland
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/