* Re: [PATCH bpf-next] selftests/bpf: bpf tunnel test.
From: William Tu @ 2018-04-30 14:29 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: Y Song, Linux Kernel Network Developers
In-Reply-To: <74a48492-ab99-bbe4-632d-ce7ff82ff127@iogearbox.net>
On Mon, Apr 30, 2018 at 2:05 AM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 04/30/2018 09:02 AM, Y Song wrote:
>> Hi, William,
>>
>> When compiled the selftests/bpf in my centos 7 based system, I have
>> the following failures,
>>
>> clang -I. -I./include/uapi -I../../../include/uapi
>> -Wno-compare-distinct-pointer-types \
>> -O2 -target bpf -emit-llvm -c test_tunnel_kern.c -o - | \
>> llc -march=bpf -mcpu=generic -filetype=obj -o
>> /data/users/yhs/work/net-next/tools/testing/selftests/bpf/test_tunnel_kern.o
>> test_tunnel_kern.c:21:10: fatal error: 'linux/erspan.h' file not found
>> #include <linux/erspan.h>
>> ^~~~~~~~~~~~~~~~
>> 1 error generated.
>>
>> Maybe I missed some packages to install?
>
It works for me because I do 'make headers_install' and install the
erspan.h in my /usr/include/linux/
I will submit a patch to add the erspan.h in tools/include/uapi/linux
Thanks
William
^ permalink raw reply
* [PATCH bpf-next] tools include uapi: Grab a copy of linux/erspan.h
From: William Tu @ 2018-04-30 14:26 UTC (permalink / raw)
To: netdev
Bring the erspan uapi header file so BPF tunnel helpers can use it.
Fixes: 933a741e3b82 ("selftests/bpf: bpf tunnel test.")
Reported-by: Yonghong Song <yhs@fb.com>
Signed-off-by: William Tu <u9012063@gmail.com>
---
tools/include/uapi/linux/erspan.h | 52 +++++++++++++++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
create mode 100644 tools/include/uapi/linux/erspan.h
diff --git a/tools/include/uapi/linux/erspan.h b/tools/include/uapi/linux/erspan.h
new file mode 100644
index 000000000000..841573019ae1
--- /dev/null
+++ b/tools/include/uapi/linux/erspan.h
@@ -0,0 +1,52 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/*
+ * ERSPAN Tunnel Metadata
+ *
+ * Copyright (c) 2018 VMware
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * Userspace API for metadata mode ERSPAN tunnel
+ */
+#ifndef _UAPI_ERSPAN_H
+#define _UAPI_ERSPAN_H
+
+#include <linux/types.h> /* For __beXX in userspace */
+#include <asm/byteorder.h>
+
+/* ERSPAN version 2 metadata header */
+struct erspan_md2 {
+ __be32 timestamp;
+ __be16 sgt; /* security group tag */
+#if defined(__LITTLE_ENDIAN_BITFIELD)
+ __u8 hwid_upper:2,
+ ft:5,
+ p:1;
+ __u8 o:1,
+ gra:2,
+ dir:1,
+ hwid:4;
+#elif defined(__BIG_ENDIAN_BITFIELD)
+ __u8 p:1,
+ ft:5,
+ hwid_upper:2;
+ __u8 hwid:4,
+ dir:1,
+ gra:2,
+ o:1;
+#else
+#error "Please fix <asm/byteorder.h>"
+#endif
+};
+
+struct erspan_metadata {
+ int version;
+ union {
+ __be32 index; /* Version 1 (type II)*/
+ struct erspan_md2 md2; /* Version 2 (type III) */
+ } u;
+};
+
+#endif /* _UAPI_ERSPAN_H */
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] ethtool: fix a potential missing-check bug
From: Edward Cree @ 2018-04-30 14:20 UTC (permalink / raw)
To: Wenwen Wang
Cc: Kangjie Lu, David S. Miller, Florian Fainelli, Andrew Lunn,
Russell King, Inbar Karmy, Eugenia Emantayev, Al Viro, Yury Norov,
Vidya Sagar Ravipati, Alan Brady, Stephen Hemminger,
open list:NETWORKING [GENERAL], open list
In-Reply-To: <1525051915-31944-1-git-send-email-wang6495@umn.edu>
On 30/04/18 02:31, Wenwen Wang wrote:
> In ethtool_get_rxnfc(), the object "info" is firstly copied from
> user-space. If the FLOW_RSS flag is set in the member field flow_type of
> "info" (and cmd is ETHTOOL_GRXFH), info needs to be copied again from
> user-space because FLOW_RSS is newer and has new definition, as mentioned
> in the comment. However, given that the user data resides in user-space, a
> malicious user can race to change the data after the first copy. By doing
> so, the user can inject inconsistent data. For example, in the second
> copy, the FLOW_RSS flag could be cleared in the field flow_type of "info".
> In the following execution, "info" will be used in the function
> ops->get_rxnfc(). Such inconsistent data can potentially lead to unexpected
> information leakage since ops->get_rxnfc() will prepare various types of
> data according to flow_type, and the prepared data will be eventually
> copied to user-space. This inconsistent data may also cause undefined
> behaviors based on how ops->get_rxnfc() is implemented.
I'm not sure there's actually an issue here, since the only purpose of the
FLOW_RSS check is to avoid faulting/trampling user memory when the user
process only has the short version of 'info'.
If userland subsequently removes the FLOW_RSS flag, then all that will
happen is that info_size is larger than it ought to be; that cannot affect
ops->get_rxnfc() since it isn't passed; the op should already be treating
'info' as unsafe/user-controlled.
The only way this could lead to information leakage would be if in the non-
FLOW_RSS case ops->get_rxnfc() was writing things it shouldn't into the
latter part of 'info' and was getting away with it so far as that was
never copied_to_user; that seems improbable to me, but I suppose you might
want to do the check anyway as belt-and-braces security.
(A cleaner approach might be to only copy_from_user() the extra region of
'info', leaving the previously-copied part alone. That way each byte is
only copied_from_user once and thus cannot change.)
-Ed
> This patch re-verifies the flow_type field of "info" after the second copy.
> If the value is not as expected, an error code will be returned.
>
> Signed-off-by: Wenwen Wang <wang6495@umn.edu>
> ---
> net/core/ethtool.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/core/ethtool.c b/net/core/ethtool.c
> index 03416e6..a121034 100644
> --- a/net/core/ethtool.c
> +++ b/net/core/ethtool.c
> @@ -1032,6 +1032,8 @@ static noinline_for_stack int ethtool_get_rxnfc(struct net_device *dev,
> info_size = sizeof(info);
> if (copy_from_user(&info, useraddr, info_size))
> return -EFAULT;
> + if (!(info.flow_type & FLOW_RSS))
> + return -EINVAL;
> }
>
> if (info.cmd == ETHTOOL_GRXCLSRLALL) {
^ permalink raw reply
* [PATCH] rtlwifi: fix spelling mistake: "dismatch" -> "mismatch"
From: Colin King @ 2018-04-30 13:41 UTC (permalink / raw)
To: Ping-Ke Shih, Kalle Valo, David S . Miller, Larry Finger,
linux-wireless, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake in RT_TRACE message text.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
.../net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c | 2 +-
.../net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c | 2 +-
.../net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c
index 8fce371749d3..f22fec093f1d 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c
@@ -1783,7 +1783,7 @@ static void btc8192e2ant_tdma_duration_adjust(struct btc_coexist *btcoexist,
bool scan = false, link = false, roam = false;
RT_TRACE(rtlpriv, COMP_BT_COEXIST, DBG_LOUD,
- "[BTCoex], PsTdma type dismatch!!!, ");
+ "[BTCoex], PsTdma type mismatch!!!, ");
RT_TRACE(rtlpriv, COMP_BT_COEXIST, DBG_LOUD,
"curPsTdma=%d, recordPsTdma=%d\n",
coex_dm->cur_ps_tdma, coex_dm->tdma_adj_type);
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
index 73ec31972944..279fe01bb55e 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
@@ -2766,7 +2766,7 @@ static void btc8723b2ant_tdma_duration_adjust(struct btc_coexist *btcoexist,
if (coex_dm->cur_ps_tdma != coex_dm->ps_tdma_du_adj_type) {
bool scan = false, link = false, roam = false;
RT_TRACE(rtlpriv, COMP_BT_COEXIST, DBG_LOUD,
- "[BTCoex], PsTdma type dismatch!!!, curPsTdma=%d, recordPsTdma=%d\n",
+ "[BTCoex], PsTdma type mismatch!!!, curPsTdma=%d, recordPsTdma=%d\n",
coex_dm->cur_ps_tdma, coex_dm->ps_tdma_du_adj_type);
btcoexist->btc_get(btcoexist, BTC_GET_BL_WIFI_SCAN, &scan);
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c
index 2202d5e18977..01a9d303603b 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c
@@ -2614,7 +2614,7 @@ static void btc8821a2ant_tdma_duration_adjust(struct btc_coexist *btcoexist,
bool scan = false, link = false, roam = false;
RT_TRACE(rtlpriv, COMP_BT_COEXIST, DBG_LOUD,
- "[BTCoex], PsTdma type dismatch!!!, cur_ps_tdma = %d, recordPsTdma = %d\n",
+ "[BTCoex], PsTdma type mismatch!!!, cur_ps_tdma = %d, recordPsTdma = %d\n",
coex_dm->cur_ps_tdma, coex_dm->ps_tdma_du_adj_type);
btcoexist->btc_get(btcoexist, BTC_GET_BL_WIFI_SCAN, &scan);
--
2.17.0
^ permalink raw reply related
* Re: [PATCH net-next 0/8] r8169: further improvements w/o functional change
From: David Miller @ 2018-04-30 13:39 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <9b5f541e-8725-46ca-4466-0c3295229252@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sat, 28 Apr 2018 22:06:02 +0200
> This series aims at further improving and simplifying the code w/o
> any intended functional changes.
>
> Series was tested on: RTL8169sb, RTL8168d, RTL8168e-vl
Series applied, thank you.
^ permalink raw reply
* KASAN: use-after-free Read in perf_trace_rpc_stats_latency
From: syzbot @ 2018-04-30 13:34 UTC (permalink / raw)
To: anna.schumaker, bfields, davem, jlayton, linux-kernel, linux-nfs,
netdev, syzkaller-bugs, trond.myklebust
Hello,
syzbot hit the following crash on bpf-next commit
f60ad0a0c441530280a4918eca781a6a94dffa50 (Sun Apr 29 15:45:55 2018 +0000)
Merge branch 'bpf_get_stack'
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=27db1f90e2b972a5f2d3
Unfortunately, I don't have any reproducer for this crash yet.
Raw console output:
https://syzkaller.appspot.com/x/log.txt?id=6741221342969856
Kernel config:
https://syzkaller.appspot.com/x/.config?id=4410550353033654931
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+27db1f90e2b972a5f2d3@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for
details.
If you forward the report, please keep this part and the footer.
rpcbind: RPC call returned error 22
rpcbind: RPC call returned error 22
rpcbind: RPC call returned error 22
rpcbind: RPC call returned error 22
==================================================================
BUG: KASAN: use-after-free in strlen+0x83/0xa0 lib/string.c:482
Read of size 1 at addr ffff8801d6f0a1c0 by task syz-executor7/5079
CPU: 1 PID: 5079 Comm: syz-executor7 Not tainted 4.17.0-rc2+ #16
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+0x1b9/0x294 lib/dump_stack.c:113
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
__asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:430
strlen+0x83/0xa0 lib/string.c:482
trace_event_get_offsets_rpc_stats_latency
include/trace/events/sunrpc.h:215 [inline]
perf_trace_rpc_stats_latency+0x318/0x10d0 include/trace/events/sunrpc.h:215
trace_rpc_stats_latency include/trace/events/sunrpc.h:215 [inline]
rpc_count_iostats_metrics+0x594/0x8a0 net/sunrpc/stats.c:182
rpc_count_iostats+0x76/0x90 net/sunrpc/stats.c:195
xprt_release+0xa3b/0x1110 net/sunrpc/xprt.c:1351
rpc_release_resources_task+0x20/0xa0 net/sunrpc/sched.c:1024
rpc_release_task net/sunrpc/sched.c:1068 [inline]
__rpc_execute+0x5e9/0xf50 net/sunrpc/sched.c:833
rpc_execute+0x37f/0x480 net/sunrpc/sched.c:852
rpc_run_task+0x615/0x8c0 net/sunrpc/clnt.c:1053
rpc_call_sync+0x196/0x290 net/sunrpc/clnt.c:1082
rpc_ping+0x155/0x1f0 net/sunrpc/clnt.c:2513
rpc_create_xprt+0x282/0x3f0 net/sunrpc/clnt.c:479
rpc_create+0x52e/0x900 net/sunrpc/clnt.c:587
nfs_create_rpc_client+0x63e/0x850 fs/nfs/client.c:523
nfs_init_client+0x74/0x100 fs/nfs/client.c:634
nfs_get_client+0x1065/0x1500 fs/nfs/client.c:425
nfs_init_server+0x364/0xfb0 fs/nfs/client.c:670
nfs_create_server+0x86/0x5f0 fs/nfs/client.c:953
nfs_try_mount+0x177/0xab0 fs/nfs/super.c:1884
nfs_fs_mount+0x17de/0x2efd fs/nfs/super.c:2695
mount_fs+0xae/0x328 fs/super.c:1267
vfs_kern_mount.part.34+0xd4/0x4d0 fs/namespace.c:1037
vfs_kern_mount fs/namespace.c:1027 [inline]
do_new_mount fs/namespace.c:2518 [inline]
do_mount+0x564/0x3070 fs/namespace.c:2848
ksys_mount+0x12d/0x140 fs/namespace.c:3064
__do_sys_mount fs/namespace.c:3078 [inline]
__se_sys_mount fs/namespace.c:3075 [inline]
__x64_sys_mount+0xbe/0x150 fs/namespace.c:3075
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x455979
RSP: 002b:00007f1e2785bc68 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007f1e2785c6d4 RCX: 0000000000455979
RDX: 0000000020fb5ffc RSI: 0000000020343ff8 RDI: 000000002091dff8
RBP: 000000000072bf50 R08: 000000002000a000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 0000000000000440 R14: 00000000006fa6a0 R15: 0000000000000001
Allocated by task 5079:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
__do_kmalloc mm/slab.c:3718 [inline]
__kmalloc_track_caller+0x14a/0x760 mm/slab.c:3733
kstrdup+0x39/0x70 mm/util.c:56
xs_format_common_peer_ports+0x130/0x370 net/sunrpc/xprtsock.c:290
xs_format_peer_addresses net/sunrpc/xprtsock.c:303 [inline]
xs_setup_udp+0x5ea/0x880 net/sunrpc/xprtsock.c:3037
xprt_create_transport+0x1d7/0x596 net/sunrpc/xprt.c:1433
rpc_create+0x489/0x900 net/sunrpc/clnt.c:573
nfs_create_rpc_client+0x63e/0x850 fs/nfs/client.c:523
nfs_init_client+0x74/0x100 fs/nfs/client.c:634
nfs_get_client+0x1065/0x1500 fs/nfs/client.c:425
nfs_init_server+0x364/0xfb0 fs/nfs/client.c:670
nfs_create_server+0x86/0x5f0 fs/nfs/client.c:953
nfs_try_mount+0x177/0xab0 fs/nfs/super.c:1884
nfs_fs_mount+0x17de/0x2efd fs/nfs/super.c:2695
mount_fs+0xae/0x328 fs/super.c:1267
vfs_kern_mount.part.34+0xd4/0x4d0 fs/namespace.c:1037
vfs_kern_mount fs/namespace.c:1027 [inline]
do_new_mount fs/namespace.c:2518 [inline]
do_mount+0x564/0x3070 fs/namespace.c:2848
ksys_mount+0x12d/0x140 fs/namespace.c:3064
__do_sys_mount fs/namespace.c:3078 [inline]
__se_sys_mount fs/namespace.c:3075 [inline]
__x64_sys_mount+0xbe/0x150 fs/namespace.c:3075
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 6:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kfree+0xd9/0x260 mm/slab.c:3813
xs_update_peer_port net/sunrpc/xprtsock.c:309 [inline]
xs_set_port+0x105/0x180 net/sunrpc/xprtsock.c:1827
rpcb_getport_done+0x224/0x2d0 net/sunrpc/rpcb_clnt.c:824
rpc_exit_task+0xc9/0x2d0 net/sunrpc/sched.c:725
__rpc_execute+0x28a/0xf50 net/sunrpc/sched.c:784
rpc_async_schedule+0x16/0x20 net/sunrpc/sched.c:857
process_one_work+0xc1e/0x1b50 kernel/workqueue.c:2145
worker_thread+0x1cc/0x1440 kernel/workqueue.c:2279
kthread+0x345/0x410 kernel/kthread.c:238
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
The buggy address belongs to the object at ffff8801d6f0a1c0
which belongs to the cache kmalloc-32 of size 32
The buggy address is located 0 bytes inside of
32-byte region [ffff8801d6f0a1c0, ffff8801d6f0a1e0)
The buggy address belongs to the page:
page:ffffea00075bc280 count:1 mapcount:0 mapping:ffff8801d6f0a000
index:0xffff8801d6f0afc1
flags: 0x2fffc0000000100(slab)
raw: 02fffc0000000100 ffff8801d6f0a000 ffff8801d6f0afc1 0000000100000024
raw: ffffea00075c52a0 ffff8801da801238 ffff8801da8001c0 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801d6f0a080: 01 fc fc fc fc fc fc fc 00 02 fc fc fc fc fc fc
ffff8801d6f0a100: 00 02 fc fc fc fc fc fc 00 02 fc fc fc fc fc fc
> ffff8801d6f0a180: fb fb fb fb fc fc fc fc fb fb fb fb fc fc fc fc
^
ffff8801d6f0a200: 00 02 fc fc fc fc fc fc 01 fc fc fc fc fc fc fc
ffff8801d6f0a280: fb fb fb fb fc fc fc fc fb fb fb fb fc fc fc fc
==================================================================
---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzkaller@googlegroups.com.
syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is
merged
into any tree, please reply to this email with:
#syz fix: exact-commit-title
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.
^ permalink raw reply
* Re: [PATCH] net: ethernet: ucc: fix spelling mistake: "tx-late-collsion" -> "tx-late-collision"
From: David Miller @ 2018-04-30 13:30 UTC (permalink / raw)
To: colin.king
Cc: leoyang.li, netdev, linuxppc-dev, kernel-janitors, linux-kernel
In-Reply-To: <20180428095707.7424-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Sat, 28 Apr 2018 10:57:07 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to spelling mistake in tx_fw_stat_gstrings text
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH] liquidio: fix spelling mistake: "mac_tx_multi_collison" -> "mac_tx_multi_collision"
From: David Miller @ 2018-04-30 13:30 UTC (permalink / raw)
To: colin.king
Cc: derek.chickles, satananda.burla, felix.manlunas, raghu.vatsavayi,
netdev, kernel-janitors, linux-kernel
In-Reply-To: <20180428095216.7236-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Sat, 28 Apr 2018 10:52:16 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to spelling mistake in oct_stats_strings text
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH] qed: fix spelling mistake: "checksumed" -> "checksummed"
From: David Miller @ 2018-04-30 13:30 UTC (permalink / raw)
To: colin.king
Cc: Ariel.Elior, everest-linux-l2, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20180428094320.7016-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Sat, 28 Apr 2018 10:43:20 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to spelling mistake in DP_INFO message text
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH V2 net-next 0/6] liquidio: enhanced ethtool --set-channels feature
From: David Miller @ 2018-04-30 13:26 UTC (permalink / raw)
To: felix.manlunas
Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla,
intiyaz.basha
In-Reply-To: <20180428063204.GA3229@felix-thinkpad.cavium.com>
From: Felix Manlunas <felix.manlunas@cavium.com>
Date: Fri, 27 Apr 2018 23:32:04 -0700
> From: Intiyaz Basha <intiyaz.basha@cavium.com>
>
> For the ethtool --set-channels feature, the liquidio driver currently
> accepts max combined value as the queue count configured during driver
> load time, where max combined count is the total count of input and output
> queues. This limitation is applicable only when SR-IOV is enabled, that
> is, when VFs are created for PF. If SR-IOV is not enabled, the driver can
> configure max supported (64) queues.
>
> This series of patches are for enhancing driver to accept
> max supported queues for ethtool --set-channels.
>
> Changes in V2:
> Only patch #6 was changed to fix these Sparse warnings reported by kbuild
> test robot:
> lio_ethtool.c:848:5: warning: symbol 'lio_23xx_reconfigure_queue_count'
> was not declared. Should it be static?
> lio_ethtool.c:877:22: warning: incorrect type in assignment (different
> base types)
> lio_ethtool.c:878:22: warning: incorrect type in assignment (different
> base types)
> lio_ethtool.c:879:22: warning: incorrect type in assignment (different
> base types)
Series applied, thank you.
^ permalink raw reply
* Re: i.MX6S/DL and QCA8334 switch using DSA driver - CPU port not working
From: Andrew Lunn @ 2018-04-30 13:20 UTC (permalink / raw)
To: Michal Vokáč; +Cc: netdev, Vivien Didelot, Florian Fainelli
In-Reply-To: <48c029f1-1632-573f-c628-86b4972d668c@gmail.com>
> Using rgmii-id for the port is not valid as the qca8k driver does not support
> that mode. It only supports rgmii and sgmii. I think this is actually not
> correct. When phy-mode is set to rgmii for port the qca8k driver configures
> internal delays in the switch. So it behaves like rgmii-id I think.
>
> Should not it be:
>
> --- a/drivers/net/dsa/qca8k.c
> +++ b/drivers/net/dsa/qca8k.c
> @@ -474,7 +474,7 @@ qca8k_set_pad_ctrl(struct qca8k_priv *priv, int port, int mode)
> * PHY or MAC.
> */
> switch (mode) {
> - case PHY_INTERFACE_MODE_RGMII:
> + case PHY_INTERFACE_MODE_RGMII_ID:
> qca8k_write(priv, reg,
> QCA8K_PORT_PAD_RGMII_EN |
> QCA8K_PORT_PAD_RGMII_TX_DELAY(3) |
We have to be careful cleaning this up. It has the potential to break
existing boards when using an old device tree blob.
Andrew
^ permalink raw reply
* Re: [PATCH 04/40] proc: introduce proc_create_seq{,_data}
From: David Howells @ 2018-04-30 13:19 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-rtc, Alessandro Zummo, Alexandre Belloni, devel, linux-scsi,
linux-acpi, Greg Kroah-Hartman, Jiri Slaby, megaraidlinux.pdl,
linux-kernel, Alexey Dobriyan, dhowells, linux-ide,
netfilter-devel, Alexander Viro, netdev, Andrew Morton,
linux-ext4, linux-afs, jfs-discussion, drbd-dev
In-Reply-To: <20180425154827.32251-5-hch@lst.de>
Christoph Hellwig <hch@lst.de> wrote:
> +
> +struct proc_dir_entry *proc_create_seq_data(const char *name, umode_t mode,
> + struct proc_dir_entry *parent, const struct seq_operations *ops,
> + void *data)
> +{
> ...
> +EXPORT_SYMBOL(proc_create_seq_data);
Please add documentation comments to exported functions when you add them.
David
^ permalink raw reply
* Re: [PATCH] net: phy: marvell: clear wol event before setting it
From: Andrew Lunn @ 2018-04-30 13:17 UTC (permalink / raw)
To: Jisheng Zhang
Cc: Bhadram Varka, Florian Fainelli, David S. Miller, netdev,
linux-kernel, Jingju Hou
In-Reply-To: <20180427152555.5e8efb9c@xhacker.debian>
> > diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
> > index ed8a67d..5d3d138 100644
> > --- a/drivers/net/phy/marvell.c
> > +++ b/drivers/net/phy/marvell.c
> > @@ -55,6 +55,7 @@
> >
> > #define MII_M1011_IEVENT 0x13
> > #define MII_M1011_IEVENT_CLEAR 0x0000
> > +#define MII_M1011_IEVENT_WOL_EVENT BIT(7)
> >
> > #define MII_M1011_IMASK 0x12
> > - #define MII_M1011_IMASK_INIT 0x6400
> > + #define MII_M1011_IMASK_INIT 0x6480
> >
> > @@ -195,13 +196,40 @@ struct marvell_priv {
> > bool copper;
> > };
> >
> > +static int marvell_clear_wol_status(struct phy_device *phydev)
> > +{
> > + int err, temp, oldpage;
> > +
> > + oldpage = phy_read(phydev, MII_MARVELL_PHY_PAGE);
> > + if (oldpage < 0)
> > + return oldpage;
> > +
> > + err = phy_write(phydev, MII_MARVELL_PHY_PAGE,
> > + MII_88E1318S_PHY_WOL_PAGE);
> > + if (err < 0)
> > + return err;
> > +
> > + /*
> > + * Clear WOL status so that for next WOL event
> > + * interrupt will be generated by HW
> > + */
> > + temp = phy_read(phydev, MII_88E1318S_PHY_WOL_CTRL);
> > + temp |= MII_88E1318S_PHY_WOL_CTRL_CLEAR_WOL_STATUS;
> > + err = phy_write(phydev, MII_88E1318S_PHY_WOL_CTRL, temp);
>
> is it better to reuse __phy_write()?
phy_modify_paged() would be the best function to use.
Andrew
^ permalink raw reply
* Re: Representing cpu-port of a switch
From: sk.syed2 @ 2018-04-30 13:06 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, jayaram, syeds, andrew, vivien.didelot
In-Reply-To: <F2B0308A-7EE7-4175-A338-18CD27A10EC5@gmail.com>
> Again, pretty standard. What you probably meant is that for host destined or initiated traffic you must use that internal port to egress/ingress frames towards the other external ports.
>
Yes.
>
>>Without tagging, we cant really use DSA, and hide the cpu/dsa port. So
>>if we expose this cpu port as a interface with fixed-phy
>>infrastructure does it create any problems?
>
> Well the fact that you don't have a tagging protocol does not really mean you cannot use DSA. You could create your own tagging format which in your case could be as simple as keeping the prepended DMA packet descriptor and have the parsing of that descriptor be done in a DSA tagger driver.
This would need HW change wont it?
Not that I would necessarily recommend that though, see below.
>
> DSA documentation says one
>>cannot open a socket on cpu/dsa port and send/receive traffic. Is it
>>fairly common to use internal/cpu port as a network interface- i.e,
>>creating a socket and send/receive traffic?
>
> In the context of DSA, all external ports are represented by a network device. This means that the CPU/management port is only used to ingress/egress frames that include the tag which either the switch hardware inserts on its way to the host or conversely that the host must insert to have the switch do the appropriate switching operation. If you do not use tags and you still have a way to target specific external ports the same representation should happen and you do not want to expose the internal port because it will only be used to send/receive traffic from the external ports and it will not be used to send or receive traffic to itself (so to speak).
Just like with DSA you should have the ability to create network
devices that are per-port and you can use the HW provided information
to deliver packets to the appropriate destination port, conversely
send from the appropriate source port.
>
>
The switch HW doesn't have any provision to target specific external
port. I think I didnt make this clear. We would like to integrate a
switch along with an endpoint into a single HW. Meaning we would like
to use internal cpu port as any normal network port to send and
receive traffic. The external network ports will not be used to
send/receive normal traffic(except for control/mgmt frames). So, the
two external front panel ports tied to phys are lets say eth1, eth2.
The cpu port tied to DMAs is represented using fixed-link/always_on
interface say ep0(endpoint). Now applications can open a socket and
send/receive traffic from ep0. The switch does forwarding based on
programmed CAM. Do you see any problem with this approach?
>>One problem is how to report back when network errors(like if both
>>front panel ports are disconnected, the expectation is to bring this
>>cpu port down?).
>
> The CPU port should be considered always UP and the external ports must have proper link notifications in place through PHYLIB/PHYLINK preferably. With link management in place the carrier state is properly managed and the network stack won't send traffic from a port that is not UP.
>
>>We also need to offload all the switch configuration to switch-dev. So
>>the question is using switch-dev without DSA and representing a cpu
>>port as a normal network interface would be ok?
>
> Using switchdev without DSA is absolutely okay, see rocker and mlxsw, but neither of those do represent their CPU/management port for the reasons outlined above that it is only used to convey traffic to/from other ports that have a proper network device representation.
>
May be this is something elementary, but what do you mean by proper
network device representation that cpu port lacks?
^ permalink raw reply
* VRF: ICMPV6 Echo Reply failed to egress if ingress pkt Src is IPV6 Global and Dest is IPV6 Link Local.
From: Sukumar Gopalakrishnan @ 2018-04-30 12:58 UTC (permalink / raw)
To: netdev
VRF: ICMPV6 Echo Reply failed to egress if ingress pkt Src is IPV6
Global and Dest is IPV6 Link Local.
KERNEL VERSION:
================
4.14.28
BUG REPORT:
============
https://bugzilla.kernel.org/show_bug.cgi?id=199573
CONFIGURATION AND PACKET FLOW:
==============================
1) Created VRF device(Vrf_258) and enslaved network device(v1_F4246) to this
VRF. Assigned Global address 2001::1 and fe80::1 to VLAN device.
/exos/bin # ifconfig -a v1_F4246
v1_F4246 Link encap:Ethernet HWaddr 00:04:96:98:C9:18
inet6 addr: 2001::1/64 Scope:Global
inet6 addr: fe80::1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:52 errors:0 dropped:0 overruns:0 frame:0
TX packets:98 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3024 (2.9 KiB) TX bytes:8116 (7.9 KiB)
/exos/bin # ifconfig -a vrf_258
vrf_258 Link encap:Ethernet HWaddr 00:04:96:98:C9:18
inet addr:127.0.0.1 Mask:255.0.0.0
UP RUNNING NOARP MASTER MTU:65536 Metric:1
RX packets:27 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1512 (1.4 KiB) TX bytes:0 (0.0 B)
/exos/bin # ip link show vrf_258
14: vrf_258: <NOARP,MASTER,UP,LOWER_UP> mtu 65536 qdisc noqueue state
UP mode DEFAULT group default qlen 1000
link/ether 00:04:96:98:c9:18 brd ff:ff:ff:ff:ff:ff
/exos/bin # ip link show v1_F4246
54: v1_F4246: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
master vrf_258 state UNKNOWN mode DEFAULT group default qlen 1000
link/ether 00:04:96:98:c9:18 brd ff:ff:ff:ff:ff:ff
2) Received Ping request to local intf IP 2001::1 from neigbour DUT
with following SRC/Dest.
Rx ICMPV6 Echo Req Pkt's SRC IP = fe800000:0:0:2, DEST IP = 20010000:0:0:1
3) Incoming packet SRC is IPv6 Global address so skb->dev changed to
vrf_258 by ip receive function.
4) Since it is local delivered packet icmpv6_echo_reply() is invoked.
This function tries to send reply with
SRC IP = 20010000:0:0:1
DEST IP = fe800000:0:0:2
flowi6_oif = vrf_dev258
5) ip6_dst_lookup() is failed for this packet and got dropped.
fl6.flowi6_oif = icmp6_iif(skb);
flowi6_oif is having vrf device index when ip6_dst_lookup() is invoked.
Pkt flows to ip6_dst_lookup() ->
ip6_dst_lookup_tail()->ip6_route_output_flags()->l3mdev_link_scope_lookup()->vrf_link_scope_lookup()
There is a check in vrf_link_scope_lookup() which is dropping the reply packet.
In this case flowi6_oif and dev->ifindex are same.
..
if (fl6->flowi6_oif == dev->ifindex) {
dst = &net->ipv6.ip6_null_entry->dst;
dst_hold(dst);
return dst;
}
..
TEMP FIX:
=========
Return Ingress vlan device's ifIndex instead of skb->dev's.
static int icmp6_iif(const struct sk_buff *skb)
{
int iif = IP6CB(skb)->iif; // skb->dev->ifindex;
..
..
}
^ permalink raw reply
* Re: DSA
From: Andrew Lunn @ 2018-04-30 12:50 UTC (permalink / raw)
To: Dave Richards; +Cc: netdev@vger.kernel.org
In-Reply-To: <MWHPR06MB3503CE521D6993C7786A3E93DC8D0@MWHPR06MB3503.namprd06.prod.outlook.com>
On Fri, Apr 27, 2018 at 06:10:55PM +0000, Dave Richards wrote:
> Hello,
>
> I am building a prototype for a new product based on a Lanner, Inc. embedded PC. It is an Intel Celeron-based system with two host I210 GbE chips connected to 2 MV88E6172 chips (one NIC to one switch). Everything appears to show up hardware-wise. My question is, what is the next step? How does DSA know which NICs are intended to be masters? Is this supposed to be auto-detected or is this knowledge supposed to be communicated explicitly. Reading through the DSA driver code I see that there is a check of the OF property list for the device for a "label"/"cpu" property/value pair that needs to be present. Who sets this and when?
Hi Dave
Since you are on Intel, you don't have simple access to Device
tree. So you need to use platform data instead. Or possibly start
hacking on ACPI support for DSA. For the moment, i would suggest
platform data.
I'm also working on a similar setup, intel CPU connected to an
MV88E6532. I have some work in progress code i can share with you,
which i want to submit for inclusion to mainline in the next few
weeks. This adds platform data support to the mv88e6xxx driver, and
will give you an idea how you link the MAC to the switch.
What MDIO bus do you connect the switches to? The i210 MDIO bus? If
so, this is going to cause you a problem. The igb driver ignores the
Linux MDIO and PHY code, and does it all itself. DSA assumes the
switch can be accessed using Linux standard MDIO interfaces. So you
have going to have to hack on the igb driver to make it use standard
MDIO.
Andrew
^ permalink raw reply
* Re: ID of (former "National") TI's PHY DP83848
From: Andrew Lunn @ 2018-04-30 12:22 UTC (permalink / raw)
To: Juergen Borleis; +Cc: netdev, Florian Fainelli
In-Reply-To: <201804271351.05091.jbe@pengutronix.de>
On Fri, Apr 27, 2018 at 01:51:04PM +0200, Juergen Borleis wrote:
> Hi,
>
> I have worked on a DP83848 variant without an interrupt line. While at it, I
> read through all datasheets of existing variants of the DP83848 phy.
>
> Here is what I've found so far:
>
> +--------------+--------------+--------+-----+
> | Variant | Phy ID | Note | IRQ |
> +--------------+--------------+--------+-----+
> | DP83848H | 0x20005c90 | MINI | NO |
> +--------------+--------------+--------+-----+
> | DP83848J | 0x20005c90 | MINI | NO |
> +--------------+--------------+--------+-----+
> | DP83848K | 0x20005c90 | MINI | NO |
> +--------------+--------------+--------+-----+
> | DP83848M | 0x20005c90 | MINI | NO |
> +--------------+--------------+--------+-----+
> | DP83848T | 0x20005c90 | MINI | NO |
> +--------------+--------------+--------+-----+
> | DP83848EP | 0x20005c90 | | YES |
> +--------------+--------------+--------+-----+
> | DP83848HT | 0x20005c90 | | YES |
> +--------------+--------------+--------+-----+
> | DP83848Q | 0x20005ca2 | MINI | NO |
> +--------------+--------------+--------+-----+
> | DP83848V | 0x20005ca2 | | YES |
> +--------------+--------------+--------+-----+
> | DP83848C | 0x20005ca2 | | YES |
> +--------------+--------------+--------+-----+
>
> "MINI" means a less pin count variant.
> "IRQ"-"YES" means, the device has a interrupt line,
> "IRQ"-"NO" means, the device has no interrupt line.
>
> How to deal with interrupts, if the device itself has no interrupt line (and
> uses the same phy ID)? How to deal with the same Phy ID used for different
> devices and different features?
Hi Juergen
Interrupts are always in two parts. One part is the PHY driver side,
saying it supports interrupts, providing the functions to configure
interrupts, check if an interrupt did happen, and acknowledge it. The
second part is somehow specifying which specific interrupt is used,
via device tree, or platform data. Only when both are supplied will
PHYLIB try to use the interrupts.
So it should be safe if they PHY driver always says it supports
interrupts. The platform then must not provide an interrupt number
when there is not one.
As for other features, you probably need to take same approach. How
does a mini differ? Less LEDs? Only RGMII, not GMII?
Andrew
^ permalink raw reply
* Re: [PATCH bpf-next 0/3] bpf: fix formatting for eBPF helper doc
From: Daniel Borkmann @ 2018-04-30 11:57 UTC (permalink / raw)
To: Quentin Monnet, ast; +Cc: netdev, oss-drivers
In-Reply-To: <20180430103905.12863-1-quentin.monnet@netronome.com>
On 04/30/2018 12:39 PM, Quentin Monnet wrote:
> Here is a follow-up set for eBPF helper documentation, with two patches to
> fix formatting issues:
>
> - One to fix an error I introduced with the initial set for the doc.
> - One for the newly added bpf_get_stack(), that is currently not parsed
> correctly with the Python script (function signature is fine, but
> description and return value appear as empty).
>
> There is no change to text contents in this set.
Applied to bpf-next, thanks Quentin!
^ permalink raw reply
* [PATCH net-next V2] cls_flower: Support multiple masks per priority
From: Paul Blakey @ 2018-04-30 11:28 UTC (permalink / raw)
To: Jiri Pirko, Cong Wang, Jamal Hadi Salim, David Miller, netdev
Cc: Yevgeny Kliteynik, Roi Dayan, Shahar Klein, Mark Bloch,
Or Gerlitz, Paul Blakey
Currently flower doesn't support inserting filters with different masks
on a single priority, even if the actual flows (key + mask) inserted
aren't overlapping, as with the use case of offloading openvswitch
datapath flows. Instead one must go up one level, and assign different
priorities for each mask, which will create a different flower
instances.
This patch opens flower to support more than one mask per priority,
and a single flower instance. It does so by adding another hash table
on top of the existing one which will store the different masks,
and the filters that share it.
The user is left with the responsibility of ensuring non overlapping
flows, otherwise precedence is not guaranteed.
Signed-off-by: Paul Blakey <paulb@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
Changes:
V1 -> V2: in fl_init, removed unnessecry err variable, just return direct result instead.
in fl_mask_range, removed extra new line.
commit msg, spelling.
net/sched/cls_flower.c | 275 +++++++++++++++++++++++++++++++------------------
1 file changed, 174 insertions(+), 101 deletions(-)
diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index d964e60..eacaaf8 100644
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@ -61,16 +61,18 @@ struct fl_flow_mask_range {
struct fl_flow_mask {
struct fl_flow_key key;
struct fl_flow_mask_range range;
- struct rcu_head rcu;
+ struct rhash_head ht_node;
+ struct rhashtable ht;
+ struct rhashtable_params filter_ht_params;
+ struct flow_dissector dissector;
+ struct list_head filters;
+ struct rcu_head rcu;
+ struct list_head list;
};
struct cls_fl_head {
struct rhashtable ht;
- struct fl_flow_mask mask;
- struct flow_dissector dissector;
- bool mask_assigned;
- struct list_head filters;
- struct rhashtable_params ht_params;
+ struct list_head masks;
union {
struct work_struct work;
struct rcu_head rcu;
@@ -79,6 +81,7 @@ struct cls_fl_head {
};
struct cls_fl_filter {
+ struct fl_flow_mask *mask;
struct rhash_head ht_node;
struct fl_flow_key mkey;
struct tcf_exts exts;
@@ -94,6 +97,13 @@ struct cls_fl_filter {
struct net_device *hw_dev;
};
+static const struct rhashtable_params mask_ht_params = {
+ .key_offset = offsetof(struct fl_flow_mask, key),
+ .key_len = sizeof(struct fl_flow_key),
+ .head_offset = offsetof(struct fl_flow_mask, ht_node),
+ .automatic_shrinking = true,
+};
+
static unsigned short int fl_mask_range(const struct fl_flow_mask *mask)
{
return mask->range.end - mask->range.start;
@@ -103,13 +113,19 @@ static void fl_mask_update_range(struct fl_flow_mask *mask)
{
const u8 *bytes = (const u8 *) &mask->key;
size_t size = sizeof(mask->key);
- size_t i, first = 0, last = size - 1;
+ size_t i, first = 0, last;
- for (i = 0; i < sizeof(mask->key); i++) {
+ for (i = 0; i < size; i++) {
+ if (bytes[i]) {
+ first = i;
+ break;
+ }
+ }
+ last = first;
+ for (i = size - 1; i != first; i--) {
if (bytes[i]) {
- if (!first && i)
- first = i;
last = i;
+ break;
}
}
mask->range.start = rounddown(first, sizeof(long));
@@ -140,12 +156,11 @@ static void fl_clear_masked_range(struct fl_flow_key *key,
memset(fl_key_get_start(key, mask), 0, fl_mask_range(mask));
}
-static struct cls_fl_filter *fl_lookup(struct cls_fl_head *head,
+static struct cls_fl_filter *fl_lookup(struct fl_flow_mask *mask,
struct fl_flow_key *mkey)
{
- return rhashtable_lookup_fast(&head->ht,
- fl_key_get_start(mkey, &head->mask),
- head->ht_params);
+ return rhashtable_lookup_fast(&mask->ht, fl_key_get_start(mkey, mask),
+ mask->filter_ht_params);
}
static int fl_classify(struct sk_buff *skb, const struct tcf_proto *tp,
@@ -153,28 +168,28 @@ static int fl_classify(struct sk_buff *skb, const struct tcf_proto *tp,
{
struct cls_fl_head *head = rcu_dereference_bh(tp->root);
struct cls_fl_filter *f;
+ struct fl_flow_mask *mask;
struct fl_flow_key skb_key;
struct fl_flow_key skb_mkey;
- if (!atomic_read(&head->ht.nelems))
- return -1;
-
- fl_clear_masked_range(&skb_key, &head->mask);
+ list_for_each_entry_rcu(mask, &head->masks, list) {
+ fl_clear_masked_range(&skb_key, mask);
- skb_key.indev_ifindex = skb->skb_iif;
- /* skb_flow_dissect() does not set n_proto in case an unknown protocol,
- * so do it rather here.
- */
- skb_key.basic.n_proto = skb->protocol;
- skb_flow_dissect_tunnel_info(skb, &head->dissector, &skb_key);
- skb_flow_dissect(skb, &head->dissector, &skb_key, 0);
+ skb_key.indev_ifindex = skb->skb_iif;
+ /* skb_flow_dissect() does not set n_proto in case an unknown
+ * protocol, so do it rather here.
+ */
+ skb_key.basic.n_proto = skb->protocol;
+ skb_flow_dissect_tunnel_info(skb, &mask->dissector, &skb_key);
+ skb_flow_dissect(skb, &mask->dissector, &skb_key, 0);
- fl_set_masked_key(&skb_mkey, &skb_key, &head->mask);
+ fl_set_masked_key(&skb_mkey, &skb_key, mask);
- f = fl_lookup(head, &skb_mkey);
- if (f && !tc_skip_sw(f->flags)) {
- *res = f->res;
- return tcf_exts_exec(skb, &f->exts, res);
+ f = fl_lookup(mask, &skb_mkey);
+ if (f && !tc_skip_sw(f->flags)) {
+ *res = f->res;
+ return tcf_exts_exec(skb, &f->exts, res);
+ }
}
return -1;
}
@@ -187,11 +202,28 @@ static int fl_init(struct tcf_proto *tp)
if (!head)
return -ENOBUFS;
- INIT_LIST_HEAD_RCU(&head->filters);
+ INIT_LIST_HEAD_RCU(&head->masks);
rcu_assign_pointer(tp->root, head);
idr_init(&head->handle_idr);
- return 0;
+ return rhashtable_init(&head->ht, &mask_ht_params);
+}
+
+static bool fl_mask_put(struct cls_fl_head *head, struct fl_flow_mask *mask,
+ bool async)
+{
+ if (!list_empty(&mask->filters))
+ return false;
+
+ rhashtable_remove_fast(&head->ht, &mask->ht_node, mask_ht_params);
+ rhashtable_destroy(&mask->ht);
+ list_del_rcu(&mask->list);
+ if (async)
+ kfree_rcu(mask, rcu);
+ else
+ kfree(mask);
+
+ return true;
}
static void __fl_destroy_filter(struct cls_fl_filter *f)
@@ -234,8 +266,6 @@ static void fl_hw_destroy_filter(struct tcf_proto *tp, struct cls_fl_filter *f,
}
static int fl_hw_replace_filter(struct tcf_proto *tp,
- struct flow_dissector *dissector,
- struct fl_flow_key *mask,
struct cls_fl_filter *f,
struct netlink_ext_ack *extack)
{
@@ -247,8 +277,8 @@ static int fl_hw_replace_filter(struct tcf_proto *tp,
tc_cls_common_offload_init(&cls_flower.common, tp, f->flags, extack);
cls_flower.command = TC_CLSFLOWER_REPLACE;
cls_flower.cookie = (unsigned long) f;
- cls_flower.dissector = dissector;
- cls_flower.mask = mask;
+ cls_flower.dissector = &f->mask->dissector;
+ cls_flower.mask = &f->mask->key;
cls_flower.key = &f->mkey;
cls_flower.exts = &f->exts;
cls_flower.classid = f->res.classid;
@@ -283,28 +313,31 @@ static void fl_hw_update_stats(struct tcf_proto *tp, struct cls_fl_filter *f)
&cls_flower, false);
}
-static void __fl_delete(struct tcf_proto *tp, struct cls_fl_filter *f,
+static bool __fl_delete(struct tcf_proto *tp, struct cls_fl_filter *f,
struct netlink_ext_ack *extack)
{
struct cls_fl_head *head = rtnl_dereference(tp->root);
+ bool async = tcf_exts_get_net(&f->exts);
+ bool last;
idr_remove(&head->handle_idr, f->handle);
list_del_rcu(&f->list);
+ last = fl_mask_put(head, f->mask, async);
if (!tc_skip_hw(f->flags))
fl_hw_destroy_filter(tp, f, extack);
tcf_unbind_filter(tp, &f->res);
- if (tcf_exts_get_net(&f->exts))
+ if (async)
call_rcu(&f->rcu, fl_destroy_filter);
else
__fl_destroy_filter(f);
+
+ return last;
}
static void fl_destroy_sleepable(struct work_struct *work)
{
struct cls_fl_head *head = container_of(work, struct cls_fl_head,
work);
- if (head->mask_assigned)
- rhashtable_destroy(&head->ht);
kfree(head);
module_put(THIS_MODULE);
}
@@ -320,10 +353,15 @@ static void fl_destroy_rcu(struct rcu_head *rcu)
static void fl_destroy(struct tcf_proto *tp, struct netlink_ext_ack *extack)
{
struct cls_fl_head *head = rtnl_dereference(tp->root);
+ struct fl_flow_mask *mask, *next_mask;
struct cls_fl_filter *f, *next;
- list_for_each_entry_safe(f, next, &head->filters, list)
- __fl_delete(tp, f, extack);
+ list_for_each_entry_safe(mask, next_mask, &head->masks, list) {
+ list_for_each_entry_safe(f, next, &mask->filters, list) {
+ if (__fl_delete(tp, f, extack))
+ break;
+ }
+ }
idr_destroy(&head->handle_idr);
__module_get(THIS_MODULE);
@@ -715,14 +753,14 @@ static int fl_set_key(struct net *net, struct nlattr **tb,
return ret;
}
-static bool fl_mask_eq(struct fl_flow_mask *mask1,
- struct fl_flow_mask *mask2)
+static void fl_mask_copy(struct fl_flow_mask *dst,
+ struct fl_flow_mask *src)
{
- const long *lmask1 = fl_key_get_start(&mask1->key, mask1);
- const long *lmask2 = fl_key_get_start(&mask2->key, mask2);
+ const void *psrc = fl_key_get_start(&src->key, src);
+ void *pdst = fl_key_get_start(&dst->key, src);
- return !memcmp(&mask1->range, &mask2->range, sizeof(mask1->range)) &&
- !memcmp(lmask1, lmask2, fl_mask_range(mask1));
+ memcpy(pdst, psrc, fl_mask_range(src));
+ dst->range = src->range;
}
static const struct rhashtable_params fl_ht_params = {
@@ -731,14 +769,13 @@ static const struct rhashtable_params fl_ht_params = {
.automatic_shrinking = true,
};
-static int fl_init_hashtable(struct cls_fl_head *head,
- struct fl_flow_mask *mask)
+static int fl_init_mask_hashtable(struct fl_flow_mask *mask)
{
- head->ht_params = fl_ht_params;
- head->ht_params.key_len = fl_mask_range(mask);
- head->ht_params.key_offset += mask->range.start;
+ mask->filter_ht_params = fl_ht_params;
+ mask->filter_ht_params.key_len = fl_mask_range(mask);
+ mask->filter_ht_params.key_offset += mask->range.start;
- return rhashtable_init(&head->ht, &head->ht_params);
+ return rhashtable_init(&mask->ht, &mask->filter_ht_params);
}
#define FL_KEY_MEMBER_OFFSET(member) offsetof(struct fl_flow_key, member)
@@ -761,8 +798,7 @@ static int fl_init_hashtable(struct cls_fl_head *head,
FL_KEY_SET(keys, cnt, id, member); \
} while(0);
-static void fl_init_dissector(struct cls_fl_head *head,
- struct fl_flow_mask *mask)
+static void fl_init_dissector(struct fl_flow_mask *mask)
{
struct flow_dissector_key keys[FLOW_DISSECTOR_KEY_MAX];
size_t cnt = 0;
@@ -802,31 +838,66 @@ static void fl_init_dissector(struct cls_fl_head *head,
FL_KEY_SET_IF_MASKED(&mask->key, keys, cnt,
FLOW_DISSECTOR_KEY_ENC_PORTS, enc_tp);
- skb_flow_dissector_init(&head->dissector, keys, cnt);
+ skb_flow_dissector_init(&mask->dissector, keys, cnt);
+}
+
+static struct fl_flow_mask *fl_create_new_mask(struct cls_fl_head *head,
+ struct fl_flow_mask *mask)
+{
+ struct fl_flow_mask *newmask;
+ int err;
+
+ newmask = kzalloc(sizeof(*newmask), GFP_KERNEL);
+ if (!newmask)
+ return ERR_PTR(-ENOMEM);
+
+ fl_mask_copy(newmask, mask);
+
+ err = fl_init_mask_hashtable(newmask);
+ if (err)
+ goto errout_free;
+
+ fl_init_dissector(newmask);
+
+ INIT_LIST_HEAD_RCU(&newmask->filters);
+
+ err = rhashtable_insert_fast(&head->ht, &newmask->ht_node,
+ mask_ht_params);
+ if (err)
+ goto errout_destroy;
+
+ list_add_tail_rcu(&newmask->list, &head->masks);
+
+ return newmask;
+
+errout_destroy:
+ rhashtable_destroy(&newmask->ht);
+errout_free:
+ kfree(newmask);
+
+ return ERR_PTR(err);
}
static int fl_check_assign_mask(struct cls_fl_head *head,
+ struct cls_fl_filter *fnew,
+ struct cls_fl_filter *fold,
struct fl_flow_mask *mask)
{
- int err;
+ struct fl_flow_mask *newmask;
- if (head->mask_assigned) {
- if (!fl_mask_eq(&head->mask, mask))
+ fnew->mask = rhashtable_lookup_fast(&head->ht, mask, mask_ht_params);
+ if (!fnew->mask) {
+ if (fold)
return -EINVAL;
- else
- return 0;
- }
- /* Mask is not assigned yet. So assign it and init hashtable
- * according to that.
- */
- err = fl_init_hashtable(head, mask);
- if (err)
- return err;
- memcpy(&head->mask, mask, sizeof(head->mask));
- head->mask_assigned = true;
+ newmask = fl_create_new_mask(head, mask);
+ if (IS_ERR(newmask))
+ return PTR_ERR(newmask);
- fl_init_dissector(head, mask);
+ fnew->mask = newmask;
+ } else if (fold && fold->mask == fnew->mask) {
+ return -EINVAL;
+ }
return 0;
}
@@ -924,30 +995,26 @@ static int fl_change(struct net *net, struct sk_buff *in_skb,
if (err)
goto errout_idr;
- err = fl_check_assign_mask(head, &mask);
+ err = fl_check_assign_mask(head, fnew, fold, &mask);
if (err)
goto errout_idr;
if (!tc_skip_sw(fnew->flags)) {
- if (!fold && fl_lookup(head, &fnew->mkey)) {
+ if (!fold && fl_lookup(fnew->mask, &fnew->mkey)) {
err = -EEXIST;
- goto errout_idr;
+ goto errout_mask;
}
- err = rhashtable_insert_fast(&head->ht, &fnew->ht_node,
- head->ht_params);
+ err = rhashtable_insert_fast(&fnew->mask->ht, &fnew->ht_node,
+ fnew->mask->filter_ht_params);
if (err)
- goto errout_idr;
+ goto errout_mask;
}
if (!tc_skip_hw(fnew->flags)) {
- err = fl_hw_replace_filter(tp,
- &head->dissector,
- &mask.key,
- fnew,
- extack);
+ err = fl_hw_replace_filter(tp, fnew, extack);
if (err)
- goto errout_idr;
+ goto errout_mask;
}
if (!tc_in_hw(fnew->flags))
@@ -955,8 +1022,9 @@ static int fl_change(struct net *net, struct sk_buff *in_skb,
if (fold) {
if (!tc_skip_sw(fold->flags))
- rhashtable_remove_fast(&head->ht, &fold->ht_node,
- head->ht_params);
+ rhashtable_remove_fast(&fold->mask->ht,
+ &fold->ht_node,
+ fold->mask->filter_ht_params);
if (!tc_skip_hw(fold->flags))
fl_hw_destroy_filter(tp, fold, NULL);
}
@@ -970,12 +1038,15 @@ static int fl_change(struct net *net, struct sk_buff *in_skb,
tcf_exts_get_net(&fold->exts);
call_rcu(&fold->rcu, fl_destroy_filter);
} else {
- list_add_tail_rcu(&fnew->list, &head->filters);
+ list_add_tail_rcu(&fnew->list, &fnew->mask->filters);
}
kfree(tb);
return 0;
+errout_mask:
+ fl_mask_put(head, fnew->mask, false);
+
errout_idr:
if (fnew->handle)
idr_remove(&head->handle_idr, fnew->handle);
@@ -994,10 +1065,10 @@ static int fl_delete(struct tcf_proto *tp, void *arg, bool *last,
struct cls_fl_filter *f = arg;
if (!tc_skip_sw(f->flags))
- rhashtable_remove_fast(&head->ht, &f->ht_node,
- head->ht_params);
+ rhashtable_remove_fast(&f->mask->ht, &f->ht_node,
+ f->mask->filter_ht_params);
__fl_delete(tp, f, extack);
- *last = list_empty(&head->filters);
+ *last = list_empty(&head->masks);
return 0;
}
@@ -1005,16 +1076,19 @@ static void fl_walk(struct tcf_proto *tp, struct tcf_walker *arg)
{
struct cls_fl_head *head = rtnl_dereference(tp->root);
struct cls_fl_filter *f;
-
- list_for_each_entry_rcu(f, &head->filters, list) {
- if (arg->count < arg->skip)
- goto skip;
- if (arg->fn(tp, f, arg) < 0) {
- arg->stop = 1;
- break;
- }
+ struct fl_flow_mask *mask;
+
+ list_for_each_entry_rcu(mask, &head->masks, list) {
+ list_for_each_entry_rcu(f, &mask->filters, list) {
+ if (arg->count < arg->skip)
+ goto skip;
+ if (arg->fn(tp, f, arg) < 0) {
+ arg->stop = 1;
+ break;
+ }
skip:
- arg->count++;
+ arg->count++;
+ }
}
}
@@ -1150,7 +1224,6 @@ static int fl_dump_key_flags(struct sk_buff *skb, u32 flags_key, u32 flags_mask)
static int fl_dump(struct net *net, struct tcf_proto *tp, void *fh,
struct sk_buff *skb, struct tcmsg *t)
{
- struct cls_fl_head *head = rtnl_dereference(tp->root);
struct cls_fl_filter *f = fh;
struct nlattr *nest;
struct fl_flow_key *key, *mask;
@@ -1169,7 +1242,7 @@ static int fl_dump(struct net *net, struct tcf_proto *tp, void *fh,
goto nla_put_failure;
key = &f->key;
- mask = &head->mask.key;
+ mask = &f->mask->key;
if (mask->indev_ifindex) {
struct net_device *dev;
--
2.7.4
^ permalink raw reply related
* [PATCH bpf-next 3/3] bpf: update bpf.h uapi header for tools
From: Quentin Monnet @ 2018-04-30 10:39 UTC (permalink / raw)
To: daniel, ast; +Cc: netdev, oss-drivers, quentin.monnet
In-Reply-To: <20180430103905.12863-1-quentin.monnet@netronome.com>
Bring fixes for eBPF helper documentation formatting to bpf.h under
tools/ as well.
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
---
tools/include/uapi/linux/bpf.h | 62 +++++++++++++++++++++---------------------
1 file changed, 31 insertions(+), 31 deletions(-)
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 23b334bba1a6..8daef7326bb7 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -828,12 +828,12 @@ union bpf_attr {
*
* Also, be aware that the newer helper
* **bpf_perf_event_read_value**\ () is recommended over
- * **bpf_perf_event_read*\ () in general. The latter has some ABI
+ * **bpf_perf_event_read**\ () in general. The latter has some ABI
* quirks where error and counter value are used as a return code
* (which is wrong to do since ranges may overlap). This issue is
- * fixed with bpf_perf_event_read_value(), which at the same time
- * provides more features over the **bpf_perf_event_read**\ ()
- * interface. Please refer to the description of
+ * fixed with **bpf_perf_event_read_value**\ (), which at the same
+ * time provides more features over the **bpf_perf_event_read**\
+ * () interface. Please refer to the description of
* **bpf_perf_event_read_value**\ () for details.
* Return
* The value of the perf event counter read from the map, or a
@@ -1770,33 +1770,33 @@ union bpf_attr {
*
* int bpf_get_stack(struct pt_regs *regs, void *buf, u32 size, u64 flags)
* Description
- * Return a user or a kernel stack in bpf program provided buffer.
- * To achieve this, the helper needs *ctx*, which is a pointer
- * to the context on which the tracing program is executed.
- * To store the stacktrace, the bpf program provides *buf* with
- * a nonnegative *size*.
- *
- * The last argument, *flags*, holds the number of stack frames to
- * skip (from 0 to 255), masked with
- * **BPF_F_SKIP_FIELD_MASK**. The next bits can be used to set
- * the following flags:
- *
- * **BPF_F_USER_STACK**
- * Collect a user space stack instead of a kernel stack.
- * **BPF_F_USER_BUILD_ID**
- * Collect buildid+offset instead of ips for user stack,
- * only valid if **BPF_F_USER_STACK** is also specified.
- *
- * **bpf_get_stack**\ () can collect up to
- * **PERF_MAX_STACK_DEPTH** both kernel and user frames, subject
- * to sufficient large buffer size. Note that
- * this limit can be controlled with the **sysctl** program, and
- * that it should be manually increased in order to profile long
- * user stacks (such as stacks for Java programs). To do so, use:
- *
- * ::
- *
- * # sysctl kernel.perf_event_max_stack=<new value>
+ * Return a user or a kernel stack in bpf program provided buffer.
+ * To achieve this, the helper needs *ctx*, which is a pointer
+ * to the context on which the tracing program is executed.
+ * To store the stacktrace, the bpf program provides *buf* with
+ * a nonnegative *size*.
+ *
+ * The last argument, *flags*, holds the number of stack frames to
+ * skip (from 0 to 255), masked with
+ * **BPF_F_SKIP_FIELD_MASK**. The next bits can be used to set
+ * the following flags:
+ *
+ * **BPF_F_USER_STACK**
+ * Collect a user space stack instead of a kernel stack.
+ * **BPF_F_USER_BUILD_ID**
+ * Collect buildid+offset instead of ips for user stack,
+ * only valid if **BPF_F_USER_STACK** is also specified.
+ *
+ * **bpf_get_stack**\ () can collect up to
+ * **PERF_MAX_STACK_DEPTH** both kernel and user frames, subject
+ * to sufficient large buffer size. Note that
+ * this limit can be controlled with the **sysctl** program, and
+ * that it should be manually increased in order to profile long
+ * user stacks (such as stacks for Java programs). To do so, use:
+ *
+ * ::
+ *
+ * # sysctl kernel.perf_event_max_stack=<new value>
*
* Return
* a non-negative value equal to or less than size on success, or
--
2.14.1
^ permalink raw reply related
* [PATCH bpf-next 2/3] bpf: fix formatting for bpf_get_stack() helper doc
From: Quentin Monnet @ 2018-04-30 10:39 UTC (permalink / raw)
To: daniel, ast; +Cc: netdev, oss-drivers, quentin.monnet, Yonghong Song
In-Reply-To: <20180430103905.12863-1-quentin.monnet@netronome.com>
Fix formatting (indent) for bpf_get_stack() helper documentation, so
that the doc is rendered correctly with the Python script.
Fixes: c195651e565a ("bpf: add bpf_get_stack helper")
Cc: Yonghong Song <yhs@fb.com>
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
---
Note: The error was a missing space between the '*' marking the
comments, and the tabs. This expected mixed indent comes from the fact I
started to write the doc as a RST, then copied my contents (tabs
included) in the header file and added a " * " (with a space) prefix
everywhere.
On a second thought, using such indent style was maybe... not my best idea
ever. Anyway, if indent for documenting eBPF helpers really gets to painful, we
could relax parsing rules in the Python script to make things easier.
---
include/uapi/linux/bpf.h | 54 ++++++++++++++++++++++++------------------------
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 530ff6588d8f..8daef7326bb7 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -1770,33 +1770,33 @@ union bpf_attr {
*
* int bpf_get_stack(struct pt_regs *regs, void *buf, u32 size, u64 flags)
* Description
- * Return a user or a kernel stack in bpf program provided buffer.
- * To achieve this, the helper needs *ctx*, which is a pointer
- * to the context on which the tracing program is executed.
- * To store the stacktrace, the bpf program provides *buf* with
- * a nonnegative *size*.
- *
- * The last argument, *flags*, holds the number of stack frames to
- * skip (from 0 to 255), masked with
- * **BPF_F_SKIP_FIELD_MASK**. The next bits can be used to set
- * the following flags:
- *
- * **BPF_F_USER_STACK**
- * Collect a user space stack instead of a kernel stack.
- * **BPF_F_USER_BUILD_ID**
- * Collect buildid+offset instead of ips for user stack,
- * only valid if **BPF_F_USER_STACK** is also specified.
- *
- * **bpf_get_stack**\ () can collect up to
- * **PERF_MAX_STACK_DEPTH** both kernel and user frames, subject
- * to sufficient large buffer size. Note that
- * this limit can be controlled with the **sysctl** program, and
- * that it should be manually increased in order to profile long
- * user stacks (such as stacks for Java programs). To do so, use:
- *
- * ::
- *
- * # sysctl kernel.perf_event_max_stack=<new value>
+ * Return a user or a kernel stack in bpf program provided buffer.
+ * To achieve this, the helper needs *ctx*, which is a pointer
+ * to the context on which the tracing program is executed.
+ * To store the stacktrace, the bpf program provides *buf* with
+ * a nonnegative *size*.
+ *
+ * The last argument, *flags*, holds the number of stack frames to
+ * skip (from 0 to 255), masked with
+ * **BPF_F_SKIP_FIELD_MASK**. The next bits can be used to set
+ * the following flags:
+ *
+ * **BPF_F_USER_STACK**
+ * Collect a user space stack instead of a kernel stack.
+ * **BPF_F_USER_BUILD_ID**
+ * Collect buildid+offset instead of ips for user stack,
+ * only valid if **BPF_F_USER_STACK** is also specified.
+ *
+ * **bpf_get_stack**\ () can collect up to
+ * **PERF_MAX_STACK_DEPTH** both kernel and user frames, subject
+ * to sufficient large buffer size. Note that
+ * this limit can be controlled with the **sysctl** program, and
+ * that it should be manually increased in order to profile long
+ * user stacks (such as stacks for Java programs). To do so, use:
+ *
+ * ::
+ *
+ * # sysctl kernel.perf_event_max_stack=<new value>
*
* Return
* a non-negative value equal to or less than size on success, or
--
2.14.1
^ permalink raw reply related
* [PATCH bpf-next 1/3] bpf: fix formatting for bpf_perf_event_read() helper doc
From: Quentin Monnet @ 2018-04-30 10:39 UTC (permalink / raw)
To: daniel, ast; +Cc: netdev, oss-drivers, quentin.monnet
In-Reply-To: <20180430103905.12863-1-quentin.monnet@netronome.com>
Some edits brought to the last iteration of BPF helper functions
documentation introduced an error with RST formatting. As a result, most
of one paragraph is rendered in bold text when only the name of a helper
should be. Fix it, and fix formatting of another function name in the
same paragraph.
Fixes: c6b5fb8690fa ("bpf: add documentation for eBPF helpers (42-50)")
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
---
include/uapi/linux/bpf.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 23b334bba1a6..530ff6588d8f 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -828,12 +828,12 @@ union bpf_attr {
*
* Also, be aware that the newer helper
* **bpf_perf_event_read_value**\ () is recommended over
- * **bpf_perf_event_read*\ () in general. The latter has some ABI
+ * **bpf_perf_event_read**\ () in general. The latter has some ABI
* quirks where error and counter value are used as a return code
* (which is wrong to do since ranges may overlap). This issue is
- * fixed with bpf_perf_event_read_value(), which at the same time
- * provides more features over the **bpf_perf_event_read**\ ()
- * interface. Please refer to the description of
+ * fixed with **bpf_perf_event_read_value**\ (), which at the same
+ * time provides more features over the **bpf_perf_event_read**\
+ * () interface. Please refer to the description of
* **bpf_perf_event_read_value**\ () for details.
* Return
* The value of the perf event counter read from the map, or a
--
2.14.1
^ permalink raw reply related
* [PATCH bpf-next 0/3] bpf: fix formatting for eBPF helper doc
From: Quentin Monnet @ 2018-04-30 10:39 UTC (permalink / raw)
To: daniel, ast; +Cc: netdev, oss-drivers, quentin.monnet
Hi,
Here is a follow-up set for eBPF helper documentation, with two patches to
fix formatting issues:
- One to fix an error I introduced with the initial set for the doc.
- One for the newly added bpf_get_stack(), that is currently not parsed
correctly with the Python script (function signature is fine, but
description and return value appear as empty).
There is no change to text contents in this set.
Quentin Monnet (3):
bpf: fix formatting for bpf_perf_event_read() helper doc
bpf: fix formatting for bpf_get_stack() helper documentation
bpf: update bpf.h uapi header for tools
include/uapi/linux/bpf.h | 62 +++++++++++++++++++++---------------------
tools/include/uapi/linux/bpf.h | 62 +++++++++++++++++++++---------------------
2 files changed, 62 insertions(+), 62 deletions(-)
--
2.14.1
^ permalink raw reply
* Re: ipw2100: fix spelling mistake: "decsribed" -> "described"
From: Kalle Valo @ 2018-04-30 10:38 UTC (permalink / raw)
To: Colin Ian King
Cc: Stanislav Yakovlev, linux-wireless, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20180428223108.20458-1-colin.king@canonical.com>
Colin Ian King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to spelling mistake in comment and in the ord_data text
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Patch applied to wireless-drivers-next.git, thanks.
3ea0a58cf9cf ipw2100: fix spelling mistake: "decsribed" -> "described"
--
https://patchwork.kernel.org/patch/10370407/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: rt2x00: fix spelling mistake in various macros, UKNOWN -> UNKNOWN
From: Kalle Valo @ 2018-04-30 10:35 UTC (permalink / raw)
To: Colin Ian King
Cc: Stanislaw Gruszka, Helmut Schaa, linux-wireless, netdev,
kernel-janitors, linux-kernel
In-Reply-To: <20180418114750.1978-1-colin.king@canonical.com>
Colin Ian King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Rename several macros that contain mispellings of UNKNOWN
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Patch applied to wireless-drivers-next.git, thanks.
cc282a0c5f08 rt2x00: fix spelling mistake in various macros, UKNOWN -> UNKNOWN
--
https://patchwork.kernel.org/patch/10348023/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ 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