On Wed, 6 Nov 2013 07:07:37 +0100
Ingo Molnar wrote:
> So until compilers get smarter (or there's some compiler trick I haven't
> noticed) lets stay with the separate section - it's not the end of the
> world, the (effective) 'noinline' aspect of noprobes changes code
> generation anyway.
>
* Masami Hiramatsu wrote:
> (2013/11/06 15:07), Ingo Molnar wrote:
> >
> > * Masami Hiramatsu wrote:
> >
> [...] I hope to build the list when the kernel build time if
> possible... Would you have any idea to classify some annotated(but no
> side-effect) functions?
> >>>
>
(2013/11/06 15:07), Ingo Molnar wrote:
>
> * Masami Hiramatsu wrote:
>
[...] I hope to build the list when the kernel build time if
possible... Would you have any idea to classify some annotated(but no
side-effect) functions?
>>>
>>> The macro magic I can think of would need to
(2013/11/06 15:07), Ingo Molnar wrote:
* Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
[...] I hope to build the list when the kernel build time if
possible... Would you have any idea to classify some annotated(but no
side-effect) functions?
The macro magic I can think of
* Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
(2013/11/06 15:07), Ingo Molnar wrote:
* Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
[...] I hope to build the list when the kernel build time if
possible... Would you have any idea to classify some annotated(but
On Wed, 6 Nov 2013 07:07:37 +0100
Ingo Molnar mi...@kernel.org wrote:
So until compilers get smarter (or there's some compiler trick I haven't
noticed) lets stay with the separate section - it's not the end of the
world, the (effective) 'noinline' aspect of noprobes changes code
* Masami Hiramatsu wrote:
> >> [...] I hope to build the list when the kernel build time if
> >> possible... Would you have any idea to classify some annotated(but no
> >> side-effect) functions?
> >
> > The macro magic I can think of would need to change the syntax of the
> > function
On Tue, 5 Nov 2013 08:05:37 +0100
Ingo Molnar wrote:
> The macro magic I can think of would need to change the syntax of the
> function definition - for example that is how the SYSCALL_DEFINE*() macros
> work.
Or something like the EXPORT_SYMBOL(), but that wouldn't include the
size of the
(2013/11/05 20:38), Masami Hiramatsu wrote:
> (2013/11/05 16:05), Ingo Molnar wrote:
>>
>> * Masami Hiramatsu wrote:
>>
>>> (2013/11/05 15:09), Ingo Molnar wrote:
* Steven Rostedt wrote:
> On Fri, 01 Nov 2013 11:25:37 +
> Masami Hiramatsu wrote:
>
>> Prohibit
(2013/11/05 16:05), Ingo Molnar wrote:
>
> * Masami Hiramatsu wrote:
>
>> (2013/11/05 15:09), Ingo Molnar wrote:
>>>
>>> * Steven Rostedt wrote:
>>>
On Fri, 01 Nov 2013 11:25:37 +
Masami Hiramatsu wrote:
> Prohibit probing on func_ptr_is_kernel_text().
> Since the
(2013/11/05 16:05), Ingo Molnar wrote:
* Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
(2013/11/05 15:09), Ingo Molnar wrote:
* Steven Rostedt rost...@goodmis.org wrote:
On Fri, 01 Nov 2013 11:25:37 +
Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
Prohibit
(2013/11/05 20:38), Masami Hiramatsu wrote:
(2013/11/05 16:05), Ingo Molnar wrote:
* Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
(2013/11/05 15:09), Ingo Molnar wrote:
* Steven Rostedt rost...@goodmis.org wrote:
On Fri, 01 Nov 2013 11:25:37 +
Masami Hiramatsu
On Tue, 5 Nov 2013 08:05:37 +0100
Ingo Molnar mi...@kernel.org wrote:
The macro magic I can think of would need to change the syntax of the
function definition - for example that is how the SYSCALL_DEFINE*() macros
work.
Or something like the EXPORT_SYMBOL(), but that wouldn't include the
* Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
[...] I hope to build the list when the kernel build time if
possible... Would you have any idea to classify some annotated(but no
side-effect) functions?
The macro magic I can think of would need to change the syntax of the
* Masami Hiramatsu wrote:
> (2013/11/05 15:09), Ingo Molnar wrote:
> >
> > * Steven Rostedt wrote:
> >
> >> On Fri, 01 Nov 2013 11:25:37 +
> >> Masami Hiramatsu wrote:
> >>
> >>> Prohibit probing on func_ptr_is_kernel_text().
> >>> Since the func_ptr_is_kernel_text() is called from
>
(2013/11/05 15:09), Ingo Molnar wrote:
>
> * Steven Rostedt wrote:
>
>> On Fri, 01 Nov 2013 11:25:37 +
>> Masami Hiramatsu wrote:
>>
>>> Prohibit probing on func_ptr_is_kernel_text().
>>> Since the func_ptr_is_kernel_text() is called from
>>> notifier_call_chain() which is called from int3
* Steven Rostedt wrote:
> On Fri, 01 Nov 2013 11:25:37 +
> Masami Hiramatsu wrote:
>
> > Prohibit probing on func_ptr_is_kernel_text().
> > Since the func_ptr_is_kernel_text() is called from
> > notifier_call_chain() which is called from int3 handler,
> > probing it may cause double int3
(2013/11/05 11:00), Steven Rostedt wrote:
> On Fri, 01 Nov 2013 11:25:37 +
> Masami Hiramatsu wrote:
>
>> Prohibit probing on func_ptr_is_kernel_text().
>> Since the func_ptr_is_kernel_text() is called from
>> notifier_call_chain() which is called from int3 handler,
>> probing it may cause
On Fri, 01 Nov 2013 11:25:37 +
Masami Hiramatsu wrote:
> Prohibit probing on func_ptr_is_kernel_text().
> Since the func_ptr_is_kernel_text() is called from
> notifier_call_chain() which is called from int3 handler,
> probing it may cause double int3 fault and kernel will
> reboot.
>
> This
On Fri, 01 Nov 2013 11:25:37 +
Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
Prohibit probing on func_ptr_is_kernel_text().
Since the func_ptr_is_kernel_text() is called from
notifier_call_chain() which is called from int3 handler,
probing it may cause double int3 fault and
(2013/11/05 11:00), Steven Rostedt wrote:
On Fri, 01 Nov 2013 11:25:37 +
Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
Prohibit probing on func_ptr_is_kernel_text().
Since the func_ptr_is_kernel_text() is called from
notifier_call_chain() which is called from int3 handler,
* Steven Rostedt rost...@goodmis.org wrote:
On Fri, 01 Nov 2013 11:25:37 +
Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
Prohibit probing on func_ptr_is_kernel_text().
Since the func_ptr_is_kernel_text() is called from
notifier_call_chain() which is called from int3
(2013/11/05 15:09), Ingo Molnar wrote:
* Steven Rostedt rost...@goodmis.org wrote:
On Fri, 01 Nov 2013 11:25:37 +
Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
Prohibit probing on func_ptr_is_kernel_text().
Since the func_ptr_is_kernel_text() is called from
* Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
(2013/11/05 15:09), Ingo Molnar wrote:
* Steven Rostedt rost...@goodmis.org wrote:
On Fri, 01 Nov 2013 11:25:37 +
Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
Prohibit probing on func_ptr_is_kernel_text().
On Fri, 01 Nov 2013 11:25:37 +
Masami Hiramatsu wrote:
> Prohibit probing on func_ptr_is_kernel_text().
> Since the func_ptr_is_kernel_text() is called from
> notifier_call_chain() which is called from int3 handler,
> probing it may cause double int3 fault and kernel will
> reboot.
>
> This
Prohibit probing on func_ptr_is_kernel_text().
Since the func_ptr_is_kernel_text() is called from
notifier_call_chain() which is called from int3 handler,
probing it may cause double int3 fault and kernel will
reboot.
This happenes when the kernel built with CONFIG_DEBUG_NOTIFIERS=y.
Prohibit probing on func_ptr_is_kernel_text().
Since the func_ptr_is_kernel_text() is called from
notifier_call_chain() which is called from int3 handler,
probing it may cause double int3 fault and kernel will
reboot.
This happenes when the kernel built with CONFIG_DEBUG_NOTIFIERS=y.
On Fri, 01 Nov 2013 11:25:37 +
Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
Prohibit probing on func_ptr_is_kernel_text().
Since the func_ptr_is_kernel_text() is called from
notifier_call_chain() which is called from int3 handler,
probing it may cause double int3 fault and
28 matches
Mail list logo
