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 12:19:40 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Daniel Díaz <daniel.diaz@...aro.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, paul@...pouillou.net
Subject: Re: [PATCH 5.15 000/245] 5.15.150-rc1 review

On 2/29/24 11:54, Greg Kroah-Hartman wrote:
> On Tue, Feb 27, 2024 at 12:56:32PM -0600, Daniel Díaz wrote:
>> Hello!
>>
>> On 27/02/24 7:23 a. m., 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.
>>>
>>> The whole patch series can be found in one patch at:
>>> 	https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.150-rc1.gz
>>> or in the git tree and branch at:
>>> 	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
>>> and the diffstat can be found below.
>>>
>>> thanks,
>>>
>>> greg k-h
>>
>> We're seeing build regressions here with RISC-V, with GCC 8, GCC 12, and Clang 17:
>>
>> -----8<-----
>>    In file included from /builds/linux/include/linux/list.h:9,
>>                     from /builds/linux/include/linux/module.h:12,
>>                     from /builds/linux/drivers/net/ethernet/realtek/r8169_main.c:12:
>>    /builds/linux/drivers/net/ethernet/realtek/r8169_main.c:5512:35: error: 'rtl8169_pm_ops' undeclared here (not in a function); did you mean 'rtl8169_poll'?
>>     5512 |         .driver.pm      = pm_ptr(&rtl8169_pm_ops),
>>          |                                   ^~~~~~~~~~~~~~
>>    /builds/linux/include/linux/kernel.h:46:44: note: in definition of macro 'PTR_IF'
>>       46 | #define PTR_IF(cond, ptr)       ((cond) ? (ptr) : NULL)
>>          |                                            ^~~
>>    /builds/linux/drivers/net/ethernet/realtek/r8169_main.c:5512:27: note: in expansion of macro 'pm_ptr'
>>     5512 |         .driver.pm      = pm_ptr(&rtl8169_pm_ops),
>>          |                           ^~~~~~
>>    make[5]: *** [/builds/linux/scripts/Makefile.build:289: drivers/net/ethernet/realtek/r8169_main.o] Error 1
>> ----->8-----
>>
>> Bisection points to:
>>
>>    commit ac2871f646a8f556203f5b6be875ce406d855ddb
>>    Author: Paul Cercueil <paul@...pouillou.net>
>>    Date:   Tue Dec 7 00:20:59 2021 +0000
>>        PM: core: Redefine pm_ptr() macro
>>        [ Upstream commit c06ef740d401d0f4ab188882bf6f8d9cf0f75eaf ]
>>
>> A revert could not be done cleanly.
>>
>> Tuxmake reproducer:
>>
>>    tuxmake --runtime podman --target-arch riscv --toolchain gcc-12 --kconfig defconfig
>>
>> Reported-by: Linux Kernel Functional Testing <lkft@...aro.org>
> 
> I've been beating on this for a while and I really don't know what is
> happening, sorry.  The driver looks fine, something is "odd" with riscv

No, the driver is not fine. Upstream has commit 8fe6e670640e ("r8169: use new
PM macros") which makes rtl8169_pm_ops unconditional. That commit is missing
in v5.15.y. Applying it makes the problem disappear.

In other words, the problem is not riscv specific, but will be seen if the
realtek driver is built with CONFIG_PM=n (which happens to be the case with
riscv:defconfig).

Guenter