* Re: [BUG] i.MX25: Broken include in mach-mx25pdk.c
From: Matthias Kaehlcke @ 2010-03-25 17:28 UTC (permalink / raw)
To: Baruch Siach; +Cc: Sascha Hauer, linux-arm-kernel, David S. Miller, netdev
In-Reply-To: <20100325164147.GA27698@jasper.tkos.co.il>
hi,
El Thu, Mar 25, 2010 at 06:41:47PM +0200 Baruch Siach ha dit:
> On Thu, Mar 25, 2010 at 05:16:35PM +0100, Matthias Kaehlcke wrote:
> > compiling arch/arm/mach-mx25/mach-mx25pdk.c fails due to the missing
> > include "linux/fec.h" and incomplete types that are supposed to
> > defined in this header
> >
> > i'd send a fix, but greping through the kernel tree i haven't been
> > able to identify the file defining the missing elements, i suppose it's still
> > sitting bored in some development tree waiting to be merged
>
> Apply the patch at http://patchwork.ozlabs.org/patch/41235/.
>
> For some reason this patch never made it to the mainline even after my
> repeated nagging :(.
thanks for the pointer, baruch!
david: is there any inconvenience to merge the patch to netdev? if so,
what can be done to make it mergeable?
regards
--
Matthias Kaehlcke
Embedded Linux Developer
Barcelona
The assumption that what currently exists must necessarily
exist is the acid that corrodes all visionary thinking
.''`.
using free software / Debian GNU/Linux | http://debian.org : :' :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
^ permalink raw reply
* Re: Problem with talking to the kernel and iproute2/ifconfig
From: Patrick McHardy @ 2010-03-25 17:31 UTC (permalink / raw)
To: Paweł Staszewski; +Cc: Linux Network Development list
In-Reply-To: <4BAB88A3.9070702@itcare.pl>
[-- Attachment #1: Type: text/plain, Size: 749 bytes --]
Paweł Staszewski wrote:
> Hello
>
> I have strange problem with kernel 2.6.33.1
>
> I have script with 6267 ip's
>
> cat gateways.conf | grep 'addr add' | wc -l
> 6267
>
> and when i want to commit this interfaces by command:
> ip -batch gateways.conf
>
> I have only 680 ip interfaces
> ip a | grep inet | grep ' 10.' | wc -l
> 680
>
>
> I test this on kernels 2.6.29.1 and 2.6.30.1 and all was OK.
> on kernel 2.6.29.1
>
> ip -batch gateways.conf
> ip a | grep inet | grep ' 10.' | wc -l
> 6267
>
> on kernel 2.6.30.1
> ip -batch gateways.conf
> ip a | grep inet | grep ' 10.' | wc -l
> 6267
Does this patch help? When "idx" points to the last device
of a chain, it will never get incremented past s_idx and we
fail to reset s_ip_idx.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 455 bytes --]
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 51ca946..3feb2b3 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1194,7 +1194,7 @@ static int inet_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb)
hlist_for_each_entry_rcu(dev, node, head, index_hlist) {
if (idx < s_idx)
goto cont;
- if (idx > s_idx)
+ if (h > s_h || idx > s_idx)
s_ip_idx = 0;
in_dev = __in_dev_get_rcu(dev);
if (!in_dev)
^ permalink raw reply related
* RE: [PATCH] e1000e: export some settings using ethtool private flags
From: Tantilov, Emil S @ 2010-03-25 17:33 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev@vger.kernel.org
In-Reply-To: <4BAB9DB0.7020203@garzik.org>
Jeff Garzik wrote:
> On 03/25/2010 01:16 PM, Tantilov, Emil S wrote:
>> Jeff Garzik wrote:
>>> The ethtool private flags interface exists to get/set
>>> driver-specific settings at runtime, in a flexible manner.
>>>
>>> Use this facility to export a couple e1000e features, that were
>>> previously only set at module initialization time.
>>>
>>> Signed-off-by: Jeff Garzik<jgarzik@redhat.com>
>>> ---
>>> drivers/net/e1000e/ethtool.c | 27 +++++++++++++++++++++++++++
>>> 1 file changed, 27 insertions(+)
>>
>> Jeff,
>>
>> What is the use case for the ethtool private flags?
>
> It is stated in the changelog above :) It enables feature setting at
> setting, on an easy, per-network-interface basis, that were previously
> only settable at module initialization (ie. load) time.
>
>
>> At least I don't see an option in ethtool that would make use of
>> them.
>
> This is added in a separate patch, since the above patch is the first
> to make use of the private-flags ethtool mechanism.
Can you point me to it? It would really help me with testing.
Thanks,
Emil
^ permalink raw reply
* Re: [PATCH] e1000e: export some settings using ethtool private flags
From: Jeff Garzik @ 2010-03-25 17:30 UTC (permalink / raw)
To: Tantilov, Emil S; +Cc: netdev@vger.kernel.org
In-Reply-To: <EA929A9653AAE14F841771FB1DE5A1365FE4B3E5A7@rrsmsx501.amr.corp.intel.com>
On 03/25/2010 01:16 PM, Tantilov, Emil S wrote:
> Jeff Garzik wrote:
>> The ethtool private flags interface exists to get/set driver-specific
>> settings at runtime, in a flexible manner.
>>
>> Use this facility to export a couple e1000e features, that were
>> previously only set at module initialization time.
>>
>> Signed-off-by: Jeff Garzik<jgarzik@redhat.com>
>> ---
>> drivers/net/e1000e/ethtool.c | 27 +++++++++++++++++++++++++++
>> 1 file changed, 27 insertions(+)
>
> Jeff,
>
> What is the use case for the ethtool private flags?
It is stated in the changelog above :) It enables feature setting at
setting, on an easy, per-network-interface basis, that were previously
only settable at module initialization (ie. load) time.
> At least I don't see an option in ethtool that would make use of them.
This is added in a separate patch, since the above patch is the first to
make use of the private-flags ethtool mechanism.
Jeff
^ permalink raw reply
* Re: Oops from tcp_collapse() when using splice()
From: Steven J. Magnani @ 2010-03-25 17:38 UTC (permalink / raw)
To: netdev
In-Reply-To: <1269538271.3012.92.camel@iscandar.digidescorp.com>
On Wed, 2009-11-11 at 11:22 GMT, Karl Hiramoto wrote:
>
> Hi, the following oops occurs with both 2.6.28.9 and 2.6.30.9
>
> userspace program is using splice() on two tcp sockets.
>
> Internal error: Oops: 817 [#1]
> Modules linked in: pppoe pppox br2684 crc_ccitt nf_nat_pptp nf_nat_proto_gre nf_conntrack_pptp
> nf_conntrack_proto_gre af_key ixp4xx_crypto ipt_MASQUERADE
> CPU: 0 Not tainted (2.6.30.9 #1)
> PC is at tcp_collapse+0x268/0x338
> LR is at 0xc2c49640
> pc : [<c020be4c>] lr : [<c2c49640>] psr: 80000013
> sp : c0323c80 ip : c3a09920 fp : c0323cb8
> r10: 20ec0490 r9 : 00000e2c r8 : c2d117a0
> r7 : c2c49620 r6 : c2d11780 r5 : c2c49600 r4 : 00000074
> r3 : 00000000 r2 : 20ec4594 r1 : 00004104 r0 : c2c49600
> Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
> Control: 000039ff Table: 02efc000 DAC: 00000017
> Process swapper (pid: 0, stack limit = 0xc0322260)
> Stack: (0xc0323c80 to 0xc0324000)
> 3c80: c3a09920 c3a09920 c3a098c0 ffffc476 c3a098c0 c3a098c0 0000059a c2cded80
> 3ca0: c2eef054 c3a09c20 c2eef054 c0323cfc c0323cbc c020c114 c020bbf0 20ec0490
> 3cc0: 20ed15b0 18295345 00000000 c3a09c20 00000000 000008ec c3a098c0 0000059a
> 3ce0: c2cded80 c2eef054 c2cdeda0 c2eef054 c0323d30 c0323d00 c020c394 c020bf28
> 3d00: c2e5ec00 ffffffff c3a098c0 c2cded80 0000059a c2eef054 00000020 c2cdeda0
> 3d20: c2eef054 c0323d5c c0323d34 c02102f8 c020c1b4 00000000 c2cded80 c3a098c0
> 3d40: c2eef054 c03576fc c2eef040 0000cd2b c0323d8c c0323d60 c0215770 c020fddc
> 3d60: bf11dcfc 00000000 c0323d8c c0323d78 00000000 c2cded80 c3a098c0 c2eef054
> 3d80: c0323dc8 c0323d90 c021750c c021574c 0a430f2d 0000cd2b 00000005 c0357e58
> 3da0: c033dd04 c2cded80 00000000 c03576fc c0358518 c033b870 00000000 c0323dec
> 3dc0: c0323dcc c01fb6ac c0216e6c c2cded80 c2cded80 c2eef040 c2e5ec00 c0357a40
> 3de0: c0323e0c c0323df0 c01fbb68 c01fb55c 00000000 c01fb550 80000000 c0357a20
> 3e00: c0323e38 c0323e10 c01fb52c c01fbaf8 c2e5ec00 c2cded80 c0357a20 c2cded80
> 3e20: c03576fc c2e5ec00 c0357a40 c0323e64 c0323e3c c01fbab8 c01fb22c 00000000
> 3e40: c01fb220 80000000 c0357a20 c2cded80 c2e5ec00 00000800 c0323e94 c0323e68
> 3e60: c01ddf24 c01fb86c c2e5c600 c0323ecc 00000002 c033b888 ffffbe5e 00000040
> 3e80: 00000000 c033b86c c0323ec0 c0323e98 c01ddff4 c01ddb9c c033b888 00000040
> 3ea0: 00000100 0000012c c033b86c c033b87c ffffbe60 c0323eec c0323ec4 c01e095c
> 3ec0: c01ddf74 c0322000 0000000c 00000100 00000001 00000009 c034b72c 00000000
> 3ee0: c0323f20 c0323ef0 c00359dc c01e0900 c0323efc c0029608 00000003 00000000
> 3f00: 00000008 c03426a8 0001c608 690541f1 0001c49c c0323f30 c0323f24 c0035c98
> 3f20: c003597c c0323f48 c0323f34 c0020058 c0035c60 ffffffff 0000001f c0323fa0
> 3f40: c0323f4c c00209c4 c002000c c03273c8 c383e300 c0322000 00000000 c0021de8
> 3f60: c0322000 c0021de8 c03426a8 0001c608 690541f1 0001c49c c0323fa0 c0323fa4
> 3f80: c0323f94 c0021cb0 c0021dfc 60000013 ffffffff c0323fc0 c0323fa4 c0021cb0
> 3fa0: c0021df4 c034dfc4 c0342450 c001dd60 c0326344 c0323fd0 c0323fc4 c0263be4
> 3fc0: c0021c80 c0323ff4 c0323fd4 c00089c0 c0263b98 c00083ac c001dd60 000039fd
> 3fe0: c03426d8 c001e164 00000000 c0323ff8 00008034 c00087bc 00000000 00000000
> Backtrace:
> [<c020bbe4>] (tcp_collapse+0x0/0x338) from [<c020c114>] (tcp_prune_queue+0x1f8/0x28c)
> [<c020bf1c>] (tcp_prune_queue+0x0/0x28c) from [<c020c394>] (tcp_data_queue+0x1ec/0xc3c)
> [<c020c1a8>] (tcp_data_queue+0x0/0xc3c) from [<c02102f8>] (tcp_rcv_established+0x528/0x5e0)
> [<c020fdd0>] (tcp_rcv_established+0x0/0x5e0) from [<c0215770>] (tcp_v4_do_rcv+0x30/0x1c4)
> [<c0215740>] (tcp_v4_do_rcv+0x0/0x1c4) from [<c021750c>] (tcp_v4_rcv+0x6ac/0x754)
> r7:c2eef054 r6:c3a098c0 r5:c2cded80 r4:00000000
> [<c0216e60>] (tcp_v4_rcv+0x0/0x754) from [<c01fb6ac>] (ip_local_deliver_finish+0x15c/0x21c)
> [<c01fb550>] (ip_local_deliver_finish+0x0/0x21c) from [<c01fbb68>]
> (ip_local_deliver+0x7c/0x88)
> r8:c0357a40 r7:c2e5ec00 r6:c2eef040 r5:c2cded80 r4:c2cded80
> [<c01fbaec>] (ip_local_deliver+0x0/0x88) from [<c01fb52c>] (ip_rcv_finish+0x30c/0x330)
> r4:c0357a20
> [<c01fb220>] (ip_rcv_finish+0x0/0x330) from [<c01fbab8>] (ip_rcv+0x258/0x28c)
> r8:c0357a40 r7:c2e5ec00 r6:c03576fc r5:c2cded80 r4:c0357a20
> [<c01fb860>] (ip_rcv+0x0/0x28c) from [<c01ddf24>] (netif_receive_skb+0x394/0x3d8)
> r7:00000800 r6:c2e5ec00 r5:c2cded80 r4:c0357a20
> [<c01ddb90>] (netif_receive_skb+0x0/0x3d8) from [<c01ddff4>] (process_backlog+0x8c/0xd8)
> [<c01ddf68>] (process_backlog+0x0/0xd8) from [<c01e095c>] (net_rx_action+0x68/0x188)
> [<c01e08f4>] (net_rx_action+0x0/0x188) from [<c00359dc>] (__do_softirq+0x6c/0xf8)
> [<c0035970>] (__do_softirq+0x0/0xf8) from [<c0035c98>] (irq_exit+0x44/0x4c)
> [<c0035c54>] (irq_exit+0x0/0x4c) from [<c0020058>] (asm_do_IRQ+0x58/0x6c)
> [<c0020000>] (asm_do_IRQ+0x0/0x6c) from [<c00209c4>] (__irq_svc+0x24/0x80)
> Exception stack(0xc0323f4c to 0xc0323f94)
> 3f40: c03273c8 c383e300 c0322000 00000000 c0021de8
> 3f60: c0322000 c0021de8 c03426a8 0001c608 690541f1 0001c49c c0323fa0 c0323fa4
> 3f80: c0323f94 c0021cb0 c0021dfc 60000013 ffffffff
> r5:0000001f r4:ffffffff
> [<c0021de8>] (default_idle+0x0/0x4c) from [<c0021cb0>] (cpu_idle+0x3c/0x58)
> [<c0021c74>] (cpu_idle+0x0/0x58) from [<c0263be4>] (rest_init+0x58/0x6c)
> r7:c0326344 r6:c001dd60 r5:c0342450 r4:c034dfc4
> [<c0263b8c>] (rest_init+0x0/0x6c) from [<c00089c0>] (start_kernel+0x210/0x264)
> [<c00087b0>] (start_kernel+0x0/0x264) from [<00008034>] (0x8034)
> r6:c001e164 r5:c03426d8 r4:000039fd
> Code: e50b302c e06a1002 5a000002 e3a03000 (e5833000)
If there was any followup to this, I can't find it. I see similar
problems with 2.6.33.1:
BUG: failure at net/ipv4/tcp_input.c:4665/tcp_collapse()!
Kernel panic - not syncing: BUG!
Call Trace:
[<20002a20>] microblaze_unwind+0x30/0x50
[<20002724>] show_stack+0x130/0x16c
[<20002768>] dump_stack+0x8/0x20
[<2000b5a0>] panic+0x78/0x1f4
[<20177e50>] tcp_collapse+0x358/0x42c
[<20178110>] tcp_prune_queue+0x1ec/0x2c8
[<201783d8>] tcp_data_queue+0x1ec/0xd30
[<2017cb78>] tcp_rcv_established+0x724/0x800
[<20182eb8>] tcp_v4_do_rcv+0x34/0x1d8
[<20185014>] tcp_v4_rcv+0x504/0x814
[<2016585c>] ip_local_deliver+0x118/0x1ec
[<20165e50>] ip_rcv+0x520/0x5ac
[<201468e4>] netif_receive_skb+0x2ec/0x338
[<201469b8>] process_backlog+0x88/0xec
[<2014ad20>] net_rx_action+0x84/0x1b8
[<20011244>] __do_softirq+0x94/0x148
[<20011328>] do_softirq+0x30/0x54
[<2001161c>] irq_exit+0x30/0x48
[<2000114c>] do_IRQ+0xcc/0xf8
IRQ
[<200d6b40>] strncpy+0x1c/0x30
[<200da618>] strncpy_from_user+0x40/0x88
[<2005a374>] getname+0x84/0xf4
[<2004dff8>] do_sys_open+0x28/0xe4
[<2004e0e4>] sys_open+0x14/0x2c
SYSCALL
[<2d19d33c>] PID 88 [syslogd]
Any suggestions on how to pin this down?
------------------------------------------------------------------------
Steven J. Magnani "I claim this network for MARS!
www.digidescorp.com Earthling, return my space modulator!"
#include <standard.disclaimer>
^ permalink raw reply
* Re: Problem with talking to the kernel and iproute2/ifconfig
From: Paweł Staszewski @ 2010-03-25 17:52 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Linux Network Development list
In-Reply-To: <4BAB9E02.2040605@trash.net>
Yes
This patch resolve this problem and all is working now correctly.
cat gateways.conf | grep 'addr add' | wc -l
6267
ip -batch gateways.conf
ip a sh | grep ' 10.' | grep inet | wc -l
6267
W dniu 2010-03-25 18:31, Patrick McHardy pisze:
> Paweł Staszewski wrote:
>
>> Hello
>>
>> I have strange problem with kernel 2.6.33.1
>>
>> I have script with 6267 ip's
>>
>> cat gateways.conf | grep 'addr add' | wc -l
>> 6267
>>
>> and when i want to commit this interfaces by command:
>> ip -batch gateways.conf
>>
>> I have only 680 ip interfaces
>> ip a | grep inet | grep ' 10.' | wc -l
>> 680
>>
>>
>> I test this on kernels 2.6.29.1 and 2.6.30.1 and all was OK.
>> on kernel 2.6.29.1
>>
>> ip -batch gateways.conf
>> ip a | grep inet | grep ' 10.' | wc -l
>> 6267
>>
>> on kernel 2.6.30.1
>> ip -batch gateways.conf
>> ip a | grep inet | grep ' 10.' | wc -l
>> 6267
>>
> Does this patch help? When "idx" points to the last device
> of a chain, it will never get incremented past s_idx and we
> fail to reset s_ip_idx.
>
>
^ permalink raw reply
* Re: [PATCH] e1000e: export some settings using ethtool private flags
From: Laurent Chavey @ 2010-03-25 17:52 UTC (permalink / raw)
To: Tantilov, Emil S; +Cc: Jeff Garzik, netdev@vger.kernel.org
In-Reply-To: <EA929A9653AAE14F841771FB1DE5A1365FE4B3E600@rrsmsx501.amr.corp.intel.com>
http://lists.openwall.net/netdev/2007/08/10/114
On Thu, Mar 25, 2010 at 10:33 AM, Tantilov, Emil S
<emil.s.tantilov@intel.com> wrote:
> Jeff Garzik wrote:
>> On 03/25/2010 01:16 PM, Tantilov, Emil S wrote:
>>> Jeff Garzik wrote:
>>>> The ethtool private flags interface exists to get/set
>>>> driver-specific settings at runtime, in a flexible manner.
>>>>
>>>> Use this facility to export a couple e1000e features, that were
>>>> previously only set at module initialization time.
>>>>
>>>> Signed-off-by: Jeff Garzik<jgarzik@redhat.com>
>>>> ---
>>>> drivers/net/e1000e/ethtool.c | 27 +++++++++++++++++++++++++++
>>>> 1 file changed, 27 insertions(+)
>>>
>>> Jeff,
>>>
>>> What is the use case for the ethtool private flags?
>>
>> It is stated in the changelog above :) It enables feature setting at
>> setting, on an easy, per-network-interface basis, that were previously
>> only settable at module initialization (ie. load) time.
>>
>>
>>> At least I don't see an option in ethtool that would make use of
>>> them.
>>
>> This is added in a separate patch, since the above patch is the first
>> to make use of the private-flags ethtool mechanism.
>
> Can you point me to it? It would really help me with testing.
>
> Thanks,
> Emil
>
>
> --
> 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
* [PATCH 1/4] netfilter: xt_recent: fix regression in rules using a zero hit_count
From: kaber @ 2010-03-25 17:54 UTC (permalink / raw)
To: davem; +Cc: netfilter-devel, netdev
In-Reply-To: <1269539686-3885-1-git-send-email-kaber@trash.net>
From: Patrick McHardy <kaber@trash.net>
Commit 8ccb92ad (netfilter: xt_recent: fix false match) fixed supposedly
false matches in rules using a zero hit_count. As it turns out there is
nothing false about these matches and people are actually using entries
with a hit_count of zero to make rules dependant on addresses inserted
manually through /proc.
Since this slipped past the eyes of three reviewers, instead of
reverting the commit in question, this patch explicitly checks
for a hit_count of zero to make the intentions more clear.
Reported-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
Tested-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
Cc: stable@kernel.org
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
net/netfilter/xt_recent.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/netfilter/xt_recent.c b/net/netfilter/xt_recent.c
index 7073dbb..971d172 100644
--- a/net/netfilter/xt_recent.c
+++ b/net/netfilter/xt_recent.c
@@ -267,7 +267,7 @@ recent_mt(const struct sk_buff *skb, const struct xt_match_param *par)
for (i = 0; i < e->nstamps; i++) {
if (info->seconds && time_after(time, e->stamps[i]))
continue;
- if (info->hit_count && ++hits >= info->hit_count) {
+ if (!info->hit_count || ++hits >= info->hit_count) {
ret = !ret;
break;
}
--
1.6.5.7
^ permalink raw reply related
* [PATCH 0/4] netfilter fixes
From: kaber @ 2010-03-25 17:54 UTC (permalink / raw)
To: davem; +Cc: netfilter-devel, netdev
Hi Dave,
following are four netfilter fixes for 2.6.34, fixing:
- a regression in the recent match, introduced during 2.6.33
- a crash after a failed memory allocation in xt_hashlimit seq_file handling
- an incorrect hook priority of the IPv6 raw table
- a missing 'break' in the IPv6 xt_hashlimit netmask calculation
include/linux/netfilter_ipv6.h | 1 +
net/ipv6/netfilter/ip6table_raw.c | 2 +-
net/netfilter/xt_hashlimit.c | 4 +++-
net/netfilter/xt_recent.c | 2 +-
4 files changed, 6 insertions(+), 3 deletions(-)
Please apply or pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git master
Thanks!
PS: this is my first "live" attempt at using git-send-email, so appologies
in advance in case I made any mistakes.
^ permalink raw reply
* [PATCH 2/4] netfilter: xt_hashlimit: dl_seq_stop() fix
From: kaber @ 2010-03-25 17:54 UTC (permalink / raw)
To: davem; +Cc: netfilter-devel, netdev
In-Reply-To: <1269539686-3885-2-git-send-email-kaber@trash.net>
From: Eric Dumazet <eric.dumazet@gmail.com>
If dl_seq_start() memory allocation fails, we crash later in
dl_seq_stop(), trying to kfree(ERR_PTR(-ENOMEM))
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
net/netfilter/xt_hashlimit.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/netfilter/xt_hashlimit.c b/net/netfilter/xt_hashlimit.c
index 9e9c489..70d561a 100644
--- a/net/netfilter/xt_hashlimit.c
+++ b/net/netfilter/xt_hashlimit.c
@@ -879,7 +879,8 @@ static void dl_seq_stop(struct seq_file *s, void *v)
struct xt_hashlimit_htable *htable = s->private;
unsigned int *bucket = (unsigned int *)v;
- kfree(bucket);
+ if (!IS_ERR(bucket))
+ kfree(bucket);
spin_unlock_bh(&htable->lock);
}
--
1.6.5.7
^ permalink raw reply related
* [PATCH 3/4] netfilter: ip6table_raw: fix table priority
From: kaber @ 2010-03-25 17:54 UTC (permalink / raw)
To: davem; +Cc: netfilter-devel, netdev
In-Reply-To: <1269539686-3885-3-git-send-email-kaber@trash.net>
From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
The order of the IPv6 raw table is currently reversed, that makes impossible
to use the NOTRACK target in IPv6: for example if someone enters
ip6tables -t raw -A PREROUTING -p tcp --dport 80 -j NOTRACK
and if we receive fragmented packets then the first fragment will be
untracked and thus skip nf_ct_frag6_gather (and conntrack), while all
subsequent fragments enter nf_ct_frag6_gather and reassembly will never
successfully be finished.
Singed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
include/linux/netfilter_ipv6.h | 1 +
net/ipv6/netfilter/ip6table_raw.c | 2 +-
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/include/linux/netfilter_ipv6.h b/include/linux/netfilter_ipv6.h
index d654873..1f7e300 100644
--- a/include/linux/netfilter_ipv6.h
+++ b/include/linux/netfilter_ipv6.h
@@ -59,6 +59,7 @@
enum nf_ip6_hook_priorities {
NF_IP6_PRI_FIRST = INT_MIN,
NF_IP6_PRI_CONNTRACK_DEFRAG = -400,
+ NF_IP6_PRI_RAW = -300,
NF_IP6_PRI_SELINUX_FIRST = -225,
NF_IP6_PRI_CONNTRACK = -200,
NF_IP6_PRI_MANGLE = -150,
diff --git a/net/ipv6/netfilter/ip6table_raw.c b/net/ipv6/netfilter/ip6table_raw.c
index aef31a2..b9cf7cd 100644
--- a/net/ipv6/netfilter/ip6table_raw.c
+++ b/net/ipv6/netfilter/ip6table_raw.c
@@ -13,7 +13,7 @@ static const struct xt_table packet_raw = {
.valid_hooks = RAW_VALID_HOOKS,
.me = THIS_MODULE,
.af = NFPROTO_IPV6,
- .priority = NF_IP6_PRI_FIRST,
+ .priority = NF_IP6_PRI_RAW,
};
/* The work comes in here from netfilter.c. */
--
1.6.5.7
^ permalink raw reply related
* [PATCH 4/4] netfilter: xt_hashlimit: IPV6 bugfix
From: kaber @ 2010-03-25 17:54 UTC (permalink / raw)
To: davem; +Cc: netfilter-devel, netdev
In-Reply-To: <1269539686-3885-4-git-send-email-kaber@trash.net>
From: Eric Dumazet <eric.dumazet@gmail.com>
A missing break statement in hashlimit_ipv6_mask(), and masks
between /64 and /95 are not working at all...
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
net/netfilter/xt_hashlimit.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/netfilter/xt_hashlimit.c b/net/netfilter/xt_hashlimit.c
index 70d561a..215a648 100644
--- a/net/netfilter/xt_hashlimit.c
+++ b/net/netfilter/xt_hashlimit.c
@@ -493,6 +493,7 @@ static void hashlimit_ipv6_mask(__be32 *i, unsigned int p)
case 64 ... 95:
i[2] = maskl(i[2], p - 64);
i[3] = 0;
+ break;
case 96 ... 127:
i[3] = maskl(i[3], p - 96);
break;
--
1.6.5.7
^ permalink raw reply related
* QoS weirdness : HTB accuracy
From: Julien Vehent @ 2010-03-25 18:06 UTC (permalink / raw)
To: Netdev, netfilter
[-- Attachment #1: Type: text/plain, Size: 1547 bytes --]
Hello folks,
I observe unused bandwidth on my QoS policy that I cannot explain.
Conditions are: I have a HTB tree with 8 classes and a total rate of
768kbits. I use the ATM option so I assume the real rate to be something
close to 675kbits (about 88% of the ethernet rate).
The sum of my 8 rates is exactly 768kbits. Some have ceil values up to
768kbits.
When class 20 "tcp_acks" starts borrowing, TC reduces the total bandwidth
down to 595kbits/S (minus 79kbits/s). And I can't explain why....
The attached graph "tc_htb_weirdness.png" shows the result: there are
'holes' in the sending rate.
I tried to play with burst sizes, r2q value and hysteresis mode, but the
results are the same.
System is debian squeeze, kernel version is 2.6.26, iproute2 version is
2.6.26 - 07/25/2008.
I have attached two files:
- "tcrules.txt" : the traffic control rules
- "tc_htb_weirdness.png" : the rrdtool graph, resolution is 1 second.
And here: http://jve.linuxwall.info/ressources/code/tc_hole_analysis.html
a sheet with some of the measures values. I used it to calculate the size
of one of the hole. The last table (with green and red cells) shows that,
when class 20 "tcp_acks" starts sending at unixtime 1265496813, there is a
lot of bandwidth left over (last column is all green). During the 95
seconds while class 20 is sending, 3880776 bits could be sent but are not.
That's about 40kbits/s on average.
Does anybody observess the same behavior? Any logical explanation to this
or is it a bug ?
Julien
[-- Attachment #2: tcrules.txt --]
[-- Type: text/plain, Size: 2619 bytes --]
#root
tc qdisc add dev eth0 root handle 1: htb default 99 r2q 100
#main branch
tc class add dev eth0 parent 1:0 classid 1:1 htb rate 768kbit ceil 768kbit linklayer atm overhead 5
# class 10 "interactive"
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 128kbit ceil 200kbit burst 5k prio 1 linklayer atm overhead 5
tc qdisc add dev eth0 parent 1:10 handle 110: pfifo limit 1000
tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle 10 fw flowid 1:10
# class 20 "tcp_acks"
tc class add dev eth0 parent 1:1 classid 1:20 htb rate 64kbit ceil 768kbit burst 3k prio 2 linklayer atm overhead 5
tc qdisc add dev eth0 parent 1:20 handle 120: pfifo limit 1000
tc filter add dev eth0 parent 1:0 protocol ip prio 2 handle 20 fw flowid 1:20
# class 30 "ssh"
tc class add dev eth0 parent 1:1 classid 1:30 htb rate 64kbit ceil 300kbit burst 2k prio 3 linklayer atm overhead 5
tc qdisc add dev eth0 parent 1:30 handle 130: sfq perturb 10
tc filter add dev eth0 parent 1:0 protocol ip prio 3 handle 30 fw flowid 1:30
# class 40 "main web"
tc class add dev eth0 parent 1:1 classid 1:40 htb rate 256kbit ceil 768kbit burst 20k prio 4 linklayer atm overhead 5
# class 41 "sub web 1"
tc class add dev eth0 parent 1:40 classid 1:41 htb rate 100kbit ceil 768kbit burst 20k prio 4 linklayer atm overhead 5
tc qdisc add dev eth0 parent 1:41 handle 141: sfq perturb 10
tc filter add dev eth0 parent 1:0 protocol ip prio 4 handle 41 fw flowid 1:41
# class 42 "sub web 2"
tc class add dev eth0 parent 1:40 classid 1:42 htb rate 100kbit ceil 768kbit burst 20k prio 4 linklayer atm overhead 5
tc qdisc add dev eth0 parent 1:42 handle 142: sfq perturb 10
tc filter add dev eth0 parent 1:0 protocol ip prio 5 handle 42 fw flowid 1:42
# class 49 "sub web gen"
tc class add dev eth0 parent 1:40 classid 1:49 htb rate 56kbit ceil 768kbit burst 20k prio 4 linklayer atm overhead 5
tc qdisc add dev eth0 parent 1:49 handle 149: sfq perturb 10
tc filter add dev eth0 parent 1:0 protocol ip prio 6 handle 49 fw flowid 1:49
# class 50 "torrent"
tc class add dev eth0 parent 1:1 classid 1:50 htb rate 128kbit ceil 768kbit burst 2k prio 5 linklayer atm overhead 5
tc qdisc add dev eth0 parent 1:50 handle 150: sfq perturb 10
tc filter add dev eth0 parent 1:0 protocol ip prio 7 handle 50 fw flowid 1:50
# class 99 "default"
tc class add dev eth0 parent 1:1 classid 1:99 htb rate 128kbit ceil 768kbit burst 2k prio 5 linklayer atm overhead 5 mtu 1500
tc qdisc add dev eth0 parent 1:99 handle 199: sfq perturb 10
tc filter add dev eth0 parent 1:0 protocol ip prio 99 handle 99 fw flowid 1:99
[-- Attachment #3: tc_htb_weirdness.png --]
[-- Type: image/png, Size: 29681 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4] netfilter fixes
From: David Miller @ 2010-03-25 18:49 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel, netdev
In-Reply-To: <1269539686-3885-1-git-send-email-kaber@trash.net>
From: kaber@trash.net
Date: Thu, 25 Mar 2010 18:54:42 +0100
> Please apply or pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git master
Pulled, thanks a lot Patrick.
^ permalink raw reply
* Re: [PATCHv1 3/4] netxen: added sanity check for pci map
From: David Miller @ 2010-03-25 19:04 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman
In-Reply-To: <1269500806-15383-4-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Thu, 25 Mar 2010 00:06:45 -0700
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
>
> Return value of ioremap is not checked, NULL check added.
You're not even thinking when you make these changes.
Let's try again ok?
These ioremap() calls store the pointers into local variables.
So it doesn't work at all to just jump to err_out to clean
them up and iounmap them.
The unamp code you end up calling in netxen_pci_map() only does an
iounmap() on pointers stored in the netxen_adapter struct. At this
point they haven't been stored there yet.
So they still leak.
Can you tell my patience on this patch set is very much running
out? If you put half of the effort writing these patches as I
am putting into reviewing them, we wouldn't have to go back
and forth on this so many times.
Double check your work, and resubmit this whole patch set once you've
fixed this one, I think the other ones look fine.
Thanks.
^ permalink raw reply
* Re: rps: add CONFIG_RPS
From: David Miller @ 2010-03-25 19:08 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
Ok, this default boolean version looks fine.
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH RFC 1/2] flow: virtualize get and entry deletion methods
From: David Miller @ 2010-03-25 19:26 UTC (permalink / raw)
To: timo.teras; +Cc: netdev, herbert
In-Reply-To: <1269509091-6440-2-git-send-email-timo.teras@iki.fi>
From: Timo Teras <timo.teras@iki.fi>
Date: Thu, 25 Mar 2010 11:24:50 +0200
> This allows to validate the cached object before returning it.
> It also allows to destruct object properly, if the last reference
> was held in flow cache. This is also a prepartion for caching
> bundles in the flow cache.
>
> In return for virtualizing the methods, we save on:
> - not having to regenerate the whole flow cache on policy removal:
> each flow matching a killed policy gets refreshed as the getter
> function notices it smartly.
> - we do not have to call flow_cache_flush from policy gc, since the
> flow cache now properly deletes the object if it had any references
>
> This also means the flow cache entry deletion does more work. If
> it's too slow now, may have to implement delayed deletion of flow
> cache entries. But this is a save because this enables immediate
> deletion of policies and bundles.
>
> Signed-off-by: Timo Teras <timo.teras@iki.fi>
I'm concerned about the new costs being added here.
We have to now take the policy lock as a reader every time the flow
cache wants to grab a reference. So we now have this plus the
indirect function call new overhead.
Maybe we can make the dead state check safe to do asynchronously
somehow? I wonder if the policy layer is overdue for an RCU
conversion or similar.
Anyways, something to think about. Otherwise I don't mind these
changes.
^ permalink raw reply
* Re: [PATCH 1/1] [TIPC] Removed inactive maintainer
From: David Miller @ 2010-03-25 19:40 UTC (permalink / raw)
To: jon.maloy; +Cc: netdev, tipc-discussion
In-Reply-To: <1269531343-27569-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Paul Maloy <jon.maloy@ericsson.com>
Date: Thu, 25 Mar 2010 11:35:43 -0400
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Applied, thanks Jon.
^ permalink raw reply
* [PATCH] netfilter: CLUSTERIP: clusterip_seq_stop() fix
From: Eric Dumazet @ 2010-03-25 19:47 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter-devel, netdev, David Miller
In-Reply-To: <1269539686-3885-3-git-send-email-kaber@trash.net>
If clusterip_seq_start() memory allocation fails, we crash later in
clusterip_seq_start(), trying to kfree(ERR_PTR(-ENOMEM))
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/net/ipv4/netfilter/ipt_CLUSTERIP.c b/net/ipv4/netfilter/ipt_CLUSTERIP.c
index 0886f96..afa937b 100644
--- a/net/ipv4/netfilter/ipt_CLUSTERIP.c
+++ b/net/ipv4/netfilter/ipt_CLUSTERIP.c
@@ -600,7 +600,8 @@ static void *clusterip_seq_next(struct seq_file *s, void *v, loff_t *pos)
static void clusterip_seq_stop(struct seq_file *s, void *v)
{
- kfree(v);
+ if (!IS_ERR(v))
+ kfree(v);
}
static int clusterip_seq_show(struct seq_file *s, void *v)
^ permalink raw reply related
* [GIT]: Networking
From: David Miller @ 2010-03-25 19:58 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) ISDN driver section mismatch fixes from Henrik Kretzschmar.
2) xt_hashlimit netfilter fixes (leaks, missing break in IPV6
header parsing switch statement) from Eric Dumazet.
3) netpoll silently sets dport to zero when spaces are in
kernel command line parameters, at least warn about this.
From Amerigo Wang.
4) IGB crashes in promisc mode when VLAN packet is received
without any vlans registered, fix from Alexander Duyck.
5) skb_shared_info causes all packets to use 4K SLABs instead
of 2K ones, due to completely unused dma_head and dma_maps
fields which we removed all references to recently. Kill
them, also from Alexander Duyck.
6) Via Andrew Morton, allow nls_cls to be modular.
7) netpoll crashes in bnx2 because it invokes wrong interrupt
handler, fix from Benjamin Li. Also, need to invoke
netif_napi_add() after we know exactly how many irq vectors
will be used, also from Benjamin Li.
8) af_key loses errors and returns zero on some memory allocation
failures, fix from Dan Carpenter.
9) VIA Velocity programs advertisement MII registers incorrectly
when both RX and TX flow control are enabled, from your's truly.
Noticed by Roel Kluin.
10) Update TIPC maintainers entry, from Jon Maloy.
11) VLANs do not do TX queue selection properly when the device
has a ->select_queue() override. Also add some validation
to make sure we do not choose a queue larger than the number
the device actually has. From Vasu Dev.
12) RXRPX protocol does not check for allocation failures in
incomping call accept code, fix from Tetsuo Handa.
13) Fix regression in xt_recent netfilter module wrt. zero hit_count
rules. From Thomas Jarosch.
14) blackfin CAN driver register definitions moved to asm/bfin_can.h,
from Mike Frysinger.
15) Disallow acceptance of NX_P3_B1 rev chips by the netxen driver,
these are preproduction chips and the driver doesn't work properly
right now with them. From Eric W. Biederman and ack'd by
Qlogic folks, although another solution to this problem might be
forthcoming.
16) ksz884x driver returns bogus error code from netdev_set_eeprom,
fix from Jens Rottmann.
17) IGB mishandled RX FIFO errors and incorrectly changes TX queue
len on link changes, fixes from Mitch Williams and Emil
Tantilov.
18) IPV6 RAW netfilter table priority is set wrong, fix from
Jozsef Kadlecsik.
Please pull, thanks a lot!
The following changes since commit 01e77706cdde7c0b47e5ca1f4284a795504c7c40:
Linus Torvalds (1):
Merge branch 'for-linus' of git://gitorious.org/linux-omap-dss2/linux
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
Alexander Duyck (2):
igb: only use vlan_gro_receive if vlans are registered
skbuff: remove unused dma_head & dma_maps fields
Amerigo Wang (1):
netpoll: warn when there are spaces in parameters
Ben Blum (1):
cgroups: net_cls as module
Benjamin Li (1):
bnx2: Fix netpoll crash.
Dan Carpenter (1):
af_key: return error if pfkey_xfrm_policy2msg_prep() fails
David S. Miller (3):
Merge branch 'master' of /home/davem/src/GIT/linux-2.6/
Merge branch 'master' of git://git.kernel.org/.../kaber/nf-2.6
via-velocity: Fix FLOW_CNTL_TX_RX handling in set_mii_flow_control()
Emil Tantilov (1):
igb: do not modify tx_queue_len on link speed change
Eric Dumazet (2):
netfilter: xt_hashlimit: dl_seq_stop() fix
netfilter: xt_hashlimit: IPV6 bugfix
Eric W. Biederman (1):
netxen: The driver doesn't work on NX_P3_B1 so cause probe to fail.
Henrik Kretzschmar (4):
isdn: Cleanup Sections in PCMCIA driver sedlbauer
isdn: Cleanup Sections in PCMCIA driver teles
isdn: Cleanup Sections in PCMCIA driver avma1
isdn: Cleanup Sections in PCMCIA driver elsa
Jens Rottmann (1):
ksz884x: fix return value of netdev_set_eeprom
Jon Maloy (1):
TIPC: Removed inactive maintainer
Jozsef Kadlecsik (1):
netfilter: ip6table_raw: fix table priority
Michael Chan (1):
bnx2: Use proper handler during netpoll.
Mike Frysinger (1):
can: bfin_can: switch to common Blackfin can header
Mitch Williams (1):
igb: count Rx FIFO errors correctly
Patrick McHardy (1):
netfilter: xt_recent: fix regression in rules using a zero hit_count
Tetsuo Handa (1):
rxrpc: Check allocation failure.
Vasu Dev (2):
vlan: adds vlan_dev_select_queue
vlan: updates vlan real_num_tx_queues
MAINTAINERS | 1 -
drivers/isdn/hisax/avma1_cs.c | 12 ++--
drivers/isdn/hisax/elsa_cs.c | 12 ++--
drivers/isdn/hisax/sedlbauer_cs.c | 12 ++--
drivers/isdn/hisax/teles_cs.c | 12 ++--
drivers/net/bnx2.c | 14 +++--
drivers/net/can/bfin_can.c | 97 +++-------------------------------
drivers/net/igb/igb.h | 1 -
drivers/net/igb/igb_main.c | 22 +++-----
drivers/net/ksz884x.c | 2 +-
drivers/net/netxen/netxen_nic_main.c | 4 +-
drivers/net/via-velocity.c | 2 +-
include/linux/netfilter_ipv6.h | 1 +
include/linux/skbuff.h | 6 --
net/8021q/vlan.c | 2 +
net/8021q/vlan_dev.c | 71 ++++++++++++++++++++++++-
net/core/netpoll.c | 7 ++-
net/ipv6/netfilter/ip6table_raw.c | 2 +-
net/key/af_key.c | 8 +--
net/netfilter/xt_hashlimit.c | 4 +-
net/netfilter/xt_recent.c | 2 +-
net/sched/Kconfig | 5 ++-
net/sched/cls_cgroup.c | 36 +++++++++---
23 files changed, 166 insertions(+), 169 deletions(-)
^ permalink raw reply
* Re: Does Realtek RTL8110S and RTL8100C work ?
From: Jan Ceuleers @ 2010-03-25 20:02 UTC (permalink / raw)
To: Markus Feldmann; +Cc: netdev
In-Reply-To: <hoab2m$kc0$1@dough.gmane.org>
Markus Feldmann wrote:
> i am thinking about buying a Mini-ITX Server with some Realtek Cips on
> the PCI Network Devices. These are
> Realtek RTL8110S
> Realtek RTL8100C
>
> The Mini-ITX is a Jetway JNF92.
> Does anybody know whether they work good or should i keep the hands off
> these?
I've got a Jetway J7F4 which has two Realtek RTL8110S devices. They look like this:
# lshw
(...)
*-network:0
description: Ethernet interface
product: RTL-8110SC/8169SC Gigabit Ethernet
vendor: Realtek Semiconductor Co., Ltd.
physical id: 9
bus info: pci@0000:00:09.0
logical name: eth0
version: 10
serial: 00:30:18:a4:e4:a4
size: 1GB/s
capacity: 1GB/s
width: 32 bits
clock: 66MHz
capabilities: bus_master ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=full ip=192.168.1.11 latency=64 link=yes maxlatency=64 mingnt=32 module=r8169 multicast=yes port=MII speed=1GB/s
*-network:1
description: Ethernet interface
product: RTL-8110SC/8169SC Gigabit Ethernet
vendor: Realtek Semiconductor Co., Ltd.
physical id: b
bus info: pci@0000:00:0b.0
logical name: eth1
version: 10
serial: 00:30:18:a4:e4:a5
size: 100MB/s
capacity: 1GB/s
width: 32 bits
clock: 66MHz
capabilities: bus_master ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=full ip=10.20.0.3 latency=64 link=yes maxlatency=64 mingnt=32 module=r8169 multicast=yes port=MII speed=100MB/s
(...)
eth1 has auto-negotiated 100Mbit/s because it is hard-wired to a device which isn't gigabit-capable.
Cheers, Jan
^ permalink raw reply
* Re: mmotm 2010-03-23 - IPv6 warnings...
From: David Miller @ 2010-03-25 20:25 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: akpm, netdev, linux-kernel
In-Reply-To: <4788.1269535530@localhost>
From: Valdis.Kletnieks@vt.edu
Date: Thu, 25 Mar 2010 12:45:30 -0400
> On Wed, 24 Mar 2010 18:42:26 EDT, Andrew Morton said:
>> On Wed, 24 Mar 2010 21:36:41 -0400 Valdis.Kletnieks@vt.edu wrote:
>>
>> > On Tue, 23 Mar 2010 15:34:59 PDT, akpm@linux-foundation.org said:
>> > > The mm-of-the-moment snapshot 2010-03-23-15-34 has been uploaded to
>> > >
>> > > http://userweb.kernel.org/~akpm/mmotm/
>> >
>> > Seen in my dmesg. It may be relevant that I'm at home, and my IPv6
>> > prefix arrives via a PPP VPN connection. This happened about 20-25 seconds
>> > after I launched pppd.
>>
>> Yes, thanks, I get the same - it doesn't seem to break anything. It
>> also happens some time after boot has completed.
>
> Just doing an 'ifup eth0' on a network with IPv6 on it is sufficient.
I'm going to look into this more deeply tonight.
^ permalink raw reply
* [net-2.6 PATCH] ixgbe: fix bug with vlan strip in promsic mode
From: Jeff Kirsher @ 2010-03-25 21:34 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Jesse Brandeburg, Jeff Kirsher
From: Jesse Brandeburg <jesse.brandeburg@intel.com>
The ixgbe driver was setting up 82598 hardware correctly, so that
when promiscuous mode was enabled hardware stripping was turned
off. But on 82599 the logic to disable/enable hardware stripping
is different, and the code was not updated correctly when the
hardware vlan stripping was enabled as default.
This change comprises the creation of two new helper functions
and calling them from the right locations to disable and enable
hardware stripping of vlan tags at appropriate times.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_main.c | 115 +++++++++++++++++++++++++---------------
1 files changed, 72 insertions(+), 43 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index 997d997..3c86707 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -2481,12 +2481,74 @@ static void ixgbe_vlan_rx_kill_vid(struct net_device *netdev, u16 vid)
hw->mac.ops.set_vfta(&adapter->hw, vid, pool_ndx, false);
}
+/**
+ * ixgbe_vlan_filter_disable - helper to disable hw vlan filtering
+ * @adapter: driver data
+ */
+static void ixgbe_vlan_filter_disable(struct ixgbe_adapter *adapter)
+{
+ struct ixgbe_hw *hw = &adapter->hw;
+ u32 vlnctrl = IXGBE_READ_REG(hw, IXGBE_VLNCTRL);
+ int i, j;
+
+ switch (hw->mac.type) {
+ case ixgbe_mac_82598EB:
+ vlnctrl &= ~(IXGBE_VLNCTRL_VME | IXGBE_VLNCTRL_VFE);
+ vlnctrl &= ~IXGBE_VLNCTRL_CFIEN;
+ IXGBE_WRITE_REG(hw, IXGBE_VLNCTRL, vlnctrl);
+ break;
+ case ixgbe_mac_82599EB:
+ vlnctrl &= ~IXGBE_VLNCTRL_VFE;
+ vlnctrl &= ~IXGBE_VLNCTRL_CFIEN;
+ IXGBE_WRITE_REG(hw, IXGBE_VLNCTRL, vlnctrl);
+ for (i = 0; i < adapter->num_rx_queues; i++) {
+ j = adapter->rx_ring[i]->reg_idx;
+ vlnctrl = IXGBE_READ_REG(hw, IXGBE_RXDCTL(j));
+ vlnctrl &= ~IXGBE_RXDCTL_VME;
+ IXGBE_WRITE_REG(hw, IXGBE_RXDCTL(j), vlnctrl);
+ }
+ break;
+ default:
+ break;
+ }
+}
+
+/**
+ * ixgbe_vlan_filter_enable - helper to enable hw vlan filtering
+ * @adapter: driver data
+ */
+static void ixgbe_vlan_filter_enable(struct ixgbe_adapter *adapter)
+{
+ struct ixgbe_hw *hw = &adapter->hw;
+ u32 vlnctrl = IXGBE_READ_REG(hw, IXGBE_VLNCTRL);
+ int i, j;
+
+ switch (hw->mac.type) {
+ case ixgbe_mac_82598EB:
+ vlnctrl |= IXGBE_VLNCTRL_VME | IXGBE_VLNCTRL_VFE;
+ vlnctrl &= ~IXGBE_VLNCTRL_CFIEN;
+ IXGBE_WRITE_REG(hw, IXGBE_VLNCTRL, vlnctrl);
+ break;
+ case ixgbe_mac_82599EB:
+ vlnctrl |= IXGBE_VLNCTRL_VFE;
+ vlnctrl &= ~IXGBE_VLNCTRL_CFIEN;
+ IXGBE_WRITE_REG(hw, IXGBE_VLNCTRL, vlnctrl);
+ for (i = 0; i < adapter->num_rx_queues; i++) {
+ j = adapter->rx_ring[i]->reg_idx;
+ vlnctrl = IXGBE_READ_REG(hw, IXGBE_RXDCTL(j));
+ vlnctrl |= IXGBE_RXDCTL_VME;
+ IXGBE_WRITE_REG(hw, IXGBE_RXDCTL(j), vlnctrl);
+ }
+ break;
+ default:
+ break;
+ }
+}
+
static void ixgbe_vlan_rx_register(struct net_device *netdev,
struct vlan_group *grp)
{
struct ixgbe_adapter *adapter = netdev_priv(netdev);
- u32 ctrl;
- int i, j;
if (!test_bit(__IXGBE_DOWN, &adapter->state))
ixgbe_irq_disable(adapter);
@@ -2497,25 +2559,7 @@ static void ixgbe_vlan_rx_register(struct net_device *netdev,
* still receive traffic from a DCB-enabled host even if we're
* not in DCB mode.
*/
- ctrl = IXGBE_READ_REG(&adapter->hw, IXGBE_VLNCTRL);
-
- /* Disable CFI check */
- ctrl &= ~IXGBE_VLNCTRL_CFIEN;
-
- /* enable VLAN tag stripping */
- if (adapter->hw.mac.type == ixgbe_mac_82598EB) {
- ctrl |= IXGBE_VLNCTRL_VME;
- } else if (adapter->hw.mac.type == ixgbe_mac_82599EB) {
- for (i = 0; i < adapter->num_rx_queues; i++) {
- u32 ctrl;
- j = adapter->rx_ring[i]->reg_idx;
- ctrl = IXGBE_READ_REG(&adapter->hw, IXGBE_RXDCTL(j));
- ctrl |= IXGBE_RXDCTL_VME;
- IXGBE_WRITE_REG(&adapter->hw, IXGBE_RXDCTL(j), ctrl);
- }
- }
-
- IXGBE_WRITE_REG(&adapter->hw, IXGBE_VLNCTRL, ctrl);
+ ixgbe_vlan_filter_enable(adapter);
ixgbe_vlan_rx_add_vid(netdev, 0);
@@ -2550,17 +2594,17 @@ void ixgbe_set_rx_mode(struct net_device *netdev)
{
struct ixgbe_adapter *adapter = netdev_priv(netdev);
struct ixgbe_hw *hw = &adapter->hw;
- u32 fctrl, vlnctrl;
+ u32 fctrl;
/* Check for Promiscuous and All Multicast modes */
fctrl = IXGBE_READ_REG(hw, IXGBE_FCTRL);
- vlnctrl = IXGBE_READ_REG(hw, IXGBE_VLNCTRL);
if (netdev->flags & IFF_PROMISC) {
hw->addr_ctrl.user_set_promisc = 1;
fctrl |= (IXGBE_FCTRL_UPE | IXGBE_FCTRL_MPE);
- vlnctrl &= ~IXGBE_VLNCTRL_VFE;
+ /* don't hardware filter vlans in promisc mode */
+ ixgbe_vlan_filter_disable(adapter);
} else {
if (netdev->flags & IFF_ALLMULTI) {
fctrl |= IXGBE_FCTRL_MPE;
@@ -2568,12 +2612,11 @@ void ixgbe_set_rx_mode(struct net_device *netdev)
} else {
fctrl &= ~(IXGBE_FCTRL_UPE | IXGBE_FCTRL_MPE);
}
- vlnctrl |= IXGBE_VLNCTRL_VFE;
+ ixgbe_vlan_filter_enable(adapter);
hw->addr_ctrl.user_set_promisc = 0;
}
IXGBE_WRITE_REG(hw, IXGBE_FCTRL, fctrl);
- IXGBE_WRITE_REG(hw, IXGBE_VLNCTRL, vlnctrl);
/* reprogram secondary unicast list */
hw->mac.ops.update_uc_addr_list(hw, netdev);
@@ -2640,7 +2683,7 @@ static void ixgbe_napi_disable_all(struct ixgbe_adapter *adapter)
static void ixgbe_configure_dcb(struct ixgbe_adapter *adapter)
{
struct ixgbe_hw *hw = &adapter->hw;
- u32 txdctl, vlnctrl;
+ u32 txdctl;
int i, j;
ixgbe_dcb_check_config(&adapter->dcb_cfg);
@@ -2658,22 +2701,8 @@ static void ixgbe_configure_dcb(struct ixgbe_adapter *adapter)
IXGBE_WRITE_REG(hw, IXGBE_TXDCTL(j), txdctl);
}
/* Enable VLAN tag insert/strip */
- vlnctrl = IXGBE_READ_REG(hw, IXGBE_VLNCTRL);
- if (hw->mac.type == ixgbe_mac_82598EB) {
- vlnctrl |= IXGBE_VLNCTRL_VME | IXGBE_VLNCTRL_VFE;
- vlnctrl &= ~IXGBE_VLNCTRL_CFIEN;
- IXGBE_WRITE_REG(hw, IXGBE_VLNCTRL, vlnctrl);
- } else if (hw->mac.type == ixgbe_mac_82599EB) {
- vlnctrl |= IXGBE_VLNCTRL_VFE;
- vlnctrl &= ~IXGBE_VLNCTRL_CFIEN;
- IXGBE_WRITE_REG(hw, IXGBE_VLNCTRL, vlnctrl);
- for (i = 0; i < adapter->num_rx_queues; i++) {
- j = adapter->rx_ring[i]->reg_idx;
- vlnctrl = IXGBE_READ_REG(hw, IXGBE_RXDCTL(j));
- vlnctrl |= IXGBE_RXDCTL_VME;
- IXGBE_WRITE_REG(hw, IXGBE_RXDCTL(j), vlnctrl);
- }
- }
+ ixgbe_vlan_filter_enable(adapter);
+
hw->mac.ops.set_vfta(&adapter->hw, 0, 0, true);
}
^ permalink raw reply related
* [net-2.6 PATCH] bonding: fix broken multicast with round-robin mode
From: Andy Gospodarek @ 2010-03-25 21:40 UTC (permalink / raw)
To: netdev; +Cc: lhh, fubar, bonding-devel
Round-robin (mode 0) does nothing to ensure that any multicast traffic
originally destined for the host will continue to arrive at the host when
the link that sent the IGMP join or membership report goes down. One of
the benefits of absolute round-robin transmit.
Keeping track of subscribed multicast groups for each slave did not seem
like a good use of resources, so I decided to simply send on the
curr_active slave of the bond (typically the first enslaved device that
is up). This makes failover management simple as IGMP membership
reports only need to be sent when the curr_active_slave changes. I
tested this patch and it appears to work as expected.
Originally reported by Lon Hohberger <lhh@redhat.com>.
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
CC: Lon Hohberger <lhh@redhat.com>
CC: Jay Vosburgh <fubar@us.ibm.com>
---
drivers/net/bonding/bond_main.c | 34 ++++++++++++++++++++++++++--------
1 files changed, 26 insertions(+), 8 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 430c022..0b38455 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1235,6 +1235,11 @@ void bond_change_active_slave(struct bonding *bond, struct slave *new_active)
write_lock_bh(&bond->curr_slave_lock);
}
}
+
+ /* resend IGMP joins since all were sent on curr_active_slave */
+ if (bond->params.mode == BOND_MODE_ROUNDROBIN) {
+ bond_resend_igmp_join_requests(bond);
+ }
}
/**
@@ -4138,22 +4143,35 @@ static int bond_xmit_roundrobin(struct sk_buff *skb, struct net_device *bond_dev
struct bonding *bond = netdev_priv(bond_dev);
struct slave *slave, *start_at;
int i, slave_no, res = 1;
+ struct iphdr *iph = ip_hdr(skb);
read_lock(&bond->lock);
if (!BOND_IS_OK(bond))
goto out;
-
/*
- * Concurrent TX may collide on rr_tx_counter; we accept that
- * as being rare enough not to justify using an atomic op here
+ * Start with the curr_active_slave that joined the bond as the
+ * default for sending IGMP traffic. For failover purposes one
+ * needs to maintain some consistency for the interface that will
+ * send the join/membership reports. The curr_active_slave found
+ * will send all of this type of traffic.
*/
- slave_no = bond->rr_tx_counter++ % bond->slave_cnt;
+ if ((skb->protocol == htons(ETH_P_IP)) &&
+ (iph->protocol == htons(IPPROTO_IGMP))) {
+ slave = bond->curr_active_slave;
+ } else {
+ /*
+ * Concurrent TX may collide on rr_tx_counter; we accept
+ * that as being rare enough not to justify using an
+ * atomic op here.
+ */
+ slave_no = bond->rr_tx_counter++ % bond->slave_cnt;
- bond_for_each_slave(bond, slave, i) {
- slave_no--;
- if (slave_no < 0)
- break;
+ bond_for_each_slave(bond, slave, i) {
+ slave_no--;
+ if (slave_no < 0)
+ break;
+ }
}
start_at = slave;
^ permalink raw reply related
* [net-2.6 PATCH] igbvf: do not modify tx_queue_len on link speed change
From: Jeff Kirsher @ 2010-03-25 22:11 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Franco Fichtner, Emil Tantilov, Jeff Kirsher
From: Emil Tantilov <emil.s.tantilov@intel.com>
Previously the driver tweaked txqueuelen to avoid false Tx hang reports seen at half duplex.
This had the effect of overriding user set values on link change/reset. Testing shows that
adjusting only the timeout factor is sufficient to prevent Tx hang reports at half duplex.
Based on e1000e patch by Franco Fichtner <franco@lastsummer.de>
CC: Franco Fichtner <franco@lastsummer.de>
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/igbvf/igbvf.h | 1 -
drivers/net/igbvf/netdev.c | 11 +----------
2 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/drivers/net/igbvf/igbvf.h b/drivers/net/igbvf/igbvf.h
index a1774b2..debeee2 100644
--- a/drivers/net/igbvf/igbvf.h
+++ b/drivers/net/igbvf/igbvf.h
@@ -198,7 +198,6 @@ struct igbvf_adapter {
struct igbvf_ring *tx_ring /* One per active queue */
____cacheline_aligned_in_smp;
- unsigned long tx_queue_len;
unsigned int restart_queue;
u32 txd_cmd;
diff --git a/drivers/net/igbvf/netdev.c b/drivers/net/igbvf/netdev.c
index a77afd8..b41037e 100644
--- a/drivers/net/igbvf/netdev.c
+++ b/drivers/net/igbvf/netdev.c
@@ -1304,8 +1304,6 @@ static void igbvf_configure_tx(struct igbvf_adapter *adapter)
/* enable Report Status bit */
adapter->txd_cmd |= E1000_ADVTXD_DCMD_RS;
-
- adapter->tx_queue_len = adapter->netdev->tx_queue_len;
}
/**
@@ -1524,7 +1522,6 @@ void igbvf_down(struct igbvf_adapter *adapter)
del_timer_sync(&adapter->watchdog_timer);
- netdev->tx_queue_len = adapter->tx_queue_len;
netif_carrier_off(netdev);
/* record the stats before reset*/
@@ -1857,21 +1854,15 @@ static void igbvf_watchdog_task(struct work_struct *work)
&adapter->link_duplex);
igbvf_print_link_info(adapter);
- /*
- * tweak tx_queue_len according to speed/duplex
- * and adjust the timeout factor
- */
- netdev->tx_queue_len = adapter->tx_queue_len;
+ /* adjust timeout factor according to speed/duplex */
adapter->tx_timeout_factor = 1;
switch (adapter->link_speed) {
case SPEED_10:
txb2b = 0;
- netdev->tx_queue_len = 10;
adapter->tx_timeout_factor = 16;
break;
case SPEED_100:
txb2b = 0;
- netdev->tx_queue_len = 100;
/* maybe add some timeout factor ? */
break;
}
^ 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