[Cluster-devel] BUG? racy access to i_diskflags

[Steven Whitehouse <swhiteho@redhat.com>]

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

That looks ok to me. The access in inode_go_lock() occurs when the glock
on the inode has been acquired but before any process (such as might be
calling so_gfs2_set_flags() for example) will be able to access the
inode.

The flags access in inode_go_lock() is there to ensure that in the event
of a node crashing when it is part way through truncating an inode, that
the truncated blocks are not seen by any other processes after the
event. It is required because it is impossible to guarantee that a
truncation will always fit inside a single transaction,

Steve.