RTEMS | cpukit/jffs2/gc.c: Prevent live lock for split reads (!757)

[Kinsey Moore (@opticron)]

Kinsey Moore created a merge request: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/757

Project:Branches: opticron/rtems:brmain-jffs2-livelock to rtems/rtos/rtems:main
Author:   Kinsey Moore
Assignee: Kinsey Moore



## Summary

cpukit/jffs2/gc.c: Prevent live lock for split reads

In some cases a file read is not completed in a single call into the
JFFS2 layer and the inode is left in the READING state. When this
happens, it's possible for a garbage collection pass to be initiated
before completion of the read. In some such cases, the garbage
collection pass is executed in a tight loop that expects granular
locking to allow forward progress of the read between collection passes.
With RTEMS monolithic locking of the JFFS2 layer, forward progress is
not possible in this situation since the monolithic lock is never
released inside the loop.

The solution is to have the garbage collection pass return failure when
no progress is possible due to a bad inode state. This allows the read
to complete and the collection pass can be attempted at a later time.


<!-- 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/757
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/20250929/932156af/attachment.htm>