* Re: [PATCH 1/2] net: Enable 64-bit net device statistics on 32-bit architectures
From: Stephen Hemminger @ 2010-06-04 17:28 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, Arnd Bergmann, netdev, linux-net-drivers
In-Reply-To: <1275592298.2106.36.camel@achroite.uk.solarflarecom.com>
On Thu, 03 Jun 2010 20:11:38 +0100
Ben Hutchings <bhutchings@solarflare.com> wrote:
> static inline u64 rtnl_link_stats64_read(const u64 *field)
> {
> return ACCESS_ONCE(*field);
> }
> static inline u32 rtnl_link_stats64_read32(const u64 *field)
> {
> return ACCESS_ONCE(*field);
> }
Do we really care if compiler reorders access. I think not.
There was no order guarantee in the past.
--
^ permalink raw reply
* [PATCH nf-next-2.6] conntrack: IPS_UNTRACKED bit
From: Eric Dumazet @ 2010-06-04 16:25 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Changli Gao, Netfilter Developers, netdev
In-Reply-To: <1275654964.2482.150.camel@edumazet-laptop>
Le vendredi 04 juin 2010 à 14:36 +0200, Eric Dumazet a écrit :
> Le vendredi 04 juin 2010 à 14:29 +0200, Patrick McHardy a écrit :
> > Changli Gao wrote:
> > > On Fri, Jun 4, 2010 at 7:40 PM, Patrick McHardy <kaber@trash.net> wrote:
> > >> Eric Dumazet wrote:
> > >>> Obviously, an IPS_UNTRACKED bit would be much easier to implement.
> > >>> Would it be acceptable ?
> > >> That also would be fine. However the main idea behind using a nfctinfo
> > >> bit was that we wouldn't need the untracked conntrack anymore at all.
> > >> But I guess a per-cpu untrack conntrack would already be an improvement
> > >> over the current situation.
> > >
> > > I think Eric didn't mean ip_conntrack_info but ip_conntrack_status
> > > bit. Since we have had a IPS_TEMPLATE bit, I think another
> > > IPS_UNTRACKED bit is also acceptable.
> >
> > Yes, of course. But using one of these bits implies that we'd still
> > have the untracked conntrack.
>
> Yes, it was my idea, with a per_cpu untracked conntrack.
>
> I'll submit a patch, thanks.
>
>
Here is first part, introducing IPS_UNTRACKED bit and various helpers to
abstract nf_conntrack_untracked access.
I'll cook second patch in a couple of hours for per_cpu conversion.
Thanks !
[PATCH nf-next-2.6] conntrack: IPS_UNTRACKED bit
NOTRACK makes all cpus share a cache line on nf_conntrack_untracked
twice per packet. This is bad for performance.
__read_mostly annotation is also a bad choice.
This patch introduces IPS_UNTRACKED bit so that we can use later a
per_cpu untrack structure more easily.
A new helper, nf_ct_untracked_get() returns a pointer to
nf_conntrack_untracked.
Another one, nf_ct_untracked_status_or() is used by nf_nat_init() to add
IPS_NAT_DONE_MASK bits to untracked status.
nf_ct_is_untracked() prototype is changed to work on a nf_conn pointer.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/linux/netfilter/nf_conntrack_common.h | 4 ++++
include/net/netfilter/nf_conntrack.h | 12 +++++++++---
include/net/netfilter/nf_conntrack_core.h | 2 +-
net/ipv4/netfilter/nf_nat_core.c | 2 +-
net/ipv4/netfilter/nf_nat_standalone.c | 2 +-
net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c | 2 +-
net/netfilter/nf_conntrack_core.c | 11 ++++++++---
net/netfilter/nf_conntrack_netlink.c | 2 +-
net/netfilter/xt_CT.c | 4 ++--
net/netfilter/xt_NOTRACK.c | 2 +-
net/netfilter/xt_TEE.c | 4 ++--
net/netfilter/xt_cluster.c | 2 +-
net/netfilter/xt_conntrack.c | 11 ++++++-----
net/netfilter/xt_socket.c | 2 +-
net/netfilter/xt_state.c | 14 ++++++++------
15 files changed, 47 insertions(+), 29 deletions(-)
diff --git a/include/linux/netfilter/nf_conntrack_common.h b/include/linux/netfilter/nf_conntrack_common.h
index 14e6d32..1afd18c 100644
--- a/include/linux/netfilter/nf_conntrack_common.h
+++ b/include/linux/netfilter/nf_conntrack_common.h
@@ -76,6 +76,10 @@ enum ip_conntrack_status {
/* Conntrack is a template */
IPS_TEMPLATE_BIT = 11,
IPS_TEMPLATE = (1 << IPS_TEMPLATE_BIT),
+
+ /* Conntrack is a fake untracked entry */
+ IPS_UNTRACKED_BIT = 12,
+ IPS_UNTRACKED = (1 << IPS_UNTRACKED_BIT),
};
/* Connection tracking event types */
diff --git a/include/net/netfilter/nf_conntrack.h b/include/net/netfilter/nf_conntrack.h
index bde095f..3bc38c7 100644
--- a/include/net/netfilter/nf_conntrack.h
+++ b/include/net/netfilter/nf_conntrack.h
@@ -261,7 +261,13 @@ extern s16 (*nf_ct_nat_offset)(const struct nf_conn *ct,
u32 seq);
/* Fake conntrack entry for untracked connections */
-extern struct nf_conn nf_conntrack_untracked;
+static inline struct nf_conn *nf_ct_untracked_get(void)
+{
+ extern struct nf_conn nf_conntrack_untracked;
+
+ return &nf_conntrack_untracked;
+}
+extern void nf_ct_untracked_status_or(unsigned long bits);
/* Iterate over all conntracks: if iter returns true, it's deleted. */
extern void
@@ -289,9 +295,9 @@ static inline int nf_ct_is_dying(struct nf_conn *ct)
return test_bit(IPS_DYING_BIT, &ct->status);
}
-static inline int nf_ct_is_untracked(const struct sk_buff *skb)
+static inline int nf_ct_is_untracked(const struct nf_conn *ct)
{
- return (skb->nfct == &nf_conntrack_untracked.ct_general);
+ return test_bit(IPS_UNTRACKED_BIT, &ct->status);
}
extern int nf_conntrack_set_hashsize(const char *val, struct kernel_param *kp);
diff --git a/include/net/netfilter/nf_conntrack_core.h b/include/net/netfilter/nf_conntrack_core.h
index 3d7524f..aced085 100644
--- a/include/net/netfilter/nf_conntrack_core.h
+++ b/include/net/netfilter/nf_conntrack_core.h
@@ -60,7 +60,7 @@ static inline int nf_conntrack_confirm(struct sk_buff *skb)
struct nf_conn *ct = (struct nf_conn *)skb->nfct;
int ret = NF_ACCEPT;
- if (ct && ct != &nf_conntrack_untracked) {
+ if (ct && !nf_ct_is_untracked(ct)) {
if (!nf_ct_is_confirmed(ct))
ret = __nf_conntrack_confirm(skb);
if (likely(ret == NF_ACCEPT))
diff --git a/net/ipv4/netfilter/nf_nat_core.c b/net/ipv4/netfilter/nf_nat_core.c
index 4f8bddb..c7719b2 100644
--- a/net/ipv4/netfilter/nf_nat_core.c
+++ b/net/ipv4/netfilter/nf_nat_core.c
@@ -742,7 +742,7 @@ static int __init nf_nat_init(void)
spin_unlock_bh(&nf_nat_lock);
/* Initialize fake conntrack so that NAT will skip it */
- nf_conntrack_untracked.status |= IPS_NAT_DONE_MASK;
+ nf_ct_untracked_status_or(IPS_NAT_DONE_MASK);
l3proto = nf_ct_l3proto_find_get((u_int16_t)AF_INET);
diff --git a/net/ipv4/netfilter/nf_nat_standalone.c b/net/ipv4/netfilter/nf_nat_standalone.c
index beb2581..6723c68 100644
--- a/net/ipv4/netfilter/nf_nat_standalone.c
+++ b/net/ipv4/netfilter/nf_nat_standalone.c
@@ -98,7 +98,7 @@ nf_nat_fn(unsigned int hooknum,
return NF_ACCEPT;
/* Don't try to NAT if this packet is not conntracked */
- if (ct == &nf_conntrack_untracked)
+ if (nf_ct_is_untracked(ct))
return NF_ACCEPT;
nat = nfct_nat(ct);
diff --git a/net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c b/net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c
index 9be8177..1df3c8b 100644
--- a/net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c
+++ b/net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c
@@ -208,7 +208,7 @@ icmpv6_error(struct net *net, struct nf_conn *tmpl,
type = icmp6h->icmp6_type - 130;
if (type >= 0 && type < sizeof(noct_valid_new) &&
noct_valid_new[type]) {
- skb->nfct = &nf_conntrack_untracked.ct_general;
+ skb->nfct = &nf_ct_untracked_get()->ct_general;
skb->nfctinfo = IP_CT_NEW;
nf_conntrack_get(skb->nfct);
return NF_ACCEPT;
diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
index eeeb8bc..6c1da21 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -62,7 +62,7 @@ EXPORT_SYMBOL_GPL(nf_conntrack_htable_size);
unsigned int nf_conntrack_max __read_mostly;
EXPORT_SYMBOL_GPL(nf_conntrack_max);
-struct nf_conn nf_conntrack_untracked __read_mostly;
+struct nf_conn nf_conntrack_untracked;
EXPORT_SYMBOL_GPL(nf_conntrack_untracked);
static int nf_conntrack_hash_rnd_initted;
@@ -1321,6 +1321,12 @@ EXPORT_SYMBOL_GPL(nf_conntrack_set_hashsize);
module_param_call(hashsize, nf_conntrack_set_hashsize, param_get_uint,
&nf_conntrack_htable_size, 0600);
+void nf_ct_untracked_status_or(unsigned long bits)
+{
+ nf_conntrack_untracked.status |= bits;
+}
+EXPORT_SYMBOL_GPL(nf_ct_untracked_status_or);
+
static int nf_conntrack_init_init_net(void)
{
int max_factor = 8;
@@ -1368,8 +1374,7 @@ static int nf_conntrack_init_init_net(void)
#endif
atomic_set(&nf_conntrack_untracked.ct_general.use, 1);
/* - and look it like as a confirmed connection */
- set_bit(IPS_CONFIRMED_BIT, &nf_conntrack_untracked.status);
-
+ nf_ct_untracked_status_or(IPS_CONFIRMED | IPS_UNTRACKED);
return 0;
#ifdef CONFIG_NF_CONNTRACK_ZONES
diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c
index c42ff6a..5bae1cd 100644
--- a/net/netfilter/nf_conntrack_netlink.c
+++ b/net/netfilter/nf_conntrack_netlink.c
@@ -480,7 +480,7 @@ ctnetlink_conntrack_event(unsigned int events, struct nf_ct_event *item)
int err;
/* ignore our fake conntrack entry */
- if (ct == &nf_conntrack_untracked)
+ if (nf_ct_is_untracked(ct))
return 0;
if (events & (1 << IPCT_DESTROY)) {
diff --git a/net/netfilter/xt_CT.c b/net/netfilter/xt_CT.c
index 562bf32..0cb6053 100644
--- a/net/netfilter/xt_CT.c
+++ b/net/netfilter/xt_CT.c
@@ -67,7 +67,7 @@ static int xt_ct_tg_check(const struct xt_tgchk_param *par)
return -EINVAL;
if (info->flags & XT_CT_NOTRACK) {
- ct = &nf_conntrack_untracked;
+ ct = nf_ct_untracked_get();
atomic_inc(&ct->ct_general.use);
goto out;
}
@@ -132,7 +132,7 @@ static void xt_ct_tg_destroy(const struct xt_tgdtor_param *par)
struct nf_conn *ct = info->ct;
struct nf_conn_help *help;
- if (ct != &nf_conntrack_untracked) {
+ if (!nf_ct_is_untracked(ct)) {
help = nfct_help(ct);
if (help)
module_put(help->helper->me);
diff --git a/net/netfilter/xt_NOTRACK.c b/net/netfilter/xt_NOTRACK.c
index 512b912..9d78218 100644
--- a/net/netfilter/xt_NOTRACK.c
+++ b/net/netfilter/xt_NOTRACK.c
@@ -23,7 +23,7 @@ notrack_tg(struct sk_buff *skb, const struct xt_action_param *par)
If there is a real ct entry correspondig to this packet,
it'll hang aroun till timing out. We don't deal with it
for performance reasons. JK */
- skb->nfct = &nf_conntrack_untracked.ct_general;
+ skb->nfct = &nf_ct_untracked_get()->ct_general;
skb->nfctinfo = IP_CT_NEW;
nf_conntrack_get(skb->nfct);
diff --git a/net/netfilter/xt_TEE.c b/net/netfilter/xt_TEE.c
index 859d9fd..7a11826 100644
--- a/net/netfilter/xt_TEE.c
+++ b/net/netfilter/xt_TEE.c
@@ -104,7 +104,7 @@ tee_tg4(struct sk_buff *skb, const struct xt_action_param *par)
#ifdef WITH_CONNTRACK
/* Avoid counting cloned packets towards the original connection. */
nf_conntrack_put(skb->nfct);
- skb->nfct = &nf_conntrack_untracked.ct_general;
+ skb->nfct = &nf_ct_untracked_get()->ct_general;
skb->nfctinfo = IP_CT_NEW;
nf_conntrack_get(skb->nfct);
#endif
@@ -177,7 +177,7 @@ tee_tg6(struct sk_buff *skb, const struct xt_action_param *par)
#ifdef WITH_CONNTRACK
nf_conntrack_put(skb->nfct);
- skb->nfct = &nf_conntrack_untracked.ct_general;
+ skb->nfct = &nf_ct_untracked_get()->ct_general;
skb->nfctinfo = IP_CT_NEW;
nf_conntrack_get(skb->nfct);
#endif
diff --git a/net/netfilter/xt_cluster.c b/net/netfilter/xt_cluster.c
index 30b95a1..f4af1bf 100644
--- a/net/netfilter/xt_cluster.c
+++ b/net/netfilter/xt_cluster.c
@@ -120,7 +120,7 @@ xt_cluster_mt(const struct sk_buff *skb, struct xt_action_param *par)
if (ct == NULL)
return false;
- if (ct == &nf_conntrack_untracked)
+ if (nf_ct_is_untracked(ct))
return false;
if (ct->master)
diff --git a/net/netfilter/xt_conntrack.c b/net/netfilter/xt_conntrack.c
index 39681f1..e536710 100644
--- a/net/netfilter/xt_conntrack.c
+++ b/net/netfilter/xt_conntrack.c
@@ -123,11 +123,12 @@ conntrack_mt(const struct sk_buff *skb, struct xt_action_param *par,
ct = nf_ct_get(skb, &ctinfo);
- if (ct == &nf_conntrack_untracked)
- statebit = XT_CONNTRACK_STATE_UNTRACKED;
- else if (ct != NULL)
- statebit = XT_CONNTRACK_STATE_BIT(ctinfo);
- else
+ if (ct) {
+ if (nf_ct_is_untracked(ct))
+ statebit = XT_CONNTRACK_STATE_UNTRACKED;
+ else
+ statebit = XT_CONNTRACK_STATE_BIT(ctinfo);
+ } else
statebit = XT_CONNTRACK_STATE_INVALID;
if (info->match_flags & XT_CONNTRACK_STATE) {
diff --git a/net/netfilter/xt_socket.c b/net/netfilter/xt_socket.c
index 3d54c23..1ca8990 100644
--- a/net/netfilter/xt_socket.c
+++ b/net/netfilter/xt_socket.c
@@ -127,7 +127,7 @@ socket_match(const struct sk_buff *skb, struct xt_action_param *par,
* reply packet of an established SNAT-ted connection. */
ct = nf_ct_get(skb, &ctinfo);
- if (ct && (ct != &nf_conntrack_untracked) &&
+ if (ct && !nf_ct_is_untracked(ct) &&
((iph->protocol != IPPROTO_ICMP &&
ctinfo == IP_CT_IS_REPLY + IP_CT_ESTABLISHED) ||
(iph->protocol == IPPROTO_ICMP &&
diff --git a/net/netfilter/xt_state.c b/net/netfilter/xt_state.c
index e12e053..a507922 100644
--- a/net/netfilter/xt_state.c
+++ b/net/netfilter/xt_state.c
@@ -26,14 +26,16 @@ state_mt(const struct sk_buff *skb, struct xt_action_param *par)
const struct xt_state_info *sinfo = par->matchinfo;
enum ip_conntrack_info ctinfo;
unsigned int statebit;
+ struct nf_conn *ct = nf_ct_get(skb, &ctinfo);
- if (nf_ct_is_untracked(skb))
- statebit = XT_STATE_UNTRACKED;
- else if (!nf_ct_get(skb, &ctinfo))
+ if (!ct)
statebit = XT_STATE_INVALID;
- else
- statebit = XT_STATE_BIT(ctinfo);
-
+ else {
+ if (nf_ct_is_untracked(ct))
+ statebit = XT_STATE_UNTRACKED;
+ else
+ statebit = XT_STATE_BIT(ctinfo);
+ }
return (sinfo->statemask & statebit);
}
^ permalink raw reply related
* Re: [PATCH] [ath5k][leds] Ability to disable leds support. If leds support enabled do not force mac802.11 leds layer selection.
From: Pavel Roskin @ 2010-06-04 16:22 UTC (permalink / raw)
To: Dmytro Milinevskyy
Cc: ath5k-devel, Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez,
Bob Copeland, John W. Linville, GeunSik Lim, Greg Kroah-Hartman,
Lukas Turek, Mark Hindley, Johannes Berg, Jiri Kosina, Kalle Valo,
Keng-Yu Lin, Luca Verdesca, Shahar Or, linux-wireless, netdev,
linux-kernel
In-Reply-To: <4c0902ef.0a41df0a.6c86.2df0@mx.google.com>
On Fri, 2010-06-04 at 16:43 +0300, Dmytro Milinevskyy wrote:
> Hi!
>
> Here is the patch to disable ath5k leds support on build stage.
> However if the leds support was enabled do not force selection of 802.11 leds layer.
> Depency on LEDS_CLASS is kept.
>
> Suggestion given by Pavel Roskin and Bob Copeland applied.
It's great that you did it. The patch is much clearer now. That makes
smaller issues visible. Please don't be discouraged by the criticism,
you are on the right track.
First of all, your patch doesn't apply cleanly to the current
wireless-testing because of formatting changes in Makefile. Please
update.
> +config ATH5K_LEDS
> + tristate "Atheros 5xxx wireless cards LEDs support"
> + depends on ATH5K
> + select NEW_LEDS
> + select LEDS_CLASS
> + ---help---
> + Atheros 5xxx LED support.
"tristate" is wrong here. "tristate" would allow users select "m",
which is wrong, since LED support is not a separate module. I think you
want "bool" here.
> +#ifdef CONFIG_ATH5K_LEDS
> /*
> * State for LED triggers
> */
> @@ -95,6 +96,7 @@ struct ath5k_led
> struct ath5k_softc *sc; /* driver state */
> struct led_classdev led_dev; /* led classdev */
> };
> +#endif
This shouldn't be needed. I'll rather see a structure that is not used
in some cases than an extra pair of preprocessor conditionals.
> diff --git a/drivers/net/wireless/ath/ath5k/gpio.c b/drivers/net/wireless/ath/ath5k/gpio.c
> index 64a27e7..9e757b3 100644
> --- a/drivers/net/wireless/ath/ath5k/gpio.c
> +++ b/drivers/net/wireless/ath/ath5k/gpio.c
> @@ -25,6 +25,7 @@
> #include "debug.h"
> #include "base.h"
>
> +#ifdef CONFIG_ATH5K_LEDS
> /*
> * Set led state
> */
> @@ -76,6 +77,7 @@ void ath5k_hw_set_ledstate(struct ath5k_hw *ah, unsigned int state)
> else
> AR5K_REG_ENABLE_BITS(ah, AR5K_PCICFG, led_5210);
> }
> +#endif
I would just move that function to led.c (and don't forget to include
reg.h). The Makefile should take care of the rest.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [2.6.35-rc1] page alloc failure order:1, mode:0x4020
From: Michael Guntsche @ 2010-06-04 16:16 UTC (permalink / raw)
To: Eric Dumazet; +Cc: linux-kernel, netdev
In-Reply-To: <1275656014.2482.169.camel@edumazet-laptop>
On 2010.06.04 14:53:34 , Eric Dumazet wrote:
> order-1 allocations are unfortunate, since this hardware should use
> order-0 ones if possible, and it seems it was its goal.
>
> 3872 (0xF20) comes from
<snip>
>
> 1) Maybe rx_bufsize should not include the roundup() since
> ath_rxbuf_alloc() also do an alignment adjustment ?
>
> 2) We should try to reduce skb_shared_info by four bytes.
>
> Could you try this patch ?
>
>
> We make sure rx_bufsize + various overhead <= PAGE_SIZE
> But I am not sure its legal for the hardware...
I applied the patch recompiled and run it on the routerboard, trying
to trigger the bug again.
Kind regards,
Michael
^ permalink raw reply
* Re: [stable] [PATCH] virtio_net: indicate oom when addbuf returns failure
From: Greg KH @ 2010-06-04 16:05 UTC (permalink / raw)
To: Rusty Russell
Cc: stable, Herbert Xu, Michael S. Tsirkin, netdev, Bruce Rogers
In-Reply-To: <201006041028.56798.rusty@rustcorp.com.au>
On Fri, Jun 04, 2010 at 10:28:56AM +0930, Rusty Russell wrote:
> This patch is a subset of an already upstream patch, but this portion
> is useful in earlier releases.
What is the git commit id of that upstream patch?
thanks,
greg k-h
^ permalink raw reply
* Re: [Patch] infiniband: check local reserved ports
From: Roland Dreier @ 2010-06-04 16:04 UTC (permalink / raw)
To: Cong Wang
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Tetsuo Handa,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <4C085C9A.30506-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > Should this inet_is_reserved_local_port() test apply to all the "port
> > spaces" that this code is handling? I honestly am ignorant of the
> > intended semantics of the new local_reserved_ports stuff, hence my question.
> Yes, but I only found this case, is there any else?
My question was more in the other direction: should this test apply to
all the "port spaces" handled here? From looking at the code, it
appears the answer is yes -- it seems that putting a port in
local_reserved_ports reserves that port for IPv4 and IPv6, UDP, TCP,
SCTP, DCCP, everything, so we should probably reserve all RDMA CM ports too.
--
Roland Dreier <rolandd-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] act_mirred: don't clone skb when skb isn't shared
From: Changli Gao @ 2010-06-04 13:43 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: David S. Miller, netdev, Changli Gao
don't clone skb when skb isn't shared
When the tcf_action is TC_ACT_STOLEN, and the skb isn't shared, we don't need
to clone a new skb. As the skb will be freed after this function returns, we
can use it freely once we get a reference to it.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
----
net/sched/act_mirred.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/net/sched/act_mirred.c b/net/sched/act_mirred.c
index c0b6863..79d4318 100644
--- a/net/sched/act_mirred.c
+++ b/net/sched/act_mirred.c
@@ -169,13 +169,20 @@ static int tcf_mirred(struct sk_buff *skb, struct tc_action *a,
goto out;
}
- skb2 = skb_act_clone(skb, GFP_ATOMIC);
- if (skb2 == NULL)
- goto out;
+ at = G_TC_AT(skb->tc_verd);
+ if (m->tcf_action == TC_ACT_STOLEN && !skb_shared(skb)) {
+ skb2 = skb_get(skb);
+ skb2->tc_verd = SET_TC_VERD(skb2->tc_verd, 0);
+ skb2->tc_verd = CLR_TC_OK2MUNGE(skb2->tc_verd);
+ skb2->tc_verd = CLR_TC_MUNGED(skb2->tc_verd);
+ } else {
+ skb2 = skb_act_clone(skb, GFP_ATOMIC);
+ if (skb2 == NULL)
+ goto out;
+ }
m->tcf_bstats.bytes += qdisc_pkt_len(skb2);
m->tcf_bstats.packets++;
- at = G_TC_AT(skb->tc_verd);
if (!(at & AT_EGRESS)) {
if (m->tcfm_ok_push)
skb_push(skb2, skb2->dev->hard_header_len);
@@ -185,8 +192,8 @@ static int tcf_mirred(struct sk_buff *skb, struct tc_action *a,
if (m->tcfm_eaction != TCA_EGRESS_MIRROR)
skb2->tc_verd = SET_TC_FROM(skb2->tc_verd, at);
- skb2->dev = dev;
skb2->skb_iif = skb->dev->ifindex;
+ skb2->dev = dev;
dev_queue_xmit(skb2);
err = 0;
^ permalink raw reply related
* Re: [PATCH] rps: tcp: fix rps_sock_flow_table table updates
From: Tom Herbert @ 2010-06-04 15:15 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev
In-Reply-To: <20100603.200721.59663365.davem@davemloft.net>
Looks good to me. Thanks Eric.
Tom
On Thu, Jun 3, 2010 at 8:07 PM, David Miller <davem@davemloft.net> wrote:
>
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 03 Jun 2010 21:03:58 +0200
>
> > I believe a moderate SYN flood attack can corrupt RFS flow table
> > (rps_sock_flow_table), making RPS/RFS much less effective.
> ...
> > This patch moves sock_rps_save_rxhash() to a sock locked section,
> > and only for non LISTEN sockets.
>
> This looks good to me.
>
> Tom, please review.
^ permalink raw reply
* Re: 200 millisecond timeouts in TCP
From: Satoru SATOH @ 2010-06-04 15:02 UTC (permalink / raw)
To: Ryousei Takano; +Cc: Ivan Novick, netdev
In-Reply-To: <AANLkTilsYS8P2VqATmasXjjdhjPMMZznIHBByXc1i8cU@mail.gmail.com>
It's possible to tune the RTO min value (rto_min) per route since
2.6.23+. (see also the manual of iproute2, ip(8) )
- satoru
On Fri, Jun 04, 2010 at 03:58:57PM +0900, Ryousei Takano wrote:
> On Fri, Jun 4, 2010 at 7:37 AM, Ivan Novick <novickivan@gmail.com> wrote:
> > Hello,
> >
> > Using tcpdump and systemtap I am seeing that sometimes retransmission
> > of data is sent after waiting 200 milliseconds. However sometimes
> > retransmissions happen quicker.
> >
> > Is there a specifc event that causes these 200 milisec delays to kick
> > in? Are those events identifiable in netstat -s output?
> >
> > Also do you know if the timeout numbers for TCP are configurable parameters?
> >
> The minimum RTO value is fixed to 200 ms. It is useful to make the min/max
> RTO values tunable. For example, reducing the minimum RTO value is effective
> for TCP incast problem [1]. Of course, it may occur spurious retransmissions.
>
> [1] Vijay Vasudevan, et al, Safe and Effective Fine-grained TCP Retransmissions
> for Datacenter Communication, SIGCOMM2009
>
> In Solaris, there are two tunable parameters: tcp_rexmit_interval_min/max.
>
> Do you have plan to introduce sysctl parameters like these to the Linux.
>
> Thanks,
> Ryousei
^ permalink raw reply
* Re: [Patch 2/2] mlx4: add dynamic LRO disable support
From: Ben Hutchings @ 2010-06-04 14:25 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, herbert.xu, nhorman, sgruszka, davem
In-Reply-To: <4C085D45.6040001@redhat.com>
On Fri, 2010-06-04 at 09:56 +0800, Cong Wang wrote:
> On 06/03/10 20:37, Ben Hutchings wrote:
> > On Wed, 2010-06-02 at 23:39 -0400, Amerigo Wang wrote:
> >> This patch adds dynamic LRO diable support for mlx4 net driver.
> >> It also fixes a bug of mlx4, which checks NETIF_F_LRO flag in rx
> >> path without rtnl lock.
> > [...]
> >
> > Is that flag test actually unsafe - and if so, how is testing num_lro
> > any better? Perhaps access to net_device::features should be wrapped
> > with ACCESS_ONCE() to ensure that reads and writes are atomic.
> >
>
> At least, I don't find there is any race with 'num_lro', thus
> no lock is needed.
In both cases there is a race condition but it is harmless so long as
the read and the write are atomic. There is a general assumption in
networking code that this is the case for int and long. Personally I
would prefer to see this made explicit using ACCESS_ONCE(), but I don't
see any specific problem in mlx4 (not that I'm familiar with this driver
either).
Now that I look at the patch again, I see you're using a static (i.e.
global) variable to 'back up' the non-zero (enabled) value of num_lro.
This is introducing a bug! The correct value is apparently set in
mlx4_en_get_profile(); you would need to replicate that.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Is CONFIG_IP_VS_IPV6 still/really dangerous?
From: Ferenc Wagner @ 2010-06-04 13:56 UTC (permalink / raw)
To: Julius Volz; +Cc: netdev
Hi,
In commit fab0de02fb0da83b90cec7fce4294747d86d5c6f CONFIG_IP_VS_IPV6 is
described as:
Add IPv6 support to IPVS. This is incomplete and might be dangerous.
I agree its implementation is incomplete. But I wonder if it's really
dangerous in the sense that generic distribution kernels shouldn't
enable it, because it can break unrelated (eg. IPv4 IPVS) functionality.
What does that warning mean today? Isn't it out of date?
--
Thanks,
Feri.
^ permalink raw reply
* Re: [PATCH] [ath5k][leds] Ability to disable leds support. If leds support enabled do not force mac802.11 leds layer selection.
From: John W. Linville @ 2010-06-04 14:09 UTC (permalink / raw)
To: Dmytro Milinevskyy
Cc: Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez, Bob Copeland,
GeunSik Lim, Greg Kroah-Hartman, Lukas Turek, Mark Hindley,
Johannes Berg, Jiri Kosina, Kalle Valo, Keng-Yu Lin,
Luca Verdesca, Shahar Or, linux-wireless, netdev, linux-kernel
In-Reply-To: <4c0804e2.0c3ddf0a.2771.10f7@mx.google.com>
On Thu, Jun 03, 2010 at 10:39:30PM +0300, Dmytro Milinevskyy wrote:
> Hi!
>
> Here is the patch to disable ath5k leds support on build stage.
> However if the leds support was enabled do not force selection of 802.11 leds layer.
> Depency on LEDS_CLASS is kept.
>
> Suggestion given by Pavel Roskin and Bob Copeland applied.
>
> Regards,
>
> --Dima
Needs at least a Signed-off-by line, and preferrably a changelog that
explains what the patch is doing and (especially) why it is necessary.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: Is CONFIG_IP_VS_IPV6 still/really dangerous?
From: Julius Volz @ 2010-06-04 14:14 UTC (permalink / raw)
To: Ferenc Wagner; +Cc: netdev, robert.gallagher
In-Reply-To: <87631y3nr3.fsf@tac.ki.iif.hu>
Hi Ferenc,
On Fri, Jun 4, 2010 at 3:56 PM, Ferenc Wagner <wferi@niif.hu> wrote:
> Hi,
>
> In commit fab0de02fb0da83b90cec7fce4294747d86d5c6f CONFIG_IP_VS_IPV6 is
> described as:
>
> Add IPv6 support to IPVS. This is incomplete and might be dangerous.
>
> I agree its implementation is incomplete. But I wonder if it's really
> dangerous in the sense that generic distribution kernels shouldn't
> enable it, because it can break unrelated (eg. IPv4 IPVS) functionality.
>
> What does that warning mean today? Isn't it out of date?
I wrote the IPv6 support back in the day, but never used it
large-scale. Rob Gallagher from HEAnet was doing some bigger
experiments with it, but I'm not sure how far it went. CCing him.
There are probably some other people out there that have tested it
extensively. Maybe try the lvs-users and lvs-devel mailing lists?
http://www.linuxvirtualserver.org/mailing.html
Julius
--
Julius Volz - Site Reliability Engineer
Google Switzerland GmbH - Identification No.: CH-020.4.028.116-1
^ permalink raw reply
* Re: still having r8169 woes with XID 18000000
From: Phil Sutter @ 2010-06-04 13:43 UTC (permalink / raw)
To: Timo Teräs; +Cc: netdev, françois romieu
In-Reply-To: <4C08F953.1050800@iki.fi>
Hi,
On Fri, Jun 04, 2010 at 04:02:11PM +0300, Timo Teräs wrote:
> > Comparing r8169-6.013 with it's predecessor 6.012, you'll find a newly
> > enabled function rtl8169_phy_power_up() as well as some more invocations
> > of rtl8169_phy_power_down().
> >
> > This is probably the solution to these (at least in our case) very
> > sporadic, but highly annoying, problems. In fact, when our NIC didn't
> > detect any link, it needed a full power-cycle (no success with
> > reset-button), so almost not workaroundable.
>
> Sounds very similar to the problem I have. Thanks for the pointers!
>
> It looks like the r8169 driver does have phy power up code in it, but
> it's only executed for specific versions of the chip. Realtek driver
> seems to do it unconditionally.
Hmm. I actually never looked at the corresponding parts of the
in-tree-driver, but that would have definitely been the next step in
order to fix it.
> The check seems to be:
> if ((tp->mac_version == RTL_GIGA_MAC_VER_11) ||
> (tp->mac_version == RTL_GIGA_MAC_VER_12) ||
> (tp->mac_version >= RTL_GIGA_MAC_VER_17)) {
>
> I wonder if I should just add my mac version there (_VER_05) and test if
> it'll make it better.
Surely worth a try. On the other hand, looking at the sheer mass of
problem reports regarding this driver, making it worse is rather hard to
do I guess. :)
(Good night and) good luck, Phil
^ permalink raw reply
* [PATCH] [ath5k][leds] Ability to disable leds support. If leds support enabled do not force mac802.11 leds layer selection.
From: Dmytro Milinevskyy @ 2010-06-04 13:43 UTC (permalink / raw)
To: ath5k-devel
Cc: Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez, Bob Copeland,
John W. Linville, GeunSik Lim, Greg Kroah-Hartman, Lukas Turek,
Mark Hindley, Johannes Berg, Jiri Kosina, Kalle Valo, Keng-Yu Lin,
Luca Verdesca, Shahar Or, linux-wireless, netdev, linux-kernel
Hi!
Here is the patch to disable ath5k leds support on build stage.
However if the leds support was enabled do not force selection of 802.11 leds layer.
Depency on LEDS_CLASS is kept.
Suggestion given by Pavel Roskin and Bob Copeland applied.
Regards,
--Dima
---
drivers/net/wireless/ath/ath5k/Kconfig | 12 +++++++++---
drivers/net/wireless/ath/ath5k/Makefile | 2 +-
drivers/net/wireless/ath/ath5k/ath5k.h | 22 ++++++++++++++++++++++
drivers/net/wireless/ath/ath5k/base.h | 13 +++++++++----
drivers/net/wireless/ath/ath5k/gpio.c | 2 ++
5 files changed, 43 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/Kconfig b/drivers/net/wireless/ath/ath5k/Kconfig
index eb83b7b..29f4572 100644
--- a/drivers/net/wireless/ath/ath5k/Kconfig
+++ b/drivers/net/wireless/ath/ath5k/Kconfig
@@ -1,9 +1,6 @@
config ATH5K
tristate "Atheros 5xxx wireless cards support"
depends on PCI && MAC80211
- select MAC80211_LEDS
- select LEDS_CLASS
- select NEW_LEDS
---help---
This module adds support for wireless adapters based on
Atheros 5xxx chipset.
@@ -18,6 +15,15 @@ config ATH5K
If you choose to build a module, it'll be called ath5k. Say M if
unsure.
+
+config ATH5K_LEDS
+ tristate "Atheros 5xxx wireless cards LEDs support"
+ depends on ATH5K
+ select NEW_LEDS
+ select LEDS_CLASS
+ ---help---
+ Atheros 5xxx LED support.
+
config ATH5K_DEBUG
bool "Atheros 5xxx debugging"
depends on ATH5K
diff --git a/drivers/net/wireless/ath/ath5k/Makefile b/drivers/net/wireless/ath/ath5k/Makefile
index cc09595..6d552dd 100644
--- a/drivers/net/wireless/ath/ath5k/Makefile
+++ b/drivers/net/wireless/ath/ath5k/Makefile
@@ -10,8 +10,8 @@ ath5k-y += phy.o
ath5k-y += reset.o
ath5k-y += attach.o
ath5k-y += base.o
-ath5k-y += led.o
ath5k-y += rfkill.o
ath5k-y += ani.o
ath5k-$(CONFIG_ATH5K_DEBUG) += debug.o
+ath5k-$(CONFIG_ATH5K_LEDS) += led.o
obj-$(CONFIG_ATH5K) += ath5k.o
diff --git a/drivers/net/wireless/ath/ath5k/ath5k.h b/drivers/net/wireless/ath/ath5k/ath5k.h
index 2785946..bb7e09a 100644
--- a/drivers/net/wireless/ath/ath5k/ath5k.h
+++ b/drivers/net/wireless/ath/ath5k/ath5k.h
@@ -1148,11 +1148,27 @@ struct ath5k_hw {
int ath5k_hw_attach(struct ath5k_softc *sc);
void ath5k_hw_detach(struct ath5k_hw *ah);
+#ifdef CONFIG_ATH5K_LEDS
/* LED functions */
int ath5k_init_leds(struct ath5k_softc *sc);
void ath5k_led_enable(struct ath5k_softc *sc);
void ath5k_led_off(struct ath5k_softc *sc);
void ath5k_unregister_leds(struct ath5k_softc *sc);
+#else
+static inline int ath5k_init_leds(struct ath5k_softc *sc)
+{
+ return 0;
+}
+static inline void ath5k_led_enable(struct ath5k_softc *sc)
+{
+}
+static inline void ath5k_led_off(struct ath5k_softc *sc)
+{
+}
+static inline void ath5k_unregister_leds(struct ath5k_softc *sc)
+{
+}
+#endif
/* Reset Functions */
int ath5k_hw_nic_wakeup(struct ath5k_hw *ah, int flags, bool initial);
@@ -1233,7 +1249,13 @@ int ath5k_hw_set_slot_time(struct ath5k_hw *ah, unsigned int slot_time);
int ath5k_hw_init_desc_functions(struct ath5k_hw *ah);
/* GPIO Functions */
+#ifdef CONFIG_ATH5K_LEDS
void ath5k_hw_set_ledstate(struct ath5k_hw *ah, unsigned int state);
+#else
+static inline void ath5k_hw_set_ledstate(struct ath5k_hw *ah, unsigned int state)
+{
+}
+#endif
int ath5k_hw_set_gpio_input(struct ath5k_hw *ah, u32 gpio);
int ath5k_hw_set_gpio_output(struct ath5k_hw *ah, u32 gpio);
u32 ath5k_hw_get_gpio(struct ath5k_hw *ah, u32 gpio);
diff --git a/drivers/net/wireless/ath/ath5k/base.h b/drivers/net/wireless/ath/ath5k/base.h
index 56221bc..97b26c1 100644
--- a/drivers/net/wireless/ath/ath5k/base.h
+++ b/drivers/net/wireless/ath/ath5k/base.h
@@ -86,6 +86,7 @@ struct ath5k_txq {
#define ATH5K_LED_MAX_NAME_LEN 31
+#ifdef CONFIG_ATH5K_LEDS
/*
* State for LED triggers
*/
@@ -95,6 +96,7 @@ struct ath5k_led
struct ath5k_softc *sc; /* driver state */
struct led_classdev led_dev; /* led classdev */
};
+#endif
/* Rfkill */
struct ath5k_rfkill {
@@ -186,9 +188,6 @@ struct ath5k_softc {
u8 bssidmask[ETH_ALEN];
- unsigned int led_pin, /* GPIO pin for driving LED */
- led_on; /* pin setting for LED on */
-
struct tasklet_struct restq; /* reset tasklet */
unsigned int rxbufsize; /* rx size based on mtu */
@@ -196,7 +195,6 @@ struct ath5k_softc {
spinlock_t rxbuflock;
u32 *rxlink; /* link ptr in last RX desc */
struct tasklet_struct rxtq; /* rx intr tasklet */
- struct ath5k_led rx_led; /* rx led */
struct list_head txbuf; /* transmit buffer */
spinlock_t txbuflock;
@@ -204,7 +202,14 @@ struct ath5k_softc {
struct ath5k_txq txqs[AR5K_NUM_TX_QUEUES]; /* tx queues */
struct ath5k_txq *txq; /* main tx queue */
struct tasklet_struct txtq; /* tx intr tasklet */
+
+
+#ifdef CONFIG_ATH5K_LEDS
+ unsigned int led_pin, /* GPIO pin for driving LED */
+ led_on; /* pin setting for LED on */
+ struct ath5k_led rx_led; /* rx led */
struct ath5k_led tx_led; /* tx led */
+#endif
struct ath5k_rfkill rf_kill;
diff --git a/drivers/net/wireless/ath/ath5k/gpio.c b/drivers/net/wireless/ath/ath5k/gpio.c
index 64a27e7..9e757b3 100644
--- a/drivers/net/wireless/ath/ath5k/gpio.c
+++ b/drivers/net/wireless/ath/ath5k/gpio.c
@@ -25,6 +25,7 @@
#include "debug.h"
#include "base.h"
+#ifdef CONFIG_ATH5K_LEDS
/*
* Set led state
*/
@@ -76,6 +77,7 @@ void ath5k_hw_set_ledstate(struct ath5k_hw *ah, unsigned int state)
else
AR5K_REG_ENABLE_BITS(ah, AR5K_PCICFG, led_5210);
}
+#endif
/*
* Set GPIO inputs
--
1.7.1
^ permalink raw reply related
* [PATCH] htb: remove two unnecessary assignments
From: Changli Gao @ 2010-06-04 11:33 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: David S. Miller, netdev, Changli Gao
remove two unnecessary assignments
we don't need to assign NULL when initialize structure objects.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
----
net/sched/sch_htb.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/sched/sch_htb.c b/net/sched/sch_htb.c
index 0b52b8d..4be8d04 100644
--- a/net/sched/sch_htb.c
+++ b/net/sched/sch_htb.c
@@ -1550,7 +1550,6 @@ static const struct Qdisc_class_ops htb_class_ops = {
};
static struct Qdisc_ops htb_qdisc_ops __read_mostly = {
- .next = NULL,
.cl_ops = &htb_class_ops,
.id = "htb",
.priv_size = sizeof(struct htb_sched),
@@ -1561,7 +1560,6 @@ static struct Qdisc_ops htb_qdisc_ops __read_mostly = {
.init = htb_init,
.reset = htb_reset,
.destroy = htb_destroy,
- .change = NULL /* htb_change */,
.dump = htb_dump,
.owner = THIS_MODULE,
};
^ permalink raw reply related
* Re: net-next Build error in qlogic driver from randconfig.
From: andrew hendry @ 2010-06-04 13:23 UTC (permalink / raw)
To: netdev; +Cc: Amit Kumar Salecha, Anirban Chakraborty
In-Reply-To: <1275657622.8635.13.camel@jaunty>
sorry ignore, i see it just got fixed.
On Fri, Jun 4, 2010 at 11:20 PM, Andrew Hendry <andrew.hendry@gmail.com> wrote:
>
> net-next currently gives a build error from a randconfig.
> # CONFIG_INET is not set
> CONFIG_QLCNIC=m
>
> ERROR: "qlcnicvf_set_ilb_mode" [drivers/net/qlcnic/qlcnic.ko] undefined!
> ERROR: "qlcnicvf_config_bridged_mode" [drivers/net/qlcnic/qlcnic.ko] undefined!
> ERROR: "qlcnicvf_config_led" [drivers/net/qlcnic/qlcnic.ko] undefined!
> ERROR: "qlcnicvf_clear_ilb_mode" [drivers/net/qlcnic/qlcnic.ko] undefined!
> ERROR: "qlcnicvf_start_firmware" [drivers/net/qlcnic/qlcnic.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
> make: *** Waiting for unfinished jobs....
>
>
>
^ permalink raw reply
* net-next Build error in qlogic driver from randconfig.
From: Andrew Hendry @ 2010-06-04 13:20 UTC (permalink / raw)
To: netdev; +Cc: Amit Kumar Salecha, Anirban Chakraborty
net-next currently gives a build error from a randconfig.
# CONFIG_INET is not set
CONFIG_QLCNIC=m
ERROR: "qlcnicvf_set_ilb_mode" [drivers/net/qlcnic/qlcnic.ko] undefined!
ERROR: "qlcnicvf_config_bridged_mode" [drivers/net/qlcnic/qlcnic.ko] undefined!
ERROR: "qlcnicvf_config_led" [drivers/net/qlcnic/qlcnic.ko] undefined!
ERROR: "qlcnicvf_clear_ilb_mode" [drivers/net/qlcnic/qlcnic.ko] undefined!
ERROR: "qlcnicvf_start_firmware" [drivers/net/qlcnic/qlcnic.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
make: *** Waiting for unfinished jobs....
^ permalink raw reply
* Re: [PATCH net-next-2.6] net sched: make pedit check for clones instead
From: Herbert Xu @ 2010-06-04 13:05 UTC (permalink / raw)
To: jamal; +Cc: davem, Jiri Pirko, netdev
In-Reply-To: <1275655386.3445.62.camel@bigi>
On Fri, Jun 04, 2010 at 08:43:06AM -0400, jamal wrote:
> And here's the second one. I noticed Changli's changes are not yet in
> net-next. I will wait for that change to propagate and then send the
> fix to pedit that i discussed with Herbert.
Thanks Jamal!
BTW, I think this patch should go in first (before the one that
removes the OK2MUNGE setting) to be on the safe side.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <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
* Re: still having r8169 woes with XID 18000000
From: Timo Teräs @ 2010-06-04 13:02 UTC (permalink / raw)
To: phil; +Cc: netdev, françois romieu
In-Reply-To: <20100604123641.ED8154CD45@orbit.nwl.cc>
On 06/04/2010 03:36 PM, Phil Sutter wrote:
> On Fri, Jun 04, 2010 at 03:10:47PM +0300, Timo Teräs wrote:
>> After fixing the MAC issues earlier, I'm still seeing some weird trouble
>> with my RTL8169sc/8110sc / XID 18000000 boards.
>>
>> The box(es) were originally running 2.6.30.x kernel and everything
>> worked without major problems. But after upgrading to 2.6.32.x (and even
>> with most of the newer fixes included too), it seems that the sometimes
>> (not too often) some of the interfaces just won't work after reboot
>> (cold or hard). It's a 3-in-1 board, and usually when this happens one
>> of the interfaces won't work but the other two do work.
>>
>> Whenever an interface is "broken", the following conditions are true:
>> - forcing it to 10mbit/s and disabling autoneg will make it work
>> - when it's not working ethtool -S reports rx_errors and align_errors
>> increasing
>> - when autoneg is on, ethtool says that "Link Detected: no"
>
> This (your last point) is about what we were experiencing at work using
> PCI-based Gigabit Realtek NICs. Our solution to the problem was to
> switch to a different NIC (Intel e1000), which obviously solves any
> problems. ;)
>
> But I've done some tests before, mainly being inspired by these mails:
> http://permalink.gmane.org/gmane.linux.network/160136
> http://permalink.gmane.org/gmane.linux.network/160280
> and after some feedback from the mainboard manufacturer I've tested the
> out-of-tree driver Realtek provides (version 6.013.00), which seems to
> not have this issue. Very interesting results show up when comparing
> 6.013 with 6.012 (citing myself):
>
> Comparing r8169-6.013 with it's predecessor 6.012, you'll find a newly
> enabled function rtl8169_phy_power_up() as well as some more invocations
> of rtl8169_phy_power_down().
>
> This is probably the solution to these (at least in our case) very
> sporadic, but highly annoying, problems. In fact, when our NIC didn't
> detect any link, it needed a full power-cycle (no success with
> reset-button), so almost not workaroundable.
Sounds very similar to the problem I have. Thanks for the pointers!
It looks like the r8169 driver does have phy power up code in it, but
it's only executed for specific versions of the chip. Realtek driver
seems to do it unconditionally.
The check seems to be:
if ((tp->mac_version == RTL_GIGA_MAC_VER_11) ||
(tp->mac_version == RTL_GIGA_MAC_VER_12) ||
(tp->mac_version >= RTL_GIGA_MAC_VER_17)) {
I wonder if I should just add my mac version there (_VER_05) and test if
it'll make it better.
- Timo
^ permalink raw reply
* Re: [2.6.35-rc1] page alloc failure order:1, mode:0x4020
From: Eric Dumazet @ 2010-06-04 12:53 UTC (permalink / raw)
To: Michael Guntsche; +Cc: linux-kernel, netdev
In-Reply-To: <20100604092025.GA96690@trillian.comsick.at>
Le vendredi 04 juin 2010 à 11:20 +0200, Michael Guntsche a écrit :
> Hi list,
>
> Testing 2.6.35-rc1 on my powerpc based routerboard I saw the following page allocation
> error happening during an apt-get update with a semi loaded wlan
> interface
>
> [309611.189267] __alloc_pages_slowpath: 52 callbacks suppressed
> [309611.194959] gzip: page allocation failure. order:1, mode:0x4020
> [309611.200981] Call Trace:
> [309611.203547] [c399bc50] [c0008144] show_stack+0x48/0x15c (unreliable)
> [309611.210041] [c399bc80] [c006268c] __alloc_pages_nodemask+0x3d4/0x52c
> [309611.216512] [c399bd20] [c008619c] __slab_alloc+0x560/0x570
> [309611.222111] [c399bd60] [c0086a98] __kmalloc_track_caller+0xd4/0x104
> [309611.228505] [c399bd80] [c01dd220] __alloc_skb+0x64/0x124
> [309611.233944] [c399bda0] [c994e034] ath_rxbuf_alloc+0x34/0xbc [ath]
> [309611.240178] [c399bdc0] [c9a1ec9c] ath_rx_tasklet+0x480/0x7c4 [ath9k]
> [309611.246658] [c399be80] [c9a1dae0] ath9k_tasklet+0x114/0x13c [ath9k]
> [309611.253055] [c399bea0] [c002532c] tasklet_action+0x88/0x104
> [309611.258746] [c399bec0] [c0025e30] __do_softirq+0xb4/0x134
> [309611.264261] [c399bf00] [c0005ec4] do_softirq+0x58/0x5c
> [309611.269514] [c399bf10] [c0025c20] irq_exit+0x7c/0x9c
> [309611.274591] [c399bf20] [c0005f64] do_IRQ+0x9c/0xb4
> [309611.279509] [c399bf40] [c00117d8] ret_from_except+0x0/0x14
> [309611.285112] --- Exception: 501 at 0xff31f0c
> [309611.285121] LR = 0xff32548
> [309611.292536] Mem-Info:
> [309611.294899] DMA per-cpu:
> [309611.297528] CPU 0: hi: 42, btch: 7 usd: 18
> [309611.302444] active_anon:1040 inactive_anon:1160 isolated_anon:0
> [309611.302455] active_file:14871 inactive_file:9440 isolated_file:0
> [309611.302467] unevictable:491 dirty:1258 writeback:0 unstable:0
> [309611.302478] free:628 slab_reclaimable:832 slab_unreclaimable:2312
> [309611.302490] mapped:2254 shmem:36 pagetables:202 bounce:0
> [309611.332409] DMA free:2512kB min:1440kB low:1800kB high:2160kB active_anon:4160kB inactive_anon:4640kB active_file:59484kB inactive_file:37760kB unevictable:1964kB isolated(anon):0kB isolated(file):0kB present:130048kB mlocked:1964kB dirty:5032kB writeback:0kB mapped:9016kB shmem:144kB slab_reclaimable:3328kB slab_unreclaimable:9248kB kernel_stack:528kB pagetables:808kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
> [309611.372230] lowmem_reserve[]: 0 0 0
> [309611.375835] DMA: 596*4kB 14*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 2512kB
> [309611.386215] 24770 total pagecache pages
> [309611.390147] 0 pages in swap cache
> [309611.393559] Swap cache stats: add 0, delete 0, find 0/0
> [309611.398884] Free swap = 0kB
> [309611.401857] Total swap = 0kB
> [309611.411877] 32768 pages RAM
> [309611.414765] 1228 pages reserved
> [309611.418000] 27690 pages shared
> [309611.421147] 8802 pages non-shared
> [309611.424560] SLUB: Unable to allocate memory on node -1 (gfp=0x20)
> [309611.430764] cache: kmalloc-8192, object size: 8192, buffer size: 8192, default order: 3, min order: 1
> [309611.440276] node 0: slabs: 155, objs: 620, free: 0
> [309611.445439] skbuff alloc of size 3872 failed
order-1 allocations are unfortunate, since this hardware should use
order-0 ones if possible, and it seems it was its goal.
3872 (0xF20) comes from
#define IEEE80211_MAX_MPDU_LEN (3840 + FCS_LEN +
(IEEE80211_WEP_IVLEN + \
IEEE80211_WEP_KIDLEN + \
IEEE80211_WEP_CRCLEN))
common->rx_bufsize = roundup(IEEE80211_MAX_MPDU_LEN +
ah->caps.rx_status_len,
min(common->cachelsz, (u16)64));
Then __dev_alloc_skb() adds two more blocs :
NET_SKB_PAD (64 bytes on your platform ?)
sizeof(struct skb_shared_info)
(on 32bit : 0x104 ... oh well that might be the problem : it is rounded
to 0x140)
And ath driver adds common->cachelsz (I dont know its value)
-> more than 4096 bytes
1) Maybe rx_bufsize should not include the roundup() since
ath_rxbuf_alloc() also do an alignment adjustment ?
2) We should try to reduce skb_shared_info by four bytes.
Could you try this patch ?
We make sure rx_bufsize + various overhead <= PAGE_SIZE
But I am not sure its legal for the hardware...
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index ca6065b..0a0dc3a 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -226,10 +226,10 @@ static int ath_rx_edma_init(struct ath_softc *sc, int nbufs)
u32 size;
- common->rx_bufsize = roundup(IEEE80211_MAX_MPDU_LEN +
- ah->caps.rx_status_len,
- min(common->cachelsz, (u16)64));
-
+ size = roundup(IEEE80211_MAX_MPDU_LEN + ah->caps.rx_status_len,
+ min(common->cachelsz, (u16)64));
+ common->rx_bufsize = max_t(u32, size,
+ SKB_MAX_ORDER(NET_SKB_PAD + common->cachelsz, 0));
ath9k_hw_set_rx_bufsize(ah, common->rx_bufsize -
ah->caps.rx_status_len);
^ permalink raw reply related
* [PATCH net-next-2.6] net sched: make pedit check for clones instead
From: jamal @ 2010-06-04 12:43 UTC (permalink / raw)
To: davem; +Cc: Herbert Xu, Jiri Pirko, netdev
[-- Attachment #1: Type: text/plain, Size: 198 bytes --]
And here's the second one. I noticed Changli's changes are not yet in
net-next. I will wait for that change to propagate and then send the
fix to pedit that i discussed with Herbert.
cheers,
jamal
[-- Attachment #2: pedit1 --]
[-- Type: text/plain, Size: 806 bytes --]
commit 0697bf778d48d155ef48f652cee8f103db3dcedb
Author: Jamal Hadi Salim <hadi@cyberus.ca>
Date: Fri Jun 4 08:39:47 2010 -0400
net sched: make pedit check for clones instead
Now that the core path doesnt set OK to munge we detect
writable skbs by looking to see if they are cloned.
Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
diff --git a/net/sched/act_pedit.c b/net/sched/act_pedit.c
index fdbd0b7..8d15caf 100644
--- a/net/sched/act_pedit.c
+++ b/net/sched/act_pedit.c
@@ -127,8 +127,7 @@ static int tcf_pedit(struct sk_buff *skb, struct tc_action *a,
int i, munged = 0;
u8 *pptr;
- if (!(skb->tc_verd & TC_OK2MUNGE)) {
- /* should we set skb->cloned? */
+ if (skb_cloned(skb)) {
if (pskb_expand_head(skb, 0, 0, GFP_ATOMIC)) {
return p->tcf_action;
}
^ permalink raw reply related
* Re: still having r8169 woes with XID 18000000
From: Phil Sutter @ 2010-06-04 12:36 UTC (permalink / raw)
To: Timo Teräs; +Cc: françois romieu, netdev
In-Reply-To: <4C08ED47.1030800@iki.fi>
Hi,
On Fri, Jun 04, 2010 at 03:10:47PM +0300, Timo Teräs wrote:
> After fixing the MAC issues earlier, I'm still seeing some weird trouble
> with my RTL8169sc/8110sc / XID 18000000 boards.
>
> The box(es) were originally running 2.6.30.x kernel and everything
> worked without major problems. But after upgrading to 2.6.32.x (and even
> with most of the newer fixes included too), it seems that the sometimes
> (not too often) some of the interfaces just won't work after reboot
> (cold or hard). It's a 3-in-1 board, and usually when this happens one
> of the interfaces won't work but the other two do work.
>
> Whenever an interface is "broken", the following conditions are true:
> - forcing it to 10mbit/s and disabling autoneg will make it work
> - when it's not working ethtool -S reports rx_errors and align_errors
> increasing
> - when autoneg is on, ethtool says that "Link Detected: no"
This (your last point) is about what we were experiencing at work using
PCI-based Gigabit Realtek NICs. Our solution to the problem was to
switch to a different NIC (Intel e1000), which obviously solves any
problems. ;)
But I've done some tests before, mainly being inspired by these mails:
http://permalink.gmane.org/gmane.linux.network/160136
http://permalink.gmane.org/gmane.linux.network/160280
and after some feedback from the mainboard manufacturer I've tested the
out-of-tree driver Realtek provides (version 6.013.00), which seems to
not have this issue. Very interesting results show up when comparing
6.013 with 6.012 (citing myself):
Comparing r8169-6.013 with it's predecessor 6.012, you'll find a newly
enabled function rtl8169_phy_power_up() as well as some more invocations
of rtl8169_phy_power_down().
This is probably the solution to these (at least in our case) very
sporadic, but highly annoying, problems. In fact, when our NIC didn't
detect any link, it needed a full power-cycle (no success with
reset-button), so almost not workaroundable.
HTH, Phil
^ permalink raw reply
* Re: [RFC nf-next-2.6] conntrack: per cpu nf_conntrack_untracked
From: Eric Dumazet @ 2010-06-04 12:36 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Changli Gao, Netfilter Developers, netdev
In-Reply-To: <4C08F1A4.2050906@trash.net>
Le vendredi 04 juin 2010 à 14:29 +0200, Patrick McHardy a écrit :
> Changli Gao wrote:
> > On Fri, Jun 4, 2010 at 7:40 PM, Patrick McHardy <kaber@trash.net> wrote:
> >> Eric Dumazet wrote:
> >>> Obviously, an IPS_UNTRACKED bit would be much easier to implement.
> >>> Would it be acceptable ?
> >> That also would be fine. However the main idea behind using a nfctinfo
> >> bit was that we wouldn't need the untracked conntrack anymore at all.
> >> But I guess a per-cpu untrack conntrack would already be an improvement
> >> over the current situation.
> >
> > I think Eric didn't mean ip_conntrack_info but ip_conntrack_status
> > bit. Since we have had a IPS_TEMPLATE bit, I think another
> > IPS_UNTRACKED bit is also acceptable.
>
> Yes, of course. But using one of these bits implies that we'd still
> have the untracked conntrack.
Yes, it was my idea, with a per_cpu untracked conntrack.
I'll submit a patch, 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
* Re: [RFC nf-next-2.6] conntrack: per cpu nf_conntrack_untracked
From: Patrick McHardy @ 2010-06-04 12:29 UTC (permalink / raw)
To: Changli Gao; +Cc: Eric Dumazet, Netfilter Developers, netdev
In-Reply-To: <AANLkTilKEpFTg5bH8d9UE3a3DVJNAGYz10Jgkt6lXtJ0@mail.gmail.com>
Changli Gao wrote:
> On Fri, Jun 4, 2010 at 7:40 PM, Patrick McHardy <kaber@trash.net> wrote:
>> Eric Dumazet wrote:
>>> Obviously, an IPS_UNTRACKED bit would be much easier to implement.
>>> Would it be acceptable ?
>> That also would be fine. However the main idea behind using a nfctinfo
>> bit was that we wouldn't need the untracked conntrack anymore at all.
>> But I guess a per-cpu untrack conntrack would already be an improvement
>> over the current situation.
>
> I think Eric didn't mean ip_conntrack_info but ip_conntrack_status
> bit. Since we have had a IPS_TEMPLATE bit, I think another
> IPS_UNTRACKED bit is also acceptable.
Yes, of course. But using one of these bits implies that we'd still
have the untracked conntrack.
^ 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