linux-kernel - Re: ARM: 2.6.3[45] PCI regression (IXP4xx and PXA?)

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:	Thu, 26 Aug 2010 22:54:39 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	benh@...nel.crashing.org
Cc:	linux@....linux.org.uk, khc@...waw.pl,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: ARM: 2.6.3[45] PCI regression (IXP4xx and PXA?)

On Thu, 26 Aug 2010 20:55:09 +0900
FUJITA Tomonori <fujita.tomonori@....ntt.co.jp> wrote:

> On Fri, 20 Aug 2010 07:51:52 +1000
> Benjamin Herrenschmidt <benh@...nel.crashing.org> wrote:
> 
> > On Thu, 2010-08-19 at 23:50 +0900, FUJITA Tomonori wrote:
> > > 
> > > You mean that you like to permit architectures to modify
> > > dev->coherent_dma_mask behind a device? If so, I'm against it because
> > > it means dev->coherent_dma_mask has two meanings. That's confusing.
> > 
> > No it's not. It has one and only one meaning which is the mask defining
> > where the coherent memory can come from for that device. Nobody cares if
> > the device can do more and has been "clipped" at set_coherent_dma_mask()
> > time by the bus. This is not useful information.
> 
> Ok.

btw, I'm still not sure, letting architectures to clip the dma mask
(and coherent mask) behind a driver is correct by defintion of the DMA
API (it's not a real problem).

DMA-API.txt defines dma_set_mask is "checks to see if the mask is
possible and update the device parameters if it is". It means that
architectures can't clip the mask behind a driver, I think.

Lots of drivers do something like:

if (dma_set_mask(dev, DMA_BIT_MASK(64)))
        if (dma_set_mask(dev, DMA_BIT_MASK(32)))

What arm does is accepting whatever dma mask and setting the clipped
mask behind a driver. If we use this sementics (archs are free to clip
the mask), drivers don't need the second dma_set_mask call. And the
driver wrongly assumes that it successfully set 64bit dma mask (and
possibly set the hardware to 64bit dma mode needlessly).
--
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/