netdev - Re: [PATCH net-next] enetc: Workaround for MDIO register access issue

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: <20201110230525.GO1456319@lunn.ch>
Date:   Wed, 11 Nov 2020 00:05:25 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Claudiu Manoil <claudiu.manoil@....com>
Cc:     netdev@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>,
        "David S . Miller" <davem@...emloft.net>,
        Alex Marginean <alexandru.marginean@....com>,
        Vladimir Oltean <vladimir.oltean@....com>
Subject: Re: [PATCH net-next] enetc: Workaround for MDIO register access issue

On Tue, Nov 10, 2020 at 05:43:04PM +0200, Claudiu Manoil wrote:
> From: Alex Marginean <alexandru.marginean@....com>
> 
> Due to a hardware issue, an access to MDIO registers
> that is concurrent with other ENETC register accesses
> may lead to the MDIO access being dropped or corrupted.
> The workaround introduces locking for all register accesses
> to the ENETC register space.  To reduce performance impact,
> a readers-writers locking scheme has been implemented.
> The writer in this case is the MDIO access code (irrelevant
> whether that MDIO access is a register read or write), and
> the reader is any access code to non-MDIO ENETC registers.
> Also, the datapath functions acquire the read lock fewer times
> and use _hot accessors.  All the rest of the code uses the _wa
> accessors which lock every register access.

Hi Claudiu

The code you are adding makes no comment about the odd using of
read/writer locks. This is going to confused people.

Please could you add helpers, probably as inline functions in a
header, which take/release the read_lock and the write_lock, which
don't use the name read_ or write_. Maybe something like
enetc_lock_mdio()/enetc_unlock_mdio(), enetc_lock_reg(),
enetc_unlock_reg(). Put comments by the helpers explaining what is
going on. That should help avoid future confusion and questions.

Thanks
	Andrew