svn commit: r307626 - head/sys/ufs/ffs

[Konstantin Belousov]

On Sun, Nov 13, 2016 at 10:50:19AM -0800, Adrian Chadd wrote:
> Ok, so after talking with others, my questions are:
> 
> * I thought our VM was supposed to not be doing double mapping like
> this. warner's comment on irc was:
> 
> ===
> 13:39 < bsdimp> adrian the VM isn't supposed to do it at all.
> 13:39 < bsdimp> adrian that is, double map on purpose.
> 13:40 < bsdimp> though there's some exceptions to the rule
> 13:40 < bsdimp> since kernel mappings go away in userland, and
> userland doesn't execute while you're in kernel mode, you can do the
> flushing
>                 game in busdma to prevent most issues.
> 13:41 < bsdimp> which is what we do. Generally, though, our VM doesn't
> do it in-kernel.
> ===
> 
> * is this still the case? or are there places in the VM where we are doing this?
> * can we introduce a machdep/pmap capability check to see if aliasing
> is allowed and if so, turn this feature on?
This never was the case, and never will.  VM establishes mappings as
requested by the userspace and kernel, and n-times mapping for the same
page is always legitimate.  It is the pmap duty to handle that.

If you cared to read my previous mail, I already explained that besides
the userspace asking for n-mapping, there is at least buffer cache which
also maps the same page into KVA, from the times when unified buffer
cache/page cache was introduced.  Same is true for n-mapping of shared
anon pages.

> 
> Adding a pmap capability and turning it on for say, i386/amd64/arm64
> would allow for this new feature as well as the previous behaviour on
> older platforms.
> 
> I don't think I have the time to fix mips pmap to support this new
> feature, so if you want to turn it on for all features, we should
> really fix/test pmap on said platforms first.
This is not a new feature, this is the old bug on that platform.

> 
> Final comment: I'd really like to see a sort of "tested on" for things
> like this, because it's not clear which platforms/architectures it was
> tested on.