From patchwork Fri Sep 11 21:13:04 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Rose, Gregory V" X-Patchwork-Id: 33503 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@bilbo.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from ozlabs.org (ozlabs.org [203.10.76.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.ozlabs.org", Issuer "CA Cert Signing Authority" (verified OK)) by bilbo.ozlabs.org (Postfix) with ESMTPS id D085EB7334 for ; Sat, 12 Sep 2009 07:13:19 +1000 (EST) Received: by ozlabs.org (Postfix) id C4084DDD0B; Sat, 12 Sep 2009 07:13:19 +1000 (EST) Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by ozlabs.org (Postfix) with ESMTP id 6F177DDD01 for ; Sat, 12 Sep 2009 07:13:19 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756849AbZIKVNI (ORCPT ); Fri, 11 Sep 2009 17:13:08 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756840AbZIKVNF (ORCPT ); Fri, 11 Sep 2009 17:13:05 -0400 Received: from mga01.intel.com ([192.55.52.88]:48560 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756838AbZIKVNE convert rfc822-to-8bit (ORCPT ); Fri, 11 Sep 2009 17:13:04 -0400 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 11 Sep 2009 14:09:09 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.44,372,1249282800"; d="scan'208";a="492682995" Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49]) by fmsmga002.fm.intel.com with ESMTP; 11 Sep 2009 14:05:24 -0700 Received: from orsmsx508.amr.corp.intel.com ([10.22.226.46]) by orsmsx603.amr.corp.intel.com ([10.22.226.49]) with mapi; Fri, 11 Sep 2009 14:13:06 -0700 From: "Rose, Gregory V" To: Joe Perches , David Miller CC: "shemminger@vyatta.com" , "Kirsher, Jeffrey T" , "netdev@vger.kernel.org" , "gospo@redhat.com" , "Skidmore, Donald C" Date: Fri, 11 Sep 2009 14:13:04 -0700 Subject: RE: [net-next PATCH V2] etherdevice.h: random_ether_addr update Thread-Topic: [net-next PATCH V2] etherdevice.h: random_ether_addr update Thread-Index: AcozIKok6aexQ7KBQHSZluf4qJalhQAAq7BQ Message-ID: <43F901BD926A4E43B106BF17856F07556A7EAC63@orsmsx508.amr.corp.intel.com> References: <20090911014757.19631.66570.stgit@localhost.localdomain> <20090910190703.25d14533@nehalam> <1252638163.4355.35.camel@Joe-Laptop.home> <20090911.121542.45333246.davem@davemloft.net> <1252700442.15292.62.camel@Joe-Laptop.home> <1252701862.15292.73.camel@Joe-Laptop.home> In-Reply-To: <1252701862.15292.73.camel@Joe-Laptop.home> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org The addresses generated here will likely never be used in a production environment. They are place holders so that the device will function before any management console has done what 99.9% of all vendors will do, which is assign their own address. OK, that 99% is not a real number, but consider it illustrative of the fact that almost all VMM vendors will assign their own MAC addresses. They're useful for test and development and that's about it. We're in discussion with partners about how best to approach the management interface for this and each vendor has his own preferred approach (which complicates the solution) but for now the accepted method is for the igbvf driver to set it's own assigned MAC address in the guest. The discussion is useful but I think we should keep in mind that the addresses in question will be transitory in nature, likely to be never used except for test and development. One thing, the original patch described it as ncessary to help prevent collisions among MAC address and this is incorrect. It was intended to help reduce collisions with other vendors MAC addresses. If the list doesn't consider that a worth while goal then we can withdraw the patch or take one of the suggested permutations. Thanks, - Greg Rose LAN Access Division Intel Corp. -----Original Message----- From: Joe Perches [mailto:joe@perches.com] Sent: Friday, September 11, 2009 1:44 PM To: David Miller Cc: shemminger@vyatta.com; Kirsher, Jeffrey T; netdev@vger.kernel.org; gospo@redhat.com; Rose, Gregory V; Skidmore, Donald C Subject: Re: [net-next PATCH V2] etherdevice.h: random_ether_addr update Perhaps this is slightly better, it doesn't call random32 for each octet and makes sure the leading octet is >= 0x04. random_ether_address should assign a leading octet >= "0x04" Does not use get_random_bytes to avoid drawing down entropy pool. Signed-off-by: Joe Perches --- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h index 3d7a668..fddcabf 100644 --- a/include/linux/etherdevice.h +++ b/include/linux/etherdevice.h @@ -121,9 +121,26 @@ static inline int is_valid_ether_addr(const u8 *addr) */ static inline void random_ether_addr(u8 *addr) { - get_random_bytes (addr, ETH_ALEN); - addr [0] &= 0xfe; /* clear multicast bit */ - addr [0] |= 0x02; /* set local assignment bit (IEEE802) */ + u32 val; + + /* not calling get_random_bytes to avoid using entropy */ + do { + val = random32(); + addr[0] = val; + } while (addr[0] < 4); + addr[0] &= 0xfe; /* clear multicast bit */ + addr[0] |= 0x02; /* set local assignment bit (IEEE802) */ + + val >>= 8; + addr[1] = val; + val >>= 8; + addr[2] = val; + val >>= 8; + addr[3] = val; + val = random32(); + addr[4] = val; + val >>= 8; + addr[5] = val; } /**