* [RESENT PATCH v2] ixgbe: Use memzero_explicit directly in crypto cases
From: zhong jiang @ 2019-09-17 14:44 UTC (permalink / raw)
To: jakub.kicinski, davem
Cc: anna.schumaker, trond.myklebust, netdev, linux-kernel, zhongjiang
It's better to use memzero_explicit() to replace memset() in crypto cases.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
index 31629fc..7e4f32f 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
@@ -960,10 +960,10 @@ int ixgbe_ipsec_vf_add_sa(struct ixgbe_adapter *adapter, u32 *msgbuf, u32 vf)
return 0;
err_aead:
- memset(xs->aead, 0, sizeof(*xs->aead));
+ memzero_explicit(xs->aead, sizeof(*xs->aead));
kfree(xs->aead);
err_xs:
- memset(xs, 0, sizeof(*xs));
+ memzero_explicit(xs, sizeof(*xs));
kfree(xs);
err_out:
msgbuf[1] = err;
@@ -1049,7 +1049,7 @@ int ixgbe_ipsec_vf_del_sa(struct ixgbe_adapter *adapter, u32 *msgbuf, u32 vf)
ixgbe_ipsec_del_sa(xs);
/* remove the xs that was made-up in the add request */
- memset(xs, 0, sizeof(*xs));
+ memzero_explicit(xs, sizeof(*xs));
kfree(xs);
return 0;
--
1.7.12.4
^ permalink raw reply related
* Re: [PATCH bpf-next 1/5] perf/core: Add PERF_FORMAT_LOST read_format
From: kbuild test robot @ 2019-09-17 14:32 UTC (permalink / raw)
To: Daniel Xu
Cc: kbuild-all, bpf, songliubraving, yhs, andriin, peterz, mingo,
acme, Daniel Xu, ast, alexander.shishkin, jolsa, namhyung,
linux-kernel, netdev, kernel-team
In-Reply-To: <20190917133056.5545-2-dxu@dxuuu.xyz>
[-- Attachment #1: Type: text/plain, Size: 1672 bytes --]
Hi Daniel,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on bpf-next/master]
url: https://github.com/0day-ci/linux/commits/Daniel-Xu/perf-core-Add-PERF_FORMAT_LOST-read_format/20190917-213515
base: https://kernel.googlesource.com/pub/scm/linux/kernel/git/bpf/bpf-next.git master
config: i386-tinyconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-11) 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 >>):
kernel/events/core.c: In function 'perf_event_lost':
>> kernel/events/core.c:4753:11: error: implicit declaration of function 'perf_kprobe_missed'; did you mean 'perf_release'? [-Werror=implicit-function-declaration]
lost += perf_kprobe_missed(event);
^~~~~~~~~~~~~~~~~~
perf_release
cc1: some warnings being treated as errors
vim +4753 kernel/events/core.c
4739
4740 static struct pmu perf_kprobe;
4741 static u64 perf_event_lost(struct perf_event *event)
4742 {
4743 struct ring_buffer *rb;
4744 u64 lost = 0;
4745
4746 rcu_read_lock();
4747 rb = rcu_dereference(event->rb);
4748 if (likely(!!rb))
4749 lost += local_read(&rb->lost);
4750 rcu_read_unlock();
4751
4752 if (event->attr.type == perf_kprobe.type)
> 4753 lost += perf_kprobe_missed(event);
4754
4755 return lost;
4756 }
4757
---
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: 7185 bytes --]
^ permalink raw reply
* Re: [PATCH] ath10k: fix spelling mistake "eanble" -> "enable"
From: Kalle Valo @ 2019-09-17 14:13 UTC (permalink / raw)
To: Colin King
Cc: David S . Miller, ath10k, linux-wireless, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20190913074339.27280-1-colin.king@canonical.com>
Colin King <colin.king@canonical.com> wrote:
> There is a spelling mistake in a ath10k_warn warning message. Fix it.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
09764659003d ath10k: fix spelling mistake "eanble" -> "enable"
--
https://patchwork.kernel.org/patch/11144035/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath10k: add cleanup in ath10k_sta_state()
From: Kalle Valo @ 2019-09-17 14:11 UTC (permalink / raw)
To: Wenwen Wang
Cc: Wenwen Wang, David S. Miller,
open list:QUALCOMM ATHEROS ATH10K WIRELESS DRIVER,
open list:NETWORKING DRIVERS (WIRELESS),
open list:NETWORKING DRIVERS, open list
In-Reply-To: <1565903072-3948-1-git-send-email-wenwen@cs.uga.edu>
Wenwen Wang <wenwen@cs.uga.edu> wrote:
> If 'sta->tdls' is false, no cleanup is executed, leading to memory/resource
> leaks, e.g., 'arsta->tx_stats'. To fix this issue, perform cleanup before
> go to the 'exit' label.
>
> Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
334f5b61a6f2 ath10k: add cleanup in ath10k_sta_state()
--
https://patchwork.kernel.org/patch/11096481/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] selftests/net: replace AF_MAX with INT_MAX in socket.c
From: shuah @ 2019-09-17 14:09 UTC (permalink / raw)
To: Marcelo Henrique Cerri
Cc: David S. Miller, netdev, linux-kselftest, linux-kernel, shuah
In-Reply-To: <20190917071222.6nfzmcxt4kxzgpki@gallifrey>
On 9/17/19 1:12 AM, Marcelo Henrique Cerri wrote:
> So the problem arises because the headers we have in userspace might
> be older and not match what we have in the kernel. In that case, the
> actual value of AF_MAX in the userspace headers might be a valid
> protocol family in the new kernel.
>
> That happens relatively often for us because we support different
> kernel versions at the same time in a given Ubuntu series.
>
Right. This is an evolving use-case for kselftest to make it easier to
run on distribution kernels.
> An alternative is to use the headers we have in the kernel tree, but I
> believe that might cause other issues.
>
Kselftest is tied to the kernel in such as way that you do need to use
the kernel headers to compile.
Do you run newer tests on older kernels? Where do you build them? What
I would like to see is fixing the test to run on older kernels and not
changing the tests to suit older kernel needs.
This definitely isn't a change that is good to make. We have to come
with a better way to solve this. Could you please send me the errors
you are seeing so I can help you find a better solution.
thanks,
-- Shuah
^ permalink raw reply
* Re: [PATCH] ath10k: Use ARRAY_SIZE
From: Kalle Valo @ 2019-09-17 14:09 UTC (permalink / raw)
To: Vasyl Gomonovych
Cc: davem, ath10k, linux-wireless, Vasyl Gomonovych, netdev,
linux-kernel
In-Reply-To: <20190718203032.15528-1-gomonovych@gmail.com>
Vasyl Gomonovych <gomonovych@gmail.com> wrote:
> fix coccinelle warning, use ARRAY_SIZE
>
> Signed-off-by: Vasyl Gomonovych <gomonovych@gmail.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
7921ae091907 ath10k: Use ARRAY_SIZE
--
https://patchwork.kernel.org/patch/11049553/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: divide error in cdc_ncm_update_rxtx_max
From: syzbot @ 2019-09-17 14:09 UTC (permalink / raw)
To: andreyknvl, bjorn, davem, linux-kernel, linux-usb, netdev, oliver,
syzkaller-bugs
In-Reply-To: <87h85bm3nh.fsf@miraculix.mork.no>
Hello,
syzbot has tested the proposed patch but the reproducer still triggered
crash:
divide error in usbnet_update_max_qlen
cdc_ncm 5-1:1.0: setting tx_max = 16384
divide error: 0000 [#1] SMP KASAN
CPU: 1 PID: 1737 Comm: kworker/1:2 Not tainted 5.3.0-rc7+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: usb_hub_wq hub_event
RIP: 0010:usbnet_update_max_qlen drivers/net/usb/usbnet.c:344 [inline]
RIP: 0010:usbnet_update_max_qlen+0x231/0x370 drivers/net/usb/usbnet.c:338
Code: 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 46 01
00 00 48 8d bb f4 00 00 00 31 d2 b8 c8 63 01 00 48 89 f9 <48> f7 b3 a8 01
00 00 48 ba 00 00 00 00 00 fc ff df 48 c1 e9 03 0f
RSP: 0018:ffff8881c05c7010 EFLAGS: 00010246
RAX: 00000000000163c8 RBX: ffff8881c7334ec0 RCX: ffff8881c7334fb4
RDX: 0000000000000000 RSI: ffffffff8344ecde RDI: ffff8881c7334fb4
RBP: 0000000000000003 R08: ffff8881d4a9b000 R09: ffffed1038e6688a
R10: ffffed1038e66889 R11: ffff8881c733444f R12: 0000000000004000
R13: ffff8881c7334ec0 R14: 0000000000000000 R15: ffff8881d62e77ac
FS: 0000000000000000(0000) GS:ffff8881db300000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f5a513e8000 CR3: 00000001d6436000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
cdc_ncm_update_rxtx_max+0xa61/0xf30 drivers/net/usb/cdc_ncm.c:437
cdc_ncm_setup drivers/net/usb/cdc_ncm.c:664 [inline]
cdc_ncm_bind_common+0x1005/0x2570 drivers/net/usb/cdc_ncm.c:921
cdc_ncm_bind+0x7c/0x1c0 drivers/net/usb/cdc_ncm.c:1035
usbnet_probe+0xb43/0x23cf drivers/net/usb/usbnet.c:1722
usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361
really_probe+0x281/0x6d0 drivers/base/dd.c:548
driver_probe_device+0x101/0x1b0 drivers/base/dd.c:721
__device_attach_driver+0x1c2/0x220 drivers/base/dd.c:828
bus_for_each_drv+0x162/0x1e0 drivers/base/bus.c:454
__device_attach+0x217/0x360 drivers/base/dd.c:894
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
device_add+0xae6/0x16f0 drivers/base/core.c:2165
usb_set_configuration+0xdf6/0x1670 drivers/usb/core/message.c:2023
generic_probe+0x9d/0xd5 drivers/usb/core/generic.c:210
usb_probe_device+0x99/0x100 drivers/usb/core/driver.c:266
really_probe+0x281/0x6d0 drivers/base/dd.c:548
driver_probe_device+0x101/0x1b0 drivers/base/dd.c:721
__device_attach_driver+0x1c2/0x220 drivers/base/dd.c:828
bus_for_each_drv+0x162/0x1e0 drivers/base/bus.c:454
__device_attach+0x217/0x360 drivers/base/dd.c:894
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
device_add+0xae6/0x16f0 drivers/base/core.c:2165
usb_new_device.cold+0x6a4/0xe79 drivers/usb/core/hub.c:2536
hub_port_connect drivers/usb/core/hub.c:5098 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5213 [inline]
port_event drivers/usb/core/hub.c:5359 [inline]
hub_event+0x1b5c/0x3640 drivers/usb/core/hub.c:5441
process_one_work+0x92b/0x1530 kernel/workqueue.c:2269
worker_thread+0x96/0xe20 kernel/workqueue.c:2415
kthread+0x318/0x420 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Modules linked in:
---[ end trace 472dbe98145a6d5e ]---
RIP: 0010:usbnet_update_max_qlen drivers/net/usb/usbnet.c:344 [inline]
RIP: 0010:usbnet_update_max_qlen+0x231/0x370 drivers/net/usb/usbnet.c:338
Code: 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 46 01
00 00 48 8d bb f4 00 00 00 31 d2 b8 c8 63 01 00 48 89 f9 <48> f7 b3 a8 01
00 00 48 ba 00 00 00 00 00 fc ff df 48 c1 e9 03 0f
RSP: 0018:ffff8881c05c7010 EFLAGS: 00010246
RAX: 00000000000163c8 RBX: ffff8881c7334ec0 RCX: ffff8881c7334fb4
RDX: 0000000000000000 RSI: ffffffff8344ecde RDI: ffff8881c7334fb4
RBP: 0000000000000003 R08: ffff8881d4a9b000 R09: ffffed1038e6688a
R10: ffffed1038e66889 R11: ffff8881c733444f R12: 0000000000004000
R13: ffff8881c7334ec0 R14: 0000000000000000 R15: ffff8881d62e77ac
FS: 0000000000000000(0000) GS:ffff8881db300000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f5a513e8000 CR3: 00000001d6436000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Tested on:
commit: f0df5c1b usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git
console output: https://syzkaller.appspot.com/x/log.txt?x=173ea979600000
kernel config: https://syzkaller.appspot.com/x/.config?x=5c6633fa4ed00be5
dashboard link: https://syzkaller.appspot.com/bug?extid=ce366e2b8296e25d84f5
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
patch: https://syzkaller.appspot.com/x/patch.diff?x=1538611d600000
^ permalink raw reply
* Re: [PATCH 1/3] ath10k: snoc: skip regulator operations
From: Kalle Valo @ 2019-09-17 14:04 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Govind Singh, David S. Miller, ath10k, linux-wireless, netdev,
linux-kernel, linux-arm-msm
In-Reply-To: <20190725174755.23432-2-bjorn.andersson@linaro.org>
Bjorn Andersson <bjorn.andersson@linaro.org> wrote:
> The regulator operations is trying to set a voltage to a fixed value, by
> giving some wiggle room. But some board designs specifies regulator
> voltages outside this limited range. One such example is the Lenovo Yoga
> C630, with vdd-3.3-ch0 in particular specified at 3.1V.
>
> But consumers with fixed voltage requirements should just rely on the
> board configuration to provide the power at the required level, so this
> code should be removed.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
3 patches applied to ath-next branch of ath.git, thanks.
b003e7f1974e ath10k: snoc: skip regulator operations
c56c7f24d7f8 ath10k: Use standard regulator bulk API in snoc
f93bcf0ce6a1 ath10k: Use standard bulk clock API in snoc
--
https://patchwork.kernel.org/patch/11059507/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath10k: Fix HOST capability QMI incompatibility
From: Kalle Valo @ 2019-09-17 14:03 UTC (permalink / raw)
To: Bjorn Andersson
Cc: David S. Miller, Rob Herring, Mark Rutland, linux-wireless,
netdev, devicetree, linux-kernel, ath10k, stable
In-Reply-To: <20190725063108.15790-1-bjorn.andersson@linaro.org>
Bjorn Andersson <bjorn.andersson@linaro.org> wrote:
> The introduction of 768ec4c012ac ("ath10k: update HOST capability QMI
> message") served the purpose of supporting the new and extended HOST
> capability QMI message.
>
> But while the new message adds a slew of optional members it changes the
> data type of the "daemon_support" member, which means that older
> versions of the firmware will fail to decode the incoming request
> message.
>
> There is no way to detect this breakage from Linux and there's no way to
> recover from sending the wrong message (i.e. we can't just try one
> format and then fallback to the other), so a quirk is introduced in
> DeviceTree to indicate to the driver that the firmware requires the 8bit
> version of this message.
>
> Cc: stable@vger.kernel.org
> Fixes: 768ec4c012ac ("ath10k: update HOST capability qmi message")
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
7165ef890a4c ath10k: Fix HOST capability QMI incompatibility
--
https://patchwork.kernel.org/patch/11058005/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: divide error in cdc_ncm_update_rxtx_max
From: Bjørn Mork @ 2019-09-17 13:52 UTC (permalink / raw)
To: syzbot
Cc: andreyknvl, davem, linux-kernel, linux-usb, netdev, oliver,
syzkaller-bugs
In-Reply-To: <000000000000c7b6940592ab9606@google.com>
[-- Attachment #1: Type: text/plain, Size: 57 bytes --]
#syz test: https://github.com/google/kasan.git f0df5c1b
[-- Attachment #2: 0001-cdc_ncm-fix-divide-error-when-USB-packet-size-is-0.patch --]
[-- Type: text/x-diff, Size: 4937 bytes --]
From dd2eb64899d5e695e5e05c674ecbbc3fce01b4b5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= <bjorn@mork.no>
Date: Tue, 17 Sep 2019 15:46:03 +0200
Subject: [RFC] cdc_ncm: fix divide error when USB packet size is 0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
syzbot reported:
cdc_ncm 1-1:1.0: dwNtbInMaxSize=0 is too small. Using 2048
cdc_ncm 1-1:1.0: setting rx_max = 2048
cdc_ncm 1-1:1.0: setting tx_max = 16384
divide error: 0000 [#1] SMP KASAN
CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.3.0-rc7+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine,
BIOS Google 01/01/2011
Workqueue: usb_hub_wq hub_event
RIP: 0010:cdc_ncm_update_rxtx_max+0xc6e/0xef0 drivers/net/usb/cdc_ncm.c:419
Code: e0 07 38 c2 0f 9e c1 84 d2 0f 95 c0 84 c1 0f 85 35 02 00 00 0f
b7 5b 04 81 e3 ff 07 00 00 e8 29 47 f7 fd 31 d2 44 89 e0 31 ff <f7> f3
41 89 d5 89 d6 e8 86 48 f7 fd 45 85 ed 0f 85 17 f7 ff ff e8
RSP: 0018:ffff8881da20f030 EFLAGS: 00010246
RAX: 0000000000004000 RBX: 0000000000000000 RCX: 0000000000000001
RDX: 0000000000000000 RSI: ffffffff83469377 RDI: 0000000000000000
RBP: ffff8881c7ba0000 R08: ffff8881da1f9800 R09: ffffed103b645d58
R10: ffffed103b645d57 R11: ffff8881db22eabf R12: 0000000000004000
R13: 0000000000000000 R14: ffff8881d35f3dc0 R15: ffff8881d2a70f00
FS: 0000000000000000(0000) GS:ffff8881db200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f1059879000 CR3: 00000001d49db000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
cdc_ncm_setup drivers/net/usb/cdc_ncm.c:667 [inline]
cdc_ncm_bind_common+0x1005/0x2570 drivers/net/usb/cdc_ncm.c:924
cdc_ncm_bind+0x7c/0x1c0 drivers/net/usb/cdc_ncm.c:1038
usbnet_probe+0xb43/0x23cf drivers/net/usb/usbnet.c:1722
usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361
really_probe+0x281/0x6d0 drivers/base/dd.c:548
driver_probe_device+0x101/0x1b0 drivers/base/dd.c:721
__device_attach_driver+0x1c2/0x220 drivers/base/dd.c:828
bus_for_each_drv+0x162/0x1e0 drivers/base/bus.c:454
__device_attach+0x217/0x360 drivers/base/dd.c:894
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
device_add+0xae6/0x16f0 drivers/base/core.c:2165
usb_set_configuration+0xdf6/0x1670 drivers/usb/core/message.c:2023
generic_probe+0x9d/0xd5 drivers/usb/core/generic.c:210
usb_probe_device+0x99/0x100 drivers/usb/core/driver.c:266
really_probe+0x281/0x6d0 drivers/base/dd.c:548
driver_probe_device+0x101/0x1b0 drivers/base/dd.c:721
__device_attach_driver+0x1c2/0x220 drivers/base/dd.c:828
bus_for_each_drv+0x162/0x1e0 drivers/base/bus.c:454
__device_attach+0x217/0x360 drivers/base/dd.c:894
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
device_add+0xae6/0x16f0 drivers/base/core.c:2165
usb_new_device.cold+0x6a4/0xe79 drivers/usb/core/hub.c:2536
hub_port_connect drivers/usb/core/hub.c:5098 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5213 [inline]
port_event drivers/usb/core/hub.c:5359 [inline]
hub_event+0x1b5c/0x3640 drivers/usb/core/hub.c:5441
process_one_work+0x92b/0x1530 kernel/workqueue.c:2269
worker_thread+0x96/0xe20 kernel/workqueue.c:2415
kthread+0x318/0x420 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Modules linked in:
---[ end trace ab75cc10e099d8e9 ]---
Reported-by: syzbot+ce366e2b8296e25d84f5@syzkaller.appspotmail.com
Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
drivers/net/usb/cdc_ncm.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 50c05d0f44cb..029fe9082a8f 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -377,6 +377,7 @@ static void cdc_ncm_update_rxtx_max(struct usbnet *dev, u32 new_rx, u32 new_tx)
{
struct cdc_ncm_ctx *ctx = (struct cdc_ncm_ctx *)dev->data[0];
u8 iface_no = ctx->control->cur_altsetting->desc.bInterfaceNumber;
+ u16 maxp = usb_maxpacket(dev->udev, dev->out, 1);
u32 val;
val = cdc_ncm_check_rx_max(dev, new_rx);
@@ -411,12 +412,8 @@ static void cdc_ncm_update_rxtx_max(struct usbnet *dev, u32 new_rx, u32 new_tx)
/* Adding a pad byte here if necessary simplifies the handling
* in cdc_ncm_fill_tx_frame, making tx_max always represent
* the real skb max size.
- *
- * We cannot use dev->maxpacket here because this is called from
- * .bind which is called before usbnet sets up dev->maxpacket
*/
- if (val != le32_to_cpu(ctx->ncm_parm.dwNtbOutMaxSize) &&
- val % usb_maxpacket(dev->udev, dev->out, 1) == 0)
+ if (maxp && val != le32_to_cpu(ctx->ncm_parm.dwNtbOutMaxSize) && val % maxp == 0)
val++;
/* we might need to flush any pending tx buffers if running */
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] dt-bindings: net: dwmac: fix 'mac-mode' type
From: Rob Herring @ 2019-09-17 13:53 UTC (permalink / raw)
To: Alexandru Ardelean
Cc: netdev, devicetree, linux-kernel@vger.kernel.org, David Miller,
Giuseppe CAVALLARO, Alexandre Torgue, Andrew Lunn,
Florian Fainelli
In-Reply-To: <20190917103052.13456-1-alexandru.ardelean@analog.com>
On Tue, Sep 17, 2019 at 2:31 AM Alexandru Ardelean
<alexandru.ardelean@analog.com> wrote:
>
> The 'mac-mode' property is similar to 'phy-mode' and 'phy-connection-type',
> which are enums of mode strings.
>
> The 'dwmac' driver supports almost all modes declared in the 'phy-mode'
> enum (except for 1 or 2). But in general, there may be a case where
> 'mac-mode' becomes more generic and is moved as part of phylib or netdev.
>
> In any case, the 'mac-mode' field should be made an enum, and it also makes
> sense to just reference the 'phy-connection-type' from
> 'ethernet-controller.yaml'. That will also make it more future-proof for new
> modes.
>
> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> ---
> Documentation/devicetree/bindings/net/snps,dwmac.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] ixgbe: Use memset_explicit directly in crypto cases
From: zhong jiang @ 2019-09-17 13:41 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: jakub.kicinski, davem, anna.schumaker, trond.myklebust, netdev,
linux-kernel
In-Reply-To: <98a942fb-0c47-ffa6-4c9c-f30b5d6f750e@cogentembedded.com>
On 2019/9/17 17:59, Sergei Shtylyov wrote:
> Hello!
>
> On 17.09.2019 6:45, zhong jiang wrote:
>
>> It's better to use memset_explicit() to replace memset() in crypto cases.
>
> But you're using memzero_explicit() below?
Sorry, stupid Oops. I will repost. Thank for your reminder.
Sincerely,
zhong jiang
>
>> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
>> ---
>> drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
>> index 31629fc..7e4f32f 100644
>> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
>> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
>> @@ -960,10 +960,10 @@ int ixgbe_ipsec_vf_add_sa(struct ixgbe_adapter *adapter, u32 *msgbuf, u32 vf)
>> return 0;
>> err_aead:
>> - memset(xs->aead, 0, sizeof(*xs->aead));
>> + memzero_explicit(xs->aead, sizeof(*xs->aead));
>> kfree(xs->aead);
>> err_xs:
>> - memset(xs, 0, sizeof(*xs));
>> + memzero_explicit(xs, sizeof(*xs));
>> kfree(xs);
>> err_out:
>> msgbuf[1] = err;
>> @@ -1049,7 +1049,7 @@ int ixgbe_ipsec_vf_del_sa(struct ixgbe_adapter *adapter, u32 *msgbuf, u32 vf)
>> ixgbe_ipsec_del_sa(xs);
>> /* remove the xs that was made-up in the add request */
>> - memset(xs, 0, sizeof(*xs));
>> + memzero_explicit(xs, sizeof(*xs));
>> kfree(xs);
>> return 0;
>
> MBR, Sergei
>
> .
>
^ permalink raw reply
* Re: [PATCH] ath10k: Use ARRAY_SIZE instead of dividing sizeof array with sizeof an element
From: zhong jiang @ 2019-09-17 13:37 UTC (permalink / raw)
To: Kalle Valo; +Cc: davem, ath10k, linux-wireless, netdev, linux-kernel
In-Reply-To: <20190917071632.001AC6155E@smtp.codeaurora.org>
On 2019/9/17 15:16, Kalle Valo wrote:
> zhong jiang <zhongjiang@huawei.com> wrote:
>
>> With the help of Coccinelle, ARRAY_SIZE can be replaced in ath10k_snoc_wlan_enable.
>>
>> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
> I already got an identical patch so dropping this one.
>
> error: patch failed: drivers/net/wireless/ath/ath10k/snoc.c:976
> error: drivers/net/wireless/ath/ath10k/snoc.c: patch does not apply
> stg import: Diff does not apply cleanly
>
Thank for your remainder.
Sincerely,
zhong jiang
^ permalink raw reply
* [PATCH bpf-next 0/5] Add PERF_FORMAT_LOST read_format
From: Daniel Xu @ 2019-09-17 13:30 UTC (permalink / raw)
To: bpf, songliubraving, yhs, andriin, peterz, mingo, acme
Cc: Daniel Xu, ast, alexander.shishkin, jolsa, namhyung, linux-kernel,
netdev, kernel-team
It's useful to know kprobe's nmissed count. For example with tracing
tools, it's important to know when events may have been lost. debugfs
currently exposes a control file to get this information, but it is not
compatible with probes registered with the perf API.
While bpf programs may be able to manually count nhit, there is no way
to gather nmissed. In other words, it is currently not possible to this
retrieve information about FD-based probes.
This patch adds a new field to perf's read_format that lets users query
misses. Misses include both misses from the underlying kprobe
infrastructure and misses from ringbuffer infrastructure.
I studied the code various code paths for perf software events and perf
tracepoints and it does not look like anything can "miss" in the same
way kprobes can. They can all, however, suffer from ringbuffer misses.
It's possible I missed something while reading the code so please let
me know if I am mistaken.
Daniel Xu (5):
perf/core: Add PERF_FORMAT_LOST read_format
perf/core: Sync perf_event.h to tools
libbpf: Add helpers to extract perf fd from bpf_link
libbpf: Set read_format PERF_FORMAT_LOST on kprobe perf fds
libbpf: Add selftest for PERF_FORMAT_LOST perf read_format
include/linux/trace_events.h | 1 +
include/uapi/linux/perf_event.h | 5 ++-
kernel/events/core.c | 39 +++++++++++++++++--
kernel/trace/trace_kprobe.c | 8 ++++
tools/include/uapi/linux/perf_event.h | 5 ++-
tools/lib/bpf/libbpf.c | 30 ++++++++++++--
tools/lib/bpf/libbpf.h | 13 +++++++
tools/lib/bpf/libbpf.map | 3 ++
.../selftests/bpf/prog_tests/attach_probe.c | 32 ++++++++++++++-
9 files changed, 127 insertions(+), 9 deletions(-)
--
2.21.0
^ permalink raw reply
* [PATCH bpf-next 2/5] perf/core: Sync perf_event.h to tools
From: Daniel Xu @ 2019-09-17 13:30 UTC (permalink / raw)
To: bpf, songliubraving, yhs, andriin, peterz, mingo, acme
Cc: Daniel Xu, ast, alexander.shishkin, jolsa, namhyung, linux-kernel,
netdev, kernel-team
In-Reply-To: <20190917133056.5545-1-dxu@dxuuu.xyz>
Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
---
tools/include/uapi/linux/perf_event.h | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tools/include/uapi/linux/perf_event.h b/tools/include/uapi/linux/perf_event.h
index 7198ddd0c6b1..bd874c7257f0 100644
--- a/tools/include/uapi/linux/perf_event.h
+++ b/tools/include/uapi/linux/perf_event.h
@@ -273,6 +273,7 @@ enum {
* { u64 time_enabled; } && PERF_FORMAT_TOTAL_TIME_ENABLED
* { u64 time_running; } && PERF_FORMAT_TOTAL_TIME_RUNNING
* { u64 id; } && PERF_FORMAT_ID
+ * { u64 missed; } && PERF_FORMAT_LOST
* } && !PERF_FORMAT_GROUP
*
* { u64 nr;
@@ -280,6 +281,7 @@ enum {
* { u64 time_running; } && PERF_FORMAT_TOTAL_TIME_RUNNING
* { u64 value;
* { u64 id; } && PERF_FORMAT_ID
+ * { u64 missed; } && PERF_FORMAT_LOST
* } cntr[nr];
* } && PERF_FORMAT_GROUP
* };
@@ -289,8 +291,9 @@ enum perf_event_read_format {
PERF_FORMAT_TOTAL_TIME_RUNNING = 1U << 1,
PERF_FORMAT_ID = 1U << 2,
PERF_FORMAT_GROUP = 1U << 3,
+ PERF_FORMAT_LOST = 1U << 4,
- PERF_FORMAT_MAX = 1U << 4, /* non-ABI */
+ PERF_FORMAT_MAX = 1U << 5, /* non-ABI */
};
#define PERF_ATTR_SIZE_VER0 64 /* sizeof first published struct */
--
2.21.0
^ permalink raw reply related
* [PATCH bpf-next 4/5] libbpf: Set read_format PERF_FORMAT_LOST on kprobe perf fds
From: Daniel Xu @ 2019-09-17 13:30 UTC (permalink / raw)
To: bpf, songliubraving, yhs, andriin, peterz, mingo, acme
Cc: Daniel Xu, ast, alexander.shishkin, jolsa, namhyung, linux-kernel,
netdev, kernel-team
In-Reply-To: <20190917133056.5545-1-dxu@dxuuu.xyz>
There is no way to get the nmissed count from kprobes that are created
using the perf API. The previous commits added read_format support for
this count. Enable it in this commit.
Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
---
tools/lib/bpf/libbpf.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 1ca0acd1d823..43f45f6d914d 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -5031,7 +5031,7 @@ static int determine_uprobe_retprobe_bit(void)
}
static int perf_event_open_probe(bool uprobe, bool retprobe, const char *name,
- uint64_t offset, int pid)
+ uint64_t offset, int pid, uint64_t read_format)
{
struct perf_event_attr attr = {};
char errmsg[STRERR_BUFSIZE];
@@ -5060,6 +5060,7 @@ static int perf_event_open_probe(bool uprobe, bool retprobe, const char *name,
}
attr.size = sizeof(attr);
attr.type = type;
+ attr.read_format = read_format;
attr.config1 = ptr_to_u64(name); /* kprobe_func or uprobe_path */
attr.config2 = offset; /* kprobe_addr or probe_offset */
@@ -5087,7 +5088,8 @@ struct bpf_link *bpf_program__attach_kprobe(struct bpf_program *prog,
int pfd, err;
pfd = perf_event_open_probe(false /* uprobe */, retprobe, func_name,
- 0 /* offset */, -1 /* pid */);
+ 0 /* offset */, -1 /* pid */,
+ PERF_FORMAT_LOST /* read_format */);
if (pfd < 0) {
pr_warning("program '%s': failed to create %s '%s' perf event: %s\n",
bpf_program__title(prog, false),
@@ -5118,7 +5120,8 @@ struct bpf_link *bpf_program__attach_uprobe(struct bpf_program *prog,
int pfd, err;
pfd = perf_event_open_probe(true /* uprobe */, retprobe,
- binary_path, func_offset, pid);
+ binary_path, func_offset, pid,
+ 0 /* read_format */);
if (pfd < 0) {
pr_warning("program '%s': failed to create %s '%s:0x%zx' perf event: %s\n",
bpf_program__title(prog, false),
--
2.21.0
^ permalink raw reply related
* [PATCH bpf-next 5/5] libbpf: Add selftest for PERF_FORMAT_LOST perf read_format
From: Daniel Xu @ 2019-09-17 13:30 UTC (permalink / raw)
To: bpf, songliubraving, yhs, andriin, peterz, mingo, acme
Cc: Daniel Xu, ast, alexander.shishkin, jolsa, namhyung, linux-kernel,
netdev, kernel-team
In-Reply-To: <20190917133056.5545-1-dxu@dxuuu.xyz>
Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
---
.../selftests/bpf/prog_tests/attach_probe.c | 32 ++++++++++++++++++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/bpf/prog_tests/attach_probe.c b/tools/testing/selftests/bpf/prog_tests/attach_probe.c
index 5ecc267d98b0..3d636cccb6dc 100644
--- a/tools/testing/selftests/bpf/prog_tests/attach_probe.c
+++ b/tools/testing/selftests/bpf/prog_tests/attach_probe.c
@@ -1,6 +1,11 @@
// SPDX-License-Identifier: GPL-2.0
#include <test_progs.h>
+struct perf_read_output {
+ u64 count;
+ u64 lost;
+};
+
ssize_t get_base_addr() {
size_t start;
char buf[256];
@@ -32,6 +37,8 @@ void test_attach_probe(void)
const char *file = "./test_attach_probe.o";
struct bpf_program *kprobe_prog, *kretprobe_prog;
struct bpf_program *uprobe_prog, *uretprobe_prog;
+ struct perf_read_output kprobe_read_output;
+ const struct bpf_link_fd *kprobe_fd_link;
struct bpf_object *obj;
int err, prog_fd, duration = 0, res;
struct bpf_link *kprobe_link = NULL;
@@ -40,7 +47,8 @@ void test_attach_probe(void)
struct bpf_link *uretprobe_link = NULL;
int results_map_fd;
size_t uprobe_offset;
- ssize_t base_addr;
+ ssize_t base_addr, nread;
+ int kprobe_fd;
base_addr = get_base_addr();
if (CHECK(base_addr < 0, "get_base_addr",
@@ -116,6 +124,28 @@ void test_attach_probe(void)
/* trigger & validate kprobe && kretprobe */
usleep(1);
+ kprobe_fd_link = bpf_link__as_fd(kprobe_link);
+ if (CHECK(!kprobe_fd_link, "kprobe_link_as_fd",
+ "failed to cast link to fd link\n"))
+ goto cleanup;
+
+ kprobe_fd = bpf_link_fd__fd(kprobe_fd_link);
+ if (CHECK(kprobe_fd < 0, "kprobe_get_perf_fd",
+ "failed to get perf fd from kprobe link\n"))
+ goto cleanup;
+
+ /* Set to unexpected value so we can check the read(2) did stuff */
+ kprobe_read_output.lost = 1;
+ nread = read(kprobe_fd, &kprobe_read_output,
+ sizeof(kprobe_read_output));
+ if (CHECK(nread != sizeof(kprobe_read_output), "kprobe_perf_read",
+ "failed to read from perf fd\n"))
+ goto cleanup;
+ if (CHECK(kprobe_read_output.lost != 0, "kprobe_lost",
+ "read wrong value from perf fd: %lu\n",
+ kprobe_read_output.lost))
+ goto cleanup;
+
err = bpf_map_lookup_elem(results_map_fd, &kprobe_idx, &res);
if (CHECK(err, "get_kprobe_res",
"failed to get kprobe res: %d\n", err))
--
2.21.0
^ permalink raw reply related
* [PATCH bpf-next 3/5] libbpf: Add helpers to extract perf fd from bpf_link
From: Daniel Xu @ 2019-09-17 13:30 UTC (permalink / raw)
To: bpf, songliubraving, yhs, andriin, peterz, mingo, acme
Cc: Daniel Xu, ast, alexander.shishkin, jolsa, namhyung, linux-kernel,
netdev, kernel-team
In-Reply-To: <20190917133056.5545-1-dxu@dxuuu.xyz>
It is sometimes necessary to perform operations on the underlying perf fd.
There is not currently a way to extract the fd given a bpf_link, so add a
a pair of casting and getting helpers.
The casting and getting helpers are nice because they let us define
broad categories of links that makes it clear to users what they can
expect to extract from what type of link.
Acked-by: Song Liu <songliubraving@fb.com>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
---
tools/lib/bpf/libbpf.c | 21 +++++++++++++++++++++
tools/lib/bpf/libbpf.h | 13 +++++++++++++
tools/lib/bpf/libbpf.map | 3 +++
3 files changed, 37 insertions(+)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index e0276520171b..1ca0acd1d823 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -4875,6 +4875,7 @@ int bpf_prog_load_xattr(const struct bpf_prog_load_attr *attr,
struct bpf_link {
int (*destroy)(struct bpf_link *link);
+ enum bpf_link_type type;
};
int bpf_link__destroy(struct bpf_link *link)
@@ -4908,6 +4909,24 @@ static int bpf_link__destroy_perf_event(struct bpf_link *link)
return err;
}
+const struct bpf_link_fd *bpf_link__as_fd(const struct bpf_link *link)
+{
+ if (link->type != LIBBPF_LINK_FD)
+ return NULL;
+
+ return (struct bpf_link_fd *)link;
+}
+
+enum bpf_link_type bpf_link__type(const struct bpf_link *link)
+{
+ return link->type;
+}
+
+int bpf_link_fd__fd(const struct bpf_link_fd *link)
+{
+ return link->fd;
+}
+
struct bpf_link *bpf_program__attach_perf_event(struct bpf_program *prog,
int pfd)
{
@@ -4931,6 +4950,7 @@ struct bpf_link *bpf_program__attach_perf_event(struct bpf_program *prog,
if (!link)
return ERR_PTR(-ENOMEM);
link->link.destroy = &bpf_link__destroy_perf_event;
+ link->link.type = LIBBPF_LINK_FD;
link->fd = pfd;
if (ioctl(pfd, PERF_EVENT_IOC_SET_BPF, prog_fd) < 0) {
@@ -5224,6 +5244,7 @@ struct bpf_link *bpf_program__attach_raw_tracepoint(struct bpf_program *prog,
link = malloc(sizeof(*link));
if (!link)
return ERR_PTR(-ENOMEM);
+ link->link.type = LIBBPF_LINK_FD;
link->link.destroy = &bpf_link__destroy_fd;
pfd = bpf_raw_tracepoint_open(tp_name, prog_fd);
diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
index e8f70977d137..2ddef5315ff9 100644
--- a/tools/lib/bpf/libbpf.h
+++ b/tools/lib/bpf/libbpf.h
@@ -166,7 +166,20 @@ LIBBPF_API int bpf_program__pin(struct bpf_program *prog, const char *path);
LIBBPF_API int bpf_program__unpin(struct bpf_program *prog, const char *path);
LIBBPF_API void bpf_program__unload(struct bpf_program *prog);
+enum bpf_link_type {
+ LIBBPF_LINK_FD,
+};
+
struct bpf_link;
+struct bpf_link_fd;
+
+/* casting APIs */
+LIBBPF_API const struct bpf_link_fd *
+bpf_link__as_fd(const struct bpf_link *link);
+
+/* getters APIs */
+LIBBPF_API enum bpf_link_type bpf_link__type(const struct bpf_link *link);
+LIBBPF_API int bpf_link_fd__fd(const struct bpf_link_fd *link);
LIBBPF_API int bpf_link__destroy(struct bpf_link *link);
diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
index d04c7cb623ed..216713b9eef6 100644
--- a/tools/lib/bpf/libbpf.map
+++ b/tools/lib/bpf/libbpf.map
@@ -189,4 +189,7 @@ LIBBPF_0.0.4 {
LIBBPF_0.0.5 {
global:
bpf_btf_get_next_id;
+ bpf_link__type;
+ bpf_link__as_fd;
+ bpf_link_fd__fd;
} LIBBPF_0.0.4;
--
2.21.0
^ permalink raw reply related
* [PATCH bpf-next 1/5] perf/core: Add PERF_FORMAT_LOST read_format
From: Daniel Xu @ 2019-09-17 13:30 UTC (permalink / raw)
To: bpf, songliubraving, yhs, andriin, peterz, mingo, acme
Cc: Daniel Xu, ast, alexander.shishkin, jolsa, namhyung, linux-kernel,
netdev, kernel-team
In-Reply-To: <20190917133056.5545-1-dxu@dxuuu.xyz>
It's useful to know kprobe's nmissed count. For example with tracing
tools, it's important to know when events may have been lost. debugfs
currently exposes a control file to get this information, but it is not
compatible with probes registered with the perf API.
While bpf programs may be able to manually count nhit, there is no way
to gather nmissed. In other words, it is currently not possible to this
retrieve information about FD-based probes.
This patch adds a new field to perf's read_format that lets users query
misses. Misses include both misses from the underlying kprobe
infrastructure and misses from ringbuffer infrastructure.
Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
---
include/linux/trace_events.h | 1 +
include/uapi/linux/perf_event.h | 5 ++++-
kernel/events/core.c | 39 ++++++++++++++++++++++++++++++---
kernel/trace/trace_kprobe.c | 8 +++++++
4 files changed, 49 insertions(+), 4 deletions(-)
diff --git a/include/linux/trace_events.h b/include/linux/trace_events.h
index 30a8cdcfd4a4..952520c1240a 100644
--- a/include/linux/trace_events.h
+++ b/include/linux/trace_events.h
@@ -587,6 +587,7 @@ extern int bpf_get_kprobe_info(const struct perf_event *event,
u32 *fd_type, const char **symbol,
u64 *probe_offset, u64 *probe_addr,
bool perf_type_tracepoint);
+extern u64 perf_kprobe_missed(const struct perf_event *event);
#endif
#ifdef CONFIG_UPROBE_EVENTS
extern int perf_uprobe_init(struct perf_event *event,
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index 7198ddd0c6b1..bd874c7257f0 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -273,6 +273,7 @@ enum {
* { u64 time_enabled; } && PERF_FORMAT_TOTAL_TIME_ENABLED
* { u64 time_running; } && PERF_FORMAT_TOTAL_TIME_RUNNING
* { u64 id; } && PERF_FORMAT_ID
+ * { u64 missed; } && PERF_FORMAT_LOST
* } && !PERF_FORMAT_GROUP
*
* { u64 nr;
@@ -280,6 +281,7 @@ enum {
* { u64 time_running; } && PERF_FORMAT_TOTAL_TIME_RUNNING
* { u64 value;
* { u64 id; } && PERF_FORMAT_ID
+ * { u64 missed; } && PERF_FORMAT_LOST
* } cntr[nr];
* } && PERF_FORMAT_GROUP
* };
@@ -289,8 +291,9 @@ enum perf_event_read_format {
PERF_FORMAT_TOTAL_TIME_RUNNING = 1U << 1,
PERF_FORMAT_ID = 1U << 2,
PERF_FORMAT_GROUP = 1U << 3,
+ PERF_FORMAT_LOST = 1U << 4,
- PERF_FORMAT_MAX = 1U << 4, /* non-ABI */
+ PERF_FORMAT_MAX = 1U << 5, /* non-ABI */
};
#define PERF_ATTR_SIZE_VER0 64 /* sizeof first published struct */
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 0463c1151bae..ee08d3ed6299 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -1715,6 +1715,9 @@ static void __perf_event_read_size(struct perf_event *event, int nr_siblings)
if (event->attr.read_format & PERF_FORMAT_ID)
entry += sizeof(u64);
+ if (event->attr.read_format & PERF_FORMAT_LOST)
+ entry += sizeof(u64);
+
if (event->attr.read_format & PERF_FORMAT_GROUP) {
nr += nr_siblings;
size += sizeof(u64);
@@ -4734,6 +4737,24 @@ u64 perf_event_read_value(struct perf_event *event, u64 *enabled, u64 *running)
}
EXPORT_SYMBOL_GPL(perf_event_read_value);
+static struct pmu perf_kprobe;
+static u64 perf_event_lost(struct perf_event *event)
+{
+ struct ring_buffer *rb;
+ u64 lost = 0;
+
+ rcu_read_lock();
+ rb = rcu_dereference(event->rb);
+ if (likely(!!rb))
+ lost += local_read(&rb->lost);
+ rcu_read_unlock();
+
+ if (event->attr.type == perf_kprobe.type)
+ lost += perf_kprobe_missed(event);
+
+ return lost;
+}
+
static int __perf_read_group_add(struct perf_event *leader,
u64 read_format, u64 *values)
{
@@ -4770,11 +4791,15 @@ static int __perf_read_group_add(struct perf_event *leader,
values[n++] += perf_event_count(leader);
if (read_format & PERF_FORMAT_ID)
values[n++] = primary_event_id(leader);
+ if (read_format & PERF_FORMAT_LOST)
+ values[n++] = perf_event_lost(leader);
for_each_sibling_event(sub, leader) {
values[n++] += perf_event_count(sub);
if (read_format & PERF_FORMAT_ID)
values[n++] = primary_event_id(sub);
+ if (read_format & PERF_FORMAT_LOST)
+ values[n++] = perf_event_lost(sub);
}
raw_spin_unlock_irqrestore(&ctx->lock, flags);
@@ -4831,7 +4856,7 @@ static int perf_read_one(struct perf_event *event,
u64 read_format, char __user *buf)
{
u64 enabled, running;
- u64 values[4];
+ u64 values[5];
int n = 0;
values[n++] = __perf_event_read_value(event, &enabled, &running);
@@ -4841,6 +4866,8 @@ static int perf_read_one(struct perf_event *event,
values[n++] = running;
if (read_format & PERF_FORMAT_ID)
values[n++] = primary_event_id(event);
+ if (read_format & PERF_FORMAT_LOST)
+ values[n++] = perf_event_lost(event);
if (copy_to_user(buf, values, n * sizeof(u64)))
return -EFAULT;
@@ -6141,7 +6168,7 @@ static void perf_output_read_one(struct perf_output_handle *handle,
u64 enabled, u64 running)
{
u64 read_format = event->attr.read_format;
- u64 values[4];
+ u64 values[5];
int n = 0;
values[n++] = perf_event_count(event);
@@ -6155,6 +6182,8 @@ static void perf_output_read_one(struct perf_output_handle *handle,
}
if (read_format & PERF_FORMAT_ID)
values[n++] = primary_event_id(event);
+ if (read_format & PERF_FORMAT_LOST)
+ values[n++] = perf_event_lost(event);
__output_copy(handle, values, n * sizeof(u64));
}
@@ -6165,7 +6194,7 @@ static void perf_output_read_group(struct perf_output_handle *handle,
{
struct perf_event *leader = event->group_leader, *sub;
u64 read_format = event->attr.read_format;
- u64 values[5];
+ u64 values[6];
int n = 0;
values[n++] = 1 + leader->nr_siblings;
@@ -6183,6 +6212,8 @@ static void perf_output_read_group(struct perf_output_handle *handle,
values[n++] = perf_event_count(leader);
if (read_format & PERF_FORMAT_ID)
values[n++] = primary_event_id(leader);
+ if (read_format & PERF_FORMAT_LOST)
+ values[n++] = perf_event_lost(leader);
__output_copy(handle, values, n * sizeof(u64));
@@ -6196,6 +6227,8 @@ static void perf_output_read_group(struct perf_output_handle *handle,
values[n++] = perf_event_count(sub);
if (read_format & PERF_FORMAT_ID)
values[n++] = primary_event_id(sub);
+ if (read_format & PERF_FORMAT_LOST)
+ values[n++] = perf_event_lost(sub);
__output_copy(handle, values, n * sizeof(u64));
}
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 9d483ad9bb6c..cff471c8750b 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -196,6 +196,14 @@ bool trace_kprobe_error_injectable(struct trace_event_call *call)
return within_error_injection_list(trace_kprobe_address(tk));
}
+u64 perf_kprobe_missed(const struct perf_event *event)
+{
+ struct trace_event_call *call = event->tp_event;
+ struct trace_kprobe *tk = (struct trace_kprobe *)call->data;
+
+ return tk->rp.kp.nmissed;
+}
+
static int register_kprobe_event(struct trace_kprobe *tk);
static int unregister_kprobe_event(struct trace_kprobe *tk);
--
2.21.0
^ permalink raw reply related
* RE: -Wsizeof-array-div warnings in ethernet drivers
From: Jose Abreu @ 2019-09-17 13:26 UTC (permalink / raw)
To: David Laight, 'Jose Abreu', Nathan Chancellor,
Tom Lendacky, Giuseppe Cavallaro, Alexandre Torgue,
David S. Miller
Cc: Nick Desaulniers, Ilie Halip, David Bolvansky,
netdev@vger.kernel.org, clang-built-linux@googlegroups.com
In-Reply-To: <510d777024554eab846ef93d05998b63@AcuMS.aculab.com>
From: David Laight <David.Laight@ACULAB.COM>
Date: Sep/17/2019, 11:36:21 (UTC+00:00)
> From: Jose Abreu
> > Sent: 17 September 2019 08:59
> > From: Nathan Chancellor <natechancellor@gmail.com>
> > Date: Sep/17/2019, 08:32:32 (UTC+00:00)
> >
> > > Hi all,
> > >
> > > Clang recently added a new diagnostic in r371605, -Wsizeof-array-div,
> > > that tries to warn when sizeof(X) / sizeof(Y) does not compute the
> > > number of elements in an array X (i.e., sizeof(Y) is wrong). See that
> > > commit for more details:
> ...
> > > ../drivers/net/ethernet/amd/xgbe/xgbe-dev.c:361:49: warning: expression
> > > does not compute the number of elements in this array; element type is
> > > 'u8' (aka 'unsigned char'), not 'u32' (aka 'unsigned int')
> > > [-Wsizeof-array-div]
> > > unsigned int key_regs = sizeof(pdata->rss_key) / sizeof(u32);
> > > ~~~~~~~~~~~~~~ ^
> ...
> > > What is the reasoning behind having the key being an array of u8s but
> > > seemlingly converting it into an array of u32s? It's not immediately
> > > apparent from reading over the code but I am not familiar with it so I
> > > might be making a mistake. I assume this is intentional? If so, the
> > > warning can be silenced and we'll send patches to do so but we want to
> > > make sure we aren't actually papering over a mistake.
> >
> > This is because we write 32 bits at a time to the reg but internally the
> > driver uses 8 bits to store the array. If you look at
> > dwxgmac2_rss_configure() you'll see that cfg->key is casted to u32 which
> > is the value we use in HW writes. Then the for loop just does the math
> > to check how many u32's has to write.
>
> That stinks of a possible misaligned data access.....
It's possible to happen only if structure field is not aligned. I guess
I can either change all to u32 or just __align the field of the struct
...
---
Thanks,
Jose Miguel Abreu
^ permalink raw reply
* Re: [PATCH] dt-bindings: net: dwmac: fix 'mac-mode' type
From: Ardelean, Alexandru @ 2019-09-17 13:24 UTC (permalink / raw)
To: andrew@lunn.ch
Cc: davem@davemloft.net, alexandre.torgue@st.com,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
peppe.cavallaro@st.com, netdev@vger.kernel.org,
f.fainelli@gmail.com, robh+dt@kernel.org
In-Reply-To: <20190917124132.GG20778@lunn.ch>
On Tue, 2019-09-17 at 14:41 +0200, Andrew Lunn wrote:
> [External]
>
> On Tue, Sep 17, 2019 at 01:30:52PM +0300, Alexandru Ardelean wrote:
> > The 'mac-mode' property is similar to 'phy-mode' and 'phy-connection-type',
> > which are enums of mode strings.
> >
> > The 'dwmac' driver supports almost all modes declared in the 'phy-mode'
> > enum (except for 1 or 2). But in general, there may be a case where
> > 'mac-mode' becomes more generic and is moved as part of phylib or netdev.
> >
> > In any case, the 'mac-mode' field should be made an enum, and it also makes
> > sense to just reference the 'phy-connection-type' from
> > 'ethernet-controller.yaml'. That will also make it more future-proof for new
> > modes.
> >
> > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
>
> Hi Alexandru
>
> Adding a Fixes: tag would be good. Just reply in this thread, and
> patchwork will do magic to append it to the patch.
>
Oops. Good point.
Thanks for the tip.
Let's see if Rob agrees as well.
Fixes: 9c15d3597c62 ("dt-bindings: net: dwmac: document 'mac-mode' property")
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
>
> Andrew
^ permalink raw reply
* Re: [PATCH] dt-bindings: net: dwmac: fix 'mac-mode' type
From: Andrew Lunn @ 2019-09-17 12:41 UTC (permalink / raw)
To: Alexandru Ardelean
Cc: netdev, devicetree, linux-kernel, davem, robh+dt, peppe.cavallaro,
alexandre.torgue, f.fainelli
In-Reply-To: <20190917103052.13456-1-alexandru.ardelean@analog.com>
On Tue, Sep 17, 2019 at 01:30:52PM +0300, Alexandru Ardelean wrote:
> The 'mac-mode' property is similar to 'phy-mode' and 'phy-connection-type',
> which are enums of mode strings.
>
> The 'dwmac' driver supports almost all modes declared in the 'phy-mode'
> enum (except for 1 or 2). But in general, there may be a case where
> 'mac-mode' becomes more generic and is moved as part of phylib or netdev.
>
> In any case, the 'mac-mode' field should be made an enum, and it also makes
> sense to just reference the 'phy-connection-type' from
> 'ethernet-controller.yaml'. That will also make it more future-proof for new
> modes.
>
> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Hi Alexandru
Adding a Fixes: tag would be good. Just reply in this thread, and
patchwork will do magic to append it to the patch.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH ipsec-next v2 6/6] xfrm: add espintcp (RFC 8229)
From: Sabrina Dubroca @ 2019-09-17 12:40 UTC (permalink / raw)
To: Steffen Klassert; +Cc: netdev, Herbert Xu
In-Reply-To: <20190917120413.GF2879@gauss3.secunet.de>
2019-09-17, 14:04:13 +0200, Steffen Klassert wrote:
> On Tue, Sep 17, 2019 at 01:57:43PM +0200, Sabrina Dubroca wrote:
> > 2019-09-17, 13:26:49 +0200, Steffen Klassert wrote:
> > > On Wed, Sep 11, 2019 at 04:13:07PM +0200, Sabrina Dubroca wrote:
> > > ...
> > > > diff --git a/net/xfrm/Kconfig b/net/xfrm/Kconfig
> > > > index 51bb6018f3bf..e67044527fb7 100644
> > > > --- a/net/xfrm/Kconfig
> > > > +++ b/net/xfrm/Kconfig
> > > > @@ -73,6 +73,16 @@ config XFRM_IPCOMP
> > > > select CRYPTO
> > > > select CRYPTO_DEFLATE
> > > >
> > > > +config XFRM_ESPINTCP
> > > > + bool "ESP in TCP encapsulation (RFC 8229)"
> > > > + depends on XFRM && INET_ESP
> > > > + select STREAM_PARSER
> > > > + select NET_SOCK_MSG
> > > > + help
> > > > + Support for RFC 8229 encapsulation of ESP and IKE over TCP sockets.
> > > > +
> > > > + If unsure, say N.
> > > > +
> > >
> > > One nitpick: This is IPv4 only, so please move this below the ESP
> > > section in net/ipv4/Kconfig and use the naming convention there.
> > > I.e. bool "IP: ESP in TCP encapsulation (RFC 8229)"
> >
> > That's temporary, though, the next step will be to make it work for
> > both IPv4 and IPv6. Do you prefer I move it to net/ipv4/Kconfig for
> > now, and then back to net/xfrm/Kconfig when I add IPv6 support?
>
> We have separate config options for ESP4 and ESP6, so we should
> also have separate config options for 'ESP in TCP' for IPv4 and IPv6.
> So this should go to net/ipv4/Kconfig. When you add IPv6 support
> place it in net/ipv6/Kconfig.
Ok, I'll do that, and rename the config entry to CONFIG_INET_ESPINTCP.
Thanks.
--
Sabrina
^ permalink raw reply
* Re: [PATCH v3] net: mdio: switch to using gpiod_get_optional()
From: Andrew Lunn @ 2019-09-17 12:16 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Florian Fainelli, Heiner Kallweit, David S. Miller, Linus Walleij,
Andy Shevchenko, netdev, linux-kernel
In-Reply-To: <20190917000933.GA254663@dtor-ws>
On Mon, Sep 16, 2019 at 05:09:33PM -0700, Dmitry Torokhov wrote:
> The MDIO device reset line is optional and now that gpiod_get_optional()
> returns proper value when GPIO support is compiled out, there is no
> reason to use fwnode_get_named_gpiod() that I plan to hide away.
>
> Let's switch to using more standard gpiod_get_optional() and
> gpiod_set_consumer_name() to keep the nice "PHY reset" label.
>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Hi Dmitry
What path into mainline do you expect this to take? Via DaveM?
net-next is closed now, so i guess you will need to repost in two
weeks time.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH ipsec-next v2 6/6] xfrm: add espintcp (RFC 8229)
From: Steffen Klassert @ 2019-09-17 12:04 UTC (permalink / raw)
To: Sabrina Dubroca; +Cc: netdev, Herbert Xu
In-Reply-To: <20190917115743.GA89567@bistromath.localdomain>
On Tue, Sep 17, 2019 at 01:57:43PM +0200, Sabrina Dubroca wrote:
> 2019-09-17, 13:26:49 +0200, Steffen Klassert wrote:
> > On Wed, Sep 11, 2019 at 04:13:07PM +0200, Sabrina Dubroca wrote:
> > ...
> > > diff --git a/net/xfrm/Kconfig b/net/xfrm/Kconfig
> > > index 51bb6018f3bf..e67044527fb7 100644
> > > --- a/net/xfrm/Kconfig
> > > +++ b/net/xfrm/Kconfig
> > > @@ -73,6 +73,16 @@ config XFRM_IPCOMP
> > > select CRYPTO
> > > select CRYPTO_DEFLATE
> > >
> > > +config XFRM_ESPINTCP
> > > + bool "ESP in TCP encapsulation (RFC 8229)"
> > > + depends on XFRM && INET_ESP
> > > + select STREAM_PARSER
> > > + select NET_SOCK_MSG
> > > + help
> > > + Support for RFC 8229 encapsulation of ESP and IKE over TCP sockets.
> > > +
> > > + If unsure, say N.
> > > +
> >
> > One nitpick: This is IPv4 only, so please move this below the ESP
> > section in net/ipv4/Kconfig and use the naming convention there.
> > I.e. bool "IP: ESP in TCP encapsulation (RFC 8229)"
>
> That's temporary, though, the next step will be to make it work for
> both IPv4 and IPv6. Do you prefer I move it to net/ipv4/Kconfig for
> now, and then back to net/xfrm/Kconfig when I add IPv6 support?
We have separate config options for ESP4 and ESP6, so we should
also have separate config options for 'ESP in TCP' for IPv4 and IPv6.
So this should go to net/ipv4/Kconfig. When you add IPv6 support
place it in net/ipv6/Kconfig.
^ 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