Re: [RFC PATCH] panic: fix deadlock in panic()

Hi, Petr On 2020/6/4 16:29, Petr Mladek wrote: It might cause double unlock (deadlock) on architectures that did not use NMI to stop the CPUs. I have created a conservative fix for this problem for SLES, see

Re: [PATCH] module: make module symbols visible after init

Hi, Petr, Jessica and Miroslav Thank you for your reply On 2020/6/4 16:57, Petr Mladek wrote: On Wed 2020-06-03 14:12:00, Cheng Jian wrote: It is really handful that module symbols can be found already when the module is MODULE_STATE_COMING state. It is used by livepatching, ftrace, and maybe

Re: [PATCH 2/2] sched/debug: add sched_update_nr_running tracepoint

On 2019/9/4 0:05, Valentin Schneider wrote: On 03/09/2019 16:43, Radim Krčmář wrote: The paper "The Linux Scheduler: a Decade of Wasted Cores" used several custom data gathering points to better understand what was going on in the scheduler. Red Hat adapted one of them for the tracepoint

Re: [PATCH] ftrace: enable trampoline when rec count decrement to one

Hi, Steven On 2019/5/6 3:34, Steven Rostedt wrote: Thanks for the patch. There was some race condition that prevented me from doing this in the first place, but unfortunately, I don't remember what that was :-/ I'll have to think about this before applying this patch. Maybe there isn't a

Re: kernel BUG at kernel/cred.c:434!

On 2019/4/16 11:40, Kees Cook wrote: On Mon, Apr 15, 2019 at 11:20 AM Paul Moore wrote: On Mon, Apr 15, 2019 at 11:05 AM Oleg Nesterov wrote: On 04/15, Paul Moore wrote: On Mon, Apr 15, 2019 at 9:43 AM Oleg Nesterov wrote: Well, acct("/proc/self/attr/current") doesn't look like a good

Re: [PATCH] sched/fair: Use 'unsigned long' for group_shares,group_runnable

On 2019/4/15 23:25, Peter Zijlstra wrote: On Mon, Apr 15, 2019 at 11:20:31PM +0800, chengjian (D) wrote: Hi, Peter On 2019/4/15 20:46, Peter Zijlstra wrote: I write a demo about this, which I described it as overflow. I'm not saying there's no overflow, I'm saying there's nothing UB about

Re: [PATCH] sched/fair: Use 'unsigned long' for group_shares,group_runnable

Hi, Peter On 2019/4/15 20:46, Peter Zijlstra wrote: I write a demo about this, which I described it as overflow. #cat test.c //test.c #include #include #include #include int main(void) {     long a = 1048576 * 9144968455305; /* shares = tg_shares * load */     unsigned long b = a;    

kernel BUG at kernel/cred.c:434!

Hi. syzkaller reported the following BUG: [   73.146973] kernel BUG at kernel/cred.c:434! [   73.150231] invalid opcode: [#1] SMP KASAN PTI [   73.151928] CPU: 2 PID: 4058 Comm: syz-executor.6 Not tainted 5.1.0-rc4-00062-g2d06b235815e-dirty #2 [   73.155174] Hardware name: QEMU Standard

Re: WARN ON at kernel/sched/deadline.c task_non_contending

On 2019/3/13 22:49, luca abeni wrote: Hi, After looking at the patch a little bit more and running some tests, I suspect this solution might be racy: when the timer is already active, (and hrtimer_start() fails), it relies on its handler to decrease the running bw (by setting

WARN ON at kernel/sched/deadline.c task_non_contending

Hi. When looking to test SCHED_DEADLINE syzkaller report an warn in task_non_contending(). I tested the mainline kernel with the C program and captured the same call trace. [The previous message contains some strings in other formats, making the mail less readable. So I resend it. SORRY.] [ 

Re: [RFC PATCH] perf: Paper over the hw.target problems

Hi Alexander, I have tested the new version, and put it in the syzkaller workspace, it works well now. Tested-by: Cheng Jian Thanks a lot for taking the time and providing all the details. Please find an updated version below, which should not exhibit that warning. Thanks.

Re: [PATCH] x86: livepatch: Treat R_X86_64_PLT32 as R_X86_64_PC32

Hi，Jiri This patch should be merged into 4.4 stable, which still use klp_write_module_reloc. https://elixir.bootlin.com/linux/v4.4.174/source/arch/x86/kernel/livepatch.c ZeFeng may have sent a stable(4.4-y) patch to the wrong mail-list(mainline). Thanks. On 2019/2/15 15:28, Jiri Kosina

Re: [PATCH v3] perf/trace : Fix repetitious traces of perf on tracepoint

Hi, Milian On 2018/1/16 22:33, Milian Wolff wrote: perf script print the same wakeup_new event multiple times. These events which trigger this issue all specify a target process. commit e6dab5ffab59 ("perf/trace: Add ability to set a target task for events") has designed a method to trace

Re: [PATCH v3] perf/trace : Fix repetitious traces of perf on tracepoint

Hi, Milian On 2018/1/16 22:33, Milian Wolff wrote: perf script print the same wakeup_new event multiple times. These events which trigger this issue all specify a target process. commit e6dab5ffab59 ("perf/trace: Add ability to set a target task for events") has designed a method to trace

Re: [PATCH] perf/trace : Fix repetitious traces of perf on tracepoint When i use perf to trace the sched_wakeup_new tracepoint, there is a bug that output the same event repetitiously. It can be repro

On 2018/1/15 20:31, Peter Zijlstra wrote: I'm sorry I gave an inappropriate example to make the phenomenon look confusing. These events are registered per_cpu and attach in the the perf_event_ctxp of task too. So the same event is placed in the process context CPU times. perf record -e

Re: [PATCH] perf/trace : Fix repetitious traces of perf on tracepoint When i use perf to trace the sched_wakeup_new tracepoint, there is a bug that output the same event repetitiously. It can be repro

On 2018/1/15 20:31, Peter Zijlstra wrote: I'm sorry I gave an inappropriate example to make the phenomenon look confusing. These events are registered per_cpu and attach in the the perf_event_ctxp of task too. So the same event is placed in the process context CPU times. perf record -e

Re: [PATCH] kprobe : fix out-of-bounds in register_kretprobe when parsing negative data_size

Hi The demo is like: #include #include #include #include #include static int data_size=0; module_param(data_size, int, 0644); static struct kretprobe rp; static int ret_handler(struct kretprobe_instance *ri, struct pt_regs *regs) { printk(KERN_DEBUG "ret_handler\n"); return 0; }

Re: [PATCH] kprobe : fix out-of-bounds in register_kretprobe when parsing negative data_size

Hi The demo is like: #include #include #include #include #include static int data_size=0; module_param(data_size, int, 0644); static struct kretprobe rp; static int ret_handler(struct kretprobe_instance *ri, struct pt_regs *regs) { printk(KERN_DEBUG "ret_handler\n"); return 0; }

Re: [PATCH] futex: use fault_in to avoid infinite loop

On 2017/12/7 5:40, Peter Zijlstra wrote: @@ -3262,6 +3262,8 @@ static int futex_wait_requeue_pi(u32 __user *uaddr, unsigned int flags, SYSCALL_DEFINE2(set_robust_list, struct robust_list_head __user *, head, size_t, len) { + unsigned long address = (unsigned

Re: [PATCH] futex: use fault_in to avoid infinite loop

On 2017/12/7 5:40, Peter Zijlstra wrote: @@ -3262,6 +3262,8 @@ static int futex_wait_requeue_pi(u32 __user *uaddr, unsigned int flags, SYSCALL_DEFINE2(set_robust_list, struct robust_list_head __user *, head, size_t, len) { + unsigned long address = (unsigned

Re: [PATCH v3 0/5] Switch arm64 over to qrwlock

Hi, all. On 2017/10/20 0:53, Will Deacon wrote: I've not had any more feedback on this and the testing results are very encouraging so I'd like to merge it for 4.15. However, it might make more sense for the whole thing to go via -tip instead. Ingo, Peter: what do you prefer? Will Will

Re: [PATCH v3 0/5] Switch arm64 over to qrwlock

Hi, all. On 2017/10/20 0:53, Will Deacon wrote: I've not had any more feedback on this and the testing results are very encouraging so I'd like to merge it for 4.15. However, it might make more sense for the whole thing to go via -tip instead. Ingo, Peter: what do you prefer? Will Will

Re: [PATCH] perf/tools : remove default system_wide in sched record

On 2017/10/25 10:23, Namhyung Kim wrote: On Tue, Oct 24, 2017 at 10:46:44AM -0300, Arnaldo Carvalho de Melo wrote: Em Tue, Oct 24, 2017 at 03:45:34PM +0800, Cheng Jian escreveu: When running perf sched record, there is a bug. It's system_wide when we specify a command line. Humm, isn't

Re: [PATCH] perf/tools : remove default system_wide in sched record

On 2017/10/25 10:23, Namhyung Kim wrote: On Tue, Oct 24, 2017 at 10:46:44AM -0300, Arnaldo Carvalho de Melo wrote: Em Tue, Oct 24, 2017 at 03:45:34PM +0800, Cheng Jian escreveu: When running perf sched record, there is a bug. It's system_wide when we specify a command line. Humm, isn't

Re: A issue about ptrace/SINGLESTEP on arm64

On 2017/10/16 23:30, Will Deacon wrote: Can you jump the PC once the child appears to be "stuck"? IIRC, GDB has special heuristics to step through LDXR/STXR critical sections. The function can be returned, But the number of instructions looks too much We use objdump to count the assembly

Re: A issue about ptrace/SINGLESTEP on arm64

On 2017/10/16 23:30, Will Deacon wrote: Can you jump the PC once the child appears to be "stuck"? IIRC, GDB has special heuristics to step through LDXR/STXR critical sections. The function can be returned, But the number of instructions looks too much We use objdump to count the assembly

A issue about ptrace/SINGLESTEP on arm64

Hi I write demo use ptrace/SINGLESTEP to count the number of instructions executed by the process The parent process fork+exec a child process, and trace(SINGLESTEP) it, It works fine under the x86_64 architecture but has an exception under arm64. ```cpp //demo.c #include #include

A issue about ptrace/SINGLESTEP on arm64

Hi I write demo use ptrace/SINGLESTEP to count the number of instructions executed by the process The parent process fork+exec a child process, and trace(SINGLESTEP) it, It works fine under the x86_64 architecture but has an exception under arm64. ```cpp //demo.c #include #include

Re: [PATCH] perf/ftrace : Fix repetitious traces when specify a target task

On 2017/10/10 19:33, Peter Zijlstra wrote: No, this _cannot_ be right. The whole point of the @task argument was to deliver the event multiple times -- maybe not to the same event, but it needs to be delivered multiple times in some cases. Therefore this is broken. But now you've got me

Re: [PATCH] perf/ftrace : Fix repetitious traces when specify a target task

On 2017/10/10 19:33, Peter Zijlstra wrote: No, this _cannot_ be right. The whole point of the @task argument was to deliver the event multiple times -- maybe not to the same event, but it needs to be delivered multiple times in some cases. Therefore this is broken. But now you've got me

Re: a competition when some threads acquire futex

On 2017/9/6 16:36, Thomas Gleixner write: Ok. Still that patch has issues. 1) It's white space damaged. Please use TAB not spaces for indentation. checkpatch.pl would have told you. 2) Why are you using _cond_resched() instead of plain cond_resched(). cond_resched() is what you want

Re: a competition when some threads acquire futex

On 2017/9/6 16:36, Thomas Gleixner write: Ok. Still that patch has issues. 1) It's white space damaged. Please use TAB not spaces for indentation. checkpatch.pl would have told you. 2) Why are you using _cond_resched() instead of plain cond_resched(). cond_resched() is what you want

Re: a competition when some threads acquire futex

diff --git a/kernel/futex.c b/kernel/futex.c index 3d38eaf..0b2d17a 100644 --- a/kernel/futex.c +++ b/kernel/futex.c @@ -1545,6 +1545,7 @@ static int wake_futex_pi(u32 __user *uaddr, u32 uval, struct futex_pi_state *pi_ spin_unlock(>lock); wake_up_q(_q); +_cond_resched( );

Re: a competition when some threads acquire futex

diff --git a/kernel/futex.c b/kernel/futex.c index 3d38eaf..0b2d17a 100644 --- a/kernel/futex.c +++ b/kernel/futex.c @@ -1545,6 +1545,7 @@ static int wake_futex_pi(u32 __user *uaddr, u32 uval, struct futex_pi_state *pi_ spin_unlock(>lock); wake_up_q(_q); +_cond_resched( );

Re: [PATCH] arm64: Convert pr_warning to standard pr_warn

Hi Mark, OK, I will do it now On Tue, Sep 05, 2017 at 10:28:38AM +0800, chengjian c00427203 wrote: Convert pr_warning to standard pr_warn in arch/arm64/kernel/smp.c Signed-off-by: Cheng Jian --- arch/arm64/kernel/smp.c | 4 ++-- 1 file changed, 2 insertions(+),

Re: [PATCH] arm64: Convert pr_warning to standard pr_warn

Hi Mark, OK, I will do it now On Tue, Sep 05, 2017 at 10:28:38AM +0800, chengjian c00427203 wrote: Convert pr_warning to standard pr_warn in arch/arm64/kernel/smp.c Signed-off-by: Cheng Jian --- arch/arm64/kernel/smp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Is this

a competition when some threads acquire futex

A competition happend when some thread use pthread_mutex(futex in kernel). I make a demo about this : two thread get a lock and then sleep for a few time, finally unlock when waked up. ```cpp pthread_mutex_lock(); //printf("tid = %lu, count = %d\n", pthread_self( ), i);

a competition when some threads acquire futex

A competition happend when some thread use pthread_mutex(futex in kernel). I make a demo about this : two thread get a lock and then sleep for a few time, finally unlock when waked up. ```cpp pthread_mutex_lock(); //printf("tid = %lu, count = %d\n", pthread_self( ), i);