[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