> In drm_prime_handle_to_fd_ioctl(), flags is cleared to only support
> DRM_CLOEXEC but in gem_prime_export() callbacks of each driver, it uses
> 0600 as flags for dma_buf_export() like following.
>
> return dma_buf_export(obj, _dmabuf_ops, obj->base.size, 0600);
Oops, nice catch, radeon and
In drm_prime_handle_to_fd_ioctl(), flags is cleared to only support
DRM_CLOEXEC but in gem_prime_export() callbacks of each driver, it uses
0600 as flags for dma_buf_export() like following.
return dma_buf_export(obj, i915_dmabuf_ops, obj-base.size, 0600);
Oops, nice catch, radeon and
On Thu, Sep 27, 2012 at 4:30 PM, Seung-Woo Kim
wrote:
> Increasing ref counts of both dma-buf and gem for imported dma-buf come from
> gem
> makes memory leak. release function of dma-buf cannot be called because
> f_count
> of dma-buf increased by importing gem and gem ref count cannot be
Hi Dave,
On 2012? 12? 18? 15:30, Dave Airlie wrote:
> On Thu, Sep 27, 2012 at 4:30 PM, Seung-Woo Kim
> wrote:
>> Increasing ref counts of both dma-buf and gem for imported dma-buf come from
>> gem
>> makes memory leak. release function of dma-buf cannot be called because
>> f_count
>> of
Hi Dave,
On 2012년 12월 18일 15:30, Dave Airlie wrote:
On Thu, Sep 27, 2012 at 4:30 PM, Seung-Woo Kim sw0312@samsung.com wrote:
Increasing ref counts of both dma-buf and gem for imported dma-buf come from
gem
makes memory leak. release function of dma-buf cannot be called because
f_count
On 2012? 11? 20? 19:26, Maarten Lankhorst wrote:
> Op 20-11-12 02:03, ??? schreef:
>> Hi Maarten,
>>
>> On 2012? 11? 19? 19:27, Maarten Lankhorst wrote:
>>> Op 15-11-12 04:52, Seung-Woo Kim schreef:
Increasing ref counts of both dma-buf and gem for imported dma-buf
come from gem makes
Op 20-11-12 02:03, ??? schreef:
> Hi Maarten,
>
> On 2012? 11? 19? 19:27, Maarten Lankhorst wrote:
>> Op 15-11-12 04:52, Seung-Woo Kim schreef:
>>> Increasing ref counts of both dma-buf and gem for imported dma-buf
>>> come from gem makes memory leak. release function of dma-buf cannot
>>> be
Hi Maarten,
On 2012? 11? 19? 19:27, Maarten Lankhorst wrote:
> Op 15-11-12 04:52, Seung-Woo Kim schreef:
>> Increasing ref counts of both dma-buf and gem for imported dma-buf
>> come from gem makes memory leak. release function of dma-buf cannot
>> be called because f_count of dma-buf increased
Op 20-11-12 02:03, 김승우 schreef:
Hi Maarten,
On 2012년 11월 19일 19:27, Maarten Lankhorst wrote:
Op 15-11-12 04:52, Seung-Woo Kim schreef:
Increasing ref counts of both dma-buf and gem for imported dma-buf
come from gem makes memory leak. release function of dma-buf cannot
be called because
On 2012년 11월 20일 19:26, Maarten Lankhorst wrote:
Op 20-11-12 02:03, 김승우 schreef:
Hi Maarten,
On 2012년 11월 19일 19:27, Maarten Lankhorst wrote:
Op 15-11-12 04:52, Seung-Woo Kim schreef:
Increasing ref counts of both dma-buf and gem for imported dma-buf
come from gem makes memory leak. release
Hi All,
This patch has been tested with only Exynos driver so other maintainers may
need to test this.
Acked-by: Inki Dae
2012/11/15 Seung-Woo Kim
> Increasing ref counts of both dma-buf and gem for imported dma-buf
> come from gem makes memory leak. release function of dma-buf cannot
> be
Op 15-11-12 04:52, Seung-Woo Kim schreef:
> Increasing ref counts of both dma-buf and gem for imported dma-buf
> come from gem makes memory leak. release function of dma-buf cannot
> be called because f_count of dma-buf increased by importing gem and
> gem ref count cannot be decrease because of
Hi All,
This patch has been tested with only Exynos driver so other maintainers may
need to test this.
Acked-by: Inki Dae inki@samsung.com
2012/11/15 Seung-Woo Kim sw0312@samsung.com
Increasing ref counts of both dma-buf and gem for imported dma-buf
come from gem makes memory leak.
Op 15-11-12 04:52, Seung-Woo Kim schreef:
Increasing ref counts of both dma-buf and gem for imported dma-buf
come from gem makes memory leak. release function of dma-buf cannot
be called because f_count of dma-buf increased by importing gem and
gem ref count cannot be decrease because of
Hi Maarten,
On 2012년 11월 19일 19:27, Maarten Lankhorst wrote:
Op 15-11-12 04:52, Seung-Woo Kim schreef:
Increasing ref counts of both dma-buf and gem for imported dma-buf
come from gem makes memory leak. release function of dma-buf cannot
be called because f_count of dma-buf increased by
Increasing ref counts of both dma-buf and gem for imported dma-buf
come from gem makes memory leak. release function of dma-buf cannot
be called because f_count of dma-buf increased by importing gem and
gem ref count cannot be decrease because of exported dma-buf.
So I add dma_buf_put() for
Increasing ref counts of both dma-buf and gem for imported dma-buf
come from gem makes memory leak. release function of dma-buf cannot
be called because f_count of dma-buf increased by importing gem and
gem ref count cannot be decrease because of exported dma-buf.
So I add dma_buf_put() for
Hi Jani,
Sorry for late reply.
On 2012? 09? 27? 22:43, Jani Nikula wrote:
> On Thu, 27 Sep 2012, Seung-Woo Kim wrote:
>> Increasing ref counts of both dma-buf and gem for imported dma-buf come from
>> gem
>> makes memory leak. release function of dma-buf cannot be called because
>> f_count
>>
Hi Jani,
Sorry for late reply.
On 2012년 09월 27일 22:43, Jani Nikula wrote:
On Thu, 27 Sep 2012, Seung-Woo Kim sw0312@samsung.com wrote:
Increasing ref counts of both dma-buf and gem for imported dma-buf come from
gem
makes memory leak. release function of dma-buf cannot be called because
On Thu, 27 Sep 2012, Seung-Woo Kim wrote:
> Increasing ref counts of both dma-buf and gem for imported dma-buf come from
> gem
> makes memory leak. release function of dma-buf cannot be called because
> f_count
> of dma-buf increased by importing gem and gem ref count cannot be decrease
>
Hi Rob,
On 2012? 09? 27? 15:52, Rob Clark wrote:
> fwiw, I had a similar patch:
>
> https://patchwork.kernel.org/patch/1229161/
Yes, I already check your patch and even my patch's title is a bit from
your patch.
I thought locking issue blocks your patch, so I sent simple fixes on
current
Increasing ref counts of both dma-buf and gem for imported dma-buf come from gem
makes memory leak. release function of dma-buf cannot be called because f_count
of dma-buf increased by importing gem and gem ref count cannot be decrease
because of exported dma-buf.
So I add dma_buf_put() for
On Thu, Sep 27, 2012 at 9:14 AM, ??? wrote:
> Hi Rob,
>
> On 2012? 09? 27? 15:52, Rob Clark wrote:
>> fwiw, I had a similar patch:
>>
>> https://patchwork.kernel.org/patch/1229161/
>
> Yes, I already check your patch and even my patch's title is a bit from
> your patch.
>
> I thought locking
fwiw, I had a similar patch:
https://patchwork.kernel.org/patch/1229161/
although it was on top of some locking fixes from Daniel (which I
think are also needed):
https://patchwork.kernel.org/patch/1227251/
although that seemed to cause/trigger some explosions which I think
still need to be
Increasing ref counts of both dma-buf and gem for imported dma-buf come from gem
makes memory leak. release function of dma-buf cannot be called because f_count
of dma-buf increased by importing gem and gem ref count cannot be decrease
because of exported dma-buf.
So I add dma_buf_put() for
fwiw, I had a similar patch:
https://patchwork.kernel.org/patch/1229161/
although it was on top of some locking fixes from Daniel (which I
think are also needed):
https://patchwork.kernel.org/patch/1227251/
although that seemed to cause/trigger some explosions which I think
still need to be
Hi Rob,
On 2012년 09월 27일 15:52, Rob Clark wrote:
fwiw, I had a similar patch:
https://patchwork.kernel.org/patch/1229161/
Yes, I already check your patch and even my patch's title is a bit from
your patch.
I thought locking issue blocks your patch, so I sent simple fixes on
current state.
On Thu, Sep 27, 2012 at 9:14 AM, 김승우 sw0312@samsung.com wrote:
Hi Rob,
On 2012년 09월 27일 15:52, Rob Clark wrote:
fwiw, I had a similar patch:
https://patchwork.kernel.org/patch/1229161/
Yes, I already check your patch and even my patch's title is a bit from
your patch.
I thought
On Thu, 27 Sep 2012, Seung-Woo Kim sw0312@samsung.com wrote:
Increasing ref counts of both dma-buf and gem for imported dma-buf come from
gem
makes memory leak. release function of dma-buf cannot be called because
f_count
of dma-buf increased by importing gem and gem ref count cannot be
On Tue, Sep 04, 2012 at 05:32:21PM -0500, Rob Clark wrote:
> Dave, I just noticed that I still have this patch locally, but don't
> see it in drm-next.. so just checking that it didn't get forgotten
My locking fixes blew up :(
-Daniel
>
> BR,
> -R
>
> On Tue, Jul 24, 2012 at 3:05 AM, Daniel
On Wed, Sep 5, 2012 at 4:02 AM, Daniel Vetter wrote:
> On Tue, Sep 04, 2012 at 05:32:21PM -0500, Rob Clark wrote:
>> Dave, I just noticed that I still have this patch locally, but don't
>> see it in drm-next.. so just checking that it didn't get forgotten
>
> My locking fixes blew up :(
oh,
On Tue, Sep 04, 2012 at 05:32:21PM -0500, Rob Clark wrote:
Dave, I just noticed that I still have this patch locally, but don't
see it in drm-next.. so just checking that it didn't get forgotten
My locking fixes blew up :(
-Daniel
BR,
-R
On Tue, Jul 24, 2012 at 3:05 AM, Daniel Vetter
On Wed, Sep 5, 2012 at 4:02 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Sep 04, 2012 at 05:32:21PM -0500, Rob Clark wrote:
Dave, I just noticed that I still have this patch locally, but don't
see it in drm-next.. so just checking that it didn't get forgotten
My locking fixes blew up :(
Dave, I just noticed that I still have this patch locally, but don't
see it in drm-next.. so just checking that it didn't get forgotten
BR,
-R
On Tue, Jul 24, 2012 at 3:05 AM, Daniel Vetter wrote:
> On Tue, Jul 24, 2012 at 1:07 AM, Rob Clark wrote:
>> From: Rob Clark
>>
>> The GEM handle
Dave, I just noticed that I still have this patch locally, but don't
see it in drm-next.. so just checking that it didn't get forgotten
BR,
-R
On Tue, Jul 24, 2012 at 3:05 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Jul 24, 2012 at 1:07 AM, Rob Clark rob.cl...@linaro.org wrote:
From: Rob
On Tue, Jul 24, 2012 at 1:07 AM, Rob Clark wrote:
> From: Rob Clark
>
> The GEM handle takes the reference. If a driver is actually importing a
> foreign dmabuf, rather than just re-importing it's own dmabuf, it needs
> to do a get_dma_buf().
>
> Signed-off-by: Rob Clark
[Maybe mention that
Dear Rob,
Am Montag, den 23.07.2012, 18:07 -0500 schrieb Rob Clark:
> From: Rob Clark
>
> The GEM handle takes the reference. If a driver is actually importing a
> foreign dmabuf, rather than just re-importing it's own dmabuf, it needs
> to do a get_dma_buf().
>
> Signed-off-by: Rob Clark
>
Dear Rob,
Am Montag, den 23.07.2012, 18:07 -0500 schrieb Rob Clark:
From: Rob Clark r...@ti.com
The GEM handle takes the reference. If a driver is actually importing a
foreign dmabuf, rather than just re-importing it's own dmabuf, it needs
to do a get_dma_buf().
Signed-off-by: Rob
On Tue, Jul 24, 2012 at 1:07 AM, Rob Clark rob.cl...@linaro.org wrote:
From: Rob Clark r...@ti.com
The GEM handle takes the reference. If a driver is actually importing a
foreign dmabuf, rather than just re-importing it's own dmabuf, it needs
to do a get_dma_buf().
Signed-off-by: Rob Clark
From: Rob Clark
The GEM handle takes the reference. If a driver is actually importing a
foreign dmabuf, rather than just re-importing it's own dmabuf, it needs
to do a get_dma_buf().
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_prime.c|7 +++
From: Rob Clark r...@ti.com
The GEM handle takes the reference. If a driver is actually importing a
foreign dmabuf, rather than just re-importing it's own dmabuf, it needs
to do a get_dma_buf().
Signed-off-by: Rob Clark r...@ti.com
---
drivers/gpu/drm/drm_prime.c|7 +++
41 matches
Mail list logo