linux-kernel - Re: [PATCH RESEND] drm/ttm: expose CPU address of DMA-allocated pages

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] [day] [month] [year] [list]

Message-ID: <CAAVeFuLfREn00Qw51Q9=0ncqO-WAR87Sf=0VWOPETrk9T5sG2w@mail.gmail.com>
Date:	Tue, 22 Jul 2014 14:46:55 +0900
From:	Alexandre Courbot <gnurou@...il.com>
To:	Dave Airlie <airlied@...il.com>
Cc:	Alexandre Courbot <acourbot@...dia.com>,
	David Airlie <airlied@...ux.ie>,
	Ben Skeggs <bskeggs@...hat.com>,
	David Herrmann <dh.herrmann@...il.com>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH RESEND] drm/ttm: expose CPU address of DMA-allocated pages

On Tue, Jul 22, 2014 at 2:07 PM, Dave Airlie <airlied@...il.com> wrote:
> On 22 July 2014 14:21, Alexandre Courbot <gnurou@...il.com> wrote:
>> DRM maintainers, could I have a comment about this patch? A bunch of
>> Nouveau changes depend on it.
>
> I'm not sure we really have anyone who is in a great position to comment,
>
> my major issue would be its allocate a large chunk of RAM that might
> not be needed
> in all cases, and if we could avoid that when we don't need it, then
> it would be good.

Strictly speaking memory allocated using dma_alloc_coherent() should
only be accessed by the CPU through the returned mapping, so having
this extra information is probably as legitimate as the current
dma_address array.

Now I agree that this results in more memory being used, which is
especially sad since this information is already known in the dma_page
internal structure. Maybe we could expose the whole dma_pages instead
of just the dma address? That way both addresses would be accessible
for the same memory cost (we will need an array to store the adresses
to the dma_pages).

>
> Or maybe we could join some allocations together, but with the Linux
> mm subsystem,
> who knows maybe separate small allocs have a better hope of success.
>
> Dave.
--
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/