[lkml]   [2002]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.4.18 no timestamp update on modified mmapped files

    On Sat, 15 Jun 2002, Hugh Dickins wrote:
    > On Sat, 15 Jun 2002, Kevin Easton wrote:
    > > On Wed, 12 Jun 2002, Hugh Dickins wrote:
    > > >
    > > > But you didn't spell out the worst news on that option: read faults
    > > > into a read-only shared mapping of a file which the application had
    > > > open for read-write when it mmapped: the page must be mapped to disk
    > > > at read fault time (because the mapping just might be mprotected for
    > > > read-write later on, and the page then dirtied).
    > >
    > > Can't the page be mapped to disk at the page-dirtying-fault time? I
    > > was under the impression that even after the mapping has been mprotected
    > > for read-write, the first write to each page will still cause a page
    > > fault that results in the page being marked dirty.
    > It depends on the history of the mapping. mprotect() does not fault in
    > any new pages, it just changes permissions on page table entries already
    > present. So, if you're talking about a fresh mapping, or an area of a
    > mapping which has not yet been accessed, you're correct. And you're
    > correct if you're talking about a private mapping (which needs write
    > protection to do copy-on-write). But those aren't cases of concern here.
    > In general, there will already be some page table entries present,
    > and mprotect() from shared readonly to readwrite currently adds write
    > permission to those entries, and no write fault will then occur on
    > first write to those pages. I was suggesting that we'd need to change
    > that (to the behaviour you expect) if we were trying to guarantee disk
    > space for unbacked dirty pages (without allocating on read fault).
    > (I'm referring above to the implementation in Linux 2.4 or 2.5:
    > I've not checked other releases or OSes, which could indeed arrange
    > permissions so that there's always a page-dirtying fault.)
    > Hugh

    Hmm.. so how do such pages get marked dirty on architectures that don't
    do it in hardware ("most RISC architectures" according to a comment in
    memory.c)? Is the entire mapping made dirty when the write permissions
    are added?

    - Kevin

    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:26    [W:3.461 / U:0.016 seconds]
    ©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site