Re: [PATCH] kprobes: bugfix: try_module_get even if calling_mod is NULL

[Andrew Morton <akpm@linux-foundation.org>]

On Wed, 05 Nov 2008 19:06:57 -0500
Masami Hiramatsu <mhiramat@redhat.com> wrote:

> Get probed module even if the caller is in the kernel core code.
> 
> Signed-off-by: Masami Hiramatsu <mhiramat@redhat.com>
> ---
> 
> >> One question, off topic.
> >> If calling_mod is NULL, no try_module_get(), is that OK?
> >
> > Good question. Currently, kprobes is called only from kernel modules,
> > so calling_mod should be always !NULL.
> > However, it should be fixed, because the logic is not correct.
> 
> Thank you so much. So here is the additional bugfix patch.
> 
>  kernel/kprobes.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: 2.6.28-rc3/kernel/kprobes.c
> ===================================================================
> --- 2.6.28-rc3.orig/kernel/kprobes.c
> +++ 2.6.28-rc3/kernel/kprobes.c
> @@ -634,7 +634,7 @@ static int __kprobes __register_kprobe(s
>  		 * avoid incrementing the module refcount, so as to allow
>  		 * unloading of self probing modules.
>  		 */
> -		if (calling_mod && calling_mod != probed_mod) {
> +		if (calling_mod != probed_mod) {
>  			if (unlikely(!try_module_get(probed_mod))) {
>  				preempt_enable();
>  				return -EINVAL;
> 

I do not understand this description "Get probed module even if the
caller is in the kernel core code".

What bug is being fixed here?  What is the kernel behaviour before and
after the patch?

Was the bug present in 2.6.27, 2.6.26 etc?  Or was it a post-2.6.28
regression?