This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [Patch 2/5][Djprobe]Djprobe Coexist with Kprobes
On Wed, Oct 19, 2005 at 10:30:04PM +0900, Masami Hiramatsu wrote:
> Hi, Anil
>
> >
> > How about calling flush_scheduled_work(). Will this work?
> >
>
> I think it will work. And I wrote it as a pseudo-code here.
> Does this fit your idea?
Perfect, and the code looks lot simpler now and cpu hotplug safe too, :-)
>
> ---
> register_djprobe()
> {
> down(&djprobe_mutex); /* avoid deadlock */
>
> instance = create_instance();
> register_kprobe(&instance->kp);
>
> /* schedule check routine */
> for_each_other_cpu()
> schedule_work(per_cpu_works);
> flush_scheduled_work(); /* might sleep */
>
> arch_install_instance(instance);
>
> up(&djprobe_mutex);
> }
>
> unregister_djprobe()
> {
> down(&djprobe_mutex); /* avoid deadlock */
>
> arch_uninstall_instance(instance);
>
> /* schedule check routine */
> for_each_other_cpu()
> schedule_work(per_cpu_works);
> flush_scheduled_work(); /* might sleep */
>
> unregister_kprobe(&instance->kp);
> release_instance(instance);
>
> up(&djprobe_mutex);
> }
> ---
>
> Of course, this code would not block other processes, and not
> allocate any temporary works.
Exactly.
> But, if we use flush_scheduled_work(), register/unregister_djprobe()
> might sleep. In other words, those functions are no longer atomic.
Even though it is not automic, the above calls are synchronous i.e
when register/unregister_djprobe() returns the probes are enabled / disabled.
> So, it would take a long time to register/unregister some probes
> at a time.
> I'm concerned about this point. What do you think about that?
This issue can be addressed with providing register/unregister_bulk_djprobe(),
I think. so with this api, we can actually register/unregister multiple djprobes with
just one flush_scheduled_work().
cheers,
Anil