* Re: [PATCH 1/1 net-next] openvswitch: use PTR_ERR_OR_ZERO
From: David Miller @ 2014-11-16 19:43 UTC (permalink / raw)
To: fabf-AgBVmzD5pcezQB+pC5nmwQ
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1415989978-28559-1-git-send-email-fabf-AgBVmzD5pcezQB+pC5nmwQ@public.gmane.org>
From: Fabian Frederick <fabf@skynet.be>
Date: Fri, 14 Nov 2014 19:32:58 +0100
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
Applied.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCH 1/1 net-next] net: dsa: replace count*size kmalloc by kmalloc_array
From: David Miller @ 2014-11-16 19:43 UTC (permalink / raw)
To: fabf; +Cc: linux-kernel, netdev
In-Reply-To: <1415990202-28673-1-git-send-email-fabf@skynet.be>
From: Fabian Frederick <fabf@skynet.be>
Date: Fri, 14 Nov 2014 19:36:42 +0100
> kmalloc_array manages count*sizeof overflow.
>
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
Applied, and yes I read Joe's feedback and the rest of this thread
wrt. sizeof(u8/s8). That can be done as a followup.
^ permalink raw reply
* Re: [PATCH 1/1 net-next] net: dsa: replace count*size kzalloc by kcalloc
From: David Miller @ 2014-11-16 19:44 UTC (permalink / raw)
To: fabf; +Cc: linux-kernel, netdev
In-Reply-To: <1415990303-28764-1-git-send-email-fabf@skynet.be>
From: Fabian Frederick <fabf@skynet.be>
Date: Fri, 14 Nov 2014 19:38:23 +0100
> kcalloc manages count*sizeof overflow.
>
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
Applied.
^ permalink raw reply
* Re: [PATCH] ieee802154: fix error handling in ieee802154fake_probe()
From: David Miller @ 2014-11-16 19:45 UTC (permalink / raw)
To: marcel
Cc: alex.aring, khoroshilov, linux-wpan, netdev, linux-kernel,
ldv-project
In-Reply-To: <B1D43522-B042-4D92-8F8A-D2AD89A3F0F9@holtmann.org>
From: Marcel Holtmann <marcel@holtmann.org>
Date: Sat, 15 Nov 2014 16:58:28 +0900
> Dave, do you want to just take it via net-stable tree? We currently
> have no urgent bluetooth-stable tree patches pending.
Yeah I can do that, applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] dcbnl : Disable software interrupts before taking dcb_lock
From: David Miller @ 2014-11-16 19:51 UTC (permalink / raw)
To: anish; +Cc: netdev, john.fastabend, neerav.parikh
In-Reply-To: <1416011911-28998-1-git-send-email-anish@chelsio.com>
From: Anish Bhatt <anish@chelsio.com>
Date: Fri, 14 Nov 2014 16:38:31 -0800
> Solves possible lockup issues that can be seen from firmware DCB agents calling
> into the DCB app api.
>
> DCB firmware event queues can be tied in with NAPI so that dcb events are
> generated in softIRQ context. This can results in calls to dcb_*app()
> functions which try to take the dcb_lock.
>
> If the the event triggers while we also have the dcb_lock because lldpad or
> some other agent happened to be issuing a get/set command we could see a cpu
> lockup.
>
> This code was not originally written with firmware agents in mind, hence
> grabbing dcb_lock from softIRQ context was not considered.
>
> Signed-off-by: Anish Bhatt <anish@chelsio.com>
Applied, thanks.
^ permalink raw reply
* Re: [GIT net] Open vSwitch
From: David Miller @ 2014-11-16 20:02 UTC (permalink / raw)
To: pshelar; +Cc: netdev
In-Reply-To: <1416015444-1519-1-git-send-email-pshelar@nicira.com>
From: Pravin B Shelar <pshelar@nicira.com>
Date: Fri, 14 Nov 2014 17:37:24 -0800
> Following fixes are accumulated in ovs-repo.
> Three of them are related to protocol processing, one is
> related to memory leak in case of error and one is to
> fix race.
> Patch "Validate IPv6 flow key and mask values" has conflicts
> with net-next, Let me know if you want me to send the patch
> for net-next.
Pulled, thanks a lot.
I'll sort out the merge conflicts next time I merge net into
net-next, thanks for offering.
^ permalink raw reply
* Re: [net-next 00/12][pull request] Intel Wired LAN Driver Updates 2014-11-14
From: David Miller @ 2014-11-16 20:04 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <1416031715-32498-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 14 Nov 2014 22:08:23 -0800
> This series contains updates to i40e only.
Patch #3 needs to be updated to do error handling for the case where
skb_linearize() fails, as pointed out by Eric Dumazet.
^ permalink raw reply
* Business Project.
From: Mrs. Yeung Wong @ 2014-11-16 19:59 UTC (permalink / raw)
To: Recipients
i have secured business project for you.reply only to my private email mrsyeungwong06@rogers.com if interested.
Regards,
Yeung.
^ 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 20:16 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: Neal Cardwell, Yuchung Cheng, netdev
In-Reply-To: <8d9b6a2c313db242c1afb3bcd6a12c51@visp.net.lb>
On Sun, 2014-11-16 at 21:05 +0200, Denys Fedoryshchenko wrote:
> On 2014-11-16 20:11, Eric Dumazet wrote:
> > 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 ?
> This problem are happening on multiple different units that i am using
> as https balancers, and all of them very different (except it is all
> Intel CPU's, but even in that - different generations and models). Such
> problem seems happens on all of them, and seems doesn't depend on
> hardware (networking - igb, e1000e, broadcom stuff - all affected). But
> if it is important:
> S2600GZ motherboard, one E5-2620 Xeon
> networking - onboard igb, 2 ports used
> 100GB RAM
> This particular one has bonding (but it seems crashes with or without
> it).
>
> System are custom, running on USB flash, busybox+glibc based setup,
> similar OS working for other purposes for NAT, PPPoE termination without
> any issues.
>
> What is common between failing units:
>
> I am using haproxy-based HTTPS balancer(Also as i remember haproxy doing
> a lot of setsockopt stuff), that is handling right now:
> 454444 connections established
> Bandwidth passing thru is around 1Gbps.
>
> I'm disabling tso/gso/gro on all interfaces.
>
> The way i am forwarding transparent traffic to haproxy:
> iptables -t mangle -A PREROUTING -p tcp --sport 443 -j MARK --set-mark
> 0x1
> iptables -t mangle -A PREROUTING -p tcp --dport 443 -j MARK --set-mark
> 0x1
> ip rule add fwmark 0x1 lookup 100
> ip route add local 0.0.0.0/0 dev lo table 100
>
> "Typical" setup is
>
> backend ssl_passthru
> mode tcp
> option transparent
> source 0.0.0.0 usesrc clientip
>
> frontend ssl-in
> mode tcp
> bind :443 transparent
> default_backend ssl_passthru
> option tcp-smart-accept
>
> I hope i didnt missed something important. I can provide remote ssh
> access to it.
> I will keep sending info, just with hope that some of info maybe will
> give idea, what i should patch or test.
>
> P.S. Just got an idea now, that -2147483648 hinting that somewhere is
> happening integer overflow from very large positive value, to negative.
> I will try to set triggers also to that now.
>
> If required i can provide image with such system. I am not sure you are
> interested in this problem and if it can be reproduced on synthetic
> setup, but as i remember this memory leak happened with me once also on
> normal server with torrents (i left some image unattended for 2 weeks,
> with a lot of requests, and it crashed at the end), so it might affect
> also other use cases.
> I am trying to limit now socket buffers, to see if it will decrease
> frequency of crashes.
> Also i tried to put "canary" values inside structure, near
> sk_forward_alloc , to see if there is any sort of memory corruption
> occuring on sk_forward_alloc, but seems there is no corruption.
> I will try also going back to stable kernels 3.2.64, to see if it will
> fix this problem, but testing takes sometimes almost 1 day, depends on
> luck.
Thanks Denys !
Could you try following patch ?
Thanks !
net/ipv4/tcp_output.c | 33 +++++++++++----------------------
1 file changed, 11 insertions(+), 22 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index a3d453b94747..877eb4aa05a6 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2998,7 +2998,7 @@ static int tcp_send_syn_data(struct sock *sk, struct sk_buff *syn)
{
struct tcp_sock *tp = tcp_sk(sk);
struct tcp_fastopen_request *fo = tp->fastopen_req;
- int syn_loss = 0, space, i, err = 0, iovlen = fo->data->msg_iovlen;
+ int syn_loss = 0, space, err = 0;
struct sk_buff *syn_data = NULL, *data;
unsigned long last_syn_loss = 0;
@@ -3031,25 +3031,17 @@ static int tcp_send_syn_data(struct sock *sk, struct sk_buff *syn)
/* limit to order-0 allocations */
space = min_t(size_t, space, SKB_MAX_HEAD(MAX_TCP_HEADER));
- syn_data = skb_copy_expand(syn, MAX_TCP_HEADER, space,
- sk->sk_allocation);
- if (syn_data == NULL)
+ syn_data = sk_stream_alloc_skb(sk, space, sk->sk_allocation);
+ if (!syn_data)
goto fallback;
- for (i = 0; i < iovlen && syn_data->len < space; ++i) {
- struct iovec *iov = &fo->data->msg_iov[i];
- unsigned char __user *from = iov->iov_base;
- int len = iov->iov_len;
-
- if (syn_data->len + len > space)
- len = space - syn_data->len;
- else if (i + 1 == iovlen)
- /* No more data pending in inet_wait_for_connect() */
- fo->data = NULL;
+ memcpy(syn_data->cb, syn->cb, sizeof(syn->cb));
+ if (memcpy_fromiovec(skb_put(syn_data, space), fo->data->msg_iov, space))
+ goto fallback;
- if (skb_add_data(syn_data, from, len))
- goto fallback;
- }
+ /* No more data pending in inet_wait_for_connect() */
+ if (space == fo->size)
+ fo->data = NULL;
/* Queue a data-only packet after the regular SYN for retransmission */
data = pskb_copy(syn_data, sk->sk_allocation);
@@ -3101,13 +3093,10 @@ int tcp_connect(struct sock *sk)
return 0;
}
- buff = alloc_skb_fclone(MAX_TCP_HEADER + 15, sk->sk_allocation);
- if (unlikely(buff == NULL))
+ buff = sk_stream_alloc_skb(sk, 0, sk->sk_allocation);
+ if (unlikely(!buff))
return -ENOBUFS;
- /* Reserve space for headers. */
- skb_reserve(buff, MAX_TCP_HEADER);
-
tcp_init_nondata_skb(buff, tp->write_seq++, TCPHDR_SYN);
tp->retrans_stamp = tcp_time_stamp;
tcp_connect_queue_skb(sk, buff);
^ permalink raw reply related
* Re: [patch iproute2] tc: add support for vlan tc action
From: Jamal Hadi Salim @ 2014-11-16 20:19 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, pshelar, therbert, edumazet, willemb, dborkman, mst, fw,
Paul.Durrant, tgraf
In-Reply-To: <1415804134-9895-1-git-send-email-jiri@resnulli.us>
On 11/12/14 09:55, Jiri Pirko wrote:
> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>
Latest patches work great. If you want you can
include these notes in the iproute2 commit log.
There is only one small doubt when i add two vlan
tags(Q followed by QandQ). Look at the very end
of the text i have below...
cheers,
jamal
---
export TC=/media/MT1/other-gits/iproute2-jiri/tc/tc
export ETH=eth0
#index supplied by kernel
sudo $TC actions add action vlan pop
#explicit add with our index
sudo $TC actions add action vlan pop index 10
sudo $TC actions add action vlan push id 123
sudo $TC actions add action vlan push id 456 protocol 802.1Q
sudo $TC actions add action vlan push id 789 protocol 802.1ad
sudo $TC actions ls action vlan
------ expect something like ----
action order 0: vlan pop
index 1 ref 1 bind 0
action order 1: vlan push id 123 protocol 802.1Q
index 2 ref 1 bind 0
action order 2: vlan push id 456 protocol 802.1Q
index 3 ref 1 bind 0
action order 3: vlan push id 789 protocol 802.1ad
index 4 ref 1 bind 0
action order 4: vlan pop
index 10 ref 1 bind 0
-------
#show stats
sudo $TC -s actions ls action vlan
-------
action order 0: vlan pop
index 1 ref 1 bind 0 installed 78 sec used 78 sec
Action statistics:
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
action order 1: vlan push id 123 protocol 802.1Q
index 2 ref 1 bind 0 installed 44 sec used 44 sec
Action statistics:
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
action order 2: vlan push id 456 protocol 802.1Q
index 3 ref 1 bind 0 installed 42 sec used 42 sec
Action statistics:
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
action order 3: vlan push id 789 protocol 802.1ad
index 4 ref 1 bind 0 installed 39 sec used 39 sec
Action statistics:
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
action order 4: vlan pop
index 10 ref 1 bind 0 installed 47 sec used 47 sec
Action statistics:
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
-----
sudo $TC actions flush action vlan
#expect all actions to be gone..
sudo $TC actions ls action vlan
#lets bind actions to filters...
sudo ip li add dev dummy0 type dummy
sudo ifconfig dummy0 up
#
sudo tc qdisc del dev $ETH ingress
sudo tc qdisc add dev $ETH ingress
#
sudo $TC filter add dev $ETH parent ffff: pref 11 protocol ip \
u32 match ip src 10.0.0.1 flowid 1:1 \
action vlan push id 123 \
action mirred egress redirect dev dummy0
window 1> sudo tcpdump -n -i dummy0 -e -X
window 2> ping -c 1 10.0.0.1
Expect something like:
52:54:00:c3:4b:c5 > 02:00:00:22:01:01, ethertype 802.1Q (0x8100), length
102: vlan 123, p 0, ethertype IPv4, ...
#now look at the stats..
sudo $TC -s filter ls dev $ETH parent ffff: protocol ip
#
sudo $TC filter add dev $ETH parent ffff: pref 12 protocol ip \
u32 match ip src 10.0.0.2 flowid 1:2 \
action vlan push id 456 protocol 802.1Q \
action mirred egress redirect dev dummy0
sudo tcpdump -n -i dummy0 -X -e
ping -c 1 10.0.0.2
#look at the stats..
sudo $TC -s filter ls dev $ETH parent ffff: protocol ip
#
sudo $TC filter add dev $ETH parent ffff: pref 13 protocol ip \
u32 match ip src 10.0.0.13 flowid 1:13 \
action vlan push id 789 protocol 802.1ad \
action mirred egress redirect dev dummy0
ping -c 1 10.0.0.2
sudo tcpdump -n -i dummy0 -X -e
Expect ...
52:54:00:c3:4b:c5 > 02:00:00:22:01:01, ethertype 802.1Q-QinQ (0x88a8),
length 102: vlan 789, p 0, ethertype IPv4,,,
#
sudo $TC -s filter ls dev $ETH parent 1: protocol ip
#
# Speaking in New Brunswickian:
# For shits and giggles lets add two vlans ...
# match all pings this time...
#
sudo $TC filter add dev $ETH parent ffff: pref 11 protocol ip u32 \
match ip protocol 1 0xff flowid 1:1 \
action vlan push id 123 \
action vlan push id 789 protocol 802.1ad \
action mirred egress redirect dev dummy0
sudo $TC -s filter ls dev $ETH parent ffff: protocol ip
------
filter pref 11 u32
filter pref 11 u32 fh 800: ht divisor 1
filter pref 11 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1
(rule hit 2 success 0)
match 00010000/00ff0000 at 8 (success 0 )
action order 1: vlan push id 123 protocol 802.1Q
index 13 ref 1 bind 1 installed 6 sec used 6 sec
Action statistics:
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
action order 2: vlan push id 789 protocol 802.1ad
index 14 ref 1 bind 1 installed 6 sec used 6 sec
Action statistics:
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
action order 3: mirred (Egress Redirect to device dummy0) stolen
index 9 ref 1 bind 1 installed 6 sec used 6 sec
Action statistics:
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
----
Send 10 pings to 192.168.100.1
ping 192.168.100.1 -c 10
sudo $TC -s filter ls dev $ETH parent ffff: protocol ip
------
filter pref 11 u32
filter pref 11 u32 fh 800: ht divisor 1
filter pref 11 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1
(rule hit 24 success 10)
match 00010000/00ff0000 at 8 (success 10 )
action order 1: vlan push id 123 protocol 802.1Q
index 13 ref 1 bind 1 installed 143 sec used 60 sec
Action statistics:
Sent 840 bytes 10 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
action order 2: vlan push id 789 protocol 802.1ad
index 14 ref 1 bind 1 installed 143 sec used 60 sec
Action statistics:
Sent 840 bytes 10 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
action order 3: mirred (Egress Redirect to device dummy0) stolen
index 9 ref 1 bind 1 installed 143 sec used 60 sec
Action statistics:
Sent 840 bytes 10 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
--------
As can be seen, the two vlan tags were supposedly added. I am
not sure how well it worked. I see 4 more bytes added. tcpdump doesnt do
a good job telling me if it worked...
17:58:31.636816 00:22:01:01:52:54 > 00:00:00:00:02:00, ethertype
802.1Q-QinQ (0x88a8), length 106: vlan 789, p 0, LLC, dsap Unknown
(0x44) Group, ssap Null (0x00) Command, ctrl 0x5400: Information, send
seq 0, rcv seq 42, Flags [Command], length 88
0x0000: 0000 0000 0200 0022 0101 5254 88a8 0315
0x0010: 00c3 4500 0054 c06b 0000 4001 704c 8100
0x0020: 007b c0a8 6401 c0a8 649f 0000 24b8 027c
0x0030: 000a c7e5 6854 0000 0000 e0b4 0900 0000
0x0040: 0000 1011 1213 1415 1617 1819 1a1b 1c1d
0x0050: 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d
0x0060: 2e2f 3031 3233 3435 3637
Here it is with just 802.1q tag...
17:53:38.198323 52:54:00:c3:4b:c5 > 02:00:00:22:01:01, ethertype 802.1Q
(0x8100), length 102: vlan 456, p 0, ethertype IPv4, 192.168.100.1 >
192.168.100.159: ICMP echo reply, id 620, seq 1, length 64
0x0000: 0200 0022 0101 5254 00c3 4bc5 8100 01c8
0x0010: 0800 4500 0054 c052 0000 4001 7065 c0a8
0x0020: 6401 c0a8 649f 0000 6482 026c 0001 a2e4
0x0030: 6854 0000 0000 cc04 0300 0000 0000 1011
0x0040: 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021
0x0050: 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031
0x0060: 3233 3435 3637
------------
^ permalink raw reply
* Re: [PATCH] net/at91_ether: fix loading when macb is compiled as a module
From: Gilles Chanteperdrix @ 2014-11-16 20:32 UTC (permalink / raw)
To: David Miller; +Cc: nicolas.ferre, netdev
In-Reply-To: <20141116.135302.1339801219762777528.davem@davemloft.net>
On Sun, Nov 16, 2014 at 01:53:02PM -0500, David Miller wrote:
> From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> Date: Sun, 16 Nov 2014 19:05:06 +0100
>
> > 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>
>
> This is not acceptable, sorry.
>
> This means the module stays in memory even if nobody has a real use
> for it.
>
> You'll need to find another solution, and I'll say in passing that this
> was very poorly designed and that's why the problem exists.
>
Ok, I see multiple possible other fixes:
- inline the shared functions in the macb.h driver or move them to a
library, this effectively means duplication, but who is going to
enable both drivers anyway?
- when both drivers are compiled as module, make one module
containing both drivers say at91+macb.ko
- modify the code I posted so that it only keeps the macb driver
loaded without macb device if IS_ENABLED(CONFIG_ARM_AT91_ETHER)
and probably many others I do not see.
I just do not know which one you would find acceptable.
Regards.
--
Gilles.
^ permalink raw reply
* Re: [PATCH 0/3] Add temperature reading and registers dump to mv88e6171
From: David Miller @ 2014-11-16 20:48 UTC (permalink / raw)
To: andrew; +Cc: netdev, linux
In-Reply-To: <1416086694-15790-1-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Sat, 15 Nov 2014 22:24:50 +0100
> These patches centralize the temperature sensor reading code, and then
> make use of it with the mv88e6171 which has a compatible
> sensor. Additionally, support is added for reading the mv88e6171 via
> ethtool.
Series applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net-next] device: Add dev_<level>_once variants
From: David Miller @ 2014-11-16 20:49 UTC (permalink / raw)
To: joe
Cc: f.fainelli, jeffrey.t.kirsher, shannon.nelson, netdev, nhorman,
sassmann, jogreene
In-Reply-To: <1416091109.5912.32.camel@perches.com>
From: Joe Perches <joe@perches.com>
Date: Sat, 15 Nov 2014 14:38:29 -0800
> Add the equivalents to pr_<level>_once.
>
> Suggested-by: Florian Fainelli <f.fainelli@gmail.com>
> Signed-off-by: Joe Perches <joe@perches.com>
This probably should go via the device layer core, thanks thus Greg KH.
^ permalink raw reply
* Re: [PATCH net-next 00/14] net: provide common RSS key infrastructure
From: David Miller @ 2014-11-16 21:03 UTC (permalink / raw)
To: edumazet
Cc: netdev, Thomas.Lendacky, ariel.elior, mchan, prashant,
rasesh.mody, sathya.perla, subbu.seetharaman, ajit.khaparde,
jesse.brandeburg, jeffrey.t.kirsher, amirv, sshah, sbhatewara
In-Reply-To: <1416147798-16561-1-git-send-email-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Sun, 16 Nov 2014 06:23:04 -0800
> 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.
Looks good, series applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] qmi_wwan: Add support for HP lt4112 LTE/HSPA+ Gobi 4G Modem
From: David Miller @ 2014-11-16 21:05 UTC (permalink / raw)
To: bjorn; +Cc: mardnh, netdev
In-Reply-To: <87ppcneyy2.fsf@nemi.mork.no>
From: Bjørn Mork <bjorn@mork.no>
Date: Sun, 16 Nov 2014 20:18:45 +0100
> Martin Hauke <mardnh@gmx.de> writes:
>
>> Added the USB VID/PID for the HP lt4112 LTE/HSPA+ Gobi 4G Modem (Huawei me906e)
>>
>> Signed-off-by: Martin Hauke <mardnh@gmx.de>
>
> Acked-by: Bjørn Mork <bjorn@mork.no>
>
> Dave, please add this to the netdev stable queue as well.
Ok, applied and queued up for -stable.
Thanks.
^ permalink raw reply
* Re: pkt_sched: Fix qdisc len in qdisc_peek_dequeued() [61c9eaf9008] - question
From: Michal Soltys @ 2014-11-16 21:09 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Linux Netdev List
In-Reply-To: <1416161725.17262.92.camel@edumazet-glaptop2.roam.corp.google.com>
Actually, now that I analyzed it more carefully - not having that patch
would cause obvious issues (e.g. hfsc trying to activate already active
leaf in certain scenarios).
So, sorry for the noise.
PS.
Removed Jarek from CC, as that email is no longer valid.
^ permalink raw reply
* Re: [PATCH v2 net-next 6/7] bpf: allow eBPF programs to use maps
From: Alexei Starovoitov @ 2014-11-16 21:24 UTC (permalink / raw)
To: David Miller
Cc: Ingo Molnar, Andy Lutomirski, Daniel Borkmann,
Hannes Frederic Sowa, Eric Dumazet, Linux API,
Network Development, LKML
In-Reply-To: <20141116.140422.570375628237589645.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Sun, Nov 16, 2014 at 11:04 AM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
> From: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
> Date: Thu, 13 Nov 2014 17:36:49 -0800
>
>> +static u64 bpf_map_lookup_elem(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)
>> +{
>> + /* verifier checked that R1 contains a valid pointer to bpf_map
>> + * and R2 points to a program stack and map->key_size bytes were
>> + * initialized
>> + */
>> + struct bpf_map *map = (struct bpf_map *) (unsigned long) r1;
>> + void *key = (void *) (unsigned long) r2;
>> + void *value;
>> +
>> + WARN_ON_ONCE(!rcu_read_lock_held());
>> +
>> + value = map->ops->map_lookup_elem(map, key);
>> +
>> + /* lookup() returns either pointer to element value or NULL
>> + * which is the meaning of PTR_TO_MAP_VALUE_OR_NULL type
>> + */
>> + return (unsigned long) value;
>> +}
>
> You should translate this into a true boolean '1' or '0' value so that
> kernel pointers don't propagate to the user or his eBPF programs.
that won't work. eBPF programs have to see all sorts of kernel
pointers. In this case it's a pointer to map element value
or NULL. There are pointers to stack, pointers to map root,
pointers to context, etc. Programs can read pointers from
other data structures. And in the case of tracing they can
pretty much access any kernel memory in read only way.
Just like 'perf probe' filters.
The requirement that _unprivileged_ programs should
not be able to pass all these pointers back to user is
well understood and was discussed in detail several
month back. It's verifier that will prevent leaking of
kernel addresses. Today, the whole thing is for root
only. When the infra is ready for non-root I will add
a pass to verifier, that will kick in only for unprivileged
programs. Verifier already tracks all pointers and
can prevent passing them to user. In this case
verifier knows that register R0 after a call to
bpf_map_lookup_elem() is
"either pointer to element value or NULL",
so it will prevent storing it into any memory or
doing arithmetic on it, so that user space cannot
see the pointer, whereas eBPF program can use
it to access map element value.
^ permalink raw reply
* Re: [PATCH v2 net-next 6/7] bpf: allow eBPF programs to use maps
From: David Miller @ 2014-11-16 21:34 UTC (permalink / raw)
To: ast-uqk4Ao+rVK5Wk0Htik3J/w
Cc: mingo-DgEjT+Ai2ygdnm+yROfE0A, luto-kltTT9wpgjJwATOyAt5JVQ,
dborkman-H+wXaHxf7aLQT0dZR+AlfA,
hannes-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-api-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAMEtUuwrST6wGnBU6UU2NYEubskHYf1XZmZQpkgM+cUc8YD9OA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
From: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
Date: Sun, 16 Nov 2014 13:24:53 -0800
> The requirement that _unprivileged_ programs should
> not be able to pass all these pointers back to user is
> well understood and was discussed in detail several
> month back. It's verifier that will prevent leaking of
> kernel addresses.
Ok, fair enough.
^ permalink raw reply
* [PATCH net-next] i40e: Reduce stack in i40e_dbg_dump_desc
From: Joe Perches @ 2014-11-16 22:12 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Shannon Nelson, netdev
In-Reply-To: <5467C3BA.6090003@gmail.com>
Reduce stack use by using kmemdup and not using a very
large struct on stack.
In function ‘i40e_dbg_dump_desc’:
warning: the frame size of 8192 bytes is larger than 2048 bytes [-Wframe-larger-than=]
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/ethernet/intel/i40e/i40e_debugfs.c | 30 +++++++++++++++-----------
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
index a03f459..232783d 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
@@ -773,7 +773,7 @@ static void i40e_dbg_dump_desc(int cnt, int vsi_seid, int ring_id, int desc_n,
{
struct i40e_tx_desc *txd;
union i40e_rx_desc *rxd;
- struct i40e_ring ring;
+ struct i40e_ring *ring;
struct i40e_vsi *vsi;
int i;
@@ -792,29 +792,32 @@ static void i40e_dbg_dump_desc(int cnt, int vsi_seid, int ring_id, int desc_n,
vsi_seid);
return;
}
- if (is_rx_ring)
- ring = *vsi->rx_rings[ring_id];
- else
- ring = *vsi->tx_rings[ring_id];
+
+ ring = kmemdup(is_rx_ring
+ ? vsi->rx_rings[ring_id] : vsi->tx_rings[ring_id],
+ sizeof(*ring), GFP_KERNEL);
+ if (!ring)
+ return;
+
if (cnt == 2) {
dev_info(&pf->pdev->dev, "vsi = %02i %s ring = %02i\n",
vsi_seid, is_rx_ring ? "rx" : "tx", ring_id);
- for (i = 0; i < ring.count; i++) {
+ for (i = 0; i < ring->count; i++) {
if (!is_rx_ring) {
- txd = I40E_TX_DESC(&ring, i);
+ txd = I40E_TX_DESC(ring, i);
dev_info(&pf->pdev->dev,
" d[%03i] = 0x%016llx 0x%016llx\n",
i, txd->buffer_addr,
txd->cmd_type_offset_bsz);
} else if (sizeof(union i40e_rx_desc) ==
sizeof(union i40e_16byte_rx_desc)) {
- rxd = I40E_RX_DESC(&ring, i);
+ rxd = I40E_RX_DESC(ring, i);
dev_info(&pf->pdev->dev,
" d[%03i] = 0x%016llx 0x%016llx\n",
i, rxd->read.pkt_addr,
rxd->read.hdr_addr);
} else {
- rxd = I40E_RX_DESC(&ring, i);
+ rxd = I40E_RX_DESC(ring, i);
dev_info(&pf->pdev->dev,
" d[%03i] = 0x%016llx 0x%016llx 0x%016llx 0x%016llx\n",
i, rxd->read.pkt_addr,
@@ -823,26 +826,26 @@ static void i40e_dbg_dump_desc(int cnt, int vsi_seid, int ring_id, int desc_n,
}
}
} else if (cnt == 3) {
- if (desc_n >= ring.count || desc_n < 0) {
+ if (desc_n >= ring->count || desc_n < 0) {
dev_info(&pf->pdev->dev,
"descriptor %d not found\n", desc_n);
return;
}
if (!is_rx_ring) {
- txd = I40E_TX_DESC(&ring, desc_n);
+ txd = I40E_TX_DESC(ring, desc_n);
dev_info(&pf->pdev->dev,
"vsi = %02i tx ring = %02i d[%03i] = 0x%016llx 0x%016llx\n",
vsi_seid, ring_id, desc_n,
txd->buffer_addr, txd->cmd_type_offset_bsz);
} else if (sizeof(union i40e_rx_desc) ==
sizeof(union i40e_16byte_rx_desc)) {
- rxd = I40E_RX_DESC(&ring, desc_n);
+ rxd = I40E_RX_DESC(ring, desc_n);
dev_info(&pf->pdev->dev,
"vsi = %02i rx ring = %02i d[%03i] = 0x%016llx 0x%016llx\n",
vsi_seid, ring_id, desc_n,
rxd->read.pkt_addr, rxd->read.hdr_addr);
} else {
- rxd = I40E_RX_DESC(&ring, desc_n);
+ rxd = I40E_RX_DESC(ring, desc_n);
dev_info(&pf->pdev->dev,
"vsi = %02i rx ring = %02i d[%03i] = 0x%016llx 0x%016llx 0x%016llx 0x%016llx\n",
vsi_seid, ring_id, desc_n,
@@ -852,6 +855,7 @@ static void i40e_dbg_dump_desc(int cnt, int vsi_seid, int ring_id, int desc_n,
} else {
dev_info(&pf->pdev->dev, "dump desc rx/tx <vsi_seid> <ring_id> [<desc_n>]\n");
}
+ kfree(ring);
}
/**
^ permalink raw reply related
* [PATCH net-next] netdevice: Neaten includes and forward declarations
From: Joe Perches @ 2014-11-16 22:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20141116.154923.1364136096942964102.davem@davemloft.net>
Use the appropriate #include path for neighbour.h and
add device.h which was indirectly #included by dmaengine.h
Remove unnecessary forward declaration of struct device;
Add comments for other forward struct declarations.
Signed-off-by: Joe Perches <joe@perches.com>
---
include/linux/netdevice.h | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index fa6bd7d..33ce566 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -36,6 +36,7 @@
#include <linux/percpu.h>
#include <linux/rculist.h>
+#include <linux/device.h>
#include <linux/dmaengine.h>
#include <linux/workqueue.h>
#include <linux/dynamic_queue_limits.h>
@@ -49,16 +50,15 @@
#include <net/netprio_cgroup.h>
#include <linux/netdev_features.h>
-#include <linux/neighbour.h>
+
+#include <uapi/linux/neighbour.h>
#include <uapi/linux/netdevice.h>
-struct netpoll_info;
-struct device;
-struct phy_device;
-/* 802.11 specific */
-struct wireless_dev;
-/* 802.15.4 specific */
-struct wpan_dev;
+/* forward struct type declarations */
+struct netpoll_info; /* for net_device_ops */
+struct phy_device; /* for net_device */
+struct wireless_dev; /* for net_device: 802.11 specific */
+struct wpan_dev; /* for net_device: 802.15.4 specific */
void netdev_set_default_ethtool_ops(struct net_device *dev,
const struct ethtool_ops *ops);
^ permalink raw reply related
* Re: [PATCH 1/1 net-next] wireless: remove unnecessary sizeof(u8)
From: Julian Calaby @ 2014-11-16 22:33 UTC (permalink / raw)
To: Fabian Frederick
Cc: linux-kernel@vger.kernel.org, Stefano Brivio, John W. Linville,
Johannes Berg, Emmanuel Grumbach, Intel Linux Wireless,
Larry Finger, Chaoming Li, linux-wireless, b43-dev, netdev
In-Reply-To: <1415998553-12636-1-git-send-email-fabf@skynet.be>
Hi Fabian,
On Sat, Nov 15, 2014 at 7:55 AM, Fabian Frederick <fabf@skynet.be> wrote:
> sizeof(u8) is always 1.
I thought that sizeof(*variable) was preferred over sizeof(type), so
shouldn't these be switched to that format instead?
(I know that this is all no-op, but it should reduce the potential for
highly unlikely bugs in the future. Also, the extra processing is
compile-time not run-time.)
Thanks,
Julian Calaby
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
> ---
> drivers/net/wireless/b43/ppr.c | 2 +-
> drivers/net/wireless/iwlwifi/pcie/trans.c | 2 +-
> drivers/net/wireless/rtlwifi/efuse.c | 16 ++++++++--------
> 3 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/wireless/b43/ppr.c b/drivers/net/wireless/b43/ppr.c
> index 9a77027..6bc1c6f 100644
> --- a/drivers/net/wireless/b43/ppr.c
> +++ b/drivers/net/wireless/b43/ppr.c
> @@ -28,7 +28,7 @@ void b43_ppr_clear(struct b43_wldev *dev, struct b43_ppr *ppr)
> memset(ppr, 0, sizeof(*ppr));
>
> /* Compile-time PPR check */
> - BUILD_BUG_ON(sizeof(struct b43_ppr) != B43_PPR_RATES_NUM * sizeof(u8));
> + BUILD_BUG_ON(sizeof(struct b43_ppr) != B43_PPR_RATES_NUM);
> }
>
> void b43_ppr_add(struct b43_wldev *dev, struct b43_ppr *ppr, int diff)
> diff --git a/drivers/net/wireless/iwlwifi/pcie/trans.c b/drivers/net/wireless/iwlwifi/pcie/trans.c
> index 836725e..f016824 100644
> --- a/drivers/net/wireless/iwlwifi/pcie/trans.c
> +++ b/drivers/net/wireless/iwlwifi/pcie/trans.c
> @@ -1157,7 +1157,7 @@ static void iwl_trans_pcie_configure(struct iwl_trans *trans,
> trans_pcie->n_no_reclaim_cmds = trans_cfg->n_no_reclaim_cmds;
> if (trans_pcie->n_no_reclaim_cmds)
> memcpy(trans_pcie->no_reclaim_cmds, trans_cfg->no_reclaim_cmds,
> - trans_pcie->n_no_reclaim_cmds * sizeof(u8));
> + trans_pcie->n_no_reclaim_cmds);
>
> trans_pcie->rx_buf_size_8k = trans_cfg->rx_buf_size_8k;
> if (trans_pcie->rx_buf_size_8k)
> diff --git a/drivers/net/wireless/rtlwifi/efuse.c b/drivers/net/wireless/rtlwifi/efuse.c
> index 0b4082c..a3135c5 100644
> --- a/drivers/net/wireless/rtlwifi/efuse.c
> +++ b/drivers/net/wireless/rtlwifi/efuse.c
> @@ -251,8 +251,8 @@ void read_efuse(struct ieee80211_hw *hw, u16 _offset, u16 _size_byte, u8 *pbuf)
> }
>
> /* allocate memory for efuse_tbl and efuse_word */
> - efuse_tbl = kzalloc(rtlpriv->cfg->maps[EFUSE_HWSET_MAX_SIZE] *
> - sizeof(u8), GFP_ATOMIC);
> + efuse_tbl = kzalloc(rtlpriv->cfg->maps[EFUSE_HWSET_MAX_SIZE],
> + GFP_ATOMIC);
> if (!efuse_tbl)
> return;
> efuse_word = kzalloc(EFUSE_MAX_WORD_UNIT * sizeof(u16 *), GFP_ATOMIC);
> @@ -733,8 +733,8 @@ static int efuse_pg_packet_read(struct ieee80211_hw *hw, u8 offset, u8 *data)
> if (offset > 15)
> return false;
>
> - memset(data, 0xff, PGPKT_DATA_SIZE * sizeof(u8));
> - memset(tmpdata, 0xff, PGPKT_DATA_SIZE * sizeof(u8));
> + memset(data, 0xff, PGPKT_DATA_SIZE);
> + memset(tmpdata, 0xff, PGPKT_DATA_SIZE);
>
> while (continual && (efuse_addr < EFUSE_MAX_SIZE)) {
> if (readstate & PG_STATE_HEADER) {
> @@ -772,7 +772,7 @@ static void efuse_write_data_case1(struct ieee80211_hw *hw, u16 *efuse_addr,
> struct rtl_priv *rtlpriv = rtl_priv(hw);
> struct pgpkt_struct tmp_pkt;
> int dataempty = true;
> - u8 originaldata[8 * sizeof(u8)];
> + u8 originaldata[8];
> u8 badworden = 0x0F;
> u8 match_word_en, tmp_word_en;
> u8 tmpindex;
> @@ -881,7 +881,7 @@ static void efuse_write_data_case2(struct ieee80211_hw *hw, u16 *efuse_addr,
> struct pgpkt_struct tmp_pkt;
> u8 pg_header;
> u8 tmp_header;
> - u8 originaldata[8 * sizeof(u8)];
> + u8 originaldata[8];
> u8 tmp_word_cnts;
> u8 badworden = 0x0F;
>
> @@ -904,7 +904,7 @@ static void efuse_write_data_case2(struct ieee80211_hw *hw, u16 *efuse_addr,
>
> tmp_word_cnts = efuse_calculate_word_cnts(tmp_pkt.word_en);
>
> - memset(originaldata, 0xff, 8 * sizeof(u8));
> + memset(originaldata, 0xff, 8);
>
> if (efuse_pg_packet_read(hw, tmp_pkt.offset, originaldata)) {
> badworden = enable_efuse_data_write(hw,
> @@ -962,7 +962,7 @@ static int efuse_pg_packet_write(struct ieee80211_hw *hw,
> target_pkt.offset = offset;
> target_pkt.word_en = word_en;
>
> - memset(target_pkt.data, 0xFF, 8 * sizeof(u8));
> + memset(target_pkt.data, 0xFF, 8);
>
> efuse_word_enable_data_read(word_en, data, target_pkt.data);
> target_word_cnts = efuse_calculate_word_cnts(target_pkt.word_en);
> --
> 1.9.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* [PATCH net-next] enic: support skb->xmit_more
From: Govindarajulu Varadarajan @ 2014-11-16 23:04 UTC (permalink / raw)
To: davem, netdev, ssujith, benve; +Cc: Govindarajulu Varadarajan
Update posted_index only when skb->xmit_more is 0 or tx queue is full.
Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
---
drivers/net/ethernet/cisco/enic/enic_main.c | 8 ++++++--
drivers/net/ethernet/cisco/enic/vnic_wq.h | 20 +++++++++++---------
2 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/cisco/enic/enic_main.c b/drivers/net/ethernet/cisco/enic/enic_main.c
index 5afe360..52bccfd 100644
--- a/drivers/net/ethernet/cisco/enic/enic_main.c
+++ b/drivers/net/ethernet/cisco/enic/enic_main.c
@@ -533,6 +533,7 @@ static netdev_tx_t enic_hard_start_xmit(struct sk_buff *skb,
struct vnic_wq *wq;
unsigned long flags;
unsigned int txq_map;
+ struct netdev_queue *txq;
if (skb->len <= 0) {
dev_kfree_skb_any(skb);
@@ -541,6 +542,7 @@ static netdev_tx_t enic_hard_start_xmit(struct sk_buff *skb,
txq_map = skb_get_queue_mapping(skb) % enic->wq_count;
wq = &enic->wq[txq_map];
+ txq = netdev_get_tx_queue(netdev, skb_get_queue_mapping(skb));
/* Non-TSO sends must fit within ENIC_NON_TSO_MAX_DESC descs,
* which is very likely. In the off chance it's going to take
@@ -558,7 +560,7 @@ static netdev_tx_t enic_hard_start_xmit(struct sk_buff *skb,
if (vnic_wq_desc_avail(wq) <
skb_shinfo(skb)->nr_frags + ENIC_DESC_MAX_SPLITS) {
- netif_tx_stop_queue(netdev_get_tx_queue(netdev, txq_map));
+ netif_tx_stop_queue(txq);
/* This is a hard error, log it */
netdev_err(netdev, "BUG! Tx ring full when queue awake!\n");
spin_unlock_irqrestore(&enic->wq_lock[txq_map], flags);
@@ -568,7 +570,9 @@ static netdev_tx_t enic_hard_start_xmit(struct sk_buff *skb,
enic_queue_wq_skb(enic, wq, skb);
if (vnic_wq_desc_avail(wq) < MAX_SKB_FRAGS + ENIC_DESC_MAX_SPLITS)
- netif_tx_stop_queue(netdev_get_tx_queue(netdev, txq_map));
+ netif_tx_stop_queue(txq);
+ if (!skb->xmit_more || netif_xmit_stopped(txq))
+ vnic_wq_doorbell(wq);
spin_unlock_irqrestore(&enic->wq_lock[txq_map], flags);
diff --git a/drivers/net/ethernet/cisco/enic/vnic_wq.h b/drivers/net/ethernet/cisco/enic/vnic_wq.h
index 2c6c708..816f1ad 100644
--- a/drivers/net/ethernet/cisco/enic/vnic_wq.h
+++ b/drivers/net/ethernet/cisco/enic/vnic_wq.h
@@ -104,6 +104,17 @@ static inline void *vnic_wq_next_desc(struct vnic_wq *wq)
return wq->to_use->desc;
}
+static inline void vnic_wq_doorbell(struct vnic_wq *wq)
+{
+ /* Adding write memory barrier prevents compiler and/or CPU
+ * reordering, thus avoiding descriptor posting before
+ * descriptor is initialized. Otherwise, hardware can read
+ * stale descriptor fields.
+ */
+ wmb();
+ iowrite32(wq->to_use->index, &wq->ctrl->posted_index);
+}
+
static inline void vnic_wq_post(struct vnic_wq *wq,
void *os_buf, dma_addr_t dma_addr,
unsigned int len, int sop, int eop,
@@ -122,15 +133,6 @@ static inline void vnic_wq_post(struct vnic_wq *wq,
buf->wr_id = wrid;
buf = buf->next;
- if (eop) {
- /* Adding write memory barrier prevents compiler and/or CPU
- * reordering, thus avoiding descriptor posting before
- * descriptor is initialized. Otherwise, hardware can read
- * stale descriptor fields.
- */
- wmb();
- iowrite32(buf->index, &wq->ctrl->posted_index);
- }
wq->to_use = buf;
wq->ring.desc_avail -= desc_skip_cnt;
--
2.1.3
^ permalink raw reply related
* [PATCH] fix #51791 - bug? mac 00:00:00:00:00:00 with natsemi DP83815 after driver load
From: Roland Kletzing @ 2014-11-17 0:17 UTC (permalink / raw)
To: netdev
In-Reply-To: <trinity-1cec0308-6242-413f-a63f-b09cded30a4f-1416096326518@3capp-webde-bs03>
This one should fix Bugzilla #51791 (details below).
Natsemi driver does not read MAC correctly from eeprom, while natsemi-diag from nictools-pci does. Apparently, tt`s a timing issue in the kernel driver.
According to ftp://ftp.gwdg.de/pub/linux/misc/donald.becker/diag/natsemi-diag.c , eeprom_delay(ee_addr) is defined as follows:
/* Delay between EEPROM clock transitions.
This flushes the write buffer to prevent quick double-writes.
*/
#define eeprom_delay(ee_addr) inl(ee_addr); inl(ee_addr)
while in the natsemi linux kernel driver, the delay is done this way :
#define eeprom_delay(ee_addr) readl(ee_addr)
, which results in the MAC being all zero`s.
So i simply added a second readl() to increase delay (instead of turning into inl() as proposed before). This may look a little bit ugly, but it`s fixing the problem for me.
I´m not sure how many natsemi users being left on this planet (probably few), but i guess this change does not do any harm on platforms where the driver does not behave buggy, so please consider adding it to mainline/stable/longterm.
Signed-off-by: Roland Kletzing <devzero@web.de>
---
drivers/net/ethernet/natsemi/natsemi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/natsemi/natsemi.c b/drivers/net/ethernet/natsemi/natsemi.c
index b83f7c0..246bb91 100644
--- a/drivers/net/ethernet/natsemi/natsemi.c
+++ b/drivers/net/ethernet/natsemi/natsemi.c
@@ -987,7 +987,7 @@ static int natsemi_probe1(struct pci_dev *pdev, const struct pci_device_id *ent)
The old method of using an ISA access as a delay, __SLOW_DOWN_IO__, is
deprecated.
*/
-#define eeprom_delay(ee_addr) readl(ee_addr)
+#define eeprom_delay(ee_addr) readl(ee_addr); readl(ee_addr)
#define EE_Write0 (EE_ChipSelect)
#define EE_Write1 (EE_ChipSelect | EE_DataIn)
--
regards
Roland
> Gesendet: Sonntag, 16. November 2014 um 01:05 Uhr
> Von: devzero@web.de
> An: linux-kernel@vger.kernel.org
> Betreff: re: bug? mac 00:00:00:00:00:00 with natsemi DP83815 after driver load
>
> forwarding to lkml, as no response on netdev list so far.
>
> maybe someone has a clue how to properly fix this timing issue. the remaining question is about how to correctly replace readl() with inl() to make it compile cleanly or how eeprom_delay() is being done correctly. inl() seems to be slower to complete which seems to make the driver work, but it seems it needs an I/O port as param but not an memory-adress.
>
> sorry, i`m not good at programming, but now as the problem is "basically" fixed there are just some tiny bits missing for a proper fix. i´m unsure if typecasting ee_addr is the right thing to do (i think it`s not) and if a patch with such typecast would have any chance for being accepted.
>
> ----------------------------
> hi,
> as i`m doing a little project with this older devices, i have come across this issue again and had some fun to dig deeper into it.
>
> it`s a little bit academic, as i can do ifconfig eth0 hw ether..... as a workaround, but it sucks to hack that into startup scripts and i also have seen udev not playing nicely with it.
>
> apparently the problem is being caused by a timing issue in the natsemi driver.
>
> i added some debug printk`s in natsemi.c -> eeprom_read() after each occurrence of eeprom_delay(ee_addr); , and the problem went away.
>
> there is a hint about timing sensitivity in the code:
>
> /* Delay between EEPROM clock transitions.
> No extra delay is needed with 33Mhz PCI, but future 66Mhz access may need
> a delay. Note that pre-2.0.34 kernels had a cache-alignment bug that
> made udelay() unreliable.
> The old method of using an ISA access as a delay, __SLOW_DOWN_IO__, is
> deprecated.
> */
>
> looking at the source of natsemi-diag.c made me wonder why that utility is using
>
> #define eeprom_delay(ee_addr) inl(ee_addr)
>
> instead of
>
> #define eeprom_delay(ee_addr) readl(ee_addr)
>
> and apparently, that also fixes the problem (but gives a compile warning):
>
> drivers/net/ethernet/natsemi/natsemi.c: In function âeeprom_readâ:
> drivers/net/ethernet/natsemi/natsemi.c:1019:3: warning: passing argument 1 of âinlâ makes integer from pointer without a cast [enabled by default]
> In file included from include/linux/io.h:22:0,
> from include/linux/pci.h:54,
> from drivers/net/ethernet/natsemi/natsemi.c:38:
>
>
> looking at a more recent version of natsemi-diag.c , i even found this one:
>
> ftp://ftp.gwdg.de/pub/linux/misc/donald.becker/diag/natsemi-diag.c
>
> /* Delay between EEPROM clock transitions.
> This flushes the write buffer to prevent quick double-writes.
> */
> #define eeprom_delay(ee_addr) inl(ee_addr); inl(ee_addr)
>
> The question is how to make a proper fix, as i don`t know what to pass to inl() , as it seems it should not get an mmapped adress but an i/o port instead !?
>
> "The in*() functions return data read from the specified I/O port"
>
> "The read*() functions read data from device memory previously mapped by map_memory()"
>
> regards
> roland
>
> ps: CC driver maintainer from Kernel Maintainers file.
>
>
>
> Roland Kletzing | 17 Dec 13:38 2012
> bug? mac 00:00:00:00:00:00 with natsemi DP83815 after driver load
>
> Hello,
> i recently played with my older evo t20/wyse 3235le thin clients and flashed
> a linux kernel into those, apparently there seems an issue with the natsemi
> driver.
>
> after driver load (natsemi.ko) eth0 has no valid mac adress, dmesg and
> ifconfig shows just zero`s: 00:00:00:00:00:00.
>
> despite that , the nic is working fine for me (in this test setup i set the
> mac manually: ifconfig eth0 hw ether de:ad:be:ef:be:ef )
>
> apparently, the driver fails to read the proper mac from the eeprom, as
> "natsemi-diag -ee" (from nictools-pci in debian squeeze) shows, that there
> is a valid "Ethernet MAC Station Address" stored inside the eeprom. (see
> below)
>
> looks like a driver bug !?
> does anybody have a clue what`s going wrong here?
>
> regards
> roland
>
> #lspci
>
> 00:00.0 Host bridge: Cyrix Corporation PCI Master
> 00:0f.0 Ethernet controller: National Semiconductor Corporation DP83815
> (MacPhyter) Ethernet Controller
> 00:12.0 ISA bridge: Cyrix Corporation 5530 Legacy [Kahlua] (rev 30)
> 00:12.1 Bridge: Cyrix Corporation 5530 SMI [Kahlua]
> 00:12.2 IDE interface: Cyrix Corporation 5530 IDE [Kahlua]
> 00:12.3 Multimedia audio controller: Cyrix Corporation 5530 Audio [Kahlua]
> 00:12.4 VGA compatible controller: Cyrix Corporation 5530 Video [Kahlua]
> 00:13.0 USB Controller: Compaq Computer Corporation ZFMicro Chipset USB (rev
> 06)
>
> #dmesg |egrep "natsemi|eth"
> natsemi dp8381x driver, version 2.1, Sept 11, 2006
> natsemi 0000:00:0f.0: setting latency timer to 64
> natsemi eth0: NatSemi DP8381[56] at 0x4010000 (0000:00:0f.0),
> 00:00:00:00:00:00, IRQ 10, port TP.
> eth0: DSPCFG accepted after 0 usec.
> eth0: link up.
> eth0: Setting full-duplex based on negotiated link capability.
>
> #natsemi-diag -aa
> natsemi-diag.c:v2.08 2/28/2005 Donald Becker (becker <at> scyld.com)
> http://www.scyld.com/diag/index.html
> Index #1: Found a NatSemi DP83815 adapter at 0xf800.
> Natsemi 83815 series with station address de:ad:be:ef:be:ef
> Transceiver setting Autonegotation advertise 10/100 Mbps half and full
> duplex.
> This device appears to be active, so some registers will not be read.
> To see all register values use the '-f' flag.
> NatSemi DP83815 chip registers at 0xf800
> 0x000: 00000004 e805e000 00000002 00000000 ******** 00f1cd65 00000001
> 00000000
> 0x020: 03abd200 d0f01002 00000000 00000000 03abd000 18700010 00000000
> 00000000
> 0x040: ******** 00200000 00000004 0000efbe ffff000b 30303030 00000403
> 00000000
> 0x060: ******** ******** ******** ******** ******** ******** ********
> ********
> 0x080: 00003100 0000786d 00002000 00005c21 000005e1 000045e1 00000005
> 00002801
> 0x0A0: ******** ******** ******** ******** ******** ******** ********
> ********
> 0x0C0: 00000615 00000002 00000000 00000000 00000000 00000000 00000100
> 00000030
> 0x0E0: 00000000 000000bf 00000804 00008200 00000000 00000000 00000000
> 00000000
> Interrupt sources are pending (00000200).
> Tx queue emptied indication.
> Receive mode is 0xc8200000: Normal unicast and hashed multicast.
> Rx filter contents: adde efbe efbe 0000 0000 0000 0000 0000
>
> #natsemi-diag -ee
> natsemi-diag.c:v2.08 2/28/2005 Donald Becker (becker <at> scyld.com)
> http://www.scyld.com/diag/index.html
> Index #1: Found a NatSemi DP83815 adapter at 0xf800.
> Natsemi 83815 series with station address de:ad:be:ef:be:ef
> Transceiver setting Autonegotation advertise 10/100 Mbps half and full
> duplex.
> EEPROM address length 6, 64 words.
> EEPROM contents (64 words):
> 0x00: 100b 0020 0b34 41fb 0000 0000 0000 4000
> 0x08: 0d32 dff4 1905 aa48 0000 0000 129c 4c4c
> 0x10: ca52 2ccc 0cb2 9c6c 0c6c 8c0c 2020 6080
> 0x18: 0800 0000 0000 0000 0000 0000 0000 0000
> 0x20: 0000 0000 0000 0000 0000 0000 0000 0000
> 0x28: 0000 0000 0000 0000 0000 0000 0000 0000
> 0x30: 0000 0000 0000 0000 0000 0000 0000 0000
> 0x38: 0000 0000 0000 0000 0000 0000 0000 e418
> Decoded EEPROM contents:
> PCI Subsystem IDs -- Vendor 0x100b, Device 0x0020.
> PCI timer settings -- minimum grant 11, maximum latency 52.
> Ethernet MAC Station Address 00:80:64:1a:e8:bf.
> Wake-On-LAN password 00:00:00:00:00:00.
> Transceiver setting 0x--f-: advertise 10/100 Mbps half and full duplex.
> Flow control enabled.
> EEPROM active region checksum read as aa48, vs aa48 calculated value.
^ permalink raw reply related
* Re: [PATCH] [bonding]: clear header_ops when last slave detached
From: Wengang @ 2014-11-17 1:19 UTC (permalink / raw)
To: netdev; +Cc: Wengang Wang
In-Reply-To: <1415845156-15461-1-git-send-email-wen.gang.wang@oracle.com>
Hi,
Could anybody please review this patch?
thanks,
wengang
于 2014年11月13日 10:19, Wengang Wang 写道:
> When last slave of a bonding master is removed, the bonding then does not work.
> When packet_snd is called against with a master net_device, it accesses
> header_ops. In case the header_ops is not valid any longer(say module unloaded)
> it will then access an invalid memory address.
> This patch try to fix this issue by clearing header_ops when last slave
> detached.
>
> Signed-off-by: Wengang Wang <wen.gang.wang@oracle.com>
> ---
> drivers/net/bonding/bond_main.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index c9ac06c..84a34fc 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -1728,6 +1728,8 @@ static int __bond_release_one(struct net_device *bond_dev,
> unblock_netpoll_tx();
> synchronize_rcu();
> bond->slave_cnt--;
> + if (!bond->slave_cnt)
> + bond->dev->header_ops = NULL;
>
> if (!bond_has_slaves(bond)) {
> call_netdevice_notifiers(NETDEV_CHANGEADDR, bond->dev);
^ permalink raw reply
* ipx: fix locking regression in ipx_sendmsg and ipx_recvmsg
From: Jiri Bohac @ 2014-11-17 1:34 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, netdev; +Cc: Arnd Bergmann
This fixes an old regression introduced by commit
b0d0d915 (ipx: remove the BKL).
When a recvmsg syscall blocks waiting for new data, no data can be sent on the
same socket with sendmsg because ipx_recvmsg() sleeps with the socket locked.
This breaks mars-nwe (NetWare emulator):
- the ncpserv process reads the request using recvmsg
- ncpserv forks and spawns nwconn
- ncpserv calls a (blocking) recvmsg and waits for new requests
- nwconn deadlocks in sendmsg on the same socket
Commit b0d0d915 has simply replaced BKL locking with
lock_sock/release_sock. Unlike now, BKL got unlocked while
sleeping, so a blocking recvmsg did not block a concurrent
sendmsg.
Similarly, a potentially sleeping sendmsg() could block calls to recvmsg().
Only keep the socket locked while actually working with the socket data and
release it prior to calling skb_recv_datagram() / ipxitf_send().
Signed-off-by: Jiri Bohac <jbohac@suse.cz>
diff --git a/net/ipx/af_ipx.c b/net/ipx/af_ipx.c
index 91729b8..1e0d796 100644
--- a/net/ipx/af_ipx.c
+++ b/net/ipx/af_ipx.c
@@ -1703,11 +1703,11 @@ static int ipx_sendmsg(struct kiocb *iocb, struct socket *sock,
/* if (sk->sk_zapped)
return -EIO; */ /* Socket not bound */
if (flags & ~(MSG_DONTWAIT|MSG_CMSG_COMPAT))
- goto out;
+ goto out_release;
/* Max possible packet size limited by 16 bit pktsize in header */
if (len >= 65535 - sizeof(struct ipxhdr))
- goto out;
+ goto out_release;
if (usipx) {
if (!ipxs->port) {
@@ -1718,24 +1718,24 @@ static int ipx_sendmsg(struct kiocb *iocb, struct socket *sock,
#ifdef CONFIG_IPX_INTERN
rc = -ENETDOWN;
if (!ipxs->intrfc)
- goto out; /* Someone zonked the iface */
+ goto out_release; /* Someone zonked the iface */
memcpy(uaddr.sipx_node, ipxs->intrfc->if_node,
IPX_NODE_LEN);
#endif
rc = __ipx_bind(sock, (struct sockaddr *)&uaddr,
sizeof(struct sockaddr_ipx));
if (rc)
- goto out;
+ goto out_release;
}
rc = -EINVAL;
if (msg->msg_namelen < sizeof(*usipx) ||
usipx->sipx_family != AF_IPX)
- goto out;
+ goto out_release;
} else {
rc = -ENOTCONN;
if (sk->sk_state != TCP_ESTABLISHED)
- goto out;
+ goto out_release;
usipx = &local_sipx;
usipx->sipx_family = AF_IPX;
@@ -1745,12 +1745,16 @@ static int ipx_sendmsg(struct kiocb *iocb, struct socket *sock,
memcpy(usipx->sipx_node, ipxs->dest_addr.node, IPX_NODE_LEN);
}
+ /* releases sk */
rc = ipxrtr_route_packet(sk, usipx, msg->msg_iov, len,
flags & MSG_DONTWAIT);
if (rc >= 0)
rc = len;
-out:
+ goto out;
+
+out_release:
release_sock(sk);
+out:
return rc;
}
@@ -1776,20 +1780,21 @@ static int ipx_recvmsg(struct kiocb *iocb, struct socket *sock,
#ifdef CONFIG_IPX_INTERN
rc = -ENETDOWN;
if (!ipxs->intrfc)
- goto out; /* Someone zonked the iface */
+ goto out_release; /* Someone zonked the iface */
memcpy(uaddr.sipx_node, ipxs->intrfc->if_node, IPX_NODE_LEN);
#endif /* CONFIG_IPX_INTERN */
rc = __ipx_bind(sock, (struct sockaddr *)&uaddr,
sizeof(struct sockaddr_ipx));
if (rc)
- goto out;
+ goto out_release;
}
rc = -ENOTCONN;
if (sock_flag(sk, SOCK_ZAPPED))
- goto out;
+ goto out_release;
+ release_sock(sk);
skb = skb_recv_datagram(sk, flags & ~MSG_DONTWAIT,
flags & MSG_DONTWAIT, &rc);
if (!skb) {
@@ -1807,8 +1812,10 @@ static int ipx_recvmsg(struct kiocb *iocb, struct socket *sock,
rc = skb_copy_datagram_iovec(skb, sizeof(struct ipxhdr), msg->msg_iov,
copied);
- if (rc)
- goto out_free;
+ if (rc) {
+ skb_free_datagram(sk, skb);
+ goto out;
+ }
if (skb->tstamp.tv64)
sk->sk_stamp = skb->tstamp;
@@ -1822,11 +1829,11 @@ static int ipx_recvmsg(struct kiocb *iocb, struct socket *sock,
msg->msg_namelen = sizeof(*sipx);
}
rc = copied;
+ goto out;
-out_free:
- skb_free_datagram(sk, skb);
-out:
+out_release:
release_sock(sk);
+out:
return rc;
}
diff --git a/net/ipx/ipx_route.c b/net/ipx/ipx_route.c
index 67e7ad3..2f082af 100644
--- a/net/ipx/ipx_route.c
+++ b/net/ipx/ipx_route.c
@@ -163,6 +163,7 @@ int ipxrtr_route_skb(struct sk_buff *skb)
/*
* Route an outgoing frame from a socket.
+ * Expects sk to be locked and releases it before returning.
*/
int ipxrtr_route_packet(struct sock *sk, struct sockaddr_ipx *usipx,
struct iovec *iov, size_t len, int noblock)
@@ -184,7 +185,7 @@ int ipxrtr_route_packet(struct sock *sk, struct sockaddr_ipx *usipx,
rt = ipxrtr_lookup(usipx->sipx_network);
rc = -ENETUNREACH;
if (!rt)
- goto out;
+ goto out_release;
intrfc = rt->ir_intrfc;
}
@@ -242,12 +243,16 @@ int ipxrtr_route_packet(struct sock *sk, struct sockaddr_ipx *usipx,
else
ipx->ipx_checksum = ipx_cksum(ipx, len + sizeof(struct ipxhdr));
+ release_sock(sk);
rc = ipxitf_send(intrfc, skb, (rt && rt->ir_routed) ?
rt->ir_router_node : ipx->ipx_dest.node);
+ goto out;
out_put:
ipxitf_put(intrfc);
if (rt)
ipxrtr_put(rt);
+out_release:
+ release_sock(sk);
out:
return rc;
}
--
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CZ
^ 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