[PATCH] fix corruption case for block size < page size

[Lachlan McIlroy]

Eric Sandeen wrote:
> Eric Sandeen wrote:
> 
>> Gah; or not.  what is going on here...  Doing just steps 1, 2, 3, 4
>> (ending on the extending truncate):
>>
>> # xfs_io -c "pwrite -S 0x11 -b 4096 0 4096" -c "mmap -r 0 512" -c "mread
>> 0 512" -c "munmap" -c "truncate 256" -c "truncate 514" -t -d -f
>> /mnt/scratch/testfile
>>
>> # xfs_bmap -v /mnt/scratch/testfile
>> /mnt/scratch/testfile:
>>  EXT: FILE-OFFSET      BLOCK-RANGE      AG AG-OFFSET        TOTAL
>>    0: [0..0]:          63..63            0 (63..63)             1
>>    1: [1..1]:          hole                                     1
>>
>> It looks like what I expect, at this point.  But then:
>>
>> # sync
>> # xfs_bmap -v /mnt/scratch/testfile
>> /mnt/scratch/testfile:
>>  EXT: FILE-OFFSET      BLOCK-RANGE      AG AG-OFFSET        TOTAL
>>    0: [0..1]:          63..64            0 (63..64)             2
>>
>> Um, why'd that last block get mapped in?  mmap vs. direct IO I'm
>> guessing... w/o the mmap read this does not happen.
> 
> Replying to myself twice?  I really need to go to bed.
> 
> So this all does seem to come back to page_state_convert.
> 
> Both the extending write in the original case and the sync above find
> their way there; but esp. in the sync test above, why do we have *any*
> work to do?
Eric, did you find out why sync was allocating that second block?

> 
> With a little instrumentation I see that for the truncate out; sync test
> above we get to xfs_vm_writepage() for a page which is *not* dirty, and
> yet we call page_state_convert on it and map in that 2nd block... Is
> that right!?  I guess it is; ->write_cache_pages() clears dirty before
> calling writepage.  Still why would this page be found dirty on this
> path.  Bah.  Bedtime.
> 
> -Eric