linux-kernel - Re: [PATCH] firewire: fw-ohci: sync AT dma buffer before use

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: <47D8661A.4090809@s5r6.in-berlin.de>
Date:	Thu, 13 Mar 2008 00:24:10 +0100
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	David Moore <dcm@....EDU>
CC:	Jarod Wilson <jwilson@...hat.com>,
	linux1394-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] firewire: fw-ohci: sync AT dma buffer before use

David Moore wrote:
> 1. The dma_sync should probably be done before the context_append
> because the controller could in theory start reading the data as soon as
> context_append is called right?

Yes, but its syncing is superfluous anyway, as mentioned in the other 
post.  *If* it is doing something for Jarod's setup, then only because 
of side effects like memory barrier properties.

> 2. As an optimization, we should attempt to allocate the payload in the
> lower 32-bits of physical memory, to prevent extra memcopies on x86_64.
> I think this can be done by adding GFP_DMA32 to kmalloc where the
> payload was allocated in fw-cdev.c.  There might be other places where
> we would benefit from GFP_DMA32 also.  Of course, these optimizations
> are probably better saved for another patch.

I think so too.  GFP_DMA32 would be appropriate on machines with 
"software IOMMU" alias swiotlb.

Does GFP_DMA32 have adverse affects on machines with a real IOMMU?
-- 
Stefan Richter
-=====-==--- --== -==--
http://arcgraph.de/sr/
--
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/