Hi Ingo,
(2013/12/13 14:34), Masami Hiramatsu wrote:
> And also, even if we can detect the recursion, we can't stop the
> kernel, we need to skip the probe. This means that we need to
> recover to the main execution path by doing single step. As you
> may know, since the single
Hi Ingo,
(2013/12/13 14:34), Masami Hiramatsu wrote:
And also, even if we can detect the recursion, we can't stop the
kernel, we need to skip the probe. This means that we need to
recover to the main execution path by doing single step. As you
may know, since the single stepping involves
(2013/12/13 14:34), Masami Hiramatsu wrote:
>> Lets assume we allow a probe to be inserted in the single-step path.
>> Such a probe will be an INT3 instruction and if it hits we get a
>> recursive INT3 invocation. In that case the INT3 handler should simply
>> restore the original instruction
(2013/12/12 23:03), Ingo Molnar wrote:
>
> * Masami Hiramatsu wrote:
>
>> (2013/12/11 22:34), Ingo Molnar wrote:
>>>
>>> * Masami Hiramatsu wrote:
>>>
> So why are annotations needed at all? What can happen if an
> annotation is missing and a piece of code is probed which is also
On 12/12/2013 06:03 AM, Ingo Molnar wrote:
>> No, because the int3 already changes the original instruction.
>> This means that you cannot skip singlestep(or emulate) the
>> instruction which is copied to execution buffer (ainsn->insn),
>> even if you have such the flag.
>> So, kprobe requires the
* Masami Hiramatsu wrote:
> (2013/12/11 22:34), Ingo Molnar wrote:
> >
> > * Masami Hiramatsu wrote:
> >
> >>> So why are annotations needed at all? What can happen if an
> >>> annotation is missing and a piece of code is probed which is also
> >>> used by the kprobes code internally - do
* Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
(2013/12/11 22:34), Ingo Molnar wrote:
* Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
So why are annotations needed at all? What can happen if an
annotation is missing and a piece of code is probed which is also
On 12/12/2013 06:03 AM, Ingo Molnar wrote:
No, because the int3 already changes the original instruction.
This means that you cannot skip singlestep(or emulate) the
instruction which is copied to execution buffer (ainsn-insn),
even if you have such the flag.
So, kprobe requires the
(2013/12/12 23:03), Ingo Molnar wrote:
* Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
(2013/12/11 22:34), Ingo Molnar wrote:
* Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
So why are annotations needed at all? What can happen if an
annotation is missing and a
(2013/12/13 14:34), Masami Hiramatsu wrote:
Lets assume we allow a probe to be inserted in the single-step path.
Such a probe will be an INT3 instruction and if it hits we get a
recursive INT3 invocation. In that case the INT3 handler should simply
restore the original instruction and _leave
(2013/12/11 22:34), Ingo Molnar wrote:
>
> * Masami Hiramatsu wrote:
>
>>> So why are annotations needed at all? What can happen if an
>>> annotation is missing and a piece of code is probed which is also
>>> used by the kprobes code internally - do we crash, lock up,
>>> misbehave or handle
* Masami Hiramatsu wrote:
> > So why are annotations needed at all? What can happen if an
> > annotation is missing and a piece of code is probed which is also
> > used by the kprobes code internally - do we crash, lock up,
> > misbehave or handle it safely?
>
> The kprobe has recursion
* Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
So why are annotations needed at all? What can happen if an
annotation is missing and a piece of code is probed which is also
used by the kprobes code internally - do we crash, lock up,
misbehave or handle it safely?
The
(2013/12/11 22:34), Ingo Molnar wrote:
* Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
So why are annotations needed at all? What can happen if an
annotation is missing and a piece of code is probed which is also
used by the kprobes code internally - do we crash, lock up,
(2013/12/11 0:28), Ingo Molnar wrote:
>
> * Masami Hiramatsu wrote:
>
>> (2013/12/05 19:21), Ingo Molnar wrote:
>>>
>>> * Masami Hiramatsu wrote:
>>>
> So we need both a maintainable and a sane/safe solution, and I'd
> like to apply the whole thing at once and be at ease that the
* Masami Hiramatsu wrote:
> (2013/12/05 19:21), Ingo Molnar wrote:
> >
> > * Masami Hiramatsu wrote:
> >
> >>> So we need both a maintainable and a sane/safe solution, and I'd
> >>> like to apply the whole thing at once and be at ease that the
> >>> solution is round. We should have done
(2013/12/11 0:28), Ingo Molnar wrote:
* Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
(2013/12/05 19:21), Ingo Molnar wrote:
* Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
So we need both a maintainable and a sane/safe solution, and I'd
like to apply the whole
* Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
(2013/12/05 19:21), Ingo Molnar wrote:
* Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
So we need both a maintainable and a sane/safe solution, and I'd
like to apply the whole thing at once and be at ease that the
(2013/12/07 10:32), Frank Ch. Eigler wrote:
> Hi -
>
> On Sat, Dec 07, 2013 at 08:19:13AM +0900, Masami Hiramatsu wrote:
>
>> [...]
>>> Would you plan to limit kprobes (or just the perf-probe frontend) to
>>> only function-entries also?
>
>> Exactly, yes :). Currently I have a patch for
Hi -
On Sat, Dec 07, 2013 at 08:19:13AM +0900, Masami Hiramatsu wrote:
> [...]
> > Would you plan to limit kprobes (or just the perf-probe frontend) to
> > only function-entries also?
> Exactly, yes :). Currently I have a patch for kprobe-tracer
> implementation (not only for perf-probe, but
(2013/12/07 4:07), Frank Ch. Eigler wrote:
> Hi, Masami -
>
> masami.hiramatsu.pt wrote:
>
>> [...]
[...] Then, I'd like to propose this new whitelist feature in
kprobe-tracer (not raw kprobe itself). And a sysctl knob for
disabling the whitelist. That knob will be
(2013/12/06 15:54), Sandeepa Prabhu wrote:
>>> I am not sure if this question is related, uprobes or ftrace code does
>>> not define __kprobes, so is it safe to place kprobe on uprobes or
>>> ftrace code?
>>
>> Yes, it is "safe" in qualitative meaning. But for ftrace code, it could
>> give a
Hi, Masami -
masami.hiramatsu.pt wrote:
> [...]
> >> [...] Then, I'd like to propose this new whitelist feature in
> >> kprobe-tracer (not raw kprobe itself). And a sysctl knob for
> >> disabling the whitelist. That knob will be
> >> /proc/sys/debug/kprobe-event-whitelist and disabling it will
Hi, Masami -
masami.hiramatsu.pt wrote:
[...]
[...] Then, I'd like to propose this new whitelist feature in
kprobe-tracer (not raw kprobe itself). And a sysctl knob for
disabling the whitelist. That knob will be
/proc/sys/debug/kprobe-event-whitelist and disabling it will mark
(2013/12/06 15:54), Sandeepa Prabhu wrote:
I am not sure if this question is related, uprobes or ftrace code does
not define __kprobes, so is it safe to place kprobe on uprobes or
ftrace code?
Yes, it is safe in qualitative meaning. But for ftrace code, it could
give a performance impact by
(2013/12/07 4:07), Frank Ch. Eigler wrote:
Hi, Masami -
masami.hiramatsu.pt wrote:
[...]
[...] Then, I'd like to propose this new whitelist feature in
kprobe-tracer (not raw kprobe itself). And a sysctl knob for
disabling the whitelist. That knob will be
Hi -
On Sat, Dec 07, 2013 at 08:19:13AM +0900, Masami Hiramatsu wrote:
[...]
Would you plan to limit kprobes (or just the perf-probe frontend) to
only function-entries also?
Exactly, yes :). Currently I have a patch for kprobe-tracer
implementation (not only for perf-probe, but doesn't
(2013/12/07 10:32), Frank Ch. Eigler wrote:
Hi -
On Sat, Dec 07, 2013 at 08:19:13AM +0900, Masami Hiramatsu wrote:
[...]
Would you plan to limit kprobes (or just the perf-probe frontend) to
only function-entries also?
Exactly, yes :). Currently I have a patch for kprobe-tracer
>> I am not sure if this question is related, uprobes or ftrace code does
>> not define __kprobes, so is it safe to place kprobe on uprobes or
>> ftrace code?
>
> Yes, it is "safe" in qualitative meaning. But for ftrace code, it could
> give a performance impact by miss-hitting. Since uprobe is
(2013/12/05 22:08), Sandeepa Prabhu wrote:
>> OK, I think the kprobe is like a strong medicine, not a toy,
>> since it can intercept most of the kernel functions which
>> may process a sensitive user private data. Thus even if we
>> fix all bugs and make it safe, I don't think we can open
>> it
(2013/12/05 23:49), Frank Ch. Eigler wrote:
>
> Hi, Masami -
>
> masami.hiramatsu.pt wrote:
>
>> [...]
>> For the safeness of kprobes, I have an idea; introduce a whitelist
>> for dynamic events. AFAICS, the biggest unstable issue of kprobes
>> comes from putting *many* probes on the functions
(2013/12/05 19:21), Ingo Molnar wrote:
>
> * Masami Hiramatsu wrote:
>
>>> So we need both a maintainable and a sane/safe solution, and I'd
>>> like to apply the whole thing at once and be at ease that the
>>> solution is round. We should have done this years ago.
>>
>> For the safeness of
Hi, Masami -
masami.hiramatsu.pt wrote:
> [...]
> For the safeness of kprobes, I have an idea; introduce a whitelist
> for dynamic events. AFAICS, the biggest unstable issue of kprobes
> comes from putting *many* probes on the functions called from tracers.
Why do you think so? We have had
> OK, I think the kprobe is like a strong medicine, not a toy,
> since it can intercept most of the kernel functions which
> may process a sensitive user private data. Thus even if we
> fix all bugs and make it safe, I don't think we can open
> it for all users (of course, there should be a knob
* Masami Hiramatsu wrote:
> > So we need both a maintainable and a sane/safe solution, and I'd
> > like to apply the whole thing at once and be at ease that the
> > solution is round. We should have done this years ago.
>
> For the safeness of kprobes, I have an idea; introduce a whitelist
* Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
So we need both a maintainable and a sane/safe solution, and I'd
like to apply the whole thing at once and be at ease that the
solution is round. We should have done this years ago.
For the safeness of kprobes, I have an idea;
OK, I think the kprobe is like a strong medicine, not a toy,
since it can intercept most of the kernel functions which
may process a sensitive user private data. Thus even if we
fix all bugs and make it safe, I don't think we can open
it for all users (of course, there should be a knob to
Hi, Masami -
masami.hiramatsu.pt wrote:
[...]
For the safeness of kprobes, I have an idea; introduce a whitelist
for dynamic events. AFAICS, the biggest unstable issue of kprobes
comes from putting *many* probes on the functions called from tracers.
Why do you think so? We have had
(2013/12/05 19:21), Ingo Molnar wrote:
* Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
So we need both a maintainable and a sane/safe solution, and I'd
like to apply the whole thing at once and be at ease that the
solution is round. We should have done this years ago.
For the
(2013/12/05 23:49), Frank Ch. Eigler wrote:
Hi, Masami -
masami.hiramatsu.pt wrote:
[...]
For the safeness of kprobes, I have an idea; introduce a whitelist
for dynamic events. AFAICS, the biggest unstable issue of kprobes
comes from putting *many* probes on the functions called from
(2013/12/05 22:08), Sandeepa Prabhu wrote:
OK, I think the kprobe is like a strong medicine, not a toy,
since it can intercept most of the kernel functions which
may process a sensitive user private data. Thus even if we
fix all bugs and make it safe, I don't think we can open
it for all
I am not sure if this question is related, uprobes or ftrace code does
not define __kprobes, so is it safe to place kprobe on uprobes or
ftrace code?
Yes, it is safe in qualitative meaning. But for ftrace code, it could
give a performance impact by miss-hitting. Since uprobe is independent
(2013/12/04 17:46), Sandeepa Prabhu wrote:
> On 4 December 2013 13:09, Masami Hiramatsu
> wrote:
>> (2013/12/04 11:54), Sandeepa Prabhu wrote:
>>> On 4 December 2013 06:58, Masami Hiramatsu
>>> wrote:
Hi,
Here is the version 4 of NOKPORBE_SYMBOL series.
In this version, I
(2013/12/04 17:45), Ingo Molnar wrote:
>
> * Masami Hiramatsu wrote:
>
>> Hi,
>> Here is the version 4 of NOKPORBE_SYMBOL series.
>>
>> In this version, I removed the cleanup patches and
>> add bugfixes I've found, since those bugs will be
>> critical.
>>
>> Rest of the cleanup and visible
On 4 December 2013 13:09, Masami Hiramatsu
wrote:
> (2013/12/04 11:54), Sandeepa Prabhu wrote:
>> On 4 December 2013 06:58, Masami Hiramatsu
>> wrote:
>>> Hi,
>>> Here is the version 4 of NOKPORBE_SYMBOL series.
>>>
>>> In this version, I removed the cleanup patches and
>>> add bugfixes I've
* Masami Hiramatsu wrote:
> Hi,
> Here is the version 4 of NOKPORBE_SYMBOL series.
>
> In this version, I removed the cleanup patches and
> add bugfixes I've found, since those bugs will be
> critical.
>
> Rest of the cleanup and visible blacklists will be proposed later in
> another series.
On 4 December 2013 13:09, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
(2013/12/04 11:54), Sandeepa Prabhu wrote:
On 4 December 2013 06:58, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
Hi,
Here is the version 4 of NOKPORBE_SYMBOL series.
In this version, I removed the
* Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
Hi,
Here is the version 4 of NOKPORBE_SYMBOL series.
In this version, I removed the cleanup patches and
add bugfixes I've found, since those bugs will be
critical.
Rest of the cleanup and visible blacklists will be proposed later
(2013/12/04 17:45), Ingo Molnar wrote:
* Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
Hi,
Here is the version 4 of NOKPORBE_SYMBOL series.
In this version, I removed the cleanup patches and
add bugfixes I've found, since those bugs will be
critical.
Rest of the cleanup and
(2013/12/04 17:46), Sandeepa Prabhu wrote:
On 4 December 2013 13:09, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
(2013/12/04 11:54), Sandeepa Prabhu wrote:
On 4 December 2013 06:58, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
Hi,
Here is the version 4 of
(2013/12/04 11:54), Sandeepa Prabhu wrote:
> On 4 December 2013 06:58, Masami Hiramatsu
> wrote:
>> Hi,
>> Here is the version 4 of NOKPORBE_SYMBOL series.
>>
>> In this version, I removed the cleanup patches and
>> add bugfixes I've found, since those bugs will be
>> critical.
>> Rest of the
On 4 December 2013 06:58, Masami Hiramatsu
wrote:
> Hi,
> Here is the version 4 of NOKPORBE_SYMBOL series.
>
> In this version, I removed the cleanup patches and
> add bugfixes I've found, since those bugs will be
> critical.
> Rest of the cleanup and visible blacklists will be
> proposed later
Hi,
Here is the version 4 of NOKPORBE_SYMBOL series.
In this version, I removed the cleanup patches and
add bugfixes I've found, since those bugs will be
critical.
Rest of the cleanup and visible blacklists will be
proposed later in another series.
Oh, just one new thing, I added a new RFC patch
Hi,
Here is the version 4 of NOKPORBE_SYMBOL series.
In this version, I removed the cleanup patches and
add bugfixes I've found, since those bugs will be
critical.
Rest of the cleanup and visible blacklists will be
proposed later in another series.
Oh, just one new thing, I added a new RFC patch
On 4 December 2013 06:58, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
Hi,
Here is the version 4 of NOKPORBE_SYMBOL series.
In this version, I removed the cleanup patches and
add bugfixes I've found, since those bugs will be
critical.
Rest of the cleanup and visible blacklists
(2013/12/04 11:54), Sandeepa Prabhu wrote:
On 4 December 2013 06:58, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
Hi,
Here is the version 4 of NOKPORBE_SYMBOL series.
In this version, I removed the cleanup patches and
add bugfixes I've found, since those bugs will be
critical.
56 matches
Mail list logo
