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