RTEMS 5.1 pc686 BSP malloc_info problem?

Chris Johns chrisj at rtems.org
Thu Oct 15 20:19:56 UTC 2020

On 16/10/20 6:16 am, Alan Cudmore wrote:
> On Thu, Oct 15, 2020 at 3:03 PM Chris Johns <chrisj at rtems.org> wrote:
>> The number of bits needs to align to a value that fits the whole 32 bit mask so
>> the last is used to trigger the bug.
> How can I calculate this? 

The number of bits in a bitmap is the number of blocks in the file system. The
search bit map is a bit for every 32 bits of the block bit map. Therefore 32
bits of the search bit map covers 32 x 32 or 1024 blocks. The RFS can search
1024 blocks of the file system for a free block with a single 32 bit test.

A file system with 4096 blocks will have 4 search bit map elements (as defined
in the RFS).

The buffer overflow will happen if the "(blocks % 1024) == 0"

> It would be great if I could tell known
> users that they don't need to worry about it.

Yes this is a good approach.

> For example, in the open source cFS bundle where I encountered the
> issue, it creates an RFS formatted RAM disk that is 0x200000 bytes in
> size (2 Mbytes). I would imagine that is a nice round number of bitmap
> elements.

It depends on the block size as well as that determines the number of blocks.


More information about the devel mailing list