On Thu, 2008-11-06 at 18:51 -0800, Andrew Morton wrote: > On Fri, 7 Nov 2008 11:09:49 +0900 "______ shin hong" <hongshin@xxxxxxxxx> wrote: > > > Dear Ext4 maintainer, > > > > I found a suspected data race bug at ext4_release_file() in ext4/file.c . > > > > Is it necessary to re-check whether the if-statement's > > condition(atomic_read(&inode->i_writecount) == 1) is satisifed after > > semaphore down operation? > > > > It seems to use "test and test and set" pattern(double-checking) > > but the second "test" seems to be missed. > > > > Please examine this function. Thank you. > > > > p.s. I sent the same report to sct@xxxxxxxxxxx But I did not received > > any reply. > > I think my mail was discarded so I am sending the same again. > > > > An appropriate way to report this possible bug is to Cc: the ext4 mailing > list, which I have cc'ed here. I guess we could add the check after grab the i_data_sem, but not sure how useful is that, there is always a window that during the process of freeing preallocation, another new writer to the same inode. The i_data_sem semaphore is hold to prevent race between discard preallocation and use of preallocation, not to protect i_writecount. The check of inode's i_writecount is to avoid doing discard for every file close, the idea is only try to discard the preallocation for the last writer of the file. But the i_writecount could be >1 at the time of discard preallocation. If a new writer comes in after i_data_sem is hold then the preallocation is freed, then by the time the new writer comes in and need block allocation, the preallocate gets build up atomatically. Mingming -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
