* [PATCH 3/6] [IPV4] trie: put leaf nodes in a slab cache
From: Stephen Hemminger @ 2008-01-15 0:46 UTC (permalink / raw)
To: David Miller; +Cc: robert.olsson, netdev
In-Reply-To: <20080114164450.55f8c9b2@deepthought>
This improves locality for operations that touch all the leaves.
Later patch will grow the size of the leaf so it becomes more
important.
Signed-off-by: Stephen Hemminger <stephen.hemminger@vyatta.com>
--- a/net/ipv4/fib_trie.c 2008-01-14 12:26:51.000000000 -0800
+++ b/net/ipv4/fib_trie.c 2008-01-14 13:41:00.000000000 -0800
@@ -162,6 +162,7 @@ static struct tnode *halve(struct trie *
static void tnode_free(struct tnode *tn);
static struct kmem_cache *fn_alias_kmem __read_mostly;
+static struct kmem_cache *trie_leaf_kmem __read_mostly;
static inline struct tnode *node_parent(struct node *node)
{
@@ -316,7 +317,8 @@ static inline void alias_free_mem_rcu(st
static void __leaf_free_rcu(struct rcu_head *head)
{
- kfree(container_of(head, struct leaf, rcu));
+ struct leaf *leaf = container_of(head, struct leaf, rcu);
+ kmem_cache_free(trie_leaf_kmem, leaf);
}
static void __leaf_info_free_rcu(struct rcu_head *head)
@@ -366,7 +368,7 @@ static inline void tnode_free(struct tno
static struct leaf *leaf_new(void)
{
- struct leaf *l = kmalloc(sizeof(struct leaf), GFP_KERNEL);
+ struct leaf *l = kmem_cache_alloc(trie_leaf_kmem, GFP_KERNEL);
if (l) {
l->parent = T_LEAF;
INIT_HLIST_HEAD(&l->list);
@@ -1927,6 +1929,9 @@ void __init fib_hash_init(void)
{
fn_alias_kmem = kmem_cache_create("ip_fib_alias", sizeof(struct fib_alias),
0, SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
+
+ trie_leaf_kmem = kmem_cache_create("ip_fib_trie", sizeof(struct leaf),
+ 0, SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
}
^ permalink raw reply
* [PATCH 2/6] [IPV4] fib hash|trie initialization
From: Stephen Hemminger @ 2008-01-15 5:00 UTC (permalink / raw)
Cc: David Miller, robert.olsson, netdev
In-Reply-To: <20080114125755.6157a3bf@deepthought>
Initialization of the slab cache's should be done when IP is
initialized to make sure of available memory, and that code
can be marked __init.
Signed-off-by: Stephen Hemminger <stephen.hemminger@vyatta.com>
---
Applies after statistics (#1) patch for net-2.6.25
include/net/ip_fib.h | 5 +++--
net/ipv4/fib_frontend.c | 9 ++++++---
net/ipv4/fib_hash.c | 24 +++++++++++-------------
net/ipv4/fib_trie.c | 16 ++++++++--------
4 files changed, 28 insertions(+), 26 deletions(-)
--- a/include/net/ip_fib.h 2008-01-14 14:59:32.000000000 -0800
+++ b/include/net/ip_fib.h 2008-01-14 15:01:12.000000000 -0800
@@ -231,8 +231,9 @@ extern int fib_sync_down(__be32 local, s
extern int fib_sync_up(struct net_device *dev);
extern __be32 __fib_res_prefsrc(struct fib_result *res);
-/* Exported by fib_hash.c */
-extern struct fib_table *fib_hash_init(u32 id);
+/* Exported by fib_{hash|trie}.c */
+extern void fib_hash_init(void);
+extern struct fib_table *fib_hash_table(u32 id);
static inline void fib_combine_itag(u32 *itag, struct fib_result *res)
{
--- a/net/ipv4/fib_frontend.c 2008-01-14 14:59:32.000000000 -0800
+++ b/net/ipv4/fib_frontend.c 2008-01-14 15:01:12.000000000 -0800
@@ -53,11 +53,11 @@ static int __net_init fib4_rules_init(st
{
struct fib_table *local_table, *main_table;
- local_table = fib_hash_init(RT_TABLE_LOCAL);
+ local_table = fib_hash_table(RT_TABLE_LOCAL);
if (local_table == NULL)
return -ENOMEM;
- main_table = fib_hash_init(RT_TABLE_MAIN);
+ main_table = fib_hash_table(RT_TABLE_MAIN);
if (main_table == NULL)
goto fail;
@@ -83,7 +83,8 @@ struct fib_table *fib_new_table(struct n
tb = fib_get_table(net, id);
if (tb)
return tb;
- tb = fib_hash_init(id);
+
+ tb = fib_hash_table(id);
if (!tb)
return NULL;
h = id & (FIB_TABLE_HASHSZ - 1);
@@ -1042,6 +1043,8 @@ void __init ip_fib_init(void)
register_pernet_subsys(&fib_net_ops);
register_netdevice_notifier(&fib_netdev_notifier);
register_inetaddr_notifier(&fib_inetaddr_notifier);
+
+ fib_hash_init();
}
EXPORT_SYMBOL(inet_addr_type);
--- a/net/ipv4/fib_hash.c 2008-01-14 14:59:32.000000000 -0800
+++ b/net/ipv4/fib_hash.c 2008-01-14 15:01:12.000000000 -0800
@@ -746,21 +746,19 @@ static int fn_hash_dump(struct fib_table
return skb->len;
}
-struct fib_table *fib_hash_init(u32 id)
+void __init fib_hash_init(void)
{
- struct fib_table *tb;
+ fn_hash_kmem = kmem_cache_create("ip_fib_hash", sizeof(struct fib_node),
+ 0, SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
+
+ fn_alias_kmem = kmem_cache_create("ip_fib_alias", sizeof(struct fib_alias),
+ 0, SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
+
+}
- if (fn_hash_kmem == NULL)
- fn_hash_kmem = kmem_cache_create("ip_fib_hash",
- sizeof(struct fib_node),
- 0, SLAB_HWCACHE_ALIGN,
- NULL);
-
- if (fn_alias_kmem == NULL)
- fn_alias_kmem = kmem_cache_create("ip_fib_alias",
- sizeof(struct fib_alias),
- 0, SLAB_HWCACHE_ALIGN,
- NULL);
+struct fib_table *fib_hash_table(u32 id)
+{
+ struct fib_table *tb;
tb = kmalloc(sizeof(struct fib_table) + sizeof(struct fn_hash),
GFP_KERNEL);
--- a/net/ipv4/fib_trie.c 2008-01-14 15:01:12.000000000 -0800
+++ b/net/ipv4/fib_trie.c 2008-01-14 20:57:41.000000000 -0800
@@ -1923,19 +1923,19 @@ out:
return -1;
}
-/* Fix more generic FIB names for init later */
+void __init fib_hash_init(void)
+{
+ fn_alias_kmem = kmem_cache_create("ip_fib_alias", sizeof(struct fib_alias),
+ 0, SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
+}
-struct fib_table *fib_hash_init(u32 id)
+
+/* Fix more generic FIB names for init later */
+struct fib_table *fib_hash_table(u32 id)
{
struct fib_table *tb;
struct trie *t;
- if (fn_alias_kmem == NULL)
- fn_alias_kmem = kmem_cache_create("ip_fib_alias",
- sizeof(struct fib_alias),
- 0, SLAB_HWCACHE_ALIGN,
- NULL);
-
tb = kmalloc(sizeof(struct fib_table) + sizeof(struct trie),
GFP_KERNEL);
if (tb == NULL)
^ permalink raw reply
* Re: [PATCH 0/3] UCC TDM driver for MPC83xx platforms
From: Kumar Gala @ 2008-01-15 3:31 UTC (permalink / raw)
To: Andrew Morton
Cc: Kim Phillips, Poonam.Aggrwal, sfr, rubini, linux-ppcdev, netdev,
linux-kernel, Michael.Barkowski, ashish.kalra, Rich.Cutler
In-Reply-To: <20080114131530.9d33f50a.akpm@linux-foundation.org>
On Jan 14, 2008, at 3:15 PM, Andrew Morton wrote:
> On Mon, 14 Jan 2008 12:00:51 -0600
> Kim Phillips <kim.phillips@freescale.com> wrote:
>
>> On Thu, 10 Jan 2008 21:41:20 -0700
>> "Aggrwal Poonam" <Poonam.Aggrwal@freescale.com> wrote:
>>
>>> Hello All
>>>
>>> I am waiting for more feedback on the patches.
>>>
>>> If there are no objections please consider them for 2.6.25.
>>>
>> if this isn't going to go through Alessandro Rubini/misc drivers, can
>> it go through the akpm/mm tree?
>>
>
> That would work. But it might be more appropriate to go Kumar-
> >paulus->Linus.
I'm ok w/taking the arch/powerpc bits, but I"m a bit concerned about
the driver itself. I'm wondering if we need a TDM framework in the
kernel.
I guess if Poonam could possibly describe how this driver is actually
used that would be helpful. I see we have 8315 with a discrete TDM
block and I'm guessing 82xx/85xx based CPM parts of some form of TDM
as well.
- k
^ permalink raw reply
* Re: [PATCH] atl1: fix frame length bug
From: Jay Cliburn @ 2008-01-15 2:04 UTC (permalink / raw)
To: jeff, davem; +Cc: Jay Cliburn, csnook, david.harris, netdev
In-Reply-To: <1200362201-30987-1-git-send-email-jacliburn@bellsouth.net>
On Mon, 14 Jan 2008 19:56:41 -0600
Jay Cliburn <jacliburn@bellsouth.net> wrote:
> The driver sets up the hardware to accept a frame with max length
> equal to MTU + Ethernet header + FCS + VLAN tag, but we neglect to
> add the VLAN tag size to the ingress buffer. When a VLAN-tagged
> frame arrives, the hardware passes it, but bad things happen
> because the buffer is too small. This patch fixes that.
>
> Thanks to David Harris for reporting the bug and testing the fix.
>
> Tested-by: David Harris <david.harris@cpni-inc.com>
> Signed-off-by: Jay Cliburn <jacliburn@bellsouth.net>
Jeff, Dave,
This bugfix needs to go in for 2.6.24 if possible.
Thanks,
Jay
^ permalink raw reply
* [PATCH] atl1: fix frame length bug
From: Jay Cliburn @ 2008-01-15 1:56 UTC (permalink / raw)
To: jeff, davem; +Cc: csnook, david.harris, netdev, Jay Cliburn
The driver sets up the hardware to accept a frame with max length
equal to MTU + Ethernet header + FCS + VLAN tag, but we neglect to
add the VLAN tag size to the ingress buffer. When a VLAN-tagged
frame arrives, the hardware passes it, but bad things happen
because the buffer is too small. This patch fixes that.
Thanks to David Harris for reporting the bug and testing the fix.
Tested-by: David Harris <david.harris@cpni-inc.com>
Signed-off-by: Jay Cliburn <jacliburn@bellsouth.net>
---
drivers/net/atl1/atl1_main.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/atl1/atl1_main.c b/drivers/net/atl1/atl1_main.c
index 35b0a7d..9200ee5 100644
--- a/drivers/net/atl1/atl1_main.c
+++ b/drivers/net/atl1/atl1_main.c
@@ -120,7 +120,7 @@ static int __devinit atl1_sw_init(struct atl1_adapter *adapter)
struct atl1_hw *hw = &adapter->hw;
struct net_device *netdev = adapter->netdev;
- hw->max_frame_size = netdev->mtu + ETH_HLEN + ETH_FCS_LEN;
+ hw->max_frame_size = netdev->mtu + ETH_HLEN + ETH_FCS_LEN + VLAN_HLEN;
hw->min_frame_size = ETH_ZLEN + ETH_FCS_LEN;
adapter->wol = 0;
@@ -688,7 +688,7 @@ static int atl1_change_mtu(struct net_device *netdev, int new_mtu)
{
struct atl1_adapter *adapter = netdev_priv(netdev);
int old_mtu = netdev->mtu;
- int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN;
+ int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN + VLAN_HLEN;
if ((max_frame < ETH_ZLEN + ETH_FCS_LEN) ||
(max_frame > MAX_JUMBO_FRAME_SIZE)) {
@@ -853,8 +853,8 @@ static u32 atl1_configure(struct atl1_adapter *adapter)
/* set Interrupt Clear Timer */
iowrite16(adapter->ict, hw->hw_addr + REG_CMBDISDMA_TIMER);
- /* set MTU, 4 : VLAN */
- iowrite32(hw->max_frame_size + 4, hw->hw_addr + REG_MTU);
+ /* set max frame size hw will accept */
+ iowrite32(hw->max_frame_size, hw->hw_addr + REG_MTU);
/* jumbo size & rrd retirement timer */
value = (((u32) hw->rx_jumbo_th & RXQ_JMBOSZ_TH_MASK)
--
1.5.3.7
^ permalink raw reply related
* [Patch 2.6.24 1/1]S2io: Fixed synchronization between scheduling of napi with card reset and close
From: Sreenivasa Honnur @ 2008-01-15 1:23 UTC (permalink / raw)
To: netdev, jeff; +Cc: support
- Fixed synchronization between scheduling of napi with card reset and close
by moving the enabling and disabling of napi to card up and card down
functions respectively instead of open and close.
Signed-off-by: Surjit Reang <surjit.reang@neterion.com>
Signed-off-by: Ramkrishna Vepa <ram.vepa@neterion.com>
---
diff -Nurp 2-0-26-10/drivers/net/s2io.c 2-0-26-17/drivers/net/s2io.c
--- 2-0-26-10/drivers/net/s2io.c 2008-01-10 01:33:53.000000000 +0530
+++ 2-0-26-17/drivers/net/s2io.c 2008-01-10 04:39:15.000000000 +0530
@@ -84,7 +84,7 @@
#include "s2io.h"
#include "s2io-regs.h"
-#define DRV_VERSION "2.0.26.10"
+#define DRV_VERSION "2.0.26.17"
/* S2io Driver name & version. */
static char s2io_driver_name[] = "Neterion";
@@ -3851,8 +3851,6 @@ static int s2io_open(struct net_device *
netif_carrier_off(dev);
sp->last_link_state = 0;
- napi_enable(&sp->napi);
-
if (sp->config.intr_type == MSI_X) {
int ret = s2io_enable_msi_x(sp);
@@ -3895,7 +3893,6 @@ static int s2io_open(struct net_device *
return 0;
hw_init_failed:
- napi_disable(&sp->napi);
if (sp->config.intr_type == MSI_X) {
if (sp->entries) {
kfree(sp->entries);
@@ -3935,7 +3932,6 @@ static int s2io_close(struct net_device
return 0;
netif_stop_queue(dev);
- napi_disable(&sp->napi);
/* Reset card, kill tasklet and free Tx and Rx buffers. */
s2io_card_down(sp);
@@ -6799,6 +6795,8 @@ static void do_s2io_card_down(struct s2i
struct XENA_dev_config __iomem *bar0 = sp->bar0;
unsigned long flags;
register u64 val64 = 0;
+ struct config_param *config;
+ config = &sp->config;
if (!is_s2io_card_up(sp))
return;
@@ -6810,6 +6808,10 @@ static void do_s2io_card_down(struct s2i
}
clear_bit(__S2IO_STATE_CARD_UP, &sp->state);
+ /* Disable napi */
+ if (config->napi)
+ napi_disable(&sp->napi);
+
/* disable Tx and Rx traffic on the NIC */
if (do_io)
stop_nic(sp);
@@ -6903,6 +6905,11 @@ static int s2io_card_up(struct s2io_nic
DBG_PRINT(INFO_DBG, "Buf in ring:%d is %d:\n", i,
atomic_read(&sp->rx_bufs_left[i]));
}
+
+ /* Initialise napi */
+ if (config->napi)
+ napi_enable(&sp->napi);
+
/* Maintain the state prior to the open */
if (sp->promisc_flg)
sp->promisc_flg = 0;
^ permalink raw reply
* Re: [PATCH 1/3] drivers/net/ipg.c: Fix skbuff leak
From: Francois Romieu @ 2008-01-14 23:15 UTC (permalink / raw)
To: David Miller; +Cc: netdev
David Miller <davem@davemloft.net> :
> From: Francois Romieu <romieu@fr.zoreil.com>
> >
> > I should be able to test your r8169 NAPI changes tomorrow.
>
> Thank you.
(sorry for the delay)
I think that the r8169 part should be reverted.
. With it, my 8169 oopsed unexpectedly in rtl8169_reinit_task a few
seconds after I started a 'ping -q -f -l64 -s 36' and before I did
anything else. I do not have a clear explanation for the oops yet.
. rtl8169_reset_task will not like it as it could allow two racing
r8169_rx_interrupt.
. The irq will be enabled later when needed: the modified code is
only relevant for the reset/reinit tasks.
. After reverting the hunk, the 8168 in the same box stood the same
stream (> 50kpps in both direction). Everything worked as expected
when I ifconfiged it down, then up again. Same thing when I pluged
the cable out then in.
I'll give it more testing/thought.
--
Ueimor
^ permalink raw reply
* Re: 2.6.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
From: Paul Moore @ 2008-01-14 23:19 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: Andrew Morton, linux-kernel, netdev
In-Reply-To: <4382.1200351868@turing-police.cc.vt.edu>
On Monday 14 January 2008 6:04:28 pm Valdis.Kletnieks@vt.edu wrote:
> On Mon, 14 Jan 2008 14:07:46 EST, Paul Moore said:
> > http://git.infradead.org/?p=users/pcmoore/lblnet-2.6_testing;a=commitdiff
> >;h=02f1c89d6e36507476f78108a3dcc78538be460b
>
> Initial testing indicates that 2.6.24-rc6-mm1 plus this one commit is
> behaving itself correctly - my Tcl test case that reliably demonstrated
> wedges during SYN handling is definitively fixed, and the current issue
> with hangs with data pending seems to be gone as well (after admittedly
> light testing).
>
> Thanks for finding the commit that fixed it...
No problem, glad to hear that fixed the problem. It's already in Linus' tree
so any future -mm kernels as well as 2.6.24 should be problem-free, at least
with respect to this ;)
--
paul moore
linux security @ hp
^ permalink raw reply
* Re: 2.6.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
From: Valdis.Kletnieks @ 2008-01-14 23:04 UTC (permalink / raw)
To: Paul Moore; +Cc: Andrew Morton, linux-kernel, netdev
In-Reply-To: <200801141407.46345.paul.moore@hp.com>
[-- Attachment #1: Type: text/plain, Size: 524 bytes --]
On Mon, 14 Jan 2008 14:07:46 EST, Paul Moore said:
>
> http://git.infradead.org/?p=users/pcmoore/lblnet-2.6_testing;a=commitdiff;h=02f1c89d6e36507476f78108a3dcc78538be460b
Initial testing indicates that 2.6.24-rc6-mm1 plus this one commit is
behaving itself correctly - my Tcl test case that reliably demonstrated wedges
during SYN handling is definitively fixed, and the current issue with hangs with
data pending seems to be gone as well (after admittedly light testing).
Thanks for finding the commit that fixed it...
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: [patch for 2.6.24? 1/1] bonding: locking fix
From: Jay Vosburgh @ 2008-01-14 23:01 UTC (permalink / raw)
To: Andrew Morton; +Cc: Krzysztof Oledzki, davem, jeff, shemminger, netdev
In-Reply-To: <20080114144754.29a448ad.akpm@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> wrote:
[...]
>That's bond_lock.
>
>This patch (below) addresses what appears to me to be an obvious
>imbalance in rtnl_lock.
>
>I don't care how it's fixed, really. Someone please fix it?
I posted a correct patch for this a few days ago:
http://marc.info/?l=linux-netdev&m=119975746803886&w=2
The correct fix requires more than simply removing the rtnl calls.
I've got a few other patches in the pipeline, so I'm planning to
repost the set the above patch was a part of plus a few others, most
likely tomorrow.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [patch for 2.6.24? 1/1] bonding: locking fix
From: Andrew Morton @ 2008-01-14 22:47 UTC (permalink / raw)
To: Krzysztof Oledzki; +Cc: davem, jeff, shemminger, Jay Vosburgh, netdev
In-Reply-To: <Pine.LNX.4.64.0801142313350.26034@bizon.gios.gov.pl>
(cc's added)
On Mon, 14 Jan 2008 23:14:25 +0100 (CET)
Krzysztof Oledzki <olel@ans.pl> wrote:
>
>
> On Mon, 14 Jan 2008, akpm@linux-foundation.org wrote:
>
> > From: Andrew Morton <akpm@linux-foundation.org>
> >
> > Remove stray rtnl_unlock().
> >
> > Addresses http://bugzilla.kernel.org/show_bug.cgi?id=9542
> >
> > Cc: "David S. Miller" <davem@davemloft.net>
> > Cc: Stephen Hemminger <shemminger@linux-foundation.org>
> > Cc: Krzysztof Oledzki <olel@ans.pl>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > ---
> >
> > drivers/net/bonding/bond_sysfs.c | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff -puN drivers/net/bonding/bond_sysfs.c~bonding-locking-fix drivers/net/bonding/bond_sysfs.c
> > --- a/drivers/net/bonding/bond_sysfs.c~bonding-locking-fix
> > +++ a/drivers/net/bonding/bond_sysfs.c
> > @@ -1111,8 +1111,6 @@ static ssize_t bonding_store_primary(str
> > out:
> > write_unlock_bh(&bond->lock);
> >
> > - rtnl_unlock();
> > -
> > return count;
> > }
> > static DEVICE_ATTR(primary, S_IRUGO | S_IWUSR, bonding_show_primary, bonding_store_primary);
> > _
> >
>
> http://thread.gmane.org/gmane.linux.network/82566/focus=83142
>
That's bond_lock.
This patch (below) addresses what appears to me to be an obvious
imbalance in rtnl_lock.
I don't care how it's fixed, really. Someone please fix it?
From: Andrew Morton <akpm@linux-foundation.org>
Remove stray rtnl_unlock().
Addresses http://bugzilla.kernel.org/show_bug.cgi?id=9542
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>
Cc: Krzysztof Oledzki <olel@ans.pl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/net/bonding/bond_sysfs.c | 2 --
1 file changed, 2 deletions(-)
diff -puN drivers/net/bonding/bond_sysfs.c~bonding-locking-fix drivers/net/bonding/bond_sysfs.c
--- a/drivers/net/bonding/bond_sysfs.c~bonding-locking-fix
+++ a/drivers/net/bonding/bond_sysfs.c
@@ -1111,8 +1111,6 @@ static ssize_t bonding_store_primary(str
out:
write_unlock_bh(&bond->lock);
- rtnl_unlock();
-
return count;
}
static DEVICE_ATTR(primary, S_IRUGO | S_IWUSR, bonding_show_primary, bonding_store_primary);
_
^ permalink raw reply
* [PATCH 5/5] forcedeth: multicast fix
From: Ayaz Abdulla @ 2008-01-13 21:03 UTC (permalink / raw)
To: Jeff Garzik, Manfred Spraul, Andrew Morton, nedev
[-- Attachment #1: Type: text/plain, Size: 222 bytes --]
This patch fixes the case where no multicast addresses are requested to
be added to the multicast filter. The multicast mask must be set to all
1's instead of all 0's.
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
[-- Attachment #2: patch-forcedeth-multicast --]
[-- Type: text/plain, Size: 1707 bytes --]
--- old/drivers/net/forcedeth.c 2008-01-13 15:15:22.000000000 -0500
+++ new/drivers/net/forcedeth.c 2008-01-13 15:24:22.000000000 -0500
@@ -277,7 +277,9 @@
#define NVREG_MCASTADDRA_FORCE 0x01
NvRegMulticastAddrB = 0xB4,
NvRegMulticastMaskA = 0xB8,
+#define NVREG_MCASTMASKA_NONE 0xffffffff
NvRegMulticastMaskB = 0xBC,
+#define NVREG_MCASTMASKB_NONE 0xffff
NvRegPhyInterface = 0xC0,
#define PHY_RGMII 0x10000000
@@ -2693,6 +2695,9 @@
addr[1] = alwaysOn[1];
mask[0] = alwaysOn[0] | alwaysOff[0];
mask[1] = alwaysOn[1] | alwaysOff[1];
+ } else {
+ mask[0] = NVREG_MCASTMASKA_NONE;
+ mask[1] = NVREG_MCASTMASKB_NONE;
}
}
addr[0] |= NVREG_MCASTADDRA_FORCE;
@@ -4803,8 +4808,8 @@
nv_mac_reset(dev);
writel(NVREG_MCASTADDRA_FORCE, base + NvRegMulticastAddrA);
writel(0, base + NvRegMulticastAddrB);
- writel(0, base + NvRegMulticastMaskA);
- writel(0, base + NvRegMulticastMaskB);
+ writel(NVREG_MCASTMASKA_NONE, base + NvRegMulticastMaskA);
+ writel(NVREG_MCASTMASKB_NONE, base + NvRegMulticastMaskB);
writel(0, base + NvRegPacketFilterFlags);
writel(0, base + NvRegTransmitterControl);
@@ -4898,8 +4903,8 @@
spin_lock_irq(&np->lock);
writel(NVREG_MCASTADDRA_FORCE, base + NvRegMulticastAddrA);
writel(0, base + NvRegMulticastAddrB);
- writel(0, base + NvRegMulticastMaskA);
- writel(0, base + NvRegMulticastMaskB);
+ writel(NVREG_MCASTMASKA_NONE, base + NvRegMulticastMaskA);
+ writel(NVREG_MCASTMASKB_NONE, base + NvRegMulticastMaskB);
writel(NVREG_PFF_ALWAYS|NVREG_PFF_MYADDR, base + NvRegPacketFilterFlags);
/* One manual link speed update: Interrupts are enabled, future link
* speed changes cause interrupts and are handled by nv_link_irq().
^ permalink raw reply
* [PATCH 4/5] forcedeth: tx pause fix
From: Ayaz Abdulla @ 2008-01-13 21:03 UTC (permalink / raw)
To: Jeff Garzik, Manfred Spraul, Andrew Morton, netdev
[-- Attachment #1: Type: text/plain, Size: 169 bytes --]
This patch fixes the tx pause enable watermark flags. The new values
where determined to be optimal during testing.
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
[-- Attachment #2: patch-forcedeth-txpause --]
[-- Type: text/plain, Size: 547 bytes --]
--- old/drivers/net/forcedeth.c 2008-01-13 15:12:16.000000000 -0500
+++ new/drivers/net/forcedeth.c 2008-01-13 15:14:55.000000000 -0500
@@ -316,8 +316,8 @@
NvRegTxRingPhysAddrHigh = 0x148,
NvRegRxRingPhysAddrHigh = 0x14C,
NvRegTxPauseFrame = 0x170,
-#define NVREG_TX_PAUSEFRAME_DISABLE 0x1ff0080
-#define NVREG_TX_PAUSEFRAME_ENABLE 0x0c00030
+#define NVREG_TX_PAUSEFRAME_DISABLE 0x01ff0080
+#define NVREG_TX_PAUSEFRAME_ENABLE 0x01800010
NvRegMIIStatus = 0x180,
#define NVREG_MIISTAT_ERROR 0x0001
#define NVREG_MIISTAT_LINKCHANGE 0x0008
^ permalink raw reply
* [PATCH 3/5] forcedeth: updated copyright section
From: Ayaz Abdulla @ 2008-01-13 21:02 UTC (permalink / raw)
To: Jeff Garzik, Manfred Spraul, Andrew Morton, nedev
[-- Attachment #1: Type: text/plain, Size: 119 bytes --]
This patch updates the copyright section to include 2007 and 2008.
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
[-- Attachment #2: patch-forcedeth-copyright --]
[-- Type: text/plain, Size: 605 bytes --]
--- old/drivers/net/forcedeth.c 2008-01-13 15:10:18.000000000 -0500
+++ new/drivers/net/forcedeth.c 2008-01-13 15:11:47.000000000 -0500
@@ -13,7 +13,7 @@
* Copyright (C) 2004 Andrew de Quincey (wol support)
* Copyright (C) 2004 Carl-Daniel Hailfinger (invalid MAC handling, insane
* IRQ rate fixes, bigendian fixes, cleanups, verification)
- * Copyright (c) 2004,5,6 NVIDIA Corporation
+ * Copyright (c) 2004,2005,2006,2007,2008 NVIDIA Corporation
*
* 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
^ permalink raw reply
* [PATCH 1/5] forcedeth: reset register fix
From: Ayaz Abdulla @ 2008-01-13 21:02 UTC (permalink / raw)
To: Jeff Garzik, Manfred Spraul, Andrew Morton, nedev
[-- Attachment #1: Type: text/plain, Size: 118 bytes --]
This patch fixes the reset register definition from 0x3C to 0x34.
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
[-- Attachment #2: patch-forcedeth-reset-register --]
[-- Type: text/plain, Size: 379 bytes --]
--- old/drivers/net/forcedeth.c 2008-01-13 15:00:43.000000000 -0500
+++ new/drivers/net/forcedeth.c 2008-01-13 15:00:48.000000000 -0500
@@ -226,7 +226,7 @@
#define NVREG_MISC1_HD 0x02
#define NVREG_MISC1_FORCE 0x3b0f3c
- NvRegMacReset = 0x3c,
+ NvRegMacReset = 0x34,
#define NVREG_MAC_RESET_ASSERT 0x0F3
NvRegTransmitterControl = 0x084,
#define NVREG_XMITCTL_START 0x01
^ permalink raw reply
* Re: [BUG] skge 0000:02:05: read data parity error
From: Stephen Hemminger @ 2008-01-14 22:37 UTC (permalink / raw)
To: Oliver Pinter (Pintér Olivér)
Cc: Adrian Bunk, linux-kernel, netdev, gregkh
In-Reply-To: <6101e8c40801141358la75d1c6vb100247dbbd651a@mail.gmail.com>
On Mon, 14 Jan 2008 22:58:51 +0100
"Oliver Pinter (Pintér Olivér)" <oliver.pntr@gmail.com> wrote:
> I "tested" other devices resources file, and only with skge freezed
> the system. from this think, that is skge driver bug
>
Its a property of the hardware, and the current device model has
no way to stop it. Other devices are worse and can die if you access
pci config space.
--
Stephen Hemminger <stephen.hemminger@vyatta.com>
^ permalink raw reply
* [PATCH 2/5] forcedeth: checksum fix
From: Ayaz Abdulla @ 2008-01-13 21:02 UTC (permalink / raw)
To: Jeff Garzik, Manfred Spraul, Andrew Morton, nedev
[-- Attachment #1: Type: text/plain, Size: 625 bytes --]
The driver should inform the stack when checksum has been performed by
the HW when both IP and TCP (or UDP) checksum flags are indicated by HW.
Previously, it would also inform the stack when only IP checksum flag
was indicated by HW. This can cause data corruption when IP fragments
are used. The IP Identification field can wrap around and cause data
from new fragments to fill into older fragment slots with same IP Id.
The stack would then not perform TCP/UDP checksum (after re-assembly of
all fragments) since driver falsely stated it was already calculated.
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
[-- Attachment #2: patch-forcedeth-checksum --]
[-- Type: text/plain, Size: 1826 bytes --]
--- old/drivers/net/forcedeth.c 2008-01-13 15:01:36.000000000 -0500
+++ new/drivers/net/forcedeth.c 2008-01-13 15:08:31.000000000 -0500
@@ -471,9 +471,9 @@
#define NV_RX_AVAIL (1<<31)
#define NV_RX2_CHECKSUMMASK (0x1C000000)
-#define NV_RX2_CHECKSUMOK1 (0x10000000)
-#define NV_RX2_CHECKSUMOK2 (0x14000000)
-#define NV_RX2_CHECKSUMOK3 (0x18000000)
+#define NV_RX2_CHECKSUM_IP (0x10000000)
+#define NV_RX2_CHECKSUM_IP_TCP (0x14000000)
+#define NV_RX2_CHECKSUM_IP_UDP (0x18000000)
#define NV_RX2_DESCRIPTORVALID (1<<29)
#define NV_RX2_SUBSTRACT1 (1<<25)
#define NV_RX2_ERROR1 (1<<18)
@@ -2375,14 +2375,9 @@
goto next_pkt;
}
}
- if ((flags & NV_RX2_CHECKSUMMASK) == NV_RX2_CHECKSUMOK2)/*ip and tcp */ {
+ if (((flags & NV_RX2_CHECKSUMMASK) == NV_RX2_CHECKSUM_IP_TCP) || /*ip and tcp */
+ ((flags & NV_RX2_CHECKSUMMASK) == NV_RX2_CHECKSUM_IP_UDP)) /*ip and udp */
skb->ip_summed = CHECKSUM_UNNECESSARY;
- } else {
- if ((flags & NV_RX2_CHECKSUMMASK) == NV_RX2_CHECKSUMOK1 ||
- (flags & NV_RX2_CHECKSUMMASK) == NV_RX2_CHECKSUMOK3) {
- skb->ip_summed = CHECKSUM_UNNECESSARY;
- }
- }
} else {
dev_kfree_skb(skb);
goto next_pkt;
@@ -2474,14 +2469,9 @@
}
}
- if ((flags & NV_RX2_CHECKSUMMASK) == NV_RX2_CHECKSUMOK2)/*ip and tcp */ {
+ if (((flags & NV_RX2_CHECKSUMMASK) == NV_RX2_CHECKSUM_IP_TCP) || /*ip and tcp */
+ ((flags & NV_RX2_CHECKSUMMASK) == NV_RX2_CHECKSUM_IP_UDP)) /*ip and udp */
skb->ip_summed = CHECKSUM_UNNECESSARY;
- } else {
- if ((flags & NV_RX2_CHECKSUMMASK) == NV_RX2_CHECKSUMOK1 ||
- (flags & NV_RX2_CHECKSUMMASK) == NV_RX2_CHECKSUMOK3) {
- skb->ip_summed = CHECKSUM_UNNECESSARY;
- }
- }
/* got a valid packet - forward it to the network core */
skb_put(skb, len);
^ permalink raw reply
* Re: [PATCH 0/3] bonding: 3 fixes for 2.6.24
From: Krzysztof Oledzki @ 2008-01-14 22:15 UTC (permalink / raw)
To: Jay Vosburgh
Cc: Andy Gospodarek, netdev, Jeff Garzik, David Miller, Herbert Xu
In-Reply-To: <18609.1200160598@death>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2394 bytes --]
On Sat, 12 Jan 2008, Jay Vosburgh wrote:
> Krzysztof Oledzki <olel@ans.pl> wrote:
> [...]
>> Exactly. All I need to do is to reboot my server, I have 100% probability
>> to get the warning.
>
> I wish it were that easy for me; I'm not sure what magic thing
> you've got on your server or network that I don't, but I haven't been
> able to make this lockdep warning happen at all.
>
>> Right. So, what is the final patch? I would like to test it if that's
>> possible. ;)
>
> Can you test the following and let me know if it triggers the
> warning? I believe this is the minimum locking needed, and based on
> input from Herbert, we shouldn't need to hold the lock at _bh. If this
> one works, and nobody sees any other issues with it, then it's the final
> patch for this lockdep problem. I'll add some deep, meaningful comments
> to explain the locking a bit (i.e., we're called with rtnl for the
> allmulti and promisc cases, so we're ok there without additional locks,
> but the later code could be called from anywhere, so it needs locks to
> prevent the slave list from changing, but the mc_lists themselves are
> covered by the netif_tx_lock that all callers will hold), but this would
> be the actual code change.
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 77d004d..6906dbc 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -3937,8 +3937,6 @@ static void bond_set_multicast_list(struct net_device *bond_dev)
> struct bonding *bond = bond_dev->priv;
> struct dev_mc_list *dmi;
>
> - write_lock_bh(&bond->lock);
> -
> /*
> * Do promisc before checking multicast_mode
> */
> @@ -3959,6 +3957,8 @@ static void bond_set_multicast_list(struct net_device *bond_dev)
> bond_set_allmulti(bond, -1);
> }
>
> + read_lock(&bond->lock);
> +
> bond->flags = bond_dev->flags;
>
> /* looking for addresses to add to slaves' mc list */
> @@ -3979,7 +3979,7 @@ static void bond_set_multicast_list(struct net_device *bond_dev)
> bond_mc_list_destroy(bond);
> bond_mc_list_copy(bond_dev->mc_list, bond, GFP_ATOMIC);
>
> - write_unlock_bh(&bond->lock);
> + read_unlock(&bond->lock);
> }
>
> /*
>
>
I can confirm that the warning went away.
Tested-by: Krzysztof Piotr Oledzki <ole@ans.pl>
Best regards,
Krzysztof Olędzki
^ permalink raw reply
* Re: [BUG] skge 0000:02:05: read data parity error
From: Oliver Pinter (Pintér Olivér) @ 2008-01-14 21:58 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Stephen Hemminger, linux-kernel, netdev, gregkh
In-Reply-To: <20080114215209.GK9847@does.not.exist>
I "tested" other devices resources file, and only with skge freezed
the system. from this think, that is skge driver bug
--
Thanks,
Oliver
^ permalink raw reply
* Re: [BUG] skge 0000:02:05: read data parity error
From: Adrian Bunk @ 2008-01-14 21:52 UTC (permalink / raw)
To: Oliver Pinter (Pintér Olivér)
Cc: Stephen Hemminger, linux-kernel, netdev, gregkh
In-Reply-To: <6101e8c40801141341hcb17b08h2fd5244bccb21928@mail.gmail.com>
On Mon, Jan 14, 2008 at 10:41:52PM +0100, Oliver Pinter (Pintér Olivér) wrote:
> On 1/14/08, Adrian Bunk <bunk@kernel.org> wrote:
> > On Mon, Jan 14, 2008 at 10:31:03PM +0100, Oliver Pinter (Pintér Olivér)
> > wrote:
> > > I think, it is a potential security breakpoint, when applications with
> > > root permission its read, then a machine is freezed, or only i thin
> > > it's?
> >
> > When you are root there are infinite ways to kill your machine, so
> > there's nothing security related about this issue.
>
> Yes, i know, but when some application or daemons read some file with
> running root privileges, then ...
>
> thanks, then it is only a "feature" and not bug.
It might be a bug in the application.
But there are worse things than crashing your machine (e.g. getting your
/etc/shadow) that can happen when someone with bad intentions can read
files with root privileges.
> Thanks,
> Oliver
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [BUG] skge 0000:02:05: read data parity error
From: Greg KH @ 2008-01-14 21:48 UTC (permalink / raw)
To: Oliver Pinter (Pint?r Oliv?r)
Cc: Adrian Bunk, Stephen Hemminger, linux-kernel, netdev
In-Reply-To: <6101e8c40801141341hcb17b08h2fd5244bccb21928@mail.gmail.com>
On Mon, Jan 14, 2008 at 10:41:52PM +0100, Oliver Pinter (Pint?r Oliv?r) wrote:
> On 1/14/08, Adrian Bunk <bunk@kernel.org> wrote:
> > On Mon, Jan 14, 2008 at 10:31:03PM +0100, Oliver Pinter (Pint?r Oliv?r)
> > wrote:
> > > I think, it is a potential security breakpoint, when applications with
> > > root permission its read, then a machine is freezed, or only i thin
> > > it's?
> >
> > When you are root there are infinite ways to kill your machine, so
> > there's nothing security related about this issue.
>
> Yes, i know, but when some application or daemons read some file with
> running root privileges, then ...
It's always been that way, this is nothing new.
thanks,
greg k-h
^ permalink raw reply
* Re: Why are network counters only updated once a second?
From: Michael Chan @ 2008-01-14 22:31 UTC (permalink / raw)
To: Mark Seger; +Cc: netdev
In-Reply-To: <478BC662.6030004@hp.com>
On Mon, 2008-01-14 at 15:30 -0500, Mark Seger wrote:
> Eventually the frequency became better aligned at a 1 second interval
> because now the number look better, but the problem I see is that when
> the sampling interval is very close to the monitoring interval you still
> get periodic incorrect data. Furthermore, you now need to know which
> way the counters are updated before you pick a sampling interval! But
> the real point is if anyone ever wants to do finer grained monitoring,
> say every 1/2 or even tenth of a second, they can't because the counters
> won't change between samples. Has this ever been discussed before?
On most Broadcom NICs, the statistics counters are periodically DMA'ed
from the chip and the default interval is roughly 1 second. On most of
these chips, you can override this interval using ethtool -C eth0.
As I mentioned earlier, the 5706/5708 has a bug in the statistics DMA
engine that can corrupt counters from time to time. The workaround is
effective, but you now lose the ability to control the DMA interval.
^ permalink raw reply
* Re: [BUG] skge 0000:02:05: read data parity error
From: Oliver Pinter (Pintér Olivér) @ 2008-01-14 21:44 UTC (permalink / raw)
To: Greg KH; +Cc: Adrian Bunk, Stephen Hemminger, linux-kernel, netdev
In-Reply-To: <20080114213802.GA7860@suse.de>
On 1/14/08, Greg KH <gregkh@suse.de> wrote:
> On Mon, Jan 14, 2008 at 10:31:03PM +0100, Oliver Pinter (Pint?r Oliv?r)
> wrote:
> > I think, it is a potential security breakpoint, when applications with
> > root permission its read, then a machine is freezed, or only i thinK
> > it's?
>
> I'm sorry, I don't quite understand what you are trying to say here.
>
huh, sorry, it's typo and i'm not learn english, only myself ... and
my spelling is very bad, sorry
--
Thanks,
Oliver
^ permalink raw reply
* Re: [BUG] skge 0000:02:05: read data parity error
From: Oliver Pinter (Pintér Olivér) @ 2008-01-14 21:41 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Stephen Hemminger, linux-kernel, netdev, gregkh
In-Reply-To: <20080114213453.GJ9847@does.not.exist>
On 1/14/08, Adrian Bunk <bunk@kernel.org> wrote:
> On Mon, Jan 14, 2008 at 10:31:03PM +0100, Oliver Pinter (Pintér Olivér)
> wrote:
> > I think, it is a potential security breakpoint, when applications with
> > root permission its read, then a machine is freezed, or only i thin
> > it's?
>
> When you are root there are infinite ways to kill your machine, so
> there's nothing security related about this issue.
Yes, i know, but when some application or daemons read some file with
running root privileges, then ...
thanks, then it is only a "feature" and not bug.
>
> > Thanks,
> > Oliver
>
> cu
> Adrian
>
> --
>
> "Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
> "Only a promise," Lao Er said.
> Pearl S. Buck - Dragon Seed
>
>
--
Thanks,
Oliver
^ permalink raw reply
* Re: [BUG] skge 0000:02:05: read data parity error
From: Greg KH @ 2008-01-14 21:38 UTC (permalink / raw)
To: Oliver Pinter (Pint?r Oliv?r)
Cc: Adrian Bunk, Stephen Hemminger, linux-kernel, netdev
In-Reply-To: <6101e8c40801141331n3cb66c04pc74ff07faf04c8fd@mail.gmail.com>
On Mon, Jan 14, 2008 at 10:31:03PM +0100, Oliver Pinter (Pint?r Oliv?r) wrote:
> I think, it is a potential security breakpoint, when applications with
> root permission its read, then a machine is freezed, or only i thin
> it's?
I'm sorry, I don't quite understand what you are trying to say here.
^ 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