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
