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.
> check i_size -> ok
> allocate a page
> 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/