search for: preempt_schedule

...ck_t *kretprobe_table_lock_ptr(unsigned long hash) return &(kretprobe_table_locks[hash].lock); } -/* - * Normally, functions that we'd want to prohibit kprobes in, are marked - * __kprobes. But, there are cases where such functions already belong to - * a different section (__sched for preempt_schedule) - * - * For such cases, we now have a blacklist - */ -static struct kprobe_blackpoint kprobe_blacklist[] = { - {"preempt_schedule",}, - {"native_get_debugreg",}, - {NULL} /* Terminator */ -}; +/* Blacklist -- list of struct kprobe_blackpoint */ +static LIST_HEAD(kprobe_black...

...0xd2/0x130 Oct 28 10:36:40 localhost kernel:  [md_do_sync+1571/2048] md_do_sync+0x623/0x800 Oct 28 10:36:40 localhost kernel:  [recalc_task_prio+136/336] recalc_task_prio+0x88/0x150 Oct 28 10:36:40 localhost kernel:  [activate_task+98/128] activate_task+0x62/0x80 Oct 28 10:36:40 localhost kernel:  [preempt_schedule+73/112] preempt_schedule+0x49/0x70 Oct 28 10:36:40 localhost kernel:  [md_thread+373/384] md_thread+0x175/0x180 Oct 28 10:36:40 localhost kernel:  [schedule_tail+23/80] schedule_tail+0x17/0x50 Oct 28 10:36:40 localhost kernel:  [ret_from_fork+6/28] ret_from_fork+0x6/0x1c Oct 28 10:36:40 localhost k...

Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've tried to implement new NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is defined, it is easy to maintain. At this moment, I

Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've tried to implement new NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is defined, it is easy to maintain. At this moment, I

...0>] ? common_interrupt+0x30/0x40 [<c01300e0>] ? load_balance+0x550/0x7d0 [<c0431614>] ? _raw_spin_unlock_irq+0x4/0x20 [<c012d9ba>] ? finish_task_switch+0x3a/0x90 [<c042f5c9>] ? schedule+0x1c9/0x520 [<c0103d30>] ? common_interrupt+0x30/0x40 [<c042facf>] ? preempt_schedule+0x2f/0x50 [<c0198a60>] ? do_wp_page+0x160/0x960 [<c0199c02>] ? handle_mm_fault+0x5d2/0xaa0 [<c01244b0>] ? do_page_fault+0x0/0x370 [<c01245f0>] ? do_page_fault+0x140/0x370 [<c01b7b2f>] ? copy_strings+0x17f/0x1a0 [<c01b935e>] ? do_execve+0x2be/0x310 [<c01...

...tion - */ - .popsection diff --git a/kernel/kprobes.c b/kernel/kprobes.c index a0d367a..ec0dbc7 100644 --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -96,9 +96,6 @@ static raw_spinlock_t *kretprobe_table_lock_ptr(unsigned long hash) static struct kprobe_blackpoint kprobe_blacklist[] = { {"preempt_schedule",}, {"native_get_debugreg",}, - {"irq_entries_start",}, - {"common_interrupt",}, - {"mcount",}, /* mcount can be called from everywhere */ {NULL} /* Terminator */ }; @@ -1328,8 +1325,11 @@ static int __kprobes in_kprobes_functions(unsigned long...

...? free_zspage+0xe8/0xe8 [zsmalloc] [ 340.320012] [<ffffffff810d58d1>] ? finish_task_switch+0x3de/0x484 [ 340.320015] [<ffffffff810d58a6>] ? finish_task_switch+0x3b3/0x484 [ 340.320021] [<ffffffff81d27ad5>] ? __schedule+0xa4d/0xd16 [ 340.320024] [<ffffffff81d28086>] ? preempt_schedule+0x1f/0x21 [ 340.320028] [<ffffffff81d27ff9>] ? preempt_schedule_common+0xb7/0xe8 [ 340.320034] [<ffffffffa02d3f0e>] zram_free_page+0x112/0x1f6 [zram] [ 340.320039] [<ffffffffa02d5e6c>] zram_make_request+0x45d/0x89f [zram] [ 340.320045] [<ffffffffa02d5a0f>] ? zram_rw_...

With the ATI bug I was hitting earlier fixed, only my btrfs partition continues to show high cpu usage for some operations. Rsync, git pull, git checkout and svn up are typicall operations which trigger the high cpu usage. As an example, this perf report is from using git checkout to change to a new branch; the change needed to checkout 208 files out of about 1600 total files. du(1) reports

Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've tried to implement new NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is defined, it is easy to maintain. This series

Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've tried to implement new NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is defined, it is easy to maintain. This series

Hi, Here is the version 3 of NOKPORBE_SYMBOL series. Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've introduced NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is defined

Hi, Here is the version 3 of NOKPORBE_SYMBOL series. Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've introduced NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is defined

On Tue, Aug 11, 2020 at 11:20:54AM +0200, peterz at infradead.org wrote: > On Tue, Aug 11, 2020 at 10:38:50AM +0200, J?rgen Gro? wrote: > > In case you don't want to do it I can send the patch for the Xen > > variants. > > I might've opened a whole new can of worms here. I'm not sure we > can/want to fix the entire fallout this release :/ > > Let me

On Tue, Aug 11, 2020 at 11:20:54AM +0200, peterz at infradead.org wrote: > On Tue, Aug 11, 2020 at 10:38:50AM +0200, J?rgen Gro? wrote: > > In case you don't want to do it I can send the patch for the Xen > > variants. > > I might've opened a whole new can of worms here. I'm not sure we > can/want to fix the entire fallout this release :/ > > Let me

...xe8 [zsmalloc] > [ 340.320012] [<ffffffff810d58d1>] ? finish_task_switch+0x3de/0x484 > [ 340.320015] [<ffffffff810d58a6>] ? finish_task_switch+0x3b3/0x484 > [ 340.320021] [<ffffffff81d27ad5>] ? __schedule+0xa4d/0xd16 > [ 340.320024] [<ffffffff81d28086>] ? preempt_schedule+0x1f/0x21 > [ 340.320028] [<ffffffff81d27ff9>] ? preempt_schedule_common+0xb7/0xe8 > [ 340.320034] [<ffffffffa02d3f0e>] zram_free_page+0x112/0x1f6 [zram] > [ 340.320039] [<ffffffffa02d5e6c>] zram_make_request+0x45d/0x89f [zram] > [ 340.320045] [<ffffffffa02d...

...xe8 [zsmalloc] > [ 340.320012] [<ffffffff810d58d1>] ? finish_task_switch+0x3de/0x484 > [ 340.320015] [<ffffffff810d58a6>] ? finish_task_switch+0x3b3/0x484 > [ 340.320021] [<ffffffff81d27ad5>] ? __schedule+0xa4d/0xd16 > [ 340.320024] [<ffffffff81d28086>] ? preempt_schedule+0x1f/0x21 > [ 340.320028] [<ffffffff81d27ff9>] ? preempt_schedule_common+0xb7/0xe8 > [ 340.320034] [<ffffffffa02d3f0e>] zram_free_page+0x112/0x1f6 [zram] > [ 340.320039] [<ffffffffa02d5e6c>] zram_make_request+0x45d/0x89f [zram] > [ 340.320045] [<ffffffffa02d...

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and easy fork fail. The problem was fragmentation caused by zram and GPU driver mainly. With memory pressure, their pages were spread out all of pageblock and it cannot be migrated with current compaction algorithm which supports only LRU pages. In the end, compaction cannot

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and easy fork fail. The problem was fragmentation caused by zram and GPU driver mainly. With memory pressure, their pages were spread out all of pageblock and it cannot be migrated with current compaction algorithm which supports only LRU pages. In the end, compaction cannot

...happens for both SMP and UP kernels (however, in different places). For the SMP kernel I saw a crash in "task_tick_fair", on the UP kernel in the arch code __switch_to somewhere around the unlazy_fpu() call (a bit confusing due to the heavy inlining). In yet another version I have "preempt_schedule" directly on the stack, it''s not clear where it crashes, since I don''t even get a kernel trace. Sometimes the crash would be due to a memory access into Nirvana land (while trying to get a per_cpu variable) and another time jumping to the null pointer. I have to say that ex...