<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
Am 24.08.22 um 16:47 schrieb Jason Ekstrand:<br>
<blockquote type="cite" cite="mid:CAOFGe96pKaiH85ReT6y_V4vCKQjXz_hf2O7mqG89aiKXoFiF1w@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Aug 8, 2022 at 11:39
AM Jason Ekstrand <<a href="mailto:jason.ekstrand@collabora.com" moz-do-not-send="true" class="moz-txt-link-freetext">jason.ekstrand@collabora.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">On Sun, 2022-08-07 at
18:35 +0200, Christian König wrote:<br>
> Am 02.08.22 um 23:01 schrieb Jason Ekstrand:<br>
> > Ever since 68129f431faa ("dma-buf: warn about
containers in<br>
> > dma_resv object"),<br>
> > dma_resv_add_shared_fence will warn if you attempt
to add a<br>
> > container fence.<br>
> > While most drivers were fine, fences can also be
added to a<br>
> > dma_resv via the<br>
> > recently added DMA_BUF_IOCTL_IMPORT_SYNC_FILE.
Use<br>
> > dma_fence_unwrap_for_each<br>
> > to add each fence one at a time.<br>
> > <br>
> > Fixes: 594740497e99 ("dma-buf: Add an API for
importing sync files<br>
> > (v10)")<br>
> > Signed-off-by: Jason Ekstrand <<a href="mailto:jason.ekstrand@collabora.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">jason.ekstrand@collabora.com</a>><br>
> > Reported-by: Sarah Walker <<a href="mailto:Sarah.Walker@imgtec.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">Sarah.Walker@imgtec.com</a>><br>
> > Cc: Christian König <<a href="mailto:christian.koenig@amd.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">christian.koenig@amd.com</a>><br>
> > ---<br>
> > drivers/dma-buf/dma-buf.c | 23
+++++++++++++++++------<br>
> > 1 file changed, 17 insertions(+), 6 deletions(-)<br>
> > <br>
> > diff --git a/drivers/dma-buf/dma-buf.c
b/drivers/dma-buf/dma-buf.c<br>
> > index 630133284e2b..8d5d45112f52 100644<br>
> > --- a/drivers/dma-buf/dma-buf.c<br>
> > +++ b/drivers/dma-buf/dma-buf.c<br>
> > @@ -15,6 +15,7 @@<br>
> > #include <linux/slab.h><br>
> > #include <linux/dma-buf.h><br>
> > #include <linux/dma-fence.h><br>
> > +#include <linux/dma-fence-unwrap.h><br>
> > #include <linux/anon_inodes.h><br>
> > #include <linux/export.h><br>
> > #include <linux/debugfs.h><br>
> > @@ -391,8 +392,10 @@ static long
dma_buf_import_sync_file(struct<br>
> > dma_buf *dmabuf,<br>
> > const void
__user *user_data)<br>
> > {<br>
> > struct dma_buf_import_sync_file arg;<br>
> > - struct dma_fence *fence;<br>
> > + struct dma_fence *fence, *f;<br>
> > enum dma_resv_usage usage;<br>
> > + struct dma_fence_unwrap iter;<br>
> > + unsigned int num_fences;<br>
> > int ret = 0;<br>
> > <br>
> > if (copy_from_user(&arg, user_data,
sizeof(arg)))<br>
> > @@ -411,13 +414,21 @@ static long
dma_buf_import_sync_file(struct<br>
> > dma_buf *dmabuf,<br>
> > usage = (arg.flags &
DMA_BUF_SYNC_WRITE) ?<br>
> > DMA_RESV_USAGE_WRITE :<br>
> > <br>
> > DMA_RESV_USAGE_READ;<br>
> > <br>
> > - dma_resv_lock(dmabuf->resv, NULL);<br>
> > + num_fences = 0;<br>
> > + dma_fence_unwrap_for_each(f, &iter,
fence)<br>
> > + ++num_fences;<br>
> > <br>
> > - ret =
dma_resv_reserve_fences(dmabuf->resv, 1);<br>
> > - if (!ret)<br>
> >
- dma_resv_add_fence(dmabuf->resv, fence,
usage);<br>
> > + if (num_fences > 0) {<br>
> > + dma_resv_lock(dmabuf->resv,
NULL);<br>
> > <br>
> > - dma_resv_unlock(dmabuf->resv);<br>
> > + ret =
dma_resv_reserve_fences(dmabuf->resv,<br>
> > num_fences);<br>
> <br>
> That looks like it is misplaced.<br>
> <br>
> You *must* only lock the reservation object once and
then add all<br>
> fences <br>
> in one go.<br>
<br>
That's what I'm doing. Lock, reserve, add a bunch, unlock.
I am<br>
assuming that the iterator won't suddenly want to iterate
more fences<br>
between my initial count and when I go to add them but I
think that<br>
assumption is ok.<br>
</blockquote>
<div><br>
</div>
<div>Bump. This has been sitting here for a couple of weeks.
I still don't see the problem.</div>
</div>
</div>
</blockquote>
<br>
I've send you a patch for a bug fix in the dma_resv object regarding
this.<br>
<br>
Apart from that I've just seen that I miss read the code a bit,
didn't realized that there where two loops with
dma_fence_unwrap_for_each().<br>
<br>
Regards,<br>
Christian.<br>
<br>
<blockquote type="cite" cite="mid:CAOFGe96pKaiH85ReT6y_V4vCKQjXz_hf2O7mqG89aiKXoFiF1w@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>--Jason<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
--Jason<br>
<br>
<br>
> Thinking now about it we probably had a bug around that
before as<br>
> well. <br>
> Going to double check tomorrow.<br>
> <br>
> Regards,<br>
> Christian.<br>
> <br>
> > + if (!ret) {<br>
> >
+ dma_fence_unwrap_for_each(f,
&iter, fence)<br>
> >
+ dma_resv_add_fence(dmabuf->resv,
f,<br>
> > usage);<br>
> > + }<br>
> > +<br>
> > + dma_resv_unlock(dmabuf->resv);<br>
> > + }<br>
> > <br>
> > dma_fence_put(fence);<br>
> > <br>
> <br>
<br>
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>