[PATCH] ubi: try_recover_peb: Don't torture the new PEB if there is no write operation

[Zhihao Cheng]

The new peb is put always with torture flag even there is no write
operation. For example, ubi_io_read_vid_hdr failure can lead a torture
operation during the erasing of new PEB, which brings meaningless and
life-wearing torture verification.

Fix by adding a torture state value to identify whether the write
operation happens on new PEB. BTW, let ubi write failure warnning be
printed only when a write operation fails.

Fixes: 801c135ce73d5d ("UBI: Unsorted Block Images")
Signed-off-by: Zhihao Cheng <chengzhihao1 at huawei.com>
---
 drivers/mtd/ubi/eba.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/ubi/eba.c b/drivers/mtd/ubi/eba.c
index f0c549e62c55..509c90304ab8 100644
--- a/drivers/mtd/ubi/eba.c
+++ b/drivers/mtd/ubi/eba.c
@@ -805,7 +805,7 @@ static int try_recover_peb(struct ubi_volume *vol, int pnum, int lnum,
 {
 	struct ubi_device *ubi = vol->ubi;
 	struct ubi_vid_hdr *vid_hdr;
-	int new_pnum, err, vol_id = vol->vol_id, data_size;
+	int new_pnum, err, vol_id = vol->vol_id, data_size, torture = 0;
 	uint32_t crc;
 
 	*retry = false;
@@ -843,6 +843,7 @@ static int try_recover_peb(struct ubi_volume *vol, int pnum, int lnum,
 
 	memcpy(ubi->peb_buf + offset, buf, len);
 
+	torture = 1;
 	data_size = offset + len;
 	crc = crc32(UBI_CRC32_INIT, ubi->peb_buf, data_size);
 	vid_hdr->sqnum = cpu_to_be64(ubi_next_sqnum(ubi));
@@ -872,8 +873,9 @@ static int try_recover_peb(struct ubi_volume *vol, int pnum, int lnum,
 		 * Bad luck? This physical eraseblock is bad too? Crud. Let's
 		 * try to get another one.
 		 */
-		ubi_wl_put_peb(ubi, vol_id, lnum, new_pnum, 1);
-		ubi_warn(ubi, "failed to write to PEB %d", new_pnum);
+		ubi_wl_put_peb(ubi, vol_id, lnum, new_pnum, torture);
+		if (torture)
+			ubi_warn(ubi, "failed to write to PEB %d", new_pnum);
 	}
 
 	return err;
-- 
2.52.0