* Re: [RFC PATCH v2 14/17] net: skb_array: expose peek API
From: Michael S. Tsirkin @ 2017-06-06 3:10 UTC (permalink / raw)
To: John Fastabend; +Cc: eric.dumazet, netdev
In-Reply-To: <20170502154032.9304.50203.stgit@john-Precision-Tower-5810>
On Tue, May 02, 2017 at 08:40:32AM -0700, John Fastabend wrote:
> This adds a peek routine to skb_array.h for use with qdisc.
>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> ---
> include/linux/skb_array.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/linux/skb_array.h b/include/linux/skb_array.h
> index f4dfade..33f1f0c 100644
> --- a/include/linux/skb_array.h
> +++ b/include/linux/skb_array.h
> @@ -72,6 +72,11 @@ static inline bool __skb_array_empty(struct skb_array *a)
> return !__ptr_ring_peek(&a->ring);
> }
>
> +static inline struct sk_buff *skb_array_peek(struct skb_array *a)
> +{
> + return __ptr_ring_peek(&a->ring);
> +}
> +
> static inline bool skb_array_empty(struct skb_array *a)
> {
> return ptr_ring_empty(&a->ring);
I think it's better to call this __skb_array_peek: the issue
is that callers must be careful with it's use - see the comment
near __ptr_ring_peek.
--
MST
^ permalink raw reply
* Re: [PATCH] net: bridge: fix potential NULL pointer dereference
From: Gustavo A. R. Silva @ 2017-06-06 3:13 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: Stephen Hemminger, David S. Miller, bridge, netdev, roopa
In-Reply-To: <840022de-3d31-4f62-aaaf-ba83d5c78ad7@cumulusnetworks.com>
Hi Nikolay,
Quoting Nikolay Aleksandrov <nikolay@cumulusnetworks.com>:
> On 06/06/17 00:30, Gustavo A. R. Silva wrote:
>> Add NULL check before dereferencing pointer _p_ inside br_afspec().
>>
>> Addresses-Coverity-ID: 1401872
>> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
>> ---
>> net/bridge/br_netlink.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
>> index 1e63ec4..ad85a9c 100644
>> --- a/net/bridge/br_netlink.c
>> +++ b/net/bridge/br_netlink.c
>> @@ -776,7 +776,7 @@ int br_setlink(struct net_device *dev, struct
>> nlmsghdr *nlh, u16 flags)
>> goto out;
>> }
>>
>> - if (afspec) {
>> + if (p && afspec) {
>> err = br_afspec((struct net_bridge *)netdev_priv(dev), p,
>> afspec, RTM_SETLINK);
>> }
>>
>
> While I see a possible issue with the new bridge tunnel code (+CC
> Roopa), this is
> the wrong fix because there are legitimate use cases where p is null
> and br_afspec
> is called.
> We need to change the p->flags check in br_afspec()'s
> IFLA_BRIDGE_VLAN_TUNNEL_INFO case
> to check for a NULL p first.
>
You're right. I got it.
> Thanks for the report!
Sure thing, glad to help.
Thank you!
^ permalink raw reply
* Re: [RFC PATCH v2 00/17] latest qdisc patch series
From: Michael S. Tsirkin @ 2017-06-06 4:30 UTC (permalink / raw)
To: John Fastabend; +Cc: eric.dumazet, netdev, Jason Wang
In-Reply-To: <20170502153518.9304.17904.stgit@john-Precision-Tower-5810>
On Tue, May 02, 2017 at 08:36:03AM -0700, John Fastabend wrote:
> I am not going to be able to work on this for a few days so I figured
> it might be worth getting some feedback if there is any. Any thoughts
> on how to squeeze a few extra pps out of this would be very useful.
Batch dequeue into a temporary buffer, then scan this
buffer and xmit without locks might be a good idea.
It certainly helped vhost. You might need to requeue
if you are unable to xmit, there's now support for this.
--
MST
^ permalink raw reply
* Re: [PATCH 2/2] xfrm: add UDP encapsulation port in migrate message
From: kbuild test robot @ 2017-06-06 4:53 UTC (permalink / raw)
To: Antony Antony
Cc: kbuild-all, netdev, Antony Antony, Steffen Klassert, Herbert Xu,
David S . Miller, Richard Guy Briggs
In-Reply-To: <20170605215625.11043-3-antony@phenome.org>
[-- Attachment #1: Type: text/plain, Size: 9242 bytes --]
Hi Antony,
[auto build test ERROR on ipsec-next/master]
[also build test ERROR on v4.12-rc4 next-20170605]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Antony-Antony/add-udp-encapsulation-port-to-xfrm_do_migrate/20170606-114911
base: https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git master
config: x86_64-randconfig-x015-201723 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
>> net//key/af_key.c:3836:13: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.migrate = pfkey_send_migrate,
^~~~~~~~~~~~~~~~~~
net//key/af_key.c:3836:13: note: (near initialization for 'pfkeyv2_mgr.migrate')
Cyclomatic Complexity 5 include/linux/compiler.h:__read_once_size
Cyclomatic Complexity 5 include/linux/compiler.h:__write_once_size
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:__set_bit
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:constant_test_bit
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:variable_test_bit
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:fls64
Cyclomatic Complexity 1 include/linux/log2.h:__ilog2_u64
Cyclomatic Complexity 1 include/linux/list.h:hlist_unhashed
Cyclomatic Complexity 1 include/linux/list.h:hlist_empty
Cyclomatic Complexity 2 include/linux/list.h:__hlist_del
Cyclomatic Complexity 1 include/asm-generic/getorder.h:__get_order
Cyclomatic Complexity 1 include/linux/err.h:ERR_PTR
Cyclomatic Complexity 1 include/linux/err.h:PTR_ERR
Cyclomatic Complexity 1 include/linux/err.h:IS_ERR
Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:atomic_read
Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:atomic_set
Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:atomic_add
Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:atomic_inc
Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:atomic_dec
Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:atomic_dec_and_test
Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:atomic_add_return
Cyclomatic Complexity 5 arch/x86/include/asm/preempt.h:__preempt_count_add
Cyclomatic Complexity 5 arch/x86/include/asm/preempt.h:__preempt_count_sub
Cyclomatic Complexity 1 include/linux/spinlock.h:spin_lock_bh
Cyclomatic Complexity 1 include/linux/spinlock.h:spin_unlock_bh
Cyclomatic Complexity 1 include/linux/rcupdate.h:__rcu_read_lock
Cyclomatic Complexity 1 include/linux/rcupdate.h:__rcu_read_unlock
Cyclomatic Complexity 1 include/linux/rcupdate.h:synchronize_rcu
Cyclomatic Complexity 1 include/linux/rcutiny.h:rcu_is_watching
Cyclomatic Complexity 1 include/linux/rcupdate.h:rcu_lock_acquire
Cyclomatic Complexity 1 include/linux/rcupdate.h:rcu_lock_release
Cyclomatic Complexity 4 include/linux/rcupdate.h:rcu_read_lock
Cyclomatic Complexity 4 include/linux/rcupdate.h:rcu_read_unlock
Cyclomatic Complexity 3 include/linux/rculist.h:hlist_add_head_rcu
Cyclomatic Complexity 1 include/linux/kasan.h:kasan_kmalloc
Cyclomatic Complexity 28 include/linux/slab.h:kmalloc_index
Cyclomatic Complexity 1 include/linux/slab.h:kmem_cache_alloc_trace
Cyclomatic Complexity 1 include/linux/slab.h:kmalloc_order_trace
Cyclomatic Complexity 68 include/linux/slab.h:kmalloc_large
Cyclomatic Complexity 5 include/linux/slab.h:kmalloc
Cyclomatic Complexity 1 include/linux/skbuff.h:alloc_skb
Cyclomatic Complexity 1 include/linux/skbuff.h:skb_end_pointer
Cyclomatic Complexity 3 include/linux/skbuff.h:skb_cloned
Cyclomatic Complexity 1 include/linux/skbuff.h:skb_reset_transport_header
Cyclomatic Complexity 2 include/linux/skbuff.h:skb_orphan
Cyclomatic Complexity 1 include/linux/skbuff.h:skb_copy_datagram_msg
Cyclomatic Complexity 2 include/linux/skbuff.h:memcpy_from_msg
Cyclomatic Complexity 1 include/linux/seq_file.h:seq_user_ns
Cyclomatic Complexity 1 include/linux/seq_file_net.h:seq_file_net
Cyclomatic Complexity 1 include/net/net_namespace.h:read_pnet
Cyclomatic Complexity 1 include/linux/proc_fs.h:proc_create
Cyclomatic Complexity 4 include/net/netns/generic.h:net_generic
Cyclomatic Complexity 1 include/net/sock.h:sk_entry
Cyclomatic Complexity 1 include/net/sock.h:sk_unhashed
Cyclomatic Complexity 1 include/net/sock.h:sk_hashed
Cyclomatic Complexity 1 include/net/sock.h:sk_node_init
Cyclomatic Complexity 1 include/net/sock.h:__sk_del_node
Cyclomatic Complexity 2 include/net/sock.h:__sk_del_node_init
Cyclomatic Complexity 1 include/net/sock.h:sock_hold
Cyclomatic Complexity 1 include/net/sock.h:__sock_put
Cyclomatic Complexity 3 include/net/sock.h:sk_del_node_init
Cyclomatic Complexity 1 include/net/sock.h:sk_add_node_rcu
Cyclomatic Complexity 1 include/net/sock.h:sock_set_flag
Cyclomatic Complexity 2 include/net/sock.h:sock_flag
Cyclomatic Complexity 1 include/net/sock.h:sk_has_account
Cyclomatic Complexity 2 include/net/sock.h:sk_mem_charge
Cyclomatic Complexity 2 include/net/sock.h:sock_put
Cyclomatic Complexity 1 include/net/sock.h:sk_tx_queue_clear
Cyclomatic Complexity 1 include/net/sock.h:sk_set_socket
Cyclomatic Complexity 1 include/net/sock.h:sock_orphan
Cyclomatic Complexity 1 include/net/sock.h:sk_wmem_alloc_get
Cyclomatic Complexity 1 include/net/sock.h:sk_rmem_alloc_get
Cyclomatic Complexity 1 include/net/sock.h:skb_set_owner_r
Cyclomatic Complexity 5 include/net/sock.h:sock_recv_ts_and_drops
Cyclomatic Complexity 1 include/net/sock.h:sock_net
Cyclomatic Complexity 1 include/net/ipv6.h:ipv6_addr_equal
Cyclomatic Complexity 1 include/net/xfrm.h:xs_net
Cyclomatic Complexity 1 include/net/xfrm.h:xp_net
Cyclomatic Complexity 2 include/net/xfrm.h:xfrm_pol_put
Cyclomatic Complexity 1 include/net/xfrm.h:__xfrm_state_put
Cyclomatic Complexity 2 include/net/xfrm.h:xfrm_state_put
Cyclomatic Complexity 1 include/net/xfrm.h:xfrm_state_hold
Cyclomatic Complexity 1 include/net/xfrm.h:xfrm_state_kern
Cyclomatic Complexity 1 include/net/xfrm.h:xfrm6_addr_equal
Cyclomatic Complexity 2 include/net/xfrm.h:xfrm_addr_equal
Cyclomatic Complexity 1 include/net/xfrm.h:xfrm_policy_id2dir
Cyclomatic Complexity 1 net//key/af_key.c:pfkey_sk
Cyclomatic Complexity 2 net//key/af_key.c:pfkey_can_dump
Cyclomatic Complexity 1 net//key/af_key.c:pfkey_hdr_dup
Cyclomatic Complexity 4 net//key/af_key.c:verify_address_len
Cyclomatic Complexity 1 net//key/af_key.c:pfkey_sec_ctx_len
Cyclomatic Complexity 3 net//key/af_key.c:verify_sec_ctx_len
Cyclomatic Complexity 2 net//key/af_key.c:pfkey_sadb2xfrm_user_sec_ctx
Cyclomatic Complexity 4 net//key/af_key.c:present_and_same_family
Cyclomatic Complexity 11 net//key/af_key.c:parse_exthdrs
Cyclomatic Complexity 5 net//key/af_key.c:pfkey_satype2proto
Cyclomatic Complexity 4 net//key/af_key.c:pfkey_proto2satype
vim +3836 net//key/af_key.c
61145aa1 Pavel Emelyanov 2008-02-09 3820 {
61145aa1 Pavel Emelyanov 2008-02-09 3821 return 0;
61145aa1 Pavel Emelyanov 2008-02-09 3822 }
61145aa1 Pavel Emelyanov 2008-02-09 3823
2c8c1e72 Alexey Dobriyan 2010-01-17 3824 static inline void pfkey_exit_proc(struct net *net)
61145aa1 Pavel Emelyanov 2008-02-09 3825 {
61145aa1 Pavel Emelyanov 2008-02-09 3826 }
^1da177e Linus Torvalds 2005-04-16 3827 #endif
^1da177e Linus Torvalds 2005-04-16 3828
^1da177e Linus Torvalds 2005-04-16 3829 static struct xfrm_mgr pfkeyv2_mgr =
^1da177e Linus Torvalds 2005-04-16 3830 {
^1da177e Linus Torvalds 2005-04-16 3831 .notify = pfkey_send_notify,
^1da177e Linus Torvalds 2005-04-16 3832 .acquire = pfkey_send_acquire,
^1da177e Linus Torvalds 2005-04-16 3833 .compile_policy = pfkey_compile_policy,
^1da177e Linus Torvalds 2005-04-16 3834 .new_mapping = pfkey_send_new_mapping,
26b15dad Jamal Hadi Salim 2005-06-18 3835 .notify_policy = pfkey_send_policy_notify,
08de61be Shinta Sugimoto 2007-02-08 @3836 .migrate = pfkey_send_migrate,
0f24558e Horia Geanta 2014-02-12 3837 .is_alive = pfkey_is_alive,
^1da177e Linus Torvalds 2005-04-16 3838 };
^1da177e Linus Torvalds 2005-04-16 3839
3fa87a32 Alexey Dobriyan 2008-11-25 3840 static int __net_init pfkey_net_init(struct net *net)
3fa87a32 Alexey Dobriyan 2008-11-25 3841 {
23c049ca Eric W. Biederman 2009-11-29 3842 struct netns_pfkey *net_pfkey = net_generic(net, pfkey_net_id);
3fa87a32 Alexey Dobriyan 2008-11-25 3843 int rv;
3fa87a32 Alexey Dobriyan 2008-11-25 3844
:::::: The code at line 3836 was first introduced by commit
:::::: 08de61beab8a21c8e0b3906a97defda5f1f66ece [PFKEYV2]: Extension for dynamic update of endpoint address(es)
:::::: TO: Shinta Sugimoto <shinta.sugimoto@ericsson.com>
:::::: CC: David S. Miller <davem@davemloft.net>
---
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: 26678 bytes --]
^ permalink raw reply
* Re: [PATCH v1 1/2] net: emac: fix reset timeout with AR8035 phy
From: kbuild test robot @ 2017-06-06 5:00 UTC (permalink / raw)
To: Christian Lamparter
Cc: kbuild-all, netdev, David S . Miller, Ivan Mikhaylov, Chris Blake
In-Reply-To: <635dd014238af6f48c4169439b7ac161e80de1b7.1496695540.git.chunkeey@googlemail.com>
[-- Attachment #1: Type: text/plain, Size: 1511 bytes --]
Hi Christian,
[auto build test ERROR on net-next/master]
[also build test ERROR on v4.12-rc4 next-20170605]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Christian-Lamparter/net-emac-fix-reset-timeout-with-AR8035-phy/20170606-113953
config: powerpc-allmodconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc
All errors (new ones prefixed by >>):
drivers/net//ethernet/ibm/emac/core.c: In function 'emac_reset':
>> drivers/net//ethernet/ibm/emac/core.c:414:4: error: label 'do_retry' used but not defined
goto do_retry;
^~~~
vim +/do_retry +414 drivers/net//ethernet/ibm/emac/core.c
408 return 0;
409 } else {
410 if (emac_has_feature(dev, EMAC_FTR_460EX_PHY_CLK_FIX) &&
411 !try_internal_clock) {
412 /* do a retry with the internal clock */
413 try_internal_clock = true;
> 414 goto do_retry;
415 } else {
416 emac_report_timeout_error(dev, "reset timeout");
417 dev->reset_failed = 1;
---
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: 53803 bytes --]
^ permalink raw reply
* Re: [PATCH net 3/3] netvsc: fix RCU warning from set_multicast
From: kbuild test robot @ 2017-06-06 5:17 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: kbuild-all, davem, netdev, Stephen Hemminger
In-Reply-To: <20170605211010.9571-4-sthemmin@microsoft.com>
[-- Attachment #1: Type: text/plain, Size: 2693 bytes --]
Hi Stephen,
[auto build test ERROR on net/master]
url: https://github.com/0day-ci/linux/commits/Stephen-Hemminger/netvsc-bug-fixes/20170606-120730
config: x86_64-allyesdebian (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All error/warnings (new ones prefixed by >>):
drivers/net//hyperv/netvsc_drv.c: In function 'do_set_multicast':
drivers/net//hyperv/netvsc_drv.c:70:2: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
if (nvdev)
^~
drivers/net//hyperv/netvsc_drv.c:73:3: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'
if (rdev) {
^~
drivers/net//hyperv/netvsc_drv.c: At top level:
>> drivers/net//hyperv/netvsc_drv.c:84:2: warning: data definition has no type or storage class
rtnl_unlock();
^~~~~~~~~~~
>> drivers/net//hyperv/netvsc_drv.c:84:2: error: type defaults to 'int' in declaration of 'rtnl_unlock' [-Werror=implicit-int]
>> drivers/net//hyperv/netvsc_drv.c:84:2: error: function declaration isn't a prototype [-Werror=strict-prototypes]
>> drivers/net//hyperv/netvsc_drv.c:84:2: error: conflicting types for 'rtnl_unlock'
In file included from include/linux/inetdevice.h:13:0,
from drivers/net//hyperv/netvsc_drv.c:30:
include/linux/rtnetlink.h:28:13: note: previous declaration of 'rtnl_unlock' was here
extern void rtnl_unlock(void);
^~~~~~~~~~~
>> drivers/net//hyperv/netvsc_drv.c:85:1: error: expected identifier or '(' before '}' token
}
^
cc1: some warnings being treated as errors
vim +84 drivers/net//hyperv/netvsc_drv.c
64 struct net_device *ndev = hv_get_drvdata(device_obj);
65 struct netvsc_device *nvdev;
66 struct rndis_device *rdev;
67
68 rtnl_lock();
69 nvdev = rtnl_dereference(ndevctx->nvdev);
> 70 if (nvdev)
71 rdev = nvdev->extension;
72
> 73 if (rdev) {
74 if (ndev->flags & IFF_PROMISC)
75 rndis_filter_set_packet_filter(rdev,
76 NDIS_PACKET_TYPE_PROMISCUOUS);
77 else
78 rndis_filter_set_packet_filter(rdev,
79 NDIS_PACKET_TYPE_BROADCAST |
80 NDIS_PACKET_TYPE_ALL_MULTICAST |
81 NDIS_PACKET_TYPE_DIRECTED);
82 }
83 }
> 84 rtnl_unlock();
> 85 }
86
87 static void netvsc_set_multicast_list(struct net_device *net)
88 {
---
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: 38856 bytes --]
^ permalink raw reply
* Re: [PATCH net 3/3] netvsc: fix RCU warning from set_multicast
From: kbuild test robot @ 2017-06-06 5:24 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: kbuild-all, davem, netdev, Stephen Hemminger
In-Reply-To: <20170605211010.9571-4-sthemmin@microsoft.com>
[-- Attachment #1: Type: text/plain, Size: 2799 bytes --]
Hi Stephen,
[auto build test WARNING on net/master]
url: https://github.com/0day-ci/linux/commits/Stephen-Hemminger/netvsc-bug-fixes/20170606-120730
config: x86_64-randconfig-x007-201723 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers/net//hyperv/netvsc_drv.c: In function 'do_set_multicast':
>> drivers/net//hyperv/netvsc_drv.c:70:2: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
if (nvdev)
^~
drivers/net//hyperv/netvsc_drv.c:73:3: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'
if (rdev) {
^~
drivers/net//hyperv/netvsc_drv.c: At top level:
drivers/net//hyperv/netvsc_drv.c:84:2: warning: data definition has no type or storage class
rtnl_unlock();
^~~~~~~~~~~
drivers/net//hyperv/netvsc_drv.c:84:2: error: type defaults to 'int' in declaration of 'rtnl_unlock' [-Werror=implicit-int]
drivers/net//hyperv/netvsc_drv.c:84:2: error: function declaration isn't a prototype [-Werror=strict-prototypes]
drivers/net//hyperv/netvsc_drv.c:84:2: error: conflicting types for 'rtnl_unlock'
In file included from include/linux/inetdevice.h:13:0,
from drivers/net//hyperv/netvsc_drv.c:30:
include/linux/rtnetlink.h:28:13: note: previous declaration of 'rtnl_unlock' was here
extern void rtnl_unlock(void);
^~~~~~~~~~~
drivers/net//hyperv/netvsc_drv.c:85:1: error: expected identifier or '(' before '}' token
}
^
cc1: some warnings being treated as errors
vim +/if +70 drivers/net//hyperv/netvsc_drv.c
54
55 static int debug = -1;
56 module_param(debug, int, S_IRUGO);
57 MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
58
59 static void do_set_multicast(struct work_struct *w)
60 {
61 struct net_device_context *ndevctx =
62 container_of(w, struct net_device_context, work);
63 struct hv_device *device_obj = ndevctx->device_ctx;
64 struct net_device *ndev = hv_get_drvdata(device_obj);
65 struct netvsc_device *nvdev;
66 struct rndis_device *rdev;
67
68 rtnl_lock();
69 nvdev = rtnl_dereference(ndevctx->nvdev);
> 70 if (nvdev)
71 rdev = nvdev->extension;
72
73 if (rdev) {
74 if (ndev->flags & IFF_PROMISC)
75 rndis_filter_set_packet_filter(rdev,
76 NDIS_PACKET_TYPE_PROMISCUOUS);
77 else
78 rndis_filter_set_packet_filter(rdev,
---
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: 30708 bytes --]
^ permalink raw reply
* Re: [PATCH net] net: bridge: fix a null pointer dereference in br_afspec
From: Roopa Prabhu @ 2017-06-06 5:28 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: netdev@vger.kernel.org, bridge, garsilva, davem@davemloft.net
In-Reply-To: <1496701584-26855-1-git-send-email-nikolay@cumulusnetworks.com>
On Mon, Jun 5, 2017 at 3:26 PM, Nikolay Aleksandrov
<nikolay@cumulusnetworks.com> wrote:
> We might call br_afspec() with p == NULL which is a valid use case if
> the action is on the bridge device itself, but the bridge tunnel code
> dereferences the p pointer without checking, so check if p is null
> first.
>
> Reported-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
> Fixes: efa5356b0d97 ("bridge: per vlan dst_metadata netlink support")
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Acked-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Thanks Nikolay.
^ permalink raw reply
* Re: Stmmac: fix for hw timestamp of GMAC 3 unit
From: Giuseppe CAVALLARO @ 2017-06-06 5:43 UTC (permalink / raw)
To: Mario Molitor, alexandre.torgue; +Cc: netdev, linux-kernel
In-Reply-To: <trinity-32054cc5-4d62-4e1d-a846-3c34dcf24545-1496700699842@3capp-webde-bap31>
Hi Mario
thanks for your tests, and, at first glance, your patches seem to be
sensible so,
please, send the changes as patches for net.git kernel.
Regards
Peppe
On 6/6/2017 12:11 AM, Mario Molitor wrote:
> Dear stmmac maintainer group,
>
> I have found an problem in stmmac driver of linux kernel and I hope for a fix in the mainline kernel.
> At the moment I have two patch files which fix this problem for me.
> The problem seems created with the commit d2042052a0aa6a54f01a0c9e14243ec040b100e2 and ba1ffd74df74a9efa5290f87632a0ed55f1aa387 has breakage the functionality of GMAC3 unit.
> I assume that these commits were only tested with a GMAC4 unit.
> I have got seen this problem with execution of ptp4l daemon on system with linux 4.11 Kernel.
>
> ===============================================================================
> root@QuantumXsoc:~ ptp4l -f /etc/ptp.cfg -i eth0 -m
> ptp4l[47.928]: selected /dev/ptp0 as PTP clock
> ptp4l[47.937]: port 1: INITIALIZING to LISTENING on INITIALIZE
> ptp4l[47.938]: port 0: INITIALIZING to LISTENING on INITIALIZE
> ptp4l[47.938]: port 1: link up
> [ 48.282709] socfpga-dwmac ff702000.ethernet eth0: get valid RX hw timestamp 0
> [ 48.316316] socfpga-dwmac ff702000.ethernet eth0: get valid RX hw timestamp 0
> [ 48.340260] socfpga-dwmac ff702000.ethernet eth0: get valid RX hw timestamp 0
> [ 48.456738] socfpga-dwmac ff702000.ethernet eth0: get valid RX hw timestamp 0
> ptp4l[48.457]: port 1: received DELAY_REQ without timestamp
> [ 48.488442] socfpga-dwmac ff702000.ethernet eth0: get valid RX hw timestamp 0
> [ 48.495599] socfpga-dwmac ff702000.ethernet eth0: get valid RX hw timestamp 0
> ptp4l[48.489]: port 1: received SYNC without timestamp
> ....
> ================================================================================
>
> I have found two kind of problems and for this two patches (based on the 4.11 kernel) which fix this problem.
>
> 1.) PTP_TCR_SNAPTYPSEL_1
>
> The first problem was for my point of view the change of definition PTP_TCR_SNAPTYPSEL_1. I think according the
> CYCLON V documention only the bit 16 of snaptypesel should be set. (more information see Table 17-20 (cv_5v4.pdf) : Timestamp Snapshot Dependency on Register Bits)
> I believe that the GMAC4 have another necessary definition.
>
> ( patch 0001-stmmac-fix-ptp-header-for-GMAC3-hw-timestamp.patch )
> ================================================================================================
> >From 2d54d58dc8548d98572eb5fbfe488ec59b4c0ef5 Mon Sep 17 00:00:00 2001
> From: Mario Molitor <mario_molitor@web.de>
> Date: Mon, 5 Jun 2017 18:58:49 +0200
> Subject: [PATCH 1/2] stmmac: fix ptp header for GMAC3 hw timestamp
>
> According the CYCLON V documention only the bit 16 of snaptypesel should set.
> (more information see Table 17-20 (cv_5v4.pdf) : Timestamp Snapshot Dependency on Register Bits)
>
> fixed: d2042052a0aa6a54f01a0c9e14243ec040b100e2
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 15 ++++++++++++---
> drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h | 3 ++-
> 2 files changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 4498a38..13a1ac9 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -471,7 +471,10 @@ static int stmmac_hwtstamp_ioctl(struct net_device *dev, struct ifreq *ifr)
> /* PTP v1, UDP, any kind of event packet */
> config.rx_filter = HWTSTAMP_FILTER_PTP_V1_L4_EVENT;
> /* take time stamp for all event messages */
> - snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
> + if (priv->plat->has_gmac4)
> + snap_type_sel = PTP_GMAC4_TCR_SNAPTYPSEL_1;
> + else
> + snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
>
> ptp_over_ipv4_udp = PTP_TCR_TSIPV4ENA;
> ptp_over_ipv6_udp = PTP_TCR_TSIPV6ENA;
> @@ -503,7 +506,10 @@ static int stmmac_hwtstamp_ioctl(struct net_device *dev, struct ifreq *ifr)
> config.rx_filter = HWTSTAMP_FILTER_PTP_V2_L4_EVENT;
> ptp_v2 = PTP_TCR_TSVER2ENA;
> /* take time stamp for all event messages */
> - snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
> + if (priv->plat->has_gmac4)
> + snap_type_sel = PTP_GMAC4_TCR_SNAPTYPSEL_1;
> + else
> + snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
>
> ptp_over_ipv4_udp = PTP_TCR_TSIPV4ENA;
> ptp_over_ipv6_udp = PTP_TCR_TSIPV6ENA;
> @@ -537,7 +543,10 @@ static int stmmac_hwtstamp_ioctl(struct net_device *dev, struct ifreq *ifr)
> config.rx_filter = HWTSTAMP_FILTER_PTP_V2_EVENT;
> ptp_v2 = PTP_TCR_TSVER2ENA;
> /* take time stamp for all event messages */
> - snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
> + if (priv->plat->has_gmac4)
> + snap_type_sel = PTP_GMAC4_TCR_SNAPTYPSEL_1;
> + else
> + snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
>
> ptp_over_ipv4_udp = PTP_TCR_TSIPV4ENA;
> ptp_over_ipv6_udp = PTP_TCR_TSIPV6ENA;
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h
> index 48fb72f..f4b31d6 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h
> @@ -59,7 +59,8 @@
> /* Enable Snapshot for Messages Relevant to Master */
> #define PTP_TCR_TSMSTRENA BIT(15)
> /* Select PTP packets for Taking Snapshots */
> -#define PTP_TCR_SNAPTYPSEL_1 GENMASK(17, 16)
> +#define PTP_TCR_SNAPTYPSEL_1 BIT(16)
> +#define PTP_GMAC4_TCR_SNAPTYPSEL_1 GENMASK(17, 16)
> /* Enable MAC address for PTP Frame Filtering */
> #define PTP_TCR_TSENMACADDR BIT(18)
>
^ permalink raw reply
* Re: [PATCH 2/2] xfrm: add UDP encapsulation port in migrate message
From: kbuild test robot @ 2017-06-06 6:04 UTC (permalink / raw)
To: Antony Antony
Cc: kbuild-all, netdev, Antony Antony, Steffen Klassert, Herbert Xu,
David S . Miller, Richard Guy Briggs
In-Reply-To: <20170605215625.11043-3-antony@phenome.org>
[-- Attachment #1: Type: text/plain, Size: 3100 bytes --]
Hi Antony,
[auto build test WARNING on ipsec-next/master]
[also build test WARNING on v4.12-rc4 next-20170605]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Antony-Antony/add-udp-encapsulation-port-to-xfrm_do_migrate/20170606-114911
base: https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git master
config: m68k-sun3_defconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 4.9.0
reproduce:
wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k
All warnings (new ones prefixed by >>):
>> net/key/af_key.c:3836:2: warning: initialization from incompatible pointer type
.migrate = pfkey_send_migrate,
^
net/key/af_key.c:3836:2: warning: (near initialization for 'pfkeyv2_mgr.migrate')
vim +3836 net/key/af_key.c
61145aa1 Pavel Emelyanov 2008-02-09 3820 {
61145aa1 Pavel Emelyanov 2008-02-09 3821 return 0;
61145aa1 Pavel Emelyanov 2008-02-09 3822 }
61145aa1 Pavel Emelyanov 2008-02-09 3823
2c8c1e72 Alexey Dobriyan 2010-01-17 3824 static inline void pfkey_exit_proc(struct net *net)
61145aa1 Pavel Emelyanov 2008-02-09 3825 {
61145aa1 Pavel Emelyanov 2008-02-09 3826 }
^1da177e Linus Torvalds 2005-04-16 3827 #endif
^1da177e Linus Torvalds 2005-04-16 3828
^1da177e Linus Torvalds 2005-04-16 3829 static struct xfrm_mgr pfkeyv2_mgr =
^1da177e Linus Torvalds 2005-04-16 3830 {
^1da177e Linus Torvalds 2005-04-16 3831 .notify = pfkey_send_notify,
^1da177e Linus Torvalds 2005-04-16 3832 .acquire = pfkey_send_acquire,
^1da177e Linus Torvalds 2005-04-16 3833 .compile_policy = pfkey_compile_policy,
^1da177e Linus Torvalds 2005-04-16 3834 .new_mapping = pfkey_send_new_mapping,
26b15dad Jamal Hadi Salim 2005-06-18 3835 .notify_policy = pfkey_send_policy_notify,
08de61be Shinta Sugimoto 2007-02-08 @3836 .migrate = pfkey_send_migrate,
0f24558e Horia Geanta 2014-02-12 3837 .is_alive = pfkey_is_alive,
^1da177e Linus Torvalds 2005-04-16 3838 };
^1da177e Linus Torvalds 2005-04-16 3839
3fa87a32 Alexey Dobriyan 2008-11-25 3840 static int __net_init pfkey_net_init(struct net *net)
3fa87a32 Alexey Dobriyan 2008-11-25 3841 {
23c049ca Eric W. Biederman 2009-11-29 3842 struct netns_pfkey *net_pfkey = net_generic(net, pfkey_net_id);
3fa87a32 Alexey Dobriyan 2008-11-25 3843 int rv;
3fa87a32 Alexey Dobriyan 2008-11-25 3844
:::::: The code at line 3836 was first introduced by commit
:::::: 08de61beab8a21c8e0b3906a97defda5f1f66ece [PFKEYV2]: Extension for dynamic update of endpoint address(es)
:::::: TO: Shinta Sugimoto <shinta.sugimoto@ericsson.com>
:::::: CC: David S. Miller <davem@davemloft.net>
---
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: 12002 bytes --]
^ permalink raw reply
* Re: [PATCH] net: ethoc: enable NAPI before poll may be scheduled
From: Tobias Klauser @ 2017-06-06 6:05 UTC (permalink / raw)
To: Max Filippov
Cc: netdev, David S. Miller, Florian Fainelli, Thierry Reding, stable
In-Reply-To: <1496712676-11862-1-git-send-email-jcmvbkbc@gmail.com>
On 2017-06-06 at 03:31:16 +0200, Max Filippov <jcmvbkbc@gmail.com> wrote:
> ethoc_reset enables device interrupts, ethoc_interrupt may schedule a
> NAPI poll before NAPI is enabled in the ethoc_open, which results in
> device being unable to send or receive anything until it's closed and
> reopened. In case the device is flooded with ingress packets it may be
> unable to recover at all.
> Move napi_enable above ethoc_reset in the ethoc_open to fix that.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Reviewed-by: Tobias Klauser <tklauser@distanz.ch>
^ permalink raw reply
* [PATCH net-next] tun: use symmetric hash
From: Jason Wang @ 2017-06-06 6:09 UTC (permalink / raw)
To: netdev, linux-kernel; +Cc: mst, Jason Wang
Tun actually expects a symmetric hash for queue selecting to work
correctly, otherwise packets belongs to a single flow may be
redirected to the wrong queue. So this patch switch to use
__skb_get_hash_symmetric().
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/tun.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index f8041f9c..fe660e5 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -465,7 +465,7 @@ static u16 tun_select_queue(struct net_device *dev, struct sk_buff *skb,
rcu_read_lock();
numqueues = ACCESS_ONCE(tun->numqueues);
- txq = skb_get_hash(skb);
+ txq = __skb_get_hash_symmetric(skb);
if (txq) {
e = tun_flow_find(&tun->flows[tun_hashfn(txq)], txq);
if (e) {
@@ -867,7 +867,7 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
*/
__u32 rxhash;
- rxhash = skb_get_hash(skb);
+ rxhash = __skb_get_hash_symmetric(skb);
if (rxhash) {
struct tun_flow_entry *e;
e = tun_flow_find(&tun->flows[tun_hashfn(rxhash)],
@@ -1334,7 +1334,7 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
skb_reset_network_header(skb);
skb_probe_transport_header(skb, 0);
- rxhash = skb_get_hash(skb);
+ rxhash = __skb_get_hash_symmetric(skb);
#ifndef CONFIG_4KSTACKS
tun_rx_batched(tun, tfile, skb, more);
#else
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next 00/16] nfp: ctrl vNIC
From: Jiri Pirko @ 2017-06-06 6:16 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev, oss-drivers
In-Reply-To: <20170606000157.17556-1-jakub.kicinski@netronome.com>
Tue, Jun 06, 2017 at 02:01:41AM CEST, jakub.kicinski@netronome.com wrote:
>Hi!
>
>This series adds the ability to use one vNIC as a control channel
>for passing messages to and from the application firmware. The
>implementation restructures the existing netdev vNIC code to be able
>to deal with nfp_nets with netdev pointer set to NULL. Control vNICs
>are not visible to userspace (other than for dumping ring state), and
>since they don't have netdevs we use a tasklet for RX and simple skb
>list for TX queuing.
>
>Due to special status of the control vNIC we have to reshuffle the
>init code a bit to make sure control vNIC will be fully brought up
>(and therefore communication with app FW can happen) before any netdev
>or port is visible to user space.
>
>FW will designate which vNIC is supposed to be used as control one
>by setting _pf%u_net_ctrl_bar symbol. Some FWs depend on metadata
>being prepended to control message, some prefer to look at queue ID
>to decide that something is a control message. Our implementation
>can cater to both.
>
>First two users of this code will be eBPF maps and flower offloads.
How do you actually do the configuration from the userspace? I did not
find it in the patches.
I'm not really sure that doing it using one "control netdevice" is the
correct way to go. The configuration is asic-wide, should be done by a
devlink parent handle which was introduced for that exact purpose.
Am I missing something? We need to sync in this. In mlxsw we need to do
some pre-netdev configuraton as well.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 2/3] PCI: Enable PCIe Relaxed Ordering if supported
From: Ding Tianhong @ 2017-06-06 6:09 UTC (permalink / raw)
To: Alexander Duyck
Cc: Casey Leedom, Ashok Raj, Bjorn Helgaas, Michael Werner,
Ganesh Goudar, Asit K Mallick, Patrick J Cramer,
Suravee Suthikulpanit, Bob Shaw, h, Amir Ancel, Gabriele Paoloni,
David Laight, Jeff Kirsher, Catalin Marinas, Will Deacon,
Mark Rutland, Robin Murphy, David Miller, linux-arm-kernel
In-Reply-To: <CAKgT0Uf_nRAmaAN+6AgY-01jYekgW9UM2wGwRfDTTDxGjd+otQ@mail.gmail.com>
On 2017/6/6 8:28, Alexander Duyck wrote:
> On Mon, Jun 5, 2017 at 6:33 AM, Ding Tianhong <dingtianhong@huawei.com> wrote:
>>
>>
>> On 2017/6/4 2:19, Alexander Duyck wrote:
>>> On Fri, Jun 2, 2017 at 9:04 PM, Ding Tianhong <dingtianhong@huawei.com> wrote:
>>>> The PCIe Device Control Register use the bit 4 to indicate that
>>>> whether the device is permitted to enable relaxed ordering or not.
>>>> But relaxed ordering is not safe for some platform which could only
>>>> use strong write ordering, so devices are allowed (but not required)
>>>> to enable relaxed ordering bit by default.
>>>>
>>>> If a platform support relaxed ordering but does not enable it by
>>>> default, enable it in the PCIe configuration. This allows some device
>>>> to send TLPs with the relaxed ordering attributes set, which may
>>>> improve the performance.
>>>>
>>>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>>>> ---
>>>> drivers/pci/pci.c | 42 ++++++++++++++++++++++++++++++++++++++++++
>>>> drivers/pci/probe.c | 11 +++++++++++
>>>> include/linux/pci.h | 3 +++
>>>> 3 files changed, 56 insertions(+)
>>>>
>>>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>>>> index b01bd5b..f57a374 100644
>>>> --- a/drivers/pci/pci.c
>>>> +++ b/drivers/pci/pci.c
>>>> @@ -4878,6 +4878,48 @@ int pcie_set_mps(struct pci_dev *dev, int mps)
>>>> EXPORT_SYMBOL(pcie_set_mps);
>>>>
>>>> /**
>>>> + * pcie_set_relaxed_ordering - set PCI Express relexed ordering bit
>>>> + * @dev: PCI device to query
>>>> + *
>>>> + * If possible sets relaxed ordering
>>>> + */
>>>> +int pcie_set_relaxed_ordering(struct pci_dev *dev)
>>>> +{
>>>> + return pcie_capability_set_word(dev, PCI_EXP_DEVCTL, PCI_EXP_DEVCTL_RELAX_EN);
>>>> +}
>>>> +EXPORT_SYMBOL(pcie_set_relaxed_ordering);
>>>> +
>>>> +/**
>>>> + * pcie_clear_relaxed_ordering - clear PCI Express relexed ordering bit
>>>> + * @dev: PCI device to query
>>>> + *
>>>> + * If possible clear relaxed ordering
>>>> + */
>>>> +int pcie_clear_relaxed_ordering(struct pci_dev *dev)
>>>> +{
>>>> + return pcie_capability_clear_word(dev, PCI_EXP_DEVCTL, PCI_EXP_DEVCTL_RELAX_EN);
>>>> +}
>>>> +EXPORT_SYMBOL(pcie_clear_relaxed_ordering);
>>>> +
>>>> +/**
>>>> + * pcie_get_relaxed_ordering - check PCI Express relexed ordering bit
>>>> + * @dev: PCI device to query
>>>> + *
>>>> + * Returns true if relaxed ordering is been set
>>>> + */
>>>> +int pcie_get_relaxed_ordering(struct pci_dev *dev)
>>>> +{
>>>> + u16 v;
>>>> +
>>>> + pcie_capability_read_word(dev, PCI_EXP_DEVCTL, &v);
>>>> +
>>>> + return (v & PCI_EXP_DEVCTL_RELAX_EN) >> 4;
>>>> +}
>>>> +EXPORT_SYMBOL(pcie_get_relaxed_ordering);
>>>> +
>>>> +/**
>>>> + * pcie_set_mps - set PCI Express maximum payload size
>>>> +/**
>>>> * pcie_get_minimum_link - determine minimum link settings of a PCI device
>>>> * @dev: PCI device to query
>>>> * @speed: storage for minimum speed
>>>> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
>>>> index 19c8950..aeb22b5 100644
>>>> --- a/drivers/pci/probe.c
>>>> +++ b/drivers/pci/probe.c
>>>> @@ -1701,6 +1701,16 @@ static void pci_configure_extended_tags(struct pci_dev *dev)
>>>> PCI_EXP_DEVCTL_EXT_TAG);
>>>> }
>>>>
>>>> +static void pci_configure_relaxed_ordering(struct pci_dev *dev)
>>>> +{
>>>> + int ret;
>>>> +
>>>> + if (dev && (dev->dev_flags & PCI_DEV_FLAGS_NO_RELAXED_ORDERING))
>>>
>>> So there is a minor issue here. The problem is this is only trying to
>>> modify relaxed ordering for the device itself. That isn't what we
>>> want. What we want is to modify it on all of the upstream port
>>> interfaces where there is something the path to the root complex that
>>> has an issue. So if the root complex has to set the
>>> NO_RELAXED_ORDERING flag on a root port, all of the interfaces below
>>> it that would be pushing traffic toward it should not have the relaxed
>>> ordering bit set.
>>>
>>> Also I am pretty sure this is a PCIe capability, not a PCI capability.
>>> You probably need to make sure you code is making this distinction
>>> which I don't know if it currently is. If you need an example of the
>>> kind of checks I am suggesting just take a look at
>>> pcie_configure_mps(). It is verifying the function is PCIe before
>>> attempting to make any updates. In your case you will probably also
>>> need to make sure there is a bus for you to walk up the chain of.
>>> Otherwise this shouldn't apply.
>>>
>>>
>>>> + pcie_set_relaxed_ordering(dev);
>>>> + else
>>>> + pcie_clear_relaxed_ordering(dev);
>>>> +}
>>>
>>> Also I am not a fan of the way this is handled currently. If you don't
>>> have relaxed ordering set then you don't need to do anything else, if
>>> you do have it set but there is no bus to walk up you shouldn't change
>>> it, and if there is a bus to walk up and you find that the root
>>> complex on that bus has the NO_RELAXED_ORDERING set you should clear
>>> it. Right now this code seems to be enabling relaxed ordering if the
>>> NO_RELAXED_ORDERING flag is set.
>>>
>>
>> Hi Alexander:
>>
>> I reconsidered your suggestion and found I miss something here,
>> decide to modify the configure police as your solution, I think
>> it is close to our goal.
>>
>> Thanks
>> Ding
>>
>> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
>> index 19c8950..68dee05 100644
>> --- a/drivers/pci/probe.c
>> +++ b/drivers/pci/probe.c
>> @@ -1701,6 +1701,45 @@ static void pci_configure_extended_tags(struct pci_dev *dev)
>> PCI_EXP_DEVCTL_EXT_TAG);
>> }
>>
>> +static int pcie_clearing_relaxed_ordering(struct pci_dev *dev, void *data)
>> +{
>> + int origin_ero;
>> +
>> + if (!pci_is_pcie(dev))
>> + return 0;
>> +
>> + origin_ero = pcie_get_relaxed_ordering(dev);
>> +
>> + /* If the releaxed ordering enable bit is not set, do nothing. */
>> + if (!origin_ero)
>> + return 0;
>> +
>> + pcie_clear_relaxed_ordering(dev);
>> +
>> + dev_info(&dev->dev, "Disable Relaxed Ordering\n");
>> +
>> + return 0;
>> +}
>> +
>> +static void pci_configure_relaxed_ordering(struct pci_dev *dev)
>> +{
>> + int origin_ero;
>> +
>> + if (!pci_is_pcie(dev))
>> + return;
>> +
>> + origin_ero = pcie_get_relaxed_ordering(dev);
>> + /* If the releaxed ordering enable bit is not set, do nothing. */
>> + if (!origin_ero)
>> + return;
>> +
>> + if (dev->dev_flags & PCI_DEV_FLAGS_NO_RELAXED_ORDERING) {
>> + pcie_clear_relaxed_ordering(dev);
>> + pci_walk_bus(dev->bus, pcie_clearing_relaxed_ordering, NULL);
>> + dev_info(&dev->dev, "Disable Relaxed Ordering\n");
>> + }
>> +}
>> +
>
> This is kind of backwards from what I was thinking. Basically what I
> would like to see is at probe time we should work our way up the PCIe
> buses checking to see if any device has
> PCI_DEV_FLAGS_NO_RELAXED_ORDERING set. The assumption is if we can't
> use relaxed ordering with the downstream facing port we probably
> shouldn't be enabling it on our upstream facing port. We don't want to
> be writing to other devices and such since we don't know what they
> need, we will only know what our device needs and if the root complex
> reports that it can't support relaxed ordering we should disable it
> for the device we are initializing and move on.
>
> You might use pcie_get_minimum_link as an example of what I am
> thinking. Basically what we should do is add a function that will
> return true if any of the devices above us do not support relaxed
> ordering, otherwise return false. Then based on that result if we get
> a return that indicates that relaxed ordering is not supported we
> should update our device to disable relaxed ordering. If the device
> above us doesn't exist, or isn't PCIe we should just exit and skip
> updating relaxed ordering since we are probably running in a guest.
>
I think I understand what you mean this time, if no obviously problem,
I will send next version base on this code, thanks.
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 19c8950..777fe5c 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1701,6 +1701,48 @@ static void pci_configure_extended_tags(struct pci_dev *dev)
PCI_EXP_DEVCTL_EXT_TAG);
}
+/**
+ * pci_dev_relaxed_ordering_disabled - check if the PCI device
+ * should disable the relaxed ordering attribute.
+ * @dev: PCI device
+ *
+ * Return true if any of the PCI devices above us do not support
+ * relaxed ordering.
+ */
+static int pcie_check_relaxed_ordering_status(struct pci_dev *dev)
+{
+ int ro_disabled = 0;
+
+ while(dev) {
+ if (dev->dev_flags & PCI_DEV_FLAGS_NO_RELAXED_ORDERING) {
+ ro_disabled = 1;
+ break;
+ }
+ dev = dev->bus->self;
+ }
+
+ return ro_disabled;
+}
+
+static void pci_configure_relaxed_ordering(struct pci_dev *dev)
+{
+ struct pci_dev *bridge = pci_upstream_bridge(dev);
+ int origin_ero;
+
+ if (!pci_is_pcie(dev) || !bridge || !pci_is_pcie(bridge))
+ return;
+
+ origin_ero = pcie_get_relaxed_ordering(dev);
+ /* If the releaxed ordering enable bit is not set, do nothing. */
+ if (!origin_ero)
+ return;
+
+ if (pcie_check_relaxed_ordering_status(dev)) {
+ pcie_clear_relaxed_ordering(dev);
+ dev_info(&dev->dev, "Disable Relaxed Ordering\n");
+ }
+}
+
>> static void pci_configure_device(struct pci_dev *dev)
>> {
>> struct hotplug_params hpp;
>> @@ -1708,6 +1747,7 @@ static void pci_configure_device(struct pci_dev *dev)
>>
>> pci_configure_mps(dev);
>> pci_configure_extended_tags(dev);
>> + pci_configure_relaxed_ordering(dev);
>>
>> memset(&hpp, 0, sizeof(hpp));
>> ret = pci_get_hp_params(dev, &hpp);
>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>>
>>
>>
>>>> +
>>>> static void pci_configure_device(struct pci_dev *dev)
>>>> {
>>>> struct hotplug_params hpp;
>>>> @@ -1708,6 +1718,7 @@ static void pci_configure_device(struct pci_dev *dev)
>>>>
>>>> pci_configure_mps(dev);
>>>> pci_configure_extended_tags(dev);
>>>> + pci_configure_relaxed_ordering(dev);
>>>>
>>>> memset(&hpp, 0, sizeof(hpp));
>>>> ret = pci_get_hp_params(dev, &hpp);
>>>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>>>> index e1e8428..84bd6af 100644
>>>> --- a/include/linux/pci.h
>>>> +++ b/include/linux/pci.h
>>>> @@ -1105,6 +1105,9 @@ int __pci_enable_wake(struct pci_dev *dev, pci_power_t state,
>>>> void pci_pme_wakeup_bus(struct pci_bus *bus);
>>>> void pci_d3cold_enable(struct pci_dev *dev);
>>>> void pci_d3cold_disable(struct pci_dev *dev);
>>>> +int pcie_set_relaxed_ordering(struct pci_dev *dev);
>>>> +int pcie_clear_relaxed_ordering(struct pci_dev *dev);
>>>> +int pcie_get_relaxed_ordering(struct pci_dev *dev);
>>>>
>>>> static inline int pci_enable_wake(struct pci_dev *dev, pci_power_t state,
>>>> bool enable)
>>>> --
>>>> 1.9.0
>>>>
>>>>
>>>
>>> .
>>>
>>
>
> .
>
^ permalink raw reply related
* Re: [PATCH] cxgb4: implement ndo_set_vf_rate()
From: Ganesh Goudar @ 2017-06-06 6:43 UTC (permalink / raw)
To: Mintz, Yuval
Cc: netdev@vger.kernel.org, davem@davemloft.net,
nirranjan@chelsio.com, kumaras@chelsio.com
In-Reply-To: <BLUPR0701MB2004623B3F087A8213B2AEBF8DCA0@BLUPR0701MB2004.namprd07.prod.outlook.com>
On Monday, June 06/05/17, 2017 at 14:03:14 +0000, Mintz, Yuval wrote:
> > + pktsize = be16_to_cpu(port_rpl.u.info.mtu);
> > + /* subtract ethhdr size and 4 bytes crc since, f/w appends it */
> > + pktsize = pktsize - sizeof(struct ethhdr) - 4;
> > + /* subtract ipv4 hdr size, tcp hdr size to get typical IPv4 MSS size */
> > + pktsize = pktsize - sizeof(struct iphdr) - sizeof(struct tcphdr);
> > + /* configure Traffic Class for rate-limiting */
> > + ret = t4_sched_params(adap, SCHED_CLASS_TYPE_PACKET,
> > + SCHED_CLASS_LEVEL_CL_RL,
> > + SCHED_CLASS_MODE_CLASS,
> > + SCHED_CLASS_RATEUNIT_BITS,
> > + SCHED_CLASS_RATEMODE_ABS,
> > + pi->port_id, class_id, 0,
> > + max_tx_rate * 1000, 0, pktsize);
>
> Does it mean you're achieving throughput limitation by
> limiting the PP/s?
By bits/sec.
^ permalink raw reply
* RE: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova
From: Ilan Tayari @ 2017-06-06 6:52 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Alexei Starovoitov, Saeed Mahameed, David S. Miller, Doug Ledford,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
jsorensen-b10kYP2dOMg@public.gmane.org, Andy Shevchenko,
linux-fpga-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Alan Tull,
yi1.li-VuQAYsv1563Yd54FQh9/CA@public.gmane.org, Boris Pismenny
In-Reply-To: <20170605151724.GA20182-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 3427 bytes --]
> -----Original Message-----
> From: Jason Gunthorpe [mailto:jgunthorpe@obsidianresearch.com]
> Subject: Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova
>
> On Sun, Jun 04, 2017 at 07:51:24AM +0000, Ilan Tayari wrote:
> > > From: Jason Gunthorpe [mailto:jgunthorpe@obsidianresearch.com]
> > > Subject: Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for
> Innova
> > >
> > > On Mon, May 29, 2017 at 04:09:06PM +0000, Ilan Tayari wrote:
> > >
> > > > > For IPSec, this is already in the kernel.
> > > > > See this patchset:
> > > > > http://www.mail-archive.com/netdev@vger.kernel.org/msg162876.html
> > > >
> > > > Sorry, I pointed at the RFC by mistake.
> > > >
> > > > This is the relevant pull request:
> > > > https://patchwork.ozlabs.org/patch/752707/
> > >
> > > This is connecting ipsec to a netdev, while Innova seems to be a
> >
> > Jason,
> >
> > "network connected ipsec accelerator configured using IP packets."
> > No. This is incorrect.
> > Where did you get that from?
>
> That is what you described to me - you said the only way to configure
> the FPGA was via IP packets in-band. It is not part of the NIC and the
> NIC only loads the FPGA bitstream.
>
> Maybe you should explain more how this works?
I think this is just a misunderstanding.
The FPGA is part of this NIC, not something external.
The fact that we configure the FPGA using special inband packets isn't
changing anything. IMO, it might have been any other bus on the card,
standard or proprietary, and the arguments for how to design the driver
would stay the same.
Note that these packets are not generated as IP packets at the host.
They are RoCE packets. The command payload is generated by the driver,
then the QP and RoCE headers are generates by the ConnectX ASIC. The packet
is then consumed by the FPGA.
On the way back, the response is generated by the FPGA, and consumed by
the ConnectX ASIC, with the response payload delivered to the QP in the
driver.
So neither the host stack nor the network are aware of them.
They exist momentarily only on the internal traces on the board and not
anywhere else.
>
> > So you configure it from userspace with regular IPSec 'ip xfrm
> > state' commands or over netlink with your favorite IKE daemon.
>
> But you don't give an ip xfrm configuration to the NIC when you submit
> the work request? By your description it sounded liked the FPGA
> pattern matches packets from the NIC side to apply the xfrm.
>
> Jason
I didn't want to dig into this, because it's not submitted yet.
But here's an example configuration flow for creating an IPSec SA:
* User gives 'ip xfrm state add' command in shell, with 'offload' argument
* iproute2 sends XFRM_MSG_NEWSA netlink message with XFRMA_OFFLOAD_DEV attribute
* Xfrm stack generates a new xfrm_state object and calls the netdevice's xdo_dev_state_add callback
* mlx5e driver formats HW-specific ADD_SA command packet and sends it over RoCE QP to FPGA
* FPGA adds the SA to its offloaded SADB, and sends a response packet for 'success'
That's pretty much it.
Does this help to understand what goes on?
I don't mind explaining further, but I think you will just see it in the
patchset when we submit.
Ilan.
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±ÙšŠ{ayº\x1dʇڙë,j\a¢f£¢·hš‹»öì\x17/oSc¾™Ú³9˜uÀ¦æå‰È&jw¨®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿïêäz¹Þ–Šàþf£¢·hšˆ§~ˆmš
^ permalink raw reply
* Re: [PATCH net-next 00/16] nfp: ctrl vNIC
From: Jakub Kicinski @ 2017-06-06 7:21 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, oss-drivers
In-Reply-To: <20170606061610.GA1911@nanopsycho>
On Tue, 6 Jun 2017 08:16:10 +0200, Jiri Pirko wrote:
> Tue, Jun 06, 2017 at 02:01:41AM CEST, jakub.kicinski@netronome.com wrote:
> >Hi!
> >
> >This series adds the ability to use one vNIC as a control channel
> >for passing messages to and from the application firmware. The
> >implementation restructures the existing netdev vNIC code to be able
> >to deal with nfp_nets with netdev pointer set to NULL. Control vNICs
> >are not visible to userspace (other than for dumping ring state), and
> >since they don't have netdevs we use a tasklet for RX and simple skb
> >list for TX queuing.
> >
> >Due to special status of the control vNIC we have to reshuffle the
> >init code a bit to make sure control vNIC will be fully brought up
> >(and therefore communication with app FW can happen) before any netdev
> >or port is visible to user space.
> >
> >FW will designate which vNIC is supposed to be used as control one
> >by setting _pf%u_net_ctrl_bar symbol. Some FWs depend on metadata
> >being prepended to control message, some prefer to look at queue ID
> >to decide that something is a control message. Our implementation
> >can cater to both.
> >
> >First two users of this code will be eBPF maps and flower offloads.
>
> How do you actually do the configuration from the userspace? I did not
> find it in the patches.
Yes, there is nothing interesting in those patches, really. It's all
internal to the driver. This set basically allows us to dedicate some
queue pairs to high-speed communication with the FW (sending commands,
populating/dumping eBPF and Flower tables).
The eBPF maps and Flower offload patches should follow in coming weeks.
> I'm not really sure that doing it using one "control netdevice" is the
> correct way to go.
The control queues are not exposed to user space at all. It's up to
the driver logic to generate and consume all messages passing on those
queues. I had to make this a separate series because of the amount
of code churn. I'm also not a fan of exposing control netdevices.
Reasons ranging from NetworkManager latching onto them (even if it's
configured not to) to someone inevitably trying to control the device
from user space with vendor commands and make the driver-kept state go
out of whack :/
> The configuration is asic-wide, should be done by a devlink parent
> handle which was introduced for that exact purpose.
>
> Am I missing something? We need to sync in this. In mlxsw we need to do
> some pre-netdev configuraton as well.
For programmable NICs we still need to come up with some API for setting
the target application/firmware name/adapter mode, but I don't think we
have any more fine-grained parameters to set per-device just yet.
I was thinking of either devlink, or perhaps, since I'm hearing people
want those to be persistent/written into flash, the recent MTD
discussion got me wondering if we should just expose the entire flash
and teach ethtool to modify the vendor-specific parameter table
directly in the flash. That seems like something that could quickly
get out of hand, though :S
What were your plans with pre-netdev config?
I hope this makes things slightly clearer, sorry for not doing a good
job on the cover letter :)
^ permalink raw reply
* [PATCH net] net: stmmac: fix completely hung TX when using TSO
From: Niklas Cassel @ 2017-06-06 7:25 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue; +Cc: Niklas Cassel, netdev, linux-kernel
stmmac_tso_allocator can fail to set the Last Descriptor bit
on a descriptor that actually was the last descriptor.
This happens when the buffer of the last descriptor ends
up having a size of exactly TSO_MAX_BUFF_SIZE.
When the IP eventually reaches the next last descriptor,
which actually has the bit set, the DMA will hang.
When the DMA hangs, we get a tx timeout, however,
since stmmac does not do a complete reset of the IP
in stmmac_tx_timeout, we end up in a state with
completely hung TX.
Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 68a188e74c54..440bea049a7f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2723,7 +2723,7 @@ static void stmmac_tso_allocator(struct stmmac_priv *priv, unsigned int des,
priv->hw->desc->prepare_tso_tx_desc(desc, 0, buff_size,
0, 1,
- (last_segment) && (buff_size < TSO_MAX_BUFF_SIZE),
+ (last_segment) && (tmp_len <= TSO_MAX_BUFF_SIZE),
0, 0);
tmp_len -= TSO_MAX_BUFF_SIZE;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH net 3/3] netvsc: fix RCU warning from set_multicast (fwd)
From: Julia Lawall @ 2017-06-06 7:52 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: davem, netdev, Stephen Hemminger, kbuild-all
Please check the indentation of lines 73 onward.
thanks,
julia
---------- Forwarded message ----------
Date: Tue, 6 Jun 2017 14:40:59 +0800
From: kbuild test robot <fengguang.wu@intel.com>
To: kbuild@01.org
Cc: Julia Lawall <julia.lawall@lip6.fr>
Subject: Re: [PATCH net 3/3] netvsc: fix RCU warning from set_multicast
CC: kbuild-all@01.org
In-Reply-To: <20170605211010.9571-4-sthemmin@microsoft.com>
TO: Stephen Hemminger <stephen@networkplumber.org>
CC: davem@davemloft.net
CC: netdev@vger.kernel.org, Stephen Hemminger <sthemmin@microsoft.com>
Hi Stephen,
[auto build test WARNING on net/master]
url: https://github.com/0day-ci/linux/commits/Stephen-Hemminger/netvsc-bug-fixes/20170606-120730
:::::: branch date: 3 hours ago
:::::: commit date: 3 hours ago
>> drivers/net/hyperv/netvsc_drv.c:71:2-26: code aligned with following code on line 73
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 65bcf34d2ae4e8a34c6b65dbd9efff1aee7050a2
vim +71 drivers/net/hyperv/netvsc_drv.c
65bcf34d Stephen Hemminger 2017-06-05 65 struct netvsc_device *nvdev;
d426b2e3 Haiyang Zhang 2011-11-30 66 struct rndis_device *rdev;
d426b2e3 Haiyang Zhang 2011-11-30 67
65bcf34d Stephen Hemminger 2017-06-05 68 rtnl_lock();
65bcf34d Stephen Hemminger 2017-06-05 69 nvdev = rtnl_dereference(ndevctx->nvdev);
65bcf34d Stephen Hemminger 2017-06-05 70 if (nvdev)
d426b2e3 Haiyang Zhang 2011-11-30 @71 rdev = nvdev->extension;
d426b2e3 Haiyang Zhang 2011-11-30 72
65bcf34d Stephen Hemminger 2017-06-05 @73 if (rdev) {
0a1275ca Vitaly Kuznetsov 2016-05-13 74 if (ndev->flags & IFF_PROMISC)
d426b2e3 Haiyang Zhang 2011-11-30 75 rndis_filter_set_packet_filter(rdev,
d426b2e3 Haiyang Zhang 2011-11-30 76 NDIS_PACKET_TYPE_PROMISCUOUS);
:::::: The code at line 71 was first introduced by commit
:::::: d426b2e3d91f8ec3203f8852e7ad0153b5dfdf71 net/hyperv: Add support for promiscuous mode setting
:::::: TO: Haiyang Zhang <haiyangz@microsoft.com>
:::::: CC: Greg Kroah-Hartman <gregkh@suse.de>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: [PATCH net] net: stmmac: fix completely hung TX when using TSO
From: Giuseppe CAVALLARO @ 2017-06-06 8:00 UTC (permalink / raw)
To: Niklas Cassel, Alexandre Torgue; +Cc: Niklas Cassel, netdev, linux-kernel
In-Reply-To: <20170606072501.16560-1-niklas.cassel@axis.com>
Hi Niklas
I get the point and I acked the patch but Alex, please, can you confirm
that this issue has never seen on your boxes where the TSO has been
fully tested? The initial development (commit f748be531) introduces
the following:
(last_segment) && (buff_size < TSO_MAX_BUFF_SIZE),
...
On 6/6/2017 9:25 AM, Niklas Cassel wrote:
> stmmac_tso_allocator can fail to set the Last Descriptor bit
> on a descriptor that actually was the last descriptor.
>
> This happens when the buffer of the last descriptor ends
> up having a size of exactly TSO_MAX_BUFF_SIZE.
>
> When the IP eventually reaches the next last descriptor,
> which actually has the bit set, the DMA will hang.
>
> When the DMA hangs, we get a tx timeout, however,
> since stmmac does not do a complete reset of the IP
> in stmmac_tx_timeout, we end up in a state with
> completely hung TX.
>
> Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 68a188e74c54..440bea049a7f 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -2723,7 +2723,7 @@ static void stmmac_tso_allocator(struct stmmac_priv *priv, unsigned int des,
>
> priv->hw->desc->prepare_tso_tx_desc(desc, 0, buff_size,
> 0, 1,
> - (last_segment) && (buff_size < TSO_MAX_BUFF_SIZE),
> + (last_segment) && (tmp_len <= TSO_MAX_BUFF_SIZE),
> 0, 0);
>
> tmp_len -= TSO_MAX_BUFF_SIZE;
Regards
Peppe
^ permalink raw reply
* Re: [PATCH v2] xfrm: fix xfrm_dev_event() missing when compile without CONFIG_XFRM_OFFLOAD
From: Steffen Klassert @ 2017-06-06 8:06 UTC (permalink / raw)
To: Hangbin Liu; +Cc: netdev, Guy Shapiro, David Miller
In-Reply-To: <1496300276-30901-1-git-send-email-liuhangbin@gmail.com>
On Thu, Jun 01, 2017 at 02:57:56PM +0800, Hangbin Liu wrote:
> In commit d77e38e612a0 ("xfrm: Add an IPsec hardware offloading API") we
> make xfrm_device.o only compiled when enable option CONFIG_XFRM_OFFLOAD.
> But this will make xfrm_dev_event() missing if we only enable default XFRM
> options.
>
> Then if we set down and unregister an interface with IPsec on it.
You should not be able to register an interface with IPsec offload
without CONFIG_XFRM_OFFLOAD.
> there
> will no xfrm_garbage_collect(), which will cause dev usage count hold and
> get error like:
>
> unregister_netdevice: waiting for <dev> to become free. Usage count = 4
Can you explain how to reproduce this?
^ permalink raw reply
* Re: [PATCH net-next 00/16] nfp: ctrl vNIC
From: Jiri Pirko @ 2017-06-06 8:23 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev, oss-drivers
In-Reply-To: <20170606002105.7a84432f@cakuba.netronome.com>
Tue, Jun 06, 2017 at 09:21:45AM CEST, kubakici@wp.pl wrote:
>On Tue, 6 Jun 2017 08:16:10 +0200, Jiri Pirko wrote:
>> Tue, Jun 06, 2017 at 02:01:41AM CEST, jakub.kicinski@netronome.com wrote:
>> >Hi!
>> >
>> >This series adds the ability to use one vNIC as a control channel
>> >for passing messages to and from the application firmware. The
>> >implementation restructures the existing netdev vNIC code to be able
>> >to deal with nfp_nets with netdev pointer set to NULL. Control vNICs
>> >are not visible to userspace (other than for dumping ring state), and
>> >since they don't have netdevs we use a tasklet for RX and simple skb
>> >list for TX queuing.
>> >
>> >Due to special status of the control vNIC we have to reshuffle the
>> >init code a bit to make sure control vNIC will be fully brought up
>> >(and therefore communication with app FW can happen) before any netdev
>> >or port is visible to user space.
>> >
>> >FW will designate which vNIC is supposed to be used as control one
>> >by setting _pf%u_net_ctrl_bar symbol. Some FWs depend on metadata
>> >being prepended to control message, some prefer to look at queue ID
>> >to decide that something is a control message. Our implementation
>> >can cater to both.
>> >
>> >First two users of this code will be eBPF maps and flower offloads.
>>
>> How do you actually do the configuration from the userspace? I did not
>> find it in the patches.
>
>Yes, there is nothing interesting in those patches, really. It's all
>internal to the driver. This set basically allows us to dedicate some
>queue pairs to high-speed communication with the FW (sending commands,
>populating/dumping eBPF and Flower tables).
>
>The eBPF maps and Flower offload patches should follow in coming weeks.
Okay. So you don't let the user to dicide for which purpose (bpf/flowe)
he wants to use the nic, right?
>
>> I'm not really sure that doing it using one "control netdevice" is the
>> correct way to go.
>
>The control queues are not exposed to user space at all. It's up to
>the driver logic to generate and consume all messages passing on those
>queues. I had to make this a separate series because of the amount
>of code churn. I'm also not a fan of exposing control netdevices.
>Reasons ranging from NetworkManager latching onto them (even if it's
>configured not to) to someone inevitably trying to control the device
>from user space with vendor commands and make the driver-kept state go
>out of whack :/
Okay, that got me confused. I thought that you want the control
netdevice. Now that is clear we both don't want to see that, I'm fine :)
>
>> The configuration is asic-wide, should be done by a devlink parent
>> handle which was introduced for that exact purpose.
>>
>> Am I missing something? We need to sync in this. In mlxsw we need to do
>> some pre-netdev configuraton as well.
>
>For programmable NICs we still need to come up with some API for setting
>the target application/firmware name/adapter mode, but I don't think we
>have any more fine-grained parameters to set per-device just yet.
>
>I was thinking of either devlink, or perhaps, since I'm hearing people
>want those to be persistent/written into flash, the recent MTD
>discussion got me wondering if we should just expose the entire flash
>and teach ethtool to modify the vendor-specific parameter table
>directly in the flash. That seems like something that could quickly
>get out of hand, though :S
Yeah, I'm not fan of the mtd exposing some fw internals. I believe that
for the config like yours (switching the operation mode of nic), we
should have well defined user api. And since this is per-device, not
per-netdev, devlink should be the vahicle to carry this.
>
>What were your plans with pre-netdev config?
We need to pass come initial resource division. Generally the consensus
is to have these options exposed through devlink, let the user configure
them all and then to have a trigger that would cause driver
re-orchestration according to the new values. The flow would look like
this:
-driver loads with defaults, inits hw and instantiates netdevs
-driver exposes config options via devlink
-user sets up the options
-user pushes the "go" trigger
-upon the trigger command, devlink calls the driver re-init callback
-driver shuts down the current instances, re-initializes hw,
re-instantiates the netdevs
Makes sense?
>
>I hope this makes things slightly clearer, sorry for not doing a good
>job on the cover letter :)
No worries :)
^ permalink raw reply
* RE: [PATCH v2 4/4] net: macb: Add hardware PTP support
From: Rafal Ozieblo @ 2017-06-06 8:54 UTC (permalink / raw)
To: Richard Cochran
Cc: David Miller, nicolas.ferre@atmel.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, harini.katakam@xilinx.com,
andrei.pistirica@microchip.com
In-Reply-To: <20170604205516.GA7848@localhost.localdomain>
> From: Richard Cochran [mailto:richardcochran@gmail.com]
> Sent: 4 czerwca 2017 22:55
> To: Rafal Ozieblo <rafalo@cadence.com>
> Cc: David Miller <davem@davemloft.net>; nicolas.ferre@atmel.com;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> harini.katakam@xilinx.com; andrei.pistirica@microchip.com
> Subject: Re: [PATCH v2 4/4] net: macb: Add hardware PTP support
>
> On Fri, Jun 02, 2017 at 03:28:10PM +0100, Rafal Ozieblo wrote:
>
> > +int gem_get_hwtst(struct net_device *dev, struct ifreq *rq)
> > +{
> > + struct macb *bp = netdev_priv(dev);
> > + struct hwtstamp_config *tstamp_config = &bp->tstamp_config;
> > +
> > + if ((bp->hw_dma_cap & HW_DMA_CAP_PTP) == 0)
> > + return -EFAULT;
>
> Segmentation fault? Really?
>
> ...
>
> > +int gem_set_hwtst(struct net_device *dev, struct ifreq *ifr, int cmd)
> > +{
> > + struct macb *bp = netdev_priv(dev);
> > + struct hwtstamp_config *tstamp_config = &bp->tstamp_config;
> > + enum macb_bd_control tx_bd_control = TSTAMP_DISABLED;
> > + enum macb_bd_control rx_bd_control = TSTAMP_DISABLED;
> > + u32 regval;
> > +
> > + if ((bp->hw_dma_cap & HW_DMA_CAP_PTP) == 0)
> > + return -EFAULT;
>
> here again
Would "ENOTSUP" be sufficient ?
>
> Thanks,
> Richard
Regards,
Rafal
^ permalink raw reply
* [net-next 00/11][pull request] 1GbE Intel Wired LAN Driver Updates 2017-06-06
From: Jeff Kirsher @ 2017-06-06 8:57 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann, jogreene
This series contains updates and fixes to e1000e and igb.
Matwey V Kornilov fixes an issue where igb_get_phy_id_82575() relies on
the fact that page 0 is already selected, but this is not the case after
igb_read_phy_reg_gs40g()/igb_write_phy_reg_gs40g() were removed in a
previous commit. This leads to initialization failure and some devices
not working. To fix the issue, explicitly select page 0 before first
access to PHY registers.
Arnd Bergmann modifies the driver to avoid a "defined but not used"
warning by removing #ifdefs and using __maybe_unused annotation instead
for new power management functions.
Jake provides most of the changes in the series, all around PTP and
timestamp fixes/updates. Resolved several race conditions based on
the hardware can only handle one transmit timestamp at a time, so
fix the locking logic, as well as create a statistic for "skipped"
timestamps to help administrators identify issues.
Benjamin Poirier provides 2 changes, first to igb to remove the
second argument to igb_update_stats() since it always passes the
same two arguments. So instead of having to pass the second argument,
just update the function to the necessary information from the adapter
structure. Second modifies the e1000e_get_stats64() call to
dev_get_stats() to avoid ethtool garbage being reported.
Konstantin Khlebnikov modifies e1000e to use disable_hardirq(), instead
of disable_irq() for MSIx vectors in e1000_netpoll().
The following are changes since commit 9d15e5cc8cb68326f7f89b76e04c834fe8e1a2db:
mdio: mux: fix an incorrect less than zero error check using a u32
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 1GbE
Arnd Bergmann (1):
igb: mark PM functions as __maybe_unused
Benjamin Poirier (2):
igb: Remove useless argument
e1000e: Don't return uninitialized stats
Jacob Keller (6):
e1000e: fix race condition around skb_tstamp_tx()
igb: fix race condition with PTP_TX_IN_PROGRESS bits
igb: avoid permanent lock of *_PTP_TX_IN_PROGRESS
e1000e: add statistic indicating number of skipped Tx timestamps
igb: add statistic indicating number of skipped Tx timestamps
igb: check for Tx timestamp timeouts during watchdog
Konstantin Khlebnikov (1):
e1000e: use disable_hardirq() also for MSIX vectors in e1000_netpoll()
Matwey V Kornilov (1):
igb: Explicitly select page 0 at initialization
drivers/net/ethernet/intel/e1000e/e1000.h | 1 +
drivers/net/ethernet/intel/e1000e/ethtool.c | 3 +-
drivers/net/ethernet/intel/e1000e/netdev.c | 39 ++++++++++++--------
drivers/net/ethernet/intel/igb/e1000_82575.c | 1 +
drivers/net/ethernet/intel/igb/igb.h | 4 ++-
drivers/net/ethernet/intel/igb/igb_ethtool.c | 3 +-
drivers/net/ethernet/intel/igb/igb_main.c | 54 ++++++++++++++++------------
drivers/net/ethernet/intel/igb/igb_ptp.c | 41 +++++++++++++++++++--
8 files changed, 103 insertions(+), 43 deletions(-)
--
2.12.2
^ permalink raw reply
* [net-next 02/11] igb: mark PM functions as __maybe_unused
From: Jeff Kirsher @ 2017-06-06 8:58 UTC (permalink / raw)
To: davem; +Cc: Arnd Bergmann, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20170606085809.78571-1-jeffrey.t.kirsher@intel.com>
From: Arnd Bergmann <arnd@arndb.de>
The new wake function is only used by the suspend/resume handlers that
are defined in inside of an #ifdef, which can cause this harmless
warning:
drivers/net/ethernet/intel/igb/igb_main.c:7988:13: warning: 'igb_deliver_wake_packet' defined but not used [-Wunused-function]
Removing the #ifdef, instead using a __maybe_unused annotation
simplifies the code and avoids the warning.
Fixes: b90fa8763560 ("igb: Enable reading of wake up packet")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/igb_main.c | 18 +++++-------------
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index 1cf74aa4ebd9..2d5bdb1fd37d 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -191,10 +191,7 @@ static int igb_disable_sriov(struct pci_dev *dev);
static int igb_pci_disable_sriov(struct pci_dev *dev);
#endif
-#ifdef CONFIG_PM
-#ifdef CONFIG_PM_SLEEP
static int igb_suspend(struct device *);
-#endif
static int igb_resume(struct device *);
static int igb_runtime_suspend(struct device *dev);
static int igb_runtime_resume(struct device *dev);
@@ -204,7 +201,6 @@ static const struct dev_pm_ops igb_pm_ops = {
SET_RUNTIME_PM_OPS(igb_runtime_suspend, igb_runtime_resume,
igb_runtime_idle)
};
-#endif
static void igb_shutdown(struct pci_dev *);
static int igb_pci_sriov_configure(struct pci_dev *dev, int num_vfs);
#ifdef CONFIG_IGB_DCA
@@ -8015,9 +8011,7 @@ static void igb_deliver_wake_packet(struct net_device *netdev)
netif_rx(skb);
}
-#ifdef CONFIG_PM
-#ifdef CONFIG_PM_SLEEP
-static int igb_suspend(struct device *dev)
+static int __maybe_unused igb_suspend(struct device *dev)
{
int retval;
bool wake;
@@ -8036,9 +8030,8 @@ static int igb_suspend(struct device *dev)
return 0;
}
-#endif /* CONFIG_PM_SLEEP */
-static int igb_resume(struct device *dev)
+static int __maybe_unused igb_resume(struct device *dev)
{
struct pci_dev *pdev = to_pci_dev(dev);
struct net_device *netdev = pci_get_drvdata(pdev);
@@ -8092,7 +8085,7 @@ static int igb_resume(struct device *dev)
return err;
}
-static int igb_runtime_idle(struct device *dev)
+static int __maybe_unused igb_runtime_idle(struct device *dev)
{
struct pci_dev *pdev = to_pci_dev(dev);
struct net_device *netdev = pci_get_drvdata(pdev);
@@ -8104,7 +8097,7 @@ static int igb_runtime_idle(struct device *dev)
return -EBUSY;
}
-static int igb_runtime_suspend(struct device *dev)
+static int __maybe_unused igb_runtime_suspend(struct device *dev)
{
struct pci_dev *pdev = to_pci_dev(dev);
int retval;
@@ -8124,11 +8117,10 @@ static int igb_runtime_suspend(struct device *dev)
return 0;
}
-static int igb_runtime_resume(struct device *dev)
+static int __maybe_unused igb_runtime_resume(struct device *dev)
{
return igb_resume(dev);
}
-#endif /* CONFIG_PM */
static void igb_shutdown(struct pci_dev *pdev)
{
--
2.12.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox