Re: [PATCH] dma-buf: add get_dma_buf() |
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: Re: [PATCH] dma-buf: add get_dma_buf()
- From: Tomasz Stanislawski <t.stanislaws@xxxxxxxxxxx>
- Date: Tue, 22 May 2012 17:00:31 +0200
- Cc: patches@xxxxxxxxxx, dri-devel@xxxxxxxxxxxxxxxxxxxxx, Rob Clark <rob.clark@xxxxxxxxxx>, linaro-mm-sig@xxxxxxxxxxxxxxxx, '박경민' <kyungmin.park@xxxxxxxxxxx>, Rob Clark <rob@xxxxxx>, airlied@xxxxxxxxxx, Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>, sumit.semwal@xxxxxxxxxx, linux-media@xxxxxxxxxxxxxxx
- Delivered-to: dri-devel@xxxxxxxxxxxxxxxxxxxxx
- In-reply-to: <20120522143234.GC4629@phenom.ffwll.local>
- References: <1331913881-13105-1-git-send-email-rob.clark@linaro.org> <4FBB98E0.8040600@samsung.com> <20120522143234.GC4629@phenom.ffwll.local>
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
On 05/22/2012 04:32 PM, Daniel Vetter wrote:
> On Tue, May 22, 2012 at 03:47:12PM +0200, Tomasz Stanislawski wrote:
>> Hi,
>> I think I discovered an interesting issue with dma_buf.
>> I found out that dma_buf_fd does not increase reference
>> count for dma_buf::file. This leads to potential kernel
>> crash triggered by user space. Please, take a look on
>> the scenario below:
>>
>> The applications spawns two thread. One of them is exporting DMABUF.
>>
>> Thread I | Thread II | Comments
>> -----------------------+-------------------+-----------------------------------
>> dbuf = dma_buf_export | | dma_buf is creates, refcount is 1
>> fd = dma_buf_fd(dbuf) | | assume fd is set to 42, refcount is still 1
>> | close(42) | The file descriptor is closed asynchronously, dbuf's refcount drops to 0
>> | dma_buf_release | dbuf structure is freed, dbuf becomes a dangling pointer
>> int size = dbuf->size; | | the dbuf is dereferenced, causing a kernel crash
>> -----------------------+-------------------+-----------------------------------
>>
>> I think that the problem could be fixed in two ways.
>> a) forcing driver developer to call get_dma_buf just before calling dma_buf_fd.
>> b) increasing dma_buf->file's reference count at dma_buf_fd
>>
>> I prefer solution (b) because it prevents symmetry between dma_buf_fd and close.
>> I mean that dma_buf_fd increases reference count, close decreases it.
>>
>> What is your opinion about the issue?
>
> I guess most exporters would like to hang onto the exported dma_buf a bit
> and hence need a reference (e.g. to cache the dma_buf as long as the
> underlying buffer object exists). So I guess we can change the semantics
> of dma_buf_fd from transferring the reference you currently have (and
> hence forbidding any further access by the caller) to grabbing a reference
> of it's on for the fd that is created.
> -Daniel
Hi Daniel,
Would it be simpler, safer and more intuitive if dma_buf_fd increased
dmabuf->file's reference counter?
Regards,
Tomasz Stanislawski
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Home]
[Linux USB Devel]
[Video for Linux]
[Linux Audio Users]
[Photo]
[Yosemite News]
[Yosemite Photos]
[Video Projectors]
[PDAs]
[Free Online Dating]
[Hacking TiVo]
[Linux Kernel]
[Linux SCSI]
[XFree86]
[Devices]
[Big List of Linux Books]
[16.7MP]