On 11/10/2017 10:11, Fan Deng wrote:
> 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.
Hmmm well ....
> ---
> 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))
... there is a ')' missing?
RTEMS_RFS_SUPERBLOCK_SIZE should be RTEMS_RFS_ROOT_INO.
> return EINVAL;
> + no -= RTEMS_RFS_SUPERBLOCK_SIZE;
Same here.
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
