Re: [PATCH] dma-buf: fix debugfs versus rcu and fence dumping

2018-12-16 Thread kbuild test robot 
Hi Jérôme,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v4.20-rc6 next-20181214]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/jglisse-redhat-com/dma-buf-fix-debugfs-versus-rcu-and-fence-dumping/20181206-205935
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   include/linux/slab.h:332:43: warning: dubious: x & !y
   include/linux/slab.h:332:43: warning: dubious: x & !y
>> drivers/dma-buf/dma-buf.c:1031:9: warning: context imbalance in 
>> 'dma_buf_debug_show' - different lock contexts for basic block

vim +/dma_buf_debug_show +1031 drivers/dma-buf/dma-buf.c

b89e3563 drivers/base/dma-buf.cSumit Semwal   2013-04-04  1008  
b89e3563 drivers/base/dma-buf.cSumit Semwal   2013-04-04  1009  #ifdef 
CONFIG_DEBUG_FS
eb0b947e drivers/dma-buf/dma-buf.c Mathias Krause 2016-06-19  1010  static int 
dma_buf_debug_show(struct seq_file *s, void *unused)
b89e3563 drivers/base/dma-buf.cSumit Semwal   2013-04-04  1011  {
b89e3563 drivers/base/dma-buf.cSumit Semwal   2013-04-04  1012  int ret;
b89e3563 drivers/base/dma-buf.cSumit Semwal   2013-04-04  1013  struct 
dma_buf *buf_obj;
b89e3563 drivers/base/dma-buf.cSumit Semwal   2013-04-04  1014  struct 
dma_buf_attachment *attach_obj;
5eb2c72c drivers/dma-buf/dma-buf.c Russell King   2017-03-31  1015  struct 
reservation_object *robj;
5eb2c72c drivers/dma-buf/dma-buf.c Russell King   2017-03-31  1016  struct 
reservation_object_list *fobj;
5eb2c72c drivers/dma-buf/dma-buf.c Russell King   2017-03-31  1017  struct 
dma_fence *fence;
5eb2c72c drivers/dma-buf/dma-buf.c Russell King   2017-03-31  1018  
unsigned seq;
5eb2c72c drivers/dma-buf/dma-buf.c Russell King   2017-03-31  1019  int 
count = 0, attach_count, shared_count, i;
b89e3563 drivers/base/dma-buf.cSumit Semwal   2013-04-04  1020  size_t 
size = 0;
b89e3563 drivers/base/dma-buf.cSumit Semwal   2013-04-04  1021  
b89e3563 drivers/base/dma-buf.cSumit Semwal   2013-04-04  1022  ret = 
mutex_lock_interruptible(_list.lock);
b89e3563 drivers/base/dma-buf.cSumit Semwal   2013-04-04  1023  
b89e3563 drivers/base/dma-buf.cSumit Semwal   2013-04-04  1024  if (ret)
b89e3563 drivers/base/dma-buf.cSumit Semwal   2013-04-04  1025  
return ret;
b89e3563 drivers/base/dma-buf.cSumit Semwal   2013-04-04  1026  
c0b00a52 drivers/base/dma-buf.cSumit Semwal   2014-02-03  1027  
seq_puts(s, "\nDma-buf Objects:\n");
da6c8f5e drivers/dma-buf/dma-buf.c Russell King   2017-03-31  1028  
seq_printf(s, "%-8s\t%-8s\t%-8s\t%-8s\texp_name\n",
da6c8f5e drivers/dma-buf/dma-buf.c Russell King   2017-03-31  1029  
   "size", "flags", "mode", "count");
b89e3563 drivers/base/dma-buf.cSumit Semwal   2013-04-04  1030  
b89e3563 drivers/base/dma-buf.cSumit Semwal   2013-04-04 @1031  
list_for_each_entry(buf_obj, _list.head, list_node) {
b89e3563 drivers/base/dma-buf.cSumit Semwal   2013-04-04  1032  
ret = mutex_lock_interruptible(_obj->lock);
b89e3563 drivers/base/dma-buf.cSumit Semwal   2013-04-04  1033  
b89e3563 drivers/base/dma-buf.cSumit Semwal   2013-04-04  1034  
if (ret) {
c0b00a52 drivers/base/dma-buf.cSumit Semwal   2014-02-03  1035  
seq_puts(s,
b89e3563 drivers/base/dma-buf.cSumit Semwal   2013-04-04  1036  
 "\tERROR locking buffer object: skipping\n");
b89e3563 drivers/base/dma-buf.cSumit Semwal   2013-04-04  1037  
continue;
b89e3563 drivers/base/dma-buf.cSumit Semwal   2013-04-04  1038  
}
b89e3563 drivers/base/dma-buf.cSumit Semwal   2013-04-04  1039  
c0b00a52 drivers/base/dma-buf.cSumit Semwal   2014-02-03  1040  
seq_printf(s, "%08zu\t%08x\t%08x\t%08ld\t%s\n",
c0b00a52 drivers/base/dma-buf.cSumit Semwal   2014-02-03  1041  
buf_obj->size,
b89e3563 drivers/base/dma-buf.cSumit Semwal   2013-04-04  1042  
buf_obj->file->f_flags, buf_obj->file->f_mode,
a1f6dbac drivers/dma-buf/dma-buf.c Al Viro2014-08-20  1043  
file_count(buf_obj->file),
c0b00a52 drivers/base/dma-buf.cSumit Semwal   2014-02-03  1044  
buf_obj->exp_name);
b89e3563 drivers/base/dma-buf.cSumit Semwal   2013-04-04  1045  
5eb2c72c drivers/dma-buf/dma-buf.c Russell King   2017-03-31  1046  
robj = buf_obj->resv;
5eb2c72c drivers/dma-buf/dma-buf.c Russell King   2017-03-31  1047  
while (true) {
5eb2c72c drivers/dma-buf/dma-buf.c Russell King   2017-03-31  1048

Re: [PATCH] dma-buf: fix debugfs versus rcu and fence dumping

2018-12-07 Thread Sasha Levin 
Hi,

[This is an automated email]

This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all

The bot has tested the following trees: v4.19.7, v4.14.86, v4.9.143, v4.4.166, 
v3.18.128, 

v4.19.7: Build OK!
v4.14.86: Build OK!
v4.9.143: Failed to apply! Possible dependencies:
5eb2c72c8acc ("dma-buf: fence debugging")

v4.4.166: Failed to apply! Possible dependencies:
5eb2c72c8acc ("dma-buf: fence debugging")

v3.18.128: Failed to apply! Possible dependencies:
5eb2c72c8acc ("dma-buf: fence debugging")


How should we proceed with this patch?

--
Thanks,
Sasha
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dma-buf: fix debugfs versus rcu and fence dumping v2

2018-12-07 Thread Sasha Levin 
Hi,

[This is an automated email]

This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all

The bot has tested the following trees: v4.19.7, v4.14.86, v4.9.143, v4.4.166, 
v3.18.128, 

v4.19.7: Build OK!
v4.14.86: Build OK!
v4.9.143: Failed to apply! Possible dependencies:
5eb2c72c8acc ("dma-buf: fence debugging")

v4.4.166: Failed to apply! Possible dependencies:
5eb2c72c8acc ("dma-buf: fence debugging")

v3.18.128: Failed to apply! Possible dependencies:
5eb2c72c8acc ("dma-buf: fence debugging")


How should we proceed with this patch?

--
Thanks,
Sasha
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dma-buf: fix debugfs versus rcu and fence dumping v2

2018-12-06 Thread Koenig, Christian 
Am 06.12.18 um 17:58 schrieb Chris Wilson:
> Quoting jgli...@redhat.com (2018-12-06 15:47:04)
>> From: Jérôme Glisse 
>>
>> The debugfs take reference on fence without dropping them. Also the
>> rcu section are not well balance. Fix all that ...
> Wouldn't the code be a lot simpler (and a consistent snapshot) if it used
> reservation_object_get_fences_rcu()?

Yeah, thought about that as well.

Or even better move that code into reservation_object.c as 
reservation_object_show_fences() or something like that.

Christian.

> -Chris

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dma-buf: fix debugfs versus rcu and fence dumping v2

2018-12-06 Thread Chris Wilson 
Quoting jgli...@redhat.com (2018-12-06 15:47:04)
> From: Jérôme Glisse 
> 
> The debugfs take reference on fence without dropping them. Also the
> rcu section are not well balance. Fix all that ...

Wouldn't the code be a lot simpler (and a consistent snapshot) if it used
reservation_object_get_fences_rcu()?
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dma-buf: fix debugfs versus rcu and fence dumping

2018-12-06 Thread Jerome Glisse 
On Thu, Dec 06, 2018 at 04:08:12PM +, Koenig, Christian wrote:
> Am 06.12.18 um 16:21 schrieb Jerome Glisse:
> > On Thu, Dec 06, 2018 at 08:09:28AM +, Koenig, Christian wrote:
> >> Am 06.12.18 um 02:41 schrieb jgli...@redhat.com:
> >>> From: Jérôme Glisse 
> >>>
> >>> The debugfs take reference on fence without dropping them. Also the
> >>> rcu section are not well balance. Fix all that ...
> >>>
> >>> Signed-off-by: Jérôme Glisse 
> >>> Cc: Christian König 
> >>> Cc: Daniel Vetter 
> >>> Cc: Sumit Semwal 
> >>> Cc: linux-me...@vger.kernel.org
> >>> Cc: dri-devel@lists.freedesktop.org
> >>> Cc: linaro-mm-...@lists.linaro.org
> >>> Cc: Stéphane Marchesin 
> >>> Cc: sta...@vger.kernel.org
> >> Well NAK, you are now taking the RCU lock twice and dropping the RCU and
> >> still accessing fobj has a huge potential for accessing freed up memory.
> >>
> >> The only correct thing I can see here is to grab a reference to the
> >> fence before printing any info on it,
> >> Christian.
> > Hu ? That is exactly what i am doing, take reference under rcu,
> > rcu_unlock print the fence info, drop the fence reference, rcu
> > lock rinse and repeat ...
> >
> > Note that the fobj in _existing_ code is access outside the rcu
> > end that there is an rcu imbalance in that code ie a lonlely
> > rcu_unlock after the for loop.
> >
> > So that the existing code is broken.
> 
> No, the existing code is perfectly fine.
> 
> Please note the break in the loop before the rcu_unlock();
> > if (!read_seqcount_retry(>seq, seq))
> > break; <- HERE!
> > rcu_read_unlock();
> > }
> 
> So your patch breaks that and take the RCU read lock twice.

Ok missed that, i wonder if the refcount in balance explains
the crash that was reported to me ... i sent a patch just for
that.

Thank you for reviewing and pointing out the code i was
oblivious too :)

Cheers,
Jérôme
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dma-buf: fix debugfs versus rcu and fence dumping

2018-12-06 Thread Koenig, Christian 
Am 06.12.18 um 16:21 schrieb Jerome Glisse:
> On Thu, Dec 06, 2018 at 08:09:28AM +, Koenig, Christian wrote:
>> Am 06.12.18 um 02:41 schrieb jgli...@redhat.com:
>>> From: Jérôme Glisse 
>>>
>>> The debugfs take reference on fence without dropping them. Also the
>>> rcu section are not well balance. Fix all that ...
>>>
>>> Signed-off-by: Jérôme Glisse 
>>> Cc: Christian König 
>>> Cc: Daniel Vetter 
>>> Cc: Sumit Semwal 
>>> Cc: linux-me...@vger.kernel.org
>>> Cc: dri-devel@lists.freedesktop.org
>>> Cc: linaro-mm-...@lists.linaro.org
>>> Cc: Stéphane Marchesin 
>>> Cc: sta...@vger.kernel.org
>> Well NAK, you are now taking the RCU lock twice and dropping the RCU and
>> still accessing fobj has a huge potential for accessing freed up memory.
>>
>> The only correct thing I can see here is to grab a reference to the
>> fence before printing any info on it,
>> Christian.
> Hu ? That is exactly what i am doing, take reference under rcu,
> rcu_unlock print the fence info, drop the fence reference, rcu
> lock rinse and repeat ...
>
> Note that the fobj in _existing_ code is access outside the rcu
> end that there is an rcu imbalance in that code ie a lonlely
> rcu_unlock after the for loop.
>
> So that the existing code is broken.

No, the existing code is perfectly fine.

Please note the break in the loop before the rcu_unlock();
>   if (!read_seqcount_retry(>seq, seq))
>   break; <- HERE!
>   rcu_read_unlock();
>   }

So your patch breaks that and take the RCU read lock twice.

Regards,
Christian.

>
>>> ---
>>>drivers/dma-buf/dma-buf.c | 11 +--
>>>1 file changed, 9 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>>> index 13884474d158..f6f4de42ac49 100644
>>> --- a/drivers/dma-buf/dma-buf.c
>>> +++ b/drivers/dma-buf/dma-buf.c
>>> @@ -1051,24 +1051,31 @@ static int dma_buf_debug_show(struct seq_file *s, 
>>> void *unused)
>>> fobj = rcu_dereference(robj->fence);
>>> shared_count = fobj ? fobj->shared_count : 0;
>>> fence = rcu_dereference(robj->fence_excl);
>>> +   fence = dma_fence_get_rcu(fence);
>>> if (!read_seqcount_retry(>seq, seq))
>>> break;
>>> rcu_read_unlock();
>>> }
>>> -
>>> -   if (fence)
>>> +   if (fence) {
>>> seq_printf(s, "\tExclusive fence: %s %s %ssignalled\n",
>>>fence->ops->get_driver_name(fence),
>>>fence->ops->get_timeline_name(fence),
>>>dma_fence_is_signaled(fence) ? "" : "un");
>>> +   dma_fence_put(fence);
>>> +   }
>>> +
>>> +   rcu_read_lock();
>>> for (i = 0; i < shared_count; i++) {
>>> fence = rcu_dereference(fobj->shared[i]);
>>> if (!dma_fence_get_rcu(fence))
>>> continue;
>>> +   rcu_read_unlock();
>>> seq_printf(s, "\tShared fence: %s %s %ssignalled\n",
>>>fence->ops->get_driver_name(fence),
>>>fence->ops->get_timeline_name(fence),
>>>dma_fence_is_signaled(fence) ? "" : "un");
>>> +   dma_fence_put(fence);
>>> +   rcu_read_lock();
>>> }
>>> rcu_read_unlock();
>>>

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] dma-buf: fix debugfs versus rcu and fence dumping v2

2018-12-06 Thread jglisse 
From: Jérôme Glisse 

The debugfs take reference on fence without dropping them. Also the
rcu section are not well balance. Fix all that ...

Changed since v1:
- moved fobj logic around to be rcu safe

Signed-off-by: Jérôme Glisse 
Cc: Christian König 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: Stéphane Marchesin 
Cc: sta...@vger.kernel.org
---
 drivers/dma-buf/dma-buf.c | 21 -
 1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 13884474d158..9688d99894d6 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1048,27 +1048,38 @@ static int dma_buf_debug_show(struct seq_file *s, void 
*unused)
while (true) {
seq = read_seqcount_begin(>seq);
rcu_read_lock();
-   fobj = rcu_dereference(robj->fence);
-   shared_count = fobj ? fobj->shared_count : 0;
fence = rcu_dereference(robj->fence_excl);
+   fence = dma_fence_get_rcu(fence);
if (!read_seqcount_retry(>seq, seq))
break;
rcu_read_unlock();
}
-
-   if (fence)
+   if (fence) {
seq_printf(s, "\tExclusive fence: %s %s %ssignalled\n",
   fence->ops->get_driver_name(fence),
   fence->ops->get_timeline_name(fence),
   dma_fence_is_signaled(fence) ? "" : "un");
-   for (i = 0; i < shared_count; i++) {
+   dma_fence_put(fence);
+   }
+
+   rcu_read_lock();
+   fobj = rcu_dereference(robj->fence);
+   shared_count = fobj ? fobj->shared_count : 0;
+   for (i = 0, fence = NULL; i < shared_count; i++) {
fence = rcu_dereference(fobj->shared[i]);
if (!dma_fence_get_rcu(fence))
continue;
+   rcu_read_unlock();
+
seq_printf(s, "\tShared fence: %s %s %ssignalled\n",
   fence->ops->get_driver_name(fence),
   fence->ops->get_timeline_name(fence),
   dma_fence_is_signaled(fence) ? "" : "un");
+   dma_fence_put(fence);
+
+   rcu_read_lock();
+   fobj = rcu_dereference(robj->fence);
+   shared_count = fobj ? fobj->shared_count : 0;
}
rcu_read_unlock();
 
-- 
2.17.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dma-buf: fix debugfs versus rcu and fence dumping

2018-12-06 Thread Jerome Glisse 
On Thu, Dec 06, 2018 at 08:09:28AM +, Koenig, Christian wrote:
> Am 06.12.18 um 02:41 schrieb jgli...@redhat.com:
> > From: Jérôme Glisse 
> >
> > The debugfs take reference on fence without dropping them. Also the
> > rcu section are not well balance. Fix all that ...
> >
> > Signed-off-by: Jérôme Glisse 
> > Cc: Christian König 
> > Cc: Daniel Vetter 
> > Cc: Sumit Semwal 
> > Cc: linux-me...@vger.kernel.org
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: linaro-mm-...@lists.linaro.org
> > Cc: Stéphane Marchesin 
> > Cc: sta...@vger.kernel.org
> 
> Well NAK, you are now taking the RCU lock twice and dropping the RCU and 
> still accessing fobj has a huge potential for accessing freed up memory.
> 
> The only correct thing I can see here is to grab a reference to the 
> fence before printing any info on it,
> Christian.

Hu ? That is exactly what i am doing, take reference under rcu,
rcu_unlock print the fence info, drop the fence reference, rcu
lock rinse and repeat ...

Note that the fobj in _existing_ code is access outside the rcu
end that there is an rcu imbalance in that code ie a lonlely
rcu_unlock after the for loop.

So that the existing code is broken.

> 
> > ---
> >   drivers/dma-buf/dma-buf.c | 11 +--
> >   1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > index 13884474d158..f6f4de42ac49 100644
> > --- a/drivers/dma-buf/dma-buf.c
> > +++ b/drivers/dma-buf/dma-buf.c
> > @@ -1051,24 +1051,31 @@ static int dma_buf_debug_show(struct seq_file *s, 
> > void *unused)
> > fobj = rcu_dereference(robj->fence);
> > shared_count = fobj ? fobj->shared_count : 0;
> > fence = rcu_dereference(robj->fence_excl);
> > +   fence = dma_fence_get_rcu(fence);
> > if (!read_seqcount_retry(>seq, seq))
> > break;
> > rcu_read_unlock();
> > }
> > -
> > -   if (fence)
> > +   if (fence) {
> > seq_printf(s, "\tExclusive fence: %s %s %ssignalled\n",
> >fence->ops->get_driver_name(fence),
> >fence->ops->get_timeline_name(fence),
> >dma_fence_is_signaled(fence) ? "" : "un");
> > +   dma_fence_put(fence);
> > +   }
> > +
> > +   rcu_read_lock();
> > for (i = 0; i < shared_count; i++) {
> > fence = rcu_dereference(fobj->shared[i]);
> > if (!dma_fence_get_rcu(fence))
> > continue;
> > +   rcu_read_unlock();
> > seq_printf(s, "\tShared fence: %s %s %ssignalled\n",
> >fence->ops->get_driver_name(fence),
> >fence->ops->get_timeline_name(fence),
> >dma_fence_is_signaled(fence) ? "" : "un");
> > +   dma_fence_put(fence);
> > +   rcu_read_lock();
> > }
> > rcu_read_unlock();
> >   
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dma-buf: fix debugfs versus rcu and fence dumping

2018-12-06 Thread Koenig, Christian 
Am 06.12.18 um 02:41 schrieb jgli...@redhat.com:
> From: Jérôme Glisse 
>
> The debugfs take reference on fence without dropping them. Also the
> rcu section are not well balance. Fix all that ...
>
> Signed-off-by: Jérôme Glisse 
> Cc: Christian König 
> Cc: Daniel Vetter 
> Cc: Sumit Semwal 
> Cc: linux-me...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linaro-mm-...@lists.linaro.org
> Cc: Stéphane Marchesin 
> Cc: sta...@vger.kernel.org

Well NAK, you are now taking the RCU lock twice and dropping the RCU and 
still accessing fobj has a huge potential for accessing freed up memory.

The only correct thing I can see here is to grab a reference to the 
fence before printing any info on it,
Christian.

> ---
>   drivers/dma-buf/dma-buf.c | 11 +--
>   1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 13884474d158..f6f4de42ac49 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -1051,24 +1051,31 @@ static int dma_buf_debug_show(struct seq_file *s, 
> void *unused)
>   fobj = rcu_dereference(robj->fence);
>   shared_count = fobj ? fobj->shared_count : 0;
>   fence = rcu_dereference(robj->fence_excl);
> + fence = dma_fence_get_rcu(fence);
>   if (!read_seqcount_retry(>seq, seq))
>   break;
>   rcu_read_unlock();
>   }
> -
> - if (fence)
> + if (fence) {
>   seq_printf(s, "\tExclusive fence: %s %s %ssignalled\n",
>  fence->ops->get_driver_name(fence),
>  fence->ops->get_timeline_name(fence),
>  dma_fence_is_signaled(fence) ? "" : "un");
> + dma_fence_put(fence);
> + }
> +
> + rcu_read_lock();
>   for (i = 0; i < shared_count; i++) {
>   fence = rcu_dereference(fobj->shared[i]);
>   if (!dma_fence_get_rcu(fence))
>   continue;
> + rcu_read_unlock();
>   seq_printf(s, "\tShared fence: %s %s %ssignalled\n",
>  fence->ops->get_driver_name(fence),
>  fence->ops->get_timeline_name(fence),
>  dma_fence_is_signaled(fence) ? "" : "un");
> + dma_fence_put(fence);
> + rcu_read_lock();
>   }
>   rcu_read_unlock();
>   

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] dma-buf: fix debugfs versus rcu and fence dumping

2018-12-05 Thread jglisse 
From: Jérôme Glisse 

The debugfs take reference on fence without dropping them. Also the
rcu section are not well balance. Fix all that ...

Signed-off-by: Jérôme Glisse 
Cc: Christian König 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: Stéphane Marchesin 
Cc: sta...@vger.kernel.org
---
 drivers/dma-buf/dma-buf.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 13884474d158..f6f4de42ac49 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1051,24 +1051,31 @@ static int dma_buf_debug_show(struct seq_file *s, void 
*unused)
fobj = rcu_dereference(robj->fence);
shared_count = fobj ? fobj->shared_count : 0;
fence = rcu_dereference(robj->fence_excl);
+   fence = dma_fence_get_rcu(fence);
if (!read_seqcount_retry(>seq, seq))
break;
rcu_read_unlock();
}
-
-   if (fence)
+   if (fence) {
seq_printf(s, "\tExclusive fence: %s %s %ssignalled\n",
   fence->ops->get_driver_name(fence),
   fence->ops->get_timeline_name(fence),
   dma_fence_is_signaled(fence) ? "" : "un");
+   dma_fence_put(fence);
+   }
+
+   rcu_read_lock();
for (i = 0; i < shared_count; i++) {
fence = rcu_dereference(fobj->shared[i]);
if (!dma_fence_get_rcu(fence))
continue;
+   rcu_read_unlock();
seq_printf(s, "\tShared fence: %s %s %ssignalled\n",
   fence->ops->get_driver_name(fence),
   fence->ops->get_timeline_name(fence),
   dma_fence_is_signaled(fence) ? "" : "un");
+   dma_fence_put(fence);
+   rcu_read_lock();
}
rcu_read_unlock();
 
-- 
2.17.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel