Re: [PATCH v2 net] net: mvpp2: Prevent parser TCAM memory corruption

[Tobias Waldekranz <tobias@waldekranz.com>]

On fre, mar 21, 2025 at 13:12, Andrew Lunn <andrew@lunn.ch> wrote:
>> +static int mvpp2_prs_init_from_hw_unlocked(struct mvpp2 *priv,
>> +					   struct mvpp2_prs_entry *pe, int tid)
>>  {
>>  	int i;
>>  
>
> This is called from quite a few places, and the locking is not always
> obvious. Maybe add

Agreed, that was why i chose the _unlocked suffix vs. just prefixing
with _ or something. For sure I can add it, I just want to run something
by you first:

Originally, my idea was to just protect mvpp2_prs_init_from_hw() and
mvpp2_prs_hw_write(). Then I realized that the software shadow of the
SRAM table must also be protected, which is why locking had to be
hoisted up to the current scope.

> __must_hold(&priv->prs_spinlock)
>
> so sparse can verify the call paths ?

So if we add these asserts only to the hardware access leaf functions,
do we risk inadvertently signaling to future readers that the lock is
only there to protect the hardware tables?