* Re: [PATCH 1/2] net: netcp: replace IS_ERR_OR_NULL by IS_ERR
From: David Miller @ 2016-11-17 4:27 UTC (permalink / raw)
To: Julia.Lawall
Cc: w-kwok2, kernel-janitors, m-karicheri2, netdev, linux-kernel,
christophe.jaillet
In-Reply-To: <1479293014-18811-2-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
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 <Julia.Lawall@lip6.fr>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [patch net-next 0/4] mlxsw: Introduce support for I2C bus
From: David Miller @ 2016-11-17 4:29 UTC (permalink / raw)
To: jiri; +Cc: netdev, vadimp, idosch, eladr, yotamg, nogahf, arkadis, ogerlitz
In-Reply-To: <1479306046-13324-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
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.
^ permalink raw reply
* Re: [PATCH net] : add a missing rcu synchronization
From: David Miller @ 2016-11-17 4:31 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, michael.chan
In-Reply-To: <1479306712.8455.185.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 16 Nov 2016 06:31:52 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> 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 <edumazet@google.com>
> Cc: Michael Chan <michael.chan@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] : add a missing rcu synchronization
From: Eric Dumazet @ 2016-11-17 4:59 UTC (permalink / raw)
To: David Miller; +Cc: netdev, michael.chan
In-Reply-To: <20161116.233106.2234599506618839323.davem@davemloft.net>
On Wed, 2016-11-16 at 23:31 -0500, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 16 Nov 2016 06:31:52 -0800
>
> > From: Eric Dumazet <edumazet@google.com>
> >
> > 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 <edumazet@google.com>
> > Cc: Michael Chan <michael.chan@broadcom.com>
>
> Applied.
Thanks David for the title fix ;)
^ permalink raw reply
* Philanthropic Gesture
From: Susanne Hanna Ursula Klattent @ 2016-11-17 5:23 UTC (permalink / raw)
To: Recipients
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: sussanklattenh1@gmail.com
^ permalink raw reply
* Problems with item delivery, n.000859529
From: FedEx 2Day A.M. @ 2016-11-17 6:12 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 197 bytes --]
Dear Customer,
Your parcel has arrived at November 14. Courier was unable to deliver the parcel to you.
Delivery Label is attached to this email.
Regards,
Alvin Mccarthy,
Sr. Operation Manager.
[-- Attachment #2: Delivery_Notification_000859529.zip --]
[-- Type: application/zip, Size: 7477 bytes --]
^ permalink raw reply
* Re: [PATCH net v2] net: nsid cannot be allocated for a dead netns
From: Cong Wang @ 2016-11-17 6:32 UTC (permalink / raw)
To: David Miller
Cc: Nicolas Dichtel, Andrey Wagin, Linux Kernel Network Developers
In-Reply-To: <20161116.231722.2198167385156796830.davem@davemloft.net>
On Wed, Nov 16, 2016 at 8:17 PM, David Miller <davem@davemloft.net> wrote:
> From: Cong Wang <xiyou.wangcong@gmail.com>
> Date: Wed, 16 Nov 2016 09:29:29 -0800
>
>> On Wed, Nov 16, 2016 at 1:49 AM, Nicolas Dichtel
>> <nicolas.dichtel@6wind.com> 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(&net->count) || !atomic_read(&peer->count))
>>> + return -EINVAL;
>>> +
>>> return idr_alloc(&net->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(&net->count) == 0)
>> + return NETNSA_NSID_NOT_ASSIGNED;
>> spin_lock_irqsave(&net->nsid_lock, flags);
>> alloc = atomic_read(&peer->count) == 0 ? false : true;
>> id = __peernet2id_alloc(net, peer, &alloc);
>
> 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...
^ permalink raw reply
* Re: [v3] mwifiex: report wakeup for wowlan
From: Kalle Valo @ 2016-11-17 6:41 UTC (permalink / raw)
To: Rajat Jain
Cc: Amitkumar Karwar, Nishant Sarmukadam, linux-wireless, netdev,
Rajat Jain, Wei-Ning Huang, Brian Norris, Eric Caruso, rajatxjain
In-Reply-To: <1475613462-93384-1-git-send-email-rajatja@google.com>
Rajat Jain <rajatja@google.com> 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 <wnhuang@google.com>
> Signed-off-by: Rajat Jain <rajatja@google.com>
> Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
> Reviewed-by: Eric Caruso <ejcaruso@chromium.org>
> Acked-by: Amitkumar Karwar <akarwar@marvell.com>
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
^ permalink raw reply
* Re: wlcore: Allow scans when in AP mode
From: Kalle Valo @ 2016-11-17 6:43 UTC (permalink / raw)
To: Xander Huff
Cc: linux-wireless, netdev, James Minor, linux-kernel, xander.huff
In-Reply-To: <1475855157-21271-1-git-send-email-xander.huff@ni.com>
Xander Huff <xander.huff@ni.com> wrote:
> From: James Minor <james.minor@ni.com>
>
> 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 <james.minor@ni.com>
> Signed-off-by: Xander Huff <xander.huff@ni.com>
> Reviewed-by: Ben Shelton <ben.shelton@ni.com>
> Reviewed-by: Jaeden Amero <jaeden.amero@ni.com>
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
^ permalink raw reply
* Re: brcmfmac: print name of connect status event
From: Kalle Valo @ 2016-11-17 6:45 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, netdev, linux-kernel,
Rafał Miłecki
In-Reply-To: <20161014074559.22962-1-zajec5@gmail.com>
Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> This simplifies debugging. Format %s (%u) comes from similar debugging
> message in brcmf_fweh_event_worker.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
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
^ permalink raw reply
* Re: p54: memset(0) whole array
From: Kalle Valo @ 2016-11-17 6:45 UTC (permalink / raw)
To: Jiri Slaby
Cc: chunkeey-gM/Ye1E23mwN+BqQ9rBEUg,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jiri Slaby,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161014092309.24113-1-jslaby-AlSwsSmVLrQ@public.gmane.org>
Jiri Slaby <jslaby-AlSwsSmVLrQ@public.gmane.org> 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 <jslaby-AlSwsSmVLrQ@public.gmane.org>
> Cc: Christian Lamparter <chunkeey-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> Cc: Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Acked-by: Christian Lamparter <chunkeey-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
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
^ permalink raw reply
* Re: wireless: fix bogus maybe-uninitialized warning
From: Kalle Valo @ 2016-11-17 6:46 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Kalle Valo, Stanislav Yakovlev, Jouni Malinen, Johannes Berg,
David S. Miller, linux-wireless, netdev, Arnd Bergmann,
linux-kernel
In-Reply-To: <20161024153918.2810634-2-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> 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 *)&dst+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 <arnd@arndb.de>
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
^ permalink raw reply
* Re: [v2] cw1200: fix bogus maybe-uninitialized warning
From: Kalle Valo @ 2016-11-17 6:48 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Solomon Peachy, David Laight, Arnd Bergmann, Johannes Berg,
linux-wireless, netdev, linux-kernel
In-Reply-To: <20161025202121.1070879-1-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> 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 <David.Laight@ACULAB.COM>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
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
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net: marvell: Allow drivers to be built with COMPILE_TEST
From: kbuild test robot @ 2016-11-17 7:10 UTC (permalink / raw)
To: Florian Fainelli
Cc: kbuild-all, netdev, davem, mw, arnd, gregory.clement, Shaohui.Xie,
Florian Fainelli
In-Reply-To: <20161116003541.18415-4-f.fainelli@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 902 bytes --]
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 infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 44138 bytes --]
^ permalink raw reply
* Re: [Patch net] net: check dead netns for peernet2id_alloc()
From: Andrei Vagin @ 2016-11-17 7:17 UTC (permalink / raw)
To: Cong Wang; +Cc: Linux Kernel Network Developers, Nicolas Dichtel
In-Reply-To: <1479320822-17483-1-git-send-email-xiyou.wangcong@gmail.com>
On Wed, Nov 16, 2016 at 10:27 AM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> Andrei reports we still allocate netns ID from idr after we destroy
> it in cleanup_net().
>
> cleanup_net():
> ...
> idr_destroy(&net->netns_ids);
> ...
> list_for_each_entry_reverse(ops, &pernet_list, list)
> ops_exit_list(ops, &net_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 <avagin@openvz.org>
>
> Fixes: 0c7aecd4bde4 ("netns: add rtnl cmd to add and get peer netns ids")
> Reported-by: Andrei Vagin <avagin@gmail.com>
> Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
> ---
> 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(&net->count) == 0)
> + return NETNSA_NSID_NOT_ASSIGNED;
> spin_lock_irqsave(&net->nsid_lock, flags);
> alloc = atomic_read(&peer->count) == 0 ? false : true;
> id = __peernet2id_alloc(net, peer, &alloc);
> --
> 2.1.0
>
^ permalink raw reply
* Re: Virtio_net support vxlan encapsulation package TSO offload discuss
From: Jason Wang @ 2016-11-17 7:27 UTC (permalink / raw)
To: Zhangming (James, Euler), netdev@vger.kernel.org
Cc: Michael S. Tsirkin, Vlad Yasevic, Amnon Ilan
In-Reply-To: <DBCD2614ECF3FF4087A2C27CA80E34DD54027936@SZXEMA501-MBX.china.huawei.com>
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 *)&hdr, 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);
>>>>> skb_set_inner_mac_header(skb, tnl_len - mac_len);
>>>>> skb_set_inner_network_header(skb, tnl_len + payload_mac_len - mac_len);
>>>>> skb->encapsulation = 1;
>>>>> }
>>>>>
>>>>>
>>>> Something like this, and you probably need do something more:
>>>>
>>>> - use net-next.git to generate the patch (for the latest code)
>>>> - add feature negotiation
>>>> - tun/macvtap/qemu patches for this, you can start with tun/macvtap
>>>> patches
>>>> - support for all other SKB_GSO_* types which is not supported
>>>> - use a new field instead of num_buffers
>>>> - a virtio spec patch to describe the support for encapsulation
>>>> offload
>>>>
>>>> Thanks
>>> Thank you for your advice, I will start it right now.
>>>
>>> Thanks
>> Cool, one more question: while at it, I think you may want to add support for dpdk too?
>>
>> Thanks
> Do you mean that the patch should be compatible with virtio pmd, or give virtio pmd patch?
>
> Thanks
I mean it's better to prepare patches for both virtio pmd and dpdk.
Thanks
^ permalink raw reply
* Re: Netperf UDP issue with connected sockets
From: Jesper Dangaard Brouer @ 2016-11-17 8:16 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Rick Jones, "netdev
In-Reply-To: <1479342849.8455.233.camel@edumazet-glaptop3.roam.corp.google.com>
On Wed, 16 Nov 2016 16:34:09 -0800
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> 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 Command Shared Object Symbol
> > + 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% netperf netperf [.] send_data
> > + 1.92% netperf netperf [.] send_omni_inner
>
> Check "ss -nu" ?
>
> You will see if sockets are connected (present in ss output or not)
Tested different versions of netperf, commands used below signature:
netperf-2.6.0: connected "broken"
netperf-2.7.0: connected works
SVN-r709 : connected works
I noticed there is a Send-Q, and the perf-top2 is _raw_spin_lock, which
looks like it comes from __dev_queue_xmit(), but we know from
experience that this stall is actually caused by writing the
tailptr/doorbell in the HW. Thus, this could benefit a lot from
bulk/xmit_more into the qdisc layer.
> 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
Thanks for explaining that! :-)
http://lxr.free-electrons.com/source/include/net/ip.h?v=4.8#L332
http://lxr.free-electrons.com/source/net/ipv4/ip_output.c?v=4.8#L449
Netperf UDP_STREAM default send 64K packets that get fragmented...
which actually is very unfortunate because people end-up testing a code
path in the kernel they didn't expect. That is why I use the
option "-- -m 1472".
> time to try IP_MTU_DISCOVER ;)
To Rick, maybe you can find a good solution or option with Eric's hint,
to send appropriate sized UDP packets with Don't Fragment (DF).
--
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
Testing with ss -nua
$ /usr/local/stow/netperf-2.6.0-demo/bin/netperf -H 198.18.50.1 -t UDP_STREAM -l 3 -- -m 1472 -n -N > /dev/null & sleep 1; ss -una
State Recv-Q Send-Q Local Address:Port Peer Address:Port
UNCONN 0 11520 *:54589 *:*
$ /usr/local/stow/netperf-2.7.0-demo/bin/netperf -H 198.18.50.1 -t UDP_STREAM -l 3 -- -m 1472 -n -N > /dev/null & sleep 1; ss -una
State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 18432 198.18.50.3:46803 198.18.50.1:51851
$ ~/tools/netperf2-svn/src/netperf -H 198.18.50.1 -t UDP_STREAM -l 3 -- -m 1472 -n -N > /dev/null & sleep 1; ss -una
State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 43776 198.18.50.3:42965 198.18.50.1:51948
^ permalink raw reply
* Re: [PATCH net v2] net: nsid cannot be allocated for a dead netns
From: Nicolas Dichtel @ 2016-11-17 8:39 UTC (permalink / raw)
To: David Miller, xiyou.wangcong; +Cc: avagin, netdev
In-Reply-To: <20161116.231722.2198167385156796830.davem@davemloft.net>
Le 17/11/2016 à 05:17, David Miller a écrit :
[snip]
> Indeed, this looks cleaner, Nicolas?
Yes, I agree. Cong already sent a v3 of my patch, let's apply it.
^ permalink raw reply
* Re: [Patch net] net: check dead netns for peernet2id_alloc()
From: Nicolas Dichtel @ 2016-11-17 8:39 UTC (permalink / raw)
To: Cong Wang, netdev; +Cc: avagin
In-Reply-To: <1479320822-17483-1-git-send-email-xiyou.wangcong@gmail.com>
Le 16/11/2016 à 19:27, Cong Wang a écrit :
> Andrei reports we still allocate netns ID from idr after we destroy
> it in cleanup_net().
>
> cleanup_net():
> ...
> idr_destroy(&net->netns_ids);
> ...
> list_for_each_entry_reverse(ops, &pernet_list, list)
> ops_exit_list(ops, &net_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.
>
> Fixes: 0c7aecd4bde4 ("netns: add rtnl cmd to add and get peer netns ids")
> Reported-by: Andrei Vagin <avagin@gmail.com>
> Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
^ permalink raw reply
* Re: [PATCH net v2] net: nsid cannot be allocated for a dead netns
From: Nicolas Dichtel @ 2016-11-17 8:41 UTC (permalink / raw)
To: Cong Wang, David Miller; +Cc: Andrey Wagin, Linux Kernel Network Developers
In-Reply-To: <CAM_iQpUGayFoDSQL2w6bOVKG2q=dSDyf1jQ5LvrYuy7V_y_auA@mail.gmail.com>
Le 17/11/2016 à 07:32, Cong Wang a écrit :
[snip]
> since Nicolas' patch doesn't even compile...
It's always surprising how agressive you are, really :(
Can you show me the compilation error of this patch (we are talking about the v2
patch here)?
^ permalink raw reply
* Re: [PATCH ipsec-next 6/8] xfrm: policy: only use rcu in xfrm_sk_policy_lookup
From: Nicolas Dichtel @ 2016-11-17 8:55 UTC (permalink / raw)
To: Florian Westphal; +Cc: netdev, Steffen Klassert
In-Reply-To: <20161116173028.GI30581@breakpoint.cc>
Le 16/11/2016 à 18:30, Florian Westphal a écrit :
[snip]
> This should fix it (if we succeed grabbing the refcount, then if (err && !xfrm_pol_hold_rcu
> evaluates to false and we hit last else branch and set pol to ERR_PTR(0)...
Haha, right :) Thank you for the quick fix.
The patch solves my problem. You can add my 'tested-by' tag in the formal
submission.
Tested-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net: marvell: Allow drivers to be built with COMPILE_TEST
From: Arnd Bergmann @ 2016-11-17 9:10 UTC (permalink / raw)
To: kbuild test robot
Cc: Florian Fainelli, kbuild-all, netdev, davem, mw, gregory.clement,
Shaohui.Xie
In-Reply-To: <201611171025.rUxQZT0L%fengguang.wu@intel.com>
On Thursday, November 17, 2016 10:30:10 AM CET kbuild test robot wrote:
>
> 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!
>
>
This can be avoided by adding 'depends on HAS_DMA'. We should probably just
fix m32r instead to not require that and allow building all drivers even when
they can't work in the end.
Arnd
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net: marvell: Allow drivers to be built with COMPILE_TEST
From: Arnd Bergmann @ 2016-11-17 9:12 UTC (permalink / raw)
To: kbuild test robot
Cc: Florian Fainelli, kbuild-all, netdev, davem, mw, gregory.clement,
Shaohui.Xie
In-Reply-To: <201611171559.suMIPVBq%fengguang.wu@intel.com>
On Thursday, November 17, 2016 3:10:10 PM CET kbuild test robot wrote:
> 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'
We should fix this, I'd suggest either adding an inline wrapper for
mvebu_mbus_get_dram_win_info() when CONFIG_MVEBU_MBUS is not set,
or allowing CONFIG_MVEBU_MBUS to be enabled for COMPILE_TEST as well.
Arnd
^ permalink raw reply
* Re: [PATCH 1/1] ixgbe: write flush vfta registers
From: zhuyj @ 2016-11-17 9:33 UTC (permalink / raw)
To: Lino Sanfilippo
Cc: e1000-devel@lists.sourceforge.net, netdev, intel-wired-lan
In-Reply-To: <trinity-ec3a2e6f-7310-41aa-8743-61bc62ccf663-1479305144399@3capp-gmx-bs59>
Sure. From the following.
"
VLAN Filter. Each bit ‘i’ in register ‘n’ affects packets with VLAN
tags equal to 32*n+i.
128 VLAN Filter registers compose a table of 4096 bits that cover all
possible VLAN
tags.
Each bit when set, enables packets with the associated VLAN tags to
pass. Each bit
when cleared, blocks packets with this VLAN tag.
"
Your suggestions seems reasonable. Please wait. I will make tests to
vefiry your suggestions.
I will keep you update.
On Wed, Nov 16, 2016 at 10:05 PM, Lino Sanfilippo <LinoSanfilippo@gmx.de> wrote:
>
>
> Hi,
>
>>
>> Sometimes vfta registers can not be written successfully in dcb mode.
>> This is very occassional. When the ixgbe nic runs for a very long time,
>> sometimes this bug occurs. But after IXGBE_WRITE_FLUSH is executed,
>> this bug never occurs.
>>
>> Signed-off-by: Zhu Yanjun <zyjzyj2000@gmail.com>
>> ---
>> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
>> index bd93d82..1221cfb 100644
>> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
>> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
>> @@ -4138,8 +4138,10 @@ static void ixgbe_vlan_promisc_enable(struct ixgbe_adapter *adapter)
>> }
>>
>> /* Set all bits in the VLAN filter table array */
>> - for (i = hw->mac.vft_size; i--;)
>> + for (i = hw->mac.vft_size; i--;) {
>> IXGBE_WRITE_REG(hw, IXGBE_VFTA(i), ~0U);
>> + IXGBE_WRITE_FLUSH(hw);
>> + }
>
> Should it not be sufficient to do the flush only once, at the end of the function?
>
> Regards,
> Lino
------------------------------------------------------------------------------
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH net-next v2 3/4] bpf, mlx5: drop priv->xdp_prog reference on netdev cleanup
From: Saeed Mahameed @ 2016-11-17 9:34 UTC (permalink / raw)
To: Daniel Borkmann
Cc: David S. Miller, Alexei Starovoitov, Brenden Blanco, zhiyisun,
Rana Shahout, Saeed Mahameed, Linux Netdev List
In-Reply-To: <582C817A.4030902@iogearbox.net>
On Wed, Nov 16, 2016 at 5:55 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 11/16/2016 04:45 PM, Daniel Borkmann wrote:
>>
>> On 11/16/2016 01:51 PM, Saeed Mahameed wrote:
>>>
>>> On Wed, Nov 16, 2016 at 2:04 AM, Daniel Borkmann <daniel@iogearbox.net>
>>> wrote:
>>>>
>>>> mlx5e_xdp_set() is currently the only place where we drop reference on
>>>> the
>>>> prog sitting in priv->xdp_prog when it's exchanged by a new one. We also
>>>> need to make sure that we eventually release that reference, for
>>>> example,
>>>> in case the netdev is dismantled.
>>>>
>>>> Fixes: 86994156c736 ("net/mlx5e: XDP fast RX drop bpf programs support")
>>>> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
>>>> ---
>>>> drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 3 +++
>>>> 1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
>>>> b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
>>>> index cf26672..60fe54c 100644
>>>> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
>>>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
>>>> @@ -3715,6 +3715,9 @@ static void mlx5e_nic_cleanup(struct mlx5e_priv
>>>> *priv)
>>>>
>>>> if (MLX5_CAP_GEN(mdev, vport_group_manager))
>>>> mlx5_eswitch_unregister_vport_rep(esw, 0);
>>>> +
>>>> + if (priv->xdp_prog)
>>>> + bpf_prog_put(priv->xdp_prog);
>>>> }
>>>
>>>
>>> I thought that on unregister_netdev ndo_xdp_set will be called with
>>> NULL prog to cleanup. like any other resources (Vlans/mac_lists/
>>> etc..), why xdp should be different ?
>>> Anyway if this is the case, I am ok with this fix, you can even send
>>> it to net (it looks like a serious leak).
>>
>>
>> The only interaction with ndo_xdp() right now is dev_change_xdp_fd()
>> and the currently a bit terse dump via rtnl_xdp_fill(). The latter
>> only tells whether something is actually attached and will have more
>> info in near future, but doesn't alter anything.
>>
>> dev_change_xdp_fd() is only triggered from user side via netlink when
>> IFLA_XDP container attr is around, so no automatic cleanup here. This
>> means as per documentation in enum xdp_netdev_command, that the driver
>> has full ownership, thus needs to bpf_prog_put().
>
>
> Note that without patch 2/4, just sending this one to net doesn't really
> solve anything, since there the mlx5e_xdp_set() still has the incorrect
> bpf_prog_add(prog, 1) around. So it's the whole series if so. I had it
> originally targeted at net, but Alexei suggested net-next; I don't really
> mind either way, so I agreed to go for net-next.
Ok, Thank you Daniel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox