Hi, On Tue, 2010-08-17 at 13:28 +0900, 홍신 shin hong wrote: > Hi. I am reporting an issue suspected as racy > while I read inode_go_lock() at gfs2/glops.c in Linux 2.6.35. > > Since I do not have much background on GFS2, I am not certain > whether the issue is serious or not. But please examine the issue > and let me know your opinion. > > It seems that inode_go_lock() accesses gfs2_inode's i_diskflags field > without any lock held. > > But, as do_gfs2_set_flags() updates gfs2_inode's i_diskflags, > concurrent executions with with inode_go_lock() might result > race conditions. > > Could you examine the issue please? > > Sincerely > Shin Hong
Yes, inode_go_lock() does examine those flags, but the layers above that call should ensure that it is single threaded in effect. The setting of flags required a glock is held, and inode_go_lock() would be called as part of the glock acquisition, and it is single threaded even if a shared lock is requested, so it will have completed before do_gfs2_set_flags() is called. Or perhaps I should say, it should have completed before then unless you have found a code path where that is not the case? Steve.
