From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jiri Bohac Subject: Re: [PATCH] bonding: 802.3ad: make aggregator_identifier bond-private Date: Fri, 14 Feb 2014 21:51:47 +0100 Message-ID: <20140214205147.GA1798@midget.suse.cz> References: <20140214171350.GC11688@midget.suse.cz> <20140214191243.GA3173@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jay Vosburgh , Veaceslav Falico , Andy Gospodarek , netdev@vger.kernel.org To: Flavio Leitner Return-path: Received: from cantor2.suse.de ([195.135.220.15]:33460 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751838AbaBNUvv (ORCPT ); Fri, 14 Feb 2014 15:51:51 -0500 Content-Disposition: inline In-Reply-To: <20140214191243.GA3173@localhost.localdomain> Sender: netdev-owner@vger.kernel.org List-ID: On Fri, Feb 14, 2014 at 05:12:43PM -0200, Flavio Leitner wrote: > On Fri, Feb 14, 2014 at 06:13:50PM +0100, Jiri Bohac wrote: > > Fix this by making aggregator_identifier private to the bond. > > I don't see how you fix the duplicate agg id with this patch because > you initialize for each bond to 0, then use the same algo further on. > So, what is changing? My understanding is that the aggregator identifier is used internally by the bond and never appears anywhere in the LACP traffic. So having duplicate aggregator ids between two bonds on the same machine does not matter. But it is a problem if two aggregators in the same bond share the same id. Is my understanding wrong? > Actually, aggregator_identifier is a global variable to make sure the > counter is always increasing for new bonds. So, the fix would be to > not reset it to zero, isn't it? I was considering this fix, but my concern was that the variable (u16) would overflow sooner than it does now. It would take 2^16 enslavings on the machine, while with my patch you need 2^16 enslavings on a single bond. Hypothetically, a rogue NET_ADMIN in one net namespace may cause this overflow to break a bond in another nemespace. Maybe I'm being paranoid? ;) -- Jiri Bohac SUSE Labs, SUSE CZ -- Jiri Bohac SUSE Labs, SUSE CZ