* Re: Yahoo/Msn Ticket Number 3XTA932CL9
From: Yahoo/Msn© @ 2010-03-02 16:26 UTC (permalink / raw)
To: info
£1,000,000.00 has been awarded to you in the Yahoo/Msn Grant Award,send us your Names,Tel,Country:
^ permalink raw reply
* Re: Yahoo/Msn Ticket Number 3XTA932CL9
From: Yahoo/Msn© @ 2010-03-02 16:35 UTC (permalink / raw)
To: info
£1,000,000.00 has been awarded to you in the Yahoo/Msn Grant Award,send us your Names,Tel,Country:
^ permalink raw reply
* Re: [PATCH 1/1] bnx2x: Tx barriers and locks
From: Stanislaw Gruszka @ 2010-03-02 16:59 UTC (permalink / raw)
To: Michael Chan
Cc: Vladislav Zolotarov, netdev@vger.kernel.org, davem@davemloft.net,
Eilon Greenstein, Matthew Carlson
In-Reply-To: <C27F8246C663564A84BB7AB34397724218312F8FD4@IRVEXCHCCR01.corp.ad.broadcom.com>
On Tue, Mar 02, 2010 at 08:18:44AM -0800, Michael Chan wrote:
> Stanislaw Gruszka wrote:
>
> > On Tue, Mar 02, 2010 at 04:50:59AM -0800, Vladislav Zolotarov wrote:
> > > Stanislaw barrier() is not a memory barrier - it's a
> > compiler barrier. I don't think removing it from
> > bnx2x_tx_avail() will improve anything. If u think I'm wrong,
> > could u, pls., provide a specific example.
> >
> > Only improvement is removing confusing code, And comment like
> > "Tell compiler that prod and cons can change" is even more
> > confusing. If you think I'm wrong, just tell as why that
> > barrier is needed :)
>
> The barrier (compiler barrier at least) is required in
> bnx2x_tx_avail(). The status block index can be updated by DMA and
> the compiler doesn't know it (because it is considered wrong to
If you are telling status block index you mean which variable ?
> declare the status block as volatile). Near the end of
> bnx2x_start_xmit() where we call bnx2x_tx_avail() twice. It is
> possible that the compiler will optimize it and not look at the
> status block in memory the second time.
Ok, I'm trying to understand.
^ permalink raw reply
* Re: [Bridge] [PATCH] bridge: per-cpu packet statistics
From: Stephen Hemminger @ 2010-03-02 17:22 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, bridge, David Miller
In-Reply-To: <1267509690.2843.5.camel@edumazet-laptop>
On Tue, 02 Mar 2010 07:01:30 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le lundi 01 mars 2010 à 16:16 -0800, Stephen Hemminger a écrit :
> > The shared packet statistics are a potential source of slow down
> > on bridged traffic. Convert to per-cpu array, but only keep those
> > statistics which change per-packet.
> >
> > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> >
> > ---
> >
> > net/bridge/br_device.c | 43 ++++++++++++++++++++++++++++++++++++++-----
> > net/bridge/br_if.c | 6 ++++++
> > net/bridge/br_input.c | 5 +++--
> > net/bridge/br_private.h | 8 ++++++++
> > 4 files changed, 55 insertions(+), 7 deletions(-)
> >
> > --- a/net/bridge/br_device.c 2010-03-01 08:22:23.476657998 -0800
> > +++ b/net/bridge/br_device.c 2010-03-01 15:31:36.737227465 -0800
> > @@ -26,11 +26,12 @@ netdev_tx_t br_dev_xmit(struct sk_buff *
> > const unsigned char *dest = skb->data;
> > struct net_bridge_fdb_entry *dst;
> > struct net_bridge_mdb_entry *mdst;
> > + struct br_cpu_netstats *brstats = this_cpu_ptr(br->stats);
> >
> > - BR_INPUT_SKB_CB(skb)->brdev = dev;
> > + brstats->tx_packets++;
> > + brstats->tx_bytes += skb->len;
>
>
> On TX path, this is not really necessary, since we already dirtied
> txq->lock before calling br_dev_xmit(), we can use txq->tx_packets and
> txq->tx_bytes for free ?
Bridge is already using lockless transmit LLTX, so tx_lock is not touched.
^ permalink raw reply
* Re: [Bridge] [PATCH] bridge: per-cpu packet statistics
From: Stephen Hemminger @ 2010-03-02 17:23 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, bridge, David Miller
In-Reply-To: <1267520579.2964.27.camel@edumazet-laptop>
On Tue, 02 Mar 2010 10:02:59 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
>
> Le lundi 01 mars 2010 à 16:16 -0800, Stephen Hemminger a écrit :
>
> > + for_each_online_cpu(cpu) {
> > + const struct br_cpu_netstats *bstats
> > + = per_cpu_ptr(br->stats, cpu);
> > +
> > + stats->rx_bytes += bstats->rx_bytes;
> > + stats->rx_packets += bstats->rx_packets;
> > + }
>
> And last point, we should use for_each_possible_cpu() here
>
> Here is your patch with all my comments integrated :
>
> 1) Use txq->{tx_bytes|tx_packets} counter
>
> 2) alloc_percpu(struct ...) instead of alloc_percpu(sizeof(struct ...))
>
> 3) free_netdev() in destructor
>
> 4) for_each_possible_cpu() instead of for_each_online_cpu()
>
> 5) br_get_stats() use local variables for the sake of concurrent users
No need, bridge has no queue!
^ permalink raw reply
* Re: [PATCH] Export smbios strings associated with onboard devices to sysfs
From: Narendra K @ 2010-03-02 17:33 UTC (permalink / raw)
To: matt_domsch
Cc: netdev, linux-hotplug, linux-pci, jordan_hargrave,
sandeep_k_shandilya, charles_rose, shyam_iyer
In-Reply-To: <EDA0A4495861324DA2618B4C45DCB3EE6122A2@blrx3m08.blr.amer.dell.com>
> > -----Original Message-----
> > From: Domsch, Matt [mailto:Matt_Domsch@Dell.com]
> > Sent: Friday, February 26, 2010 2:19 AM
> > To: K, Narendra
> > Cc: netdev@vger.kernel.org; linux-hotplug@vger.kernel.org; linux-
> > pci@vger.kernel.org; Hargrave, Jordan; Shandilya, Sandeep K; Rose,
> > Charles; Iyer, Shyam
> > Subject: Re: [PATCH] Export smbios strings associated with onboard
> > devices to sysfs
> >
> > On Thu, Feb 25, 2010 at 02:29:42PM -0600, K, Narendra wrote:
> > > 1.Export smbios strings of onboard devices, to sysfs. For example -
> >
> > I like the idea in this patch, which exports this additional
> > smbios-provided string in sysfs. This removes the need to parse the
> > SMBIOS table in userspace, which requires root privs.
> >
> > The concept is also extensible to other methods (e.g. ACPI) that I
> > expect will appear for the platform BIOS to provide naming hints to
> > the OS - I want those to appear in sysfs also.
> >
> > now, for the patch:
> >
> > > + if (!(strcmp(attr_name(bus->dev_attrs[i]),
> "smbiosname")))
> > {
> > > + if (!smbiosname_string_is_valid(dev, NULL))
> > > + continue;
> > > + }
> > > error = device_create_file(dev, &bus->dev_attrs[i]);
> > > if (error) {
> > > while (--i >= 0)
> >
> > This cannot go in bus.c. It needs to go in pci-sysfs.c.
> >
Resending the patch with review comments incorporated.
Signed-off-by: Jordan Hargrave <Jordan_Hargrave@dell.com>
Signed-off-by: Narendra K <Narendra_K@dell.com>
---
drivers/firmware/dmi_scan.c | 23 ++++++++++++++++++
drivers/pci/pci-sysfs.c | 54 +++++++++++++++++++++++++++++++++++++++++++
include/linux/dmi.h | 9 +++++++
3 files changed, 86 insertions(+), 0 deletions(-)
diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index 31b983d..1d10663 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -278,6 +278,28 @@ static void __init dmi_save_ipmi_device(const struct dmi_header *dm)
list_add_tail(&dev->list, &dmi_devices);
}
+static void __init dmi_save_devslot(int id, int seg, int bus, int devfn, const char *name)
+{
+ struct dmi_devslot *slot;
+
+ slot = dmi_alloc(sizeof(*slot) + strlen(name) + 1);
+ if (!slot) {
+ printk(KERN_ERR "dmi_save_devslot: out of memory.\n");
+ return;
+ }
+ slot->id = id;
+ slot->seg = seg;
+ slot->bus = bus;
+ slot->devfn = devfn;
+
+ strcpy((char *)&slot[1], name);
+ slot->dev.type = DMI_DEV_TYPE_DEVSLOT;
+ slot->dev.name = &slot[1];
+ slot->dev.device_data = slot;
+
+ list_add(&slot->dev.list, &dmi_devices);
+}
+
static void __init dmi_save_extended_devices(const struct dmi_header *dm)
{
const u8 *d = (u8*) dm + 5;
@@ -286,6 +308,7 @@ static void __init dmi_save_extended_devices(const struct dmi_header *dm)
if ((*d & 0x80) == 0)
return;
+ dmi_save_devslot(-1, *(u16 *)(d+2), *(d+4), *(d+5), dmi_string_nosave(dm, *(d-1)));
dmi_save_one_device(*d & 0x7f, dmi_string_nosave(dm, *(d - 1)));
}
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 807224e..85d5d79 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -142,6 +142,54 @@ static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
(u8)(pci_dev->class));
}
+#ifdef CONFIG_DMI
+#include <linux/dmi.h>
+static ssize_t
+smbiosname_string_is_valid(struct device *dev, char *buf)
+{
+ struct pci_dev *pdev = to_pci_dev(dev);
+ struct dmi_device *dmi;
+ struct dmi_devslot *dslot;
+ int bus;
+ int devfn;
+
+ bus = pdev->bus->number;
+ devfn = pdev->devfn;
+
+ dmi = NULL;
+ while ((dmi = dmi_find_device(DMI_DEV_TYPE_DEVSLOT, NULL, dmi)) != NULL) {
+ dslot = dmi->device_data;
+ if (dslot && dslot->bus == bus && dslot->devfn == devfn) {
+ if (buf)
+ return scnprintf(buf, PAGE_SIZE, "%s\n", dmi->name);
+ return strlen(dmi->name);
+ }
+ }
+}
+
+static ssize_t
+smbiosname_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ return smbiosname_string_is_valid(dev, buf);
+
+}
+
+struct smbios_attribute {
+ struct attribute attr;
+ ssize_t(*show) (struct device * edev, char *buf);
+ int (*test) (struct device * edev, char *buf);
+};
+
+#define SMBIOSNAME_DEVICE_ATTR(_name, _mode, _show, _test) \
+struct smbios_attribute smbios_attr_##_name = { \
+ .attr = {.name = __stringify(_name), .mode = _mode }, \
+ .show = _show, \
+ .test = _test, \
+};
+
+static SMBIOSNAME_DEVICE_ATTR(smbiosname, 0444, smbiosname_show, smbiosname_string_is_valid);
+#endif
+
static ssize_t is_enabled_store(struct device *dev,
struct device_attribute *attr, const char *buf,
size_t count)
@@ -1140,6 +1188,7 @@ static int __init pci_sysfs_init(void)
{
struct pci_dev *pdev = NULL;
int retval;
+ struct smbios_attribute *attr = &smbios_attr_smbiosname;
sysfs_initialized = 1;
for_each_pci_dev(pdev) {
@@ -1148,6 +1197,11 @@ static int __init pci_sysfs_init(void)
pci_dev_put(pdev);
return retval;
}
+#ifdef CONFIG_DMI
+ /* if the device does not have an associated smbios string in the smbios table, do not create this attribute */
+ if (attr->test && attr->test(&pdev->dev, NULL))
+ sysfs_create_file(&pdev->dev.kobj, &attr->attr);
+#endif
}
return 0;
diff --git a/include/linux/dmi.h b/include/linux/dmi.h
index a8a3e1a..cc57c3a 100644
--- a/include/linux/dmi.h
+++ b/include/linux/dmi.h
@@ -20,6 +20,7 @@ enum dmi_device_type {
DMI_DEV_TYPE_SAS,
DMI_DEV_TYPE_IPMI = -1,
DMI_DEV_TYPE_OEM_STRING = -2,
+ DMI_DEV_TYPE_DEVSLOT = -3,
};
struct dmi_header {
@@ -37,6 +38,14 @@ struct dmi_device {
#ifdef CONFIG_DMI
+struct dmi_devslot {
+ struct dmi_device dev;
+ int id;
+ int seg;
+ int bus;
+ int devfn;
+};
+
extern int dmi_check_system(const struct dmi_system_id *list);
const struct dmi_system_id *dmi_first_match(const struct dmi_system_id *list);
extern const char * dmi_get_system_info(int field);
--
1.6.5.2
With regards,
Narendra K
^ permalink raw reply related
* Re: [PATCH 1/1] bnx2x: Tx barriers and locks
From: Michael Chan @ 2010-03-02 17:26 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Vladislav Zolotarov, netdev@vger.kernel.org, davem@davemloft.net,
Eilon Greenstein, Matthew Carlson
In-Reply-To: <20100302165946.GC6491@dhcp-lab-161.englab.brq.redhat.com>
On Tue, 2010-03-02 at 08:59 -0800, Stanislaw Gruszka wrote:
> On Tue, Mar 02, 2010 at 08:18:44AM -0800, Michael Chan wrote:
> > Stanislaw Gruszka wrote:
> >
> > > On Tue, Mar 02, 2010 at 04:50:59AM -0800, Vladislav Zolotarov wrote:
> > > > Stanislaw barrier() is not a memory barrier - it's a
> > > compiler barrier. I don't think removing it from
> > > bnx2x_tx_avail() will improve anything. If u think I'm wrong,
> > > could u, pls., provide a specific example.
> > >
> > > Only improvement is removing confusing code, And comment like
> > > "Tell compiler that prod and cons can change" is even more
> > > confusing. If you think I'm wrong, just tell as why that
> > > barrier is needed :)
> >
> > The barrier (compiler barrier at least) is required in
> > bnx2x_tx_avail(). The status block index can be updated by DMA and
> > the compiler doesn't know it (because it is considered wrong to
>
> If you are telling status block index you mean which variable ?
The fp-> fields which can be updated by NAPI poll based on new status
block DMA.
>
> > declare the status block as volatile). Near the end of
> > bnx2x_start_xmit() where we call bnx2x_tx_avail() twice. It is
> > possible that the compiler will optimize it and not look at the
> > status block in memory the second time.
>
> Ok, I'm trying to understand.
> --
^ permalink raw reply
* RE: [PATCH] Export smbios strings associated with onboard devicesto sysfs
From: Narendra_K @ 2010-03-02 17:42 UTC (permalink / raw)
To: achiang
Cc: netdev, linux-hotplug, linux-pci, Matt_Domsch, Jordan_Hargrave,
Sandeep_K_Shandilya, Charles_Rose, Shyam_Iyer
In-Reply-To: <20100225214020.GA15010@ldl.fc.hp.com>
> -----Original Message-----
> From: Alex Chiang [mailto:achiang@hp.com]
> Sent: Friday, February 26, 2010 3:10 AM
> To: K, Narendra
> Cc: netdev@vger.kernel.org; linux-hotplug@vger.kernel.org; linux-
> pci@vger.kernel.org; Domsch, Matt; Hargrave, Jordan; Shandilya,
Sandeep
> K; Rose, Charles; Iyer, Shyam
> Subject: Re: [PATCH] Export smbios strings associated with onboard
> devicesto sysfs
>
> * Narendra K <Narendra_K@dell.com>:
> >
> > * We have been having discussions in the netdev list about
> > creating multiple names for the network interfaces to bring
> > determinism into the way network interfaces are named in the
> > OSes. In specific, "eth0 in the OS does not always map to the
> > integrated NIC Gb1 as labelled on the chassis".
>
> Yes, I agree that this is a real problem that we do not handle
> well today.
>
> > 1.Export smbios strings of onboard devices, to sysfs. For example -
> >
> > cat /sys/class/net/eth0/device/smbiosname
> > Embedded NIC 2
> >
> > cat /sys/bus/pci/devices/0000\:03\:00.0/smbiosname
> > Embedded NIC 2
>
> I agree with this concept, but I don't like the interface.
>
> The name "smbiosname" isn't the proper level of abstraction. We
> don't want users to care what firmware standard is providing the
> name (think smbios vs acpi vs open firmware...).
>
> We learned this lesson with exposing ACPI interfaces. Let's not
> make the same mistake here.
>
> Something like "firmwarename", "fwname", "platformname" etc. is
> generic, and then the interface will make sense for platforms
> that do not implement SMBIOS.
>
> I don't particularly care which name you choose as long as it's
> properly generic.
>
> As far as implementation goes, I've been thinking about this
> problem for a while now, and I keep wanting to use the
> pci_create_slot() API, but am still a little on the fence about
> it.
>
> The pros:
> - all you have to do is write a simple little driver that
> can read SMBIOS to get PCI bus:devfn and the name, and
> then you call pci_create_slot(). Then you get all sorts
> of stuff for free, like sysfs exposure, proper
> refcounting (important given that the PCI logical
> hotplug interface (/sys/bus/pci/rescan and friends) can
> be used to remove onboard devices), etc.
>
> - see drivers/acpi/pci_slot.c for an example of how to
> detect slots and then register them.
>
> The cons:
> - the user interface is /sys/bus/pci/slots/<name>
>
> I don't know if that is an appropriate interface, since
> technically an onboard device isn't in a slot. But maybe
> if you did something like:
>
> /sys/bus/pci/slots/onboard0
> /sys/bus/pci/slots/onboard1
>
> that might make sense.
>
> Or...
> /sys/bus/pci/onboard/<name>
>
> I read through the patch, but given that the implementation
> strategy might change based on my comments, will hold off and see
> how the conversation develops.
Thanks. I will wait too, to see how the discussion develops on this
method of implementation.
With regards,
Narendra K
^ permalink raw reply
* e1000e: reset of tx_queue_len
From: Franco Fichtner @ 2010-03-02 17:44 UTC (permalink / raw)
To: Netdev, jesse.brandeburg, bruce.w.allan
Hi all,
while working on a new server, I noticed that tx_queue_len is reset
to the default of 1000 while ADDRCONF(NETDEV_CHANGE).
This happens with 2.6.30.8, but I could not see any obvious
differences to the current state of e1000e, while trying to find the
problem in the code.
The interface has been configured including a customized qlen
via /etc/network/interfaces. The ports are not connected at startup
so obviously the Kernel reports
ADDRCONF(NETDEV_UP): eth2: link is not ready
while ifconfig properly displays the customized qlen.
When plugging the server tx_queue_len is reset to 1000.
Any help is appreciated. Thanks.
Franco
^ permalink raw reply
* [PATCH] bridge: per-cpu packet statistics (v2)
From: Stephen Hemminger @ 2010-03-02 17:58 UTC (permalink / raw)
To: David Miller; +Cc: Eric Dumazet, netdev, bridge
In-Reply-To: <1267520579.2964.27.camel@edumazet-laptop>
The shared packet statistics are a potential source of slow down
on bridged traffic. Convert to per-cpu array, but only keep those
statistics which change per-packet.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
Take Eric's bug fix changes. But keep the per cpu transmit
per cpu statistics. There is no point in going multiqueue for
a pseudo-interface which is lockless and queue less.
net/bridge/br_device.c | 43 ++++++++++++++++++++++++++++++++++++++-----
net/bridge/br_if.c | 6 ++++++
net/bridge/br_input.c | 5 +++--
net/bridge/br_private.h | 8 ++++++++
4 files changed, 55 insertions(+), 7 deletions(-)
--- a/net/bridge/br_device.c 2010-03-02 09:26:23.208191713 -0800
+++ b/net/bridge/br_device.c 2010-03-02 09:29:38.811818410 -0800
@@ -26,11 +26,12 @@ netdev_tx_t br_dev_xmit(struct sk_buff *
const unsigned char *dest = skb->data;
struct net_bridge_fdb_entry *dst;
struct net_bridge_mdb_entry *mdst;
+ struct br_cpu_netstats *brstats = this_cpu_ptr(br->stats);
- BR_INPUT_SKB_CB(skb)->brdev = dev;
+ brstats->tx_packets++;
+ brstats->tx_bytes += skb->len;
- dev->stats.tx_packets++;
- dev->stats.tx_bytes += skb->len;
+ BR_INPUT_SKB_CB(skb)->brdev = dev;
skb_reset_mac_header(skb);
skb_pull(skb, ETH_HLEN);
@@ -81,6 +82,31 @@ static int br_dev_stop(struct net_device
return 0;
}
+static struct net_device_stats *br_get_stats(struct net_device *dev)
+{
+ struct net_bridge *br = netdev_priv(dev);
+ struct net_device_stats *stats = &dev->stats;
+ struct br_cpu_netstats sum = { 0 };
+ unsigned int cpu;
+
+ for_each_possible_cpu(cpu) {
+ const struct br_cpu_netstats *bstats
+ = per_cpu_ptr(br->stats, cpu);
+
+ sum.tx_bytes += bstats->tx_bytes;
+ sum.tx_packets += bstats->tx_packets;
+ sum.rx_bytes += bstats->rx_bytes;
+ sum.rx_packets += bstats->rx_packets;
+ }
+
+ stats->tx_bytes = sum.tx_bytes;
+ stats->tx_packets = sum.tx_packets;
+ stats->rx_bytes = sum.rx_bytes;
+ stats->rx_packets = sum.rx_packets;
+
+ return stats;
+}
+
static int br_change_mtu(struct net_device *dev, int new_mtu)
{
struct net_bridge *br = netdev_priv(dev);
@@ -180,19 +206,28 @@ static const struct net_device_ops br_ne
.ndo_open = br_dev_open,
.ndo_stop = br_dev_stop,
.ndo_start_xmit = br_dev_xmit,
+ .ndo_get_stats = br_get_stats,
.ndo_set_mac_address = br_set_mac_address,
.ndo_set_multicast_list = br_dev_set_multicast_list,
.ndo_change_mtu = br_change_mtu,
.ndo_do_ioctl = br_dev_ioctl,
};
+static void br_dev_free(struct net_device *dev)
+{
+ struct net_bridge *br = netdev_priv(dev);
+
+ free_percpu(br->stats);
+ free_netdev(dev);
+}
+
void br_dev_setup(struct net_device *dev)
{
random_ether_addr(dev->dev_addr);
ether_setup(dev);
dev->netdev_ops = &br_netdev_ops;
- dev->destructor = free_netdev;
+ dev->destructor = br_dev_free;
SET_ETHTOOL_OPS(dev, &br_ethtool_ops);
dev->tx_queue_len = 0;
dev->priv_flags = IFF_EBRIDGE;
--- a/net/bridge/br_if.c 2010-03-02 09:26:23.188192219 -0800
+++ b/net/bridge/br_if.c 2010-03-02 09:31:19.801199305 -0800
@@ -185,6 +185,12 @@ static struct net_device *new_bridge_dev
br = netdev_priv(dev);
br->dev = dev;
+ br->stats = alloc_percpu(struct br_cpu_netstats);
+ if (!br->stats) {
+ free_netdev(dev);
+ return NULL;
+ }
+
spin_lock_init(&br->lock);
INIT_LIST_HEAD(&br->port_list);
spin_lock_init(&br->hash_lock);
--- a/net/bridge/br_input.c 2010-03-02 09:26:23.196192436 -0800
+++ b/net/bridge/br_input.c 2010-03-02 09:27:04.424067504 -0800
@@ -23,9 +23,11 @@ const u8 br_group_address[ETH_ALEN] = {
static int br_pass_frame_up(struct sk_buff *skb)
{
struct net_device *indev, *brdev = BR_INPUT_SKB_CB(skb)->brdev;
+ struct net_bridge *br = netdev_priv(brdev);
+ struct br_cpu_netstats *brstats = this_cpu_ptr(br->stats);
- brdev->stats.rx_packets++;
- brdev->stats.rx_bytes += skb->len;
+ brstats->rx_packets++;
+ brstats->rx_bytes += skb->len;
indev = skb->dev;
skb->dev = brdev;
--- a/net/bridge/br_private.h 2010-03-02 09:26:23.180193181 -0800
+++ b/net/bridge/br_private.h 2010-03-02 09:27:04.424067504 -0800
@@ -135,6 +135,14 @@ struct net_bridge
spinlock_t lock;
struct list_head port_list;
struct net_device *dev;
+
+ struct br_cpu_netstats __percpu {
+ unsigned long rx_packets;
+ unsigned long tx_packets;
+ unsigned long rx_bytes;
+ unsigned long tx_bytes;
+ } *stats;
+
spinlock_t hash_lock;
struct hlist_head hash[BR_HASH_SIZE];
unsigned long feature_mask;
^ permalink raw reply
* Re: [PATCH] bridge: per-cpu packet statistics (v2)
From: Eric Dumazet @ 2010-03-02 18:06 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev, bridge
In-Reply-To: <20100302095831.151c8bb5@nehalam>
Le mardi 02 mars 2010 à 09:58 -0800, Stephen Hemminger a écrit :
> + struct br_cpu_netstats __percpu {
> + unsigned long rx_packets;
> + unsigned long tx_packets;
> + unsigned long rx_bytes;
> + unsigned long tx_bytes;
> + } *stats;
> +
Ok, please group rx stats together instead of interleave, this to reduce
possibility of touching two cache lines in tx path (or rx path)
struct br_cpu_netstats __percpu {
> unsigned long rx_packets;
> + unsigned long rx_bytes;
>
> + unsigned long tx_packets;
> + unsigned long tx_bytes;
> + } *stats;
> +
^ permalink raw reply
* Re: e1000e: reset of tx_queue_len
From: Brandeburg, Jesse @ 2010-03-02 18:27 UTC (permalink / raw)
To: Franco Fichtner; +Cc: Netdev, Allan, Bruce W
In-Reply-To: <4B8D4E7E.2000805@lastsummer.de>
On Tue, 2 Mar 2010, Franco Fichtner wrote:
> while working on a new server, I noticed that tx_queue_len is reset
> to the default of 1000 while ADDRCONF(NETDEV_CHANGE).
> This happens with 2.6.30.8, but I could not see any obvious
> differences to the current state of e1000e, while trying to find the
> problem in the code.
The driver tries to set the queuelen back to 1000 if the link changes
speed, because the driver tries to shorten the txqueuelen to 100 to reduce
latency when the link changes to 100/10 Mb/s
> The interface has been configured including a customized qlen
> via /etc/network/interfaces. The ports are not connected at startup
> so obviously the Kernel reports
>
> ADDRCONF(NETDEV_UP): eth2: link is not ready
do your scripts try to configure the queuelen when link is not up? Why
are the ports not connected at startup?
>
> while ifconfig properly displays the customized qlen.
>
> When plugging the server tx_queue_len is reset to 1000.
>
> Any help is appreciated. Thanks.
you can safely comment out the code in netdev.c on lines 3532 through
3549, as well as any other lines of code in the driver that modify or use
the variable netdev->tx_queue_len
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.30.y.git;a=blob;f=drivers/net/e1000e/netdev.c;h=42055a580f7ccd6cc2ac59ea5d7d864157b57107;hb=HEAD#l3532
Its possible we should just remove this code from the in-kernel
driver, as I don't think many other drivers mess with the tx_queue_len
either. We did introduce the code to fix some users complaints about the
amount of work that can get queued up in the hardware with tx_queue_len =
1000 when at 10/100 speeds.
Hope this helps!
^ permalink raw reply
* Re: [PATCH] Export smbios strings associated with onboard devices to sysfs
From: Greg KH @ 2010-03-02 18:28 UTC (permalink / raw)
To: Narendra K
Cc: matt_domsch, netdev, linux-hotplug, linux-pci, jordan_hargrave,
sandeep_k_shandilya, charles_rose, shyam_iyer
In-Reply-To: <20100302173302.GA20936@mock.linuxdev.us.dell.com>
On Tue, Mar 02, 2010 at 11:33:04AM -0600, Narendra K wrote:
> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> index 807224e..85d5d79 100644
> --- a/drivers/pci/pci-sysfs.c
> +++ b/drivers/pci/pci-sysfs.c
> @@ -142,6 +142,54 @@ static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
> (u8)(pci_dev->class));
> }
>
> +#ifdef CONFIG_DMI
> +#include <linux/dmi.h>
#includes go at the top of the file.
Can you just create a pci-dmi.c and put this in that .c that way you
don't need any #ifdefs in a .c file?
> +static ssize_t
> +smbiosname_string_is_valid(struct device *dev, char *buf)
> +{
> + struct pci_dev *pdev = to_pci_dev(dev);
> + struct dmi_device *dmi;
> + struct dmi_devslot *dslot;
> + int bus;
> + int devfn;
> +
> + bus = pdev->bus->number;
> + devfn = pdev->devfn;
> +
> + dmi = NULL;
> + while ((dmi = dmi_find_device(DMI_DEV_TYPE_DEVSLOT, NULL, dmi)) != NULL) {
> + dslot = dmi->device_data;
> + if (dslot && dslot->bus == bus && dslot->devfn == devfn) {
> + if (buf)
> + return scnprintf(buf, PAGE_SIZE, "%s\n", dmi->name);
> + return strlen(dmi->name);
> + }
> + }
> +}
> +
> +static ssize_t
> +smbiosname_show(struct device *dev, struct device_attribute *attr, char *buf)
> +{
> + return smbiosname_string_is_valid(dev, buf);
> +
> +}
> +
> +struct smbios_attribute {
> + struct attribute attr;
> + ssize_t(*show) (struct device * edev, char *buf);
> + int (*test) (struct device * edev, char *buf);
> +};
Why are you creating your own attribute type?
> +
> +#define SMBIOSNAME_DEVICE_ATTR(_name, _mode, _show, _test) \
> +struct smbios_attribute smbios_attr_##_name = { \
> + .attr = {.name = __stringify(_name), .mode = _mode }, \
> + .show = _show, \
> + .test = _test, \
> +};
> +
> +static SMBIOSNAME_DEVICE_ATTR(smbiosname, 0444, smbiosname_show, smbiosname_string_is_valid);
Why are you creating a #define that is only used once?
What is wrong with a "normal" device attribute that you can not use it
here?
> +#endif
> +
> static ssize_t is_enabled_store(struct device *dev,
> struct device_attribute *attr, const char *buf,
> size_t count)
> @@ -1140,6 +1188,7 @@ static int __init pci_sysfs_init(void)
> {
> struct pci_dev *pdev = NULL;
> int retval;
> + struct smbios_attribute *attr = &smbios_attr_smbiosname;
>
> sysfs_initialized = 1;
> for_each_pci_dev(pdev) {
> @@ -1148,6 +1197,11 @@ static int __init pci_sysfs_init(void)
> pci_dev_put(pdev);
> return retval;
> }
> +#ifdef CONFIG_DMI
> + /* if the device does not have an associated smbios string in the smbios table, do not create this attribute */
> + if (attr->test && attr->test(&pdev->dev, NULL))
> + sysfs_create_file(&pdev->dev.kobj, &attr->attr);
> +#endif
Put this in a new function and call it in a different file.
And how are you handling pci devices that are added after the pci
subsystem is initialized (think pci hotplug).
And where are you removing this sysfs file?
Why not put this in the pci_create_sysfs_dev_files function?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH]: tipc: Fix oops on send prior to entering networked mode (v2)
From: Neil Horman @ 2010-03-02 18:33 UTC (permalink / raw)
To: netdev; +Cc: jon.maloy, allan.stephens, tipc-discussion, davem
In-Reply-To: <20100219194033.GA28743@hmsreliant.think-freely.org>
Ok, after some debate, heres version 2 of this patch. Its a complete rewrite.
I started with the patches we'd proposed previously, then realized theres a much
easier and elegant way to handle this, which I've implemented below.
Fix TIPC to disallow sending to remote addresses prior to entering NET_MODE
user programs can oops the kernel by sending datagrams via AF_TIPC prior to
entering networked mode. The following backtrace has been observed:
ID: 13459 TASK: ffff810014640040 CPU: 0 COMMAND: "tipc-client"
[exception RIP: tipc_node_select_next_hop+90]
RIP: ffffffff8869d3c3 RSP: ffff81002d9a5ab8 RFLAGS: 00010202
RAX: 0000000000000001 RBX: 0000000000000001 RCX: 0000000000000001
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000001001001
RBP: 0000000001001001 R8: 0074736575716552 R9: 0000000000000000
R10: ffff81003fbd0680 R11: 00000000000000c8 R12: 0000000000000008
R13: 0000000000000001 R14: 0000000000000001 R15: ffff810015c6ca00
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#4 [ffff81002d9a5ab0] tipc_node_select_next_hop at ffffffff8869d3b1
#5 [ffff81002d9a5ae0] tipc_link_send_sections_fast at ffffffff88698558
#6 [ffff81002d9a5be0] tipc_forward2port at ffffffff8869eb1d
#7 [ffff81002d9a5c10] tipc_send2port at ffffffff8869eb79
#8 [ffff81002d9a5c30] send_msg at ffffffff886a1d0b
#9 [ffff81002d9a5cb0] sock_sendmsg at ffffffff80055261
RIP: 0000003cbd8d49a3 RSP: 00007fffc84e0be8 RFLAGS: 00010206
RAX: 000000000000002c RBX: ffffffff8005d116 RCX: 0000000000000000
RDX: 0000000000000008 RSI: 00007fffc84e0c00 RDI: 0000000000000003
RBP: 0000000000000000 R8: 00007fffc84e0c10 R9: 0000000000000010
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fffc84e0d10 R14: 0000000000000000 R15: 00007fffc84e0c30
ORIG_RAX: 000000000000002c CS: 0033 SS: 002b
What happens is that, when the tipc module in inserted it enters a standalone
node mode in which communication to its own address is allowed <0.0.0> but not
to other addresses, since the appropriate data structures have not been
allocated yet (specifically the tipc_net pointer). There is nothing stopping a
client from trying to send such a message however, and if that happens, we
attempt to dereference tipc_net.zones while the pointer is still NULL, and
explode. The fix is pretty straightforward. Since these oopses all arise from
the dereference of global pointers prior to their assignment to allocated
values, and since these allocations are small (about 2k total), lets convert
these pointers to static arrays of the appropriate size. All the accesses to
these bits consider 0/NULL to be a non match when searching, so all the lookups
still work properly, and there is no longer a chance of a bad dererence
anywhere. As a bonus, this lets us eliminate the setup/teardown routines for
those pointers, and elimnates the need to preform any locking around them to
prevent access while their being allocated/freed.
I've updated the tipc_net structure to behave this way to fix the exact reported
problem, and also fixed up the tipc_bearers and media_list arrays to fix an
obvious simmilar problem that arises from issuing tipc-config commands to
manipulate bearers/links prior to entering networked mode
I've tested this for a few hours by running the sanity tests and stress test
with the tipcutils suite, and nothing has fallen over. There have been a few
lockdep warnings, but those were there before, and can be addressed later, as
they didn't actually result in any deadlock.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Allan Stephens <allan.stephens@windriver.com>
CC: David S. Miller <davem@davemloft.net>
CC: tipc-discussion@lists.sourceforge.net
bearer.c | 28 ++--------------------------
bearer.h | 2 +-
net.c | 25 ++++---------------------
3 files changed, 7 insertions(+), 48 deletions(-)
diff --git a/net/tipc/bearer.c b/net/tipc/bearer.c
index 327011f..d1b9226 100644
--- a/net/tipc/bearer.c
+++ b/net/tipc/bearer.c
@@ -45,10 +45,10 @@
#define MAX_ADDR_STR 32
-static struct media *media_list = NULL;
+static struct media media_list[MAX_MEDIA];
static u32 media_count = 0;
-struct bearer *tipc_bearers = NULL;
+struct bearer tipc_bearers[MAX_BEARERS];
/**
* media_name_valid - validate media name
@@ -660,26 +660,6 @@ int tipc_disable_bearer(const char *name)
-int tipc_bearer_init(void)
-{
- int res;
-
- write_lock_bh(&tipc_net_lock);
- tipc_bearers = kcalloc(MAX_BEARERS, sizeof(struct bearer), GFP_ATOMIC);
- media_list = kcalloc(MAX_MEDIA, sizeof(struct media), GFP_ATOMIC);
- if (tipc_bearers && media_list) {
- res = 0;
- } else {
- kfree(tipc_bearers);
- kfree(media_list);
- tipc_bearers = NULL;
- media_list = NULL;
- res = -ENOMEM;
- }
- write_unlock_bh(&tipc_net_lock);
- return res;
-}
-
void tipc_bearer_stop(void)
{
u32 i;
@@ -695,10 +675,6 @@ void tipc_bearer_stop(void)
if (tipc_bearers[i].active)
bearer_disable(tipc_bearers[i].publ.name);
}
- kfree(tipc_bearers);
- kfree(media_list);
- tipc_bearers = NULL;
- media_list = NULL;
media_count = 0;
}
diff --git a/net/tipc/bearer.h b/net/tipc/bearer.h
index ca57348..000228e 100644
--- a/net/tipc/bearer.h
+++ b/net/tipc/bearer.h
@@ -114,7 +114,7 @@ struct bearer_name {
struct link;
-extern struct bearer *tipc_bearers;
+extern struct bearer tipc_bearers[];
void tipc_media_addr_printf(struct print_buf *pb, struct tipc_media_addr *a);
struct sk_buff *tipc_media_get_names(void);
diff --git a/net/tipc/net.c b/net/tipc/net.c
index 7906608..f25b1cd 100644
--- a/net/tipc/net.c
+++ b/net/tipc/net.c
@@ -116,7 +116,8 @@
*/
DEFINE_RWLOCK(tipc_net_lock);
-struct network tipc_net = { NULL };
+struct _zone *tipc_zones[256] = { NULL, };
+struct network tipc_net = { tipc_zones };
struct tipc_node *tipc_net_select_remote_node(u32 addr, u32 ref)
{
@@ -158,28 +159,12 @@ void tipc_net_send_external_routes(u32 dest)
}
}
-static int net_init(void)
-{
- memset(&tipc_net, 0, sizeof(tipc_net));
- tipc_net.zones = kcalloc(tipc_max_zones + 1, sizeof(struct _zone *), GFP_ATOMIC);
- if (!tipc_net.zones) {
- return -ENOMEM;
- }
- return 0;
-}
-
static void net_stop(void)
{
u32 z_num;
- if (!tipc_net.zones)
- return;
-
- for (z_num = 1; z_num <= tipc_max_zones; z_num++) {
+ for (z_num = 1; z_num <= tipc_max_zones; z_num++)
tipc_zone_delete(tipc_net.zones[z_num]);
- }
- kfree(tipc_net.zones);
- tipc_net.zones = NULL;
}
static void net_route_named_msg(struct sk_buff *buf)
@@ -282,9 +267,7 @@ int tipc_net_start(u32 addr)
tipc_named_reinit();
tipc_port_reinit();
- if ((res = tipc_bearer_init()) ||
- (res = net_init()) ||
- (res = tipc_cltr_init()) ||
+ if ((res = tipc_cltr_init()) ||
(res = tipc_bclink_init())) {
return res;
}
^ permalink raw reply related
* [patch] [iproute] ip exit, ip and tc line number
From: Michele Petrazzo - Unipex @ 2010-03-02 18:28 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 290 bytes --]
Hi,
I create a small patch that solve an annoying problem that I found on
"ip -batch" usage, so the command exits without end the parsing of the
batch file also if I specify the -force switch.
Also add the shown of the right line number where batch file fail for
both ip and tc
Michele
[-- Attachment #2: iproute.diff --]
[-- Type: text/x-diff, Size: 1476 bytes --]
commit 805fac22865d50b561643e58f5c2c001439a6a7d
Author: Michele Petrazzo <michele.petrazzo@unipex.it>
Date: Tue Mar 2 19:12:50 2010 +0100
Resolving "ip" exit on batch usage and add to ip and tc commands
the right line number on the output message then use with batch
switch
Signed-off-by: Michele Petrazzo <michele.petrazzo@unipex.it>
diff --git a/ip/ip.c b/ip/ip.c
index ace8cc6..b8c4914 100644
--- a/ip/ip.c
+++ b/ip/ip.c
@@ -125,6 +125,9 @@ static int batch(const char *name)
if (!force)
break;
}
+ else {
+ lineno++;
+ }
}
if (line)
free(line);
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index e9256d9..8ec6cfd 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -1014,7 +1014,7 @@ static int ipaddr_modify(int cmd, int flags, int argc, char **argv)
}
if (l && matches(d, l) != 0) {
fprintf(stderr, "\"dev\" (%s) must match \"label\" (%s).\n", d, l);
- exit(1);
+ return -1;
}
if (peer_len == 0 && local_len) {
@@ -1079,7 +1079,7 @@ static int ipaddr_modify(int cmd, int flags, int argc, char **argv)
}
if (rtnl_talk(&rth, &req.n, 0, 0, NULL, NULL, NULL) < 0)
- exit(2);
+ return -2;
return 0;
}
diff --git a/tc/tc.c b/tc/tc.c
index 8e362d2..ce78621 100644
--- a/tc/tc.c
+++ b/tc/tc.c
@@ -250,6 +250,11 @@ static int batch(const char *name)
if (!force)
break;
}
+ else {
+ cmdlineno++;
+ }
+
+
}
if (line)
free(line);
^ permalink raw reply related
* RE: [PATCH 0/8]: Bug fixes and new FW patch series
From: Vladislav Zolotarov @ 2010-03-02 19:14 UTC (permalink / raw)
To: Vladislav Zolotarov, davem@davemloft.net; +Cc: netdev@vger.kernel.org
In-Reply-To: <1266408196.25691.841.camel@lb-tlvb-vladz>
Dave, it seems that u have forgotten to apply the 7-th patch from that series (the one that removes the old bnx2x firmware ver. 5.2.7).
The old .ihex files are still present in the master branch.
Could u, pls., check that u have applied the mentioned patch.
Thanks,
vlad
> -----Original Message-----
> From: netdev-owner@vger.kernel.org
> [mailto:netdev-owner@vger.kernel.org] On Behalf Of Vladislav Zolotarov
> Sent: Wednesday, February 17, 2010 2:03 PM
> To: davem@davemloft.net
> Cc: netdev@vger.kernel.org
> Subject: [PATCH 0/8]: Bug fixes and new FW patch series
>
> Dave, hi.
> Pls., apply the following series of patches.
> It includes a few bugs fixes and a few FW.
>
> The patches may also be found at
> http://linux.broadcom.com/eilong/1.52.1-6
>
> thanks,
> vlad
>
>
> --
> 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
>
>
^ permalink raw reply
* Re: [PATCH 0/8]: Bug fixes and new FW patch series
From: David Miller @ 2010-03-02 19:17 UTC (permalink / raw)
To: vladz; +Cc: netdev
In-Reply-To: <8628FE4E7912BF47A96AE7DD7BAC0AADCB46A2B4A6@SJEXCHCCR02.corp.ad.broadcom.com>
From: "Vladislav Zolotarov" <vladz@broadcom.com>
Date: Tue, 2 Mar 2010 11:14:09 -0800
> Dave, it seems that u have forgotten to apply the 7-th patch from that series (the one that removes the old bnx2x firmware ver. 5.2.7).
>
> The old .ihex files are still present in the master branch.
>
> Could u, pls., check that u have applied the mentioned patch.
If it's not applied, I don't have it any more and you need
to resend it to me.
^ permalink raw reply
* RE: [PATCH 0/8]: Bug fixes and new FW patch series
From: Vladislav Zolotarov @ 2010-03-02 19:40 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <20100302.111719.211474245.davem@davemloft.net>
The patches are still availiable at:
http://linux.broadcom.com/eilong/1.52.1-6
It seems like the patch 7 hasn't been applied (remove old .ihex files)
Could u apply it, plz.
vlad
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Tuesday, March 02, 2010 9:17 PM
> To: Vladislav Zolotarov
> Cc: netdev@vger.kernel.org
> Subject: Re: [PATCH 0/8]: Bug fixes and new FW patch series
>
> From: "Vladislav Zolotarov" <vladz@broadcom.com>
> Date: Tue, 2 Mar 2010 11:14:09 -0800
>
> > Dave, it seems that u have forgotten to apply the 7-th
> patch from that series (the one that removes the old bnx2x
> firmware ver. 5.2.7).
> >
> > The old .ihex files are still present in the master branch.
> >
> > Could u, pls., check that u have applied the mentioned patch.
>
> If it's not applied, I don't have it any more and you need
> to resend it to me.
>
>
^ permalink raw reply
* RE: [PATCH 0/8]: Bug fixes and new FW patch series
From: Vladislav Zolotarov @ 2010-03-02 19:42 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <20100217.134451.10225453.davem@davemloft.net>
I'll surely do. Sorry for the inconvenience.
vlad
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Wednesday, February 17, 2010 11:45 PM
> To: Vladislav Zolotarov
> Cc: netdev@vger.kernel.org
> Subject: Re: [PATCH 0/8]: Bug fixes and new FW patch series
>
> From: "Vladislav Zolotarov" <vladz@broadcom.com>
> Date: Wed, 17 Feb 2010 14:03:16 +0200
>
> > Dave, hi.
> > Pls., apply the following series of patches.
> > It includes a few bugs fixes and a few FW.
> >
> > The patches may also be found at
> > http://linux.broadcom.com/eilong/1.52.1-6
>
> All applied, but please coordinate better with changes coming in via
> your colleages.
>
> Patch #6 would not apply cleanly because the firmware/Makefile is
> different due to the bnx2 driver firmware updates made yesterday.
>
> I fixed it up by hand, but in the future apply patches that apply
> cleanly to the current tree.
>
> Thanks.
>
>
^ permalink raw reply
* Re: [PATCH 0/8]: Bug fixes and new FW patch series
From: David Miller @ 2010-03-02 19:46 UTC (permalink / raw)
To: vladz; +Cc: netdev
In-Reply-To: <8628FE4E7912BF47A96AE7DD7BAC0AADCB46A2B4AF@SJEXCHCCR02.corp.ad.broadcom.com>
From: "Vladislav Zolotarov" <vladz@broadcom.com>
Date: Tue, 2 Mar 2010 11:40:20 -0800
> The patches are still availiable at:
> http://linux.broadcom.com/eilong/1.52.1-6
>
> It seems like the patch 7 hasn't been applied (remove old .ihex files)
>
> Could u apply it, plz.
This is so frustrating.
What part of "you need to resend it to me" do you not understand?
I'm not going to your web sites to grab your patches, I use patchwork
and my email inbox as my work queue.
^ permalink raw reply
* Re: e1000e: reset of tx_queue_len
From: Franco Fichtner @ 2010-03-02 19:52 UTC (permalink / raw)
To: Brandeburg, Jesse; +Cc: Netdev, Allan, Bruce W
In-Reply-To: <alpine.WNT.2.00.1003021020160.2888@jbrandeb-desk1.amr.corp.intel.com>
Brandeburg, Jesse wrote:
> On Tue, 2 Mar 2010, Franco Fichtner wrote:
>
>> while working on a new server, I noticed that tx_queue_len is reset
>> to the default of 1000 while ADDRCONF(NETDEV_CHANGE).
>> This happens with 2.6.30.8, but I could not see any obvious
>> differences to the current state of e1000e, while trying to find the
>> problem in the code.
>>
>
> The driver tries to set the queuelen back to 1000 if the link changes
> speed, because the driver tries to shorten the txqueuelen to 100 to reduce
> latency when the link changes to 100/10 Mb/s
>
Thanks, that explains it. Since we don't connect ports at startup, the
plugging causes
a speed "change".
>> The interface has been configured including a customized qlen
>> via /etc/network/interfaces. The ports are not connected at startup
>> so obviously the Kernel reports
>>
>> ADDRCONF(NETDEV_UP): eth2: link is not ready
>>
>
> do your scripts try to configure the queuelen when link is not up? Why
> are the ports not connected at startup?
>
I have a modified up command that sets appropriate values of mtu and
qlen via ip. The device is
brought up at startup automatically with the correct values. At least
that's what ifconfig shows
even though the port is not yet connected.
There has been a lot of testing back and forth with single hosts and
much larger quantities of traffic.
This got really messy when testing single host first (connected via 100
Mb/s, so qlen to 100) and then
switching to 1000 Mb/s. qlen would still be 100, causing lots of packet
drops. This took a few
days to track down, unfortunately.
> Hope this helps
Greatly appreciated, thanks again. :)
Franco
^ permalink raw reply
* RE: [PATCH 0/8]: Bug fixes and new FW patch series
From: Vladislav Zolotarov @ 2010-03-02 20:05 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <20100302.114623.119214667.davem@davemloft.net>
I thought u were taking "FW add/remove" patches from the ftp/http sites and not from your mailbox.
The patch is on its way to your mailbox... ;)
Thanks,
vlad
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Tuesday, March 02, 2010 9:46 PM
> To: Vladislav Zolotarov
> Cc: netdev@vger.kernel.org
> Subject: Re: [PATCH 0/8]: Bug fixes and new FW patch series
>
> From: "Vladislav Zolotarov" <vladz@broadcom.com>
> Date: Tue, 2 Mar 2010 11:40:20 -0800
>
> > The patches are still availiable at:
> > http://linux.broadcom.com/eilong/1.52.1-6
> >
> > It seems like the patch 7 hasn't been applied (remove old
> .ihex files)
> >
> > Could u apply it, plz.
>
> This is so frustrating.
>
> What part of "you need to resend it to me" do you not understand?
>
> I'm not going to your web sites to grab your patches, I use patchwork
> and my email inbox as my work queue.
>
>
^ permalink raw reply
* [RFC v2 00/10] snet: Security for NETwork syscalls
From: Samir Bellabes @ 2010-03-02 20:23 UTC (permalink / raw)
To: linux-security-module
Cc: linux-kernel, netdev, netfilter-devel, jamal, Patrick McHardy,
Evgeniy Polyakov, Neil Horman, Grzegorz Nosek, Samir Bellabes
Hello lsm and netdev people,
This set of patches is the version 2 of snet, which I would like to submit as a
RFC.
snet is a linux security module. It provides a mecanism defering syscall
security hooks and decision (verdict) to userspace.
snet has some subsystems :
- snet_core : init and exit the system
- snet_hooks : LSM hooks
- snet_netlink : kernel-user communication (genetlink)
- snet_event : manages the list of protected syscalls
- snet_verdict : provides a waitqueue for syscalls and manage verdicts
- snet_ticket : provides a granted-access ticket mecanism
I believe that snet will help to get over the classical configuration
complexity of others security modules, by providing interactivity to users.
I also think that monolithic strategy is broken with snet, as we can provide
security for others syscall's categories:
- sfs : security for filesystem,
- stask: security for task,
- smem : security for memory
..
In this way, and by putting abstraction on how this subsystems can talk to each
others, we may use the security combinaison we want: choose to run sfs,
stask, but not snet nor smem. Better, developpers may investigated how to build
another security subsystem for tasks, and use others existing (smem, snet..)
which they don't want to modify
I think that interactivity is very usefull for users, as they may be notify when
something is wrong and take decision, and from userspace, the decision may be
defered to another box. In this way, snet also have a advantage for mobile
devices as the policy decision will be push to a distant server, mobile device
will then wait for verdicts and as policy strategies are centralized.
Finally, and a important point: snet integration respects the LSM framework idea
of using LSM hooks.
New feature from the previous version:
* Building a ticket mecanism for each task_struct using pointer void *security
Use the pointer (void*) security related to task_struct to provides
granted-acces tickets: if two identical requests are coming, ask the user
for the first one, store the result in a ticket and for the second request,
just look in the tickets owned by the task-struct
* send data buffer of sendmsg to userspace
this may provide a way to look inside the data (as a anti-virus do)
roadmap:
* find a way to send data buffer of sendmsg to userspace (using netfilter)
* adding other security systems
we can think about adding fork(), exec(), open(), close()..
I'm Ccing netfilter-devel, as snet may be seen as a way to do filtering.
Samir Bellabes (10):
lsm: add security_socket_closed()
Revert "lsm: Remove the socket_post_accept() hook"
snet: introduce security/snet, Makefile and Kconfig changes
snet: introduce snet_core
snet: introduce snet_event
snet: introduce snet_hooks
snet: introduce snet_netlink
snet: introduce snet_verdict
snet: introduce snet_ticket
snet: introduce snet_utils
include/linux/security.h | 23 ++
include/linux/snet.h | 120 ++++++
net/socket.c | 3 +
security/Kconfig | 6 +
security/Makefile | 2 +
security/capability.c | 10 +
security/security.c | 10 +
security/snet/Kconfig | 11 +
security/snet/Makefile | 14 +
security/snet/snet_core.c | 76 ++++
security/snet/snet_event.c | 189 ++++++++++
security/snet/snet_event.h | 21 +
security/snet/snet_hooks.c | 710 +++++++++++++++++++++++++++++++++++
security/snet/snet_hooks.h | 10 +
security/snet/snet_netlink.c | 431 +++++++++++++++++++++
security/snet/snet_netlink.h | 17 +
security/snet/snet_netlink_helper.c | 230 +++++++++++
security/snet/snet_netlink_helper.h | 7 +
security/snet/snet_ticket.c | 171 +++++++++
security/snet/snet_ticket.h | 37 ++
security/snet/snet_ticket_helper.c | 127 +++++++
security/snet/snet_ticket_helper.h | 8 +
security/snet/snet_utils.c | 38 ++
security/snet/snet_utils.h | 10 +
security/snet/snet_verdict.c | 184 +++++++++
security/snet/snet_verdict.h | 23 ++
26 files changed, 2488 insertions(+), 0 deletions(-)
create mode 100644 include/linux/snet.h
create mode 100644 security/snet/Kconfig
create mode 100644 security/snet/Makefile
create mode 100644 security/snet/snet_core.c
create mode 100644 security/snet/snet_event.c
create mode 100644 security/snet/snet_event.h
create mode 100644 security/snet/snet_hooks.c
create mode 100644 security/snet/snet_hooks.h
create mode 100644 security/snet/snet_netlink.c
create mode 100644 security/snet/snet_netlink.h
create mode 100644 security/snet/snet_netlink_helper.c
create mode 100644 security/snet/snet_netlink_helper.h
create mode 100644 security/snet/snet_ticket.c
create mode 100644 security/snet/snet_ticket.h
create mode 100644 security/snet/snet_ticket_helper.c
create mode 100644 security/snet/snet_ticket_helper.h
create mode 100644 security/snet/snet_utils.c
create mode 100644 security/snet/snet_utils.h
create mode 100644 security/snet/snet_verdict.c
create mode 100644 security/snet/snet_verdict.h
^ permalink raw reply
* [RFC v2 01/10] lsm: add security_socket_closed()
From: Samir Bellabes @ 2010-03-02 20:23 UTC (permalink / raw)
To: linux-security-module
Cc: linux-kernel, netdev, netfilter-devel, jamal, Patrick McHardy,
Evgeniy Polyakov, Neil Horman, Grzegorz Nosek, Samir Bellabes
In-Reply-To: <1267561394-13626-1-git-send-email-sam@synack.fr>
Allow a security module to update security informations when a socket is closed.
Signed-off-by: Samir Bellabes <sam@synack.fr>
---
include/linux/security.h | 10 ++++++++++
net/socket.c | 1 +
security/capability.c | 5 +++++
security/security.c | 5 +++++
4 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/include/linux/security.h b/include/linux/security.h
index 2c627d3..74e564b 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -981,6 +981,9 @@ static inline void security_free_mnt_opts(struct security_mnt_opts *opts)
* @sock contains the socket structure.
* @how contains the flag indicating how future sends and receives are handled.
* Return 0 if permission is granted.
+ * @socket_close:
+ * Allow a module to update security informations when a socket is closed
+ * @sock is closed.
* @socket_sock_rcv_skb:
* Check permissions on incoming network packets. This hook is distinct
* from Netfilter's IP input hooks since it is the first time that the
@@ -1680,6 +1683,7 @@ struct security_operations {
int (*socket_getsockopt) (struct socket *sock, int level, int optname);
int (*socket_setsockopt) (struct socket *sock, int level, int optname);
int (*socket_shutdown) (struct socket *sock, int how);
+ void (*socket_close) (struct socket *sock);
int (*socket_sock_rcv_skb) (struct sock *sk, struct sk_buff *skb);
int (*socket_getpeersec_stream) (struct socket *sock, char __user *optval, int __user *optlen, unsigned len);
int (*socket_getpeersec_dgram) (struct socket *sock, struct sk_buff *skb, u32 *secid);
@@ -2700,6 +2704,7 @@ int security_socket_getpeername(struct socket *sock);
int security_socket_getsockopt(struct socket *sock, int level, int optname);
int security_socket_setsockopt(struct socket *sock, int level, int optname);
int security_socket_shutdown(struct socket *sock, int how);
+void security_socket_close(struct socket *sock);
int security_sock_rcv_skb(struct sock *sk, struct sk_buff *skb);
int security_socket_getpeersec_stream(struct socket *sock, char __user *optval,
int __user *optlen, unsigned len);
@@ -2812,6 +2817,11 @@ static inline int security_socket_shutdown(struct socket *sock, int how)
{
return 0;
}
+
+static inline void security_socket_close(struct socket *sock)
+{
+}
+
static inline int security_sock_rcv_skb(struct sock *sk,
struct sk_buff *skb)
{
diff --git a/net/socket.c b/net/socket.c
index 769c386..b4eb361 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -1055,6 +1055,7 @@ static int sock_close(struct inode *inode, struct file *filp)
printk(KERN_DEBUG "sock_close: NULL inode\n");
return 0;
}
+ security_socket_close(SOCKET_I(inode));
sock_release(SOCKET_I(inode));
return 0;
}
diff --git a/security/capability.c b/security/capability.c
index 5c700e1..a9810dc 100644
--- a/security/capability.c
+++ b/security/capability.c
@@ -677,6 +677,10 @@ static int cap_socket_shutdown(struct socket *sock, int how)
return 0;
}
+static void cap_socket_close(struct socket *sock)
+{
+}
+
static int cap_socket_sock_rcv_skb(struct sock *sk, struct sk_buff *skb)
{
return 0;
@@ -1084,6 +1088,7 @@ void security_fixup_ops(struct security_operations *ops)
set_to_cap_if_null(ops, socket_setsockopt);
set_to_cap_if_null(ops, socket_getsockopt);
set_to_cap_if_null(ops, socket_shutdown);
+ set_to_cap_if_null(ops, socket_close);
set_to_cap_if_null(ops, socket_sock_rcv_skb);
set_to_cap_if_null(ops, socket_getpeersec_stream);
set_to_cap_if_null(ops, socket_getpeersec_dgram);
diff --git a/security/security.c b/security/security.c
index 122b748..288c3a8 100644
--- a/security/security.c
+++ b/security/security.c
@@ -1118,6 +1118,11 @@ int security_socket_shutdown(struct socket *sock, int how)
return security_ops->socket_shutdown(sock, how);
}
+void security_socket_close(struct socket *sock)
+{
+ return security_ops->socket_close(sock);
+}
+
int security_sock_rcv_skb(struct sock *sk, struct sk_buff *skb)
{
return security_ops->socket_sock_rcv_skb(sk, skb);
--
1.6.3.3
^ permalink raw reply related
* [RFC v2 02/10] Revert "lsm: Remove the socket_post_accept() hook"
From: Samir Bellabes @ 2010-03-02 20:23 UTC (permalink / raw)
To: linux-security-module
Cc: linux-kernel, netdev, netfilter-devel, jamal, Patrick McHardy,
Evgeniy Polyakov, Neil Horman, Grzegorz Nosek, Samir Bellabes
In-Reply-To: <1267561394-13626-1-git-send-email-sam@synack.fr>
This reverts commit 8651d5c0b1f874c5b8307ae2b858bc40f9f02482.
snet needs to reintroduce this hook, as it was designed to be: a hook for
updating security informations on objects.
Signed-off-by: Samir Bellabes <sam@synack.fr>
Acked-by: Serge Hallyn <serue@us.ibm.com>
---
include/linux/security.h | 13 +++++++++++++
net/socket.c | 2 ++
security/capability.c | 5 +++++
security/security.c | 5 +++++
4 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/include/linux/security.h b/include/linux/security.h
index 74e564b..d8ad624 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -938,6 +938,11 @@ static inline void security_free_mnt_opts(struct security_mnt_opts *opts)
* @sock contains the listening socket structure.
* @newsock contains the newly created server socket for connection.
* Return 0 if permission is granted.
+ * @socket_post_accept:
+ * This hook allows a security module to copy security
+ * information into the newly created socket's inode.
+ * @sock contains the listening socket structure.
+ * @newsock contains the newly created server socket for connection.
* @socket_sendmsg:
* Check permission before transmitting a message to another socket.
* @sock contains the socket structure.
@@ -1674,6 +1679,8 @@ struct security_operations {
struct sockaddr *address, int addrlen);
int (*socket_listen) (struct socket *sock, int backlog);
int (*socket_accept) (struct socket *sock, struct socket *newsock);
+ void (*socket_post_accept) (struct socket *sock,
+ struct socket *newsock);
int (*socket_sendmsg) (struct socket *sock,
struct msghdr *msg, int size);
int (*socket_recvmsg) (struct socket *sock,
@@ -2696,6 +2703,7 @@ int security_socket_bind(struct socket *sock, struct sockaddr *address, int addr
int security_socket_connect(struct socket *sock, struct sockaddr *address, int addrlen);
int security_socket_listen(struct socket *sock, int backlog);
int security_socket_accept(struct socket *sock, struct socket *newsock);
+void security_socket_post_accept(struct socket *sock, struct socket *newsock);
int security_socket_sendmsg(struct socket *sock, struct msghdr *msg, int size);
int security_socket_recvmsg(struct socket *sock, struct msghdr *msg,
int size, int flags);
@@ -2778,6 +2786,11 @@ static inline int security_socket_accept(struct socket *sock,
return 0;
}
+static inline void security_socket_post_accept(struct socket *sock,
+ struct socket *newsock)
+{
+}
+
static inline int security_socket_sendmsg(struct socket *sock,
struct msghdr *msg, int size)
{
diff --git a/net/socket.c b/net/socket.c
index b4eb361..2e66a5a 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -1538,6 +1538,8 @@ SYSCALL_DEFINE4(accept4, int, fd, struct sockaddr __user *, upeer_sockaddr,
fd_install(newfd, newfile);
err = newfd;
+ security_socket_post_accept(sock, newsock);
+
out_put:
fput_light(sock->file, fput_needed);
out:
diff --git a/security/capability.c b/security/capability.c
index a9810dc..61eae40 100644
--- a/security/capability.c
+++ b/security/capability.c
@@ -641,6 +641,10 @@ static int cap_socket_accept(struct socket *sock, struct socket *newsock)
return 0;
}
+static void cap_socket_post_accept(struct socket *sock, struct socket *newsock)
+{
+}
+
static int cap_socket_sendmsg(struct socket *sock, struct msghdr *msg, int size)
{
return 0;
@@ -1081,6 +1085,7 @@ void security_fixup_ops(struct security_operations *ops)
set_to_cap_if_null(ops, socket_connect);
set_to_cap_if_null(ops, socket_listen);
set_to_cap_if_null(ops, socket_accept);
+ set_to_cap_if_null(ops, socket_post_accept);
set_to_cap_if_null(ops, socket_sendmsg);
set_to_cap_if_null(ops, socket_recvmsg);
set_to_cap_if_null(ops, socket_getsockname);
diff --git a/security/security.c b/security/security.c
index 288c3a8..673979f 100644
--- a/security/security.c
+++ b/security/security.c
@@ -1082,6 +1082,11 @@ int security_socket_accept(struct socket *sock, struct socket *newsock)
return security_ops->socket_accept(sock, newsock);
}
+void security_socket_post_accept(struct socket *sock, struct socket *newsock)
+{
+ security_ops->socket_post_accept(sock, newsock);
+}
+
int security_socket_sendmsg(struct socket *sock, struct msghdr *msg, int size)
{
return security_ops->socket_sendmsg(sock, msg, size);
--
1.6.3.3
^ permalink raw reply related
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