[ros-kernel] Mm problem: "Freeing locked page"

[Mike Nordell]

(this follows discussions on IRC re. this bug)

Ge van Geldorp wrote:

> ... I found that the installer tries to ReadFile() something into
> a buffer which is located in the uninitialized data section (aka BSS).

Same thing I've experienced, but with a much smaller program. Just trying to
ReadFile into a buffer held in BSS memory crashed the kernel. For the ones
not knowing what BSS is, it's uninitialized process global  data. Basically,
at global scope:

  char foo[47211];

puts foo in BSS. R/W data segment, but neither initialized nor
committed/mapped (from the kernels POV) until actually used. Upon first
touch from the program (read or write doesn't matter) the memory (obviously,
one page at a time) is to be zero-filled before handing it over to the
program.

And herein lies the problem it seems.

> I tried to fix it with the attached patch

I can veirfy that it worked for this/my particular problem I did see.
Though, looking at the surrounding code I, like you I suspect, have a
nagging feeling this isn't the right way to go about it. What I've been
thinking about is - perhaps that kernel-null-page used for e.g. BSS should
be referenced one more time when it's mapped into/used from a process' BSS
data (if it even is referenced now)? That way it would never get into this
section of the code where refcount==0, but the lock count > 0.

Until the other problems are researched, I think it's a good thing to not
commit this patch just yet, but to see if my idea (or anyones elses) might
have some merit and bring us closer to the *real* solution for the problem
at hand. It is however a severity 1 problem, crashing the kernel from a
plain usermode program.


Thanks Gé, for finding out why and how it crashed in this case.

/Mike