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: Mon, 28 Sep 2020 15:31:28 +0200 From: Paul Cercueil <paul@...pouillou.net> To: Christoph Hellwig <hch@....de> Cc: Stephen Rothwell <sfr@...b.auug.org.au>, Dave Airlie <airlied@...ux.ie>, DRI <dri-devel@...ts.freedesktop.org>, Linux Next Mailing List <linux-next@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: linux-next: build failure after merge of the drm tree Le lun. 28 sept. 2020 à 14:10, Christoph Hellwig <hch@....de> a écrit : > On Mon, Sep 28, 2020 at 01:46:55PM +0200, Paul Cercueil wrote: >>> dma_mmap_attrs can only be used on allocations from dma_mmap_attrs >>> with >>> the same attrs. As there is no allocation using >>> DMA_ATTR_NON_CONSISTENT >>> in the drm core, something looks very fishy here. >> >> Is that a fact? I don't see why you couldn't change the cache >> settings >> after allocation. In practice it works just fine. > > Accessing the same physical address using different caching attributes > is undefined behavior and fairly dangerous on most architectures, and > thus not supported by the DMA API. It's allocated with dma_alloc_wc, but then it's only accessed as non-coherent. Anyway, for the time being I guess you could revert 37054fc81443. But I have patches on top of it in drm-misc-next so it's going to be a mess. If we have time I can come up with a custom dumb_create() fonction, to make sure that the GEM buffers are allocated with dma_alloc_noncoherent(). Is there a dma_mmap_noncoherent() too? -Paul
Powered by blists - more mailing lists