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

As part of chasing the BUG() we've been seeing in objrmap I took a good
look at vmtruncate(). I believe I've identified a race condition that no
only triggers that BUG(), but also could cause some strange behavior
without the objrmap patch.

Basically vmtruncate() does the following steps: first, it unmaps the
truncated pages from all page tables using zap_page_range(). Then it
removes those pages from the page cache using truncate_inode_pages().
These steps are done without any lock that I can find, so it's possible for
another task to get in between the unmap and the remove, and remap one or
more pages back into its page tables.

The result of this is a page that has been disconnected from the file but
is mapped in a task's address space as if it were still part of that file.
Any further modifications to this page will be lost.

I can easily detect this condition by adding a bugcheck for page_mapped()
in truncate_complete_page(), then running Andrew's bash-shared-mapping test

Please feel free to poke holes in my analysis. I'm not at all sure I
haven't missed some subtlety here.

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.077 / U:4.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site