* Re: [RFC PATCH net-next 0/7 v2]IPv6:netfilter: defragment
From: Patrick McHardy @ 2010-03-23 17:16 UTC (permalink / raw)
To: YOSHIFUJI Hideaki
Cc: Shan Wei, YOSHIFUJI Hideaki, David Miller, Alexey Dobriyan,
Yasuyuki KOZAKAI, netdev@vger.kernel.org, netfilter-devel
In-Reply-To: <4BA8EC4A.9070802@linux-ipv6.org>
YOSHIFUJI Hideaki wrote:
> Hello.
>
> Sorry for my slow response.
>
> (2010/03/16 1:27), Patrick McHardy wrote:
>> YOSHIFUJI Hideaki wrote:
>>> (2010/03/11 18:16), Shan Wei wrote:
>>>>> On the other hand, I'd even say we should NOT send
>>>>> icmp here (at least by default) because standard routers
>>>>> never send such packet.
>>>>
>>>> Yes，for routers, the patch-set does not send icmp message to
>>>> source host. It only does on destination host with IPv6 connection
>>>> track enable.
>>>
>>> Please make it optional (via parameter) at least.
>>
>> The ICMP messages are only sent if the packet is destined for the
>> local host, similar to what IPv6 defrag would do if conntrack wouldn't
>> be used. So this patch increases consistency, why should we make this
>> optional?
>
> Well, in the first place, I do think conntrack should be
> transparent as much as possible. And, I cannot find other
> netfilter conntrack code (ipv4 or ipv6) sending icmp e.g.
> parameter problem etc.
Agreed on the transparent part, however I consider silently dropping
packets not transparent. In fact conntrack itself should never drop
packets except under some very special circumstances when there's
no other choice in order to operate correctly. Dropping packets is
supposed to be a policy decision made by the user.
In this case without conntrack, IPv6 would send an ICMPv6 message,
so in my opinion the transparent thing to do would be to still send
them. Of course only if reassembly is done on an end host.
There's really no difference in sending these packets from conntrack
compared to passing the incomplete fragments upwards to IPv6 and
waiting for another timeout, except that its easier to implement
consistently by generating the packets within conntrack.
> As I said before, I agree that netfilter may drop packets
> by any reasons, but I do think it should be done silently.
> It can increment netfilter's own statistic counting etc.
> but it should not increment the core's (especially,
> specific) statistic counting.
It really depends on what you define as "transparent".
>
> Reassembling processes are the same. We should NOT send icmp, and
> if ever desired, we might optionally send icmp (in other
> module maybe).
Please see above for my reasoning. There's also the matter of consistency
between IPv4 and IPv6 conntrack.
^ permalink raw reply
* Re: ixgbe: Set IXGBE_RSC_CB(skb)->DMA field to zero after unmapping the address
From: Malli @ 2010-03-23 17:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Mallikarjuna R Chilakala, Linux Kernel Mailing List, David Miller,
netdev
In-Reply-To: <1269316670.8599.101.camel@pasglop>
On Mon, Mar 22, 2010 at 8:57 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Mon, 2010-03-22 at 17:59 +0000, Linux Kernel Mailing List wrote:
>> Gitweb: http://git.kernel.org/linus/fd3686a842717b890fbe3024b83a616c54d5dba0
>> Commit: fd3686a842717b890fbe3024b83a616c54d5dba0
>> Parent: 936332b8e00103fc20eb7e915c9a3bcb2835a11a
>> Author: Mallikarjuna R Chilakala <mallikarjuna.chilakala@intel.com>
>> AuthorDate: Fri Mar 19 04:41:33 2010 +0000
>> Committer: David S. Miller <davem@davemloft.net>
>> CommitDate: Fri Mar 19 21:00:44 2010 -0700
>>
>> ixgbe: Set IXGBE_RSC_CB(skb)->DMA field to zero after unmapping the address
>>
>> As per Simon Horman's feedback set IXGBE_RSC_CB(skb)->dma to zero
>> after unmapping HWRSC DMA address to avoid double freeing.
>>
>
> Note that this whole code is bogus :-) You cannot just assume that 0 is
> a invalid DMA address. It is not. In fact, while you can check if a
> dma_addr_t is invalid using dma_mapping_error(), the generic APIs
> don't provide you with a magic "bad" value you can use for what you are
> trying to do.
>
> Granted, I think we should make our iommu code reserve the first page
> for the sake of everybody's sanity and to avoid such pitfalls, but
> this code is wrong with today iommu implementations.
>
> Cheers,
> Ben.
Yes. I just realized that i can't assign a zero magic "bad" value. It is only
valid in x86/arm/m68k/alpha architecures and not in spark & PowerPC arch,
(it should be ~0). In some other architecutres it throws a BUG() on with
dma_mapping_error() checks. So the patch is not a total bogus in some
architectures :(.
May be it is best to create an internal FLAG in IXGBE_RSC_CB(skb)
which can be used to avoid this double freeing.
^ permalink raw reply
* [patch 1/1] cgroups: net_cls as module
From: akpm @ 2010-03-23 15:24 UTC (permalink / raw)
To: davem; +Cc: netdev, akpm, bblum, kamezawa.hiroyu, laijs, lizf, menage
From: Ben Blum <bblum@andrew.cmu.edu>
Allows the net_cls cgroup subsystem to be compiled as a module
This patch modifies net/sched/cls_cgroup.c to allow the net_cls subsystem
to be optionally compiled as a module instead of builtin. The
cgroup_subsys struct is moved around a bit to allow the subsys_id to be
either declared as a compile-time constant by the cgroup_subsys.h include
in cgroup.h, or, if it's a module, initialized within the struct by
cgroup_load_subsys.
Signed-off-by: Ben Blum <bblum@andrew.cmu.edu>
Acked-by: Li Zefan <lizf@cn.fujitsu.com>
Cc: Paul Menage <menage@google.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
net/sched/Kconfig | 5 ++++-
net/sched/cls_cgroup.c | 36 +++++++++++++++++++++++++++---------
2 files changed, 31 insertions(+), 10 deletions(-)
diff -puN net/sched/Kconfig~cgroups-net_cls-as-module net/sched/Kconfig
--- a/net/sched/Kconfig~cgroups-net_cls-as-module
+++ a/net/sched/Kconfig
@@ -328,13 +328,16 @@ config NET_CLS_FLOW
module will be called cls_flow.
config NET_CLS_CGROUP
- bool "Control Group Classifier"
+ tristate "Control Group Classifier"
select NET_CLS
depends on CGROUPS
---help---
Say Y here if you want to classify packets based on the control
cgroup of their process.
+ To compile this code as a module, choose M here: the
+ module will be called cls_cgroup.
+
config NET_EMATCH
bool "Extended Matches"
select NET_CLS
diff -puN net/sched/cls_cgroup.c~cgroups-net_cls-as-module net/sched/cls_cgroup.c
--- a/net/sched/cls_cgroup.c~cgroups-net_cls-as-module
+++ a/net/sched/cls_cgroup.c
@@ -24,6 +24,25 @@ struct cgroup_cls_state
u32 classid;
};
+static struct cgroup_subsys_state *cgrp_create(struct cgroup_subsys *ss,
+ struct cgroup *cgrp);
+static void cgrp_destroy(struct cgroup_subsys *ss, struct cgroup *cgrp);
+static int cgrp_populate(struct cgroup_subsys *ss, struct cgroup *cgrp);
+
+struct cgroup_subsys net_cls_subsys = {
+ .name = "net_cls",
+ .create = cgrp_create,
+ .destroy = cgrp_destroy,
+ .populate = cgrp_populate,
+#ifdef CONFIG_NET_CLS_CGROUP
+ .subsys_id = net_cls_subsys_id,
+#else
+#define net_cls_subsys_id net_cls_subsys.subsys_id
+#endif
+ .module = THIS_MODULE,
+};
+
+
static inline struct cgroup_cls_state *cgrp_cls_state(struct cgroup *cgrp)
{
return container_of(cgroup_subsys_state(cgrp, net_cls_subsys_id),
@@ -79,14 +98,6 @@ static int cgrp_populate(struct cgroup_s
return cgroup_add_files(cgrp, ss, ss_files, ARRAY_SIZE(ss_files));
}
-struct cgroup_subsys net_cls_subsys = {
- .name = "net_cls",
- .create = cgrp_create,
- .destroy = cgrp_destroy,
- .populate = cgrp_populate,
- .subsys_id = net_cls_subsys_id,
-};
-
struct cls_cgroup_head
{
u32 handle;
@@ -277,12 +288,19 @@ static struct tcf_proto_ops cls_cgroup_o
static int __init init_cgroup_cls(void)
{
- return register_tcf_proto_ops(&cls_cgroup_ops);
+ int ret = register_tcf_proto_ops(&cls_cgroup_ops);
+ if (ret)
+ return ret;
+ ret = cgroup_load_subsys(&net_cls_subsys);
+ if (ret)
+ unregister_tcf_proto_ops(&cls_cgroup_ops);
+ return ret;
}
static void __exit exit_cgroup_cls(void)
{
unregister_tcf_proto_ops(&cls_cgroup_ops);
+ cgroup_unload_subsys(&net_cls_subsys);
}
module_init(init_cgroup_cls);
_
^ permalink raw reply
* net-next: 2.6.34-rc1 regression: panic when running diagnostic on interface with IPv6
From: Tantilov, Emil S @ 2010-03-23 18:28 UTC (permalink / raw)
To: netdev@vger.kernel.org; +Cc: David Miller, Stephen Hemminger
Bisecting points to this patch:
http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=commitdiff;h=84e8b803f1e16f3a2b8b80f80a63fa2f2f8a9be6
And I confirmed that the issue goes away after reverting it.
Steps to reproduce:
1. Load the driver and configure IPv6 address.
2. Run ethtool diag:
ethtool -t eth0
3. If this doesn't brake it try again, or just do ifdown/up. Other operations on the interface will eventually panic the system:
[ 436.118773] ------------[ cut here ]------------
[ 436.124009] WARNING: at net/ipv6/ip6_fib.c:1159 fib6_del+0x44/0x39f()
[ 436.131280] Hardware name: S5520HC
[ 436.135147] Modules linked in: bnx2 e1000e ixgbe mdio e1000
[ 436.141894] Pid: 7290, comm: ethtool Not tainted 2.6.33-net-next-master-bisect #45
[ 436.150427] Call Trace:
[ 436.153230] [<ffffffff81033c41>] ? __wake_up+0x43/0x50
[ 436.159139] [<ffffffff8142728d>] ? fib6_del+0x44/0x39f
[ 436.165043] [<ffffffff81038e97>] warn_slowpath_common+0x77/0x8f
[ 436.171826] [<ffffffff81038ebe>] warn_slowpath_null+0xf/0x11
[ 436.178321] [<ffffffff8142728d>] fib6_del+0x44/0x39f
[ 436.184037] [<ffffffff81424864>] __ip6_del_rt+0x49/0x68
[ 436.190043] [<ffffffff814249d3>] ip6_del_rt+0x38/0x3a
[ 436.195855] [<ffffffff8141fe8f>] __ipv6_ifa_notify+0x141/0x17c
[ 436.202541] [<ffffffff814209bf>] addrconf_ifdown+0x1e2/0x292
[ 436.209034] [<ffffffff8142199a>] addrconf_notify+0x6e7/0x7a0
[ 436.215531] [<ffffffff814addec>] ? _raw_spin_lock_irqsave+0x11/0x19
[ 436.222730] [<ffffffff81045ac6>] ? spin_unlock_irqrestore+0x9/0xb
[ 436.229727] [<ffffffff81046266>] ? del_timer+0x72/0x80
[ 436.235644] [<ffffffff81426914>] ? fib6_age+0x0/0x6e
[ 436.241723] [<ffffffff8103e73d>] ? local_bh_enable_ip+0x9/0xb
[ 436.248639] [<ffffffff814add75>] ? _raw_spin_unlock_bh+0x12/0x14
[ 436.255880] [<ffffffff814271da>] ? fib6_run_gc+0xca/0xcf
[ 436.262297] [<ffffffff814b05c0>] notifier_call_chain+0x33/0x5b
[ 436.283900] [<ffffffff810556c5>] __raw_notifier_call_chain+0x9/0xb
[ 436.291282] [<ffffffff810556d6>] raw_notifier_call_chain+0xf/0x11
[ 436.298624] [<ffffffff813953f9>] call_netdevice_notifiers+0x16/0x18
[ 436.306172] [<ffffffff81395912>] dev_close+0x39/0x3f
[ 436.312204] [<ffffffffa00580dd>] e1000_diag_test+0xc0/0x952 [e1000e]
[ 436.319788] [<ffffffff810d4727>] ? __kmalloc+0x103/0x115
[ 436.326200] [<ffffffff81398703>] ? ethtool_self_test+0x97/0x111
[ 436.333300] [<ffffffff8139871f>] ethtool_self_test+0xb3/0x111
[ 436.340254] [<ffffffff81399928>] dev_ethtool+0x891/0xd3d
[ 436.346721] [<ffffffff813974b2>] dev_ioctl+0x4c2/0x61d
[ 436.352944] [<ffffffff810a42b0>] ? lock_page+0x11/0x29
[ 436.359167] [<ffffffff810a5865>] ? filemap_fault+0x1b4/0x308
[ 436.365973] [<ffffffff810a4391>] ? unlock_page+0xf/0x11
[ 436.372292] [<ffffffff813843e0>] sock_do_ioctl+0x3b/0x46
[ 436.378745] [<ffffffff813845f8>] sock_ioctl+0x20d/0x220
[ 436.385071] [<ffffffff810e6d0b>] vfs_ioctl+0x2a/0x9d
[ 436.391085] [<ffffffff810e7282>] do_vfs_ioctl+0x48c/0x4dd
[ 436.397599] [<ffffffff814b057e>] ? do_page_fault+0x23e/0x24d
[ 436.404466] [<ffffffff810e732a>] sys_ioctl+0x57/0x7a
[ 436.410540] [<ffffffff81002a2b>] system_call_fastpath+0x16/0x1b
[ 436.417694] ---[ end trace c17f3867d68797ab ]---
[ 583.838894] general protection fault: 0000 [#1] SMP
[ 583.844981] last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:0b:00.0/local_cpus
[ 583.854839] CPU 10
[ 583.857051] Modules linked in: bnx2 ixgbe mdio e1000 [last unloaded: e1000e]
[ 583.866400]
[ 583.868450] Pid: 7644, comm: ifconfig Tainted: G W 2.6.33-net-next-master-bisect #45 S5520HC/S5520HC
[ 583.880203] RIP: 0010:[<ffffffff81423ac0>] [<ffffffff81423ac0>] fib6_ifdown+0xb/0x26
[ 583.889810] RSP: 0018:ffff8801eb0afbe8 EFLAGS: 00010202
[ 583.896143] RAX: ffff8801ebbac000 RBX: 6b6b6b6b6b6b6b6b RCX: ffffffff81c13c60
[ 583.904517] RDX: ffffffff81c13c60 RSI: ffff8801eb0afd28 RDI: 6b6b6b6b6b6b6b6b
[ 583.912894] RBP: ffff8801eb0afbe8 R08: 0000000000000000 R09: ffff8801ae27d100
[ 583.921324] R10: ffff8801ae27cfc0 R11: ffff8801edaab2c0 R12: ffff8801eb0afc78
[ 583.921327] R13: ffffffff81c13c60 R14: ffff8801eb0afd28 R15: 0000000000000000
[ 583.921331] FS: 00007fa9c7486710(0000) GS:ffff880028340000(0000) knlGS:0000000000000000
[ 583.921334] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 583.921336] CR2: 000000377bcbd268 CR3: 00000001eb9e2000 CR4: 00000000000006e0
[ 583.921339] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 583.921342] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 583.921345] Process ifconfig (pid: 7644, threadinfo ffff8801eb0ae000, task ffff8801ed774bf0)
[ 583.921347] Stack:
[ 583.921348] ffff8801eb0afc28 ffffffff81427621 0000000000000000 ffffffff81c13c60
[ 583.921352] <0> 0000000000000000 ffff8801eb88b1f0 ffff8801eb0afc78 ffff8801ef045c78
[ 583.921355] <0> ffff8801eb0afc48 ffffffff81426cef ffff8801eb0afc48 ffff8801eb0afc78
[ 583.921359] Call Trace:
[ 583.921365] [<ffffffff81427621>] fib6_clean_node+0x39/0xa2
[ 583.921370] [<ffffffff81426cef>] fib6_walk_continue+0xa1/0x101
[ 583.921374] [<ffffffff81426da2>] fib6_walk+0x53/0x6a
[ 583.921378] [<ffffffff81426df3>] fib6_clean_tree+0x3a/0x3c
[ 583.921382] [<ffffffff814275e8>] ? fib6_clean_node+0x0/0xa2
[ 583.921386] [<ffffffff81423ab5>] ? fib6_ifdown+0x0/0x26
[ 583.921390] [<ffffffff81426e67>] fib6_clean_all+0x58/0x76
Emil
^ permalink raw reply
* RE: [Bug 15582] New: BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
From: Duyck, Alexander H @ 2010-03-23 18:32 UTC (permalink / raw)
To: David Miller, akpm@linux-foundation.org
Cc: kaber@trash.net, Kirsher, Jeffrey T, Brandeburg, Jesse,
Allan, Bruce W, Waskiewicz Jr, Peter P,
bugzilla-daemon@bugzilla.kernel.org, netdev@vger.kernel.org,
stivi@kity.pl
In-Reply-To: <20100322.210043.66718554.davem@davemloft.net>
David Miller wrote:
> From: Andrew Morton <akpm@linux-foundation.org>
> Date: Mon, 22 Mar 2010 16:14:16 -0700
>
>>
>> (switched to email. Please respond via emailed reply-to-all, not
>> via the bugzilla web interface).
>>
>> On Fri, 19 Mar 2010 12:01:10 GMT
>> bugzilla-daemon@bugzilla.kernel.org wrote:
>>
>>> http://bugzilla.kernel.org/show_bug.cgi?id=15582
>>>
>>> Summary: BUG: unable to handle kernel NULL pointer
>>> dereference at 0000000000000028
>>
>> A bug in igb or the vlan code, I guess.
>
> Hmmm, should have been fixed by:
>
> commit d1c76af9e2434fac3add561e26c61b06503de986
> Author: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Mon Mar 16 10:50:02 2009 -0700
>
> GRO: Move netpoll checks to correct location
>
>
> ...
>
> Nevermind, the backtrace signature is different for this
> one.
Actually I think this may be a bug in igb_receive_skb. My guess would be that promiscuous mode is somehow being enabled which is turning off the vlan filtering and as a result we are probably picking up vlan traffic when we have no vlans registered. The null pointer in that case would be adapter->vlgrp.
The patch below should address it. However I suspect it will get mangled by our email system here so I don't believe it will apply. I have also sent a copy of to Jeff to pull into his tree for testing and submission.
Thanks,
Alex
---
This change makes it so that vlan_gro_receive is only used if vlans have been
registered to the adapter structure. Previously we were just sending all vlan
tagged frames in via this function but this results in a null pointer
dereference when vlans are not registered.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
drivers/net/igb/igb_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
index 45a0e4f..7855f71 100644
--- a/drivers/net/igb/igb_main.c
+++ b/drivers/net/igb/igb_main.c
@@ -5110,7 +5110,7 @@ static void igb_receive_skb(struct igb_q_vector *q_vector,
{
struct igb_adapter *adapter = q_vector->adapter;
- if (vlan_tag)
+ if (vlan_tag && adapter->vlgrp)
vlan_gro_receive(&q_vector->napi, adapter->vlgrp,
vlan_tag, skb);
else
^ permalink raw reply related
* Re: [PATCH 00/12] l2tp: Introduce L2TPv3 support
From: David Miller @ 2010-03-23 18:53 UTC (permalink / raw)
To: james; +Cc: netdev
In-Reply-To: <2f9409cb1003230319u799ef2e4l583f4f667ffa0169@mail.gmail.com>
From: James Chapman <james@jchapman.plus.com>
Date: Tue, 23 Mar 2010 10:19:03 +0000
> scripts/checkpatch.pl didn't pick these up. Is there a recommended way
> to find these in the future? I'm using stg to manage these patches.
GIT warns about them when you try to apply them.
I check patches using a dry run with a script that looks
something like:
#!/bin/sh
set -x
git apply --check --whitespace=error-all $1
^ permalink raw reply
* Re: [RFC PATCH net-next 0/7 v2]IPv6:netfilter: defragment
From: YOSHIFUJI Hideaki @ 2010-03-23 18:58 UTC (permalink / raw)
To: Patrick McHardy
Cc: Shan Wei, YOSHIFUJI Hideaki, David Miller, Alexey Dobriyan,
Yasuyuki KOZAKAI, netdev@vger.kernel.org, netfilter-devel,
YOSHIFUJI Hideaki
In-Reply-To: <4BA8F75E.2040303@trash.net>
Hello.
(2010/03/24 2:16), Patrick McHardy wrote:
> YOSHIFUJI Hideaki wrote:
>> Hello.
>>
>> Sorry for my slow response.
>>
>> (2010/03/16 1:27), Patrick McHardy wrote:
>>> YOSHIFUJI Hideaki wrote:
>>>> (2010/03/11 18:16), Shan Wei wrote:
>>>>>> On the other hand, I'd even say we should NOT send
>>>>>> icmp here (at least by default) because standard routers
>>>>>> never send such packet.
>>>>>
>>>>> Yes，for routers, the patch-set does not send icmp message to
>>>>> source host. It only does on destination host with IPv6 connection
>>>>> track enable.
>>>>
>>>> Please make it optional (via parameter) at least.
>>>
>>> The ICMP messages are only sent if the packet is destined for the
>>> local host, similar to what IPv6 defrag would do if conntrack wouldn't
>>> be used. So this patch increases consistency, why should we make this
>>> optional?
>>
>> Well, in the first place, I do think conntrack should be
>> transparent as much as possible. And, I cannot find other
>> netfilter conntrack code (ipv4 or ipv6) sending icmp e.g.
>> parameter problem etc.
>
> Agreed on the transparent part, however I consider silently dropping
> packets not transparent. In fact conntrack itself should never drop
> packets except under some very special circumstances when there's
> no other choice in order to operate correctly. Dropping packets is
> supposed to be a policy decision made by the user.
Definitely right.
> In this case without conntrack, IPv6 would send an ICMPv6 message,
> so in my opinion the transparent thing to do would be to still send
> them. Of course only if reassembly is done on an end host.
Well, no. conntrack should just forward even uncompleted fragments
to next process (e.g. core ipv6 code), and then the core would send
ICMP error back. ICMP should be sent by the core ipv6 code according
to decision of itself, not according to netfilter.
> There's really no difference in sending these packets from conntrack
> compared to passing the incomplete fragments upwards to IPv6 and
> waiting for another timeout, except that its easier to implement
> consistently by generating the packets within conntrack.
It should never be sent by the decision of the netfilter because
the semantics and code paths are different in two cases.
>> As I said before, I agree that netfilter may drop packets
>> by any reasons, but I do think it should be done silently.
>> It can increment netfilter's own statistic counting etc.
>> but it should not increment the core's (especially,
>> specific) statistic counting.
>
> It really depends on what you define as "transparent".
I mean, netfilter conntrack should not either drop or modify any
packets, and it should not generate any additional packets.
>> Reassembling processes are the same. We should NOT send icmp, and
>> if ever desired, we might optionally send icmp (in other
>> module maybe).
>
> Please see above for my reasoning. There's also the matter of consistency
> between IPv4 and IPv6 conntrack.
Would you please explain more about what you mean by consistency
between IPv4 and IPv6 conntrack?
I do think it is rather different, anyway (because original packets
is to be preserved in IPv6, but not in IPv4).
--yoshfuji
^ permalink raw reply
* Reporting Bugs on This List
From: Eduardo Panisset @ 2010-03-23 19:05 UTC (permalink / raw)
To: netdev
Hi All,
I have already reported two bugs on XFRM framework since yesterday.
However my reports haven't been answered yet (I thought strange as
this list is very active) and one of my questions simply disappeared
even if its a simple plain text messages without offensive terms
neither I think any other constraint.
So I would like to know How would be the better way to report bugs on
this list ?
Thanks in advance,
Eduardo Panisset.
^ permalink raw reply
* Re: [PATCH] rps: make distributing packets fairly among all the online CPUs default
From: David Miller @ 2010-03-23 19:09 UTC (permalink / raw)
To: eric.dumazet; +Cc: xiaosuo, therbert, netdev, bhutchings
In-Reply-To: <1269349580.2983.113.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 23 Mar 2010 14:06:20 +0100
> Le mardi 23 mars 2010 à 19:58 +0800, Changli Gao a écrit :
>
>> The sysadmins you mentioned above are Linux experters, and they know
>> how to tunning the system to get the best performance, but the default
>> configuration should be for the ordinary users, who don't know Linux
>> much.
>>
>
> I strongly NACK your change at this very moment, many devices run
> without a linux expert to tune them, thanks.
Right, we're not GNOME, we don't screw knowledgable users of
our software by default.
I agree with Eric %100 on this.
^ permalink raw reply
* Re: Reporting Bugs on This List
From: Atis Elsts @ 2010-03-23 19:22 UTC (permalink / raw)
To: Eduardo Panisset; +Cc: netdev
In-Reply-To: <b7b22e81003231205v38fa8774y81da6da5278c99a2@mail.gmail.com>
You need to submit patches in a proper format, and with [PATCH] in
subject line, so they get tracked automatically.
Reading this may be helpful: http://www.kernel.org/pub/linux/docs/lkml/#s1-10
Patches to netdev also need to apply clearly to net-2.6 (right?) Linux
kernel tree.
Also, be prepared that it may take much more time than one day until
someone reviews them.
On Tue, Mar 23, 2010 at 9:05 PM, Eduardo Panisset
<eduardo.panisset@gmail.com> wrote:
> Hi All,
>
> I have already reported two bugs on XFRM framework since yesterday.
> However my reports haven't been answered yet (I thought strange as
> this list is very active) and one of my questions simply disappeared
> even if its a simple plain text messages without offensive terms
> neither I think any other constraint.
> So I would like to know How would be the better way to report bugs on
> this list ?
>
> Thanks in advance,
> Eduardo Panisset.
> --
> 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
>
--
~Atis
^ permalink raw reply
* Re: Reporting Bugs on This List
From: David Miller @ 2010-03-23 19:27 UTC (permalink / raw)
To: eduardo.panisset; +Cc: netdev
In-Reply-To: <b7b22e81003231205v38fa8774y81da6da5278c99a2@mail.gmail.com>
From: Eduardo Panisset <eduardo.panisset@gmail.com>
Date: Tue, 23 Mar 2010 16:05:59 -0300
> I have already reported two bugs on XFRM framework since yesterday.
> However my reports haven't been answered yet (I thought strange as
> this list is very active) and one of my questions simply disappeared
> even if its a simple plain text messages without offensive terms
> neither I think any other constraint.
It's incredibly unreasonable to expect immediate responses from a
group of volunteers.
Personally, it takes me over 2 hours just to make a first pass over
the day's emails in the morning. This means not even replying to
anything or reading any content seriously. That's just deleting the
excess postings I have no direct interest in.
Then I go over patches, that can take 3 hours or more.
And then, and only then, can I look at bug reports and other things
which are not new patches. And your mail falls into that category
because you didn't post a proper patch, and if you did you'd need
to properly signoff on the patch and provide a properly formed
commit message.
You just need to be patient.
^ permalink raw reply
* Re: [Bug 15582] New: BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
From: David Miller @ 2010-03-23 19:40 UTC (permalink / raw)
To: alexander.h.duyck
Cc: akpm, kaber, jeffrey.t.kirsher, jesse.brandeburg, bruce.w.allan,
peter.p.waskiewicz.jr, bugzilla-daemon, netdev, stivi
In-Reply-To: <80769D7B14936844A23C0C43D9FBCF0F254E49A854@orsmsx501.amr.corp.intel.com>
From: "Duyck, Alexander H" <alexander.h.duyck@intel.com>
Date: Tue, 23 Mar 2010 11:32:19 -0700
> The patch below should address it. However I suspect it will get
> mangled by our email system here so I don't believe it will apply.
> I have also sent a copy of to Jeff to pull into his tree for testing
> and submission.
Good spotting, thanks Alex.
I'll wait for testing and a final version via Jeff.
^ permalink raw reply
* Re: Gianfar: RX Recycle skb->len error
From: David Miller @ 2010-03-23 20:00 UTC (permalink / raw)
To: ben; +Cc: avorontsov, netdev, Sandeep.Kumar, kumar.gala
In-Reply-To: <A6A1774AFD79E346AE6D49A33CB294530DC19F4A@EX-BE-017-SFO.shared.themessagecenter.com>
From: "Ben Menchaca (ben@bigfootnetworks.com)" <ben@bigfootnetworks.com>
Date: Tue, 23 Mar 2010 07:16:58 -0700
>> There's no need to make this so complicated. Just remember the
>> value and then refer to it later, when needed.
>
> Thanks for the sanity adjustment! As suggested, then...hope to hear
> from FS soon.
Let's get this tested and with a proper commit message and
signoff so it can get applied.
Thanks!
^ permalink raw reply
* Re: Reporting Bugs on This List
From: Eduardo Panisset @ 2010-03-23 20:06 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100323.122747.172618601.davem@davemloft.net>
Okay David,
Sorry, lack me experience on what to expect and what procedures I
should follow as is the first time I'm participating on this list.
However my intention is just to contribute for the kernel stability
and development.
I will be pacient.
Thanks.
Thank you also to Atis (I will check the link you have sent).
Eduardo Panisset.
On Tue, Mar 23, 2010 at 4:27 PM, David Miller <davem@davemloft.net> wrote:
> From: Eduardo Panisset <eduardo.panisset@gmail.com>
> Date: Tue, 23 Mar 2010 16:05:59 -0300
>
>> I have already reported two bugs on XFRM framework since yesterday.
>> However my reports haven't been answered yet (I thought strange as
>> this list is very active) and one of my questions simply disappeared
>> even if its a simple plain text messages without offensive terms
>> neither I think any other constraint.
>
> It's incredibly unreasonable to expect immediate responses from a
> group of volunteers.
>
> Personally, it takes me over 2 hours just to make a first pass over
> the day's emails in the morning. This means not even replying to
> anything or reading any content seriously. That's just deleting the
> excess postings I have no direct interest in.
>
> Then I go over patches, that can take 3 hours or more.
>
> And then, and only then, can I look at bug reports and other things
> which are not new patches. And your mail falls into that category
> because you didn't post a proper patch, and if you did you'd need
> to properly signoff on the patch and provide a properly formed
> commit message.
>
> You just need to be patient.
>
^ permalink raw reply
* Re: [PATCH 1/2] cgroups: net_cls as module
From: David Miller @ 2010-03-23 20:09 UTC (permalink / raw)
To: bblum; +Cc: akpm, netdev
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ksz884x: fix return value of netdev_set_eeprom
From: David Miller @ 2010-03-23 20:09 UTC (permalink / raw)
To: JRottmann; +Cc: Tristram.Ha, netdev, linux-kernel
In-Reply-To: <4BA8CEF6.2010707@LiPPERTEmbedded.de>
From: Jens Rottmann <JRottmann@LiPPERTEmbedded.de>
Date: Tue, 23 Mar 2010 15:23:50 +0100
> ksz884x: fix return value of netdev_set_eeprom
>
> netdev_set_eeprom() confused ethtool by just returning 1 on error
> instead of a proper -EINVAL.
>
> Signed-off-by: Jens Rottmann <JRottmann@LiPPERTEmbedded.de>
Applied, thank you.
^ permalink raw reply
* Re: [RFC PATCH net-next 0/7 v2]IPv6:netfilter: defragment
From: Jozsef Kadlecsik @ 2010-03-23 20:10 UTC (permalink / raw)
To: YOSHIFUJI Hideaki
Cc: Patrick McHardy, Shan Wei, YOSHIFUJI Hideaki, David Miller,
Alexey Dobriyan, Yasuyuki KOZAKAI, netdev@vger.kernel.org,
netfilter-devel
In-Reply-To: <4BA90F72.6010404@linux-ipv6.org>
Hi,
On Wed, 24 Mar 2010, YOSHIFUJI Hideaki wrote:
> > In this case without conntrack, IPv6 would send an ICMPv6 message,
> > so in my opinion the transparent thing to do would be to still send
> > them. Of course only if reassembly is done on an end host.
>
> Well, no. conntrack should just forward even uncompleted fragments
> to next process (e.g. core ipv6 code), and then the core would send
> ICMP error back. ICMP should be sent by the core ipv6 code according
> to decision of itself, not according to netfilter.
But what state could be associated by conntrack to the uncompleted
fragments but the INVALID state? In consequence, in any sane setup, the
uncompleted fragments will be dropped silently by a filter table rule
and no ICMP error message will be sent back.
Therefore I think iff the destination of the fragments is the host
itself, then conntrack should generate an ICMP error message. But that
error message must be processed by conntrack to set its state and then
the fate of the generated packet can be decided by a rule.
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/2] be2net: handle dma mapping errors in Tx path
From: David Miller @ 2010-03-23 20:23 UTC (permalink / raw)
To: sathyap; +Cc: netdev
In-Reply-To: <20100323064112.GA3706@serverengines.com>
From: Sathya Perla <sathyap@serverengines.com>
Date: Tue, 23 Mar 2010 12:11:12 +0530
>
> Signed-off-by: Sathya Perla <sathyap@serverengines.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 2/2] be2net: fix unmap_single/page() called incorrectly in Tx compl processing
From: David Miller @ 2010-03-23 20:23 UTC (permalink / raw)
To: sathyap; +Cc: netdev
In-Reply-To: <20100323064134.GA3733@serverengines.com>
From: Sathya Perla <sathyap@serverengines.com>
Date: Tue, 23 Mar 2010 12:11:34 +0530
> The first wrb seen by tx compl processing does not have a dma handle in it.
> Currently, pci_unmap_single() is attempted on this wrb and pci_unmap_page() on the
> rest. So, pci_unmap_page() gets incorrectly called on the dma hdl of skb->data (that
> was mapped using map_single()). This patch fixes this issue.
>
> Signed-off-by: Sathya Perla <sathyap@serverengines.com>
Applied.
^ permalink raw reply
* [RFC PATCH] net: add additional lock to qdisc to increase enqueue/dequeue fairness
From: Alexander Duyck @ 2010-03-23 20:25 UTC (permalink / raw)
To: netdev
The qdisc layer shows a significant issue when you start transmitting from
multiple CPUs. The issue is that the transmit rate drops significantly, and I
believe it is due to the fact that the spinlock is shared between the 1
dequeue, and n-1 enqueue cpu threads. In order to improve this situation I am
adding one additional lock which will need to be obtained during the enqueue
portion of the path. This essentially allows sch_direct_xmit to jump to
near the head of the line when attempting to obtain the lock after
completing a transmit.
Running the script below I saw an increase from 200K packets per second to
1.07M packets per second as a result of this patch.
for j in `seq 0 15`; do
for i in `seq 0 7`; do
netperf -H <ip> -t UDP_STREAM -l 600 -N -T $i -- -m 6 &
done
done
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
include/net/sch_generic.h | 3 ++-
net/core/dev.c | 7 ++++++-
net/sched/sch_generic.c | 1 +
3 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index 67dc08e..f5088a9 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -51,7 +51,6 @@ struct Qdisc {
struct list_head list;
u32 handle;
u32 parent;
- atomic_t refcnt;
struct gnet_stats_rate_est rate_est;
int (*reshape_fail)(struct sk_buff *skb,
struct Qdisc *q);
@@ -65,6 +64,8 @@ struct Qdisc {
struct netdev_queue *dev_queue;
struct Qdisc *next_sched;
+ atomic_t refcnt;
+ spinlock_t enqueue_lock;
struct sk_buff *gso_skb;
/*
* For performance sake on SMP, we put highly modified fields at the end
diff --git a/net/core/dev.c b/net/core/dev.c
index a03aab4..8a2d508 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2006,8 +2006,10 @@ static inline int __dev_xmit_skb(struct sk_buff *skb, struct Qdisc *q,
spinlock_t *root_lock = qdisc_lock(q);
int rc;
+ spin_lock(&q->enqueue_lock);
spin_lock(root_lock);
if (unlikely(test_bit(__QDISC_STATE_DEACTIVATED, &q->state))) {
+ spin_unlock(&q->enqueue_lock);
kfree_skb(skb);
rc = NET_XMIT_DROP;
} else if ((q->flags & TCQ_F_CAN_BYPASS) && !qdisc_qlen(q) &&
@@ -2018,7 +2020,9 @@ static inline int __dev_xmit_skb(struct sk_buff *skb, struct Qdisc *q,
* xmit the skb directly.
*/
__qdisc_update_bstats(q, skb->len);
- if (sch_direct_xmit(skb, q, dev, txq, root_lock))
+ spin_unlock(&q->enqueue_lock);
+ rc = sch_direct_xmit(skb, q, dev, txq, root_lock);
+ if (rc)
__qdisc_run(q);
else
clear_bit(__QDISC_STATE_RUNNING, &q->state);
@@ -2026,6 +2030,7 @@ static inline int __dev_xmit_skb(struct sk_buff *skb, struct Qdisc *q,
rc = NET_XMIT_SUCCESS;
} else {
rc = qdisc_enqueue_root(skb, q);
+ spin_unlock(&q->enqueue_lock);
qdisc_run(q);
}
spin_unlock(root_lock);
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index 5173c1e..4b5e125 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -538,6 +538,7 @@ struct Qdisc *qdisc_alloc(struct netdev_queue *dev_queue,
sch = (struct Qdisc *) QDISC_ALIGN((unsigned long) p);
sch->padded = (char *) sch - (char *) p;
+ spin_lock_init(&sch->enqueue_lock);
INIT_LIST_HEAD(&sch->list);
skb_queue_head_init(&sch->q);
sch->ops = ops;
^ permalink raw reply related
* Re: [RFC PATCH] net: add additional lock to qdisc to increase enqueue/dequeue fairness
From: David Miller @ 2010-03-23 20:31 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: netdev
In-Reply-To: <20100323202553.21598.10754.stgit@gitlad.jf.intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Tue, 23 Mar 2010 13:25:53 -0700
> The qdisc layer shows a significant issue when you start transmitting from
> multiple CPUs.
Why are you hitting any central qdisc lock on a multiqueue
configuration?
^ permalink raw reply
* Re: [RFC PATCH] net: add additional lock to qdisc to increase enqueue/dequeue fairness
From: Rick Jones @ 2010-03-23 20:40 UTC (permalink / raw)
To: Alexander Duyck; +Cc: netdev
In-Reply-To: <20100323202553.21598.10754.stgit@gitlad.jf.intel.com>
Alexander Duyck wrote:
> The qdisc layer shows a significant issue when you start transmitting from
> multiple CPUs. The issue is that the transmit rate drops significantly, and I
> believe it is due to the fact that the spinlock is shared between the 1
> dequeue, and n-1 enqueue cpu threads. In order to improve this situation I am
> adding one additional lock which will need to be obtained during the enqueue
> portion of the path. This essentially allows sch_direct_xmit to jump to
> near the head of the line when attempting to obtain the lock after
> completing a transmit.
>
> Running the script below I saw an increase from 200K packets per second to
> 1.07M packets per second as a result of this patch.
>
> for j in `seq 0 15`; do
> for i in `seq 0 7`; do
> netperf -H <ip> -t UDP_STREAM -l 600 -N -T $i -- -m 6 &
> done
> done
Wow - someone is using the no control connection mode in netperf :) Or were you
actually trying to get the test-specific -N option to control whether or not
netperf "connects" the UDP socket?
rick jones
^ permalink raw reply
* Re: [RFC PATCH] net: add additional lock to qdisc to increase enqueue/dequeue fairness
From: Eric Dumazet @ 2010-03-23 20:54 UTC (permalink / raw)
To: Alexander Duyck; +Cc: netdev
In-Reply-To: <20100323202553.21598.10754.stgit@gitlad.jf.intel.com>
Le mardi 23 mars 2010 à 13:25 -0700, Alexander Duyck a écrit :
> The qdisc layer shows a significant issue when you start transmitting from
> multiple CPUs. The issue is that the transmit rate drops significantly, and I
> believe it is due to the fact that the spinlock is shared between the 1
> dequeue, and n-1 enqueue cpu threads. In order to improve this situation I am
> adding one additional lock which will need to be obtained during the enqueue
> portion of the path. This essentially allows sch_direct_xmit to jump to
> near the head of the line when attempting to obtain the lock after
> completing a transmit.
>
> Running the script below I saw an increase from 200K packets per second to
> 1.07M packets per second as a result of this patch.
>
> for j in `seq 0 15`; do
> for i in `seq 0 7`; do
> netperf -H <ip> -t UDP_STREAM -l 600 -N -T $i -- -m 6 &
> done
> done
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> ---
>
Hi Alexander
Thats a pretty good topic :)
So to speedup a pathological case (dozen of cpus all sending to same
queue), you suggest adding a spin_lock to fast path, slowing down normal
cases ?
Quite frankly, the real problem in this case is not the reduced
throughput, but fact that one cpu can stay a long time doing the xmits
to device, of skb queued by other cpus. This can hurt latencies a lot,
for real time threads for example...
I wonder if ticket spinlocks are not the problem. Maybe we want a
variant of spinlocks, so that cpu doing transmits can get the lock
before other cpus...
^ permalink raw reply
* Re: [RFC PATCH] net: add additional lock to qdisc to increase enqueue/dequeue fairness
From: Eric Dumazet @ 2010-03-23 21:18 UTC (permalink / raw)
To: Alexander Duyck; +Cc: netdev
In-Reply-To: <1269377667.2915.25.camel@edumazet-laptop>
Le mardi 23 mars 2010 à 21:54 +0100, Eric Dumazet a écrit :
> I wonder if ticket spinlocks are not the problem. Maybe we want a
> variant of spinlocks, so that cpu doing transmits can get the lock
> before other cpus...
Something like this portable implementation :
struct spinprio {
spinlock_t lock;
int highprio_cnt;
};
void spinprio_lock(struct spinprio *l)
{
while (1) {
spin_lock(&l->lock);
if (!l->highprio_cnt)
break;
spin_unlock(&l->lock);
cpu_relax();
}
}
void spinprio_unlock(struct spinprio *l)
{
spin_unlock(&l->lock);
}
void spinprio_relock(struct spinprio *l)
{
l->highprio_cnt = 1;
spin_lock(&l->lock);
l->highprio_cnt = 0;
}
We would have to use spinprio_unlock()/spinprio_relock() in
sch_direct_xmit()
^ permalink raw reply
* Re: [RFC PATCH] net: add additional lock to qdisc to increase enqueue/dequeue fairness
From: David Miller @ 2010-03-23 21:45 UTC (permalink / raw)
To: eric.dumazet; +Cc: alexander.h.duyck, netdev
In-Reply-To: <1269377667.2915.25.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 23 Mar 2010 21:54:27 +0100
> Quite frankly, the real problem in this case is not the reduced
> throughput, but fact that one cpu can stay a long time doing the xmits
> to device, of skb queued by other cpus. This can hurt latencies a lot,
> for real time threads for example...
>
> I wonder if ticket spinlocks are not the problem. Maybe we want a
> variant of spinlocks, so that cpu doing transmits can get the lock
> before other cpus...
I want to note that things operate the way they do now
intentionally.
Herbert Xu and Jamal Hadi Salim were active in this area
about 4 years ago.
^ 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