[(fixed)] Fix infinite loop in INFTL_foldchain() in drivers/mtd/inftlcore.c

I'm having problems with my email client, but I've attached a patch  
(both inline and as a regular attachment). This patch fixes a loop  
that is potentially infinite in INFTL_foldchain in  
drivers/mtd/inftlcore.c.

When iterating over a chain in reverse (oldest block first), this  
patch correctly marks the PUtable[] entry of the second to last erase  
block of a chain as BLOCK_NIL, regardless of whether or not it can  
format the last block successfully. Before, the second to last block  
was only marked as pointing to BLOCK_NIL if INFTL_formatblock()  
succeeded on the last block of the chain, which could potentially  
result in an infinite loop if the block was worn out and refused to  
format.

If there are any problems with this patch please let me know. I can  
apply them fine after pulling them from email, but my email client  
(web interface) isn't fullproof, so if anybody else has problems,  
please let me know. (I can't send it through pine or otherwise due to  
network configuration.)

Thanks,
Daniel

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
>From 8f1275749768d316788194cc198093b00f85d0d6 Mon Sep 17 00:00:00 2001
From: Daniel Rosenthal <danielrosenthal@acm.org>
Date: Sun, 5 Oct 2008 17:43:10 -0400
Subject: [PATCH] Fix infinite loop in INFTL_foldchain in drivers/mtd/inftlcore.c.


Signed-off-by: Daniel Rosenthal <danielrosenthal@acm.org>
---
 drivers/mtd/inftlcore.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

Hi Daniel,

Daniel Rosenthal wrote:
> I'm having problems with my email client, but I've attached a patch 
> (both inline and as a regular attachment). This patch fixes a loop that 
> is potentially infinite in INFTL_foldchain in drivers/mtd/inftlcore.c.
> 
> When iterating over a chain in reverse (oldest block first), this patch 
> correctly marks the PUtable[] entry of the second to last erase block of 
> a chain as BLOCK_NIL, regardless of whether or not it can format the 
> last block successfully. Before, the second to last block was only 
> marked as pointing to BLOCK_NIL if INFTL_formatblock() succeeded on the 
> last block of the chain, which could potentially result in an infinite 
> loop if the block was worn out and refused to format.
> 
> If there are any problems with this patch please let me know. I can 
> apply them fine after pulling them from email, but my email client (web 
> interface) isn't fullproof, so if anybody else has problems, please let 
> me know. (I can't send it through pine or otherwise due to network 
> configuration.)

I haven't looked at this code for quite a while, but your
reasoning and patch looks right to me. So you have my acked-by.

Acked-by: Greg Ungerer <gerg@snapgear.com>

David, I assume you are going to pick this up?

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Dude       EMAIL:     gerg@snapgear.com
Secure Computing Corporation                PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com

On Wed, 2008-10-08 at 16:25 +1000, Greg Ungerer wrote:
> Hi Daniel,
> 
> Daniel Rosenthal wrote:
> > I'm having problems with my email client, but I've attached a patch 
> > (both inline and as a regular attachment). This patch fixes a loop that 
> > is potentially infinite in INFTL_foldchain in drivers/mtd/inftlcore.c.
> > 
> > When iterating over a chain in reverse (oldest block first), this patch 
> > correctly marks the PUtable[] entry of the second to last erase block of 
> > a chain as BLOCK_NIL, regardless of whether or not it can format the 
> > last block successfully. Before, the second to last block was only 
> > marked as pointing to BLOCK_NIL if INFTL_formatblock() succeeded on the 
> > last block of the chain, which could potentially result in an infinite 
> > loop if the block was worn out and refused to format.
> > 
> > If there are any problems with this patch please let me know. I can 
> > apply them fine after pulling them from email, but my email client (web 
> > interface) isn't fullproof, so if anybody else has problems, please let 
> > me know. (I can't send it through pine or otherwise due to network 
> > configuration.)
> 
> I haven't looked at this code for quite a while, but your
> reasoning and patch looks right to me. So you have my acked-by.
> 
> Acked-by: Greg Ungerer <gerg@snapgear.com>
> 
> David, I assume you are going to pick this up?

Committed. Thanks.