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
| ||
|
Date: Thu, 12 Nov 2015 11:07:23 +0900 From: Alexandre Courbot <acourbot@...dia.com> To: Ben Skeggs <skeggsb@...il.com>, Ben Skeggs <bskeggs@...hat.com>, "Dave Airlie" <airlied@...ux.ie> CC: <nouveau@...ts.freedesktop.org>, <linux-kernel@...r.kernel.org>, "Andrew Morton" <akpm@...ux-foundation.org>, Guenter Roeck <linux@...ck-us.net> Subject: Re: [Nouveau] [PATCH] instmem/gk20a: use DMA API CPU mapping On 11/12/2015 07:49 AM, Ben Skeggs wrote: > * PGP Signed by an unknown key > > On 11/11/2015 06:07 PM, Alexandre Courbot wrote: >> Commit 69c4938249fb ("drm/nouveau/instmem/gk20a: use direct CPU access") >> tried to be smart while using the DMA-API by managing the CPU mappings of >> buffers allocated with the DMA-API by itself. In doing so, it relied >> on dma_to_phys() which is an architecture-private function not >> available everywhere. This broke the build on several architectures. >> >> Since there is no reliable and portable way to obtain the physical >> address of a DMA-API buffer, stop trying to be smart and just use the >> CPU mapping that the DMA-API can provide. This means that buffers will >> be CPU-mapped for all their life as opposed to when we need them, but >> anyway using the DMA-API here is a fallback for when no IOMMU is >> available so we should not expect optimal behavior. >> >> This makes the IOMMU and DMA-API implementations of instmem diverge >> enough that we should maybe put them into separate files... >> >> Signed-off-by: Alexandre Courbot <acourbot@...dia.com> >> --- >> Ben/Dave, since Dave's fix has reached mainline and builds are not >> broken anymore, we can proceed one of two ways: >> >> 1) Ben merges this for 4.4 and let it flow for -rc2 >> 2) I send another fix against the kernel tree > I just spoke to Dave, and I'll take this in my tree for 4.5 if > everything works fine with the temporary hack fix. Does that sound OK > to you? I would rather get rid of this illicit dma_to_phys() quickly so other people don't start thinking it's ok to use in drivers/ (or start throwing stones at me), but your call. -- 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