[PATCH] dccp_probe: Fix module load dependencies between dccp and

[PATCH] dccp_probe: Fix module load dependencies between dccp and

[Neil Horman]

Hey-
	This was just recently reported to me.  When built as modules,
the dccp_probe module has a silent dependency on the dccp module.  This stems
from the fact that the module_init routine of dccp_probe registers a jprobe on
the dccp_sendmsg symbol.  Since the symbol is only referenced as a text string
(the .symbol_name field in the jprobe struct) rather than the address of the
symbol itself, depmod never picks this dependency up, and so if you load the
dccp_probe module without the dccp module loaded, the register_jprobe call fails
with an -EINVAL, and the whole module load fails.

	The fix is pretty easy, we can just wrap the register_jprobe call in a
try_then_request_module call, which forces the dependency to get satisfied prior
to the probe registration.

	I've verified that this fixes the problem myself.

Regards
Neil

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>


 probe.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)


diff --git a/net/dccp/probe.c b/net/dccp/probe.c
index a1362dc..bace1d8 100644
--- a/net/dccp/probe.c
+++ b/net/dccp/probe.c
@@ -161,7 +161,8 @@ static __init int dccpprobe_init(void)
 	if (!proc_net_fops_create(&init_net, procname, S_IRUSR, &dccpprobe_fops))
 		goto err0;
 
-	ret = register_jprobe(&dccp_send_probe);
+	ret = try_then_request_module((register_jprobe(&dccp_send_probe) = 0),
+					"dccp");
 	if (ret)
 		goto err1;
 

Re: [PATCH] dccp_probe: Fix module load dependencies between dccp

[Arnaldo Carvalho de Melo]

Em Thu, Jan 14, 2010 at 03:15:17PM -0500, Neil Horman escreveu:
> Hey-
> 	This was just recently reported to me.  When built as modules,
> the dccp_probe module has a silent dependency on the dccp module.  This stems
> from the fact that the module_init routine of dccp_probe registers a jprobe on
> the dccp_sendmsg symbol.  Since the symbol is only referenced as a text string
> (the .symbol_name field in the jprobe struct) rather than the address of the
> symbol itself, depmod never picks this dependency up, and so if you load the
> dccp_probe module without the dccp module loaded, the register_jprobe call fails
> with an -EINVAL, and the whole module load fails.
> 
> 	The fix is pretty easy, we can just wrap the register_jprobe call in a
> try_then_request_module call, which forces the dependency to get satisfied prior
> to the probe registration.
> 
> 	I've verified that this fixes the problem myself.
> 
> Regards
> Neil
> 
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>

That is ok with me, thanks!

Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>

- Arnaldo

Re: [PATCH] dccp_probe: Fix module load dependencies between dccp

[David Miller]

From: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Date: Thu, 14 Jan 2010 18:17:43 -0200

> Em Thu, Jan 14, 2010 at 03:15:17PM -0500, Neil Horman escreveu:
>> Hey-
>> 	This was just recently reported to me.  When built as modules,
>> the dccp_probe module has a silent dependency on the dccp module.  This stems
>> from the fact that the module_init routine of dccp_probe registers a jprobe on
>> the dccp_sendmsg symbol.  Since the symbol is only referenced as a text string
>> (the .symbol_name field in the jprobe struct) rather than the address of the
>> symbol itself, depmod never picks this dependency up, and so if you load the
>> dccp_probe module without the dccp module loaded, the register_jprobe call fails
>> with an -EINVAL, and the whole module load fails.
>> 
>> 	The fix is pretty easy, we can just wrap the register_jprobe call in a
>> try_then_request_module call, which forces the dependency to get satisfied prior
>> to the probe registration.
>> 
>> 	I've verified that this fixes the problem myself.
>> 
>> Regards
>> Neil
>> 
>> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> 
> That is ok with me, thanks!
> 
> Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>

Applied.

Neil, always CC: netdev on networking patches, thanks.

Re: [PATCH] dccp_probe: Fix module load dependencies between dccp

[Neil Horman]

On Fri, Jan 15, 2010 at 01:41:10AM -0800, David Miller wrote:
> From: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
> Date: Thu, 14 Jan 2010 18:17:43 -0200
> 
> > Em Thu, Jan 14, 2010 at 03:15:17PM -0500, Neil Horman escreveu:
> >> Hey-
> >> 	This was just recently reported to me.  When built as modules,
> >> the dccp_probe module has a silent dependency on the dccp module.  This stems
> >> from the fact that the module_init routine of dccp_probe registers a jprobe on
> >> the dccp_sendmsg symbol.  Since the symbol is only referenced as a text string
> >> (the .symbol_name field in the jprobe struct) rather than the address of the
> >> symbol itself, depmod never picks this dependency up, and so if you load the
> >> dccp_probe module without the dccp module loaded, the register_jprobe call fails
> >> with an -EINVAL, and the whole module load fails.
> >> 
> >> 	The fix is pretty easy, we can just wrap the register_jprobe call in a
> >> try_then_request_module call, which forces the dependency to get satisfied prior
> >> to the probe registration.
> >> 
> >> 	I've verified that this fixes the problem myself.
> >> 
> >> Regards
> >> Neil
> >> 
> >> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> > 
> > That is ok with me, thanks!
> > 
> > Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> 
> Applied.
> 
> Neil, always CC: netdev on networking patches, thanks.
> 
Sorry, MAINTAINERS listed a separate list for dccp, I figured there was a
protocol sub-tree that acme kept.
Neil

Re: [PATCH] dccp_probe: Fix module load dependencies between dccp

[gerrit]

Hi Neil,

thank you for these patches, being on vacation it is probably to late for
Acked-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>

>> Neil, always CC: netdev on networking patches, thanks.
>>
> Sorry, MAINTAINERS listed a separate list for dccp, I figured there was a
> protocol sub-tree that acme kept.
Yes there is a separate tree [1], but by convention we always CC: to
netdev, since the latter at the moment is pretty low-volume, and also
sometimes problems (such as this one) are of wider interest.

Thanks again
Gerrit

[1]
http://www.linuxfoundation.org/collaborate/workgroups/networking/dccp_testing#Experimental_DCCP_source_tree