Re: [PATCH linux-2.6.0-test10-mm1] filemap_fdatawait.patch

[Janet Morgan <janetmor@us.ibm.com>]

Janet Morgan wrote:

> Andrew Morton wrote:
>
>> Andrew Morton <akpm@osdl.org> 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