2011/2/27 Ted Ts'o <tytso@xxxxxxx>: > On Mon, Feb 21, 2011 at 05:50:21PM +0100, Marco Stornelli wrote: >> 2011/2/21 Christoph Hellwig <hch@xxxxxxxxxxxxx>: >> > On Mon, Feb 21, 2011 at 09:26:32AM +0100, Marco Stornelli wrote: >> >> From: Marco Stornelli <marco.stornelli@xxxxxxxxx> >> >> >> >> All fs must check for the immutable flag in their fallocate callback. >> >> It's possible to have a race condition in this scenario: an application >> >> open a file in read/write and it does something, meanwhile root set the >> >> immutable flag on the file, the application at that point can call >> >> fallocate with success. Only Ocfs2 check for the immutable flag at the >> >> moment. >> > >> > Please add the check in fs/open.c:do_fallocate() so that it covers all >> > filesystems. >> > >> > >> >> The check should be done after the fs got the inode mutex lock. > > Why? None of the other places which check the IMMUTABLE flag do so > under the inode mutex lock. Yes, it's true that we're not properly > doing proper locking when updating i_flags from the ioctl (this is > true for all file systems), but this has been true for quite some > time, and using a mutex to protect bit set/clear/test operations would > be like using a sledgehammer to kill a fly. > > A proper fix if we want to be completely correct about updates to > i_flags would involve using test_bit, set_bit, and clear_bit, which is > guaranteed to be atomic. This is how we update the > ext4_inode_info->i_flags (which is different from inode->i_flags) (see > the definition and use of EXT4_INODE_BIT_FNS in fs/ext4/ext4.h). > > At some point, it would be good to fix how we set/get i_flags values, > but that's independent of the change that's being discussed here. > > - Ted > I was thinking to the possible race with setattr callback. Marco -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
