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