Hi, On Thu, 2005-01-27 at 07:57, Al Viro wrote:
> Note that fs users of file_fsync() are definitely not going to be > involved into contention here - they need opened file => held active > reference to superblock. > So we are left only with fs-internal asynchronous callers of > lock_super(). UDF, UFS, sysv, hpfs and ext2 are out of question - they > don't have async callers of that sort. ext3... maybe, I'm not familiar > with resize code in there. In any case, that'd better be fixed in > ext3 if such abuse exists. ext3 resize is like file_fsync() --- it's an ioctl, so there's a guaranteed open file at that point. But while the resize code originally used lock_super() to protect from races against allocation/deallocation, the ordering fixes in it means that that's all safe anyway now. The lock_super() is currently only really used to guard against two threads doing resize at the same time, and if it's a problem, it would be trivial to use a different lock. --Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/