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: <20230602101058.7faf94bf@kernel.org>
Date: Fri, 2 Jun 2023 10:10:58 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Andrew Lunn <andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet
 <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Dan Carpenter
 <dan.carpenter@...aro.org>, Oleksij Rempel <linux@...pel-privat.de>,
 netdev@...r.kernel.org
Subject: Re: [PATCH net-next] net: phylib: fix phy_read*_poll_timeout()

On Fri, 2 Jun 2023 17:34:31 +0100 Russell King (Oracle) wrote:
> On Fri, Jun 02, 2023 at 05:17:59PM +0100, Russell King (Oracle) wrote:
> > On Fri, Jun 02, 2023 at 09:05:39AM -0700, Jakub Kicinski wrote:  
> > > Wait, did the version I proposed not work?
> > > 
> > > https://lore.kernel.org/all/20230530121910.05b9f837@kernel.org/  
> > 
> > If we're into the business of throwing web URLs at each other for
> > messages we've already read, here's my one for you which contains
> > the explanation why your one is broken, and proposing my solution.
> > 
> > https://lore.kernel.org/all/ZHZmBBDSVMf1WQWI@shell.armlinux.org.uk/
> > 
> > To see exactly why yours is broken, see the paragraph starting
> > "The elephant in the room..."

Ah, yes, sorry, I'll admit I didn't get what you mean by the elephant
paragraph when I read that.

> If you don't like my solution, then I suppose another possibility would
> be:
> 
> #define __phy_poll_read(phydev, regnum, val) \
> 	({ \
> 		int __err; \
> 		__err = phy_read(phydev, regnum); \
> 		if (__err >= 0) \
> 			val = __err; \
> 		__err; \
> 	})
> 
> #define phy_read_poll_timeout(phydev, regnum, val, cond, sleep_us, \
>                                 timeout_us, sleep_before_read) \
> ({ \
> 	int __ret, __err; \
> 	__ret = read_poll_timeout(__phy_poll_read, __err, \
> 				  __err < 0 || (cond), \
> 		sleep_us, timeout_us, sleep_before_read, phydev, regnum, val); \
> 	if (__err < 0) \
> 		__ret = __err; \
> ...
> 
> but that brings with it the possibility of using an uninitialised
> "val" (e.g. if phy_read() returns an error on the first iteration.)
> and is way more horrid and even less easy to understand.
> 
> Remember that we default to *not* warning about uninitialised variables
> when building the kernel, so this won't produce a warning - which I
> guess is probably why you didn't notice that your suggestion left "val"
> uninitialised.

Right :(  Let's keep the patch as is.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ