* 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: [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
* 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: [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
* 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: [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
* 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
* [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
* 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
* 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: [RFC PATCH net-next 0/7 v2]IPv6:netfilter: defragment
From: YOSHIFUJI Hideaki @ 2010-03-23 16:28 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: <4B9E5FEC.9010002@trash.net>
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.
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.
Reassembling processes are the same. We should NOT send icmp, and
if ever desired, we might optionally send icmp (in other
module maybe).
Regards,
--yoshfuji
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Fix locking in flush_backlog
From: Eric Dumazet @ 2010-03-23 16:14 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <65634d661003230856v3d1737dehf64a883c1e785333@mail.gmail.com>
Le mardi 23 mars 2010 à 08:56 -0700, Tom Herbert a écrit :
> Eric,
>
> I'm not sure what you're asking. Do you just want to add spinlocks in
> the flush_backlog function without changing the mechanism to call the
> function on each CPU, or keep flush_backlog but call it from
> netdev_run_todo for each queue?
>
keep flush_backlog() so that its role is obvious and indentation level
not too big.
static void flush_backlog(int cpu)
{
struct softnet_data *queue = &per_cpu(softnet_data, cpu);
struct sk_buff *skb, *tmp;
unsigned long flags;
spin_lock_irqsave(&queue->input_pkt_queue.lock, flags);
skb_queue_walk_safe(&queue->input_pkt_queue, skb, tmp)
if (skb->dev == dev) {
__skb_unlink(skb, &queue->input_pkt_queue);
kfree_skb(skb);
}
spin_unlock_irqrestore(&queue->input_pkt_queue.lock, flags);
}
And call it from netdev_run_todo() :
for_each_online_cpu(i)
flush_backlog(i);
This adds two lines to netdev_run_todo() only.
Thanks
^ permalink raw reply
* Re: [PATCH] Fix locking in flush_backlog
From: Tom Herbert @ 2010-03-23 15:56 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, netdev
In-Reply-To: <1269325757.3043.11.camel@edumazet-laptop>
On Mon, Mar 22, 2010 at 11:29 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le lundi 22 mars 2010 à 23:04 -0700, Tom Herbert a écrit :
>> Need to take spinlocks when dequeuing from input_pkt_queue in
>> flush_backlog. Also, with the spinlock the backlog queues can
>> be flushed directly from netdev_run_todo.
>>
>> Signed-off-by: Tom Herbert <therbert@google.com>
>> ---
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index a03aab4..e7db656 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -2765,20 +2765,6 @@ int netif_receive_skb(struct sk_buff *skb)
>> }
>> EXPORT_SYMBOL(netif_receive_skb);
>>
>> -/* Network device is going away, flush any packets still pending */
>> -static void flush_backlog(void *arg)
>> -{
>> - struct net_device *dev = arg;
>> - struct softnet_data *queue = &__get_cpu_var(softnet_data);
>> - struct sk_buff *skb, *tmp;
>> -
>> - skb_queue_walk_safe(&queue->input_pkt_queue, skb, tmp)
>> - if (skb->dev == dev) {
>> - __skb_unlink(skb, &queue->input_pkt_queue);
>> - kfree_skb(skb);
>> - }
>> -}
>> -
>> static int napi_gro_complete(struct sk_buff *skb)
>> {
>> struct packet_type *ptype;
>> @@ -5545,6 +5531,7 @@ void netdev_run_todo(void)
>> while (!list_empty(&list)) {
>> struct net_device *dev
>> = list_first_entry(&list, struct net_device, todo_list);
>> + int i;
>> list_del(&dev->todo_list);
>>
>> if (unlikely(dev->reg_state != NETREG_UNREGISTERING)) {
>> @@ -5556,7 +5543,22 @@ void netdev_run_todo(void)
>>
>> dev->reg_state = NETREG_UNREGISTERED;
>>
>> - on_each_cpu(flush_backlog, dev, 1);
>> + /* Flush backlog queues of any pending packets */
>> + for_each_online_cpu(i) {
>> + struct softnet_data *queue = &per_cpu(softnet_data, i);
>> + struct sk_buff *skb, *tmp;
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(&queue->input_pkt_queue.lock, flags);
>> + skb_queue_walk_safe(&queue->input_pkt_queue, skb, tmp)
>> + if (skb->dev == dev) {
>> + __skb_unlink(skb,
>> + &queue->input_pkt_queue);
>> + kfree_skb(skb);
>> + }
>> + spin_unlock_irqrestore(&queue->input_pkt_queue.lock,
>> + flags);
>> + }
>>
>> netdev_wait_allrefs(dev);
>>
>
> OK (this is a patch for net-next-2.6)
>
> Could you please keep the function, to ease netdev_run_todo() review ?
>
Eric,
I'm not sure what you're asking. Do you just want to add spinlocks in
the flush_backlog function without changing the mechanism to call the
function on each CPU, or keep flush_backlog but call it from
netdev_run_todo for each queue?
Tom
^ permalink raw reply
* Re: [RFC PATCH net-next 0/7 v2]IPv6:netfilter: defragment
From: Patrick McHardy @ 2010-03-23 15:05 UTC (permalink / raw)
To: Shan Wei
Cc: YOSHIFUJI Hideaki, David Miller, Alexey Dobriyan,
Yasuyuki KOZAKAI, netdev@vger.kernel.org, netfilter-devel,
yoshfuji@linux-ipv6.org >> YOSHIFUJI Hideaki
In-Reply-To: <4B98B4FC.50904@cn.fujitsu.com>
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.
>
The nf-next tree is open again, now would be a good time to resubmit
these patches.
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" 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] ksz884x: fix return value of netdev_set_eeprom
From: Jens Rottmann @ 2010-03-23 14:23 UTC (permalink / raw)
To: David S. Miller; +Cc: Tristram Ha, netdev, linux-kernel
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>
---
--- linux-2.6.34-rc2-git1/drivers/net/ksz884x.c
+++ return_value_fixed/drivers/net/ksz884x.c
@@ -6322,7 +6322,7 @@ static int netdev_set_eeprom(struct net_
int len;
if (eeprom->magic != EEPROM_MAGIC)
- return 1;
+ return -EINVAL;
len = (eeprom->offset + eeprom->len + 1) / 2;
for (i = eeprom->offset / 2; i < len; i++)
_
^ permalink raw reply
* RE: Gianfar: RX Recycle skb->len error
From: Ben Menchaca (ben@bigfootnetworks.com) @ 2010-03-23 14:16 UTC (permalink / raw)
To: David Miller
Cc: avorontsov@ru.mvista.com, netdev@vger.kernel.org,
Sandeep.Kumar@freescale.com, kumar.gala@freescale.com
In-Reply-To: <20100322.203053.37576243.davem@davemloft.net>
> 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.
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index b671555..669de02 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -2393,6 +2393,7 @@ struct sk_buff * gfar_new_skb(struct net_device *dev)
* as many bytes as needed to align the data properly
*/
skb_reserve(skb, alignamount);
+ GFAR_CB(skb)->alignamount = alignamount;
return skb;
}
@@ -2533,13 +2534,13 @@ int gfar_clean_rx_ring(struct gfar_priv_rx_q *rx_queue, int rx_work_limit)
newskb = skb;
else if (skb) {
/*
- * We need to reset ->data to what it
+ * We need to un-reserve() the skb to what it
* was before gfar_new_skb() re-aligned
* it to an RXBUF_ALIGNMENT boundary
* before we put the skb back on the
* recycle list.
*/
- skb->data = skb->head + NET_SKB_PAD;
+ skb_reserve(skb, -GFAR_CB(skb)->alignamount);
__skb_queue_head(&priv->rx_recycle, skb);
}
} else {
diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
index 3d72dc4..3ae2c77 100644
--- a/drivers/net/gianfar.h
+++ b/drivers/net/gianfar.h
@@ -566,6 +566,12 @@ struct rxfcb {
u16 vlctl; /* VLAN control word */
};
+struct gfar_skb_cb {
+ int alignamount;
+};
+
+#define GFAR_CB(skb) ((struct gfar_skb_cb *)((skb)->cb))
+
struct rmon_mib
{
u32 tr64; /* 0x.680 - Transmit and Receive 64-byte Frame Counter */
^ permalink raw reply related
* Re: [PATCH] rps: make distributing packets fairly among all the online CPUs default
From: Andi Kleen @ 2010-03-23 14:05 UTC (permalink / raw)
To: Changli Gao
Cc: Eric Dumazet, David S. Miller, Tom Herbert, netdev, Ben Hutchings
In-Reply-To: <412e6f7f1003230303l69fc142ey1581fff4c3e749be@mail.gmail.com>
Changli Gao <xiaosuo@gmail.com> writes:
>
> I do think distributing packets fairly among all the online CPUs will
> helps most of users. I remember the smp_affinity of IRQ is the
> online_cpu_mask be default.
The established wisdom is that most apps prefer locality.
The cost of data transfer between CPUs is worse than the
overhead of processing the packet header in the stack.
That's why no system does interrupt RR by default anymore.
Besides if you do such a change you would need extensive benchmarking
to verify that it's a good idea.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* [BUG] XFRM IS NOT UPDATING ETH TYPE FIELD FOR INNER PACKET ON ETH HEADER
From: Eduardo Panisset @ 2010-03-23 13:22 UTC (permalink / raw)
To: netdev
Hi,
Before doing this change wireshark was showing the inner packet as
"malformed" as it uses the ethernet's type field to classify the L3
packets as IPv6, IPv4 and so on.
The problem is when the inner packet is reinserted into Linux stack
and the ethernet header keeps holding on its type field a value for
the protocol of outer packet.
Below my correction on file net/xfrm/xfrm_input.c, function xfrm_prepare_input:
...
skb->protocol = inner_mode->afinfo->eth_proto; // existing code
eth_hdr(skb)->h_proto = skb->protocol; // my change, adding this line
...
Regards,
Eduardo Panisset.
^ permalink raw reply
* Re: [PATCH] rps: make distributing packets fairly among all the online CPUs default
From: Eric Dumazet @ 2010-03-23 13:06 UTC (permalink / raw)
To: Changli Gao; +Cc: David S. Miller, Tom Herbert, netdev, Ben Hutchings
In-Reply-To: <412e6f7f1003230458o459b9e45i7327c5330c43e152@mail.gmail.com>
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.
Ordinary users dont need RPS magic in 2.6.35.
Maybe in 2.6.38+ we can reconsider this, if RPS deployment happens to be
successful, thanks to experts doing their job and reports.
^ permalink raw reply
* Re: [RFC Patch 1/3] netpoll: add generic support for bridge and bonding devices
From: Jeff Moyer @ 2010-03-23 12:11 UTC (permalink / raw)
To: Matt Mackall
Cc: Amerigo Wang, linux-kernel, netdev, bridge, Andy Gospodarek,
Neil Horman, Stephen Hemminger, bonding-devel, Jay Vosburgh,
David Miller
In-Reply-To: <1269297081.3552.19.camel@calx>
Matt Mackall <mpm@selenic.com> writes:
> On Mon, 2010-03-22 at 04:17 -0400, Amerigo Wang wrote:
>> This whole patchset is for adding netpoll support to bridge and bonding
>> devices. I already tested it for bridge, bonding, bridge over bonding,
>> and bonding over bridge. It looks fine now.
>
> Ages ago, Jeff Moyer took a run at this, added him to the cc: on the off
> chance he still cares.
I'll take a look at it in a bit. For now, here is the link to my
original post on this for Amerigo's reading pleasure:
http://lkml.indiana.edu/hypermail/linux/kernel/0507.0/0206.html
Cheers,
Jeff
^ permalink raw reply
* Does Realtek RTL8110S and RTL8100C work ?
From: Markus Feldmann @ 2010-03-23 12:09 UTC (permalink / raw)
To: netdev
Hi All,
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?
regards Markus
^ permalink raw reply
* Re: [PATCH] rps: make distributing packets fairly among all the online CPUs default
From: Changli Gao @ 2010-03-23 11:58 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, Tom Herbert, netdev, Ben Hutchings
In-Reply-To: <1269344306.2983.16.camel@edumazet-laptop>
On Tue, Mar 23, 2010 at 7:38 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mardi 23 mars 2010 à 18:03 +0800, Changli Gao a écrit :
>
>
> I know _many_ applications that perform better when all network IRQS are
> directed to one CPU only. Single threaded UDP server for example, with
> fast answer, or routers, or ...
Yea, single threaded applicatons can't get much from RPS, but
multi-threaded applications such as apache do. And more and more
applications are programmed with the assumption there are more than
one CPUs/Cores.
>
> Many sysadmins tuned their machine to meet this requirement. Installing
> 2.6.35, if RPS enabled by default will make them unhappy, especially if
> CONFIG_SYSFS is not set, since they wont be able to change RPS settings.
>
> If RPS was good for all workloads, activating it would make sense, but
> this is not the case.
>
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.
--
Regards，
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [net-next-2.6 PATCH] ipoib: remove addrlen check for mc addresses
From: Moni Shoua @ 2010-03-23 11:55 UTC (permalink / raw)
To: Moni Shoua
Cc: Eli Cohen, Or Gerlitz, Jiri Pirko, netdev, davem, linux-rdma,
jgunthorpe
In-Reply-To: <4BA8A9BD.9030508@Voltaire.COM>
> maybe your'e looking for this one
> http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=commit;h=32a806c194ea112cfab00f558482dd97bee5e44e
This is the link to the related patch of course but it also tells you which tree to clone
^ permalink raw reply
* Hi
From: Santhapuri, Damodar @ 2010-03-23 11:55 UTC (permalink / raw)
To: netdev@vger.kernel.org
Subscribe me on it
^ permalink raw reply
* Re: [net-next-2.6 PATCH] ipoib: remove addrlen check for mc addresses
From: Moni Shoua @ 2010-03-23 11:45 UTC (permalink / raw)
To: Eli Cohen; +Cc: Or Gerlitz, Jiri Pirko, netdev, davem, linux-rdma, jgunthorpe
In-Reply-To: <20100323113436.GD12224@mtldesk030.lab.mtl.com>
Eli Cohen wrote:
> On Tue, Mar 23, 2010 at 12:34:13PM +0200, Or Gerlitz wrote:
>> basically, as the subject line suggests, it should be in Dave's net-next tree
>>
> I just need to clone this tree and need the url. Can you give it to me
> from .git/config?
> Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
maybe your'e looking for this one
http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=commit;h=32a806c194ea112cfab00f558482dd97bee5e44e
^ 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