All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gustavo Padovan <gustavo@padovan.org>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	Sumit Semwal <sumit.semwal@linaro.org>,
	Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH] dma-buf/fence: Avoid use of uninitialised timestamp
Date: Tue, 14 Feb 2017 12:22:02 -0200	[thread overview]
Message-ID: <20170214142202.GC6562@joana> (raw)
In-Reply-To: <20170214135252.GJ18048@nuc-i3427.alporthouse.com>

2017-02-14 Chris Wilson <chris@chris-wilson.co.uk>:

> On Tue, Feb 14, 2017 at 11:40:38AM -0200, Gustavo Padovan wrote:
> > Hi Chris,
> > 
> > 2017-02-14 Chris Wilson <chris@chris-wilson.co.uk>:
> > > diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c
> > > index c769dc653b34..bfead12390f2 100644
> > > --- a/drivers/dma-buf/sync_debug.c
> > > +++ b/drivers/dma-buf/sync_debug.c
> > > @@ -84,7 +84,7 @@ static void sync_print_fence(struct seq_file *s,
> > >  		   show ? "_" : "",
> > >  		   sync_status_str(status));
> > >  
> > > -	if (status) {
> > > +	if (test_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, &fence->flags)) {
> > >  		struct timespec64 ts64 =
> > >  			ktime_to_timespec64(fence->timestamp);
> > 
> > How about add this test_bit() to dma_fence_is_signaled_locked() so
> > we test both for DMA_FENCE_FLAG_SIGNALED_BIT and
> > DMA_FENCE_FLAG_TIMESTAMP_BIT there at the same time?
> 
> I was thinking of only using it as communication with the timestamp
> user. That avoids getting into the situation as to which bit truly means
> is-signaled and we still only synchronize on SIGNALED_BIT.
> 
> It would be possible, but I don't think it makes anything simpler.

Yes, it doesn't make anything better. We should keep it that way for
users that doesn't need timestamp.

> 
> One thing that occurs to me is whether we should be setting the
> timestamp when we set an error. The above (sync_debug though) implies
> that it expects the error to have the timestamp. sync_fence_info could
> go either way.

We could do it. I don't see any reason against it.

Gustavo

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2017-02-14 14:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-14 12:40 [PATCH] dma-buf/fence: Avoid use of uninitialised timestamp Chris Wilson
2017-02-14 13:40 ` Gustavo Padovan
2017-02-14 13:52   ` Chris Wilson
2017-02-14 14:22     ` Gustavo Padovan [this message]
2017-02-14 14:28       ` Chris Wilson
2017-02-14 15:52 ` ✓ Fi.CI.BAT: success for " Patchwork
2017-07-11 17:09 ` [PATCH] " Chris Wilson
2017-07-14 19:20   ` Gustavo Padovan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170214142202.GC6562@joana \
    --to=gustavo@padovan.org \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=sumit.semwal@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.