three quesions about filesytem

Joel Sherrill joel.sherrill at oarcorp.com
Fri Apr 20 13:41:59 UTC 2007


shizheng wrote:
> Hi:
>
>   1.
>       rtems_libio_is_valid_perms always returns non-zero value,
>       so I can't catch why it's called in IMFS_evaluate_permission and IMFS_eval_path.
>
>       #define RTEMS_LIBIO_PERMS_RWX    S_IRWXO
>       /*
>        * Verifies that the permission flag is valid.
>        */
>       #define rtems_libio_is_valid_perms( _perm )     \
>        (~ ((~RTEMS_LIBIO_PERMS_RWX) & _perm ))
>
>             
>
This is only used to check for an assert condition. Did somehow a bit
get set in
the permissions that isn't even defined.
>
>   1.
>           
>    2. Why isn't there a semaphore and reference count to protect IMFS
>       nodes like dosfs?
>
The IMFS was developed primarily to support the development of the
filesystem infrastructure.
It was developed as a useful test aid for the software layer above it.
It was just an oversight.

Looked at another way.. this is open source. The IMFS was initially
released with just
a subset of the functionality it has now. People have added to it as
they require.

If you have a patch for this, it would be appreciated.
>
>    1. Let's suppose / and /mem are IMFS_DIRECTORY nodes, and
>       /mem/file is an IMFS_MEMORY_FILE node. Then I can delete
>       /mem/file while it's still in open progress. To prove this, you
>       can create two task:
>
>       rtems_task imfs_reader(rtems_task_argument argument)
>       {
>       int open_status, stat_status;
>       struct stat stat_buf;
>       rtems_id tid;
>
>       rtems_task_ident( RTEMS_SELF, RTEMS_SEARCH_ALL_NODES, &tid );
>       printf( "imfs_reader task was invoked with argument (%d) "
>       "and has id of 0x%x\n", argument, tid );
>
>       while(1){
>       open_status = open("/dev/test", 0);
>       sleep(2+argument);
>       stat_status = stat("/dev/test", &stat_buf);
>       if(open_status>=0 && stat_status==-1){
>       printf("file deleted while still opened\n", argument);
>       Print_time();
>       exit(0);
>       }
>       close(open_status);
>       }
>       }
>
>       rtems_task imfs_writer(rtems_task_argument argument)
>       {
>       rtems_id tid;
>
>       rtems_task_ident( RTEMS_SELF, RTEMS_SEARCH_ALL_NODES, &tid );
>       printf( "imfs_writer task was invoked with argument (%d) "
>       "and has id of 0x%x\n", argument, tid );
>
>       while(1){
>       mknod("/dev/test", 0777|S_IFCHR, 0);
>       sleep(2+argument);
>       unlink("/dev/test");
>       sleep(2+argument);
>       }
>       }
>
>       After about 4 seconds, you can see "file deleted while still
>       opened" on the screen.
>
Feel free to submit a test case and patch for this one.
>
>   1.
>
>
>    2. imfs_dir_close doesn't check the st_nlink member of an IMFS
>       directory node.
>       So such a scenario will cause memory leak:
>          1. suppose /emptydir is an empty IMFS directory
>          2. dirp = opendir("/emptydir");
>             rmdir("/emptydir");
>             closedir(dirp);
>          3. After rmdir calls imfs_dir_rmnod, the IMFS node of
>             /emptydir has been
>             Chain_Extract from the IMFS name tree, but can't be freed
>             as a result of
>             opendir. Because imfs_dir_close doesn't do any check, this
>             IMFS node
>             will never be freed.
>
>
> Question No 2 and 3 are very obvious, I'm very confused why you guys
> remain the code
> like that, so I guess you may think it's the application-user's
> responsiblity to do
> the synchronization, but why dosfs does the effort while IMFS doesn't.
>
Feel free to submit a test case and patch for this one.
> Thank you very much for bringing us such a good open-source real-time
> os to the world:)))
>
:)

--joel
>
> best wishes from shizheng, University of Science and Technology of China
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>   




More information about the users mailing list