This change fixes https://devel.rtems.org/ticket/3089.
Briefly, rtems_rfs_group.c contains conflicting conversions between
block numbers and group number and bit offset pairs. This caused the
actual bit stored on the bitmask to be one bit displaced from its
intended location.
For more details, please see the associated ticket.
Tested by inspecting the written bitmasks with and without this change.
---
cpukit/libfs/src/rfs/rtems-rfs-group.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/cpukit/libfs/src/rfs/rtems-rfs-group.c
b/cpukit/libfs/src/rfs/rtems-rfs-group.c
index c319dc526c..e1480330a7 100644
--- a/cpukit/libfs/src/rfs/rtems-rfs-group.c
+++ b/cpukit/libfs/src/rfs/rtems-rfs-group.c
@@ -167,7 +167,17 @@ rtems_rfs_group_bitmap_alloc (rtems_rfs_file_system* fs,
goal -= RTEMS_RFS_ROOT_INO;
}
else
+ {
size = fs->group_blocks;
+ /*
+ * It is possible for 'goal' to be zero. Any newly created inode will have
+ * its 'last_data_block' set to zero, which is then used as 'goal' to
+ * allocate new blocks. When that happens, we simply set 'goal' to zero and
+ * continue the search from there.
+ */
+ if (goal >= RTEMS_RFS_SUPERBLOCK_SIZE)
+ goal -= RTEMS_RFS_SUPERBLOCK_SIZE;
+ }
group_start = goal / size;
bit = (rtems_rfs_bitmap_bit) (goal % size);
@@ -324,8 +334,9 @@ rtems_rfs_group_bitmap_test (rtems_rfs_file_system* fs,
}
else
{
- if (no >= rtems_rfs_fs_blocks (fs))
+ if ((no < RTEMS_RFS_SUPERBLOCK_SIZE) || (no >= rtems_rfs_fs_blocks (fs))
return EINVAL;
+ no -= RTEMS_RFS_SUPERBLOCK_SIZE;
size = fs->group_blocks;
}
--
2.14.2.920.gcf0c67979c-goog
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
