Hi, In AUFS branch deletion code paths, it seems that s_inodes of the aufs superblock is walked through without taking the inode_lock. Is it a safe to walk through this list and working on it without holding the inode_lock? Rest of places in the kernel where s_inodes list is manipulated with holding inode_lock. Also i see that inode_lock doesn't seem to be an exported symbol and VFS seems to be the only consumer of it.
Sometimes on case of branch deletion on one of branch succeeds when some i/o happening on aufs mount point, sometimes i seem to hit upon a crash in the code path au_h_iptr.( via au_refresh_hinode_self code) where h_inode contain some invalid kernel virtual address. Also i see that au_ii could return NULL. does the below patch is necessary in the code path remount, del branch scenario? --- iinfo.c.orig 2010-08-06 09:08:59.000000000 -0400 +++ iinfo.c 2010-08-06 09:24:31.000000000 -0400 @@ -24,11 +24,14 @@ struct inode *au_h_iptr(struct inode *inode, aufs_bindex_t bindex) { - struct inode *h_inode; + struct inode *h_inode = NULL; + struct au_iinfo *iinfo; IiMustAnyLock(inode); - h_inode = au_ii(inode)->ii_hinode[0 + bindex].hi_inode; + iinfo = au_ii(inode); + if ( iinfo ) + h_inode = au_ii(inode)->ii_hinode[0 + bindex].hi_inode; AuDebugOn(h_inode && atomic_read(&h_inode->i_count) <= 0); return h_inode; } thx,thayumanavar s. ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev