linux-kernel - Re: Panic: dma_map_area overflow 66 bytes on 3.7+

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sat, 29 Dec 2012 11:29:32 +0100
From:	Martin Nybo Andersen <tweek@...ek.dk>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	"David S. Miller" <davem@...emloft.net>,
	Michal Schmidt <mschmidt@...hat.com>,
	linux-kernel@...r.kernel.org, netdev <netdev@...r.kernel.org>
Subject: Re: Panic: dma_map_area overflow 66 bytes on 3.7+

On Friday 28 December 2012 20:53:10 Eric Dumazet wrote:
> On Fri, 2012-12-28 at 20:05 +0100, Martin Nybo Andersen wrote:
> > Hi list,
> > 
> > Since the release of 3.7 my main computer has been panicking a couple of
> > times on both 3.7.0 and 3.7.1 because of a 'dma_map_area overflow xx bytes'.
> > 
> > Example screen shot:
> > http://www.tweek.dk/panic.jpg
> > 
> > I can reproduce it somewhat easily by visiting http://www.openstreetmap.org/
> > and zoom erratically with the scroll-button on the mouse.
> > 
> > The panic seems to occur on line 229 of arch/x86/kernel/amd_gart_64.c, and
> > reverting commit aee77e4accbeb2c86b1d294cd84fec4a12dde3bd (r8169: use
> > unlimited DMA burst for TX) seems to fix the problem for me (at least I've
> > not been able to make it panic as before (yet)).
> > 
> > 
> > lspci -v:
> > 00:00.0 Host bridge: Advanced Micro Devices [AMD] nee ATI RS480 Host Bridge (rev 01)
> > 00:02.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RS480 PCI-X Root Port
> > 00:05.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RS480 PCI Bridge
> > 00:12.0 SATA controller: Advanced Micro Devices [AMD] nee ATI SB600 Non-Raid-5 SATA
> > 00:13.0 USB controller: Advanced Micro Devices [AMD] nee ATI SB600 USB (OHCI0)
> > 00:13.1 USB controller: Advanced Micro Devices [AMD] nee ATI SB600 USB (OHCI1)
> > 00:13.2 USB controller: Advanced Micro Devices [AMD] nee ATI SB600 USB (OHCI2)
> > 00:13.3 USB controller: Advanced Micro Devices [AMD] nee ATI SB600 USB (OHCI3)
> > 00:13.4 USB controller: Advanced Micro Devices [AMD] nee ATI SB600 USB (OHCI4)
> > 00:13.5 USB controller: Advanced Micro Devices [AMD] nee ATI SB600 USB Controller (EHCI)
> > 00:14.0 SMBus: Advanced Micro Devices [AMD] nee ATI SBx00 SMBus Controller (rev 13)
> > 00:14.1 IDE interface: Advanced Micro Devices [AMD] nee ATI SB600 IDE
> > 00:14.2 Audio device: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel HDA)
> > 00:14.3 ISA bridge: Advanced Micro Devices [AMD] nee ATI SB600 PCI to LPC Bridge
> > 00:14.4 PCI bridge: Advanced Micro Devices [AMD] nee ATI SBx00 PCI to PCI Bridge
> > 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
> > 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
> > 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
> > 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
> > 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
> > 02:00.0 VGA compatible controller: NVIDIA Corporation G84 [GeForce 8600 GT] (rev a1)
> > 03:07.0 Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV PCI Bridge Controller [Ver 1.0] (rev 01)
> > 
> > 
> > Please tell, if more info is needed.
> 
> Seems you have CONFIG_IOMMU_DEBUG, is it really what you want ?
That is true, I've enabled CONFIG_IOMMU_DEBUG.
If I want it? It seems like I don't... :-)

> It seems a bit strange we panic in this case
> ( panic_on_overflow = 1;)
I don't know much about IOMMUs, but if the alternative is trashed memory then
I'm in for it.

panic_on_overflow is set on lines 26--27 of arch/x86/kernel/pci-dma.c along
with force_iommu if CONFIG_IOMMU_DEBUG is enabled.

> You could try to add iommu=nopanic to your boot command : packet should
> be dropped, instead of panic.
I opt for disabling CONFIG_IOMMU_DEBUG, as it sets force_iommu as well.

If the only consequence of this is stats.tx_dropped being bumped not too
often, that's ok for me.


Thanks for the quick help! :-)


Regards,
Martin Nybo Andersen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/