Dear Masami and Steve,
I have sent v2 but still have confusions:
OK, I think it is simpler to check the rp->kp.addr && rp->kp.symbol_name
because it is not allowed (it can lead inconsistent setting).
How about this code? Is this work for you?
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
i
ister your driver/filesystem without releasing, it
will
break the kernel.
Thank you,
-- Steve
On Tue, 22 Dec 2020 20:03:56 +0900
Masami Hiramatsu wrote:
On Mon, 21 Dec 2020 21:31:42 +0800
"Wangshaobo (bobo)" wrote:
Hi steven, Masami,
We have encountered a problem, when we attem
Hi steven, Masami,
We have encountered a problem, when we attempted to use steven's suggestion as
following,
If you call this here, you must make sure kprobe_addr() is called on rp->kp.
But if kretprobe_blacklist_size == 0, kprobe_addr() is not called before
this check. So it should be in betwe
Hi Masami,
I will update and resend it soon
Thank you
-- ShaoBo
在 2020/12/15 11:31, Masami Hiramatsu 写道:
Hi ShaoBo,
On Wed, 2 Dec 2020 09:23:35 +0800
"Wangshaobo (bobo)" wrote:
Hi steve, Masami,
Thanks for your works, i will check code again and modify properly
according
Hi steve, Masami,
Thanks for your works, i will check code again and modify properly
according to steve's suggestion.
-- ShaoBo
在 2020/12/2 7:32, Masami Hiramatsu 写道:
On Mon, 30 Nov 2020 16:18:50 -0500
Steven Rostedt wrote:
Masami,
Can you review this patch, and also, should this go to -
在 2020/9/18 18:01, Yicong Yang 写道:
On 2020/9/18 16:25, Wang ShaoBo wrote:
Make use of devm_platform_get_and_ioremap_resource() provided by
driver core platform instead of duplicated analogue. dev_err() is
removed because it has been done in devm_ioremap_resource().
Signed-off-by: Wang ShaoBo
在 2020/7/30 18:03, Arnaldo Carvalho de Melo 写道:
Em Wed, Jul 29, 2020 at 04:47:36PM -0700, Ian Rogers escreveu:
On Fri, Jul 24, 2020 at 3:07 AM Wang ShaoBo wrote:
Function jvmti_write_code called by compiled_method_load_cb may return
error in using fwrite_unlocked, this failure should be capt
Tested-by: Wang ShaoBo
在 2020/7/17 22:04, Josh Poimboeuf 写道:
A couple of reliable unwinder fixes for newly forked tasks, which were
reported by Wang ShaoBo.
Josh Poimboeuf (2):
x86/unwind/orc: Fix ORC for newly forked tasks
x86/stacktrace: Fix reliable check for empty user task stacks
在 2020/6/5 9:51, Josh Poimboeuf 写道:
On Fri, Jun 05, 2020 at 09:26:42AM +0800, Wangshaobo (bobo) wrote:
So, I want to ask is there any side effects if i modify like this ? this
modification is based on
your fix. It looks like ok with proper test.
diff --git a/arch/x86/kernel/unwind_orc.c b
在 2020/6/8 17:46, Catalin Marinas 写道:
On Mon, Jun 08, 2020 at 10:49:25AM +0800, Wang ShaoBo wrote:
Currently arm64 personality syscall uses wrapper __arm64_sys_personality
to redirect to __arm64_sys_arm64_personality, it's easily confused,
Whereas using an normal hook arch_check_personality()
在 2020/6/4 10:40, Josh Poimboeuf 写道:
On Thu, Jun 04, 2020 at 09:24:55AM +0800, Wangshaobo (bobo) wrote:
在 2020/6/3 23:33, Josh Poimboeuf 写道:
On Wed, Jun 03, 2020 at 10:06:07PM +0800, Wangshaobo (bobo) wrote:
To be honest, I don't remember what I meant by sibling calls. They
don't
在 2020/6/3 23:33, Josh Poimboeuf 写道:
On Wed, Jun 03, 2020 at 10:06:07PM +0800, Wangshaobo (bobo) wrote:
To be honest, I don't remember what I meant by sibling calls. They
don't even leave anything on the stack.
For noreturns, the code might be laid out like th
在 2020/6/2 21:14, Josh Poimboeuf 写道:
On Tue, Jun 02, 2020 at 09:22:30AM +0800, Wangshaobo (bobo) wrote:
so i think this question is related to ORC unwinder, could i ask if you have
strategy or plan to avoid this problem ?
I suspect something like this would fix it (untested):
diff --git a
在 2020/6/2 2:05, Josh Poimboeuf 写道:
On Sat, May 30, 2020 at 10:21:19AM +0800, Wangshaobo (bobo) wrote:
1) when a user mode task just fork start excuting ret_from_fork() till
schedule_tail, unwind_next_frame found
orc->sp_reg is ORC_REG_UNDEFINED but orc->end not equals zero, thi
在 2020/5/20 15:05, Jiri Olsa 写道:
On Wed, May 20, 2020 at 11:32:16AM +0800, Wang ShaoBo wrote:
key_scan_pos is a pointer for getting scan position in
bpf__obj_config_map() for each BPF map configuration term,
but it's misused when error not happened.
Fixes: 066dacbf2a32 ("perf bpf: Add API to
15 matches
Mail list logo
