* Re: [PATCH] net: fec: stop the "rcv is not +last, " error messages
From: Fabio Estevam @ 2016-03-31 10:58 UTC (permalink / raw)
To: Greg Ungerer; +Cc: Troy Kisky, netdev@vger.kernel.org
In-Reply-To: <56FC7A96.9070002@uclinux.org>
Hi Greg,
On Wed, Mar 30, 2016 at 10:17 PM, Greg Ungerer <gerg@uclinux.org> wrote:
> Yes, that fixes it. Will you carry this change?
Thanks for confirming.
Yes, I will submit it later today;
^ permalink raw reply
* Re: [PATCH] net: fec: stop the "rcv is not +last, " error messages
From: Fabio Estevam @ 2016-03-31 10:56 UTC (permalink / raw)
To: Fugang Duan; +Cc: Greg Ungerer, Troy Kisky, netdev@vger.kernel.org
In-Reply-To: <VI1PR0401MB1855458E0B31502D1C112AF6FF990@VI1PR0401MB1855.eurprd04.prod.outlook.com>
Hi Andy,
On Wed, Mar 30, 2016 at 10:41 PM, Fugang Duan <fugang.duan@nxp.com> wrote:
>
> Fabio, we cannot do it like this that may cause confused for the quirk flag "FEC_QUIRK_HAS_RACC".
We can treat FEC_QUIRK_HAS_RACC flag as "this is a non-Coldfire SoC".
>
>
> Hi, Greg,
>
> The header file fec.h define the FEC_FTRL as below, if ColdFire SoC has no this register, we may remove the define in here and define the register according to SOC type. For example, it is ColdFire Soc, define it as 0xFFF. Is it feasible ?
>
This is even worse IMHO. We should not write to a 'fake' register
offset of 0xFFF.
^ permalink raw reply
* Re: [PATCH net-next 1/6] net: skbuff: don't use union for napi_id and sender_cpu
From: Eric Dumazet @ 2016-03-31 10:32 UTC (permalink / raw)
To: Jason Wang; +Cc: davem, mst, netdev, linux-kernel
In-Reply-To: <1459403439-6011-2-git-send-email-jasowang@redhat.com>
On Thu, 2016-03-31 at 13:50 +0800, Jason Wang wrote:
> We use a union for napi_id and send_cpu, this is ok for most of the
> cases except when we want to support busy polling for tun which needs
> napi_id to be stored and passed to socket during tun_net_xmit(). In
> this case, napi_id was overridden with sender_cpu before tun_net_xmit()
> was called if XPS was enabled. Fixing by not using union for napi_id
> and sender_cpu.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> include/linux/skbuff.h | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 15d0df9..8aee891 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -743,11 +743,11 @@ struct sk_buff {
> __u32 hash;
> __be16 vlan_proto;
> __u16 vlan_tci;
> -#if defined(CONFIG_NET_RX_BUSY_POLL) || defined(CONFIG_XPS)
> - union {
> - unsigned int napi_id;
> - unsigned int sender_cpu;
> - };
> +#if defined(CONFIG_NET_RX_BUSY_POLL)
> + unsigned int napi_id;
> +#endif
> +#if defined(CONFIG_XPS)
> + unsigned int sender_cpu;
> #endif
> union {
> #ifdef CONFIG_NETWORK_SECMARK
Hmmm...
This is a serious problem.
Making skb bigger (8 bytes because of alignment) was not considered
valid for sender_cpu introduction. We worked quite hard to avoid this,
if you take a look at git history :(
Can you describe more precisely the problem and code path ?
^ permalink raw reply
* [PATCH] netlink: use nla_get_in_addr and nla_put_in_addr for ipv4 address
From: Haishuang Yan @ 2016-03-31 10:21 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy
Cc: netdev, linux-kernel, Haishuang Yan
Since nla_get_in_addr and nla_put_in_addr were implemented,
so use them appropriately.
Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
---
net/ipv4/ip_tunnel_core.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/ip_tunnel_core.c b/net/ipv4/ip_tunnel_core.c
index 02dd990..47ea85d 100644
--- a/net/ipv4/ip_tunnel_core.c
+++ b/net/ipv4/ip_tunnel_core.c
@@ -247,10 +247,10 @@ static int ip_tun_build_state(struct net_device *dev, struct nlattr *attr,
tun_info->key.tun_id = nla_get_be64(tb[LWTUNNEL_IP_ID]);
if (tb[LWTUNNEL_IP_DST])
- tun_info->key.u.ipv4.dst = nla_get_be32(tb[LWTUNNEL_IP_DST]);
+ tun_info->key.u.ipv4.dst = nla_get_in_addr(tb[LWTUNNEL_IP_DST]);
if (tb[LWTUNNEL_IP_SRC])
- tun_info->key.u.ipv4.src = nla_get_be32(tb[LWTUNNEL_IP_SRC]);
+ tun_info->key.u.ipv4.src = nla_get_in_addr(tb[LWTUNNEL_IP_SRC]);
if (tb[LWTUNNEL_IP_TTL])
tun_info->key.ttl = nla_get_u8(tb[LWTUNNEL_IP_TTL]);
@@ -275,8 +275,8 @@ static int ip_tun_fill_encap_info(struct sk_buff *skb,
struct ip_tunnel_info *tun_info = lwt_tun_info(lwtstate);
if (nla_put_be64(skb, LWTUNNEL_IP_ID, tun_info->key.tun_id) ||
- nla_put_be32(skb, LWTUNNEL_IP_DST, tun_info->key.u.ipv4.dst) ||
- nla_put_be32(skb, LWTUNNEL_IP_SRC, tun_info->key.u.ipv4.src) ||
+ nla_put_in_addr(skb, LWTUNNEL_IP_DST, tun_info->key.u.ipv4.dst) ||
+ nla_put_in_addr(skb, LWTUNNEL_IP_SRC, tun_info->key.u.ipv4.src) ||
nla_put_u8(skb, LWTUNNEL_IP_TOS, tun_info->key.tos) ||
nla_put_u8(skb, LWTUNNEL_IP_TTL, tun_info->key.ttl) ||
nla_put_be16(skb, LWTUNNEL_IP_FLAGS, tun_info->key.tun_flags))
--
1.8.3.1
^ permalink raw reply related
* Re: am335x: no multicast reception over VLAN
From: Yegor Yefremov @ 2016-03-31 10:16 UTC (permalink / raw)
To: Mugunthan V N
Cc: Peter Korsgaard, Grygorii Strashko, netdev,
linux-omap@vger.kernel.org, drivshin, ml
In-Reply-To: <56FCF5BB.2030000@ti.com>
On Thu, Mar 31, 2016 at 12:02 PM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
> On Thursday 31 March 2016 01:22 PM, Yegor Yefremov wrote:
>> On Thu, Mar 31, 2016 at 8:37 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>>> On Thursday 31 March 2016 01:17 AM, Peter Korsgaard wrote:
>>>>>>>>> "Mugunthan" == Mugunthan V N <mugunthanvnm@ti.com> writes:
>>>>
>>>> Hi,
>>>>
>>>> > You had received these packets as tcpdump will enable promiscuous mode
>>>> > so that you receive all the packets from the wire.
>>>>
>>>> FYI, you can use the -p option to tcpdump to not put the interface into
>>>> promiscuous mode.
>>>>
>>>
>>> Thanks for the information Peter Korsgaard.
>>>
>>> Yegor, can you provide tcpdump using -p as well in Grygorii commands.
>>
>> Before VLAN configuration:
>>
>> # switch-config -d
>> cpsw hw version 1.12 (0)
>> 0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
>> unreg_mcast = 0x0, member_list = 0x3
>> 1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
>> no super, port_mask = 0x3
>> 2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
>> persistant, port_num = 0x0, Secure
>> 3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
>> unreg_mcast = 0x0, member_list = 0x7
>> 4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
>> no super, port_mask = 0x3
>> 5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
>> unreg_mcast = 0x0, member_list = 0x5
>> 6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
>> no super, port_mask = 0x5
>> 7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
>> persistant, port_num = 0x0, Secure
>> 8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
>> no super, port_mask = 0x5
>>
>> After VLAN configuration:
>>
>> # switch-config -d
>> cpsw hw version 1.12 (0)
>> 0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
>> unreg_mcast = 0x0, member_list = 0x3
>> 1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
>> no super, port_mask = 0x3
>> 2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
>> persistant, port_num = 0x0, Secure
>> 3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
>> unreg_mcast = 0x0, member_list = 0x7
>> 4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
>> no super, port_mask = 0x3
>> 5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
>> unreg_mcast = 0x0, member_list = 0x5
>> 6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
>> no super, port_mask = 0x5
>> 7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
>> persistant, port_num = 0x0, Secure
>> 8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
>> no super, port_mask = 0x5
>> 9 : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5,
>> unreg_mcast = 0x0, member_list = 0x5
>> 10 : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type =
>> persistant, port_num = 0x0
>> 11 : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state =
>> f, no super, port_mask = 0x5
>> 12 : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f,
>> no super, port_mask = 0x5
>>
>> During mulitcast receive:
>>
>> # switch-config -d
>> cpsw hw version 1.12 (0)
>> 0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
>> unreg_mcast = 0x0, member_list = 0x3
>> 1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
>> no super, port_mask = 0x3
>> 2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
>> persistant, port_num = 0x0, Secure
>> 3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
>> unreg_mcast = 0x0, member_list = 0x7
>> 4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
>> no super, port_mask = 0x3
>> 5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
>> unreg_mcast = 0x0, member_list = 0x5
>> 6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
>> no super, port_mask = 0x5
>> 7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
>> persistant, port_num = 0x0, Secure
>> 8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
>> no super, port_mask = 0x5
>> 9 : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5,
>> unreg_mcast = 0x0, member_list = 0x5
>> 10 : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type =
>> persistant, port_num = 0x0
>> 11 : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state =
>> f, no super, port_mask = 0x5
>> 12 : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f,
>> no super, port_mask = 0x5
>> 13 : type: mcast, vid = 2, addr = 01:00:5e:03:1d:47, mcast_state = f,
>> no super, port_mask = 0x5
>> 14 : type: ucast, vid = 100, addr = 66:22:04:bc:90:26, ucast_type =
>> untouched , port_num = 0x2
>
> I could see multicast address 01:00:5e:03:1d:47 is added to ALE table at
> index 13, but it is added for VLAN id 2 ie eth1, did you ran the test
> for eth1 or eth1.100?
My routing table looks as follows:
# route add -net 224.0.0.0 netmask 224.0.0.0 eth1.100
# ip route show
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.233
192.168.100.0/24 dev eth1.100 proto kernel scope link src 192.168.100.2
192.168.254.0/24 dev eth0 proto kernel scope link src 192.168.254.254
224.0.0.0/3 dev eth1.100 scope link
so multicast packets should go via eth1.100
Yegor
^ permalink raw reply
* Re: am335x: no multicast reception over VLAN
From: Mugunthan V N @ 2016-03-31 10:02 UTC (permalink / raw)
To: Yegor Yefremov
Cc: Peter Korsgaard, Grygorii Strashko, netdev,
linux-omap@vger.kernel.org, drivshin, ml
In-Reply-To: <CAGm1_kutVn+jNf58QwKyO8j5NmRhaOCUsXmpTiLbX75AczCm6w@mail.gmail.com>
On Thursday 31 March 2016 01:22 PM, Yegor Yefremov wrote:
> On Thu, Mar 31, 2016 at 8:37 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>> On Thursday 31 March 2016 01:17 AM, Peter Korsgaard wrote:
>>>>>>>> "Mugunthan" == Mugunthan V N <mugunthanvnm@ti.com> writes:
>>>
>>> Hi,
>>>
>>> > You had received these packets as tcpdump will enable promiscuous mode
>>> > so that you receive all the packets from the wire.
>>>
>>> FYI, you can use the -p option to tcpdump to not put the interface into
>>> promiscuous mode.
>>>
>>
>> Thanks for the information Peter Korsgaard.
>>
>> Yegor, can you provide tcpdump using -p as well in Grygorii commands.
>
> Before VLAN configuration:
>
> # switch-config -d
> cpsw hw version 1.12 (0)
> 0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
> unreg_mcast = 0x0, member_list = 0x3
> 1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x3
> 2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
> persistant, port_num = 0x0, Secure
> 3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
> unreg_mcast = 0x0, member_list = 0x7
> 4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x3
> 5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
> unreg_mcast = 0x0, member_list = 0x5
> 6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x5
> 7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0, Secure
> 8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x5
>
> After VLAN configuration:
>
> # switch-config -d
> cpsw hw version 1.12 (0)
> 0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
> unreg_mcast = 0x0, member_list = 0x3
> 1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x3
> 2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
> persistant, port_num = 0x0, Secure
> 3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
> unreg_mcast = 0x0, member_list = 0x7
> 4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x3
> 5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
> unreg_mcast = 0x0, member_list = 0x5
> 6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x5
> 7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0, Secure
> 8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x5
> 9 : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5,
> unreg_mcast = 0x0, member_list = 0x5
> 10 : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0
> 11 : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state =
> f, no super, port_mask = 0x5
> 12 : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f,
> no super, port_mask = 0x5
>
> During mulitcast receive:
>
> # switch-config -d
> cpsw hw version 1.12 (0)
> 0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
> unreg_mcast = 0x0, member_list = 0x3
> 1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x3
> 2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
> persistant, port_num = 0x0, Secure
> 3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
> unreg_mcast = 0x0, member_list = 0x7
> 4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x3
> 5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
> unreg_mcast = 0x0, member_list = 0x5
> 6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x5
> 7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0, Secure
> 8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x5
> 9 : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5,
> unreg_mcast = 0x0, member_list = 0x5
> 10 : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0
> 11 : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state =
> f, no super, port_mask = 0x5
> 12 : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f,
> no super, port_mask = 0x5
> 13 : type: mcast, vid = 2, addr = 01:00:5e:03:1d:47, mcast_state = f,
> no super, port_mask = 0x5
> 14 : type: ucast, vid = 100, addr = 66:22:04:bc:90:26, ucast_type =
> untouched , port_num = 0x2
I could see multicast address 01:00:5e:03:1d:47 is added to ALE table at
index 13, but it is added for VLAN id 2 ie eth1, did you ran the test
for eth1 or eth1.100?
Regards
Mugunthan V N
^ permalink raw reply
* IPv6: routing/forwarding/masking link-local addresses
From: Michal Kazior @ 2016-03-31 9:44 UTC (permalink / raw)
To: Network Development, linux-wireless
Hi,
The most commonly used framing/addressing in 802.11 is 3addr. This is
how most Access Points work and Clients follow suit.
However it is impossible to put a 3addr Client interface into a bridge
because it's not possible to properly distinguish RA/TA/DA/SA
addresses.
There is 4addr framing in 802.11 (often referred to as WDS or
Repeater) but it's a loose standard and various vendors implement it
differently. For this kind of framing to work both AP and Client must
support the same flavor of the framing. Many APs don't even allow the
user to enable WDS. This makes it troublesome to extend wireless
networks without replacing AP equipment (upgrading AP software isn't
always an option).
There is already a userspace tool which solves this problem for IPv4
called relayd [1]. It forwards ARP/DHCP packets (and replaces MAC
addresses accordingly) between non-bridged interfaces and adds
additional route entries to the firewall to, effectively, act as a
bridge transparently. via routing. Compared to ARP Proxy it doesn't
require IP address configuration on local interfaces.
I'm trying to add IPv6 support for relayd. The problem is I can't get
link-local addresses to route properly.
I can easily get things like 2000::/32 to route perfectly fine but
fe80:: just won't work. Upon inspection I've noticed:
; ip link add veth0 type veth peer name veth1
; ip link set veth0 up
; ip link set veth1 up
; ip route add fe80::1 dev veth0
; ip route add 2000::1 dev veth0
; ip route get iif veth1 fe80::1
fe80::1 from :: dev veth1 metric 0
cache iif veth1
; ip route get iif veth1 2000::1
2000::1 from :: dev veth0 metric 0
cache iif veth1
; ip link del veth0
If I remove default fe80::/64 routes I get:
; ip link del veth0
; ip link add veth0 type veth peer name veth1
; ip link set veth0 up
; ip link set veth1 up
; ip route del fe80::/64 dev veth0
; ip route del fe80::/64 dev veth1
; ip route add fe80::1 dev veth0
; ip route add 2000::1 dev veth0
; ip route get iif veth1 fe80::1
unreachable fe80::1 from :: dev lo table unspec proto kernel metric
4294967295 error -101 iif veth1
; ip route get iif veth1 2000::1
2000::1 from :: dev veth0 metric 0
cache iif veth1
The fe80:: route gets ignored completely in both cases.
My question is: can I make it work (a kernel knob I'm not aware of) or
does it require patching the kernel? Thoughts/ideas/hints?
Michał
[1]: http://git.openwrt.org/?p=project/relayd.git;a=summary
^ permalink raw reply
* Re: [PATCH net] tun, bpf: fix suspicious RCU usage in tun_{attach,detach}_filter
From: Jiri Slaby @ 2016-03-31 9:15 UTC (permalink / raw)
To: Daniel Borkmann, davem
Cc: alexei.starovoitov, mkubecek, sasha.levin, eric.dumazet, mst,
netdev
In-Reply-To: <755ee9ec1f6d2229be41806964b372548e4b7586.1459382574.git.daniel@iogearbox.net>
On 03/31/2016, 02:13 AM, Daniel Borkmann wrote:
> Sasha Levin reported a suspicious rcu_dereference_protected() warning
> found while fuzzing with trinity that is similar to this one:
>
> [ 52.765684] net/core/filter.c:2262 suspicious rcu_dereference_protected() usage!
> [ 52.765688] other info that might help us debug this:
> [ 52.765695] rcu_scheduler_active = 1, debug_locks = 1
> [ 52.765701] 1 lock held by a.out/1525:
> [ 52.765704] #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff816a64b7>] rtnl_lock+0x17/0x20
> [ 52.765721] stack backtrace:
> [ 52.765728] CPU: 1 PID: 1525 Comm: a.out Not tainted 4.5.0+ #264
> [...]
> [ 52.765768] Call Trace:
> [ 52.765775] [<ffffffff813e488d>] dump_stack+0x85/0xc8
> [ 52.765784] [<ffffffff810f2fa5>] lockdep_rcu_suspicious+0xd5/0x110
> [ 52.765792] [<ffffffff816afdc2>] sk_detach_filter+0x82/0x90
> [ 52.765801] [<ffffffffa0883425>] tun_detach_filter+0x35/0x90 [tun]
> [ 52.765810] [<ffffffffa0884ed4>] __tun_chr_ioctl+0x354/0x1130 [tun]
> [ 52.765818] [<ffffffff8136fed0>] ? selinux_file_ioctl+0x130/0x210
> [ 52.765827] [<ffffffffa0885ce3>] tun_chr_ioctl+0x13/0x20 [tun]
> [ 52.765834] [<ffffffff81260ea6>] do_vfs_ioctl+0x96/0x690
> [ 52.765843] [<ffffffff81364af3>] ? security_file_ioctl+0x43/0x60
> [ 52.765850] [<ffffffff81261519>] SyS_ioctl+0x79/0x90
> [ 52.765858] [<ffffffff81003ba2>] do_syscall_64+0x62/0x140
> [ 52.765866] [<ffffffff817d563f>] entry_SYSCALL64_slow_path+0x25/0x25
>
> Same can be triggered with PROVE_RCU (+ PROVE_RCU_REPEATEDLY) enabled
> from tun_attach_filter() when user space calls ioctl(tun_fd, TUN{ATTACH,
> DETACH}FILTER, ...) for adding/removing a BPF filter on tap devices.
>
> Since the fix in f91ff5b9ff52 ("net: sk_{detach|attach}_filter() rcu
> fixes") sk_attach_filter()/sk_detach_filter() now dereferences the
> filter with rcu_dereference_protected(), checking whether socket lock
> is held in control path.
>
> Since its introduction in 994051625981 ("tun: socket filter support"),
> tap filters are managed under RTNL lock from __tun_chr_ioctl(). Thus the
> sock_owned_by_user(sk) doesn't apply in this specific case and therefore
> triggers the false positive.
>
> Extend the BPF API with __sk_attach_filter()/__sk_detach_filter() pair
> that is used by tap filters and pass in lockdep_rtnl_is_held() for the
> rcu_dereference_protected() checks instead.
It seems to be gone with this patch here.
thanks,
--
js
suse labs
^ permalink raw reply
* [PATCH v2] net: mvpp2: replace MVPP2_CPU_D_CACHE_LINE_SIZE with cache_line_size
From: Jisheng Zhang @ 2016-03-31 9:03 UTC (permalink / raw)
To: davem, mw; +Cc: netdev, linux-kernel, linux-arm-kernel, Jisheng Zhang
The mvpp2 ip maybe used in SoCs which may have have different cacheline
size. Replace the MVPP2_CPU_D_CACHE_LINE_SIZE with cache_line_size.
And since dma_alloc_coherent() is always cacheline size aligned, so
remove the align checks.
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
---
Since v1:
- use cache_line_size() suggested by Marcin
drivers/net/ethernet/marvell/mvpp2.c | 14 +-------------
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index e9aa8d9..868a957 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -321,7 +321,6 @@
/* Lbtd 802.3 type */
#define MVPP2_IP_LBDT_TYPE 0xfffa
-#define MVPP2_CPU_D_CACHE_LINE_SIZE 32
#define MVPP2_TX_CSUM_MAX_SIZE 9800
/* Timeout constants */
@@ -377,7 +376,7 @@
#define MVPP2_RX_PKT_SIZE(mtu) \
ALIGN((mtu) + MVPP2_MH_SIZE + MVPP2_VLAN_TAG_LEN + \
- ETH_HLEN + ETH_FCS_LEN, MVPP2_CPU_D_CACHE_LINE_SIZE)
+ ETH_HLEN + ETH_FCS_LEN, cache_line_size())
#define MVPP2_RX_BUF_SIZE(pkt_size) ((pkt_size) + NET_SKB_PAD)
#define MVPP2_RX_TOTAL_SIZE(buf_size) ((buf_size) + MVPP2_SKB_SHINFO_SIZE)
@@ -4493,10 +4492,6 @@ static int mvpp2_aggr_txq_init(struct platform_device *pdev,
if (!aggr_txq->descs)
return -ENOMEM;
- /* Make sure descriptor address is cache line size aligned */
- BUG_ON(aggr_txq->descs !=
- PTR_ALIGN(aggr_txq->descs, MVPP2_CPU_D_CACHE_LINE_SIZE));
-
aggr_txq->last_desc = aggr_txq->size - 1;
/* Aggr TXQ no reset WA */
@@ -4526,9 +4521,6 @@ static int mvpp2_rxq_init(struct mvpp2_port *port,
if (!rxq->descs)
return -ENOMEM;
- BUG_ON(rxq->descs !=
- PTR_ALIGN(rxq->descs, MVPP2_CPU_D_CACHE_LINE_SIZE));
-
rxq->last_desc = rxq->size - 1;
/* Zero occupied and non-occupied counters - direct access */
@@ -4616,10 +4608,6 @@ static int mvpp2_txq_init(struct mvpp2_port *port,
if (!txq->descs)
return -ENOMEM;
- /* Make sure descriptor address is cache line size aligned */
- BUG_ON(txq->descs !=
- PTR_ALIGN(txq->descs, MVPP2_CPU_D_CACHE_LINE_SIZE));
-
txq->last_desc = txq->size - 1;
/* Set Tx descriptors queue starting address - indirect access */
--
2.8.0.rc3
^ permalink raw reply related
* [PATCH] net: mvpp2: fix maybe-uninitialized warning
From: Jisheng Zhang @ 2016-03-31 9:01 UTC (permalink / raw)
To: davem, mw; +Cc: netdev, linux-kernel, linux-arm-kernel, Jisheng Zhang
This is to fix the following maybe-uninitialized warning:
drivers/net/ethernet/marvell/mvpp2.c:6007:18: warning: 'err' may be
used uninitialized in this function [-Wmaybe-uninitialized]
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index c797971a..e9aa8d9 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -6059,8 +6059,10 @@ static int mvpp2_port_init(struct mvpp2_port *port)
/* Map physical Rx queue to port's logical Rx queue */
rxq = devm_kzalloc(dev, sizeof(*rxq), GFP_KERNEL);
- if (!rxq)
+ if (!rxq) {
+ err = -ENOMEM;
goto err_free_percpu;
+ }
/* Map this Rx queue to a physical queue */
rxq->id = port->first_rxq + queue;
rxq->port = port->id;
--
2.8.0.rc3
^ permalink raw reply related
* Re: [PATCH 0/5] wireless: ti: Convert specialized logging macros to kernel style
From: Eliad Peller @ 2016-03-31 8:59 UTC (permalink / raw)
To: Joe Perches
Cc: Kalle Valo, LKML, linux-wireless@vger.kernel.org,
open list:NETWORKING DRIVERS, Guy Mishol, Uri Mashiach,
Johannes Berg
In-Reply-To: <1459411668.1744.6.camel@perches.com>
On Thu, Mar 31, 2016 at 11:07 AM, Joe Perches <joe@perches.com> wrote:
> On Thu, 2016-03-31 at 10:39 +0300, Kalle Valo wrote:
>> Joe Perches <joe@perches.com> writes:
>> > On Wed, 2016-03-30 at 14:51 +0300, Kalle Valo wrote:
>> > > Joe Perches <joe@perches.com> writes:
>> > > >
>> > > > Using the normal kernel logging mechanisms makes this code
>> > > > a bit more like other wireless drivers.
>> > > Personally I don't see the point but I don't have any strong opinions. A
>> > > bigger problem is that TI drivers are not really in active development
>> > > and that's I'm not thrilled to take big patches like this for dormant
>> > > drivers.
>> > Not very dormant.
>> >
>> > 35 patches in the last year, most of them adding functionality.
>> Oh, I didn't realise it had that many patches. But the driver is
>> orphaned and doesn't have a maintainer so could I then have an ack from
>> one of the active contributors that this ok?
>
> Fine by me.
>
> $ ./scripts/get_maintainer.pl -f --git drivers/net/wireless/ti/
>
> Kalle Valo <kvalo@codeaurora.org> (maintainer:NETWORKING DRIVERS (WIRELESS),commit_signer:27/35=77%)
> Eliad Peller <eliad@wizery.com> (commit_signer:9/35=26%,authored:7/35=20%)
> Guy Mishol <guym@ti.com> (commit_signer:6/35=17%,authored:5/35=14%)
> Johannes Berg <johannes.berg@intel.com> (commit_signer:6/35=17%,authored:3/35=9%)
> Uri Mashiach <uri.mashiach@compulab.co.il> (commit_signer:4/35=11%,authored:4/35=11%)
>
> For those people now added to the cc list,
> here's the original patch thread:
>
> https://lkml.org/lkml/2016/3/7/1099
I don't have a strong opinion here either.
(I do like the trailing newline being added automatically, but that's
hardly an issue...)
Eliad.
^ permalink raw reply
* [PATCH v2] net: mvneta: replace MVNETA_CPU_D_CACHE_LINE_SIZE with cache_line_size
From: Jisheng Zhang @ 2016-03-31 8:54 UTC (permalink / raw)
To: thomas.petazzoni, mw, gregory.clement, davem
Cc: netdev, linux-kernel, linux-arm-kernel, Jisheng Zhang
The mvneta is also used in some Marvell berlin family SoCs which may
have different cacheline size. Replace the MVNETA_CPU_D_CACHE_LINE_SIZE
usage with cache_line_size().
And since dma_alloc_coherent() is always cacheline size aligned, so
remove the align checks.
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
---
Since v1:
- use cache_line_size() suggested by Marcin
drivers/net/ethernet/marvell/mvneta.c | 10 +---------
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 577f7ca..b1db000 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -260,7 +260,6 @@
#define MVNETA_VLAN_TAG_LEN 4
-#define MVNETA_CPU_D_CACHE_LINE_SIZE 32
#define MVNETA_TX_CSUM_DEF_SIZE 1600
#define MVNETA_TX_CSUM_MAX_SIZE 9800
#define MVNETA_ACC_MODE_EXT1 1
@@ -300,7 +299,7 @@
#define MVNETA_RX_PKT_SIZE(mtu) \
ALIGN((mtu) + MVNETA_MH_SIZE + MVNETA_VLAN_TAG_LEN + \
ETH_HLEN + ETH_FCS_LEN, \
- MVNETA_CPU_D_CACHE_LINE_SIZE)
+ cache_line_size())
#define IS_TSO_HEADER(txq, addr) \
((addr >= txq->tso_hdrs_phys) && \
@@ -2764,9 +2763,6 @@ static int mvneta_rxq_init(struct mvneta_port *pp,
if (rxq->descs == NULL)
return -ENOMEM;
- BUG_ON(rxq->descs !=
- PTR_ALIGN(rxq->descs, MVNETA_CPU_D_CACHE_LINE_SIZE));
-
rxq->last_desc = rxq->size - 1;
/* Set Rx descriptors queue starting address */
@@ -2837,10 +2833,6 @@ static int mvneta_txq_init(struct mvneta_port *pp,
if (txq->descs == NULL)
return -ENOMEM;
- /* Make sure descriptor address is cache line size aligned */
- BUG_ON(txq->descs !=
- PTR_ALIGN(txq->descs, MVNETA_CPU_D_CACHE_LINE_SIZE));
-
txq->last_desc = txq->size - 1;
/* Set maximum bandwidth for enabled TXQs */
--
2.8.0.rc3
^ permalink raw reply related
* [PATCH] rds: rds-stress show all zeros after few minutes
From: shamir rabinovitch @ 2016-03-31 0:50 UTC (permalink / raw)
To: rds-devel, netdev; +Cc: davem, shamir.rabinovitch
Issue can be seen on platforms that use 8K and above page size
while rds fragment size is 4K. On those platforms single page is
shared between 2 or more rds fragments. Each fragment has it's own
offeset and rds cong map code need to take this offset to account.
Not taking this offset to account lead to reading the data fragment
as congestion map fragment and hang of the rds transmit due to far
cong map corruption.
Reviewed-by: Wengang Wang <wen.gang.wang@oracle.com>
Reviewed-by: Ajaykumar Hotchandani <ajaykumar.hotchandani@oracle.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Tested-by: Anand Bibhuti <anand.bibhuti@oracle.com>
Signed-off-by: shamir rabinovitch <shamir.rabinovitch@oracle.com>
---
net/rds/ib_recv.c | 2 +-
net/rds/iw_recv.c | 2 +-
net/rds/page.c | 5 +++--
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/net/rds/ib_recv.c b/net/rds/ib_recv.c
index 977fb86..abc8cc8 100644
--- a/net/rds/ib_recv.c
+++ b/net/rds/ib_recv.c
@@ -796,7 +796,7 @@ static void rds_ib_cong_recv(struct rds_connection *conn,
addr = kmap_atomic(sg_page(&frag->f_sg));
- src = addr + frag_off;
+ src = addr + frag->f_sg.offset + frag_off;
dst = (void *)map->m_page_addrs[map_page] + map_off;
for (k = 0; k < to_copy; k += 8) {
/* Record ports that became uncongested, ie
diff --git a/net/rds/iw_recv.c b/net/rds/iw_recv.c
index a66d179..62a1738 100644
--- a/net/rds/iw_recv.c
+++ b/net/rds/iw_recv.c
@@ -585,7 +585,7 @@ static void rds_iw_cong_recv(struct rds_connection *conn,
addr = kmap_atomic(frag->f_page);
- src = addr + frag_off;
+ src = addr + frag->f_offset + frag_off;
dst = (void *)map->m_page_addrs[map_page] + map_off;
for (k = 0; k < to_copy; k += 8) {
/* Record ports that became uncongested, ie
diff --git a/net/rds/page.c b/net/rds/page.c
index 5a14e6d..715cbaa 100644
--- a/net/rds/page.c
+++ b/net/rds/page.c
@@ -135,8 +135,9 @@ int rds_page_remainder_alloc(struct scatterlist *scat, unsigned long bytes,
if (rem->r_offset != 0)
rds_stats_inc(s_page_remainder_hit);
- rem->r_offset += bytes;
- if (rem->r_offset == PAGE_SIZE) {
+ /* some hw (e.g. sparc) require aligned memory */
+ rem->r_offset += ALIGN(bytes, 8);
+ if (rem->r_offset >= PAGE_SIZE) {
__free_page(rem->r_page);
rem->r_page = NULL;
}
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] net: mvneta: explicitly disable BM on 64bit platform
From: Jisheng Zhang @ 2016-03-31 8:13 UTC (permalink / raw)
To: Marcin Wojtas
Cc: Gregory CLEMENT, David S. Miller, Thomas Petazzoni, netdev,
linux-kernel, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAPv3WKcR+JgoguUUEW0_uPoJL_CtxgKz-ZG_rZhGAAB5utzqMw@mail.gmail.com>
Hi Marcin,
On Thu, 31 Mar 2016 08:49:19 +0200 Marcin Wojtas wrote:
> Hi Jisheng,
>
> 2016-03-31 7:53 GMT+02:00 Jisheng Zhang <jszhang@marvell.com>:
> > Hi Gregory,
> >
> > On Wed, 30 Mar 2016 17:11:41 +0200 Gregory CLEMENT wrote:
> >
> >> Hi Jisheng,
> >>
> >> On mer., mars 30 2016, Jisheng Zhang <jszhang@marvell.com> wrote:
> >>
> >> > The mvneta BM can't work on 64bit platform, as the BM hardware expects
> >> > buf virtual address to be placed in the first four bytes of mapped
> >> > buffer, but obviously the virtual address on 64bit platform can't be
> >> > stored in 4 bytes. So we have to explicitly disable BM on 64bit
> >> > platform.
> >>
> >> Actually mvneta is used on Armada 3700 which is a 64bits platform.
> >> Is it true that the driver needs some change to use BM in 64 bits, but
> >> we don't have to disable it.
> >>
> >> Here is the 64 bits part of the patch we have currently on the hardware
> >> prototype. We have more things which are really related to the way the
> >> mvneta is connected to the Armada 3700 SoC. This code was not ready for
> >
> > Thanks for the sharing.
> >
> > I think we could commit easy parts firstly, for example: the cacheline size
> > hardcoding, either piece of your diff or my version:
> >
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/418513.html
>
> Since the commit:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm64/include/asm/cache.h?id=97303480753e48fb313dc0e15daaf11b0451cdb8
> detached L1_CACHE_BYTES from real cache size, I suggest, the macro should be:
> #define MVNETA_CPU_D_CACHE_LINE_SIZE cache_line_size()
Thanks for the hint. I'll send out updated version to address the cacheline size
issue.
>
> Regarding check after dma_alloc_coherent, I agree it's not necessary.
>
> >
> >> mainline but I prefer share it now instead of having the HWBM blindly
> >
> > I have looked through the diff, it is for the driver itself on 64bit platforms,
> > and it doesn't touch BM. The BM itself need to be disabled for 64bit, I'm not
> > sure the BM could work on 64bit even with your diff. Per my understanding, the BM
> > can't work on 64 bit, let's have a look at some piece of the mvneta_bm_construct()
> >
> > *(u32 *)buf = (u32)buf;
>
> Indeed this particular part is different and unclear, I tried
> different options - with no success. I'm checking with design team
> now. Anyway, I managed to enable operation for HWBM on A3700 with one
> work-around in mvneta_hwbm_rx():
> data = phys_to_virt(rx_desc->buf_phys_addr);
oh yes! This seems a good idea. And If we replace all
data = (void *)rx_desc->buf_cookie
with
data = phys_to_virt(rx_desc->buf_phys_addr);
we also resolve the buf_cookie issue on 64bit platforms! no need to introduce
data_high or use existing reserved member to store virtual address' higher 32bits
>
> Of course mvneta_bm, due to some silicone differences needed also a rework.
>
> Actually I'd wait with updating 64-bit parts of mvneta, until real
> support for such machine's controller is introduced. Basing on my
> experience with enabling neta on A3700, it turns out to be more
> changes.
I agree with you. And I need one more rework: berlin SoCs don't have mbus
concept at all ;)
Thanks for your hints,
Jisheng
^ permalink raw reply
* Re: [PATCH 0/5] wireless: ti: Convert specialized logging macros to kernel style
From: Joe Perches @ 2016-03-31 8:07 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-kernel, linux-wireless, netdev, Eliad Peller, Guy Mishol,
Uri Mashiach, Johannes Berg
In-Reply-To: <87y48z3xkz.fsf@purkki.adurom.net>
On Thu, 2016-03-31 at 10:39 +0300, Kalle Valo wrote:
> Joe Perches <joe@perches.com> writes:
> > On Wed, 2016-03-30 at 14:51 +0300, Kalle Valo wrote:
> > > Joe Perches <joe@perches.com> writes:
> > > >
> > > > Using the normal kernel logging mechanisms makes this code
> > > > a bit more like other wireless drivers.
> > > Personally I don't see the point but I don't have any strong opinions. A
> > > bigger problem is that TI drivers are not really in active development
> > > and that's I'm not thrilled to take big patches like this for dormant
> > > drivers.
> > Not very dormant.
> >
> > 35 patches in the last year, most of them adding functionality.
> Oh, I didn't realise it had that many patches. But the driver is
> orphaned and doesn't have a maintainer so could I then have an ack from
> one of the active contributors that this ok?
Fine by me.
$ ./scripts/get_maintainer.pl -f --git drivers/net/wireless/ti/
Kalle Valo <kvalo@codeaurora.org> (maintainer:NETWORKING DRIVERS (WIRELESS),commit_signer:27/35=77%)
Eliad Peller <eliad@wizery.com> (commit_signer:9/35=26%,authored:7/35=20%)
Guy Mishol <guym@ti.com> (commit_signer:6/35=17%,authored:5/35=14%)
Johannes Berg <johannes.berg@intel.com> (commit_signer:6/35=17%,authored:3/35=9%)
Uri Mashiach <uri.mashiach@compulab.co.il> (commit_signer:4/35=11%,authored:4/35=11%)
For those people now added to the cc list,
here's the original patch thread:
https://lkml.org/lkml/2016/3/7/1099
^ permalink raw reply
* RE: [PATCH iproute2 v1 1/1] lib/utils: fix get_addr() and get_prefix() error messages
From: Varlese, Marco @ 2016-03-31 8:04 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev@vger.kernel.org, davem@davemloft.net, Jiri Pirko,
John Fastabend, jhs@mojatatu.com, Szczerbik, PrzemyslawX
In-Reply-To: <20160330165420.36f98115@xeon-e3>
[-- Attachment #1: Type: text/plain, Size: 1571 bytes --]
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Thursday, March 31, 2016 12:54 AM
> To: Varlese, Marco <marco.varlese@intel.com>
> Cc: netdev@vger.kernel.org; davem@davemloft.net; Jiri Pirko
<jiri@resnulli.us>;
> John Fastabend <john.fastabend@gmail.com>; jhs@mojatatu.com; Szczerbik,
> PrzemyslawX <przemyslawx.szczerbik@intel.com>
> Subject: Re: [PATCH iproute2 v1 1/1] lib/utils: fix get_addr() and
get_prefix()
> error messages
>
> On Tue, 22 Mar 2016 13:02:02 +0000
> "Varlese, Marco" <marco.varlese@intel.com> wrote:
>
> > An attempt to add invalid address to interface would print "???" string
> > instead of the address family name.
> >
> > For example:
> > $ ip address add 256.10.166.1/24 dev ens8
> > Error: ??? prefix is expected rather than "256.10.166.1/24".
> >
> > $ ip neighbor add proxy 2001:db8::g dev ens8
> > Error: ??? address is expected rather than "2001:db8::g".
> >
> > With this patch the output will look like:
> > $ ip address add 256.10.166.1/24 dev ens8
> > Error: inet prefix is expected rather than "256.10.166.1/24".
> >
> > $ ip neighbor add proxy 2001:db8::g dev ens8
> > Error: inet6 address is expected rather than "2001:db8::g".
> >
> > Signed-off-by: Przemyslaw Szczerbik <przemyslawx.szczerbik@intel.com>
> > Signed-off-by: Marco Varlese <marco.varlese@intel.com>
> > ---
> > lib/utils.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
>
> If you look at git, I already applied this by manual fix.
Thanks, I didn't see your other email. Thank you for your help!
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 4414 bytes --]
^ permalink raw reply
* Fwd: Urgent- Quotations Needed
From: Nethaji road @ 2016-03-31 7:59 UTC (permalink / raw)
In-Reply-To: <243313206.418853.1459409843137.JavaMail.root@muthoottumini.com>
Dear Sir,
FYI kindly send us proforma ASAP for the attached purchase order.
Thanks
Carmen Rodriguez
^ permalink raw reply
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement
From: Giuseppe CAVALLARO @ 2016-03-31 7:53 UTC (permalink / raw)
To: Dinh Nguyen
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Heiko Stübner, netdev-u79uwXL29TY76Z2rM5mHXA,
Gabriel Fernandez, LKML, Frank Schäfer,
open list:ARM/Rockchip SoC..., LAKML, Fabrice GASNIER,
Andreas Färber, Tomeu Vizoso, Alexandre TORGUE
In-Reply-To: <CADhT+wdXXp322vmgFmWTUiiRZTsCWeJSSdU=BMEEbSyb_bnrUw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 3/30/2016 6:44 PM, Dinh Nguyen wrote:
> On Tue, Mar 15, 2016 at 7:36 AM, Giuseppe CAVALLARO
> <peppe.cavallaro-qxv4g6HH51o@public.gmane.org> wrote:
>> Hello Tomeu
>>
>> On 3/15/2016 8:23 AM, Tomeu Vizoso wrote:
>>>
>>> Thanks.
>>>
>>> Btw, I have rebased on top of 4.5 this morning and I have noticed that
>>> 88f8b1bb41c6 ("stmmac: Fix 'eth0: No PHY found' regression") got in
>>> there, so I guess we have now a bunch of boards with broken network on
>>> that release:(
>>
>>
>>
>> This is the status on my side: I am testing on an HW that has the
>> Enhanced descriptors and all works fine.
>>
>> On this HW, if I force the driver to use the normal descriptor
>> layout, I meet problems but using both net.git and net-next.
>> So I suspect I cannot ply with this HW forcing the normal descriptors.
>> But! That is helping me to check if, on net-next, the stmmac is
>> actually programming fine the normal desc case.
>> I have just found another fix so I kindly ask you to apply the temp
>> patch attached and let me know.
>> In details, I have noticed that the OWN bit was not set in the right
>> TDES0.
>>
>> I also ask you to give me a log of the kernel where the stmmac was
>> running fine. I would like to see which configuration it is selected
>> at runtime by the driver on your box.
>> From your previous logs (where the stmmac failed), it seems that
>> the problem is on normal desc but, to be honest, this is the first
>> case I see a 3.50a with HW capability register and w/o Enhanced
>> descriptors.
>>
>
> Are you still working on a fix for:
>
> [ 1.196110] libphy: PHY stmmac-0:ffffffff not found
> [ 1.200972] eth0: Could not attach to PHY
> [ 1.204991] stmmac_open: Cannot attach to PHY (error: -19)
>
> I see the error still there as of linux-next 20160330.
this could be because the fixes have been not applied on net-next
I will check and resend all asap
peppe
>
> Dinh
>
^ permalink raw reply
* Re: am335x: no multicast reception over VLAN
From: Yegor Yefremov @ 2016-03-31 7:52 UTC (permalink / raw)
To: Mugunthan V N
Cc: Peter Korsgaard, Grygorii Strashko, netdev,
linux-omap@vger.kernel.org, drivshin, ml
In-Reply-To: <56FCC59B.70209@ti.com>
[-- Attachment #1: Type: text/plain, Size: 6225 bytes --]
On Thu, Mar 31, 2016 at 8:37 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
> On Thursday 31 March 2016 01:17 AM, Peter Korsgaard wrote:
>>>>>>> "Mugunthan" == Mugunthan V N <mugunthanvnm@ti.com> writes:
>>
>> Hi,
>>
>> > You had received these packets as tcpdump will enable promiscuous mode
>> > so that you receive all the packets from the wire.
>>
>> FYI, you can use the -p option to tcpdump to not put the interface into
>> promiscuous mode.
>>
>
> Thanks for the information Peter Korsgaard.
>
> Yegor, can you provide tcpdump using -p as well in Grygorii commands.
Before VLAN configuration:
# switch-config -d
cpsw hw version 1.12 (0)
0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
unreg_mcast = 0x0, member_list = 0x3
1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
no super, port_mask = 0x3
2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
persistant, port_num = 0x0, Secure
3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
unreg_mcast = 0x0, member_list = 0x7
4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
no super, port_mask = 0x3
5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
unreg_mcast = 0x0, member_list = 0x5
6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
no super, port_mask = 0x5
7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
persistant, port_num = 0x0, Secure
8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
no super, port_mask = 0x5
After VLAN configuration:
# switch-config -d
cpsw hw version 1.12 (0)
0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
unreg_mcast = 0x0, member_list = 0x3
1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
no super, port_mask = 0x3
2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
persistant, port_num = 0x0, Secure
3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
unreg_mcast = 0x0, member_list = 0x7
4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
no super, port_mask = 0x3
5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
unreg_mcast = 0x0, member_list = 0x5
6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
no super, port_mask = 0x5
7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
persistant, port_num = 0x0, Secure
8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
no super, port_mask = 0x5
9 : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5,
unreg_mcast = 0x0, member_list = 0x5
10 : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type =
persistant, port_num = 0x0
11 : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state =
f, no super, port_mask = 0x5
12 : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f,
no super, port_mask = 0x5
During mulitcast receive:
# switch-config -d
cpsw hw version 1.12 (0)
0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
unreg_mcast = 0x0, member_list = 0x3
1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
no super, port_mask = 0x3
2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
persistant, port_num = 0x0, Secure
3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
unreg_mcast = 0x0, member_list = 0x7
4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
no super, port_mask = 0x3
5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
unreg_mcast = 0x0, member_list = 0x5
6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
no super, port_mask = 0x5
7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
persistant, port_num = 0x0, Secure
8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
no super, port_mask = 0x5
9 : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5,
unreg_mcast = 0x0, member_list = 0x5
10 : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type =
persistant, port_num = 0x0
11 : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state =
f, no super, port_mask = 0x5
12 : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f,
no super, port_mask = 0x5
13 : type: mcast, vid = 2, addr = 01:00:5e:03:1d:47, mcast_state = f,
no super, port_mask = 0x5
14 : type: ucast, vid = 100, addr = 66:22:04:bc:90:26, ucast_type =
untouched , port_num = 0x2
After multicast receive use case:
# switch-config -d
cpsw hw version 1.12 (0)
0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
unreg_mcast = 0x0, member_list = 0x3
1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
no super, port_mask = 0x3
2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
persistant, port_num = 0x0, Secure
3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
unreg_mcast = 0x0, member_list = 0x7
4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
no super, port_mask = 0x3
5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
unreg_mcast = 0x0, member_list = 0x5
6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
no super, port_mask = 0x5
7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
persistant, port_num = 0x0, Secure
8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
no super, port_mask = 0x5
9 : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5,
unreg_mcast = 0x0, member_list = 0x5
10 : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type =
persistant, port_num = 0x0
11 : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state =
f, no super, port_mask = 0x5
12 : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f,
no super, port_mask = 0x5
15 : type: ucast, vid = 100, addr = 66:22:04:bc:90:26, ucast_type =
untouched , port_num = 0x2
Both tcpdumps with -p option showed no packets. If I execute ping, I
can see related ICMP packets. addr = 66:22:04:bc:90:26 is PandaBoards
MAC.
Btw I've attached my test scripts (mcastr.py - multicast receiver and
mcastt.py - multicast transmitter). Could you reproduce my setup?
Thanks.
Yegor
[-- Attachment #2: mcastr.py --]
[-- Type: text/plain, Size: 821 bytes --]
import socket
import struct
import sys
multicast_group = '224.3.29.71'
server_address = ('', 10000)
# Create the socket
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
# Bind to the server address
sock.bind(server_address)
# Tell the operating system to add the socket to the multicast group
# on all interfaces.
group = socket.inet_aton(multicast_group)
mreq = struct.pack('4sL', group, socket.INADDR_ANY)
sock.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, mreq)
# Receive/respond loop
while True:
print >>sys.stderr, '\nwaiting to receive message'
data, address = sock.recvfrom(1024)
print >>sys.stderr, 'received %s bytes from %s' % (len(data), address)
print >>sys.stderr, data
print >>sys.stderr, 'sending acknowledgement to', address
sock.sendto('ack', address)
[-- Attachment #3: mcastt.py --]
[-- Type: text/plain, Size: 1075 bytes --]
import socket
import struct
import sys
message = 'very important data'
multicast_group = ('224.3.29.71', 10000)
# Create the datagram socket
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
# Set a timeout so the socket does not block indefinitely when trying
# to receive data.
sock.settimeout(0.2)
# Set the time-to-live for messages to 1 so they do not go past the
# local network segment.
ttl = struct.pack('b', 1)
sock.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_TTL, ttl)
try:
# Send data to the multicast group
print >>sys.stderr, 'sending "%s"' % message
sent = sock.sendto(message, multicast_group)
# Look for responses from all recipients
while True:
print >>sys.stderr, 'waiting to receive'
try:
data, server = sock.recvfrom(16)
except socket.timeout:
print >>sys.stderr, 'timed out, no more responses'
break
else:
print >>sys.stderr, 'received "%s" from %s' % (data, server)
finally:
print >>sys.stderr, 'closing socket'
sock.close()
^ permalink raw reply
* Re: Question on rhashtable in worst-case scenario.
From: Herbert Xu @ 2016-03-31 7:50 UTC (permalink / raw)
To: Johannes Berg
Cc: Ben Greear, David Miller, linux-kernel, linux-wireless, netdev,
tgraf
In-Reply-To: <1459410405.4576.8.camel@sipsolutions.net>
On Thu, Mar 31, 2016 at 09:46:45AM +0200, Johannes Berg wrote:
>
> In this case, I think perhaps you can just patch your local system with
> the many interfaces connecting to the same AP to add the parameter
> Herbert suggested (.insecure_elasticity = true in sta_rht_params). This
> is, after all, very much a case that "normal" operation doesn't even
> get close to.
I think you should just turn it on everywhere for mac80211. Chain
length checks simply don't make sense when you allow duplicate
keys in the hash table.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Question on rhashtable in worst-case scenario.
From: Johannes Berg @ 2016-03-31 7:46 UTC (permalink / raw)
To: Ben Greear, David Miller
Cc: linux-kernel, herbert, linux-wireless, netdev, tgraf
In-Reply-To: <56FC0445.6010200@candelatech.com>
On Wed, 2016-03-30 at 09:52 -0700, Ben Greear wrote:
> If someone can fix rhashtable, then great.
> I read some earlier comments [1] back when someone else reported
> similar problems, and the comments seemed to indicate that rhashtable
> was broken in this manner on purpose to protect against hashing
> attacks.
>
> If you are baking in this type of policy to what should be a basic
> data-type, then it is not useful for how it is being used in
> the mac80211 stack.
>
> [1] http://lkml.iu.edu/hypermail/linux/kernel/1512.2/01681.html
>
That's not really saying it's purposely broken, that's more saying that
Herbert didn't see a point in fixing a case that has awful behaviour
already.
However, I'm confused now - we can much more easily live with
*insertion* failures, as the linked email indicates, than *deletion*
failures, which I think you had indicated originally. Are you really
seeing *deletion* failures?
If there are in fact *deletion* failures then I think we really need to
address those in rhashtable, no matter the worst-case behaviour of the
hashing or keys, since we should be able to delete entries in order to
get back to something reasonable. Looking at the code though, I don't
actually see that happening.
If you're seeing only *insertion* failures, which you indicated in the
root of this thread, then I think for the general case in mac80211 we
can live with that - we use a seeded jhash for the hash function, and
since in the general case we cannot accept entries with identical MAC
addresses to start with, it shouldn't be possible to run into this
problem under normal use cases.
In this case, I think perhaps you can just patch your local system with
the many interfaces connecting to the same AP to add the parameter
Herbert suggested (.insecure_elasticity = true in sta_rht_params). This
is, after all, very much a case that "normal" operation doesn't even
get close to.
johannes
^ permalink raw reply
* Re: [PATCH] stmmac: Fix phy without MDIO subnode
From: Giuseppe CAVALLARO @ 2016-03-31 7:40 UTC (permalink / raw)
To: Robert Gadsdon, John Keeping; +Cc: Gabriel Fernandez, netdev, linux-kernel
In-Reply-To: <56FC1972.9050704@gmail.com>
Hello Robert
On 3/30/2016 8:22 PM, Robert Gadsdon wrote:
> I have applied this to my Rock2 - Kernel 4.6-rc1 - and eth0 is present,
> now, but no network traffic gets through:
there are some patches not yet applied that fix known
problems
pls take a look at :
"stmmac: MDIO fixes"
and
[PATCH (net-next.git)] STMMAC: fix TX Normal descriptor
peppe
>
> To rock2:
> $ ping rgrock2
> PING rgrock2 (192.168.0.xx) 56(84) bytes of data.
> ^C
> --- rgrock2 ping statistics ---
> 9 packets transmitted, 0 received, 100% packet loss, time 7999ms
>
>>From rock2:
> # ping 192.168.0.x
> PING 192.168.0.x (192.168.0.2) 56(84) bytes of data.
>>From 192.168.0.xx icmp_seq=1 Destination Host Unreachable
>>From 192.168.0.xx icmp_seq=2 Destination Host Unreachable
>>From 192.168.0.xx icmp_seq=3 Destination Host Unreachable
>>From 192.168.0.xx icmp_seq=4 Destination Host Unreachable
>>From 192.168.0.xx icmp_seq=5 Destination Host Unreachable
>>From 192.168.0.xx icmp_seq=6 Destination Host Unreachable
>>From 192.168.0.xx icmp_seq=7 Destination Host Unreachable
>>From 192.168.0.xx icmp_seq=8 Destination Host Unreachable
>
> --- 192.168.0.x ping statistics ---
> 9 packets transmitted, 0 received, +8 errors, 100% packet loss, time 8001ms
>
> Everything worked OK with kernel 4.5-rc7, and with 4.5 Final with the
> -rc7 versions of stmmac_platform.c and stmmac_mdio.c substituted..
>
> Robert Gadsdon. March 30, 2016
>
^ permalink raw reply
* Re: [PATCH 0/5] wireless: ti: Convert specialized logging macros to kernel style
From: Kalle Valo @ 2016-03-31 7:39 UTC (permalink / raw)
To: Joe Perches; +Cc: linux-kernel, linux-wireless, netdev
In-Reply-To: <1459373791.25110.132.camel@perches.com>
Joe Perches <joe@perches.com> writes:
> On Wed, 2016-03-30 at 14:51 +0300, Kalle Valo wrote:
>> Joe Perches <joe@perches.com> writes:
>> > Using the normal kernel logging mechanisms makes this code
>> > a bit more like other wireless drivers.
>> Personally I don't see the point but I don't have any strong opinions. A
>> bigger problem is that TI drivers are not really in active development
>> and that's I'm not thrilled to take big patches like this for dormant
>> drivers.
>
> Not very dormant.
>
> 35 patches in the last year, most of them adding functionality.
Oh, I didn't realise it had that many patches. But the driver is
orphaned and doesn't have a maintainer so could I then have an ack from
one of the active contributors that this ok?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] net: mvneta: remove useless RX descriptor prefetch
From: Jisheng Zhang @ 2016-03-31 7:15 UTC (permalink / raw)
To: thomas.petazzoni, gregory.clement, davem
Cc: netdev, linux-kernel, linux-arm-kernel
In-Reply-To: <20160331144537.20f04a8c@xhacker>
Hi all,
On Thu, 31 Mar 2016 14:45:37 +0800 Jisheng Zhang wrote:
> Hi,
>
> + linux arm kernel
>
> On Thu, 31 Mar 2016 14:36:30 +0800 Jisheng Zhang wrote:
>
> > The rx descriptors are allocated using dma_alloc_coherent, so prefetch
> > doesn't really happen at all.
>
> This is for RFC, I'm sorry to send it without changing its title -- s/PATCH/RFC.
>
> I'm not sure whether there's any benefit to prefetch on space allocated from
> dma_alloc_coherent.
After more consideration, I think my patch is wrong.
As for coherent platforms, the space allocated from dma_alloc_coherent is
cacheable, so prefetch would definitely benefit us.
As for noncoherent platforms, the space allocated from dma_alloc_coherent is
uncacheable, but prefetch on arm/arm64 is implemented via. pld/prfm, the op
would be nop if target address is uncacheable.
So let's drop this patch.
Thanks,
Jisheng
>
> Thanks
>
> >
> > Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
> > ---
> > drivers/net/ethernet/marvell/mvneta.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> > index 5880871..6c09a27 100644
> > --- a/drivers/net/ethernet/marvell/mvneta.c
> > +++ b/drivers/net/ethernet/marvell/mvneta.c
> > @@ -757,7 +757,6 @@ mvneta_rxq_next_desc_get(struct mvneta_rx_queue *rxq)
> > int rx_desc = rxq->next_desc_to_proc;
> >
> > rxq->next_desc_to_proc = MVNETA_QUEUE_NEXT_DESC(rxq, rx_desc);
> > - prefetch(rxq->descs + rxq->next_desc_to_proc);
> > return rxq->descs + rx_desc;
> > }
> >
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Reboot Failed was occurred after v4.4-rc1 during IPv6 Ready Logo Conformance Test
From: Yuki Machida @ 2016-03-31 7:09 UTC (permalink / raw)
To: netdev
Hi all,
Reboot Failed was occurred at Linux Kernel after v4.4-rc1 during IPv6 Ready Logo Conformance Test.
Not Fix a bug in v4.5-rc7 yet.
I will conform that it fix a bug in v4.6-rc1.
Currently, it is under investigation.
IPv6 Ready Logo
https://www.ipv6ready.org/
TAHI Project
http://www.tahi.org/
I ran the IPv6 Ready Logo Core Conformance Test on Intel D510MO (Atom D510).
It is using userland build with yocto project.
Test Environment
Test Specification : 4.0.6
Tool Version : REL_3_3_2
Test Program Version : V6LC_5_0_0
Target Device : Intel D510MO (Atom D510)
I conform that random testcases are failed.
(e.g. No.5, No.130, No.131, No.134, No.167 and No.168)
Regards,
Yuki Machida
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox