Re: Virtio_net support vxlan encapsulation package TSO offload discuss

[Jason Wang]

On 2016年11月17日 09:31, Zhangming (James, Euler) wrote:

On 2016年11月15日 11:28, Jason Wang wrote:

On 2016年11月10日 14:19, Zhangming (James, Euler) wrote:

On 2016年11月09日 15:14, Jason Wang wrote:

On 2016年11月08日 19:58, Zhangming (James, Euler) wrote:

On 2016年11月08日 19:17, Jason Wang wrote:


On 2016年11月08日 19:13, Jason Wang wrote:

Cc Michael

On 2016年11月08日 16:34, Zhangming (James, Euler) wrote:

In container scenario, OVS is installed in the Virtual machine,
and all the containers connected to the OVS will communicated
through VXLAN encapsulation.

By now, virtio_net does not support TSO offload for VXLAN
encapsulated TSO package. In this condition, the performance is
not good, sender is bottleneck

I googled this scenario, but I didn’t find any information. Will
virtio_net support VXLAN encapsulation package TSO offload later?


Yes and for both sender and receiver.


My idea is virtio_net open encapsulated TSO offload, and
transport encapsulation info to TUN, TUN will parse the info and
build skb with encapsulation info.

OVS or kernel on the host should be modified to support this.
Using this method, the TCP performance aremore than 2x as before.

Any advice and suggestions for this idea or new idea will be
greatly appreciated!

Best regards,

  James zhang


Sounds very good. And we may also need features bits
(VIRTIO_NET_F_GUEST|HOST_GSO_X) for this.

This is in fact one of items in networking todo list. (See
http://www.linux-kvm.org/page/NetworkingTodo). While at it, we'd
better support not only VXLAN but also other tunnels.

Cc Vlad who is working on extending virtio-net headers.


We can start with the spec work, or if you've already had some
bits you can post them as RFC for early review.

Thanks

Below is my demo code
Virtio_net.c
static int virtnet_probe(struct virtio_device *vdev), add belows codes:
   if (virtio_has_feature(vdev, VIRTIO_NET_F_MRG_RXBUF) ||  
// avoid gso segment, it should be negotiation later, because 
in the demo I reuse num_buffers.
   virtio_has_feature(vdev, VIRTIO_F_VERSION_1)) {
   dev->hw_enc_features |= NETIF_F_TSO;
   dev->hw_enc_features |= NETIF_F_ALL_CSUM;
   dev->hw_enc_features |= NETIF_F_GSO_UDP_TUNNEL;
   dev->hw_enc_features |= NETIF_F_GSO_UDP_TUNNEL_CSUM;
   dev->hw_enc_features |=
NETIF_F_GSO_TUNNEL_REMCSUM;

   dev->features |= NETIF_F_GSO_UDP_TUNNEL;
   dev->features |= NETIF_F_GSO_UDP_TUNNEL_CSUM;
   dev->features |= NETIF_F_GSO_TUNNEL_REMCSUM;
   }

static int xmit_skb(struct send_queue *sq, struct sk_buff *skb), add
below to pieces of codes

   if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_TUNNEL)
   hdr->hdr.gso_type |= VIRTIO_NET_HDR_GSO_TUNNEL;
   if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_TUNNEL_CSUM)
   hdr->hdr.gso_type |= VIRTIO_NET_HDR_GSO_TUNNEL_CSUM;
   if (skb_shinfo(skb)->gso_type & SKB_GSO_TUNNEL_REMCSUM)
   hdr->hdr.gso_type |=
VIRTIO_NET_HDR_GSO_TUNNEL_REMCSUM;

   if (skb->encapsulation && skb_is_gso(skb)) {
   inner_mac_len = skb_inner_network_header(skb) - 
skb_inner_mac_header(skb);
   tnl_len = skb_inner_mac_header(skb) - skb_mac_header(skb);
   if ( !(inner_mac_len >> DATA_LEN_SHIFT) && !(tnl_len >> 
DATA_LEN_SHIFT) ) {
   hdr->hdr.flags |= VIRTIO_NET_HDR_F_ENCAPSULATION;
   hdr->num_buffers = (__virtio16)((inner_mac_len << 
DATA_LEN_SHIFT) | tnl_len);   //we reuse num_buffers for simple , we should 
add extend member for later.
   }  else
   hdr->num_buffers = 0;
   }

Tun.c
   if (memcpy_fromiovecend((void *), iv, offset, 
tun->vnet_hdr_sz))  //read header with negotiation length
   return -EFAULT;

   if (hdr.gso_type & VIRTIO_NET_HDR_GSO_TUNNEL)
//set tunnel gso info
   skb_shinfo(skb)->gso_type |= SKB_GSO_UDP_TUNNEL;
   if (hdr.gso_type & VIRTIO_NET_HDR_GSO_TUNNEL_CSUM)
   skb_shinfo(skb)->gso_type |= SKB_GSO_UDP_TUNNEL_CSUM;
   if (hdr.gso_type & VIRTIO_NET_HDR_GSO_TUNNEL_REMCSUM)
   skb_shinfo(skb)->gso_type |=
SKB_GSO_TUNNEL_REMCSUM;

   if (hdr.flags & VIRTIO_NET_HDR_F_ENCAPSULATION) {
//read tunnel info from header and set to built skb.
   tnl_len = tun16_to_cpu(tun, hdr.num_buffers) & 
TUN_TNL_LEN_MASK;
   payload_mac_len = tun16_to_cpu(tun, hdr.num_buffers) >> 
TUN_DATA_LEN_SHIFT;
   mac_len = skb_network_header(skb) - skb_mac_header(skb);
   

Re: [Patch net] net: check dead netns for peernet2id_alloc()

[Andrei Vagin]

On Wed, Nov 16, 2016 at 10:27 AM, Cong Wang  wrote:
> Andrei reports we still allocate netns ID from idr after we destroy
> it in cleanup_net().
>
> cleanup_net():
>   ...
>   idr_destroy(>netns_ids);
>   ...
>   list_for_each_entry_reverse(ops, _list, list)
> ops_exit_list(ops, _exit_list);
>   -> rollback_registered_many()
> -> rtmsg_ifinfo_build_skb()
>  -> rtnl_fill_ifinfo()
>-> peernet2id_alloc()
>
> After that point we should not even access net->netns_ids, we
> should check the death of the current netns as early as we can in
> peernet2id_alloc().
>
> For net-next we can consider to avoid sending rtmsg totally,
> it is a good optimization for netns teardown path.

It works for me and looks good. Thanks.

Acked-by: Andrei Vagin 

>
> Fixes: 0c7aecd4bde4 ("netns: add rtnl cmd to add and get peer netns ids")
> Reported-by: Andrei Vagin 
> Cc: Nicolas Dichtel 
> Signed-off-by: Cong Wang 
> ---
>  net/core/net_namespace.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
> index f61c0e0..7001da9 100644
> --- a/net/core/net_namespace.c
> +++ b/net/core/net_namespace.c
> @@ -219,6 +219,8 @@ int peernet2id_alloc(struct net *net, struct net *peer)
> bool alloc;
> int id;
>
> +   if (atomic_read(>count) == 0)
> +   return NETNSA_NSID_NOT_ASSIGNED;
> spin_lock_irqsave(>nsid_lock, flags);
> alloc = atomic_read(>count) == 0 ? false : true;
> id = __peernet2id_alloc(net, peer, );
> --
> 2.1.0
>

Re: [PATCH net-next v2 3/3] net: marvell: Allow drivers to be built with COMPILE_TEST

[kbuild test robot]

Hi Florian,

[auto build test ERROR on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Florian-Fainelli/net-fsl-Allow-most-drivers-to-be-built-with-COMPILE_TEST/20161116-094841
config: mips-allyesconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `mvneta_bm_pool_create':
>> mvneta_bm.c:(.text+0x772f0c): undefined reference to 
>> `mvebu_mbus_get_dram_win_info'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [v2] cw1200: fix bogus maybe-uninitialized warning

[Kalle Valo]

Arnd Bergmann  wrote:
> On x86, the cw1200 driver produces a rather silly warning about the
> possible use of the 'ret' variable without an initialization
> presumably after being confused by the architecture specific definition
> of WARN_ON:
> 
> drivers/net/wireless/st/cw1200/wsm.c: In function ‘wsm_handle_rx’:
> drivers/net/wireless/st/cw1200/wsm.c:1457:9: error: ‘ret’ may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> 
> We have already checked that 'count' is larger than 0 here, so
> we know that 'ret' is initialized. Changing the 'for' loop
> into do/while also makes this clear to the compiler.
> 
> Suggested-by: David Laight 
> Signed-off-by: Arnd Bergmann 

Patch applied to wireless-drivers-next.git, thanks.

7fc1503c906f cw1200: fix bogus maybe-uninitialized warning

-- 
https://patchwork.kernel.org/patch/9395413/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: wireless: fix bogus maybe-uninitialized warning

[Kalle Valo]

Arnd Bergmann  wrote:
> The hostap_80211_rx() function is supposed to set up the mac addresses
> for four possible cases, based on two bits of input data. For
> some reason, gcc decides that it's possible that none of the these
> four cases apply and the addresses remain uninitialized:
> 
> drivers/net/wireless/intersil/hostap/hostap_80211_rx.c: In function 
> ‘hostap_80211_rx’:
> arch/x86/include/asm/string_32.h:77:14: warning: ‘src’ may be used 
> uninitialized in this function [-Wmaybe-uninitialized]
> drivers/net/wireless/intel/ipw2x00/libipw_rx.c: In function ‘libipw_rx’:
> arch/x86/include/asm/string_32.h:77:14: error: ‘dst’ may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> arch/x86/include/asm/string_32.h:78:22: error: ‘*((void *)+4)’ may be 
> used uninitialized in this function [-Werror=maybe-uninitialized]
> 
> This warning is clearly nonsense, but changing the last case into
> 'default' makes it obvious to the compiler too, which avoids the
> warning and probably leads to better object code too.
> 
> The same code is duplicated several times in the kernel, so this
> patch uses the same workaround for all copies. The exact configuration
> was hit only very rarely in randconfig builds and I only saw it
> in three drivers, but I assume that all of them are potentially
> affected, and it's better to keep the code consistent.
> 
> Signed-off-by: Arnd Bergmann 

Patch applied to wireless-drivers-next.git, thanks.

10f3366b4d89 wireless: fix bogus maybe-uninitialized warning

-- 
https://patchwork.kernel.org/patch/9392385/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: p54: memset(0) whole array

[Kalle Valo]

Jiri Slaby  wrote:
> gcc 7 complains:
> drivers/net/wireless/intersil/p54/fwio.c: In function 'p54_scan':
> drivers/net/wireless/intersil/p54/fwio.c:491:4: warning: 'memset' used with 
> length equal to number of elements without multiplication by element size 
> [-Wmemset-elt-size]
> 
> Fix that by passing the correct size to memset.
> 
> Signed-off-by: Jiri Slaby 
> Cc: Christian Lamparter 
> Cc: Kalle Valo 
> Cc: linux-wirel...@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Acked-by: Christian Lamparter 

Patch applied to wireless-drivers-next.git, thanks.

6f1758178820 p54: memset(0) whole array

-- 
https://patchwork.kernel.org/patch/9376333/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: brcmfmac: print name of connect status event

[Kalle Valo]

Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> This simplifies debugging. Format %s (%u) comes from similar debugging
> message in brcmf_fweh_event_worker.
> 
> Signed-off-by: Rafał Miłecki 

Patch applied to wireless-drivers-next.git, thanks.

e1c122d55f9e brcmfmac: print name of connect status event

-- 
https://patchwork.kernel.org/patch/9376147/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: wlcore: Allow scans when in AP mode

[Kalle Valo]

Xander Huff  wrote:
> From: James Minor 
> 
> When in AP mode, scans can be done without changing firmware to
> the multi-role firmware. Allow the interface to scan if forced
> in the scan request.
> 
> Signed-off-by: James Minor 
> Signed-off-by: Xander Huff 
> Reviewed-by: Ben Shelton 
> Reviewed-by: Jaeden Amero 

Patch applied to wireless-drivers-next.git, thanks.

87016f5eb1a3 wlcore: Allow scans when in AP mode

-- 
https://patchwork.kernel.org/patch/9366467/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [v3] mwifiex: report wakeup for wowlan

[Kalle Valo]

Rajat Jain  wrote:
> Register the WLAN device as a wakeup source since it can
> wake the system via wake-on-wireless-lan. In an actual wowlan
> event, notify the PM core that we are the current wakeup source.
> This allows the PM core to update the wakeup attributes in /sys.
> 
> This was causing wakeup issues on chromeos as the system was
> apparently confused about the wakeup source.
> 
> Signed-off-by: Wei-Ning Huang 
> Signed-off-by: Rajat Jain 
> Tested-by: Wei-Ning Huang 
> Reviewed-by: Eric Caruso 
> Acked-by: Amitkumar Karwar 

Patch applied to wireless-drivers-next.git, thanks.

df566a481ee8 mwifiex: report wakeup for wowlan

-- 
https://patchwork.kernel.org/patch/9362275/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH net v2] net: nsid cannot be allocated for a dead netns

[Cong Wang]

On Wed, Nov 16, 2016 at 8:17 PM, David Miller  wrote:
> From: Cong Wang 
> Date: Wed, 16 Nov 2016 09:29:29 -0800
>
>> On Wed, Nov 16, 2016 at 1:49 AM, Nicolas Dichtel
>>  wrote:
>>> diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
>>> index f61c0e02a413..63f65387f4e1 100644
>>> --- a/net/core/net_namespace.c
>>> +++ b/net/core/net_namespace.c
>>> @@ -159,6 +159,9 @@ static int alloc_netid(struct net *net, struct net 
>>> *peer, int reqid)
>>> max = reqid + 1;
>>> }
>>>
>>> +   if (!atomic_read(>count) || !atomic_read(>count))
>>> +   return -EINVAL;
>>> +
>>> return idr_alloc(>netns_ids, peer, min, max, GFP_ATOMIC);
>>>  }
>>
>>
>> There is already a check in peernet2id_alloc(), so why not just the 
>> following?
>>
>> diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
>> index f61c0e0..7001da9 100644
>> --- a/net/core/net_namespace.c
>> +++ b/net/core/net_namespace.c
>> @@ -219,6 +219,8 @@ int peernet2id_alloc(struct net *net, struct net *peer)
>> bool alloc;
>> int id;
>>
>> +   if (atomic_read(>count) == 0)
>> +   return NETNSA_NSID_NOT_ASSIGNED;
>> spin_lock_irqsave(>nsid_lock, flags);
>> alloc = atomic_read(>count) == 0 ? false : true;
>> id = __peernet2id_alloc(net, peer, );
>
> Indeed, this looks cleaner, Nicolas?

Yeah, I already sent a formal patch:
https://patchwork.ozlabs.org/patch/695747/

since Nicolas' patch doesn't even compile...

Philanthropic Gesture

[Susanne Hanna Ursula Klattent]

Hello

I want to donate a token of my Wealth as part of my Philanthropic Gesture to 
the world . Interested individuals or groups should contact me.

Regards
Susanne Hanna Ursula Klatten
Email: sussanklatte...@gmail.com

Re: [PATCH net] : add a missing rcu synchronization

[Eric Dumazet]

On Wed, 2016-11-16 at 23:31 -0500, David Miller wrote:
> From: Eric Dumazet 
> Date: Wed, 16 Nov 2016 06:31:52 -0800
> 
> > From: Eric Dumazet 
> > 
> > Add a missing synchronize_net() call to avoid potential use after free,
> > since we explicitly call napi_hash_del() to factorize the RCU grace
> > period.
> > 
> > Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")
> > Signed-off-by: Eric Dumazet 
> > Cc: Michael Chan 
> 
> Applied.

Thanks David for the title fix ;)

Re: [PATCH net] : add a missing rcu synchronization

[David Miller]

From: Eric Dumazet 
Date: Wed, 16 Nov 2016 06:31:52 -0800

> From: Eric Dumazet 
> 
> Add a missing synchronize_net() call to avoid potential use after free,
> since we explicitly call napi_hash_del() to factorize the RCU grace
> period.
> 
> Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")
> Signed-off-by: Eric Dumazet 
> Cc: Michael Chan 

Applied.

Re: [patch net-next 0/4] mlxsw: Introduce support for I2C bus

[David Miller]

From: Jiri Pirko 
Date: Wed, 16 Nov 2016 15:20:42 +0100

> Vadim says:
> 
> This patchset adds I2C access support for SwitchX, SwitchX2, SwitchIB,
> SwitchIB2 and Spectrum silicones.

Series applied, thanks.

Re: [PATCH 1/2] net: netcp: replace IS_ERR_OR_NULL by IS_ERR

[David Miller]

From: Julia Lawall 
Date: Wed, 16 Nov 2016 11:43:33 +0100

> knav_queue_open always returns an ERR_PTR value, never NULL.  This can be
> confirmed by unfolding the function calls and conforms to the function's
> documentation.  Thus, replace IS_ERR_OR_NULL by IS_ERR in error checks.
> 
> The change is made using the following semantic patch:
> (http://coccinelle.lip6.fr/)
 ...
> Signed-off-by: Julia Lawall 

Applied to net-next, thanks.

Re: [PATCH net] net: dsa: b53: Fix VLAN usage and how we treat CPU port

[David Miller]

From: Florian Fainelli 
Date: Tue, 15 Nov 2016 15:58:15 -0800

> We currently have a fundamental problem in how we treat the CPU port and
> its VLAN membership. As soon as a second VLAN is configured to be
> untagged, the CPU automatically becomes untagged for that VLAN as well,
> and yet, we don't gracefully make sure that the CPU becomes tagged in
> the other VLANs it could be a member of. This results in only one VLAN
> being effectively usable from the CPU's perspective.
> 
> Instead of having some pretty complex logic which tries to maintain the
> CPU port's default VLAN and its untagged properties, just do something
> very simple which consists in neither altering the CPU port's PVID
> settings, nor its untagged settings:
> 
> - whenever a VLAN is added, the CPU is automatically a member of this
>   VLAN group, as a tagged member
> - PVID settings for downstream ports do not alter the CPU port's PVID
>   since it now is part of all VLANs in the system
> 
> This means that a typical example where e.g: LAN ports are in VLAN1, and
> WAN port is in VLAN2, now require having two VLAN interfaces for the
> host to properly terminate and send traffic from/to.
> 
> Fixes: Fixes: a2482d2ce349 ("net: dsa: b53: Plug in VLAN support")
> Reported-by: Hartmut Knaack 
> Signed-off-by: Florian Fainelli 
> ---
> David,
> 
> Can you queue this for -stable so it makes it into 4.8.4?

Applied and queued up for -stable, thanks.

Re: [PATCH net] sctp: use new rhlist interface on sctp transport rhashtable

[David Miller]

From: Xin Long 
Date: Tue, 15 Nov 2016 23:23:11 +0800

> Now sctp transport rhashtable uses hash(lport, dport, daddr) as the key
> to hash a node to one chain. If in one host thousands of assocs connect
> to one server with the same lport and different laddrs (although it's
> not a normal case), all the transports would be hashed into the same
> chain.
> 
> It may cause to keep returning -EBUSY when inserting a new node, as the
> chain is too long and sctp inserts a transport node in a loop, which
> could even lead to system hangs there.
> 
> The new rhlist interface works for this case that there are many nodes
> with the same key in one chain. It puts them into a list then makes this
> list be as a node of the chain.
> 
> This patch is to replace rhashtable_ interface with rhltable_ interface.
> Since a chain would not be too long and it would not return -EBUSY with
> this fix when inserting a node, the reinsert loop is also removed here.
> 
> Signed-off-by: Xin Long 

Applied to net-next, thanks.

Re: [PATCH net v2] net: nsid cannot be allocated for a dead netns

[David Miller]

From: Cong Wang 
Date: Wed, 16 Nov 2016 09:29:29 -0800

> On Wed, Nov 16, 2016 at 1:49 AM, Nicolas Dichtel
>  wrote:
>> diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
>> index f61c0e02a413..63f65387f4e1 100644
>> --- a/net/core/net_namespace.c
>> +++ b/net/core/net_namespace.c
>> @@ -159,6 +159,9 @@ static int alloc_netid(struct net *net, struct net 
>> *peer, int reqid)
>> max = reqid + 1;
>> }
>>
>> +   if (!atomic_read(>count) || !atomic_read(>count))
>> +   return -EINVAL;
>> +
>> return idr_alloc(>netns_ids, peer, min, max, GFP_ATOMIC);
>>  }
> 
> 
> There is already a check in peernet2id_alloc(), so why not just the following?
> 
> diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
> index f61c0e0..7001da9 100644
> --- a/net/core/net_namespace.c
> +++ b/net/core/net_namespace.c
> @@ -219,6 +219,8 @@ int peernet2id_alloc(struct net *net, struct net *peer)
> bool alloc;
> int id;
> 
> +   if (atomic_read(>count) == 0)
> +   return NETNSA_NSID_NOT_ASSIGNED;
> spin_lock_irqsave(>nsid_lock, flags);
> alloc = atomic_read(>count) == 0 ? false : true;
> id = __peernet2id_alloc(net, peer, );

Indeed, this looks cleaner, Nicolas?

Re: [PATCH net-next 0/4] bnxt_en: Updates.

[David Miller]

From: Michael Chan 
Date: Wed, 16 Nov 2016 21:13:06 -0500

> New firmware spec. update, autoneg update, and UDP RSS support.

Looks good, series applied, thanks Michael.

Re: [PATCHv2 perf/core 2/2] tools lib bpf: Sync with samples/bpf/libbpf

[Joe Stringer]

On 16 November 2016 at 19:39, Wangnan (F)  wrote:
>
>
> On 2016/11/17 10:46, Joe Stringer wrote:
>>
>> On 16 November 2016 at 18:10, Wangnan (F)  wrote:
>>>
>>> I'm also working on improving bpf.c. Please have a look at:
>>>
>>> https://lkml.org/lkml/2016/11/14/1078
>>>
>>> Since bpf.c is simple, I think we can add more functions and fixes
>>> gradually, instead of a full copy.
>>>
>>> See my inline comment below.
>>
>> Ah, I missed this, my apologies. It looks like it will provide much of
>> what I need, I can reassess this patch with your series in mind.
>>
>> One comment though for your patch (I don't have the original thread to
>> respond to unfortunately): The map_pin and map_get functions in your
>> patch series can be used to pin progs too, so maybe there is a better
>> name? You'll see that this patch uses bpf_obj_{pin,get}() - although I
>> wouldn't want those to be confused with the libbpf.c objects so maybe
>> there's a clearer name that could be used.
>>
>> I also have some patches to rework the samples/bpf/* code to use
>> libbpf instead of the sample code that is there, is it worth me
>> submitting that? It will need to wait for your patch to go in, plus a
>> merge with davem's tree.
>>
> I'm happy to see you are trying to replace samples/bpf 's own
> libbpf with tools/lib/bpf. I think you can submit your work
> on libbpf and patches on samples together if they are ready.
> Arnaldo can pick up patches good for him, and you can improve
> other patches based on his newest branch.

I'll look into it.

Re: CPU port VLAN configuration [Was: Re: [PATCH net] net: dsa: b53: Fix VLAN usage and how we treat CPU port]

[Vivien Didelot]

Hi Florian,

Florian Fainelli  writes:

>> We currently have a fundamental problem in how we treat the CPU port and
>> its VLAN membership. As soon as a second VLAN is configured to be
>> untagged, the CPU automatically becomes untagged for that VLAN as well,
>> and yet, we don't gracefully make sure that the CPU becomes tagged in
>> the other VLANs it could be a member of. This results in only one VLAN
>> being effectively usable from the CPU's perspective.
>> 
>> Instead of having some pretty complex logic which tries to maintain the
>> CPU port's default VLAN and its untagged properties, just do something
>> very simple which consists in neither altering the CPU port's PVID
>> settings, nor its untagged settings:
>> 
>> - whenever a VLAN is added, the CPU is automatically a member of this
>>   VLAN group, as a tagged member

mv88e6xxx currently does that.

>> - PVID settings for downstream ports do not alter the CPU port's PVID
>>   since it now is part of all VLANs in the system

If I'm not mistaken, the CPU port's PVID defaults to 0, since no other
value really makes sense...

>> This means that a typical example where e.g: LAN ports are in VLAN1, and
>> WAN port is in VLAN2, now require having two VLAN interfaces for the
>> host to properly terminate and send traffic from/to.
>
> Do you know how mv88e6xxx deals with this case? In the use case
> mentioned, what we have is this:
>
> - Ports0-3 -> VLAN1 (LAN segment)
> - Port4 -> WAN (WAN segment)
>
> With OpenWrt/swconfig you would typically have eth0.1 and eth0.2
> interfaces that would take care of terminating VLAN tags, this is the
> behavior that I am bringing back here because it is the only way you can
> have the downstream ports configured as untagged, and yet have proper
> segregation appear from the CPU port's perspective (unless you use
> Marvell/Broadcom/QCA tags, which we don't do yet here, but still).
>
> A more general issue that I am still working on is having the ability to
> control the CPU port's VLAN properties by configuring the master bridge
> device, since it is inherently "a view" (if multiple bridges, multiple
> views) of the CPU port of an Ethernet switch. The general idea would be
> that if you do:
>
> bridge vlan add vid 2 dev br0 self
>
> this calls down into the switch driver to actually configure VLAN ID 2
> on the CPU port to be tagged.

This is the good approach IMO.

As a side note, a good first thing to do here would be to fix the actual
behavior of switchdev calls from iproute2 commands. It doesn't respect
what the bridge's manpage describes in the VLAN section:

   self   the vlan is configured on the specified physical device.
  Required if the device is the bridge device.

   master the vlan is configured on the software bridge (default).

If I'm not mistaken, "bridge vlan add vid 2 dev lan2 [master]" currently
programs the hardware.

> I have a prototype of this that nearly works [1], except upon the
> initial bridge master device creation, since we have not had the ability
> to enslave port members yet, we are not able to propagate the bridge's
> default VLAN to the CPU port. More to come in the next weeks!

For this case, maybe the way to go would be to let DSA query the bridge
VLAN membership when enslaving a port and configure the CPU port
accordingly if needed.

Thanks,

Vivien

Re: [PATCHv2 perf/core 2/2] tools lib bpf: Sync with samples/bpf/libbpf

[Wangnan (F)]

On 2016/11/17 10:46, Joe Stringer wrote:

On 16 November 2016 at 18:10, Wangnan (F)  wrote:

I'm also working on improving bpf.c. Please have a look at:

https://lkml.org/lkml/2016/11/14/1078

Since bpf.c is simple, I think we can add more functions and fixes
gradually, instead of a full copy.

See my inline comment below.

Ah, I missed this, my apologies. It looks like it will provide much of
what I need, I can reassess this patch with your series in mind.

One comment though for your patch (I don't have the original thread to
respond to unfortunately): The map_pin and map_get functions in your
patch series can be used to pin progs too, so maybe there is a better
name? You'll see that this patch uses bpf_obj_{pin,get}() - although I
wouldn't want those to be confused with the libbpf.c objects so maybe
there's a clearer name that could be used.

I also have some patches to rework the samples/bpf/* code to use
libbpf instead of the sample code that is there, is it worth me
submitting that? It will need to wait for your patch to go in, plus a
merge with davem's tree.


I'm happy to see you are trying to replace samples/bpf 's own
libbpf with tools/lib/bpf. I think you can submit your work
on libbpf and patches on samples together if they are ready.
Arnaldo can pick up patches good for him, and you can improve
other patches based on his newest branch.

Thank you.

Re: [PATCHv2 perf/core 2/2] tools lib bpf: Sync with samples/bpf/libbpf

[Joe Stringer]

On 16 November 2016 at 19:21, Wangnan (F)  wrote:
>
>
> On 2016/11/17 10:46, Joe Stringer wrote:
>>
>> On 16 November 2016 at 18:10, Wangnan (F)  wrote:
>>>
>>> I'm also working on improving bpf.c. Please have a look at:
>>>
>>> https://lkml.org/lkml/2016/11/14/1078
>>>
>>> Since bpf.c is simple, I think we can add more functions and fixes
>>> gradually, instead of a full copy.
>>>
>>> See my inline comment below.
>>
>> Ah, I missed this, my apologies. It looks like it will provide much of
>> what I need, I can reassess this patch with your series in mind.
>>
>> One comment though for your patch (I don't have the original thread to
>> respond to unfortunately): The map_pin and map_get functions in your
>> patch series can be used to pin progs too, so maybe there is a better
>> name? You'll see that this patch uses bpf_obj_{pin,get}() - although I
>> wouldn't want those to be confused with the libbpf.c objects so maybe
>> there's a clearer name that could be used.
>
>
> The full thread can be found:
>
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1272045.html
>
> (lkml.kernel.org is not working for me, sorry)
>
> In that patch set, bpf_map_pin/get is linked into perf hooks, so BPF script
> can pin a map to sysfs. I think this feature would be useful, but I don't
> have an example to show how to use it. I didn't provide program pinning/get
> interface because in perf hook they are not useful. After rethinking your
> suggestion now I think it is okay to provide bpf_obj_{pin,get} in bpf.c
> and export bpf_map_pin to perf hook. I'll adjust my own patch.

OK. For what it's worth, I also have a slightly higher level user of
this interface with a patch series for libbpf.[ch] that allows to you
pin a bpf_object * to the filesystem; The idea is that you pass it a
subpath, then it will make sure the BPF FS is mounted, then put your
programs and maps under, for example,
/sys/fs/bpf/$subpath/{maps,progs}/foo (where 'foo' is a symbol name
from your eBPF ELF). I also plan to post this soon, but it depends on
bpf_obj_pin() so will need your patch to go in first. I will submit it
when I can.

/*
 @@ -53,24 +60,71 @@ static int sys_bpf(enum bpf_cmd cmd, union bpf_attr
 *attr,
  return syscall(__NR_bpf, cmd, attr, size);
}
-int bpf_create_map(enum bpf_map_type map_type, int key_size,
 -  int value_size, int max_entries)
 +int bpf_create_map(enum bpf_map_type map_type, int key_size, int
 value_size,
 +  int max_entries, int map_flags)
{
 -   union bpf_attr attr;
 +   union bpf_attr attr = {
 +   .map_type = map_type,
 +   .key_size = key_size,
 +   .value_size = value_size,
 +   .max_entries = max_entries,
 +   .map_flags = map_flags,
 +   };
- memset(, '\0', sizeof(attr));
 +   return sys_bpf(BPF_MAP_CREATE, , sizeof(attr));
 +}

>>>
>>> I lost map_flags in original bpf.c. Thanks to your patch. map_flags is
>>> useful
>>> when creating BPF_MAP_TYPE_PERCPU_HASH: BPF_F_NO_PREALLOC is meanful in
>>> this
>>> case.
>>
>> Do you want me to resubmit this piece as a separate patch or will you
>> address this?
>
>
> Please send it.

OK.

RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

[Hayes Wang]

[...]
> Fix the hw rx checksum is always enabled, and the user couldn't switch
> it to sw rx checksum.
> 
> Note that the RTL_VER_01 only supports sw rx checksum only. Besides,
> the hw rx checksum for RTL_VER_02 is disabled after
> commit b9a321b48af4 ("r8152: Fix broken RX checksums."). Re-enable it.

Excuse me. If I want to re-send this one patch, should I let
RTL_VER_02 use rx hw checksum?

Best Regards,
Hayes

Re: [PATCH] net: dsa: mv88e6xxx: Respect SPEED_UNFORCED, don't set force bit

[Vivien Didelot]

Hi Andrew,

Andrew Lunn  writes:

> The SPEED_UNFORCED indicates the MAC & PHY should perform
> auto-negotiation to determine a speed which works. If this is called
> for, don't set the force bit. If it is set, the MAC actually does
> 10Gbps, why the internal PHYs don't support.
>
> Signed-off-by: Andrew Lunn 

Fixes: 96a2b40c7bd3 ("net: dsa: mv88e6xxx: add port's MAC speed setter")

Reviewed-by: Vivien Didelot 

David, this is for net-next.

Thanks!

Vivien

linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi all,

After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

net/core/dev.c: In function 'sk_busy_loop':
net/core/dev.c:5065:3: error: implicit declaration of function 
'cpu_relax_lowlatency' [-Werror=implicit-function-declaration]
   cpu_relax_lowlatency();
   ^

Caused by commit

  5bd0b85ba8bb ("locking/core, arch: Remove cpu_relax_lowlatency()")

interacting with commit

  217f69743681 ("net: busy-poll: allow preemption in sk_busy_loop()")

from the net-next tree.

I have applied the following merge fix patch.

From: Stephen Rothwell 
Date: Thu, 17 Nov 2016 14:13:05 +1100
Subject: [PATCH] net: busy-poll: fix up for cpu_relax_lowlatency() removal

Signed-off-by: Stephen Rothwell 
---
 net/core/dev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index d29d538ec5ad..6b9f8eb55b62 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5062,7 +5062,7 @@ bool sk_busy_loop(struct sock *sk, int nonblock)
return rc;
goto restart;
}
-   cpu_relax_lowlatency();
+   cpu_relax();
}
if (napi_poll)
busy_poll_stop(napi, have_poll_lock);
-- 
2.10.2

-- 
Cheers,
Stephen Rothwell

Re: [PATCHv2 perf/core 2/2] tools lib bpf: Sync with samples/bpf/libbpf

[Wangnan (F)]

On 2016/11/17 10:46, Joe Stringer wrote:

On 16 November 2016 at 18:10, Wangnan (F)  wrote:

I'm also working on improving bpf.c. Please have a look at:

https://lkml.org/lkml/2016/11/14/1078

Since bpf.c is simple, I think we can add more functions and fixes
gradually, instead of a full copy.

See my inline comment below.

Ah, I missed this, my apologies. It looks like it will provide much of
what I need, I can reassess this patch with your series in mind.

One comment though for your patch (I don't have the original thread to
respond to unfortunately): The map_pin and map_get functions in your
patch series can be used to pin progs too, so maybe there is a better
name? You'll see that this patch uses bpf_obj_{pin,get}() - although I
wouldn't want those to be confused with the libbpf.c objects so maybe
there's a clearer name that could be used.


The full thread can be found:

https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1272045.html

(lkml.kernel.org is not working for me, sorry)

In that patch set, bpf_map_pin/get is linked into perf hooks, so BPF script
can pin a map to sysfs. I think this feature would be useful, but I don't
have an example to show how to use it. I didn't provide program pinning/get
interface because in perf hook they are not useful. After rethinking your
suggestion now I think it is okay to provide bpf_obj_{pin,get} in bpf.c
and export bpf_map_pin to perf hook. I'll adjust my own patch.


I also have some patches to rework the samples/bpf/* code to use
libbpf instead of the sample code that is there, is it worth me
submitting that? It will need to wait for your patch to go in, plus a
merge with davem's tree.


On 2016/11/17 1:43, Joe Stringer wrote:


[SNIP]


   /*
@@ -53,24 +60,71 @@ static int sys_bpf(enum bpf_cmd cmd, union bpf_attr
*attr,
 return syscall(__NR_bpf, cmd, attr, size);
   }
   -int bpf_create_map(enum bpf_map_type map_type, int key_size,
-  int value_size, int max_entries)
+int bpf_create_map(enum bpf_map_type map_type, int key_size, int
value_size,
+  int max_entries, int map_flags)
   {
-   union bpf_attr attr;
+   union bpf_attr attr = {
+   .map_type = map_type,
+   .key_size = key_size,
+   .value_size = value_size,
+   .max_entries = max_entries,
+   .map_flags = map_flags,
+   };
   - memset(, '\0', sizeof(attr));
+   return sys_bpf(BPF_MAP_CREATE, , sizeof(attr));
+}



I lost map_flags in original bpf.c. Thanks to your patch. map_flags is
useful
when creating BPF_MAP_TYPE_PERCPU_HASH: BPF_F_NO_PREALLOC is meanful in this
case.

Do you want me to resubmit this piece as a separate patch or will you
address this?


Please send it.

Thank you.

RE: [PATCH net 2/2] r8152: rx descriptor check

[Hayes Wang]

Francois Romieu [mailto:rom...@fr.zoreil.com]
> Sent: Tuesday, November 15, 2016 9:11 AM
[...]
> If it was possible to get it wrong once, it should be possible to
> get it wrong twice, especially if some part of the hardware design
> is recycled. I don't mean anything else.

I agree with you. However, I have to let it could be reproduced
for confirming it.

Besides, the behavior is different for PCIe and USB device. There
is no action of DMA for USB device. It is done by the USB host
controller. And, the USB host controller wouldn't allow the device
sends a data which is more than the size of the buffer.

Best Regards,
Hayes

linux-next: manual merge of the tip tree with the net-next tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  drivers/net/ethernet/amd/Kconfig

between commits:

  e78332b2285d ("amd-xgbe: Add ECC status support for the device memory")
  abf0a1c2b26a ("amd-xgbe: Add support for SFP+ modules")

from the net-next tree and commit:

  d1cbfd771ce8 ("ptp_clock: Allow for it to be optional")

from the tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/ethernet/amd/Kconfig
index 7ab6efbe4189,713ea7ad22c3..
--- a/drivers/net/ethernet/amd/Kconfig
+++ b/drivers/net/ethernet/amd/Kconfig
@@@ -173,13 -173,11 +173,13 @@@ config SUNLANC
  
  config AMD_XGBE
tristate "AMD 10GbE Ethernet driver"
 -  depends on ((OF_NET && OF_ADDRESS) || ACPI) && HAS_IOMEM && HAS_DMA
 -  depends on ARM64 || COMPILE_TEST
 +  depends on ((OF_NET && OF_ADDRESS) || ACPI || PCI) && HAS_IOMEM && 
HAS_DMA
 +  depends on X86 || ARM64 || COMPILE_TEST
select BITREVERSE
select CRC32
-   select PTP_1588_CLOCK
 +  select PHYLIB
 +  select AMD_XGBE_HAVE_ECC if X86
+   imply PTP_1588_CLOCK
---help---
  This driver supports the AMD 10GbE Ethernet device found on an
  AMD SoC.

Re: [PATCHv2 perf/core 2/2] tools lib bpf: Sync with samples/bpf/libbpf

[Joe Stringer]

On 16 November 2016 at 18:10, Wangnan (F)  wrote:
> I'm also working on improving bpf.c. Please have a look at:
>
> https://lkml.org/lkml/2016/11/14/1078
>
> Since bpf.c is simple, I think we can add more functions and fixes
> gradually, instead of a full copy.
>
> See my inline comment below.

Ah, I missed this, my apologies. It looks like it will provide much of
what I need, I can reassess this patch with your series in mind.

One comment though for your patch (I don't have the original thread to
respond to unfortunately): The map_pin and map_get functions in your
patch series can be used to pin progs too, so maybe there is a better
name? You'll see that this patch uses bpf_obj_{pin,get}() - although I
wouldn't want those to be confused with the libbpf.c objects so maybe
there's a clearer name that could be used.

I also have some patches to rework the samples/bpf/* code to use
libbpf instead of the sample code that is there, is it worth me
submitting that? It will need to wait for your patch to go in, plus a
merge with davem's tree.

>
> On 2016/11/17 1:43, Joe Stringer wrote:
>>
>> Extend the tools/ version of libbpf to include all of the functionality
>> provided in the samples/bpf version.
>>
>> Signed-off-by: Joe Stringer 
>> ---
>> v2: Don't shift non-bpf changes across.
>>  Various type cleanups, removal of extraneous declarations
>> ---
>>   tools/lib/bpf/bpf.c| 107 --
>>   tools/lib/bpf/bpf.h| 202
>> +++--
>>   tools/lib/bpf/libbpf.c |   3 +-
>>   3 files changed, 279 insertions(+), 33 deletions(-)
>>
>> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
>> index 4212ed62235b..5e061851ac00 100644
>> --- a/tools/lib/bpf/bpf.c
>> +++ b/tools/lib/bpf/bpf.c
>> @@ -20,10 +20,17 @@
>>*/
>> #include 
>> -#include 
>> +#include 
>>   #include 
>>   #include 
>> +#include 
>> +#include 
>>   #include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>>   #include "bpf.h"
>>
>
>
> Why we need these network related headers?

I started with a copy/paste, assuming that the headers were all in use
but I guess that assumption was wrong.

>>   /*
>> @@ -53,24 +60,71 @@ static int sys_bpf(enum bpf_cmd cmd, union bpf_attr
>> *attr,
>> return syscall(__NR_bpf, cmd, attr, size);
>>   }
>>   -int bpf_create_map(enum bpf_map_type map_type, int key_size,
>> -  int value_size, int max_entries)
>> +int bpf_create_map(enum bpf_map_type map_type, int key_size, int
>> value_size,
>> +  int max_entries, int map_flags)
>>   {
>> -   union bpf_attr attr;
>> +   union bpf_attr attr = {
>> +   .map_type = map_type,
>> +   .key_size = key_size,
>> +   .value_size = value_size,
>> +   .max_entries = max_entries,
>> +   .map_flags = map_flags,
>> +   };
>>   - memset(, '\0', sizeof(attr));
>> +   return sys_bpf(BPF_MAP_CREATE, , sizeof(attr));
>> +}
>>
>
>
> I lost map_flags in original bpf.c. Thanks to your patch. map_flags is
> useful
> when creating BPF_MAP_TYPE_PERCPU_HASH: BPF_F_NO_PREALLOC is meanful in this
> case.

Do you want me to resubmit this piece as a separate patch or will you
address this?

> Although it is okay in samples, I still prefer a explicit bzero() or
> memset(),
> because kernel checks if unused field in this union is zero. However I'll
> check
> c standard to see how unused field would be initialized.

OK.

>> diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
>> index e8ba54087497..4dba36995771 100644
>> --- a/tools/lib/bpf/bpf.h
>> +++ b/tools/lib/bpf/bpf.h
>> @@ -23,16 +23,202 @@
>> #include 
>>   +struct bpf_insn;
>> +
>>   int bpf_create_map(enum bpf_map_type map_type, int key_size, int
>> value_size,
>> -  int max_entries);
>> +  int max_entries, int map_flags);
>> +int bpf_update_elem(int fd, void *key, void *value, unsigned long long
>> flags);
>> +int bpf_lookup_elem(int fd, void *key, void *value);
>> +int bpf_delete_elem(int fd, void *key);
>> +int bpf_get_next_key(int fd, void *key, void *next_key);
>> +
>> +int bpf_load_program(enum bpf_prog_type prog_type,
>> +const struct bpf_insn *insns, int insn_len,
>> +const char *license, int kern_version,
>> +char *log_buf, size_t log_buf_sz);
>> +
>> +int bpf_obj_pin(int fd, const char *pathname);
>> +int bpf_obj_get(const char *pathname);
>>   -/* Recommend log buffer size */
>>   #define BPF_LOG_BUF_SIZE 65536
>> -int bpf_load_program(enum bpf_prog_type type, struct bpf_insn *insns,
>> -size_t insns_cnt, char *license,
>> -u32 kern_version, char *log_buf,
>> -size_t log_buf_sz);
>>   -int bpf_map_update_elem(int fd, void *key, void *value,
>> -   u64 flags);
>> +/* ALU ops on registers, bpf_add|sub|...: 

Re: [PATCH] net: ethernet: faraday: To support device tree usage.

[Greentime Hu]

On Thu, Nov 17, 2016 at 12:12 AM, Arnd Bergmann  wrote:
> On Wednesday, November 16, 2016 3:37:15 PM CET Andrew Lunn wrote:
>> On Wed, Nov 16, 2016 at 10:26:52PM +0800, Greentime Hu wrote:
>> > On Wed, Nov 16, 2016 at 9:47 PM, Andrew Lunn  wrote:
>> > > On Wed, Nov 16, 2016 at 04:43:15PM +0800, Greentime Hu wrote:
>> > >> To support device tree usage for ftmac100.
>> > >>
>> > >> Signed-off-by: Greentime Hu 
>> > >> ---
>> > >>  drivers/net/ethernet/faraday/ftmac100.c |7 +++
>> > >>  1 file changed, 7 insertions(+)
>> > >>
>> > >> diff --git a/drivers/net/ethernet/faraday/ftmac100.c 
>> > >> b/drivers/net/ethernet/faraday/ftmac100.c
>> > >> index dce5f7b..81dd9e1 100644
>> > >> --- a/drivers/net/ethernet/faraday/ftmac100.c
>> > >> +++ b/drivers/net/ethernet/faraday/ftmac100.c
>> > >> @@ -1172,11 +1172,17 @@ static int __exit ftmac100_remove(struct 
>> > >> platform_device *pdev)
>> > >>   return 0;
>> > >>  }
>> > >>
>> > >> +static const struct of_device_id mac_of_ids[] = {
>> > >> + { .compatible = "andestech,atmac100" },
>> > >> + { }
>> > >
>> > > andestech is not in
>> > > Documentation/devicetree/bindings/vendor-prefixes.txt Please provide a
>> > > separate patch adding it.
>> > OK. I will provide another patch to add andestech.
>> >
>> > > Humm, why andestech? Why not something based around faraday
>> > > technology?
>> > It is because we use the same ftmac100 IP provided from faraday
>> > technology but I am now using it in andestech SoC.
>>
>> Please make sure you get an acked-by: from the device tree
>> maintainers. They might want you to use faraday, since that is the
>> original IP provider. For example, all Synopsys licensed IP uses
>> "snps,XXX", not the SoC vendor with the license.
>
> I think ideally we have both the ID from andes and from faraday here.
>
> Note that we already have "moxa,moxart-mac" as a compatible string
> for this hardware, though it uses a different driver.
>
> We should probably have a single binding document describing
> both compatible strings and any optional properties.
>
> Arnd

I am agree with that.
Andes got this ftmac100 ip from faraday and we refined it.
We rename it to atmac100 to provide to our customer.
These 2 mac100 are using different hardware RTL code but they are
software compatible.

Most of the IPs in Andes SoC are named as atXXX in its dts.
I suggest using this string "andestech,atmac100".

Re: [PATCH net-next v2 3/3] net: marvell: Allow drivers to be built with COMPILE_TEST

[kbuild test robot]

Hi Florian,

[auto build test ERROR on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Florian-Fainelli/net-fsl-Allow-most-drivers-to-be-built-with-COMPILE_TEST/20161116-094841
config: m32r-allmodconfig (attached as .config)
compiler: m32r-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m32r 

All errors (new ones prefixed by >>):

   ERROR: "bad_dma_ops" [sound/core/snd-pcm.ko] undefined!
   ERROR: "dma_common_mmap" [sound/core/snd-pcm.ko] undefined!
>> ERROR: "bad_dma_ops" [drivers/net/ethernet/marvell/mvpp2.ko] undefined!
   ERROR: "mvebu_mbus_get_dram_win_info" 
[drivers/net/ethernet/marvell/mvneta_bm.ko] undefined!
>> ERROR: "bad_dma_ops" [drivers/net/ethernet/marvell/mvneta_bm.ko] undefined!
>> ERROR: "bad_dma_ops" [drivers/net/ethernet/marvell/mvneta.ko] undefined!
>> ERROR: "bad_dma_ops" [drivers/net/ethernet/marvell/mv643xx_eth.ko] undefined!
   ERROR: "bad_dma_ops" [drivers/net/ethernet/freescale/gianfar_driver.ko] 
undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH net-next] af_packet: Use virtio_net_hdr_to_skb().

[Jarno Rajahalme]

Use the common virtio_net_hdr_to_skb() instead of open coding it.
Other call sites were changed by commit fd2a0437dc, but this one was
missed, maybe because it is split in two parts of the source code.

Also fix other call sites to be more uniform.

Fixes: fd2a0437dc ("virtio_net: introduce virtio_net_hdr_{from,to}_skb")
Signed-off-by: Jarno Rajahalme 
---
 drivers/net/macvtap.c  |  5 ++---
 drivers/net/tun.c  | 12 
 include/linux/virtio_net.h |  2 +-
 net/packet/af_packet.c | 44 +---
 4 files changed, 8 insertions(+), 55 deletions(-)

diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 070e329..5da9861 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -821,9 +821,8 @@ static ssize_t macvtap_put_user(struct macvtap_queue *q,
if (iov_iter_count(iter) < vnet_hdr_len)
return -EINVAL;
 
-   ret = virtio_net_hdr_from_skb(skb, _hdr,
- macvtap_is_little_endian(q));
-   if (ret)
+   if (virtio_net_hdr_from_skb(skb, _hdr,
+   macvtap_is_little_endian(q)))
BUG();
 
if (copy_to_iter(_hdr, sizeof(vnet_hdr), iter) !=
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 9328568..864aae3 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1252,8 +1252,7 @@ static ssize_t tun_get_user(struct tun_struct *tun, 
struct tun_file *tfile,
return -EFAULT;
}
 
-   err = virtio_net_hdr_to_skb(skb, , tun_is_little_endian(tun));
-   if (err) {
+   if (virtio_net_hdr_to_skb(skb, , tun_is_little_endian(tun))) {
this_cpu_inc(tun->pcpu_stats->rx_frame_errors);
kfree_skb(skb);
return -EINVAL;
@@ -1361,15 +1360,12 @@ static ssize_t tun_put_user(struct tun_struct *tun,
}
 
if (vnet_hdr_sz) {
-   struct virtio_net_hdr gso = { 0 }; /* no info leak */
-   int ret;
-
+   struct virtio_net_hdr gso;
if (iov_iter_count(iter) < vnet_hdr_sz)
return -EINVAL;
 
-   ret = virtio_net_hdr_from_skb(skb, ,
- tun_is_little_endian(tun));
-   if (ret) {
+   if (virtio_net_hdr_from_skb(skb, ,
+   tun_is_little_endian(tun))) {
struct skb_shared_info *sinfo = skb_shinfo(skb);
pr_err("unexpected GSO type: "
   "0x%x, gso_size %d, hdr_len %d\n",
diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
index 1c912f8..74f1e33 100644
--- a/include/linux/virtio_net.h
+++ b/include/linux/virtio_net.h
@@ -98,4 +98,4 @@ static inline int virtio_net_hdr_from_skb(const struct 
sk_buff *skb,
return 0;
 }
 
-#endif /* _LINUX_VIRTIO_BYTEORDER */
+#endif /* _LINUX_VIRTIO_NET_H */
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 11db0d6..09abb88 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1971,8 +1971,6 @@ static unsigned int run_filter(struct sk_buff *skb,
 static int __packet_rcv_vnet(const struct sk_buff *skb,
 struct virtio_net_hdr *vnet_hdr)
 {
-   *vnet_hdr = (const struct virtio_net_hdr) { 0 };
-
if (virtio_net_hdr_from_skb(skb, vnet_hdr, vio_le()))
BUG();
 
@@ -2391,8 +2389,6 @@ static void tpacket_set_protocol(const struct net_device 
*dev,
 
 static int __packet_snd_vnet_parse(struct virtio_net_hdr *vnet_hdr, size_t len)
 {
-   unsigned short gso_type = 0;
-
if ((vnet_hdr->flags & VIRTIO_NET_HDR_F_NEEDS_CSUM) &&
(__virtio16_to_cpu(vio_le(), vnet_hdr->csum_start) +
 __virtio16_to_cpu(vio_le(), vnet_hdr->csum_offset) + 2 >
@@ -2404,29 +2400,6 @@ static int __packet_snd_vnet_parse(struct virtio_net_hdr 
*vnet_hdr, size_t len)
if (__virtio16_to_cpu(vio_le(), vnet_hdr->hdr_len) > len)
return -EINVAL;
 
-   if (vnet_hdr->gso_type != VIRTIO_NET_HDR_GSO_NONE) {
-   switch (vnet_hdr->gso_type & ~VIRTIO_NET_HDR_GSO_ECN) {
-   case VIRTIO_NET_HDR_GSO_TCPV4:
-   gso_type = SKB_GSO_TCPV4;
-   break;
-   case VIRTIO_NET_HDR_GSO_TCPV6:
-   gso_type = SKB_GSO_TCPV6;
-   break;
-   case VIRTIO_NET_HDR_GSO_UDP:
-   gso_type = SKB_GSO_UDP;
-   break;
-   default:
-   return -EINVAL;
-   }
-
-   if (vnet_hdr->gso_type & VIRTIO_NET_HDR_GSO_ECN)
-   gso_type |= SKB_GSO_TCP_ECN;
-
-   if (vnet_hdr->gso_size == 0)
-   return -EINVAL;
-   }
-
-   

[PATCH net-next 1/4] bnxt_en: Update firmware interface spec to 1.5.4.

[Michael Chan]

Use the new FORCE_LINK_DWN bit to shutdown link during close.

Signed-off-by: Michael Chan 
---
 drivers/net/ethernet/broadcom/bnxt/bnxt.c |  8 ++-
 drivers/net/ethernet/broadcom/bnxt/bnxt_hsi.h | 91 +--
 2 files changed, 94 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c 
b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 27a2dd9..1332577 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -5346,7 +5346,7 @@ static int bnxt_hwrm_shutdown_link(struct bnxt *bp)
return 0;
 
bnxt_hwrm_cmd_hdr_init(bp, , HWRM_PORT_PHY_CFG, -1, -1);
-   req.flags = cpu_to_le32(PORT_PHY_CFG_REQ_FLAGS_FORCE_LINK_DOWN);
+   req.flags = cpu_to_le32(PORT_PHY_CFG_REQ_FLAGS_FORCE_LINK_DWN);
return hwrm_send_message(bp, , sizeof(req), HWRM_CMD_TIMEOUT);
 }
 
@@ -5409,6 +5409,12 @@ static int bnxt_update_phy_setting(struct bnxt *bp)
update_link = true;
}
 
+   /* The last close may have shutdown the link, so need to call
+* PHY_CFG to bring it back up.
+*/
+   if (!netif_carrier_ok(bp->dev))
+   update_link = true;
+
if (!bnxt_eee_config_ok(bp))
update_eee = true;
 
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_hsi.h 
b/drivers/net/ethernet/broadcom/bnxt/bnxt_hsi.h
index 04a96cc..0456d5b 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_hsi.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_hsi.h
@@ -215,6 +215,9 @@ struct hwrm_async_event_cmpl_dcb_config_change {
__le16 event_id;
#define 
HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_EVENT_ID_DCB_CONFIG_CHANGE 0x3UL
__le32 event_data2;
+   #define HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_EVENT_DATA2_ETS 0x1UL
+   #define HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_EVENT_DATA2_PFC 0x2UL
+   #define HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_EVENT_DATA2_APP 0x4UL
u8 opaque_v;
#define HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_V   0x1UL
#define HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_OPAQUE_MASK 0xfeUL
@@ -224,6 +227,14 @@ struct hwrm_async_event_cmpl_dcb_config_change {
__le32 event_data1;
#define 
HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_EVENT_DATA1_PORT_ID_MASK 0xUL
#define HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_EVENT_DATA1_PORT_ID_SFT 0
+   #define 
HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_EVENT_DATA1_RECOMMEND_ROCE_PRIORITY_MASK
 0xffUL
+   #define 
HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_EVENT_DATA1_RECOMMEND_ROCE_PRIORITY_SFT 
16
+   #define 
HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_EVENT_DATA1_RECOMMEND_ROCE_PRIORITY_NONE
 (0xffUL << 16)
+   #define 
HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_EVENT_DATA1_RECOMMEND_ROCE_PRIORITY_LAST

HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_EVENT_DATA1_RECOMMEND_ROCE_PRIORITY_NONE
+   #define 
HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_EVENT_DATA1_RECOMMEND_L2_PRIORITY_MASK 
0xff00UL
+   #define 
HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_EVENT_DATA1_RECOMMEND_L2_PRIORITY_SFT 24
+   #define 
HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_EVENT_DATA1_RECOMMEND_L2_PRIORITY_NONE 
(0xffUL << 24)
+   #define 
HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_EVENT_DATA1_RECOMMEND_L2_PRIORITY_LAST  
  HWRM_ASYNC_EVENT_CMPL_DCB_CONFIG_CHANGE_EVENT_DATA1_RECOMMEND_L2_PRIORITY_NONE
 };
 
 /* HWRM Asynchronous Event Completion Record for port connection not allowed 
(16 bytes) */
@@ -485,12 +496,12 @@ struct hwrm_async_event_cmpl_hwrm_error {
#define HWRM_ASYNC_EVENT_CMPL_HWRM_ERROR_EVENT_DATA1_TIMESTAMP 0x1UL
 };
 
-/* HW Resource Manager Specification 1.5.1 */
+/* HW Resource Manager Specification 1.5.4 */
 #define HWRM_VERSION_MAJOR 1
 #define HWRM_VERSION_MINOR 5
-#define HWRM_VERSION_UPDATE1
+#define HWRM_VERSION_UPDATE4
 
-#define HWRM_VERSION_STR   "1.5.1"
+#define HWRM_VERSION_STR   "1.5.4"
 /*
  * Following is the signature for HWRM message field that indicates not
  * applicable (All F's). Need to cast it the size of the field if needed.
@@ -612,6 +623,9 @@ struct cmd_nums {
#define HWRM_FW_QSTATUS(0xc1UL)
#define HWRM_FW_SET_TIME   (0xc8UL)
#define HWRM_FW_GET_TIME   (0xc9UL)
+   #define HWRM_FW_SET_STRUCTURED_DATA(0xcaUL)
+   #define HWRM_FW_GET_STRUCTURED_DATA(0xcbUL)
+   #define HWRM_FW_IPC_MAILBOX(0xccUL)
#define HWRM_EXEC_FWD_RESP (0xd0UL)
#define HWRM_REJECT_FWD_RESP   (0xd1UL)
#define HWRM_FWD_RESP  (0xd2UL)
@@ -626,6 +640,8 @@ struct cmd_nums {
#define HWRM_DBG_WRITE_DIRECT  

[PATCH net-next 0/4] bnxt_en: Updates.

[Michael Chan]

New firmware spec. update, autoneg update, and UDP RSS support.

Michael Chan (4):
  bnxt_en: Update firmware interface spec to 1.5.4.
  bnxt_en: Enhance autoneg support.
  bnxt_en: Add UDP RSS support for 57X1X chips.
  bnxt_en: Add ethtool -n|-N rx-flow-hash support.

 drivers/net/ethernet/broadcom/bnxt/bnxt.c |  52 +--
 drivers/net/ethernet/broadcom/bnxt/bnxt.h |   4 +-
 drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 167 +-
 drivers/net/ethernet/broadcom/bnxt/bnxt_hsi.h |  91 +++-
 4 files changed, 298 insertions(+), 16 deletions(-)

-- 
1.8.3.1

[PATCH net-next 4/4] bnxt_en: Add ethtool -n|-N rx-flow-hash support.

[Michael Chan]

To display and modify the RSS hash.

Signed-off-by: Michael Chan 
---
 drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 167 +-
 1 file changed, 164 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c 
b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
index a7e04ff..fa6125e 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
@@ -542,6 +542,146 @@ static int bnxt_grxclsrule(struct bnxt *bp, struct 
ethtool_rxnfc *cmd)
 
return rc;
 }
+#endif
+
+static u64 get_ethtool_ipv4_rss(struct bnxt *bp)
+{
+   if (bp->rss_hash_cfg & VNIC_RSS_CFG_REQ_HASH_TYPE_IPV4)
+   return RXH_IP_SRC | RXH_IP_DST;
+   return 0;
+}
+
+static u64 get_ethtool_ipv6_rss(struct bnxt *bp)
+{
+   if (bp->rss_hash_cfg & VNIC_RSS_CFG_REQ_HASH_TYPE_IPV6)
+   return RXH_IP_SRC | RXH_IP_DST;
+   return 0;
+}
+
+static int bnxt_grxfh(struct bnxt *bp, struct ethtool_rxnfc *cmd)
+{
+   cmd->data = 0;
+   switch (cmd->flow_type) {
+   case TCP_V4_FLOW:
+   if (bp->rss_hash_cfg & VNIC_RSS_CFG_REQ_HASH_TYPE_TCP_IPV4)
+   cmd->data |= RXH_IP_SRC | RXH_IP_DST |
+RXH_L4_B_0_1 | RXH_L4_B_2_3;
+   cmd->data |= get_ethtool_ipv4_rss(bp);
+   break;
+   case UDP_V4_FLOW:
+   if (bp->rss_hash_cfg & VNIC_RSS_CFG_REQ_HASH_TYPE_UDP_IPV4)
+   cmd->data |= RXH_IP_SRC | RXH_IP_DST |
+RXH_L4_B_0_1 | RXH_L4_B_2_3;
+   /* fall through */
+   case SCTP_V4_FLOW:
+   case AH_ESP_V4_FLOW:
+   case AH_V4_FLOW:
+   case ESP_V4_FLOW:
+   case IPV4_FLOW:
+   cmd->data |= get_ethtool_ipv4_rss(bp);
+   break;
+
+   case TCP_V6_FLOW:
+   if (bp->rss_hash_cfg & VNIC_RSS_CFG_REQ_HASH_TYPE_TCP_IPV6)
+   cmd->data |= RXH_IP_SRC | RXH_IP_DST |
+RXH_L4_B_0_1 | RXH_L4_B_2_3;
+   cmd->data |= get_ethtool_ipv6_rss(bp);
+   break;
+   case UDP_V6_FLOW:
+   if (bp->rss_hash_cfg & VNIC_RSS_CFG_REQ_HASH_TYPE_UDP_IPV6)
+   cmd->data |= RXH_IP_SRC | RXH_IP_DST |
+RXH_L4_B_0_1 | RXH_L4_B_2_3;
+   /* fall through */
+   case SCTP_V6_FLOW:
+   case AH_ESP_V6_FLOW:
+   case AH_V6_FLOW:
+   case ESP_V6_FLOW:
+   case IPV6_FLOW:
+   cmd->data |= get_ethtool_ipv6_rss(bp);
+   break;
+   }
+   return 0;
+}
+
+#define RXH_4TUPLE (RXH_IP_SRC | RXH_IP_DST | RXH_L4_B_0_1 | RXH_L4_B_2_3)
+#define RXH_2TUPLE (RXH_IP_SRC | RXH_IP_DST)
+
+static int bnxt_srxfh(struct bnxt *bp, struct ethtool_rxnfc *cmd)
+{
+   u32 rss_hash_cfg = bp->rss_hash_cfg;
+   int tuple, rc = 0;
+
+   if (cmd->data == RXH_4TUPLE)
+   tuple = 4;
+   else if (cmd->data == RXH_2TUPLE)
+   tuple = 2;
+   else if (!cmd->data)
+   tuple = 0;
+   else
+   return -EINVAL;
+
+   if (cmd->flow_type == TCP_V4_FLOW) {
+   rss_hash_cfg &= ~VNIC_RSS_CFG_REQ_HASH_TYPE_TCP_IPV4;
+   if (tuple == 4)
+   rss_hash_cfg |= VNIC_RSS_CFG_REQ_HASH_TYPE_TCP_IPV4;
+   } else if (cmd->flow_type == UDP_V4_FLOW) {
+   if (tuple == 4 && !(bp->flags & BNXT_FLAG_UDP_RSS_CAP))
+   return -EINVAL;
+   rss_hash_cfg &= ~VNIC_RSS_CFG_REQ_HASH_TYPE_UDP_IPV4;
+   if (tuple == 4)
+   rss_hash_cfg |= VNIC_RSS_CFG_REQ_HASH_TYPE_UDP_IPV4;
+   } else if (cmd->flow_type == TCP_V6_FLOW) {
+   rss_hash_cfg &= ~VNIC_RSS_CFG_REQ_HASH_TYPE_TCP_IPV6;
+   if (tuple == 4)
+   rss_hash_cfg |= VNIC_RSS_CFG_REQ_HASH_TYPE_TCP_IPV6;
+   } else if (cmd->flow_type == UDP_V6_FLOW) {
+   if (tuple == 4 && !(bp->flags & BNXT_FLAG_UDP_RSS_CAP))
+   return -EINVAL;
+   rss_hash_cfg &= ~VNIC_RSS_CFG_REQ_HASH_TYPE_UDP_IPV6;
+   if (tuple == 4)
+   rss_hash_cfg |= VNIC_RSS_CFG_REQ_HASH_TYPE_UDP_IPV6;
+   } else if (tuple == 4) {
+   return -EINVAL;
+   }
+
+   switch (cmd->flow_type) {
+   case TCP_V4_FLOW:
+   case UDP_V4_FLOW:
+   case SCTP_V4_FLOW:
+   case AH_ESP_V4_FLOW:
+   case AH_V4_FLOW:
+   case ESP_V4_FLOW:
+   case IPV4_FLOW:
+   if (tuple == 2)
+   rss_hash_cfg |= VNIC_RSS_CFG_REQ_HASH_TYPE_IPV4;
+   else if (!tuple)
+   rss_hash_cfg &= ~VNIC_RSS_CFG_REQ_HASH_TYPE_IPV4;
+   break;
+
+   case TCP_V6_FLOW:
+   case UDP_V6_FLOW:
+   case SCTP_V6_FLOW:
+   case 

[PATCH net-next 2/4] bnxt_en: Enhance autoneg support.

[Michael Chan]

On some dual port NICs, the speed setting on one port can affect the
available speed on the other port.  Add logic to detect these changes
and adjust the advertised speed settings when necessary.

Signed-off-by: Michael Chan 
---
 drivers/net/ethernet/broadcom/bnxt/bnxt.c | 23 +++
 drivers/net/ethernet/broadcom/bnxt/bnxt.h |  1 +
 2 files changed, 24 insertions(+)

diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c 
b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 1332577..4db50e8 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -1499,6 +1499,7 @@ static int bnxt_async_event_process(struct bnxt *bp,
netdev_warn(bp->dev, "Link speed %d no longer 
supported\n",
speed);
}
+   set_bit(BNXT_LINK_SPEED_CHNG_SP_EVENT, >sp_event);
/* fall thru */
}
case HWRM_ASYNC_EVENT_CMPL_EVENT_ID_LINK_STATUS_CHANGE:
@@ -5095,6 +5096,7 @@ static int bnxt_update_link(struct bnxt *bp, bool 
chng_link_state)
struct hwrm_port_phy_qcfg_input req = {0};
struct hwrm_port_phy_qcfg_output *resp = bp->hwrm_cmd_resp_addr;
u8 link_up = link_info->link_up;
+   u16 diff;
 
bnxt_hwrm_cmd_hdr_init(bp, , HWRM_PORT_PHY_QCFG, -1, -1);
 
@@ -5182,6 +5184,23 @@ static int bnxt_update_link(struct bnxt *bp, bool 
chng_link_state)
link_info->link_up = 0;
}
mutex_unlock(>hwrm_cmd_lock);
+
+   diff = link_info->support_auto_speeds ^ link_info->advertising;
+   if ((link_info->support_auto_speeds | diff) !=
+   link_info->support_auto_speeds) {
+   /* An advertised speed is no longer supported, so we need to
+* update the advertisement settings.  See bnxt_reset() for
+* comments about the rtnl_lock() sequence below.
+*/
+   clear_bit(BNXT_STATE_IN_SP_TASK, >state);
+   rtnl_lock();
+   link_info->advertising = link_info->support_auto_speeds;
+   if (test_bit(BNXT_STATE_OPEN, >state) &&
+   (link_info->autoneg & BNXT_AUTONEG_SPEED))
+   bnxt_hwrm_set_link_setting(bp, true, false);
+   set_bit(BNXT_STATE_IN_SP_TASK, >state);
+   rtnl_unlock();
+   }
return 0;
 }
 
@@ -6108,6 +6127,10 @@ static void bnxt_sp_task(struct work_struct *work)
if (test_and_clear_bit(BNXT_RX_NTP_FLTR_SP_EVENT, >sp_event))
bnxt_cfg_ntp_filters(bp);
if (test_and_clear_bit(BNXT_LINK_CHNG_SP_EVENT, >sp_event)) {
+   if (test_and_clear_bit(BNXT_LINK_SPEED_CHNG_SP_EVENT,
+  >sp_event))
+   bnxt_hwrm_phy_qcaps(bp);
+
rc = bnxt_update_link(bp, true);
if (rc)
netdev_err(bp->dev, "SP task can't update link (rc: 
%x)\n",
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.h 
b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
index 51b164a..666bc06 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
@@ -1089,6 +1089,7 @@ struct bnxt {
 #define BNXT_RESET_TASK_SILENT_SP_EVENT11
 #define BNXT_GENEVE_ADD_PORT_SP_EVENT  12
 #define BNXT_GENEVE_DEL_PORT_SP_EVENT  13
+#define BNXT_LINK_SPEED_CHNG_SP_EVENT  14
 
struct bnxt_pf_info pf;
 #ifdef CONFIG_BNXT_SRIOV
-- 
1.8.3.1

[PATCH net-next 3/4] bnxt_en: Add UDP RSS support for 57X1X chips.

[Michael Chan]

The newer chips have proper support for 4-tuple UDP RSS.

Signed-off-by: Michael Chan 
---
 drivers/net/ethernet/broadcom/bnxt/bnxt.c | 21 ++---
 drivers/net/ethernet/broadcom/bnxt/bnxt.h |  3 ++-
 2 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c 
b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 4db50e8..7401c90 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -3425,13 +3425,7 @@ static int bnxt_hwrm_vnic_set_rss(struct bnxt *bp, u16 
vnic_id, bool set_rss)
 
bnxt_hwrm_cmd_hdr_init(bp, , HWRM_VNIC_RSS_CFG, -1, -1);
if (set_rss) {
-   vnic->hash_type = VNIC_RSS_CFG_REQ_HASH_TYPE_IPV4 |
- VNIC_RSS_CFG_REQ_HASH_TYPE_TCP_IPV4 |
- VNIC_RSS_CFG_REQ_HASH_TYPE_IPV6 |
- VNIC_RSS_CFG_REQ_HASH_TYPE_TCP_IPV6;
-
-   req.hash_type = cpu_to_le32(vnic->hash_type);
-
+   req.hash_type = cpu_to_le32(bp->rss_hash_cfg);
if (vnic->flags & BNXT_VNIC_RSS_FLAG) {
if (BNXT_CHIP_TYPE_NITRO_A0(bp))
max_rings = bp->rx_nr_rings - 1;
@@ -6940,6 +6934,19 @@ static int bnxt_init_one(struct pci_dev *pdev, const 
struct pci_device_id *ent)
 #endif
bnxt_set_dflt_rings(bp);
 
+   /* Default RSS hash cfg. */
+   bp->rss_hash_cfg = VNIC_RSS_CFG_REQ_HASH_TYPE_IPV4 |
+  VNIC_RSS_CFG_REQ_HASH_TYPE_TCP_IPV4 |
+  VNIC_RSS_CFG_REQ_HASH_TYPE_IPV6 |
+  VNIC_RSS_CFG_REQ_HASH_TYPE_TCP_IPV6;
+   if (!BNXT_CHIP_NUM_57X0X(bp->chip_num) &&
+   !BNXT_CHIP_TYPE_NITRO_A0(bp) &&
+   bp->hwrm_spec_code >= 0x10501) {
+   bp->flags |= BNXT_FLAG_UDP_RSS_CAP;
+   bp->rss_hash_cfg |= VNIC_RSS_CFG_REQ_HASH_TYPE_UDP_IPV4 |
+   VNIC_RSS_CFG_REQ_HASH_TYPE_UDP_IPV6;
+   }
+
if (BNXT_PF(bp) && !BNXT_CHIP_TYPE_NITRO_A0(bp)) {
dev->hw_features |= NETIF_F_NTUPLE;
if (bnxt_rfs_capable(bp)) {
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.h 
b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
index 666bc06..47be789 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
@@ -700,7 +700,6 @@ struct bnxt_vnic_info {
u8  *uc_list;
 
u16 *fw_grp_ids;
-   u16 hash_type;
dma_addr_t  rss_table_dma_addr;
__le16  *rss_table;
dma_addr_t  rss_hash_key_dma_addr;
@@ -952,6 +951,7 @@ struct bnxt {
#define BNXT_FLAG_RFS   0x100
#define BNXT_FLAG_SHARED_RINGS  0x200
#define BNXT_FLAG_PORT_STATS0x400
+   #define BNXT_FLAG_UDP_RSS_CAP   0x800
#define BNXT_FLAG_EEE_CAP   0x1000
#define BNXT_FLAG_CHIP_NITRO_A0 0x100
 
@@ -1007,6 +1007,7 @@ struct bnxt {
struct bnxt_ring_grp_info   *grp_info;
struct bnxt_vnic_info   *vnic_info;
int nr_vnics;
+   u32 rss_hash_cfg;
 
u8  max_tc;
struct bnxt_queue_info  q_info[BNXT_MAX_QUEUE];
-- 
1.8.3.1

Re: [PATCHv2 perf/core 2/2] tools lib bpf: Sync with samples/bpf/libbpf

[Wangnan (F)]

I'm also working on improving bpf.c. Please have a look at:

https://lkml.org/lkml/2016/11/14/1078

Since bpf.c is simple, I think we can add more functions and fixes
gradually, instead of a full copy.

See my inline comment below.

On 2016/11/17 1:43, Joe Stringer wrote:

Extend the tools/ version of libbpf to include all of the functionality
provided in the samples/bpf version.

Signed-off-by: Joe Stringer 
---
v2: Don't shift non-bpf changes across.
 Various type cleanups, removal of extraneous declarations
---
  tools/lib/bpf/bpf.c| 107 --
  tools/lib/bpf/bpf.h| 202 +++--
  tools/lib/bpf/libbpf.c |   3 +-
  3 files changed, 279 insertions(+), 33 deletions(-)

diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
index 4212ed62235b..5e061851ac00 100644
--- a/tools/lib/bpf/bpf.c
+++ b/tools/lib/bpf/bpf.c
@@ -20,10 +20,17 @@
   */
  
  #include 

-#include 
+#include 
  #include 
  #include 
+#include 
+#include 
  #include 
+#include 
+#include 
+#include 
+#include 
+#include 
  #include "bpf.h"
  


Why we need these network related headers?


  /*
@@ -53,24 +60,71 @@ static int sys_bpf(enum bpf_cmd cmd, union bpf_attr *attr,
return syscall(__NR_bpf, cmd, attr, size);
  }
  
-int bpf_create_map(enum bpf_map_type map_type, int key_size,

-  int value_size, int max_entries)
+int bpf_create_map(enum bpf_map_type map_type, int key_size, int value_size,
+  int max_entries, int map_flags)
  {
-   union bpf_attr attr;
+   union bpf_attr attr = {
+   .map_type = map_type,
+   .key_size = key_size,
+   .value_size = value_size,
+   .max_entries = max_entries,
+   .map_flags = map_flags,
+   };
  
-	memset(, '\0', sizeof(attr));

+   return sys_bpf(BPF_MAP_CREATE, , sizeof(attr));
+}
  


I lost map_flags in original bpf.c. Thanks to your patch. map_flags is 
useful

when creating BPF_MAP_TYPE_PERCPU_HASH: BPF_F_NO_PREALLOC is meanful in this
case.

Although it is okay in samples, I still prefer a explicit bzero() or 
memset(),
because kernel checks if unused field in this union is zero. However 
I'll check

c standard to see how unused field would be initialized.





diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
index e8ba54087497..4dba36995771 100644
--- a/tools/lib/bpf/bpf.h
+++ b/tools/lib/bpf/bpf.h
@@ -23,16 +23,202 @@
  
  #include 
  
+struct bpf_insn;

+
  int bpf_create_map(enum bpf_map_type map_type, int key_size, int value_size,
-  int max_entries);
+  int max_entries, int map_flags);
+int bpf_update_elem(int fd, void *key, void *value, unsigned long long flags);
+int bpf_lookup_elem(int fd, void *key, void *value);
+int bpf_delete_elem(int fd, void *key);
+int bpf_get_next_key(int fd, void *key, void *next_key);
+
+int bpf_load_program(enum bpf_prog_type prog_type,
+const struct bpf_insn *insns, int insn_len,
+const char *license, int kern_version,
+char *log_buf, size_t log_buf_sz);
+
+int bpf_obj_pin(int fd, const char *pathname);
+int bpf_obj_get(const char *pathname);
  
-/* Recommend log buffer size */

  #define BPF_LOG_BUF_SIZE 65536
-int bpf_load_program(enum bpf_prog_type type, struct bpf_insn *insns,
-size_t insns_cnt, char *license,
-u32 kern_version, char *log_buf,
-size_t log_buf_sz);
  
-int bpf_map_update_elem(int fd, void *key, void *value,

-   u64 flags);
+/* ALU ops on registers, bpf_add|sub|...: dst_reg += src_reg */
+
+#define BPF_ALU64_REG(OP, DST, SRC)\
+   ((struct bpf_insn) {\
+   .code  = BPF_ALU64 | BPF_OP(OP) | BPF_X,\
+   .dst_reg = DST, \
+   .src_reg = SRC, \
+   .off   = 0, \
+   .imm   = 0 })
+


Should we define these macros here? They are in include/linux/filter.h
and duplicated in tools/include/linux/filter.h. Redefining them here
would cause conflict.

Thank you.

[net-next] af_packet: Use virtio_net_hdr_to_skb().

[Jarno Rajahalme]

Use the common virtio_net_hdr_to_skb() instead of open coding it.
Other call sites were changed by commit fd2a0437dc, but this one was
missed, maybe because it is split in two parts of the source code.

Also fix other call sites to be more uniform.

Fixes: fd2a0437dc ("virtio_net: introduce virtio_net_hdr_{from,to}_skb")
Signed-off-by: Jarno Rajahalme 
---
 drivers/net/macvtap.c  |  5 ++---
 drivers/net/tun.c  | 12 
 include/linux/virtio_net.h |  2 +-
 net/packet/af_packet.c | 44 +---
 4 files changed, 8 insertions(+), 55 deletions(-)

diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 070e329..5da9861 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -821,9 +821,8 @@ static ssize_t macvtap_put_user(struct macvtap_queue *q,
if (iov_iter_count(iter) < vnet_hdr_len)
return -EINVAL;
 
-   ret = virtio_net_hdr_from_skb(skb, _hdr,
- macvtap_is_little_endian(q));
-   if (ret)
+   if (virtio_net_hdr_from_skb(skb, _hdr,
+   macvtap_is_little_endian(q)))
BUG();
 
if (copy_to_iter(_hdr, sizeof(vnet_hdr), iter) !=
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 9328568..864aae3 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1252,8 +1252,7 @@ static ssize_t tun_get_user(struct tun_struct *tun, 
struct tun_file *tfile,
return -EFAULT;
}
 
-   err = virtio_net_hdr_to_skb(skb, , tun_is_little_endian(tun));
-   if (err) {
+   if (virtio_net_hdr_to_skb(skb, , tun_is_little_endian(tun))) {
this_cpu_inc(tun->pcpu_stats->rx_frame_errors);
kfree_skb(skb);
return -EINVAL;
@@ -1361,15 +1360,12 @@ static ssize_t tun_put_user(struct tun_struct *tun,
}
 
if (vnet_hdr_sz) {
-   struct virtio_net_hdr gso = { 0 }; /* no info leak */
-   int ret;
-
+   struct virtio_net_hdr gso;
if (iov_iter_count(iter) < vnet_hdr_sz)
return -EINVAL;
 
-   ret = virtio_net_hdr_from_skb(skb, ,
- tun_is_little_endian(tun));
-   if (ret) {
+   if (virtio_net_hdr_from_skb(skb, ,
+   tun_is_little_endian(tun))) {
struct skb_shared_info *sinfo = skb_shinfo(skb);
pr_err("unexpected GSO type: "
   "0x%x, gso_size %d, hdr_len %d\n",
diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
index 1c912f8..74f1e33 100644
--- a/include/linux/virtio_net.h
+++ b/include/linux/virtio_net.h
@@ -98,4 +98,4 @@ static inline int virtio_net_hdr_from_skb(const struct 
sk_buff *skb,
return 0;
 }
 
-#endif /* _LINUX_VIRTIO_BYTEORDER */
+#endif /* _LINUX_VIRTIO_NET_H */
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 11db0d6..09abb88 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1971,8 +1971,6 @@ static unsigned int run_filter(struct sk_buff *skb,
 static int __packet_rcv_vnet(const struct sk_buff *skb,
 struct virtio_net_hdr *vnet_hdr)
 {
-   *vnet_hdr = (const struct virtio_net_hdr) { 0 };
-
if (virtio_net_hdr_from_skb(skb, vnet_hdr, vio_le()))
BUG();
 
@@ -2391,8 +2389,6 @@ static void tpacket_set_protocol(const struct net_device 
*dev,
 
 static int __packet_snd_vnet_parse(struct virtio_net_hdr *vnet_hdr, size_t len)
 {
-   unsigned short gso_type = 0;
-
if ((vnet_hdr->flags & VIRTIO_NET_HDR_F_NEEDS_CSUM) &&
(__virtio16_to_cpu(vio_le(), vnet_hdr->csum_start) +
 __virtio16_to_cpu(vio_le(), vnet_hdr->csum_offset) + 2 >
@@ -2404,29 +2400,6 @@ static int __packet_snd_vnet_parse(struct virtio_net_hdr 
*vnet_hdr, size_t len)
if (__virtio16_to_cpu(vio_le(), vnet_hdr->hdr_len) > len)
return -EINVAL;
 
-   if (vnet_hdr->gso_type != VIRTIO_NET_HDR_GSO_NONE) {
-   switch (vnet_hdr->gso_type & ~VIRTIO_NET_HDR_GSO_ECN) {
-   case VIRTIO_NET_HDR_GSO_TCPV4:
-   gso_type = SKB_GSO_TCPV4;
-   break;
-   case VIRTIO_NET_HDR_GSO_TCPV6:
-   gso_type = SKB_GSO_TCPV6;
-   break;
-   case VIRTIO_NET_HDR_GSO_UDP:
-   gso_type = SKB_GSO_UDP;
-   break;
-   default:
-   return -EINVAL;
-   }
-
-   if (vnet_hdr->gso_type & VIRTIO_NET_HDR_GSO_ECN)
-   gso_type |= SKB_GSO_TCP_ECN;
-
-   if (vnet_hdr->gso_size == 0)
-   return -EINVAL;
-   }
-
-   

Re: [PATCH net-next] netpoll: more efficient locking

[David Miller]

From: Eric Dumazet 
Date: Wed, 16 Nov 2016 14:54:50 -0800

> From: Eric Dumazet 
> 
> Callers of netpoll_poll_lock() own NAPI_STATE_SCHED
> 
> Callers of netpoll_poll_unlock() have BH blocked between
> the NAPI_STATE_SCHED being cleared and poll_lock is released.
> 
> We can avoid the spinlock which has no contention, and use cmpxchg()
> on poll_owner which we need to set anyway.
> 
> This removes a possible lockdep violation after the cited commit,
> since sk_busy_loop() re-enables BH before calling busy_poll_stop()
> 
> Fixes: 217f69743681 ("net: busy-poll: allow preemption in sk_busy_loop()")
> Signed-off-by: Eric Dumazet 

Applied, thanks Eric.

Re: [PATCH net-next v3 2/3] net: fsl: Allow most drivers to be built with COMPILE_TEST

[Fengguang Wu]

On Wed, Nov 16, 2016 at 11:52:45AM -0800, Florian Fainelli wrote:

On 11/15/2016 07:23 PM, kbuild test robot wrote:

Hi Florian,

[auto build test WARNING on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Florian-Fainelli/net-gianfar_ptp-Rename-FS-bit-to-FIPERST/20161116-095805
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sh

All warnings (new ones prefixed by >>):

   drivers/net/ethernet/freescale/fsl_pq_mdio.c: In function 
'fsl_pq_mdio_remove':

drivers/net/ethernet/freescale/fsl_pq_mdio.c:498:27: warning: unused variable 
'priv' [-Wunused-variable]

 struct fsl_pq_mdio_priv *priv = bus->priv;


Humm, this looks bogus, the variable is used see below:


  ^~~~

vim +/priv +498 drivers/net/ethernet/freescale/fsl_pq_mdio.c

1577ecef drivers/net/fsl_pq_mdio.cAndy Fleming
2009-02-04  482   return 0;
1577ecef drivers/net/fsl_pq_mdio.cAndy Fleming
2009-02-04  483
dd3b8a32 drivers/net/ethernet/freescale/fsl_pq_mdio.c Timur Tabi  
2012-08-29  484  error:
dd3b8a32 drivers/net/ethernet/freescale/fsl_pq_mdio.c Timur Tabi  2012-08-29  
485   if (priv->map)
b3319b10 drivers/net/fsl_pq_mdio.cAnton Vorontsov 2009-12-30  
486   iounmap(priv->map);
dd3b8a32 drivers/net/ethernet/freescale/fsl_pq_mdio.c Timur Tabi  
2012-08-29  487
1577ecef drivers/net/fsl_pq_mdio.cAndy Fleming
2009-02-04  488   kfree(new_bus);
dd3b8a32 drivers/net/ethernet/freescale/fsl_pq_mdio.c Timur Tabi  
2012-08-29  489
1577ecef drivers/net/fsl_pq_mdio.cAndy Fleming
2009-02-04  490   return err;
1577ecef drivers/net/fsl_pq_mdio.cAndy Fleming
2009-02-04  491  }
1577ecef drivers/net/fsl_pq_mdio.cAndy Fleming
2009-02-04  492
1577ecef drivers/net/fsl_pq_mdio.cAndy Fleming
2009-02-04  493
5078ac79 drivers/net/ethernet/freescale/fsl_pq_mdio.c Timur Tabi  
2012-08-29  494  static int fsl_pq_mdio_remove(struct platform_device *pdev)
1577ecef drivers/net/fsl_pq_mdio.cAndy Fleming
2009-02-04  495  {
5078ac79 drivers/net/ethernet/freescale/fsl_pq_mdio.c Timur Tabi  2012-08-29  496  
 struct device *device = >dev;
1577ecef drivers/net/fsl_pq_mdio.cAndy Fleming
2009-02-04  497   struct mii_bus *bus = dev_get_drvdata(device);
b3319b10 drivers/net/fsl_pq_mdio.cAnton Vorontsov 2009-12-30 
@498   struct fsl_pq_mdio_priv *priv = bus->priv;
1577ecef drivers/net/fsl_pq_mdio.cAndy Fleming
2009-02-04  499
1577ecef drivers/net/fsl_pq_mdio.cAndy Fleming
2009-02-04  500   mdiobus_unregister(bus);
1577ecef drivers/net/fsl_pq_mdio.cAndy Fleming
2009-02-04  501
b3319b10 drivers/net/fsl_pq_mdio.cAnton Vorontsov 2009-12-30  
502   iounmap(priv->map);


Right here.

What compiler version is this?


Compiler is sh4-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705.

include/asm-generic/io.h conditionally defines iounmap() to be an
empty inline function, which may explain the warning on sh4.

General speaking, it's a false warning. The solution could be to teach
the robot to ignore such 'unused variable' warnings in non-x86 archs.

Thanks,
Fengguang

Re: Virtio_net support vxlan encapsulation package TSO offload discuss

[Zhangming (James, Euler)]

On 2016年11月15日 11:28, Jason Wang wrote:
>On 2016年11月10日 14:19, Zhangming (James, Euler) wrote:
>> On 2016年11月09日 15:14, Jason Wang wrote:
>>> On 2016年11月08日 19:58, Zhangming (James, Euler) wrote:
 On 2016年11月08日 19:17, Jason Wang wrote:

> On 2016年11月08日 19:13, Jason Wang wrote:
>> Cc Michael
>>
>> On 2016年11月08日 16:34, Zhangming (James, Euler) wrote:
>>> In container scenario, OVS is installed in the Virtual machine, 
>>> and all the containers connected to the OVS will communicated 
>>> through VXLAN encapsulation.
>>>
>>> By now, virtio_net does not support TSO offload for VXLAN 
>>> encapsulated TSO package. In this condition, the performance is 
>>> not good, sender is bottleneck
>>>
>>> I googled this scenario, but I didn’t find any information. Will 
>>> virtio_net support VXLAN encapsulation package TSO offload later?
>>>
>> Yes and for both sender and receiver.
>>
>>> My idea is virtio_net open encapsulated TSO offload, and 
>>> transport encapsulation info to TUN, TUN will parse the info and 
>>> build skb with encapsulation info.
>>>
>>> OVS or kernel on the host should be modified to support this. 
>>> Using this method, the TCP performance aremore than 2x as before.
>>>
>>> Any advice and suggestions for this idea or new idea will be 
>>> greatly appreciated!
>>>
>>> Best regards,
>>>
>>>  James zhang
>>>
>> Sounds very good. And we may also need features bits
>> (VIRTIO_NET_F_GUEST|HOST_GSO_X) for this.
>>
>> This is in fact one of items in networking todo list. (See 
>> http://www.linux-kvm.org/page/NetworkingTodo). While at it, we'd 
>> better support not only VXLAN but also other tunnels.
> Cc Vlad who is working on extending virtio-net headers.
>
>> We can start with the spec work, or if you've already had some 
>> bits you can post them as RFC for early review.
>>
>> Thanks
 Below is my demo code
 Virtio_net.c
 static int virtnet_probe(struct virtio_device *vdev), add belows codes:
   if (virtio_has_feature(vdev, VIRTIO_NET_F_MRG_RXBUF) ||  
 // avoid gso segment, it should be negotiation later, 
 because in the demo I reuse num_buffers.
   virtio_has_feature(vdev, VIRTIO_F_VERSION_1)) {
   dev->hw_enc_features |= NETIF_F_TSO;
   dev->hw_enc_features |= NETIF_F_ALL_CSUM;
   dev->hw_enc_features |= NETIF_F_GSO_UDP_TUNNEL;
   dev->hw_enc_features |= NETIF_F_GSO_UDP_TUNNEL_CSUM;
   dev->hw_enc_features |= 
 NETIF_F_GSO_TUNNEL_REMCSUM;

   dev->features |= NETIF_F_GSO_UDP_TUNNEL;
   dev->features |= NETIF_F_GSO_UDP_TUNNEL_CSUM;
   dev->features |= NETIF_F_GSO_TUNNEL_REMCSUM;
   }

 static int xmit_skb(struct send_queue *sq, struct sk_buff *skb), add 
 below to pieces of codes

   if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_TUNNEL)
   hdr->hdr.gso_type |= VIRTIO_NET_HDR_GSO_TUNNEL;
   if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_TUNNEL_CSUM)
   hdr->hdr.gso_type |= 
 VIRTIO_NET_HDR_GSO_TUNNEL_CSUM;
   if (skb_shinfo(skb)->gso_type & SKB_GSO_TUNNEL_REMCSUM)
   hdr->hdr.gso_type |= 
 VIRTIO_NET_HDR_GSO_TUNNEL_REMCSUM;

   if (skb->encapsulation && skb_is_gso(skb)) {
   inner_mac_len = skb_inner_network_header(skb) - 
 skb_inner_mac_header(skb);
   tnl_len = skb_inner_mac_header(skb) - 
 skb_mac_header(skb);
   if ( !(inner_mac_len >> DATA_LEN_SHIFT) && !(tnl_len >> 
 DATA_LEN_SHIFT) ) {
   hdr->hdr.flags |= VIRTIO_NET_HDR_F_ENCAPSULATION;
   hdr->num_buffers = (__virtio16)((inner_mac_len 
 << DATA_LEN_SHIFT) | tnl_len);//we reuse num_buffers for 
 simple , we should add extend member for later.
   }  else
   hdr->num_buffers = 0;
   }

 Tun.c
   if (memcpy_fromiovecend((void *), iv, offset, 
 tun->vnet_hdr_sz)) //read header with negotiation length
   return -EFAULT;

   if (hdr.gso_type & VIRTIO_NET_HDR_GSO_TUNNEL)
 //set tunnel gso info
   skb_shinfo(skb)->gso_type |= SKB_GSO_UDP_TUNNEL;
   if (hdr.gso_type & VIRTIO_NET_HDR_GSO_TUNNEL_CSUM)
   skb_shinfo(skb)->gso_type |= 
 SKB_GSO_UDP_TUNNEL_CSUM;
   if (hdr.gso_type & 

Re: [PATCHv2 perf/core 1/2] tools lib bpf: Sync {tools,}/include/uapi/linux/bpf.h

[Wangnan (F)]

On 2016/11/17 1:43, Joe Stringer wrote:

The tools version of this header is out of date; update it to the latest
version from the kernel headers.

Signed-off-by: Joe Stringer 
---
v2: No change.
---
  tools/include/uapi/linux/bpf.h | 51 ++
  1 file changed, 51 insertions(+)


Acked-by: Wang Nan 


diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 9e5fc168c8a3..f09c70b97eca 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -95,6 +95,7 @@ enum bpf_prog_type {
BPF_PROG_TYPE_SCHED_ACT,
BPF_PROG_TYPE_TRACEPOINT,
BPF_PROG_TYPE_XDP,
+   BPF_PROG_TYPE_PERF_EVENT,
  };
  
  #define BPF_PSEUDO_MAP_FD	1

@@ -375,6 +376,56 @@ enum bpf_func_id {
 */
BPF_FUNC_probe_write_user,
  
+	/**

+* bpf_current_task_under_cgroup(map, index) - Check cgroup2 membership 
of current task
+* @map: pointer to bpf_map in BPF_MAP_TYPE_CGROUP_ARRAY type
+* @index: index of the cgroup in the bpf_map
+* Return:
+*   == 0 current failed the cgroup2 descendant test
+*   == 1 current succeeded the cgroup2 descendant test
+*< 0 error
+*/
+   BPF_FUNC_current_task_under_cgroup,
+
+   /**
+* bpf_skb_change_tail(skb, len, flags)
+* The helper will resize the skb to the given new size,
+* to be used f.e. with control messages.
+* @skb: pointer to skb
+* @len: new skb length
+* @flags: reserved
+* Return: 0 on success or negative error
+*/
+   BPF_FUNC_skb_change_tail,
+
+   /**
+* bpf_skb_pull_data(skb, len)
+* The helper will pull in non-linear data in case the
+* skb is non-linear and not all of len are part of the
+* linear section. Only needed for read/write with direct
+* packet access.
+* @skb: pointer to skb
+* @len: len to make read/writeable
+* Return: 0 on success or negative error
+*/
+   BPF_FUNC_skb_pull_data,
+
+   /**
+* bpf_csum_update(skb, csum)
+* Adds csum into skb->csum in case of CHECKSUM_COMPLETE.
+* @skb: pointer to skb
+* @csum: csum to add
+* Return: csum on success or negative error
+*/
+   BPF_FUNC_csum_update,
+
+   /**
+* bpf_set_hash_invalid(skb)
+* Invalidate current skb>hash.
+* @skb: pointer to skb
+*/
+   BPF_FUNC_set_hash_invalid,
+
__BPF_FUNC_MAX_ID,
  };
  

Re: [PATCH] icmp: Restore resistence to abnormal messages

[Vicente Jiménez]

On Wed, Nov 16, 2016 at 2:14 AM, Florian Westphal  wrote:
> Vicente Jiménez  wrote:
>> 1- add warning with pr_warn_ratelimited. I like this idea. I also
>> though about adding some message but I have no kernel experience and I
>> preferred to have just a working solution.
>
> I added this only to show whats happening.
>
> I don't like such printks because end users can't do anything about it.
>
What about using net_dbg_ratelimited macro? it only adds messages if
debug is enabled.

>
>> Finally, both patches decrement current packet by a value: Mine by 2
>> and Florian's by 8 bytes. Both arbitrary values. Personally I prefer
>> to go by small steps. If the small step fails, it just iterate again
>> and with 4 iterations, my patch also decrement the original value by 8
>> bytes (4x2).
>> Basically they are the same but my patch take smaller steps and miss
>> the warning message.
>
> IIRC I chose 8 because connection recovered faster in my case.
>
> I have not experienced this issue again (I dropped the patch from
> my kernel at some point and the connection stalls did not reappear so
> this got fixed elsewhere).
My issue is permanent for now in various locations. We have to
decrease MTU manually on all devices with newer kernels. We don't have
direct access to those abnormal routers because they are managed by a
communication provider that think the network had no problem because
all their Windows machines apparently work perfectly.

-- 
cheers
vicente

Re: Netperf UDP issue with connected sockets

[Eric Dumazet]

On Wed, 2016-11-16 at 23:40 +0100, Jesper Dangaard Brouer wrote:

> Using -R 1 does not seem to help remove __ip_select_ident()
> 
> Samples: 56K of event 'cycles', Event count (approx.): 78628132661
>   Overhead  CommandShared ObjectSymbol
> +9.11%  netperf[kernel.vmlinux] [k] __ip_select_ident
> +6.98%  netperf[kernel.vmlinux] [k] _raw_spin_lock
> +6.21%  swapper[mlx5_core]  [k] mlx5e_poll_tx_cq
> +5.03%  netperf[kernel.vmlinux] [k] 
> copy_user_enhanced_fast_string
> +4.69%  netperf[kernel.vmlinux] [k] __ip_make_skb
> +4.63%  netperf[kernel.vmlinux] [k] skb_set_owner_w
> +4.15%  swapper[kernel.vmlinux] [k] __slab_free
> +3.80%  netperf[mlx5_core]  [k] mlx5e_sq_xmit
> +2.00%  swapper[kernel.vmlinux] [k] sock_wfree
> +1.94%  netperfnetperf  [.] send_data
> +1.92%  netperfnetperf  [.] send_omni_inner

Check "ss -nu"  ?

You will see if sockets are connected (present in ss output or not)

UDP being connected does not prevent __ip_select_ident() being used.

if ((iph->frag_off & htons(IP_DF)) && !skb->ignore_df) {

So you need IP_DF being set, and skb->ignore_df being 0

-> time to try IP_MTU_DISCOVER ;)

[PATCH] netns: make struct pernet_operations::id unsigned int

[Alexey Dobriyan]

Make struct pernet_operations::id unsigned.

There are 2 reasons to do so:

1)
This field is really an index into an zero based array and
thus is unsigned entity. Using negative value is out-of-bound
access by definition.

2)
On x86_64 unsigned 32-bit data which are mixed with pointers
via array indexing or offsets added or subtracted to pointers
are preffered to signed 32-bit data.

"int" being used as an array index needs to be sign-extended
to 64-bit before being used.

void f(long *p, int i)
{
g(p[i]);
}

  roughly translates to

movsx   rsi, esi
mov rdi, [rsi+...]
callg

MOVSX is 3 byte instruction which isn't necessary if the variable is
unsigned because x86_64 is zero extending by default.

Now, there is net_generic() function which, you guessed it right, uses
"int" as an array index:

static inline void *net_generic(const struct net *net, int id)
{
...
ptr = ng->ptr[id - 1];
...
}

And this function is used a lot, so those sign extensions add up.

Patch snipes ~1730 bytes on allyesconfig kernel (without all junk
messing with code generation):

add/remove: 0/0 grow/shrink: 70/598 up/down: 396/-2126 (-1730)

Unfortunately some functions actually grow bigger.
This is a semmingly random artefact of code generation with register
allocator being used differently. gcc decides that some variable
needs to live in new r8+ registers and every access now requires REX
prefix. Or it is shifted into r12, so [r12+0] addressing mode has to be
used which is longer than [r8]

However, overall balance is in negative direction:

add/remove: 0/0 grow/shrink: 70/598 up/down: 396/-2126 (-1730)
function old new   delta
nfsd4_lock  38863959 +73
tipc_link_build_proto_msg   10961140 +44
mac80211_hwsim_new_radio27762808 +32
tipc_mon_rcv10321058 +26
svcauth_gss_legacy_init 14131429 +16
tipc_bcbase_select_primary   379 392 +13
nfsd4_exchange_id   12471260 +13
nfsd4_setclientid_confirm782 793 +11
...
put_client_renew_locked  494 480 -14
ip_set_sockfn_get730 716 -14
geneve_sock_add  829 813 -16
nfsd4_sequence_done  721 703 -18
nlmclnt_lookup_host  708 686 -22
nfsd4_lockt 10851063 -22
nfs_get_client  10771050 -27
tcf_bpf_init11061076 -30
nfsd4_encode_fattr  59975930 -67
Total: Before=154856051, After=154854321, chg -0.00%

Signed-off-by: Alexey Dobriyan 
---

 drivers/infiniband/core/cma.c |2 +-
 drivers/net/bonding/bond_main.c   |2 +-
 drivers/net/geneve.c  |2 +-
 drivers/net/gtp.c |2 +-
 drivers/net/ppp/ppp_generic.c |2 +-
 drivers/net/ppp/pppoe.c   |2 +-
 drivers/net/vxlan.c   |2 +-
 drivers/net/wireless/mac80211_hwsim.c |2 +-
 fs/lockd/netns.h  |2 +-
 fs/lockd/svc.c|2 +-
 fs/nfs/inode.c|2 +-
 fs/nfs/netns.h|2 +-
 fs/nfs_common/grace.c |2 +-
 fs/nfsd/netns.h   |2 +-
 fs/nfsd/nfsctl.c  |2 +-
 include/net/bonding.h |2 +-
 include/net/ip_tunnels.h  |6 +++---
 include/net/net_namespace.h   |2 +-
 include/net/netfilter/nf_conntrack_l4proto.h  |2 +-
 include/net/netfilter/nf_conntrack_synproxy.h |2 +-
 include/net/netns/generic.h   |2 +-
 kernel/audit.c|2 +-
 net/8021q/vlan.c  |2 +-
 net/8021q/vlan.h  |2 +-
 net/bridge/br_netfilter_hooks.c   |2 +-
 net/caif/caif_dev.c   |2 +-
 net/core/net_namespace.c  |7 +++
 net/core/pktgen.c |2 +-
 net/ipv4/ip_gre.c |4 ++--
 net/ipv4/ip_tunnel.c  |4 ++--
 net/ipv4/ip_vti.c |2 +-

linux-next: manual merge of the net-next tree with the net tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  kernel/bpf/verifier.c

between commit:

  f23cc643f9ba ("bpf: fix range arithmetic for bpf map access")

from the net tree and commit:

  de464375daf0 ("bpf: Remove unused but set variables")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc kernel/bpf/verifier.c
index 6a936159c6e0,89f787ca47ef..
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@@ -212,12 -229,13 +229,13 @@@ static void print_verifier_state(struc
else if (t == CONST_PTR_TO_MAP || t == PTR_TO_MAP_VALUE ||
 t == PTR_TO_MAP_VALUE_OR_NULL ||
 t == PTR_TO_MAP_VALUE_ADJ)
-   verbose("(ks=%d,vs=%d)",
+   verbose("(ks=%d,vs=%d,id=%u)",
reg->map_ptr->key_size,
-   reg->map_ptr->value_size);
+   reg->map_ptr->value_size,
+   reg->id);
if (reg->min_value != BPF_REGISTER_MIN_RANGE)
 -  verbose(",min_value=%llu",
 -  (unsigned long long)reg->min_value);
 +  verbose(",min_value=%lld",
 +  (long long)reg->min_value);
if (reg->max_value != BPF_REGISTER_MAX_RANGE)
verbose(",max_value=%llu",
(unsigned long long)reg->max_value);
@@@ -1477,9 -1498,7 +1499,8 @@@ static void adjust_reg_min_max_vals(str
struct bpf_insn *insn)
  {
struct bpf_reg_state *regs = env->cur_state.regs, *dst_reg;
 -  u64 min_val = BPF_REGISTER_MIN_RANGE, max_val = BPF_REGISTER_MAX_RANGE;
 +  s64 min_val = BPF_REGISTER_MIN_RANGE;
 +  u64 max_val = BPF_REGISTER_MAX_RANGE;
-   bool min_set = false, max_set = false;
u8 opcode = BPF_OP(insn->code);
  
dst_reg = [insn->dst_reg];

linux-next: manual merge of the net-next tree with the net tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  include/linux/bpf_verifier.h

between commit:

  f23cc643f9ba ("bpf: fix range arithmetic for bpf map access")

from the net tree and commit:

  57a09bf0a416 ("bpf: Detect identical PTR_TO_MAP_VALUE_OR_NULL registers")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/bpf_verifier.h
index 6aaf425cebc3,ac5b393ee6b2..
--- a/include/linux/bpf_verifier.h
+++ b/include/linux/bpf_verifier.h
@@@ -22,8 -22,8 +22,9 @@@ struct bpf_reg_state 
 * Used to determine if any memory access using this register will
 * result in a bad access.
 */
 -  u64 min_value, max_value;
 +  s64 min_value;
 +  u64 max_value;
+   u32 id;
union {
/* valid when type == CONST_IMM | PTR_TO_STACK | UNKNOWN_VALUE 
*/
s64 imm;

linux-next: manual merge of the net-next tree with the net tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c

between commit:

  ba1ffd74df74 ("stmmac: fix PTP support for GMAC4")

from the net tree and commit:

  f8be0d78be6e ("net: ethernet: stmmac: change dma descriptors to __le32")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
index a601f8d43b75,bec72d3103a1..
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
@@@ -211,18 -205,14 +212,18 @@@ static void dwmac4_rd_enable_tx_timesta
  
  static int dwmac4_wrback_get_tx_timestamp_status(struct dma_desc *p)
  {
 -  return (le32_to_cpu(p->des3) & TDES3_TIMESTAMP_STATUS)
 -  >> TDES3_TIMESTAMP_STATUS_SHIFT;
 +  /* Context type from W/B descriptor must be zero */
-   if (p->des3 & TDES3_CONTEXT_TYPE)
++  if (le32_to_cpu(p->des3) & TDES3_CONTEXT_TYPE)
 +  return -EINVAL;
 +
 +  /* Tx Timestamp Status is 1 so des0 and des1'll have valid values */
-   if (p->des3 & TDES3_TIMESTAMP_STATUS)
++  if (le32_to_cpu(p->des3) & TDES3_TIMESTAMP_STATUS)
 +  return 0;
 +
 +  return 1;
  }
  
 -/*  NOTE: For RX CTX bit has to be checked before
 - *  HAVE a specific function for TX and another one for RX
 - */
 -static u64 dwmac4_wrback_get_timestamp(void *desc, u32 ats)
 +static inline u64 dwmac4_get_timestamp(void *desc, u32 ats)
  {
struct dma_desc *p = (struct dma_desc *)desc;
u64 ns;
@@@ -234,54 -224,12 +235,54 @@@
return ns;
  }
  
 -static int dwmac4_context_get_rx_timestamp_status(void *desc, u32 ats)
 +static int dwmac4_rx_check_timestamp(void *desc)
 +{
 +  struct dma_desc *p = (struct dma_desc *)desc;
 +  u32 own, ctxt;
 +  int ret = 1;
 +
-   own = p->des3 & RDES3_OWN;
-   ctxt = ((p->des3 & RDES3_CONTEXT_DESCRIPTOR)
++  own = le32_to_cpu(p->des3) & RDES3_OWN;
++  ctxt = ((le32_to_cpu(p->des3) & RDES3_CONTEXT_DESCRIPTOR)
 +  >> RDES3_CONTEXT_DESCRIPTOR_SHIFT);
 +
 +  if (likely(!own && ctxt)) {
 +  if ((p->des0 == 0x) && (p->des1 == 0x))
 +  /* Corrupted value */
 +  ret = -EINVAL;
 +  else
 +  /* A valid Timestamp is ready to be read */
 +  ret = 0;
 +  }
 +
 +  /* Timestamp not ready */
 +  return ret;
 +}
 +
 +static int dwmac4_wrback_get_rx_timestamp_status(void *desc, u32 ats)
  {
struct dma_desc *p = (struct dma_desc *)desc;
 +  int ret = -EINVAL;
 +
 +  /* Get the status from normal w/b descriptor */
-   if (likely(p->des3 & TDES3_RS1V)) {
-   if (likely(p->des1 & RDES1_TIMESTAMP_AVAILABLE)) {
++  if (likely(le32_to_cpu(p->des3) & TDES3_RS1V)) {
++  if (likely(le32_to_cpu(p->des1) & RDES1_TIMESTAMP_AVAILABLE)) {
 +  int i = 0;
 +
 +  /* Check if timestamp is OK from context descriptor */
 +  do {
 +  ret = dwmac4_rx_check_timestamp(desc);
 +  if (ret < 0)
 +  goto exit;
 +  i++;
  
 -  return (le32_to_cpu(p->des1) & RDES1_TIMESTAMP_AVAILABLE)
 -  >> RDES1_TIMESTAMP_AVAILABLE_SHIFT;
 +  } while ((ret == 1) || (i < 10));
 +
 +  if (i == 10)
 +  ret = -EBUSY;
 +  }
 +  }
 +exit:
 +  return ret;
  }
  
  static void dwmac4_rd_init_rx_desc(struct dma_desc *p, int disable_rx_ic,

linux-next: manual merge of the net-next tree with the net tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  drivers/net/ethernet/cavium/thunder/nicvf_main.c

between commit:

  712c31853440 ("net: thunderx: Program LMAC credits based on MTU")

from the net tree and commit:

  109cc16526c6 ("ethernet/cavium: use core min/max MTU checking")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/ethernet/cavium/thunder/nicvf_main.c
index 8a37012c9c89,b192712c93b7..
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@@ -1292,19 -1312,10 +1292,13 @@@ static int nicvf_change_mtu(struct net_
  {
struct nicvf *nic = netdev_priv(netdev);
  
-   if (new_mtu > NIC_HW_MAX_FRS)
-   return -EINVAL;
- 
-   if (new_mtu < NIC_HW_MIN_FRS)
-   return -EINVAL;
- 
 +  netdev->mtu = new_mtu;
 +
 +  if (!netif_running(netdev))
 +  return 0;
 +
if (nicvf_update_hw_max_frs(nic, new_mtu))
return -EINVAL;
 -  netdev->mtu = new_mtu;
 -  nic->mtu = new_mtu;
  
return 0;
  }

Re: [PATCH net-next v6] cadence: Add LSO support.

[David Miller]

From: Rafal Ozieblo 
Date: Wed, 16 Nov 2016 10:02:34 +

> New Cadence GEM hardware support Large Segment Offload (LSO):
> TCP segmentation offload (TSO) as well as UDP fragmentation
> offload (UFO). Support for those features was added to the driver.
> ---
> Changed in v2:
> macb_lso_check_compatibility() changed to macb_features_check()
> (with little modifications) and bind to .ndo_features_check.
> (after Eric Dumazet suggestion)
> ---
> Changed in v3:
> Respin to net-next.
> ---
> Changed in v4:
> (struct iphdr*)skb_network_header(skb) changed to ip_hdr(skb)
> ---
> Changed in v5:
> Changes after Florian Fainelli comments
> ---
> Changes in v6:
> UDP checksum zeroing removed. There is no need to zeroing
> UDP checksum during UFO operation.
> 
> Signed-off-by: Rafal Ozieblo 

Applied.

But you really, truly, screwed up this commit message.

Everything after "---" will be deleted from the commit message when I
apply your patch with GIT.  Which means your entire changelog plus
your signoff were removed.

Please do this properly in the future.

Re: [PATCH v2] net/phy/vitesse: Configure RGMII skew on VSC8601, if needed

[David Miller]

From: Alexandru Gagniuc 
Date: Wed, 16 Nov 2016 01:02:33 -0800

> With RGMII, we need a 1.5 to 2ns skew between clock and data lines. The
> VSC8601 can handle this internally. While the VSC8601 can set more
> fine-grained delays, the standard skew settings work out of the box.
> The same heuristic is used to determine when this skew should be enabled
> as in vsc824x_config_init().
> 
> Tested on custom board with AM3352 SOC and VSC801 PHY.
> 
> Signed-off-by: Alexandru Gagniuc 
> ---
> Changes since v1:
>  * Added comment detailing applicability to different RGMII interfaces.

Applied.

[PATCH net-next] netpoll: more efficient locking

[Eric Dumazet]

From: Eric Dumazet 

Callers of netpoll_poll_lock() own NAPI_STATE_SCHED

Callers of netpoll_poll_unlock() have BH blocked between
the NAPI_STATE_SCHED being cleared and poll_lock is released.

We can avoid the spinlock which has no contention, and use cmpxchg()
on poll_owner which we need to set anyway.

This removes a possible lockdep violation after the cited commit,
since sk_busy_loop() re-enables BH before calling busy_poll_stop()

Fixes: 217f69743681 ("net: busy-poll: allow preemption in sk_busy_loop()")
Signed-off-by: Eric Dumazet 
---
 include/linux/netdevice.h |1 -
 include/linux/netpoll.h   |   13 +++--
 net/core/dev.c|1 -
 net/core/netpoll.c|6 +++---
 4 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index bcddf951ccee..e84800edd249 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -316,7 +316,6 @@ struct napi_struct {
unsigned intgro_count;
int (*poll)(struct napi_struct *, int);
 #ifdef CONFIG_NETPOLL
-   spinlock_t  poll_lock;
int poll_owner;
 #endif
struct net_device   *dev;
diff --git a/include/linux/netpoll.h b/include/linux/netpoll.h
index b25ee9ffdbe6..1828900c9411 100644
--- a/include/linux/netpoll.h
+++ b/include/linux/netpoll.h
@@ -78,8 +78,11 @@ static inline void *netpoll_poll_lock(struct napi_struct 
*napi)
struct net_device *dev = napi->dev;
 
if (dev && dev->npinfo) {
-   spin_lock(>poll_lock);
-   napi->poll_owner = smp_processor_id();
+   int owner = smp_processor_id();
+
+   while (cmpxchg(>poll_owner, -1, owner) != -1)
+   cpu_relax();
+
return napi;
}
return NULL;
@@ -89,10 +92,8 @@ static inline void netpoll_poll_unlock(void *have)
 {
struct napi_struct *napi = have;
 
-   if (napi) {
-   napi->poll_owner = -1;
-   spin_unlock(>poll_lock);
-   }
+   if (napi)
+   smp_store_release(>poll_owner, -1);
 }
 
 static inline bool netpoll_tx_running(struct net_device *dev)
diff --git a/net/core/dev.c b/net/core/dev.c
index edba9efeb2e9..f71b34ab57a5 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5143,7 +5143,6 @@ void netif_napi_add(struct net_device *dev, struct 
napi_struct *napi,
list_add(>dev_list, >napi_list);
napi->dev = dev;
 #ifdef CONFIG_NETPOLL
-   spin_lock_init(>poll_lock);
napi->poll_owner = -1;
 #endif
set_bit(NAPI_STATE_SCHED, >state);
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 53599bd0c82d..9424673009c1 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -171,12 +171,12 @@ static void poll_one_napi(struct napi_struct *napi)
 static void poll_napi(struct net_device *dev)
 {
struct napi_struct *napi;
+   int cpu = smp_processor_id();
 
list_for_each_entry(napi, >napi_list, dev_list) {
-   if (napi->poll_owner != smp_processor_id() &&
-   spin_trylock(>poll_lock)) {
+   if (cmpxchg(>poll_owner, -1, cpu) == -1) {
poll_one_napi(napi);
-   spin_unlock(>poll_lock);
+   smp_store_release(>poll_owner, -1);
}
}
 }

Re: [PATCH] net: bcm63xx_enet: fix build failure

[David Miller]

From: Sudip Mukherjee 
Date: Wed, 16 Nov 2016 22:50:16 +

> The build of mips bcm63xx_defconfig was failing with the error:
> drivers/net/ethernet/broadcom/bcm63xx_enet.c:1440:2:
>   error: expected expression before 'return'
> 
> The return statement should be termibated with ';' and not ','.
> 
> Fixes: 42469bf5d9bb ("net: bcm63xx_enet: Utilize phy_ethtool_nway_reset")
> Signed-off-by: Sudip Mukherjee 

Already fixes in the current net-next tree.

[PATCH] net: bcm63xx_enet: fix build failure

[Sudip Mukherjee]

The build of mips bcm63xx_defconfig was failing with the error:
drivers/net/ethernet/broadcom/bcm63xx_enet.c:1440:2:
error: expected expression before 'return'

The return statement should be termibated with ';' and not ','.

Fixes: 42469bf5d9bb ("net: bcm63xx_enet: Utilize phy_ethtool_nway_reset")
Signed-off-by: Sudip Mukherjee 
---

build log is at:
https://travis-ci.org/sudipm-mukherjee/parport/jobs/176269457

 drivers/net/ethernet/broadcom/bcm63xx_enet.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.c 
b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
index a43ab90..3b14d51 100644
--- a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+++ b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
@@ -1435,7 +1435,7 @@ static int bcm_enet_nway_reset(struct net_device *dev)
 
priv = netdev_priv(dev);
if (priv->has_phy)
-   return phy_ethtool_nway_reset(dev),
+   return phy_ethtool_nway_reset(dev);
 
return -EOPNOTSUPP;
 }
-- 
1.9.1

Re: Netperf UDP issue with connected sockets

[Rick Jones]

On 11/16/2016 02:40 PM, Jesper Dangaard Brouer wrote:

On Wed, 16 Nov 2016 09:46:37 -0800
Rick Jones  wrote:

It is a wild guess, but does setting SO_DONTROUTE affect whether or not
a connect() would have the desired effect?  That is there to protect
people from themselves (long story about people using UDP_STREAM to
stress improperly air-gapped systems during link up/down testing)
It can be disabled with a test-specific -R 1 option, so your netperf
command would become:

netperf -H 198.18.50.1 -t UDP_STREAM -l 120 -- -m 1472 -n -N -R 1


Using -R 1 does not seem to help remove __ip_select_ident()


Bummer.  It was a wild guess anyway, since I was seeing a connect() call 
on the data socket.



Samples: 56K of event 'cycles', Event count (approx.): 78628132661
  Overhead  CommandShared ObjectSymbol
+9.11%  netperf[kernel.vmlinux] [k] __ip_select_ident
+6.98%  netperf[kernel.vmlinux] [k] _raw_spin_lock
+6.21%  swapper[mlx5_core]  [k] mlx5e_poll_tx_cq
+5.03%  netperf[kernel.vmlinux] [k] 
copy_user_enhanced_fast_string
+4.69%  netperf[kernel.vmlinux] [k] __ip_make_skb
+4.63%  netperf[kernel.vmlinux] [k] skb_set_owner_w
+4.15%  swapper[kernel.vmlinux] [k] __slab_free
+3.80%  netperf[mlx5_core]  [k] mlx5e_sq_xmit
+2.00%  swapper[kernel.vmlinux] [k] sock_wfree
+1.94%  netperfnetperf  [.] send_data
+1.92%  netperfnetperf  [.] send_omni_inner


Well, the next step I suppose is to have you try a quick netperf 
UDP_STREAM under strace to see if your netperf binary does what mine did:


strace -v -o /tmp/netperf.strace netperf -H 198.18.50.1 -t UDP_STREAM -l 
1 -- -m 1472 -n -N -R 1


And see if you see the connect() I saw. (Note, I make the runtime 1 second)

rick

[PATCH iproute2 v2 7/9] l2tp: support sequence numbering

[Asbjørn Sloth Tønnesen]

This patch implement and documents the user interface for
sequence numbering.

Signed-off-by: Asbjørn Sloth Tønnesen 
---
 ip/ipl2tp.c| 23 +++
 man/man8/ip-l2tp.8 | 15 +++
 2 files changed, 38 insertions(+)

diff --git a/ip/ipl2tp.c b/ip/ipl2tp.c
index f5d4113..ab35023 100644
--- a/ip/ipl2tp.c
+++ b/ip/ipl2tp.c
@@ -246,6 +246,12 @@ static void print_session(struct l2tp_data *data)
printf("  reorder timeout: %u\n", p->reorder_timeout);
else
printf("\n");
+   if (p->send_seq || p->recv_seq) {
+   printf("  sequence numbering:");
+   if (p->send_seq) printf(" send");
+   if (p->recv_seq) printf(" recv");
+   printf("\n");
+   }
 }
 
 static int get_response(struct nlmsghdr *n, void *arg)
@@ -482,6 +488,7 @@ static void usage(void)
fprintf(stderr, "  session_id ID peer_session_id ID\n");
fprintf(stderr, "  [ cookie HEXSTR ] [ peer_cookie HEXSTR ]\n");
fprintf(stderr, "  [ offset OFFSET ] [ peer_offset OFFSET ]\n");
+   fprintf(stderr, "  [ seq { none | send | recv | both } ]\n");
fprintf(stderr, "  [ l2spec_type L2SPEC ]\n");
fprintf(stderr, "   ip l2tp del tunnel tunnel_id ID\n");
fprintf(stderr, "   ip l2tp del session tunnel_id ID session_id 
ID\n");
@@ -652,6 +659,22 @@ static int parse_args(int argc, char **argv, int cmd, 
struct l2tp_parm *p)
fprintf(stderr, "Unknown layer2specific header 
type \"%s\"\n", *argv);
exit(-1);
}
+   } else if (strcmp(*argv, "seq") == 0) {
+   NEXT_ARG();
+   if (strcasecmp(*argv, "both") == 0) {
+   p->recv_seq = 1;
+   p->send_seq = 1;
+   } else if (strcasecmp(*argv, "recv") == 0) {
+   p->recv_seq = 1;
+   } else if (strcasecmp(*argv, "send") == 0) {
+   p->send_seq = 1;
+   } else if (strcasecmp(*argv, "none") == 0) {
+   p->recv_seq = 0;
+   p->send_seq = 0;
+   } else {
+   fprintf(stderr, "Unknown seq value \"%s\"\n", 
*argv);
+   exit(-1);
+   }
} else if (strcmp(*argv, "tunnel") == 0) {
p->tunnel = 1;
} else if (strcmp(*argv, "session") == 0) {
diff --git a/man/man8/ip-l2tp.8 b/man/man8/ip-l2tp.8
index 991d097..d4e7270 100644
--- a/man/man8/ip-l2tp.8
+++ b/man/man8/ip-l2tp.8
@@ -51,6 +51,8 @@ ip-l2tp - L2TPv3 static unmanaged tunnel configuration
 .br
 .RB "[ " l2spec_type " { " none " | " default " } ]"
 .br
+.RB "[ " seq " { " none " | " send " | " recv " | " both " } ]"
+.br
 .RB "[ " offset
 .IR OFFSET
 .RB " ] [ " peer_offset
@@ -238,6 +240,19 @@ set the layer2specific header type of the session.
 Valid values are:
 .BR none ", " default "."
 .TP
+.BI seq " SEQ"
+controls sequence numbering to prevent or detect out of order packets.
+.B send
+puts a sequence number in the default layer2specific header of each
+outgoing packet.
+.B recv
+reorder packets if they are received out of order.
+Default is
+.BR none "."
+.br
+Valid values are:
+.BR none ", " send ", " recv ", " both "."
+.TP
 .BI offset " OFFSET"
 sets the byte offset from the L2TP header where user data starts in
 transmitted L2TP data packets. This is hardly ever used. If set, the
-- 
2.10.2

[PATCH iproute2 v2 8/9] l2tp: show tunnel: expose UDP checksum state

[Asbjørn Sloth Tønnesen]

Signed-off-by: Asbjørn Sloth Tønnesen 
---
 ip/ipl2tp.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/ip/ipl2tp.c b/ip/ipl2tp.c
index ab35023..f2bbc0c 100644
--- a/ip/ipl2tp.c
+++ b/ip/ipl2tp.c
@@ -218,9 +218,24 @@ static void print_tunnel(const struct l2tp_data *data)
printf("  Peer tunnel %u\n",
   p->peer_tunnel_id);
 
-   if (p->encap == L2TP_ENCAPTYPE_UDP)
+   if (p->encap == L2TP_ENCAPTYPE_UDP) {
printf("  UDP source / dest ports: %hu/%hu\n",
   p->local_udp_port, p->peer_udp_port);
+
+   switch (p->local_ip.family) {
+   case AF_INET:
+   printf("  UDP checksum: %s\n",
+  p->udp_csum ? "enabled" : "disabled");
+   break;
+   case AF_INET6:
+   printf("  UDP checksum: %s%s%s%s\n",
+  p->udp6_csum_tx && p->udp6_csum_rx ? "enabled" : 
"",
+  p->udp6_csum_tx && !p->udp6_csum_rx ? "tx" : "",
+  !p->udp6_csum_tx && p->udp6_csum_rx ? "rx" : "",
+  !p->udp6_csum_tx && !p->udp6_csum_rx ? 
"disabled" : "");
+   break;
+   }
+   }
 }
 
 static void print_session(struct l2tp_data *data)
-- 
2.10.2

[PATCH iproute2 v2 4/9] l2tp: fix L2TP_ATTR_{RECV,SEND}_SEQ handling

[Asbjørn Sloth Tønnesen]

L2TP_ATTR_RECV_SEQ and L2TP_ATTR_SEND_SEQ are declared as NLA_U8
attributes in the kernel, so let's threat them accordingly.

Signed-off-by: Asbjørn Sloth Tønnesen 
---
 ip/ipl2tp.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/ip/ipl2tp.c b/ip/ipl2tp.c
index 2e0e9c7..a7cbd66 100644
--- a/ip/ipl2tp.c
+++ b/ip/ipl2tp.c
@@ -160,8 +160,8 @@ static int create_session(struct l2tp_parm *p)
addattr8(, 1024, L2TP_ATTR_L2SPEC_LEN, p->l2spec_len);
 
if (p->mtu) addattr16(, 1024, L2TP_ATTR_MTU, p->mtu);
-   if (p->recv_seq)addattr(, 1024, L2TP_ATTR_RECV_SEQ);
-   if (p->send_seq)addattr(, 1024, L2TP_ATTR_SEND_SEQ);
+   if (p->recv_seq)addattr8(, 1024, L2TP_ATTR_RECV_SEQ, 1);
+   if (p->send_seq)addattr8(, 1024, L2TP_ATTR_SEND_SEQ, 1);
if (p->lns_mode)addattr(, 1024, L2TP_ATTR_LNS_MODE);
if (p->data_seq)addattr8(, 1024, L2TP_ATTR_DATA_SEQ, 
p->data_seq);
if (p->reorder_timeout) addattr64(, 1024, L2TP_ATTR_RECV_TIMEOUT,
@@ -304,8 +304,10 @@ static int get_response(struct nlmsghdr *n, void *arg)
memcpy(p->peer_cookie, RTA_DATA(attrs[L2TP_ATTR_PEER_COOKIE]),
   p->peer_cookie_len = 
RTA_PAYLOAD(attrs[L2TP_ATTR_PEER_COOKIE]));
 
-   p->recv_seq = !!attrs[L2TP_ATTR_RECV_SEQ];
-   p->send_seq = !!attrs[L2TP_ATTR_SEND_SEQ];
+   if (attrs[L2TP_ATTR_RECV_SEQ])
+   p->recv_seq = !!rta_getattr_u8(attrs[L2TP_ATTR_RECV_SEQ]);
+   if (attrs[L2TP_ATTR_SEND_SEQ])
+   p->send_seq = !!rta_getattr_u8(attrs[L2TP_ATTR_SEND_SEQ]);
 
if (attrs[L2TP_ATTR_RECV_TIMEOUT])
p->reorder_timeout = 
rta_getattr_u64(attrs[L2TP_ATTR_RECV_TIMEOUT]);
-- 
2.10.2

[PATCH iproute2 v2 6/9] l2tp: read IPv6 UDP checksum attributes from kernel

[Asbjørn Sloth Tønnesen]

In case of an older kernel that doesn't set L2TP_ATTR_UDP_ZERO_CSUM6_{RX,TX}
the old hard-coded value is being preserved, since the attribute flag will be
missing.

Signed-off-by: Asbjørn Sloth Tønnesen 
---
 ip/ipl2tp.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/ip/ipl2tp.c b/ip/ipl2tp.c
index 03ca0cc..f5d4113 100644
--- a/ip/ipl2tp.c
+++ b/ip/ipl2tp.c
@@ -292,12 +292,9 @@ static int get_response(struct nlmsghdr *n, void *arg)
if (attrs[L2TP_ATTR_UDP_CSUM])
p->udp_csum = !!rta_getattr_u8(attrs[L2TP_ATTR_UDP_CSUM]);
 
-   /*
-* Not fetching from L2TP_ATTR_UDP_ZERO_CSUM6_{T,R}X because the
-* kernel doesn't send it so just leave it as default value.
-*/
-   p->udp6_csum_tx = 1;
-   p->udp6_csum_rx = 1;
+   p->udp6_csum_tx = !attrs[L2TP_ATTR_UDP_ZERO_CSUM6_TX];
+   p->udp6_csum_rx = !attrs[L2TP_ATTR_UDP_ZERO_CSUM6_RX];
+
if (attrs[L2TP_ATTR_COOKIE])
memcpy(p->cookie, RTA_DATA(attrs[L2TP_ATTR_COOKIE]),
   p->cookie_len = RTA_PAYLOAD(attrs[L2TP_ATTR_COOKIE]));
-- 
2.10.2

[PATCH iproute2 v2 3/9] l2tp: fix integers with too few significant bits

[Asbjørn Sloth Tønnesen]

udp6_csum_{tx,rx}, tunnel and session are the only ones
currently used.

recv_seq, send_seq, lns_mode and data_seq are partially
implemented in a useless way.

Signed-off-by: Asbjørn Sloth Tønnesen 
---
 ip/ipl2tp.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/ip/ipl2tp.c b/ip/ipl2tp.c
index d3338ac..2e0e9c7 100644
--- a/ip/ipl2tp.c
+++ b/ip/ipl2tp.c
@@ -56,15 +56,15 @@ struct l2tp_parm {
 
uint16_t pw_type;
uint16_t mtu;
-   int udp6_csum_tx:1;
-   int udp6_csum_rx:1;
-   int udp_csum:1;
-   int recv_seq:1;
-   int send_seq:1;
-   int lns_mode:1;
-   int data_seq:2;
-   int tunnel:1;
-   int session:1;
+   unsigned int udp6_csum_tx:1;
+   unsigned int udp6_csum_rx:1;
+   unsigned int udp_csum:1;
+   unsigned int recv_seq:1;
+   unsigned int send_seq:1;
+   unsigned int lns_mode:1;
+   unsigned int data_seq:2;
+   unsigned int tunnel:1;
+   unsigned int session:1;
int reorder_timeout;
const char *ifname;
uint8_t l2spec_type;
-- 
2.10.2

[PATCH iproute2 v2 5/9] l2tp: fix L2TP_ATTR_UDP_CSUM handling

[Asbjørn Sloth Tønnesen]

L2TP_ATTR_UDP_CSUM is read by the kernel as a NLA_FLAG value,
but is validated as a NLA_U8, so we will write it as an u8,
but the value isn't actually being read by the kernel.

It is written by the kernel as a NLA_U8, so we will read as
such.

Signed-off-by: Asbjørn Sloth Tønnesen 
---
 ip/ipl2tp.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/ip/ipl2tp.c b/ip/ipl2tp.c
index a7cbd66..03ca0cc 100644
--- a/ip/ipl2tp.c
+++ b/ip/ipl2tp.c
@@ -120,7 +120,7 @@ static int create_tunnel(struct l2tp_parm *p)
addattr16(, 1024, L2TP_ATTR_UDP_SPORT, p->local_udp_port);
addattr16(, 1024, L2TP_ATTR_UDP_DPORT, p->peer_udp_port);
if (p->udp_csum)
-   addattr(, 1024, L2TP_ATTR_UDP_CSUM);
+   addattr8(, 1024, L2TP_ATTR_UDP_CSUM, 1);
if (!p->udp6_csum_tx)
addattr(, 1024, L2TP_ATTR_UDP_ZERO_CSUM6_TX);
if (!p->udp6_csum_rx)
@@ -289,7 +289,9 @@ static int get_response(struct nlmsghdr *n, void *arg)
if (attrs[L2TP_ATTR_L2SPEC_LEN])
p->l2spec_len = rta_getattr_u8(attrs[L2TP_ATTR_L2SPEC_LEN]);
 
-   p->udp_csum = !!attrs[L2TP_ATTR_UDP_CSUM];
+   if (attrs[L2TP_ATTR_UDP_CSUM])
+   p->udp_csum = !!rta_getattr_u8(attrs[L2TP_ATTR_UDP_CSUM]);
+
/*
 * Not fetching from L2TP_ATTR_UDP_ZERO_CSUM6_{T,R}X because the
 * kernel doesn't send it so just leave it as default value.
-- 
2.10.2

[PATCH iproute2 v2 9/9] man: ip-l2tp.8: document UDP checksum options

[Asbjørn Sloth Tønnesen]

Signed-off-by: Asbjørn Sloth Tønnesen 
---
 man/man8/ip-l2tp.8 | 33 +
 1 file changed, 33 insertions(+)

diff --git a/man/man8/ip-l2tp.8 b/man/man8/ip-l2tp.8
index d4e7270..8ce630a 100644
--- a/man/man8/ip-l2tp.8
+++ b/man/man8/ip-l2tp.8
@@ -30,6 +30,12 @@ ip-l2tp - L2TPv3 static unmanaged tunnel configuration
 .IR PORT
 .RB " ]"
 .br
+.RB "[ " udp_csum " { " on " | " off " } ]"
+.br
+.RB "[ " udp6_csum_tx " { " on " | " off " } ]"
+.br
+.RB "[ " udp6_csum_rx " { " on " | " off " } ]"
+.br
 .ti -8
 .BR "ip l2tp add session"
 .RB "[ " name
@@ -190,6 +196,33 @@ selected.
 set the UDP destination port to be used for the tunnel. Must be
 present when udp encapsulation is selected. Ignored when ip
 encapsulation is selected.
+.TP
+.BI udp_csum " STATE"
+(IPv4 only) control if IPv4 UDP checksums should be calculated and checked for 
the
+encapsulating UDP packets, when UDP encapsulating is selected.
+Default is
+.BR off "."
+.br
+Valid values are:
+.BR on ", " off "."
+.TP
+.BI udp6_csum_tx " STATE"
+(IPv6 only) control if IPv6 UDP checksums should be calculated for 
encapsulating
+UDP packets, when UDP encapsulating is selected.
+Default is
+.BR on "."
+.br
+Valid values are:
+.BR on ", " off "."
+.TP
+.BI udp6_csum_rx " STATE"
+(IPv6 only) control if IPv6 UDP checksums should be checked for the 
encapsulating
+UDP packets, when UDP encapsulating is selected.
+Default is
+.BR on "."
+.br
+Valid values are:
+.BR on ", " off "."
 .SS ip l2tp del tunnel - destroy a tunnel
 .TP
 .BI tunnel_id " ID"
-- 
2.10.2

[PATCH iproute2 v2 2/9] man: ip-l2tp.8: remove non-existent tunnel parameter name

[Asbjørn Sloth Tønnesen]

The name parameter is only valid for sessions, not tunnels.

Signed-off-by: Asbjørn Sloth Tønnesen 
---
 man/man8/ip-l2tp.8 | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/man/man8/ip-l2tp.8 b/man/man8/ip-l2tp.8
index 4a3bb20..991d097 100644
--- a/man/man8/ip-l2tp.8
+++ b/man/man8/ip-l2tp.8
@@ -154,9 +154,6 @@ tunnels and sessions to be established and provides for 
detecting and
 acting upon network failures.
 .SS ip l2tp add tunnel - add a new tunnel
 .TP
-.BI name " NAME "
-sets the session network interface name. Default is l2tpethN.
-.TP
 .BI tunnel_id " ID"
 set the tunnel id, which is a 32-bit integer value. Uniquely
 identifies the tunnel. The value used must match the peer_tunnel_id
-- 
2.10.2

[PATCH iproute2 v2 1/9] man: ip-l2tp.8: fix l2spec_type documentation

[Asbjørn Sloth Tønnesen]

Signed-off-by: Asbjørn Sloth Tønnesen 
---
 man/man8/ip-l2tp.8 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/man/man8/ip-l2tp.8 b/man/man8/ip-l2tp.8
index 5b7041f..4a3bb20 100644
--- a/man/man8/ip-l2tp.8
+++ b/man/man8/ip-l2tp.8
@@ -239,7 +239,7 @@ find in received L2TP packets. Default is to use no cookie.
 set the layer2specific header type of the session.
 .br
 Valid values are:
-.BR none ", " udp "."
+.BR none ", " default "."
 .TP
 .BI offset " OFFSET"
 sets the byte offset from the L2TP header where user data starts in
-- 
2.10.2

Re: Netperf UDP issue with connected sockets

[Jesper Dangaard Brouer]

On Wed, 16 Nov 2016 09:46:37 -0800
Rick Jones  wrote:

> On 11/16/2016 04:16 AM, Jesper Dangaard Brouer wrote:
> > [1] Subj: High perf top ip_idents_reserve doing netperf UDP_STREAM
> >  - https://www.spinics.net/lists/netdev/msg294752.html
> >
> > Not fixed in version 2.7.0.
> >  - ftp://ftp.netperf.org/netperf/netperf-2.7.0.tar.gz
> >
> > Used extra netperf configure compile options:
> >  ./configure  --enable-histogram --enable-demo
> >
> > It seems like some fix attempts exists in the SVN repository::
> >
> >  svn checkout http://www.netperf.org/svn/netperf2/trunk/ netperf2-svn
> >  svn log -r709
> >  # A quick stab at getting remote connect going for UDP_STREAM
> >  svn diff -r708:709
> >
> > Testing with SVN version, still show __ip_select_ident() in top#1.  
> 
> Indeed, there was a fix for getting the remote side connect()ed. 
> Looking at what I have for the top of trunk I do though see a connect() 
> call being made at the local end:
> 
> socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4
> getsockopt(4, SOL_SOCKET, SO_SNDBUF, [212992], [4]) = 0
> getsockopt(4, SOL_SOCKET, SO_RCVBUF, [212992], [4]) = 0
> setsockopt(4, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
> bind(4, {sa_family=AF_INET, sin_port=htons(0), 
> sin_addr=inet_addr("0.0.0.0")}, 16) = 0
> setsockopt(4, SOL_SOCKET, SO_DONTROUTE, [1], 4) = 0
> setsockopt(4, SOL_IP, IP_RECVERR, [1], 4) = 0
> brk(0xe53000)   = 0xe53000
> getsockname(4, {sa_family=AF_INET, sin_port=htons(59758), 
> sin_addr=inet_addr("0.0.0.0")}, [16]) = 0
> sendto(3, 
> "\0\0\0a\377\377\377\377\377\377\377\377\377\377\377\377\0\0\0\10\0\0\0\0\0\0\0\321\377\377\377\377"...,
>  
> 656, 0, NULL, 0) = 656
> select(1024, [3], NULL, NULL, {120, 0}) = 1 (in [3], left {119, 995630})
> recvfrom(3, 
> "\0\0\0b\0\0\0\0\0\3@\0\0\3@\0\0\0\0\2\0\3@\0\377\377\377\377\0\0\0\321"..., 
> 656, 0, NULL, NULL) = 656
> write(1, "need to connect is 1\n", 21)  = 21
> rt_sigaction(SIGALRM, {0x402ea6, [ALRM], SA_RESTORER|SA_INTERRUPT, 
> 0x7f2824eb2cb0}, NULL, 8) = 0
> rt_sigaction(SIGINT, {0x402ea6, [INT], SA_RESTORER|SA_INTERRUPT, 
> 0x7f2824eb2cb0}, NULL, 8) = 0
> alarm(1)= 0
> connect(4, {sa_family=AF_INET, sin_port=htons(34832), 
> sin_addr=inet_addr("127.0.0.1")}, 16) = 0
> sendto(4, "netperf\0netperf\0netperf\0netperf\0"..., 1024, 0, NULL, 0) = 
> 1024
> sendto(4, "netperf\0netperf\0netperf\0netperf\0"..., 1024, 0, NULL, 0) = 
> 1024
> sendto(4, "netperf\0netperf\0netperf\0netperf\0"..., 1024, 0, NULL, 0) = 
> 1024
> 
> the only difference there with top of trunk is that "need to connect" 
> write/printf I just put in the code to be a nice marker in the system 
> call trace.
> 
> It is a wild guess, but does setting SO_DONTROUTE affect whether or not 
> a connect() would have the desired effect?  That is there to protect 
> people from themselves (long story about people using UDP_STREAM to 
> stress improperly air-gapped systems during link up/down testing) 
> It can be disabled with a test-specific -R 1 option, so your netperf 
> command would become:
> 
> netperf -H 198.18.50.1 -t UDP_STREAM -l 120 -- -m 1472 -n -N -R 1

Using -R 1 does not seem to help remove __ip_select_ident()

Samples: 56K of event 'cycles', Event count (approx.): 78628132661
  Overhead  CommandShared ObjectSymbol
+9.11%  netperf[kernel.vmlinux] [k] __ip_select_ident
+6.98%  netperf[kernel.vmlinux] [k] _raw_spin_lock
+6.21%  swapper[mlx5_core]  [k] mlx5e_poll_tx_cq
+5.03%  netperf[kernel.vmlinux] [k] 
copy_user_enhanced_fast_string
+4.69%  netperf[kernel.vmlinux] [k] __ip_make_skb
+4.63%  netperf[kernel.vmlinux] [k] skb_set_owner_w
+4.15%  swapper[kernel.vmlinux] [k] __slab_free
+3.80%  netperf[mlx5_core]  [k] mlx5e_sq_xmit
+2.00%  swapper[kernel.vmlinux] [k] sock_wfree
+1.94%  netperfnetperf  [.] send_data
+1.92%  netperfnetperf  [.] send_omni_inner


> >
> > (p.s. is netperf ever going to be converted from SVN to git?)
> >  
> 
> Well  my git-fu could use some work (gentle, offlinetaps with a 
> clueful tutorial bat would be welcome), and at least in the past, going 
> to git was held back because there were a bunch of netperf users on 
> Windows and there wasn't (at the time) support for git under Windows.
> 
> But I am not against the idea in principle.

Once you have learned git, you will never go back to SVN. Just do it! :-)

Here are even nice writeups of how to convert and preserve history:
 http://john.albin.net/git/convert-subversion-to-git

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  Author of http://www.iptv-analyzer.org
  LinkedIn: http://www.linkedin.com/in/brouer

[PATCH iproute2 1/1] tc: distinguish Add/Replace filter operations

[Roman Mashak]

Signed-off-by: Roman Mashak 
Signed-off-by: Jamal Hadi Salim 
---
 tc/tc_filter.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/tc/tc_filter.c b/tc/tc_filter.c
index 932677a..ff8713b 100644
--- a/tc/tc_filter.c
+++ b/tc/tc_filter.c
@@ -226,6 +226,16 @@ int print_filter(const struct sockaddr_nl *who, struct 
nlmsghdr *n, void *arg)
if (n->nlmsg_type == RTM_DELTFILTER)
fprintf(fp, "deleted ");
 
+   if (n->nlmsg_type == RTM_NEWTFILTER &&
+   (n->nlmsg_flags & NLM_F_CREATE) &&
+   !(n->nlmsg_flags & NLM_F_EXCL))
+   fprintf(fp, "replaced ");
+
+   if (n->nlmsg_type == RTM_NEWTFILTER &&
+   (n->nlmsg_flags & NLM_F_CREATE) &&
+   (n->nlmsg_flags & NLM_F_EXCL))
+   fprintf(fp, "added ");
+
fprintf(fp, "filter ");
if (!filter_ifindex || filter_ifindex != t->tcm_ifindex)
fprintf(fp, "dev %s ", ll_index_to_name(t->tcm_ifindex));
-- 
1.9.1

[PATCH net 1/1] net sched filters: pass netlink message flags in event notification

[Roman Mashak]

Userland client should be able to read an event, and reflect it back to
the kernel, therefore it needs to extract complete set of netlink flags.

For example, this will allow "tc monitor" to distinguish Add and Replace
operations.

Signed-off-by: Roman Mashak 
Signed-off-by: Jamal Hadi Salim 
---
 net/sched/cls_api.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
index 2b2a797..8e93d4a 100644
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@ -112,7 +112,7 @@ static void tfilter_notify_chain(struct net *net, struct 
sk_buff *oskb,
 
for (it_chain = chain; (tp = rtnl_dereference(*it_chain)) != NULL;
 it_chain = >next)
-   tfilter_notify(net, oskb, n, tp, 0, event, false);
+   tfilter_notify(net, oskb, n, tp, n->nlmsg_flags, event, false);
 }
 
 /* Select new prio value from the range, managed by kernel. */
@@ -430,7 +430,8 @@ static int tfilter_notify(struct net *net, struct sk_buff 
*oskb,
if (!skb)
return -ENOBUFS;
 
-   if (tcf_fill_node(net, skb, tp, fh, portid, n->nlmsg_seq, 0, event) <= 
0) {
+   if (tcf_fill_node(net, skb, tp, fh, portid, n->nlmsg_seq,
+ n->nlmsg_flags, event) <= 0) {
kfree_skb(skb);
return -EINVAL;
}
-- 
1.9.1

Re: [PATCH net] cxgb4: do not call napi_hash_del()

[David Miller]

From: Eric Dumazet 
Date: Wed, 16 Nov 2016 06:19:02 -0800

> From: Eric Dumazet 
> 
> Calling napi_hash_del() before netif_napi_del() is dangerous
> if a synchronize_rcu() is not enforced before NAPI struct freeing.
> 
> Lets leave this detail to core networking stack and feel
> more comfortable.
> 
> Signed-off-by: Eric Dumazet 

Applied.

Re: [PATCH net] be2net: do not call napi_hash_del()

[David Miller]

From: Eric Dumazet 
Date: Wed, 16 Nov 2016 06:12:42 -0800

> From: Eric Dumazet 
> 
> Calling napi_hash_del() before netif_napi_del() is dangerous
> if a synchronize_rcu() is not enforced before NAPI struct freeing.
> 
> Lets leave this detail to core networking stack and feel
> more comfortable.
> 
> Signed-off-by: Eric Dumazet 

Applied.

Re: [PATCH] netronome: don't access real_num_rx_queues directly

[David Miller]

From: Arnd Bergmann 
Date: Wed, 16 Nov 2016 15:10:49 +0100

> The netdev->real_num_rx_queues setting is only available if CONFIG_SYSFS
> is enabled, so we now get a build failure when that is turned off:
> 
> netronome/nfp/nfp_net_common.c: In function 'nfp_net_ring_swap_enable':
> netronome/nfp/nfp_net_common.c:2489:18: error: 'struct net_device' has no 
> member named 'real_num_rx_queues'; did you mean 'real_num_tx_queues'?
> 
> As far as I can tell, the check here is only used as an optimization that
> we can skip in order to fix the compilation. If sysfs is disabled,
> the following netif_set_real_num_rx_queues() has no effect.
> 
> Fixes: 164d1e9e5d52 ("nfp: add support for ethtool .set_channels")
> Signed-off-by: Arnd Bergmann 

Applied, thanks.

Re: [PATCH net-next] sfc: remove napi_hash_del() call

[David Miller]

From: Eric Dumazet 
Date: Wed, 16 Nov 2016 06:01:47 -0800

> From: Eric Dumazet 
> 
> Calling napi_hash_del() after netif_napi_del() is pointless.
> 
> Signed-off-by: Eric Dumazet 

Applied.

Re: [PATCH net-next] lwtunnel: subtract tunnel headroom from mtu on output redirect

[David Miller]

From: David Lebrun 
Date: Wed, 16 Nov 2016 10:05:46 +0100

> This patch changes the lwtunnel_headroom() function which is called
> in ipv4_mtu() and ip6_mtu(), to also return the correct headroom
> value when the lwtunnel state is OUTPUT_REDIRECT.
> 
> This patch enables e.g. SR-IPv6 encapsulations to work without
> manually setting the route mtu.
> 
> Acked-by: Roopa Prabhu 
> Signed-off-by: David Lebrun 

Applied, thanks David.

[PATCH net-next 2/3] RDS: TCP: Track peer's connection generation number

[Sowmini Varadhan]

The RDS transport has to be able to distinguish between
two types of failure events:
(a) when the transport fails (e.g., TCP connection reset)
but the RDS socket/connection layer on both sides stays
the same
(b) when the peer's RDS layer itself resets (e.g., due to module
reload or machine reboot at the peer)
In case (a) both sides must reconnect and continue the RDS messaging
without any message loss or disruption to the message sequence numbers,
and this is achieved by rds_send_path_reset().

In case (b) we should reset all rds_connection state to the
new incarnation of the peer. Examples of state that needs to
be reset are next expected rx sequence number from, or messages to be
retransmitted to, the new incarnation of the peer.

To achieve this, the RDS handshake probe added as part of
commit 5916e2c1554f ("RDS: TCP: Enable multipath RDS for TCP")
is enhanced so that sender and receiver of the RDS ping-probe
will add a generation number as part of the RDS_EXTHDR_GEN_NUM
extension header. Each peer stores local and remote generation
numbers as part of each rds_connection. Changes in generation
number will be detected via incoming handshake probe ping
request or response and will allow the receiver to reset rds_connection
state.

Signed-off-by: Sowmini Varadhan 
Acked-by: Santosh Shilimkar 
---
 net/rds/af_rds.c |4 
 net/rds/connection.c |2 ++
 net/rds/message.c|1 +
 net/rds/rds.h|8 +++-
 net/rds/recv.c   |   36 
 net/rds/send.c   |9 +++--
 6 files changed, 57 insertions(+), 3 deletions(-)

diff --git a/net/rds/af_rds.c b/net/rds/af_rds.c
index 6beaeb1..2ac1e61 100644
--- a/net/rds/af_rds.c
+++ b/net/rds/af_rds.c
@@ -605,10 +605,14 @@ static void rds_exit(void)
 }
 module_exit(rds_exit);
 
+u32 rds_gen_num;
+
 static int rds_init(void)
 {
int ret;
 
+   net_get_random_once(_gen_num, sizeof(rds_gen_num));
+
ret = rds_bind_lock_init();
if (ret)
goto out;
diff --git a/net/rds/connection.c b/net/rds/connection.c
index 13f459d..b86e188 100644
--- a/net/rds/connection.c
+++ b/net/rds/connection.c
@@ -269,6 +269,8 @@ static void __rds_conn_path_init(struct rds_connection 
*conn,
kmem_cache_free(rds_conn_slab, conn);
conn = found;
} else {
+   conn->c_my_gen_num = rds_gen_num;
+   conn->c_peer_gen_num = 0;
hlist_add_head_rcu(>c_hash_node, head);
rds_cong_add_conn(conn);
rds_conn_count++;
diff --git a/net/rds/message.c b/net/rds/message.c
index 6cb9106..49bfb51 100644
--- a/net/rds/message.c
+++ b/net/rds/message.c
@@ -42,6 +42,7 @@
 [RDS_EXTHDR_RDMA]  = sizeof(struct rds_ext_header_rdma),
 [RDS_EXTHDR_RDMA_DEST] = sizeof(struct rds_ext_header_rdma_dest),
 [RDS_EXTHDR_NPATHS]= sizeof(u16),
+[RDS_EXTHDR_GEN_NUM]   = sizeof(u32),
 };
 
 
diff --git a/net/rds/rds.h b/net/rds/rds.h
index 4121e18..ebbf909 100644
--- a/net/rds/rds.h
+++ b/net/rds/rds.h
@@ -151,6 +151,9 @@ struct rds_connection {
 
struct rds_conn_pathc_path[RDS_MPATH_WORKERS];
wait_queue_head_t   c_hs_waitq; /* handshake waitq */
+
+   u32 c_my_gen_num;
+   u32 c_peer_gen_num;
 };
 
 static inline
@@ -243,7 +246,8 @@ struct rds_ext_header_rdma_dest {
 /* Extension header announcing number of paths.
  * Implicit length = 2 bytes.
  */
-#define RDS_EXTHDR_NPATHS  4
+#define RDS_EXTHDR_NPATHS  5
+#define RDS_EXTHDR_GEN_NUM 6
 
 #define __RDS_EXTHDR_MAX   16 /* for now */
 
@@ -338,6 +342,7 @@ static inline u32 rds_rdma_cookie_offset(rds_rdma_cookie_t 
cookie)
 #define RDS_MSG_RETRANSMITTED  5
 #define RDS_MSG_MAPPED 6
 #define RDS_MSG_PAGEVEC7
+#define RDS_MSG_FLUSH  8
 
 struct rds_message {
atomic_tm_refcount;
@@ -664,6 +669,7 @@ static inline void __rds_wake_sk_sleep(struct sock *sk)
 struct rds_message *rds_cong_update_alloc(struct rds_connection *conn);
 
 /* conn.c */
+extern u32 rds_gen_num;
 int rds_conn_init(void);
 void rds_conn_exit(void);
 struct rds_connection *rds_conn_create(struct net *net,
diff --git a/net/rds/recv.c b/net/rds/recv.c
index cbfabdf..9d0666e 100644
--- a/net/rds/recv.c
+++ b/net/rds/recv.c
@@ -120,6 +120,36 @@ static void rds_recv_rcvbuf_delta(struct rds_sock *rs, 
struct sock *sk,
/* do nothing if no change in cong state */
 }
 
+static void rds_conn_peer_gen_update(struct rds_connection *conn,
+u32 peer_gen_num)
+{
+   int i;
+   struct rds_message *rm, *tmp;
+   unsigned long flags;
+
+   WARN_ON(conn->c_trans->t_type != RDS_TRANS_TCP);
+   if (peer_gen_num != 0) {
+   if (conn->c_peer_gen_num != 0 &&
+   

[PATCH net-next 3/3] RDS: TCP: Force every connection to be initiated by numerically smaller IP address

[Sowmini Varadhan]

When 2 RDS peers initiate an RDS-TCP connection simultaneously,
there is a potential for "duelling syns" on either/both sides.
See commit 241b271952eb ("RDS-TCP: Reset tcp callbacks if re-using an
outgoing socket in rds_tcp_accept_one()") for a description of this
condition, and the arbitration logic which ensures that the
numerically large IP address in the TCP connection is bound to the
RDS_TCP_PORT ("canonical ordering").

The rds_connection should not be marked as RDS_CONN_UP until the
arbitration logic has converged for the following reason. The sender
may start transmitting RDS datagrams as soon as RDS_CONN_UP is set,
and since the sender removes all datagrams from the rds_connection's
cp_retrans queue based on TCP acks. If the TCP ack was sent from
a tcp socket that got reset as part of duel aribitration (but
before data was delivered to the receivers RDS socket layer),
the sender may end up prematurely freeing the datagram, and
the datagram is no longer reliably deliverable.

This patch remedies that condition by making sure that, upon
receipt of 3WH completion state change notification of TCP_ESTABLISHED
in rds_tcp_state_change, we mark the rds_connection as RDS_CONN_UP
if, and only if, the IP addresses and ports for the connection are
canonically ordered. In all other cases, rds_tcp_state_change will
force an rds_conn_path_drop(), and rds_queue_reconnect() on
both peers will restart the connection to ensure canonical ordering.

A side-effect of enforcing this condition in rds_tcp_state_change()
is that rds_tcp_accept_one_path() can now be refactored for simplicity.
It is also no longer possible to encounter an RDS_CONN_UP connection in
the arbitration logic in rds_tcp_accept_one().

Signed-off-by: Sowmini Varadhan 
Acked-by: Santosh Shilimkar 
---
 net/rds/connection.c  |1 +
 net/rds/tcp_connect.c |   14 +-
 net/rds/tcp_listen.c  |   29 -
 3 files changed, 26 insertions(+), 18 deletions(-)

diff --git a/net/rds/connection.c b/net/rds/connection.c
index b86e188..fe9d31c 100644
--- a/net/rds/connection.c
+++ b/net/rds/connection.c
@@ -683,6 +683,7 @@ void rds_conn_path_connect_if_down(struct rds_conn_path *cp)
!test_and_set_bit(RDS_RECONNECT_PENDING, >cp_flags))
queue_delayed_work(rds_wq, >cp_conn_w, 0);
 }
+EXPORT_SYMBOL_GPL(rds_conn_path_connect_if_down);
 
 void rds_conn_connect_if_down(struct rds_connection *conn)
 {
diff --git a/net/rds/tcp_connect.c b/net/rds/tcp_connect.c
index 05f61c5..d6839d9 100644
--- a/net/rds/tcp_connect.c
+++ b/net/rds/tcp_connect.c
@@ -60,7 +60,19 @@ void rds_tcp_state_change(struct sock *sk)
case TCP_SYN_RECV:
break;
case TCP_ESTABLISHED:
-   rds_connect_path_complete(cp, RDS_CONN_CONNECTING);
+   /* Force the peer to reconnect so that we have the
+* TCP ports going from . to
+* .. We avoid marking the
+* RDS connection as RDS_CONN_UP until the reconnect,
+* to avoid RDS datagram loss.
+*/
+   if (cp->cp_conn->c_laddr > cp->cp_conn->c_faddr &&
+   rds_conn_path_transition(cp, RDS_CONN_CONNECTING,
+RDS_CONN_ERROR)) {
+   rds_conn_path_drop(cp);
+   } else {
+   rds_connect_path_complete(cp, RDS_CONN_CONNECTING);
+   }
break;
case TCP_CLOSE_WAIT:
case TCP_CLOSE:
diff --git a/net/rds/tcp_listen.c b/net/rds/tcp_listen.c
index c9c4968..f74bab3 100644
--- a/net/rds/tcp_listen.c
+++ b/net/rds/tcp_listen.c
@@ -83,25 +83,20 @@ struct rds_tcp_connection *rds_tcp_accept_one_path(struct 
rds_connection *conn)
 {
int i;
bool peer_is_smaller = (conn->c_faddr < conn->c_laddr);
-   int npaths = conn->c_npaths;
-
-   if (npaths <= 1) {
-   struct rds_conn_path *cp = >c_path[0];
-   int ret;
-
-   ret = rds_conn_path_transition(cp, RDS_CONN_DOWN,
-  RDS_CONN_CONNECTING);
-   if (!ret)
-   rds_conn_path_transition(cp, RDS_CONN_ERROR,
-RDS_CONN_CONNECTING);
-   return cp->cp_transport_data;
-   }
+   int npaths = max_t(int, 1, conn->c_npaths);
 
-   /* for mprds, paths with cp_index > 0 MUST be initiated by the peer
+   /* for mprds, all paths MUST be initiated by the peer
 * with the smaller address.
 */
-   if (!peer_is_smaller)
+   if (!peer_is_smaller) {
+   /* Make sure we initiate at least one path if this
+* has not already been done; rds_start_mprds() will
+* take care of additional paths, if necessary.
+*/
+   if (npaths == 1)
+

[PATCH net-next 1/3] RDS: TCP: set RDS_FLAG_RETRANSMITTED in cp_retrans list

[Sowmini Varadhan]

As noted in rds_recv_incoming() sequence numbers on data packets
can decreas for the failover case, and the Rx path is equipped
to recover from this, if the RDS_FLAG_RETRANSMITTED is set
on the rds header of an incoming message with a suspect sequence
number.

The RDS_FLAG_RETRANSMITTED is predicated on the RDS_FLAG_RETRANSMITTED
flag in the rds_message, so make sure the flag is set on messages
queued for retransmission.

Signed-off-by: Sowmini Varadhan 
Acked-by: Santosh Shilimkar 
---
 net/rds/tcp_send.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/net/rds/tcp_send.c b/net/rds/tcp_send.c
index 89d09b4..dcf4742 100644
--- a/net/rds/tcp_send.c
+++ b/net/rds/tcp_send.c
@@ -100,6 +100,9 @@ int rds_tcp_xmit(struct rds_connection *conn, struct 
rds_message *rm,
set_bit(RDS_MSG_HAS_ACK_SEQ, >m_flags);
tc->t_last_expected_una = rm->m_ack_seq + 1;
 
+   if (test_bit(RDS_MSG_RETRANSMITTED, >m_flags))
+   rm->m_inc.i_hdr.h_flags |= RDS_FLAG_RETRANSMITTED;
+
rdsdebug("rm %p tcp nxt %u ack_seq %llu\n",
 rm, rds_tcp_snd_nxt(tc),
 (unsigned long long)rm->m_ack_seq);
-- 
1.7.1

[PATCH net-next 0/3] RDS: TCP: HA/Failover fixes

[Sowmini Varadhan]

This series contains a set of fixes for bugs exposed when
we ran the following in a loop between a test machine pair:

 while (1); do
   # modprobe rds-tcp on test nodes
   # run rds-stress in bi-dir mode between test machine pair 
   # modprobe -r rds-tcp on test nodes
 done

rds-stress in bi-dir mode will cause both nodes to initiate
RDS-TCP connections at almost the same instant, exposing the 
bugs fixed in this series. 

Without the fixes, rds-stress reports sporadic packet drops,
and packets arriving out of sequence. After the fixes,we have
been able to run the  test overnight, without any issues.

Each patch has a detailed description of the root-cause fixed
by the patch.


Sowmini Varadhan (3):
  RDS: TCP: set RDS_FLAG_RETRANSMITTED in cp_retrans list
  RDS: TCP: Track peer's connection generation number
  RDS: TCP: Force every connection to be initiated by numerically
smaller IP address

 net/rds/af_rds.c  |4 
 net/rds/connection.c  |3 +++
 net/rds/message.c |1 +
 net/rds/rds.h |8 +++-
 net/rds/recv.c|   36 
 net/rds/send.c|9 +++--
 net/rds/tcp_connect.c |   14 +-
 net/rds/tcp_listen.c  |   29 -
 net/rds/tcp_send.c|3 +++
 9 files changed, 86 insertions(+), 21 deletions(-)

Re: [PATCH] rtl8xxxu: Fix for agressive power saving by rtl8723bu wireless IC

[Jes Sorensen]

John Heenan  writes:
> Barry Day has submitted real world reports for the 8192eu and 8192cu.
> This needs to be acknowledged. I have submitted real world reports for
> the 8723bu.

Lets get this a little more clear - first of all, I have asked you to
investigate which part resolves the problem. Rather than 'I randomly
moved something around and it happens to work for me'.

> When it comes down to it, it looks like the kernel code changes are
> really going to be very trivial to fix this problem and we need to
> take the focus off dramatic outbursts over style issues to a strategy
> for getting usable results from real world testing.
>
> Addressing style issues in a dramatic manner to me looks like a mean
> sport for maintainers who line up to easy target first time
> contributors. This mean attitude comes from the top with a well known
> comment about "publicly making fun of people". The polite comments
> over style from Joe Perches and Rafał Miłecki are welcomed.

Once bad code is in place, it is way harder to get rid of it again. It
is *normal* for maintainers to ask contributors to do things
correctly. In addition you have been asked repeatedly by multiple people
to respect coding style, but every patch you posted violated it again in
a different way, instead of spending the little time it would take for
you to get it right.

> An effective strategy would be to insert some printk statements to
> trace what init steps vendor derived drivers do each time
> wpa_supplicant is called and ask real world testers to report their
> results. This is a lot more productive and less error prone than
> laboriously pouring over vendor source code. Alternative drivers that
> use vendor code from Realtek is enormously complicated and a huge pain
> to make sense of.
>
> Joe Sorensen's driver code is far easier to make sense of and it is a
> shame Realtek don't come to the party. Joe Sorensens's code take takes
> advantage of the excellent work of kernel contributors to the mac80211
> driver.

Now you are pissing on my name - do you really want to be taken
seriously here?

> Previous comments I made about enable_rf, rtl8xxxu_start,
> rtl8xxxu_init_device etc should be clarified. I will leave it for the
> moment as it currently serves no direct useful purpose.

I have made it very clear I want this issue resolved, but I want it
done right.

Jes

Re: net/l2tp:BUG: KASAN: use-after-free in l2tp_ip6_close

[Guillaume Nault]

On Wed, Nov 16, 2016 at 11:08:23AM -0800, Cong Wang wrote:
> On Wed, Nov 16, 2016 at 8:30 AM, Guillaume Nault  wrote:
> > diff --git a/net/l2tp/l2tp_ip.c b/net/l2tp/l2tp_ip.c
> > index fce25af..982f6c4 100644
> > --- a/net/l2tp/l2tp_ip.c
> > +++ b/net/l2tp/l2tp_ip.c
> > @@ -251,8 +251,6 @@ static int l2tp_ip_bind(struct sock *sk, struct 
> > sockaddr *uaddr, int addr_len)
> > int ret;
> > int chk_addr_ret;
> >
> > -   if (!sock_flag(sk, SOCK_ZAPPED))
> > -   return -EINVAL;
> > if (addr_len < sizeof(struct sockaddr_l2tpip))
> > return -EINVAL;
> > if (addr->l2tp_family != AF_INET)
> > @@ -267,6 +265,9 @@ static int l2tp_ip_bind(struct sock *sk, struct 
> > sockaddr *uaddr, int addr_len)
> > read_unlock_bh(_ip_lock);
> >
> > lock_sock(sk);
> > +   if (!sock_flag(sk, SOCK_ZAPPED))
> > +   goto out;
> > +
> > if (sk->sk_state != TCP_CLOSE || addr_len < sizeof(struct 
> > sockaddr_l2tpip))
> > goto out;
> >
> > diff --git a/net/l2tp/l2tp_ip6.c b/net/l2tp/l2tp_ip6.c
> > index ad3468c..9978d01 100644
> > --- a/net/l2tp/l2tp_ip6.c
> > +++ b/net/l2tp/l2tp_ip6.c
> > @@ -269,8 +269,6 @@ static int l2tp_ip6_bind(struct sock *sk, struct 
> > sockaddr *uaddr, int addr_len)
> > int addr_type;
> > int err;
> >
> > -   if (!sock_flag(sk, SOCK_ZAPPED))
> > -   return -EINVAL;
> > if (addr->l2tp_family != AF_INET6)
> > return -EINVAL;
> > if (addr_len < sizeof(*addr))
> > @@ -296,6 +294,9 @@ static int l2tp_ip6_bind(struct sock *sk, struct 
> > sockaddr *uaddr, int addr_len)
> > lock_sock(sk);
> >
> > err = -EINVAL;
> > +   if (!sock_flag(sk, SOCK_ZAPPED))
> > +   goto out_unlock;
> > +
> > if (sk->sk_state != TCP_CLOSE)
> > goto out_unlock;
> 
> 
> Makes sense, it should prevent a concurrent caller adding the socket
> into bind table
> twice after passing __l2tp_ip_bind_lookup() check.

Yes, and the __l2tp_ip_bind_lookup() call is also racy. But, by
properly checking the SOCK_ZAPPED flag, we probably can remove this
call entirely.

For now, I only wanted to make sure the issue was well identified. I'll
submit a more complete patch for net (with protected SOCK_ZAPPED check
in l2tp_ip_connect() too).

Re: [patch net-next 6/8] ipv4: fib: Add an API to request a FIB dump

[Ido Schimmel]

On Wed, Nov 16, 2016 at 08:43:25PM +0100, Hannes Frederic Sowa wrote:
> On 16.11.2016 19:51, Ido Schimmel wrote:
> > On Wed, Nov 16, 2016 at 06:35:45PM +0100, Hannes Frederic Sowa wrote:
> >> On 16.11.2016 16:18, Ido Schimmel wrote:
> >>> On Wed, Nov 16, 2016 at 03:51:01PM +0100, Hannes Frederic Sowa wrote:
>  On 16.11.2016 15:09, Jiri Pirko wrote:
> > From: Ido Schimmel 
> >
> > Commit b90eb7549499 ("fib: introduce FIB notification infrastructure")
> > introduced a new notification chain to notify listeners (f.e., switchdev
> > drivers) about addition and deletion of routes.
> >
> > However, upon registration to the chain the FIB tables can already be
> > populated, which means potential listeners will have an incomplete view
> > of the tables.
> >
> > Solve that by adding an API to request a FIB dump. The dump itself it
> > done using RCU in order not to starve consumers that need RTNL to make
> > progress.
> >
> > Signed-off-by: Ido Schimmel 
> > Signed-off-by: Jiri Pirko 
> 
>  Have you looked at potential inconsistencies resulting of RCU walking
>  the table and having concurrent inserts?
> >>>
> >>> Yes. I did try to think about situations in which this approach will
> >>> fail, but I could only find problems with concurrent removals, which I
> >>> addressed in 5/8. In case of concurrent insertions, even if you missed
> >>> the node, you would still get the ENTRY_ADD event to your listener.
> >>
> >> Theoretically a node could still be installed while the deletion event
> >> fired before registering the notifier. E.g. a synchronize_net before
> >> dumping could help here?
> > 
> > If the deletion event fired for some fib alias, then by 5/8 we are
> > guaranteed that it was already unlinked from the fib alias list in the
> > leaf in which it was contained. So, while it's possible we didn't
> > register our listener in time for the deletion event, we won't traverse
> > this fib alias while dumping the trie anyway. Did I understand you
> > correctly?
> > 
> 
> Theoretically we can have the same problem for insertion:
> 
> You receive a delete event from the notifier that is queued up first but
> the dump will still see the entry in the fib due to being managed by RCU
> (the notifier running on another CPU).
> 
> The problem is that the fib_remove_alias->hlist_del_rcu->WRITE_ONCE is
> still not strongly ordered against the local fib dump trie walk.

It's pretty late here so I would have to check this out tomorrow
morning. If this is indeed the case (not saying you're wrong, just want
to verify for myself), then I guess 5/8 can be dropped and instead we
should go with Dave's suggestion? I don't see any other way given the
constraints...

Thanks a lot Hannes!

HELLO

[Wilfred Kabore]

Dear Friend,

Greetings and hope this mail meets you well!

I want you to be my partner in the transfer of the sum of $6.7 Million dollars 
discovered in my  department in one of the leading Banks (EcoBank Plc) here in 
Burkina-Faso. I shall give you more information on this proposal when I get 
your reply, but rest assured that I will give you 40%  of the total sum once 
the transfer is completed but you have to maintain secrecy of this business 
deal if you are ready to work with me.

God bless you as I wait for your response.

Dr. Kabore Wilfred

Re: [PATCH net 1/7] net: ethernet: ti: cpsw: fix bad register access in probe error path

[Grygorii Strashko]

On 11/16/2016 08:35 AM, Johan Hovold wrote:
> Make sure to resume the platform device to enable clocks before
> accessing the CPSW registers in the probe error path (e.g. for deferred
> probe).
> 
> Unhandled fault: external abort on non-linefetch (0x1008) at 0xd0872d08
> ...
> [] (cpsw_ale_control_set) from [] 
> (cpsw_ale_destroy+0x2c/0x44)
> [] (cpsw_ale_destroy) from [] (cpsw_probe+0xbd0/0x10c4)
> [] (cpsw_probe) from [] (platform_drv_probe+0x5c/0xc0)
> 
> Note that in the unlikely event of a runtime-resume failure, we'll leak
> the ale struct.
> 
> Fixes: df828598a755 ("netdev: driver: ethernet: Add TI CPSW driver")
> Signed-off-by: Johan Hovold 
> ---
>  drivers/net/ethernet/ti/cpsw.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
> index c6cff3d2ff05..5bc5e6189661 100644
> --- a/drivers/net/ethernet/ti/cpsw.c
> +++ b/drivers/net/ethernet/ti/cpsw.c
> @@ -2818,7 +2818,12 @@ static int cpsw_probe(struct platform_device *pdev)
>   return 0;
>  
>  clean_ale_ret:
> - cpsw_ale_destroy(cpsw->ale);
> + if (pm_runtime_get_sync(>dev) < 0) {
> + pm_runtime_put_noidle(>dev);
> + } else {
> + cpsw_ale_destroy(cpsw->ale);
> + pm_runtime_put_sync(>dev);
> + }
>  clean_dma_ret:
>   cpdma_ctlr_destroy(cpsw->dma);
>  clean_runtime_disable_ret:
> 

I think, wouldn't it be logically more simple to just keep CPSW PM runtime 
enabled during probe?
Like in below diff (not tested):

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 0548e56..deaac1b 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -2657,13 +2657,12 @@ static int cpsw_probe(struct platform_device *pdev)
goto clean_runtime_disable_ret;
}
cpsw->version = readl(>regs->id_ver);
-   pm_runtime_put_sync(>dev);
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
cpsw->wr_regs = devm_ioremap_resource(>dev, res);
if (IS_ERR(cpsw->wr_regs)) {
ret = PTR_ERR(cpsw->wr_regs);
-   goto clean_runtime_disable_ret;
+   goto clean_runtime_put_ret;
}
 
memset(_params, 0, sizeof(dma_params));
@@ -2700,7 +2699,7 @@ static int cpsw_probe(struct platform_device *pdev)
default:
dev_err(priv->dev, "unknown version 0x%08x\n", cpsw->version);
ret = -ENODEV;
-   goto clean_runtime_disable_ret;
+   goto clean_runtime_put_ret;
}
for (i = 0; i < cpsw->data.slaves; i++) {
struct cpsw_slave *slave = >slaves[i];
@@ -2729,7 +2728,7 @@ static int cpsw_probe(struct platform_device *pdev)
if (!cpsw->dma) {
dev_err(priv->dev, "error initializing dma\n");
ret = -ENOMEM;
-   goto clean_runtime_disable_ret;
+   goto clean_runtime_put_ret;
}
 
cpsw->txch[0] = cpdma_chan_create(cpsw->dma, 0, cpsw_tx_handler, 0);
@@ -2831,12 +2830,16 @@ static int cpsw_probe(struct platform_device *pdev)
}
}
 
+   pm_runtime_put(>dev);
+
return 0;
 
 clean_ale_ret:
cpsw_ale_destroy(cpsw->ale);
 clean_dma_ret:
cpdma_ctlr_destroy(cpsw->dma);
+clean_runtime_put_ret:
+   pm_runtime_put_sync(>dev);
 clean_runtime_disable_ret:
pm_runtime_disable(>dev);
 clean_ndev_ret:

-- 
regards,
-grygorii

Re: [PATCH net][v2] bpf: fix range arithmetic for bpf map access

[Jann Horn]

On Wed, Nov 16, 2016 at 9:25 PM, Josef Bacik  wrote:
> On 11/16/2016 01:41 PM, Jann Horn wrote:
>>
>> On Tue, Nov 15, 2016 at 3:20 PM, Josef Bacik  wrote:
>>>
>>> On 11/15/2016 08:47 AM, Jann Horn wrote:

 In states_equal():
 if (rold->type == NOT_INIT ||
(rold->type == UNKNOWN_VALUE && rcur->type != NOT_INIT))
 <
 continue;

 I think this is broken in code like the following:

 int value;
 if (condition) {
   value = 1; // visited first by verifier
 } else {
   value = 100; // visited second by verifier
 }
 int dummy = 1; // states seem to converge here, but actually don't
 map[value] = 1234;

 `value` would be an UNKNOWN_VALUE for both paths, right? So
 states_equal() would decide that the states converge after the
 conditionally executed code?

>>>
>>> Value would be CONST_IMM for both paths, and wouldn't match so they
>>> wouldn't
>>> converge.  I think I understood your question right, let me know if I'm
>>> addressing the wrong part of it.
>>
>>
>> Okay, true, but what if you load the values from a map and bounds-check
>> them
>> instead of hardcoding them? Then they will be of type UNKNOWN_VALUE,
>> right?
>> Like this:
>>
>> int value = map[0];
>> if (condition) {
>>   value &= 0x1; // visited first by verifier
>> } else {
>>   // nothing; visited second by verifier
>> }
>> int dummy = 1; // states seem to converge here, but actually don't
>> map[value] = 1234;
>>
>> And then `rold->type == UNKNOWN_VALUE && rcur->type != NOT_INIT` will be
>> true in the `dummy = 1` line, and the states converge. Am I missing
>> something?
>>
>
> Ah ok yeah I see it now you are right.  This is slightly different from this
> particular problem so I'll send a second patch to address this, sound
> reasonable?  Thanks,

Sure, makes sense.

Re: [PATCH net][v2] bpf: fix range arithmetic for bpf map access

[Josef Bacik]

On 11/16/2016 01:41 PM, Jann Horn wrote:

On Tue, Nov 15, 2016 at 3:20 PM, Josef Bacik  wrote:

On 11/15/2016 08:47 AM, Jann Horn wrote:

In states_equal():
if (rold->type == NOT_INIT ||
   (rold->type == UNKNOWN_VALUE && rcur->type != NOT_INIT))
<
continue;

I think this is broken in code like the following:

int value;
if (condition) {
  value = 1; // visited first by verifier
} else {
  value = 100; // visited second by verifier
}
int dummy = 1; // states seem to converge here, but actually don't
map[value] = 1234;

`value` would be an UNKNOWN_VALUE for both paths, right? So
states_equal() would decide that the states converge after the
conditionally executed code?



Value would be CONST_IMM for both paths, and wouldn't match so they wouldn't
converge.  I think I understood your question right, let me know if I'm
addressing the wrong part of it.


Okay, true, but what if you load the values from a map and bounds-check them
instead of hardcoding them? Then they will be of type UNKNOWN_VALUE, right?
Like this:

int value = map[0];
if (condition) {
  value &= 0x1; // visited first by verifier
} else {
  // nothing; visited second by verifier
}
int dummy = 1; // states seem to converge here, but actually don't
map[value] = 1234;

And then `rold->type == UNKNOWN_VALUE && rcur->type != NOT_INIT` will be
true in the `dummy = 1` line, and the states converge. Am I missing something?



Ah ok yeah I see it now you are right.  This is slightly different from this 
particular problem so I'll send a second patch to address this, sound 
reasonable?  Thanks,


Josef

Re: [patch net-next] mlxsw: spectrum_router: Adjust placement of FIB abort warning

[David Miller]

From: Jiri Pirko 
Date: Wed, 16 Nov 2016 09:51:58 +0100

> From: Ido Schimmel 
> 
> The recent merge commit bb598c1b8c9b ("Merge
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net") would cause
> the FIB abort warning to fire whenever we flush the FIB tables - either
> during module removal or actual abort.
> 
> Move it back to its rightful location in the FIB abort function.
> 
> Signed-off-by: Ido Schimmel 
> Signed-off-by: Jiri Pirko 

Applied, thanks for fixing this up.

Re: [BUG] X86: Removing inline decl on arch/x86/include/asm/desc.h.

[Eric Dumazet]

On Wed, 2016-11-16 at 20:16 +0100, Thomas Gleixner wrote:
> On Tue, 15 Nov 2016, Corcodel Marian wrote:
> >  Inline declarations suppress warning message from compiler but
> >  most of these functions was declared static and is not used local on file.
> 
> Huch? This is a header file and the functions are marked inline on purpose.
> 
> Can you please explain what you are trying to achieve and why you think
> that this is a good idea?

Corcodel Marian is a bot.
Do not bother Thomas. 
Total Waste of time.

https://www.spinics.net/lists/netdev/msg370788.html

https://www.mail-archive.com/netdev@vger.kernel.org/msg103775.html

Re: [PATCH net] virtio-net: add a missing synchronize_net()

[David Miller]

From: Eric Dumazet 
Date: Tue, 15 Nov 2016 22:24:12 -0800

> From: Eric Dumazet 
> 
> It seems many drivers do not respect napi_hash_del() contract.
> 
> When napi_hash_del() is used before netif_napi_del(), an RCU grace
> period is needed before freeing NAPI object.
> 
> Fixes: 91815639d880 ("virtio-net: rx busy polling support")
> Signed-off-by: Eric Dumazet 

Applied and queued up for -stable, thanks Eric.

Re: [PATCH net-next v3 3/3] net: marvell: Allow drivers to be built with COMPILE_TEST

[Florian Fainelli]

On 11/16/2016 11:04 AM, kbuild test robot wrote:
> Hi Florian,
> 
> [auto build test WARNING on net-next/master]
> 
> url:
> https://github.com/0day-ci/linux/commits/Florian-Fainelli/net-gianfar_ptp-Rename-FS-bit-to-FIPERST/20161116-095805
> config: s390-allyesconfig (attached as .config)
> compiler: s390x-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
> wget 
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>  -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=s390 
> 
> All warnings (new ones prefixed by >>):

While we could fix some of these warnings for 64-bit architectures, the
mvneta and mvpp2 drivers would not work there anyway since they assume
physical addresses will always be 32-bit wide and casts such addresses
accordingly.

Should we still silence these warnings?
-- 
Florian

Re: [PATCH net-next v3 2/3] net: fsl: Allow most drivers to be built with COMPILE_TEST

[Florian Fainelli]

On 11/15/2016 07:23 PM, kbuild test robot wrote:
> Hi Florian,
> 
> [auto build test WARNING on net-next/master]
> 
> url:
> https://github.com/0day-ci/linux/commits/Florian-Fainelli/net-gianfar_ptp-Rename-FS-bit-to-FIPERST/20161116-095805
> config: sh-allmodconfig (attached as .config)
> compiler: sh4-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
> wget 
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>  -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=sh 
> 
> All warnings (new ones prefixed by >>):
> 
>drivers/net/ethernet/freescale/fsl_pq_mdio.c: In function 
> 'fsl_pq_mdio_remove':
>>> drivers/net/ethernet/freescale/fsl_pq_mdio.c:498:27: warning: unused 
>>> variable 'priv' [-Wunused-variable]
>  struct fsl_pq_mdio_priv *priv = bus->priv;

Humm, this looks bogus, the variable is used see below:

>   ^~~~
> 
> vim +/priv +498 drivers/net/ethernet/freescale/fsl_pq_mdio.c
> 
> 1577ecef drivers/net/fsl_pq_mdio.cAndy Fleming
> 2009-02-04  482 return 0;
> 1577ecef drivers/net/fsl_pq_mdio.cAndy Fleming
> 2009-02-04  483  
> dd3b8a32 drivers/net/ethernet/freescale/fsl_pq_mdio.c Timur Tabi  
> 2012-08-29  484  error:
> dd3b8a32 drivers/net/ethernet/freescale/fsl_pq_mdio.c Timur Tabi  
> 2012-08-29  485 if (priv->map)
> b3319b10 drivers/net/fsl_pq_mdio.cAnton Vorontsov 
> 2009-12-30  486 iounmap(priv->map);
> dd3b8a32 drivers/net/ethernet/freescale/fsl_pq_mdio.c Timur Tabi  
> 2012-08-29  487  
> 1577ecef drivers/net/fsl_pq_mdio.cAndy Fleming
> 2009-02-04  488 kfree(new_bus);
> dd3b8a32 drivers/net/ethernet/freescale/fsl_pq_mdio.c Timur Tabi  
> 2012-08-29  489  
> 1577ecef drivers/net/fsl_pq_mdio.cAndy Fleming
> 2009-02-04  490 return err;
> 1577ecef drivers/net/fsl_pq_mdio.cAndy Fleming
> 2009-02-04  491  }
> 1577ecef drivers/net/fsl_pq_mdio.cAndy Fleming
> 2009-02-04  492  
> 1577ecef drivers/net/fsl_pq_mdio.cAndy Fleming
> 2009-02-04  493  
> 5078ac79 drivers/net/ethernet/freescale/fsl_pq_mdio.c Timur Tabi  
> 2012-08-29  494  static int fsl_pq_mdio_remove(struct platform_device *pdev)
> 1577ecef drivers/net/fsl_pq_mdio.cAndy Fleming
> 2009-02-04  495  {
> 5078ac79 drivers/net/ethernet/freescale/fsl_pq_mdio.c Timur Tabi  
> 2012-08-29  496 struct device *device = >dev;
> 1577ecef drivers/net/fsl_pq_mdio.cAndy Fleming
> 2009-02-04  497 struct mii_bus *bus = dev_get_drvdata(device);
> b3319b10 drivers/net/fsl_pq_mdio.cAnton Vorontsov 
> 2009-12-30 @498 struct fsl_pq_mdio_priv *priv = bus->priv;
> 1577ecef drivers/net/fsl_pq_mdio.cAndy Fleming
> 2009-02-04  499  
> 1577ecef drivers/net/fsl_pq_mdio.cAndy Fleming
> 2009-02-04  500 mdiobus_unregister(bus);
> 1577ecef drivers/net/fsl_pq_mdio.cAndy Fleming
> 2009-02-04  501  
> b3319b10 drivers/net/fsl_pq_mdio.cAnton Vorontsov 
> 2009-12-30  502 iounmap(priv->map);

Right here.

What compiler version is this?
-- 
Florian

Re: [PATCH net-next 0/6] Fixes for the MV88e6xxx interrupt code

[Andrew Lunn]

> Take a look at how the 'device_irq' local variable is used in
> mv88e6xxx_g2_irq_setup.  You assign it to 'err' in an error
> path before it is ever set to anything.
> 
> I think you meant to use the structure's 'device_irq' member
> instead.

Hi David

Agreed. Thanks for the review.

Andrew

Re: [patch net-next 6/8] ipv4: fib: Add an API to request a FIB dump

[Hannes Frederic Sowa]

On 16.11.2016 19:51, Ido Schimmel wrote:
> Hi,
> 
> On Wed, Nov 16, 2016 at 06:35:45PM +0100, Hannes Frederic Sowa wrote:
>> On 16.11.2016 16:18, Ido Schimmel wrote:
>>> On Wed, Nov 16, 2016 at 03:51:01PM +0100, Hannes Frederic Sowa wrote:
 On 16.11.2016 15:09, Jiri Pirko wrote:
> From: Ido Schimmel 
>
> Commit b90eb7549499 ("fib: introduce FIB notification infrastructure")
> introduced a new notification chain to notify listeners (f.e., switchdev
> drivers) about addition and deletion of routes.
>
> However, upon registration to the chain the FIB tables can already be
> populated, which means potential listeners will have an incomplete view
> of the tables.
>
> Solve that by adding an API to request a FIB dump. The dump itself it
> done using RCU in order not to starve consumers that need RTNL to make
> progress.
>
> Signed-off-by: Ido Schimmel 
> Signed-off-by: Jiri Pirko 

 Have you looked at potential inconsistencies resulting of RCU walking
 the table and having concurrent inserts?
>>>
>>> Yes. I did try to think about situations in which this approach will
>>> fail, but I could only find problems with concurrent removals, which I
>>> addressed in 5/8. In case of concurrent insertions, even if you missed
>>> the node, you would still get the ENTRY_ADD event to your listener.
>>
>> Theoretically a node could still be installed while the deletion event
>> fired before registering the notifier. E.g. a synchronize_net before
>> dumping could help here?
> 
> If the deletion event fired for some fib alias, then by 5/8 we are
> guaranteed that it was already unlinked from the fib alias list in the
> leaf in which it was contained. So, while it's possible we didn't
> register our listener in time for the deletion event, we won't traverse
> this fib alias while dumping the trie anyway. Did I understand you
> correctly?
> 

Theoretically we can have the same problem for insertion:

You receive a delete event from the notifier that is queued up first but
the dump will still see the entry in the fib due to being managed by RCU
(the notifier running on another CPU).

The problem is that the fib_remove_alias->hlist_del_rcu->WRITE_ONCE is
still not strongly ordered against the local fib dump trie walk.

>> I don't know how you prepare the data structures for inserting in into
>> the hardware, but if ordering matters, the notifier for a delete event
>> can be called before the dump installed the fib entry?
> 
> Right. It's possible for the listener to receive a deletion event for a
> fib entry it doesn't have, in which case it should just ignore it (as
> current listeners do).

Yep, for this specific case.

Bye,
Hannes

Re: [PATCH] net: dsa: mv88e6xxx: Respect SPEED_UNFORCED, don't set force bit

[David Miller]

From: Andrew Lunn 
Date: Wed, 16 Nov 2016 04:26:48 +0100

> The SPEED_UNFORCED indicates the MAC & PHY should perform
> auto-negotiation to determine a speed which works. If this is called
> for, don't set the force bit. If it is set, the MAC actually does
> 10Gbps, why the internal PHYs don't support.
> 
> Signed-off-by: Andrew Lunn 

What tree is this for?  This is a fix but the patch doesn't apply to
'net'.

Re: [PATCH net-next 0/6] Fixes for the MV88e6xxx interrupt code

[David Miller]

From: David Miller 
Date: Wed, 16 Nov 2016 14:21:02 -0500 (EST)

> From: Andrew Lunn 
> Date: Wed, 16 Nov 2016 01:56:50 +0100
> 
>> The interrupt code was never tested with a board who's probing
>> resulted in an -EPROBE_DEFFERED. So the clean up paths never got
>> tested. I now do have -EPROBE_DEFFERED, and things break badly during
>> cleanup. These are the fixes.
>> 
>> This is fixing code in net-next.
> 
> Series applied, thanks Andrew.

Actually, I reverted, there is a bug.

Take a look at how the 'device_irq' local variable is used in
mv88e6xxx_g2_irq_setup.  You assign it to 'err' in an error
path before it is ever set to anything.

I think you meant to use the structure's 'device_irq' member
instead.

Re: [PATCH net-next 0/6] Fixes for the MV88e6xxx interrupt code

[David Miller]

From: Andrew Lunn 
Date: Wed, 16 Nov 2016 01:56:50 +0100

> The interrupt code was never tested with a board who's probing
> resulted in an -EPROBE_DEFFERED. So the clean up paths never got
> tested. I now do have -EPROBE_DEFFERED, and things break badly during
> cleanup. These are the fixes.
> 
> This is fixing code in net-next.

Series applied, thanks Andrew.

Re: [BUG] X86: Removing inline decl on arch/x86/include/asm/desc.h.

[Thomas Gleixner]

On Tue, 15 Nov 2016, Corcodel Marian wrote:
>  Inline declarations suppress warning message from compiler but
>  most of these functions was declared static and is not used local on file.

Huch? This is a header file and the functions are marked inline on purpose.

Can you please explain what you are trying to achieve and why you think
that this is a good idea?

Thanks,

tglx

Re: [PATCH net] sctp: use new rhlist interface on sctp transport rhashtable

[Marcelo Ricardo Leitner]

On Tue, Nov 15, 2016 at 11:23:11PM +0800, Xin Long wrote:
> Now sctp transport rhashtable uses hash(lport, dport, daddr) as the key
> to hash a node to one chain. If in one host thousands of assocs connect
> to one server with the same lport and different laddrs (although it's
> not a normal case), all the transports would be hashed into the same
> chain.
> 
> It may cause to keep returning -EBUSY when inserting a new node, as the
> chain is too long and sctp inserts a transport node in a loop, which
> could even lead to system hangs there.
> 
> The new rhlist interface works for this case that there are many nodes
> with the same key in one chain. It puts them into a list then makes this
> list be as a node of the chain.
> 
> This patch is to replace rhashtable_ interface with rhltable_ interface.
> Since a chain would not be too long and it would not return -EBUSY with
> this fix when inserting a node, the reinsert loop is also removed here.
> 
> Signed-off-by: Xin Long 

Acked-by: Marcelo Ricardo Leitner 

> ---
>  include/net/sctp/sctp.h|  2 +-
>  include/net/sctp/structs.h |  4 +-
>  net/sctp/associola.c   |  8 +++-
>  net/sctp/input.c   | 93 
> ++
>  net/sctp/socket.c  |  7 +---
>  5 files changed, 64 insertions(+), 50 deletions(-)
> 
> diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
> index 31acc3f..f0dcaeb 100644
> --- a/include/net/sctp/sctp.h
> +++ b/include/net/sctp/sctp.h
> @@ -164,7 +164,7 @@ void sctp_backlog_migrate(struct sctp_association *assoc,
> struct sock *oldsk, struct sock *newsk);
>  int sctp_transport_hashtable_init(void);
>  void sctp_transport_hashtable_destroy(void);
> -void sctp_hash_transport(struct sctp_transport *t);
> +int sctp_hash_transport(struct sctp_transport *t);
>  void sctp_unhash_transport(struct sctp_transport *t);
>  struct sctp_transport *sctp_addrs_lookup_transport(
>   struct net *net,
> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
> index 11c3bf2..c5a2d83 100644
> --- a/include/net/sctp/structs.h
> +++ b/include/net/sctp/structs.h
> @@ -124,7 +124,7 @@ extern struct sctp_globals {
>   /* This is the sctp port control hash.  */
>   struct sctp_bind_hashbucket *port_hashtable;
>   /* This is the hash of all transports. */
> - struct rhashtable transport_hashtable;
> + struct rhltable transport_hashtable;
>  
>   /* Sizes of above hashtables. */
>   int ep_hashsize;
> @@ -762,7 +762,7 @@ static inline int sctp_packet_empty(struct sctp_packet 
> *packet)
>  struct sctp_transport {
>   /* A list of transports. */
>   struct list_head transports;
> - struct rhash_head node;
> + struct rhlist_head node;
>  
>   /* Reference counting. */
>   atomic_t refcnt;
> diff --git a/net/sctp/associola.c b/net/sctp/associola.c
> index f10d339..68428e1 100644
> --- a/net/sctp/associola.c
> +++ b/net/sctp/associola.c
> @@ -700,11 +700,15 @@ struct sctp_transport *sctp_assoc_add_peer(struct 
> sctp_association *asoc,
>   /* Set the peer's active state. */
>   peer->state = peer_state;
>  
> + /* Add this peer into the transport hashtable */
> + if (sctp_hash_transport(peer)) {
> + sctp_transport_free(peer);
> + return NULL;
> + }
> +
>   /* Attach the remote transport to our asoc.  */
>   list_add_tail_rcu(>transports, >peer.transport_addr_list);
>   asoc->peer.transport_count++;
> - /* Add this peer into the transport hashtable */
> - sctp_hash_transport(peer);
>  
>   /* If we do not yet have a primary path, set one.  */
>   if (!asoc->peer.primary_path) {
> diff --git a/net/sctp/input.c b/net/sctp/input.c
> index a01a56e..458e506 100644
> --- a/net/sctp/input.c
> +++ b/net/sctp/input.c
> @@ -790,10 +790,9 @@ static struct sctp_endpoint 
> *__sctp_rcv_lookup_endpoint(struct net *net,
>  
>  /* rhashtable for transport */
>  struct sctp_hash_cmp_arg {
> - const struct sctp_endpoint  *ep;
> - const union sctp_addr   *laddr;
> - const union sctp_addr   *paddr;
> - const struct net*net;
> + const union sctp_addr   *paddr;
> + const struct net*net;
> + u16 lport;
>  };
>  
>  static inline int sctp_hash_cmp(struct rhashtable_compare_arg *arg,
> @@ -801,7 +800,6 @@ static inline int sctp_hash_cmp(struct 
> rhashtable_compare_arg *arg,
>  {
>   struct sctp_transport *t = (struct sctp_transport *)ptr;
>   const struct sctp_hash_cmp_arg *x = arg->key;
> - struct sctp_association *asoc;
>   int err = 1;
>  
>   if (!sctp_cmp_addr_exact(>ipaddr, x->paddr))
> @@ -809,19 +807,10 @@ static inline int sctp_hash_cmp(struct 
> rhashtable_compare_arg *arg,
>   if (!sctp_transport_hold(t))
>   return err;
>  
> - asoc = t->asoc;
> - if 

[PATCH 1/3] net: stmmac: replace all pr_xxx by their netdev_xxx counterpart

[Corentin Labbe]

From: LABBE Corentin 

The stmmac driver use lots of pr_xxx functions to print information.
This is bad since we cannot know which device logs the information.
(moreover if two stmmac device are present)

Furthermore, it seems that it assumes wrongly that all logs will always
be subsequent by using a dev_xxx then some indented pr_xxx like this:
kernel: sun7i-dwmac 1c5.ethernet: no reset control found
kernel:  Ring mode enabled
kernel:  No HW DMA feature register supported
kernel:  Normal descriptors
kernel:  TX Checksum insertion supported

So this patch replace all pr_xxx by their netdev_xxx counterpart.
Excepts for some printing where netdev "cause" unpretty output like:
sun7i-dwmac 1c5.ethernet (unnamed net_device) (uninitialized): no reset 
control found
In those case, I keep dev_xxx.

In the same time I remove some "stmmac:" print since
this will be a duplicate with that dev_xxx displays.

Signed-off-by: Corentin Labbe 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 204 --
 drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c |  14 +-
 2 files changed, 123 insertions(+), 95 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 8eb12353..791daf4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -305,7 +305,7 @@ bool stmmac_eee_init(struct stmmac_priv *priv)
 */
spin_lock_irqsave(>lock, flags);
if (priv->eee_active) {
-   pr_debug("stmmac: disable EEE\n");
+   netdev_dbg(priv->dev, "disable EEE\n");
del_timer_sync(>eee_ctrl_timer);
priv->hw->mac->set_eee_timer(priv->hw, 0,
 tx_lpi_timer);
@@ -334,7 +334,7 @@ bool stmmac_eee_init(struct stmmac_priv *priv)
ret = true;
spin_unlock_irqrestore(>lock, flags);
 
-   pr_debug("stmmac: Energy-Efficient Ethernet initialized\n");
+   netdev_dbg(priv->dev, "Energy-Efficient Ethernet 
initialized\n");
}
 out:
return ret;
@@ -456,8 +456,8 @@ static int stmmac_hwtstamp_ioctl(struct net_device *dev, 
struct ifreq *ifr)
   sizeof(struct hwtstamp_config)))
return -EFAULT;
 
-   pr_debug("%s config flags:0x%x, tx_type:0x%x, rx_filter:0x%x\n",
-__func__, config.flags, config.tx_type, config.rx_filter);
+   netdev_dbg(priv->dev, "%s config flags:0x%x, tx_type:0x%x, 
rx_filter:0x%x\n",
+  __func__, config.flags, config.tx_type, config.rx_filter);
 
/* reserved for future extensions */
if (config.flags)
@@ -756,8 +756,9 @@ static void stmmac_adjust_link(struct net_device *dev)
break;
default:
if (netif_msg_link(priv))
-   pr_warn("%s: Speed (%d) not 10/100\n",
-   dev->name, phydev->speed);
+   netdev_warn(priv->dev,
+   "Speed (%d) not 10/100\n",
+   phydev->speed);
break;
}
 
@@ -810,10 +811,10 @@ static void stmmac_check_pcs_mode(struct stmmac_priv 
*priv)
(interface == PHY_INTERFACE_MODE_RGMII_ID) ||
(interface == PHY_INTERFACE_MODE_RGMII_RXID) ||
(interface == PHY_INTERFACE_MODE_RGMII_TXID)) {
-   pr_debug("STMMAC: PCS RGMII support enable\n");
+   netdev_dbg(priv->dev, "PCS RGMII support enabled\n");
priv->hw->pcs = STMMAC_PCS_RGMII;
} else if (interface == PHY_INTERFACE_MODE_SGMII) {
-   pr_debug("STMMAC: PCS SGMII support enable\n");
+   netdev_dbg(priv->dev, "PCS SGMII support enabled\n");
priv->hw->pcs = STMMAC_PCS_SGMII;
}
}
@@ -848,15 +849,15 @@ static int stmmac_init_phy(struct net_device *dev)
 
snprintf(phy_id_fmt, MII_BUS_ID_SIZE + 3, PHY_ID_FMT, bus_id,
 priv->plat->phy_addr);
-   pr_debug("stmmac_init_phy:  trying to attach to %s\n",
-phy_id_fmt);
+   netdev_dbg(priv->dev, "stmmac_init_phy: trying to attach to 
%s\n",
+  phy_id_fmt);
 
phydev = phy_connect(dev, phy_id_fmt, _adjust_link,
 interface);
}
 
if (IS_ERR_OR_NULL(phydev)) {
-   

[PATCH 3/3] net: stmmac: replace if (netif_msg_type) by their netif_xxx counterpart

[Corentin Labbe]

From: LABBE Corentin 

As sugested by Joe Perches, we could replace all
if (netif_msg_type(priv)) dev_xxx(priv->devices, ...)
by the simpler macro netif_xxx(priv, hw, priv->dev, ...)

Signed-off-by: Corentin Labbe 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 49 ++-
 1 file changed, 21 insertions(+), 28 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index d160bdb..fbd1cd7 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -755,10 +755,9 @@ static void stmmac_adjust_link(struct net_device *dev)
stmmac_hw_fix_mac_speed(priv);
break;
default:
-   if (netif_msg_link(priv))
-   netdev_warn(priv->dev,
-   "Speed (%d) not 10/100\n",
-   phydev->speed);
+   netif_warn(priv, link, priv->dev,
+  "Speed (%d) not 10/100\n",
+  phydev->speed);
break;
}
 
@@ -1036,14 +1035,14 @@ static int init_dma_desc_rings(struct net_device *dev, 
gfp_t flags)
 
priv->dma_buf_sz = bfsize;
 
-   if (netif_msg_probe(priv)) {
-   netdev_dbg(priv->dev, "(%s) dma_rx_phy=0x%08x 
dma_tx_phy=0x%08x\n",
-  __func__, (u32)priv->dma_rx_phy,
-  (u32)priv->dma_tx_phy);
+   netif_dbg(priv, probe, priv->dev,
+ "(%s) dma_rx_phy=0x%08x dma_tx_phy=0x%08x\n",
+ __func__, (u32)priv->dma_rx_phy, (u32)priv->dma_tx_phy);
+
+   /* RX INITIALIZATION */
+   netif_dbg(priv, probe, priv->dev,
+ "SKB addresses:\nskb\t\tskb data\tdma data\n");
 
-   /* RX INITIALIZATION */
-   netdev_dbg(priv->dev, "SKB addresses:\nskb\t\tskb data\tdma 
data\n");
-   }
for (i = 0; i < DMA_RX_SIZE; i++) {
struct dma_desc *p;
if (priv->extend_desc)
@@ -1055,11 +1054,9 @@ static int init_dma_desc_rings(struct net_device *dev, 
gfp_t flags)
if (ret)
goto err_init_rx_buffers;
 
-   if (netif_msg_probe(priv))
-   netdev_dbg(priv->dev, "[%p]\t[%p]\t[%x]\n",
-  priv->rx_skbuff[i],
-priv->rx_skbuff[i]->data,
-(unsigned int)priv->rx_skbuff_dma[i]);
+   netif_dbg(priv, probe, priv->dev, "[%p]\t[%p]\t[%x]\n",
+ priv->rx_skbuff[i], priv->rx_skbuff[i]->data,
+ (unsigned int)priv->rx_skbuff_dma[i]);
}
priv->cur_rx = 0;
priv->dirty_rx = (unsigned int)(i - DMA_RX_SIZE);
@@ -1389,9 +1386,8 @@ static void stmmac_tx_clean(struct stmmac_priv *priv)
netif_tx_lock(priv->dev);
if (netif_queue_stopped(priv->dev) &&
stmmac_tx_avail(priv) > STMMAC_TX_THRESH) {
-   if (netif_msg_tx_done(priv))
-   netdev_dbg(priv->dev, "%s: restart transmit\n",
-  __func__);
+   netif_dbg(priv, tx_done, priv->dev,
+ "%s: restart transmit\n", __func__);
netif_wake_queue(priv->dev);
}
netif_tx_unlock(priv->dev);
@@ -2096,9 +2092,8 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, 
struct net_device *dev)
priv->cur_tx = STMMAC_GET_ENTRY(priv->cur_tx, DMA_TX_SIZE);
 
if (unlikely(stmmac_tx_avail(priv) <= (MAX_SKB_FRAGS + 1))) {
-   if (netif_msg_hw(priv))
-   netdev_dbg(priv->dev, "%s: stop transmitted packets\n",
-  __func__);
+   netif_dbg(priv, hw, priv->dev, "%s: stop transmitted packets\n",
+ __func__);
netif_stop_queue(dev);
}
 
@@ -2298,9 +2293,8 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, 
struct net_device *dev)
}
 
if (unlikely(stmmac_tx_avail(priv) <= (MAX_SKB_FRAGS + 1))) {
-   if (netif_msg_hw(priv))
-   netdev_dbg(priv->dev,
-  "%s: stop transmitted packets\n", __func__);
+   netif_dbg(priv, hw, priv->dev, "%s: stop transmitted packets\n",
+ __func__);
netif_stop_queue(dev);
}
 
@@ -2465,9 +2459,8 @@ static inline void stmmac_rx_refill(struct stmmac_priv 
*priv)
if 

[PATCH 2/3] net: stmmac: replace hardcoded function name by __func__

[Corentin Labbe]

From: LABBE Corentin 

Some printing have the function name hardcoded.
It is better to use __func__ instead.

Signed-off-by: Corentin Labbe 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 791daf4..d160bdb 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -849,7 +849,7 @@ static int stmmac_init_phy(struct net_device *dev)
 
snprintf(phy_id_fmt, MII_BUS_ID_SIZE + 3, PHY_ID_FMT, bus_id,
 priv->plat->phy_addr);
-   netdev_dbg(priv->dev, "stmmac_init_phy: trying to attach to 
%s\n",
+   netdev_dbg(priv->dev, "%s: trying to attach to %s\n", __func__,
   phy_id_fmt);
 
phydev = phy_connect(dev, phy_id_fmt, _adjust_link,
@@ -890,9 +890,8 @@ static int stmmac_init_phy(struct net_device *dev)
if (phydev->is_pseudo_fixed_link)
phydev->irq = PHY_POLL;
 
-   netdev_dbg(priv->dev,
-  "stmmac_init_phy: attached to PHY (UID 0x%x) Link = %d\n",
-  phydev->phy_id, phydev->link);
+   netdev_dbg(priv->dev, "%s: attached to PHY (UID 0x%x) Link = %d\n",
+  __func__, phydev->phy_id, phydev->link);
 
return 0;
 }
-- 
2.7.3