* bridge: Use consistent NF_DROP returns in nf_pre_routing
From: Herbert Xu @ 2010-12-10 3:38 UTC (permalink / raw)
To: David S. Miller, netdev
Hi:
bridge: Use consistent NF_DROP returns in nf_pre_routing
The nf_pre_routing functions in bridging have collected two
distinct ways of returning NF_DROP over the years, inline and
via goto. There is no reason for preferring either one.
So this patch arbitrarily picks the inline variant and converts
the all the gotos.
Also removes a redundant comment.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index 865fd76..3fb35fb 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -566,26 +566,26 @@ static unsigned int br_nf_pre_routing_ipv6(unsigned int hook,
u32 pkt_len;
if (skb->len < sizeof(struct ipv6hdr))
- goto inhdr_error;
+ return NF_DROP;
if (!pskb_may_pull(skb, sizeof(struct ipv6hdr)))
- goto inhdr_error;
+ return NF_DROP;
hdr = ipv6_hdr(skb);
if (hdr->version != 6)
- goto inhdr_error;
+ return NF_DROP;
pkt_len = ntohs(hdr->payload_len);
if (pkt_len || hdr->nexthdr != NEXTHDR_HOP) {
if (pkt_len + sizeof(struct ipv6hdr) > skb->len)
- goto inhdr_error;
+ return NF_DROP;
if (pskb_trim_rcsum(skb, pkt_len + sizeof(struct ipv6hdr)))
- goto inhdr_error;
+ return NF_DROP;
}
if (hdr->nexthdr == NEXTHDR_HOP && check_hbh_len(skb))
- goto inhdr_error;
+ return NF_DROP;
nf_bridge_put(skb->nf_bridge);
if (!nf_bridge_alloc(skb))
@@ -598,9 +598,6 @@ static unsigned int br_nf_pre_routing_ipv6(unsigned int hook,
br_nf_pre_routing_finish_ipv6);
return NF_STOLEN;
-
-inhdr_error:
- return NF_DROP;
}
/* Direct IPv6 traffic to br_nf_pre_routing_ipv6.
@@ -619,11 +616,11 @@ static unsigned int br_nf_pre_routing(unsigned int hook, struct sk_buff *skb,
__u32 len = nf_bridge_encap_header_len(skb);
if (unlikely(!pskb_may_pull(skb, len)))
- goto out;
+ return NF_DROP;
p = br_port_get_rcu(in);
if (p == NULL)
- goto out;
+ return NF_DROP;
br = p->br;
if (skb->protocol == htons(ETH_P_IPV6) || IS_VLAN_IPV6(skb) ||
@@ -645,8 +642,7 @@ static unsigned int br_nf_pre_routing(unsigned int hook, struct sk_buff *skb,
nf_bridge_pull_encap_header_rcsum(skb);
if (br_parse_ip_options(skb))
- /* Drop invalid packet */
- goto out;
+ return NF_DROP;
nf_bridge_put(skb->nf_bridge);
if (!nf_bridge_alloc(skb))
@@ -660,9 +656,6 @@ static unsigned int br_nf_pre_routing(unsigned int hook, struct sk_buff *skb,
br_nf_pre_routing_finish);
return NF_STOLEN;
-
-out:
- return NF_DROP;
}
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* Re: [PATCH] Sysctl interface to UNIX_INFLIGHT_TRIGGER_GC v.2
From: Shan Wei @ 2010-12-10 3:45 UTC (permalink / raw)
To: pavel; +Cc: netdev
In-Reply-To: <4D011136.8030404@pavlinux.ru>
Pavel Vasilyev wrote, at 12/10/2010 01:26 AM:
> Sysctl interface to UNIX_INFLIGHT_TRIGGER_GC.
> IMHO convenient for testing.
>
>+inflight_trigger_gc - INTEGER
>+ The maximal number of inflight sockets for force garbage collect.
>+
>+ Default: 16000
1) For lower payload and enough memory, it's not necessary to force garbage collection.
So set it to 0, disable gc.
2) Copy your patch to the mail, for other guys to review it.
--
Best Regards
-----
Shan Wei
^ permalink raw reply
* Re: [PATCH] fix hostap registration order
From: David Miller @ 2010-12-10 3:53 UTC (permalink / raw)
To: mroos; +Cc: netdev, j, linux-wireless
In-Reply-To: <alpine.SOC.1.00.1012100020110.26229@math.ut.ee>
From: Meelis Roos <mroos@linux.ee>
Date: Fri, 10 Dec 2010 01:19:23 +0200 (EET)
> In 2.6.37-rc4, hostap_pci init gives a WARNING with backtrace telling
> that netif_stop_queue is called before register_netdev. Fix it by moving
> this call after register_netdev. Removes the warning and seems to work,
> but why is the call to netif_stop_queue needed at all after
> register_netdev?
>
> Signed-off-by: Meelis Roos <mroos@linux.ee>
It should simply not touch the queue state at all at this point.
Your change would add a race. At the moment the device is registered
it can be brought up, and then your code will eroneously modify
the queue state.
^ permalink raw reply
* Re: [PATCH] Fix 2.6.34-rc1 regression in disable_ipv6 support
From: Stephen Hemminger @ 2010-12-10 4:02 UTC (permalink / raw)
To: Brian Haley
Cc: Eric W. Biederman, David Miller, netdev, Mahesh Kelkar,
Lorenzo Colitti, YOSHIFUJI Hideaki, stable
In-Reply-To: <4D00F58A.2050307@hp.com>
On Thu, 09 Dec 2010 10:28:10 -0500
Brian Haley <brian.haley@hp.com> wrote:
> On 12/08/2010 11:16 PM, Eric W. Biederman wrote:
> > Finding the real bug is beyond me right now, but fixing the regression
> > in disable_ipv6 is simple. We can just delete ::1 when we bring down
> > the loopback interface, and it will be restored automatically when we
> > bring the loopback interface back up.
>
> Hi Eric,
>
> This would work as well, same check, different way.
>
> Signed-off-by: Brian Haley <brian.haley@hp.com>
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 23cc8e1..5d16a9d 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -2728,7 +2728,8 @@ static int addrconf_ifdown(struct net_device *dev, int how)
> and not link-local, then retain it. */
> if (!how &&
> (ifa->flags&IFA_F_PERMANENT) &&
> - !(ipv6_addr_type(&ifa->addr) & IPV6_ADDR_LINKLOCAL)) {
> + !(ipv6_addr_type(&ifa->addr) &
> + (IPV6_ADDR_LINKLOCAL|IPV6_ADDR_LOOPBACK))) {
> list_move_tail(&ifa->if_list, &keep_list);
>
> /* If not doing DAD on this address, just keep it. */
This patch is cleaner but still fails for the non ::1 address case.
# ip addr add 2000:db8::1/64 dev lo
# ping6 ::1 -- works
# ping6 2000:db8::1 --works
# ip li set dev lo down
# ping6 ::1 -- does not work (expected)
# ping6 2000:db8::1 -- ditto
# ip il set dev lo up
# ping6 ::1 -- works (good)
# ping6 2000:db8::1 -- fails (network unreachable)
Looks like connected route is not getting restored correctly, probably
because loopback has NOARP flag set.
The problem may not be true for just loopback, it may also apply to
tunnels.
^ permalink raw reply
* Re: [PATCH] Link directly to the archive files rather than using search paths.
From: Stephen Hemminger @ 2010-12-10 4:03 UTC (permalink / raw)
To: Diego Elio Pettenò; +Cc: netdev, Daniel Kurtz, Mike Frysinger
In-Reply-To: <1291946520.4146.2.camel@yamato.home.flameeyes.eu>
On Fri, 10 Dec 2010 03:02:00 +0100
Diego Elio Pettenò <flameeyes@gmail.com> wrote:
> Il giorno gio, 09/12/2010 alle 17.56 -0800, Stephen Hemminger ha
> scritto:
> > Please be more clear in your subject, yes I can tell this is for
> > iproute utilities but others may not.
>
> Sorry, I should have used --subject-prefix, will make sure to set it
> into the configuration file for the future.
>
> > When refering to "previous code" either reply to the original
> > message thread or provide a link to the changes.
>
> Uhm, the "previous code" in here is "the Makefile as it was before the
> patch", want me to rephrase and resend?
>
No. just wanted to make sure. I take any fix as long as it is clear
what it is doing.
--
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: optimize INET input path further
From: David Miller @ 2010-12-10 4:07 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1291179847.2856.452.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 01 Dec 2010 06:04:07 +0100
> Followup of commit b178bb3dfc30 (net: reorder struct sock fields)
>
> Optimize INET input path a bit further, by :
>
> 1) moving sk_refcnt close to sk_lock.
>
> This reduces number of dirtied cache lines by one on 64bit arches (and
> 64 bytes cache line size).
>
> 2) moving inet_daddr & inet_rcv_saddr at the beginning of sk
>
> (same cache line than hash / family / bound_dev_if / nulls_node)
>
> This reduces number of accessed cache lines in lookups by one, and dont
> increase size of inet and timewait socks.
> inet and tw sockets now share same place-holder for these fields.
...
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH v3] Net-ethtool : Allow ethtool to set interface in loopback mode.
From: David Miller @ 2010-12-10 4:11 UTC (permalink / raw)
To: bhutchings; +Cc: maheshb, netdev, chavey
In-Reply-To: <1291234623.3170.17.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 01 Dec 2010 20:17:03 +0000
> On Wed, 2010-12-01 at 12:14 -0800, Mahesh Bandewar wrote:
>> This patch enables ethtool to set the loopback mode on a given
>> interface. By configuring the interface in loopback mode in conjunction
>> with a policy route / rule, a userland application can stress the egress /
>> ingress path exposing the flows of the change in progress and potentially
>> help developer(s) understand the impact of those changes without even
>> sending a packet out on the network.
>>
>> Following set of commands illustrates one such example -
>> a) ip -4 addr add 192.168.1.1/24 dev eth1
>> b) ip -4 rule add from all iif eth1 lookup 250
>> c) ip -4 route add local 0/0 dev lo proto kernel scope host table 250
>> d) arp -Ds 192.168.1.100 eth1
>> e) arp -Ds 192.168.1.200 eth1
>> f) sysctl -w net.ipv4.ip_nonlocal_bind=1
>> g) sysctl -w net.ipv4.conf.all.accept_local=1
>> # Assuming that the machine has 8 cores
>> h) taskset 000f netserver -L 192.168.1.200
>> i) taskset 00f0 netperf -t TCP_CRR -L 192.168.1.100 -H 192.168.1.200 -l 30
>>
>> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
> [...]
> Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
This patch doesn't apply, it has been corrupted by Mahesh's email
client.
Mahesh, please correct this problem and resubmit.
^ permalink raw reply
* Re: [PATCH 0/2] New jhash function
From: David Miller @ 2010-12-10 4:19 UTC (permalink / raw)
To: rusty; +Cc: kadlec, linux-kernel, netdev, netfilter-devel, torvalds
In-Reply-To: <201012090753.46050.rusty@rustcorp.com.au>
From: Rusty Russell <rusty@rustcorp.com.au>
Date: Thu, 9 Dec 2010 07:53:45 +1030
> On Thu, 9 Dec 2010 03:39:54 am David Miller wrote:
>> From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
>> Date: Fri, 3 Dec 2010 13:38:59 +0100
>>
>> > The current jhash.h implements the lookup2() hash function by Bob Jenkins.
>> > However, lookup2() is outdated as Bob wrote a new hash function called
>> > lookup3(). There is a longer comparison of those two and other hash
>> > functions at http://burtleburtle.net/bob/hash/doobs.html.
>> >
>> > Please consider applying the following patches.
>>
>> Patch #1 is already in the net-next-2.6 tree, and as long as there are
>> no major objections to the general crowd (including Rusty et al.) I am
>> happy to put patch #2 into my tree as well.
>>
>> Rusty, does the current version of patch #2 look good to you?
>
> Yes, 2/2 good. Thanks Jozsef!
>
> Acked-by: Rusty Russell <rusty@rustcorp.com.au>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH] xfrm: Fix xfrm_state_migrate leak
From: David Miller @ 2010-12-10 4:36 UTC (permalink / raw)
To: herbert; +Cc: steffen.klassert, thomas.egerer, netdev
In-Reply-To: <20101207093157.GA4845@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 7 Dec 2010 17:31:57 +0800
> On Tue, Dec 07, 2010 at 10:28:56AM +0100, Steffen Klassert wrote:
>> From: Thomas Egerer <thomas.egerer@secunet.com>
>>
>> xfrm_state_migrate calls kfree instead of xfrm_state_put to free
>> a failed state. According to git commit 553f9118 this can cause
>> memory leaks.
>>
>> Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
>> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
>
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> Good catch. Thanks!
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] IP checksuming doesn't work on GE0301 option cards
From: David Miller @ 2010-12-10 4:43 UTC (permalink / raw)
To: tsbogend; +Cc: netdev, j.dumon
In-Reply-To: <20101208082152.407022397DD@solo.franken.de>
From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Date: Wed, 8 Dec 2010 09:21:52 +0100 (CET)
> There is definitly a problem, that some option cards send up broken
> IP pakets leading to corrupted IP packets. These corruptions aren't
> detected, because the driver claims that the packets are already
> checksummed. This change removes the CHECKSUM_UNNECESSARY option
> and let IP detect broken data.
>
> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next-2.6] filter: use size of fetched data in __load_pointer()
From: David Miller @ 2010-12-10 4:46 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1291796775.2883.21.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 08 Dec 2010 09:26:15 +0100
> __load_pointer() checks data we fetch from skb is included in head
> portion, but assumes we fetch one byte, instead of up to four.
>
> This wont crash because we have extra bytes (struct skb_shared_info)
> after head, but this can read uninitialized bytes.
>
> Fix this using size of the data (1, 2, 4 bytes) in the test.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
I'll apply this, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next 1/4] bnx2x: LSO code was broken on BE platforms
From: David Miller @ 2010-12-10 4:50 UTC (permalink / raw)
To: vladz; +Cc: netdev, eilong
In-Reply-To: <1291808589.30114.65.camel@lb-tlvb-vladz>
From: "Vladislav Zolotarov" <vladz@broadcom.com>
Date: Wed, 8 Dec 2010 13:43:09 +0200
> Make the LSO code work on BE platforms: parsing_data field of
> a parsing BD (PBD) for 57712 was improperly composed which made FW read wrong
> values for TCP header's length and offset and, as a result, the corresponding
> PCI device was performing bad DMA reads triggering EEH.
>
> Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/4] bnx2x: Use dma_alloc_coherent() semantics for ILT memory allocation
From: David Miller @ 2010-12-10 4:50 UTC (permalink / raw)
To: vladz; +Cc: netdev, eilong
In-Reply-To: <1291808598.30114.66.camel@lb-tlvb-vladz>
From: "Vladislav Zolotarov" <vladz@broadcom.com>
Date: Wed, 8 Dec 2010 13:43:17 +0200
> Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 3/4] bnx2x: Fixed a compilation warning
From: David Miller @ 2010-12-10 4:50 UTC (permalink / raw)
To: vladz; +Cc: netdev, eilong
In-Reply-To: <1291808609.30114.67.camel@lb-tlvb-vladz>
From: "Vladislav Zolotarov" <vladz@broadcom.com>
Date: Wed, 8 Dec 2010 13:43:29 +0200
> bnx2x_src_init_t2() is used only when BCM_CNIC is defined.
> So, to avoid a compilation warning, we won't define it unless
> BCM_CNIC is defined.
>
> Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 4/4] bnx2x: Update version number and a date.
From: David Miller @ 2010-12-10 4:50 UTC (permalink / raw)
To: vladz; +Cc: netdev, eilong
In-Reply-To: <1291808617.30114.68.camel@lb-tlvb-vladz>
From: "Vladislav Zolotarov" <vladz@broadcom.com>
Date: Wed, 8 Dec 2010 13:43:37 +0200
> Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH 0/7] e1000e: cleanup
From: Kirsher, Jeffrey T @ 2010-12-10 5:20 UTC (permalink / raw)
To: asbjorn@asbjorn.biz
Cc: e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1291862457-16671-1-git-send-email-asbjorn@asbjorn.biz>
[-- Attachment #1: Type: text/plain, Size: 2270 bytes --]
On Thu, 2010-12-09 at 02:40 +0000, Asbjoern Sloth Toennesen wrote:
> Hi,
>
> This patchset fixes most checkstyle problems in e1000e.
>
> Checkpatch summary:
> pre: total: 221 errors, 129 warnings, 24520 lines checked
> post: total: 2 errors, 34 warnings, 24533 lines checked
>
> The two remaining errors are of the type "Macros with complex values
> should be enclosed in parenthesis", with macros containing 3 comma
> seperated values.
>
> The remaining warnings are all caused by <20ms msleep usage, that should
> be replaced with usleep_range calls.
>
> This patchset is based on top of jkirsher/net-next-2.6.git (67d5288)
>
> Asbjoern Sloth Toennesen (7):
> e1000e: cleanup: fix spacing issues
> e1000e: cleanup: fix bracket issues
> e1000e: cleanup: simplify E1000_ALL_* defines
> e1000e: cleanup: fix long lines
> e1000e: cleanup: fix space issues in ich8_* structs
> e1000e: cleanup: swap arguments to avoid checkpatch errors
> e1000e: cleanup: fix copyright notices to preferred style
>
> drivers/net/e1000e/82571.c | 70 +++++++-------
> drivers/net/e1000e/defines.h | 110 ++++++++++++-----------
> drivers/net/e1000e/e1000.h | 93 +++++++++++---------
> drivers/net/e1000e/es2lan.c | 135 ++++++++++++++--------------
> drivers/net/e1000e/ethtool.c | 75 ++++++++--------
> drivers/net/e1000e/hw.h | 56 ++++++------
> drivers/net/e1000e/ich8lan.c | 185 +++++++++++++++++++-------------------
> drivers/net/e1000e/lib.c | 78 ++++++++--------
> drivers/net/e1000e/netdev.c | 171 +++++++++++++++++------------------
> drivers/net/e1000e/param.c | 60 +++++++------
> drivers/net/e1000e/phy.c | 204 +++++++++++++++++++++---------------------
> 11 files changed, 625 insertions(+), 612 deletions(-)
>
> --
> 1.7.2.3
>
We already have patches queued up internally and are under validation
for the changes in patches 1 through 5 along along with other patches
for e1000e. These patches will be posted shortly.
Patch 6 should be fixed in checkpatch.pl and from Florian's response, it
sounds like the fix is already out there.
Patch 7 does not resolve any warnings in checkpatch.pl and there is no
impending need to make this change.
So I won't be applying this series of patches.
Cheers,
Jeff
[-- Attachment #2: Type: text/plain, Size: 79 bytes --]
------------------------------------------------------------------------------
[-- Attachment #3: Type: text/plain, Size: 257 bytes --]
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH v2 3/4] kthread: NUMA aware kthread_create_on_cpu()
From: Eric Dumazet @ 2010-12-10 5:59 UTC (permalink / raw)
To: Andrew Morton
Cc: Andi Kleen, linux-kernel, netdev, David Miller, Tejun Heo,
Rusty Russell, Tony Luck, Fenghua Yu
In-Reply-To: <20101209164438.fae1ba4c.akpm@linux-foundation.org>
Le jeudi 09 décembre 2010 à 16:44 -0800, Andrew Morton a écrit :
> The name "kthread_create_on_cpu" is pretty misleading.
>
> One would expect such a function to create a kthread which is bound to
> that CPU. But what it in fact does is to create a kthread which is
> bound to all CPUs and whose stack, task_struct and thread_info were
> allocated from the node which contains `cpu'.
>
> Also, a saner interface would be one which takes the numa_node_id, not
> the cpu number.
>
> >
> > ...
> >
> > /**
> > - * kthread_create - create a kthread.
> > + * kthread_create_on_cpu - create a kthread.
> > * @threadfn: the function to run until signal_pending(current).
> > * @data: data ptr for @threadfn.
> > + * @cpu: cpu number.
> > * @namefmt: printf-style name for the thread.
> > *
> > * Description: This helper function creates and names a kernel
> > * thread. The thread will be stopped: use wake_up_process() to start
> > * it. See also kthread_run().
> > *
> > + * If thread is going to be bound on a particular cpu, give its number
> > + * in @cpu, to get NUMA affinity for kthread stack, or else give -1.
>
> This is a bit presumptuous. The caller might wish to later bind this
> thread to some or all of the CPUs on the node, rather than to a single
> CPU (eg, kswapd()).
>
>
> So what to do? Maybe add a new kthread_create_node() which prepares a
> kthread whose memory is bound to that node, then add a
> kthread_create_cpu() convenience wrapper around that?
>
We probably can add the "bind to cpu" as a fifth patch, to avoid one
kthread_bind(p, cpu); done by these callers.
My reasoning not including this kthread_bind(p, cpu) in initial patch
series that I was focusing on NUMA properties first, not on scheduling
(this part already runs correctly as far as I know)
Thanks for taking the patch series, I was about to resubmit it today :)
^ permalink raw reply
* Re: ip rule and/or route problem in 2.6.37-rc5+
From: Ben Greear @ 2010-12-10 6:19 UTC (permalink / raw)
To: NetDev, therbert
In-Reply-To: <4D017D0D.50907@candelatech.com>
On 12/09/2010 05:06 PM, Ben Greear wrote:
>
> This problem appears to have happened between 2.6.36.1 and 2.6.37-rc2.
> We haven't fully bisected the problem yet.
>
>
> The basic test:
>
> * one normal interface using DHCP
> * A second interface specified to use it's own routing table.
> * 'ip rules' to determine behaviour.
>
> After running these commands abelow, the system can no longer
> route out it's normal interface. It appears that the final line
> is the one that messes things up. If you flush table 10001 after
> that, things start working again.
>
> The 'pref 20' rule is also important. It should not have
> any affect on this ping, but it appears that it does, somehow.
> If you remove it, the problem also goes away, regardless of
> the routes in table 10001.
>
>
> ip rule add pref 512 lookup local
> ip rule del pref 0 lookup local
> ip link set eth2 up
> ip -4 addr add 172.16.0.102/24 broadcast 172.16.0.255 dev eth2
> ip rule add to 172.16.0.102 iif eth2 lookup local pref 10
> ip rule add iif eth2 lookup 10001 pref 20
> ip route add 172.16.0.0/24 dev eth2 table 10001
> ip route add unreachable 0/0 table 10001
Seems this is the commit that broke this behaviour:
4465b469008bc03b98a1b8df4e9ae501b6c69d4b is first bad commit
commit 4465b469008bc03b98a1b8df4e9ae501b6c69d4b
Author: Tom Herbert <therbert@google.com>
Date: Sun May 23 19:54:12 2010 +0000
ipv4: Allow configuring subnets as local addresses
This patch allows a host to be configured to respond to any address in
a specified range as if it were local, without actually needing to
configure the address on an interface. This is done through routing
table configuration. For instance, to configure a host to respond
to any address in 10.1/16 received on eth0 as a local address we can do:
ip rule add from all iif eth0 lookup 200
ip route add local 10.1/16 dev lo proto kernel scope host src 127.0.0.1 table 200
This host is now reachable by any 10.1/16 address (route lookup on
input for packets received on eth0 can find the route). On output, the
rule will not be matched so that this host can still send packets to
10.1/16 (not sent on loopback). Presumably, external routing can be
configured to make sense out of this.
To make this work, we needed to modify the logic in finding the
interface which is assigned a given source address for output
(dev_ip_find). We perform a normal fib_lookup instead of just a
lookup on the local table, and in the lookup we ignore the input
interface for matching.
This patch is useful to implement IP-anycast for subnets of virtual
addresses.
Signed-off-by: Tom Herbert <therbert@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
>
>
>
>
> [root@ct503-60 ~]# ping 192.168.100.1
> PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
> 64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=0.257 ms
> 64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=0.285 ms
> \x03
> --- 192.168.100.1 ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 1290ms
> rtt min/avg/max/mdev = 0.257/0.271/0.285/0.014 ms
> [root@ct503-60 ~]# ifconfig
> eth0 Link encap:Ethernet HWaddr 00:30:48:DA:60:1C
> inet addr:192.168.100.173 Bcast:192.168.100.255 Mask:255.255.255.0
> inet6 addr: fe80::230:48ff:feda:601c/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:99 errors:0 dropped:0 overruns:0 frame:0
> TX packets:97 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:10562 (10.3 KiB) TX bytes:9634 (9.4 KiB)
> Memory:fa7e0000-fa800000
>
> lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> inet6 addr: ::1/128 Scope:Host
> UP LOOPBACK RUNNING MTU:16436 Metric:1
> RX packets:54 errors:0 dropped:0 overruns:0 frame:0
> TX packets:54 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:5280 (5.1 KiB) TX bytes:5280 (5.1 KiB)
>
> [root@ct503-60 ~]# ip rule add pref 512 lookup local
> local[root@ct503-60 ~]# ip rule del pref 0 lookup local
> [root@ct503-60 ~]# ping 192.168.100.1
> PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
> 64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=0.266 ms
> 64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=0.238 ms
> \x03
> --- 192.168.100.1 ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 1101ms
> rtt min/avg/max/mdev = 0.238/0.252/0.266/0.014 ms
> [root@ct503-60 ~]# ip link set eth2 up
> adcast 172.16.0.255 dev eth2Dec 10 11:50:01 localhost kernel: e1000e 0000:08:00.0: irq 49 for MSI/MSI-X
> Dec 10 11:50:01 localhost kernel: e1000e 0000:08:00.0: irq 49 for MSI/MSI-X
> Dec 10 11:50:01 localhost kernel: ADDRCONF(NETDEV_UP): eth2: link is not ready
> 2root@ct503-60 ~]# ping 192.168.100.1
> PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
> 64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=0.247 ms
> Dec 10 11:50:04 localhost kernel: e1000e: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
> Dec 10 11:50:04 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
> 64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=0.271 ms
> 64 bytes from 192.168.100.1: icmp_seq=3 ttl=64 time=0.263 ms
> \x03
> --- 192.168.100.1 ping statistics ---
> 3 packets transmitted, 3 received, 0% packet loss, time 2317ms
> rtt min/avg/max/mdev = 0.247/0.260/0.271/0.016 ms
> [root@ct503-60 ~]# ip rule add to 172.16.0.102 iif eth2 lookup local pref 10
> 001 pref 20[root@ct503-60 ~]# ip rule add iif eth2 lookup 10001 pref 20
> [root@ct503-60 ~]# ping 192.168.100.1
> PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
> 64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=0.346 ms
> Dec 10 11:50:14 localhost kernel: eth2: no IPv6 routers present
> 64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=0.251 ms
> \x03
> --- 192.168.100.1 ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 1245ms
> rtt min/avg/max/mdev = 0.251/0.298/0.346/0.050 ms
> [root@ct503-60 ~]# ip route add 172.16.0.0/24 dev eth2 table 10001
> 10001[root@ct503-60 ~]# ip route add unreachable 0/0 table 10001
> [root@ct503-60 ~]# ping 192.168.100.1
> connect: Invalid argument
> [root@ct503-60 ~]# ip route show
> 192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.173
> 172.16.0.0/24 dev eth2 proto kernel scope link src 172.16.0.102
> 169.254.0.0/16 dev eth0 scope link metric 1003
> default via 192.168.100.1 dev eth0
> You have new mail in /var/spool/mail/root
> [root@ct503-60 ~]# ip route show table 10001
> 172.16.0.0/24 dev eth2 scope link
> unreachable default
> [root@ct503-60 ~]#
>
> [root@ct503-60 ~]# ip route flush table 10001
> [root@ct503-60 ~]# ping 192.168.100.1
> PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
> 64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=4.10 ms
> 64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=0.260 ms
> \x03
> --- 192.168.100.1 ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 1300ms
> rtt min/avg/max/mdev = 0.260/2.181/4.102/1.921 ms
> [root@ct503-60 ~]#
>
>
> Thanks,
> Ben
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v2 3/4] kthread: NUMA aware kthread_create_on_cpu()
From: Andrew Morton @ 2010-12-10 6:32 UTC (permalink / raw)
To: Eric Dumazet
Cc: Andi Kleen, linux-kernel, netdev, David Miller, Tejun Heo,
Rusty Russell, Tony Luck, Fenghua Yu
In-Reply-To: <1291960798.2803.18.camel@edumazet-laptop>
On Fri, 10 Dec 2010 06:59:58 +0100 Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le jeudi 09 d__cembre 2010 __ 16:44 -0800, Andrew Morton a __crit :
>
> > The name "kthread_create_on_cpu" is pretty misleading.
> >
> > One would expect such a function to create a kthread which is bound to
> > that CPU. But what it in fact does is to create a kthread which is
> > bound to all CPUs and whose stack, task_struct and thread_info were
> > allocated from the node which contains `cpu'.
> >
> > Also, a saner interface would be one which takes the numa_node_id, not
> > the cpu number.
> >
>
>
> > >
> > > ...
> > >
> > > /**
> > > - * kthread_create - create a kthread.
> > > + * kthread_create_on_cpu - create a kthread.
> > > * @threadfn: the function to run until signal_pending(current).
> > > * @data: data ptr for @threadfn.
> > > + * @cpu: cpu number.
> > > * @namefmt: printf-style name for the thread.
> > > *
> > > * Description: This helper function creates and names a kernel
> > > * thread. The thread will be stopped: use wake_up_process() to start
> > > * it. See also kthread_run().
> > > *
> > > + * If thread is going to be bound on a particular cpu, give its number
> > > + * in @cpu, to get NUMA affinity for kthread stack, or else give -1.
> >
> > This is a bit presumptuous. The caller might wish to later bind this
> > thread to some or all of the CPUs on the node, rather than to a single
> > CPU (eg, kswapd()).
> >
> >
> > So what to do? Maybe add a new kthread_create_node() which prepares a
> > kthread whose memory is bound to that node, then add a
> > kthread_create_cpu() convenience wrapper around that?
> >
>
> We probably can add the "bind to cpu" as a fifth patch, to avoid one
> kthread_bind(p, cpu); done by these callers.
>
> My reasoning not including this kthread_bind(p, cpu) in initial patch
> series that I was focusing on NUMA properties first, not on scheduling
> (this part already runs correctly as far as I know)
>
> Thanks for taking the patch series, I was about to resubmit it today :)
>
but but but. The name "kthread_create_on_cpu" sucks. It's plain wrong.
^ permalink raw reply
* Re: [PATCH v2 3/4] kthread: NUMA aware kthread_create_on_cpu()
From: Eric Dumazet @ 2010-12-10 7:02 UTC (permalink / raw)
To: Andrew Morton
Cc: Andi Kleen, linux-kernel, netdev, David Miller, Tejun Heo,
Rusty Russell, Tony Luck, Fenghua Yu
In-Reply-To: <20101209223210.acd540de.akpm@linux-foundation.org>
Le jeudi 09 décembre 2010 à 22:32 -0800, Andrew Morton a écrit :
> but but but. The name "kthread_create_on_cpu" sucks. It's plain wrong.
Okay you are right Andrew ;) I dont have better idea for the moment.
Note that all callers I converted really create one kthread per cpu, not
per node. They didnt care of node affinity, only me :)
kthread_create_on_node() seems misleading to me (some cpus run on
memoryless nodes)
^ permalink raw reply
* Re: [PATCH v2 3/4] kthread: NUMA aware kthread_create_on_cpu()
From: Andrew Morton @ 2010-12-10 7:09 UTC (permalink / raw)
To: Eric Dumazet
Cc: Andi Kleen, linux-kernel, netdev, David Miller, Tejun Heo,
Rusty Russell, Tony Luck, Fenghua Yu
In-Reply-To: <1291964561.2803.25.camel@edumazet-laptop>
On Fri, 10 Dec 2010 08:02:41 +0100 Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le jeudi 09 d__cembre 2010 __ 22:32 -0800, Andrew Morton a __crit :
>
> > but but but. The name "kthread_create_on_cpu" sucks. It's plain wrong.
>
> Okay you are right Andrew ;) I dont have better idea for the moment.
Dunno. kthread_create_with_memory_on_node() :)
How's about kthread_create_for_node()? That's sufficiently vague to
not mislead readers into thinking that it schedules the thread on that
CPU and leaves room in the namespace for a real kthread_create_on_cpu()
(which we could well end up creating).
kthread_create_node_mem()?
> Note that all callers I converted really create one kthread per cpu, not
> per node. They didnt care of node affinity, only me :)
>
> kthread_create_on_node() seems misleading to me (some cpus run on
> memoryless nodes)
True, but what we're doing here is specifying on which node the
kthread's memory resources should reside - we need to do that even for
CPUs which live on memoryless nodes.
^ permalink raw reply
* Re: [PATCH] fix hostap registration order
From: Meelis Roos @ 2010-12-10 7:19 UTC (permalink / raw)
To: j; +Cc: David Miller, netdev, linux-wireless
In-Reply-To: <20101209.195315.193716225.davem@davemloft.net>
> > In 2.6.37-rc4, hostap_pci init gives a WARNING with backtrace telling
> > that netif_stop_queue is called before register_netdev. Fix it by moving
> > this call after register_netdev. Removes the warning and seems to work,
> > but why is the call to netif_stop_queue needed at all after
> > register_netdev?
>
> It should simply not touch the queue state at all at this point.
>
> Your change would add a race. At the moment the device is registered
> it can be brought up, and then your code will eroneously modify
> the queue state.
OK, I can make a simpler patch for that but I would like to understand
the original reasons for having netif_stop_queue there. Just a relict or
still somehow important?
Jouni?
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Re: Adding Support for SG,GSO,GRO
From: Michał Mirosław @ 2010-12-10 8:27 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Govindarajan, Sriramakrishnan, netdev@vger.kernel.org
In-Reply-To: <1291921115.2647.28.camel@bwh-desktop>
W dniu 9 grudnia 2010 19:58 użytkownik Ben Hutchings
<bhutchings@solarflare.com> napisał:
> On Thu, 2010-12-09 at 19:47 +0100, Michał Mirosław wrote:
>> 2010/12/9 Ben Hutchings <bhutchings@solarflare.com>:
>> > On Thu, 2010-12-09 at 16:03 +0530, Govindarajan, Sriramakrishnan wrote:
>> >> Hi
>> >> We have a NAPI compliant driver(net/drivers/davinci_emac.c), that does
>> >> well at 10/100Mbps loads. Now the same controller/driver is used for
>> >> 1000Mbps
>> >> mode as well, where the CPU gets saturated easily
>> >>
>> >> Internally the module supports scatter gather DMA(which is currently not
>> >> exercised) but there is no HW checksum support.
>> >>
>> >> To specifically implement GRO, GSO support would it be sufficient to add
>> >> SG support to the driver? Are there other means of increasing the throughput
>> >> and decreasing the CPU loading?
>> [...]
>> > On the TX side, NETIF_F_SG means that the stack may include data in the
>> > skb by reference to arbitrary pages *even if their contents are still
>> > being changed* (think sendfile()), which means it depends on hardware
>> > checksum generation.
>>
>> Isn't that condition too broad? If the data could change after packet
>> is submitted to the driver then results would be unpredictable and
>> allow sending wrong data with correct (because hw-calculated)
>> checksum.
> This is not done for a regular send(), only for functions such as
> sendfile() which are specified to read the data asynchronously.
>
>> Right now NETIF_F_SG is removed from dev->features by
>> netdev_fix_features() if no checksum offloads are enabled.
>>
>> Just an idea: would driver with NETIF_F_SG|NETIF_F_HW_CSUM using
>> skb_checksum_help() in xmit path work? This would allow to use DMA
>> scatter-gather without hardware checksumming (and avoid copying the
>> packet's data before sending).
> No, you cannot calculate a checksum for the fragments without also
> copying them to ensure the data doesn't change afterward and invalidate
> the checksum. You could in theory make a copy into multiple fragments,
> but there's no point in doing that unless the frame size is larger than
> a page.
Then at least couple of drivers are broken in this way (ibmveth,
chelsio for UDP, there are other hits on skb_checksum_help).
I'm not familiar with splice/sendfile code, but I would expect, that
pages transferred with it have to be submitted after "data ready"
notification and pinned in memory by DMA mapping (with hardware
checksumming, CPU does not need to see the data, but still it has to
be there already) until the frame is transferred to the network
device. So, even if the contents of the page changes (because further
data is transferred), the part that is submitted to be sent should
not.
If that's really not the case, then splice/sendfile to network is
useless as it means random data corruption. Googling around shows
reports about sendfile() correllated corruption - could this the
cause?
Best Regards,
Michał Mirosław
^ permalink raw reply
* [net-next-2.6 08/27] e1000: fix return value not set on error
From: Jeff Kirsher @ 2010-12-10 9:50 UTC (permalink / raw)
To: davem, davem, dnelson
Cc: netdev, Dean Nelson, bphilips, Jesse Brandeburg, Jeff Kirsher,
gospo, stable
In-Reply-To: <1291974667-30254-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Dean Nelson <dnelson@redhat.com>
Dean noticed that 'err' wasn't being set when the "goto err_dma"
statement is executed in the following hunk from the commit. It's value
will be zero as a result of a successful call to e1000_init_hw_struct().
This patch changes the error condition to be correctly propagated.
CC: stable@kernel.org
Signed-off-by: Dean Nelson <dnelson@redhat.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Emil Tantilov <emil.s.tantilov@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000/e1000_main.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 06c7d1c..491bf2a 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -971,11 +971,13 @@ static int __devinit e1000_probe(struct pci_dev *pdev,
*/
dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
pci_using_dac = 1;
- } else if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(32))) {
- dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
} else {
- pr_err("No usable DMA config, aborting\n");
- goto err_dma;
+ err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
+ if (err) {
+ pr_err("No usable DMA config, aborting\n");
+ goto err_dma;
+ }
+ dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
}
netdev->netdev_ops = &e1000_netdev_ops;
--
1.7.3.2
^ permalink raw reply related
* [net-next 00/27][pull-request] Intel Wired LAN Driver Updates
From: Jeff Kirsher @ 2010-12-10 9:50 UTC (permalink / raw)
To: davem, davem; +Cc: Jeff Kirsher, netdev, gospo, bphilips
Here are a batch of fixes and cleanups intended for 2.6.38.
The following changes since commit:
commit defb3519a64141608725e2dac5a5aa9a3c644bae
Author: David S. Miller <davem@davemloft.net>
Date: Wed Dec 8 21:16:57 2010 -0800
net: Abstract away all dst_entry metrics accesses
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/net-next-2.6.git master
Bruce Allan (11):
e1000e: 82571-based mezzanine card can fail ethtool link test
e1000e: 82574/82583 performance improvement
e1000e: 82577/8 must acquire h/w semaphore before workaround
e1000e: 82571 Serdes can fail to get link
e1000e: 82577/8/9 mis-configured OEM bits during S0->Sx
e1000e: 82579 PHY incorrectly identified during init
e1000e: support new PBA format from EEPROM
e1000e: prevent null ptr dereference in e1000_tx_queue()
e1000e: minor error message corrections
e1000e: static analysis tools complain of a possible null ptr p
dereference
e1000e: increment the driver version
Carolyn Wyborny (1):
igb: Add new function to read part number from EEPROM in string
format
Dean Nelson (1):
e1000: fix return value not set on error
Don Skidmore (3):
ixgbe: fix X540 phy id to correct value
ixgbe: fix X540 to use it's own info struct
ixgbe: cleanup string function calls to use bound checking versions.
Emil Tantilov (2):
ixgb: Don't check for vlan group on transmit
ixgbe: fix ntuple support
Holger Eitzenberger (1):
e1000e: fix double initialization in blink path
Jeff Kirsher (8):
Documentation/networking/e1000.txt: Update documentation
Documentation/networking/e1000e.txt: Update documentation
Documentation/networking/igb.txt: update documentation
Documentation/networking/igbvf.txt: Update documentation
Documentation/networking/ixgbe.txt: Update ixgbe documentation
Documentation/networking/ixgbevf.txt: Update documentation
MAINTAINERS: Update Intel Wired LAN info
Intel Wired LAN drivers: Use static const
Documentation/networking/e1000.txt | 10 +-
Documentation/networking/e1000e.txt | 40 ++++---
Documentation/networking/igb.txt | 22 +++-
Documentation/networking/igbvf.txt | 4 +-
Documentation/networking/ixgbe.txt | 211 ++++++++++++++++++++++------------
Documentation/networking/ixgbevf.txt | 4 -
MAINTAINERS | 2 +
drivers/net/e1000/e1000_hw.c | 20 ++--
drivers/net/e1000/e1000_main.c | 10 +-
drivers/net/e1000/e1000_param.c | 13 +-
drivers/net/e1000e/82571.c | 46 ++++++--
drivers/net/e1000e/defines.h | 8 +-
drivers/net/e1000e/e1000.h | 4 +-
drivers/net/e1000e/ethtool.c | 14 ++-
drivers/net/e1000e/ich8lan.c | 18 ++-
drivers/net/e1000e/lib.c | 135 ++++++++++++++++++----
drivers/net/e1000e/netdev.c | 21 ++--
drivers/net/e1000e/param.c | 2 +-
drivers/net/e1000e/phy.c | 25 +++-
drivers/net/igb/e1000_defines.h | 7 +
drivers/net/igb/e1000_nvm.c | 93 ++++++++++++++-
drivers/net/igb/e1000_nvm.h | 2 +
drivers/net/igb/e1000_phy.c | 11 +-
drivers/net/igb/igb_main.c | 11 +-
drivers/net/ixgb/ixgb_main.c | 51 +++++----
drivers/net/ixgb/ixgb_param.c | 21 ++--
drivers/net/ixgbe/ixgbe_ethtool.c | 31 +++--
drivers/net/ixgbe/ixgbe_main.c | 32 +++---
drivers/net/ixgbe/ixgbe_phy.c | 2 +-
drivers/net/ixgbe/ixgbe_type.h | 2 +-
drivers/net/ixgbe/ixgbe_x540.c | 4 +-
drivers/net/ixgbevf/ethtool.c | 18 ++-
32 files changed, 624 insertions(+), 270 deletions(-)
--
1.7.3.2
^ 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