RTEMS | libio: Fix reference counting of file descriptors (!725)

[Sebastian Huber (@sebhub)]

Sebastian Huber created a merge request: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/725

Project:Branches: sebhub/rtems:rtems-6-fix-libio-iop-ref-count to rtems/rtos/rtems:6
Author:   Sebastian Huber
Assignee: Sebastian Huber
Reviewer: Kinsey Moore


## Summary

libio: Fix reference counting of file descriptors

Commit 0cf6de01df734c11212e63134551ee344a10ecec introduced a couple of
issues:

* ABI changes on a release branch

* Redundant LIBIO_FLAGS_FREE flag: an iop is free if and only if it is
  on the free list.

* When the iop is freed, its reference count was set to zero.  The iop
  reference count must never be set to a specific value after
  initialization at system start.  The only valid operations are
  increments and decrements.

* In the iop free handling, there was a deadlock potential by obtaining
  the libio lock while owning a file system lock.

* The reference counting did not work at all under concurrent access.
  This was indicated by the failing spintrcritical24 test program.

To fix this, remove the LIBIO_FLAGS_FREE and change the flag values back
to the original values (restore ABI).

Actions must be performed based on state changes (flags, reference
count) and not based on reading the current flags.

Remove dangerous functions rtems_libio_check_is_open(),
rtems_libio_iop_flags_bad_fd(), rtems_libio_iop_is_held(),
rtems_libio_iop_is_free().  The open property and references must be
determined by inspecting the flags returned by rtems_libio_iop_hold() or
similar.

In order to support closing a file descriptor with active references
(LIBIO_FLAGS_CLOSE_BUSY), produce exactly one reference count while
opening a file through the new function rtems_libio_iop_open().  An
associated file node is freed when the reference count changes from one
to zero.

This is an API change.  Users of rtems_libio_allocate() must now call
rtems_libio_iop_open() to make the iop available for use.

Update #5201.
Update #5311.


<!-- Default settings, if it is a dropdown it will set after submission -->

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/725
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20250915/0993a017/attachment.htm>