#4537 closed defect (invalid)

mutex is not initilaized in jffs2_new_inode

Reported by: chenjin_zhong Owned by:
Priority: normal Milestone: 5.1
Component: fs/jffs2 Version: 5
Severity: normal Keywords:
Cc: Blocked By:
Blocking:

Description

HI, I have found when call jffs2_new_inode to create inode. the f->sem is not initiliazed and lock, but it is be unlocked. The peice of source code is as follows:

struct _inode *jffs2_new_inode (struct _inode *dir_i, int mode, struct jffs2_raw_inode *ri)
{

struct _inode *inode;
struct super_block *sb = dir_i->i_sb;
struct jffs2_sb_info *c;
struct jffs2_inode_info *f;
int ret;

D1(printk(KERN_DEBUG "jffs2_new_inode(): dir_i %ld, mode 0x%x\n", dir_i->i_ino, mode));
c = JFFS2_SB_INFO(sb);


inode = new_inode(sb);


if (!inode)

return ERR_PTR(-ENOMEM);

f = JFFS2_INODE_INFO(inode);
jffs2_init_inode_info(f);

memset(ri, 0, sizeof(*ri));
/* Set OS-specific defaults for new inodes */
ri->uid = cpu_to_je16(geteuid());
ri->gid = cpu_to_je16(getegid());
ri->mode = cpu_to_jemode(mode);
ret = jffs2_do_new_inode (c, f, mode, ri);
if (ret) {

forceful evict: f->sem is locked already, and the
inode is bad.
if (inode->i_cache_prev)

inode->i_cache_prev->i_cache_next = inode->i_cache_next;

if (inode->i_cache_next)

inode->i_cache_next->i_cache_prev = inode->i_cache_prev;

mutex_unlock(&(f->sem));
jffs2_clear_inode(inode);
memset(inode, 0x6a, sizeof(*inode));
free(inode);
return ERR_PTR(ret);

}
inode->i_nlink = 1;
inode->i_ino = je32_to_cpu(ri->ino);
inode->i_mode = jemode_to_cpu(ri->mode);
inode->i_gid = je16_to_cpu(ri->gid);
inode->i_uid = je16_to_cpu(ri->uid);
inode->i_atime = inode->i_ctime = inode->i_mtime = get_seconds();
ri->atime = ri->mtime = ri->ctime = cpu_to_je32(inode->i_mtime);
inode->i_size = 0;
return inode;

}

Change History (6)

comment:1 Changed on 10/27/21 at 18:38:19 by Joel Sherrill

The code in this file is related to similar code for ports of JFFS2. Can you compare this to the current code for Linux and other ports to see what they do? That might significantly ease the analysis for all these issues.

comment:2 Changed on 10/28/21 at 05:20:02 by Sebastian Huber

Resolution: invalid
Status: newclosed

Thanks for your interest in the RTEMS port of JFFS2. If you have questions, then you could also ask them on the devel@… mailing list. The RTEMS port of JFFS2 does not use a file system internal locking. There is a global lock for each JFFS2 instance:

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);
}

comment:3 Changed on 10/28/21 at 05:20:15 by Sebastian Huber

Component: adminfs/jaffs2

comment:4 in reply to:  1 Changed on 10/28/21 at 14:34:47 by chenjin_zhong

Replying to Joel Sherrill:

The code in this file is related to similar code for ports of JFFS2. Can you compare this to the current code for Linux and other ports to see what they do? That might significantly ease the analysis for all these issues.

I have compared it with Linux JFFS2. The peice of source code in Linux is as follows,As shown in black-body section, the f->sem is not be initialized and locked in RTEMS.

struct jffs2_sb_info *c;
struct jffs2_raw_inode latest_node;
union jffs2_device_node jdev;
struct inode *inode;
dev_t rdev = 0;
int ret;

jffs2_dbg(1, "%s(): ino == %lu\n", func, ino);

inode = iget_locked(sb, ino);
if (!inode)

return ERR_PTR(-ENOMEM);

if (!(inode->i_state & I_NEW))

return inode;

f = JFFS2_INODE_INFO(inode);
c = JFFS2_SB_INFO(inode->i_sb);

jffs2_init_inode_info(f);
mutex_lock(&f->sem);

ret = jffs2_do_read_inode(c, f, inode->i_ino, &latest_node);
if (ret)

goto error;

inode->i_mode = jemode_to_cpu(latest_node.mode);
i_uid_write(inode, je16_to_cpu(latest_node.uid));
i_gid_write(inode, je16_to_cpu(latest_node.gid));
inode->i_size = je32_to_cpu(latest_node.isize);
inode->i_atime = ITIME(je32_to_cpu(latest_node.atime));
inode->i_mtime = ITIME(je32_to_cpu(latest_node.mtime));
inode->i_ctime = ITIME(je32_to_cpu(latest_node.ctime));

set_nlink(inode, f->inocache->pino_nlink);

inode->i_blocks = (inode->i_size + 511) >> 9;

comment:5 Changed on 10/28/21 at 14:42:27 by chenjin_zhong

Resolution: invalid
Status: closedreopened

comment:6 Changed on 10/28/21 at 14:45:13 by Sebastian Huber

Resolution: invalid
Status: reopenedclosed

Yes, the f->sem is an empty structure, it is not initialized, it is not used, locked or whatever in RTEMS. This is intentional and not a bug. I repeat: The RTEMS port of JFFS2 does not use a file system internal locking. There is a global lock for each JFFS2 instance.

Note: See TracTickets for help on using tickets.