linux-kernel - Re: [PATCH 5.15 000/245] 5.15.150-rc1 review

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 29 Feb 2024 10:56:36 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: stable@...r.kernel.org, patches@...ts.linux.dev,
 linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
 akpm@...ux-foundation.org, shuah@...nel.org, patches@...nelci.org,
 lkft-triage@...ts.linaro.org, pavel@...x.de, jonathanh@...dia.com,
 f.fainelli@...il.com, sudipm.mukherjee@...il.com, srw@...dewatkins.net,
 rwarsow@....de, conor@...nel.org, allen.lkml@...il.com
Subject: Re: [PATCH 5.15 000/245] 5.15.150-rc1 review

On 2/29/24 10:42, Greg Kroah-Hartman wrote:
> 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?
> 

It was found as part of the merge of v5.15.149 into ChromeOS. I did not check the
detailed circumstances and/or why ChromeOS stumbled over the problem. The merge introduces
other problems for us. We are busy tracking those down, so I don't have much time to look
into this further (not blaming v5.15.y, more likely it is the result of conflicts between
deviating code bases).

>> 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,
> 

Most likely I missed some other commit when running "git blame". Never mind, though.
We'll deal with the problem internally. It was just a note to let people know
that there is some inconsistency in v5.15.y.

Thanks,
Guenter