lkml.org 
[lkml]   [2012]   [May]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [patch|rfc] block: don't mark buffers beyond end of disk as mapped
Date
Nick Piggin <npiggin@gmail.com> writes:

> On 2 May 2012 00:08, Jeff Moyer <jmoyer@redhat.com> wrote:
>> Nick Piggin <npiggin@gmail.com> writes:
>>
>>> Not a bad fix. But it's kind of sad to have i_size checking logic also in
>>> block_read_full_page, that does not cope with this.
>>>
>>> I have found there are parts of the kernel (readahead) that try to read
>>> beyond EOF and seem to get angry if we return an error (by not
>>> marking uptodate in readpage) in that case though :(
>>>
>>> But, either way, I think it's very reasonable to not mark buffers beyond
>>> end of device as mapped. So I think your patch is fine.
>>>
>>> I guess for ext[234], it does not read metadata close to the end of the
>>> device or you were using 4K sized blocks?
>>
>> Well, the test case just reads directly from the loop device, bypassing
>> the file system, and I did use 1KB blocks when making the file system, so
>> it is quite puzzling.
>
> It's because buffer_head creation does not go through the same paths
> for bdev file access versus getblk APIs.
>
> blkdev_get_block does the right thing there
>
> In fact, it's probably good to unify the checks here, i.e., use max_blocks()

You really think it's worth it? I mean, it's just an i_size_read and a
shift, and there is precedent for it inside fs/buffer.c. I'd prefer to
keep the patch as-is, but will change it if you feel that strongly about
it.

Cheers,
Jeff


\
 
 \ /
  Last update: 2012-05-01 23:21    [W:0.493 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site