Bug of IMFS_unlink ?

[Wei Shen]

Hi,

I try to verify my supposition using code segments below.

(1)
mknod()
open()
close()
unlink()

(2)
mknod()
open()
unlink()
close()

IMFS_memfile_remove will be called to free related data structures when
deleting an IMFS memory file. I debugged the above code segments. In (1)
IMFS_memfile_remove is called; in (2) it is never called...

Maybe, we can clear the LIBIO_FLAGS_OPEN flag bit of "iop" in memfile_close
before memfile_check_rmnod.
And for device_close and imfs_dir_close, add similar checks.


> Looks to me that the generic close should be detecting this
> condition and (maybe) calling the specific filetype for unlink.


Since link count is recorded in jnode, we may only be able to check in each
filesystem.

Regards,
Wei

On 8/22/08, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:
>
> Wei Shen wrote:
>
>> I suspect there is a bug with unlink of IMFS files, but I am not certain.
>>
>> If a file is still being opened, IMFS_unlink will not really free the
>> file node, but just decrements its link count and removes it from the
>> parent's chain, and the remaining work is leaved to close.
>> memfile_close calls memfile_check_rmnod to delete the file node with a
>> zero link count when the last user closes the file.
>>
>> However, in memfile_check_rmnod "rtems_libio_is_file_open" is checked,
>> which it will always be TRUE because the LIBIO_FLAGS_OPEN flag bit has not
>> been cleared yet. Hence, the file node will never be deleted, while it can
>> no more be accessed in the file system.
>>
>>
> Can you provide a simple test case and let me analyze it?
>
>> I also wonder why device_close and imfs_dir_close do not do similar rmnod
>> checks as memfile_close.
>>
>>
> Looks to me that the generic close should be detecting this
> condition and (maybe) calling the specific filetype for unlink.
>
> What do you think of that?  Again I think it will take a test
> case to verify and fix.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20080825/a76dec9a/attachment.html>