* Re: [RFC, PATCH 1/2, net-next] net: netsec: Use page_pool API
From: Ilias Apalodimas @ 2019-06-27 9:40 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: netdev, jaswinder.singh, ard.biesheuvel, bjorn.topel,
magnus.karlsson, daniel, ast, makita.toshiaki, jakub.kicinski,
john.fastabend, davem
In-Reply-To: <20190627113708.67a8575a@carbon>
Hi Jepser,
> On Tue, 25 Jun 2019 18:06:18 +0300
> Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote:
>
> > @@ -1059,7 +1059,23 @@ static void netsec_setup_tx_dring(struct netsec_priv *priv)
> > static int netsec_setup_rx_dring(struct netsec_priv *priv)
> > {
> > struct netsec_desc_ring *dring = &priv->desc_ring[NETSEC_RING_RX];
> > - int i;
> > + struct page_pool_params pp_params = { 0 };
> > + int i, err;
> > +
> > + pp_params.order = 0;
> > + /* internal DMA mapping in page_pool */
> > + pp_params.flags = PP_FLAG_DMA_MAP;
> > + pp_params.pool_size = DESC_NUM;
> > + pp_params.nid = cpu_to_node(0);
> > + pp_params.dev = priv->dev;
> > + pp_params.dma_dir = DMA_FROM_DEVICE;
>
> I was going to complain about this DMA_FROM_DEVICE, until I noticed
> that in next patch you have:
>
> pp_params.dma_dir = xdp_prog ? DMA_BIDIRECTIONAL : DMA_FROM_DEVICE;
True. Since the first patch only adds page_pool support, i wanted to be clear
that DMA_BIDIRECTIONAL is only needed for XDP use cases (and especially XDP_TX)
>
> Making a note here to help other reviewers.
Thanks
>
> > + dring->page_pool = page_pool_create(&pp_params);
> > + if (IS_ERR(dring->page_pool)) {
> > + err = PTR_ERR(dring->page_pool);
> > + dring->page_pool = NULL;
> > + goto err_out;
> > + }
> >
Cheers
/Ilias
^ permalink raw reply
* Re: [RFC, PATCH 1/2, net-next] net: netsec: Use page_pool API
From: Jesper Dangaard Brouer @ 2019-06-27 9:37 UTC (permalink / raw)
To: Ilias Apalodimas
Cc: netdev, jaswinder.singh, ard.biesheuvel, bjorn.topel,
magnus.karlsson, daniel, ast, makita.toshiaki, jakub.kicinski,
john.fastabend, davem, brouer
In-Reply-To: <1561475179-7686-2-git-send-email-ilias.apalodimas@linaro.org>
On Tue, 25 Jun 2019 18:06:18 +0300
Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote:
> @@ -1059,7 +1059,23 @@ static void netsec_setup_tx_dring(struct netsec_priv *priv)
> static int netsec_setup_rx_dring(struct netsec_priv *priv)
> {
> struct netsec_desc_ring *dring = &priv->desc_ring[NETSEC_RING_RX];
> - int i;
> + struct page_pool_params pp_params = { 0 };
> + int i, err;
> +
> + pp_params.order = 0;
> + /* internal DMA mapping in page_pool */
> + pp_params.flags = PP_FLAG_DMA_MAP;
> + pp_params.pool_size = DESC_NUM;
> + pp_params.nid = cpu_to_node(0);
> + pp_params.dev = priv->dev;
> + pp_params.dma_dir = DMA_FROM_DEVICE;
I was going to complain about this DMA_FROM_DEVICE, until I noticed
that in next patch you have:
pp_params.dma_dir = xdp_prog ? DMA_BIDIRECTIONAL : DMA_FROM_DEVICE;
Making a note here to help other reviewers.
> + dring->page_pool = page_pool_create(&pp_params);
> + if (IS_ERR(dring->page_pool)) {
> + err = PTR_ERR(dring->page_pool);
> + dring->page_pool = NULL;
> + goto err_out;
> + }
>
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net-next] xdp: xdp_umem: fix umem pages mapping for 32bits systems
From: kbuild test robot @ 2019-06-27 9:01 UTC (permalink / raw)
To: Ivan Khoronzhuk
Cc: kbuild-all, bjorn.topel, magnus.karlsson, davem, ast, daniel,
hawk, john.fastabend, netdev, bpf, xdp-newbies, linux-kernel,
Ivan Khoronzhuk
In-Reply-To: <20190626155911.13574-1-ivan.khoronzhuk@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1767 bytes --]
Hi Ivan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Ivan-Khoronzhuk/xdp-xdp_umem-fix-umem-pages-mapping-for-32bits-systems/20190627-135949
config: x86_64-randconfig-x004-201925 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-9) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All error/warnings (new ones prefixed by >>):
net//xdp/xdp_umem.c: In function 'xdp_umem_unmap_pages':
>> net//xdp/xdp_umem.c:177:3: error: implicit declaration of function 'kunmap'; did you mean 'vunmap'? [-Werror=implicit-function-declaration]
kunmap(umem->pgs[i]);
^~~~~~
vunmap
net//xdp/xdp_umem.c: In function 'xdp_umem_reg':
>> net//xdp/xdp_umem.c:384:25: error: implicit declaration of function 'kmap'; did you mean 'bmap'? [-Werror=implicit-function-declaration]
umem->pages[i].addr = kmap(umem->pgs[i]);
^~~~
bmap
>> net//xdp/xdp_umem.c:384:23: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
umem->pages[i].addr = kmap(umem->pgs[i]);
^
cc1: some warnings being treated as errors
vim +177 net//xdp/xdp_umem.c
171
172 static void xdp_umem_unmap_pages(struct xdp_umem *umem)
173 {
174 unsigned int i;
175
176 for (i = 0; i < umem->npgs; i++)
> 177 kunmap(umem->pgs[i]);
178 }
179
---
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: 28463 bytes --]
^ permalink raw reply
* [PATCH net-next v2] net: ethtool: Allow parsing ETHER_FLOW types when using flow_rule
From: Maxime Chevallier @ 2019-06-27 8:52 UTC (permalink / raw)
To: davem, Pablo Neira Ayuso, Florian Fainelli, Jiri Pirko,
Jakub Kicinski
Cc: Maxime Chevallier, netdev, linux-kernel, Antoine Tenart,
thomas.petazzoni
When parsing an ethtool_rx_flow_spec, users can specify an ethernet flow
which could contain matches based on the ethernet header, such as the
MAC address, the VLAN tag or the ethertype.
ETHER_FLOW uses the src and dst ethernet addresses, along with the
ethertype as keys. Matches based on the vlan tag are also possible, but
they are specified using the special FLOW_EXT flag.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
V2 : Add src and dst mac address parsing, as suggested by Pablo.
net/core/ethtool.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 4d1011b2e24f..6288e69e94fc 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -2883,6 +2883,30 @@ ethtool_rx_flow_rule_create(const struct ethtool_rx_flow_spec_input *input)
match->mask.basic.n_proto = htons(0xffff);
switch (fs->flow_type & ~(FLOW_EXT | FLOW_MAC_EXT | FLOW_RSS)) {
+ case ETHER_FLOW: {
+ const struct ethhdr *ether_spec, *ether_m_spec;
+
+ ether_spec = &fs->h_u.ether_spec;
+ ether_m_spec = &fs->m_u.ether_spec;
+
+ if (!is_zero_ether_addr(ether_m_spec->h_source)) {
+ ether_addr_copy(match->key.eth_addrs.src,
+ ether_spec->h_source);
+ ether_addr_copy(match->mask.eth_addrs.src,
+ ether_m_spec->h_source);
+ }
+ if (!is_zero_ether_addr(ether_m_spec->h_dest)) {
+ ether_addr_copy(match->key.eth_addrs.dst,
+ ether_spec->h_dest);
+ ether_addr_copy(match->mask.eth_addrs.dst,
+ ether_m_spec->h_dest);
+ }
+ if (ether_m_spec->h_proto) {
+ match->key.basic.n_proto = ether_spec->h_proto;
+ match->mask.basic.n_proto = ether_m_spec->h_proto;
+ }
+ }
+ break;
case TCP_V4_FLOW:
case UDP_V4_FLOW: {
const struct ethtool_tcpip4_spec *v4_spec, *v4_m_spec;
--
2.20.1
^ permalink raw reply related
* [PATCH net] igmp: fix memory leak in igmpv3_del_delrec()
From: Eric Dumazet @ 2019-06-27 8:27 UTC (permalink / raw)
To: David S . Miller
Cc: netdev, Eric Dumazet, Eric Dumazet, Hangbin Liu,
syzbot+6ca1abd0db68b5173a4f
im->tomb and/or im->sources might not be NULL, but we
currently overwrite their values blindly.
Using swap() will make sure the following call to kfree_pmc(pmc)
will properly free the psf structures.
Tested with the C repro provided by syzbot, which basically does :
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
setsockopt(3, SOL_IP, IP_ADD_MEMBERSHIP, "\340\0\0\2\177\0\0\1\0\0\0\0", 12) = 0
ioctl(3, SIOCSIFFLAGS, {ifr_name="lo", ifr_flags=0}) = 0
setsockopt(3, SOL_IP, IP_MSFILTER, "\340\0\0\2\177\0\0\1\1\0\0\0\1\0\0\0\377\377\377\377", 20) = 0
ioctl(3, SIOCSIFFLAGS, {ifr_name="lo", ifr_flags=IFF_UP}) = 0
exit_group(0) = ?
BUG: memory leak
unreferenced object 0xffff88811450f140 (size 64):
comm "softirq", pid 0, jiffies 4294942448 (age 32.070s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00 ................
00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................
backtrace:
[<00000000c7bad083>] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline]
[<00000000c7bad083>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<00000000c7bad083>] slab_alloc mm/slab.c:3326 [inline]
[<00000000c7bad083>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
[<000000009acc4151>] kmalloc include/linux/slab.h:547 [inline]
[<000000009acc4151>] kzalloc include/linux/slab.h:742 [inline]
[<000000009acc4151>] ip_mc_add1_src net/ipv4/igmp.c:1976 [inline]
[<000000009acc4151>] ip_mc_add_src+0x36b/0x400 net/ipv4/igmp.c:2100
[<000000004ac14566>] ip_mc_msfilter+0x22d/0x310 net/ipv4/igmp.c:2484
[<0000000052d8f995>] do_ip_setsockopt.isra.0+0x1795/0x1930 net/ipv4/ip_sockglue.c:959
[<000000004ee1e21f>] ip_setsockopt+0x3b/0xb0 net/ipv4/ip_sockglue.c:1248
[<0000000066cdfe74>] udp_setsockopt+0x4e/0x90 net/ipv4/udp.c:2618
[<000000009383a786>] sock_common_setsockopt+0x38/0x50 net/core/sock.c:3126
[<00000000d8ac0c94>] __sys_setsockopt+0x98/0x120 net/socket.c:2072
[<000000001b1e9666>] __do_sys_setsockopt net/socket.c:2083 [inline]
[<000000001b1e9666>] __se_sys_setsockopt net/socket.c:2080 [inline]
[<000000001b1e9666>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2080
[<00000000420d395e>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301
[<000000007fd83a4b>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes: 24803f38a5c0 ("igmp: do not remove igmp souce list info when set link down")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Hangbin Liu <liuhangbin@gmail.com>
Reported-by: syzbot+6ca1abd0db68b5173a4f@syzkaller.appspotmail.com
---
net/ipv4/igmp.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index a57f0d69eadb9bdcc4b2c4a82819d2dce44bf428..85107bf812f228ae34e767b2e440aec4776fbe6c 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -1228,12 +1228,8 @@ static void igmpv3_del_delrec(struct in_device *in_dev, struct ip_mc_list *im)
if (pmc) {
im->interface = pmc->interface;
if (im->sfmode == MCAST_INCLUDE) {
- im->tomb = pmc->tomb;
- pmc->tomb = NULL;
-
- im->sources = pmc->sources;
- pmc->sources = NULL;
-
+ swap(im->tomb, pmc->tomb);
+ swap(im->sources, pmc->sources);
for (psf = im->sources; psf; psf = psf->sf_next)
psf->sf_crcount = in_dev->mr_qrv ?: net->ipv4.sysctl_igmp_qrv;
} else {
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* memory leak in ip_mc_add_src (2)
From: syzbot @ 2019-06-27 8:17 UTC (permalink / raw)
To: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: 249155c2 Merge branch 'parisc-5.2-4' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=122594ada00000
kernel config: https://syzkaller.appspot.com/x/.config?x=1db8bd6825f9661c
dashboard link: https://syzkaller.appspot.com/bug?extid=6ca1abd0db68b5173a4f
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15dc46eea00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17ee5aada00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+6ca1abd0db68b5173a4f@syzkaller.appspotmail.com
executing program
executing program
executing program
executing program
BUG: memory leak
unreferenced object 0xffff88811450f140 (size 64):
comm "softirq", pid 0, jiffies 4294942448 (age 32.070s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00 ................
00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................
backtrace:
[<00000000c7bad083>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<00000000c7bad083>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<00000000c7bad083>] slab_alloc mm/slab.c:3326 [inline]
[<00000000c7bad083>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
[<000000009acc4151>] kmalloc include/linux/slab.h:547 [inline]
[<000000009acc4151>] kzalloc include/linux/slab.h:742 [inline]
[<000000009acc4151>] ip_mc_add1_src net/ipv4/igmp.c:1976 [inline]
[<000000009acc4151>] ip_mc_add_src+0x36b/0x400 net/ipv4/igmp.c:2100
[<000000004ac14566>] ip_mc_msfilter+0x22d/0x310 net/ipv4/igmp.c:2484
[<0000000052d8f995>] do_ip_setsockopt.isra.0+0x1795/0x1930
net/ipv4/ip_sockglue.c:959
[<000000004ee1e21f>] ip_setsockopt+0x3b/0xb0 net/ipv4/ip_sockglue.c:1248
[<0000000066cdfe74>] udp_setsockopt+0x4e/0x90 net/ipv4/udp.c:2618
[<000000009383a786>] sock_common_setsockopt+0x38/0x50
net/core/sock.c:3126
[<00000000d8ac0c94>] __sys_setsockopt+0x98/0x120 net/socket.c:2072
[<000000001b1e9666>] __do_sys_setsockopt net/socket.c:2083 [inline]
[<000000001b1e9666>] __se_sys_setsockopt net/socket.c:2080 [inline]
[<000000001b1e9666>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2080
[<00000000420d395e>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<000000007fd83a4b>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff88810ec5ab40 (size 64):
comm "softirq", pid 0, jiffies 4294943651 (age 20.040s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00 ................
00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................
backtrace:
[<00000000c7bad083>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<00000000c7bad083>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<00000000c7bad083>] slab_alloc mm/slab.c:3326 [inline]
[<00000000c7bad083>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
[<000000009acc4151>] kmalloc include/linux/slab.h:547 [inline]
[<000000009acc4151>] kzalloc include/linux/slab.h:742 [inline]
[<000000009acc4151>] ip_mc_add1_src net/ipv4/igmp.c:1976 [inline]
[<000000009acc4151>] ip_mc_add_src+0x36b/0x400 net/ipv4/igmp.c:2100
[<000000004ac14566>] ip_mc_msfilter+0x22d/0x310 net/ipv4/igmp.c:2484
[<0000000052d8f995>] do_ip_setsockopt.isra.0+0x1795/0x1930
net/ipv4/ip_sockglue.c:959
[<000000004ee1e21f>] ip_setsockopt+0x3b/0xb0 net/ipv4/ip_sockglue.c:1248
[<0000000066cdfe74>] udp_setsockopt+0x4e/0x90 net/ipv4/udp.c:2618
[<000000009383a786>] sock_common_setsockopt+0x38/0x50
net/core/sock.c:3126
[<00000000d8ac0c94>] __sys_setsockopt+0x98/0x120 net/socket.c:2072
[<000000001b1e9666>] __do_sys_setsockopt net/socket.c:2083 [inline]
[<000000001b1e9666>] __se_sys_setsockopt net/socket.c:2080 [inline]
[<000000001b1e9666>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2080
[<00000000420d395e>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<000000007fd83a4b>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888112a6e080 (size 64):
comm "softirq", pid 0, jiffies 4294944252 (age 14.030s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00 ................
00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................
backtrace:
[<00000000c7bad083>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<00000000c7bad083>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<00000000c7bad083>] slab_alloc mm/slab.c:3326 [inline]
[<00000000c7bad083>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
[<000000009acc4151>] kmalloc include/linux/slab.h:547 [inline]
[<000000009acc4151>] kzalloc include/linux/slab.h:742 [inline]
[<000000009acc4151>] ip_mc_add1_src net/ipv4/igmp.c:1976 [inline]
[<000000009acc4151>] ip_mc_add_src+0x36b/0x400 net/ipv4/igmp.c:2100
[<000000004ac14566>] ip_mc_msfilter+0x22d/0x310 net/ipv4/igmp.c:2484
[<0000000052d8f995>] do_ip_setsockopt.isra.0+0x1795/0x1930
net/ipv4/ip_sockglue.c:959
[<000000004ee1e21f>] ip_setsockopt+0x3b/0xb0 net/ipv4/ip_sockglue.c:1248
[<0000000066cdfe74>] udp_setsockopt+0x4e/0x90 net/ipv4/udp.c:2618
[<000000009383a786>] sock_common_setsockopt+0x38/0x50
net/core/sock.c:3126
[<00000000d8ac0c94>] __sys_setsockopt+0x98/0x120 net/socket.c:2072
[<000000001b1e9666>] __do_sys_setsockopt net/socket.c:2083 [inline]
[<000000001b1e9666>] __se_sys_setsockopt net/socket.c:2080 [inline]
[<000000001b1e9666>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2080
[<00000000420d395e>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<000000007fd83a4b>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* [PATCH net-next v3 4/4] net: sched: em_ipt: add support for addrtype matching
From: Nikolay Aleksandrov @ 2019-06-27 8:10 UTC (permalink / raw)
To: netdev
Cc: roopa, davem, pablo, xiyou.wangcong, jiri, jhs, eyal.birger,
Nikolay Aleksandrov
In-Reply-To: <20190627081047.24537-1-nikolay@cumulusnetworks.com>
Allow em_ipt to use addrtype for matching. Restrict the use only to
revision 1 which has IPv6 support. Since it's a NFPROTO_UNSPEC xt match
we use the user-specified nfproto for matching, in case it's unspecified
both v4/v6 will be matched by the rule.
v2: no changes, was patch 5 in v1
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
v3: no changes
net/sched/em_ipt.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/net/sched/em_ipt.c b/net/sched/em_ipt.c
index 3c356d6f719a..9fff6480acc6 100644
--- a/net/sched/em_ipt.c
+++ b/net/sched/em_ipt.c
@@ -72,11 +72,25 @@ static int policy_validate_match_data(struct nlattr **tb, u8 mrev)
return 0;
}
+static int addrtype_validate_match_data(struct nlattr **tb, u8 mrev)
+{
+ if (mrev != 1) {
+ pr_err("only addrtype match revision 1 supported");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static const struct em_ipt_xt_match em_ipt_xt_matches[] = {
{
.match_name = "policy",
.validate_match_data = policy_validate_match_data
},
+ {
+ .match_name = "addrtype",
+ .validate_match_data = addrtype_validate_match_data
+ },
{}
};
--
2.21.0
^ permalink raw reply related
* [PATCH net-next v3 3/4] net: sched: em_ipt: keep the user-specified nfproto and dump it
From: Nikolay Aleksandrov @ 2019-06-27 8:10 UTC (permalink / raw)
To: netdev
Cc: roopa, davem, pablo, xiyou.wangcong, jiri, jhs, eyal.birger,
Nikolay Aleksandrov
In-Reply-To: <20190627081047.24537-1-nikolay@cumulusnetworks.com>
If we dump NFPROTO_UNSPEC as nfproto user-space libxtables can't handle
it and would exit with an error like:
"libxtables: unhandled NFPROTO in xtables_set_nfproto"
In order to avoid the error return the user-specified nfproto. If we
don't record it then the match family is used which can be
NFPROTO_UNSPEC. Even if we add support to mask NFPROTO_UNSPEC in
iproute2 we have to be compatible with older versions which would be
also be allowed to add NFPROTO_UNSPEC matches (e.g. addrtype after the
last patch).
v3: don't use the user nfproto for matching, only for dumping the rule,
also don't allow the nfproto to be unspecified (explained above)
v2: adjust changes to missing patch, was patch 04 in v1
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
Unfortunately we still have to save the user-nfproto for dumping
otherwise we'll break user-space because it can add a rule which it
won't be able to dump later and in fact will terminate the whole dump.
I also thought about masking it but that seems more hacky, I'd prefer
to return an expected value which was passed when the rule was created.
net/sched/em_ipt.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/net/sched/em_ipt.c b/net/sched/em_ipt.c
index fd7f5b288c31..3c356d6f719a 100644
--- a/net/sched/em_ipt.c
+++ b/net/sched/em_ipt.c
@@ -21,6 +21,7 @@
struct em_ipt_match {
const struct xt_match *match;
u32 hook;
+ u8 nfproto;
u8 match_data[0] __aligned(8);
};
@@ -115,6 +116,7 @@ static int em_ipt_change(struct net *net, void *data, int data_len,
struct em_ipt_match *im = NULL;
struct xt_match *match;
int mdata_len, ret;
+ u8 nfproto;
ret = nla_parse_deprecated(tb, TCA_EM_IPT_MAX, data, data_len,
em_ipt_policy, NULL);
@@ -125,6 +127,15 @@ static int em_ipt_change(struct net *net, void *data, int data_len,
!tb[TCA_EM_IPT_MATCH_DATA] || !tb[TCA_EM_IPT_NFPROTO])
return -EINVAL;
+ nfproto = nla_get_u8(tb[TCA_EM_IPT_NFPROTO]);
+ switch (nfproto) {
+ case NFPROTO_IPV4:
+ case NFPROTO_IPV6:
+ break;
+ default:
+ return -EINVAL;
+ }
+
match = get_xt_match(tb);
if (IS_ERR(match)) {
pr_err("unable to load match\n");
@@ -140,6 +151,7 @@ static int em_ipt_change(struct net *net, void *data, int data_len,
im->match = match;
im->hook = nla_get_u32(tb[TCA_EM_IPT_HOOK]);
+ im->nfproto = nfproto;
nla_memcpy(im->match_data, tb[TCA_EM_IPT_MATCH_DATA], mdata_len);
ret = check_match(net, im, mdata_len);
@@ -231,7 +243,7 @@ static int em_ipt_dump(struct sk_buff *skb, struct tcf_ematch *em)
return -EMSGSIZE;
if (nla_put_u8(skb, TCA_EM_IPT_MATCH_REVISION, im->match->revision) < 0)
return -EMSGSIZE;
- if (nla_put_u8(skb, TCA_EM_IPT_NFPROTO, im->match->family) < 0)
+ if (nla_put_u8(skb, TCA_EM_IPT_NFPROTO, im->nfproto) < 0)
return -EMSGSIZE;
if (nla_put(skb, TCA_EM_IPT_MATCH_DATA,
im->match->usersize ?: im->match->matchsize,
--
2.21.0
^ permalink raw reply related
* [PATCH net-next v3 2/4] net: sched: em_ipt: set the family based on the packet if it's unspecified
From: Nikolay Aleksandrov @ 2019-06-27 8:10 UTC (permalink / raw)
To: netdev
Cc: roopa, davem, pablo, xiyou.wangcong, jiri, jhs, eyal.birger,
Nikolay Aleksandrov
In-Reply-To: <20190627081047.24537-1-nikolay@cumulusnetworks.com>
Set the family based on the packet if it's unspecified otherwise
protocol-neutral matches will have wrong information (e.g. NFPROTO_UNSPEC).
In preparation for using NFPROTO_UNSPEC xt matches.
v2: set the nfproto only when unspecified
Suggested-by: Eyal Birger <eyal.birger@gmail.com>
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
v3: no change
net/sched/em_ipt.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/net/sched/em_ipt.c b/net/sched/em_ipt.c
index 64dbafe4e94c..fd7f5b288c31 100644
--- a/net/sched/em_ipt.c
+++ b/net/sched/em_ipt.c
@@ -182,6 +182,7 @@ static int em_ipt_match(struct sk_buff *skb, struct tcf_ematch *em,
const struct em_ipt_match *im = (const void *)em->data;
struct xt_action_param acpar = {};
struct net_device *indev = NULL;
+ u8 nfproto = im->match->family;
struct nf_hook_state state;
int ret;
@@ -189,10 +190,14 @@ static int em_ipt_match(struct sk_buff *skb, struct tcf_ematch *em,
case htons(ETH_P_IP):
if (!pskb_network_may_pull(skb, sizeof(struct iphdr)))
return 0;
+ if (nfproto == NFPROTO_UNSPEC)
+ nfproto = NFPROTO_IPV4;
break;
case htons(ETH_P_IPV6):
if (!pskb_network_may_pull(skb, sizeof(struct ipv6hdr)))
return 0;
+ if (nfproto == NFPROTO_UNSPEC)
+ nfproto = NFPROTO_IPV6;
break;
default:
return 0;
@@ -203,7 +208,7 @@ static int em_ipt_match(struct sk_buff *skb, struct tcf_ematch *em,
if (skb->skb_iif)
indev = dev_get_by_index_rcu(em->net, skb->skb_iif);
- nf_hook_state_init(&state, im->hook, im->match->family,
+ nf_hook_state_init(&state, im->hook, nfproto,
indev ?: skb->dev, skb->dev, NULL, em->net, NULL);
acpar.match = im->match;
--
2.21.0
^ permalink raw reply related
* [PATCH net-next v3 1/4] net: sched: em_ipt: match only on ip/ipv6 traffic
From: Nikolay Aleksandrov @ 2019-06-27 8:10 UTC (permalink / raw)
To: netdev
Cc: roopa, davem, pablo, xiyou.wangcong, jiri, jhs, eyal.birger,
Nikolay Aleksandrov
In-Reply-To: <20190627081047.24537-1-nikolay@cumulusnetworks.com>
Restrict matching only to ip/ipv6 traffic and make sure we can use the
headers, otherwise matches will be attempted on any protocol which can
be unexpected by the xt matches. Currently policy supports only ipv4/6.
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
v3: no change
v2: no change
net/sched/em_ipt.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/net/sched/em_ipt.c b/net/sched/em_ipt.c
index 243fd22f2248..64dbafe4e94c 100644
--- a/net/sched/em_ipt.c
+++ b/net/sched/em_ipt.c
@@ -185,6 +185,19 @@ static int em_ipt_match(struct sk_buff *skb, struct tcf_ematch *em,
struct nf_hook_state state;
int ret;
+ switch (tc_skb_protocol(skb)) {
+ case htons(ETH_P_IP):
+ if (!pskb_network_may_pull(skb, sizeof(struct iphdr)))
+ return 0;
+ break;
+ case htons(ETH_P_IPV6):
+ if (!pskb_network_may_pull(skb, sizeof(struct ipv6hdr)))
+ return 0;
+ break;
+ default:
+ return 0;
+ }
+
rcu_read_lock();
if (skb->skb_iif)
--
2.21.0
^ permalink raw reply related
* [PATCH net-next v3 0/4] em_ipt: add support for addrtype
From: Nikolay Aleksandrov @ 2019-06-27 8:10 UTC (permalink / raw)
To: netdev
Cc: roopa, davem, pablo, xiyou.wangcong, jiri, jhs, eyal.birger,
Nikolay Aleksandrov
Hi,
We would like to be able to use the addrtype from tc for ACL rules and
em_ipt seems the best place to add support for the already existing xt
match. The biggest issue is that addrtype revision 1 (with ipv6 support)
is NFPROTO_UNSPEC and currently em_ipt can't differentiate between v4/v6
if such xt match is used because it passes the match's family instead of
the packet one. The first 3 patches make em_ipt match only on IP
traffic (currently both policy and addrtype recognize such traffic
only) and make it pass the actual packet's protocol instead of the xt
match family when it's unspecified. They also add support for NFPROTO_UNSPEC
xt matches. The last patch allows to add addrtype rules via em_ipt.
We need to keep the user-specified nfproto for dumping in order to be
compatible with libxtables, we cannot dump NFPROTO_UNSPEC as the nfproto
or we'll get an error from libxtables, thus the nfproto is limited to
ipv4/ipv6 in patch 03 and is recorded.
v3: don't use the user nfproto for matching, only for dumping, more
information is available in the commit message in patch 03
v2: change patch 02 to set the nfproto only when unspecified and drop
patch 04 from v1 (Eyal Birger)
Thank you,
Nikolay Aleksandrov
Nikolay Aleksandrov (4):
net: sched: em_ipt: match only on ip/ipv6 traffic
net: sched: em_ipt: set the family based on the packet if it's
unspecified
net: sched: em_ipt: keep the user-specified nfproto and dump it
net: sched: em_ipt: add support for addrtype matching
net/sched/em_ipt.c | 48 ++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 46 insertions(+), 2 deletions(-)
--
2.21.0
^ permalink raw reply
* [PATCH bpf-next] virtio_net: add XDP meta data support
From: Yuya Kusakabe @ 2019-06-27 8:06 UTC (permalink / raw)
To: davem
Cc: Michael S. Tsirkin, Jason Wang, Alexei Starovoitov,
Daniel Borkmann, Jakub Kicinski, Jesper Dangaard Brouer,
John Fastabend, Martin KaFai Lau, Song Liu, Yonghong Song, netdev,
Yuya Kusakabe
This adds XDP meta data support to both receive_small() and
receive_mergeable().
Fixes: de8f3a83b0a0 ("bpf: add meta pointer for direct access")
Signed-off-by: Yuya Kusakabe <yuya.kusakabe@gmail.com>
---
drivers/net/virtio_net.c | 40 +++++++++++++++++++++++++++++-----------
1 file changed, 29 insertions(+), 11 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 4f3de0ac8b0b..e787657fc568 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -371,7 +371,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
struct receive_queue *rq,
struct page *page, unsigned int offset,
unsigned int len, unsigned int truesize,
- bool hdr_valid)
+ bool hdr_valid, unsigned int metasize)
{
struct sk_buff *skb;
struct virtio_net_hdr_mrg_rxbuf *hdr;
@@ -393,17 +393,25 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
else
hdr_padded_len = sizeof(struct padded_vnet_hdr);
- if (hdr_valid)
+ if (hdr_valid && !metasize)
memcpy(hdr, p, hdr_len);
len -= hdr_len;
offset += hdr_padded_len;
p += hdr_padded_len;
- copy = len;
+ copy = len + metasize;
if (copy > skb_tailroom(skb))
copy = skb_tailroom(skb);
- skb_put_data(skb, p, copy);
+
+ if (metasize) {
+ skb_put_data(skb, p - metasize, copy);
+ __skb_pull(skb, metasize);
+ skb_metadata_set(skb, metasize);
+ copy -= metasize;
+ } else {
+ skb_put_data(skb, p, copy);
+ }
len -= copy;
offset += copy;
@@ -644,6 +652,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
unsigned int delta = 0;
struct page *xdp_page;
int err;
+ unsigned int metasize = 0;
len -= vi->hdr_len;
stats->bytes += len;
@@ -683,8 +692,8 @@ static struct sk_buff *receive_small(struct net_device *dev,
xdp.data_hard_start = buf + VIRTNET_RX_PAD + vi->hdr_len;
xdp.data = xdp.data_hard_start + xdp_headroom;
- xdp_set_data_meta_invalid(&xdp);
xdp.data_end = xdp.data + len;
+ xdp.data_meta = xdp.data;
xdp.rxq = &rq->xdp_rxq;
orig_data = xdp.data;
act = bpf_prog_run_xdp(xdp_prog, &xdp);
@@ -695,9 +704,11 @@ static struct sk_buff *receive_small(struct net_device *dev,
/* Recalculate length in case bpf program changed it */
delta = orig_data - xdp.data;
len = xdp.data_end - xdp.data;
+ metasize = xdp.data - xdp.data_meta;
break;
case XDP_TX:
stats->xdp_tx++;
+ xdp.data_meta = xdp.data;
xdpf = convert_to_xdp_frame(&xdp);
if (unlikely(!xdpf))
goto err_xdp;
@@ -735,11 +746,14 @@ static struct sk_buff *receive_small(struct net_device *dev,
}
skb_reserve(skb, headroom - delta);
skb_put(skb, len);
- if (!delta) {
+ if (!delta && !metasize) {
buf += header_offset;
memcpy(skb_vnet_hdr(skb), buf, vi->hdr_len);
} /* keep zeroed vnet hdr since packet was changed by bpf */
+ if (metasize)
+ skb_metadata_set(skb, metasize);
+
err:
return skb;
@@ -761,7 +775,7 @@ static struct sk_buff *receive_big(struct net_device *dev,
{
struct page *page = buf;
struct sk_buff *skb = page_to_skb(vi, rq, page, 0, len,
- PAGE_SIZE, true);
+ PAGE_SIZE, true, 0);
stats->bytes += len - vi->hdr_len;
if (unlikely(!skb))
@@ -793,6 +807,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
unsigned int truesize;
unsigned int headroom = mergeable_ctx_to_headroom(ctx);
int err;
+ unsigned int metasize = 0;
head_skb = NULL;
stats->bytes += len - vi->hdr_len;
@@ -839,8 +854,8 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
data = page_address(xdp_page) + offset;
xdp.data_hard_start = data - VIRTIO_XDP_HEADROOM + vi->hdr_len;
xdp.data = data + vi->hdr_len;
- xdp_set_data_meta_invalid(&xdp);
xdp.data_end = xdp.data + (len - vi->hdr_len);
+ xdp.data_meta = xdp.data;
xdp.rxq = &rq->xdp_rxq;
act = bpf_prog_run_xdp(xdp_prog, &xdp);
@@ -859,18 +874,20 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
* adjusted
*/
len = xdp.data_end - xdp.data + vi->hdr_len;
+ metasize = xdp.data - xdp.data_meta;
/* We can only create skb based on xdp_page. */
if (unlikely(xdp_page != page)) {
rcu_read_unlock();
put_page(page);
head_skb = page_to_skb(vi, rq, xdp_page,
- offset, len,
- PAGE_SIZE, false);
+ offset, len,
+ PAGE_SIZE, false, metasize);
return head_skb;
}
break;
case XDP_TX:
stats->xdp_tx++;
+ xdp.data_meta = xdp.data;
xdpf = convert_to_xdp_frame(&xdp);
if (unlikely(!xdpf))
goto err_xdp;
@@ -921,7 +938,8 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
goto err_skb;
}
- head_skb = page_to_skb(vi, rq, page, offset, len, truesize, !xdp_prog);
+ head_skb = page_to_skb(vi, rq, page, offset, len, truesize, !xdp_prog,
+ metasize);
curr_skb = head_skb;
if (unlikely(!curr_skb))
--
2.20.1
^ permalink raw reply related
* RE: [PATCH net-next 07/10] net: stmmac: Enable support for > 32 Bits addressing in XGMAC
From: Jose Abreu @ 2019-06-27 7:54 UTC (permalink / raw)
To: Andrew Lunn, Jose Abreu
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Joao Pinto,
David S . Miller, Giuseppe Cavallaro, Alexandre Torgue
In-Reply-To: <20190626201953.GI27733@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
> > +
> > + if (priv->dma_cap.addr64) {
> > + ret = dma_set_mask_and_coherent(device,
> > + DMA_BIT_MASK(priv->dma_cap.addr64));
> > + if (!ret)
> > + dev_info(priv->device, "Using %d bits DMA width\n",
> > + priv->dma_cap.addr64);
> > + }
>
> Hi Jose
>
> If dma_set_mask_and_coherent() fails, i think you are supposed to fall
> back to 32 bits. So you might want to clear priv->dma_cap.addr64.
Yeah, seems right. Thanks for pointing!
^ permalink raw reply
* RE: [PATCH net-next 10/10] net: stmmac: Try to get C45 PHY if everything else fails
From: Jose Abreu @ 2019-06-27 7:54 UTC (permalink / raw)
To: Andrew Lunn, Jose Abreu
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Joao Pinto,
David S . Miller, Giuseppe Cavallaro, Alexandre Torgue
In-Reply-To: <20190626200128.GH27733@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
> On Wed, Jun 26, 2019 at 03:47:44PM +0200, Jose Abreu wrote:
> > On PCI based setups that are connected to C45 PHY we won't have DT
> > bindings specifying what's the correct PHY type.
>
> You can associate a DT node to a PCI device. The driver does not have
> to do anything special, the PCI core code does all the work.
>
> As an example look at imx6q-zii-rdu2.dts, node &pcie, which has an
> intel i210 on the pcie bus, and we need a handle to it.
That's for ARM but I'm using X86_64 which only has ACPI :/
^ permalink raw reply
* Re: [PATCH v2] flow_dissector: Fix vlan header offset in __skb_flow_dissect
From: Jiri Pirko @ 2019-06-27 7:44 UTC (permalink / raw)
To: David Miller
Cc: yuehaibing, sdf, jianbol, jiri, mirq-linux, willemb, sdf,
linux-kernel, netdev
In-Reply-To: <20190626.192829.1694521513812984310.davem@davemloft.net>
Thu, Jun 27, 2019 at 04:28:29AM CEST, davem@davemloft.net wrote:
>From: YueHaibing <yuehaibing@huawei.com>
>Date: Mon, 24 Jun 2019 11:49:13 +0800
>
>> @@ -998,6 +998,9 @@ bool __skb_flow_dissect(const struct net *net,
>> skb && skb_vlan_tag_present(skb)) {
>> proto = skb->protocol;
>> } else {
>> + if (dissector_vlan == FLOW_DISSECTOR_KEY_MAX)
>> + nhoff -= sizeof(*vlan);
>> +
>
>But this is wrong when we are being called via eth_get_headlen(), in
>that case nhoff will be sizeof(struct ethhdr).
This patch was replaced by:
[PATCH] bonding: Always enable vlan tx offload
http://patchwork.ozlabs.org/patch/1122886/
^ permalink raw reply
* Re: [PATCH bpf-next] virtio_net: add XDP meta data support in receive_small()
From: Yuya Kusakabe @ 2019-06-27 7:35 UTC (permalink / raw)
To: jasowang, davem
Cc: netdev, ast, daniel, jakub.kicinski, hawk, john.fastabend, mst
In-Reply-To: <74dc4919-cf27-b058-5996-5af4d9acbd77@redhat.com>
>> This adds XDP meta data support to the code path receive_small().
>>
>> mrg_rxbuf=off is required on qemu, because receive_mergeable() still
>> doesn't support XDP meta data.
>
>
>What's the reason for this?
I didn't have enough time to add support XDP meta data to
receive_mergeable(). But I'll try it a little more. Please wait for the
next patch.
>>
>> Fixes: de8f3a83b0a0 ("bpf: add meta pointer for direct access")
>> Signed-off-by: Yuya Kusakabe <yuya.kusakabe@gmail.com>
>
>
>Could you please cc virtio maintainer through get_maintainer.pl?
>
>Thanks
Sorry. I added them.
Thanks.
> ---
> drivers/net/virtio_net.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 4f3de0ac8b0b..14165c5edb7d 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -644,6 +644,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
> unsigned int delta = 0;
> struct page *xdp_page;
> int err;
> + unsigned int metasize = 0;
>
> len -= vi->hdr_len;
> stats->bytes += len;
> @@ -683,8 +684,8 @@ static struct sk_buff *receive_small(struct net_device *dev,
>
> xdp.data_hard_start = buf + VIRTNET_RX_PAD + vi->hdr_len;
> xdp.data = xdp.data_hard_start + xdp_headroom;
> - xdp_set_data_meta_invalid(&xdp);
> xdp.data_end = xdp.data + len;
> + xdp.data_meta = xdp.data;
> xdp.rxq = &rq->xdp_rxq;
> orig_data = xdp.data;
> act = bpf_prog_run_xdp(xdp_prog, &xdp);
> @@ -695,9 +696,11 @@ static struct sk_buff *receive_small(struct net_device *dev,
> /* Recalculate length in case bpf program changed it */
> delta = orig_data - xdp.data;
> len = xdp.data_end - xdp.data;
> + metasize = xdp.data - xdp.data_meta;
> break;
> case XDP_TX:
> stats->xdp_tx++;
> + xdp.data_meta = xdp.data;
> xdpf = convert_to_xdp_frame(&xdp);
> if (unlikely(!xdpf))
> goto err_xdp;
> @@ -735,11 +738,14 @@ static struct sk_buff *receive_small(struct net_device *dev,
> }
> skb_reserve(skb, headroom - delta);
> skb_put(skb, len);
> - if (!delta) {
> + if (!delta && !metasize) {
> buf += header_offset;
> memcpy(skb_vnet_hdr(skb), buf, vi->hdr_len);
> } /* keep zeroed vnet hdr since packet was changed by bpf */
>
> + if (metasize)
> + skb_metadata_set(skb, metasize);
> +
> err:
> return skb;
>
^ permalink raw reply
* Re: [PATCH bpf v4 2/2] xdp: fix hang while unregistering device bound to xdp socket
From: Ilya Maximets @ 2019-06-27 7:23 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, linux-kernel, bpf, xdp-newbies, David S. Miller,
Björn Töpel, Magnus Karlsson, Jonathan Lemon,
Daniel Borkmann
In-Reply-To: <20190626113427.761cc845@cakuba.netronome.com>
On 26.06.2019 21:34, Jakub Kicinski wrote:
> On Wed, 26 Jun 2019 21:15:15 +0300, Ilya Maximets wrote:
>> diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c
>> index 267b82a4cbcf..56729e74cbea 100644
>> --- a/net/xdp/xdp_umem.c
>> +++ b/net/xdp/xdp_umem.c
>> @@ -140,34 +140,38 @@ int xdp_umem_assign_dev(struct xdp_umem *umem, struct net_device *dev,
>> return err;
>> }
>>
>> -static void xdp_umem_clear_dev(struct xdp_umem *umem)
>> +void xdp_umem_clear_dev(struct xdp_umem *umem)
>> {
>> + bool lock = rtnl_is_locked();
>
> How do you know it's not just locked by someone else? You need to pass
> the locked state in if this is called from different paths, some of
> which already hold rtnl.
Oh. That's a shame. I need more sleep.
Thanks for spotting. I'll re-work this part.
Best regards, Ilya Maximets.
>
> Preferably factor the code which needs the lock out into a separate
> function like this:
>
> void __function()
> {
> do();
> the();
> things();
> under();
> the();
> lock();
> }
>
> void function()
> {
> rtnl_lock();
> __function();
> rtnl_unlock();
> }
>
>> struct netdev_bpf bpf;
>> int err;
>>
>> + if (!lock)
>> + rtnl_lock();
>
>
>
^ permalink raw reply
* Re: [PATCH net-next] xdp: xdp_umem: fix umem pages mapping for 32bits systems
From: kbuild test robot @ 2019-06-27 7:04 UTC (permalink / raw)
To: Ivan Khoronzhuk
Cc: kbuild-all, bjorn.topel, magnus.karlsson, davem, ast, daniel,
hawk, john.fastabend, netdev, bpf, xdp-newbies, linux-kernel,
Ivan Khoronzhuk
In-Reply-To: <20190626155911.13574-1-ivan.khoronzhuk@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 4008 bytes --]
Hi Ivan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Ivan-Khoronzhuk/xdp-xdp_umem-fix-umem-pages-mapping-for-32bits-systems/20190627-135949
config: i386-randconfig-x073-201925 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-9) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
net//xdp/xdp_umem.c: In function 'xdp_umem_unmap_pages':
net//xdp/xdp_umem.c:177:3: error: implicit declaration of function 'kunmap'; did you mean 'vunmap'? [-Werror=implicit-function-declaration]
kunmap(umem->pgs[i]);
^~~~~~
vunmap
net//xdp/xdp_umem.c: In function 'xdp_umem_reg':
>> net//xdp/xdp_umem.c:384:25: error: implicit declaration of function 'kmap'; did you mean 'vmap'? [-Werror=implicit-function-declaration]
umem->pages[i].addr = kmap(umem->pgs[i]);
^~~~
vmap
net//xdp/xdp_umem.c:384:23: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
umem->pages[i].addr = kmap(umem->pgs[i]);
^
cc1: some warnings being treated as errors
vim +384 net//xdp/xdp_umem.c
311
312 static int xdp_umem_reg(struct xdp_umem *umem, struct xdp_umem_reg *mr)
313 {
314 u32 chunk_size = mr->chunk_size, headroom = mr->headroom;
315 unsigned int chunks, chunks_per_page;
316 u64 addr = mr->addr, size = mr->len;
317 int size_chk, err, i;
318
319 if (chunk_size < XDP_UMEM_MIN_CHUNK_SIZE || chunk_size > PAGE_SIZE) {
320 /* Strictly speaking we could support this, if:
321 * - huge pages, or*
322 * - using an IOMMU, or
323 * - making sure the memory area is consecutive
324 * but for now, we simply say "computer says no".
325 */
326 return -EINVAL;
327 }
328
329 if (!is_power_of_2(chunk_size))
330 return -EINVAL;
331
332 if (!PAGE_ALIGNED(addr)) {
333 /* Memory area has to be page size aligned. For
334 * simplicity, this might change.
335 */
336 return -EINVAL;
337 }
338
339 if ((addr + size) < addr)
340 return -EINVAL;
341
342 chunks = (unsigned int)div_u64(size, chunk_size);
343 if (chunks == 0)
344 return -EINVAL;
345
346 chunks_per_page = PAGE_SIZE / chunk_size;
347 if (chunks < chunks_per_page || chunks % chunks_per_page)
348 return -EINVAL;
349
350 headroom = ALIGN(headroom, 64);
351
352 size_chk = chunk_size - headroom - XDP_PACKET_HEADROOM;
353 if (size_chk < 0)
354 return -EINVAL;
355
356 umem->address = (unsigned long)addr;
357 umem->chunk_mask = ~((u64)chunk_size - 1);
358 umem->size = size;
359 umem->headroom = headroom;
360 umem->chunk_size_nohr = chunk_size - headroom;
361 umem->npgs = size / PAGE_SIZE;
362 umem->pgs = NULL;
363 umem->user = NULL;
364 INIT_LIST_HEAD(&umem->xsk_list);
365 spin_lock_init(&umem->xsk_list_lock);
366
367 refcount_set(&umem->users, 1);
368
369 err = xdp_umem_account_pages(umem);
370 if (err)
371 return err;
372
373 err = xdp_umem_pin_pages(umem);
374 if (err)
375 goto out_account;
376
377 umem->pages = kcalloc(umem->npgs, sizeof(*umem->pages), GFP_KERNEL);
378 if (!umem->pages) {
379 err = -ENOMEM;
380 goto out_account;
381 }
382
383 for (i = 0; i < umem->npgs; i++)
> 384 umem->pages[i].addr = kmap(umem->pgs[i]);
385
386 return 0;
387
388 out_account:
389 xdp_umem_unaccount_pages(umem);
390 return err;
391 }
392
---
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: 32965 bytes --]
^ permalink raw reply
* KASAN: use-after-free Write in xfrm_policy_flush
From: syzbot @ 2019-06-27 6:50 UTC (permalink / raw)
To: davem, herbert, linux-kernel, netdev, steffen.klassert,
syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 249155c2 Merge branch 'parisc-5.2-4' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10f1198da00000
kernel config: https://syzkaller.appspot.com/x/.config?x=9a31528e58cc12e2
dashboard link: https://syzkaller.appspot.com/bug?extid=2daeb7ae5e8245095f65
compiler: clang version 9.0.0 (/home/glider/llvm/clang
80fee25776c2fb61e74c1ecb1a523375c2500b69)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+2daeb7ae5e8245095f65@syzkaller.appspotmail.com
netlink: 168 bytes leftover after parsing attributes in process
`syz-executor.2'.
==================================================================
BUG: KASAN: use-after-free in __write_once_size
include/linux/compiler.h:221 [inline]
BUG: KASAN: use-after-free in __hlist_del include/linux/list.h:748 [inline]
BUG: KASAN: use-after-free in hlist_del_rcu include/linux/rculist.h:455
[inline]
BUG: KASAN: use-after-free in __xfrm_policy_unlink
net/xfrm/xfrm_policy.c:2217 [inline]
BUG: KASAN: use-after-free in xfrm_policy_flush+0x3be/0x900
net/xfrm/xfrm_policy.c:1794
Write of size 8 at addr ffff8880a5cfdd00 by task syz-executor.2/31717
CPU: 0 PID: 31717 Comm: syz-executor.2 Not tainted 5.2.0-rc6+ #7
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1d8/0x2f8 lib/dump_stack.c:113
print_address_description+0x6d/0x310 mm/kasan/report.c:188
__kasan_report+0x14b/0x1c0 mm/kasan/report.c:317
kasan_report+0x26/0x50 mm/kasan/common.c:614
__asan_report_store8_noabort+0x17/0x20 mm/kasan/generic_report.c:137
__write_once_size include/linux/compiler.h:221 [inline]
__hlist_del include/linux/list.h:748 [inline]
hlist_del_rcu include/linux/rculist.h:455 [inline]
__xfrm_policy_unlink net/xfrm/xfrm_policy.c:2217 [inline]
xfrm_policy_flush+0x3be/0x900 net/xfrm/xfrm_policy.c:1794
xfrm_flush_policy+0x132/0x3c0 net/xfrm/xfrm_user.c:2123
xfrm_user_rcv_msg+0x46b/0x720 net/xfrm/xfrm_user.c:2657
netlink_rcv_skb+0x1f0/0x460 net/netlink/af_netlink.c:2482
xfrm_netlink_rcv+0x74/0x90 net/xfrm/xfrm_user.c:2665
netlink_unicast_kernel net/netlink/af_netlink.c:1307 [inline]
netlink_unicast+0x962/0xaf0 net/netlink/af_netlink.c:1333
netlink_sendmsg+0xa7a/0xd40 net/netlink/af_netlink.c:1922
sock_sendmsg_nosec net/socket.c:646 [inline]
sock_sendmsg net/socket.c:665 [inline]
___sys_sendmsg+0x66b/0x9a0 net/socket.c:2286
__sys_sendmsg net/socket.c:2324 [inline]
__do_sys_sendmsg net/socket.c:2333 [inline]
__se_sys_sendmsg net/socket.c:2331 [inline]
__x64_sys_sendmsg+0x1cf/0x290 net/socket.c:2331
do_syscall_64+0xfe/0x140 arch/x86/entry/common.c:301
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x459519
Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f4e7b5f5c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000459519
RDX: 0000000000000000 RSI: 000000002014f000 RDI: 0000000000000003
RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4e7b5f66d4
R13: 00000000004c7264 R14: 00000000004dc6c8 R15: 00000000ffffffff
Allocated by task 8433:
save_stack mm/kasan/common.c:71 [inline]
set_track mm/kasan/common.c:79 [inline]
__kasan_kmalloc+0x11c/0x1b0 mm/kasan/common.c:489
kasan_kmalloc+0x9/0x10 mm/kasan/common.c:503
__do_kmalloc mm/slab.c:3660 [inline]
__kmalloc+0x23c/0x310 mm/slab.c:3669
kmalloc include/linux/slab.h:552 [inline]
kzalloc include/linux/slab.h:742 [inline]
xfrm_hash_alloc+0x38/0xe0 net/xfrm/xfrm_hash.c:21
xfrm_policy_init net/xfrm/xfrm_policy.c:4036 [inline]
xfrm_net_init+0x269/0xd60 net/xfrm/xfrm_policy.c:4120
ops_init+0x336/0x420 net/core/net_namespace.c:130
setup_net+0x212/0x690 net/core/net_namespace.c:316
copy_net_ns+0x224/0x380 net/core/net_namespace.c:439
create_new_namespaces+0x4ec/0x700 kernel/nsproxy.c:103
unshare_nsproxy_namespaces+0x12a/0x190 kernel/nsproxy.c:202
ksys_unshare+0x540/0xac0 kernel/fork.c:2692
__do_sys_unshare kernel/fork.c:2760 [inline]
__se_sys_unshare kernel/fork.c:2758 [inline]
__x64_sys_unshare+0x38/0x40 kernel/fork.c:2758
do_syscall_64+0xfe/0x140 arch/x86/entry/common.c:301
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 21222:
save_stack mm/kasan/common.c:71 [inline]
set_track mm/kasan/common.c:79 [inline]
__kasan_slab_free+0x12a/0x1e0 mm/kasan/common.c:451
kasan_slab_free+0xe/0x10 mm/kasan/common.c:459
__cache_free mm/slab.c:3432 [inline]
kfree+0xae/0x120 mm/slab.c:3755
xfrm_hash_free+0x38/0xd0 net/xfrm/xfrm_hash.c:35
xfrm_bydst_resize net/xfrm/xfrm_policy.c:602 [inline]
xfrm_hash_resize+0x13f1/0x1840 net/xfrm/xfrm_policy.c:680
process_one_work+0x814/0x1130 kernel/workqueue.c:2269
worker_thread+0xc01/0x1640 kernel/workqueue.c:2415
kthread+0x325/0x350 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
The buggy address belongs to the object at ffff8880a5cfdd00
which belongs to the cache kmalloc-64 of size 64
The buggy address is located 0 bytes inside of
64-byte region [ffff8880a5cfdd00, ffff8880a5cfdd40)
The buggy address belongs to the page:
page:ffffea0002973f40 refcount:1 mapcount:0 mapping:ffff8880aa400340
index:0x0
flags: 0x1fffc0000000200(slab)
raw: 01fffc0000000200 ffffea000267ccc8 ffffea0002a49b08 ffff8880aa400340
raw: 0000000000000000 ffff8880a5cfd000 0000000100000020 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8880a5cfdc00: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
ffff8880a5cfdc80: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
> ffff8880a5cfdd00: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
^
ffff8880a5cfdd80: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
ffff8880a5cfde00: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply
* Re: [PATCH 2/3 nf-next] netfilter:nf_flow_table: Support bridge type flow offload
From: wenxu @ 2019-06-27 6:22 UTC (permalink / raw)
To: Florian Westphal; +Cc: pablo, netfilter-devel, netdev
In-Reply-To: <20190626191945.2mktaqrcrfcrfc66@breakpoint.cc>
On 6/27/2019 3:19 AM, Florian Westphal wrote:
> Florian Westphal <fw@strlen.de> wrote:
>> wenxu@ucloud.cn <wenxu@ucloud.cn> wrote:
>>> diff --git a/net/netfilter/nf_flow_table_ip.c b/net/netfilter/nf_flow_table_ip.c
>>> index 0016bb8..9af01ef 100644
>>> --- a/net/netfilter/nf_flow_table_ip.c
>>> +++ b/net/netfilter/nf_flow_table_ip.c
>>> - neigh_xmit(NEIGH_ARP_TABLE, outdev, &nexthop, skb);
>>> + if (family == NFPROTO_IPV4) {
>>> + iph = ip_hdr(skb);
>>> + ip_decrease_ttl(iph);
>>> +
>>> + nexthop = rt_nexthop(rt, flow->tuplehash[!dir].tuple.src_v4.s_addr);
>>> + skb_dst_set_noref(skb, &rt->dst);
>>> + neigh_xmit(NEIGH_ARP_TABLE, outdev, &nexthop, skb);
>>> + } else {
>>> + const struct net_bridge_port *p;
>>> +
>>> + if (vlan_tag && (p = br_port_get_rtnl_rcu(state->in)))
>>> + __vlan_hwaccel_put_tag(skb, p->br->vlan_proto, vlan_tag);
>>> + else
>>> + __vlan_hwaccel_clear_tag(skb);
>>> +
>>> + br_dev_queue_push_xmit(state->net, state->sk, skb);
>> Won't that result in a module dep on bridge?
I will fix it in version 2
>>
>> Whats the idea with this patch?
>>
>> Do you see a performance improvement when bypassing bridge layer? If so,
>> how much?
>>
>> I just wonder if its really cheaper than not using bridge conntrack in
>> the first place :-)
This patch is based on the conntrack function in bridge. It will bypass the fdb lookup
and conntrack lookup to get the performance improvement. The more important things
for hardware offload in the future with nf_tables add hardware offload support
>
^ permalink raw reply
* [PATCH 2/2] net: macb: Fix SUBNS increment and increase resolution
From: Harini Katakam @ 2019-06-27 6:21 UTC (permalink / raw)
To: nicolas.ferre, davem, richardcochran, claudiu.beznea, rafalo,
andrei.pistirica
Cc: netdev, linux-kernel, michal.simek, harinikatakamlinux,
harini.katakam
In-Reply-To: <1561616460-32439-1-git-send-email-harini.katakam@xilinx.com>
The subns increment register has 24 bits as follows:
RegBit[15:0] = Subns[23:8]; RegBit[31:24] = Subns[7:0]
Fix the same in the driver and increase sub ns resolution to the
best capable, 24 bits. This should be the case on all GEM versions
that this PTP driver supports.
Signed-off-by: Harini Katakam <harini.katakam@xilinx.com>
---
drivers/net/ethernet/cadence/macb.h | 6 +++++-
drivers/net/ethernet/cadence/macb_ptp.c | 5 ++++-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
index 90bc70b..03983bd 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -496,7 +496,11 @@
/* Bitfields in TISUBN */
#define GEM_SUBNSINCR_OFFSET 0
-#define GEM_SUBNSINCR_SIZE 16
+#define GEM_SUBNSINCRL_OFFSET 24
+#define GEM_SUBNSINCRL_SIZE 8
+#define GEM_SUBNSINCRH_OFFSET 0
+#define GEM_SUBNSINCRH_SIZE 16
+#define GEM_SUBNSINCR_SIZE 24
/* Bitfields in TI */
#define GEM_NSINCR_OFFSET 0
diff --git a/drivers/net/ethernet/cadence/macb_ptp.c b/drivers/net/ethernet/cadence/macb_ptp.c
index 6276eac..43a3f0d 100644
--- a/drivers/net/ethernet/cadence/macb_ptp.c
+++ b/drivers/net/ethernet/cadence/macb_ptp.c
@@ -104,7 +104,10 @@ static int gem_tsu_incr_set(struct macb *bp, struct tsu_incr *incr_spec)
* to take effect.
*/
spin_lock_irqsave(&bp->tsu_clk_lock, flags);
- gem_writel(bp, TISUBN, GEM_BF(SUBNSINCR, incr_spec->sub_ns));
+ /* RegBit[15:0] = Subns[23:8]; RegBit[31:24] = Subns[7:0] */
+ gem_writel(bp, TISUBN, GEM_BF(SUBNSINCRL, incr_spec->sub_ns) |
+ GEM_BF(SUBNSINCRH, (incr_spec->sub_ns >>
+ GEM_SUBNSINCRL_SIZE)));
gem_writel(bp, TI, GEM_BF(NSINCR, incr_spec->ns));
spin_unlock_irqrestore(&bp->tsu_clk_lock, flags);
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] net: macb: Add separate definition for PPM fraction
From: Harini Katakam @ 2019-06-27 6:20 UTC (permalink / raw)
To: nicolas.ferre, davem, richardcochran, claudiu.beznea, rafalo,
andrei.pistirica
Cc: netdev, linux-kernel, michal.simek, harinikatakamlinux,
harini.katakam
In-Reply-To: <1561616460-32439-1-git-send-email-harini.katakam@xilinx.com>
The scaled ppm parameter passed to _adjfine() contains a 16 bit
fraction. This just happens to be the same as SUBNSINCR_SIZE now.
Hence define this separately.
Signed-off-by: Harini Katakam <harini.katakam@xilinx.com>
---
drivers/net/ethernet/cadence/macb.h | 3 +++
drivers/net/ethernet/cadence/macb_ptp.c | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
index 515bfd2..90bc70b 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -834,6 +834,9 @@ struct gem_tx_ts {
/* limit RX checksum offload to TCP and UDP packets */
#define GEM_RX_CSUM_CHECKED_MASK 2
+/* Scaled PPM fraction */
+#define PPM_FRACTION 16
+
/* struct macb_tx_skb - data about an skb which is being transmitted
* @skb: skb currently being transmitted, only set for the last buffer
* of the frame
diff --git a/drivers/net/ethernet/cadence/macb_ptp.c b/drivers/net/ethernet/cadence/macb_ptp.c
index 0a8aca8..6276eac 100644
--- a/drivers/net/ethernet/cadence/macb_ptp.c
+++ b/drivers/net/ethernet/cadence/macb_ptp.c
@@ -135,7 +135,7 @@ static int gem_ptp_adjfine(struct ptp_clock_info *ptp, long scaled_ppm)
* (temp / USEC_PER_SEC) + 0.5
*/
adj += (USEC_PER_SEC >> 1);
- adj >>= GEM_SUBNSINCR_SIZE; /* remove fractions */
+ adj >>= PPM_FRACTION; /* remove fractions */
adj = div_u64(adj, USEC_PER_SEC);
adj = neg_adj ? (word - adj) : (word + adj);
--
2.7.4
^ permalink raw reply related
* [PATCH 0/2] Sub ns increment fixes in Macb PTP
From: Harini Katakam @ 2019-06-27 6:20 UTC (permalink / raw)
To: nicolas.ferre, davem, richardcochran, claudiu.beznea, rafalo,
andrei.pistirica
Cc: netdev, linux-kernel, michal.simek, harinikatakamlinux,
harini.katakam
The subns increment register fields are not captured correctly in the
driver. Fix the same and also increase the subns incr resolution.
Sub ns resolution was increased to 24 bits in r1p06f2 version. To my
knowledge, this PTP driver, with its current BD time stamp
implementation, is only useful to that version or above. So, I have
increased the resolution unconditionally. Please let me know if there
is any IP versions incompatible with this - there is no register to
obtain this information from.
Changes from RFC:
None
Harini Katakam (2):
net: macb: Add separate definition for PPM fraction
net: macb: Fix SUBNS increment and increase resolution
drivers/net/ethernet/cadence/macb.h | 9 ++++++++-
drivers/net/ethernet/cadence/macb_ptp.c | 7 +++++--
2 files changed, 13 insertions(+), 3 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [for-next V2 09/10] RDMA/nldev: Added configuration of RDMA dynamic interrupt moderation to netlink
From: Yamin Friedman @ 2019-06-27 5:29 UTC (permalink / raw)
To: Sagi Grimberg, Saeed Mahameed, David S. Miller, Doug Ledford,
Jason Gunthorpe
Cc: Leon Romanovsky, Or Gerlitz, Tal Gilboa, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org
In-Reply-To: <f621af3b-37a3-eb97-368a-3201fa49f338@grimberg.me>
On 6/26/2019 12:15 AM, Sagi Grimberg wrote:
>
>
> On 6/25/19 1:57 PM, Saeed Mahameed wrote:
>> From: Yamin Friedman <yaminf@mellanox.com>
>>
>> Added parameter in ib_device for enabling dynamic interrupt
>> moderation so
>> that it can be configured in userspace using rdma tool.
>>
>> In order to set dim for an ib device the command is:
>> rdma dev set [DEV] dim [on|off]
>> Please set on/off.
>
> Is "dim" what you want to expose to the user? maybe
> "adaptive-moderation" is more friendly?
That makes sense, I will change it.
^ permalink raw reply
* Re: [for-next V2 10/10] RDMA/core: Provide RDMA DIM support for ULPs
From: Yamin Friedman @ 2019-06-27 5:28 UTC (permalink / raw)
To: Sagi Grimberg, Saeed Mahameed, David S. Miller, Doug Ledford,
Jason Gunthorpe
Cc: Leon Romanovsky, Or Gerlitz, Tal Gilboa, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, Max Gurtovoy
In-Reply-To: <adb3687a-6db3-b1a4-cd32-8b4889550c81@grimberg.me>
On 6/26/2019 12:14 AM, Sagi Grimberg wrote:
>
>
>> +static int ib_poll_dim_handler(struct irq_poll *iop, int budget)
>> +{
>> + struct ib_cq *cq = container_of(iop, struct ib_cq, iop);
>> + struct dim *dim = cq->dim;
>> + int completed;
>> +
>> + completed = __ib_process_cq(cq, budget, cq->wc, IB_POLL_BATCH);
>> + if (completed < budget) {
>> + irq_poll_complete(&cq->iop);
>> + if (ib_req_notify_cq(cq, IB_POLL_FLAGS) > 0)
>> + irq_poll_sched(&cq->iop);
>> + }
>> +
>> + rdma_dim(dim, completed);
>
> Why duplicate the entire thing for a one-liner?
You are right, this was leftover from a previous version where there
were more significant changes. I will remove the extra function.
>
>> +
>> + return completed;
>> +}
>> +
>> static void ib_cq_completion_softirq(struct ib_cq *cq, void *private)
>> {
>> irq_poll_sched(&cq->iop);
>> @@ -105,14 +157,18 @@ static void ib_cq_completion_softirq(struct
>> ib_cq *cq, void *private)
>> static void ib_cq_poll_work(struct work_struct *work)
>> {
>> - struct ib_cq *cq = container_of(work, struct ib_cq, work);
>> + struct ib_cq *cq = container_of(work, struct ib_cq,
>> + work);
>
> Why was that changed?
I will fix this.
>
>> int completed;
>> completed = __ib_process_cq(cq, IB_POLL_BUDGET_WORKQUEUE,
>> cq->wc,
>> IB_POLL_BATCH);
>> +
>
> newline?
Same as above.
>
>> if (completed >= IB_POLL_BUDGET_WORKQUEUE ||
>> ib_req_notify_cq(cq, IB_POLL_FLAGS) > 0)
>> queue_work(cq->comp_wq, &cq->work);
>> + else if (cq->dim)
>> + rdma_dim(cq->dim, completed);
>> }
>> static void ib_cq_completion_workqueue(struct ib_cq *cq, void
>> *private)
>> @@ -166,6 +222,8 @@ struct ib_cq *__ib_alloc_cq_user(struct ib_device
>> *dev, void *private,
>> rdma_restrack_set_task(&cq->res, caller);
>> rdma_restrack_kadd(&cq->res);
>> + rdma_dim_init(cq);
>> +
>> switch (cq->poll_ctx) {
>> case IB_POLL_DIRECT:
>> cq->comp_handler = ib_cq_completion_direct;
>> @@ -173,7 +231,13 @@ struct ib_cq *__ib_alloc_cq_user(struct
>> ib_device *dev, void *private,
>> case IB_POLL_SOFTIRQ:
>> cq->comp_handler = ib_cq_completion_softirq;
>> - irq_poll_init(&cq->iop, IB_POLL_BUDGET_IRQ, ib_poll_handler);
>> + if (cq->dim) {
>> + irq_poll_init(&cq->iop, IB_POLL_BUDGET_IRQ,
>> + ib_poll_dim_handler);
>> + } else
>> + irq_poll_init(&cq->iop, IB_POLL_BUDGET_IRQ,
>> + ib_poll_handler);
>> +
>> ib_req_notify_cq(cq, IB_CQ_NEXT_COMP);
>> break;
>> case IB_POLL_WORKQUEUE:
>> @@ -226,6 +290,9 @@ void ib_free_cq_user(struct ib_cq *cq, struct
>> ib_udata *udata)
>> WARN_ON_ONCE(1);
>> }
>> + if (cq->dim)
>> + cancel_work_sync(&cq->dim->work);
>> + kfree(cq->dim);
>> kfree(cq->wc);
>> rdma_restrack_del(&cq->res);
>> ret = cq->device->ops.destroy_cq(cq, udata);
>> diff --git a/drivers/infiniband/hw/mlx5/main.c
>> b/drivers/infiniband/hw/mlx5/main.c
>> index abac70ad5c7c..b1b45dbe24a5 100644
>> --- a/drivers/infiniband/hw/mlx5/main.c
>> +++ b/drivers/infiniband/hw/mlx5/main.c
>> @@ -6305,6 +6305,8 @@ static int mlx5_ib_stage_caps_init(struct
>> mlx5_ib_dev *dev)
>> MLX5_CAP_GEN(dev->mdev, disable_local_lb_mc)))
>> mutex_init(&dev->lb.mutex);
>> + dev->ib_dev.use_cq_dim = true;
>> +
>
> Please don't. This is a bad choice to opt it in by default.
^ 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