Bug of libcsupport open?

Wei Shen cquark at gmail.com
Fri Aug 22 17:33:47 UTC 2008

On 8/22/08, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:
>  If "iop->handlers->open_h" returns an error, "open" will call
>> "rtems_set_errno_and_return_minus_one( rc )" which sets "errno" to "rc",
>> where "rc" is the return value of "open_h".
>> However, the "open_h" handler implemented by each filesystem usually
>> already sets "errno" and returns only -1 at errors, so "open" will override
>> "errno" with -1 which is not a valid errno.
>> I think you are correct.  And my scan of the open implementations
> in cpukit/libfs indicates a possible mix in returns.
> I think open() should assume -1 returned and errno set.  This
> makes it up to the specific handlers to do the right thing.
> Do you have a patch?

That is the solution comes to my mind. If you need a patch I can make it
next week.

> 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.
> What do you think of that?  Again I think it will take a test
> case to verify and fix.

I found this problem because I want to delete anonymous pipe file at close
(BTW, I give it up because can not find a clean interface to let the pipe
module know whether a pipe is anonymous). I copied some IMFS code but never
I think I can provide some test code next week.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20080823/f690a97b/attachment-0001.html>

More information about the users mailing list