[ECOS] Re: RE : [ECOS] Is JFFS2 thread-safe?

[David Woodhouse <dwmw2@infradead.org>]

On Thu, 2003-11-27 at 10:15 +0100, Vincent Catros wrote:
> If I understand, JFFS2 should be thread safe, but this has never been
> tested since multual access is avoided by fileio layer when using
> CYG_SYNCMODE_FILE_FILESYSTEM flag?

The core code of JFFS2, which is shared by both Linux and eCos ports, is
definitely thread safe -- assuming the semaphore and spinlock operations
from Linux are mapped to the correct locking primitives under eCos. I
wonder if spin_lock() should be mapped to a preemption lock. This
locking is documented in the file README.Locking. 

The eCos-specific code of JFFS2 lacks locking on its _own_ inode cache
data structures (i.e. struct _inode, not anything used by the JFFS2
core). In particular the i_cache_{next,prev} lists and the use counts
(i_count) need protection, to deal with simultaneous jffs2_iget() and
jffs2_iput() of the same inode, etc.

That is all currently protected by the CYG_SYNCMODE_FILE_FILESYSTEM
flag, but ideally we'd be able to lose that flag and provide our own
finer-grained locking. Currently, if the garbage collect thread is
implemented (I've put in place only a skeleton), it would need to
LOCK_FS(mte) before calling into jffs2_garbage_collect_pass(). That
would prevent even _read_ activity during the GC pass, which is
suboptimal.

-- 
dwmw2



-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss