Re: [PATCH][RFC] truncate vs add_to_page_cache race

[Andrew Morton]

Nick Piggin <nickpiggin@xxxxxxxxxxxx> wrote:
>
>  I think there is a race between truncate and do_generic_mapping_read.
> 
>  do_generic_mapping_read()
>  {
>  	check i_size -> ok
>  no_cached_page:
>  	allocate a page
>  	add_to_page_cache
>  	readpage
>  }
> 
>  And what can happen is truncate gets to the file after i_size is
>  checked and before the page is added to the page cache.
> 
>  I asked Hugh about this because a quick search showed he was the
>  last one to make a noise about this kind of thing. He wasn't up
>  to speed with the current code, but agreed it looks fishy.
> 
>  OK, I made a debug patch to printk and schedule_timeout in this
>  race window so I can easily truncate the file. When this happens,
>  it turns out that the readpage thinks it is reading a hole and
>  fills the page with zeros -> invalid result?

A zero-filled pagecache page outside i_size is OK.

If someone extends i_size and reads the page, they get zeros.  If they
truncate the file more, it gets dropped.  If they extend i_size then write
to the page, that's OK.  And page reclaim can reclaim it.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/