Hello Thayumanavar, Thayumanavar Sachithanantham: > 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
sb->s_umount should protect it in vfs and I don't think inode_lock is necessary. > 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. That may be another bug in aufs. Will you give me these info? (from the aufs README) - /proc/mounts (instead of the output of mount(8)) - /sys/module/aufs/* - /sys/fs/aufs/* (if you have them) - /debug/aufs/* (if you have them) - linux kernel version if your kernel is not plain, for example modified by distributor, the url where i can download its source is necessary too. - aufs version which was printed at loading the module or booting the system, instead of the date you downloaded. - configuration (define/undefine CONFIG_AUFS_xxx) - kernel configuration or /proc/config.gz (if you have it) - behaviour which you think to be incorrect - actual operation, reproducible one is better - mailto: aufs-users at lists.sourceforge.net J. R. Okajima ------------------------------------------------------------------------------ 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
