Re: Race between vmtruncate and mapped areas?

[William Lee Irwin III <wli@holomorphy.com>]

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