Skip to contentSkip to conversation

UBI patches for 2.6.36

PATCH New Artem Bityutskiy 1 participant 3 messages Aug 29, 2010

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

Hi,

I'm going to send the following patches to Linus soonish, any objections?

Signature · 2 lines
Best Regards,
Artem Bityutskiy (Битюцкий Артём)
#1 lore raw

PATCH 1/2 UBI: eliminate update of list_for_each_entry loop cursor

From: Julia Lawall <[email protected]>

list_for_each_entry uses its first argument to move from one element to the next, so modifying it can break the iteration. The variable re1 is already used within the loop as a temporary variable, and is not live here.

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@r@
iterator name list_for_each_entry;
expression x,E;
position p1,p2;
@@

list_for_each_entry@p1(x,...) { <... x =@p2 E ...> }

@@
expression x,E;
position r.p1,r.p2;
statement S;
@@

*x =@p2 E
...
list_for_each_entry@p1(x,...) S
// </smpl>

---
 drivers/mtd/ubi/cdev.c |   12 ++++++------
 1 files changed, 6 insertions(+), 6 deletions(-)
drivers/mtd/ubi/cdev.c +6 -6
index 4dfa6b9..3d2d1a6 100644
@@ -798,18 +798,18 @@ static int rename_volumes(struct ubi_device *ubi,
 			goto out_free;
 		}
 
-		re = kzalloc(sizeof(struct ubi_rename_entry), GFP_KERNEL);
-		if (!re) {
+		re1 = kzalloc(sizeof(struct ubi_rename_entry), GFP_KERNEL);
+		if (!re1) {
 			err = -ENOMEM;
 			ubi_close_volume(desc);
 			goto out_free;
 		}
 
-		re->remove = 1;
-		re->desc = desc;
-		list_add(&re->list, &rename_list);
+		re1->remove = 1;
+		re1->desc = desc;
+		list_add(&re1->list, &rename_list);
 		dbg_msg("will remove volume %d, name \"%s\"",
-			re->desc->vol->vol_id, re->desc->vol->name);
+			re1->desc->vol->vol_id, re1->desc->vol->name);
 	}
 
 	mutex_lock(&ubi->device_mutex);
Signature · 1 line
1.7.2.2
#2 lore raw

PATCH 2/2 UBI: fix forward compatibility

In reply to Artem Bityutskiy

From: Artem Bityutskiy <[email protected]>

Commit 0798cea8c2e1afee59686c51d27d0e96b05e42d1 "UBI: improve corrupted flash handling" broke delet-compatible volumes handling - it introduced a limit of 8 eraseblocks which may be corrupted. And delete-compatible eraseblocks are added to the "corrupted" list, so if we'd have a large delete-compatible volume, UBI would refuse it.

The fix is to add delete-compatible volumes to the erase list instead. Indeed, they are corrupted, we just have to erase them.

---
 drivers/mtd/ubi/scan.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
drivers/mtd/ubi/scan.c +1 -1
index 372a15a..69b52e9 100644
@@ -843,7 +843,7 @@ static int process_eb(struct ubi_device *ubi, struct ubi_scan_info *si,
 		case UBI_COMPAT_DELETE:
 			ubi_msg("\"delete\" compatible internal volume %d:%d"
 				" found, will remove it", vol_id, lnum);
-			err = add_to_list(si, pnum, ec, &si->corr);
+			err = add_to_list(si, pnum, ec, &si->erase);
 			if (err)
 				return err;
 			return 0;
Signature · 1 line
1.7.2.2