On 07/04, Masami Hiramatsu wrote:
>
> (2014/07/04 2:01), Oleg Nesterov wrote:
> > On 07/03, Oleg Nesterov wrote:
> >>
> >> Hmm. Off-topic, but it seems that instance_rmdir() leaks the memory? Say,
> >> file->filter?
> >
> > Perhaps I am totally confused, but don't we need something like the patch
>
Hi Masami,
On Fri, 04 Jul 2014 10:00:51 +0900, Masami Hiramatsu wrote:
> (2014/07/03 16:44), Namhyung Kim wrote:
>> Hi Masami,
>>
>> On Thu, 03 Jul 2014 14:46:09 +0900, Masami Hiramatsu wrote:
>>> One possible scenario is here; someone disables an event and tries to remove
>>> it (both will be do
(2014/07/04 2:01), Oleg Nesterov wrote:
> On 07/03, Oleg Nesterov wrote:
>>
>> Hmm. Off-topic, but it seems that instance_rmdir() leaks the memory? Say,
>> file->filter?
>
> Perhaps I am totally confused, but don't we need something like the patch
> below? I'll try to recheck later...
>
> Better
(2014/07/04 1:22), Oleg Nesterov wrote:
>> One possible scenario is here; someone disables an event and tries to remove
>> it (both will be done by different syscalls). If we don't synchronize
>> the first disabling, the event flag set disabled, but the event itself
>> is not disabled. Thus event
(2014/07/03 16:44), Namhyung Kim wrote:
> Hi Masami,
>
> On Thu, 03 Jul 2014 14:46:09 +0900, Masami Hiramatsu wrote:
>> One possible scenario is here; someone disables an event and tries to remove
>> it (both will be done by different syscalls). If we don't synchronize
>> the first disabling, the
On 07/03, Oleg Nesterov wrote:
>
> Hmm. Off-topic, but it seems that instance_rmdir() leaks the memory? Say,
> file->filter?
Perhaps I am totally confused, but don't we need something like the patch
below? I'll try to recheck later...
Better yet, we can probably move destroy_preds() from event_re
On 07/03, Masami Hiramatsu wrote:
>
> (2014/07/02 4:31), Oleg Nesterov wrote:
> > And. I am puzzled by probe_event_disable()->synchronize_sched(). Why
> > do we need it? I mean, why we can't use call_rcu() ? The comment says
> > "synchronize with u{,ret}pro
On 07/03, Namhyung Kim wrote:
>
> On Tue, 1 Jul 2014 21:31:47 +0200, Oleg Nesterov wrote:
> >
> > And. I am puzzled by probe_event_disable()->synchronize_sched(). Why
> > do we need it? I mean, why we can't use call_rcu() ? The comment says
> > "synch
Hi Masami,
On Thu, 03 Jul 2014 14:46:09 +0900, Masami Hiramatsu wrote:
> One possible scenario is here; someone disables an event and tries to remove
> it (both will be done by different syscalls). If we don't synchronize
> the first disabling, the event flag set disabled, but the event itself
> i
; clear it if _register() fails. And uprobe_dispatcher() is very ugly if
> is_ret_probe(). And more. So it needs a series.
>
> -----
> And. I am puzzled by probe_event_disable()->synchronize_sched(). Why
> do we need it? I mean, why we can't use call_rcu() ? The comment says
> "syn
; clear it if _register() fails. And uprobe_dispatcher() is very ugly if
> is_ret_probe(). And more. So it needs a series.
>
> -----
> And. I am puzzled by probe_event_disable()->synchronize_sched(). Why
> do we need it? I mean, why we can't use call_rcu() ? The comment says
> "syn
and then
> clear it if _register() fails. And uprobe_dispatcher() is very ugly if
> is_ret_probe(). And more. So it needs a series.
Okay, I'd like to see it. :)
>
> -
> And. I am puzzled by pro
on
to carefully set (say) TP_FLAG_TRACE before uprobe_register() and then
clear it if _register() fails. And uprobe_dispatcher() is very ugly if
is_ret_probe(). And more. So it needs a series.
-----
And. I am puzzled by probe_event_disable()-&
13 matches
Mail list logo
