On Sun, 21 Jul 2013, H. Peter Anvin wrote:
> Honestly, why don't we make the patch list (rbtree, whatever) a
> permanent part of the default breakpoint handler. It only applies to
> kernel space anyway and the kernel doesn't have any permanent
> breakpoints so there should be no performance re
Hi Jiri,
> What I am however wondering whether can't be case here is that the jump
> label was used before int3_notifier has been registered.
> I am thinking about ways around this, but we'll probably have to do the
> same ftrace is doing, i.e. hook into do_int3() directly instead of relying
>
Honestly, why don't we make the patch list (rbtree, whatever) a permanent part
of the default breakpoint handler. It only applies to kernel space anyway and
the kernel doesn't have any permanent breakpoints so there should be no
performance reason not to.
Jiri Kosina wrote:
>On Sat, 20 Jul 20
Hi Jiri,
> Fengguang, as I am not able to reproduce this bug locally, could you do me
> a favor and test whether the patch below works the problem around, just
> for the sake of testing the hypothesis?
Sure. I just created a branch with this patch on top of the first bad
commit, and queued the
On Sat, 20 Jul 2013, H. Peter Anvin wrote:
> > [0.212429] devtmpfs: initialized
> > [0.236027] int3: [#1] PREEMPT SMP DEBUG_PAGEALLOC
> > [0.237157] Modules linked in:
> > [0.237765] CPU: 1 PID: 0 Comm: swapper/1 Not tainted
> > 3.11.0-rc1-01429-g04bf576 #8
> > [0.239129]
On 07/20/2013 06:12 AM, Fengguang Wu wrote:
> Greetings,
>
> I got the below dmesg and the first bad commit is
>
> commit 51b2c07b22261f19188d9a9071943d60a067481c
> Author: Jiri Kosina
> Date: Fri Jul 12 11:22:09 2013 +0200
>
> x86: Make jump_label use int3-based patching
>
> Mak
6 matches
Mail list logo
