* Re: [PATCH, 2.6.17-rc4-git10] ieee80211softmac_io.c: fix warning "defined but not used"
From: John W. Linville @ 2006-05-26 19:24 UTC (permalink / raw)
To: Toralf Förster; +Cc: netdev, linuxppc-dev
In-Reply-To: <200605231549.43430.toralf.foerster@gmx.de>
On Tue, May 23, 2006 at 03:49:40PM +0200, Toralf Förster wrote:
> Got this compiler warning today and Johannes Berg <johannes@sipsolutions.net> wrote:
>
> Yeah, known 'bug', we have that code there but never use it. Feel free
> to submit a patch (to John Linville, CC netdev and softmac-dev) to
> remove it.
>
> Signed-off-by: Toralf Foerster <toralf.foerster@gmx.de>
This patch is whitespace-damaged. Please teach your mailer not to
convert tabs to spaces and resubmit.
Thanks!
John
> --- linux-2.6.17-rc4-git10-pcie-rme9652/net/ieee80211/softmac/ieee80211softmac_io.c.old 2006-05-12 09:44:47.000000000 +0200
> +++ linux-2.6.17-rc4-git10-pcie-rme9652/net/ieee80211/softmac/ieee80211softmac_io.c 2006-05-23 15:16:38.000000000 +0200
> @@ -456,31 +456,3 @@
> return IEEE80211_2ADDR_LEN;
> }
>
> -
> -/* Sends a control packet */
> -static int
> -ieee80211softmac_send_ctl_frame(struct ieee80211softmac_device *mac,
> - struct ieee80211softmac_network *net, u32 type, u32 arg)
> -{
> - void *pkt = NULL;
> - u32 pkt_size = 0;
<snip>
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* [PATCH] GRE: fixup gre_keymap_lookup() return type
From: Alexey Dobriyan @ 2006-05-26 19:07 UTC (permalink / raw)
To: netfilter-devel, netdev
GRE keys are 16-bit wide.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
net/ipv4/netfilter/ip_conntrack_proto_gre.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/net/ipv4/netfilter/ip_conntrack_proto_gre.c
+++ b/net/ipv4/netfilter/ip_conntrack_proto_gre.c
@@ -77,10 +77,10 @@ static inline int gre_key_cmpfn(const st
}
/* look up the source key for a given tuple */
-static u_int32_t gre_keymap_lookup(struct ip_conntrack_tuple *t)
+static __be16 gre_keymap_lookup(struct ip_conntrack_tuple *t)
{
struct ip_ct_gre_keymap *km;
- u_int32_t key = 0;
+ __be16 key = 0;
read_lock_bh(&ip_ct_gre_lock);
km = LIST_FIND(&gre_keymap_list, gre_key_cmpfn,
@@ -190,7 +190,7 @@ static int gre_pkt_to_tuple(const struct
struct ip_conntrack_tuple *tuple)
{
struct gre_hdr_pptp _pgrehdr, *pgrehdr;
- u_int32_t srckey;
+ __be16 srckey;
struct gre_hdr _grehdr, *grehdr;
/* first only delinearize old RFC1701 GRE header */
^ permalink raw reply
* Re: [RFC 0/4] NetLabel
From: James Morris @ 2006-05-26 18:56 UTC (permalink / raw)
To: Paul Moore
Cc: netdev, linux-security-module, selinux, James Morris,
Stephen Smalley
In-Reply-To: <44772E19.5030907@hp.com>
On Fri, 26 May 2006, Paul Moore wrote:
> The NetLabel netlink protocol does have a "version" message which can be
> used to get the version. My main reason for doing this is not to signal
> changes to existing messages, i.e. break backward compatability, but to
> signal to user space applications that the kernel supports a newer protocol.
>
> The printk() above is just informative, if that is your main concern I
> can yank it.
Yes, please do. Linux kernel subsystems don't have versions, use the main
kernel version if you need to.
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: Netfilter and SMP
From: Andi Kleen @ 2006-05-26 17:52 UTC (permalink / raw)
To: Majid Khan; +Cc: netdev
In-Reply-To: <a656c20605260823o1c894411t88a76c23d7855406@mail.gmail.com>
> Can somebody provide me with some information on how to configure my
> SMP system so that both processors share the network traffic load.
You would need multiple active incoming network interfaces.
Linux right now doesn't support load balancing from a single interrupt.
Even if it did that would likely require hardware support for MSI-X.
> My second question was that if there is any known method to gracefully
> handle failures in a netfilter module. Currently any failure in
> netfilter would cause the kernel panic.
Write a user space module using nf queue?
-Andi
^ permalink raw reply
* [PATCH] network dev.c comment cleanups
From: Stephen Hemminger @ 2006-05-26 17:42 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
Noticed that dev_alloc_name() comment was incorrect, and more spellung errors.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
--- br.orig/net/core/dev.c
+++ br/net/core/dev.c
@@ -127,7 +127,7 @@
* sure which should go first, but I bet it won't make much
* difference if we are running VLANs. The good news is that
* this protocol won't be in the list unless compiled in, so
- * the average user (w/out VLANs) will not be adversly affected.
+ * the average user (w/out VLANs) will not be adversely affected.
* --BLG
*
* 0800 IP
@@ -149,7 +149,7 @@ static struct list_head ptype_base[16];
static struct list_head ptype_all; /* Taps */
/*
- * The @dev_base list is protected by @dev_base_lock and the rtln
+ * The @dev_base list is protected by @dev_base_lock and the rtnl
* semaphore.
*
* Pure readers hold dev_base_lock for reading.
@@ -641,10 +641,12 @@ int dev_valid_name(const char *name)
* @name: name format string
*
* Passed a format string - eg "lt%d" it will try and find a suitable
- * id. Not efficient for many devices, not called a lot. The caller
- * must hold the dev_base or rtnl lock while allocating the name and
- * adding the device in order to avoid duplicates. Returns the number
- * of the unit assigned or a negative errno code.
+ * id. It scans list of devices to build up a free map, then chooses
+ * the first empty slot. The caller must hold the dev_base or rtnl lock
+ * while allocating the name and adding the device in order to avoid
+ * duplicates.
+ * Limited to bits_per_byte * page size devices (ie 32K on most platforms).
+ * Returns the number of the unit assigned or a negative errno code.
*/
int dev_alloc_name(struct net_device *dev, const char *name)
@@ -744,7 +746,7 @@ int dev_change_name(struct net_device *d
}
/**
- * netdev_features_change - device changes fatures
+ * netdev_features_change - device changes features
* @dev: device to cause notification
*
* Called to indicate a device has changed features.
@@ -2196,7 +2198,7 @@ int netdev_set_master(struct net_device
* @dev: device
* @inc: modifier
*
- * Add or remove promsicuity from a device. While the count in the device
+ * Add or remove promiscuity from a device. While the count in the device
* remains above zero the interface remains promiscuous. Once it hits zero
* the device reverts back to normal filtering operation. A negative inc
* value is used to drop promiscuity on the device.
@@ -3122,7 +3124,7 @@ EXPORT_SYMBOL(alloc_netdev);
void free_netdev(struct net_device *dev)
{
#ifdef CONFIG_SYSFS
- /* Compatiablity with error handling in drivers */
+ /* Compatibility with error handling in drivers */
if (dev->reg_state == NETREG_UNINITIALIZED) {
kfree((char *)dev - dev->padded);
return;
^ permalink raw reply
* [PATCH 9/9] ixgb: update version, dates
From: Kok, Auke @ 2006-05-26 16:52 UTC (permalink / raw)
To: Garzik, Jeff; +Cc: netdev, Brandeburg, Jesse, Kok, Auke, Kok, Auke
In-Reply-To: <20060526165124.30514.78477.stgit@gitlost.site>
increase the year dates to 2006 and bump the version to 1.0.109-k2
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: John Ronciak <john.ronciak@intel.com>
---
drivers/net/ixgb/Makefile | 2 +-
drivers/net/ixgb/ixgb.h | 2 +-
drivers/net/ixgb/ixgb_ee.c | 2 +-
drivers/net/ixgb/ixgb_ee.h | 2 +-
drivers/net/ixgb/ixgb_ethtool.c | 2 +-
drivers/net/ixgb/ixgb_hw.c | 2 +-
drivers/net/ixgb/ixgb_hw.h | 2 +-
drivers/net/ixgb/ixgb_ids.h | 2 +-
drivers/net/ixgb/ixgb_main.c | 6 +++---
drivers/net/ixgb/ixgb_osdep.h | 2 +-
drivers/net/ixgb/ixgb_param.c | 2 +-
11 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ixgb/Makefile b/drivers/net/ixgb/Makefile
index 7c7aff1..a8a2d3d 100644
--- a/drivers/net/ixgb/Makefile
+++ b/drivers/net/ixgb/Makefile
@@ -1,7 +1,7 @@
################################################################################
#
#
-# Copyright(c) 1999 - 2002 Intel Corporation. All rights reserved.
+# Copyright(c) 1999 - 2006 Intel Corporation. All rights reserved.
#
# This program is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by the Free
diff --git a/drivers/net/ixgb/ixgb.h b/drivers/net/ixgb/ixgb.h
index bdbaf5a..a83ef28 100644
--- a/drivers/net/ixgb/ixgb.h
+++ b/drivers/net/ixgb/ixgb.h
@@ -1,7 +1,7 @@
/*******************************************************************************
- Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved.
+ Copyright(c) 1999 - 2006 Intel Corporation. All rights reserved.
This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the Free
diff --git a/drivers/net/ixgb/ixgb_ee.c b/drivers/net/ixgb/ixgb_ee.c
index 661a46b..8357c55 100644
--- a/drivers/net/ixgb/ixgb_ee.c
+++ b/drivers/net/ixgb/ixgb_ee.c
@@ -1,7 +1,7 @@
/*******************************************************************************
- Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved.
+ Copyright(c) 1999 - 2006 Intel Corporation. All rights reserved.
This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the Free
diff --git a/drivers/net/ixgb/ixgb_ee.h b/drivers/net/ixgb/ixgb_ee.h
index 5190aa8..bf6fa22 100644
--- a/drivers/net/ixgb/ixgb_ee.h
+++ b/drivers/net/ixgb/ixgb_ee.h
@@ -1,7 +1,7 @@
/*******************************************************************************
- Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved.
+ Copyright(c) 1999 - 2006 Intel Corporation. All rights reserved.
This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the Free
diff --git a/drivers/net/ixgb/ixgb_ethtool.c b/drivers/net/ixgb/ixgb_ethtool.c
index 949f69d..cf19b89 100644
--- a/drivers/net/ixgb/ixgb_ethtool.c
+++ b/drivers/net/ixgb/ixgb_ethtool.c
@@ -1,7 +1,7 @@
/*******************************************************************************
- Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved.
+ Copyright(c) 1999 - 2006 Intel Corporation. All rights reserved.
This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the Free
diff --git a/drivers/net/ixgb/ixgb_hw.c b/drivers/net/ixgb/ixgb_hw.c
index 620cad4..f7fa10e 100644
--- a/drivers/net/ixgb/ixgb_hw.c
+++ b/drivers/net/ixgb/ixgb_hw.c
@@ -1,7 +1,7 @@
/*******************************************************************************
- Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved.
+ Copyright(c) 1999 - 2006 Intel Corporation. All rights reserved.
This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the Free
diff --git a/drivers/net/ixgb/ixgb_hw.h b/drivers/net/ixgb/ixgb_hw.h
index 19513c6..cb45689 100644
--- a/drivers/net/ixgb/ixgb_hw.h
+++ b/drivers/net/ixgb/ixgb_hw.h
@@ -1,7 +1,7 @@
/*******************************************************************************
- Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved.
+ Copyright(c) 1999 - 2006 Intel Corporation. All rights reserved.
This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the Free
diff --git a/drivers/net/ixgb/ixgb_ids.h b/drivers/net/ixgb/ixgb_ids.h
index e119c05..40a085f 100644
--- a/drivers/net/ixgb/ixgb_ids.h
+++ b/drivers/net/ixgb/ixgb_ids.h
@@ -1,7 +1,7 @@
/*******************************************************************************
- Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved.
+ Copyright(c) 1999 - 2006 Intel Corporation. All rights reserved.
This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the Free
diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
index aecdc00..57006fb 100644
--- a/drivers/net/ixgb/ixgb_main.c
+++ b/drivers/net/ixgb/ixgb_main.c
@@ -1,7 +1,7 @@
/*******************************************************************************
- Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved.
+ Copyright(c) 1999 - 2006 Intel Corporation. All rights reserved.
This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the Free
@@ -36,9 +36,9 @@ static char ixgb_driver_string[] = "Inte
#else
#define DRIVERNAPI "-NAPI"
#endif
-#define DRV_VERSION "1.0.104-k4"DRIVERNAPI
+#define DRV_VERSION "1.0.109-k2"DRIVERNAPI
char ixgb_driver_version[] = DRV_VERSION;
-static char ixgb_copyright[] = "Copyright (c) 1999-2005 Intel Corporation.";
+static char ixgb_copyright[] = "Copyright (c) 1999-2006 Intel Corporation.";
/* ixgb_pci_tbl - PCI Device ID Table
*
diff --git a/drivers/net/ixgb/ixgb_osdep.h b/drivers/net/ixgb/ixgb_osdep.h
index dba2048..ee982fe 100644
--- a/drivers/net/ixgb/ixgb_osdep.h
+++ b/drivers/net/ixgb/ixgb_osdep.h
@@ -1,7 +1,7 @@
/*******************************************************************************
- Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved.
+ Copyright(c) 1999 - 2006 Intel Corporation. All rights reserved.
This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the Free
diff --git a/drivers/net/ixgb/ixgb_param.c b/drivers/net/ixgb/ixgb_param.c
index 388462c..39fbed2 100644
--- a/drivers/net/ixgb/ixgb_param.c
+++ b/drivers/net/ixgb/ixgb_param.c
@@ -1,7 +1,7 @@
/*******************************************************************************
- Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved.
+ Copyright(c) 1999 - 2006 Intel Corporation. All rights reserved.
This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the Free
--
Auke Kok <auke-jan.h.kok@intel.com>
^ permalink raw reply related
* [PATCH 8/9] ixgb: remove changelog
From: Kok, Auke @ 2006-05-26 16:52 UTC (permalink / raw)
To: Garzik, Jeff; +Cc: netdev, Brandeburg, Jesse, Kok, Auke, Kok, Auke
In-Reply-To: <20060526165124.30514.78477.stgit@gitlost.site>
same as e1000 - remove the changelog from the driver code itself.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: John Ronciak <john.ronciak@intel.com>
---
drivers/net/ixgb/ixgb_main.c | 16 ----------------
1 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
index 037b5c3..aecdc00 100644
--- a/drivers/net/ixgb/ixgb_main.c
+++ b/drivers/net/ixgb/ixgb_main.c
@@ -28,22 +28,6 @@
#include "ixgb.h"
-/* Change Log
- * 1.0.96 04/19/05
- * - Make needlessly global code static -- bunk@stusta.de
- * - ethtool cleanup -- shemminger@osdl.org
- * - Support for MODULE_VERSION -- linville@tuxdriver.com
- * - add skb_header_cloned check to the tso path -- herbert@apana.org.au
- * 1.0.88 01/05/05
- * - include fix to the condition that determines when to quit NAPI - Robert Olsson
- * - use netif_poll_{disable/enable} to synchronize between NAPI and i/f up/down
- * 1.0.84 10/26/04
- * - reset buffer_info->dma in Tx resource cleanup logic
- * 1.0.83 10/12/04
- * - sparse cleanup - shemminger@osdl.org
- * - fix tx resource cleanup logic
- */
-
char ixgb_driver_name[] = "ixgb";
static char ixgb_driver_string[] = "Intel(R) PRO/10GbE Network Driver";
--
Auke Kok <auke-jan.h.kok@intel.com>
^ permalink raw reply related
* [PATCH 7/9] ixgb: replace netdev->priv with netdev_priv()
From: Kok, Auke @ 2006-05-26 16:52 UTC (permalink / raw)
To: Garzik, Jeff; +Cc: netdev, Brandeburg, Jesse, Kok, Auke, Kok, Auke
In-Reply-To: <20060526165124.30514.78477.stgit@gitlost.site>
fix netdev->priv ==> netdev_priv(netdev)
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: John Ronciak <john.ronciak@intel.com>
---
drivers/net/ixgb/ixgb_ethtool.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ixgb/ixgb_ethtool.c b/drivers/net/ixgb/ixgb_ethtool.c
index 6d8192f..949f69d 100644
--- a/drivers/net/ixgb/ixgb_ethtool.c
+++ b/drivers/net/ixgb/ixgb_ethtool.c
@@ -254,14 +254,14 @@ ixgb_set_tso(struct net_device *netdev,
static uint32_t
ixgb_get_msglevel(struct net_device *netdev)
{
- struct ixgb_adapter *adapter = netdev->priv;
+ struct ixgb_adapter *adapter = netdev_priv(netdev);
return adapter->msg_enable;
}
static void
ixgb_set_msglevel(struct net_device *netdev, uint32_t data)
{
- struct ixgb_adapter *adapter = netdev->priv;
+ struct ixgb_adapter *adapter = netdev_priv(netdev);
adapter->msg_enable = data;
}
#define IXGB_GET_STAT(_A_, _R_) _A_->stats._R_
--
Auke Kok <auke-jan.h.kok@intel.com>
^ permalink raw reply related
* [PATCH 6/9] ixgb: remove inlines, allow compiler to choose
From: Kok, Auke @ 2006-05-26 16:52 UTC (permalink / raw)
To: Garzik, Jeff; +Cc: netdev, Brandeburg, Jesse, Kok, Auke, Kok, Auke
In-Reply-To: <20060526165124.30514.78477.stgit@gitlost.site>
deinline a few large functions as to allow the compiler to pick.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: John Ronciak <john.ronciak@intel.com>
---
drivers/net/ixgb/ixgb_main.c | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
index a714c4d..037b5c3 100644
--- a/drivers/net/ixgb/ixgb_main.c
+++ b/drivers/net/ixgb/ixgb_main.c
@@ -203,7 +203,7 @@ module_exit(ixgb_exit_module);
* @adapter: board private structure
**/
-static inline void
+static void
ixgb_irq_disable(struct ixgb_adapter *adapter)
{
atomic_inc(&adapter->irq_sem);
@@ -217,7 +217,7 @@ ixgb_irq_disable(struct ixgb_adapter *ad
* @adapter: board private structure
**/
-static inline void
+static void
ixgb_irq_enable(struct ixgb_adapter *adapter)
{
if(atomic_dec_and_test(&adapter->irq_sem)) {
@@ -918,7 +918,7 @@ ixgb_free_tx_resources(struct ixgb_adapt
adapter->tx_ring.desc = NULL;
}
-static inline void
+static void
ixgb_unmap_and_free_tx_resource(struct ixgb_adapter *adapter,
struct ixgb_buffer *buffer_info)
{
@@ -1179,7 +1179,7 @@ ixgb_watchdog(unsigned long data)
#define IXGB_TX_FLAGS_VLAN 0x00000002
#define IXGB_TX_FLAGS_TSO 0x00000004
-static inline int
+static int
ixgb_tso(struct ixgb_adapter *adapter, struct sk_buff *skb)
{
#ifdef NETIF_F_TSO
@@ -1241,7 +1241,7 @@ ixgb_tso(struct ixgb_adapter *adapter, s
return 0;
}
-static inline boolean_t
+static boolean_t
ixgb_tx_csum(struct ixgb_adapter *adapter, struct sk_buff *skb)
{
struct ixgb_context_desc *context_desc;
@@ -1279,7 +1279,7 @@ ixgb_tx_csum(struct ixgb_adapter *adapte
#define IXGB_MAX_TXD_PWR 14
#define IXGB_MAX_DATA_PER_TXD (1<<IXGB_MAX_TXD_PWR)
-static inline int
+static int
ixgb_tx_map(struct ixgb_adapter *adapter, struct sk_buff *skb,
unsigned int first)
{
@@ -1346,7 +1346,7 @@ ixgb_tx_map(struct ixgb_adapter *adapter
return count;
}
-static inline void
+static void
ixgb_tx_queue(struct ixgb_adapter *adapter, int count, int vlan_id,int tx_flags)
{
struct ixgb_desc_ring *tx_ring = &adapter->tx_ring;
@@ -1849,7 +1849,7 @@ ixgb_clean_tx_irq(struct ixgb_adapter *a
* @sk_buff: socket buffer with received data
**/
-static inline void
+static void
ixgb_rx_checksum(struct ixgb_adapter *adapter,
struct ixgb_rx_desc *rx_desc,
struct sk_buff *skb)
--
Auke Kok <auke-jan.h.kok@intel.com>
^ permalink raw reply related
* [PATCH 5/9] ixgb: remove lock access in the fast path
From: Kok, Auke @ 2006-05-26 16:52 UTC (permalink / raw)
To: Garzik, Jeff; +Cc: netdev, Brandeburg, Jesse, Kok, Auke, Kok, Auke
In-Reply-To: <20060526165124.30514.78477.stgit@gitlost.site>
This mimics a change made in the e1000 driver that imitates a slick
tg3 way of avoiding grabbing the lock around restarting the tx queue.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: John Ronciak <john.ronciak@intel.com>
---
drivers/net/ixgb/ixgb_main.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
index b825850..a714c4d 100644
--- a/drivers/net/ixgb/ixgb_main.c
+++ b/drivers/net/ixgb/ixgb_main.c
@@ -1800,13 +1800,13 @@ ixgb_clean_tx_irq(struct ixgb_adapter *a
tx_ring->next_to_clean = i;
- spin_lock(&adapter->tx_lock);
- if(cleaned && netif_queue_stopped(netdev) && netif_carrier_ok(netdev) &&
- (IXGB_DESC_UNUSED(tx_ring) > IXGB_TX_QUEUE_WAKE)) {
-
- netif_wake_queue(netdev);
+ if (unlikely(netif_queue_stopped(netdev))) {
+ spin_lock(&adapter->tx_lock);
+ if (netif_queue_stopped(netdev) && netif_carrier_ok(netdev) &&
+ (IXGB_DESC_UNUSED(tx_ring) > IXGB_TX_QUEUE_WAKE))
+ netif_wake_queue(netdev);
+ spin_unlock(&adapter->tx_lock);
}
- spin_unlock(&adapter->tx_lock);
if(adapter->detect_tx_hung) {
/* detect a transmit hang in hardware, this serializes the
--
Auke Kok <auke-jan.h.kok@intel.com>
^ permalink raw reply related
* [PATCH 4/9] ixgb: allocate only buffersize needed
From: Kok, Auke @ 2006-05-26 16:52 UTC (permalink / raw)
To: Garzik, Jeff; +Cc: netdev, Brandeburg, Jesse, Kok, Auke, Kok, Auke
In-Reply-To: <20060526165124.30514.78477.stgit@gitlost.site>
In order to help correct window size growth, use the MFS register
to limit the packet sizes received and allocate only the buffer
size necessary
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: John Ronciak <john.ronciak@intel.com>
index 0905a82..84a8064 100644
--- a/drivers/net/ixgb/ixgb_main.c
+++ b/drivers/net/ixgb/ixgb_main.c
@@ -574,9 +574,8 @@ ixgb_sw_init(struct ixgb_adapter *adapte
hw->subsystem_vendor_id = pdev->subsystem_vendor;
hw->subsystem_id = pdev->subsystem_device;
- adapter->rx_buffer_len = IXGB_RXBUFFER_2048;
-
hw->max_frame_size = netdev->mtu + ENET_HEADER_SIZE + ENET_FCS_LENGTH;
+ adapter->rx_buffer_len = hw->max_frame_size;
if((hw->device_id == IXGB_DEVICE_ID_82597EX)
|| (hw->device_id == IXGB_DEVICE_ID_82597EX_CX4)
@@ -820,21 +819,14 @@ ixgb_setup_rctl(struct ixgb_adapter *ada
rctl |= IXGB_RCTL_SECRC;
- switch (adapter->rx_buffer_len) {
- case IXGB_RXBUFFER_2048:
- default:
+ if (adapter->rx_buffer_len <= IXGB_RXBUFFER_2048)
rctl |= IXGB_RCTL_BSIZE_2048;
- break;
- case IXGB_RXBUFFER_4096:
+ else if (adapter->rx_buffer_len <= IXGB_RXBUFFER_4096)
rctl |= IXGB_RCTL_BSIZE_4096;
- break;
- case IXGB_RXBUFFER_8192:
+ else if (adapter->rx_buffer_len <= IXGB_RXBUFFER_8192)
rctl |= IXGB_RCTL_BSIZE_8192;
- break;
- case IXGB_RXBUFFER_16384:
+ else if (adapter->rx_buffer_len <= IXGB_RXBUFFER_16384)
rctl |= IXGB_RCTL_BSIZE_16384;
- break;
- }
IXGB_WRITE_REG(&adapter->hw, RCTL, rctl);
}
@@ -1551,25 +1543,12 @@ ixgb_change_mtu(struct net_device *netde
DPRINTK(PROBE, ERR, "Invalid MTU setting %d\n", new_mtu);
return -EINVAL;
}
-
- if((max_frame <= IXGB_MAX_ENET_FRAME_SIZE_WITHOUT_FCS + ENET_FCS_LENGTH)
- || (max_frame <= IXGB_RXBUFFER_2048)) {
- adapter->rx_buffer_len = IXGB_RXBUFFER_2048;
-
- } else if(max_frame <= IXGB_RXBUFFER_4096) {
- adapter->rx_buffer_len = IXGB_RXBUFFER_4096;
- } else if(max_frame <= IXGB_RXBUFFER_8192) {
- adapter->rx_buffer_len = IXGB_RXBUFFER_8192;
+ adapter->rx_buffer_len = max_frame;
- } else {
- adapter->rx_buffer_len = IXGB_RXBUFFER_16384;
- }
-
netdev->mtu = new_mtu;
-
- if(old_max_frame != max_frame && netif_running(netdev)) {
+ if ((old_max_frame != max_frame) && netif_running(netdev)) {
ixgb_down(adapter, TRUE);
ixgb_up(adapter);
}
---
drivers/net/ixgb/ixgb_main.c | 35 +++++++----------------------------
1 files changed, 7 insertions(+), 28 deletions(-)
diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
index 5561ab6..b825850 100644
--- a/drivers/net/ixgb/ixgb_main.c
+++ b/drivers/net/ixgb/ixgb_main.c
@@ -576,9 +576,8 @@ ixgb_sw_init(struct ixgb_adapter *adapte
hw->subsystem_vendor_id = pdev->subsystem_vendor;
hw->subsystem_id = pdev->subsystem_device;
- adapter->rx_buffer_len = IXGB_RXBUFFER_2048;
-
hw->max_frame_size = netdev->mtu + ENET_HEADER_SIZE + ENET_FCS_LENGTH;
+ adapter->rx_buffer_len = hw->max_frame_size;
if((hw->device_id == IXGB_DEVICE_ID_82597EX)
|| (hw->device_id == IXGB_DEVICE_ID_82597EX_CX4)
@@ -822,21 +821,14 @@ ixgb_setup_rctl(struct ixgb_adapter *ada
rctl |= IXGB_RCTL_SECRC;
- switch (adapter->rx_buffer_len) {
- case IXGB_RXBUFFER_2048:
- default:
+ if (adapter->rx_buffer_len <= IXGB_RXBUFFER_2048)
rctl |= IXGB_RCTL_BSIZE_2048;
- break;
- case IXGB_RXBUFFER_4096:
+ else if (adapter->rx_buffer_len <= IXGB_RXBUFFER_4096)
rctl |= IXGB_RCTL_BSIZE_4096;
- break;
- case IXGB_RXBUFFER_8192:
+ else if (adapter->rx_buffer_len <= IXGB_RXBUFFER_8192)
rctl |= IXGB_RCTL_BSIZE_8192;
- break;
- case IXGB_RXBUFFER_16384:
+ else if (adapter->rx_buffer_len <= IXGB_RXBUFFER_16384)
rctl |= IXGB_RCTL_BSIZE_16384;
- break;
- }
IXGB_WRITE_REG(&adapter->hw, RCTL, rctl);
}
@@ -1546,24 +1538,11 @@ ixgb_change_mtu(struct net_device *netde
return -EINVAL;
}
- if((max_frame <= IXGB_MAX_ENET_FRAME_SIZE_WITHOUT_FCS + ENET_FCS_LENGTH)
- || (max_frame <= IXGB_RXBUFFER_2048)) {
- adapter->rx_buffer_len = IXGB_RXBUFFER_2048;
-
- } else if(max_frame <= IXGB_RXBUFFER_4096) {
- adapter->rx_buffer_len = IXGB_RXBUFFER_4096;
-
- } else if(max_frame <= IXGB_RXBUFFER_8192) {
- adapter->rx_buffer_len = IXGB_RXBUFFER_8192;
-
- } else {
- adapter->rx_buffer_len = IXGB_RXBUFFER_16384;
- }
+ adapter->rx_buffer_len = max_frame;
netdev->mtu = new_mtu;
- if(old_max_frame != max_frame && netif_running(netdev)) {
-
+ if ((old_max_frame != max_frame) && netif_running(netdev)) {
ixgb_down(adapter, TRUE);
ixgb_up(adapter);
}
--
Auke Kok <auke-jan.h.kok@intel.com>
^ permalink raw reply related
* [PATCH 3/9] ixgb: revert an unwanted fix regarding tso/descriptors
From: Kok, Auke @ 2006-05-26 16:52 UTC (permalink / raw)
To: Garzik, Jeff; +Cc: netdev, Brandeburg, Jesse, Kok, Auke, Kok, Auke
In-Reply-To: <20060526165124.30514.78477.stgit@gitlost.site>
There seemed to be another bug introduced as well as a performance hit
with the addtion of the sentinel descriptor workaround. Removal of
this workaround appears to prevent the hang. We'll take a risk
and remove it, as we had never seen the originally reported bug
under linux.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: John Ronciak <john.ronciak@intel.com>
---
drivers/net/ixgb/ixgb_main.c | 15 +--------------
1 files changed, 1 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
index 26c777f..5561ab6 100644
--- a/drivers/net/ixgb/ixgb_main.c
+++ b/drivers/net/ixgb/ixgb_main.c
@@ -1295,7 +1295,6 @@ ixgb_tx_map(struct ixgb_adapter *adapter
struct ixgb_buffer *buffer_info;
int len = skb->len;
unsigned int offset = 0, size, count = 0, i;
- unsigned int mss = skb_shinfo(skb)->tso_size;
unsigned int nr_frags = skb_shinfo(skb)->nr_frags;
unsigned int f;
@@ -1307,11 +1306,6 @@ ixgb_tx_map(struct ixgb_adapter *adapter
while(len) {
buffer_info = &tx_ring->buffer_info[i];
size = min(len, IXGB_MAX_JUMBO_FRAME_SIZE);
- /* Workaround for premature desc write-backs
- * in TSO mode. Append 4-byte sentinel desc */
- if(unlikely(mss && !nr_frags && size == len && size > 8))
- size -= 4;
-
buffer_info->length = size;
buffer_info->dma =
pci_map_single(adapter->pdev,
@@ -1337,12 +1331,6 @@ ixgb_tx_map(struct ixgb_adapter *adapter
while(len) {
buffer_info = &tx_ring->buffer_info[i];
size = min(len, IXGB_MAX_JUMBO_FRAME_SIZE);
- /* Workaround for premature desc write-backs
- * in TSO mode. Append 4-byte sentinel desc */
- if(unlikely(mss && (f == (nr_frags-1)) && (size == len)
- && (size > 8)))
- size -= 4;
-
buffer_info->length = size;
buffer_info->dma =
pci_map_page(adapter->pdev,
@@ -1421,8 +1409,7 @@ ixgb_tx_queue(struct ixgb_adapter *adapt
#define TXD_USE_COUNT(S) (((S) >> IXGB_MAX_TXD_PWR) + \
(((S) & (IXGB_MAX_DATA_PER_TXD - 1)) ? 1 : 0))
#define DESC_NEEDED TXD_USE_COUNT(IXGB_MAX_DATA_PER_TXD) + \
- MAX_SKB_FRAGS * TXD_USE_COUNT(PAGE_SIZE) + 1 \
- /* one more for TSO workaround */ + 1
+ MAX_SKB_FRAGS * TXD_USE_COUNT(PAGE_SIZE) + 1
static int
ixgb_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
--
Auke Kok <auke-jan.h.kok@intel.com>
^ permalink raw reply related
* [PATCH 2/9] ixgb: fix interface losing macaddr on ifdn/up
From: Kok, Auke @ 2006-05-26 16:51 UTC (permalink / raw)
To: Garzik, Jeff; +Cc: netdev, Brandeburg, Jesse, Kok, Auke, Kok, Auke
In-Reply-To: <20060526165124.30514.78477.stgit@gitlost.site>
user contributed fix for LAA across down/up, from tonychung00@users.sf.net.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: John Ronciak <john.ronciak@intel.com>
---
drivers/net/ixgb/ixgb_main.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
index 954894b..26c777f 100644
--- a/drivers/net/ixgb/ixgb_main.c
+++ b/drivers/net/ixgb/ixgb_main.c
@@ -238,6 +238,7 @@ ixgb_up(struct ixgb_adapter *adapter)
/* hardware has been reset, we need to reload some things */
+ ixgb_rar_set(hw, netdev->dev_addr, 0);
ixgb_set_multi(netdev);
ixgb_restore_vlan(adapter);
--
Auke Kok <auke-jan.h.kok@intel.com>
^ permalink raw reply related
* [PATCH 1/9] ixgb: fix smp polling race condition
From: Kok, Auke @ 2006-05-26 16:51 UTC (permalink / raw)
To: Garzik, Jeff; +Cc: netdev, Brandeburg, Jesse, Kok, Auke, Kok, Auke
In-Reply-To: <20060526165124.30514.78477.stgit@gitlost.site>
Moved interrupt masking to before requesting the interrupt from the OS.
Moved interrupt enable to after netif_poll_enable. This fixes a racy
BUG() where polling would be running on another CPU at the same time
that netif_poll_enable would run.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: John Ronciak <john.ronciak@intel.com>
---
drivers/net/ixgb/ixgb_main.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
index 0a0c876..954894b 100644
--- a/drivers/net/ixgb/ixgb_main.c
+++ b/drivers/net/ixgb/ixgb_main.c
@@ -247,6 +247,9 @@ ixgb_up(struct ixgb_adapter *adapter)
ixgb_configure_rx(adapter);
ixgb_alloc_rx_buffers(adapter);
+ /* disable interrupts and get the hardware into a known state */
+ IXGB_WRITE_REG(&adapter->hw, IMC, 0xffffffff);
+
#ifdef CONFIG_PCI_MSI
{
boolean_t pcix = (IXGB_READ_REG(&adapter->hw, STATUS) &
@@ -272,9 +275,6 @@ ixgb_up(struct ixgb_adapter *adapter)
return err;
}
- /* disable interrupts and get the hardware into a known state */
- IXGB_WRITE_REG(&adapter->hw, IMC, 0xffffffff);
-
if((hw->max_frame_size != max_frame) ||
(hw->max_frame_size !=
(IXGB_READ_REG(hw, MFS) >> IXGB_MFS_SHIFT))) {
@@ -295,11 +295,12 @@ ixgb_up(struct ixgb_adapter *adapter)
}
mod_timer(&adapter->watchdog_timer, jiffies);
- ixgb_irq_enable(adapter);
#ifdef CONFIG_IXGB_NAPI
netif_poll_enable(netdev);
#endif
+ ixgb_irq_enable(adapter);
+
return 0;
}
--
Auke Kok <auke-jan.h.kok@intel.com>
^ permalink raw reply related
* [PATCH 0/9] ixgb: driver update to 1.0.109-k2
From: Kok, Auke @ 2006-05-26 16:51 UTC (permalink / raw)
To: Garzik, Jeff; +Cc: netdev, Brandeburg, Jesse, Kok, Auke, Kok, Auke
Hi,
Here are the ixgb driver updates for 1.0.109-k2. This corresponds with
the release of 1.0.109 on e1000.sf.net, and fixes several issues.
e1000 update will come soon...
Summary:
[1] fix smp polling race condition
[2] fix interface losing macaddr on ifdn/up
[3] revert an unwanted fix regarding tso/descriptors
[4] allocate only buffersize needed
[5] remove lock access in the fast path
[6] remove inlines, allow compiler to choose
[7] replace netdev->priv with netdev_priv()
[8] remove changelog
[9] update version, dates
These changes are available through git.
git pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 ixgb-1.0.109-k2
these patches are against
netdev-2.6#upstream a24e2513c2d03c9a92739ec6fa7e7208f792881e
Cheers,
Auke
---
drivers/net/ixgb/Makefile | 2 -
drivers/net/ixgb/ixgb.h | 2 -
drivers/net/ixgb/ixgb_ee.c | 2 -
drivers/net/ixgb/ixgb_ee.h | 2 -
drivers/net/ixgb/ixgb_ethtool.c | 6 +-
drivers/net/ixgb/ixgb_hw.c | 2 -
drivers/net/ixgb/ixgb_hw.h | 2 -
drivers/net/ixgb/ixgb_ids.h | 2 -
drivers/net/ixgb/ixgb_main.c | 110 +++++++++++----------------------------
drivers/net/ixgb/ixgb_osdep.h | 2 -
drivers/net/ixgb/ixgb_param.c | 2 -
11 files changed, 43 insertions(+), 91 deletions(-)
--
Auke Kok <auke-jan.h.kok@intel.com>
^ permalink raw reply
* Re: [RFC 0/4] NetLabel
From: Paul Moore @ 2006-05-26 16:34 UTC (permalink / raw)
To: James Morris
Cc: netdev, linux-security-module, selinux, James Morris,
Stephen Smalley
In-Reply-To: <Pine.LNX.4.64.0605261156030.3103@d.namei>
James Morris wrote:
> On Fri, 26 May 2006, Paul Moore wrote:
>>>- Why does this module have a version number?
>>>
>>>+ printk(KERN_INFO "NetLabel: Initializing (v%s %s)\n",
>>>+ NETLBL_VER_STR, NETLBL_VER_DATE);
>>>
>>
>>The version number is there primarily to help signal possible
>>differences in the NetLabel netlink protocol.
>
> How will this ever help anything?
>
> If you change that protocol, userspace applications will break, which is
> not acceptable. You can add versioning at the protocol level or via
> adding a new netlink family in the future, but existing apps cannot break
> and you need to maintain compatibility.
>
The NetLabel netlink protocol does have a "version" message which can be
used to get the version. My main reason for doing this is not to signal
changes to existing messages, i.e. break backward compatability, but to
signal to user space applications that the kernel supports a newer protocol.
The printk() above is just informative, if that is your main concern I
can yank it.
--
paul moore
linux security @ hp
^ permalink raw reply
* Re: [RFC 0/4] NetLabel
From: Mikel L. Matthews @ 2006-05-26 16:20 UTC (permalink / raw)
To: Paul Moore
Cc: James Morris, netdev, linux-security-module, selinux,
James Morris, Stephen Smalley
In-Reply-To: <447729B7.4060702@hp.com>
Same issue, I would drop them.
Paul Moore wrote:
> Mikel L. Matthews wrote:
>> Paul Moore wrote:
>>> James Morris wrote:
>>
>
> Outgoing fragment *should* be labeled correctly assuming the Linux base
> network stack does the right thing (I haven't tested this yet). The
> issue we are discussing here is what to do about incoming packets where
> the fragments are not consistently labeled.
>
--
Thanks,
Mike
Mikel L. Matthews
Chief Technology Officer
Innovative Security Systems, Inc.
(dba Argus Systems Group)
1809 Woodfield Dr.
Savoy IL 61874
+1-217-355-6308
www.argus-systems.com
^ permalink raw reply
* Re: [RFC 0/4] NetLabel
From: Paul Moore @ 2006-05-26 16:15 UTC (permalink / raw)
To: Mikel L. Matthews
Cc: James Morris, netdev, linux-security-module, selinux,
James Morris, Stephen Smalley
In-Reply-To: <44772824.6090505@argus-systems.com>
Mikel L. Matthews wrote:
> Paul Moore wrote:
>>James Morris wrote:
>>>On Thu, 25 May 2006, Paul Moore wrote:
>>>
>>>>This patch introduces a new kernel feature designed to support labeled
>>>>networking protocols such as RIPSO and CIPSO. These protocols are required to
>>>>interoperate with existing "trusted" operating systems such as Trusted
>>>>Solaris.
>>>
>>>A few initial comments.
>>>
>>>- Did you decide that you definitely need to verify labels on fragments?
>>>
>>>I can see the code's been added to do that, but wonder about a comment
>>>made during earlier discussion that mislabeled fragments could only come
>>>from a misbehaving trusted system. What is the threat model here?
>>>
>>
>>This is one part of the patch that I really don't have a strong feeling
>>for either way. There was some concern on the LSM list that not
>>checking the fragment options might be an issue so I added some code to
>>check the fragment options. Personally I think we are probably okay
>>without it as the un-autenticated/un-verified nature of these labeling
>>protocols more or less requires either a trusted network/hosts.
>>
>>If the community decides that this check is not required then I can
>>simply drop all of the changes in ip_fragment.c.
>
> If you state you are labeling session packets (tcp or udp), that would
> lead one to believe all packets are labeled (including fragments). Based
> on our past evaluations I don't think non-labeled fragments would make
> it through an evaluation if CIPSO/RIPSO were part of the TOE/security
> Target.
>
Outgoing fragment *should* be labeled correctly assuming the Linux base
network stack does the right thing (I haven't tested this yet). The
issue we are discussing here is what to do about incoming packets where
the fragments are not consistently labeled.
--
paul moore
linux security @ hp
^ permalink raw reply
* Re: [RFC 0/4] NetLabel
From: Mikel L. Matthews @ 2006-05-26 16:09 UTC (permalink / raw)
To: Paul Moore
Cc: James Morris, netdev, linux-security-module, selinux,
James Morris, Stephen Smalley
In-Reply-To: <44771EFB.6030203@hp.com>
Paul Moore wrote:
> James Morris wrote:
>> On Thu, 25 May 2006, Paul Moore wrote:
>>> This patch introduces a new kernel feature designed to support labeled
>>> networking protocols such as RIPSO and CIPSO. These protocols are required to
>>> interoperate with existing "trusted" operating systems such as Trusted
>>> Solaris.
>> A few initial comments.
>>
>> - Did you decide that you definitely need to verify labels on fragments?
>>
>> I can see the code's been added to do that, but wonder about a comment
>> made during earlier discussion that mislabeled fragments could only come
>> from a misbehaving trusted system. What is the threat model here?
>>
>
> This is one part of the patch that I really don't have a strong feeling
> for either way. There was some concern on the LSM list that not
> checking the fragment options might be an issue so I added some code to
> check the fragment options. Personally I think we are probably okay
> without it as the un-autenticated/un-verified nature of these labeling
> protocols more or less requires either a trusted network/hosts.
>
> If the community decides that this check is not required then I can
> simply drop all of the changes in ip_fragment.c.
If you state you are labeling session packets (tcp or udp), that would
lead one to believe all packets are labeled (including fragments). Based
on our past evaluations I don't think non-labeled fragments would make
it through an evaluation if CIPSO/RIPSO were part of the TOE/security
Target.
>
>> - Can you explain how module loading and module refcounting for these
>> modules work? (e.g. what causes netlabel_cipso_v4 to be loaded, is it
>> always safe to unload if the refcount is zero?)
>
--
Thanks,
Mike
Mikel L. Matthews
Chief Technology Officer
Innovative Security Systems, Inc.
(dba Argus Systems Group)
1809 Woodfield Dr.
Savoy IL 61874
+1-217-355-6308
www.argus-systems.com
^ permalink raw reply
* Re: [PATCH 8/9] Resending NetXen 1G/10G NIC driver patch
From: Stephen Hemminger @ 2006-05-26 16:08 UTC (permalink / raw)
To: pradeep
Cc: Linsys Contractor Amit S. Kale, Kernel Netdev Mailing List,
Sanjeev Jorapur, UNM Project Staff
In-Reply-To: <1148653616.3453.115.camel@arya.linsyssoft.com>
You might also want to add support for setting
dev->perm_addr
and using ethtool_op_get_perm_addr() in ethtool_ops
^ permalink raw reply
* Re: [RFC 0/4] NetLabel
From: James Morris @ 2006-05-26 16:02 UTC (permalink / raw)
To: Paul Moore
Cc: netdev, linux-security-module, selinux, James Morris,
Stephen Smalley
In-Reply-To: <44771EFB.6030203@hp.com>
On Fri, 26 May 2006, Paul Moore wrote:
> There may be an issue with packets generated by the kernel directly and
> not as a result of an incoming packet but I can't think of a case where
> this would happen (although I suspect I am just not thinking hard
> enough). Do you have a scenario in mind?
There are several possibilities, I believe. The networking code would
need to be audited to find them all.
> Okay. I suspect this code will go away, but just for my own education
> were you thinking of something like this?
>
> static inline int my_func(void)
> #ifdef CONFIG_NETLABEL_CIPSOV4
> /* real stuff */
> #else
> /* compile away into a zero */
> return 0;
> #endif
> }
>
> ... or something else?
No.
You put the real function in a .c file and the dummy inline in a .h file.
There are many examples of this in the kernel.
> > - Why does this module have a version number?
> >
> > + printk(KERN_INFO "NetLabel: Initializing (v%s %s)\n",
> > + NETLBL_VER_STR, NETLBL_VER_DATE);
> >
>
> The version number is there primarily to help signal possible
> differences in the NetLabel netlink protocol.
How will this ever help anything?
If you change that protocol, userspace applications will break, which is
not acceptable. You can add versioning at the protocol level or via
adding a new netlink family in the future, but existing apps cannot break
and you need to maintain compatibility.
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [RFC 0/4] NetLabel
From: Paul Moore @ 2006-05-26 15:30 UTC (permalink / raw)
To: James Morris
Cc: netdev, linux-security-module, selinux, James Morris,
Stephen Smalley
In-Reply-To: <Pine.LNX.4.64.0605251938360.27473@d.namei>
James Morris wrote:
> On Thu, 25 May 2006, Paul Moore wrote:
>>This patch introduces a new kernel feature designed to support labeled
>>networking protocols such as RIPSO and CIPSO. These protocols are required to
>>interoperate with existing "trusted" operating systems such as Trusted
>>Solaris.
>
> A few initial comments.
>
> - Did you decide that you definitely need to verify labels on fragments?
>
> I can see the code's been added to do that, but wonder about a comment
> made during earlier discussion that mislabeled fragments could only come
> from a misbehaving trusted system. What is the threat model here?
>
This is one part of the patch that I really don't have a strong feeling
for either way. There was some concern on the LSM list that not
checking the fragment options might be an issue so I added some code to
check the fragment options. Personally I think we are probably okay
without it as the un-autenticated/un-verified nature of these labeling
protocols more or less requires either a trusted network/hosts.
If the community decides that this check is not required then I can
simply drop all of the changes in ip_fragment.c.
> - Can you explain how module loading and module refcounting for these
> modules work? (e.g. what causes netlabel_cipso_v4 to be loaded, is it
> always safe to unload if the refcount is zero?)
Heh, not really :)
This is part of the "not ready for submission" qualifier I mentioned at
the top of my post. Honestly I'm not sure it makes sense to have this
code as a loadable module anyway I just used some of the module bits as
it was the first example of code that I saw in the kernel which would
call init/exit functions.
If people think that this code should be made into a fully
loadable/unloadable module then there is definitely more work to be done
in this area as I really haven't looked into it too deeply. However, if
people are okay with it not being a module then I will find a proper way
of doing initialization without using the module bits.
Sorry for the confusion, I forgot to mention it earlier.
> - What about user APIs for setting and retrieving labels?
The NetLabel mechanism supports getting the labels off of a packet
directly or from the top most packet on the incoming socket queue. I
have left it up to the LSM to decide how to expose that functionality to
the user. In SELinux this is done by using the SO_PEERSEC option
similar to how you would do it if you were using the IPsec SA labeling.
It works by looking at the top most packet in the socket receive queue
for TCP and at the packet itself for UDP.
You can set/reset the label by calling the NetLabel function to set the
label of a socket; right now the label of outgoing packets is tightly
tied to the label of the socket from which they were sent. The NetLabel
code does support changing the label of a socket but I have not added
the code to SELinux to support that because I am not clear that is a
good thing to do from a SELinux point of view, currently the label is
set when the socket is created. However, should people decide this is a
good thing, one possibility would be to enable the SO_PEERSEC option for
setsockopt().
> - What about labeling of kernel-generated packets?
Kernel generated packets which are created in response to an incoming
packet, i.e. ICMP errors, get the label of the packet which caused the
response. This seems to be correct from the draft's point of view as
well as several people on the LSM list.
There may be an issue with packets generated by the kernel directly and
not as a result of an incoming packet but I can't think of a case where
this would happen (although I suspect I am just not thinking hard
enough). Do you have a scenario in mind?
> - Don't put #ifdef'd code into mainline code.
>
> e.g. in net/ipv4/ip_fragment.c
>
> +#ifdef CONFIG_NETLABEL_CIPSOV4
> + if (sopt->cipso) {
>
> This needs to be a function which is compiled away as a static inline when
> not selected. This stuff should have zero impact on the networking code
> if not enabled.
Okay. I suspect this code will go away, but just for my own education
were you thinking of something like this?
static inline int my_func(void)
#ifdef CONFIG_NETLABEL_CIPSOV4
/* real stuff */
#else
/* compile away into a zero */
return 0;
#endif
}
... or something else?
> - Try and add entries for security/selinux/nlmsgtab.c for the new Netlink
> protocol.
>
> - This does not follow normal kernel coding practices:
>
> {snip}
>
> - This kind of stuff should be removed before merging:
>
> {snip}
>
Okay.
> - Why does this module have a version number?
>
> + printk(KERN_INFO "NetLabel: Initializing (v%s %s)\n",
> + NETLBL_VER_STR, NETLBL_VER_DATE);
>
The version number is there primarily to help signal possible
differences in the NetLabel netlink protocol.
--
paul moore
linux security @ hp
^ permalink raw reply
* Netfilter and SMP
From: Majid Khan @ 2006-05-26 15:23 UTC (permalink / raw)
To: netdev
Hi,
I am developing a netfilter based application on an SMP (AMD 64;dual
core) system (kernel 2.6).
One thing that I noticed over a period of time was that most of the
network traffic was handled by only one of the processor. Only under
high network traffic (roughly 10,000 packet/sec or more) did the
second processor got invloved invloved in traffic handling. Even then
more than 90 percent of the traffic was being handled by one of the
processor.
Can somebody provide me with some information on how to configure my
SMP system so that both processors share the network traffic load.
My second question was that if there is any known method to gracefully
handle failures in a netfilter module. Currently any failure in
netfilter would cause the kernel panic.
Regards,
Majid
^ permalink raw reply
* Re: skge driver oops
From: Stephen Hemminger @ 2006-05-26 15:17 UTC (permalink / raw)
To: Beschorner Daniel
Cc: 'Krzysztof Oledzki', netdev, 'david@mantara.com'
In-Reply-To: <BB1F4EFD574E9F409035BDA71C9612500241A2@exchange.i-bn>
Please give this a try, it rearranges the transmit buffer management,
and may avoid issues with partial completions causing SKB reuse.
--- skge.orig/drivers/net/skge.c
+++ skge/drivers/net/skge.c
@@ -2372,7 +2372,8 @@ static int skge_xmit_frame(struct sk_buf
frag->size, PCI_DMA_TODEVICE);
e = e->next;
- e->skb = NULL;
+ e->skb = skb;
+
tf = e->desc;
tf->dma_lo = map;
tf->dma_hi = (u64) map >> 32;
@@ -2408,36 +2409,42 @@ static int skge_xmit_frame(struct sk_buf
return NETDEV_TX_OK;
}
-static void skge_tx_complete(struct skge_port *skge, struct skge_element *last)
+
+static void skge_tx_done(struct skge_port *skge, struct skge_element *e)
{
struct pci_dev *pdev = skge->hw->pdev;
- struct skge_element *e;
+ const struct skge_tx_desc *td = e->desc;
- for (e = skge->tx_ring.to_clean; e != last; e = e->next) {
- struct sk_buff *skb = e->skb;
- int i;
-
- e->skb = NULL;
+ /* skb header vs. fragment */
+ if (td->control & BMU_STF)
pci_unmap_single(pdev, pci_unmap_addr(e, mapaddr),
- skb_headlen(skb), PCI_DMA_TODEVICE);
+ pci_unmap_len(e, maplen),
+ PCI_DMA_TODEVICE);
+ else
+ pci_unmap_page(pdev, pci_unmap_addr(e, mapaddr),
+ pci_unmap_len(e, maplen),
+ PCI_DMA_TODEVICE);
- for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
- e = e->next;
- pci_unmap_page(pdev, pci_unmap_addr(e, mapaddr),
- skb_shinfo(skb)->frags[i].size,
- PCI_DMA_TODEVICE);
- }
+ if (td->control & BMU_EOF) {
+ if (unlikely(netif_msg_tx_done(skge)))
+ printk(KERN_DEBUG PFX "%s: tx done slot %td\n",
+ skge->netdev->name, e - skge->tx_ring.start);
- dev_kfree_skb(skb);
+ dev_kfree_skb_any(e->skb);
}
- skge->tx_ring.to_clean = e;
+ e->skb = NULL;
}
+/* Free all buffers in transmit ring */
static void skge_tx_clean(struct skge_port *skge)
{
+ struct skge_element *e;
spin_lock_bh(&skge->tx_lock);
- skge_tx_complete(skge, skge->tx_ring.to_use);
+ for (e = skge->tx_ring.to_clean; e != skge->tx_ring.to_use; e = e->next)
+ skge_tx_done(skge, e);
+
+ skge->tx_ring.to_clean = e;
netif_wake_queue(skge->netdev);
spin_unlock_bh(&skge->tx_lock);
}
@@ -2665,30 +2672,24 @@ resubmit:
return NULL;
}
-static void skge_tx_done(struct skge_port *skge)
+/* Free all buffers in Tx ring which are no longer owned by device */
+static void skge_tx_complete(struct skge_port *skge)
{
struct skge_ring *ring = &skge->tx_ring;
- struct skge_element *e, *last;
+ struct skge_element *e;
spin_lock(&skge->tx_lock);
- last = ring->to_clean;
+ skge_write8(skge->hw, Q_ADDR(txqaddr[skge->port], Q_CSR), CSR_IRQ_CL_F);
+
for (e = ring->to_clean; e != ring->to_use; e = e->next) {
struct skge_tx_desc *td = e->desc;
if (td->control & BMU_OWN)
break;
- if (td->control & BMU_EOF) {
- last = e->next;
- if (unlikely(netif_msg_tx_done(skge)))
- printk(KERN_DEBUG PFX "%s: tx done slot %td\n",
- skge->netdev->name, e - ring->start);
- }
+ skge_tx_done(skge, e);
}
-
- skge_tx_complete(skge, last);
-
- skge_write8(skge->hw, Q_ADDR(txqaddr[skge->port], Q_CSR), CSR_IRQ_CL_F);
+ skge->tx_ring.to_clean = e;
if (skge_avail(&skge->tx_ring) > TX_LOW_WATER)
netif_wake_queue(skge->netdev);
@@ -2705,7 +2706,7 @@ static int skge_poll(struct net_device *
int to_do = min(dev->quota, *budget);
int work_done = 0;
- skge_tx_done(skge);
+ skge_tx_complete(skge);
for (e = ring->to_clean; prefetch(e->next), work_done < to_do; e = e->next) {
struct skge_rx_desc *rd = e->desc;
^ permalink raw reply
* Re: [PATCH 1/9] Resending NetXen 1G/10G NIC driver patch
From: Stephen Hemminger @ 2006-05-26 15:04 UTC (permalink / raw)
To: pradeep
Cc: Linsys Contractor Amit S. Kale, Kernel Netdev Mailing List,
Sanjeev Jorapur, UNM Project Staff
In-Reply-To: <1148652872.3453.100.camel@arya.linsyssoft.com>
On Fri, 26 May 2006 14:14:32 +0000
Pradeep Dalvi <pradeep@linsyssoft.com> wrote:
> Following are the minor changes for [PATCH 1/9] in accordance with the
> given suggestions.
>
> Regards,
> pradeep
>
> diff -u linux-2.6.16.18/drivers/net/netxen/netxen_nic_ethtool.c
> linux-2.6.16.18/drivers/net/netxen/netxen_nic_ethtool.c
> --- linux-2.6.16.18/drivers/net/netxen/netxen_nic_ethtool.c
> 2006-05-25 02:43:22.000000000 -0700
> +++ linux-2.6.16.18/drivers/net/netxen/netxen_nic_ethtool.c
> 2006-05-26 04:05:34.000000000 -0700
> @@ -145,7 +145,7 @@
>
> ecmd->port = PORT_TP;
>
> - if (port->state) {
> + if (dev->flags & IFF_UP) {
if (netif_running(dev)) {
^ 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