netdev - Re: [PATCH net-next 0/2] net: dsa: realtek: fix PHY register read corruption

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: <87k0dusmar.fsf@bang-olufsen.dk>
Date:   Wed, 16 Feb 2022 18:23:25 +0000
From:   Alvin Šipraga <ALSI@...g-olufsen.dk>
To:     Luiz Angelo Daros de Luca <luizluca@...il.com>
CC:     Alvin Šipraga <alvin@...s.dk>,
        Linus Walleij <linus.walleij@...aro.org>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vladimir Oltean <olteanv@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Michael Rasmussen <MIR@...g-olufsen.dk>,
        Arınç ÜNAL <arinc.unal@...nc9.com>,
        "open list:NETWORKING DRIVERS" <netdev@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next 0/2] net: dsa: realtek: fix PHY register read
 corruption

Luiz Angelo Daros de Luca <luizluca@...il.com> writes:

>> These two patches fix the issue reported by Arınç where PHY register
>> reads sometimes return garbage data.
>>
>> MAINTAINERS: Please can you help me with the targetting of these two
>> patches? This bug is present ca. 5.16, when the SMI version of the
>> rtl8365mb driver was introduced. But now in net-next we have the MDIO
>> interface from Luiz, where the issue is also present. I am sending what
>> I think is an ideal patch series, but should I split it up and send the
>> SMI-related changes to net and the MDIO changes to net-next? If so, how
>> would I go about splitting it while preventing merge conflicts and build
>> errors?
>>
>> For now I am sending it to net-next so that the whole thing can be
>> reviewed. If it's applied, I would gladly backport the fix to the stable
>> tree for 5.16, but I am still confused about what to do for 5.17.
>>
>> Thanks for your help.
>>
>>
>> Alvin Šipraga (2):
>>   net: dsa: realtek: allow subdrivers to externally lock regmap
>>   net: dsa: realtek: rtl8365mb: serialize indirect PHY register access
>>
>>  drivers/net/dsa/realtek/realtek-mdio.c | 46 +++++++++++++++++++++-
>>  drivers/net/dsa/realtek/realtek-smi.c  | 48 +++++++++++++++++++++--
>>  drivers/net/dsa/realtek/realtek.h      |  2 +
>>  drivers/net/dsa/realtek/rtl8365mb.c    | 54 ++++++++++++++++----------
>>  4 files changed, 124 insertions(+), 26 deletions(-)
>>
>> --
>> 2.35.0
>>
>
> Thanks for the fix, Alvin.
>
> I still feel like we are trying to go around a regmap limitation
> instead of fixing it there. If we control regmap lock (we can define a
> custom lock/unlock) and create new regmap_{read,write}_nolock
> variants, we'll just need to lock the regmap, do whatever you need,
> and unlock it.

Can you show me what those regmap_{read,write}_nolock variants would
look like in your example? And what about the other regmap_ APIs we use,
like regmap_read_poll_timeout, regmap_update_bits, etc. - do you propose
to reimplement all of these?

>
> BTW, I believe that, for realtek-mdio, a regmap custom lock mechanism
> could simply use mdio lock while realtek-smi already has priv->lock.

Hmm OK. Actually I'm a bit confused about the mdio_lock: can you explain
what it's guarding against, for someone unfamiliar with MDIO? Currently
realtek-mdio's regmap has an additional lock around it (disable_locking
is 0), so with these patches applied the number of locks remains the
same.

priv->lock is a spinlock which is inappropriate here. I'm not really
sure what the point of it is, besides to handle unlocked calls to the
_noack function. It might be removable altogether but I would prefer not
to touch it for this series.

Kind regards,
Alvin