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]
Date:	Tue, 10 Jul 2012 13:32:11 -0400
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	Shuah Khan <shuah.khan@...com>
Cc:	fujita.tomonori@....ntt.co.jp, LKML <linux-kernel@...r.kernel.org>,
	akpm@...ux-foundation.org, paul.gortmaker@...driver.com,
	bhelgaas@...gle.com, amwang@...hat.com, shuahkhan@...il.com
Subject: Re: [PATCH RFC] swiotlb: Remove SWIOTLB overflow buffer support

On Tue, Jul 10, 2012 at 10:55:07AM -0600, Shuah Khan wrote:
> On Mon, 2012-07-09 at 16:25 -0400, Konrad Rzeszutek Wilk wrote:
> > On Fri, Jul 06, 2012 at 05:06:12PM -0600, Shuah Khan wrote:
> > > Remove SWIOTLB overflow buffer support and return DMA_ERROR_CODE
> > > (a value of zero) to make it consistent with iommu implementation
> > > on Intel, AMD, and swiotlb-xen.
> > 
> > While this is a good forward step and this needs to be done eventually,
> > you should first send out patches for the drivers that don't check
> > for the DMA_ERROR_CODE when doing mapping. In other words for the
> > drivers that map but don't call dma_mapping_error to check.
> > 
> > When that is fixed and *all the drivers that don't call dma_mapping_error
> > are fixed, then this patch makes sense.
> 
> The challenge will be catching all the drivers and have confidence that
> all of them are covered. I will start looking into this to get a feel
> for how many drivers needs fixing.

I don't know if all is needed. Some of them might be dead or not used
at all anymore - who knows? This treasure hunt would give a good idea
of which ones are not using the PCI/DMA API right at least.

If it is say, CONFIG_ISA enabled, well, we could #ifdef the overflow
buffer in the swiotlb with that option. And then work through fixing
up those drivers - except that finding folks with that driver to
see if it works .. yuck.. I do have some few ISA cards and some boxes
with ISA slots :-)

> 
> Also, isn't this problem today with other iommu implementations? All of
> the other iommu implementation don't have support for overflow buffers?

Right, but you are in high likehood not going to run the drivers that
don't check this with an IOMMU. Because the drivers are mostly the PCI
variants .. or PCMCIA. And the hardware that would use this did not have
IOMMU.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ