<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/net, branch v2.6.32.31</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>x25: Do not reference freed memory.</title>
<updated>2011-03-02T14:47:07+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2011-02-10T05:48:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=7599b39d52b21cd13dcc53e395b459f826fb4728'/>
<id>7599b39d52b21cd13dcc53e395b459f826fb4728</id>
<content type='text'>
commit 96642d42f076101ba98866363d908cab706d156c upstream.

In x25_link_free(), we destroy 'nb' before dereferencing
'nb-&gt;dev'.  Don't do this, because 'nb' might be freed
by then.

Reported-by: Randy Dunlap &lt;randy.dunlap@oracle.com&gt;
Tested-by: Randy Dunlap &lt;randy.dunlap@oracle.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>
commit 96642d42f076101ba98866363d908cab706d156c upstream.

In x25_link_free(), we destroy 'nb' before dereferencing
'nb-&gt;dev'.  Don't do this, because 'nb' might be freed
by then.

Reported-by: Randy Dunlap &lt;randy.dunlap@oracle.com&gt;
Tested-by: Randy Dunlap &lt;randy.dunlap@oracle.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>tcp: Make TCP_MAXSEG minimum more correct.</title>
<updated>2011-03-02T14:46:46+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2010-11-24T19:47:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=d9d89091ffe11687f7fa20b7d75b08d9e1dc1421'/>
<id>d9d89091ffe11687f7fa20b7d75b08d9e1dc1421</id>
<content type='text'>
commit c39508d6f118308355468314ff414644115a07f3 upstream.

Use TCP_MIN_MSS instead of constant 64.

Reported-by: Min Zhang &lt;mzhang@mvista.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Cc: Moritz Muehlenhoff &lt;jmm@debian.org&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 c39508d6f118308355468314ff414644115a07f3 upstream.

Use TCP_MIN_MSS instead of constant 64.

Reported-by: Min Zhang &lt;mzhang@mvista.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Cc: Moritz Muehlenhoff &lt;jmm@debian.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>tcp: Increase TCP_MAXSEG socket option minimum.</title>
<updated>2011-03-02T14:46:45+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2010-11-11T05:35:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f6e5886328bd4f59dbcd18497b8a7eea1a9f2903'/>
<id>f6e5886328bd4f59dbcd18497b8a7eea1a9f2903</id>
<content type='text'>
commit 7a1abd08d52fdeddb3e9a5a33f2f15cc6a5674d2 upstream.

As noted by Steve Chen, since commit
f5fff5dc8a7a3f395b0525c02ba92c95d42b7390 ("tcp: advertise MSS
requested by user") we can end up with a situation where
tcp_select_initial_window() does a divide by a zero (or
even negative) mss value.

The problem is that sometimes we effectively subtract
TCPOLEN_TSTAMP_ALIGNED and/or TCPOLEN_MD5SIG_ALIGNED from the mss.

Fix this by increasing the minimum from 8 to 64.

Reported-by: Steve Chen &lt;schen@mvista.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Cc: Moritz Muehlenhoff &lt;jmm@debian.org&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 7a1abd08d52fdeddb3e9a5a33f2f15cc6a5674d2 upstream.

As noted by Steve Chen, since commit
f5fff5dc8a7a3f395b0525c02ba92c95d42b7390 ("tcp: advertise MSS
requested by user") we can end up with a situation where
tcp_select_initial_window() does a divide by a zero (or
even negative) mss value.

The problem is that sometimes we effectively subtract
TCPOLEN_TSTAMP_ALIGNED and/or TCPOLEN_MD5SIG_ALIGNED from the mss.

Fix this by increasing the minimum from 8 to 64.

Reported-by: Steve Chen &lt;schen@mvista.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Cc: Moritz Muehlenhoff &lt;jmm@debian.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>sunrpc/cache: fix module refcnt leak in a failure path</title>
<updated>2011-03-02T14:46:44+00:00</updated>
<author>
<name>Li Zefan</name>
<email>lizf@cn.fujitsu.com</email>
</author>
<published>2010-03-11T22:08:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=fe20aa6ef8389723f01d6bcbb000d14646741241'/>
<id>fe20aa6ef8389723f01d6bcbb000d14646741241</id>
<content type='text'>
commit a5990ea1254cd186b38744507aeec3136a0c1c95 upstream.

Don't forget to release the module refcnt if seq_open() returns failure.

Signed-off-by: Li Zefan &lt;lizf@cn.fujitsu.com&gt;
Cc: J. Bruce Fields &lt;bfields@fieldses.org&gt;
Cc: Neil Brown &lt;neilb@suse.de&gt;
Cc: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: J. Bruce Fields &lt;bfields@citi.umich.edu&gt;
Cc: maximilian attems &lt;max@stro.at&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 a5990ea1254cd186b38744507aeec3136a0c1c95 upstream.

Don't forget to release the module refcnt if seq_open() returns failure.

Signed-off-by: Li Zefan &lt;lizf@cn.fujitsu.com&gt;
Cc: J. Bruce Fields &lt;bfields@fieldses.org&gt;
Cc: Neil Brown &lt;neilb@suse.de&gt;
Cc: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: J. Bruce Fields &lt;bfields@citi.umich.edu&gt;
Cc: maximilian attems &lt;max@stro.at&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>x25: decrement netdev reference counts on unload</title>
<updated>2011-03-02T14:46:35+00:00</updated>
<author>
<name>Apollon Oikonomopoulos</name>
<email>apollon@noc.grnet.gr</email>
</author>
<published>2010-12-07T09:43:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=cfa3f57bab83b586b948fd40d3558243d55818b2'/>
<id>cfa3f57bab83b586b948fd40d3558243d55818b2</id>
<content type='text'>
commit 171995e5d82dcc92bea37a7d2a2ecc21068a0f19 upstream.

x25 does not decrement the network device reference counts on module unload.
Thus unregistering any pre-existing interface after unloading the x25 module
hangs and results in

 unregister_netdevice: waiting for tap0 to become free. Usage count = 1

This patch decrements the reference counts of all interfaces in x25_link_free,
the way it is already done in x25_link_device_down for NETDEV_DOWN events.

Signed-off-by: Apollon Oikonomopoulos &lt;apollon@noc.grnet.gr&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 171995e5d82dcc92bea37a7d2a2ecc21068a0f19 upstream.

x25 does not decrement the network device reference counts on module unload.
Thus unregistering any pre-existing interface after unloading the x25 module
hangs and results in

 unregister_netdevice: waiting for tap0 to become free. Usage count = 1

This patch decrements the reference counts of all interfaces in x25_link_free,
the way it is already done in x25_link_device_down for NETDEV_DOWN events.

Signed-off-by: Apollon Oikonomopoulos &lt;apollon@noc.grnet.gr&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>filter: make sure filters dont read uninitialized memory</title>
<updated>2011-03-02T14:46:35+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2010-11-10T18:38:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f37c091b7f85f3f93b5eb79c4a4fa53ed1339f9e'/>
<id>f37c091b7f85f3f93b5eb79c4a4fa53ed1339f9e</id>
<content type='text'>
commit 57fe93b374a6b8711995c2d466c502af9f3a08bb upstream.

There is a possibility malicious users can get limited information about
uninitialized stack mem array. Even if sk_run_filter() result is bound
to packet length (0 .. 65535), we could imagine this can be used by
hostile user.

Initializing mem[] array, like Dan Rosenberg suggested in his patch is
expensive since most filters dont even use this array.

Its hard to make the filter validation in sk_chk_filter(), because of
the jumps. This might be done later.

In this patch, I use a bitmap (a single long var) so that only filters
using mem[] loads/stores pay the price of added security checks.

For other filters, additional cost is a single instruction.

[ Since we access fentry-&gt;k a lot now, cache it in a local variable
  and mark filter entry pointer as const. -DaveM ]

Reported-by: Dan Rosenberg &lt;drosenberg@vsecurity.com&gt;
Signed-off-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
[Backported by dann frazier &lt;dannf@debian.org&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 57fe93b374a6b8711995c2d466c502af9f3a08bb upstream.

There is a possibility malicious users can get limited information about
uninitialized stack mem array. Even if sk_run_filter() result is bound
to packet length (0 .. 65535), we could imagine this can be used by
hostile user.

Initializing mem[] array, like Dan Rosenberg suggested in his patch is
expensive since most filters dont even use this array.

Its hard to make the filter validation in sk_chk_filter(), because of
the jumps. This might be done later.

In this patch, I use a bitmap (a single long var) so that only filters
using mem[] loads/stores pay the price of added security checks.

For other filters, additional cost is a single instruction.

[ Since we access fentry-&gt;k a lot now, cache it in a local variable
  and mark filter entry pointer as const. -DaveM ]

Reported-by: Dan Rosenberg &lt;drosenberg@vsecurity.com&gt;
Signed-off-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
[Backported by dann frazier &lt;dannf@debian.org&gt;]
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>sctp: Fix out-of-bounds reading in sctp_asoc_get_hmac()</title>
<updated>2011-03-02T14:46:33+00:00</updated>
<author>
<name>Dan Rosenberg</name>
<email>drosenberg@vsecurity.com</email>
</author>
<published>2010-10-01T11:51:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=1209e7abd3be20e6a3464482c48b8bf9ecf7b997'/>
<id>1209e7abd3be20e6a3464482c48b8bf9ecf7b997</id>
<content type='text'>
commit 51e97a12bef19b7e43199fc153cf9bd5f2140362 upstream.

The sctp_asoc_get_hmac() function iterates through a peer's hmac_ids
array and attempts to ensure that only a supported hmac entry is
returned.  The current code fails to do this properly - if the last id
in the array is out of range (greater than SCTP_AUTH_HMAC_ID_MAX), the
id integer remains set after exiting the loop, and the address of an
out-of-bounds entry will be returned and subsequently used in the parent
function, causing potentially ugly memory corruption.  This patch resets
the id integer to 0 on encountering an invalid id so that NULL will be
returned after finishing the loop if no valid ids are found.

Signed-off-by: Dan Rosenberg &lt;drosenberg@vsecurity.com&gt;
Acked-by: Vlad Yasevich &lt;vladislav.yasevich@hp.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>
commit 51e97a12bef19b7e43199fc153cf9bd5f2140362 upstream.

The sctp_asoc_get_hmac() function iterates through a peer's hmac_ids
array and attempts to ensure that only a supported hmac entry is
returned.  The current code fails to do this properly - if the last id
in the array is out of range (greater than SCTP_AUTH_HMAC_ID_MAX), the
id integer remains set after exiting the loop, and the address of an
out-of-bounds entry will be returned and subsequently used in the parent
function, causing potentially ugly memory corruption.  This patch resets
the id integer to 0 on encountering an invalid id so that NULL will be
returned after finishing the loop if no valid ids are found.

Signed-off-by: Dan Rosenberg &lt;drosenberg@vsecurity.com&gt;
Acked-by: Vlad Yasevich &lt;vladislav.yasevich@hp.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>sched: Fix softirq time accounting</title>
<updated>2011-02-17T23:37:24+00:00</updated>
<author>
<name>Venkatesh Pallipadi</name>
<email>venki@google.com</email>
</author>
<published>2011-02-10T09:23:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=49c6f4a2ba104ce198c61445edbff78ce1508a65'/>
<id>49c6f4a2ba104ce198c61445edbff78ce1508a65</id>
<content type='text'>
Commit: 75e1056f5c57050415b64cb761a3acc35d91f013 upstream

Peter Zijlstra found a bug in the way softirq time is accounted in
VIRT_CPU_ACCOUNTING on this thread:

   http://lkml.indiana.edu/hypermail//linux/kernel/1009.2/01366.html

The problem is, softirq processing uses local_bh_disable internally. There
is no way, later in the flow, to differentiate between whether softirq is
being processed or is it just that bh has been disabled. So, a hardirq when bh
is disabled results in time being wrongly accounted as softirq.

Looking at the code a bit more, the problem exists in !VIRT_CPU_ACCOUNTING
as well. As account_system_time() in normal tick based accouting also uses
softirq_count, which will be set even when not in softirq with bh disabled.

Peter also suggested solution of using 2*SOFTIRQ_OFFSET as irq count
for local_bh_{disable,enable} and using just SOFTIRQ_OFFSET while softirq
processing. The patch below does that and adds API in_serving_softirq() which
returns whether we are currently processing softirq or not.

Also changes one of the usages of softirq_count in net/sched/cls_cgroup.c
to in_serving_softirq.

Looks like many usages of in_softirq really want in_serving_softirq. Those
changes can be made individually on a case by case basis.

Signed-off-by: Venkatesh Pallipadi &lt;venki@google.com&gt;
Signed-off-by: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
LKML-Reference: &lt;1286237003-12406-2-git-send-email-venki@google.com&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
Signed-off-by: Mike Galbraith &lt;efault@gmx.de&gt;
Acked-by: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&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: 75e1056f5c57050415b64cb761a3acc35d91f013 upstream

Peter Zijlstra found a bug in the way softirq time is accounted in
VIRT_CPU_ACCOUNTING on this thread:

   http://lkml.indiana.edu/hypermail//linux/kernel/1009.2/01366.html

The problem is, softirq processing uses local_bh_disable internally. There
is no way, later in the flow, to differentiate between whether softirq is
being processed or is it just that bh has been disabled. So, a hardirq when bh
is disabled results in time being wrongly accounted as softirq.

Looking at the code a bit more, the problem exists in !VIRT_CPU_ACCOUNTING
as well. As account_system_time() in normal tick based accouting also uses
softirq_count, which will be set even when not in softirq with bh disabled.

Peter also suggested solution of using 2*SOFTIRQ_OFFSET as irq count
for local_bh_{disable,enable} and using just SOFTIRQ_OFFSET while softirq
processing. The patch below does that and adds API in_serving_softirq() which
returns whether we are currently processing softirq or not.

Also changes one of the usages of softirq_count in net/sched/cls_cgroup.c
to in_serving_softirq.

Looks like many usages of in_softirq really want in_serving_softirq. Those
changes can be made individually on a case by case basis.

Signed-off-by: Venkatesh Pallipadi &lt;venki@google.com&gt;
Signed-off-by: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
LKML-Reference: &lt;1286237003-12406-2-git-send-email-venki@google.com&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
Signed-off-by: Mike Galbraith &lt;efault@gmx.de&gt;
Acked-by: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>sctp: Fix a race between ICMP protocol unreachable and connect()</title>
<updated>2011-01-07T22:43:18+00:00</updated>
<author>
<name>Vlad Yasevich</name>
<email>vladislav.yasevich@hp.com</email>
</author>
<published>2010-05-06T07:56:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6552df6df2fcfc281c64dea191fef144d5a188c5'/>
<id>6552df6df2fcfc281c64dea191fef144d5a188c5</id>
<content type='text'>
commit 50b5d6ad63821cea324a5a7a19854d4de1a0a819 upstream.

ICMP protocol unreachable handling completely disregarded
the fact that the user may have locked the socket.  It proceeded
to destroy the association, even though the user may have
held the lock and had a ref on the association.  This resulted
in the following:

Attempt to release alive inet socket f6afcc00

=========================
[ BUG: held lock freed! ]
-------------------------
somenu/2672 is freeing memory f6afcc00-f6afcfff, with a lock still held
there!
 (sk_lock-AF_INET){+.+.+.}, at: [&lt;c122098a&gt;] sctp_connect+0x13/0x4c
1 lock held by somenu/2672:
 #0:  (sk_lock-AF_INET){+.+.+.}, at: [&lt;c122098a&gt;] sctp_connect+0x13/0x4c

stack backtrace:
Pid: 2672, comm: somenu Not tainted 2.6.32-telco #55
Call Trace:
 [&lt;c1232266&gt;] ? printk+0xf/0x11
 [&lt;c1038553&gt;] debug_check_no_locks_freed+0xce/0xff
 [&lt;c10620b4&gt;] kmem_cache_free+0x21/0x66
 [&lt;c1185f25&gt;] __sk_free+0x9d/0xab
 [&lt;c1185f9c&gt;] sk_free+0x1c/0x1e
 [&lt;c1216e38&gt;] sctp_association_put+0x32/0x89
 [&lt;c1220865&gt;] __sctp_connect+0x36d/0x3f4
 [&lt;c122098a&gt;] ? sctp_connect+0x13/0x4c
 [&lt;c102d073&gt;] ? autoremove_wake_function+0x0/0x33
 [&lt;c12209a8&gt;] sctp_connect+0x31/0x4c
 [&lt;c11d1e80&gt;] inet_dgram_connect+0x4b/0x55
 [&lt;c11834fa&gt;] sys_connect+0x54/0x71
 [&lt;c103a3a2&gt;] ? lock_release_non_nested+0x88/0x239
 [&lt;c1054026&gt;] ? might_fault+0x42/0x7c
 [&lt;c1054026&gt;] ? might_fault+0x42/0x7c
 [&lt;c11847ab&gt;] sys_socketcall+0x6d/0x178
 [&lt;c10da994&gt;] ? trace_hardirqs_on_thunk+0xc/0x10
 [&lt;c1002959&gt;] syscall_call+0x7/0xb

This was because the sctp_wait_for_connect() would aqcure the socket
lock and then proceed to release the last reference count on the
association, thus cause the fully destruction path to finish freeing
the socket.

The simplest solution is to start a very short timer in case the socket
is owned by user.  When the timer expires, we can do some verification
and be able to do the release properly.

Signed-off-by: Vlad Yasevich &lt;vladislav.yasevich@hp.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>
commit 50b5d6ad63821cea324a5a7a19854d4de1a0a819 upstream.

ICMP protocol unreachable handling completely disregarded
the fact that the user may have locked the socket.  It proceeded
to destroy the association, even though the user may have
held the lock and had a ref on the association.  This resulted
in the following:

Attempt to release alive inet socket f6afcc00

=========================
[ BUG: held lock freed! ]
-------------------------
somenu/2672 is freeing memory f6afcc00-f6afcfff, with a lock still held
there!
 (sk_lock-AF_INET){+.+.+.}, at: [&lt;c122098a&gt;] sctp_connect+0x13/0x4c
1 lock held by somenu/2672:
 #0:  (sk_lock-AF_INET){+.+.+.}, at: [&lt;c122098a&gt;] sctp_connect+0x13/0x4c

stack backtrace:
Pid: 2672, comm: somenu Not tainted 2.6.32-telco #55
Call Trace:
 [&lt;c1232266&gt;] ? printk+0xf/0x11
 [&lt;c1038553&gt;] debug_check_no_locks_freed+0xce/0xff
 [&lt;c10620b4&gt;] kmem_cache_free+0x21/0x66
 [&lt;c1185f25&gt;] __sk_free+0x9d/0xab
 [&lt;c1185f9c&gt;] sk_free+0x1c/0x1e
 [&lt;c1216e38&gt;] sctp_association_put+0x32/0x89
 [&lt;c1220865&gt;] __sctp_connect+0x36d/0x3f4
 [&lt;c122098a&gt;] ? sctp_connect+0x13/0x4c
 [&lt;c102d073&gt;] ? autoremove_wake_function+0x0/0x33
 [&lt;c12209a8&gt;] sctp_connect+0x31/0x4c
 [&lt;c11d1e80&gt;] inet_dgram_connect+0x4b/0x55
 [&lt;c11834fa&gt;] sys_connect+0x54/0x71
 [&lt;c103a3a2&gt;] ? lock_release_non_nested+0x88/0x239
 [&lt;c1054026&gt;] ? might_fault+0x42/0x7c
 [&lt;c1054026&gt;] ? might_fault+0x42/0x7c
 [&lt;c11847ab&gt;] sys_socketcall+0x6d/0x178
 [&lt;c10da994&gt;] ? trace_hardirqs_on_thunk+0xc/0x10
 [&lt;c1002959&gt;] syscall_call+0x7/0xb

This was because the sctp_wait_for_connect() would aqcure the socket
lock and then proceed to release the last reference count on the
association, thus cause the fully destruction path to finish freeing
the socket.

The simplest solution is to start a very short timer in case the socket
is owned by user.  When the timer expires, we can do some verification
and be able to do the release properly.

Signed-off-by: Vlad Yasevich &lt;vladislav.yasevich@hp.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>net: release dst entry while cache-hot for GSO case too</title>
<updated>2011-01-07T22:43:14+00:00</updated>
<author>
<name>Krishna Kumar</name>
<email>krkumar2@in.ibm.com</email>
</author>
<published>2009-12-09T20:59:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=60a517cab5e8885d8873bfa3acc2a138fbb7fb9c'/>
<id>60a517cab5e8885d8873bfa3acc2a138fbb7fb9c</id>
<content type='text'>
commit 068a2de57ddf4f472e32e7af868613c574ad1d88 upstream.

Non-GSO code drops dst entry for performance reasons, but
the same is missing for GSO code. Drop dst while cache-hot
for GSO case too.

Signed-off-by: Krishna Kumar &lt;krkumar2@in.ibm.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: Andrey Vagin &lt;avagin@openvz.org&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 068a2de57ddf4f472e32e7af868613c574ad1d88 upstream.

Non-GSO code drops dst entry for performance reasons, but
the same is missing for GSO code. Drop dst while cache-hot
for GSO case too.

Signed-off-by: Krishna Kumar &lt;krkumar2@in.ibm.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: Andrey Vagin &lt;avagin@openvz.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
</feed>
