<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/dma-buf, branch v6.1.87</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.87</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.87'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2024-04-10T14:28:21+00:00</updated>
<entry>
<title>dma-buf: Fix NULL pointer dereference in sanitycheck()</title>
<updated>2024-04-10T14:28:21+00:00</updated>
<author>
<name>Pavel Sakharov</name>
<email>p.sakharov@ispras.ru</email>
</author>
<published>2024-03-19T23:15:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0336995512cdab0c65e99e4cdd47c4606debe14e'/>
<id>urn:sha1:0336995512cdab0c65e99e4cdd47c4606debe14e</id>
<content type='text'>
[ Upstream commit 2295bd846765c766701e666ed2e4b35396be25e6 ]

If due to a memory allocation failure mock_chain() returns NULL, it is
passed to dma_fence_enable_sw_signaling() resulting in NULL pointer
dereference there.

Call dma_fence_enable_sw_signaling() only if mock_chain() succeeds.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Fixes: d62c43a953ce ("dma-buf: Enable signaling on fence for selftests")
Signed-off-by: Pavel Sakharov &lt;p.sakharov@ispras.ru&gt;
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Christian König &lt;christian.koenig@amd.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20240319231527.1821372-1-p.sakharov@ispras.ru
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>dma-buf: fix check in dma_resv_add_fence</title>
<updated>2023-12-08T07:51:15+00:00</updated>
<author>
<name>Christian König</name>
<email>christian.koenig@amd.com</email>
</author>
<published>2023-11-14T12:37:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fc98ea2699c090e0377d16d733dca7a0b7508237'/>
<id>urn:sha1:fc98ea2699c090e0377d16d733dca7a0b7508237</id>
<content type='text'>
commit 95ba893c9f4feb836ddce627efd0bb6af6667031 upstream.

It's valid to add the same fence multiple times to a dma-resv object and
we shouldn't need one extra slot for each.

Signed-off-by: Christian König &lt;christian.koenig@amd.com&gt;
Reviewed-by: Thomas Hellström &lt;thomas.hellstrom@linux.intel.com&gt;
Fixes: a3f7c10a269d5 ("dma-buf/dma-resv: check if the new fence is really later")
Cc: stable@vger.kernel.org # v5.19+
Link: https://patchwork.freedesktop.org/patch/msgid/20231115093035.1889-1-christian.koenig@amd.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>dma-buf: add dma_fence_timestamp helper</title>
<updated>2023-10-19T21:08:57+00:00</updated>
<author>
<name>Christian König</name>
<email>christian.koenig@amd.com</email>
</author>
<published>2023-09-08T08:27:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d67b5a2b97b6e8959117ff71fc2daa30e66c8290'/>
<id>urn:sha1:d67b5a2b97b6e8959117ff71fc2daa30e66c8290</id>
<content type='text'>
commit b83ce9cb4a465b8f9a3fa45561b721a9551f60e3 upstream.

When a fence signals there is a very small race window where the timestamp
isn't updated yet. sync_file solves this by busy waiting for the
timestamp to appear, but on other ocassions didn't handled this
correctly.

Provide a dma_fence_timestamp() helper function for this and use it in
all appropriate cases.

Another alternative would be to grab the spinlock when that happens.

v2 by teddy: add a wait parameter to wait for the timestamp to show up, in case
   the accurate timestamp is needed and/or the timestamp is not based on
   ktime (e.g. hw timestamp)
v3 chk: drop the parameter again for unified handling

Signed-off-by: Yunxiang Li &lt;Yunxiang.Li@amd.com&gt;
Signed-off-by: Christian König &lt;christian.koenig@amd.com&gt;
Fixes: 1774baa64f93 ("drm/scheduler: Change scheduled fence track v2")
Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
CC: stable@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20230929104725.2358-1-christian.koenig@amd.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>dma-buf: Add unlocked variant of attachment-mapping functions</title>
<updated>2023-09-23T09:11:08+00:00</updated>
<author>
<name>Dmitry Osipenko</name>
<email>dmitry.osipenko@collabora.com</email>
</author>
<published>2022-10-17T17:22:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b4539ff7a48d898bfb9c97c54bee8fd568db9d8b'/>
<id>urn:sha1:b4539ff7a48d898bfb9c97c54bee8fd568db9d8b</id>
<content type='text'>
[ Upstream commit 19d6634d8789573a9212ce78dbb4348ffd4f7f78 ]

Add unlocked variant of dma_buf_map/unmap_attachment() that will
be used by drivers that don't take the reservation lock explicitly.

Acked-by: Sumit Semwal &lt;sumit.semwal@linaro.org&gt;
Acked-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20221017172229.42269-3-dmitry.osipenko@collabora.com
Stable-dep-of: a2cb9cd6a394 ("misc: fastrpc: Fix incorrect DMA mapping unmap request")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>dma-buf/sw_sync: Avoid recursive lock during fence signal</title>
<updated>2023-08-30T14:11:12+00:00</updated>
<author>
<name>Rob Clark</name>
<email>robdclark@chromium.org</email>
</author>
<published>2023-08-18T14:59:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3282e79a85c1096b1f59925d7a04a4303d605759'/>
<id>urn:sha1:3282e79a85c1096b1f59925d7a04a4303d605759</id>
<content type='text'>
[ Upstream commit e531fdb5cd5ee2564b7fe10c8a9219e2b2fac61e ]

If a signal callback releases the sw_sync fence, that will trigger a
deadlock as the timeline_fence_release recurses onto the fence-&gt;lock
(used both for signaling and the the timeline tree).

To avoid that, temporarily hold an extra reference to the signalled
fences until after we drop the lock.

(This is an alternative implementation of https://patchwork.kernel.org/patch/11664717/
which avoids some potential UAF issues with the original patch.)

v2: Remove now obsolete comment, use list_move_tail() and
    list_del_init()

Reported-by: Bas Nieuwenhuizen &lt;bas@basnieuwenhuizen.nl&gt;
Fixes: d3c6dd1fb30d ("dma-buf/sw_sync: Synchronize signal vs syncpt free")
Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20230818145939.39697-1-robdclark@gmail.com
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>dma-buf: fix an error pointer vs NULL bug</title>
<updated>2023-08-03T08:24:19+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@linaro.org</email>
</author>
<published>2023-07-06T12:37:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c3d576baa6c8f0b34750a0b6f9b12e9d64625512'/>
<id>urn:sha1:c3d576baa6c8f0b34750a0b6f9b12e9d64625512</id>
<content type='text'>
commit 00ae1491f970acc454be0df63f50942d94825860 upstream.

Smatch detected potential error pointer dereference.

    drivers/gpu/drm/drm_syncobj.c:888 drm_syncobj_transfer_to_timeline()
    error: 'fence' dereferencing possible ERR_PTR()

The error pointer comes from dma_fence_allocate_private_stub().  One
caller expected error pointers and one expected NULL pointers.  Change
it to return NULL and update the caller which expected error pointers,
drm_syncobj_assign_null_handle(), to check for NULL instead.

Fixes: f781f661e8c9 ("dma-buf: keep the signaling time of merged fences v3")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Reviewed-by: Sumit Semwal &lt;sumit.semwal@linaro.org&gt;
Signed-off-by: Sumit Semwal &lt;sumit.semwal@linaro.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/b09f1996-3838-4fa2-9193-832b68262e43@moroto.mountain
Cc: Jindong Yue &lt;jindong.yue@nxp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>dma-buf: keep the signaling time of merged fences v3</title>
<updated>2023-08-03T08:24:19+00:00</updated>
<author>
<name>Christian König</name>
<email>christian.koenig@amd.com</email>
</author>
<published>2023-06-13T08:09:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=23acc2b850ba4dfdfe2700d728be3e27710260a1'/>
<id>urn:sha1:23acc2b850ba4dfdfe2700d728be3e27710260a1</id>
<content type='text'>
commit f781f661e8c99b0cb34129f2e374234d61864e77 upstream.

Some Android CTS is testing if the signaling time keeps consistent
during merges.

v2: use the current time if the fence is still in the signaling path and
the timestamp not yet available.
v3: improve comment, fix one more case to use the correct timestamp

Signed-off-by: Christian König &lt;christian.koenig@amd.com&gt;
Reviewed-by: Luben Tuikov &lt;luben.tuikov@amd.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20230630120041.109216-1-christian.koenig@amd.com
Cc: Jindong Yue &lt;jindong.yue@nxp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>dma-buf/dma-resv: Stop leaking on krealloc() failure</title>
<updated>2023-07-27T06:50:27+00:00</updated>
<author>
<name>Ville Syrjälä</name>
<email>ville.syrjala@linux.intel.com</email>
</author>
<published>2023-07-13T19:47:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=19e7b9f1f7e1cb92a4cc53b4c064f7fb4b1f1983'/>
<id>urn:sha1:19e7b9f1f7e1cb92a4cc53b4c064f7fb4b1f1983</id>
<content type='text'>
commit 05abb3be91d8788328231ee02973ab3d47f5e3d2 upstream.

Currently dma_resv_get_fences() will leak the previously
allocated array if the fence iteration got restarted and
the krealloc_array() fails.

Free the old array by hand, and make sure we still clear
the returned *fences so the caller won't end up accessing
freed memory. Some (but not all) of the callers of
dma_resv_get_fences() seem to still trawl through the
array even when dma_resv_get_fences() failed. And let's
zero out *num_fences as well for good measure.

Cc: Sumit Semwal &lt;sumit.semwal@linaro.org&gt;
Cc: Christian König &lt;christian.koenig@amd.com&gt;
Cc: linux-media@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-sig@lists.linaro.org
Fixes: d3c80698c9f5 ("dma-buf: use new iterator in dma_resv_get_fences v3")
Signed-off-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Cc: stable@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20230713194745.1751-1-ville.syrjala@linux.intel.com
Signed-off-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>dma-buf: actually set signaling bit for private stub fences</title>
<updated>2023-02-09T10:28:23+00:00</updated>
<author>
<name>Danilo Krummrich</name>
<email>dakr@redhat.com</email>
</author>
<published>2023-01-26T00:28:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e48a8ad77be33119d3ca74bfb13bad9b8e1840c5'/>
<id>urn:sha1:e48a8ad77be33119d3ca74bfb13bad9b8e1840c5</id>
<content type='text'>
commit d2ceea0eb6e17bb37d8b85cb4c16797c0d683d1c upstream.

In dma_fence_allocate_private_stub() set the signaling bit of the newly
allocated private stub fence rather than the signaling bit of the
shared dma_fence_stub.

Cc: &lt;stable@vger.kernel.org&gt; # v6.1
Fixes: c85d00d4fd8b ("dma-buf: set signaling bit for the stub fence")
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Danilo Krummrich &lt;dakr@redhat.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20230126002844.339593-1-dakr@redhat.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>dma-buf: fix dma_buf_export init order v2</title>
<updated>2023-01-24T06:24:30+00:00</updated>
<author>
<name>Christian König</name>
<email>christian.koenig@amd.com</email>
</author>
<published>2022-12-06T13:07:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=34762a3d6a85ac0c8044ff346a0dff260515cdf4'/>
<id>urn:sha1:34762a3d6a85ac0c8044ff346a0dff260515cdf4</id>
<content type='text'>
[ Upstream commit f728a5ea27c92133893590e731ce10f6561ced87 ]

The init order and resulting error handling in dma_buf_export
was pretty messy.

Subordinate objects like the file and the sysfs kernel objects
were initializing and wiring itself up with the object in the
wrong order resulting not only in complicating and partially
incorrect error handling, but also in publishing only halve
initialized DMA-buf objects.

Clean this up thoughtfully by allocating the file independent
of the DMA-buf object. Then allocate and initialize the DMA-buf
object itself, before publishing it through sysfs. If everything
works as expected the file is then connected with the DMA-buf
object and publish it through debugfs.

Also adds the missing dma_resv_fini() into the error handling.

v2: add some missing changes to dma_bug_getfile() and a missing NULL
    check in dma_buf_file_release()

Signed-off-by: Christian König &lt;christian.koenig@amd.com&gt;
Reviewed-by: Michael J. Ruhl &lt;michael.j.ruhl@intel.com&gt;
Reviewed-by: T.J. Mercier &lt;tjmercier@google.com&gt;
Acked-by: Sumit Semwal &lt;sumit.semwal@linaro.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20221209071535.933698-1-christian.koenig@amd.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
