netdev - Re: Regression: supported_interfaces filling enforcement

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: Tue, 25 Jul 2023 12:58:31 +0200
From: "Linux regression tracking (Thorsten Leemhuis)"
 <regressions@...mhuis.info>
To: "Russell King (Oracle)" <linux@...linux.org.uk>,
 Vladimir Oltean <olteanv@...il.com>
Cc: Sergei Antonov <saproj@...il.com>, netdev@...r.kernel.org,
 Linux kernel regressions list <regressions@...ts.linux.dev>
Subject: Re: Regression: supported_interfaces filling enforcement

[CCing the regression list, as it should be in the loop for regressions:
https://docs.kernel.org/admin-guide/reporting-regressions.html]

On 13.07.23 17:08, Russell King (Oracle) wrote:
> On Mon, Jul 10, 2023 at 03:35:56PM +0300, Vladimir Oltean wrote:
>> On Tue, Jul 04, 2023 at 05:28:47PM +0300, Sergei Antonov wrote:
>>> This commit seems to break the mv88e6060 dsa driver:
>>> de5c9bf40c4582729f64f66d9cf4920d50beb897    "net: phylink: require
>>> supported_interfaces to be filled"
>>>
>>> The driver does not fill 'supported_interfaces'. What is the proper
>>> way to fix it? I managed to fix it by the following quick code.
>>> Comments? Recommendations?
>>
>> Ok, it seems that commit de5c9bf40c45 ("net: phylink: require
>> supported_interfaces to be filled") was based on a miscalculation.
> 
> Yes, it seems so. I'm not great with dealing with legacy stuff - which
> is something I've stated time and time again when drivers fall behind
> with phylink development. There's only so much that I can hold in my
> head, and I can't runtime test the legacy stuff.
> 
> I suspect two other DSA drivers are also broken by this:
> 
> drivers/net/dsa/dsa_loop.c
> drivers/net/dsa/realtek/rtl8366rb.c
> 
> based upon:
> 
> $ grep -lr dsa_switch_ops drivers/net/dsa | xargs grep -L '\.phylink_get_caps.*=' | xargs grep -L '\.adjust_link'

What happened to this regression? From here it looks like things
stalled, but I might have missed something, hence allow me to ask:

Is this still happening? Is anyone still working on fixing this?

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

#regzbot poke