<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/net/dccp, branch linux-2.6.33.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>net: Compute protocol sequence numbers and fragment IDs using MD5.</title>
<updated>2011-08-16T02:01:54+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2011-08-04T03:50:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4f92dd0dba4a3000b7ce3a7dfbe2be1ffbeb2bd1'/>
<id>4f92dd0dba4a3000b7ce3a7dfbe2be1ffbeb2bd1</id>
<content type='text'>
Computers have become a lot faster since we compromised on the
partial MD4 hash which we use currently for performance reasons.

MD5 is a much safer choice, and is inline with both RFC1948 and
other ISS generators (OpenBSD, Solaris, etc.)

Furthermore, only having 24-bits of the sequence number be truly
unpredictable is a very serious limitation.  So the periodic
regeneration and 8-bit counter have been removed.  We compute and
use a full 32-bit sequence number.

For ipv6, DCCP was found to use a 32-bit truncated initial sequence
number (it needs 43-bits) and that is fixed here as well.

Reported-by: Dan Kaminsky &lt;dan@doxpara.com&gt;
Tested-by: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Computers have become a lot faster since we compromised on the
partial MD4 hash which we use currently for performance reasons.

MD5 is a much safer choice, and is inline with both RFC1948 and
other ISS generators (OpenBSD, Solaris, etc.)

Furthermore, only having 24-bits of the sequence number be truly
unpredictable is a very serious limitation.  So the periodic
regeneration and 8-bit counter have been removed.  We compute and
use a full 32-bit sequence number.

For ipv6, DCCP was found to use a 32-bit truncated initial sequence
number (it needs 43-bits) and that is fixed here as well.

Reported-by: Dan Kaminsky &lt;dan@doxpara.com&gt;
Tested-by: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>dccp: handle invalid feature options length</title>
<updated>2011-05-23T18:22:57+00:00</updated>
<author>
<name>Dan Rosenberg</name>
<email>drosenberg@vsecurity.com</email>
</author>
<published>2011-05-06T03:27:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a49a2ad3766809aa241b4fda9ff54baa70f54421'/>
<id>a49a2ad3766809aa241b4fda9ff54baa70f54421</id>
<content type='text'>
commit a294865978b701e4d0d90135672749531b9a900d upstream.

A length of zero (after subtracting two for the type and len fields) for
the DCCPO_{CHANGE,CONFIRM}_{L,R} options will cause an underflow due to
the subtraction.  The subsequent code may read past the end of the
options value buffer when parsing.  I'm unsure of what the consequences
of this might be, but it's probably not good.

Signed-off-by: Dan Rosenberg &lt;drosenberg@vsecurity.com&gt;
Acked-by: Gerrit Renker &lt;gerrit@erg.abdn.ac.uk&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit a294865978b701e4d0d90135672749531b9a900d upstream.

A length of zero (after subtracting two for the type and len fields) for
the DCCPO_{CHANGE,CONFIRM}_{L,R} options will cause an underflow due to
the subtraction.  The subsequent code may read past the end of the
options value buffer when parsing.  I'm unsure of what the consequences
of this might be, but it's probably not good.

Signed-off-by: Dan Rosenberg &lt;drosenberg@vsecurity.com&gt;
Acked-by: Gerrit Renker &lt;gerrit@erg.abdn.ac.uk&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>dccp: fix oops on Reset after close</title>
<updated>2011-03-21T19:45:26+00:00</updated>
<author>
<name>Gerrit Renker</name>
<email>gerrit@erg.abdn.ac.uk</email>
</author>
<published>2011-03-02T07:02:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=519c0f5f84fe7ce673305bf12c55a01361b0ee50'/>
<id>519c0f5f84fe7ce673305bf12c55a01361b0ee50</id>
<content type='text'>
commit 720dc34bbbe9493c7bd48b2243058b4e447a929d upstream.

This fixes a bug in the order of dccp_rcv_state_process() that still permitted
reception even after closing the socket. A Reset after close thus causes a NULL
pointer dereference by not preventing operations on an already torn-down socket.

 dccp_v4_do_rcv()
	|
	| state other than OPEN
	v
 dccp_rcv_state_process()
	|
	| DCCP_PKT_RESET
	v
 dccp_rcv_reset()
	|
	v
 dccp_time_wait()

 WARNING: at net/ipv4/inet_timewait_sock.c:141 __inet_twsk_hashdance+0x48/0x128()
 Modules linked in: arc4 ecb carl9170 rt2870sta(C) mac80211 r8712u(C) crc_ccitt ah
 [&lt;c0038850&gt;] (unwind_backtrace+0x0/0xec) from [&lt;c0055364&gt;] (warn_slowpath_common)
 [&lt;c0055364&gt;] (warn_slowpath_common+0x4c/0x64) from [&lt;c0055398&gt;] (warn_slowpath_n)
 [&lt;c0055398&gt;] (warn_slowpath_null+0x1c/0x24) from [&lt;c02b72d0&gt;] (__inet_twsk_hashd)
 [&lt;c02b72d0&gt;] (__inet_twsk_hashdance+0x48/0x128) from [&lt;c031caa0&gt;] (dccp_time_wai)
 [&lt;c031caa0&gt;] (dccp_time_wait+0x40/0xc8) from [&lt;c031c15c&gt;] (dccp_rcv_state_proces)
 [&lt;c031c15c&gt;] (dccp_rcv_state_process+0x120/0x538) from [&lt;c032609c&gt;] (dccp_v4_do_)
 [&lt;c032609c&gt;] (dccp_v4_do_rcv+0x11c/0x14c) from [&lt;c0286594&gt;] (release_sock+0xac/0)
 [&lt;c0286594&gt;] (release_sock+0xac/0x110) from [&lt;c031fd34&gt;] (dccp_close+0x28c/0x380)
 [&lt;c031fd34&gt;] (dccp_close+0x28c/0x380) from [&lt;c02d9a78&gt;] (inet_release+0x64/0x70)

The fix is by testing the socket state first. Receiving a packet in Closed state
now also produces the required "No connection" Reset reply of RFC 4340, 8.3.1.

Reported-and-tested-by: Johan Hovold &lt;jhovold@gmail.com&gt;
Signed-off-by: Gerrit Renker &lt;gerrit@erg.abdn.ac.uk&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 720dc34bbbe9493c7bd48b2243058b4e447a929d upstream.

This fixes a bug in the order of dccp_rcv_state_process() that still permitted
reception even after closing the socket. A Reset after close thus causes a NULL
pointer dereference by not preventing operations on an already torn-down socket.

 dccp_v4_do_rcv()
	|
	| state other than OPEN
	v
 dccp_rcv_state_process()
	|
	| DCCP_PKT_RESET
	v
 dccp_rcv_reset()
	|
	v
 dccp_time_wait()

 WARNING: at net/ipv4/inet_timewait_sock.c:141 __inet_twsk_hashdance+0x48/0x128()
 Modules linked in: arc4 ecb carl9170 rt2870sta(C) mac80211 r8712u(C) crc_ccitt ah
 [&lt;c0038850&gt;] (unwind_backtrace+0x0/0xec) from [&lt;c0055364&gt;] (warn_slowpath_common)
 [&lt;c0055364&gt;] (warn_slowpath_common+0x4c/0x64) from [&lt;c0055398&gt;] (warn_slowpath_n)
 [&lt;c0055398&gt;] (warn_slowpath_null+0x1c/0x24) from [&lt;c02b72d0&gt;] (__inet_twsk_hashd)
 [&lt;c02b72d0&gt;] (__inet_twsk_hashdance+0x48/0x128) from [&lt;c031caa0&gt;] (dccp_time_wai)
 [&lt;c031caa0&gt;] (dccp_time_wait+0x40/0xc8) from [&lt;c031c15c&gt;] (dccp_rcv_state_proces)
 [&lt;c031c15c&gt;] (dccp_rcv_state_process+0x120/0x538) from [&lt;c032609c&gt;] (dccp_v4_do_)
 [&lt;c032609c&gt;] (dccp_v4_do_rcv+0x11c/0x14c) from [&lt;c0286594&gt;] (release_sock+0xac/0)
 [&lt;c0286594&gt;] (release_sock+0xac/0x110) from [&lt;c031fd34&gt;] (dccp_close+0x28c/0x380)
 [&lt;c031fd34&gt;] (dccp_close+0x28c/0x380) from [&lt;c02d9a78&gt;] (inet_release+0x64/0x70)

The fix is by testing the socket state first. Receiving a packet in Closed state
now also produces the required "No connection" Reset reply of RFC 4340, 8.3.1.

Reported-and-tested-by: Johan Hovold &lt;jhovold@gmail.com&gt;
Signed-off-by: Gerrit Renker &lt;gerrit@erg.abdn.ac.uk&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>net/dccp: expansion of error code size</title>
<updated>2010-08-02T17:26:24+00:00</updated>
<author>
<name>Yoichi Yuasa</name>
<email>yuasa@linux-mips.org</email>
</author>
<published>2010-05-25T01:37:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6e6f920379266f7b5500be5a9f4236e0ffa546c5'/>
<id>6e6f920379266f7b5500be5a9f4236e0ffa546c5</id>
<content type='text'>
[ Upstream commit d9b52dc6fd1fbb2bad645cbc86a60f984c1cb179 ]

Because MIPS's EDQUOT value is 1133(0x46d).
It's larger than u8.

Signed-off-by: Yoichi Yuasa &lt;yuasa@linux-mips.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit d9b52dc6fd1fbb2bad645cbc86a60f984c1cb179 ]

Because MIPS's EDQUOT value is 1133(0x46d).
It's larger than u8.

Signed-off-by: Yoichi Yuasa &lt;yuasa@linux-mips.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: backlog functions rename</title>
<updated>2010-04-01T23:02:04+00:00</updated>
<author>
<name>Zhu Yi</name>
<email>yi.zhu@intel.com</email>
</author>
<published>2010-03-04T18:01:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a12a9a26ff389892df27e2ff4cbf03e5b2ed0d64'/>
<id>a12a9a26ff389892df27e2ff4cbf03e5b2ed0d64</id>
<content type='text'>
[ Upstream commit a3a858ff18a72a8d388e31ab0d98f7e944841a62 ]

sk_add_backlog -&gt; __sk_add_backlog
sk_add_backlog_limited -&gt; sk_add_backlog

Signed-off-by: Zhu Yi &lt;yi.zhu@intel.com&gt;
Acked-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;


</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit a3a858ff18a72a8d388e31ab0d98f7e944841a62 ]

sk_add_backlog -&gt; __sk_add_backlog
sk_add_backlog_limited -&gt; sk_add_backlog

Signed-off-by: Zhu Yi &lt;yi.zhu@intel.com&gt;
Acked-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;


</pre>
</div>
</content>
</entry>
<entry>
<title>dccp: fix auto-loading of dccp(_probe)</title>
<updated>2010-02-04T03:00:31+00:00</updated>
<author>
<name>Gerrit Renker</name>
<email>gerrit@erg.abdn.ac.uk</email>
</author>
<published>2010-02-02T20:16:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1386be55e32a3c5d8ef4a2b243c530a7b664c02c'/>
<id>1386be55e32a3c5d8ef4a2b243c530a7b664c02c</id>
<content type='text'>
This fixes commit (38ff3e6bb987ec583268da8eb22628293095d43b) ("dccp_probe:
Fix module load dependencies between dccp and dccp_probe", from 15 Jan).

It fixes the construction of the first argument of try_then_request_module(),
where only valid return codes from the first argument should be returned.

What we do now is assign the result of register_jprobe() to ret, without
the side effect of the comparison.

Acked-by: Gerrit Renker &lt;gerrit@erg.abdn.ac.uk&gt;
Signed-off-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This fixes commit (38ff3e6bb987ec583268da8eb22628293095d43b) ("dccp_probe:
Fix module load dependencies between dccp and dccp_probe", from 15 Jan).

It fixes the construction of the first argument of try_then_request_module(),
where only valid return codes from the first argument should be returned.

What we do now is assign the result of register_jprobe() to ret, without
the side effect of the comparison.

Acked-by: Gerrit Renker &lt;gerrit@erg.abdn.ac.uk&gt;
Signed-off-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>dccp: fix bug in cache allocation</title>
<updated>2010-02-04T03:00:30+00:00</updated>
<author>
<name>Gerrit Renker</name>
<email>gerrit@erg.abdn.ac.uk</email>
</author>
<published>2010-02-01T02:12:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8ed030dd0aa400d18c63861c2c6deb7c38f4edde'/>
<id>8ed030dd0aa400d18c63861c2c6deb7c38f4edde</id>
<content type='text'>
This fixes a bug introduced in commit de4ef86cfce60d2250111f34f8a084e769f23b16
("dccp: fix dccp rmmod when kernel configured to use slub", 17 Jan): the
vsnprintf used sizeof(slab_name_fmt), which became truncated to 4 bytes, since
slab_name_fmt is now a 4-byte pointer and no longer a 32-character array.

This lead to error messages such as
 FATAL: Error inserting dccp: No buffer space available

 &gt;&gt; kernel: [ 1456.341501] kmem_cache_create: duplicate cache cci
generated due to the truncation after the 3rd character.

Fixed for the moment by introducing a symbolic constant. Tested to fix the bug.

Signed-off-by: Gerrit Renker &lt;gerrit@erg.abdn.ac.uk&gt;
Acked-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This fixes a bug introduced in commit de4ef86cfce60d2250111f34f8a084e769f23b16
("dccp: fix dccp rmmod when kernel configured to use slub", 17 Jan): the
vsnprintf used sizeof(slab_name_fmt), which became truncated to 4 bytes, since
slab_name_fmt is now a 4-byte pointer and no longer a 32-character array.

This lead to error messages such as
 FATAL: Error inserting dccp: No buffer space available

 &gt;&gt; kernel: [ 1456.341501] kmem_cache_create: duplicate cache cci
generated due to the truncation after the 3rd character.

Fixed for the moment by introducing a symbolic constant. Tested to fix the bug.

Signed-off-by: Gerrit Renker &lt;gerrit@erg.abdn.ac.uk&gt;
Acked-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'master' of /home/davem/src/GIT/linux-2.6/</title>
<updated>2010-01-23T06:45:46+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2010-01-23T06:45:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6be325719b3e54624397e413efd4b33a997e55a3'/>
<id>6be325719b3e54624397e413efd4b33a997e55a3</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>dccp: fix dccp rmmod when kernel configured to use slub</title>
<updated>2010-01-19T09:59:01+00:00</updated>
<author>
<name>Neil Horman</name>
<email>nhorman@tuxdriver.com</email>
</author>
<published>2010-01-17T17:16:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=de4ef86cfce60d2250111f34f8a084e769f23b16'/>
<id>de4ef86cfce60d2250111f34f8a084e769f23b16</id>
<content type='text'>
Hey all-
	I was tinkering with dccp recently and noticed that I BUG halted the
kernel when I rmmod-ed the dccp module.  The bug halt occured because the page
that I passed to kfree failed the PageCompound and PageSlab test in the slub
implementation of kfree.  I tracked the problem down to the following set of
events:

1) dccp, unlike all other uses of kmem_cache_create, allocates a string
dynamically when registering a slab cache.  This allocated string is freed when
the cache is destroyed.

2) Normally, (1) is not an issue, but when Slub is in use, it is possible that
caches are 'merged'.  This process causes multiple caches of simmilar
configuration to use the same cache data structure.  When this happens, the new
name of the cache is effectively dropped.

3) (2) results in kmem_cache_name returning an ambigous value (i.e.
ccid_kmem_cache_destroy, which uses this fuction to retrieve the name pointer
for freeing), is no longer guaranteed that the string it assigned is what is
returned.

4) If such merge event occurs, ccid_kmem_cache_destroy frees the wrong pointer,
which trips over the BUG in the slub implementation of kfree (since its likely
not a slab allocation, but rather a pointer into the static string table
section.

So, what to do about this.  At first blush this is pretty clearly a leak in the
information that slub owns, and as such a slub bug.  Unfortunately, theres no
really good way to fix it, without exposing slub specific implementation details
to the generic slab interface.  Also, even if we could fix this in slub cleanly,
I think the RCU free option would force us to do lots of string duplication, not
only in slub, but in every slab allocator.  As such, I'd like to propose this
solution.  Basically, I just move the storage for the kmem cache name to the
ccid_operations structure.  In so doing, we don't have to do the kstrdup or
kfree when we allocate/free the various caches for dccp, and so we avoid the
problem, by storing names with static memory, rather than heap, the way all
other calls to kmem_cache_create do.

I've tested this out myself here, and it solves the problem quite well.

Signed-off-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
Acked-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Hey all-
	I was tinkering with dccp recently and noticed that I BUG halted the
kernel when I rmmod-ed the dccp module.  The bug halt occured because the page
that I passed to kfree failed the PageCompound and PageSlab test in the slub
implementation of kfree.  I tracked the problem down to the following set of
events:

1) dccp, unlike all other uses of kmem_cache_create, allocates a string
dynamically when registering a slab cache.  This allocated string is freed when
the cache is destroyed.

2) Normally, (1) is not an issue, but when Slub is in use, it is possible that
caches are 'merged'.  This process causes multiple caches of simmilar
configuration to use the same cache data structure.  When this happens, the new
name of the cache is effectively dropped.

3) (2) results in kmem_cache_name returning an ambigous value (i.e.
ccid_kmem_cache_destroy, which uses this fuction to retrieve the name pointer
for freeing), is no longer guaranteed that the string it assigned is what is
returned.

4) If such merge event occurs, ccid_kmem_cache_destroy frees the wrong pointer,
which trips over the BUG in the slub implementation of kfree (since its likely
not a slab allocation, but rather a pointer into the static string table
section.

So, what to do about this.  At first blush this is pretty clearly a leak in the
information that slub owns, and as such a slub bug.  Unfortunately, theres no
really good way to fix it, without exposing slub specific implementation details
to the generic slab interface.  Also, even if we could fix this in slub cleanly,
I think the RCU free option would force us to do lots of string duplication, not
only in slub, but in every slab allocator.  As such, I'd like to propose this
solution.  Basically, I just move the storage for the kmem cache name to the
ccid_operations structure.  In so doing, we don't have to do the kstrdup or
kfree when we allocate/free the various caches for dccp, and so we avoid the
problem, by storing names with static memory, rather than heap, the way all
other calls to kmem_cache_create do.

I've tested this out myself here, and it solves the problem quite well.

Signed-off-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
Acked-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>dccp_probe: Fix module load dependencies between dccp and dccp_probe</title>
<updated>2010-01-15T09:40:55+00:00</updated>
<author>
<name>Neil Horman</name>
<email>nhorman@tuxdriver.com</email>
</author>
<published>2010-01-15T09:40:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=38ff3e6bb987ec583268da8eb22628293095d43b'/>
<id>38ff3e6bb987ec583268da8eb22628293095d43b</id>
<content type='text'>
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.

Signed-off-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
Acked-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.

Signed-off-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
Acked-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
</feed>
