summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorAlan Cudmore <alan.cudmore@gmail.com>2013-12-18 12:00:42 -0500
committerChris Johns <chrisj@rtems.org>2013-12-19 11:07:47 +1100
commita9619f3cb6b181f781aaf1f77931b32d0137145f (patch)
treea372ca2a520dd44d087ecfc70d7bf97a68e8d38c
parent9b48dc67ed57f31c00b2e4351a30fac947472899 (diff)
downloadrtems-a9619f3cb6b181f781aaf1f77931b32d0137145f.tar.bz2
For PR 2164 - RFS File System - fix bitmap_create_search loop bug
This is for the RFS file system. There is a bug in the rtems_rfs_bitmap_create_search loop. It is supposed to iterate over the range of bits in a search element ( usually 32 bits ), so it should loop through bits 0 through 31. Instead it loops through 0 - 32, causing some blocks not to be allocated. As in PR 2163, this depends on the block size and number of blocks in a file system. Block sizes and group sizes that are powers of 2 seem to work fine ( 512 byte blocks, 4096 block groups, etc ). When the block sizes are not powers of 2, then this loop error causes some of the blocks at the end of a group to be skipped, preventing 100% of the blocks from being used. A simple test for this and PR2163 is to create a RAM disk with block size 3900 and at least 1 full group ( 31200 blocks ). A file system with these sizes will not be able to allocate 100% of the blocks.
-rw-r--r--cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c3
1 files changed, 2 insertions, 1 deletions
diff --git a/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c b/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c
index c4050b2da8..b8bd0b3386 100644
--- a/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c
+++ b/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c
@@ -599,7 +599,8 @@ rtems_rfs_bitmap_create_search (rtems_rfs_bitmap_control* control)
size -= available;
- if (bit == rtems_rfs_bitmap_element_bits ())
+ /* Iterate from 0 to 1 less than the number of bits in an element */
+ if (bit == (rtems_rfs_bitmap_element_bits () - 1))
{
bit = 0;
search_map++;