RTEMS | cpukit/libio: Support close with IOP references held (!516)

[Chris Johns (@chris)]

Chris Johns commented on a discussion on cpukit/include/rtems/libio_.h: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/516#note_125255

 > +)
 > +{
 > +  /*
 > +   * The IOP cannot be open and there can be no references held for it
 > +   * to be returned to the free list.
 > +   *
 > +   * Note, the open flag indicates the user owns the fd that indexes
 > +   * the iop so consider it an indirect reference. We cannot return
 > +   * the iop to the free list while the user owns the fd.
 > +   *
 > +   * Read the flags once as it is an atomic and we need to test 2
 > +   * flags. No convenience call as this is the only case we have.
 > +   */
 > +  const unsigned int flags = rtems_libio_iop_flags( iop );
 > +  if ( ( ( flags & LIBIO_FLAGS_OPEN ) == 0 )
 > +       && ( ( flags & LIBIO_FLAGS_REFERENCE_MASK ) == 0 ) ) {

The IOP would have to be on the free list to be reallocated. There is also a free flag to indicate the free state so that means not open and zero references indicates the IOP can be freed if not free.  

What if the `rtems_libio_free_iop()` free flags check etc is all done within the libio lock? If adds a small overhead only for the case of two threads racing at this point in the close process.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/516#note_125255
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/20250625/db547a6b/attachment-0001.htm>