buggy IFB driver change

buggy IFB driver change

[David Miller]

Jeff, please revert: 0c0b3ae68ec93b1db5c637d294647d1cca0df763

It's wrong.  We had a lengthy analysis of this piece of code
several months ago, and it is correct.

Consider, if we run the loop and we get an error
the following happens:

1) attempt of ifb_init_one(i) fails, therefore we should
   not try to "ifb_free_one()" on "i" since it failed
2) the loop iteration first increments "i", then it
   check for error

Therefore we must decrement "i" twice before the first
free during the cleanup.  One to "undo" the for() loop
increment, and one to "skip" the ifb_init_one() case which
failed.

commit 0c0b3ae68ec93b1db5c637d294647d1cca0df763
Author: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
Date:   Sat Jan 27 00:00:01 2007 -0800

    net: ifb error path loop fix
    
    On error we should start freeing resources at [i-1] not [i-2].
    
    Signed-off-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
    Cc: Jeff Garzik <jeff@garzik.org>
    Signed-off-by: Andrew Morton <akpm@osdl.org>
    Signed-off-by: Jeff Garzik <jeff@garzik.org>

diff --git a/drivers/net/ifb.c b/drivers/net/ifb.c
index ca2b21f..c4ca7c9 100644
--- a/drivers/net/ifb.c
+++ b/drivers/net/ifb.c
@@ -271,8 +271,7 @@ static int __init ifb_init_module(void)
 	for (i = 0; i < numifbs && !err; i++)
 		err = ifb_init_one(i);
 	if (err) {
-		i--;
-		while (--i >= 0)
+		while (i--)
 			ifb_free_one(i);
 	}
 

Re: buggy IFB driver change

[Jeff Garzik]

David Miller wrote:
> Jeff, please revert: 0c0b3ae68ec93b1db5c637d294647d1cca0df763
> 
> It's wrong.  We had a lengthy analysis of this piece of code
> several months ago, and it is correct.
> 
> Consider, if we run the loop and we get an error
> the following happens:
> 
> 1) attempt of ifb_init_one(i) fails, therefore we should
>    not try to "ifb_free_one()" on "i" since it failed
> 2) the loop iteration first increments "i", then it
>    check for error
> 
> Therefore we must decrement "i" twice before the first
> free during the cleanup.  One to "undo" the for() loop
> increment, and one to "skip" the ifb_init_one() case which
> failed.
> 
> commit 0c0b3ae68ec93b1db5c637d294647d1cca0df763
> Author: Mariusz Kozlowski <m.kozlowski@tuxland.pl>

Andrew and I both missed that thread, sorry.

I'm about to crash, can you or Linus handle the correction?

	Jeff

Re: buggy IFB driver change

[David Miller]

From: Jeff Garzik <jgarzik@pobox.com>
Date: Tue, 30 Jan 2007 16:52:27 -0500

> David Miller wrote:
> > Jeff, please revert: 0c0b3ae68ec93b1db5c637d294647d1cca0df763
> > 
> > It's wrong.  We had a lengthy analysis of this piece of code
> > several months ago, and it is correct.
> > 
> > Consider, if we run the loop and we get an error
> > the following happens:
> > 
> > 1) attempt of ifb_init_one(i) fails, therefore we should
> >    not try to "ifb_free_one()" on "i" since it failed
> > 2) the loop iteration first increments "i", then it
> >    check for error
> > 
> > Therefore we must decrement "i" twice before the first
> > free during the cleanup.  One to "undo" the for() loop
> > increment, and one to "skip" the ifb_init_one() case which
> > failed.
> > 
> > commit 0c0b3ae68ec93b1db5c637d294647d1cca0df763
> > Author: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
> 
> Andrew and I both missed that thread, sorry.
> 
> I'm about to crash, can you or Linus handle the correction?

Sure.

Re: buggy IFB driver change

[Joe Perches]

On Tue, 2007-01-30 at 14:12 -0800, David Miller wrote:
> > > Therefore we must decrement "i" twice before the first
> > > free during the cleanup.  One to "undo" the for() loop
> > > increment, and one to "skip" the ifb_init_one() case which
> > > failed.

Perhaps putting the error unwind inside the for loop
is simpler and more intelligible.

diff --git a/drivers/net/ifb.c b/drivers/net/ifb.c
index ca2b21f..0b24c31 100644
--- a/drivers/net/ifb.c
+++ b/drivers/net/ifb.c
@@ -264,19 +264,20 @@ static void ifb_free_one(int index)
 
 static int __init ifb_init_module(void)
 {
-	int i, err = 0;
+	int i, err;
 	ifbs = kmalloc(numifbs * sizeof(void *), GFP_KERNEL);
 	if (!ifbs)
 		return -ENOMEM;
-	for (i = 0; i < numifbs && !err; i++)
+	for (i = 0; i < numifbs; i++) {
 		err = ifb_init_one(i);
-	if (err) {
-		i--;
-		while (--i >= 0)
-			ifb_free_one(i);
+		if (err) {
+			while (i > 0)
+				ifb_free_one(--i);
+			return err;
+		}
 	}
 
-	return err;
+	return 0;
 }
 
 static void __exit ifb_cleanup_module(void)

Re: buggy IFB driver change

[Linus Torvalds]

On Tue, 30 Jan 2007, Jeff Garzik wrote:
> 
> I'm about to crash, can you or Linus handle the correction?

Reverted, pushed out.

Davem, if you have any other issues, just push me any fixes. I'm going to 
do a final -rc7 today (way too many changes for me to be happy releasing a 
2.6.20 without a new -rc after all), and hope for the final 2.6.20 by the 
end of this week.

Sounds like a plan?

		Linus

Re: buggy IFB driver change

[David Miller]

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue, 30 Jan 2007 14:13:14 -0800 (PST)

> On Tue, 30 Jan 2007, Jeff Garzik wrote:
> > 
> > I'm about to crash, can you or Linus handle the correction?
> 
> Reverted, pushed out.
> 
> Davem, if you have any other issues, just push me any fixes. I'm going to 
> do a final -rc7 today (way too many changes for me to be happy releasing a 
> 2.6.20 without a new -rc after all), and hope for the final 2.6.20 by the 
> end of this week.
> 
> Sounds like a plan?

That works for me, I have 3 small netfilter fixes to review
(one is a nasty divide by zero case) and one potential TCP fix.
I'll take care of those right now and push.