This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: RE : Is JFFS2 thread-safe?
- From: David Woodhouse <dwmw2 at infradead dot org>
- To: Vincent Catros <Vincent dot Catros at elios-informatique dot fr>
- Cc: ecos-discuss at sources dot redhat dot com
- Date: Thu, 27 Nov 2003 09:36:26 +0000
- Subject: [ECOS] Re: RE : [ECOS] Is JFFS2 thread-safe?
- References: <000001c3b4c7$023894e0$7407a8c0@figuier>
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