From: Dave Jones <davej@redhat.com>
To: netdev@vger.kernel.org
Subject: VIA velocity skb leak.
Date: Thu, 12 Mar 2009 00:13:52 -0400 [thread overview]
Message-ID: <20090312041352.GA6035@redhat.com> (raw)
I think I've found a bug in the via-velocity driver, but I'm not
sure how to fix it.
We've been carrying some debug patches in the Fedora kernel that
dwmw2 wrote, which do some sanity checks on dma allocations.
Velocity triggered this trace..
[ 324.777540] ------------[ cut here ]------------
[ 324.777559] WARNING: at lib/dma-debug.c:470 check_unmap+0x196/0x3e4() (Not tainted)
[ 324.777575] Hardware name:
[ 324.777591] via-velocity 0000:00:0e.0: DMA-API: device driver frees DMA memory with different size [device address=0x000000001a4c8ca2] [map size=60 bytes] [unmap size=54 bytes]
[ 324.777614] Modules linked in: ipt_MASQUERADE iptable_nat nf_nat ipt_LOG xt_limit sunrpc nf_conntrack_netbios_ns ip6t_REJECT ip6table_filter ip6_tables ipv6 cpufreq_ondemand serio_raw usb_storage pcspkr i2c_viapro 3c59x mii i2c_core firewire_ohci via_velocity firewire_core crc_ccitt crc_itu_t ata_generic pata_acpi pata_via ext2 [last unloaded: scsi_wait_scan]
[ 324.777792] Pid: 0, comm: swapper Not tainted 2.6.29-0.179.rc6.git5.fc11.i686.PAE #1
[ 324.777807] Call Trace:
[ 324.777839] [<c0437a9f>] warn_slowpath+0x7c/0xa7
[ 324.777870] [<c0701800>] ? _spin_unlock_irq+0x1c/0x34
[ 324.777899] [<c042ae55>] ? account_group_exec_runtime+0x4d/0x54
[ 324.777929] [<c045783c>] ? mark_lock+0x1e/0x30b
[ 324.777952] [<c045783c>] ? mark_lock+0x1e/0x30b
[ 324.777973] [<c0554765>] ? get_hash_bucket+0x26/0x2f
[ 324.777995] [<c0554fc3>] check_unmap+0x196/0x3e4
[ 324.778021] [<c040de4d>] ? sched_clock+0x9/0xd
[ 324.778042] [<c05553bf>] debug_dma_unmap_page+0x68/0x70
[ 324.778064] [<c05553bf>] ? debug_dma_unmap_page+0x68/0x70
[ 324.778111] [<dcfc251c>] pci_unmap_single+0x65/0x70 [via_velocity]
[ 324.778148] [<dcfc25f5>] velocity_tx_srv+0xce/0x183 [via_velocity]
[ 324.778188] [<dcfc39a7>] velocity_intr+0x52f/0x594 [via_velocity]
[ 324.778211] [<c0457023>] ? trace_hardirqs_off+0xb/0xd
[ 324.778232] [<c067d15d>] ? netif_rx+0x9d/0x11a
[ 324.778277] [<dc861f8e>] ? boomerang_interrupt+0x324/0x331 [3c59x]
[ 324.778300] [<c045783c>] ? mark_lock+0x1e/0x30b
[ 324.778330] [<c047a6a4>] ? handle_fasteoi_irq+0x76/0xb7
[ 324.778351] [<c04566d8>] ? lock_release_holdtime+0x2b/0x123
[ 324.778374] [<c0479284>] handle_IRQ_event+0x22/0x58
[ 324.778394] [<c0479284>] ? handle_IRQ_event+0x22/0x58
[ 324.778417] [<c047a6ae>] handle_fasteoi_irq+0x80/0xb7
[ 324.778437] [<c047a62e>] ? handle_fasteoi_irq+0x0/0xb7
[ 324.778450] <IRQ> [<c0409cac>] ? common_interrupt+0x2c/0x34
[ 324.778490] [<c0457d78>] ? trace_hardirqs_on+0xb/0xd
[ 324.778501] [<c059fcca>] ? acpi_idle_enter_simple+0x13a/0x179
[ 324.778501] [<c059f9b4>] ? acpi_idle_enter_bm+0xd1/0x2ad
[ 324.778501] [<c0660105>] ? menu_select+0x3d/0xa4
[ 324.778501] [<c065f670>] ? cpuidle_idle_call+0x65/0x9d
[ 324.778501] [<c065f670>] ? cpuidle_idle_call+0x65/0x9d
[ 324.778501] [<c040871e>] ? cpu_idle+0x72/0x90
[ 324.778501] [<c06efa03>] ? rest_init+0x53/0x55
[ 324.778501] ---[ end trace 57ea7e11ea46a364 ]---
It looks like in velocity_xmit we do the skb_padto because the length is below
the minimum frame size (56 bytes) and pci_map the resulting 60 byte skb.
But later, when we free it, we forget that we did that size adjustment.
Does skb_padto adjust the skb->len somewhere, or is this responsibility of the caller?
Dave
--
http://www.codemonkey.org.uk
next reply other threads:[~2009-03-12 4:13 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-12 4:13 Dave Jones [this message]
2009-03-12 4:17 ` VIA velocity skb leak David Miller
2009-03-12 4:20 ` David Miller
2009-03-12 4:39 ` Dave Jones
2009-03-12 4:45 ` Eric Dumazet
2009-03-12 4:56 ` Dave Jones
2009-03-12 5:14 ` Eric Dumazet
2009-03-13 20:36 ` David Miller
2009-03-13 20:52 ` a2065 skb_padto cleanups Dave Jones
2009-03-19 1:18 ` David Miller
2009-03-13 21:10 ` r8169 skb leak Dave Jones
2009-03-13 22:26 ` Francois Romieu
2009-03-13 22:33 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090312041352.GA6035@redhat.com \
--to=davej@redhat.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).