Re: [Patch 2/5][Djprobe]Djprobe Coexist with Kprobes

[Keshavamurthy Anil S <anil dot s dot keshavamurthy at intel dot com>]

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