netdev - Re: [PATCH net-next] net: of_get_phy_mode: Change API to solve int/unit warnings

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] [day] [month] [year] [list]

Message-ID: <20191024083744.GE17535@kadam>
Date:   Thu, 24 Oct 2019 11:46:40 +0300
From:   Dan Carpenter <dan.carpenter@...cle.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] net: of_get_phy_mode: Change API to solve
 int/unit warnings

On Thu, Oct 24, 2019 at 04:49:35AM +0200, Andrew Lunn wrote:
> On Wed, Oct 23, 2019 at 07:13:20PM -0700, David Miller wrote:
> > From: Andrew Lunn <andrew@...n.ch>
> > Date: Tue, 22 Oct 2019 03:18:17 +0200
> > 
> > > Before this change of_get_phy_mode() returned an enum,
> > > phy_interface_t. On error, -ENODEV etc, is returned. If the result of
> > > the function is stored in a variable of type phy_interface_t, and the
> > > compiler has decided to represent this as an unsigned int, comparision
> > > with -ENODEV etc, is a signed vs unsigned comparision.
> > > 
> > > Fix this problem by changing the API. Make the function return an
> > > error, or 0 on success, and pass a pointer, of type phy_interface_t,
> > > where the phy mode should be stored.
> > > 
> > > Reported-by: Dan Carpenter <dan.carpenter@...cle.com>
> > > Signed-off-by: Andrew Lunn <andrew@...n.ch>
> > 
> > So now we have code that uses the 'interface' value without checking
> > the error return value which means it's potentially uninitialized.
> 
> Hi David
> 
> If it did not check before, it was passing -ENODEV to something. So it
> was already broken. But an uninitialized value is worse. I can see
> about adding error checking where there are none.
> 

We could make it __must_check.  We don't use that annotation much
outside of core functions, but I don't see a downside to it.  Smatch and
0day bot will hopefully catch most of the uninitialized variables as is.

regards,
dan carpenter