<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/net, branch v3.4.58</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>8139cp: Add dma_mapping_error checking</title>
<updated>2013-08-11T22:38:45+00:00</updated>
<author>
<name>Neil Horman</name>
<email>nhorman@tuxdriver.com</email>
</author>
<published>2013-07-31T13:03:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=249b3ecb840cdddd94103fb68d91b0dbb650064f'/>
<id>249b3ecb840cdddd94103fb68d91b0dbb650064f</id>
<content type='text'>
[ Upstream commit cf3c4c03060b688cbc389ebc5065ebcce5653e96 ]

Self explanitory dma_mapping_error addition to the 8139 driver, based on this:
https://bugzilla.redhat.com/show_bug.cgi?id=947250

It showed several backtraces arising for dma_map_* usage without checking the
return code on the mapping.  Add the check and abort the rx/tx operation if its
failed.  Untested as I have no hardware and the reporter has wandered off, but
seems pretty straightforward.

Signed-off-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
CC: "David S. Miller" &lt;davem@davemloft.net&gt;
CC: Francois Romieu &lt;romieu@fr.zoreil.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit cf3c4c03060b688cbc389ebc5065ebcce5653e96 ]

Self explanitory dma_mapping_error addition to the 8139 driver, based on this:
https://bugzilla.redhat.com/show_bug.cgi?id=947250

It showed several backtraces arising for dma_map_* usage without checking the
return code on the mapping.  Add the check and abort the rx/tx operation if its
failed.  Untested as I have no hardware and the reporter has wandered off, but
seems pretty straightforward.

Signed-off-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
CC: "David S. Miller" &lt;davem@davemloft.net&gt;
CC: Francois Romieu &lt;romieu@fr.zoreil.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usbnet: do not pretend to support SG/TSO</title>
<updated>2013-08-11T22:38:44+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2013-07-24T00:15:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d8c47c3fdc007ff3efecca98881e8e91eb088d70'/>
<id>d8c47c3fdc007ff3efecca98881e8e91eb088d70</id>
<content type='text'>
[ Upstream commit 20f0170377264e8449b6987041f0bcc4d746d3ed ]

usbnet doesn't support yet SG, so drivers should not advertise SG or TSO
capabilities, as they allow TCP stack to build large TSO packets that
need to be linearized and might use order-5 pages.

This adds an extra copy overhead and possible allocation failures.

Current code ignore skb_linearize() return code so crashes are even
possible.

Best is to not pretend SG/TSO is supported, and add this again when/if
usbnet really supports SG for devices who could get a performance gain.

Based on a prior patch from Freddy Xin &lt;freddy@asix.com.tw&gt;

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 20f0170377264e8449b6987041f0bcc4d746d3ed ]

usbnet doesn't support yet SG, so drivers should not advertise SG or TSO
capabilities, as they allow TCP stack to build large TSO packets that
need to be linearized and might use order-5 pages.

This adds an extra copy overhead and possible allocation failures.

Current code ignore skb_linearize() return code so crashes are even
possible.

Best is to not pretend SG/TSO is supported, and add this again when/if
usbnet really supports SG for devices who could get a performance gain.

Based on a prior patch from Freddy Xin &lt;freddy@asix.com.tw&gt;

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arcnet: cleanup sizeof parameter</title>
<updated>2013-08-11T22:38:44+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2013-07-19T05:48:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c062773fe4a98d935335b75e75c0d1a14a29b680'/>
<id>c062773fe4a98d935335b75e75c0d1a14a29b680</id>
<content type='text'>
[ Upstream commit 087d273caf4f7d3f2159256f255f1f432bc84a5b ]

This patch doesn't change the compiled code because ARC_HDR_SIZE is 4
and sizeof(int) is 4, but the intent was to use the header size and not
the sizeof the header size.

Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 087d273caf4f7d3f2159256f255f1f432bc84a5b ]

This patch doesn't change the compiled code because ARC_HDR_SIZE is 4
and sizeof(int) is 4, but the intent was to use the header size and not
the sizeof the header size.

Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mwifiex: Add missing endian conversion.</title>
<updated>2013-08-11T22:38:42+00:00</updated>
<author>
<name>Tomasz Moń</name>
<email>desowin@gmail.com</email>
</author>
<published>2013-07-23T05:42:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=33f91a1a3ae65f7cd175767c2a27357b63be4ba4'/>
<id>33f91a1a3ae65f7cd175767c2a27357b63be4ba4</id>
<content type='text'>
commit 83e612f632c3897be29ef02e0472f6d63e258378 upstream.

Both type and pkt_len variables are in host endian and these should be in
Little Endian in the payload.

Signed-off-by: Tomasz Moń &lt;desowin@gmail.com&gt;
Acked-by: Bing Zhao &lt;bzhao@marvell.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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

Both type and pkt_len variables are in host endian and these should be in
Little Endian in the payload.

Signed-off-by: Tomasz Moń &lt;desowin@gmail.com&gt;
Acked-by: Bing Zhao &lt;bzhao@marvell.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>rt2x00: fix stop queue</title>
<updated>2013-08-11T22:38:42+00:00</updated>
<author>
<name>Stanislaw Gruszka</name>
<email>stf_xl@wp.pl</email>
</author>
<published>2013-07-28T11:17:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f1b3ecc5a1d7e0f3e6ac108ac0f98f7756afd8c2'/>
<id>f1b3ecc5a1d7e0f3e6ac108ac0f98f7756afd8c2</id>
<content type='text'>
commit e2288b66fe7ff0288382b2af671b4da558b44472 upstream.

Since we clear QUEUE_STARTED in rt2x00queue_stop_queue(), following
call to rt2x00queue_pause_queue() reduce to noop, i.e we do not
stop queue in mac80211.

To fix that introduce rt2x00queue_pause_queue_nocheck() function,
which will stop queue in mac80211 directly.

Note that rt2x00_start_queue() explicitly set QUEUE_PAUSED bit.

Note also that reordering operations i.e. first call to
rt2x00queue_pause_queue() and then clear QUEUE_STARTED bit, will race
with rt2x00queue_unpause_queue(), so calling ieee80211_stop_queue()
directly is the only available solution to fix the problem without
major rework.

Signed-off-by: Stanislaw Gruszka &lt;stf_xl@wp.pl&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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

Since we clear QUEUE_STARTED in rt2x00queue_stop_queue(), following
call to rt2x00queue_pause_queue() reduce to noop, i.e we do not
stop queue in mac80211.

To fix that introduce rt2x00queue_pause_queue_nocheck() function,
which will stop queue in mac80211 directly.

Note that rt2x00_start_queue() explicitly set QUEUE_PAUSED bit.

Note also that reordering operations i.e. first call to
rt2x00queue_pause_queue() and then clear QUEUE_STARTED bit, will race
with rt2x00queue_unpause_queue(), so calling ieee80211_stop_queue()
directly is the only available solution to fix the problem without
major rework.

Signed-off-by: Stanislaw Gruszka &lt;stf_xl@wp.pl&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ixgbe: Fix Tx Hang issue with lldpad on 82598EB</title>
<updated>2013-08-11T22:38:42+00:00</updated>
<author>
<name>Jacob Keller</name>
<email>jacob.e.keller@intel.com</email>
</author>
<published>2013-07-26T12:46:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=167ef7af3d8b524bd448c79dc77943b1ab26db97'/>
<id>167ef7af3d8b524bd448c79dc77943b1ab26db97</id>
<content type='text'>
commit 1eb9ac14c34a948bf1538bfb9034e8ab29099a64 upstream.

This patch fixes an issue with the 82598EB device, where lldpad is causing Tx
Hangs on the card as soon as it attempts to configure DCB for the device. The
adapter will continually Tx hang and reset in a loop.

Signed-off-by: Jacob Keller &lt;jacob.e.keller@intel.com&gt;
Tested-by: Phil Schmitt &lt;phillip.j.schmitt@intel.com&gt;
Tested-by: Jack Morgan &lt;jack.morgan@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;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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

This patch fixes an issue with the 82598EB device, where lldpad is causing Tx
Hangs on the card as soon as it attempts to configure DCB for the device. The
adapter will continually Tx hang and reset in a loop.

Signed-off-by: Jacob Keller &lt;jacob.e.keller@intel.com&gt;
Tested-by: Phil Schmitt &lt;phillip.j.schmitt@intel.com&gt;
Tested-by: Jack Morgan &lt;jack.morgan@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;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ath9k_htc: do some initial hardware configuration</title>
<updated>2013-08-11T22:38:41+00:00</updated>
<author>
<name>Oleksij Rempel</name>
<email>linux@rempel-privat.de</email>
</author>
<published>2013-07-19T18:16:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a73957de8737be6932d1c52a9799cf1eb510b338'/>
<id>a73957de8737be6932d1c52a9799cf1eb510b338</id>
<content type='text'>
commit dc2a87f519a4d8cb376ab54f22b6b98a943b51ce upstream.

Currently we configure harwdare and clock, only after
interface start. In this case, if we reload module or
reboot PC without configuring adapter, firmware will freeze.
There is no software way to reset adpter.

This patch add initial configuration and set it in
disabled state, to avoid this freeze. Behaviour of this patch
should be similar to: ifconfig wlan0 up; ifconfig wlan0 down.

Bug: https://github.com/qca/open-ath9k-htc-firmware/issues/1
Tested-by: Bo Shi &lt;cnshibo@gmail.com&gt;
Signed-off-by: Oleksij Rempel &lt;linux@rempel-privat.de&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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

Currently we configure harwdare and clock, only after
interface start. In this case, if we reload module or
reboot PC without configuring adapter, firmware will freeze.
There is no software way to reset adpter.

This patch add initial configuration and set it in
disabled state, to avoid this freeze. Behaviour of this patch
should be similar to: ifconfig wlan0 up; ifconfig wlan0 down.

Bug: https://github.com/qca/open-ath9k-htc-firmware/issues/1
Tested-by: Bo Shi &lt;cnshibo@gmail.com&gt;
Signed-off-by: Oleksij Rempel &lt;linux@rempel-privat.de&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>virtio_net: fix race in RX VQ processing</title>
<updated>2013-08-04T08:26:06+00:00</updated>
<author>
<name>Michael S. Tsirkin</name>
<email>mst@redhat.com</email>
</author>
<published>2013-08-04T08:26:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=40a017c96a98a29c9d39bf0ca34651288984e9ce'/>
<id>40a017c96a98a29c9d39bf0ca34651288984e9ce</id>
<content type='text'>
commit cbdadbbf0c790f79350a8f36029208944c5487d0 upstream

virtio net called virtqueue_enable_cq on RX path after napi_complete, so
with NAPI_STATE_SCHED clear - outside the implicit napi lock.
This violates the requirement to synchronize virtqueue_enable_cq wrt
virtqueue_add_buf.  In particular, used event can move backwards,
causing us to lose interrupts.
In a debug build, this can trigger panic within START_USE.

Jason Wang reports that he can trigger the races artificially,
by adding udelay() in virtqueue_enable_cb() after virtio_mb().

However, we must call napi_complete to clear NAPI_STATE_SCHED before
polling the virtqueue for used buffers, otherwise napi_schedule_prep in
a callback will fail, causing us to lose RX events.

To fix, call virtqueue_enable_cb_prepare with NAPI_STATE_SCHED
set (under napi lock), later call virtqueue_poll with
NAPI_STATE_SCHED clear (outside the lock).

Reported-by: Jason Wang &lt;jasowang@redhat.com&gt;
Tested-by: Jason Wang &lt;jasowang@redhat.com&gt;
Acked-by: Jason Wang &lt;jasowang@redhat.com&gt;
Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
[wg: Backported to 3.2]
Signed-off-by: Wolfram Gloger &lt;wmglo@dent.med.uni-muenchen.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit cbdadbbf0c790f79350a8f36029208944c5487d0 upstream

virtio net called virtqueue_enable_cq on RX path after napi_complete, so
with NAPI_STATE_SCHED clear - outside the implicit napi lock.
This violates the requirement to synchronize virtqueue_enable_cq wrt
virtqueue_add_buf.  In particular, used event can move backwards,
causing us to lose interrupts.
In a debug build, this can trigger panic within START_USE.

Jason Wang reports that he can trigger the races artificially,
by adding udelay() in virtqueue_enable_cb() after virtio_mb().

However, we must call napi_complete to clear NAPI_STATE_SCHED before
polling the virtqueue for used buffers, otherwise napi_schedule_prep in
a callback will fail, causing us to lose RX events.

To fix, call virtqueue_enable_cb_prepare with NAPI_STATE_SCHED
set (under napi lock), later call virtqueue_poll with
NAPI_STATE_SCHED clear (outside the lock).

Reported-by: Jason Wang &lt;jasowang@redhat.com&gt;
Tested-by: Jason Wang &lt;jasowang@redhat.com&gt;
Acked-by: Jason Wang &lt;jasowang@redhat.com&gt;
Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
[wg: Backported to 3.2]
Signed-off-by: Wolfram Gloger &lt;wmglo@dent.med.uni-muenchen.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>atl1e: unmap partially mapped skb on dma error and free skb</title>
<updated>2013-07-28T23:26:08+00:00</updated>
<author>
<name>Neil Horman</name>
<email>nhorman@tuxdriver.com</email>
</author>
<published>2013-07-16T14:49:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b64a172c19b49fb8583efc379535341cc537cfc2'/>
<id>b64a172c19b49fb8583efc379535341cc537cfc2</id>
<content type='text'>
[ Upstream commit 584ec4355355ffac43571b02a314d43eb2f7fcbf ]

Ben Hutchings pointed out that my recent update to atl1e
in commit 352900b583b2852152a1e05ea0e8b579292e731e
("atl1e: fix dma mapping warnings") was missing a bit of code.

Specifically it reset the hardware tx ring to its origional state when
we hit a dma error, but didn't unmap any exiting mappings from the
operation.  This patch fixes that up.  It also remembers to free the
skb in the event that an error occurs, so we don't leak.  Untested, as
I don't have hardware.  I think its pretty straightforward, but please
review closely.

Signed-off-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
CC: Ben Hutchings &lt;bhutchings@solarflare.com&gt;
CC: Jay Cliburn &lt;jcliburn@gmail.com&gt;
CC: Chris Snook &lt;chris.snook@gmail.com&gt;
CC: "David S. Miller" &lt;davem@davemloft.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 584ec4355355ffac43571b02a314d43eb2f7fcbf ]

Ben Hutchings pointed out that my recent update to atl1e
in commit 352900b583b2852152a1e05ea0e8b579292e731e
("atl1e: fix dma mapping warnings") was missing a bit of code.

Specifically it reset the hardware tx ring to its origional state when
we hit a dma error, but didn't unmap any exiting mappings from the
operation.  This patch fixes that up.  It also remembers to free the
skb in the event that an error occurs, so we don't leak.  Untested, as
I don't have hardware.  I think its pretty straightforward, but please
review closely.

Signed-off-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
CC: Ben Hutchings &lt;bhutchings@solarflare.com&gt;
CC: Jay Cliburn &lt;jcliburn@gmail.com&gt;
CC: Chris Snook &lt;chris.snook@gmail.com&gt;
CC: "David S. Miller" &lt;davem@davemloft.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>atl1e: fix dma mapping warnings</title>
<updated>2013-07-28T23:26:08+00:00</updated>
<author>
<name>Neil Horman</name>
<email>nhorman@tuxdriver.com</email>
</author>
<published>2013-07-12T14:58:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2cb9c95527519e0dad2bacc2f8a6271aa290f491'/>
<id>2cb9c95527519e0dad2bacc2f8a6271aa290f491</id>
<content type='text'>
[ Upstream commit 352900b583b2852152a1e05ea0e8b579292e731e ]

Recently had this backtrace reported:
WARNING: at lib/dma-debug.c:937 check_unmap+0x47d/0x930()
Hardware name: System Product Name
ATL1E 0000:02:00.0: DMA-API: device driver failed to check map error[device
address=0x00000000cbfd1000] [size=90 bytes] [mapped as single]
Modules linked in: xt_conntrack nf_conntrack ebtable_filter ebtables
ip6table_filter ip6_tables snd_hda_codec_hdmi snd_hda_codec_realtek iTCO_wdt
iTCO_vendor_support snd_hda_intel acpi_cpufreq mperf coretemp btrfs zlib_deflate
snd_hda_codec snd_hwdep microcode raid6_pq libcrc32c snd_seq usblp serio_raw xor
snd_seq_device joydev snd_pcm snd_page_alloc snd_timer snd lpc_ich i2c_i801
soundcore mfd_core atl1e asus_atk0110 ata_generic pata_acpi radeon i2c_algo_bit
drm_kms_helper ttm drm i2c_core pata_marvell uinput
Pid: 314, comm: systemd-journal Not tainted 3.9.0-0.rc6.git2.3.fc19.x86_64 #1
Call Trace:
 &lt;IRQ&gt;  [&lt;ffffffff81069106&gt;] warn_slowpath_common+0x66/0x80
 [&lt;ffffffff8106916c&gt;] warn_slowpath_fmt+0x4c/0x50
 [&lt;ffffffff8138151d&gt;] check_unmap+0x47d/0x930
 [&lt;ffffffff810ad048&gt;] ? sched_clock_cpu+0xa8/0x100
 [&lt;ffffffff81381a2f&gt;] debug_dma_unmap_page+0x5f/0x70
 [&lt;ffffffff8137ce30&gt;] ? unmap_single+0x20/0x30
 [&lt;ffffffffa01569a1&gt;] atl1e_intr+0x3a1/0x5b0 [atl1e]
 [&lt;ffffffff810d53fd&gt;] ? trace_hardirqs_off+0xd/0x10
 [&lt;ffffffff81119636&gt;] handle_irq_event_percpu+0x56/0x390
 [&lt;ffffffff811199ad&gt;] handle_irq_event+0x3d/0x60
 [&lt;ffffffff8111cb6a&gt;] handle_fasteoi_irq+0x5a/0x100
 [&lt;ffffffff8101c36f&gt;] handle_irq+0xbf/0x150
 [&lt;ffffffff811dcb2f&gt;] ? file_sb_list_del+0x3f/0x50
 [&lt;ffffffff81073b10&gt;] ? irq_enter+0x50/0xa0
 [&lt;ffffffff8172738d&gt;] do_IRQ+0x4d/0xc0
 [&lt;ffffffff811dcb2f&gt;] ? file_sb_list_del+0x3f/0x50
 [&lt;ffffffff8171c6b2&gt;] common_interrupt+0x72/0x72
 &lt;EOI&gt;  [&lt;ffffffff810db5b2&gt;] ? lock_release+0xc2/0x310
 [&lt;ffffffff8109ea04&gt;] lg_local_unlock_cpu+0x24/0x50
 [&lt;ffffffff811dcb2f&gt;] file_sb_list_del+0x3f/0x50
 [&lt;ffffffff811dcb6d&gt;] fput+0x2d/0xc0
 [&lt;ffffffff811d8ea1&gt;] filp_close+0x61/0x90
 [&lt;ffffffff811fae4d&gt;] __close_fd+0x8d/0x150
 [&lt;ffffffff811d8ef0&gt;] sys_close+0x20/0x50
 [&lt;ffffffff81725699&gt;] system_call_fastpath+0x16/0x1b

The usual straighforward failure to check for dma_mapping_error after a map
operation is completed.

This patch should fix it, the reporter wandered off after filing this bz:
https://bugzilla.redhat.com/show_bug.cgi?id=954170

and I don't have hardware to test, but the fix is pretty straightforward, so I
figured I'd post it for review.

Signed-off-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
CC: Jay Cliburn &lt;jcliburn@gmail.com&gt;
CC: Chris Snook &lt;chris.snook@gmail.com&gt;
CC: "David S. Miller" &lt;davem@davemloft.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 352900b583b2852152a1e05ea0e8b579292e731e ]

Recently had this backtrace reported:
WARNING: at lib/dma-debug.c:937 check_unmap+0x47d/0x930()
Hardware name: System Product Name
ATL1E 0000:02:00.0: DMA-API: device driver failed to check map error[device
address=0x00000000cbfd1000] [size=90 bytes] [mapped as single]
Modules linked in: xt_conntrack nf_conntrack ebtable_filter ebtables
ip6table_filter ip6_tables snd_hda_codec_hdmi snd_hda_codec_realtek iTCO_wdt
iTCO_vendor_support snd_hda_intel acpi_cpufreq mperf coretemp btrfs zlib_deflate
snd_hda_codec snd_hwdep microcode raid6_pq libcrc32c snd_seq usblp serio_raw xor
snd_seq_device joydev snd_pcm snd_page_alloc snd_timer snd lpc_ich i2c_i801
soundcore mfd_core atl1e asus_atk0110 ata_generic pata_acpi radeon i2c_algo_bit
drm_kms_helper ttm drm i2c_core pata_marvell uinput
Pid: 314, comm: systemd-journal Not tainted 3.9.0-0.rc6.git2.3.fc19.x86_64 #1
Call Trace:
 &lt;IRQ&gt;  [&lt;ffffffff81069106&gt;] warn_slowpath_common+0x66/0x80
 [&lt;ffffffff8106916c&gt;] warn_slowpath_fmt+0x4c/0x50
 [&lt;ffffffff8138151d&gt;] check_unmap+0x47d/0x930
 [&lt;ffffffff810ad048&gt;] ? sched_clock_cpu+0xa8/0x100
 [&lt;ffffffff81381a2f&gt;] debug_dma_unmap_page+0x5f/0x70
 [&lt;ffffffff8137ce30&gt;] ? unmap_single+0x20/0x30
 [&lt;ffffffffa01569a1&gt;] atl1e_intr+0x3a1/0x5b0 [atl1e]
 [&lt;ffffffff810d53fd&gt;] ? trace_hardirqs_off+0xd/0x10
 [&lt;ffffffff81119636&gt;] handle_irq_event_percpu+0x56/0x390
 [&lt;ffffffff811199ad&gt;] handle_irq_event+0x3d/0x60
 [&lt;ffffffff8111cb6a&gt;] handle_fasteoi_irq+0x5a/0x100
 [&lt;ffffffff8101c36f&gt;] handle_irq+0xbf/0x150
 [&lt;ffffffff811dcb2f&gt;] ? file_sb_list_del+0x3f/0x50
 [&lt;ffffffff81073b10&gt;] ? irq_enter+0x50/0xa0
 [&lt;ffffffff8172738d&gt;] do_IRQ+0x4d/0xc0
 [&lt;ffffffff811dcb2f&gt;] ? file_sb_list_del+0x3f/0x50
 [&lt;ffffffff8171c6b2&gt;] common_interrupt+0x72/0x72
 &lt;EOI&gt;  [&lt;ffffffff810db5b2&gt;] ? lock_release+0xc2/0x310
 [&lt;ffffffff8109ea04&gt;] lg_local_unlock_cpu+0x24/0x50
 [&lt;ffffffff811dcb2f&gt;] file_sb_list_del+0x3f/0x50
 [&lt;ffffffff811dcb6d&gt;] fput+0x2d/0xc0
 [&lt;ffffffff811d8ea1&gt;] filp_close+0x61/0x90
 [&lt;ffffffff811fae4d&gt;] __close_fd+0x8d/0x150
 [&lt;ffffffff811d8ef0&gt;] sys_close+0x20/0x50
 [&lt;ffffffff81725699&gt;] system_call_fastpath+0x16/0x1b

The usual straighforward failure to check for dma_mapping_error after a map
operation is completed.

This patch should fix it, the reporter wandered off after filing this bz:
https://bugzilla.redhat.com/show_bug.cgi?id=954170

and I don't have hardware to test, but the fix is pretty straightforward, so I
figured I'd post it for review.

Signed-off-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
CC: Jay Cliburn &lt;jcliburn@gmail.com&gt;
CC: Chris Snook &lt;chris.snook@gmail.com&gt;
CC: "David S. Miller" &lt;davem@davemloft.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
