* Re: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address
From: Casey Leedom @ 2010-07-21 16:34 UTC (permalink / raw)
To: Andy Gospodarek
Cc: Harald Hoyer, David Miller, shemminger, bhutchings, sassmann,
netdev, linux-kernel, gospo, gregory.v.rose, alexander.h.duyck
In-Reply-To: <20100721150732.GR7497@gospo.rdu.redhat.com>
| From: Andy Gospodarek <andy@greyhouse.net>
| Date: Wednesday, July 21, 2010 08:07 am
|
| Agreed. The subtle difference between a locally assigned address that
| is persistent and one that is random would be helpful.
And just to point out that this case _does_ exist: the igb/igbvf drivers use
random_ether_addr() to generate a random, locally assigned MAC address for the
PCI-E SR-IOV Virtual Function MAC Addresses while the cxgb4/cxgb4vf drivers use
a persistent, non-random locally assigned MAC Addresses.
Note that I am neither arguing for nor against the proposal. I'm just
pointing out an existence case for the distinction. And yes, bit 1 being set in
the first octet of a MAC address for locally assigned MAC Addresses is part of
the IEEE 802 specification just as bit 0 being set in the same octet indicates
that it's a multi-station address.
Casey
^ permalink raw reply
* [PATCH net-2.6] ixgbe/igb: catch invalid VF settings
From: Andy Gospodarek @ 2010-07-21 16:40 UTC (permalink / raw)
To: netdev; +Cc: chrisw
Some ixgbe cards put an invalid VF device ID in the PCIe SR-IOV
capability. The ixgbe driver is only valid for PFs or non SR-IOV
hardware. It seems that the same problem could occur on igb hardware as
well, so if we discover we are trying to initialize a VF in ixbge_probe
or igb_probe, print an error and exit.
Based on a patch for ixgbe from Chris Wright <chrisw@sous-sol.org>.
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Cc: Chris Wright <chrisw@sous-sol.org>
---
drivers/net/igb/igb_main.c | 9 +++++++++
drivers/net/ixgbe/ixgbe_main.c | 9 +++++++++
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
index 3881918..cea37e0 100644
--- a/drivers/net/igb/igb_main.c
+++ b/drivers/net/igb/igb_main.c
@@ -1722,6 +1722,15 @@ static int __devinit igb_probe(struct pci_dev *pdev,
u16 eeprom_apme_mask = IGB_EEPROM_APME;
u32 part_num;
+ /* Catch broken hardware that put the wrong VF device ID in
+ * the PCIe SR-IOV capability.
+ */
+ if (pdev->is_virtfn) {
+ WARN(1, KERN_ERR "%s (%hx:%hx) should not be a VF!\n",
+ pci_name(pdev), pdev->vendor, pdev->device);
+ return -EINVAL;
+ }
+
err = pci_enable_device_mem(pdev);
if (err)
return err;
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index 7b5d976..74d9b6d 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -6492,6 +6492,15 @@ static int __devinit ixgbe_probe(struct pci_dev *pdev,
#endif
u32 part_num, eec;
+ /* Catch broken hardware that put the wrong VF device ID in
+ * the PCIe SR-IOV capability.
+ */
+ if (pdev->is_virtfn) {
+ WARN(1, KERN_ERR "%s (%hx:%hx) should not be a VF!\n",
+ pci_name(pdev), pdev->vendor, pdev->device);
+ return -EINVAL;
+ }
+
err = pci_enable_device_mem(pdev);
if (err)
return err;
--
1.6.2.5
^ permalink raw reply related
* Re: [PATCH 2/2] net: dsa: introduce MICREL KSZ8893MQL/BL ethernet switch chip support
From: Joe Perches @ 2010-07-21 16:40 UTC (permalink / raw)
To: Eric Dumazet
Cc: Lennert Buytenhek, Mike Frysinger, netdev, David S. Miller,
uclinux-dist-devel, Karl Beldan, Graf Yang, Bryan Wu
In-Reply-To: <1279726393.2452.60.camel@edumazet-laptop>
On Wed, 2010-07-21 at 17:33 +0200, Eric Dumazet wrote:
> It is used by all pr_err() friends
Shouldn't these drivers be moved into
something like drivers/net/dsa/ rather
than be kept in net?
The #define pr_fmt would be more standard as
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
The printks could be netdev_<level>
Suggested patches:
diff --git a/net/dsa/ksz8893m.c b/net/dsa/ksz8893m.c
index 98cce04..80fb0ac 100644
--- a/net/dsa/ksz8893m.c
+++ b/net/dsa/ksz8893m.c
@@ -8,7 +8,7 @@
* Licensed under the GPL-2 or later.
*/
-#define pr_fmt(fmt) "ksz8893m: " fmt
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/list.h>
#include <linux/netdevice.h>
@@ -42,11 +42,14 @@ static int ksz8893m_read(unsigned char *din, unsigned char reg, int len)
spi_message_init(&message);
spi_message_add_tail(t, &message);
ret = spi_sync(sw.dev, &message);
- if (!ret)
- return message.status;
+ if (ret) {
+ pr_err("read reg%d failed, ret=%d\n", reg, ret);
+ return ret;
+ }
+ if (message.status)
+ pr_err("read reg%d failed, status=%d\n", reg, message.status);
- pr_err("read reg%d failed, ret=%d\n", reg, ret);
- return ret;
+ return message.status;
}
static int ksz8893m_write(unsigned char *dout, unsigned char reg, int len)
@@ -65,11 +68,14 @@ static int ksz8893m_write(unsigned char *dout, unsigned char reg, int len)
spi_message_init(&message);
spi_message_add_tail(t, &message);
ret = spi_sync(sw.dev, &message);
- if (!ret)
- return message.status;
+ if (ret) {
+ pr_err("write reg%d failed, ret=%d\n", reg, ret);
+ return ret;
+ }
+ if (message.status)
+ pr_err("write reg%d failed, status=%d\n", reg, message.status);
- pr_err("write reg%d failed, ret=%d\n", reg, ret);
- return ret;
+ return message.status;
}
static char *ksz8893m_probe(struct mii_bus *bus, int sw_addr)
@@ -168,8 +174,8 @@ static int ksz8893m_setup_port(struct dsa_switch *ds, int p)
if (val < 0)
return val;
val |= AN_ENABLE | FORCE_100 | FORCE_FULL_DUPLEX;
- val &= ~(POWER_DOWN | DISABLE_MDIX | DIS_FAR_END_FAULT |\
- DISABLE_TRANSMIT | DISABLE_LED);
+ val &= ~(POWER_DOWN | DISABLE_MDIX | DIS_FAR_END_FAULT |
+ DISABLE_TRANSMIT | DISABLE_LED);
ret = mdiobus_write(ds->master_mii_bus, p, MII_BMCR, val);
if (ret < 0)
return ret;
@@ -228,8 +234,7 @@ ksz8893m_phy_read(struct dsa_switch *ds, int port, int regnum)
}
static int
-ksz8893m_phy_write(struct dsa_switch *ds,
- int port, int regnum, u16 val)
+ksz8893m_phy_write(struct dsa_switch *ds, int port, int regnum, u16 val)
{
int phy_addr = ksz8893m_port_to_phy_addr(port);
return mdiobus_write(ds->master_mii_bus, phy_addr, regnum, val);
@@ -263,7 +268,7 @@ static void ksz8893m_poll_link(struct dsa_switch *ds)
if (!link) {
if (netif_carrier_ok(dev)) {
- printk(KERN_INFO "%s: link down\n", dev->name);
+ netdev_info(dev, "link down\n");
netif_carrier_off(dev);
}
continue;
@@ -274,8 +279,8 @@ static void ksz8893m_poll_link(struct dsa_switch *ds)
val = mdiobus_read(ds->master_mii_bus, i, MII_BMSR);
if (val < 0)
continue;
- val &= HALF_10_CAPABLE | FULL_10_CAPABLE |\
- HALF_100_CAPABLE | FULL_100_CAPABLE;
+ val &= (HALF_10_CAPABLE | FULL_10_CAPABLE |
+ HALF_100_CAPABLE | FULL_100_CAPABLE);
if (val & FULL_100_CAPABLE) {
speed = 100;
duplex = 1;
@@ -288,8 +293,8 @@ static void ksz8893m_poll_link(struct dsa_switch *ds)
}
if (!netif_carrier_ok(dev)) {
- printk(KERN_INFO "%s: link up, %d Mb/s, %s duplex\n",
- dev->name, speed, duplex ? "full" : "half");
+ netdev_info(dev, "link up, %d Mb/s, %s duplex\n",
+ speed, duplex ? "full" : "half");
netif_carrier_on(dev);
}
}
^ permalink raw reply related
* Re: [PATCH net-2.6] ixgbe/igb: catch invalid VF settings
From: Chris Wright @ 2010-07-21 16:50 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: netdev, chrisw
In-Reply-To: <1279730431-17156-1-git-send-email-andy@greyhouse.net>
* Andy Gospodarek (andy@greyhouse.net) wrote:
> Some ixgbe cards put an invalid VF device ID in the PCIe SR-IOV
> capability. The ixgbe driver is only valid for PFs or non SR-IOV
> hardware. It seems that the same problem could occur on igb hardware as
> well, so if we discover we are trying to initialize a VF in ixbge_probe
> or igb_probe, print an error and exit.
>
> Based on a patch for ixgbe from Chris Wright <chrisw@sous-sol.org>.
>
> Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
> Cc: Chris Wright <chrisw@sous-sol.org>
Acked-by: Chris Wright <chrisw@sous-sol.org>
Only seen this on ixgbe, but since the result there is a kernel panic
makes sense to be defensive.
thanks,
-chris
^ permalink raw reply
* Re: net/dsa
From: Karl Beldan @ 2010-07-21 17:23 UTC (permalink / raw)
To: netdev
In-Reply-To: <20100720215417.GF21121@mail.wantstofly.org>
http://www.mail-archive.com/uclinux-dist-devel@blackfin.uclinux.org/msg04218.html
^ permalink raw reply
* Re: [PATCH 2/2] net: dsa: introduce MICREL KSZ8893MQL/BL ethernet switch chip support
From: David Miller @ 2010-07-21 17:23 UTC (permalink / raw)
To: buytenh-OLH4Qvv75CYX/NnBR394Jw
Cc: karl.beldan-Re5JQEeQqe8AvxtiuMwx3w, vapier-aBrp7R+bbdUdnm+yROfE0A,
netdev-u79uwXL29TY76Z2rM5mHXA, graf.yang-OyLXuOCK7orQT0dZR+AlfA,
uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b
In-Reply-To: <20100721151608.GM21121-SHk0+jKqY/D5VnbZ9m/NDkB+6BGkLq7r@public.gmane.org>
From: Lennert Buytenhek <buytenh-OLH4Qvv75CYX/NnBR394Jw@public.gmane.org>
Date: Wed, 21 Jul 2010 17:16:08 +0200
> On Wed, Jul 21, 2010 at 09:37:22AM -0400, Mike Frysinger wrote:
>
>> +#define pr_fmt(fmt) "ksz8893m: " fmt
>
> This has no users.
egrep pr_fmt include/linux/kernel.h
It feeds into all of the various kernel logging interfaces.
^ permalink raw reply
* Re: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address
From: Stephen Hemminger @ 2010-07-21 17:28 UTC (permalink / raw)
To: Casey Leedom
Cc: Andy Gospodarek, Harald Hoyer, David Miller, bhutchings, sassmann,
netdev, linux-kernel, gospo, gregory.v.rose, alexander.h.duyck
In-Reply-To: <201007210934.27986.leedom@chelsio.com>
On Wed, 21 Jul 2010 09:34:27 -0700
Casey Leedom <leedom@chelsio.com> wrote:
> | From: Andy Gospodarek <andy@greyhouse.net>
> | Date: Wednesday, July 21, 2010 08:07 am
> |
> | Agreed. The subtle difference between a locally assigned address that
> | is persistent and one that is random would be helpful.
>
> And just to point out that this case _does_ exist: the igb/igbvf drivers use
> random_ether_addr() to generate a random, locally assigned MAC address for the
> PCI-E SR-IOV Virtual Function MAC Addresses while the cxgb4/cxgb4vf drivers use
> a persistent, non-random locally assigned MAC Addresses.
>
> Note that I am neither arguing for nor against the proposal. I'm just
> pointing out an existence case for the distinction. And yes, bit 1 being set in
> the first octet of a MAC address for locally assigned MAC Addresses is part of
> the IEEE 802 specification just as bit 0 being set in the same octet indicates
> that it's a multi-station address.
IMHO no local assigned address should be used by udev. The cxgb4 driver
should be using random value.
Does anyone have an example of locally assigned address that has persistence
so that udev could use it.
^ permalink raw reply
* Re: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address
From: David Miller @ 2010-07-21 17:32 UTC (permalink / raw)
To: shemminger
Cc: leedom, andy, harald, bhutchings, sassmann, netdev, linux-kernel,
gospo, gregory.v.rose, alexander.h.duyck
In-Reply-To: <20100721102816.4bef5ada@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 21 Jul 2010 10:28:16 -0700
> IMHO no local assigned address should be used by udev. The cxgb4 driver
> should be using random value.
>
> Does anyone have an example of locally assigned address that has persistence
> so that udev could use it.
The cxgb4 vf addresses are not random because they are fetched from the
card's NVRAM/EEPROM/firmware/whatever and thus are persistent.
We definitely want udev to use persistent rules for them.
This whole issue only exists because of the Intel VF case, where it
lacks persistent addresses but somehow we want to assign persistent
names to it's VF interfaces.
One idea I've proposed in other discussions about this is that if the
address is not persistent (either via the MAC address bit or the sysfs
value we're thinking of providing here) we use the device's geographic
location ("device path") as the key for udev stuff.
^ permalink raw reply
* Re: [PATCH 0/3 net-2.6] bnx2x: Bug fixes in statistics handling
From: David Miller @ 2010-07-21 18:12 UTC (permalink / raw)
To: vladz; +Cc: netdev, eilong, dmitry
In-Reply-To: <1279727936.14094.41.camel@lb-tlvb-vladz>
From: "Vladislav Zolotarov" <vladz@broadcom.com>
Date: Wed, 21 Jul 2010 18:58:55 +0300
> Dave, pls., consider applying the following patches to the net-2.6 tree.
> They include 2 bugs fixes in the statistics handling flow:
All applied.
There is a space character at the beginning of every "Signed-off-by:"
line in your patch postings, please get rid of them for future
submissions.
^ permalink raw reply
* Re: [patch 1/3] drivers/net/cxgb3/t3_hw.c: use new hex_to_bin() method
From: David Miller @ 2010-07-21 18:17 UTC (permalink / raw)
To: akpm; +Cc: netdev, ext-andriy.shevchenko, divy
In-Reply-To: <201007202225.o6KMPGnA021443@imap1.linux-foundation.org>
From: akpm@linux-foundation.org
Date: Tue, 20 Jul 2010 15:25:16 -0700
> From: Andy Shevchenko <ext-andriy.shevchenko@nokia.com>
>
> Get rid of own implementation of hex_to_bin().
>
> Signed-off-by: Andy Shevchenko <ext-andriy.shevchenko@nokia.com>
> Acked-by: Divy Le Ray <divy@chelsio.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Applied.
^ permalink raw reply
* Re: [patch 2/3] arch/um/drivers: remove duplicate structure field initialization
From: David Miller @ 2010-07-21 18:17 UTC (permalink / raw)
To: akpm; +Cc: netdev, julia, shemminger
In-Reply-To: <201007202225.o6KMPHA3021446@imap1.linux-foundation.org>
From: akpm@linux-foundation.org
Date: Tue, 20 Jul 2010 15:25:17 -0700
> From: Julia Lawall <julia@diku.dk>
>
> There are two initializations of ndo_set_mac_address, one to a local
> function that is not used otherwise and one to a function that is defined
> elsewhere.
>
> The semantic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
...
>
> akpm:
>
> - Use the standard eth_mac_addr() in uml_net_set_mac()
>
> - Remove unneeded and racy local set_ether_mac()
>
> - Remove duplicated (and incorrect)
> uml_netdev_ops.ndo_set_mac_address initializer.
>
> Fixes 8bb95b39a16ed55226810596f92216c53329d2fe ("uml: convert network
> device to netdevice ops").
>
> [akpm@linux-foundation.org: rework as above]
> Signed-off-by: Julia Lawall <julia@diku.dk>
> Cc: Stephen Hemminger <shemminger@vyatta.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Applied.
^ permalink raw reply
* Re: [patch 3/3] drivers/net/82596.c: fix warning
From: David Miller @ 2010-07-21 18:18 UTC (permalink / raw)
To: akpm; +Cc: netdev, segooon
In-Reply-To: <201007202225.o6KMPIQd021449@imap1.linux-foundation.org>
From: akpm@linux-foundation.org
Date: Tue, 20 Jul 2010 15:25:18 -0700
> From: Andrew Morton <akpm@linux-foundation.org>
>
> drivers/net/82596.c: In function 'i596_open':
> drivers/net/82596.c:1044: warning: label 'err_irq_dev' defined but not used
>
> Caused by "82596: free resources on error"
>
> Cc: Kulikov Vasiliy <segooon@gmail.com>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
When this hit the -mm tree, I replied to the -mm postinging that I applied
it to net-next-2.6
So it's integrated already :-)
^ permalink raw reply
* Re: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address
From: Casey Leedom @ 2010-07-21 18:29 UTC (permalink / raw)
To: David Miller
Cc: shemminger, andy, harald, bhutchings, sassmann, netdev,
linux-kernel, gospo, gregory.v.rose, alexander.h.duyck
In-Reply-To: <20100721.103249.107094774.davem@davemloft.net>
| From: David Miller <davem@davemloft.net>
| Date: Wednesday, July 21, 2010 10:32 am
|
| From: Stephen Hemminger <shemminger@vyatta.com>
| Date: Wed, 21 Jul 2010 10:28:16 -0700
|
| > IMHO no local assigned address should be used by udev. The cxgb4 driver
| > should be using random value.
| >
| > Does anyone have an example of locally assigned address that has
| > persistence so that udev could use it.
|
| The cxgb4 vf addresses are not random because they are fetched from the
| card's NVRAM/EEPROM/firmware/whatever and thus are persistent.
|
| We definitely want udev to use persistent rules for them.
|
| This whole issue only exists because of the Intel VF case, where it
| lacks persistent addresses but somehow we want to assign persistent
| names to it's VF interfaces.
Yes, we _explicitly_ wanted to have persistent MAC Addresses for our PCI-E SR-
IOV Virtual Functions for a whole raft of reasons. The two most important were:
1. Linux' model for persistent device naming today seems to be
oriented around persistent network device addresses.
2. Lots of data centers use MAC addresses for things like DHCP/BOOTP,
security/filtering, etc.
Our design goal was to look as much like a normal Ethernet MAC as possible in
order to reduce the need for software/behavior changes.
| One idea I've proposed in other discussions about this is that if the
| address is not persistent (either via the MAC address bit or the sysfs
| value we're thinking of providing here) we use the device's geographic
| location ("device path") as the key for udev stuff.
Another option might be to have a new Net Device Operations call to ask the
adapter for a Unique Key. This could be formed for most devices via a tuple of
the {PCI Vendor ID, PCI Device ID, Adapter Serial Number, Port Number, [and if
applicable] Adapter Function ID}. Of course this could be a fairly long string
... :-)
Casey
^ permalink raw reply
* Re: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address
From: David Miller @ 2010-07-21 18:39 UTC (permalink / raw)
To: leedom
Cc: shemminger, andy, harald, bhutchings, sassmann, netdev,
linux-kernel, gospo, gregory.v.rose, alexander.h.duyck
In-Reply-To: <201007211129.48288.leedom@chelsio.com>
From: Casey Leedom <leedom@chelsio.com>
Date: Wed, 21 Jul 2010 11:29:47 -0700
> Another option might be to have a new Net Device Operations call to ask the
> adapter for a Unique Key. This could be formed for most devices via a tuple of
> the {PCI Vendor ID, PCI Device ID, Adapter Serial Number, Port Number, [and if
> applicable] Adapter Function ID}. Of course this could be a fairly long string
> ... :-)
If a unique key were available, it could be used to generate a persistent
MAC address.
And this sort of means that these drivers could use bits of the
device's geographic ID the construct persistent MAC addresses, but
only if done in a MAC namespace that could be guarenteed unique on the
local system.
^ permalink raw reply
* RE: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address
From: Rose, Gregory V @ 2010-07-21 18:43 UTC (permalink / raw)
To: Casey Leedom, David Miller
Cc: shemminger@vyatta.com, andy@greyhouse.net, harald@redhat.com,
bhutchings@solarflare.com, sassmann@redhat.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
gospo@redhat.com, Duyck, Alexander H
In-Reply-To: <201007211129.48288.leedom@chelsio.com>
>-----Original Message-----
>From: Casey Leedom [mailto:leedom@chelsio.com]
>Sent: Wednesday, July 21, 2010 11:30 AM
>To: David Miller
>Cc: shemminger@vyatta.com; andy@greyhouse.net; harald@redhat.com;
>bhutchings@solarflare.com; sassmann@redhat.com; netdev@vger.kernel.org;
>linux-kernel@vger.kernel.org; gospo@redhat.com; Rose, Gregory V; Duyck,
>Alexander H
>Subject: Re: [PATCH net-next] sysfs: add entry to indicate network
>interfaces with random MAC address
>
>| From: David Miller <davem@davemloft.net>
>| Date: Wednesday, July 21, 2010 10:32 am
>|
>| From: Stephen Hemminger <shemminger@vyatta.com>
>| Date: Wed, 21 Jul 2010 10:28:16 -0700
>|
>| > IMHO no local assigned address should be used by udev. The cxgb4
>driver
>| > should be using random value.
>| >
>| > Does anyone have an example of locally assigned address that has
>| > persistence so that udev could use it.
>|
>| The cxgb4 vf addresses are not random because they are fetched from
>the
>| card's NVRAM/EEPROM/firmware/whatever and thus are persistent.
>|
>| We definitely want udev to use persistent rules for them.
>|
>| This whole issue only exists because of the Intel VF case, where it
>| lacks persistent addresses but somehow we want to assign persistent
>| names to it's VF interfaces.
>
> Yes, we _explicitly_ wanted to have persistent MAC Addresses for our
>PCI-E SR-
>IOV Virtual Functions for a whole raft of reasons. The two most
>important were:
>
> 1. Linux' model for persistent device naming today seems to be
> oriented around persistent network device addresses.
>
> 2. Lots of data centers use MAC addresses for things like DHCP/BOOTP,
> security/filtering, etc.
>
>Our design goal was to look as much like a normal Ethernet MAC as
>possible in
>order to reduce the need for software/behavior changes.
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.
- Greg
^ permalink raw reply
* Re: [PATCH] LSM: Add post recvmsg() hook.
From: David Miller @ 2010-07-21 18:45 UTC (permalink / raw)
To: penguin-kernel
Cc: kuznet, pekkas, jmorris, yoshfuji, kaber, paul.moore, netdev,
linux-security-module
In-Reply-To: <201007171017.DFC73498.SFFFOMLVJOHOtQ@I-love.SAKURA.ne.jp>
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: Sat, 17 Jul 2010 10:17:10 +0900
> NETWORKING [IPv4/IPv6] maintainers and Paul, is below patch fine for you?
Unfortunately, after further consideration, I must reject this patch
and also the post accept() LSM hook one.
Sorry.
I looked into history of the discussions on this issue, and I have found
that the core issue with these hooks has not been addressed.
We must ensure that if:
1) Application makes poll() on UDP socket in blocking mode, and UDP
reports that receive data is available
and
2) Application, after such a poll() call, makes a blocking recvmsg() call
and no other activity has occurred on the socket meanwhile
Then we MUST return immediately with that available data.
This LSM hook, when it triggers, can violate this rule, even if you do
this looping thing.
The post accept() hook has the same problems.
Here is where we originally discussed this, in detail:
http://www.spinics.net/lists/netdev/msg95660.html
Therefore, I think this shows that what Tomoyo is trying to do is
fatally flawed. We brought this fundamental issue up to you about a
year ago, and the issue is still not addressed.
So consider very seriously, that what you are trying to do cannot be
performed without breaking applications and API behavioral
expectations.
^ permalink raw reply
* Re: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address
From: David Miller @ 2010-07-21 18:48 UTC (permalink / raw)
To: gregory.v.rose
Cc: leedom, shemminger, andy, harald, bhutchings, sassmann, netdev,
linux-kernel, gospo, alexander.h.duyck
In-Reply-To: <43F901BD926A4E43B106BF17856F0755F184620A@orsmsx508.amr.corp.intel.com>
From: "Rose, Gregory V" <gregory.v.rose@intel.com>
Date: Wed, 21 Jul 2010 11:43:19 -0700
> 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.
If the VM itself is the "physical entity" of the system, the logical
conclusion I come to is that some kind of key should be obtained
through the VM to uniquely give the device a persistent MAC.
You could do things like have the PF controller use the root filesystem
ID label to construct the VF's MAC address, or something like that.
^ permalink raw reply
* Re: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address
From: David Miller @ 2010-07-21 18:50 UTC (permalink / raw)
To: gregory.v.rose
Cc: leedom, shemminger, andy, harald, bhutchings, sassmann, netdev,
linux-kernel, gospo, alexander.h.duyck
In-Reply-To: <20100721.114851.200597269.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 21 Jul 2010 11:48:51 -0700 (PDT)
> You could do things like have the PF controller use the root filesystem
> ID label to construct the VF's MAC address, or something like that.
And here I of course mean the root filesystem of the guest the VF will
be given to.
^ permalink raw reply
* [patch] usbnet: fix 100% CPU use on suspended device
From: Elly Jones @ 2010-07-21 18:51 UTC (permalink / raw)
To: netdev
Subject: [patch] usbnet: fix 100% CPU use on suspended device
From: Elly Jones <ellyjones@google.com>
This patch causes the usbnet module not to attempt to submit URBs to the device
if the device is not ready to accept them. This fixes a misbehavior trigged by
the Qualcomm Gobi driver (released under GPL through their Code Aurora
initiative) which causes the usbnet core to consume 100% of CPU attempting and
failing to submit URBs. This patch is against Linus's 2.6 repo commit
a9f7f2e74ae0e6a801a2433dc8e9124d73da0cb4.
Signed-off-by: Elizabeth Jones <ellyjones@google.com>
---
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 81c76ad..df7e72e 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -1172,6 +1172,7 @@ static void usbnet_bh (unsigned long param)
// or are we maybe short a few urbs?
} else if (netif_running (dev->net) &&
netif_device_present (dev->net) &&
+ dev->udev->can_submit &&
!timer_pending (&dev->delay) &&
!test_bit (EVENT_RX_HALT, &dev->flags)) {
int temp = dev->rxq.qlen;
^ permalink raw reply related
* RE: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address
From: Rose, Gregory V @ 2010-07-21 19:02 UTC (permalink / raw)
To: David Miller
Cc: leedom@chelsio.com, shemminger@vyatta.com, andy@greyhouse.net,
harald@redhat.com, bhutchings@solarflare.com, sassmann@redhat.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
gospo@redhat.com, Duyck, Alexander H
In-Reply-To: <20100721.115023.69942880.davem@davemloft.net>
>-----Original Message-----
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Wednesday, July 21, 2010 11:50 AM
>To: Rose, Gregory V
>Cc: leedom@chelsio.com; shemminger@vyatta.com; andy@greyhouse.net;
>harald@redhat.com; bhutchings@solarflare.com; sassmann@redhat.com;
>netdev@vger.kernel.org; linux-kernel@vger.kernel.org; gospo@redhat.com;
>Duyck, Alexander H
>Subject: Re: [PATCH net-next] sysfs: add entry to indicate network
>interfaces with random MAC address
>
>From: David Miller <davem@davemloft.net>
>Date: Wed, 21 Jul 2010 11:48:51 -0700 (PDT)
>
>> You could do things like have the PF controller use the root
>filesystem
>> ID label to construct the VF's MAC address, or something like that.
>
>And here I of course mean the root filesystem of the guest the VF will
>be given to.
I suppose you could do that but then the VM is going to have to be allowed to set its own MAC address. There is a lot of opposition and concern about allowing VMs to set their own MAC address.
Then there's also support in the kernel now for assigning VF MAC and VLAN via the iproute2 package "ip link" commands. The administrative SW that controls VMs should be assigning MAC addresses to VFs as needed. When the VF is de-assigned from the guest because the VM is migrating then the administrative SW can assign another VF to the VM at the migration target machine and assign the same MAC address then. This way it is all done administratively from the (supposedly) secure host VMM domain and we're not allowing VMs to set their own MAC address.
Ultimately I think I agree that some sort of approach such as you and others have been suggesting should be taken. I'm agnostic about which one because my view of how things should work is a bit different. But if the community thinks that finding some way to set a persistent MAC address for a VF is useful then I'd more than happy to make sure our drivers support that also.
As soon as it is decided what that is of course.
;-)
- Greg
^ permalink raw reply
* Re: [PATCH 0/2] Support untagged symlinks to tagged directories.
From: Greg KH @ 2010-07-21 19:02 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Greg KH, Andrew Morton, Rafael J. Wysocki, Maciej W. Rozycki,
Kay Sievers, Johannes Berg, netdev
In-Reply-To: <m139vd5sms.fsf_-_@fess.ebiederm.org>
On Tue, Jul 20, 2010 at 10:08:27PM -0700, Eric W. Biederman wrote:
>
> Greg KH <gregkh@suse.de> writes:
>
> > On Mon, Jul 19, 2010 at 01:34:51PM -0700, Andrew Morton wrote:
> >> On Thu, 8 Jul 2010 16:06:01 -0700
> >> Greg KH <greg@kroah.com> wrote:
> >>
> >> > On Thu, Jul 08, 2010 at 03:28:53PM -0700, Eric W. Biederman wrote:
> >> > > Greg KH <greg@kroah.com> writes:
> >> > >
> >> > > > With this patch, how does the existing code fail as the drivers aren't
> >> > > > fixed up?
> >> > > >
> >> > > > I like this change, just worried it will cause problems if it gets into
> >> > > > .35, without your RFC patch. Will it?
> >> > >
> >>
> >> geethanks!
> >>
> >> On the FC6 test box I have no networking.
> >
> > Ick.
> >
> > Eric, any ideas?
>
> Yes. I just found some time to test my fixes and things are looking
> good. It really is just two one line fixes.
>
> On the other part of this debug with SYSFS_DEPRECATED enabled it
> with mac80211_hwsim drivers works fine no problems. I expect the
> bnep driver will also be fine.
>
> What is affecting those two is arguably a bug in the non-deprecated
> sysfs mode.
>
> Regardless here are my fixes. I have split this into a patch for
> the warning and a patch for sysfs_delete_link. Because at least
> the sysfs_delete_link code needs to make into 2.6.35 if we can.
Do these patches obsolete the existing one I have in my tree entitled:
Subject: sysfs: Don't allow the creation of symlinks we can't remove
or are they on top of that one?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address
From: David Miller @ 2010-07-21 19:33 UTC (permalink / raw)
To: gregory.v.rose
Cc: leedom, shemminger, andy, harald, bhutchings, sassmann, netdev,
linux-kernel, gospo, alexander.h.duyck
In-Reply-To: <43F901BD926A4E43B106BF17856F0755F1846247@orsmsx508.amr.corp.intel.com>
From: "Rose, Gregory V" <gregory.v.rose@intel.com>
Date: Wed, 21 Jul 2010 12:02:17 -0700
>>From: David Miller <davem@davemloft.net>
>>Date: Wed, 21 Jul 2010 11:48:51 -0700 (PDT)
>>
>>> You could do things like have the PF controller use the root
>>filesystem
>>> ID label to construct the VF's MAC address, or something like that.
>>
>>And here I of course mean the root filesystem of the guest the VF will
>>be given to.
>
> I suppose you could do that but then the VM is going to have to be
> allowed to set its own MAC address. There is a lot of opposition
> and concern about allowing VMs to set their own MAC address.
Why would that be necessary? The host with the PF creating the guest
has access to the "device" and thus the root filesystem of the guest,
and thus could pull in the root filesystem "key" and instantiate the
VF's MAC before booting the guest.
That was the idea, the control node sets up the VF MAC before the guest
boots or can have access to the VF device.
This is completely agnostic of migration or anything like that. The
procedure for setting the VF MAC is always the same.
^ permalink raw reply
* Re: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address
From: Casey Leedom @ 2010-07-21 19:25 UTC (permalink / raw)
To: David Miller
Cc: shemminger, andy, harald, bhutchings, sassmann, netdev,
linux-kernel, gospo, gregory.v.rose, alexander.h.duyck
In-Reply-To: <20100721.113906.102700682.davem@davemloft.net>
| From: David Miller <davem@davemloft.net>
| Date: Wednesday, July 21, 2010 11:39 am
|
| From: Casey Leedom <leedom@chelsio.com>
| Date: Wed, 21 Jul 2010 11:29:47 -0700
|
| > Another option might be to have a new Net Device Operations call to ask
| > the adapter for a Unique Key. This could be formed for most devices via a
| > tuple of the {PCI Vendor ID, PCI Device ID, Adapter Serial Number, Port
| > Number, [and if applicable] Adapter Function ID}. Of course this could
| > be a fairly long string ... :-)
|
| If a unique key were available, it could be used to generate a persistent
| MAC address.
True but ... the Unique Key name space is probably a lot larger (in bits) than
the MAC Address name space (~(48-2) bits) ... :-)
| And this sort of means that these drivers could use bits of the
| device's geographic ID the construct persistent MAC addresses, but
| only if done in a MAC namespace that could be guarenteed unique on the
| local system.
Yep. That's the problem of trying to construct a Unique Locally Assigned MAC
Address from a Unique Name in a larger name space.
| From: "Rose, Gregory V" <gregory.v.rose@intel.com>
| Date: Wednesday, July 21, 2010 11:43 am
|
| 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?
To be honest, I still haven't wrapped my head around how Virtual Machines are
ever going to be able to migrate when they have arbitrary PCI Devices "assigned"
(KVM Terminology) to them (AKA "PCI Pass Through"). Allowing VMs to directly
touch real and arbitrary hardware devices means that some abstraction of "saving
the device state" and "restoring the device state" can be successfully
negotiated ... which would be hard even if you quiesce the device and you
migrate to another Physical Host with identical PCI Hardware which is then
"assigned" to the migrated VM. Hard, hard, hard.
This is why most of the Hypervisor systems have used synthetic Pseudo Devices
to allow that state of those Virtual Devices to be migrated (including the MAC
Addresses which we've been talking about). I actually think that the Microsoft
HyperV approach of Virtual Ingress Queues may be a better solution. You still
need to make the VM-to-Hypervisor transitions but you get to avoid the Free List
memory copy costs which are actually the dominant cost in the RX path to VMs
using software vNICs.
But that's straying far from the topic at hand. The short answer is pretty
much what David suggests: the _hardware_ PCI-E SR-IOV Virtual Function provides
persistent, non-random MAC Addresses for use by the VF Driver -- if it wants to
use them. A VF Driver running in a VM is capable of specifying arbitrary MAC
Addresses for use with the VF and may ignore the hardware MAC Addresses provided
by the VF. This is little different from the current situation with software
vNICs which use manufactured MAC Addresses (which are persistent in all of the
Hypervisor systems at which I've looked).
| From: David Miller <davem@davemloft.net>
| Date: Wednesday, July 21, 2010 11:48 am
|
| If the VM itself is the "physical entity" of the system, the logical
| conclusion I come to is that some kind of key should be obtained
| through the VM to uniquely give the device a persistent MAC.
Which is, as above, what all Hypervisor systems which I've looked at do.
| You could do things like have the PF controller use the root filesystem
| ID label to construct the VF's MAC address, or something like that.
It's actually stored in the VM's meta-data. When a VM migrates from one
Physical Host to another all of the VM's transient and persistent state must be
available to the new Physical Host. Xen, for instance, has the concept of a
Physical Host Pool where all of the Physical Hosts have common access to shared
resources like Network Attached Storage, LAN/VLANs and the shared VM meta-data.
Casey
^ permalink raw reply
* RE: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address
From: Rose, Gregory V @ 2010-07-21 19:35 UTC (permalink / raw)
To: David Miller
Cc: leedom@chelsio.com, shemminger@vyatta.com, andy@greyhouse.net,
harald@redhat.com, bhutchings@solarflare.com, sassmann@redhat.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
gospo@redhat.com, Duyck, Alexander H
In-Reply-To: <20100721.123324.237334251.davem@davemloft.net>
>-----Original Message-----
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Wednesday, July 21, 2010 12:33 PM
>To: Rose, Gregory V
>Cc: leedom@chelsio.com; shemminger@vyatta.com; andy@greyhouse.net;
>harald@redhat.com; bhutchings@solarflare.com; sassmann@redhat.com;
>netdev@vger.kernel.org; linux-kernel@vger.kernel.org; gospo@redhat.com;
>Duyck, Alexander H
>Subject: Re: [PATCH net-next] sysfs: add entry to indicate network
>interfaces with random MAC address
>
>From: "Rose, Gregory V" <gregory.v.rose@intel.com>
>Date: Wed, 21 Jul 2010 12:02:17 -0700
>
>>>From: David Miller <davem@davemloft.net>
>>>Date: Wed, 21 Jul 2010 11:48:51 -0700 (PDT)
>>>
>>>> You could do things like have the PF controller use the root
>>>filesystem
>>>> ID label to construct the VF's MAC address, or something like that.
>>>
>>>And here I of course mean the root filesystem of the guest the VF will
>>>be given to.
>>
>> I suppose you could do that but then the VM is going to have to be
>> allowed to set its own MAC address. There is a lot of opposition
>> and concern about allowing VMs to set their own MAC address.
>
>Why would that be necessary? The host with the PF creating the guest
>has access to the "device" and thus the root filesystem of the guest,
>and thus could pull in the root filesystem "key" and instantiate the
>VF's MAC before booting the guest.
>
>That was the idea, the control node sets up the VF MAC before the guest
>boots or can have access to the VF device.
I misunderstood you. My bad.
Thank for the further explanation.
- Greg
^ permalink raw reply
* Re: [PATCH net-next-2.6] ixgbe: fix ethtool stats
From: Jeff Kirsher @ 2010-07-21 20:17 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Jesse Brandeburg, PJ Waskiewicz, netdev
In-Reply-To: <1279679904.2492.20.camel@edumazet-laptop>
On Tue, Jul 20, 2010 at 19:38, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mardi 20 juillet 2010 à 15:06 -0700, Jeff Kirsher a écrit :
>> On Tue, Jul 20, 2010 at 10:28, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> > Note : I am currently unable to test following patch, could you please
>> > Intel guys test it and Ack (or Nack) it ?
>> >
>> > Thanks !
>> >
>> > [PATCH net-next-2.6] ixgbe: fix ethtool stats
>> >
>> > In latest changes about 64bit stats on 32bit arches,
>> > [commit 28172739f0a276eb8 (net: fix 64 bit counters on 32 bit arches)],
>> > I missed ixgbe uses a bit of magic in its ixgbe_gstrings_stats
>> > definition.
>> >
>> > IXGBE_NETDEV_STAT() must now assume offsets relative to
>> > rtnl_link_stats64, not relative do dev->stats.
>> >
>> > As a bonus, we also get 64bit stats on ethtool -S
>> >
>> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>> > ---
>> > drivers/net/ixgbe/ixgbe_ethtool.c | 42 ++++++++++++++--------------
>> > 1 file changed, 21 insertions(+), 21 deletions(-)
>> >
>>
>> Thanks Eric, I have added it to my queue.
>>
>
> Thanks !
>
> By the way, my ixgbe conf doesnt like net-next-2.6 at all.
> (No link is established in my fiber loop configuration)
>
> current linux-2.6 git runs correctly, link at 10Gb, so there is a
> regression somewhere.
>
> As this machine is quite slow (I dont have anymore my Nehalem dev
> machine, had to use an old setup), a bisection would take one month...
>
>
Eric - can you send your setup and .config so that we can take a look
at why your not getting a link?
--
Cheers,
Jeff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox