* [PATCH net-next 02/13] tg3: Cleanup transmit error path
@ 2011-05-19 22:12 Matt Carlson
2011-06-02 22:18 ` [net-next,02/13] " Alex Williamson
0 siblings, 1 reply; 5+ messages in thread
From: Matt Carlson @ 2011-05-19 22:12 UTC (permalink / raw)
To: davem; +Cc: netdev, mcarlson
This patch consolidates the skb cleanup code into a function named
tg3_skb_error_unmap(). The modification addresses a long-standing bug
where pci_unmap_single() was incorrectly being called instead of
pci_unmap_page() in tigon3_dma_hwbug_workaround().
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/tg3.c | 98 ++++++++++++++++++++--------------------------------
1 files changed, 38 insertions(+), 60 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 4c44168..b2b1ba1 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -5758,16 +5758,39 @@ static void tg3_set_txd(struct tg3_napi *tnapi, int entry,
txd->vlan_tag = vlan_tag << TXD_VLAN_TAG_SHIFT;
}
+static void tg3_skb_error_unmap(struct tg3_napi *tnapi,
+ struct sk_buff *skb, int last)
+{
+ int i;
+ u32 entry = tnapi->tx_prod;
+ struct ring_info *txb = &tnapi->tx_buffers[entry];
+
+ pci_unmap_single(tnapi->tp->pdev,
+ dma_unmap_addr(txb, mapping),
+ skb_headlen(skb),
+ PCI_DMA_TODEVICE);
+ for (i = 0; i <= last; i++) {
+ skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
+
+ entry = NEXT_TX(entry);
+ txb = &tnapi->tx_buffers[entry];
+
+ pci_unmap_page(tnapi->tp->pdev,
+ dma_unmap_addr(txb, mapping),
+ frag->size, PCI_DMA_TODEVICE);
+ }
+}
+
/* Workaround 4GB and 40-bit hardware DMA bugs. */
static int tigon3_dma_hwbug_workaround(struct tg3_napi *tnapi,
- struct sk_buff *skb, u32 last_plus_one,
- u32 *start, u32 base_flags, u32 mss)
+ struct sk_buff *skb,
+ u32 base_flags, u32 mss)
{
struct tg3 *tp = tnapi->tp;
struct sk_buff *new_skb;
dma_addr_t new_addr = 0;
- u32 entry = *start;
- int i, ret = 0;
+ u32 entry = tnapi->tx_prod;
+ int ret = 0;
if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5701)
new_skb = skb_copy(skb, GFP_ATOMIC);
@@ -5783,14 +5806,12 @@ static int tigon3_dma_hwbug_workaround(struct tg3_napi *tnapi,
ret = -1;
} else {
/* New SKB is guaranteed to be linear. */
- entry = *start;
new_addr = pci_map_single(tp->pdev, new_skb->data, new_skb->len,
PCI_DMA_TODEVICE);
/* Make sure the mapping succeeded */
if (pci_dma_mapping_error(tp->pdev, new_addr)) {
ret = -1;
dev_kfree_skb(new_skb);
- new_skb = NULL;
/* Make sure new skb does not cross any 4G boundaries.
* Drop the packet if it does.
@@ -5801,39 +5822,16 @@ static int tigon3_dma_hwbug_workaround(struct tg3_napi *tnapi,
PCI_DMA_TODEVICE);
ret = -1;
dev_kfree_skb(new_skb);
- new_skb = NULL;
} else {
+ tnapi->tx_buffers[entry].skb = new_skb;
+ dma_unmap_addr_set(&tnapi->tx_buffers[entry],
+ mapping, new_addr);
+
tg3_set_txd(tnapi, entry, new_addr, new_skb->len,
base_flags, 1 | (mss << 1));
- *start = NEXT_TX(entry);
}
}
- /* Now clean up the sw ring entries. */
- i = 0;
- while (entry != last_plus_one) {
- int len;
-
- if (i == 0)
- len = skb_headlen(skb);
- else
- len = skb_shinfo(skb)->frags[i-1].size;
-
- pci_unmap_single(tp->pdev,
- dma_unmap_addr(&tnapi->tx_buffers[entry],
- mapping),
- len, PCI_DMA_TODEVICE);
- if (i == 0) {
- tnapi->tx_buffers[entry].skb = new_skb;
- dma_unmap_addr_set(&tnapi->tx_buffers[entry], mapping,
- new_addr);
- } else {
- tnapi->tx_buffers[entry].skb = NULL;
- }
- entry = NEXT_TX(entry);
- i++;
- }
-
dev_kfree_skb(skb);
return ret;
@@ -5889,11 +5887,11 @@ static netdev_tx_t tg3_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct tg3 *tp = netdev_priv(dev);
u32 len, entry, base_flags, mss;
- int would_hit_hwbug;
+ int i = -1, would_hit_hwbug;
dma_addr_t mapping;
struct tg3_napi *tnapi;
struct netdev_queue *txq;
- unsigned int i, last;
+ unsigned int last;
txq = netdev_get_tx_queue(dev, skb_get_queue_mapping(skb));
tnapi = &tp->napi[skb_get_queue_mapping(skb)];
@@ -6074,20 +6072,15 @@ static netdev_tx_t tg3_start_xmit(struct sk_buff *skb, struct net_device *dev)
}
if (would_hit_hwbug) {
- u32 last_plus_one = entry;
- u32 start;
-
- start = entry - 1 - skb_shinfo(skb)->nr_frags;
- start &= (TG3_TX_RING_SIZE - 1);
+ tg3_skb_error_unmap(tnapi, skb, i);
/* If the workaround fails due to memory/mapping
* failure, silently drop this packet.
*/
- if (tigon3_dma_hwbug_workaround(tnapi, skb, last_plus_one,
- &start, base_flags, mss))
+ if (tigon3_dma_hwbug_workaround(tnapi, skb, base_flags, mss))
goto out_unlock;
- entry = start;
+ entry = NEXT_TX(tnapi->tx_prod);
}
/* Packets are ready, update Tx producer idx local and on card. */
@@ -6113,24 +6106,9 @@ out_unlock:
return NETDEV_TX_OK;
dma_error:
- last = i;
- entry = tnapi->tx_prod;
- tnapi->tx_buffers[entry].skb = NULL;
- pci_unmap_single(tp->pdev,
- dma_unmap_addr(&tnapi->tx_buffers[entry], mapping),
- skb_headlen(skb),
- PCI_DMA_TODEVICE);
- for (i = 0; i <= last; i++) {
- skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
- entry = NEXT_TX(entry);
-
- pci_unmap_page(tp->pdev,
- dma_unmap_addr(&tnapi->tx_buffers[entry],
- mapping),
- frag->size, PCI_DMA_TODEVICE);
- }
-
+ tg3_skb_error_unmap(tnapi, skb, i);
dev_kfree_skb(skb);
+ tnapi->tx_buffers[tnapi->tx_prod].skb = NULL;
return NETDEV_TX_OK;
}
--
1.7.3.4
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [net-next,02/13] tg3: Cleanup transmit error path
2011-05-19 22:12 [PATCH net-next 02/13] tg3: Cleanup transmit error path Matt Carlson
@ 2011-06-02 22:18 ` Alex Williamson
2011-06-02 23:01 ` Matt Carlson
0 siblings, 1 reply; 5+ messages in thread
From: Alex Williamson @ 2011-06-02 22:18 UTC (permalink / raw)
To: Matt Carlson; +Cc: davem, netdev
On Thu, 2011-05-19 at 12:12 +0000, Matt Carlson wrote:
> This patch consolidates the skb cleanup code into a function named
> tg3_skb_error_unmap(). The modification addresses a long-standing bug
> where pci_unmap_single() was incorrectly being called instead of
> pci_unmap_page() in tigon3_dma_hwbug_workaround().
This patch doesn't behave well when an iommu (VT-d) is involved.
Booting an X58 chipset based system with intel_iommu=on with 3.0.0-rc1
results in the warning below. Looks like the driver is trying to unmap
0x0. Eventually something worse happens and the system reports a few
iommu faults from the device before panicing. Neither problem is
observed if 432aa7ed is reverted. tg3 device in use is a BCM5755.
Thanks,
Alex
WARNING: at drivers/pci/intel-iommu.c:2888 intel_unmap_page+0x15c/0x180()
Hardware name: 4157CTO
Driver unmaps unmatched page at PFN 0
Modules linked in: nfs lockd auth_rpcgss nfs_acl ipt_MASQUERADE iptable_nat nf_nat iptable_mangle tun autofs4 sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf bridge stp llc ipv6 dm_mirror dm_region_hash dm_log kvm_intel kvm sg microcode serio_raw wmi i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support tg3 ext4 mbcache jbd2 raid1 raid456 async_pq async_xor xor async_memcpy async_raid6_recov raid6_pq async_tx sr_mod cdrom sd_mod crc_t10dif floppy dm_mod [last unloaded: scsi_wait_scan]
Pid: 2604, comm: libvirtd Not tainted 3.0.0-rc1+ #184
Call Trace:
[<ffffffff8105c7df>] warn_slowpath_common+0x7f/0xc0
[<ffffffff8105c8d6>] warn_slowpath_fmt+0x46/0x50
[<ffffffff81245b8b>] ? find_iova+0x5b/0xa0
[<ffffffff8124a60c>] intel_unmap_page+0x15c/0x180
[<ffffffffa0128d48>] tg3_skb_error_unmap+0xb8/0x130 [tg3]
[<ffffffffa0136041>] tg3_start_xmit+0x661/0xde0 [tg3]
[<ffffffffa01363dd>] ? tg3_start_xmit+0x9fd/0xde0 [tg3]
[<ffffffff8138d7fe>] dev_hard_start_xmit+0x31e/0x6c0
[<ffffffff813a9f5f>] sch_direct_xmit+0xef/0x1c0
[<ffffffff8138dd38>] dev_queue_xmit+0x198/0x5f0
[<ffffffffa028d2ac>] br_dev_queue_push_xmit+0x6c/0xa0 [bridge]
[<ffffffffa028d478>] br_forward_finish+0x58/0x60 [bridge]
[<ffffffffa028d4f8>] __br_deliver+0x78/0xf0 [bridge]
[<ffffffff814367a9>] ? packet_rcv+0x59/0x450
[<ffffffffa028d5a5>] br_deliver+0x35/0x40 [bridge]
[<ffffffffa028b8c4>] br_dev_xmit+0x114/0x180 [bridge]
[<ffffffff8138d7fe>] dev_hard_start_xmit+0x31e/0x6c0
[<ffffffff8138df95>] dev_queue_xmit+0x3f5/0x5f0
[<ffffffff813d0c2e>] ip_finish_output+0x16e/0x340
[<ffffffff813d1110>] ip_output+0xb0/0xc0
[<ffffffff813cfdc3>] ? __ip_local_out+0xa3/0xb0
[<ffffffff813d0129>] ip_local_out+0x29/0x30
[<ffffffff813d0604>] ip_queue_xmit+0x164/0x410
[<ffffffff813e5e5c>] tcp_transmit_skb+0x41c/0x910
[<ffffffff813e86f7>] tcp_write_xmit+0x1e7/0x9d0
[<ffffffff813e8f46>] __tcp_push_pending_frames+0x26/0xc0
[<ffffffff813d77be>] tcp_push+0x6e/0x90
[<ffffffff813db4f9>] tcp_sendmsg+0x759/0xc00
[<ffffffff813fdaa8>] inet_sendmsg+0x48/0xb0
[<ffffffff811cd7f3>] ? selinux_socket_sendmsg+0x23/0x30
[<ffffffff81377e52>] sock_sendmsg+0xe2/0x120
[<ffffffff8100a7e4>] ? __switch_to+0x194/0x320
[<ffffffff81377ed1>] kernel_sendmsg+0x41/0x60
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [net-next,02/13] tg3: Cleanup transmit error path
2011-06-02 22:18 ` [net-next,02/13] " Alex Williamson
@ 2011-06-02 23:01 ` Matt Carlson
2011-06-03 1:18 ` Alex Williamson
0 siblings, 1 reply; 5+ messages in thread
From: Matt Carlson @ 2011-06-02 23:01 UTC (permalink / raw)
To: Alex Williamson; +Cc: Matthew Carlson, davem, netdev
On Thu, Jun 02, 2011 at 03:18:35PM -0700, Alex Williamson wrote:
> On Thu, 2011-05-19 at 12:12 +0000, Matt Carlson wrote:
> > This patch consolidates the skb cleanup code into a function named
> > tg3_skb_error_unmap(). The modification addresses a long-standing bug
> > where pci_unmap_single() was incorrectly being called instead of
> > pci_unmap_page() in tigon3_dma_hwbug_workaround().
>
> This patch doesn't behave well when an iommu (VT-d) is involved.
> Booting an X58 chipset based system with intel_iommu=on with 3.0.0-rc1
> results in the warning below. Looks like the driver is trying to unmap
> 0x0. Eventually something worse happens and the system reports a few
> iommu faults from the device before panicing. Neither problem is
> observed if 432aa7ed is reverted. tg3 device in use is a BCM5755.
> Thanks,
>
> Alex
>
> WARNING: at drivers/pci/intel-iommu.c:2888 intel_unmap_page+0x15c/0x180()
> Hardware name: 4157CTO
> Driver unmaps unmatched page at PFN 0
> Modules linked in: nfs lockd auth_rpcgss nfs_acl ipt_MASQUERADE iptable_nat nf_nat iptable_mangle tun autofs4 sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf bridge stp llc ipv6 dm_mirror dm_region_hash dm_log kvm_intel kvm sg microcode serio_raw wmi i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support tg3 ext4 mbcache jbd2 raid1 raid456 async_pq async_xor xor async_memcpy async_raid6_recov raid6_pq async_tx sr_mod cdrom sd_mod crc_t10dif floppy dm_mod [last unloaded: scsi_wait_scan]
> Pid: 2604, comm: libvirtd Not tainted 3.0.0-rc1+ #184
> Call Trace:
> [<ffffffff8105c7df>] warn_slowpath_common+0x7f/0xc0
> [<ffffffff8105c8d6>] warn_slowpath_fmt+0x46/0x50
> [<ffffffff81245b8b>] ? find_iova+0x5b/0xa0
> [<ffffffff8124a60c>] intel_unmap_page+0x15c/0x180
> [<ffffffffa0128d48>] tg3_skb_error_unmap+0xb8/0x130 [tg3]
> [<ffffffffa0136041>] tg3_start_xmit+0x661/0xde0 [tg3]
> [<ffffffffa01363dd>] ? tg3_start_xmit+0x9fd/0xde0 [tg3]
> [<ffffffff8138d7fe>] dev_hard_start_xmit+0x31e/0x6c0
> [<ffffffff813a9f5f>] sch_direct_xmit+0xef/0x1c0
> [<ffffffff8138dd38>] dev_queue_xmit+0x198/0x5f0
> [<ffffffffa028d2ac>] br_dev_queue_push_xmit+0x6c/0xa0 [bridge]
> [<ffffffffa028d478>] br_forward_finish+0x58/0x60 [bridge]
> [<ffffffffa028d4f8>] __br_deliver+0x78/0xf0 [bridge]
> [<ffffffff814367a9>] ? packet_rcv+0x59/0x450
> [<ffffffffa028d5a5>] br_deliver+0x35/0x40 [bridge]
> [<ffffffffa028b8c4>] br_dev_xmit+0x114/0x180 [bridge]
> [<ffffffff8138d7fe>] dev_hard_start_xmit+0x31e/0x6c0
> [<ffffffff8138df95>] dev_queue_xmit+0x3f5/0x5f0
> [<ffffffff813d0c2e>] ip_finish_output+0x16e/0x340
> [<ffffffff813d1110>] ip_output+0xb0/0xc0
> [<ffffffff813cfdc3>] ? __ip_local_out+0xa3/0xb0
> [<ffffffff813d0129>] ip_local_out+0x29/0x30
> [<ffffffff813d0604>] ip_queue_xmit+0x164/0x410
> [<ffffffff813e5e5c>] tcp_transmit_skb+0x41c/0x910
> [<ffffffff813e86f7>] tcp_write_xmit+0x1e7/0x9d0
> [<ffffffff813e8f46>] __tcp_push_pending_frames+0x26/0xc0
> [<ffffffff813d77be>] tcp_push+0x6e/0x90
> [<ffffffff813db4f9>] tcp_sendmsg+0x759/0xc00
> [<ffffffff813fdaa8>] inet_sendmsg+0x48/0xb0
> [<ffffffff811cd7f3>] ? selinux_socket_sendmsg+0x23/0x30
> [<ffffffff81377e52>] sock_sendmsg+0xe2/0x120
> [<ffffffff8100a7e4>] ? __switch_to+0x194/0x320
> [<ffffffff81377ed1>] kernel_sendmsg+0x41/0x60
Does this patch fix the problem?
Subject: [PATCH] tg3: Fix tg3_skb_error_unmap()
This function attempts to free one fragment beyond the number of
fragments that were actually mapped. This patch brings back the limit
to the correct spot.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
---
drivers/net/tg3.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 8ece39b..3d239ab 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -5771,7 +5771,7 @@ static void tg3_skb_error_unmap(struct tg3_napi *tnapi,
dma_unmap_addr(txb, mapping),
skb_headlen(skb),
PCI_DMA_TODEVICE);
- for (i = 0; i <= last; i++) {
+ for (i = 0; i < last; i++) {
skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
entry = NEXT_TX(entry);
--
1.7.3.4
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [net-next,02/13] tg3: Cleanup transmit error path
2011-06-02 23:01 ` Matt Carlson
@ 2011-06-03 1:18 ` Alex Williamson
2011-06-03 7:02 ` David Miller
0 siblings, 1 reply; 5+ messages in thread
From: Alex Williamson @ 2011-06-03 1:18 UTC (permalink / raw)
To: Matt Carlson; +Cc: davem, netdev
On Thu, 2011-06-02 at 16:01 -0700, Matt Carlson wrote:
> On Thu, Jun 02, 2011 at 03:18:35PM -0700, Alex Williamson wrote:
> > On Thu, 2011-05-19 at 12:12 +0000, Matt Carlson wrote:
> > > This patch consolidates the skb cleanup code into a function named
> > > tg3_skb_error_unmap(). The modification addresses a long-standing bug
> > > where pci_unmap_single() was incorrectly being called instead of
> > > pci_unmap_page() in tigon3_dma_hwbug_workaround().
> >
> > This patch doesn't behave well when an iommu (VT-d) is involved.
> > Booting an X58 chipset based system with intel_iommu=on with 3.0.0-rc1
> > results in the warning below. Looks like the driver is trying to unmap
> > 0x0. Eventually something worse happens and the system reports a few
> > iommu faults from the device before panicing. Neither problem is
> > observed if 432aa7ed is reverted. tg3 device in use is a BCM5755.
> > Thanks,
> >
> > Alex
> >
> > WARNING: at drivers/pci/intel-iommu.c:2888 intel_unmap_page+0x15c/0x180()
> > Hardware name: 4157CTO
> > Driver unmaps unmatched page at PFN 0
> > Modules linked in: nfs lockd auth_rpcgss nfs_acl ipt_MASQUERADE iptable_nat nf_nat iptable_mangle tun autofs4 sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf bridge stp llc ipv6 dm_mirror dm_region_hash dm_log kvm_intel kvm sg microcode serio_raw wmi i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support tg3 ext4 mbcache jbd2 raid1 raid456 async_pq async_xor xor async_memcpy async_raid6_recov raid6_pq async_tx sr_mod cdrom sd_mod crc_t10dif floppy dm_mod [last unloaded: scsi_wait_scan]
> > Pid: 2604, comm: libvirtd Not tainted 3.0.0-rc1+ #184
> > Call Trace:
> > [<ffffffff8105c7df>] warn_slowpath_common+0x7f/0xc0
> > [<ffffffff8105c8d6>] warn_slowpath_fmt+0x46/0x50
> > [<ffffffff81245b8b>] ? find_iova+0x5b/0xa0
> > [<ffffffff8124a60c>] intel_unmap_page+0x15c/0x180
> > [<ffffffffa0128d48>] tg3_skb_error_unmap+0xb8/0x130 [tg3]
> Does this patch fix the problem?
Yes it does, probably explains the subsequent iommu faults if that off
by one unmapping sometimes finds a non-zero address to unmap. Thanks,
Alex
Tested-by: Alex Williamson <alex.williamson@redhat.com>
> Subject: [PATCH] tg3: Fix tg3_skb_error_unmap()
>
> This function attempts to free one fragment beyond the number of
> fragments that were actually mapped. This patch brings back the limit
> to the correct spot.
>
> Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
> ---
> drivers/net/tg3.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
> index 8ece39b..3d239ab 100644
> --- a/drivers/net/tg3.c
> +++ b/drivers/net/tg3.c
> @@ -5771,7 +5771,7 @@ static void tg3_skb_error_unmap(struct tg3_napi *tnapi,
> dma_unmap_addr(txb, mapping),
> skb_headlen(skb),
> PCI_DMA_TODEVICE);
> - for (i = 0; i <= last; i++) {
> + for (i = 0; i < last; i++) {
> skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
>
> entry = NEXT_TX(entry);
> --
> 1.7.3.4
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [net-next,02/13] tg3: Cleanup transmit error path
2011-06-03 1:18 ` Alex Williamson
@ 2011-06-03 7:02 ` David Miller
0 siblings, 0 replies; 5+ messages in thread
From: David Miller @ 2011-06-03 7:02 UTC (permalink / raw)
To: alex.williamson; +Cc: mcarlson, netdev
From: Alex Williamson <alex.williamson@redhat.com>
Date: Thu, 02 Jun 2011 19:18:34 -0600
> On Thu, 2011-06-02 at 16:01 -0700, Matt Carlson wrote:
>> Does this patch fix the problem?
>
> Yes it does, probably explains the subsequent iommu faults if that off
> by one unmapping sometimes finds a non-zero address to unmap. Thanks,
>
> Alex
>
> Tested-by: Alex Williamson <alex.williamson@redhat.com>
Applied, thanks.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-06-03 7:02 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-05-19 22:12 [PATCH net-next 02/13] tg3: Cleanup transmit error path Matt Carlson
2011-06-02 22:18 ` [net-next,02/13] " Alex Williamson
2011-06-02 23:01 ` Matt Carlson
2011-06-03 1:18 ` Alex Williamson
2011-06-03 7:02 ` David Miller
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.