<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 13, 2023 at 12:26 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 09.12.23 03:31, Kinsey Moore wrote:<br>
> The inode cache can be altered and queried by multiple threads of<br>
> execution, even before the introduction of delayed write support for<br>
> NAND. This provides a new lock to prevent simultaneous modification of<br>
> the cache.<br>
<br>
Under which condition is the inode cache accessed without the file <br>
system instance lock for normal operations (no delayed works stuff)?<br>
<br>
Your new code still has no test cases and the configuration option is <br>
not documented (<a href="http://devel.rtems.org/ticket/4961" rel="noreferrer" target="_blank">http://devel.rtems.org/ticket/4961</a>).<br>
<br>
I am still in favour of an alternative locking approach:<br>
<br>
1. The delayed work support uses a mutex D and a condition variable C <br>
used with D.<br>
<br>
2. Add a queue for the delayed work to the fs information and a node to  <br>
register the info in the delayed work support.<br>
<br>
3. The first delayed work request of a JFFS2 instance registers the fs <br>
information in the delayed work support and uses C to signal the work to <br>
the delayed work task.<br>
<br>
4. Further requests just get enqueued and signaled using D and C.<br>
<br>
5. When a instance is unmounted, drain the delayed work queue using D and C.<br>
<br>
The delayed work uses the fs info mutex to protect the work. You need <br>
also reference count for the fs info to control the work and the drain <br>
during unmount.<br></blockquote><div><br></div><div><div>Using the FS information lock at the level of delayed work callback isn't workable with the current API exposed/consumed by the JFFS2 library as this information is not exposed to the thread calling the delayed work without modification of the JFFS2 library itself or abusing macros to pull in information that isn't actually provided to them (and would require that local variable naming be extremely consistent across usages of this abusive macro). All that is available is the callback function pointer and an opaque void pointer argument. Other implementations that use this library achieve safe locking without the FS information lock.</div><div><br></div><div>I've finally got some time this week to write a few tests for this and fix the missing documentation. I should be able to post them before the end of the week.</div><div><br></div><div>Kinsey</div> </div></div></div>