Re: [uml-devel] kernel BUG @ fork.c:251

[Jeff D. <jd...@ka...>]

mi...@st... said:
> though i dont see how a change in rootfs really solves the problem
> because if the kernel goes done its consided a bug from my point of
> view. 

Definitely a kernel bug.

And it definitely popped up all of a sudden.  I haven't recently changed 
anything that seems relevant.

Can you get stack traces and make sure that it's always procfs?  If it's
not, I'm definitely interested in what else can be involved.

#3  0xa000cb8d in __mmdrop (mm=0xa018bf80) at fork.c:251
#4  0xa0014dc1 in access_process_vm (tsk=0xa08dc000, addr=2684354488,
buf=0xa19c0000, len=53, write=0) at ptrace.c:178
#5  0xa0048904 in proc_pid_environ (task=0xa08dc000,
    buffer=0xa19c0000 "Name:\tbdflush\nState:\tS
(sleeping)\nTgid:\t0\nPid:\t5\nPPid:\t0\nTracerPid:\t0\nUid:\t0\t0\t0\t0\nGi
d:\t0\t0\t0\t0\nFDSize:\t32\nGroups:\t\nVmSize:\t       0 kB\nVmLck:\t
0 kB\nVmRSS:\t       0 kB\nVmData:\t       0 kB\nVmStk:"...) at base.c:138
#6  0xa0048bc1 in proc_info_read (file=0xa0f1a724, buf=0x9ffff250
"/proc/5/environ", count=2047, ppos=0xa0f1a744) at base.c:265

It definitely seems related to ps.  When procfs reads stats out of all the
process address spaces, it gets a reference to the process mm, reads out
the data, and drops the reference.  What appears to be happening is an
extra drop or a drop without acquiring the reference in the first place.

So, the kernel thread mm is having its last reference dropped, which is what
is being trapped by that BUG().

				Jeff