<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/net, branch v3.4.106</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packets</title>
<updated>2015-02-02T09:05:26+00:00</updated>
<author>
<name>Ben Hutchings</name>
<email>ben@decadent.org.uk</email>
</author>
<published>2014-10-30T18:27:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e02ae9ddc8130c8a83c3439d24ac831608384fc9'/>
<id>e02ae9ddc8130c8a83c3439d24ac831608384fc9</id>
<content type='text'>
commit 5188cd44c55db3e92cd9e77a40b5baa7ed4340f7 upstream.

UFO is now disabled on all drivers that work with virtio net headers,
but userland may try to send UFO/IPv6 packets anyway.  Instead of
sending with ID=0, we should select identifiers on their behalf (as we
used to).

Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Fixes: 916e4cf46d02 ("ipv6: reuse ip6_frag_id from ip6_ufo_append_data")
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
[bwh: For 3.2, net/ipv6/output_core.c is a completely new file]
Signed-off-by: Zefan Li &lt;lizefan@huawei.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 5188cd44c55db3e92cd9e77a40b5baa7ed4340f7 upstream.

UFO is now disabled on all drivers that work with virtio net headers,
but userland may try to send UFO/IPv6 packets anyway.  Instead of
sending with ID=0, we should select identifiers on their behalf (as we
used to).

Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Fixes: 916e4cf46d02 ("ipv6: reuse ip6_frag_id from ip6_ufo_append_data")
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
[bwh: For 3.2, net/ipv6/output_core.c is a completely new file]
Signed-off-by: Zefan Li &lt;lizefan@huawei.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>can: esd_usb2: fix memory leak on disconnect</title>
<updated>2015-02-02T09:05:22+00:00</updated>
<author>
<name>Alexey Khoroshilov</name>
<email>khoroshilov@ispras.ru</email>
</author>
<published>2014-10-10T20:31:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=11c9fc9d691d0a6669319c30f4da60c1d425801e'/>
<id>11c9fc9d691d0a6669319c30f4da60c1d425801e</id>
<content type='text'>
commit efbd50d2f62fc1f69a3dcd153e63ba28cc8eb27f upstream.

It seems struct esd_usb2 dev is not deallocated on disconnect. The patch adds
the missing deallocation.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov &lt;khoroshilov@ispras.ru&gt;
Acked-by: Matthias Fuchs &lt;matthias.fuchs@esd.eu&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Zefan Li &lt;lizefan@huawei.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit efbd50d2f62fc1f69a3dcd153e63ba28cc8eb27f upstream.

It seems struct esd_usb2 dev is not deallocated on disconnect. The patch adds
the missing deallocation.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov &lt;khoroshilov@ispras.ru&gt;
Acked-by: Matthias Fuchs &lt;matthias.fuchs@esd.eu&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Zefan Li &lt;lizefan@huawei.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>can: dev: avoid calling kfree_skb() from interrupt context</title>
<updated>2015-02-02T09:05:22+00:00</updated>
<author>
<name>Thomas Körper</name>
<email>thomas.koerper@esd.eu</email>
</author>
<published>2014-10-31T06:33:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=79cbdbf4cfbba078cc8864934eaf843db6ad31c3'/>
<id>79cbdbf4cfbba078cc8864934eaf843db6ad31c3</id>
<content type='text'>
commit 5247a589c24022ab34e780039cc8000c48f2035e upstream.

ikfree_skb() is Called in can_free_echo_skb(), which might be called from (TX
Error) interrupt, which triggers the folloing warning:

[ 1153.360705] ------------[ cut here ]------------
[ 1153.360715] WARNING: CPU: 0 PID: 31 at net/core/skbuff.c:563 skb_release_head_state+0xb9/0xd0()
[ 1153.360772] Call Trace:
[ 1153.360778]  [&lt;c167906f&gt;] dump_stack+0x41/0x52
[ 1153.360782]  [&lt;c105bb7e&gt;] warn_slowpath_common+0x7e/0xa0
[ 1153.360784]  [&lt;c158b909&gt;] ? skb_release_head_state+0xb9/0xd0
[ 1153.360786]  [&lt;c158b909&gt;] ? skb_release_head_state+0xb9/0xd0
[ 1153.360788]  [&lt;c105bc42&gt;] warn_slowpath_null+0x22/0x30
[ 1153.360791]  [&lt;c158b909&gt;] skb_release_head_state+0xb9/0xd0
[ 1153.360793]  [&lt;c158be90&gt;] skb_release_all+0x10/0x30
[ 1153.360795]  [&lt;c158bf06&gt;] kfree_skb+0x36/0x80
[ 1153.360799]  [&lt;f8486938&gt;] ? can_free_echo_skb+0x28/0x40 [can_dev]
[ 1153.360802]  [&lt;f8486938&gt;] can_free_echo_skb+0x28/0x40 [can_dev]
[ 1153.360805]  [&lt;f849a12c&gt;] esd_pci402_interrupt+0x34c/0x57a [esd402]
[ 1153.360809]  [&lt;c10a75b5&gt;] handle_irq_event_percpu+0x35/0x180
[ 1153.360811]  [&lt;c10a7623&gt;] ? handle_irq_event_percpu+0xa3/0x180
[ 1153.360813]  [&lt;c10a7731&gt;] handle_irq_event+0x31/0x50
[ 1153.360816]  [&lt;c10a9c7f&gt;] handle_fasteoi_irq+0x6f/0x120
[ 1153.360818]  [&lt;c10a9c10&gt;] ? handle_edge_irq+0x110/0x110
[ 1153.360822]  [&lt;c1011b61&gt;] handle_irq+0x71/0x90
[ 1153.360823]  &lt;IRQ&gt;  [&lt;c168152c&gt;] do_IRQ+0x3c/0xd0
[ 1153.360829]  [&lt;c1680b6c&gt;] common_interrupt+0x2c/0x34
[ 1153.360834]  [&lt;c107d277&gt;] ? finish_task_switch+0x47/0xf0
[ 1153.360836]  [&lt;c167c27b&gt;] __schedule+0x35b/0x7e0
[ 1153.360839]  [&lt;c10a5334&gt;] ? console_unlock+0x2c4/0x4d0
[ 1153.360842]  [&lt;c13df500&gt;] ? n_tty_receive_buf_common+0x890/0x890
[ 1153.360845]  [&lt;c10707b6&gt;] ? process_one_work+0x196/0x370
[ 1153.360847]  [&lt;c167c723&gt;] schedule+0x23/0x60
[ 1153.360849]  [&lt;c1070de1&gt;] worker_thread+0x161/0x460
[ 1153.360852]  [&lt;c1090fcf&gt;] ? __wake_up_locked+0x1f/0x30
[ 1153.360854]  [&lt;c1070c80&gt;] ? rescuer_thread+0x2f0/0x2f0
[ 1153.360856]  [&lt;c1074f01&gt;] kthread+0xa1/0xc0
[ 1153.360859]  [&lt;c1680401&gt;] ret_from_kernel_thread+0x21/0x30
[ 1153.360861]  [&lt;c1074e60&gt;] ? kthread_create_on_node+0x110/0x110
[ 1153.360863] ---[ end trace 5ff83639cbb74b35 ]---

This patch replaces the kfree_skb() by dev_kfree_skb_any().

Signed-off-by: Thomas Körper &lt;thomas.koerper@esd.eu&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Zefan Li &lt;lizefan@huawei.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 5247a589c24022ab34e780039cc8000c48f2035e upstream.

ikfree_skb() is Called in can_free_echo_skb(), which might be called from (TX
Error) interrupt, which triggers the folloing warning:

[ 1153.360705] ------------[ cut here ]------------
[ 1153.360715] WARNING: CPU: 0 PID: 31 at net/core/skbuff.c:563 skb_release_head_state+0xb9/0xd0()
[ 1153.360772] Call Trace:
[ 1153.360778]  [&lt;c167906f&gt;] dump_stack+0x41/0x52
[ 1153.360782]  [&lt;c105bb7e&gt;] warn_slowpath_common+0x7e/0xa0
[ 1153.360784]  [&lt;c158b909&gt;] ? skb_release_head_state+0xb9/0xd0
[ 1153.360786]  [&lt;c158b909&gt;] ? skb_release_head_state+0xb9/0xd0
[ 1153.360788]  [&lt;c105bc42&gt;] warn_slowpath_null+0x22/0x30
[ 1153.360791]  [&lt;c158b909&gt;] skb_release_head_state+0xb9/0xd0
[ 1153.360793]  [&lt;c158be90&gt;] skb_release_all+0x10/0x30
[ 1153.360795]  [&lt;c158bf06&gt;] kfree_skb+0x36/0x80
[ 1153.360799]  [&lt;f8486938&gt;] ? can_free_echo_skb+0x28/0x40 [can_dev]
[ 1153.360802]  [&lt;f8486938&gt;] can_free_echo_skb+0x28/0x40 [can_dev]
[ 1153.360805]  [&lt;f849a12c&gt;] esd_pci402_interrupt+0x34c/0x57a [esd402]
[ 1153.360809]  [&lt;c10a75b5&gt;] handle_irq_event_percpu+0x35/0x180
[ 1153.360811]  [&lt;c10a7623&gt;] ? handle_irq_event_percpu+0xa3/0x180
[ 1153.360813]  [&lt;c10a7731&gt;] handle_irq_event+0x31/0x50
[ 1153.360816]  [&lt;c10a9c7f&gt;] handle_fasteoi_irq+0x6f/0x120
[ 1153.360818]  [&lt;c10a9c10&gt;] ? handle_edge_irq+0x110/0x110
[ 1153.360822]  [&lt;c1011b61&gt;] handle_irq+0x71/0x90
[ 1153.360823]  &lt;IRQ&gt;  [&lt;c168152c&gt;] do_IRQ+0x3c/0xd0
[ 1153.360829]  [&lt;c1680b6c&gt;] common_interrupt+0x2c/0x34
[ 1153.360834]  [&lt;c107d277&gt;] ? finish_task_switch+0x47/0xf0
[ 1153.360836]  [&lt;c167c27b&gt;] __schedule+0x35b/0x7e0
[ 1153.360839]  [&lt;c10a5334&gt;] ? console_unlock+0x2c4/0x4d0
[ 1153.360842]  [&lt;c13df500&gt;] ? n_tty_receive_buf_common+0x890/0x890
[ 1153.360845]  [&lt;c10707b6&gt;] ? process_one_work+0x196/0x370
[ 1153.360847]  [&lt;c167c723&gt;] schedule+0x23/0x60
[ 1153.360849]  [&lt;c1070de1&gt;] worker_thread+0x161/0x460
[ 1153.360852]  [&lt;c1090fcf&gt;] ? __wake_up_locked+0x1f/0x30
[ 1153.360854]  [&lt;c1070c80&gt;] ? rescuer_thread+0x2f0/0x2f0
[ 1153.360856]  [&lt;c1074f01&gt;] kthread+0xa1/0xc0
[ 1153.360859]  [&lt;c1680401&gt;] ret_from_kernel_thread+0x21/0x30
[ 1153.360861]  [&lt;c1074e60&gt;] ? kthread_create_on_node+0x110/0x110
[ 1153.360863] ---[ end trace 5ff83639cbb74b35 ]---

This patch replaces the kfree_skb() by dev_kfree_skb_any().

Signed-off-by: Thomas Körper &lt;thomas.koerper@esd.eu&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Zefan Li &lt;lizefan@huawei.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rt2x00: do not align payload on modern H/W</title>
<updated>2015-02-02T09:05:21+00:00</updated>
<author>
<name>Stanislaw Gruszka</name>
<email>sgruszka@redhat.com</email>
</author>
<published>2014-11-11T13:28:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4c753f06b4e4b09f85fc2bb631bc5e3787bd16d0'/>
<id>4c753f06b4e4b09f85fc2bb631bc5e3787bd16d0</id>
<content type='text'>
commit cfd9167af14eb4ec21517a32911d460083ee3d59 upstream.

RT2800 and newer hardware require padding between header and payload if
header length is not multiple of 4.

For historical reasons we also align payload to to 4 bytes boundary, but
such alignment is not needed on modern H/W.

Patch fixes skb_under_panic problems reported from time to time:

https://bugzilla.kernel.org/show_bug.cgi?id=84911
https://bugzilla.kernel.org/show_bug.cgi?id=72471
http://marc.info/?l=linux-wireless&amp;m=139108549530402&amp;w=2
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1087591

Panic happened because we eat 4 bytes of skb headroom on each
(re)transmission when sending frame without the payload and the header
length not being multiple of 4 (i.e. QoS header has 26 bytes). On such
case because paylad_aling=2 is bigger than header_align=0 we increase
header_align by 4 bytes. To prevent that we could change the check to:

	if (payload_length &amp;&amp; payload_align &gt; header_align)
		header_align += 4;

but not aligning payload at all is more effective and alignment is not
really needed by H/W (that has been tested on OpenWrt project for few
years now).

Reported-and-tested-by: Antti S. Lankila &lt;alankila@bel.fi&gt;
Debugged-by: Antti S. Lankila &lt;alankila@bel.fi&gt;
Reported-by: Henrik Asp &lt;solenskiner@gmail.com&gt;
Originally-From: Helmut Schaa &lt;helmut.schaa@googlemail.com&gt;
Signed-off-by: Stanislaw Gruszka &lt;sgruszka@redhat.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Zefan Li &lt;lizefan@huawei.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit cfd9167af14eb4ec21517a32911d460083ee3d59 upstream.

RT2800 and newer hardware require padding between header and payload if
header length is not multiple of 4.

For historical reasons we also align payload to to 4 bytes boundary, but
such alignment is not needed on modern H/W.

Patch fixes skb_under_panic problems reported from time to time:

https://bugzilla.kernel.org/show_bug.cgi?id=84911
https://bugzilla.kernel.org/show_bug.cgi?id=72471
http://marc.info/?l=linux-wireless&amp;m=139108549530402&amp;w=2
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1087591

Panic happened because we eat 4 bytes of skb headroom on each
(re)transmission when sending frame without the payload and the header
length not being multiple of 4 (i.e. QoS header has 26 bytes). On such
case because paylad_aling=2 is bigger than header_align=0 we increase
header_align by 4 bytes. To prevent that we could change the check to:

	if (payload_length &amp;&amp; payload_align &gt; header_align)
		header_align += 4;

but not aligning payload at all is more effective and alignment is not
really needed by H/W (that has been tested on OpenWrt project for few
years now).

Reported-and-tested-by: Antti S. Lankila &lt;alankila@bel.fi&gt;
Debugged-by: Antti S. Lankila &lt;alankila@bel.fi&gt;
Reported-by: Henrik Asp &lt;solenskiner@gmail.com&gt;
Originally-From: Helmut Schaa &lt;helmut.schaa@googlemail.com&gt;
Signed-off-by: Stanislaw Gruszka &lt;sgruszka@redhat.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Zefan Li &lt;lizefan@huawei.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>macvtap: Fix csum_start when VLAN tags are present</title>
<updated>2015-02-02T09:05:18+00:00</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2014-11-03T06:01:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=11e4f1f6a3ea6ed6284732b50f621974c5766f22'/>
<id>11e4f1f6a3ea6ed6284732b50f621974c5766f22</id>
<content type='text'>
commit 3ce9b20f1971690b8b3b620e735ec99431573b39 upstream.

When VLAN is in use in macvtap_put_user, we end up setting
csum_start to the wrong place.  The result is that the whoever
ends up doing the checksum setting will corrupt the packet instead
of writing the checksum to the expected location, usually this
means writing the checksum with an offset of -4.

This patch fixes this by adjusting csum_start when VLAN tags are
detected.

Fixes: f09e2249c4f5 ("macvtap: restore vlan header on user read")
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;

Cheers,
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Zefan Li &lt;lizefan@huawei.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 3ce9b20f1971690b8b3b620e735ec99431573b39 upstream.

When VLAN is in use in macvtap_put_user, we end up setting
csum_start to the wrong place.  The result is that the whoever
ends up doing the checksum setting will corrupt the packet instead
of writing the checksum to the expected location, usually this
means writing the checksum with an offset of -4.

This patch fixes this by adjusting csum_start when VLAN tags are
detected.

Fixes: f09e2249c4f5 ("macvtap: restore vlan header on user read")
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;

Cheers,
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Zefan Li &lt;lizefan@huawei.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>wireless: rt2x00: add new rt2800usb device</title>
<updated>2015-02-02T09:05:08+00:00</updated>
<author>
<name>Cyril Brulebois</name>
<email>kibi@debian.org</email>
</author>
<published>2014-10-28T15:42:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9813ed0b2d83b16206353134835a03af32701697'/>
<id>9813ed0b2d83b16206353134835a03af32701697</id>
<content type='text'>
commit 664d6a792785cc677c2091038ce10322c8d04ae1 upstream.

0x1b75 0xa200 AirLive WN-200USB wireless 11b/g/n dongle

References: https://bugs.debian.org/766802
Reported-by: Martin Mokrejs &lt;mmokrejs@fold.natur.cuni.cz&gt;
Signed-off-by: Cyril Brulebois &lt;kibi@debian.org&gt;
Acked-by: Stanislaw Gruszka &lt;sgruszka@redhat.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Zefan Li &lt;lizefan@huawei.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 664d6a792785cc677c2091038ce10322c8d04ae1 upstream.

0x1b75 0xa200 AirLive WN-200USB wireless 11b/g/n dongle

References: https://bugs.debian.org/766802
Reported-by: Martin Mokrejs &lt;mmokrejs@fold.natur.cuni.cz&gt;
Signed-off-by: Cyril Brulebois &lt;kibi@debian.org&gt;
Acked-by: Stanislaw Gruszka &lt;sgruszka@redhat.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Zefan Li &lt;lizefan@huawei.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fix misuses of f_count() in ppp and netlink</title>
<updated>2015-02-02T09:04:48+00:00</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2014-10-09T03:44:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=15c0af9cd63cf84fc7f527da7d12b80e096b60d2'/>
<id>15c0af9cd63cf84fc7f527da7d12b80e096b60d2</id>
<content type='text'>
commit 24dff96a37a2ca319e75a74d3929b2de22447ca6 upstream.

we used to check for "nobody else could start doing anything with
that opened file" by checking that refcount was 2 or less - one
for descriptor table and one we'd acquired in fget() on the way to
wherever we are.  That was race-prone (somebody else might have
had a reference to descriptor table and do fget() just as we'd
been checking) and it had become flat-out incorrect back when
we switched to fget_light() on those codepaths - unlike fget(),
it doesn't grab an extra reference unless the descriptor table
is shared.  The same change allowed a race-free check, though -
we are safe exactly when refcount is less than 2.

It was a long time ago; pre-2.6.12 for ioctl() (the codepath leading
to ppp one) and 2.6.17 for sendmsg() (netlink one).  OTOH,
netlink hadn't grown that check until 3.9 and ppp used to live
in drivers/net, not drivers/net/ppp until 3.1.  The bug existed
well before that, though, and the same fix used to apply in old
location of file.

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
[lizf: Backported to 3.4: drop the change to netlink_mmap_sendmsg()]
Signed-off-by: Zefan Li &lt;lizefan@huawei.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 24dff96a37a2ca319e75a74d3929b2de22447ca6 upstream.

we used to check for "nobody else could start doing anything with
that opened file" by checking that refcount was 2 or less - one
for descriptor table and one we'd acquired in fget() on the way to
wherever we are.  That was race-prone (somebody else might have
had a reference to descriptor table and do fget() just as we'd
been checking) and it had become flat-out incorrect back when
we switched to fget_light() on those codepaths - unlike fget(),
it doesn't grab an extra reference unless the descriptor table
is shared.  The same change allowed a race-free check, though -
we are safe exactly when refcount is less than 2.

It was a long time ago; pre-2.6.12 for ioctl() (the codepath leading
to ppp one) and 2.6.17 for sendmsg() (netlink one).  OTOH,
netlink hadn't grown that check until 3.9 and ppp used to live
in drivers/net, not drivers/net/ppp until 3.1.  The bug existed
well before that, though, and the same fix used to apply in old
location of file.

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
[lizf: Backported to 3.4: drop the change to netlink_mmap_sendmsg()]
Signed-off-by: Zefan Li &lt;lizefan@huawei.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rt2800: correct BBP1_TX_POWER_CTRL mask</title>
<updated>2015-02-02T09:04:43+00:00</updated>
<author>
<name>Stanislaw Gruszka</name>
<email>sgruszka@redhat.com</email>
</author>
<published>2014-09-24T09:24:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bbb7a273be2cd8ea01fdb8c542c120ab2ffef6ad'/>
<id>bbb7a273be2cd8ea01fdb8c542c120ab2ffef6ad</id>
<content type='text'>
commit 01f7feeaf4528bec83798316b3c811701bac5d3e upstream.

Two bits control TX power on BBP_R1 register. Correct the mask,
otherwise we clear additional bit on BBP_R1 register, what can have
unknown, possible negative effect.

Signed-off-by: Stanislaw Gruszka &lt;sgruszka@redhat.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Zefan Li &lt;lizefan@huawei.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 01f7feeaf4528bec83798316b3c811701bac5d3e upstream.

Two bits control TX power on BBP_R1 register. Correct the mask,
otherwise we clear additional bit on BBP_R1 register, what can have
unknown, possible negative effect.

Signed-off-by: Stanislaw Gruszka &lt;sgruszka@redhat.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Zefan Li &lt;lizefan@huawei.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ixgbevf: Prevent RX/TX statistics getting reset to zero</title>
<updated>2014-12-01T10:02:45+00:00</updated>
<author>
<name>Narendra K</name>
<email>narendra_k@dell.com</email>
</author>
<published>2012-07-16T15:24:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9024225cf3c5f0fe29e87aa46330d41816ca91b6'/>
<id>9024225cf3c5f0fe29e87aa46330d41816ca91b6</id>
<content type='text'>
commit 936597631dd310e220544dc5c6075d924efd39b2 upstream.

The commit 4197aa7bb81877ebb06e4f2cc1b5fea2da23a7bd implements 64 bit
per ring statistics. But the driver resets the 'total_bytes' and
'total_packets' from RX and TX rings in the RX and TX interrupt
handlers to zero. This results in statistics being lost and user space
reporting RX and TX statistics as zero. This patch addresses the
issue by preventing the resetting of RX and TX ring statistics to
zero.

Signed-off-by: Narendra K &lt;narendra_k@dell.com&gt;
Tested-by: Sibai Li &lt;sibai.li@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Cc: Weng Meiling &lt;wengmeiling.weng@huawei.com&gt;
Signed-off-by: Zefan Li &lt;lizefan@huawei.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 936597631dd310e220544dc5c6075d924efd39b2 upstream.

The commit 4197aa7bb81877ebb06e4f2cc1b5fea2da23a7bd implements 64 bit
per ring statistics. But the driver resets the 'total_bytes' and
'total_packets' from RX and TX rings in the RX and TX interrupt
handlers to zero. This results in statistics being lost and user space
reporting RX and TX statistics as zero. This patch addresses the
issue by preventing the resetting of RX and TX ring statistics to
zero.

Signed-off-by: Narendra K &lt;narendra_k@dell.com&gt;
Tested-by: Sibai Li &lt;sibai.li@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Cc: Weng Meiling &lt;wengmeiling.weng@huawei.com&gt;
Signed-off-by: Zefan Li &lt;lizefan@huawei.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rtl8192ce: Fix null dereference in watchdog</title>
<updated>2014-12-01T10:02:44+00:00</updated>
<author>
<name>Ben Hutchings</name>
<email>ben@decadent.org.uk</email>
</author>
<published>2014-04-19T13:36:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4b7f15c26a453b1aa19965d515476700b8faaa0e'/>
<id>4b7f15c26a453b1aa19965d515476700b8faaa0e</id>
<content type='text'>
Dmitry Semyonov reported that after upgrading from 3.2.54 to
3.2.57 the rtl8192ce driver will crash when its interface is brought
up.  The oops message shows:

[ 1833.611397] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
[ 1833.611455] IP: [&lt;ffffffffa0410c6a&gt;] rtl92ce_update_hal_rate_tbl+0x29/0x4db [rtl8192ce]
...
[ 1833.613326] Call Trace:
[ 1833.613346]  [&lt;ffffffffa02ad9c6&gt;] ? rtl92c_dm_watchdog+0xd0b/0xec9 [rtl8192c_common]
[ 1833.613391]  [&lt;ffffffff8105b5cf&gt;] ? process_one_work+0x161/0x269
[ 1833.613425]  [&lt;ffffffff8105c598&gt;] ? worker_thread+0xc2/0x145
[ 1833.613458]  [&lt;ffffffff8105c4d6&gt;] ? manage_workers.isra.25+0x15b/0x15b
[ 1833.613496]  [&lt;ffffffff8105f6d9&gt;] ? kthread+0x76/0x7e
[ 1833.613527]  [&lt;ffffffff81356b74&gt;] ? kernel_thread_helper+0x4/0x10
[ 1833.613563]  [&lt;ffffffff8105f663&gt;] ? kthread_worker_fn+0x139/0x139
[ 1833.613598]  [&lt;ffffffff81356b70&gt;] ? gs_change+0x13/0x13

Disassembly of rtl92ce_update_hal_rate_tbl() shows that the 'sta'
parameter was null.  None of the changes to the rtlwifi family between
3.2.54 and 3.2.57 seem to directly cause this, and reverting commit
f78bccd79ba3 ('rtlwifi: rtl8192ce: Fix too long disable of IRQs')
doesn't fix it.

rtl92c_dm_watchdog() calls rtl92ce_update_hal_rate_tbl() via
rtl92c_dm_refresh_rate_adaptive_mask(), which does not appear in the
call trace as it was inlined.  That function has been completely
removed upstream which may explain why this crash wasn't seen there.

I'm not sure that it is sensible to completely remove
rtl92c_dm_refresh_rate_adaptive_mask() without making other
compensating changes elsewhere, so try to work around this for 3.2 by
checking for a null pointer in rtl92c_dm_refresh_rate_adaptive_mask()
and then skipping the call to rtl92ce_update_hal_rate_tbl().

References: https://bugs.debian.org/745137
References: https://bugs.debian.org/745462
Reported-by: Dmitry Semyonov &lt;linulin@gmail.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Cc: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Cc: Chaoming Li &lt;chaoming_li@realsil.com.cn&gt;
Cc: Satoshi IWAMOTO &lt;satoshi.iwamoto@nifty.ne.jp&gt;
Signed-off-by: Zefan Li &lt;lizefan@huawei.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Dmitry Semyonov reported that after upgrading from 3.2.54 to
3.2.57 the rtl8192ce driver will crash when its interface is brought
up.  The oops message shows:

[ 1833.611397] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
[ 1833.611455] IP: [&lt;ffffffffa0410c6a&gt;] rtl92ce_update_hal_rate_tbl+0x29/0x4db [rtl8192ce]
...
[ 1833.613326] Call Trace:
[ 1833.613346]  [&lt;ffffffffa02ad9c6&gt;] ? rtl92c_dm_watchdog+0xd0b/0xec9 [rtl8192c_common]
[ 1833.613391]  [&lt;ffffffff8105b5cf&gt;] ? process_one_work+0x161/0x269
[ 1833.613425]  [&lt;ffffffff8105c598&gt;] ? worker_thread+0xc2/0x145
[ 1833.613458]  [&lt;ffffffff8105c4d6&gt;] ? manage_workers.isra.25+0x15b/0x15b
[ 1833.613496]  [&lt;ffffffff8105f6d9&gt;] ? kthread+0x76/0x7e
[ 1833.613527]  [&lt;ffffffff81356b74&gt;] ? kernel_thread_helper+0x4/0x10
[ 1833.613563]  [&lt;ffffffff8105f663&gt;] ? kthread_worker_fn+0x139/0x139
[ 1833.613598]  [&lt;ffffffff81356b70&gt;] ? gs_change+0x13/0x13

Disassembly of rtl92ce_update_hal_rate_tbl() shows that the 'sta'
parameter was null.  None of the changes to the rtlwifi family between
3.2.54 and 3.2.57 seem to directly cause this, and reverting commit
f78bccd79ba3 ('rtlwifi: rtl8192ce: Fix too long disable of IRQs')
doesn't fix it.

rtl92c_dm_watchdog() calls rtl92ce_update_hal_rate_tbl() via
rtl92c_dm_refresh_rate_adaptive_mask(), which does not appear in the
call trace as it was inlined.  That function has been completely
removed upstream which may explain why this crash wasn't seen there.

I'm not sure that it is sensible to completely remove
rtl92c_dm_refresh_rate_adaptive_mask() without making other
compensating changes elsewhere, so try to work around this for 3.2 by
checking for a null pointer in rtl92c_dm_refresh_rate_adaptive_mask()
and then skipping the call to rtl92ce_update_hal_rate_tbl().

References: https://bugs.debian.org/745137
References: https://bugs.debian.org/745462
Reported-by: Dmitry Semyonov &lt;linulin@gmail.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Cc: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Cc: Chaoming Li &lt;chaoming_li@realsil.com.cn&gt;
Cc: Satoshi IWAMOTO &lt;satoshi.iwamoto@nifty.ne.jp&gt;
Signed-off-by: Zefan Li &lt;lizefan@huawei.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
