* Re: [PATCH] net: reset gso header when the copied skb is linearized
From: David Miller @ 2010-10-26 18:31 UTC (permalink / raw)
To: fleitner; +Cc: netdev, herbert
In-Reply-To: <1288045398-3110-1-git-send-email-fleitner@redhat.com>
From: Flavio Leitner <fleitner@redhat.com>
Date: Mon, 25 Oct 2010 20:23:18 -0200
> The gso header is incorrect when the copied skb is
> linearized. This patch creates another helper function
> to copy the gso header when it is appropriated
>
> Signed-off-by: Flavio Leitner <fleitner@redhat.com>
I don't understand why the GSO information should be
omitted just because we are creating a linearlized
version of the SKB?
The packet still could have a larger than MSS size,
and thus be composed of multiple actual segments for
the network.
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-10-26
From: David Miller @ 2010-10-26 18:32 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20101026181515.GD2446@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 26 Oct 2010 14:15:16 -0400
> Here are some fixes intended for 2.6.37. Highlights are some carl9170
> fixes, a fix/cleanup for the earlier wl1251 move, various ath9k fixes,
> a mac80211 fix relating to IBSS station expiry and a cfg80211 fix
> related to processing country IEs. One of the ath9k patches looks big,
> but it is just changing a table of register initialization values in
> order to correct a number of issues. The associated changelogs are
> reasonably descriptive of the issues involved.
>
> Also included is a patch from Tejun as part of his work to remove
> flush_scheduled_work(). I noticed you already included a similar
> patch from Tejun, so I figured this was acceptable as well.
Pulled, thanks John.
^ permalink raw reply
* Re: [PATCH] tg3: Do not call device_set_wakeup_enable() under spin_lock_bh
From: David Miller @ 2010-10-26 18:34 UTC (permalink / raw)
To: rjw; +Cc: mcarlson, mchan, netdev, maximlevitsky
In-Reply-To: <201010260101.56128.rjw@sisk.pl>
From: "Rafael J. Wysocki" <rjw@sisk.pl>
Date: Tue, 26 Oct 2010 01:01:55 +0200
> From: Rafael J. Wysocki <rjw@sisk.pl>
>
> The tg3 driver calls device_set_wakeup_enable() under spin_lock_bh,
> which causes a problem to happen after the recent core power
> management changes, because this function can sleep now. Fix this
> by moving the device_set_wakeup_enable() call out of the
> spin_lock_bh-protected area.
>
> Reported-by: Maxim Levitsky <maximlevitsky@gmail.com>
> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Applied, thanks a lot.
^ permalink raw reply
* Re: kernel panic in fib_rules_lookup [2.6.27.7 vendor-patched]
From: David Miller @ 2010-10-26 18:43 UTC (permalink / raw)
To: eric.dumazet; +Cc: sysoleg, netdev, aspam
In-Reply-To: <1287863065.2658.533.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 23 Oct 2010 21:44:25 +0200
> [PATCH] fib: fix fib_nl_newrule()
>
> Some panic reports in fib_rules_lookup() show a rule could have a NULL
> pointer as a next pointer in the rules_list.
>
> This can actually happen because of a bug in fib_nl_newrule() : It
> checks if current rule is the destination of unresolved gotos. (Other
> rules have gotos to this about to be inserted rule)
>
> Problem is it does the resolution of the gotos before the rule is
> inserted in the rules_list (and has a valid next pointer)
>
> Fix this by moving the rules_list insertion before the changes on gotos.
>
> A lockless reader can not any more follow a ctarget pointer, unless
> destination is ready (has a valid next pointer)
>
> Reported-by: Oleg A. Arkhangelsky <sysoleg@yandex.ru>
> Reported-by: Joe Buehler <aspam@cox.net>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] fib_hash: fix rcu sparse and logical errors
From: David Miller @ 2010-10-26 18:43 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1288099456.3169.110.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 26 Oct 2010 15:24:16 +0200
> While fixing CONFIG_SPARSE_RCU_POINTER errors, I had to fix accesses to
> fz->fz_hash for real.
>
> - &fz->fz_hash[fn_hash(f->fn_key, fz)]
> + rcu_dereference(fz->fz_hash) + fn_hash(f->fn_key, fz)
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ehea: Fixing statistics
From: Eric Dumazet @ 2010-10-26 18:48 UTC (permalink / raw)
To: leitao; +Cc: davem, netdev
In-Reply-To: <1288116213-11801-1-git-send-email-leitao@linux.vnet.ibm.com>
Le mardi 26 octobre 2010 à 14:03 -0400, leitao@linux.vnet.ibm.com a
écrit :
> @@ -2296,6 +2314,7 @@ static int ehea_start_xmit(struct sk_buff *skb, struct net_device *dev)
>
> ehea_post_swqe(pr->qp, swqe);
> pr->tx_packets++;
> + pr->tx_bytes += skb->len;
>
> if (unlikely(atomic_read(&pr->swqe_avail) <= 1)) {
> spin_lock_irqsave(&pr->netif_queue, flags);
This seems very suspicious to me. Lets take a look at this driver.
ehea_xmit3() frees the skb.
Yet, you happily use skb after it... kaboom...
Note: driver already uses skb after its freeing, before your patch.
if (vlan_tx_tag_present(skb)) {
swqe->tx_control |= EHEA_SWQE_VLAN_INSERT;
swqe->vlan_tag = vlan_tx_tag_get(skb);
}
How can it works ?
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2] can: Topcliff: PCH_CAN driver: Fix build warnings
From: Marc Kleine-Budde @ 2010-10-26 18:52 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
sameo-VuQAYsv1563Yd54FQh9/CA,
margie.foster-ral2JQCrhuEAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w,
masa-korg-ECg8zkTtlr0C6LszWs/t0g,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w, chripell-VaTbYqLCNhc,
morinaga526-ECg8zkTtlr0C6LszWs/t0g, David Miller,
joel.clark-ral2JQCrhuEAvxtiuMwx3w, qi.wang-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <4CC71DA4.3020600-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 946 bytes --]
On 10/26/2010 08:27 PM, Wolfgang Grandegger wrote:
> Oh, this patch has various other issues, as Marc and I have already
> pointed out, which should be fixed before the driver hits the user.
> Unfortunately, the CC to netdev of our reviews got lost somehow, sorry
After noticing my faul I resend my review to the netdev + socketcan
mailinglists and the individual persons mentioned in the original patch.
> for the inconvenience, but the original author should have received it.
> Tomoya, could you (or somebody else) please also fix the remaining
> issues quickly?
For reference, here it is:
http://www.spinics.net/lists/netdev/msg144852.html
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: [STABLE 2.6.32 PATCH] net: release dst entry while cache-hot for GSO case too
From: David Miller @ 2010-10-26 18:54 UTC (permalink / raw)
To: eric.dumazet; +Cc: avagin, mjt, avagin, stable, netdev, krkumar2
In-Reply-To: <1286814652.2737.41.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 11 Oct 2010 18:30:52 +0200
> Le lundi 11 octobre 2010 à 20:19 +0400, Andrew Vagin a écrit :
>> On 10/11/2010 07:59 PM, David Miller wrote:
>> > From: Eric Dumazet<eric.dumazet@gmail.com>
>> > Date: Mon, 11 Oct 2010 17:46:49 +0200
>> >
>> >> This patch was an optimization, not a bug fix.
>> > Right, this has no business going into 2.6.32-stable at all.
>> This is bug fix. Now nobody drops dst in case gso and veth, because the
>> commit 60df914e295a21a223e43a7ee01e0c73c64dd111 deletes skb_dst_drop
>> from the veth.c. We should commit my patch or revert commit 60df914e.
>>
>> We have two bug reports:
>>
>> http://www.spinics.net/lists/netdev/msg142104.html
>>
>> http://bugzilla.openvz.org/show_bug.cgi?id=1634
>>
>> Taylan verified that the patch really fix his bug.
>
> Now that makes sense ;)
In case there is any doubt about this -stable patch submission:
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH] ipv4: Flush per-ns routing cache more sanely.
From: Eric Dumazet @ 2010-10-26 18:57 UTC (permalink / raw)
To: David Miller; +Cc: netdev, daniel.lezcano, ebiederm
In-Reply-To: <20101026.103428.179941457.davem@davemloft.net>
Le mardi 26 octobre 2010 à 10:34 -0700, David Miller a écrit :
> Flush the routing cache only of entries that match the
> network namespace in which the purge event occurred.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
>
> Could I get some testing and performance analysis feedback
> on this change? I don't want it to just die :-)
>
I believe its fine, thanks !
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
I'll respin my __rcu patch, of course.
^ permalink raw reply
* Re: [PATCH] ipv4: Flush per-ns routing cache more sanely.
From: Daniel Lezcano @ 2010-10-26 18:57 UTC (permalink / raw)
To: David Miller; +Cc: netdev, ebiederm
In-Reply-To: <20101026.103428.179941457.davem@davemloft.net>
On 10/26/2010 07:34 PM, David Miller wrote:
> Flush the routing cache only of entries that match the
> network namespace in which the purge event occurred.
>
> Signed-off-by: David S. Miller<davem@davemloft.net>
> ---
>
> Could I get some testing and performance analysis feedback
> on this change? I don't want it to just die :-)
>
Ok, will do in a couple of days.
Thanks
-- Daniel
^ permalink raw reply
* Re: [PATCH] ipv4: Flush per-ns routing cache more sanely.
From: Eric W. Biederman @ 2010-10-26 19:05 UTC (permalink / raw)
To: David Miller; +Cc: netdev, daniel.lezcano
In-Reply-To: <20101026.103428.179941457.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> Flush the routing cache only of entries that match the
> network namespace in which the purge event occurred.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
>
> Could I get some testing and performance analysis feedback
> on this change? I don't want it to just die :-)
>
> THanks!
>
> diff --git a/include/net/route.h b/include/net/route.h
> index 7e5e73b..8d24761 100644
> --- a/include/net/route.h
> +++ b/include/net/route.h
> @@ -106,7 +106,7 @@ extern int ip_rt_init(void);
> extern void ip_rt_redirect(__be32 old_gw, __be32 dst, __be32 new_gw,
> __be32 src, struct net_device *dev);
> extern void rt_cache_flush(struct net *net, int how);
> -extern void rt_cache_flush_batch(void);
> +extern void rt_cache_flush_batch(struct net *net);
> extern int __ip_route_output_key(struct net *, struct rtable **, const struct flowi *flp);
> extern int ip_route_output_key(struct net *, struct rtable **, struct flowi *flp);
> extern int ip_route_output_flow(struct net *, struct rtable **rp, struct flowi *flp, struct sock *sk, int flags);
> diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
> index 36e27c2..828d471 100644
> --- a/net/ipv4/fib_frontend.c
> +++ b/net/ipv4/fib_frontend.c
> @@ -999,7 +999,7 @@ static int fib_netdev_event(struct notifier_block *this, unsigned long event, vo
> rt_cache_flush(dev_net(dev), 0);
> break;
> case NETDEV_UNREGISTER_BATCH:
> - rt_cache_flush_batch();
> + rt_cache_flush_batch(dev_net(dev));
It still has this incorrect conversion in it.
Eric
^ permalink raw reply
* Re: [PATCH linux-2.6 v2] IPv6: Temp addresses are immediately deleted.
From: David Miller @ 2010-10-26 19:19 UTC (permalink / raw)
To: gwurster
Cc: kuznet, pekkas, jmorris, yoshfuji, kaber, shemminger,
eric.dumazet, herbert, ebiederm, netdev, linux-kernel
In-Reply-To: <201010161442.18748.gwurster@scs.carleton.ca>
From: Glenn Wurster <gwurster@scs.carleton.ca>
Date: Sat, 16 Oct 2010 14:42:17 -0400
> This patch accommodates the case where the router is only broadcasting
> advertisements every x seconds, and yet the user has set the valid_lft to be
> something less than x. In this setup, the condition I mentioned in the patch
> description happens, where the new temporary address is created, but the last
> modification time on that temporary address is set to the time of the last
> router advertisement, which was more than valid_lft seconds ago. In this
> case, the temporary address is immediately deleted, and we are left with no
> temporary address on the interface. Furthermore, because all temporary
> addresses get deleted by the time the next router advertisement arrives, we
> are left with not being able to use temporary addresses until we move
> networks.
Thanks for the information, I'll look into this some more.
^ permalink raw reply
* Re: [PATCH] ipv4: Flush per-ns routing cache more sanely.
From: David Miller @ 2010-10-26 19:20 UTC (permalink / raw)
To: ebiederm; +Cc: netdev, daniel.lezcano
In-Reply-To: <m1sjzs3hbw.fsf@fess.ebiederm.org>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Tue, 26 Oct 2010 12:05:39 -0700
>> @@ -999,7 +999,7 @@ static int fib_netdev_event(struct notifier_block *this, unsigned long event, vo
>> rt_cache_flush(dev_net(dev), 0);
>> break;
>> case NETDEV_UNREGISTER_BATCH:
>> - rt_cache_flush_batch();
>> + rt_cache_flush_batch(dev_net(dev));
>
> It still has this incorrect conversion in it.
Sorry I missed that, what's the exact problem with it?
^ permalink raw reply
* [PATCH] fib_rules: __rcu annotates ctarget
From: Eric Dumazet @ 2010-10-26 19:24 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Adds __rcu annotation to (struct fib_rule)->ctarget
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/net/fib_rules.h | 2 +-
net/core/fib_rules.c | 11 ++++++-----
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/include/net/fib_rules.h b/include/net/fib_rules.h
index 106f309..075f1e3 100644
--- a/include/net/fib_rules.h
+++ b/include/net/fib_rules.h
@@ -20,7 +20,7 @@ struct fib_rule {
u32 table;
u8 action;
u32 target;
- struct fib_rule * ctarget;
+ struct fib_rule __rcu *ctarget;
char iifname[IFNAMSIZ];
char oifname[IFNAMSIZ];
struct rcu_head rcu;
diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c
index 12b43cc..82a4369 100644
--- a/net/core/fib_rules.c
+++ b/net/core/fib_rules.c
@@ -351,12 +351,12 @@ static int fib_nl_newrule(struct sk_buff *skb, struct nlmsghdr* nlh, void *arg)
list_for_each_entry(r, &ops->rules_list, list) {
if (r->pref == rule->target) {
- rule->ctarget = r;
+ RCU_INIT_POINTER(rule->ctarget, r);
break;
}
}
- if (rule->ctarget == NULL)
+ if (rcu_dereference_protected(rule->ctarget, 1) == NULL)
unresolved = 1;
} else if (rule->action == FR_ACT_GOTO)
goto errout_free;
@@ -386,7 +386,7 @@ static int fib_nl_newrule(struct sk_buff *skb, struct nlmsghdr* nlh, void *arg)
list_for_each_entry(r, &ops->rules_list, list) {
if (r->action == FR_ACT_GOTO &&
r->target == rule->pref) {
- BUG_ON(r->ctarget != NULL);
+ BUG_ON(rtnl_dereference(r->ctarget) != NULL);
rcu_assign_pointer(r->ctarget, rule);
if (--ops->unresolved_rules == 0)
break;
@@ -487,7 +487,7 @@ static int fib_nl_delrule(struct sk_buff *skb, struct nlmsghdr* nlh, void *arg)
*/
if (ops->nr_goto_rules > 0) {
list_for_each_entry(tmp, &ops->rules_list, list) {
- if (tmp->ctarget == rule) {
+ if (rtnl_dereference(tmp->ctarget) == rule) {
rcu_assign_pointer(tmp->ctarget, NULL);
ops->unresolved_rules++;
}
@@ -545,7 +545,8 @@ static int fib_nl_fill_rule(struct sk_buff *skb, struct fib_rule *rule,
frh->action = rule->action;
frh->flags = rule->flags;
- if (rule->action == FR_ACT_GOTO && rule->ctarget == NULL)
+ if (rule->action == FR_ACT_GOTO &&
+ rcu_dereference_raw(rule->ctarget) == NULL)
frh->flags |= FIB_RULE_UNRESOLVED;
if (rule->iifname[0]) {
^ permalink raw reply related
* Re: [PATCH] net: reset gso header when the copied skb is linearized
From: Flavio Leitner @ 2010-10-26 19:25 UTC (permalink / raw)
To: David Miller; +Cc: netdev, herbert
In-Reply-To: <20101026.113157.233700961.davem@davemloft.net>
On Tue, Oct 26, 2010 at 11:31:57AM -0700, David Miller wrote:
> From: Flavio Leitner <fleitner@redhat.com>
> Date: Mon, 25 Oct 2010 20:23:18 -0200
>
> > The gso header is incorrect when the copied skb is
> > linearized. This patch creates another helper function
> > to copy the gso header when it is appropriated
> >
> > Signed-off-by: Flavio Leitner <fleitner@redhat.com>
>
> I don't understand why the GSO information should be
> omitted just because we are creating a linearlized
> version of the SKB?
If I understand that correctly, the gso_segs is the number
of GSO segments which are divided in non-linear way. When the
copy is made using that function, the skb turns into a big
one segment inlined. So, the idea of segments is lost and
I'm not seeing how it is going to be divided again.
Later the NIC drives does, for example:
drivers/net/e1000/e1000_main.c
...
if (cleaned) {
struct sk_buff *skb = buffer_info->skb;
unsigned int segs, bytecount;
segs = skb_shinfo(skb)->gso_segs ?: 1;
/* multiply data chunks by size of * headers */
bytecount = ((segs - 1) * skb_headlen(skb)) +
skb->len;
total_tx_packets += segs;
total_tx_bytes += bytecount;
}
...
The bytecount there will be wrong because it will multiply
the old gso_segs X skb_headlen(skb) which will be the entire
skb as the payload is inlined.
I see that there are some places checking for skb_is_gso()
before do something or calculating using that math above.
> The packet still could have a larger than MSS size,
> and thus be composed of multiple actual segments for
> the network.
hopefully I answered this too in my previous comment
thanks,
--
Flavio
^ permalink raw reply
* Re: [PATCH] net: reset gso header when the copied skb is linearized
From: David Miller @ 2010-10-26 19:28 UTC (permalink / raw)
To: fleitner; +Cc: netdev, herbert
In-Reply-To: <20101026192511.GA3494@redhat.com>
From: Flavio Leitner <fleitner@redhat.com>
Date: Tue, 26 Oct 2010 17:25:11 -0200
> If I understand that correctly, the gso_segs is the number
> of GSO segments which are divided in non-linear way. When the
> copy is made using that function, the skb turns into a big
> one segment inlined. So, the idea of segments is lost and
> I'm not seeing how it is going to be divided again.
> Later the NIC drives does, for example:
GSO has nothing to do with linearity, although it just so happens
to be that GSO packets tend to be non-linear due to the way
TCP builds such frames.
The GSO segment count is the number of MSS sized frames are
contained inside of a larger than MSS sized SKB.
That is it. So the definition and meaning is independent of
linearity.
Thus, if we linearize a larger than MSS sized frame, it should still
have the same GSO attributes.
^ permalink raw reply
* Re: [PATCH] ipv4: Flush per-ns routing cache more sanely.
From: Eric Dumazet @ 2010-10-26 19:30 UTC (permalink / raw)
To: David Miller; +Cc: ebiederm, netdev, daniel.lezcano
In-Reply-To: <20101026.122022.241452738.davem@davemloft.net>
Le mardi 26 octobre 2010 à 12:20 -0700, David Miller a écrit :
> From: ebiederm@xmission.com (Eric W. Biederman)
> Date: Tue, 26 Oct 2010 12:05:39 -0700
>
> >> @@ -999,7 +999,7 @@ static int fib_netdev_event(struct notifier_block *this, unsigned long event, vo
> >> rt_cache_flush(dev_net(dev), 0);
> >> break;
> >> case NETDEV_UNREGISTER_BATCH:
> >> - rt_cache_flush_batch();
> >> + rt_cache_flush_batch(dev_net(dev));
> >
> > It still has this incorrect conversion in it.
>
> Sorry I missed that, what's the exact problem with it?
Because the way _BATCH operation is performed, we call it once...
rollback_registered_many() calls it for the first dev queued in the
list.
So it should be net independant.
^ permalink raw reply
* netlink stats: Ability to get stats for a single device?
From: Ben Greear @ 2010-10-26 19:31 UTC (permalink / raw)
To: NetDev
From what I can tell, it's impossible to request stats for a single
network device via netlink. When you have thousands of interfaces,
this means a lot of wasted effort to get stats for a particular
device.
Am I missing something, or do I just need to write up a patch
to have netlink pay attention to the ifindex?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: netlink stats: Ability to get stats for a single device?
From: Eric Dumazet @ 2010-10-26 19:35 UTC (permalink / raw)
To: Ben Greear; +Cc: NetDev
In-Reply-To: <4CC72C80.9010802@candelatech.com>
Le mardi 26 octobre 2010 à 12:31 -0700, Ben Greear a écrit :
> From what I can tell, it's impossible to request stats for a single
> network device via netlink. When you have thousands of interfaces,
> this means a lot of wasted effort to get stats for a particular
> device.
>
> Am I missing something, or do I just need to write up a patch
> to have netlink pay attention to the ifindex?
>
Its already done
rtnl_register(PF_UNSPEC, RTM_GETLINK, rtnl_getlink, rtnl_dump_ifinfo);
^ permalink raw reply
* Re: netlink stats: Ability to get stats for a single device?
From: David Miller @ 2010-10-26 19:38 UTC (permalink / raw)
To: greearb; +Cc: netdev
In-Reply-To: <4CC72C80.9010802@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
Date: Tue, 26 Oct 2010 12:31:12 -0700
> Am I missing something, or do I just need to write up a patch
> to have netlink pay attention to the ifindex?
Setting the ->ifi_index or IFLA_IFNAME attribute values appropriately
in the getlink request doesn't work?
That should give you back, amonst other things, the rtnl_link_stats
for the device in the netlink response.
^ permalink raw reply
* Re: [PATCH] net: reset gso header when the copied skb is linearized
From: Herbert Xu @ 2010-10-26 19:38 UTC (permalink / raw)
To: David Miller; +Cc: fleitner, netdev
In-Reply-To: <20101026.122801.52191238.davem@davemloft.net>
On Tue, Oct 26, 2010 at 12:28:01PM -0700, David Miller wrote:
>
> Thus, if we linearize a larger than MSS sized frame, it should still
> have the same GSO attributes.
I agree with you on all counts :)
--
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
* Re: [PATCH linux-2.6 v2] IPv6: Temp addresses are immediately deleted.
From: David Miller @ 2010-10-26 19:38 UTC (permalink / raw)
To: gwurster
Cc: kuznet, pekkas, jmorris, yoshfuji, kaber, shemminger,
eric.dumazet, herbert, ebiederm, netdev, linux-kernel
In-Reply-To: <201010161442.18748.gwurster@scs.carleton.ca>
From: Glenn Wurster <gwurster@scs.carleton.ca>
Date: Sat, 16 Oct 2010 14:42:17 -0400
> No, the first patch was to create a temporary address if none exists. Like
> Brian Haley pointed out, that patch accommodates the case where we set
> use_tempaddr to a non-zero value after the interface had been brought up.
>
> This patch accommodates the case where the router is only broadcasting
> advertisements every x seconds, and yet the user has set the valid_lft to be
> something less than x.
Ok, thanks for your patience.
I've applied both of your patches, thanks.
^ permalink raw reply
* Re: netlink stats: Ability to get stats for a single device?
From: Eric Dumazet @ 2010-10-26 19:56 UTC (permalink / raw)
To: David Miller; +Cc: greearb, netdev
In-Reply-To: <20101026.123811.13746869.davem@davemloft.net>
Le mardi 26 octobre 2010 à 12:38 -0700, David Miller a écrit :
> From: Ben Greear <greearb@candelatech.com>
> Date: Tue, 26 Oct 2010 12:31:12 -0700
>
> > Am I missing something, or do I just need to write up a patch
> > to have netlink pay attention to the ifindex?
>
> Setting the ->ifi_index or IFLA_IFNAME attribute values appropriately
> in the getlink request doesn't work?
>
> That should give you back, amonst other things, the rtnl_link_stats
> for the device in the netlink response.
> --
Yep, it should be easy to change iproute2 to not ask a full dump
in ip/ipaddress.c :
if (rtnl_wilddump_request(&rth, preferred_family, RTM_GETLINK) < 0) ...
and instead use rtnl_send() or something like that, if user provided one
specific interface name (or index)
ip link show dev eth0
^ permalink raw reply
* [PATCH 10/22] [RFC] trivial: fix typos concerning "function"
From: Uwe Kleine-König @ 2010-10-26 19:57 UTC (permalink / raw)
To: trivial; +Cc: linux-kernel, netdev
In-Reply-To: <1288123039-22368-1-git-send-email-u.kleine-koenig@pengutronix.de>
I'm a bit unsure about this patch. I'm unable to parse both statements.
Cc: netdev@vger.kernel.org
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/isdn/hisax/isar.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/isdn/hisax/isar.c b/drivers/isdn/hisax/isar.c
index 40b914b..2e72227 100644
--- a/drivers/isdn/hisax/isar.c
+++ b/drivers/isdn/hisax/isar.c
@@ -1427,8 +1427,8 @@ modeisar(struct BCState *bcs, int mode, int bc)
&bcs->hw.isar.reg->Flags))
bcs->hw.isar.dpath = 1;
else {
- printk(KERN_WARNING"isar modeisar analog funktions only with DP1\n");
- debugl1(cs, "isar modeisar analog funktions only with DP1");
+ printk(KERN_WARNING"isar modeisar analog functions only with DP1\n");
+ debugl1(cs, "isar modeisar analog functions only with DP1");
return(1);
}
break;
--
1.7.2.3
^ permalink raw reply related
* Unwanted aliasing of UDP checksum failed error counter
From: Jeremy Jackson @ 2010-10-26 19:53 UTC (permalink / raw)
To: netdev
Trying to find source of packet loss on an 8node compute cluster, we find:
(not in this example, but on the real cluster)
in /proc/sys/net/snmp
Udp: InDatagrams NoPorts InErrors OutDatagrams RcvbufErrors SndbufErrors
Udp: 976460 1750 0 986795 0 0
InErrors *and* RcvbufErrors both go up with full socket buffer, this has
made troubleshooting our application more difficult. We were chasing UDP
checksum problems, until we checked linux source code, and found aliasing.
Is this done for assembly code efficiency? Any reason ENOMEM (ie socket
buffer full) can't avoid aliasing to UDP checksum failed errors?
in linux-source-2.6.32/net/ipv4/udp.c:__udp_queue_rcv_skb()
....
/* Note that an ENOMEM error is charged twice */
if (rc == -ENOMEM) {
UDP_INC_STATS_BH(sock_net(sk), UDP_MIB_RCVBUFERRORS,
is_udplite);
atomic_inc(&sk->sk_drops);
}
goto drop;
...
drop:
UDP_INC_STATS_BH(sock_net(sk), UDP_MIB_INERRORS, is_udplite);
^ 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