FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Cluster Development

 
 
LinkBack Thread Tools
 
Old 08-17-2010, 10:40 AM
Steven Whitehouse
 
Default BUG? racy access to i_diskflags

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.
 

Thread Tools




All times are GMT. The time now is 08:12 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org