On Monday 03 May 2010 12:29:45 Amit K. Arora wrote: > On Mon, May 03, 2010 at 09:53:44AM +0530, Nikanth Karthikesan wrote: > > On Saturday 01 May 2010 12:34:26 Amit K. Arora wrote: > > > On Fri, Apr 30, 2010 at 02:33:19PM -0700, Andrew Morton wrote: > > > > Also, there doesn't seem to be much point in doing > > > > > > > > mutex_lock(i_mutex); > > > > if (some_condition) > > > > bale out > > > > mutex_unlock(i_mutex); > > > > > > > > <stuff> > > > > > > > > because `some_condition' can now become true before or during the > > > > execution of `stuff'. > > > > > > > > IOW, it's racy. > > > > oh, yes. :( > > > > > Agreed. How about doing this check in the filesystem specific fallocate > > > inode routines instead ? For example, in ext4 we could do : > > > > I guess, calling the filesystem specific fallocate with the lock held > > would create lock ordering problems? If so, this might be the only way. > > But it would be better to document at the call site, that the callee > > should check for RLIMIT_FSIZE. > > Hmm.. I never said to call the filesystem specific fallocate with > i_mutex held. What I suggested was that each filesystem at some point > anyhow takes the i_mutex to preallocate. Thats where the check should > be, to avoid the race. This is what the example patch below does. > Yes, you never said that. But I just wondered whether that would be have problems and doing the check in filesystem specific fallocate is the only solution. :) Thanks Nikanth -- 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
