On Thu, 25 May 2017 11:18:02 -0400
Steven Rostedt wrote:
> On Thu, 25 May 2017 19:34:43 +0900
> Masami Hiramatsu wrote:
>
>
> > OK, I've ensured that following command hits same BUG.
> >
> > grep t /proc/kallsyms | cut -f3 -d" " | grep -v .*\\..* |
On Thu, 25 May 2017 11:18:02 -0400
Steven Rostedt wrote:
> On Thu, 25 May 2017 19:34:43 +0900
> Masami Hiramatsu wrote:
>
>
> > OK, I've ensured that following command hits same BUG.
> >
> > grep t /proc/kallsyms | cut -f3 -d" " | grep -v .*\\..* | \
> > head -n 256 | while read i; do echo
On Thu, 25 May 2017 19:34:43 +0900
Masami Hiramatsu wrote:
> OK, I've ensured that following command hits same BUG.
>
> grep t /proc/kallsyms | cut -f3 -d" " | grep -v .*\\..* | \
> head -n 256 | while read i; do echo p $i+5 ; done >
> tracing/kprobe_events
>
> echo 1 >
On Thu, 25 May 2017 19:34:43 +0900
Masami Hiramatsu wrote:
> OK, I've ensured that following command hits same BUG.
>
> grep t /proc/kallsyms | cut -f3 -d" " | grep -v .*\\..* | \
> head -n 256 | while read i; do echo p $i+5 ; done >
> tracing/kprobe_events
>
> echo 1 >
On Thu, 25 May 2017 18:09:10 +0900
Masami Hiramatsu wrote:
> On Wed, 24 May 2017 18:25:47 -0400
> Steven Rostedt wrote:
>
> > On Wed, 24 May 2017 21:13:27 +0200 (CEST)
> > Thomas Gleixner wrote:
> >
> >
> > > > Oops: 0003 [#1]
On Thu, 25 May 2017 18:09:10 +0900
Masami Hiramatsu wrote:
> On Wed, 24 May 2017 18:25:47 -0400
> Steven Rostedt wrote:
>
> > On Wed, 24 May 2017 21:13:27 +0200 (CEST)
> > Thomas Gleixner wrote:
> >
> >
> > > > Oops: 0003 [#1] SMP
> > > > Modules linked in:
> > > > CPU: 3 PID: 1 Comm:
On Wed, 24 May 2017 18:25:47 -0400
Steven Rostedt wrote:
> On Wed, 24 May 2017 21:13:27 +0200 (CEST)
> Thomas Gleixner wrote:
>
>
> > > Oops: 0003 [#1] SMP
> > > Modules linked in:
> > > CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc2-test+ #42
>
On Wed, 24 May 2017 18:25:47 -0400
Steven Rostedt wrote:
> On Wed, 24 May 2017 21:13:27 +0200 (CEST)
> Thomas Gleixner wrote:
>
>
> > > Oops: 0003 [#1] SMP
> > > Modules linked in:
> > > CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc2-test+ #42
> > > Hardware name: MSI
On Wed, 24 May 2017, Steven Rostedt wrote:
> The trampolines uses the module allocation, and it appears, that needs
> to become rw before freeing again.
Indeed. I realized that when enabling more debug options, which led to a
reliable triple fault.
How intuitive.
> I applied this patch, and it
On Wed, 24 May 2017, Steven Rostedt wrote:
> The trampolines uses the module allocation, and it appears, that needs
> to become rw before freeing again.
Indeed. I realized that when enabling more debug options, which led to a
reliable triple fault.
How intuitive.
> I applied this patch, and it
On Wed, May 24, 2017 at 06:25:47PM -0400, Steven Rostedt wrote:
> On Wed, 24 May 2017 21:13:27 +0200 (CEST)
> Thomas Gleixner wrote:
>
>
> > > Oops: 0003 [#1] SMP
> > > Modules linked in:
> > > CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc2-test+ #42
> > > Hardware
On Wed, May 24, 2017 at 06:25:47PM -0400, Steven Rostedt wrote:
> On Wed, 24 May 2017 21:13:27 +0200 (CEST)
> Thomas Gleixner wrote:
>
>
> > > Oops: 0003 [#1] SMP
> > > Modules linked in:
> > > CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc2-test+ #42
> > > Hardware name: MSI
On Wed, 24 May 2017 21:13:27 +0200 (CEST)
Thomas Gleixner wrote:
> > Oops: 0003 [#1] SMP
> > Modules linked in:
> > CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc2-test+ #42
> > Hardware name: MSI MS-7823/CSM-H87M-G43 (MS-7823), BIOS V1.6
> > 02/22/2014 task:
On Wed, 24 May 2017 21:13:27 +0200 (CEST)
Thomas Gleixner wrote:
> > Oops: 0003 [#1] SMP
> > Modules linked in:
> > CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc2-test+ #42
> > Hardware name: MSI MS-7823/CSM-H87M-G43 (MS-7823), BIOS V1.6
> > 02/22/2014 task: 8802153a8000 task.stack:
On Wed, May 24, 2017 at 08:53:00PM +0200, Thomas Gleixner wrote:
> On Wed, 24 May 2017, Luis R. Rodriguez wrote:
> > [ 440.548057] CPU: 2 PID: 1765 Comm: ftracetest Tainted: GE
>
> 4.12.0-rc1-next-20170519+ #155
>
> Can you please try that patch against plain 4.12-rc2?
Yup, just
On Wed, May 24, 2017 at 08:53:00PM +0200, Thomas Gleixner wrote:
> On Wed, 24 May 2017, Luis R. Rodriguez wrote:
> > [ 440.548057] CPU: 2 PID: 1765 Comm: ftracetest Tainted: GE
>
> 4.12.0-rc1-next-20170519+ #155
>
> Can you please try that patch against plain 4.12-rc2?
Yup, just
On Wed, 24 May 2017, Steven Rostedt wrote:
> OK, it crashed on one of my tests. I removed the patch and it boots
> fine, and crashes when I add it back.
It reproduces here with your config.
> BUG: unable to handle kernel paging request at 880214f5c000
> IP: new_slab+0x1e8/0x2b4
> PGD
On Wed, 24 May 2017, Steven Rostedt wrote:
> OK, it crashed on one of my tests. I removed the patch and it boots
> fine, and crashes when I add it back.
It reproduces here with your config.
> BUG: unable to handle kernel paging request at 880214f5c000
> IP: new_slab+0x1e8/0x2b4
> PGD
On Wed, 24 May 2017, Luis R. Rodriguez wrote:
> [ 440.548057] CPU: 2 PID: 1765 Comm: ftracetest Tainted: GE
4.12.0-rc1-next-20170519+ #155
Can you please try that patch against plain 4.12-rc2?
Thanks,
tglx
On Wed, 24 May 2017, Luis R. Rodriguez wrote:
> [ 440.548057] CPU: 2 PID: 1765 Comm: ftracetest Tainted: GE
4.12.0-rc1-next-20170519+ #155
Can you please try that patch against plain 4.12-rc2?
Thanks,
tglx
On Wed, May 24, 2017 at 01:47:28PM -0400, Steven Rostedt wrote:
> OK, it crashed on one of my tests. I removed the patch and it boots
> fine, and crashes when I add it back.
>
> Here's the crash:
>
> Running tests on all trace events:
> Testing all events: OK
> Testing ftrace filter: OK
>
On Wed, May 24, 2017 at 01:47:28PM -0400, Steven Rostedt wrote:
> OK, it crashed on one of my tests. I removed the patch and it boots
> fine, and crashes when I add it back.
>
> Here's the crash:
>
> Running tests on all trace events:
> Testing all events: OK
> Testing ftrace filter: OK
>
OK, it crashed on one of my tests. I removed the patch and it boots
fine, and crashes when I add it back.
Here's the crash:
Running tests on all trace events:
Testing all events: OK
Testing ftrace filter: OK
trace_kprobe: Testing kprobe tracing:
BUG: unable to handle kernel paging request at
OK, it crashed on one of my tests. I removed the patch and it boots
fine, and crashes when I add it back.
Here's the crash:
Running tests on all trace events:
Testing all events: OK
Testing ftrace filter: OK
trace_kprobe: Testing kprobe tracing:
BUG: unable to handle kernel paging request at
On Wed, 24 May 2017 15:47:17 +0200 (CEST)
Thomas Gleixner wrote:
> ftrace uses module_alloc() to allocate trampoline pages. The mapping
> of module_alloc() is RWX, which makes sense as the memory is written
> to right after allocation. But nothing makes these pages RO after
>
On Wed, 24 May 2017 15:47:17 +0200 (CEST)
Thomas Gleixner wrote:
> ftrace uses module_alloc() to allocate trampoline pages. The mapping
> of module_alloc() is RWX, which makes sense as the memory is written
> to right after allocation. But nothing makes these pages RO after
> writing to them.
>
On Wed, 24 May 2017 15:47:17 +0200 (CEST)
Thomas Gleixner wrote:
> ftrace uses module_alloc() to allocate trampoline pages. The mapping of
> module_alloc() is RWX, which makes sense as the memory is written to right
> after allocation. But nothing makes these pages RO after
On Wed, 24 May 2017 15:47:17 +0200 (CEST)
Thomas Gleixner wrote:
> ftrace uses module_alloc() to allocate trampoline pages. The mapping of
> module_alloc() is RWX, which makes sense as the memory is written to right
> after allocation. But nothing makes these pages RO after writing to them.
>
>
ftrace uses module_alloc() to allocate trampoline pages. The mapping of
module_alloc() is RWX, which makes sense as the memory is written to right
after allocation. But nothing makes these pages RO after writing to them.
This problem exists since ftrace uses trampolines on x86, but it went
ftrace uses module_alloc() to allocate trampoline pages. The mapping of
module_alloc() is RWX, which makes sense as the memory is written to right
after allocation. But nothing makes these pages RO after writing to them.
This problem exists since ftrace uses trampolines on x86, but it went
30 matches
Mail list logo