[PATCH 2/9] cpukit/jffs2: Protect the inode cache

[Sebastian Huber]

On 09.12.23 03:31, Kinsey Moore wrote:
> The inode cache can be altered and queried by multiple threads of
> execution, even before the introduction of delayed write support for
> NAND. This provides a new lock to prevent simultaneous modification of
> the cache.

Under which condition is the inode cache accessed without the file 
system instance lock for normal operations (no delayed works stuff)?

Your new code still has no test cases and the configuration option is 
not documented (http://devel.rtems.org/ticket/4961).

I am still in favour of an alternative locking approach:

1. The delayed work support uses a mutex D and a condition variable C 
used with D.

2. Add a queue for the delayed work to the fs information and a node to 
register the info in the delayed work support.

3. The first delayed work request of a JFFS2 instance registers the fs 
information in the delayed work support and uses C to signal the work to 
the delayed work task.

4. Further requests just get enqueued and signaled using D and C.

5. When a instance is unmounted, drain the delayed work queue using D and C.

The delayed work uses the fs info mutex to protect the work. You need 
also reference count for the fs info to control the work and the drain 
during unmount.

-- 
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/