Messages in this thread |  | | Date | Tue, 13 May 2003 17:26:24 -0500 | From | Dave McCracken <> | Subject | Re: Race between vmtruncate and mapped areas? |
| |
--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/
|  |