netdev - Re: tg3 NIC driver bug in 3.14.x under Xen [and 3 more messages]

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <1429224694.4720.68.camel@prashant>
Date:	Thu, 16 Apr 2015 15:51:34 -0700
From:	Prashant Sreedharan <prashant@...adcom.com>
To:	Ian Jackson <Ian.Jackson@...citrix.com>
CC:	Michael Chan <mchan@...adcom.com>, <cascardo@...ux.vnet.ibm.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@...cle.com>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	David Vrabel <david.vrabel@...rix.com>,
	"Vlad Yasevich" <vyasevich@...il.com>,
	<xen-devel@...ts.xensource.com>, <netdev@...r.kernel.org>,
	"Siva Reddy (Siva) Kallam" <siva.kallam@...adcom.com>,
	Sanjeev Bansal <sanjeevb@...adcom.com>
Subject: Re: tg3 NIC driver bug in 3.14.x under Xen [and 3 more messages]

On Thu, 2015-04-16 at 18:15 +0100, Ian Jackson wrote:
> Michael Chan writes ("Re: tg3 NIC driver bug in 3.14.x under Xen [and 3 more messages]"):
> > On Thu, 2015-04-16 at 09:24 -0300, cascardo@...ux.vnet.ibm.com wrote: 
> > > Yes, this looks like the driver is not syncing the DMA buffers. Unmap is
> > > supposed to synchronize as well.
> > 
> > For small rx packets (< 256 bytes), we sync the DMA buffer before we
> > copy the data to another SKB.  For larger packets, we unmap the DMA
> > buffer.  Do we see the corruption in both cases?
> 
> Yes, at least with swiotlb=force iommu=soft.

Ok this is what is causing the problem, the driver uses
DEFINE_DMA_UNMAP_ADDR(), dma_unmap_addr_set() to keep a copy of the dma
"mapping" and dma_unmap_addr() to get the "mapping" value. On most of
the platforms this is a no-op, but it appears with "iommu=soft and
swiotlb=force" this house keeping is required, when I pass the correct
dma_addr instead of 0 while calling pci_unmap_/pci_dma_sync_ I don't see
the corruption. ie If you set CONFIG_NEED_DMA_MAP_STATE=y in your kernel
config you should not see the problem. Can you confirm ? Thanks


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html