On Fri, Oct 05, 2012 at 02:44:24PM +0100, James Bottomley wrote:
> On Fri, 2012-10-05 at 12:07 +0100, James Bottomley wrote:
> > I tried out the code at
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal.git
> > experimental-kernel_thread
> >
> > and it gives me this panic on boot.
>
> OK, found the fix: the idle thread is a kernel thread, but it doesn't
> come through kernel_thread(). The fix is to check for it (fortunately
> it has the signal usp == 0).
Um... I see, but I really wonder if that's the right fix. FWIW, sparc
will have the same problem... Hell knows. OTOH, it's a nice way to
get of implicit interplay between copy_thread() and idle_regs() - note
that SMP architectures doing default idle_regs() need to be damn careful
about what they do in their "is that kernel thread" logics; all-zeros
pt_regs might give varying results on user_mode(regs) tests, etc.
Might be better to go for
if (p->flags & PF_KTHREAD) {
if (!usp) {
we are starting an idle thread
} else {
we are setting things up for kernel_thread()
}
} else {
we are forking
}
kind of logics, looking at regs only in the last case. And to hell with
(separate and overridable) idle_regs() once everything goes that way...
> I'm now getting as freeing the init memory, which then hangs, so I
> suspect some type of execve failure trying to start the initrd... I'm
> debugging.
What are you using for toolchain, BTW? With gcc 4.3 / binutils 2.20
(cross-builds) I'm getting panics from mainline kernel on parisc32 all
way back to 2.6.28...
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
