[lkml]   [2003]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Race between vmtruncate and mapped areas?

--On Tuesday, May 13, 2003 23:58:21 +0300 Mika Penttilä
<> 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 T/L 678-3059

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:35    [W:0.079 / U:0.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site