Received-SPF: pass (google.com: domain of linux-kernel+bounces-160624-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Message-ID: <50522abe-57d0-47df-9917-e0cd6848650f@gmail.com>
Date: Fri, 26 Apr 2024 12:43:15 -0700
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH net v2 3/3] net: bcmgenet: synchronize UMAC_CMD access
To: Florian Fainelli <florian.fainelli@broadcom.com>,
 "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>,
 Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>
Cc: bcm-kernel-feedback-list@broadcom.com, netdev@vger.kernel.org,
 linux-kernel@vger.kernel.org, stable@vger.kernel.org
References: <20240425222721.2148899-1-opendmb@gmail.com>
 <20240425222721.2148899-4-opendmb@gmail.com>
 <07b4cb83-08db-449d-9d73-88e84fa570bd@broadcom.com>
Content-Language: en-US
From: Doug Berger <opendmb@gmail.com>
In-Reply-To: <07b4cb83-08db-449d-9d73-88e84fa570bd@broadcom.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 4/26/2024 11:19 AM, Florian Fainelli wrote:
> On 4/25/24 15:27, Doug Berger wrote:
>> The UMAC_CMD register is written from different execution
>> contexts and has insufficient synchronization protections to
>> prevent possible corruption. Of particular concern are the
>> acceses from the phy_device delayed work context used by the
>> adjust_link call and the BH context that may be used by the
>> ndo_set_rx_mode call.
>>
>> A spinlock is added to the driver to protect contended register
>> accesses (i.e. reg_lock) and it is used to synchronize accesses
>> to UMAC_CMD.
>>
>> Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Doug Berger <opendmb@gmail.com>
> 
> Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
> 
> As a bug fix this is totally fine. I believe there could be an 
> improvement made in 'net-next' whereby we introduce an 
> unimac_rmw_locked() or something that essentially does:
> 
> void unimac_rmw_locked(struct bcmgenet_priv *priv, u32 offset, u32 
> mask_clear, u32 mask_set)
> {
>      u32 reg;
>      spin_lock_bh(&priv->reg_lock);
>      reg = bcmgenet_umac_readl(priv, offset);
>      reg &= ~mask_clear;
>      reg |= mask_set;
>      bcmgenet_umac_writel(priv, reg, offset);
>      spin_unlock_bh(&priv->reg_lock);
> }
> 
> At least a couple of callers could benefit from it. Thanks!
The only issue I see is enforcing the 2us delay in reset_umac(). A 
scenario where a different context might attempt to modify UMAC_CMD 
during that window is admittedly contrived, but the approach of this 
commit provides better protection.

-Doug