linux-kernel - Re: IB: Add DMA mapping functions to allow device drivers to interpose

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: <20061213123043.9de95cc4.akpm@osdl.org>
Date:	Wed, 13 Dec 2006 12:30:43 -0800
From:	Andrew Morton <akpm@...l.org>
To:	Ralph Campbell <ralph.campbell@...gic.com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Roland Dreier <rolandd@...co.com>
Subject: Re: IB: Add DMA mapping functions to allow device drivers to
 interpose

On Wed, 13 Dec 2006 12:11:27 -0800
Ralph Campbell <ralph.campbell@...gic.com> wrote:

> > I'd have picked this up if it had been in git-infiniband for even a couple
> > of days.  I'm assuming this all got slammed into mainline because of the
> > merge window thing.
> > 
> > I cannot find these patches on the kernel mailing list.  I cannot find the
> > pull request anywhere.
> > 
> > > +static inline u64 ib_dma_map_single(struct ib_device *dev,
> > > +				    void *cpu_addr, size_t size,
> > > +				    enum dma_data_direction direction)
> > 
> > no, dma_map_single() returns a dma_addr_t.
> 
> ib_dma_map_single() allows the ib_ipath device driver to interpose
> on IOMMU allocations and not do them by returning the kernel
> virtual address as the "DMA address".  I started with dma_addr_t
> but it was pointed out to me that sparc64 defines dma_addr_t
> as u32. This would cause addresses to be truncated.
> Also, I chose u64 because the return value from ib_dma_*() is
> stored in the ib_sge.addr field which is u64.
> 
> My preference would be to change the offending uses of dma_addr_t
> to u64.  Do you have a better solution?

We should be able to use dma_addr_t for this?  Is it not the case that the
values we're dealing with here _are_ DMA addresses?  I think a more complete
description of the problem we're trying to solve here would help.

I'm not sure what the problem is with sparc64 - perhaps its dma_addr_t
really is a "cookie" and isn't a physical bus address?  But you want a value
which is really a physical bus address?  Dunno.

Perhaps dma64_addr_t can be used here.
-
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/