[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BANLkTi=jw5=9LcwxnXW6xNkF4RbFhHaB55Au=oDhn1yYWf53dA@mail.gmail.com>
Date: Mon, 13 Jun 2011 17:34:00 -0700
From: Greg Thelen <gthelen@...gle.com>
To: Stephen Hemminger <shemminger@...tta.com>
Cc: Stephen Hemminger <shemminger@...ux-foundation.org>,
netdev@...r.kernel.org,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] sky2: avoid using uninitialized variable
On Mon, Jun 13, 2011 at 3:12 PM, Stephen Hemminger
<shemminger@...tta.com> wrote:
> On Mon, 13 Jun 2011 14:21:59 -0700
> Greg Thelen <gthelen@...gle.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@...gle.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@...gle.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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists