[RTEMS Project] #4536: acess JFFS2 sb->s_root
RTEMS trac
trac at rtems.org
Thu Oct 28 18:29:00 UTC 2021
#4536: acess JFFS2 sb->s_root
---------------------------+----------------------
Reporter: chenjin_zhong | Owner: (none)
Type: defect | Status: closed
Priority: normal | Milestone: 5.1
Component: fs/jaffs2 | Version: 5
Severity: normal | Resolution: invalid
Keywords: | Blocked By:
Blocking: |
---------------------------+----------------------
Changes (by Sebastian Huber):
* status: reopened => closed
* resolution: => invalid
Comment:
Replying to [comment:3 chenjin_zhong]:
> Replying to [comment:1 Sebastian Huber]:
> > Thanks for your interest in the RTEMS port of JFFS2. If you have
questions, then you could also ask them on the devel at rtems.org mailing
list. The RTEMS port of JFFS2 does not use a file system internal locking.
There is a global lock for each JFFS2 instance:
> > {{{#!c
> > static void rtems_jffs2_do_lock(struct super_block *sb)
> > {
> > rtems_recursive_mutex_lock(&sb->s_mutex);
> > }
> >
> > static void rtems_jffs2_do_unlock(struct super_block *sb)
> > {
> > rtems_recursive_mutex_unlock(&sb->s_mutex);
> > }
> > }}}
>
> Suppose that a GC thread or other thread/task calls
jffs2_garbage_collect_pass, and then operates sb->s_root by
jffs2_iget.meanwhile, the main task accesing sb->s_root. a global lock for
each JFFS2 instance can't work.
It is not a high performance approach, but it works. See
`testsuites/fstests/fsjffs2gc01/init.c`.
--
Ticket URL: <http://devel.rtems.org/ticket/4536#comment:4>
RTEMS Project <http://www.rtems.org/>
RTEMS Project
More information about the bugs
mailing list