From eb7c48fbd0eaef6668f48fea8772fae7f4643494 Mon Sep 17 00:00:00 2001 From: Christopher Haster Date: Tue, 23 Jan 2024 23:04:45 -0600 Subject: [PATCH] Fixed on-disk grm representation being off-by-one The recent change to internally track mids as mid=mid+1 leaked onto disk through the grm. This is currently the only place we actually write mids to disk. The mid=mid+1 encoding is a bit of a hack and probably should not be the actual on-disk representation, since there are other ways to encode this internally. I did try to write some tests for this, but because the bug is on both the encoding and decoding side it's difficult without reading the mdir directly. I only noticed with the dbg scripts started throwing random errors. Fortunately a regression here is unlikely. --- lfs.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/lfs.c b/lfs.c index ea19d5a5..76390fd6 100644 --- a/lfs.c +++ b/lfs.c @@ -1871,7 +1871,10 @@ static lfsr_data_t lfsr_data_fromgrm(const lfsr_grm_t *grm, d += 1; for (uint8_t i = 0; i < mode; i++) { - lfs_ssize_t d_ = lfs_toleb128(grm->rms[i], &buffer[d], 5); + // adjust to on-disk representation + lfsr_smid_t mid = grm->rms[i] - 1; + + lfs_ssize_t d_ = lfs_toleb128(mid, &buffer[d], 5); LFS_ASSERT(d_ >= 0); d += d_; } @@ -1910,6 +1913,8 @@ static int lfsr_data_readgrm(lfs_t *lfs, lfsr_data_t *data, LFS_ASSERT(grm->rms[i] < lfs_smax32( lfsr_mtree_weight(lfs), lfsr_mweight(lfs))); + // adjust to in-device representation + grm->rms[i] += 1; } return 0;