netdev - Re: [PATCH net v3] net: dsa: mt7530: fix impossible MDIO address and issue warning

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: <20240704071600.36e45294@kernel.org>
Date: Thu, 4 Jul 2024 07:16:00 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Daniel Golle <daniel@...rotopia.org>
Cc: Arınç ÜNAL <arinc.unal@...nc9.com>, DENG Qingfang
 <dqfext@...il.com>, Sean Wang <sean.wang@...iatek.com>, Andrew Lunn
 <andrew@...n.ch>, Florian Fainelli <f.fainelli@...il.com>, Vladimir Oltean
 <olteanv@...il.com>, "David S. Miller" <davem@...emloft.net>, Eric Dumazet
 <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Matthias Brugger
 <matthias.bgg@...il.com>, AngeloGioacchino Del Regno
 <angelogioacchino.delregno@...labora.com>, Landen Chao
 <Landen.Chao@...iatek.com>, Frank Wunderlich <linux@...web.de>, Rob Herring
 <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-mediatek@...ts.infradead.org,
 regressions@...ts.linux.dev
Subject: Re: [PATCH net v3] net: dsa: mt7530: fix impossible MDIO address
 and issue warning

On Thu, 4 Jul 2024 11:48:42 +0100 Daniel Golle wrote:
> > > +return ((((phy_addr - MT7530_NUM_PORTS) & ~MT7530_NUM_PORTS) % PHY_MAX_ADDR) +
> > > +	MT7530_NUM_PORTS) & (PHY_MAX_ADDR - 1);  
> > 
> > nit: the return statement lacks indentation  
> 
> Yes, lacks an additional space to match the level of the first open parentheses.
> I'll fix that in the next round.

To be clear I meant the line with "return", not the continuation line
starting with MT7530_NUM_PORTS

> > but also based on the comment, isn't it:
> > 
> > 	return (round_down(phy_addr, MT7530_NUM_PORTS + 1) - 1)	& (PHY_MAX_ADDR - 1);  
> 
> The original, more complicated statement covers also the correct addresses,
> ie. 31 -> 31, 7 -> 7, 15 -> 15, 23 -> 23. However, the function is never
> called if the address is deemed correct, so that doesn't actually matter.
> 
> It's kinda difficult to decide whether it is more important to return
> correct results also for values never used with the current code, or
> have a slightly more readable and shorter function but with expectations
> regarding the input values given by the caller.
> 
> Opinions?

No strong opinion, but I do think "% PHY_MAX_ADDR" is superfluous, no?
The masking at the end with "& (PHY_MAX_ADDR - 1)" will take care of
truncation.