1.754.0
You can see that this patch significantly reduced the overhead,
50% for uprobe and 44% for uretprobe on x86_64, and even more
on x86_32.
Signed-off-by: Yonghong Song <y...@fb.com>
---
arch/x86/include/asm/uprobes.h | 4 ++
arch/x86/kernel/uprobes.c | 107 +
On 11/14/17 7:51 AM, Oleg Nesterov wrote:
On 11/13, Yonghong Song wrote:
+static int push_setup_xol_ops(struct arch_uprobe *auprobe, struct insn *insn)
+{
+ u8 opc1 = OPCODE1(insn), reg_offset = 0;
+
+ if (opc1 < 0x50 || opc1 > 0x57)
+ return -
On 11/14/17 7:34 AM, Oleg Nesterov wrote:
On 11/13, Yonghong Song wrote:
On 11/13/17 4:59 AM, Oleg Nesterov wrote:
+ switch (opc1) {
+ case 0x50:
+ reg_offset = offsetof(struct pt_regs, r8);
+ break
On 11/14/17 8:03 AM, Oleg Nesterov wrote:
On 11/14, Oleg Nesterov wrote:
+#ifdef CONFIG_X86_64
+ if (test_thread_flag(TIF_ADDR32))
+ return -ENOSYS;
+#endif
No, this doesn't look right, see my previous email. You should do this
check in the "if (insn->length == 2)"
Hi, Ingo and Peter,
This patch has been reviewed by Oleg Nesterov. Could you
take a look and help merge it upstream?
Thanks!
Yonghong
On 11/20/17 10:25 AM, Yonghong Song wrote:
On 11/20/17 8:41 AM, Oleg Nesterov wrote:
On 11/17, Yonghong Song wrote:
On 11/17/17 9:25 AM, Oleg Nesterov
On 11/27/17 9:04 AM, Arnaldo Carvalho de Melo wrote:
Em Fri, Nov 24, 2017 at 04:16:52PM +0100, Daniel Borkmann escreveu:
[ +Yonghong ]
+ Josh
On 11/24/2017 03:47 PM, Arnaldo Carvalho de Melo wrote:
FYI, just noticed, recently updated clang to version 6, from its
upstream git repo.
Do
On 11/24/17 11:09 AM, Arnaldo Carvalho de Melo wrote:
Em Fri, Nov 24, 2017 at 04:16:52PM +0100, Daniel Borkmann escreveu:
[ +Yonghong ]
On 11/24/2017 03:47 PM, Arnaldo Carvalho de Melo wrote:
FYI, just noticed, recently updated clang to version 6, from its
upstream git repo.
Do you recall
1.754.0
You can see that this patch significantly reduced the overhead,
50% for uprobe and 44% for uretprobe on x86_64, and even more
on x86_32.
Signed-off-by: Yonghong Song <y...@fb.com>
Reviewed-by: Oleg Nesterov <o...@redhat.com>
---
On 11/27/17 1:45 PM, Matthias Kaehlcke wrote:
El Mon, Nov 27, 2017 at 01:57:56PM -0600 Josh Poimboeuf ha dit:
On Mon, Nov 27, 2017 at 04:34:25PM -0300, Arnaldo Carvalho de Melo wrote:
Em Mon, Nov 27, 2017 at 11:11:56AM -0800, Yonghong Song escreveu:
On 11/27/17 9:04 AM, Arnaldo Carvalho de
On 11/17/17 9:25 AM, Oleg Nesterov wrote:
On 11/15, Yonghong Song wrote:
v3 -> v4:
. Revert most of v3 change as 32bit emulation is not really working
on x86_64 platform as among other issues, function emulate_push_stack()
needs to account for 32bit app on 64bit platf
1.754.0
You can see that this patch significantly reduced the overhead,
50% for uprobe and 44% for uretprobe on x86_64, and even more
on x86_32.
Signed-off-by: Yonghong Song <y...@fb.com>
---
arch/x86/include/asm/uprobes.h | 4 ++
arch/x86/kernel/uprobes.c | 108 +
On 11/20/17 8:41 AM, Oleg Nesterov wrote:
On 11/17, Yonghong Song wrote:
On 11/17/17 9:25 AM, Oleg Nesterov wrote:
On 11/15, Yonghong Song wrote:
v3 -> v4:
. Revert most of v3 change as 32bit emulation is not really working
on x86_64 platform as among other issues, funct
On 11/15/17 9:07 AM, Oleg Nesterov wrote:
On 11/15, Oleg Nesterov wrote:
So please, check if uprobe_init_insn() fails or not in this case. After that
we will know whether your patch needs the additional is_64bit_mm() check in
push_setup_xol_ops() or not.
OK, I did the check for you.
On 11/13/17 4:59 AM, Oleg Nesterov wrote:
The patch looks good to me, but I have a question because I know nothing
about insn encoding,
On 11/10, Yonghong Song wrote:
+static int push_setup_xol_ops(struct arch_uprobe *auprobe, struct insn *insn)
+{
+ u8 opc1 = OPCODE1(insn
1.754.0
You can see that this patch significantly reduced the overhead,
50% for uprobe and 44% for uretprobe on x86_64, and even more
on x86_32.
Signed-off-by: Yonghong Song <y...@fb.com>
---
arch/x86/include/asm/uprobes.h | 4 ++
arch/x86/kernel/uprobes.c | 111 +
On 11/9/17 3:26 AM, David Laight wrote:
From: Yonghong Song
Sent: 09 November 2017 00:55
Uprobe is a tracing mechanism for userspace programs.
Typical uprobe will incur overhead of two traps.
First trap is caused by replaced trap insn, and
the second trap is to execute the original displaced
On 11/9/17 5:44 AM, Oleg Nesterov wrote:
On 11/09, Yonghong Song wrote:
This patch extends the emulation to "push "
insns. These insns are typical in the beginning
of the function. For example, bcc
in https://github.com/iovisor/bcc repo provides
tools to measure funclantency, dete
1.754.0
You can see that this patch significantly reduced the overhead,
50% for uprobe and 44% for uretprobe on x86_64, and even more
on x86_32.
Signed-off-by: Yonghong Song <y...@fb.com>
---
arch/x86/include/asm/uprobes.h | 4 ++
arch/x86/kernel/uprobes.c | 110 +
1.754.0
You can see that this patch significantly reduced the overhead,
50% for uprobe and 44% for uretprobe on x86_64, and even more
on x86_32.
Signed-off-by: Yonghong Song <y...@fb.com>
---
arch/x86/include/asm/uprobes.h | 10
arch/x86/kernel/uprobes.c | 115 +++
1.754.0
You can see that this patch significantly reduced the overhead,
50% for uprobe and 44% for uretprobe on x86_64, and even more
on x86_32.
Signed-off-by: Yonghong Song <y...@fb.com>
---
arch/x86/include/asm/uprobes.h | 10
arch/x86/kernel/uprobes.c | 115 +++
On 11/8/17 4:06 PM, David Miller wrote:
From: Yonghong Song <y...@fb.com>
Date: Wed, 8 Nov 2017 13:37:12 -0800
Uprobe is a tracing mechanism for userspace programs.
Typical uprobe will incur overhead of two traps.
First trap is caused by replaced trap insn, and
the second trap is to e
ts. Tested on both x86_64 and x86_32,
uprobe works fine.
Fixes: b70543a0b2b6("x86/idt: Move regular trap init to tables")
Reported-and-tested-by: Yonghong Song <y...@fb.com>
Signed-off-by: Yonghong Song <y...@fb.com>
---
arch/x86/kernel/idt.c | 2 --
1 file changed, 2 deletio
On 11/8/17 10:53 PM, Thomas Gleixner wrote:
On Wed, 8 Nov 2017, Yonghong Song wrote:
On 11/8/17 4:06 PM, David Miller wrote:
From: Yonghong Song <y...@fb.com>
Date: Wed, 8 Nov 2017 13:37:12 -0800
Uprobe is a tracing mechanism for userspace programs.
Typical uprobe will incur ov
1.754.0
You can see that this patch significantly reduced the overhead,
50% for uprobe and 44% for uretprobe on x86_64, and even more
on x86_32.
Signed-off-by: Yonghong Song <y...@fb.com>
---
arch/x86/include/asm/uprobes.h | 10
arch/x86/kernel/uprobes.c | 115 +++
Hi, Ingo and Peter,
Could you take a look at this patch and if no objection
merge it into tip? This patch has been reviewed by
Oleg Nesterov.
Thanks!
Yonghong
On 11/30/17 4:12 PM, Yonghong Song wrote:
Uprobe is a tracing mechanism for userspace programs.
Typical uprobe will incur overhead
Hi, Peter,
Just wanted to ping again so that you did not miss the email below.
Please let me know your opinion.
Thanks!
Yonghong
On 4/23/18 9:50 AM, Yonghong Song wrote:
Hi, Peter,
Please see comments below.
On 4/23/18 3:52 AM, Peter Zijlstra wrote:
On Fri, Apr 20, 2018 at 11:06:03AM
On 6/16/18 5:26 AM, Arnaldo Carvalho de Melo wrote:
Hi Wang, Yogong,
While reviewing the BTF patches for pahole, I updated llvm/clang
to HEAD and then building perf with clang embedded I noticed this, will
investigate, posting here to document the regression, maybe this is
something
This patch fixed the issue with using
proper function signatures under different compiler versions.
Reported-by: Arnaldo Carvalho de Melo
Signed-off-by: Yonghong Song
---
tools/perf/util/c++/clang.cpp | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/c++/
On 6/18/18 7:31 AM, Arnaldo Carvalho de Melo wrote:
Em Sat, Jun 16, 2018 at 10:20:21AM -0700, Yonghong Song escreveu:
On 6/16/18 5:26 AM, Arnaldo Carvalho de Melo wrote:
Hi Wang, Yogong,
While reviewing the BTF patches for pahole, I updated llvm/clang
to HEAD and then building
Hi, Peter,
Ping again. Did you get chances to think about this issue again?
Thanks!
Yonghong
On 4/27/18 9:34 AM, Yonghong Song wrote:
Hi, Peter,
Just wanted to ping again so that you did not miss the email below.
Please let me know your opinion.
Thanks!
Yonghong
On 4/23/18 9:50 AM
Remove FAST_FEATURE_TESTS")
Suggested-by: Alexei Starovoitov <a...@kernel.org>
Signed-off-by: Yonghong Song <y...@fb.com>
---
Makefile | 1 +
arch/x86/include/asm/cpufeature.h | 5 +
2 files changed, 6 insertions(+)
Changelog:
v2 -> v3:
. Changed macr
Thanks for reporting. This issue has been fixed by the below commit in
bpf-next repo, which is waiting to be pulled into net-next.
=
commit 2310035fa03f651dd5b03f19a26a97512aa8842c
Author: Yonghong Song <y...@fb.com>
Date: Mon Jan 22 22:53:51 2018 -0800
bpf: fix incorrect k
On 2/12/18 7:55 AM, Alexei Starovoitov wrote:
On Mon, Feb 12, 2018 at 09:28:33AM +0100, Daniel Borkmann wrote:
On 02/12/2018 06:47 AM, Yonghong Song wrote:
On 2/11/18 11:18 AM, Mathieu Malaterre wrote:
On Sun, Feb 11, 2018 at 5:54 PM, Alexei Starovoitov
<alexei.starovoi...@gmail.com>
On 2/11/18 11:18 AM, Mathieu Malaterre wrote:
Hi,
On Sun, Feb 11, 2018 at 5:54 PM, Alexei Starovoitov
wrote:
On Sun, Feb 11, 2018 at 7:24 AM, Mathieu Malaterre wrote:
Alexei,
Could you please comment on why I am seeing those memleaks being
On 12/20/17 12:19 PM, Roman Gushchin wrote:
Bpftool determines it's own version based on the kernel
version, which is picked from the linux/version.h header.
It's strange to use the version of the installed kernel
headers, and makes much more sense to use the version
of the actual source
On 3/13/18 4:45 PM, Omar Sandoval wrote:
On Tue, Mar 13, 2018 at 04:16:27PM -0700, Howard McLauchlan wrote:
Error injection is a useful mechanism to fail arbitrary kernel
functions. However, it is often hard to guarantee an error propagates
appropriately to user space programs. By injecting
ear.
If later clang compiler starts to support asm_volatile_goto,
the change in this patch can be reverted and there should
be no impact on BPF compilation.
Fixes: d0266046ad54 ("x86: Remove FAST_FEATURE_TESTS")
Signed-off-by: Yonghong Song <y...@fb.com>
---
arch/x86/include/asm/cpuf
Hi, Arnaldo,
When I studied the bpf compilation issue with latest linus/net-next
kernel (https://patchwork.kernel.org/patch/10333829/), an alternative
approach I tried is to use __BPF__ macro. The following patch
introduced "#ifndef __BPF__" in arch/x86/include/asm/asm.h for
some inline
On 4/11/18 11:39 AM, Arnaldo Carvalho de Melo wrote:
Em Wed, Apr 11, 2018 at 09:37:46AM -0700, Yonghong Song escreveu:
Hi, Arnaldo,
When I studied the bpf compilation issue with latest linus/net-next
kernel (https://patchwork.kernel.org/patch/10333829/), an alternative
approach I tried
On 4/11/18 4:17 PM, Arnaldo Carvalho de Melo wrote:
Em Wed, Apr 11, 2018 at 04:47:29PM -0300, Arnaldo Carvalho de Melo escreveu:
Em Wed, Apr 11, 2018 at 12:22:37PM -0700, Yonghong Song escreveu:
Look at test bpf-script-test-kbuild.c, I think you can drop
uapi/asm/ptrace.h from include file
On 4/14/18 3:11 AM, Peter Zijlstra wrote:
On Fri, Apr 13, 2018 at 01:42:14PM -0700, Alexei Starovoitov wrote:
On 4/13/18 11:19 AM, Peter Zijlstra wrote:
On Tue, Apr 10, 2018 at 02:28:04PM -0700, Alexei Starovoitov wrote:
Instead of
#ifdef CC_HAVE_ASM_GOTO
we can replace it with
#ifndef
On 4/20/18 1:19 AM, Peter Zijlstra wrote:
On Sat, Apr 14, 2018 at 09:27:38PM -0700, Yonghong Song wrote:
This patch adds a preprocessor guard NO_BPF_WORKAROUND around the
asm_volatile_goto based static_cpu_has(). NO_BPF_WORKAROUND is set
at toplevel Makefile when compiler supports asm-goto
4 ("x86: Remove FAST_FEATURE_TESTS")
Suggested-by: Alexei Starovoitov <a...@kernel.org>
Signed-off-by: Yonghong Song <y...@fb.com>
---
Makefile | 1 +
arch/x86/include/asm/cpufeature.h | 5 +
2 files changed, 6 insertions(+)
Changelog:
v1 -> v2
Hi, Peter,
Just pinging. Did you get chances to look at this?
[ cc netdev as well so folks are aware of the issue. ]
Thanks!
Yonghong
On 4/14/18 9:27 PM, Yonghong Song wrote:
Commit d0266046ad54 ("x86: Remove FAST_FEATURE_TESTS")
removed X86_FAST_FEATURE_TESTS and make macro stat
Hi, Peter,
Please see comments below.
On 4/23/18 3:52 AM, Peter Zijlstra wrote:
On Fri, Apr 20, 2018 at 11:06:03AM -0700, Yonghong Song wrote:
On 4/20/18 1:19 AM, Peter Zijlstra wrote:
Hurm, so adding __BPF__ for BPF compiles isn't an option? It seems to me
having a CPP flag to identify
On 3/20/18 5:58 AM, Thadeu Lima de Souza Cascardo wrote:
Function bpf_fill_maxinsns11 is designed to not be able to be JITed on
x86_64. So, it fails when CONFIG_BPF_JIT_ALWAYS_ON=y, and
commit 09584b406742 ("bpf: fix selftests/bpf test_kmod.sh failure when
CONFIG_BPF_JIT_ALWAYS_ON=y") makes
On 3/20/18 10:00 AM, Thadeu Lima de Souza Cascardo wrote:
On Tue, Mar 20, 2018 at 09:05:15AM -0700, Yonghong Song wrote:
On 3/20/18 5:58 AM, Thadeu Lima de Souza Cascardo wrote:
Function bpf_fill_maxinsns11 is designed to not be able to be JITed on
x86_64. So, it fails when
I cannot reproduce in my local fc28 system with the attached steps.
The netlink_dumper.c file, could you confirm whether the following
header files are missing form you rhel-7.2 host?
#include
#include
I suspect you probably miss linux/tc_act/tc_bpf.h. But could you confirm
it? If this is
On 11/6/18 2:04 AM, Li Zhijian wrote:
>
> On 11/6/2018 9:47 AM, Yonghong Song wrote:
>> I cannot reproduce in my local fc28 system with the attached steps.
>>
>> The netlink_dumper.c file, could you confirm whether the following
>> header files are missing form you
On 3/13/18 4:45 PM, Omar Sandoval wrote:
On Tue, Mar 13, 2018 at 04:16:27PM -0700, Howard McLauchlan wrote:
Error injection is a useful mechanism to fail arbitrary kernel
functions. However, it is often hard to guarantee an error propagates
appropriately to user space programs. By injecting
On 3/20/18 5:58 AM, Thadeu Lima de Souza Cascardo wrote:
Function bpf_fill_maxinsns11 is designed to not be able to be JITed on
x86_64. So, it fails when CONFIG_BPF_JIT_ALWAYS_ON=y, and
commit 09584b406742 ("bpf: fix selftests/bpf test_kmod.sh failure when
CONFIG_BPF_JIT_ALWAYS_ON=y") makes
On 3/20/18 10:00 AM, Thadeu Lima de Souza Cascardo wrote:
On Tue, Mar 20, 2018 at 09:05:15AM -0700, Yonghong Song wrote:
On 3/20/18 5:58 AM, Thadeu Lima de Souza Cascardo wrote:
Function bpf_fill_maxinsns11 is designed to not be able to be JITed on
x86_64. So, it fails when
Hi, Peter,
Just wanted to ping again so that you did not miss the email below.
Please let me know your opinion.
Thanks!
Yonghong
On 4/23/18 9:50 AM, Yonghong Song wrote:
Hi, Peter,
Please see comments below.
On 4/23/18 3:52 AM, Peter Zijlstra wrote:
On Fri, Apr 20, 2018 at 11:06:03AM
Remove FAST_FEATURE_TESTS")
Suggested-by: Alexei Starovoitov
Signed-off-by: Yonghong Song
---
Makefile | 1 +
arch/x86/include/asm/cpufeature.h | 5 +
2 files changed, 6 insertions(+)
Changelog:
v2 -> v3:
. Changed macro name from NO_BPF_WORKAROUND to __NO_C
Hi, Peter,
Ping again. Did you get chances to think about this issue again?
Thanks!
Yonghong
On 4/27/18 9:34 AM, Yonghong Song wrote:
Hi, Peter,
Just wanted to ping again so that you did not miss the email below.
Please let me know your opinion.
Thanks!
Yonghong
On 4/23/18 9:50 AM
On 12/20/17 12:19 PM, Roman Gushchin wrote:
Bpftool determines it's own version based on the kernel
version, which is picked from the linux/version.h header.
It's strange to use the version of the installed kernel
headers, and makes much more sense to use the version
of the actual source
Hi, Ingo and Peter,
This patch has been reviewed by Oleg Nesterov. Could you
take a look and help merge it upstream?
Thanks!
Yonghong
On 11/20/17 10:25 AM, Yonghong Song wrote:
On 11/20/17 8:41 AM, Oleg Nesterov wrote:
On 11/17, Yonghong Song wrote:
On 11/17/17 9:25 AM, Oleg Nesterov
On 11/27/17 9:04 AM, Arnaldo Carvalho de Melo wrote:
Em Fri, Nov 24, 2017 at 04:16:52PM +0100, Daniel Borkmann escreveu:
[ +Yonghong ]
+ Josh
On 11/24/2017 03:47 PM, Arnaldo Carvalho de Melo wrote:
FYI, just noticed, recently updated clang to version 6, from its
upstream git repo.
Do
On 11/27/17 1:45 PM, Matthias Kaehlcke wrote:
El Mon, Nov 27, 2017 at 01:57:56PM -0600 Josh Poimboeuf ha dit:
On Mon, Nov 27, 2017 at 04:34:25PM -0300, Arnaldo Carvalho de Melo wrote:
Em Mon, Nov 27, 2017 at 11:11:56AM -0800, Yonghong Song escreveu:
On 11/27/17 9:04 AM, Arnaldo Carvalho de
Hi, Ingo and Peter,
Could you take a look at this patch and if no objection
merge it into tip? This patch has been reviewed by
Oleg Nesterov.
Thanks!
Yonghong
On 11/30/17 4:12 PM, Yonghong Song wrote:
Uprobe is a tracing mechanism for userspace programs.
Typical uprobe will incur overhead
On 11/13/17 4:59 AM, Oleg Nesterov wrote:
The patch looks good to me, but I have a question because I know nothing
about insn encoding,
On 11/10, Yonghong Song wrote:
+static int push_setup_xol_ops(struct arch_uprobe *auprobe, struct insn *insn)
+{
+ u8 opc1 = OPCODE1(insn
1.754.0
You can see that this patch significantly reduced the overhead,
50% for uprobe and 44% for uretprobe on x86_64, and even more
on x86_32.
Signed-off-by: Yonghong Song
---
arch/x86/include/asm/uprobes.h | 4 ++
arch/x86/kernel/uprobes.c | 111 +
On 11/14/17 7:34 AM, Oleg Nesterov wrote:
On 11/13, Yonghong Song wrote:
On 11/13/17 4:59 AM, Oleg Nesterov wrote:
+ switch (opc1) {
+ case 0x50:
+ reg_offset = offsetof(struct pt_regs, r8);
+ break
On 11/14/17 7:51 AM, Oleg Nesterov wrote:
On 11/13, Yonghong Song wrote:
+static int push_setup_xol_ops(struct arch_uprobe *auprobe, struct insn *insn)
+{
+ u8 opc1 = OPCODE1(insn), reg_offset = 0;
+
+ if (opc1 < 0x50 || opc1 > 0x57)
+ return -
On 11/14/17 8:03 AM, Oleg Nesterov wrote:
On 11/14, Oleg Nesterov wrote:
+#ifdef CONFIG_X86_64
+ if (test_thread_flag(TIF_ADDR32))
+ return -ENOSYS;
+#endif
No, this doesn't look right, see my previous email. You should do this
check in the "if (insn->length == 2)"
ts. Tested on both x86_64 and x86_32,
uprobe works fine.
Fixes: b70543a0b2b6("x86/idt: Move regular trap init to tables")
Reported-and-tested-by: Yonghong Song
Signed-off-by: Yonghong Song
---
arch/x86/kernel/idt.c | 2 --
1 file changed, 2 deletions(-)
[RESEND with adding linux-ke
1.754.0
You can see that this patch significantly reduced the overhead,
50% for uprobe and 44% for uretprobe on x86_64, and even more
on x86_32.
Signed-off-by: Yonghong Song
---
arch/x86/include/asm/uprobes.h | 10
arch/x86/kernel/uprobes.c | 115 ++
On 11/8/17 4:06 PM, David Miller wrote:
From: Yonghong Song
Date: Wed, 8 Nov 2017 13:37:12 -0800
Uprobe is a tracing mechanism for userspace programs.
Typical uprobe will incur overhead of two traps.
First trap is caused by replaced trap insn, and
the second trap is to execute the original
1.754.0
You can see that this patch significantly reduced the overhead,
50% for uprobe and 44% for uretprobe on x86_64, and even more
on x86_32.
Signed-off-by: Yonghong Song
---
arch/x86/include/asm/uprobes.h | 10
arch/x86/kernel/uprobes.c | 115 ++
On 11/8/17 10:53 PM, Thomas Gleixner wrote:
On Wed, 8 Nov 2017, Yonghong Song wrote:
On 11/8/17 4:06 PM, David Miller wrote:
From: Yonghong Song
Date: Wed, 8 Nov 2017 13:37:12 -0800
Uprobe is a tracing mechanism for userspace programs.
Typical uprobe will incur overhead of two traps
1.754.0
You can see that this patch significantly reduced the overhead,
50% for uprobe and 44% for uretprobe on x86_64, and even more
on x86_32.
Signed-off-by: Yonghong Song
---
arch/x86/include/asm/uprobes.h | 10
arch/x86/kernel/uprobes.c | 115
On 11/9/17 3:26 AM, David Laight wrote:
From: Yonghong Song
Sent: 09 November 2017 00:55
Uprobe is a tracing mechanism for userspace programs.
Typical uprobe will incur overhead of two traps.
First trap is caused by replaced trap insn, and
the second trap is to execute the original displaced
On 11/9/17 5:44 AM, Oleg Nesterov wrote:
On 11/09, Yonghong Song wrote:
This patch extends the emulation to "push "
insns. These insns are typical in the beginning
of the function. For example, bcc
in https://github.com/iovisor/bcc repo provides
tools to measure funclantency, dete
1.754.0
You can see that this patch significantly reduced the overhead,
50% for uprobe and 44% for uretprobe on x86_64, and even more
on x86_32.
Signed-off-by: Yonghong Song
---
arch/x86/include/asm/uprobes.h | 4 ++
arch/x86/kernel/uprobes.c | 110 +
1.754.0
You can see that this patch significantly reduced the overhead,
50% for uprobe and 44% for uretprobe on x86_64, and even more
on x86_32.
Signed-off-by: Yonghong Song
---
arch/x86/include/asm/uprobes.h | 4 ++
arch/x86/kernel/uprobes.c | 108 +
On 11/17/17 9:25 AM, Oleg Nesterov wrote:
On 11/15, Yonghong Song wrote:
v3 -> v4:
. Revert most of v3 change as 32bit emulation is not really working
on x86_64 platform as among other issues, function emulate_push_stack()
needs to account for 32bit app on 64bit platf
On 11/20/17 8:41 AM, Oleg Nesterov wrote:
On 11/17, Yonghong Song wrote:
On 11/17/17 9:25 AM, Oleg Nesterov wrote:
On 11/15, Yonghong Song wrote:
v3 -> v4:
. Revert most of v3 change as 32bit emulation is not really working
on x86_64 platform as among other issues, funct
On 4/11/18 11:39 AM, Arnaldo Carvalho de Melo wrote:
Em Wed, Apr 11, 2018 at 09:37:46AM -0700, Yonghong Song escreveu:
Hi, Arnaldo,
When I studied the bpf compilation issue with latest linus/net-next
kernel (https://patchwork.kernel.org/patch/10333829/), an alternative
approach I tried
On 4/11/18 4:17 PM, Arnaldo Carvalho de Melo wrote:
Em Wed, Apr 11, 2018 at 04:47:29PM -0300, Arnaldo Carvalho de Melo escreveu:
Em Wed, Apr 11, 2018 at 12:22:37PM -0700, Yonghong Song escreveu:
Look at test bpf-script-test-kbuild.c, I think you can drop
uapi/asm/ptrace.h from include file
On 4/14/18 3:11 AM, Peter Zijlstra wrote:
On Fri, Apr 13, 2018 at 01:42:14PM -0700, Alexei Starovoitov wrote:
On 4/13/18 11:19 AM, Peter Zijlstra wrote:
On Tue, Apr 10, 2018 at 02:28:04PM -0700, Alexei Starovoitov wrote:
Instead of
#ifdef CC_HAVE_ASM_GOTO
we can replace it with
#ifndef
4 ("x86: Remove FAST_FEATURE_TESTS")
Suggested-by: Alexei Starovoitov
Signed-off-by: Yonghong Song
---
Makefile | 1 +
arch/x86/include/asm/cpufeature.h | 5 +
2 files changed, 6 insertions(+)
Changelog:
v1 -> v2:
Use NO_BPF_WORKAROUND macro instead of CC_HAV
On 4/20/18 1:19 AM, Peter Zijlstra wrote:
On Sat, Apr 14, 2018 at 09:27:38PM -0700, Yonghong Song wrote:
This patch adds a preprocessor guard NO_BPF_WORKAROUND around the
asm_volatile_goto based static_cpu_has(). NO_BPF_WORKAROUND is set
at toplevel Makefile when compiler supports asm-goto
ear.
If later clang compiler starts to support asm_volatile_goto,
the change in this patch can be reverted and there should
be no impact on BPF compilation.
Fixes: d0266046ad54 ("x86: Remove FAST_FEATURE_TESTS")
Signed-off-by: Yonghong Song
---
arch/x86/include/asm/cpufeature.h | 4
1 file
Hi, Arnaldo,
When I studied the bpf compilation issue with latest linus/net-next
kernel (https://patchwork.kernel.org/patch/10333829/), an alternative
approach I tried is to use __BPF__ macro. The following patch
introduced "#ifndef __BPF__" in arch/x86/include/asm/asm.h for
some inline
Hi, Peter,
Please see comments below.
On 4/23/18 3:52 AM, Peter Zijlstra wrote:
On Fri, Apr 20, 2018 at 11:06:03AM -0700, Yonghong Song wrote:
On 4/20/18 1:19 AM, Peter Zijlstra wrote:
Hurm, so adding __BPF__ for BPF compiles isn't an option? It seems to me
having a CPP flag to identify
Hi, Peter,
Just pinging. Did you get chances to look at this?
[ cc netdev as well so folks are aware of the issue. ]
Thanks!
Yonghong
On 4/14/18 9:27 PM, Yonghong Song wrote:
Commit d0266046ad54 ("x86: Remove FAST_FEATURE_TESTS")
removed X86_FAST_FEATURE_TESTS and make macro stat
On 2/12/18 7:55 AM, Alexei Starovoitov wrote:
On Mon, Feb 12, 2018 at 09:28:33AM +0100, Daniel Borkmann wrote:
On 02/12/2018 06:47 AM, Yonghong Song wrote:
On 2/11/18 11:18 AM, Mathieu Malaterre wrote:
On Sun, Feb 11, 2018 at 5:54 PM, Alexei Starovoitov
wrote:
On Sun, Feb 11, 2018 at 7:24
1.754.0
You can see that this patch significantly reduced the overhead,
50% for uprobe and 44% for uretprobe on x86_64, and even more
on x86_32.
Signed-off-by: Yonghong Song
Reviewed-by: Oleg Nesterov
---
arch/x86/include/asm/uprobes.h | 4 ++
arch/x86/kernel/uprobes.c | 10
On 11/24/17 11:09 AM, Arnaldo Carvalho de Melo wrote:
Em Fri, Nov 24, 2017 at 04:16:52PM +0100, Daniel Borkmann escreveu:
[ +Yonghong ]
On 11/24/2017 03:47 PM, Arnaldo Carvalho de Melo wrote:
FYI, just noticed, recently updated clang to version 6, from its
upstream git repo.
Do you recall
On 1/19/21 4:22 AM, Qais Yousef wrote:
Reuse module_attach infrastructure to add a new bare tracepoint to check
we can attach to it as a raw tracepoint.
Signed-off-by: Qais Yousef
Acked-by: Yonghong Song
-project/llvm/build/install is
not used, BUILD_SHARED_LIBS=OFF is the default option [2], so also change
Documentation/bpf/bpf_devel_QA.rst together.
[1] https://clang.llvm.org/get_started.html
[2] https://www.llvm.org/docs/CMake.html
Signed-off-by: Tiezhu Yang
Acked-by: Yonghong Song
Reviewed
On 1/15/21 3:34 PM, Song Liu wrote:
On Jan 12, 2021, at 8:53 AM, KP Singh wrote:
On Tue, Jan 12, 2021 at 5:32 PM Yonghong Song wrote:
On 1/11/21 3:45 PM, Song Liu wrote:
On Jan 11, 2021, at 1:58 PM, Martin Lau wrote:
On Mon, Jan 11, 2021 at 10:35:43PM +0100, KP Singh wrote
On 1/15/21 3:34 PM, Nick Desaulniers wrote:
On Fri, Jan 15, 2021 at 3:24 PM Yonghong Song wrote:
On 1/15/21 1:53 PM, Sedat Dilek wrote:
En plus, I encountered breakage with GCC v10.2.1 and LLVM=1 and
CONFIG_DEBUG_INFO_DWARF4.
So might be good to add a "depends on !DEBUG_INF
On 1/15/21 1:53 PM, Sedat Dilek wrote:
On Fri, Jan 15, 2021 at 10:06 PM Nick Desaulniers
wrote:
DWARF v5 is the latest standard of the DWARF debug info format.
DWARF5 wins significantly in terms of size when mixed with compression
(CONFIG_DEBUG_INFO_COMPRESSED).
Link:
On 1/15/21 5:12 PM, Song Liu wrote:
On Jan 15, 2021, at 4:55 PM, Yonghong Song wrote:
On 1/15/21 3:34 PM, Song Liu wrote:
On Jan 12, 2021, at 8:53 AM, KP Singh wrote:
On Tue, Jan 12, 2021 at 5:32 PM Yonghong Song wrote:
On 1/11/21 3:45 PM, Song Liu wrote:
On Jan 11, 2021
On 1/16/21 10:21 AM, Qais Yousef wrote:
Reuse module_attach infrastructure to add a new bare tracepoint to check
we can attach to it as a raw tracepoint.
Signed-off-by: Qais Yousef
---
.../bpf/bpf_testmod/bpf_testmod-events.h | 6 +
.../selftests/bpf/bpf_testmod/bpf_testmod.c
about any ABI.
Update Documentation/bpf/bpf_design_QA.rst to document this contract.
Signed-off-by: Qais Yousef
Acked-by: Yonghong Song
/#m07264fc18fdc43af02fc1320968afefcc73d96f4
Signed-off-by: Brendan Jackman
Thanks for better description!
Acked-by: Yonghong Song
On 1/18/21 4:18 AM, Qais Yousef wrote:
On 01/16/21 18:11, Yonghong Song wrote:
On 1/16/21 10:21 AM, Qais Yousef wrote:
Reuse module_attach infrastructure to add a new bare tracepoint to check
we can attach to it as a raw tracepoint.
Signed-off-by: Qais Yousef
---
.../bpf/bpf_testmod
On 1/18/21 12:53 AM, Tiezhu Yang wrote:
In the current samples/bpf/README.rst, the url of llvm and clang git
may be out of date, they are unable to access:
$ git clone http://llvm.org/git/llvm.git
Cloning into 'llvm'...
fatal: unable to access 'http://llvm.org/git/llvm.git/ ': Maximum (20)
1 - 100 of 378 matches
Mail list logo