Messages in this thread | | | Date | Sat, 15 Jun 2002 19:12:30 +1000 | Subject | Re: 2.4.18 no timestamp update on modified mmapped files | From | Kevin Easton <> |
| |
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/
| |