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

From: Andrew Morton
Date: Thu May 13 2004 - 21:35:02 EST

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
Please read the FAQ at