RFC change to process.c

[Paul Mackerras]

Denis J Barrow writes:

> ptregs is set to NULL for kernel threads in linuxppc64  & linuxppc on
> 2.5.66 this
> is not done on non powerpc linux ports to my knowledge.
> The pSeries kernel boots fine with the modification below.

The thread_struct is completely architecture-specific, so other
architectures may well do something different.

> It specifically prevents me from modifying the pt_regs on my kernel thread
> & it
> appears to be more a hindrance than a help & makes kernel threads harder to
> debug,
> unless somebody can give me a good reason why this is the way it is I
> suggest
> that the change below be accepted.

There is a good reason why thread.regs is NULL for a kernel thread -
it is because thread.regs reflects the user-mode state of the process.
A kernel thread doesn't have any user-mode state for thread.regs to
point to.  Having a bogus (but superficially reasonable) value in
there caused some very subtle and hard-to-find bugs in the past (in
the ppc32 kernel), where code that wanted to modify user registers
(specifically the MSR) ended up changing bits in the page following
the process's kernel stack, causing completely unrelated code to crash
some random time in the future.

Why do you want to change the register values on your kernel thread
from another process anyway?  It sounds pretty dangerous.  If you are
trying to do kernel debugging, you won't get anywhere using
thread.regs either for a kernel thread or for a normal process.  If
you want to know about the state of a process that is blocked in the
kernel, you would look at p->thread.ksp for its kernel stack pointer,
then add on 112 to get a pointer to where its register values are
saved.  However, only r14 - r31, nip and cr are saved there - the rest
are either caller-saved (e.g. r0, r3-r13, xer, ctr), the same in all
processes (e.g. r2, msr) or saved elsewhere (r1, r13).

Paul.

** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/