Re: ATF t_mlock() babylon5 kernel panics

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

    Date:        Wed, 13 Mar 2019 11:09:09 +0700
    From:        Robert Elz <kre%munnari.OZ.AU@localhost>
    Message-ID:  <27829.1552450149%jinx.noi.kre.to@localhost>

A few corrections/additions to my message:

  | "page" is the page size.(4KB, 8KB or 16KB or ...)

Looks to be 4K.   Is that correct?

  | From the number of kernel messages, I'm assuming one from each of
  | those mlock/munlock calls

Now I think more than one, with a 4K page size, that's just 4
iterations of the loop, and there are more than 8 printfs.  So
now I suspect 2 printf's per mlock() and munlock() (16 printfs)
which looks about right - though there might be 19 printfs, which
is a bit weird (but no-one ever claimed I can count).

  | (possibly excepting the first, but because
  | a similar buffer was malloc()/free() 'd in the previous sub-test,

That's not possible, there was no previous sub-test.  So:

  | it is conceivable that the page started out locked - that is, if malloc()
  | returned the same page as last time.

isn't possible.

  | The buffer is free()'d after that loop ends (of course).

In this test that always happens, as the only way the test fails
is if the page size < 1024 (and not "fails" there but skips) in
which case the test never bothers freeing the buffer (like I said
before, this test has bugs ... it should do the page size test
before the malloc())  or if the malloc() fails (when there is
nothing to free).

But in other tests, the buffer does not get free'd if the test
fails (and I think all of the others fail right now).


  | While I will not fix the bugs in the test that might alter the way
  | it interacts with the kernel, I will update the test to get more
  | information from the tests that fail (and check results that are
  | currently not checked and make them available - but so as not to
  | alter what happens, merely by output to stderr).

I have done that now, and will commit after a test build and run
to make sure I made no stupid mistakes (a simple compile test and
run on my development system, which is older, and where the test
works, reveals no issues).   The commit of this meaningless diagnostic
only change is so we can see more of what is happening in the b5 test
runs.  This actually reduces the info in a sense, as some
ATF macro calls which would have printed useful info about what failed
now will just say "err == 0 failed" or something ... but the extra
printf to stderr which will be immediately before that should provide
the missing info, and more.

kre