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. > > > > > 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