Bug of libcsupport open?

[Wei Shen]

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
succeed.
I think I can provide some test code next week.

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