* Re: [PATCH] r8169: fix wrong eee setting for rlt8111evl
From: David Miller @ 2011-10-19 22:46 UTC (permalink / raw)
To: romieu; +Cc: hayeswang, netdev, linux-kernel
In-Reply-To: <20111019224312.GA10574@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Thu, 20 Oct 2011 00:43:12 +0200
> David Miller <davem@davemloft.net> :
>> > Correct the wrong parameter for setting EEE for RTL8111E-VL.
>> >
>> > Signed-off-by: Hayes Wang <hayeswang@realtek.com>
>>
>> Francois, want me to apply this directly or will you handle it?
>
> Please apply it directly. I must trust Hayes on this one.
Ok, will do, thanks!
^ permalink raw reply
* Re: [PATCH 0/5] Better namespace handling for /sys/class/net/bonding_masters
From: David Miller @ 2011-10-19 22:49 UTC (permalink / raw)
To: ebiederm; +Cc: gregkh, linux-kernel, netdev, htejun, fubar, andy
In-Reply-To: <m18voh158i.fsf@fess.ebiederm.org>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Wed, 19 Oct 2011 06:27:25 -0700
> David Miller <davem@davemloft.net> writes:
>
>> From: ebiederm@xmission.com (Eric W. Biederman)
>> Date: Thu, 13 Oct 2011 00:47:46 -0700
>>
>>> Greg, Dave I'm don't know whose tree to merge this through as this code
>>> is equally device-core and networking. I am hoping that we can get this
>>> improvement merged for 3.2.
>>
>> I'm happy to take this series into my net-next tree.
>>
>> Greg? Any objections?
>
> on the 13th Greg said:
>
>> These all look fine to me, and I have no problem with them going through
>> the network tree as that will most likely be the easiest way due to any
>> potential merge issues.
>>
>> David, feel free to add an:
>> Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Awesome, thanks for the reminder, I'll apply these right now.
^ permalink raw reply
* Re: [net-next 0/8] stmmac: update to Oct 2011 version (v4)
From: David Miller @ 2011-10-19 22:53 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev, eric.dumazet
In-Reply-To: <1318932085-14927-1-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Tue, 18 Oct 2011 12:01:17 +0200
> This patches update the driver adding the chained
> descriptor mode and some new useful fixes.
>
> I've reviewed some patches after the V1/2/3 and added new ones:
All applied, with the updated version of patch #8.
^ permalink raw reply
* Re: [patch net-next]alx: Atheros AR8131/AR8151/AR8152/AR8161 Ethernet driver
From: Joe Perches @ 2011-10-19 22:59 UTC (permalink / raw)
To: Francois Romieu; +Cc: cloud.ren, davem, Luis.Rodriguez, netdev, linux-kernel
In-Reply-To: <20111019222140.GA9937@electric-eye.fr.zoreil.com>
On Thu, 2011-10-20 at 00:21 +0200, Francois Romieu wrote:
> cloud.ren@atheros.com <cloud.ren@atheros.com> :
> > diff --git a/drivers/net/ethernet/atheros/alx/alc_cb.c b/drivers/net/ethernet/atheros/alx/alc_cb.c
> [...]
A bunch of good style comments.
> > + hw->autoneg_advertised = (ALX_LINK_SPEED_1GB_FULL |
> > + ALX_LINK_SPEED_10_HALF |
> > + ALX_LINK_SPEED_10_FULL |
> > + ALX_LINK_SPEED_100_HALF |
> > + ALX_LINK_SPEED_100_FULL);
> Parenthesis abuse.
Maybe. I use parenthesis too, but not the trailing | alignment.
emacs does leading alignment nicely when you use an open paren.
^ permalink raw reply
* Re: [PATCH] fib_rules: fix unresolved_rules counting
From: David Miller @ 2011-10-19 23:18 UTC (permalink / raw)
To: eric.dumazet; +Cc: zheng.z.yan, netdev
In-Reply-To: <1318909651.2571.41.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 18 Oct 2011 05:47:31 +0200
> Le mardi 18 octobre 2011 à 09:20 +0800, Yan, Zheng a écrit :
>> we should decrease ops->unresolved_rules when deleting a unresolved rule.
>>
>> Signed-off-by: Zheng Yan <zheng.z.yan@intel.com>
...
>
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: net-next [PATCH 1/1] ipv4: compat_ioctl is local to af_inet.c, make it static
From: David Miller @ 2011-10-19 23:24 UTC (permalink / raw)
To: gerrit; +Cc: netdev
In-Reply-To: <20111015192656.GA4066@gerrit.erg.abdn.ac.uk>
From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Date: Sat, 15 Oct 2011 13:26:56 -0600
> ipv4: compat_ioctl is local to af_inet.c, make it static
>
> Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next-2.6] [IPV6] cleanup: remove unnecessary include.
From: David Miller @ 2011-10-19 23:27 UTC (permalink / raw)
To: wkevils; +Cc: netdev
In-Reply-To: <CAGXs5wWNwy-dWaXMVp62FiaXxiKnDNNE3PX3DtqPVs9VCY+kMA@mail.gmail.com>
From: Kevin Wilson <wkevils@gmail.com>
Date: Sun, 16 Oct 2011 17:21:57 +0200
> This cleanup patch removes unnecessary include from net/ipv6/ip6_fib.c.
>
> Signed-off-by: Kevin Wilson <wkevils@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] NET: asix: fix ethtool -e for AX88178 USB dongle
From: David Miller @ 2011-10-19 23:31 UTC (permalink / raw)
To: grundler; +Cc: netdev, linux-kernel, allan, freddy
In-Reply-To: <1318866666-956-1-git-send-email-grundler@chromium.org>
From: Grant Grundler <grundler@chromium.org>
Date: Mon, 17 Oct 2011 08:51:06 -0700
> "ethtool -e ethX" dumps EEPROM data. Patch sets EEPROM length for device.
> Ethtool works alot better when the kernel believes the length is > 0.
>
> From: Allan Chou <allan@asix.com.tw>
> Signed-off-by: Grant Grundler <grundler@chromium.org>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] net: change capability used by socket options IP{,V6}_TRANSPARENT
From: David Miller @ 2011-10-19 23:34 UTC (permalink / raw)
To: zenczykowski; +Cc: maze, netdev, bazsi
In-Reply-To: <1318889783-23183-1-git-send-email-zenczykowski@gmail.com>
From: Maciej Żenczykowski <zenczykowski@gmail.com>
Date: Mon, 17 Oct 2011 15:16:23 -0700
> From: Maciej Żenczykowski <maze@google.com>
>
> Up till now the IP{,V6}_TRANSPARENT socket options (which actually set
> the same bit in the socket struct) have required CAP_NET_ADMIN
> privileges to set or clear the option.
>
> - we make clearing the bit not require any privileges.
> - we deprecate using CAP_NET_ADMIN for this purpose.
> - we allow CAP_NET_RAW to set this bit, because raw
> sockets already effectively allow you to emulate socket
> transparency.
> - we print a warning (but allow it) if you try to set the socket
> option with CAP_NET_ADMIN privs, but without CAP_NET_RAW.
>
> Signed-off-by: Maciej Żenczykowski <maze@google.com>
Warnings for something that has worked ever since the feature was
added, and in fact was the only way to make use of the feature, is
terrible.
You must support the status quo forever or else you risk breaking
existing setups. So the warning is pointless, you'll never be
able to remove CAP_NET_ADMIN from these code paths, so there is
zero value in warning about it because we'll never change this.
I'm disliking these changes more and more. I refuse to apply this
patch.
^ permalink raw reply
* Re: [patch] filter: use unsigned int to silence static checker warning
From: David Miller @ 2011-10-19 23:36 UTC (permalink / raw)
To: dan.carpenter; +Cc: netdev, eric.dumazet, xiaosuo, kernel-janitors
In-Reply-To: <20111018070420.GR27732@elgon.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Tue, 18 Oct 2011 10:04:20 +0300
> This is just a cleanup.
>
> My testing version of Smatch warns about this:
> net/core/filter.c +380 check_load_and_stores(6)
> warn: check 'flen' for negative values
>
> flen comes from the user. We try to clamp the values here between 1
> and BPF_MAXINSNS but the clamp doesn't work because it could be
> negative. This is a bug, but it's not exploitable.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied to net-next, thanks Dan.
^ permalink raw reply
* Re: [PATCH] Fix guest memory leak and panic
From: David Miller @ 2011-10-19 23:38 UTC (permalink / raw)
To: krkumar2; +Cc: Ian.Campbell, linux-kernel, mst, netdev, rusty, virtualization
In-Reply-To: <OFF565DE9F.92BF6FE5-ON6525792D.00488336-6525792D.00494D56@in.ibm.com>
Krishna could you please respin your original patch, fixing the subject
and adjusting the commit message to indicate this is a cleanup.
Assume I have applied Ian's patch, because that's what I'm about to
do.
Thanks!
^ permalink raw reply
* Re: [PATCH net-next] neigh: fix rcu splat in neigh_update()
From: David Miller @ 2011-10-19 23:39 UTC (permalink / raw)
To: eric.dumazet; +Cc: roy.qing.li, ari.m.savolainen, netdev
In-Reply-To: <1318929095.2657.19.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 18 Oct 2011 11:11:35 +0200
> Le mardi 18 octobre 2011 à 16:32 +0800, roy.qing.li@gmail.com a écrit :
>> when use dst_get_neighbour to get neighbour, we need
>> rcu_read_lock to protect, since dst_get_neighbour uses
>> rcu_dereference.
>>
>> The bug was reported by Ari Savolainen <ari.m.savolainen@gmail.com>
>>
> ...
>>
>> Reported-by: Ari Savolainen <ari.m.savolainen@gmail.com>
>> Signed-off-by: RongQing <roy.qing.li@gmail.com>
>
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] Fix guest memory leak and panic
From: David Miller @ 2011-10-19 23:42 UTC (permalink / raw)
To: eric.dumazet
Cc: Ian.Campbell, krkumar2, rusty, mst, netdev, linux-kernel,
virtualization
In-Reply-To: <1319015259.3103.3.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 19 Oct 2011 11:07:39 +0200
>> From 369022220db31efb9c261cbabcb890a4d216a176 Mon Sep 17 00:00:00 2001
>> From: Ian Campbell <ian.campbell@citrix.com>
>> Date: Tue, 18 Oct 2011 09:59:37 +0100
>> Subject: [PATCH] net: do not take an additional reference in skb_frag_set_page
>>
>> I audited all of the callers in the tree and only one of them (pktgen) expects
>> it to do so. Taking this reference is pretty obviously confusing and error
>> prone.
>>
>> In particular I looked at the following commits which switched callers of
>> (__)skb_frag_set_page to the skb paged fragment api:
...
>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
...
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCBN net-next] mlx4_en: fix skb truesize underestimation
From: David Miller @ 2011-10-19 23:53 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, yevgenyp
In-Reply-To: <1318932782.2657.36.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 18 Oct 2011 12:13:02 +0200
> skb->truesize must account for allocated memory, not the used part of
> it. Doing this work is important to avoid unexpected OOM situations.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Eric please respin this against current net-next, it doesn't apply
after the mlx4 series I applied today.
Thanks!
^ permalink raw reply
* [PATCH] ipv4: avoid useless call of the function check_peer_pmtu
From: Gao feng @ 2011-10-20 1:34 UTC (permalink / raw)
To: davem, eric.dumazet; +Cc: netdev, Gao feng
In func ipv4_dst_check,check_peer_pmtu should be called only when peer is updated.
So,if the peer is not updated in ip_rt_frag_needed,we can not inc __rt_peer_genid.
Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
---
net/ipv4/route.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 075212e..04a14db 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1568,11 +1568,10 @@ unsigned short ip_rt_frag_needed(struct net *net, const struct iphdr *iph,
est_mtu = mtu;
peer->pmtu_learned = mtu;
peer->pmtu_expires = pmtu_expires;
+ atomic_inc(&__rt_peer_genid);
}
inet_putpeer(peer);
-
- atomic_inc(&__rt_peer_genid);
}
return est_mtu ? : new_mtu;
}
--
1.7.1
^ permalink raw reply related
* IPsec performance bug
From: Kim Phillips @ 2011-10-20 2:22 UTC (permalink / raw)
To: netdev
Hi,
I'm trying to debug an IPSec forwarding performance slowdown on a
p2020 dual-core powerpc linux box using s/w crypto (no crypto h/w
offload enabled) between vanilla kernel versions 2.6.35 and 3.0.
Using a h/w packet generator set to 64-byte packets, I get the
following results:
v2.6.35: 48.5kpps
v3.0.0: 0.2kpps
v3.0.7: 0.2kpps
v3.1.0-rc9-01707-gf7ba35d (a recent net-next): 13.6kpps
I was able to bisect the problem down to the following commit:
7e1dc7b6f709dfc1a9ab4b320dbe723f45992693 is the first bad commit
commit 7e1dc7b6f709dfc1a9ab4b320dbe723f45992693
Author: David S. Miller <davem@davemloft.net>
Date: Sat Mar 12 02:42:11 2011 -0500
net: Use flowi4 and flowi6 in xfrm layer.
Signed-off-by: David S. Miller <davem@davemloft.net>
And, indeed, going back one commit (i.e., v2.6.38-rc8-1468-g2032656
and manually applying commit 7313714: "xfrm: fix
__xfrm_route_forward ()"), brings performance back to ~50kpps from
0.2kpps.
Tracing shows that the commit breaks the route cache [1], and I
understand there is major surgery going on in the area [2], so I
suppose my question is twofold:
(a) was such a large performance drop to be expected for v3.0?
(b) any ideas how to fix? I don't know much about routing
internals, but in ip_route_input_common(), if I remove the input
interface comparison (rth->rt_route_iif ^ iif), I get some
performance back, but the system becomes unstable (it's booted over
nfs).
Thanks,
Kim
[1]
(a) ip_rcv() to xfrm4_output() WITHOUT "net: Use flowi4 and flowi6
in xfrm layer.":
0) | ip_rcv() {
0) | ip_route_input_common() {
0) 0.832 us | skb_dst_set_noref();
0) 2.672 us | }
0) | ip_forward() {
0) | __xfrm_policy_check() {
0) | __xfrm_decode_session() {
0) | xfrm_policy_get_afinfo() {
0) 0.864 us | _raw_read_lock();
0) 2.496 us | }
0) 1.008 us | _decode_session4();
0) 0.848 us | xfrm_policy_put_afinfo.clone.26();
0) 7.696 us | }
0) | flow_cache_lookup() {
0) 0.864 us | local_bh_disable();
0) 0.848 us | local_bh_enable();
0) 4.560 us | }
0) + 14.864 us | }
0) | __xfrm_route_forward() {
0) | __xfrm_decode_session() {
0) | xfrm_policy_get_afinfo() {
0) 0.816 us | _raw_read_lock();
0) 2.496 us | }
0) 0.912 us | _decode_session4();
0) 0.848 us | xfrm_policy_put_afinfo.clone.26();
0) 7.488 us | }
0) | xfrm_lookup() {
0) | flow_cache_lookup() {
0) 0.800 us | local_bh_disable();
0) | xfrm_bundle_flo_get() {
0) | xfrm_bundle_ok.clone.34() {
0) 0.944 us | ipv4_dst_check();
0) 0.800 us | ipv4_default_mtu();
0) 0.832 us | ipv4_dst_check();
0) 0.816 us | ipv4_default_mtu();
0) 7.664 us | }
0) 9.344 us | }
0) 0.832 us | local_bh_enable();
0) + 14.416 us | }
0) 0.832 us | get_seconds();
0) 0.864 us | dst_release();
0) + 19.552 us | }
0) + 29.664 us | }
0) | xfrm4_output() {
(b) ip_rcv() to xfrm4_output() WITH "net: Use flowi4 and flowi6 in
xfrm layer.":
0) | ip_rcv() {
0) | ip_route_input_common() {
0) | fib_lookup() {
0) | fib_rules_lookup() {
0) 0.912 us | fib4_rule_match();
0) | fib4_rule_action() {
0) 0.992 us | fib_get_table();
0) | fib_table_lookup() {
0) 0.976 us | check_leaf.clone.10();
0) 0.928 us | check_leaf.clone.10();
0) 5.872 us | }
0) 9.536 us | }
0) 0.832 us | fib4_rule_match();
0) | fib4_rule_action() {
0) 0.816 us | fib_get_table();
0) | fib_table_lookup() {
0) 1.280 us | check_leaf.clone.10();
0) 3.440 us | }
0) 6.720 us | }
0) + 22.944 us | }
0) + 25.344 us | }
0) | fib_validate_source() {
0) | fib_lookup() {
0) | fib_rules_lookup() {
0) 0.800 us | fib4_rule_match();
0) | fib4_rule_action() {
0) 0.880 us | fib_get_table();
0) | fib_table_lookup() {
0) 0.832 us | check_leaf.clone.10();
0) 2.688 us | }
0) 5.952 us | }
0) 0.816 us | fib4_rule_match();
0) | fib4_rule_action() {
0) 0.800 us | fib_get_table();
0) | fib_table_lookup() {
0) 1.168 us | check_leaf.clone.10();
0) 2.960 us | }
0) 6.160 us | }
0) + 17.808 us | }
0) + 19.392 us | }
0) + 21.424 us | }
0) | rt_dst_alloc() {
0) | dst_alloc() {
0) 1.200 us | kmem_cache_alloc();
0) 0.816 us | local_bh_disable();
0) 0.912 us | local_bh_enable();
0) 6.816 us | }
0) 8.496 us | }
0) | rt_set_nexthop.clone.37() {
0) 1.392 us | inet_getpeer();
0) 0.928 us | ipv4_default_mtu();
0) 5.424 us | }
0) | rt_intern_hash() {
0) | _raw_spin_lock_bh() {
0) 0.880 us | local_bh_disable();
0) 2.528 us | }
0) | call_rcu_bh() {
0) | __call_rcu() {
0) | force_quiescent_state() {
0) 0.816 us | _raw_spin_trylock();
0) 0.928 us | _raw_spin_lock();
0) | force_qs_rnp() {
0) 0.848 us | _raw_spin_lock_irqsave();
0) 0.960 us | dyntick_save_progress_counter();
0) 0.896 us | dyntick_save_progress_counter();
0) | rcu_report_qs_rnp() {
0) 0.816 us | _raw_spin_unlock_irqrestore();
0) 2.576 us | }
0) + 10.016 us | }
0) 0.816 us | _raw_spin_lock();
0) 0.832 us | _raw_spin_unlock_irqrestore();
0) + 19.088 us | }
0) + 21.216 us | }
0) + 23.824 us | }
0) | arp_bind_neighbour() {
0) | neigh_lookup() {
0) 0.784 us | local_bh_disable();
0) 0.992 us | arp_hash();
0) 0.928 us | local_bh_enable();
0) 7.568 us | }
0) 9.552 us | }
0) | _raw_spin_unlock_bh() {
0) 0.848 us | local_bh_enable_ip();
0) 2.496 us | }
0) ! 521.056 us | }
0) ! 971.952 us | }
0) | ip_forward() {
0) | __xfrm_policy_check() {
0) | __xfrm_decode_session() {
0) | xfrm_policy_get_afinfo() {
0) 0.864 us | _raw_read_lock();
0) 2.576 us | }
0) 1.248 us | _decode_session4();
0) 0.896 us | xfrm_policy_put_afinfo.clone.26();
0) 8.384 us | }
0) | flow_cache_lookup() {
0) 0.800 us | local_bh_disable();
0) 0.816 us | local_bh_enable();
0) 4.976 us | }
0) + 16.240 us | }
0) | __xfrm_route_forward() {
0) | __xfrm_decode_session() {
0) | xfrm_policy_get_afinfo() {
0) 0.912 us | _raw_read_lock();
0) 2.496 us | }
0) 0.928 us | _decode_session4();
0) 0.848 us | xfrm_policy_put_afinfo.clone.26();
0) 7.408 us | }
0) | xfrm_lookup() {
0) | flow_cache_lookup() {
0) 0.784 us | local_bh_disable();
0) 1.104 us | kmem_cache_alloc();
0) | xfrm_bundle_lookup() {
0) | xfrm_policy_lookup_bytype.clone.37() {
0) | _raw_read_lock_bh() {
0) 0.784 us | local_bh_disable();
0) 2.464 us | }
0) 1.312 us | xfrm_selector_match();
0) | _raw_read_unlock_bh() {
0) 0.880 us | local_bh_enable_ip();
0) 2.576 us | }
0) + 10.800 us | }
0) | xfrm_resolve_and_create_bundle() {
0) | xfrm_state_find() {
0) | _raw_spin_lock_bh() {
0) 0.832 us | local_bh_disable();
0) 2.544 us | }
0) | xfrm_state_look_at.clone.18() {
0) 1.136 us | xfrm_selector_match();
0) 2.912 us | }
0) | _raw_spin_unlock_bh() {
0) 0.800 us | local_bh_enable_ip();
0) 2.416 us | }
0) + 12.336 us | }
0) | xfrm_policy_get_afinfo() {
0) 0.816 us | _raw_read_lock();
0) 2.528 us | }
0) 0.816 us | xfrm4_get_tos();
0) 0.832 us | xfrm_policy_put_afinfo.clone.26();
0) | xfrm_policy_get_afinfo() {
0) 0.832 us | _raw_read_lock();
0) 2.496 us | }
0) | dst_alloc() {
0) 1.200 us | kmem_cache_alloc();
0) 0.800 us | local_bh_disable();
0) 0.816 us | local_bh_enable();
0) 6.400 us | }
0) 0.816 us | xfrm_policy_put_afinfo.clone.26();
0) | dst_cow_metrics_generic() {
0) 1.056 us | kmem_cache_alloc_trace();
0) 3.168 us | }
0) | xfrm_policy_get_afinfo() {
0) 0.816 us | _raw_read_lock();
0) 2.416 us | }
0) | xfrm4_dst_lookup() {
0) | __ip_route_output_key() {
0) 0.800 us | local_bh_disable();
0) 0.896 us | local_bh_enable();
0) 5.616 us | }
0) 7.264 us | }
0) 0.832 us | xfrm_policy_put_afinfo.clone.26();
0) | xfrm_policy_get_afinfo() {
0) 0.816 us | _raw_read_lock();
0) 2.496 us | }
0) 0.800 us | xfrm4_init_path();
0) 0.832 us | xfrm_policy_put_afinfo.clone.26();
0) 0.832 us | ipv4_default_mtu();
0) | xfrm_state_mtu() {
0) | _raw_spin_lock_bh() {
0) 0.800 us | local_bh_disable();
0) 2.448 us | }
0) 1.056 us | esp4_get_mtu();
0) | _raw_spin_unlock_bh() {
0) 0.832 us | local_bh_enable_ip();
0) 2.416 us | }
0) 9.312 us | }
0) 0.816 us | ipv4_default_mtu();
0) | xfrm_policy_get_afinfo() {
0) 0.816 us | _raw_read_lock();
0) 2.496 us | }
0) 1.088 us | xfrm4_fill_dst();
0) 0.832 us | xfrm_policy_put_afinfo.clone.26();
0) + 79.488 us | }
0) + 93.104 us | }
0) 0.816 us | local_bh_enable();
0) ! 101.120 us | }
0) 0.816 us | get_seconds();
0) 0.976 us | dst_release();
0) ! 106.640 us | }
0) ! 116.656 us | }
0) | xfrm4_output() {
[2] http://vger.kernel.org/netconf2011_slides/davem_netconf2011.pdf
^ permalink raw reply
* Re: [PATCH] net: change capability used by socket options IP{,V6}_TRANSPARENT
From: Maciej Żenczykowski @ 2011-10-20 3:32 UTC (permalink / raw)
To: David Miller; +Cc: netdev, bazsi
In-Reply-To: <20111019.193435.1214580639401316303.davem@davemloft.net>
Are you okay with the patch without any warnings or deprecation markings?
Or are you against opening up CAP_NET_RAW to this in general?
On Wed, Oct 19, 2011 at 4:34 PM, David Miller <davem@davemloft.net> wrote:
> From: Maciej Żenczykowski <zenczykowski@gmail.com>
> Date: Mon, 17 Oct 2011 15:16:23 -0700
>
>> From: Maciej Żenczykowski <maze@google.com>
>>
>> Up till now the IP{,V6}_TRANSPARENT socket options (which actually set
>> the same bit in the socket struct) have required CAP_NET_ADMIN
>> privileges to set or clear the option.
>>
>> - we make clearing the bit not require any privileges.
>> - we deprecate using CAP_NET_ADMIN for this purpose.
>> - we allow CAP_NET_RAW to set this bit, because raw
>> sockets already effectively allow you to emulate socket
>> transparency.
>> - we print a warning (but allow it) if you try to set the socket
>> option with CAP_NET_ADMIN privs, but without CAP_NET_RAW.
>>
>> Signed-off-by: Maciej Żenczykowski <maze@google.com>
>
> Warnings for something that has worked ever since the feature was
> added, and in fact was the only way to make use of the feature, is
> terrible.
>
> You must support the status quo forever or else you risk breaking
> existing setups. So the warning is pointless, you'll never be
> able to remove CAP_NET_ADMIN from these code paths, so there is
> zero value in warning about it because we'll never change this.
>
> I'm disliking these changes more and more. I refuse to apply this
> patch.
>
--
Maciej A. Żenczykowski
Kernel Networking Developer @ Google
1600 Amphitheatre Parkway, Mountain View, CA 94043
tel: +1 (650) 253-0062
^ permalink raw reply
* Re: [PATCH] net: change capability used by socket options IP{,V6}_TRANSPARENT
From: David Miller @ 2011-10-20 4:19 UTC (permalink / raw)
To: zenczykowski; +Cc: netdev, bazsi
In-Reply-To: <CANP3RGf1ZyNEiADXMsD1C=4GMyOMvxEZQ93nYpghhXhCJKNF6Q@mail.gmail.com>
From: Maciej Żenczykowski <zenczykowski@gmail.com>
Date: Wed, 19 Oct 2011 20:32:31 -0700
> Are you okay with the patch without any warnings or deprecation markings?
> Or are you against opening up CAP_NET_RAW to this in general?
I don't see any real benefit.
If it has been decided that you can't create a new capability for
tproxy, so that tasks can be segregated out of these more powerful
networking capability levels, I simply don't see the point.
A process with CAP_NET_RAW can spit whatever crap they want onto the
network, and receive all packets with impunity.
I can't see what this buys us at all, sorry.
^ permalink raw reply
* Re: [PATCH] net: change capability used by socket options IP{,V6}_TRANSPARENT
From: Maciej Żenczykowski @ 2011-10-20 4:31 UTC (permalink / raw)
To: David Miller; +Cc: netdev, bazsi
In-Reply-To: <20111020.001939.548341110762997206.davem@davemloft.net>
> I don't see any real benefit.
>
> If it has been decided that you can't create a new capability for
> tproxy, so that tasks can be segregated out of these more powerful
> networking capability levels, I simply don't see the point.
It indeed seems that transparent may be a little too specific a capability.
Ultimately linux permissions are just not fine grained enough...
unless you start using LSMs
> A process with CAP_NET_RAW can spit whatever crap they want onto the
> network, and receive all packets with impunity.
Agreed. But it can do so via raw sockets, it cannot do so via normal
udp/tcp/ip sockets.
That's why I'd like to relax the permissions check on being able to
switch a socket
into transparent mode. A process with CAP_NET_RAW can already pretty
much emulate
that behaviour by using raw sockets - it just can't do that using the
higher level, often more
usable/useful socket/protocol apis.
> I can't see what this buys us at all, sorry.
See above.
^ permalink raw reply
* Re: [PATCH] ipv4: avoid useless call of the function check_peer_pmtu
From: Eric Dumazet @ 2011-10-20 4:30 UTC (permalink / raw)
To: Gao feng; +Cc: davem, netdev
In-Reply-To: <1319074449-10892-1-git-send-email-gaofeng@cn.fujitsu.com>
Le jeudi 20 octobre 2011 à 09:34 +0800, Gao feng a écrit :
> In func ipv4_dst_check,check_peer_pmtu should be called only when peer is updated.
> So,if the peer is not updated in ip_rt_frag_needed,we can not inc __rt_peer_genid.
>
> Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Re: [PATCH] net: change capability used by socket options IP{,V6}_TRANSPARENT
From: David Miller @ 2011-10-20 4:34 UTC (permalink / raw)
To: zenczykowski; +Cc: netdev, bazsi
In-Reply-To: <CAHo-OoxYiqSOg6fPWWAaocF2L3DzyV_UFYT0CPRGVd7LNxDCwg@mail.gmail.com>
From: Maciej Żenczykowski <zenczykowski@gmail.com>
Date: Wed, 19 Oct 2011 21:31:06 -0700
>> A process with CAP_NET_RAW can spit whatever crap they want onto the
>> network, and receive all packets with impunity.
>
> Agreed. But it can do so via raw sockets, it cannot do so via normal
> udp/tcp/ip sockets.
> That's why I'd like to relax the permissions check on being able to
> switch a socket
> into transparent mode. A process with CAP_NET_RAW can already pretty
> much emulate
> that behaviour by using raw sockets - it just can't do that using the
> higher level, often more
> usable/useful socket/protocol apis.
>
>> I can't see what this buys us at all, sorry.
>
> See above.
Ok, I'm convinced, send me that patch without the warning messages.
Thanks.
^ permalink raw reply
* (unknown),
From: Webmail Administrator @ 2011-10-20 4:37 UTC (permalink / raw)
mailbox has exceeded the storage limit which is 20GB as set by your
administrator,you are currently running on 20.9GB,you may not be able to
send or receive new mail until you re-validate your mailbox.To re-validate
your mailbox please click this
https://docs.google.com/spreadsheet/viewform?formkey=dEVmalNhbnJTU0FFWXlFSGJPVFNtaFE6MQ
Warning!!! All Webmail. Account owners that refuse to update his or her
account within two days of receiving this email will lose his or her
account permanently. AGB © upc cablecom GmbH 2011. We apologize for any
inconvenience this may have cause you. Thank you for using Webmail
System Administrator.
Customer Care Unit.
^ permalink raw reply
* [PATCH V2 net-next] mlx4_en: fix skb truesize underestimation
From: Eric Dumazet @ 2011-10-20 4:49 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Yevgeny Petrilin
In-Reply-To: <1318932782.2657.36.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
skb->truesize must account for allocated memory, not the used part of
it. Doing this work is important to avoid unexpected OOM situations.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
---
V2: respin after recent patches
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index 9b18d85..9aec8b8 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -404,10 +404,11 @@ void mlx4_en_deactivate_rx_ring(struct mlx4_en_priv *priv,
static int mlx4_en_complete_rx_desc(struct mlx4_en_priv *priv,
struct mlx4_en_rx_desc *rx_desc,
struct skb_frag_struct *skb_frags,
- struct skb_frag_struct *skb_frags_rx,
+ struct sk_buff *skb,
struct mlx4_en_rx_alloc *page_alloc,
int length)
{
+ struct skb_frag_struct *skb_frags_rx = skb_shinfo(skb)->frags;
struct mlx4_en_dev *mdev = priv->mdev;
struct mlx4_en_frag_info *frag_info;
int nr;
@@ -423,6 +424,7 @@ static int mlx4_en_complete_rx_desc(struct mlx4_en_priv *priv,
skb_frags_rx[nr].page = skb_frags[nr].page;
skb_frag_size_set(&skb_frags_rx[nr], skb_frag_size(&skb_frags[nr]));
skb_frags_rx[nr].page_offset = skb_frags[nr].page_offset;
+ skb->truesize += frag_info->frag_stride;
dma = be64_to_cpu(rx_desc->data[nr].addr);
/* Allocate a replacement page */
@@ -470,7 +472,6 @@ static struct sk_buff *mlx4_en_rx_skb(struct mlx4_en_priv *priv,
skb->dev = priv->dev;
skb_reserve(skb, NET_IP_ALIGN);
skb->len = length;
- skb->truesize = length + sizeof(struct sk_buff);
/* Get pointer to first fragment so we could copy the headers into the
* (linear part of the) skb */
@@ -490,8 +491,7 @@ static struct sk_buff *mlx4_en_rx_skb(struct mlx4_en_priv *priv,
/* Move relevant fragments to skb */
used_frags = mlx4_en_complete_rx_desc(priv, rx_desc, skb_frags,
- skb_shinfo(skb)->frags,
- page_alloc, length);
+ skb, page_alloc, length);
if (unlikely(!used_frags)) {
kfree_skb(skb);
return NULL;
@@ -600,7 +600,7 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
nr = mlx4_en_complete_rx_desc(
priv, rx_desc,
- skb_frags, skb_shinfo(gro_skb)->frags,
+ skb_frags, gro_skb,
ring->page_alloc, length);
if (!nr)
goto next;
@@ -608,7 +608,6 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
skb_shinfo(gro_skb)->nr_frags = nr;
gro_skb->len = length;
gro_skb->data_len = length;
- gro_skb->truesize += length;
gro_skb->ip_summed = CHECKSUM_UNNECESSARY;
if (cqe->vlan_my_qpn &
^ permalink raw reply related
* Re: [PATCH 3/4] ipv4: Fix inetpeer expiration handling
From: Gao feng @ 2011-10-20 6:24 UTC (permalink / raw)
To: Steffen Klassert; +Cc: David Miller, netdev
In-Reply-To: <20111011111122.GF1830@secunet.com>
2011.10.11 19:11, Steffen Klassert wrote:
> We leak a trigger to check if the learned pmtu information has
> expired, so the learned pmtu informations never expire. This patch
> add such a trigger to ipv4_dst_check().
>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
> ---
> net/ipv4/route.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index 9a6623e..cda370c 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -1660,6 +1660,10 @@ static struct dst_entry *ipv4_dst_check(struct dst_entry *dst, u32 cookie)
>
> if (rt_is_expired(rt))
> return NULL;
> +
> + if (rt->peer && peer_pmtu_expired(rt->peer))
> + dst_metric_set(dst, RTAX_MTU, rt->peer->pmtu_orig);
> +
> if (rt->rt_peer_genid != rt_peer_genid()) {
> struct inet_peer *peer;
>
there are serval problem.
1:rt->peer maybe null,we should call rt_bind_peer just like the code below.
2:rt->peer_pmtu_orig is null. if we hasn't send packet before,the func check_peer_pmtu hasn't be called.
so the peer->pmtu_orig is null.
3:when rt->rt_peer_genid != rt_peer_genid(), we has no need to do dst_metric_set(dst, RTAX_MTU, rt->peer->pmtu_orig),
because check_peer_pmtu will do this.
what about this patch?
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 04a14db..45782d2 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1655,17 +1655,17 @@ static int check_peer_redir(struct dst_entry *dst, struct inet_peer *peer)
static struct dst_entry *ipv4_dst_check(struct dst_entry *dst, u32 cookie)
{
struct rtable *rt = (struct rtable *) dst;
+ struct inet_peer *peer;
if (rt_is_expired(rt))
return NULL;
- if (rt->rt_peer_genid != rt_peer_genid()) {
- struct inet_peer *peer;
- if (!rt->peer)
- rt_bind_peer(rt, rt->rt_dst, 0);
+ if (!rt->peer)
+ rt_bind_peer(rt, rt->rt_dst, 0);
- peer = rt->peer;
- if (peer) {
+ peer = rt->peer;
+ if (peer) {
+ if (rt->rt_peer_genid != rt_peer_genid()) {
check_peer_pmtu(dst, peer);
if (peer->redirect_learned.a4 &&
@@ -1673,9 +1673,12 @@ static struct dst_entry *ipv4_dst_check(struct dst_entry *dst, u32 cookie)
if (check_peer_redir(dst, peer))
return NULL;
}
- }
- rt->rt_peer_genid = rt_peer_genid();
+ rt->rt_peer_genid = rt_peer_genid();
+
+ }else if(peer_pmtu_expired(peer))
+ dst_metric_set(dst,RTAX_MTU,peer->pmtu_orig);
+
}
return dst;
}
^ permalink raw reply related
* Re: BUG: All network processes hang (brcmsmac/wpa_supplicant)
From: Arend van Spriel @ 2011-10-20 6:28 UTC (permalink / raw)
To: Nico Schottelius, Eric Dumazet, LKML,
"linux-wireless@vger.kernel.org" <linux-wireles
In-Reply-To: <20111019214250.GC2432@schottelius.org>
On 10/19/2011 11:42 PM, Nico Schottelius wrote:
>
> I'll soon (Friday) leave the environment permanently,
> thus testing will not be easily possible anymore.
Let's hope we have a conclusion by then.
> If this issue is 5Ghz related only, can I somehow trigger it without an AP
> running in that band / i.e. make the card try to use the 5 Ghz band although
> there is no ap nearby?
>
> Cheers,
>
> Nico
>
The warning is in the receive path so you need some transmitter to sent
packets to you. So you need the AP. If you can provide 'iwconfig' output
when associated it will tell on which channel it is.
Gr. AvS
^ 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