Re: [Yaffs] Lockup in 2.6.28-rc8 (double lock)

On Tuesday 10 February 2009 14:26:47 Peter Barada wrote:
> On Tue, 2009-02-10 at 11:08 +1300, Charles Manning wrote:
> > On Tuesday 10 February 2009 07:02:05 Peter Barada wrote:
> > > I pulled a new copy of CVS YAFFS2 just after Charles added his patch
> > > for write_begin/write_end to build YAFFS for 2.6.28 kernels.
> >
> > <snip>
> >
> > > yaffs locking
> > > yaffs_mknod: making file
> > > yaffs_clear_inode: ino 1489, count 0 object exists
> > > yaffs locking
> > > yaffs_write_super
> > > yaffs_write_super
> > > yaffs_write_super
> > > yaffs_write_super
> > >
> > > It looks like a lookup for "Podgorica" came back as not there, but
> > > creating the object for "Podgorica" needs to clear the inode which
> > > tries to lock it, and YAFFS (and the upper FS layers) are wedged.
> > >
> > > Any ideas on how to fix this?
> >
> > Peter
> >
> > You say you pulled CVS just after I checked in the 2.6.28 stuff.
> >
> > A while later I checked in change to yportenv.h
> >
> > http://www.aleph1.co.uk/cgi-bin/viewcvs.cgi/yaffs2/yportenv.h?r1=1.20&r2=
> >1.21
> >
> > This patch **should** fix what you're seeing.
>
> Still hangs, even with a fresh checkout of YAFFS2 from 19:41 EST
> (GMT-0500) that incorporates the patch to use GFP_NOFS on YMALLOC() (log
> from file operation before):
>
>
> yaffs locking
> yaffs_lookup for 2945:Andorra
> yaffs unlocking
> yaffs_lookup not found
> yaffs_create
> yaffs_mknod: parent object 2945 type 3
> yaffs_mknod: making oject for Andorra, mode 81ed dev 0
> yaffs locking
> yaffs_mknod: making file
> yaffs unlocking
> yaffs_get_inode for object 2829
> yaffs_iget for 2829
> yaffs locking
> yaffs_FillInode mode 81ed uid 0 gid 0 size 0 count 1
> yaffs unlocking
> yaffs_mknod created object 2829 count = 1
> start yaffs_write_begin
> yaffs locking
> yaffs unlocking
> yaffs_readpage at 00000000, size 00001000
> yaffs locking
> yaffs unlocking
> yaffs_readpage done
> end yaffs_write_begin - ok
> yaffs_write_end addr c64a2000 pos 0 nBytes 2185
> yaffs locking
> yaffs_file_write about to write writing 2185 bytesto object 2829 at 0
> yaffs_file_write writing 2185 bytes, 2185 written at 0
> yaffs_file_write size updated to 2185 bytes, 5 blocks
> yaffs unlocking
> yaffs locking
> yaffs unlocking
> yaffs_file_flush object 2829 (dirty)
> yaffs locking
> yaffs unlocking
> yaffs_setattr of object 2829
> yaffs locking
> yaffs unlocking
> yaffs_setattr of object 2829
> yaffs locking
> yaffs unlocking
> yaffs_setattr of object 2829
> yaffs locking
> yaffs unlocking
> yaffs locking
> yaffs_lookup for 2945:Podgorica
> yaffs unlocking
> yaffs_lookup not found
> yaffs_create
> yaffs_mknod: parent object 2945 type 3
> yaffs_mknod: making oject for Podgorica, mode 81ed dev 0
> yaffs locking
> yaffs_mknod: making file
> yaffs_clear_inode: ino 1489, count 0 object exists
> yaffs locking
> yaffs_write_super
> yaffs_write_super
> yaffs_write_super
> yaffs_write_super

Hi Peter

Could you try adding a bit more tracing to the YMALLOC to verify that that is
the chain that is causing the problem.

Also try extending the tracing  on the locking with something like:
static void yaffs_GrossLock(yaffs_Device * dev)
{
        T(YAFFS_TRACE_OS, (KERN_DEBUG "yaffs locking %p\n",current));

        down(&dev->grossLock);
        T(YAFFS_TRACE_OS, (KERN_DEBUG "yaffs locked %p\n",current)); 

}

static void yaffs_GrossUnlock(yaffs_Device * dev)
{
        T(YAFFS_TRACE_OS, (KERN_DEBUG "yaffs unlocking %p\n",current));
        up(&dev->grossLock);

}

that should confirm the chain for us.

Perhaps the NOFS flag is not being honoured the way that was being expected.

-- Charles