Messages in this thread | | | Date | Thu, 13 May 2004 19:33:28 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH][RFC] truncate vs add_to_page_cache race |
| |
Nick Piggin <nickpiggin@yahoo.com.au> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |