sysfs: add entry to indicate network interfaces with random MAC address
in [Kernel]
|
Prev: sysfs: add entry to indicate network interfaces with random MAC address
Next: ds2782_battery: Rename get_current and get_voltage operations
From: Harald Hoyer on 21 Jul 2010 02:50 On 07/21/2010 08:34 AM, David Miller wrote: > From: Harald Hoyer<harald(a)redhat.com> > Date: Wed, 21 Jul 2010 08:26:27 +0200 > >> On 07/20/2010 11:20 PM, David Miller wrote: >>> From: Stephen Hemminger<shemminger(a)vyatta.com> >>> Date: Tue, 20 Jul 2010 14:18:16 -0700 >>> >>>> No one mentioned that the first octet of an Ethernet address already >>>> indicates "software generated" Ethernet address. Per the standard, >>>> if bit 1 is set it means address is locally assigned. >>>> >>>> static inline bool is_locally_assigned_ether(const u8 *addr) >>>> { >>>> return (addr[0]& 0x2) != 0; >>>> } >>> >>> W00t! >>> >>> Indeed, can udev just use that? :-) >> >> It already does: >> see /lib/udev/rules.d/75-persistent-net-generator.rules > > So... why doesn't this work? It works.. but the information, that the MAC is randomly generated would be valuable. So, for the non-random locally assigned MAC (with bit 1), we could easily make persistent rules based on the MAC, instead of completely ignoring them, like we do currently. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Stefan Assmann on 21 Jul 2010 04:20 On 20.07.2010 22:18, David Miller wrote: > From: Stefan Assmann <sassmann(a)redhat.com> > Date: Tue, 20 Jul 2010 14:17:30 +0200 > >> On 20.07.2010 13:58, Alex Badea wrote: >>> Hi, >>> >>> On 07/20/2010 02:47 PM, Stefan Assmann wrote: >>>>> What about devices that 'steal' MAC addresses from slave devices? >>> >>> Might I suggest an attribute such as "address_type", which could report >>> "permanent", "random", "stolen", or something else in the future? >> >> In case there's demand for such a multi-purpose attribute I see no >> reason to object. More thoughts on this? > > I think this is a great idea. > > Now it makes sense to use a new 'u8' in struct netdevice or similar to > store this, since we'll have more than a boolean here. > I put Alex' idea into code for further discussion, keeping the names mentioned here until we agree on the scope of this attribute. When we have settled I'll post a patch with proper patch description. Stefan --- include/linux/etherdevice.h | 14 ++++++++++++++ include/linux/netdevice.h | 6 ++++++ net/core/net-sysfs.c | 2 ++ 3 files changed, 22 insertions(+), 0 deletions(-) diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h index 3d7a668..f15cac8 100644 --- a/include/linux/etherdevice.h +++ b/include/linux/etherdevice.h @@ -127,6 +127,20 @@ static inline void random_ether_addr(u8 *addr) } /** + * dev_hw_addr_random - Create random MAC and set device flag + * @dev: pointer to net_device structure + * @addr: Pointer to a six-byte array containing the Ethernet address + * + * Generate random MAC to be used by a device and set addr_type + * so the state can be read by sysfs and be used by udev. + */ +static inline void dev_hw_addr_random(struct net_device *dev, u8 *hwaddr) +{ + dev->addr_type |= NET_ADDR_RANDOM; + random_ether_addr(hwaddr); +} + +/** * compare_ether_addr - Compare two Ethernet addresses * @addr1: Pointer to a six-byte array containing the Ethernet address * @addr2: Pointer other six-byte array containing the Ethernet address diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index b626289..2718895 100644 --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h @@ -66,6 +66,11 @@ struct wireless_dev; #define HAVE_FREE_NETDEV /* free_netdev() */ #define HAVE_NETDEV_PRIV /* netdev_priv() */ +/* hardware address types */ +#define NET_ADDR_PERM 0 /* address is permanent (default) */ +#define NET_ADDR_RANDOM 1 /* address is generated randomly */ +#define NET_ADDR_STOLEN 2 /* address is stolen from other device */ + /* Backlog congestion levels */ #define NET_RX_SUCCESS 0 /* keep 'em coming, baby */ #define NET_RX_DROP 1 /* packet dropped */ @@ -920,6 +925,7 @@ struct net_device { /* Interface address info. */ unsigned char perm_addr[MAX_ADDR_LEN]; /* permanent hw address */ unsigned char addr_len; /* hardware address length */ + unsigned char addr_type; /* hardware address type */ unsigned short dev_id; /* for shared network cards */ spinlock_t addr_list_lock; diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c index d2b5965..052ab14 100644 --- a/net/core/net-sysfs.c +++ b/net/core/net-sysfs.c @@ -96,6 +96,7 @@ static ssize_t netdev_store(struct device *dev, struct device_attribute *attr, NETDEVICE_SHOW(dev_id, fmt_hex); NETDEVICE_SHOW(addr_len, fmt_dec); +NETDEVICE_SHOW(addr_type, fmt_dec); NETDEVICE_SHOW(iflink, fmt_dec); NETDEVICE_SHOW(ifindex, fmt_dec); NETDEVICE_SHOW(features, fmt_long_hex); @@ -296,6 +297,7 @@ static ssize_t show_ifalias(struct device *dev, static struct device_attribute net_class_attributes[] = { __ATTR(addr_len, S_IRUGO, show_addr_len, NULL), + __ATTR(addr_type, S_IRUGO, show_addr_type, NULL), __ATTR(dev_id, S_IRUGO, show_dev_id, NULL), __ATTR(ifalias, S_IRUGO | S_IWUSR, show_ifalias, store_ifalias), __ATTR(iflink, S_IRUGO, show_iflink, NULL), -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Stefan Assmann on 22 Jul 2010 03:00 On 21.07.2010 20:43, Rose, Gregory V wrote: > I'm curious, what happens when the VM using the VF migrates to a new machine and has another VF assigned to with a different MAC address? > > Intel's view of things is that we don't use persistent MAC addresses in our VFs because the MAC address belongs to the VM and when it migrates it's going to want to use another VF with the same MAC address. If they're persistent I'm wondering how that can be done. > > This discussion has come about because some folks want to use the VF in the Host VMM. The original design goal for Intel was that VFs would be assigned to VMs and that VMM vendors would want to assign MAC addresses with their own assigned OUI's. Using the VF in the host is a feature and I'm sure people will think of ways to make good use of it. However the actual problem we've seen is a more practical one. So to pass-through a VF to a VM the host has to be aware that the VF exists. Therefore you usually have to enable the VF in the host (i.e. specify the max_vfs parameter). The device will be discovered by the system and because of the random MAC address udev ignores the new device. With the additional information we provide with our solution udev will be able to recognize the device by it's "device path" and handle it properly (until you decide to pass it to a VM or just be happy with it in the host). Remember the issue that lead to the proposal of renaming VFs to vfeth? That's exactly the problem we try to fix. Additional benefit of an "address assignment type" as Ben likes to call it would be the handling of MAC address stealing NICs. Stefan -- Stefan Assmann | Red Hat GmbH Software Engineer | Otto-Hahn-Strasse 20, 85609 Dornach | HR: Amtsgericht Muenchen HRB 153243 | GF: Brendan Lane, Charlie Peters, sassmann at redhat.com | Michael Cunningham, Charles Cachera -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Stefan Assmann on 23 Jul 2010 04:10
On 23.07.2010 02:26, Casey Leedom wrote: > > Or you simply don't have the VF Driver loaded in the "Domain 0" Control OS. When we install the cxgb4 PF Driver with "num_vf=..." this enables the PCI-E SR-IOV Capabilities within the various PFs and the corresponding VF PCI Devices are instantiated and discovered by the Domain 0 Linux OS. But without a cxgb4vf VF Driver loaded, those devices just sit there available for "Device Assignment" to VMs. > Just out of curiosity, how do you prevent the VF driver from getting loaded in the host? Except from blacklisting it. Stefan -- Stefan Assmann | Red Hat GmbH Software Engineer | Otto-Hahn-Strasse 20, 85609 Dornach | HR: Amtsgericht Muenchen HRB 153243 | GF: Brendan Lane, Charlie Peters, sassmann at redhat.com | Michael Cunningham, Charles Cachera -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |