[patch] logfs: testing the wrong variable

[patch] logfs: testing the wrong variable

[Dan Carpenter]

There is a typo here.  We should test "last" instead of "first".

Signed-off-by: Dan Carpenter <error27@gmail.com>

diff --git a/fs/logfs/super.c b/fs/logfs/super.c
index b60bfac..1e0449e 100644
--- a/fs/logfs/super.c
+++ b/fs/logfs/super.c
@@ -377,7 +377,7 @@ static struct page *find_super_block(struct super_block *sb)
 	if (!first || IS_ERR(first))
 		return NULL;
 	last = super->s_devops->find_last_sb(sb, &super->s_sb_ofs[1]);
-	if (!last || IS_ERR(first)) {
+	if (!last || IS_ERR(last)) {
 		page_cache_release(first);
 		return NULL;
 	}

Re: [patch] logfs: testing the wrong variable

[Jörn Engel]

On Wed, 21 April 2010 12:33:54 +0200, Dan Carpenter wrote:
> 
> There is a typo here.  We should test "last" instead of "first".
> 
> Signed-off-by: Dan Carpenter <error27@gmail.com>
> 
> diff --git a/fs/logfs/super.c b/fs/logfs/super.c
> index b60bfac..1e0449e 100644
> --- a/fs/logfs/super.c
> +++ b/fs/logfs/super.c
> @@ -377,7 +377,7 @@ static struct page *find_super_block(struct super_block *sb)
>  	if (!first || IS_ERR(first))
>  		return NULL;
>  	last = super->s_devops->find_last_sb(sb, &super->s_sb_ofs[1]);
> -	if (!last || IS_ERR(first)) {
> +	if (!last || IS_ERR(last)) {
>  		page_cache_release(first);
>  		return NULL;
>  	}

Applied, thanks!

Did you use a tool to find this?  And if yes, where would I find it? ;)

Jörn

-- 
In America you can have either a flimsy box banged together out of two
by fours and drywall, or a McMansion -- a flimsy box banged together
out of two by fours and drywall, but larger, more dramatic-looking,
and full of expensive fittings.
-- Paul Graham
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch] logfs: testing the wrong variable

[Dan Carpenter]

On Wed, Apr 21, 2010 at 03:15:22PM +0200, Jörn Engel wrote:

> Did you use a tool to find this?  And if yes, where would I find it? ;)
> 

This is smatch stuff (http://smatch.sf.net).

The problem is that it's a private modification where I made it print 
errors if we pass an ERR_PTR to a function.  After I send out 10 patches 
today that modification will only print false positives... Normally the 
false positives are cases where the function accepts ERR_PTRs as a 
paramater.  I need to kill most of the false positives before I can push 
the change.

The good thing about Smatch is that it's easy to compile, but the bad
thing is that it's false positive heavy.

regards,
dan carpenter

--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch] logfs: testing the wrong variable

[Jörn Engel]

On Thu, 22 April 2010 11:22:42 +0200, Dan Carpenter wrote:
> On Wed, Apr 21, 2010 at 03:15:22PM +0200, Jörn Engel wrote:
> 
> > Did you use a tool to find this?  And if yes, where would I find it? ;)
> > 
> 
> This is smatch stuff (http://smatch.sf.net).
> 
> The problem is that it's a private modification where I made it print 
> errors if we pass an ERR_PTR to a function.  After I send out 10 patches 
> today that modification will only print false positives... Normally the 
> false positives are cases where the function accepts ERR_PTRs as a 
> paramater.  I need to kill most of the false positives before I can push 
> the change.
> 
> The good thing about Smatch is that it's easy to compile, but the bad
> thing is that it's false positive heavy.

:)

I'll need to take a closer look sometime.  Years back I wrote a
callgraph generator based on smatch.  Goal was to calculate the max
stack consumption across the complete kernel, but it can be used for
other purposes as well.  I remember having to patch gcc 3.1 as part of
the exercise, so obviously the code has bitrotted since and needs some
care.

Jörn

-- 
Never argue with idiots - first they drag you down to their level,
then they beat you with experience.
-- unknown