Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1219594 > unrolled thread

[PATCH] net: phy: Handle postive return codes in phy_connect

Back to article view | Back to linux.kernel

Contents

  [PATCH] net: phy: Handle postive return codes in phy_connect Michael Welling <mwelling@ieee.org> - 2015-09-05 20:10 +0200
    Re: [PATCH] net: phy: Handle postive return codes in phy_connect Andrew Lunn <andrew@lunn.ch> - 2015-09-05 21:30 +0200
      Re: [PATCH] net: phy: Handle postive return codes in phy_connect Michael Welling <mwelling@ieee.org> - 2015-09-05 21:50 +0200
        Re: [PATCH] net: phy: Handle postive return codes in phy_connect Andrew Lunn <andrew@lunn.ch> - 2015-09-05 22:00 +0200
          Re: [PATCH] net: phy: Handle postive return codes in phy_connect Florian Fainelli <f.fainelli@gmail.com> - 2015-09-05 22:20 +0200
            Re: [PATCH] net: phy: Handle postive return codes in phy_connect Michael Welling <mwelling@ieee.org> - 2015-09-05 22:30 +0200
          Re: [PATCH] net: phy: Handle postive return codes in phy_connect Michael Welling <mwelling@ieee.org> - 2015-09-05 22:30 +0200
            Re: [PATCH] net: phy: Handle postive return codes in phy_connect Andrew Lunn <andrew@lunn.ch> - 2015-09-05 22:40 +0200

#1219594 — [PATCH] net: phy: Handle postive return codes in phy_connect

The function phy_connect_direct can possibly return a positive
return code. Using ERR_PTR with a positive value can lead to
deferencing of an invalid pointer.

Signed-off-by: Michael Welling <mwelling@ieee.org>
---
 drivers/net/phy/phy_device.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index c0f2111..a7e14a6 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -477,6 +477,9 @@ struct phy_device *phy_connect(struct net_device *dev, const char *bus_id,
 	phydev = to_phy_device(d);
 
 	rc = phy_connect_direct(dev, phydev, handler, interface);
+	if (rc > 0)
+		return ERR_PTR(-ENODEV);
+
 	if (rc)
 		return ERR_PTR(rc);
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1219614

On Sat, Sep 05, 2015 at 01:01:29PM -0500, Michael Welling wrote:
> The function phy_connect_direct can possibly return a positive
> return code. Using ERR_PTR with a positive value can lead to
> deferencing of an invalid pointer.

Is this the correct fix? Would it not be better to find where the
positive return code is from and fix that?

	 Andrew

> Signed-off-by: Michael Welling <mwelling@ieee.org>
> ---
>  drivers/net/phy/phy_device.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index c0f2111..a7e14a6 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -477,6 +477,9 @@ struct phy_device *phy_connect(struct net_device *dev, const char *bus_id,
>  	phydev = to_phy_device(d);
>  
>  	rc = phy_connect_direct(dev, phydev, handler, interface);
> +	if (rc > 0)
> +		return ERR_PTR(-ENODEV);
> +
>  	if (rc)
>  		return ERR_PTR(rc);
>  
> -- 
> 2.1.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1219625

On Sat, Sep 05, 2015 at 09:18:40PM +0200, Andrew Lunn wrote:
> On Sat, Sep 05, 2015 at 01:01:29PM -0500, Michael Welling wrote:
> > The function phy_connect_direct can possibly return a positive
> > return code. Using ERR_PTR with a positive value can lead to
> > deferencing of an invalid pointer.
> 
> Is this the correct fix? Would it not be better to find where the
> positive return code is from and fix that?

I guess I can trace it back to find out where the positive return code
is originating.

Is phy_connect_direct always supposed to return valid -errno?

> 
> 	 Andrew
> 
> > Signed-off-by: Michael Welling <mwelling@ieee.org>
> > ---
> >  drivers/net/phy/phy_device.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> > index c0f2111..a7e14a6 100644
> > --- a/drivers/net/phy/phy_device.c
> > +++ b/drivers/net/phy/phy_device.c
> > @@ -477,6 +477,9 @@ struct phy_device *phy_connect(struct net_device *dev, const char *bus_id,
> >  	phydev = to_phy_device(d);
> >  
> >  	rc = phy_connect_direct(dev, phydev, handler, interface);
> > +	if (rc > 0)
> > +		return ERR_PTR(-ENODEV);
> > +
> >  	if (rc)
> >  		return ERR_PTR(rc);
> >  
> > -- 
> > 2.1.4
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1219631

On Sat, Sep 05, 2015 at 02:44:01PM -0500, Michael Welling wrote:
> On Sat, Sep 05, 2015 at 09:18:40PM +0200, Andrew Lunn wrote:
> > On Sat, Sep 05, 2015 at 01:01:29PM -0500, Michael Welling wrote:
> > > The function phy_connect_direct can possibly return a positive
> > > return code. Using ERR_PTR with a positive value can lead to
> > > deferencing of an invalid pointer.
> > 
> > Is this the correct fix? Would it not be better to find where the
> > positive return code is from and fix that?
> 
> I guess I can trace it back to find out where the positive return code
> is originating.
> 
> Is phy_connect_direct always supposed to return valid -errno?

I would look at this from a different angle. A positive ERRNO is
probably a bug of some sort. So rather than papering over the cracks,
go find what the real issue is.

It might not be an ERRNO. E.g. https://lkml.org/lkml/2015/9/3/534
fixed a bug where a positive value is returned which is not an
indication of an error.

	   Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1219638

Le 09/05/15 12:47, Andrew Lunn a écrit :
> On Sat, Sep 05, 2015 at 02:44:01PM -0500, Michael Welling wrote:
>> On Sat, Sep 05, 2015 at 09:18:40PM +0200, Andrew Lunn wrote:
>>> On Sat, Sep 05, 2015 at 01:01:29PM -0500, Michael Welling wrote:
>>>> The function phy_connect_direct can possibly return a positive
>>>> return code. Using ERR_PTR with a positive value can lead to
>>>> deferencing of an invalid pointer.
>>>
>>> Is this the correct fix? Would it not be better to find where the
>>> positive return code is from and fix that?
>>
>> I guess I can trace it back to find out where the positive return code
>> is originating.
>>
>> Is phy_connect_direct always supposed to return valid -errno?
> 
> I would look at this from a different angle. A positive ERRNO is
> probably a bug of some sort. So rather than papering over the cracks,
> go find what the real issue is.

Agreed, you could place a WARN_ON(rc > 0) and get the offending call
trace leading to that problem. I suspect that one of the PHY drivers
might be returning a positive value as part of a phy_read() call and
that does not get properly filtered out.

> 
> It might not be an ERRNO. E.g. https://lkml.org/lkml/2015/9/3/534
> fixed a bug where a positive value is returned which is not an
> indication of an error.
> 
> 	   Andrew
> 
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1219640

On Sat, Sep 05, 2015 at 01:11:51PM -0700, Florian Fainelli wrote:
> Le 09/05/15 12:47, Andrew Lunn a écrit :
> > On Sat, Sep 05, 2015 at 02:44:01PM -0500, Michael Welling wrote:
> >> On Sat, Sep 05, 2015 at 09:18:40PM +0200, Andrew Lunn wrote:
> >>> On Sat, Sep 05, 2015 at 01:01:29PM -0500, Michael Welling wrote:
> >>>> The function phy_connect_direct can possibly return a positive
> >>>> return code. Using ERR_PTR with a positive value can lead to
> >>>> deferencing of an invalid pointer.
> >>>
> >>> Is this the correct fix? Would it not be better to find where the
> >>> positive return code is from and fix that?
> >>
> >> I guess I can trace it back to find out where the positive return code
> >> is originating.
> >>
> >> Is phy_connect_direct always supposed to return valid -errno?
> > 
> > I would look at this from a different angle. A positive ERRNO is
> > probably a bug of some sort. So rather than papering over the cracks,
> > go find what the real issue is.
> 
> Agreed, you could place a WARN_ON(rc > 0) and get the offending call
> trace leading to that problem. I suspect that one of the PHY drivers
> might be returning a positive value as part of a phy_read() call and
> that does not get properly filtered out.
>

Thanks for the feedback.

Does it hurt to always have a warning on positive return codes before
using ERR_PTR?

> > 
> > It might not be an ERRNO. E.g. https://lkml.org/lkml/2015/9/3/534
> > fixed a bug where a positive value is returned which is not an
> > indication of an error.
> > 
> > 	   Andrew
> > 
> -- 
> Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1219641

On Sat, Sep 05, 2015 at 09:47:55PM +0200, Andrew Lunn wrote:
> On Sat, Sep 05, 2015 at 02:44:01PM -0500, Michael Welling wrote:
> > On Sat, Sep 05, 2015 at 09:18:40PM +0200, Andrew Lunn wrote:
> > > On Sat, Sep 05, 2015 at 01:01:29PM -0500, Michael Welling wrote:
> > > > The function phy_connect_direct can possibly return a positive
> > > > return code. Using ERR_PTR with a positive value can lead to
> > > > deferencing of an invalid pointer.
> > > 
> > > Is this the correct fix? Would it not be better to find where the
> > > positive return code is from and fix that?
> > 
> > I guess I can trace it back to find out where the positive return code
> > is originating.
> > 
> > Is phy_connect_direct always supposed to return valid -errno?
> 
> I would look at this from a different angle. A positive ERRNO is
> probably a bug of some sort. So rather than papering over the cracks,
> go find what the real issue is.
> 
> It might not be an ERRNO. E.g. https://lkml.org/lkml/2015/9/3/534
> fixed a bug where a positive value is returned which is not an
> indication of an error.

It appears that I have stumbled upon the exact same issue as is fixed in
the patch above.

Good catch.
> 
> 	   Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1219642

> > It might not be an ERRNO. E.g. https://lkml.org/lkml/2015/9/3/534
> > fixed a bug where a positive value is returned which is not an
> > indication of an error.
> 
> It appears that I have stumbled upon the exact same issue as is fixed in
> the patch above.

Ah, sorry. I put that bug there :-(

The fix should be making its way into the kernel soon.

    Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web