* 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: 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: 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: [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: [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: [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: 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: 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: 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: 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: [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: [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
* 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
* 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
* 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
* 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-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 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] net: dsa: b53: Fix VLAN usage and how we treat CPU port
From: David Miller @ 2016-11-17 4:26 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, vivien.didelot, knaack.h
In-Reply-To: <20161115235815.25641-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
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 <knaack.h@gmx.de>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> David,
>
> Can you queue this for -stable so it makes it into 4.8.4?
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] sctp: use new rhlist interface on sctp transport rhashtable
From: David Miller @ 2016-11-17 4:22 UTC (permalink / raw)
To: lucien.xin
Cc: netdev, linux-sctp, marcelo.leitner, nhorman, vyasevich, herbert,
phil
In-Reply-To: <0a89ef8506db3bba6a37010bd5622cd145183ab4.1479223391.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
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 <lucien.xin@gmail.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net v2] net: nsid cannot be allocated for a dead netns
From: David Miller @ 2016-11-17 4:17 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: nicolas.dichtel, avagin, netdev
In-Reply-To: <CAM_iQpXzp54gOyiRu4PUcJhLEB3T+TTEL+JLE2PL+oB31ZuCJw@mail.gmail.com>
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?
^ permalink raw reply
* Re: [PATCH net-next 0/4] bnxt_en: Updates.
From: David Miller @ 2016-11-17 4:11 UTC (permalink / raw)
To: michael.chan; +Cc: netdev
In-Reply-To: <1479348790-6218-1-git-send-email-michael.chan@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
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.
^ permalink raw reply
* Re: [PATCHv2 perf/core 2/2] tools lib bpf: Sync with samples/bpf/libbpf
From: Joe Stringer @ 2016-11-17 3:53 UTC (permalink / raw)
To: Wangnan (F); +Cc: LKML, netdev, ast, Daniel Borkmann, Arnaldo Carvalho de Melo
In-Reply-To: <582D265B.4000102@huawei.com>
On 16 November 2016 at 19:39, Wangnan (F) <wangnan0@huawei.com> wrote:
>
>
> On 2016/11/17 10:46, Joe Stringer wrote:
>>
>> On 16 November 2016 at 18:10, Wangnan (F) <wangnan0@huawei.com> 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.
^ permalink raw reply
* Re: CPU port VLAN configuration [Was: Re: [PATCH net] net: dsa: b53: Fix VLAN usage and how we treat CPU port]
From: Vivien Didelot @ 2016-11-17 3:51 UTC (permalink / raw)
To: Florian Fainelli, netdev; +Cc: davem, andrew, knaack.h
In-Reply-To: <b5a41c19-b0a4-e5f8-23db-211c2d754f74@gmail.com>
Hi Florian,
Florian Fainelli <f.fainelli@gmail.com> 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
^ permalink raw reply
* Re: [PATCHv2 perf/core 2/2] tools lib bpf: Sync with samples/bpf/libbpf
From: Joe Stringer @ 2016-11-17 3:40 UTC (permalink / raw)
To: Wangnan (F); +Cc: LKML, netdev, ast, Daniel Borkmann, Arnaldo Carvalho de Melo
In-Reply-To: <582D2222.4060309@huawei.com>
On 16 November 2016 at 19:21, Wangnan (F) <wangnan0@huawei.com> wrote:
>
>
> On 2016/11/17 10:46, Joe Stringer wrote:
>>
>> On 16 November 2016 at 18:10, Wangnan (F) <wangnan0@huawei.com> 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(&attr, '\0', sizeof(attr));
>>>> + return sys_bpf(BPF_MAP_CREATE, &attr, 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.
^ 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