Re: Race between vmtruncate and mapped areas?

William Lee Irwin III
2003-05-13T22:49:29Z

On Tue, May 13, 2003 at 05:26:24PM -0500, Dave McCracken wrote:
> Hmm... Yep, it is. I did some more investigating. My initial scenario
> required that the task mapping the page extend the file after the truncate,
> which must be done via some kind of write(). The write() would trip over
> i_sem and therefore hang waiting for vmtruncate() to complete. So I was
> wrong about that one.
> Hoever, vmtruncate() does get to truncate_complete_page() with a page
> that's mapped...
> After some though it occurred to me there is a simple alternative scenario
> that's not protected. If a task is *already* in a page fault mapping the
> page in, then vmtruncate() could call zap_page_range() before the page
> fault completes. When the page fault does complete the page will be mapped
> into the area previously cleared by vmtruncate().
> We could make vmtruncate() take mmap_sem for write, but that seems somewhat
> drastic. Does anyone have any alternative ideas?

That doesn't sound like it's going to help, there isn't a unique
mmap_sem to be taken and so we just get caught between acquisitions
with the same problem.

-- wli