Janet Morgan wrote:
> Andrew Morton wrote:
>
>> Andrew Morton <[email protected]> wrote:
>>
>>
>>> Let me actually think about this a bit.
>>>
>>
>>
>> Nasty. The same race is present in 2.4.x...
>>
>> How's about we start new I/O in filemap_fdatawait() if the page is
>> dirty?
>>
>>
>> diff -puN mm/filemap.c~a mm/filemap.c
>> --- 25/mm/filemap.c~a 2003-12-31 03:10:29.000000000 -0800
>> +++ 25-akpm/mm/filemap.c 2003-12-31 03:17:05.000000000 -0800
>> @@ -206,7 +206,13 @@ restart:
>> page_cache_get(page);
>> spin_unlock(&mapping->page_lock);
>>
>> - wait_on_page_writeback(page);
>> + lock_page(page);
>> + if (PageDirty(page) && mapping->a_ops->writepage) {
>> + write_one_page(page, 1);
>> + } else {
>> + wait_on_page_writeback(page);
>> + unlock_page(page);
>> + }
>> if (PageError(page))
>> ret = -EIO;
>>
>>
>>
>>
> That fixed the problem! Stephen's testcase is running successfully on
> 2.6.1-mm1 plus your patch -- no more uninitialized data!
>
Geez, I guess not. While this was the first time the test ran
successfully for me, it is not reproducible. Subsequent runs on
2.6.1-mm1 plus the above patch are seeing unintialized data. Sorry for
the false start.
-Janet