linux-kernel - Re: [RFC][PATCH] add dma_reserve_coherent_memory()/dma_free_reserved

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: <201008261314.56782.mitov@issp.bas.bg>
Date:	Thu, 26 Aug 2010 13:14:51 +0300
From:	Marin Mitov <mitov@...p.bas.bg>
To:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
Cc:	linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
	akpm@...ux-foundation.org
Subject: Re: [RFC][PATCH] add dma_reserve_coherent_memory()/dma_free_reserved_memory() API

On Thursday, August 26, 2010 12:43:22 pm FUJITA Tomonori wrote:
> On Thu, 26 Aug 2010 10:01:52 +0300
> Marin Mitov <mitov@...p.bas.bg> wrote:
> 
> > > If you add something to the videobuf-dma-contig API, that's fine by me
> > > because drivers/media/video/videobuf-dma-contig.c uses the own
> > > structure and plays with dma_alloc_coherent. As long as a driver
> > > doesn't touch device->dma_mem directly, it's fine, 
> > 
> > Why, my understanding is that device->dma_mem is designed exactly for keeping 
> > some chunk of coherent memory for device's private use via dma_alloc_from_coherent()
> > (and that is what dt3155v4l driver is using it for).
> 
> I don't think so. device->dma_mem can be accessed only via the
> DMA-API. I think that the DMA-API says that
> dma_declare_coherent_memory declares coherent memory that can be
> access exclusively by a certain device. 

Here I agree with you: "that can be access exclusively by a certain device"

> It's not for reserving
> coherent memory that can be used for any device for a device.

Here I disagree with you: "that can be used for any device for a device".
Reserved coherent memory can be only and exclusively used by 
the __same__ device whose device->dma_mem is touched. No other devices 
are influenced because their device->dma_mem are NULL. and 
dma_alloc_from_coherent() is not invoked for them. That is why I think
this hack is not dangerous. If some device driver decide to reserve some
chunk of memory it is for its private use and no other device in the system
is influenced.

> 
> Anway, you don't need coherent memory. So using the API for coherent
> memory isn't a good idea.

Here I agree with you, but for now we have no alternative in media/video
framework.

> 
> 
> > > There are already some workarounds for
> > > contigous memory in several drivers anyway.
> > 
> > Sure, can these workarounds be exposed as API for general use?
> 
> I don't think that's a good idea. Adding temporary workaround to the
> generic API and removing it soon after that doesn't sound a good
> developing maner.

Yes, it is just a temporary solution. Just enhancing an existing temporary solution.

Thanks,

Marin Mitov

> 
--
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/