Messages in this thread | ![/](/images/icornerl.gif) | | Date | Thu, 29 Feb 2024 19:42:03 +0100 | From | Greg Kroah-Hartman <> | Subject | Re: [PATCH 5.15 000/245] 5.15.150-rc1 review |
| |
On Thu, Feb 29, 2024 at 10:15:49AM -0800, Guenter Roeck wrote: > On 2/27/24 05:23, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.15.150 release. > > There are 245 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Thu, 29 Feb 2024 13:15:36 +0000. > > Anything received after that time might be too late. > > > > $ git grep dma_fence_allocate_private_stub > drivers/dma-buf/dma-fence-unwrap.c: return dma_fence_allocate_private_stub(timestamp); > ^^^^^^^^^ > drivers/dma-buf/dma-fence-unwrap.c: tmp = dma_fence_allocate_private_stub(ktime_get()); > ^^^^^^^^^^^ > drivers/dma-buf/dma-fence.c: * dma_fence_allocate_private_stub - return a private, signaled fence > drivers/dma-buf/dma-fence.c:struct dma_fence *dma_fence_allocate_private_stub(void) > ^^^^ > drivers/dma-buf/dma-fence.c:EXPORT_SYMBOL(dma_fence_allocate_private_stub); > drivers/gpu/drm/drm_syncobj.c: struct dma_fence *fence = dma_fence_allocate_private_stub(); > include/linux/dma-fence.h:struct dma_fence *dma_fence_allocate_private_stub(void); > ^^^^
How is any of this building then? Does no one actually use dma-fence-unwrap.c?
> This was introduced with commit 4e82b9c11d3cd ("dma-buf: add dma_fence_timestamp helper") in > v5.15.149. The additional parameter to dma_fence_allocate_private_stub() was introduced in the > upstream kernel with commit f781f661e8c99 ("dma-buf: keep the signaling time of merged fences > v3") which is missing in v5.15.y.
f781f661e8c99 still uses an option to dma_fence_allocate_private_stub(): - return dma_fence_get_stub(); + return dma_fence_allocate_private_stub(timestamp);
So backporting that will continue the breakage, right?
confused,
greg k-h
| ![\](/images/icornerr.gif) |