Re: Seeing ubifs unmap LEB error with linux 2.6.35 kernel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Kiran,

----- Ursprüngliche Mail -----
> Von: "Kiran B S" <bs.kiran81@xxxxxxxxx>
> An: "Richard Weinberger" <richard.weinberger@xxxxxxxxx>, "linux-mtd" <linux-mtd@xxxxxxxxxxxxxxxxxxx>
> Gesendet: Freitag, 18. Oktober 2019 11:46:44
> Betreff: Re: Seeing ubifs unmap LEB error with linux 2.6.35 kernel

> Hi Richard,
> Also a reboot of the system recovered the ubifs filesystem.

Okay. This indicates that the problem is not fatal.
Initially we set the GC-Head to -1, unmapping the GC-Head is
a common operation in UBIFS, maybe there is some logic bug in the
replay code.

Can you please give the following change a try?
diff --git a/drivers/mtd/ubi/kapi.c b/drivers/mtd/ubi/kapi.c
index 69fa4ef03c53..03ce752d4d1e 100644
--- a/drivers/mtd/ubi/kapi.c
+++ b/drivers/mtd/ubi/kapi.c
@@ -610,8 +610,10 @@ int ubi_leb_unmap(struct ubi_volume_desc *desc, int lnum)
        if (desc->mode == UBI_READONLY || vol->vol_type == UBI_STATIC_VOLUME)
                return -EROFS;
 
-       if (lnum < 0 || lnum >= vol->reserved_pebs)
+       if (lnum < 0 || lnum >= vol->reserved_pebs) {
+               dump_stack();
                return -EINVAL;
+       }
 
        if (vol->upd_marker)
                return -EBADF;

Using dump_stack() we can see who tries to unmap a bad LEB entry.

After 2.6.35 UBIFS was changed a lot maybe the issue got fixed and
is not present in a recent kernel.

Thanks,
//richard

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/




[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux