netdev - Re: [PATCH v3 net 8/8] net: enetc: keep RX ring consumer index in sync with hardware

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: <20210301133425.drijvbm542apzv6b@skbuf>
Date:   Mon, 1 Mar 2021 15:34:25 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org
Cc:     Michael Walle <michael@...le.cc>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Alexandru Marginean <alexandru.marginean@....com>,
        Andrew Lunn <andrew@...n.ch>,
        Vladimir Oltean <vladimir.oltean@....com>
Subject: Re: [PATCH v3 net 8/8] net: enetc: keep RX ring consumer index in
 sync with hardware

On Mon, Mar 01, 2021 at 01:18:18PM +0200, Vladimir Oltean wrote:
> The simpler thing would be to put the write to the consumer index into
> enetc_refill_rx_ring directly, but there are issues with the MDIO
> locking: in the NAPI poll code we have the enetc_lock_mdio() taken from
> top-level and we use the unlocked enetc_wr_reg_hot, whereas in
> enetc_open, the enetc_lock_mdio() is not taken at the top level, but
> instead by each individual enetc_wr_reg, so we are forced to put an
> additional enetc_wr_reg in enetc_setup_rxbdr. Better organization of
> the code is left as a refactoring exercise.
> 
> Fixes: d4fd0404c1c9 ("enetc: Introduce basic PF and VF ENETC ethernet drivers")
> Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>
> ---

Claudiu pointed out privately that this is exactly what was done prior
to commit fd5736bf9f23 ("enetc: Workaround for MDIO register access issue"),
and therefore, the driver used to work before that (I missed that during
my assessment). So my Fixes: tag is actually incorrect. I will send a
follow-up version where this is squashed with patch 7/8 and the Fixes:
tag is adjusted.