Error in imfs memfile when device is full

[Joel Sherrill]

From the reporter (Круглов Сергей <skruglov@…>):

• First bug I detect with attempt write file to full device (zero empty blocks).
• And after I send too many files, disk overflow and system not responding (receive and write to disk have high priority). A test, and found block=0, after -- = too big value.
• In imfs_memfile.c

function IMFS_memfile_extend
block declared: unsigned int block, and after block— work incorrect (if block = 0).
for ( ; block>=old_blocks ; block-- ) {

IMFS_memfile_remove_block( memfile, block );

}

Must be declare int block;

[Joel Sherrill]

Proposed patch

[Gedare Bloom]

The basic problem here is that block == 0 == old_blocks. Is it valid to call IMFS_memfile_remove_block( memfile, 0 )? If so then changing unsigned to signed is a fine solution.

[Christian Mauderer <christian.mauderer@…>]

In 051778e/rtems:

imfs: Fix index underrun when extending empty file

Currently the following sequence causes a endless loop when extending an
IMFS file:

• Create a file with zero length and close it.
• Make sure nearly no allocatable memory is left.
• Open the file and write enough data into it that more than the remaining memory will be used.

In that case when extending the IMFS file, the file currently need zero
blocks. If allocating enough new blocks fails, the already allocated new
blocks will be freed again.

The comparison of block>=old_blocks that has been used prior to this
patch compared two unsigned numbers. If old_blocks was zero, the
comparison of these two numbers always evaluated to true.

This patch frees the last block in a separate step to avoid this
problem.

Note: This patch is a backport of
43119193ef0f3fef6bc01a391ccda8a97cfc149c from RTEMS master. It only
contains the bugfix. Adding a test case has been skipped because that
part of the patch didn't apply without problems and is not really
relevant for fixing the bug.

Fixes #2353