* Re: /proc/net/sockstat invalid memory accounting or memory leak in latest kernels? (trying to debug)
From: Denys Fedoryshchenko @ 2014-11-16 8:54 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Neal Cardwell, Yuchung Cheng, netdev
In-Reply-To: <1415813254.17262.7.camel@edumazet-glaptop2.roam.corp.google.com>
As latest findings, when servers are going crazy because of tcp memory
invalid accounting.
First of all i upgraded kernel to latest version 3.17.3 and added also
patch from upcoming kernel,
"12) Don't call sock_kfree_s() with NULL pointers, this function also
has the side effect of adjusting
the socket memory usage. From Cong Wang.", but it didnt helped.
I added printk_ratelimited to places where suspicious values might
appear, and got some more information.
First, is not very suspicious, no idea if it is a problem:
[ 1413.031622] sk ffff8817184d8680 sk_mem_charge negative -10752 by 4352
[ 1413.032027] sk ffff8817184d8680 sk_mem_charge negative -15104 by 4352
[ 1415.768465] sk ffff881666842d80 sk_mem_charge negative -9984 by 4352
[ 1415.768868] sk ffff881666842d80 sk_mem_charge negative -14336 by 4352
[ 1415.769268] sk ffff881666842d80 sk_mem_charge negative -18688 by 4352
[ 1415.769681] sk ffff881666842d80 sk_mem_charge negative -9088 by 4352
[ 1418.933799] sk ffff8816dd640000 sk_mem_charge negative -9984 by 4352
[ 1418.934205] sk ffff8816dd640000 sk_mem_charge negative -14336 by 4352
[ 1418.934604] sk ffff8816dd640000 sk_mem_charge negative -18688 by 4352
[ 1427.131310] sk ffff881731801a00 sk_mem_charge negative -11776 by 4352
[ 1428.564640] sk ffff881731801a00 sk_mem_charge negative -11008 by 4352
[ 1429.134279] sk ffff881731801a00 sk_mem_charge negative -11776 by 4352
[ 1429.134691] sk ffff881731801a00 sk_mem_charge negative -16128 by 4352
[ 1430.666541] sk ffff881731801a00 sk_mem_charge negative -10496 by 4352
[ 1431.395099] sk ffff881731801a00 sk_mem_charge negative -12032 by 4352
[ 1431.395506] sk ffff881731801a00 sk_mem_charge negative -16384 by 4352
[ 1431.877862] sk ffff881731801a00 sk_mem_charge negative -11648 by 4352
Second is always linked with crashes, it is sk_mem_uncharge and
sk_forward_alloc goes negative. Patch to show message
for sk_mem_uncharge in sock.h is very simple:
static inline void sk_mem_uncharge(struct sock *sk, int size)
@@ -1480,6 +1485,8 @@
if (!sk_has_account(sk))
return;
sk->sk_forward_alloc += size;
+ if (sk->sk_forward_alloc < -8192)
+ printk_ratelimited(KERN_WARNING"sk %p sk_mem_uncharge
negative %d by %d\n", sk, sk->sk_forward_alloc, size);
}
This is what i am usually setting before box are rebooted:
Nov 15 13:20:53 g1 user.warn kernel: [ 2002.363437] sk ffff88155e904100
sk_mem_uncharge negative -2147482496 by 2304
Nov 15 13:20:53 g1 user.warn kernel: [ 2002.363837] sk ffff88155e904100
sk_mem_uncharge negative -2147480192 by 2304
Nov 15 13:20:53 g1 user.warn kernel: [ 2002.364232] sk ffff88155e904100
sk_mem_uncharge negative -2147477888 by 2304
Nov 15 13:20:53 g1 user.warn kernel: [ 2002.364627] sk ffff88155e904100
sk_mem_uncharge negative -2147475584 by 2304
Nov 15 13:20:53 g1 user.warn kernel: [ 2002.365022] sk ffff88155e904100
sk_mem_uncharge negative -2147473280 by 2304
Nov 15 13:20:53 g1 user.warn kernel: [ 2002.365416] sk ffff88155e904100
sk_mem_uncharge negative -2147470976 by 2304
Nov 15 13:20:53 g1 user.warn kernel: [ 2002.365811] sk ffff88155e904100
sk_mem_uncharge negative -2147468672 by 2304
Nov 15 13:20:53 g1 user.warn kernel: [ 2002.366214] sk ffff88155e904100
sk_mem_uncharge negative -2147466368 by 2304
Nov 15 13:20:53 g1 user.warn kernel: [ 2002.366611] sk ffff88155e904100
sk_mem_uncharge negative -2147464064 by 2304
Nov 15 13:20:53 g1 user.warn kernel: [ 2002.367004] sk ffff88155e904100
sk_mem_uncharge negative -2147461760 by 2304
Nov 15 13:20:58 g1 user.warn kernel: [ 2007.363601] sk_mem_uncharge:
576170 callbacks suppressed
Nov 15 13:20:58 g1 user.warn kernel: [ 2007.364001] sk ffff88155e904100
sk_mem_uncharge negative -1517794432 by 2304
.....
until
...
Nov 15 13:31:58 g1 user.warn kernel: [ 2666.393667] sk ffff88170141ad80
sk_mem_uncharge negative -169088 by 2944
Nov 15 13:31:58 g1 user.warn kernel: [ 2666.394064] sk ffff88170141ad80
sk_mem_uncharge negative -166144 by 2944
Nov 15 13:31:58 g1 user.warn kernel: [ 2666.394472] sk ffff88170141ad80
sk_mem_uncharge negative -163200 by 2944
Nov 15 13:31:58 g1 user.warn kernel: [ 2666.394871] sk ffff88170141ad80
sk_mem_uncharge negative -158208 by 4992
<reboot>
Or:
Nov 15 14:55:01 g1 user.warn kernel: [ 1965.758129] sk ffff8815f8014e00
sk_mem_uncharge negative -2147483520 by 2304
Nov 15 14:55:01 g1 user.warn kernel: [ 1965.758536] sk ffff8815f8014e00
sk_mem_uncharge negative -2147481216 by 2304
Nov 15 14:55:01 g1 user.warn kernel: [ 1965.758935] sk ffff8815f8014e00
sk_mem_uncharge negative -2147478912 by 2304
Nov 15 14:55:01 g1 user.warn kernel: [ 1965.759332] sk ffff8815f8014e00
sk_mem_uncharge negative -2147476608 by 2304
Nov 15 14:55:01 g1 user.warn kernel: [ 1965.759728] sk ffff8815f8014e00
sk_mem_uncharge negative -2147474304 by 2304
Nov 15 14:55:01 g1 user.warn kernel: [ 1965.760124] sk ffff8815f8014e00
sk_mem_uncharge negative -2147472000 by 2304
Nov 15 14:55:01 g1 user.warn kernel: [ 1965.760518] sk ffff8815f8014e00
sk_mem_uncharge negative -2147469696 by 2304
...
Nov 15 15:03:27 g1 user.warn kernel: [ 2472.170857] sk ffff88163f429a00
sk_mem_uncharge negative -277169024 by 896
Nov 15 15:03:30 g1 user.warn kernel: [ 2474.611109] sk ffff88163f429a00
sk_mem_uncharge negative -277164928 by 896
Nov 15 15:03:30 g1 user.warn kernel: [ 2474.611511] sk ffff88163f429a00
sk_mem_uncharge negative -277164032 by 896
Nov 15 15:03:30 g1 user.warn kernel: [ 2474.706237] sk ffff88163f429a00
sk_mem_uncharge negative -277159936 by 2304
Nov 15 15:03:34 g1 user.warn kernel: [ 2478.889110] sk ffff88163f429a00
sk_mem_uncharge negative -277155840 by 2304
Nov 15 15:03:34 g1 user.warn kernel: [ 2478.911516] sk ffff88163f429a00
sk_mem_uncharge negative -277147648 by 1536
Nov 15 15:03:35 g1 user.warn kernel: [ 2479.320851] sk ffff88163f429a00
sk_mem_uncharge negative -277143552 by 2304
Nov 15 15:04:33 g1 user.warn kernel: [ 2537.408184] sk ffff88163f429a00
sk_mem_uncharge negative -277139456 by 2304
Nov 15 15:04:33 g1 user.warn kernel: [ 2537.409790] sk ffff88163f429a00
sk_mem_uncharge negative -277135360 by 896
(here i can see two sk at same time are like this)
Or
Nov 15 23:37:19 g1 user.warn kernel: [14137.049570] sk ffff8816b3312700
sk_mem_uncharge negative -2147481856 by 2304
Nov 15 23:37:19 g1 user.warn kernel: [14137.049973] sk ffff8816b3312700
sk_mem_uncharge negative -2147479552 by 2304
Nov 15 23:37:19 g1 user.warn kernel: [14137.050372] sk ffff8816b3312700
sk_mem_uncharge negative -2147477248 by 2304
Nov 15 23:37:19 g1 user.warn kernel: [14137.050770] sk ffff8816b3312700
sk_mem_uncharge negative -2147474944 by 2304
Nov 15 23:37:19 g1 user.warn kernel: [14137.051170] sk ffff8816b3312700
sk_mem_uncharge negative -2147472640 by 2304
Nov 15 23:37:19 g1 user.warn kernel: [14137.051572] sk ffff8816b3312700
sk_mem_uncharge negative -2147470336 by 2304
Nov 15 23:37:19 g1 user.warn kernel: [14137.051971] sk ffff8816b3312700
sk_mem_uncharge negative -2147468032 by 2304
Nov 15 23:37:19 g1 user.warn kernel: [14137.052371] sk ffff8816b3312700
sk_mem_uncharge negative -2147465728 by 2304
Nov 15 23:37:19 g1 user.warn kernel: [14137.052771] sk ffff8816b3312700
sk_mem_uncharge negative -2147463424 by 2304
Nov 15 23:37:19 g1 user.warn kernel: [14137.053169] sk ffff8816b3312700
sk_mem_uncharge negative -2147461120 by 2304
Nov 15 23:37:32 g1 user.warn kernel: [14150.526984] sk_mem_uncharge:
1083519 callbacks suppressed
Nov 15 23:37:32 g1 user.warn kernel: [14150.527384] sk ffff8816b3312700
sk_mem_uncharge negative -2147483392 by 2304
Nov 15 23:37:32 g1 user.warn kernel: [14150.527782] sk ffff8816b3312700
sk_mem_uncharge negative -2147481088 by 2304
Nov 15 23:37:32 g1 user.warn kernel: [14150.528179] sk ffff8816b3312700
sk_mem_uncharge negative -2147478784 by 2304
Nov 15 23:37:32 g1 user.warn kernel: [14150.528576] sk ffff8816b3312700
sk_mem_uncharge negative -2147476480 by 2304
Nov 15 23:37:32 g1 user.warn kernel: [14150.528975] sk ffff8816b3312700
sk_mem_uncharge negative -2147474176 by 2304
Nov 15 23:37:32 g1 user.warn kernel: [14150.529370] sk ffff8816b3312700
sk_mem_uncharge negative -2147471872 by 2304
Nov 15 23:37:32 g1 user.warn kernel: [14150.529770] sk ffff8816b3312700
sk_mem_uncharge negative -2147469568 by 2304
Nov 15 23:37:32 g1 user.warn kernel: [14150.530167] sk ffff8816b3312700
sk_mem_uncharge negative -2147467264 by 2304
Nov 15 23:37:32 g1 user.warn kernel: [14150.530572] sk ffff8816b3312700
sk_mem_uncharge negative -2147464960 by 2304
Nov 15 23:37:32 g1 user.warn kernel: [14150.530973] sk ffff8816b3312700
sk_mem_uncharge negative -2147462656 by 2304
<here it reboots much earlier, at this point>
I will try to get more info, what kind of socket it is.
On 2014-11-12 19:27, Eric Dumazet wrote:
> On Wed, 2014-11-12 at 19:07 +0200, Denys Fedoryshchenko wrote:
>> Hi
>>
>>
>> I've been able to trace invalid memory shown for sk_forward_alloc. Not
>> sure if it is related to bug when all tcp stack are wrecked on
>> highload
>> servers (i had even such crash on server with plain torrents, not that
>> much of them).
>> First they were appearing in ss output as f4294966016, but in tc it
>> shows as unsigned integer, while in kernel it is signed integer.
>> Should
>> i provide patch for iproute2?
>> After changing value to correct one, here is what is got:
>> skmem:(r0,rb359040,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb349440,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb349440,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb349440,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb357120,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb349440,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb357120,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb349440,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb357120,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb349440,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb349440,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb349440,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb349440,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb357120,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb357120,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb357120,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb357120,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb349440,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb349440,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb357120,t0,tb46080,f-1280,w1280,o0,bl0)
>>
>> So as it is signed integer, it is actually appears a lot as -1280
>> bytes.
>> After placing several WARN_ON_ONCE on fall functions involving
>> sk_forward_alloc, where negative value may
>> appear i traced down at least to tcp_connect_queue_skb().
>> [ 13.094561] WARNING: CPU: 4 PID: 2855 at include/net/sock.h:1476
>> tcp_connect_queue_skb+0x9f/0xd0()
>> After adding some debug values, it was confirmed:
>>
>>
>> skb_header_release(skb);
>> __tcp_add_write_queue_tail(sk, skb);
>> sk->sk_wmem_queued += skb->truesize;
>> sk_mem_charge(sk, skb->truesize); <<<< sk->sk_forward_alloc often is
>> 0,
>> and skb->truesize is 1280, so -1280 is result
>> tp->write_seq = tcb->end_seq;
>> tp->packets_out += tcp_skb_pcount(skb);
>>
>> Maybe it should not be subtracted here? Or maybe logic are inverted
>> all
>> over the code?
>> Please help :)
>>
>
> Thanks a lot for the report, I am CCing other experts ;)
>
> AFAIK, a negative forward alloc should not be a problem, a long as the
> incursion is bound.
^ permalink raw reply
* Re: [PATCHv2 net 3/4] net/mlx4_en: Implement ndo_gso_check()
From: Or Gerlitz @ 2014-11-16 9:32 UTC (permalink / raw)
To: Joe Stringer
Cc: Linux Netdev List, sathya.perla, shahed.shaikh, Amir Vadai,
dept-gelinuxnicdev, Tom Herbert, alexander.duyck, Linux Kernel
In-Reply-To: <1415925495-59312-4-git-send-email-joestringer@nicira.com>
On Fri, Nov 14, 2014 at 2:38 AM, Joe Stringer <joestringer@nicira.com> wrote:
> Use vxlan_gso_check() to advertise offload support for this NIC.
>
> Signed-off-by: Joe Stringer <joestringer@nicira.com>
FWIW (since the patches is applied already...)
Acked-by: Or Gerlitz <ogerlitz@mellanox.com>
thanks for addressing this piece.
^ permalink raw reply
* Re: [PATCHv2 net 1/4] net: Add vxlan_gso_check() helper
From: Or Gerlitz @ 2014-11-16 9:35 UTC (permalink / raw)
To: Joe Stringer; +Cc: Linux Netdev List
In-Reply-To: <1415925495-59312-2-git-send-email-joestringer@nicira.com>
On Fri, Nov 14, 2014 at 2:38 AM, Joe Stringer <joestringer@nicira.com> wrote:
> Most NICs that report NETIF_F_GSO_UDP_TUNNEL support VXLAN, and not
> other UDP-based encapsulation protocols where the format and size of the
> header differs. This patch implements a generic ndo_gso_check() for
> VXLAN which will only advertise GSO support when the skb looks like it
> contains VXLAN (or no UDP tunnelling at all).
>
> Implementation shamelessly stolen from Tom Herbert:
> http://thread.gmane.org/gmane.linux.network/332428/focus=333111
>
> Signed-off-by: Joe Stringer <joestringer@nicira.com>
> ---
> v2: Merge helpers for be2net, mlx4, qlcnic
> Use (sizeof(struct udphdr) + sizeof(struct vxlanhdr))
> v1: Initial post
> ---
> drivers/net/vxlan.c | 13 +++++++++++++
> include/net/vxlan.h | 2 ++
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
> index fa9dc45..6b65863 100644
> --- a/drivers/net/vxlan.c
> +++ b/drivers/net/vxlan.c
> @@ -1571,6 +1571,19 @@ static bool route_shortcircuit(struct net_device *dev, struct sk_buff *skb)
> return false;
> }
>
> +bool vxlan_gso_check(struct sk_buff *skb)
> +{
> + if ((skb_shinfo(skb)->gso_type & SKB_GSO_UDP_TUNNEL) &&
> + (skb->inner_protocol_type != ENCAP_TYPE_ETHER ||
> + skb->inner_protocol != htons(ETH_P_TEB) ||
> + (skb_inner_mac_header(skb) - skb_transport_header(skb) !=
> + sizeof(struct udphdr) + sizeof(struct vxlanhdr))))
> + return false;
> +
> + return true;
> +}
> +EXPORT_SYMBOL_GPL(vxlan_gso_check);
Joe, any chance you can make the extra step and inline that in
vxlan.h? this is fast path call... you will only need to move struct
vxlanhdr there too.
Or.
^ permalink raw reply
* Re: [PATCH] brcmfmac: fix error handling of irq_of_parse_and_map
From: Arend van Spriel @ 2014-11-16 13:02 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: John W. Linville, Brett Rudley, Franky (Zhenhui) Lin,
Hante Meuleman, Pieter-Paul Giesberts,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
brcm80211-dev-list-dY08KVG/lbpWk0Htik3J/w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Hans de Goede
In-Reply-To: <20141114221221.GA35541@dtor-ws>
On 11/14/14 23:12, Dmitry Torokhov wrote:
> Return value of irq_of_parse_and_map() is unsigned int, with 0
> indicating failure, so testing for negative result never works.
Whoops, that is bad. Thanks for catching this. It probably needs to go
to stable as well for 3.17 kernel.
+Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org # v3.17
+Acked-by: Arend van Spriel <arend-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Dmitry Torokhov<dtor-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> ---
>
> Not tested, found by casual code inspection.
>
> drivers/net/wireless/brcm80211/brcmfmac/of.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/brcm80211/brcmfmac/of.c b/drivers/net/wireless/brcm80211/brcmfmac/of.c
> index eb3fce82..c824570 100644
> --- a/drivers/net/wireless/brcm80211/brcmfmac/of.c
> +++ b/drivers/net/wireless/brcm80211/brcmfmac/of.c
> @@ -40,8 +40,8 @@ void brcmf_of_probe(struct brcmf_sdio_dev *sdiodev)
> return;
>
> irq = irq_of_parse_and_map(np, 0);
> - if (irq< 0) {
> - brcmf_err("interrupt could not be mapped: err=%d\n", irq);
> + if (!irq) {
> + brcmf_err("interrupt could not be mapped\n");
> devm_kfree(dev, sdiodev->pdata);
> return;
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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
* pkt_sched: Fix qdisc len in qdisc_peek_dequeued() [61c9eaf9008] - question
From: Michal Soltys @ 2014-11-16 13:04 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Linux Netdev List
Hi,
I was wondering (probably missing some subtleties) about that particular
patch, namely:
61c9eaf90081cbe6dc4f389e0056bff76eca19ec
Why would that qlen++ change be necessary ? As far as peeked qdisc sees
things, the packet is already deqeued and gone - so not really part of
the queue anymore in this context (not ever requeued either). More
advanced qdiscs such as say fq_codel - if for example they decide to
drop head during further enqueue operation - obviously won't even
consider the peeked packet.
Increasing qlen from what I can see artificially shortens queue by 1.
For some classful schedulers (say like hfsc that instantly peeks next
packet length after dequeuing), child qdiscs will be almost all the time
formally operating at queue size decreased by 1.
^ permalink raw reply
* [PATCH net-next 00/14] net: provide common RSS key infrastructure
From: Eric Dumazet @ 2014-11-16 14:23 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Thomas Lendacky, Ariel Elior, Michael Chan,
Prashant Sreedharan, Rasesh Mody, Sathya Perla, Subbu Seetharaman,
Ajit Khaparde, Jesse Brandeburg, Jeff Kirsher, Amir Vadai,
Shradha Shah, Shreyas Bhatewara, Eric Dumazet
RSS (Receive Side Scaling) uses a 40 bytes key to provide hash for incoming
packets to select appropriate incoming queue on NIC.
Hash algo (Toeplitz) is also well known and documented by Microsoft
(search for "Verifying the RSS Hash Calculation")
Problem is that some drivers use a well known key.
It makes very easy for attackers to target one particular RX queue,
knowing that number of RX queues is a power of two, or at least some
small number.
Other drivers use a random value per port, making difficult
tuning on bonding setups.
Lets add a common infrastructure, so that host gets an unique
RSS key, and drivers do not have to worry about this.
Eric Dumazet (14):
net: provide a per host RSS key generic infrastructure
amd-xgbe: use netdev_rss_key_fill() helper
bnx2x: use netdev_rss_key_fill() helper
tg3: use netdev_rss_key_fill() helper
bna: use netdev_rss_key_fill() helper
be2net:use netdev_rss_key_fill() helper
e100e: use netdev_rss_key_fill() helper
fm10k: use netdev_rss_key_fill() helper
i40e: use netdev_rss_key_fill() helper
igb: use netdev_rss_key_fill() helper
ixgbe: use netdev_rss_key_fill() helper
mlx4: use netdev_rss_key_fill() helper
sfc: use netdev_rss_key_fill() helper
vmxnet3: use netdev_rss_key_fill() helper
Documentation/sysctl/net.txt | 22 ++++++++++++++++++++++
drivers/net/ethernet/amd/xgbe/xgbe-main.c | 2 +-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 2 +-
drivers/net/ethernet/broadcom/tg3.c | 17 ++++++-----------
drivers/net/ethernet/brocade/bna/bnad.c | 2 +-
drivers/net/ethernet/emulex/benet/be_main.c | 10 +++++-----
drivers/net/ethernet/intel/e1000e/netdev.c | 9 +++------
drivers/net/ethernet/intel/fm10k/fm10k_pci.c | 10 +++-------
drivers/net/ethernet/intel/i40e/i40e_main.c | 10 +++-------
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 11 +++--------
drivers/net/ethernet/intel/igb/igb_main.c | 9 +++------
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 7 +++----
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 9 ++++++++-
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 6 +-----
drivers/net/ethernet/sfc/efx.c | 2 +-
drivers/net/vmxnet3/vmxnet3_drv.c | 9 +--------
include/linux/mlx4/qp.h | 4 +++-
include/linux/netdevice.h | 6 ++++++
net/core/ethtool.c | 11 +++++++++++
net/core/sysctl_net_core.c | 19 +++++++++++++++++++
20 files changed, 104 insertions(+), 73 deletions(-)
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply
* [PATCH net-next 02/14] amd-xgbe: use netdev_rss_key_fill() helper
From: Eric Dumazet @ 2014-11-16 14:23 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Thomas Lendacky, Ariel Elior, Michael Chan,
Prashant Sreedharan, Rasesh Mody, Sathya Perla, Subbu Seetharaman,
Ajit Khaparde, Jesse Brandeburg, Jeff Kirsher, Amir Vadai,
Shradha Shah, Shreyas Bhatewara, Eric Dumazet
In-Reply-To: <1416147798-16561-1-git-send-email-edumazet@google.com>
Use netdev_rss_key_fill() helper, as it provides better support for some
bonding setups.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Lendacky, Thomas <Thomas.Lendacky@amd.com>
---
drivers/net/ethernet/amd/xgbe/xgbe-main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-main.c b/drivers/net/ethernet/amd/xgbe/xgbe-main.c
index 05fbdf96e77e..dbd3850b8b0a 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-main.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-main.c
@@ -338,7 +338,7 @@ static int xgbe_probe(struct platform_device *pdev)
}
/* Initialize RSS hash key and lookup table */
- get_random_bytes(pdata->rss_key, sizeof(pdata->rss_key));
+ netdev_rss_key_fill(pdata->rss_key, sizeof(pdata->rss_key));
for (i = 0; i < XGBE_RSS_MAX_TABLE_SIZE; i++)
XGMAC_SET_BITS(pdata->rss_table[i], MAC_RSSDR, DMCH,
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 03/14] bnx2x: use netdev_rss_key_fill() helper
From: Eric Dumazet @ 2014-11-16 14:23 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Thomas Lendacky, Ariel Elior, Michael Chan,
Prashant Sreedharan, Rasesh Mody, Sathya Perla, Subbu Seetharaman,
Ajit Khaparde, Jesse Brandeburg, Jeff Kirsher, Amir Vadai,
Shradha Shah, Shreyas Bhatewara, Eric Dumazet
In-Reply-To: <1416147798-16561-1-git-send-email-edumazet@google.com>
Use netdev_rss_key_fill() helper, as it provides better support for some
bonding setups.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Ariel Elior <ariel.elior@qlogic.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
index e9af4af5edba..b4d71fd909ee 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
@@ -2099,7 +2099,7 @@ int bnx2x_rss(struct bnx2x *bp, struct bnx2x_rss_config_obj *rss_obj,
if (config_hash) {
/* RSS keys */
- prandom_bytes(params.rss_key, T_ETH_RSS_KEY * 4);
+ netdev_rss_key_fill(params.rss_key, T_ETH_RSS_KEY * 4);
__set_bit(BNX2X_RSS_SET_SRCH, ¶ms.rss_flags);
}
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 04/14] tg3: use netdev_rss_key_fill() helper
From: Eric Dumazet @ 2014-11-16 14:23 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Thomas Lendacky, Ariel Elior, Michael Chan,
Prashant Sreedharan, Rasesh Mody, Sathya Perla, Subbu Seetharaman,
Ajit Khaparde, Jesse Brandeburg, Jeff Kirsher, Amir Vadai,
Shradha Shah, Shreyas Bhatewara, Eric Dumazet
In-Reply-To: <1416147798-16561-1-git-send-email-edumazet@google.com>
Use of well known RSS key increases attack surface.
Switch to a random one, using generic helper so that all
ports share a common key.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Prashant Sreedharan <prashant@broadcom.com>
Cc: Michael Chan <mchan@broadcom.com>
---
drivers/net/ethernet/broadcom/tg3.c | 17 ++++++-----------
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index dbb41c1923e6..2dc001559a97 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -10540,19 +10540,14 @@ static int tg3_reset_hw(struct tg3 *tp, bool reset_phy)
udelay(100);
if (tg3_flag(tp, ENABLE_RSS)) {
+ u32 rss_key[10];
+
tg3_rss_write_indir_tbl(tp);
- /* Setup the "secret" hash key. */
- tw32(MAC_RSS_HASH_KEY_0, 0x5f865437);
- tw32(MAC_RSS_HASH_KEY_1, 0xe4ac62cc);
- tw32(MAC_RSS_HASH_KEY_2, 0x50103a45);
- tw32(MAC_RSS_HASH_KEY_3, 0x36621985);
- tw32(MAC_RSS_HASH_KEY_4, 0xbf14c0e8);
- tw32(MAC_RSS_HASH_KEY_5, 0x1bc27a1e);
- tw32(MAC_RSS_HASH_KEY_6, 0x84f4b556);
- tw32(MAC_RSS_HASH_KEY_7, 0x094ea6fe);
- tw32(MAC_RSS_HASH_KEY_8, 0x7dda01e7);
- tw32(MAC_RSS_HASH_KEY_9, 0xc04d7481);
+ netdev_rss_key_fill(rss_key, 10 * sizeof(u32));
+
+ for (i = 0; i < 10 ; i++)
+ tw32(MAC_RSS_HASH_KEY_0 + i*4, rss_key[i]);
}
tp->rx_mode = RX_MODE_ENABLE;
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 05/14] bna: use netdev_rss_key_fill() helper
From: Eric Dumazet @ 2014-11-16 14:23 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Thomas Lendacky, Ariel Elior, Michael Chan,
Prashant Sreedharan, Rasesh Mody, Sathya Perla, Subbu Seetharaman,
Ajit Khaparde, Jesse Brandeburg, Jeff Kirsher, Amir Vadai,
Shradha Shah, Shreyas Bhatewara, Eric Dumazet
In-Reply-To: <1416147798-16561-1-git-send-email-edumazet@google.com>
Use netdev_rss_key_fill() helper, as it provides better support for some
bonding setups.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Rasesh Mody <rasesh.mody@qlogic.com>
---
drivers/net/ethernet/brocade/bna/bnad.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/brocade/bna/bnad.c b/drivers/net/ethernet/brocade/bna/bnad.c
index c3861de9dc81..323721838cf9 100644
--- a/drivers/net/ethernet/brocade/bna/bnad.c
+++ b/drivers/net/ethernet/brocade/bna/bnad.c
@@ -2054,7 +2054,7 @@ bnad_init_rx_config(struct bnad *bnad, struct bna_rx_config *rx_config)
BFI_ENET_RSS_IPV4_TCP);
rx_config->rss_config.hash_mask =
bnad->num_rxp_per_rx - 1;
- get_random_bytes(rx_config->rss_config.toeplitz_hash_key,
+ netdev_rss_key_fill(rx_config->rss_config.toeplitz_hash_key,
sizeof(rx_config->rss_config.toeplitz_hash_key));
} else {
rx_config->rss_status = BNA_STATUS_T_DISABLED;
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 06/14] be2net:use netdev_rss_key_fill() helper
From: Eric Dumazet @ 2014-11-16 14:23 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Thomas Lendacky, Ariel Elior, Michael Chan,
Prashant Sreedharan, Rasesh Mody, Sathya Perla, Subbu Seetharaman,
Ajit Khaparde, Jesse Brandeburg, Jeff Kirsher, Amir Vadai,
Shradha Shah, Shreyas Bhatewara, Eric Dumazet
In-Reply-To: <1416147798-16561-1-git-send-email-edumazet@google.com>
Use netdev_rss_key_fill() helper, as it provides better support for some
bonding setups.
Rename rss_hkey local variable to rss_key to have consistent name among
drivers.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Sathya Perla <sathya.perla@emulex.com>
Cc: Subbu Seetharaman <subbu.seetharaman@emulex.com>
Cc: Ajit Khaparde <ajit.khaparde@emulex.com>
---
drivers/net/ethernet/emulex/benet/be_main.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 9a18e7930b31..54160cc62656 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -2853,10 +2853,10 @@ static int be_close(struct net_device *netdev)
static int be_rx_qs_create(struct be_adapter *adapter)
{
+ struct rss_info *rss = &adapter->rss_info;
+ u8 rss_key[RSS_HASH_KEY_LEN];
struct be_rx_obj *rxo;
int rc, i, j;
- u8 rss_hkey[RSS_HASH_KEY_LEN];
- struct rss_info *rss = &adapter->rss_info;
for_all_rx_queues(adapter, rxo, i) {
rc = be_queue_alloc(adapter, &rxo->q, RX_Q_LEN,
@@ -2901,15 +2901,15 @@ static int be_rx_qs_create(struct be_adapter *adapter)
rss->rss_flags = RSS_ENABLE_NONE;
}
- get_random_bytes(rss_hkey, RSS_HASH_KEY_LEN);
+ netdev_rss_key_fill(rss_key, RSS_HASH_KEY_LEN);
rc = be_cmd_rss_config(adapter, rss->rsstable, rss->rss_flags,
- 128, rss_hkey);
+ 128, rss_key);
if (rc) {
rss->rss_flags = RSS_ENABLE_NONE;
return rc;
}
- memcpy(rss->rss_hkey, rss_hkey, RSS_HASH_KEY_LEN);
+ memcpy(rss->rss_hkey, rss_key, RSS_HASH_KEY_LEN);
/* First time posting */
for_all_rx_queues(adapter, rxo, i)
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 07/14] e100e: use netdev_rss_key_fill() helper
From: Eric Dumazet @ 2014-11-16 14:23 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Thomas Lendacky, Ariel Elior, Michael Chan,
Prashant Sreedharan, Rasesh Mody, Sathya Perla, Subbu Seetharaman,
Ajit Khaparde, Jesse Brandeburg, Jeff Kirsher, Amir Vadai,
Shradha Shah, Shreyas Bhatewara, Eric Dumazet
In-Reply-To: <1416147798-16561-1-git-send-email-edumazet@google.com>
Use of well known RSS key increases attack surface.
Switch to a random one, using generic helper so that all
ports share a common key.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 247335d2c7ec..370cfa275ddb 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -3449,15 +3449,12 @@ static void e1000e_setup_rss_hash(struct e1000_adapter *adapter)
{
struct e1000_hw *hw = &adapter->hw;
u32 mrqc, rxcsum;
+ u32 rss_key[10];
int i;
- static const u32 rsskey[10] = {
- 0xda565a6d, 0xc20e5b25, 0x3d256741, 0xb08fa343, 0xcb2bcad0,
- 0xb4307bae, 0xa32dcb77, 0x0cf23080, 0x3bb7426a, 0xfa01acbe
- };
- /* Fill out hash function seed */
+ netdev_rss_key_fill(rss_key, sizeof(rss_key));
for (i = 0; i < 10; i++)
- ew32(RSSRK(i), rsskey[i]);
+ ew32(RSSRK(i), rss_key[i]);
/* Direct all traffic to queue 0 */
for (i = 0; i < 32; i++)
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 08/14] fm10k: use netdev_rss_key_fill() helper
From: Eric Dumazet @ 2014-11-16 14:23 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Thomas Lendacky, Ariel Elior, Michael Chan,
Prashant Sreedharan, Rasesh Mody, Sathya Perla, Subbu Seetharaman,
Ajit Khaparde, Jesse Brandeburg, Jeff Kirsher, Amir Vadai,
Shradha Shah, Shreyas Bhatewara, Eric Dumazet
In-Reply-To: <1416147798-16561-1-git-send-email-edumazet@google.com>
Use of well known RSS key increases attack surface.
Switch to a random one, using generic helper so that all
ports share a common key.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
---
drivers/net/ethernet/intel/fm10k/fm10k_pci.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_pci.c b/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
index a0cb74ab3dc6..4f5892cc32d7 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
@@ -1551,15 +1551,11 @@ void fm10k_down(struct fm10k_intfc *interface)
static int fm10k_sw_init(struct fm10k_intfc *interface,
const struct pci_device_id *ent)
{
- static const u32 seed[FM10K_RSSRK_SIZE] = { 0xda565a6d, 0xc20e5b25,
- 0x3d256741, 0xb08fa343,
- 0xcb2bcad0, 0xb4307bae,
- 0xa32dcb77, 0x0cf23080,
- 0x3bb7426a, 0xfa01acbe };
const struct fm10k_info *fi = fm10k_info_tbl[ent->driver_data];
struct fm10k_hw *hw = &interface->hw;
struct pci_dev *pdev = interface->pdev;
struct net_device *netdev = interface->netdev;
+ u32 rss_key[FM10K_RSSRK_SIZE];
unsigned int rss;
int err;
@@ -1673,8 +1669,8 @@ static int fm10k_sw_init(struct fm10k_intfc *interface,
/* initialize vxlan_port list */
INIT_LIST_HEAD(&interface->vxlan_port);
- /* initialize RSS key */
- memcpy(interface->rssrk, seed, sizeof(seed));
+ netdev_rss_key_fill(rss_key, sizeof(rss_key));
+ memcpy(interface->rssrk, rss_key, sizeof(rss_key));
/* Start off interface as being down */
set_bit(__FM10K_DOWN, &interface->state);
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 09/14] i40e: use netdev_rss_key_fill() helper
From: Eric Dumazet @ 2014-11-16 14:23 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Thomas Lendacky, Ariel Elior, Michael Chan,
Prashant Sreedharan, Rasesh Mody, Sathya Perla, Subbu Seetharaman,
Ajit Khaparde, Jesse Brandeburg, Jeff Kirsher, Amir Vadai,
Shradha Shah, Shreyas Bhatewara, Eric Dumazet
In-Reply-To: <1416147798-16561-1-git-send-email-edumazet@google.com>
Use of well known RSS key increases attack surface.
Switch to a random one, using generic helper so that all
ports share a common key.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 10 +++-------
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 11 +++--------
2 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index de664631c807..a0bee83ab2de 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -7002,20 +7002,16 @@ static int i40e_setup_misc_vector(struct i40e_pf *pf)
**/
static int i40e_config_rss(struct i40e_pf *pf)
{
- /* Set of random keys generated using kernel random number generator */
- static const u32 seed[I40E_PFQF_HKEY_MAX_INDEX + 1] = {0x41b01687,
- 0x183cfd8c, 0xce880440, 0x580cbc3c, 0x35897377,
- 0x328b25e1, 0x4fa98922, 0xb7d90c14, 0xd5bad70d,
- 0xcd15a2c1, 0xe8580225, 0x4a1e9d11, 0xfe5731be};
+ u32 rss_key[I40E_PFQF_HKEY_MAX_INDEX + 1];
struct i40e_hw *hw = &pf->hw;
u32 lut = 0;
int i, j;
u64 hena;
u32 reg_val;
- /* Fill out hash function seed */
+ netdev_rss_key_fill(rss_key, sizeof(rss_key));
for (i = 0; i <= I40E_PFQF_HKEY_MAX_INDEX; i++)
- wr32(hw, I40E_PFQF_HKEY(i), seed[i]);
+ wr32(hw, I40E_PFQF_HKEY(i), rss_key[i]);
/* By default we enable TCP/UDP with IPv4/IPv6 ptypes */
hena = (u64)rd32(hw, I40E_PFQF_HENA(0)) |
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
index f0d07ad54198..489227891ffb 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
@@ -1434,18 +1434,12 @@ static int next_queue(struct i40evf_adapter *adapter, int j)
**/
static void i40evf_configure_rss(struct i40evf_adapter *adapter)
{
+ u32 rss_key[I40E_VFQF_HKEY_MAX_INDEX + 1];
struct i40e_hw *hw = &adapter->hw;
u32 lut = 0;
int i, j;
u64 hena;
- /* Set of random keys generated using kernel random number generator */
- static const u32 seed[I40E_VFQF_HKEY_MAX_INDEX + 1] = {
- 0x794221b4, 0xbca0c5ab, 0x6cd5ebd9, 0x1ada6127,
- 0x983b3aa1, 0x1c4e71eb, 0x7f6328b2, 0xfcdc0da0,
- 0xc135cafa, 0x7a6f7e2d, 0xe7102d28, 0x163cd12e,
- 0x4954b126 };
-
/* No RSS for single queue. */
if (adapter->num_active_queues == 1) {
wr32(hw, I40E_VFQF_HENA(0), 0);
@@ -1454,8 +1448,9 @@ static void i40evf_configure_rss(struct i40evf_adapter *adapter)
}
/* Hash type is configured by the PF - we just supply the key */
+ netdev_rss_key_fill(rss_key, sizeof(rss_key));
for (i = 0; i <= I40E_VFQF_HKEY_MAX_INDEX; i++)
- wr32(hw, I40E_VFQF_HKEY(i), seed[i]);
+ wr32(hw, I40E_VFQF_HKEY(i), rss_key[i]);
/* Enable PCTYPES for RSS, TCP/UDP with IPv4/IPv6 */
hena = I40E_DEFAULT_RSS_HENA;
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 10/14] igb: use netdev_rss_key_fill() helper
From: Eric Dumazet @ 2014-11-16 14:23 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Thomas Lendacky, Ariel Elior, Michael Chan,
Prashant Sreedharan, Rasesh Mody, Sathya Perla, Subbu Seetharaman,
Ajit Khaparde, Jesse Brandeburg, Jeff Kirsher, Amir Vadai,
Shradha Shah, Shreyas Bhatewara, Eric Dumazet
In-Reply-To: <1416147798-16561-1-git-send-email-edumazet@google.com>
Use of well known RSS key increases attack surface.
Switch to a random one, using generic helper so that all
ports share a common key.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
---
drivers/net/ethernet/intel/igb/igb_main.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index 1e35fae7a62b..b0e12e7c4a3d 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -3372,14 +3372,11 @@ static void igb_setup_mrqc(struct igb_adapter *adapter)
struct e1000_hw *hw = &adapter->hw;
u32 mrqc, rxcsum;
u32 j, num_rx_queues;
- static const u32 rsskey[10] = { 0xDA565A6D, 0xC20E5B25, 0x3D256741,
- 0xB08FA343, 0xCB2BCAD0, 0xB4307BAE,
- 0xA32DCB77, 0x0CF23080, 0x3BB7426A,
- 0xFA01ACBE };
+ u32 rss_key[10];
- /* Fill out hash function seeds */
+ netdev_rss_key_fill(rss_key, sizeof(rss_key));
for (j = 0; j < 10; j++)
- wr32(E1000_RSSRK(j), rsskey[j]);
+ wr32(E1000_RSSRK(j), rss_key[j]);
num_rx_queues = adapter->rss_queues;
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 11/14] ixgbe: use netdev_rss_key_fill() helper
From: Eric Dumazet @ 2014-11-16 14:23 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Thomas Lendacky, Ariel Elior, Michael Chan,
Prashant Sreedharan, Rasesh Mody, Sathya Perla, Subbu Seetharaman,
Ajit Khaparde, Jesse Brandeburg, Jeff Kirsher, Amir Vadai,
Shradha Shah, Shreyas Bhatewara, Eric Dumazet
In-Reply-To: <1416147798-16561-1-git-send-email-edumazet@google.com>
Use of well known RSS key increases attack surface.
Switch to a random one, using generic helper so that all
ports share a common key.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index f5fcba4f9d21..932f77961d66 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -3243,10 +3243,8 @@ static void ixgbe_setup_reta(struct ixgbe_adapter *adapter, const u32 *seed)
static void ixgbe_setup_mrqc(struct ixgbe_adapter *adapter)
{
struct ixgbe_hw *hw = &adapter->hw;
- static const u32 seed[10] = { 0xE291D73D, 0x1805EC6C, 0x2A94B30D,
- 0xA54F2BEC, 0xEA49AF7C, 0xE214AD3D, 0xB855AABE,
- 0x6A3E67EA, 0x14364D17, 0x3BED200D};
u32 mrqc = 0, rss_field = 0;
+ u32 rss_key[10];
u32 rxcsum;
/* Disable indicating checksum in descriptor, enables RSS hash */
@@ -3290,7 +3288,8 @@ static void ixgbe_setup_mrqc(struct ixgbe_adapter *adapter)
if (adapter->flags2 & IXGBE_FLAG2_RSS_FIELD_IPV6_UDP)
rss_field |= IXGBE_MRQC_RSS_FIELD_IPV6_UDP;
- ixgbe_setup_reta(adapter, seed);
+ netdev_rss_key_fill(rss_key, sizeof(rss_key));
+ ixgbe_setup_reta(adapter, rss_key);
mrqc |= rss_field;
IXGBE_WRITE_REG(hw, IXGBE_MRQC, mrqc);
}
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 12/14] mlx4: use netdev_rss_key_fill() helper
From: Eric Dumazet @ 2014-11-16 14:23 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Thomas Lendacky, Ariel Elior, Michael Chan,
Prashant Sreedharan, Rasesh Mody, Sathya Perla, Subbu Seetharaman,
Ajit Khaparde, Jesse Brandeburg, Jeff Kirsher, Amir Vadai,
Shradha Shah, Shreyas Bhatewara, Eric Dumazet
In-Reply-To: <1416147798-16561-1-git-send-email-edumazet@google.com>
Use of well known RSS key increases attack surface.
Switch to a random one, using generic helper so that all
ports share a common key.
Also provide ethtool -x support to fetch RSS key
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Amir Vadai <amirv@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 9 ++++++++-
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 6 +-----
include/linux/mlx4/qp.h | 4 +++-
3 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
index 6c643230a5ed..710cf309962a 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
@@ -973,6 +973,11 @@ static u32 mlx4_en_get_rxfh_indir_size(struct net_device *dev)
return priv->rx_ring_num;
}
+static u32 mlx4_en_get_rxfh_key_size(struct net_device *netdev)
+{
+ return MLX4_EN_RSS_KEY_SIZE;
+}
+
static int mlx4_en_get_rxfh(struct net_device *dev, u32 *ring_index, u8 *key)
{
struct mlx4_en_priv *priv = netdev_priv(dev);
@@ -988,7 +993,8 @@ static int mlx4_en_get_rxfh(struct net_device *dev, u32 *ring_index, u8 *key)
ring_index[n] = rss_map->qps[n % rss_rings].qpn -
rss_map->base_qpn;
}
-
+ if (key)
+ netdev_rss_key_fill(key, MLX4_EN_RSS_KEY_SIZE);
return err;
}
@@ -1799,6 +1805,7 @@ const struct ethtool_ops mlx4_en_ethtool_ops = {
.get_rxnfc = mlx4_en_get_rxnfc,
.set_rxnfc = mlx4_en_set_rxnfc,
.get_rxfh_indir_size = mlx4_en_get_rxfh_indir_size,
+ .get_rxfh_key_size = mlx4_en_get_rxfh_key_size,
.get_rxfh = mlx4_en_get_rxfh,
.set_rxfh = mlx4_en_set_rxfh,
.get_channels = mlx4_en_get_channels,
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index ccd95177ea7c..b7bda8956011 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -1169,9 +1169,6 @@ int mlx4_en_config_rss_steer(struct mlx4_en_priv *priv)
int i, qpn;
int err = 0;
int good_qps = 0;
- static const u32 rsskey[10] = { 0xD181C62C, 0xF7F4DB5B, 0x1983A2FC,
- 0x943E1ADB, 0xD9389E6B, 0xD1039C2C, 0xA74499AD,
- 0x593D56D9, 0xF3253C06, 0x2ADC1FFC};
en_dbg(DRV, priv, "Configuring rss steering\n");
err = mlx4_qp_reserve_range(mdev->dev, priv->rx_ring_num,
@@ -1226,8 +1223,7 @@ int mlx4_en_config_rss_steer(struct mlx4_en_priv *priv)
rss_context->flags = rss_mask;
rss_context->hash_fn = MLX4_RSS_HASH_TOP;
- for (i = 0; i < 10; i++)
- rss_context->rss_key[i] = cpu_to_be32(rsskey[i]);
+ netdev_rss_key_fill(rss_context->rss_key, MLX4_EN_RSS_KEY_SIZE);
err = mlx4_qp_to_ready(mdev->dev, &priv->res.mtt, &context,
&rss_map->indir_qp, &rss_map->indir_state);
diff --git a/include/linux/mlx4/qp.h b/include/linux/mlx4/qp.h
index 5f4e36cf0091..467ccdf94c98 100644
--- a/include/linux/mlx4/qp.h
+++ b/include/linux/mlx4/qp.h
@@ -120,13 +120,15 @@ enum {
MLX4_RSS_QPC_FLAG_OFFSET = 13,
};
+#define MLX4_EN_RSS_KEY_SIZE 40
+
struct mlx4_rss_context {
__be32 base_qpn;
__be32 default_qpn;
u16 reserved;
u8 hash_fn;
u8 flags;
- __be32 rss_key[10];
+ __be32 rss_key[MLX4_EN_RSS_KEY_SIZE / sizeof(__be32)];
__be32 base_qpn_udp;
};
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 13/14] sfc: use netdev_rss_key_fill() helper
From: Eric Dumazet @ 2014-11-16 14:23 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Thomas Lendacky, Ariel Elior, Michael Chan,
Prashant Sreedharan, Rasesh Mody, Sathya Perla, Subbu Seetharaman,
Ajit Khaparde, Jesse Brandeburg, Jeff Kirsher, Amir Vadai,
Shradha Shah, Shreyas Bhatewara, Eric Dumazet
In-Reply-To: <1416147798-16561-1-git-send-email-edumazet@google.com>
Use netdev_rss_key_fill() helper, as it provides better support for some
bonding setups.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Shradha Shah <sshah@solarflare.com>
---
drivers/net/ethernet/sfc/efx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/sfc/efx.c b/drivers/net/ethernet/sfc/efx.c
index b49d04886d4f..238482495e81 100644
--- a/drivers/net/ethernet/sfc/efx.c
+++ b/drivers/net/ethernet/sfc/efx.c
@@ -1616,7 +1616,7 @@ static int efx_probe_nic(struct efx_nic *efx)
goto fail2;
if (efx->n_channels > 1)
- get_random_bytes(&efx->rx_hash_key, sizeof(efx->rx_hash_key));
+ netdev_rss_key_fill(&efx->rx_hash_key, sizeof(efx->rx_hash_key));
for (i = 0; i < ARRAY_SIZE(efx->rx_indir_table); i++)
efx->rx_indir_table[i] =
ethtool_rxfh_indir_default(i, efx->rss_spread);
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 14/14] vmxnet3: use netdev_rss_key_fill() helper
From: Eric Dumazet @ 2014-11-16 14:23 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Thomas Lendacky, Ariel Elior, Michael Chan,
Prashant Sreedharan, Rasesh Mody, Sathya Perla, Subbu Seetharaman,
Ajit Khaparde, Jesse Brandeburg, Jeff Kirsher, Amir Vadai,
Shradha Shah, Shreyas Bhatewara, Eric Dumazet
In-Reply-To: <1416147798-16561-1-git-send-email-edumazet@google.com>
Use of well known RSS key increases attack surface.
Switch to a random one, using generic helper so that all
ports share a common key.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Shreyas Bhatewara <sbhatewara@vmware.com>
---
drivers/net/vmxnet3/vmxnet3_drv.c | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 6dfcbf523936..afd295348ddb 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -2199,13 +2199,6 @@ vmxnet3_setup_driver_shared(struct vmxnet3_adapter *adapter)
if (adapter->rss) {
struct UPT1_RSSConf *rssConf = adapter->rss_conf;
- static const uint8_t rss_key[UPT1_RSS_MAX_KEY_SIZE] = {
- 0x3b, 0x56, 0xd1, 0x56, 0x13, 0x4a, 0xe7, 0xac,
- 0xe8, 0x79, 0x09, 0x75, 0xe8, 0x65, 0x79, 0x28,
- 0x35, 0x12, 0xb9, 0x56, 0x7c, 0x76, 0x4b, 0x70,
- 0xd8, 0x56, 0xa3, 0x18, 0x9b, 0x0a, 0xee, 0xf3,
- 0x96, 0xa6, 0x9f, 0x8f, 0x9e, 0x8c, 0x90, 0xc9,
- };
devRead->misc.uptFeatures |= UPT1_F_RSS;
devRead->misc.numRxQueues = adapter->num_rx_queues;
@@ -2216,7 +2209,7 @@ vmxnet3_setup_driver_shared(struct vmxnet3_adapter *adapter)
rssConf->hashFunc = UPT1_RSS_HASH_FUNC_TOEPLITZ;
rssConf->hashKeySize = UPT1_RSS_MAX_KEY_SIZE;
rssConf->indTableSize = VMXNET3_RSS_IND_TABLE_SIZE;
- memcpy(rssConf->hashKey, rss_key, sizeof(rss_key));
+ netdev_rss_key_fill(rssConf->hashKey, sizeof(rssConf->hashKey));
for (i = 0; i < rssConf->indTableSize; i++)
rssConf->indTable[i] = ethtool_rxfh_indir_default(
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 01/14] net: provide a per host RSS key generic infrastructure
From: Eric Dumazet @ 2014-11-16 14:23 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Thomas Lendacky, Ariel Elior, Michael Chan,
Prashant Sreedharan, Rasesh Mody, Sathya Perla, Subbu Seetharaman,
Ajit Khaparde, Jesse Brandeburg, Jeff Kirsher, Amir Vadai,
Shradha Shah, Shreyas Bhatewara, Eric Dumazet
In-Reply-To: <1416147798-16561-1-git-send-email-edumazet@google.com>
RSS (Receive Side Scaling) typically uses Toeplitz hash and a 40 or 52 bytes
RSS key.
Some drivers use a constant (and well known key), some drivers use a random
key per port, making bonding setups hard to tune. Well known keys increase
attack surface, considering that number of queues is usually a power of two.
This patch provides infrastructure to help drivers doing the right thing.
netdev_rss_key_fill() should be used by drivers to initialize their RSS key,
even if they provide ethtool -X support to let user redefine the key later.
A new /proc/sys/net/core/netdev_rss_key file can be used to get the host
RSS key even for drivers not providing ethtool -x support, in case some
applications want to precisely setup flows to match some RX queues.
Tested:
myhost:~# cat /proc/sys/net/core/netdev_rss_key
11:63:99:bb:79:fb:a5:a7:07:45:b2:20:bf:02:42:2d:08:1a:dd:19:2b:6b:23:ac:56:28:9d:70:c3:ac:e8:16:4b:b7:c1:10:53:a4:78:41:36:40:74:b6:15:ca:27:44:aa:b3:4d:72
myhost:~# ethtool -x eth0
RX flow hash indirection table for eth0 with 8 RX ring(s):
0: 0 1 2 3 4 5 6 7
RSS hash key:
11:63:99:bb:79:fb:a5:a7:07:45:b2:20:bf:02:42:2d:08:1a:dd:19:2b:6b:23:ac:56:28:9d:70:c3:ac:e8:16:4b:b7:c1:10:53:a4:78:41
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
Documentation/sysctl/net.txt | 22 ++++++++++++++++++++++
include/linux/netdevice.h | 6 ++++++
net/core/ethtool.c | 11 +++++++++++
net/core/sysctl_net_core.c | 19 +++++++++++++++++++
4 files changed, 58 insertions(+)
diff --git a/Documentation/sysctl/net.txt b/Documentation/sysctl/net.txt
index e26c607468a6..666594b43cff 100644
--- a/Documentation/sysctl/net.txt
+++ b/Documentation/sysctl/net.txt
@@ -142,6 +142,28 @@ netdev_max_backlog
Maximum number of packets, queued on the INPUT side, when the interface
receives packets faster than kernel can process them.
+netdev_rss_key
+--------------
+
+RSS (Receive Side Scaling) enabled drivers use a 40 bytes host key that is
+randomly generated.
+Some user space might need to gather its content even if drivers do not
+provide ethtool -x support yet.
+
+myhost:~# cat /proc/sys/net/core/netdev_rss_key
+84:50:f4:00:a8:15:d1:a7:e9:7f:1d:60:35:c7:47:25:42:97:74:ca:56:bb:b6:a1:d8: ... (52 bytes total)
+
+File contains nul bytes if no driver ever called netdev_rss_key_fill() function.
+Note:
+/proc/sys/net/core/netdev_rss_key contains 52 bytes of key,
+but most drivers only use 40 bytes of it.
+
+myhost:~# ethtool -x eth0
+RX flow hash indirection table for eth0 with 8 RX ring(s):
+ 0: 0 1 2 3 4 5 6 7
+RSS hash key:
+84:50:f4:00:a8:15:d1:a7:e9:7f:1d:60:35:c7:47:25:42:97:74:ca:56:bb:b6:a1:d8:43:e3:c9:0c:fd:17:55:c2:3a:4d:69:ed:f1:42:89
+
netdev_tstamp_prequeue
----------------------
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 4a6f770377d3..db63cf459ba1 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -3422,6 +3422,12 @@ void netdev_upper_dev_unlink(struct net_device *dev,
void netdev_adjacent_rename_links(struct net_device *dev, char *oldname);
void *netdev_lower_dev_get_private(struct net_device *dev,
struct net_device *lower_dev);
+
+/* RSS keys are 40 or 52 bytes long */
+#define NETDEV_RSS_KEY_LEN 52
+extern u8 netdev_rss_key[NETDEV_RSS_KEY_LEN];
+void netdev_rss_key_fill(void *buffer, size_t len);
+
int dev_get_nest_level(struct net_device *dev,
bool (*type_check)(struct net_device *dev));
int skb_checksum_help(struct sk_buff *skb);
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index b0f84f5ddda8..715f51f321e9 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -25,6 +25,7 @@
#include <linux/slab.h>
#include <linux/rtnetlink.h>
#include <linux/sched.h>
+#include <linux/net.h>
/*
* Some useful ethtool_ops methods that're device independent.
@@ -573,6 +574,16 @@ static int ethtool_copy_validate_indir(u32 *indir, void __user *useraddr,
return 0;
}
+u8 netdev_rss_key[NETDEV_RSS_KEY_LEN];
+
+void netdev_rss_key_fill(void *buffer, size_t len)
+{
+ BUG_ON(len > sizeof(netdev_rss_key));
+ net_get_random_once(netdev_rss_key, sizeof(netdev_rss_key));
+ memcpy(buffer, netdev_rss_key, len);
+}
+EXPORT_SYMBOL(netdev_rss_key_fill);
+
static noinline_for_stack int ethtool_get_rxfh_indir(struct net_device *dev,
void __user *useraddr)
{
diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
index f93f092fe226..31baba2a71ce 100644
--- a/net/core/sysctl_net_core.c
+++ b/net/core/sysctl_net_core.c
@@ -217,6 +217,18 @@ static int set_default_qdisc(struct ctl_table *table, int write,
}
#endif
+static int proc_do_rss_key(struct ctl_table *table, int write,
+ void __user *buffer, size_t *lenp, loff_t *ppos)
+{
+ struct ctl_table fake_table;
+ char buf[NETDEV_RSS_KEY_LEN * 3];
+
+ snprintf(buf, sizeof(buf), "%*phC", NETDEV_RSS_KEY_LEN, netdev_rss_key);
+ fake_table.data = buf;
+ fake_table.maxlen = sizeof(buf);
+ return proc_dostring(&fake_table, write, buffer, lenp, ppos);
+}
+
static struct ctl_table net_core_table[] = {
#ifdef CONFIG_NET
{
@@ -265,6 +277,13 @@ static struct ctl_table net_core_table[] = {
.mode = 0644,
.proc_handler = proc_dointvec
},
+ {
+ .procname = "netdev_rss_key",
+ .data = &netdev_rss_key,
+ .maxlen = sizeof(int),
+ .mode = 0444,
+ .proc_handler = proc_do_rss_key,
+ },
#ifdef CONFIG_BPF_JIT
{
.procname = "bpf_jit_enable",
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* Payment
From: Finance Department @ 2014-11-16 16:26 UTC (permalink / raw)
Dear Recipient,
You have been awarded the sum of 8,000,000.00 (Eight Million Pounds sterling) with reference number 77100146 by office of the ministry of finance UK.Send us your personal details to deliver your funds.
Gloria Peter
^ permalink raw reply
* (unknown),
From: Gloria C. Mackenzie @ 2014-11-16 16:45 UTC (permalink / raw)
--
Contact Mrs. Gloria C. Mackenzie for your
Donation US$ 2 Million Dollars Donation
--
^ permalink raw reply
* Re: /proc/net/sockstat invalid memory accounting or memory leak in latest kernels? (trying to debug)
From: Eric Dumazet @ 2014-11-16 18:11 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: Neal Cardwell, Yuchung Cheng, netdev
In-Reply-To: <64ef227cf22945d373cb06271fe6e051@visp.net.lb>
On Sun, 2014-11-16 at 10:54 +0200, Denys Fedoryshchenko wrote:
> As latest findings, when servers are going crazy because of tcp memory
> invalid accounting.
> First of all i upgraded kernel to latest version 3.17.3 and added also
> patch from upcoming kernel,
> "12) Don't call sock_kfree_s() with NULL pointers, this function also
> has the side effect of adjusting
> the socket memory usage. From Cong Wang.", but it didnt helped.
>
> I added printk_ratelimited to places where suspicious values might
> appear, and got some more information.
> First, is not very suspicious, no idea if it is a problem:
> [ 1413.031622] sk ffff8817184d8680 sk_mem_charge negative -10752 by 4352
> [ 1413.032027] sk ffff8817184d8680 sk_mem_charge negative -15104 by 4352
> [ 1415.768465] sk ffff881666842d80 sk_mem_charge negative -9984 by 4352
> [ 1415.768868] sk ffff881666842d80 sk_mem_charge negative -14336 by 4352
> [ 1415.769268] sk ffff881666842d80 sk_mem_charge negative -18688 by 4352
> [ 1415.769681] sk ffff881666842d80 sk_mem_charge negative -9088 by 4352
> [ 1418.933799] sk ffff8816dd640000 sk_mem_charge negative -9984 by 4352
> [ 1418.934205] sk ffff8816dd640000 sk_mem_charge negative -14336 by 4352
> [ 1418.934604] sk ffff8816dd640000 sk_mem_charge negative -18688 by 4352
> [ 1427.131310] sk ffff881731801a00 sk_mem_charge negative -11776 by 4352
> [ 1428.564640] sk ffff881731801a00 sk_mem_charge negative -11008 by 4352
> [ 1429.134279] sk ffff881731801a00 sk_mem_charge negative -11776 by 4352
> [ 1429.134691] sk ffff881731801a00 sk_mem_charge negative -16128 by 4352
> [ 1430.666541] sk ffff881731801a00 sk_mem_charge negative -10496 by 4352
> [ 1431.395099] sk ffff881731801a00 sk_mem_charge negative -12032 by 4352
> [ 1431.395506] sk ffff881731801a00 sk_mem_charge negative -16384 by 4352
> [ 1431.877862] sk ffff881731801a00 sk_mem_charge negative -11648 by 4352
> Second is always linked with crashes, it is sk_mem_uncharge and
> sk_forward_alloc goes negative. Patch to show message
> for sk_mem_uncharge in sock.h is very simple:
>
> static inline void sk_mem_uncharge(struct sock *sk, int size)
> @@ -1480,6 +1485,8 @@
> if (!sk_has_account(sk))
> return;
> sk->sk_forward_alloc += size;
> + if (sk->sk_forward_alloc < -8192)
> + printk_ratelimited(KERN_WARNING"sk %p sk_mem_uncharge
> negative %d by %d\n", sk, sk->sk_forward_alloc, size);
> }
>
Could you describe your hardware setup and networking setup ?
^ permalink raw reply
* Re: pkt_sched: Fix qdisc len in qdisc_peek_dequeued() [61c9eaf9008] - question
From: Eric Dumazet @ 2014-11-16 18:15 UTC (permalink / raw)
To: Michal Soltys; +Cc: Jarek Poplawski, Linux Netdev List
In-Reply-To: <5468A0C5.9010409@ziu.info>
On Sun, 2014-11-16 at 14:04 +0100, Michal Soltys wrote:
> Hi,
>
> I was wondering (probably missing some subtleties) about that particular
> patch, namely:
>
> 61c9eaf90081cbe6dc4f389e0056bff76eca19ec
>
> Why would that qlen++ change be necessary ? As far as peeked qdisc sees
> things, the packet is already deqeued and gone - so not really part of
> the queue anymore in this context (not ever requeued either). More
> advanced qdiscs such as say fq_codel - if for example they decide to
> drop head during further enqueue operation - obviously won't even
> consider the peeked packet.
peeked packet has not to be considered by qdisc : Their dequeue()
methods is called only when there is no more peeked packet.
>
> Increasing qlen from what I can see artificially shortens queue by 1.
> For some classful schedulers (say like hfsc that instantly peeks next
> packet length after dequeuing), child qdiscs will be almost all the time
> formally operating at queue size decreased by 1.
Well, the peeked packet is part of the queue, as it is not yet
transmitted.
^ permalink raw reply
* [PATCH] net/at91_ether: fix loading when macb is compiled as a module
From: Gilles Chanteperdrix @ 2014-11-16 18:05 UTC (permalink / raw)
To: Nicolas Ferre, netdev; +Cc: Gilles Chanteperdrix
The at91_ether driver depends on symbols defined in the macb driver.
Currently, when compiling both at91_ether and macb as module, starting
the at91_ether module fails, because the macb module can not be loaded
with a macb interface.
Avoid this issue by getting the macb module initialization routine to
always return 0, even when no macb device is detected.
Signed-off-by: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
---
drivers/net/ethernet/cadence/macb.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index 4d9fc05..f70228c 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -2327,7 +2327,20 @@ static struct platform_driver macb_driver = {
},
};
-module_platform_driver_probe(macb_driver, macb_probe);
+static bool found;
+static int __init macb_driver_init(void)
+{
+ found = platform_driver_probe(&macb_driver, macb_probe) == 0;
+ return 0;
+}
+module_init(macb_driver_init);
+
+static void __exit macb_driver_exit(void)
+{
+ if (found)
+ platform_driver_unregister(&macb_driver);
+}
+module_exit(macb_driver_exit);
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Cadence MACB/GEM Ethernet driver");
--
1.7.10.4
^ permalink raw reply related
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