Message-ID: <alpine.DEB.2.02.1210050712590.1958@localhost6.localdomain6>
Date:	Fri, 5 Oct 2012 07:22:03 +0200 (CEST)
From:	Julia Lawall <julia.lawall@...6.fr>
To:	Joe Perches <joe@...ches.com>
cc:	David Miller <davem@...emloft.net>, peter.senna@...il.com,
	shemminger@...tta.com, mlindner@...vell.com,
	kernel-janitors@...r.kernel.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 19/20] drivers/net/ethernet/marvell/skge.c: fix error
 return code

On Thu, 4 Oct 2012, Joe Perches wrote:

> On Thu, 2012-10-04 at 14:54 -0400, David Miller wrote:
>> From: Peter Senna Tschudin <peter.senna@...il.com>
>>> On Thu, Oct 4, 2012 at 8:23 PM, David Miller <davem@...emloft.net> wrote:
>>>> We want to know the implications of the bug being fixed.
>>>> Does it potentially cause an OOPS?  Bad reference counting and thus
>>>> potential leaks or early frees?
>>>>
>>>> You have to analyze the implications and ramifications of the bug
>>>> being fixed.  We need that information.
>
> You are asking for deeper level analysis that may not
> be reasonably possible from the robotic patch fixed
> by a robotic piece of a bit of code correction via a
> static analysis.

As Peter pointed out, it is not even a robotic fix, if robotic means 
literally that it was done by a robot.  A tool was used to find a 
potential problem, and then Peter studied the code to see what fix was 
appropriate.

In this case, finding out the impact, requires looking up the call chain 
in all directions to find out what the callers do with the returned value. 
And understanding the likely impact along the way.  Often the call chain 
involves function pointers.  This is all possible to do.  And perhaps it 
would be even more helpful to the consumers of the patch than just having 
the problem fixed.  But the fact remains that at other places in the 
function, someone thought it was useful to return an error code, so in the 
place where the error code return is missing, it seems like a useful fault 
to fix, whether it has an impact now or might have one later.  The main 
human analysis required to generate the patch is to be convinced that the 
given return path really represents an error condition and that the 
function normally returns the specified kind of value in that case.  If 
there is some way in which these points are unclear, then the commit
message should certainly explain the reasoning that was used.

julia

>
>>>> It's just "bad error code, this is the script that fixed it, kthx,
>>>> bye" which is pretty much useless for anaylsis.
>
> Which may be all but impossible but for the handful of
> folks that know all the gory/intimate details of the
> original bit of code.
>
>> What does it potentially cause the caller to do?  Will it potentially
>> treat an error as a success and as a result register an object
>> illegally?
>>
>> Real analysis please.  The text you provided above is basically still
>> robotic and could be used to describe any error code return fix.
>
> Right, it's useful to attempt but may be infeasible in
> practice.
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@...r.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists