<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/net, branch v2.6.27.2</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/net?h=v2.6.27.2</id>
<link rel='self' href='https://git.amat.us/linux/atom/net?h=v2.6.27.2'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2008-10-18T17:49:12Z</updated>
<entry>
<title>rfkill: update LEDs for all state changes</title>
<updated>2008-10-18T17:49:12Z</updated>
<author>
<name>Henrique de Moraes Holschuh</name>
<email>hmh@hmh.eng.br</email>
</author>
<published>2008-10-11T16:55:13Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=95a3690291668508570c593ccc8b69af1f0e3f3f'/>
<id>urn:sha1:95a3690291668508570c593ccc8b69af1f0e3f3f</id>
<content type='text'>
commit 417bd25ac4c6f76c8aafe8a584f3620f4a936b72 upstream

The LED state was not being updated by rfkill_force_state(), which
will cause regressions in wireless drivers that had old-style rfkill
support and are updated to use rfkill_force_state().

The LED state was not being updated when a change was detected through
the rfkill-&gt;get_state() hook, either.

Move the LED trigger update calls into notify_rfkill_state_change(),
where it should have been in the first place.  This takes care of both
issues above.

Signed-off-by: Henrique de Moraes Holschuh &lt;hmh@hmh.eng.br&gt;
Acked-by: Ivo van Doorn &lt;IvDoorn@gmail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>mac80211: fix two issues in debugfs</title>
<updated>2008-10-18T17:49:11Z</updated>
<author>
<name>Johannes Berg</name>
<email>johannes@sipsolutions.net</email>
</author>
<published>2008-10-10T15:52:49Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=60b216fffd66fc2ad2824a05d6838aff6b59d827'/>
<id>urn:sha1:60b216fffd66fc2ad2824a05d6838aff6b59d827</id>
<content type='text'>
Not in trees above 2.6.27 as it is fixed differently in .28.

This fixes RHBZ 466264, whenever the master interface is
renamed this code would BUG_ON. Also fixes a separately
reported bug with the debugfs dir being NULL.

This patch is not applicable to the next kernel version
because both these issues have been fixed, the first one
by not having the master interface have a ieee80211_ptr
at all, and the second one by also leaving the function
early.

Signed-off-by: Johannes Berg &lt;johannes@sipsolutions.net&gt;
Cc: John Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>tcp: Fix tcp_hybla zero congestion window growth with small rho and large cwnd.</title>
<updated>2008-10-07T22:58:17Z</updated>
<author>
<name>Daniele Lacamera</name>
<email>root@danielinux.net</email>
</author>
<published>2008-10-07T22:58:17Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=9d2c27e17b7574023b5adb5c6a50d7aaeb915543'/>
<id>urn:sha1:9d2c27e17b7574023b5adb5c6a50d7aaeb915543</id>
<content type='text'>
Because of rounding, in certain conditions, i.e. when in congestion
avoidance state rho is smaller than 1/128 of the current cwnd, TCP
Hybla congestion control starves and the cwnd is kept constant
forever.

This patch forces an increment by one segment after #send_cwnd calls
without increments(newreno behavior).

Signed-off-by: Daniele Lacamera &lt;root@danielinux.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: Fix netdev_run_todo dead-lock</title>
<updated>2008-10-07T22:50:03Z</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2008-10-07T22:50:03Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=58ec3b4db9eb5a28e3aec5f407a54e28f7039c19'/>
<id>urn:sha1:58ec3b4db9eb5a28e3aec5f407a54e28f7039c19</id>
<content type='text'>
Benjamin Thery tracked down a bug that explains many instances
of the error

unregister_netdevice: waiting for %s to become free. Usage count = %d

It turns out that netdev_run_todo can dead-lock with itself if
a second instance of it is run in a thread that will then free
a reference to the device waited on by the first instance.

The problem is really quite silly.  We were trying to create
parallelism where none was required.  As netdev_run_todo always
follows a RTNL section, and that todo tasks can only be added
with the RTNL held, by definition you should only need to wait
for the very ones that you've added and be done with it.

There is no need for a second mutex or spinlock.

This is exactly what the following patch does.

Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>tcp: Fix possible double-ack w/ user dma</title>
<updated>2008-10-07T22:31:19Z</updated>
<author>
<name>Ali Saidi</name>
<email>saidi@engin.umich.edu</email>
</author>
<published>2008-10-07T22:31:19Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=53240c208776d557dba9d7afedbcdbf512774c16'/>
<id>urn:sha1:53240c208776d557dba9d7afedbcdbf512774c16</id>
<content type='text'>
From: Ali Saidi &lt;saidi@engin.umich.edu&gt;

When TCP receive copy offload is enabled it's possible that
tcp_rcv_established() will cause two acks to be sent for a single
packet. In the case that a tcp_dma_early_copy() is successful,
copied_early is set to true which causes tcp_cleanup_rbuf() to be
called early which can send an ack. Further along in
tcp_rcv_established(), __tcp_ack_snd_check() is called and will
schedule a delayed ACK. If no packets are processed before the delayed
ack timer expires the packet will be acked twice.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: only invoke dev-&gt;change_rx_flags when device is UP</title>
<updated>2008-10-07T22:26:48Z</updated>
<author>
<name>Patrick McHardy</name>
<email>kaber@trash.net</email>
</author>
<published>2008-10-07T22:26:48Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b6c40d68ff6498b7f63ddf97cf0aa818d748dee7'/>
<id>urn:sha1:b6c40d68ff6498b7f63ddf97cf0aa818d748dee7</id>
<content type='text'>
Jesper Dangaard Brouer &lt;hawk@comx.dk&gt; reported a bug when setting a VLAN
device down that is in promiscous mode:

When the VLAN device is set down, the promiscous count on the real
device is decremented by one by vlan_dev_stop(). When removing the
promiscous flag from the VLAN device afterwards, the promiscous
count on the real device is decremented a second time by the
vlan_change_rx_flags() callback.

The root cause for this is that the -&gt;change_rx_flags() callback is
invoked while the device is down. The synchronization is meant to mirror
the behaviour of the -&gt;set_rx_mode callbacks, meaning the -&gt;open function
is responsible for doing a full sync on open, the -&gt;close() function is
responsible for doing full cleanup on -&gt;stop() and -&gt;change_rx_flags()
is meant to do incremental changes while the device is UP.

Only invoke -&gt;change_rx_flags() while the device is UP to provide the
intended behaviour.

Tested-by: Jesper Dangaard Brouer &lt;jdb@comx.dk&gt;

Signed-off-by: Patrick McHardy &lt;kaber@trash.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>netrom: Fix sock_orphan() use in nr_release</title>
<updated>2008-10-06T19:54:57Z</updated>
<author>
<name>Jarek Poplawski</name>
<email>jarkao2@gmail.com</email>
</author>
<published>2008-10-06T19:54:57Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=859f4c74d8de4dc344b3a115367d5e22a79bddaf'/>
<id>urn:sha1:859f4c74d8de4dc344b3a115367d5e22a79bddaf</id>
<content type='text'>
While debugging another bug it was found that NetRom socks
are sometimes seen unorphaned in sk_free(). This patch moves
sock_orphan() in nr_release() to the beginning (like in ax25,
or rose).

Reported-and-tested-by: Bernard Pidoux f6bvp &lt;f6bvp@free.fr&gt;
Signed-off-by: Jarek Poplawski &lt;jarkao2@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>ax25: Quick fix for making sure unaccepted sockets get destroyed.</title>
<updated>2008-10-06T19:53:50Z</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2008-10-06T19:53:50Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=33d1d2c52c3befa6c4df33b4ba58137d1c48894b'/>
<id>urn:sha1:33d1d2c52c3befa6c4df33b4ba58137d1c48894b</id>
<content type='text'>
Since we reverted 30902dc3cb0ea1cfc7ac2b17bcf478ff98420d74 ("ax25: Fix
std timer socket destroy handling.") we have to put some kind of fix
in to cure the issue whereby unaccepted connections do not get destroyed.

The approach used here is from Tihomir Heidelberg - 9a4gl

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>Revert "ax25: Fix std timer socket destroy handling."</title>
<updated>2008-10-06T19:48:29Z</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2008-10-06T19:48:29Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=88a944eef8a4f9a2ca647eb16202a2b63f8ba7cd'/>
<id>urn:sha1:88a944eef8a4f9a2ca647eb16202a2b63f8ba7cd</id>
<content type='text'>
This reverts commit 30902dc3cb0ea1cfc7ac2b17bcf478ff98420d74.

It causes all kinds of problems, based upon a report by
Bernard (f6bvp) and analysis by Jarek Poplawski.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>af_key: Free dumping state on socket close</title>
<updated>2008-10-01T12:17:54Z</updated>
<author>
<name>Timo Teras</name>
<email>timo.teras@iki.fi</email>
</author>
<published>2008-10-01T12:17:54Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=0523820482dcb42784572ffd2296c2f08c275a2b'/>
<id>urn:sha1:0523820482dcb42784572ffd2296c2f08c275a2b</id>
<content type='text'>
Fix a xfrm_{state,policy}_walk leak if pfkey socket is closed while
dumping is on-going.

Signed-off-by: Timo Teras &lt;timo.teras@iki.fi&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
