Re: Another UVM wire page count underflow panic

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Fri, 15 Mar 2019 13:28:32 -0700
    From:        Jason Thorpe <thorpej%me.com@localhost>
    Message-ID:  <B227447D-857A-4ACA-982D-C5C256FA2C70%me.com@localhost>

  | Careful, Robert, you're going to end up the designated maintainer
  | of UVM at this rate :-)

Not if I can find someone else to palm it off onto ...

Upon reflection, there is no hurry to fix this one, unlike the previous
one which was screwing up the b5 tests - we (at least currently) have no
tests which do anything as crazy as the code sequence to trigger this, so
we can take our time and solve it properly.

  | "Yuck."

Yes.   That't wasn't exactly my thought, but it rhymes.

  | POSIX's semantics could just as well be represented with a bit
  | in a flags word,

the one in the UVM map entry - yes, but that ons isn't really the
issue.   What matters is the pmap count, and even in posix that needs
to be a count, as multiple processes can independently lock the same
(shared) region, and neither one's unwire affects the wiring done by
another.

Unless my assumptions about what is what here are incorrect (which they
easily could be) the count that matters is the one which needs to remain
a count.

  | I would suggest that the right way to fix this would be as follows:

I think we ought to work out what the data structs should look like
in the various possible cases - including mixed shm and m*() allocations,
mappings, wiring, protection schemes - including where pages are
mapped (either in more than once in one process, or in different
processes) in both forms (a page that is a shm in one place is mmap'd
in another, and wired by one of them, or both, or neither).

Until we know what it will look like, I don't think trying to find
minimal code changes from what we have now will be productive.

First we need an audit of everything that affects or uses the UVM
mappings to see just what is required.  The shm stuff is easy that
way, as they have a very small visible footprint - even if they are
an ugly design.

Tomorrow (or much later today, or whatever you want to call it!)

kre