lkml.org 
[lkml]   [2003]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Race between vmtruncate and mapped areas?
Dave McCracken <dmccr@us.ibm.com> wrote:
>
> task 1 waits for IO in the page fault.
>
> task 2 calls truncate, which does zap_page_range() on the range that page
> is in.
>
> task 1 wakes up and maps the page.
>
> task 2 calls truncate_inode_pages which removes the newly mapped page from
> the page cache.
>
> Now the state is that the page has been disconnected from the file, but
> it's still mapped in task 1's address space. That task thinks it has valid
> data from the file in that page, and may continue to read/write there, and
> assume any changes will get written back..

yes. It's a very complex way of allocating anonymous memory.

I am told that Stephen, Linus and others discussed this at length at KS a
couple of years ago and the upshot was that the application is racy anyway
and there's nothing wrong with it.

Hugh calls these "Morton pages" but it wasn't me and nobody saw me do it.

It would be nice to make them go away - they cause problems.
-
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/

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