Re: Race between vmtruncate and mapped areas?

[Dave McCracken <dmccr@us.ibm.com>]

--On Tuesday, May 13, 2003 23:58:21 +0300 Mika Penttila
<mika.penttila@kolumbus.fi> wrote:

> Isn't that what inode->i_sem is supposed to protect...?

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?

Dave McCracken

======================================================================
Dave McCracken          IBM Linux Base Kernel Team      1-512-838-3059
dmccr@us.ibm.com                                        T/L   678-3059

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>