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]
Message-ID: <1223812f-1dc3-40c2-a58a-2485d68e92b6@roeck-us.net>
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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ