--On Tuesday, May 13, 2003 23:58:21 +0300 Mika Penttilä
<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 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/
This archive was generated by hypermail 2b29 : Thu May 15 2003 - 22:00:48 EST