JFFS2: jffs2_symlink/jffs2_mkdir/jffs2_mknod bug?

Joakim Tjernlund joakim.tjernlund at transmode.se
Wed Dec 2 04:16:04 EST 2009


>
> On Wed, 2009-12-02 at 10:11 +0800, Tao Huang wrote:
> > On jffs2_symlink/jffs2_mkdir/jffs2_mknod, after jffs2_write_dnode,
> > any call jffs2_clear_inode will no call jffs2_mark_node_obsolete because
> > pino_nlink is not zero. This will make kernel BUG on jffs2_garbage_collect_live.
> >
> > Run fsstress on NANDSIM can easy see this bug when no space, for example:
> > fsstress -p 2 -n 100000 -d /data -l 0 -s 100000 on 128KB NANDSIM.
>
> Hm, good catch; thanks.
>
> We _need_ to have a non-zero pino_nlink for new inodes during their
> creation. We can't just create them with zero nlink and then use
> jffs2_do_link() because that would leave an opportunity for the garbage
> collector to delete them in between.
>
> So we need to zero the nlink for a 'failed' creation. Something like
> this...?

> +      mutex_lock(&f->sem);
> +      f->inocache->pino_nlink = 0;
> +      mutex_unlock(&f->sem);

Do you need mutex lock/unlock around a simple assignment?

    Jocke




More information about the linux-mtd mailing list