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

Chris Johns (@chris) gitlab at rtems.org
Mon Jun 23 00:34:13 UTC 2025




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

 > + */
 > +static inline void rtems_libio_free(
 > +  rtems_libio_t *iop
 > +)
 > +{
 > +  /*
 > +   * 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.
 > +   */
 > +  const unsigned int flags = rtems_libio_iop_flags( iop );
 > +  if ( ( ( flags & LIBIO_FLAGS_OPEN ) == 0 )
 > +       && ( ( flags & LIBIO_FLAGS_REFERENCE_MASK ) == 0 ) ) {

It is accessing an atomic and those calls could, would or should be separate reads to the atomic variable in each those calls. I cannot see a way around this without adding a new convenience call that is only ever used here. I have added to the comment block:

```
* 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.
```

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


More information about the bugs mailing list