[PATCH 1/3] cpukit/jffs2: Avoid delayed work lock inversion

[Kinsey Moore]

On Mon, Sep 11, 2023 at 11:00 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> Hello Kinsey,
>
> since this patch fixes a bug, there should be a ticket. There should be
> also a test case which demonstrates the problem and shows that the patch
> fixes the issue.
>
> I'll open an issue and see what I can do about creating a test case for
JFFS2 that reproduces this issue.

>
>
> How do you ensure that nobody calls jffs2_queue_delayed_work() with a
> node present on this temporary chain?
>

This is handled by the off_chain checks along with the locking. If the node
is already in a chain, then delayed work is already pending and will be
handled upon expiration so additional attempts to queue the node can be
ignored. See below for off_chain issues.

>
> The existing code seems to have more issues. Firstly, it uses the
> protected chain methods.


I'll swap the protected calls to unprotected for those surrounded by
locking.


> Secondly, is uses
> rtems_chain_is_node_off_chain() with nobody setting a node off chain
> after use.
>

I was developing under RTEMS_DEBUG which does set the node off chain upon
extraction. I'll get this fixed for the non-RTEMS_DEBUG case.

Thanks for taking a look at this.

Kinsey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20230919/e06aed7f/attachment.htm>