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 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/
This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 22:00:33 EST