[RTEMS Project] #4674: readdir skips entries after unlink

[RTEMS trac]

#4674: readdir skips entries after unlink
-----------------------------+----------------------------
 Reporter:  Alexandre Oliva  |       Owner:  Needs Funding
     Type:  defect           |      Status:  assigned
 Priority:  normal           |   Milestone:  6.1
Component:  fs               |     Version:  6
 Severity:  normal           |  Resolution:
 Keywords:                   |  Blocked By:
 Blocking:                   |
-----------------------------+----------------------------

Comment (by Joel Sherrill):

 The thread of this discussion starts here: https://gcc.gnu.org/pipermail
 /gcc-patches/2022-June/597009.html

 I would like to create a test case for this and would appreciate the
 feedback. If I understand the description correctly, the scenario of
 operations that triggers this is:

 * Setup: Create a few files in a directory so there are directory entries
 for readdir() to operate on

 * opendir() the directory

 * unlink() the second entry

 * readdir() and check that all entries added during setup except the one
 unlinked are present.

 Does this need to be checked in the root directory and a subdirectory?

 As to a fix, the issue appears to be because the IMFS (root filesystem
 type) is not a traditional block-oriented filesystem. It is a tree data
 structure. Directories are doubly-linked lists. IMFS_rmnod() includes a
 call to IMFS_remove_from_directory() which is implemented as follows in
 cpukit/include/rtems/imfs.h:

 {{{
 static inline void IMFS_remove_from_directory( IMFS_jnode_t *node )
 {
   IMFS_assert( node->Parent != NULL );
   node->Parent = NULL;
   rtems_chain_extract_unprotected( &node->Node );
 }

 }}}

 One of the suggestions was to mark the directory entry as dead. That seems
 to be a possible approach here but there is the question of when the
 malloc'ed "directory slot" would be freed. My first thought that
 closedir() could scan and free it but closedir() is in newlib and does not
 appear to have a hook for the OS to do anything.

 Leaving the dead node in place is likely acceptable if it can be reused
 which would mean IMFS_mknod() would have to avoid blinding
 allocating/creating a new node and would have to look for a dead node
 entry to reuse.

 The other consequence of marking a node as dead is that any directory
 searches as part of open() or other operations would have to skip dead
 nodes. I think this only impacts IMFS_search_in_directory().

 Feedback on the test scenario and possible approach to fixing this is
 definitely appreciated.

--
Ticket URL: <http://devel.rtems.org/ticket/4674#comment:4>
RTEMS Project <http://www.rtems.org/>
RTEMS Project