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

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



> Basically what I think is happening is this:
>
> yaffs wants to allocate more memory and calls kmalloc
> kmalloc prunes the inode cache to free up memory and calls yaffs_clear_inode
> deadlock
>
> The change in yportenv.h tells kmalloc that the call is from within an fs and
> not to do fs harvesting.
>
> Hope that does something for you.
>
> -- CHarles

--
Peter Barada <peterb@logicpd.com>