Deadlock caused by locking inversion in JFFS2

[Kinsey Moore]

When the code for delayed writes was added to support JFFS2 on NAND, it introduced a possible locking inversion when managing the delayed write work queue.

This has been partially addressed by fa85760c99a72b8186c70c896b98efe0d7cde2b6, but there are other issues with this code that need to be addressed as well.

First is that when not compiling with RTEMS_DEBUG, nodes are not automatically set as off the chain upon extraction and this behavior is depended upon.

Second is that protected (ISR-locked) chain calls are used when they are not necessary due to already being locked.

Third is that the bug fixed by the referenced commit needs a test that verifies the fix.

[z.ling111]

Hey i'm interested working on this ticket would the nodes be set off only if

#if defined(RTEMS_DEBUG) is true? I can't find other functions that call this so i can't confirm. I think i'm going to try to work on the first part.

[Kinsey Moore]

Hey, thanks for the interest. I actually have a patch on the mailing list that just got approved for fixing this, so it should be going into the codebase shortly. I still need to write a test that produces the original issue, though.

[Kinsey Moore <kinsey.moore@…>]

In [changeset:"99c637fbd973a3d2f6e5adf38aac8f3f588cbb7e/rtems" 99c637f/rtems]:

cpukit/jffs2: Avoid use of off-chain semantics

This reworks the JFFS2 delayed work queue to avoid use of
on-chain/off-chain semantics since they vary in behavior under
RTEMS_DEBUG and are not guaranteed to be safe to use in SMP systems.
This adds all delayed work structs to the chain on FS init and does not
remove them until umount.

Updates #4956