Patchwork sky2: avoid using uninitialized variable

login
register
mail settings
Submitter Greg Thelen
Date June 13, 2011, 9:21 p.m.
Message ID <xr93vcw9s9zc.fsf@gthelen.mtv.corp.google.com>
Download mbox | patch
Permalink /patch/100181/
State Changes Requested
Delegated to: David Miller
Headers show

Comments

Greg Thelen - June 13, 2011, 9:21 p.m.
I am not sure if 0 or ~0 would be a better choice in the gm_phy_read()
error case.  I used 0.  A more complete solution might be to plumb up
error handling to the callers of gm_phy_read().

==
From 37486219a3d93881f3b2619a4b2bb21be62db7d4 Mon Sep 17 00:00:00 2001
From: Greg Thelen <gthelen@google.com>
Date: Mon, 13 Jun 2011 14:09:07 -0700
Subject: [PATCH] sky2: avoid using uninitialized variable

Prior to this change gm_phy_read() could return an uninitialized
variable if __gm_phy_read() failed.

This change returns zero in the failure case.

Signed-off-by: Greg Thelen <gthelen@google.com>
---
 drivers/net/sky2.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)
stephen hemminger - June 13, 2011, 10:12 p.m.
On Mon, 13 Jun 2011 14:21:59 -0700
Greg Thelen <gthelen@google.com> wrote:

> I am not sure if 0 or ~0 would be a better choice in the gm_phy_read()
> error case.  I used 0.  A more complete solution might be to plumb up
> error handling to the callers of gm_phy_read().
> 
> ==
> From 37486219a3d93881f3b2619a4b2bb21be62db7d4 Mon Sep 17 00:00:00 2001
> From: Greg Thelen <gthelen@google.com>
> Date: Mon, 13 Jun 2011 14:09:07 -0700
> Subject: [PATCH] sky2: avoid using uninitialized variable
> 
> Prior to this change gm_phy_read() could return an uninitialized
> variable if __gm_phy_read() failed.
> 
> This change returns zero in the failure case.
> 
> Signed-off-by: Greg Thelen <gthelen@google.com>

Shouldn't the callers be changed to check rather than just returning
0 and masking the problem.

--
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
Greg Thelen - June 14, 2011, 12:34 a.m.
On Mon, Jun 13, 2011 at 3:12 PM, Stephen Hemminger
<shemminger@vyatta.com> wrote:
> On Mon, 13 Jun 2011 14:21:59 -0700
> Greg Thelen <gthelen@google.com> wrote:
>
>> I am not sure if 0 or ~0 would be a better choice in the gm_phy_read()
>> error case.  I used 0.  A more complete solution might be to plumb up
>> error handling to the callers of gm_phy_read().
>>
>> ==
>> From 37486219a3d93881f3b2619a4b2bb21be62db7d4 Mon Sep 17 00:00:00 2001
>> From: Greg Thelen <gthelen@google.com>
>> Date: Mon, 13 Jun 2011 14:09:07 -0700
>> Subject: [PATCH] sky2: avoid using uninitialized variable
>>
>> Prior to this change gm_phy_read() could return an uninitialized
>> variable if __gm_phy_read() failed.
>>
>> This change returns zero in the failure case.
>>
>> Signed-off-by: Greg Thelen <gthelen@google.com>
>
> Shouldn't the callers be changed to check rather than just returning
> 0 and masking the problem.

I agree that the right long term solution is to plumb the error
handling up through the callers.  This would involve deleting the
error-free gm_phy_read() routine and replacing all calls to it with
calls to error-capable __gm_phy_read().  This would require converting
several routines from returning void to returning int allowing errors
to propagate upwards.  Notable affected routines include:
sky2_phy_power_up(), sky2_wol_init(), sky2_phy_power_down(),
sky2_hw_down(), sky2_mac_init(), sky2_hw_up(), sky2_phy_intr(),
sky2_led().  sky2_restart() would likely have to re-queue the work
item in the case of failure.  Presumably sky2_poll() would return 0 if
error is seen.  On a related note, it also seems that gm_phy_write()
callers should be checking its return value to also handle the same
class of I/O errors.  Testing these changes would involve injecting
error values or access to certain kinds of broken hardware.

For the short term I figured that not consuming random data was a step
in right direction.  But I understand if you prefer to hold out for
the complete solution.  Unfortunately, I do not currently have time to
contribute to the complete solution.
--
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
stephen hemminger - June 14, 2011, 4:02 a.m.
On Mon, 13 Jun 2011 17:34:00 -0700
Greg Thelen <gthelen@google.com> wrote:

> On Mon, Jun 13, 2011 at 3:12 PM, Stephen Hemminger
> <shemminger@vyatta.com> wrote:
> > On Mon, 13 Jun 2011 14:21:59 -0700
> > Greg Thelen <gthelen@google.com> wrote:
> >
> >> I am not sure if 0 or ~0 would be a better choice in the gm_phy_read()
> >> error case.  I used 0.  A more complete solution might be to plumb up
> >> error handling to the callers of gm_phy_read().
> >>
> >> ==
> >> From 37486219a3d93881f3b2619a4b2bb21be62db7d4 Mon Sep 17 00:00:00 2001
> >> From: Greg Thelen <gthelen@google.com>
> >> Date: Mon, 13 Jun 2011 14:09:07 -0700
> >> Subject: [PATCH] sky2: avoid using uninitialized variable
> >>
> >> Prior to this change gm_phy_read() could return an uninitialized
> >> variable if __gm_phy_read() failed.
> >>
> >> This change returns zero in the failure case.
> >>
> >> Signed-off-by: Greg Thelen <gthelen@google.com>
> >
> > Shouldn't the callers be changed to check rather than just returning
> > 0 and masking the problem.
> 
> I agree that the right long term solution is to plumb the error
> handling up through the callers.  This would involve deleting the
> error-free gm_phy_read() routine and replacing all calls to it with
> calls to error-capable __gm_phy_read().  This would require converting
> several routines from returning void to returning int allowing errors
> to propagate upwards.  Notable affected routines include:
> sky2_phy_power_up(), sky2_wol_init(), sky2_phy_power_down(),
> sky2_hw_down(), sky2_mac_init(), sky2_hw_up(), sky2_phy_intr(),
> sky2_led().  sky2_restart() would likely have to re-queue the work
> item in the case of failure.  Presumably sky2_poll() would return 0 if
> error is seen.  On a related note, it also seems that gm_phy_write()
> callers should be checking its return value to also handle the same
> class of I/O errors.  Testing these changes would involve injecting
> error values or access to certain kinds of broken hardware.

In my experience if phy reads once successfully, it is going
to read every time. If there is a problem it only happens on
the first access (powered off, bad timing, etc).


 
> For the short term I figured that not consuming random data was a step
> in right direction.  But I understand if you prefer to hold out for
> the complete solution.  Unfortunately, I do not currently have time to
> contribute to the complete solution.

--
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
David Miller - June 17, 2011, 3:10 a.m.
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Tue, 14 Jun 2011 00:02:30 -0400

> In my experience if phy reads once successfully, it is going
> to read every time. If there is a problem it only happens on
> the first access (powered off, bad timing, etc).

It also happens when the PHY can't get a response for a certain
register, for whatever reason, before internal hw timeouts trigger.

Please, check all MII accesses.  That's what I do in every driver
I've written.

--
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
Ben Hutchings - June 17, 2011, 3:51 a.m.
On Thu, 2011-06-16 at 23:10 -0400, David Miller wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Tue, 14 Jun 2011 00:02:30 -0400
> 
> > In my experience if phy reads once successfully, it is going
> > to read every time. If there is a problem it only happens on
> > the first access (powered off, bad timing, etc).
> 
> It also happens when the PHY can't get a response for a certain
> register, for whatever reason, before internal hw timeouts trigger.
> 
> Please, check all MII accesses.  That's what I do in every driver
> I've written.

It doesn't help that the mii_if_info operations are defined to never
return errors.  This doesn't prevent drivers from doing so internally,
but it does set a bad example.

Ben.
David Miller - June 17, 2011, 3:58 a.m.
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Fri, 17 Jun 2011 04:51:35 +0100

> On Thu, 2011-06-16 at 23:10 -0400, David Miller wrote:
>> From: Stephen Hemminger <shemminger@vyatta.com>
>> Date: Tue, 14 Jun 2011 00:02:30 -0400
>> 
>> > In my experience if phy reads once successfully, it is going
>> > to read every time. If there is a problem it only happens on
>> > the first access (powered off, bad timing, etc).
>> 
>> It also happens when the PHY can't get a response for a certain
>> register, for whatever reason, before internal hw timeouts trigger.
>> 
>> Please, check all MII accesses.  That's what I do in every driver
>> I've written.
> 
> It doesn't help that the mii_if_info operations are defined to never
> return errors.  This doesn't prevent drivers from doing so internally,
> but it does set a bad example.

I totally agree.
--
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

Patch

diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
index 3ee41da..eba1ac4 100644
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -206,7 +206,8 @@  io_error:
 static inline u16 gm_phy_read(struct sky2_hw *hw, unsigned port, u16 reg)
 {
 	u16 v;
-	__gm_phy_read(hw, port, reg, &v);
+	if (__gm_phy_read(hw, port, reg, &v) < 0)
+		return 0;
 	return v;
 }