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

Message-ID: <20191024024935.GM5707@lunn.ch>
Date:   Thu, 24 Oct 2019 04:49:35 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     David Miller <davem@...emloft.net>
Cc:     netdev@...r.kernel.org, dan.carpenter@...cle.com
Subject: Re: [PATCH net-next] net: of_get_phy_mode: Change API to solve
 int/unit warnings

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.

> There are also a bunch of reverse christmas tree violations created
> by this patch as well :-) :-) :-)

I tried to avoid that, but a lot of drivers are not reverse christmas
to start with. In which case i tried to not break it any more. But i
can review my changes.

    Andrew