[quotemstr]

Still no unified buffer cache. :-( The lack of coherence and memory reuse between mmap(2) and read(2) is my single biggest beef with OpenBSD right now. It's a great system in terms of robustness, documentation, and philosophical unification. It's a shame its kernel still thinks Ronald Reagan is president.

[DblPlusUngood]

What coherence is lacking? OpenBSD supports msync(2), which is the only POSIX mechanism I know of for ensuring coherency between read(2) and shared file mappings. Otherwise relying on unspecified behavior sounds dangerous.

[quotemstr]

Oh, come on. Every other system in common use is fully coherent. POSIX allowing OpenBSD's behavior doesn't make that behavior a good idea or a quality implementation.

[DblPlusUngood]

OpenBSD's choice is arguably reasonable, given their prioritization of security, since it reduces opportunities for user programs to corrupt kernel memory.

What is the problem with OpenBSD's plan for coherency? Why is the burden of explicitly calling msync(2) too much?

[quotemstr]

> reduces opportunities for user programs to corrupt kernel memory

I don't see how it could. Kernel data structures don't go on pagecache pages.

> OpenBSD's choice is arguably reasonable

At a human level, the OpenBSD people have spent way too much time coming up with rationalizations for their obsolete VM design to back down now. Whether OpenBSD's VM subsystem is good or not, their pride will force them to keep claiming that it's good, practically forever.

[DblPlusUngood]

> I don't see how it could. Kernel data structures don't go on pagecache pages.

Kernel data structures could end up on a pagecache page: all it takes is a reference counting bug and the page could be reallocated in the kernel heap, which is directly mapped by user space. Keeping user-mapped pages and pagecache pages distinct makes this less likely.

I am otherwise not convinced that there is an actual problem with OpenBSD's coherency plan.

[_wldu]

That's a feature.

[quotemstr]

Is it?