linux-kernel - Re: [RFC][PATCH 2/5 v2] dma-buf: heaps: Add heap helpers

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 19 Mar 2019 10:03:20 -0500
From:   "Andrew F. Davis" <afd@...com>
To:     Christoph Hellwig <hch@...radead.org>,
        John Stultz <john.stultz@...aro.org>
CC:     lkml <linux-kernel@...r.kernel.org>,
        Laura Abbott <labbott@...hat.com>,
        Benjamin Gaignard <benjamin.gaignard@...aro.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Sumit Semwal <sumit.semwal@...aro.org>,
        Liam Mark <lmark@...eaurora.org>,
        Brian Starkey <Brian.Starkey@....com>,
        Chenbo Feng <fengc@...gle.com>,
        Alistair Strachan <astrachan@...gle.com>,
        <dri-devel@...ts.freedesktop.org>
Subject: Re: [RFC][PATCH 2/5 v2] dma-buf: heaps: Add heap helpers

On 3/15/19 4:06 AM, Christoph Hellwig wrote:
>> +		ret = remap_pfn_range(vma, addr, page_to_pfn(page), len,
>> +				      vma->vm_page_prot);
> 
> So the same chunk could be mapped to userspace and vmap, and later on
> also DMA mapped.  Who is going to take care of cache aliasing as I
> see nothing of that in this series?
> 

We should only have one type of memory per heap so all mappings will
have the same type. That should solve the ARM specific issues, but I'm
guessing you are thinking of more tricky architectures where all
mappings need to be tracked and cleaned/invalidated..

For that I think we will have to track each right? How do others handle
that, we can't be the first to offer cached buffers to userspace.