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

[Warner Losh]

> On Nov 13, 2016, at 12:03 PM, Konstantin Belousov <kostikbel at gmail.com> wrote:
> 
> 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.

User space N way mapping is rare. Can you show an actual example of when this  is commonly done? Or being done in init(8)?

> 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.

KVA mapping is different, since that mapping goes away. And generally, the KVA mappings aren’t active while user land mappings are active. Here ‘active’ means can change the cache. When the kernel is executing on these single core 32-bit mips boxes, user space isn’t creating traffic to the pages. Also, KVA mappings tend to be for pages that we don’t actually touch in the kernel once the I/O is complete. This is true for data pages in files. It may not be true for in-kernel meta-data pages, and that might have changed with your commit (I haven’t looked in enough detail to know).

But that still begs the question: why is the fault address 0 in the original crash report. If we’re doing multiple mappings, and that’s creating a cache coherency problem because there’s two copies of dirty cache data, how does that end up with us doing a NULL dereference? That’s the part that I’m having trouble understanding and I worry that arguing over the exact parameters of the VM mapping issues might be distracting us from a credible theory, with a specific sequence of events that gets us here.

It looks like we use the direct map in kernel for addresses < 256MB. KSEG0 covers a lot of sins.

NetBSD has code to cope with congruent mappings that cause problems. These look to be only on LONGSOON and MIPS3 processors with mips32 and newer not affected by it. MIPS3 has VCE exceptions for Instructions and Data and NetBSD has code there to cope. It also maps the pages uncached until the multiple mappings go away. The other code it has to cope is effectively disabled when not on these processors. It is a twisty maze of #ifdefs, though, so maybe I’m missing something. It does disable the socket page loaning code as well when there’s issues.

So, we’re back to the basic question: why does this change cause the observed behavior, exactly?

>> 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.

This sort of argument is pointless: the code does something new, and the current code doesn’t support it. It’s that simple. Trying to label new bug / old bug, etc is pointless. It’s a bug, and it’s gotta get fixed. It isn’t clear to me it’s even understood why things are happening, so even the old / new finger pointing is premature given we don’t have a definitive cause, just a theory.

Warner

>> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-mips/attachments/20161113/8f1134aa/attachment.sig>